智能体一旦同时对接多个业务系统，故障现场就会变得非常嘈杂。表面上看都是 Agent 没有把任务跑完，往下追可能是一次 OAuth 凭据过期，可能是一个工具的入参 schema 改了没同步，也可能是因为下游权限没放开导致 403。日志如果只记一句话 调用失败 ，第二天复盘就要花一上午重新跑一遍现场，问题真正的原因经常被掩盖在重试堆栈里。
要让日志真的能定位问题，关键是把每一次跨系统调用拆成三类事实一起记录。凭据类事实包含 token 类型、颁发方、过期时间、刷新策略、是否被同一进程复用；工具类事实包含调用哪个 skill 或 API、入参和出参的摘要、版本号、超时时间、重试次数和最终状态码；权限类事实包含目标系统的租户、用户、角色、授权范围、是否命中 RBAC 或 IP 白名单。三类事实在调用前、调用中、调用后各写一次，事后排查就不再依赖操作员的记忆。
做这套日志方案可以参考三个判断标准。第一是字段固定而不是自由文本，调用前就生成调用 trace ID 贯穿全程，token 摘要只记哈希不记明文，工具调用只记入参出参的关键字段而不是整段 JSON，这样既方便检索又不泄漏敏感数据；第二是失败分级而不是只有成功失败，至少区分凭据失效、工具异常、权限拒绝、上游超时四类，每一类对应一种修复路径而不是一个统一的重试；第三是保留可回放的上下文，对话快照、工具调用链、当时的网络环境都要落盘，复现问题不需要再去找用户要一遍对话原文。
这套方法适用于已经在生产里跑 AI Agent、并且同时对接两个以上业务系统的团队，比如同时接入 ERP、客服、工单、知识库的场景。如果 Agent 只是单系统跑流程，故障定位并不复杂，搭建完整日志的成本反而高于收益；如果 Agent 还在原型阶段，连稳定调用都做不到，先把稳定的调用链跑顺再考虑日志分级。
ClawMercs 企业智能体中心在协议层就把这三类事实做了统一封装。每次跨系统调用都会自动写入 token 摘要、工具版本和权限上下文，调用链 trace ID 在对话、工具调用、知识检索、外部 API 之间贯通；排查时可以直接按 trace ID 拉出一条完整链路，看到 token 在哪一步被识别为失效、工具调用在哪一步返回了 4xx、权限在哪一步被拒绝，而不需要在多个系统的日志后台来回切换。如果团队已经在用 ClawMercs，可以直接在治理面板里配置日志保留周期和告警阈值，而不用单独搭一套日志系统；如果还没引入智能体中心，也可以在现有 Agent 框架里按上面的三类字段手动补齐，先用脚本落库，等体量起来了再考虑迁移到统一中心。
落地可以按三步推进。第一步先梳理当前所有跨系统调用的入口清单，标注每个调用涉及的 token、工具、权限字段，确认现有日志框架能拿到这些字段；第二步按上面的判断标准改造日志输出，让 trace ID 自动贯通，并按凭据、工具、权限三类打标签，敏感字段做哈希处理；第三步做一次故障演练，模拟 token 过期、工具版本变更、权限拒绝三类场景，确认按日志就能在十分钟内定位到根因，再决定是否接入告警和自动化修复。