夜雨聆风点击上方 前端Q，关注公众号
回复加群，加入前端Q技术交流群
上一篇我们聊了 Agent 的安全治理。安全是"防御层"，这一篇我们聊"洞察层" —— 也就是可观测性。
我和企业团队讨论 Agent 落地时，第二高频被问的问题（仅次于安全）就是：
"我们怎么知道这个 Agent 现在到底在做什么？"
"上线一个月了，它有没有变好？"
"出问题怎么排查？我们 Trace 系统接得上吗？"
这些问题听着是"运维问题"，本质上是 ——没有可观测性，就没有信心。
普通服务的可观测性已经被讲烂了（metrics + logs + traces）。但 Agent 不一样：
普通监控工具（Prometheus + Grafana + Sentry）能照搬，但远远不够。这一篇我们就拆开"Agent 专属可观测性"应该长什么样。
Agent 可观测的 4 个维度
先看全景图：
Hermes 把可观测性分成 4 个维度，每一个对应不同的数据源、不同的关注角度。
维度 1：行为维度（What did it do？）
回答的问题：Agent 这一次干了啥？
数据源：第三章 14 篇讲过的 Trajectory。所有事件都按 schema 持久化在 JSONL 里。
典型用法：debug 一次失败任务、回放一次诡异行为、理解一次复杂决策。
维度 2：成本维度（What did it cost？）
回答的问题：这次任务花了多少钱？
数据源：每个 LLM call 后，从 response usage 里提取 token 数 + 已知单价。
典型用法：成本归因（哪个用户/项目花得最多）、成本异常告警（突然爆表）、优化决策（要不要换便宜模型）。
维度 3：质量维度（Was it good？）
回答的问题：这次任务做得怎么样？
数据源：
典型用法：判断"Agent 越用越好还是越用越差"、找出最差 Skill、定向优化。
维度 4：学习维度（What did it learn？）
这是 Hermes 这种自进化 Agent 独有的维度。回答的问题：它从这次任务学到了什么？
数据源：Memory Store + Skill Manager 的事件流。
典型用法：判断"这个 Agent 真的在变强吗？"，这是第 30 篇的核心话题。
金句：4 个维度合在一起，才看得见 Agent 的全貌。
很多团队只盯成本和质量，结果 ——
4 个维度缺一不可。
必看的 3 类核心指标
维度讲完了，下面是更实操的 ——到底哪些指标必须盯？
我把它分成 3 类：
第 1 类：任务级指标
这是最顶层的"业务感"指标，直接代表 Agent 服务的健康度：
任务级指标异常 = 质量出问题。这一类指标必须做实时告警。
第 2 类：工具/Skill 级指标
任务级是"业务感"，工具/Skill 级是"能力感"：
工具/Skill 级异常 = 能力出问题。这一类指标用日报形式看比较合理。
第 3 类：成本级指标
成本级是"账单感"：
成本级异常 = 账单要爆。这一类必须有 cost cap 兜底（第三章 15 篇讲过）。
金句：看这 3 类指标，比看 100 个零散数字管用。
我见过有团队搞了 200 个指标的 dashboard，结果根本没人看 —— 指标多 = 有效信息少。把这 3 类共 12 个指标盯死，已经能解决 90% 的问题。
一次失败任务的回放路径
监控指标只能告诉你"出事了"，真正排查问题靠的是回放（Trace）。
Hermes 的回放路径长这样：
步骤 1：用户报告 → 找 session_id
用户反馈"Agent 把代码改坏了"。第一动作是 ——根据用户和时间找到 session_id。
管理台的查询接口大概是：
FROM sessions
WHERE user_id = 'xxx'
AND started_at > '2026-04-25 14:00'
ORDER BY started_at DESC
LIMIT 10;
关键设计：每个 session 必须能从用户/时间反查到。这要求 Trajectory 写入时就索引这两个字段。
步骤 2：拉 trajectory → 看完整事件流
拿到 session_id 后，加载这个 session 的完整 trajectory：
输出长这样：
[turn 1] memory_loaded: project_facts.md (200 tokens)
[turn 1] skill_loaded: fix_frontend_bug_v3
[turn 1] llm_call: input=2.1k, output=380
[turn 1] tool_call: file_read('src/login.tsx')
[turn 1] tool_result: <file content>
[turn 2] llm_call: input=4.5k, output=520
[turn 2] tool_call: file_write('src/login.tsx', ...) ← 这里！
[turn 2] tool_result: success
[turn 3] llm_call: input=5.2k, output=180
[turn 3] task_complete: true
步骤 3：定位到出错的 turn
从 trajectory 里找出"出错那一步"。通常是：
步骤 4：查 prompt + tool_call 详情
定位到 turn 后，深入看那一轮的完整输入输出：
会展开：
步骤 5：根因定位
看到 prompt 和 tool_call 后，根因通常 5 分钟能找到。常见的根因：
金句：5 分钟从用户反馈到根因 = 完整可观测性。
如果一次问题排查要超过半天，那大概率是可观测性还没做到位。
告警策略：4 个层级
监控指标 + 回放路径有了，下一步是告警 —— 也就是"什么情况要主动通知人"。
告警最怕两个极端：
正确的做法是分层级告警：
P0：自动停 Agent
最严重的级别，告警的同时要采取自动行动：
P0 告警要配合自动响应，不能光通知人。因为 P0 事件如果要等人来响应，损失已经发生了。
P1：立即报警
需要人 5 分钟内介入：
P1 推电话或 IM 告警，必须有人值班。
P2：日报汇总
不需要立即处理，但要每天看：
P2 用日报形式，每天早上一封邮件，团队 review。
P3：仪表盘观察
不主动推送，需要看的时候看：
P3 在 Grafana 上看就行。
金句：好的告警是少而准，不是多而杂。
我建议P0 + P1 加起来不超过 10 条告警规则。少而准，每一条都有人会响应。多了大家就开始忽略。
实操：怎么搭一套 Agent 可观测性
讲了这么多概念，给一份具体的工程方案。完整的 Agent 可观测性栈通常包括 4 层：
第 1 层：采集
Hermes 自己已经把数据采集做好了：
你不需要额外开发，只需要把这些数据导出到你已有的监控栈。
第 2 层：存储
不同类型的数据用不同的存储：
第 3 层：可视化
至少要有 4 个 dashboard：
我推荐用 Grafana。开源、免费、生态好。
第 4 层：告警
P0/P1 接 IM Bot（钉钉/飞书 + on-call 系统），P2 接邮件，P3 不告警。
告警规则用 Prometheus 的 alerting rules 写，灵活、可版本化。
金句：可观测性不是搭个 dashboard 就完事，是一套从采集到告警的完整闭环。
我的看法
写完这一篇，我想对所有正在落地 Agent 的团队说一句：
没有可观测性的 Agent，就是黑盒；黑盒的 Agent，没有人会信任。
Agent 跟普通服务最大的区别在于 ——它的行为是不确定的。同样的输入，今天可能这么干，明天可能那么干。这种不确定性如果没有可观测性兜底，用户的每次体验差异都会被怀疑成"是不是 Agent 又抽风了"。
而有了 4 个维度的可观测性后：
这种"全程可见"的状态，才能让企业从"试用"走到"信任"。
我个人最看重的不是任何单个指标，而是 ——第 4 个维度（学习维度）这件事被严肃对待。前 3 个维度是普通服务可观测性的延伸，第 4 个才是自进化 Agent 独有的。
如果一个 Agent 框架号称"自进化"，但没有任何方式让你看到"它学了什么、学得怎么样"，那它的"自进化"就是营销话术。
Hermes 把"学习维度"做成可观测的一等公民，这是它能在企业站稳的关键之一。
下一篇（29），我们换一个角度 ——怎么把"个人 Agent"扩展成"组织 Agent"。从一个开发者本机的 Hermes，到一个公司级别的 AI 平台，要走过哪几步？踩过哪些坑？
往期推荐
