Partnership on AI · 可观测性评估报告
原文：The Observability Gap in AI Agents · 报告 PDF
有调用链，还缺什么
一条 trace 可以显示 Agent 读取了文件，却未必能说明它当时以什么身份、在什么权限下读取。如果会话中途放宽了审批模式，或者子 Agent 继承了不同的权限，事后只看工具调用成功，可能无法重建授权过程。
PAI 的报告把问题放在监控工具之前：框架是否发出了回答这些问题所必需的记录？ 下游分析平台即使能够关联和展示事件，也通常无法补回从未被记录的状态变化。
用一次权限变化理解“缺口”
下面是帮助理解报告的示例，而非另一项实测事件：一个 Agent 起初需要人工批准才能执行某类操作，会话中途改成了自动执行，随后成功调用工具。日志留下了工具名、参数、结果和耗时。
这些信息足以解释“执行了什么”，却不足以判断模式变化是否符合预期。我们还需要知道：改变前后的模式是什么、谁触发了变化、以哪个身份生效，以及那次动作发生时使用的是哪套权限。
若其中一项从未记录，事后分析只能留下不确定性。即使模型能够编出一个合理解释，也不等于补回了真实发生的事件。报告把这类问题称为遥测生成层面的缺口：先有可关联的记录，才谈得上从中推导监控信号。
从目标倒推数据，而不是从已有日志猜用途
读图：从上往下看“要监控什么 → 如何形成信号 → 缺少什么记录 → 谁能补齐”。这是报告的分析框架，不是一套已经部署的产品架构。
报告先提出六类目标，包括识别越权、策略违反、人工监督失效、行为漂移、多 Agent 风险及支持事后审计，再分析所需的数据处理方式。例如，判断越权需要把行为关联到有效身份与权限；发现漂移需要跨运行建立基线；追踪委托关系需要连起多个 Agent 的事件。
这个顺序很实用：先明确“我们要识别哪一种失败”，再检查字段与关联是否充分。它避免了把日志数量或 dashboard 完整程度当成监控能力。
四种处理方式，各需要什么输入
报告没有把所有监控任务都交给同一种评分器，而是区分了四种处理方式。它们可以组合使用，但不能相互替代所缺的基础记录。
- 关联权限上下文： 将动作关联到执行身份、当时权限和外部授权记录，判断是否处于允许范围。动作被允许，也仍可能是一个糟糕的业务决定。
- 追踪来源与归属： 连起父子 Agent、指令、数据和证据的流向，解释一次委托由谁授权、一次结论使用了哪些输入。孤立的单 Agent 日志不够。
- 做语义比较： 把输出或行为与政策、任务意图或参考证据比较。它需要清晰的参照，也会受模型判断误差影响。
- 聚合并建立基线： 跨会话查看行为、配置和记忆如何变化。没有长期身份和状态变更记录，可能把不同实例混在一起，也可能错过真正的漂移来源。
回到权限变化示例，语义评分能够提醒“这个操作看起来可疑”，但确认是否越权，还需要可靠的身份与权限状态。下游分析越复杂，对上游字段的要求往往越明确。
具体缺口在哪里
报告评估了 OpenAI Agents SDK、Claude Agent SDK、LangGraph 和 CrewAI 的技术文档。其结论首先应理解为该次文档评估的时点快照，并非对所有部署配置的实时测试。
其中四类缺口与执行记录直接相关：
| 记录 | 希望回答的问题 |
|---|---|
| 持久 Agent 身份 | 跨会话、跨子 Agent 后，能否确认是谁在行动？ |
| 权限模式变更 | 何时、由谁把审批或自主执行模式改了？ |
| 记忆变更 | 哪次写入改变了后续行为，写入因何发生？ |
| 人工介入 | 为何升级、谁审核、具有何种权限、做了什么决定？ |
另外两类是推理过程和 token 级概率。它们更多依赖模型提供方是否暴露相关信息，而且信号的解释本身仍有不确定性。报告并不认为拿到推理文本就等于知道了真实决策原因，也不把 token 概率视为可靠的任务正确性分数。
因此，两类问题的工程路径不同：明确的执行事件可以通过补充字段、标准和采集实现改善；关于决策过程的信号，还需要研究其有效性。
为什么“记录了”还不等于“可以监控”
字段存在只是第一步，还要检查它是否足以完成关联。例如，一个运行内唯一的名字，未必能映射到企业识别的 Agent 身份；一个“人工已批准”的布尔值，也没有说明批准人是否具备对应权限。
记忆也是类似情况。保存操作的开始和结束，可以证明发生过一次调用，却不一定说明写入了什么、为何写入，以及它如何改变了后续决策。如果只观察最终行为，可能很晚才发现一个错误经验已经被持续复用。
报告因此区分完整、部分和缺失三档，再按类别汇总。主文矩阵便于快速看分布，具体采用时仍需检查字段级说明；一个颜色不能替代对采集范围、版本和关联语义的理解。对于敏感内容，也不能把“收集越多越好”作为默认原则，记录需求应从明确的监控目标推导。
这份评估有多强的证据
作者从两个假想金融业务场景出发，通过工作组讨论整理监控目标，然后逐字段评审四个框架的文档，采用 AI 初筛再人工核对。它提供了可检查的字段清单和分析依据，但没有通过大规模生产流量或故障注入测量这些缺口实际造成了多少失败。
这也决定了适合怎样使用它：可以用来审视自己缺少哪些记录，不能拿框架间的色块评分直接判断哪一个产品最安全。框架版本、额外插桩和组织自己的身份系统，都可能改变实际可观测性。
工程判断：把它作为监控需求的检查表
可以把需求审查组织成一个小闭环：先列出必须发现的事件，再为每个事件列出最小证据链，检查框架与外部系统是否能够提供，最后用一次可控测试确认记录确实到达分析端。这里是基于报告整理的工程使用方式，不是报告已经评测过的诊断产品。
还应区分“没有发现风险”与“没有足够记录做判断”。例如，一次运行没有权限变更事件，可能意味着权限未变，也可能意味着该事件根本没有被采集。这两种情况不能共用一个绿色成功状态。
落地时可以挑一个最关心的风险，沿图中的依赖链检查。例如，若要发现审批被绕过，应同时找到动作记录、当时的权限状态、模式变更事件和审核者身份；仅有“工具执行成功”并不够。
这份报告的价值是把“需要更好的 observability”落实为具体数据要求。对已经在做轨迹评分或根因分析的系统，先确认输入证据是否完整，往往比再增加一个分析面板更关键。报告没有提供可直接部署的诊断系统，技术文档结论也应在采用时按所用版本重新核对。