大家好，我是金全。

过去做 APM，我们很关心一条 Trace 是否完整：

请求从哪里进来，

经过哪些服务，

最后在哪里变慢、报错或者中断。

Agent 进入生产以后，

很多企业已经能够把一次运行的 Trace 完整呈现出来：

任务经过几个步骤，

调用了什么模型和工具，

每一步花了多少时间。

可一旦业务结果出了问题，

大家还是可能说不清：

Agent 当时到底做了什么？

这让我越来越强烈地感觉到：

一条 Agent Trace 可以很完整。

一次 AI 行为仍然可能没有被完整记录。

Trace 通常记录执行路径，而企业真正需要还原的是：

一个任务怎样经过 Agent 的理解、选择和行动，

最终改变了什么。

这才是一条完整的 AI 行为链。

我越来越觉得，

AI 可观测性的观察对象不再是一条 Trace，

而应该是一次业务行为。

这里说的“一次业务行为”不是某一次模型调用，

而是从任务触发到 Agent 获取信息、作出判断、采取行动并产生业务结果的完整过程。

行为链，就是把任务、Agent 获取的信息、作出的关键选择、执行动作、任务流转、状态变化和业务结果关联起来。

这里的任务流转包括任务在 Agent、子 Agent、人工和系统之间的转交。

Trace 是行为链的重要基础。

但行为链的边界，不能被一条 Trace 的边界限制住。

客户向客服 Agent 提交了一次费用争议。

Agent 查询客户资料和补偿政策，

调用 CRM 创建补偿券，

通知客户并关闭工单。

从系统记录看，这次运行很顺利：

接口全部返回成功，工具调用顺序也很清楚。

但如果客户随后投诉补偿金额错误，企业要回答的就不只是调用过哪些接口，还包括：

• 最初交给 Agent 的任务到底是什么？

• 它只是提供建议，还是可以直接补偿？中间有没有请求人工确认？

• 补偿券创建、工单关闭以后，客户权益和后续流程发生了什么变化？

• 这次动作最终解决了问题，还是制造了新的客诉？

如果只能看到模型调用和工具调用，企业看到的仍然只是一段技术路径，还不是完整行为。

工具调用只能证明 Agent 做了一步操作。

行为链还要说明，这一步操作在整个任务里意味着什么。

我之所以把它叫作“行为链”而不是执行链或者调用链，是因为企业真正需要追踪的不是一串调用，而是一系列前后相连、最终改变系统或业务状态的行为。

一条行为链应该从哪里开始？

不是第一次模型调用。

也不是 Agent 第一次选择工具。

而是：

这次运行为什么被触发，企业到底交给了它什么任务。

同一句“处理客户投诉”，可能代表完全不同的任务。

它可以只是整理材料、生成建议，也可以创建补偿方案等待确认，甚至被理解成直接完成处置。

如果行为链从模型调用才开始，最初任务、目标和允许的行动范围就已经丢了。

所以，行为链的起点至少应该留下：

• 谁或者什么系统触发了任务；

• 当时要解决什么问题；

• 任务要处理什么对象，需要完成到什么程度；

• Agent 是提供信息、提出建议，还是可以直接执行；

• 当时处于什么业务场景，有哪些限制。

Prompt 只是任务进入 Agent 的一个入口。真正需要留下的是：

Agent 当时接到的是一个什么任务。

传统 Trace 擅长用父子 Span 串起调用关系。

到了 Agent 系统，这套方法仍然是基础。

一次会话中的模型调用、检索和工具执行需要被串起来，跨会话的前后关系也不能丢。

但 Agent 的运行过程比一条同步调用链更复杂。

一个任务可能持续很久，把子任务交给其他 Agent，等待人工审批或异步消息，也可能因工具失败而重试，切换模型、工具或执行路径，或者从自动执行转为只生成建议、交给人工处理。

所以行为链不能只记录：

调用模型

调用工具

返回结果

它还要记录：

• 哪个 Agent、哪个版本正在执行；

• 任务被拆成哪些步骤，分别由模型、工具还是其他 Agent 完成；

• 是否发生过重试，是否切换过模型、工具或执行路径，是否从自动执行转为只生成建议、交给人工处理，或者中止任务；

• 哪个步骤等待人工确认，人工修改、批准或者拒绝了什么；

• 哪个工具真正改变了系统或业务状态；

• 前一步的结果怎样触发了后一步。

这里要记录的是可核对的运行事实，而不是模型写下的一篇“思考作文”。企业需要知道的是：

当时做过哪些选择、调用和动作，任务又怎样在 Agent、人工和系统之间流转。

很多 Agent Trace 到工具返回以后就结束了。

接口返回 200，脚本执行成功，工单状态更新完成。

从技术上看这次执行已经结束。

但从企业角度看真正重要的事情可能才刚刚开始。

补偿券会改变客户权益，工单关闭会改变服务流程，配置修改会改变生产状态，代码合并会进入后续发布流程。

如果行为链没有继续连接客户、工单、配置等处理对象及其状态，就会出现一个很典型的问题：

技术团队能够证明动作执行成功。

业务团队却说不清这次动作究竟影响了什么。

所以，

行为链不能停在 Agent 输出结果或工具调用完成。

更合理的终点是：

这次行为改变了哪些系统状态、业务流程或客户权益，最终结果是否已经能够确认。

调用链通常以请求完成作为边界，AI 行为链必须继续追到状态变化和业务后果。

我认为，

一条能够用于生产复盘的 AI 行为链，至少要包含六部分。

第一：任务

这次运行为什么开始，由谁触发，要解决什么问题，预期完成到什么程度。

第二：执行主体

哪个 Agent 接手任务，使用哪一版 Agent 配置，使用什么身份、在哪个环境运行，是否调用子 Agent 或发生人工接管。

第三：运行过程

任务跨越了哪些会话，进行了哪些模型调用和检索，使用了哪些工具与流程，这些步骤之间是什么关系。

第四：关键选择与任务流转

在哪些位置选择了工具、把任务交给其他 Agent、进行重试、切换执行路径、等待审批、转人工处理或接受人工修改，哪些选择改变了后续路径。

第五：动作与状态变化

Agent 最终操作了哪个对象，执行前后状态如何变化，哪些变化可以回滚，哪些已经不可逆。

第六：业务结果

任务是否完成，结果是否被采用，影响了哪些客户、交易、服务、数据或流程，是否产生返工、投诉、成本、收益或新的风险。

这六部分连起来，企业看到的才不是一棵只有技术步骤的 Trace。

而是一次 AI 行为从开始到产生后果的完整现场。

一条技术 Trace 通常有清楚的开始和结束，但一次 Agent 行为可能跨越多个系统、多个会话，甚至持续很长时间。

例如，一个 Agent 先生成补偿方案。

几个小时后，人工完成审批，结果通过消息进入另一个系统，再由另一个 Agent 创建补偿、通知客户并关闭工单。

从技术上看，这可能是几条 Trace。

但企业关心的是一件事有没有完成，

而不是几条 Trace 有没有结束。

如果不能识别同一个任务、同一个处理对象以及它们的前后关系，每条 Trace 看起来都完整，合在一起却说不清到底发生了什么。

所以行为链还需要能够跨 Trace 关联：

• 同一个任务；

• 同一个客户、工单、订单或变更对象；

• 同一个 Agent 及其版本；

• 前后相连的审批、消息和异步动作；

• 同一个最终业务结果。

讲到这里有人可能会担心：

这些内容都要记录，数据量、隐私和合规怎么办？

完整行为链不等于全量复制一切。

企业真正需要的是，出了问题以后能够把关键事实重新关联起来。

普通、低风险的问答可以轻量记录；涉及客户权益、资金、权限和生产操作的行为，需要保留更完整的现场。敏感内容可以脱敏，大型文档记录来源、版本和引用位置，关键动作保留前后状态。

也就是说：

行为链追求的不是数据最多。

而是关键事实没有断。

这和过去做可观测性很像。

采集指标、日志和 Trace，不是为了保存每一个字节，而是为了在出问题时还原关键路径。

我做了十几年 APM 和可观测性。

过去 Trace 帮助企业回答：

一次请求经过哪里，哪个服务影响了哪个服务，故障怎样沿调用关系传播。

这套能力不会因为 AI 出现而失去价值，反而会成为 AI 可观测性的基础。

但 Agent 进入生产以后，Trace 的对象正在发生变化。

过去主要追请求，现在还要追任务。

过去主要追服务调用，现在还要追任务在 Agent、工具、人工和业务流程之间的流转。

过去主要追错误和延迟，现在还要追动作、状态变化和业务后果。

所以我越来越觉得：

AI 行为链，不是重新发明一套 Trace。

而是让 Trace 从请求路径，继续走向行为现场。

一条完整的 AI 行为链，不能只告诉企业 Agent 调用了什么模型、执行了哪个工具、接口有没有返回成功。

它至少还要回答：

• 任务为什么开始，

• 由谁执行，

• 经过了哪些步骤、关键选择和任务流转，

• 哪个动作改变了系统或业务状态，

• 最终产生了什么业务结果。

只有这些内容能够被关联起来，企业才可能真正还原：

AI 到底做了什么。

行为链不是为了多记录几个步骤。

它真正要还原的，是一次 AI 行为发生时的完整现场。

下一篇，

我想用企业里最容易形成共识的 Coding Agent 看看一条行为链在真实工作现场里是什么样。

代码仓库记录了最终改动。

但它能不能解释 AI 为什么读了这些文件、执行了这些命令，

又是怎样一步步写出这段代码的？

行业参考：OpenTelemetry GenAI Semantic Conventions、Datadog Agent Observability Terms and Concepts、AgentOps Traces。