很多团队评价 AI Agent 时，只看最后输出：文章写没写好、邮件发没发对、报告有没有结论。但一旦任务失败，只看结果就不够了。你需要知道它读了哪些资料，调用了哪些工具，中间改过几次计划，哪一步等待人工确认，成本花在哪里。
这就是 AI Agent 观测性。它不是简单多打一份日志，而是把智能体的执行过程拆成可追踪、可衡量、可复盘的信号。前面讲过 任务状态机、失败重试与幂等设计 和 OpenClaw 连接器审计，观测性就是把这些运行证据放到同一张图里。
Traces 负责还原调用链路
Agent 执行一次任务，通常不是一次模型调用就结束。它可能先理解目标，再检索知识库，接着调用表格、搜索网页、生成草稿、等待确认，最后写入外部系统。traces 要记录的就是这条链路。
一个可用的 trace 至少要包含任务 ID、步骤名称、工具名称、输入摘要、输出摘要、耗时、状态和错误信息。这样失败时才能回答：是模型计划错了，还是工具返回错了，还是外部系统权限不够。
Metrics 负责判断系统是否变好
日志能解释单次问题，指标能看长期趋势。比如任务成功率、人工退回率、平均执行时长、单次成本、重试次数、工具失败率、确认节点等待时间，这些都比“感觉最近跑得还行”可靠。
指标不要一开始做太多。先选 5 个最能影响业务判断的指标，每周复盘一次。对内容运营 Agent 来说，可能是发布成功率、封面生成失败率、SEO 字段缺失率和内链数量；对销售 Agent 来说，可能是线索归类准确率和跟进任务完成率。
Logs 负责留下可读证据
观测性不是给工程师看的黑盒报错。真正好用的日志，应该让运营、产品和负责人也能读懂。比如“因为缺少客户行业字段，Agent 暂停生成报价邮件”，就比一串异常堆栈更适合业务复盘。
同时，日志要注意脱敏。客户邮箱、合同金额、访问令牌、内部账号不能裸写进日志。前面讲 工具权限模型 时提过权限分层，日志也应该有相同意识：能追责，但不扩大敏感信息暴露面。
人工确认也要纳入观测
很多 Agent 流程最慢的地方不是模型，而是人工确认。谁卡住了确认，为什么退回，退回后改了什么，这些都应该记录下来。否则团队只会觉得“Agent 不够自动化”，却看不到真实瓶颈可能在审批规则不清。
人工确认节点 不是流程里的麻烦事，而是高风险动作的保护层。把确认节点纳入观测，团队才能逐步判断哪些动作可以自动放行，哪些动作必须继续保留人工判断。
总结
AI Agent 观测性的核心，是让智能体不再只留下一个最终答案。traces 还原链路，metrics 判断趋势，logs 保留证据，人工确认和成本记录帮助团队持续优化。只有看清每一步发生了什么，Agent 才能进入更稳定的日常工作流。
