追踪规划层：为什么你的智能体追踪只记录了一半的故事

你的智能体在最终成功之前三次调用了错误的工具，而你的追踪仪表板准确地向你展示了哪些工具被调用、调用的顺序以及完整的延迟分析。但追踪无法展示真正关键的部分：为什么智能体认为这些工具调用是正确的决策、它试图完成什么目标，以及它在做出每一个错误决定时基于什么样的假设。

这就是 2026 年智能体可观测性核心存在的鸿沟。从业者在工具调用追踪上投入了大量资源。工具已经成熟，OpenTelemetry 语义规范已经确立，仪表板也非常精美。但智能体调试总是会撞上同一堵墙：你可以完全洞察智能体做了什么，却无法看到它为什么这么做。

现代智能体追踪究竟能为你提供什么

当前这一代可观测性平台——LangSmith、Arize Phoenix、Langfuse、Helicone、Braintrust——都趋向于相同的数据模型。追踪是一个 Span 的瀑布流：智能体接收输入，执行一系列工具调用，并产生输出。每个 Span 捕捉工具名称、输入参数、响应负载、延迟和 Token 计数。通过对请求进行聚合，你可以获得仪表板，显示哪些工具最常失败、哪些步骤最慢，以及 p99 延迟的表现。

这对于解决运维问题确实非常有用。当一个工具开始超时，你可以立即发现。当延迟激增，你可以隔离出是哪一步性能下降。当工具返回错误时，Span 会记录下来。

然而，这些追踪无法告诉你任何关于产生这些工具调用的过程。智能体在做出每一个决策时都经过了推理——分解目标、生成关于哪些行动能满足目标的假设、评估约束并选择路径。这些都不会出现在任何 Span 中。产生这些行动的推理过程在当前的可观测性模型中是结构性缺失的。

简单的日志记录可能会捕捉到工具的输入和输出，但它总是会漏掉中间的推理步骤，以及智能体在采取行动之前执行的结构化规划。要诊断规划层面的失败，你需要智能体决策路径的逐步记录，而不仅仅是执行路径。

规划层：智能体在行动前究竟在做什么

当一个基于 LLM 的智能体收到任务时，执行并不会立即开始。它会经历一个规划阶段：智能体将请求分解为子目标，对世界状态做出假设，识别限制其选择的约束，并构建一个它认为能满足原始目标的计划。

在一个目标导向的智能体中，这大致表现为：

• 目标分解：将高级目标分解为一系列可执行的子任务。例如，“分析客户账户并发送摘要”变成了一个由依赖步骤组成的图：检索账户数据、总结使用情况、格式化发送内容、发送。
• 假设生成：在执行之前，智能体对它将发现的情况形成信念。例如，“账户数据 API 可能会返回带有 usage 字段的 JSON。”这些假设驱动了工具的选择。
• 约束满足：智能体评估在给定速率限制、权限范围、可用工具以及会话中先前的失败情况下，哪些路径是可行的。
• 计划形成：对行动进行排序，如果执行成功，这些行动应该能产生预期的结果。

这就是规划层。它运行在 LLM 的前向传播中，在大多数生产架构中，它的输出是转瞬即逝的——它们作为 Prompt 中的上下文存在，影响下一个 Token，然后消失。

执行层——即工具调用及其结果——是被追踪的部分。而生成这些调用的规划层则没有被记录。

工具追踪无法诊断的失败模式

实际后果是，一整类智能体故障在生产环境中保持不可见。2025 年的研究将这些归类为规划层失败，它们具有共同的特征：执行追踪表面上看起来是合理的，但智能体始终在错误的Premise（前提）下运行。

假设失效且未重新规划。智能体在任务早期形成了一个假设——比如，某个 API 终端以特定的 Schema 返回数据。当第一个工具调用完成时，该假设被证明是错误的。一个设计良好的智能体应该根据响应更新其计划。然而，许多智能体会继续执行原始计划，将错误的数据代入后续步骤。工具追踪显示所有正确的工具都在以合理的顺序被调用。它无法提供任何信号表明智能体对世界的底层模型在第一步就错了。

多步任务中的目标漂移。在第一步制定的计划往往需要在第四步进行修订。上下文窗口积累的信息可能会改变对原始目标的理解。由于缺乏明确的目标状态跟踪，智能体可能会悄悄地为一个与请求略有不同的目标进行优化。工具追踪忠实地记录了每一个动作。但它无法告诉你，到第六步时，智能体已经隐含地重新界定了任务范围。

规划阶段未发现的约束违反。智能体有时会选择一系列动作，这些动作单独看起来是有效的，但集体违反了约束——比如在速率限制仅允许一个请求时并行执行三个昂贵的 API 调用，或者在确认拥有写入权限之前就向资源写入数据。如果在规划期间发现，这些失败是可以恢复的。在生产中，它们在工具调用追踪中表现为连锁错误，而没有任何迹象表明根因是规划阶段的错误约束模型。

子目标遗弃。复杂任务被分解为多个子目标。当一个子目标失败时，智能体经常会跳过它并继续执行下一个，产生在工具调用层面看起来成功的完整结果。单个 Span 都以预期的错误成功或失败。没有任何追踪记录显示一个必需的中间目标被默默地放弃了。

对智能体失败分类法进行规范化的研究编目了 148 条包含这些模式的精心挑选的执行追踪，并发现即使是长上下文模型也难以仅凭工具追踪来调试它们——因为诊断信息根本不在追踪中。

增强规划层的可观测性

暴露规划状态需要刻意的插桩（instrumentation）。核心思想很简单：当智能体（agent）生成规划时，将该规划序列化为结构化制品（artifact）并附加到追踪（trace）中。当规划发生修订时，记录修订内容及其原因。

结构化推理输出。 最直接的方法是提示智能体在执行任何工具调用之前，以结构化格式显式输出其规划状态。一个捕获当前目标、活跃子目标、假设和约束的 JSON 对象，可以让你在执行开始瞬间捕捉到智能体世界模型的快照。该对象可以作为属性附加到根追踪跨度（root trace span），或者作为链接制品嵌入。

目标树跨度（Goal-tree spans）。 与其附加单个规划快照，不如将每个子目标建模为独立的跨度。父跨度代表总目标。子跨度代表每个子目标，其属性捕获子目标描述、依赖关系、当前状态，以及它是已完成还是被放弃。这会生成一个在结构上与工具调用追踪并行且可查询的规划追踪。

假设生命周期跟踪。 在规划阶段开始时，记录智能体运行所依据的每个假设。在每次工具调用后，评估哪些假设得到了确认，哪些已失效，以及规划是否因此进行了调整。由此产生的假设追踪是针对隐性失败（silent failure）的直接诊断：失效的假设如果没有对应的规划修订，就是最常见的智能体推理错误类别的“指纹”。

修订事件。 每当智能体更新其规划时，将修订记录为一个离散事件：更改了什么、什么触发了更改，以及之前的规划状态是什么。这为你提供了智能体决策的 diff 历史，让你不仅可以回放智能体做了什么，还可以回放它在每个分支点是如何思考的。

OpenTelemetry 的 GenAI 语义规范（semantic conventions）是标准化规划属性的天然归宿。目前的规范详尽地涵盖了工具调用和模型操作，但规划层属性——目标分解、约束状态、假设跟踪——仍处于起步阶段。如今构建生产级智能体的团队在等待标准化跟上的同时，正在定义自己的属性命名空间。

多智能体系统增加了难度

在单智能体架构中，规划状态被限制在一个上下文窗口内。在多智能体系统中，规划是分布式的：编排者（orchestrator）分解任务并将子规划委派给专门的子智能体。每个智能体都持有总规划的一个片段，而这些片段需要保持彼此一致。

多智能体协作失败是一种独特且尚不被充分理解的失败类别。2025 年发布的研究指出，智能体间的不对齐（inter-agent misalignment）——执行过程中信息流的中断——是多智能体系统失败最常见的原因之一。智能体带着错误的假设继续运行，而不是寻求 clarification（澄清）。子规划偏离了编排者对智能体行为的认知模型。

这里的追踪挑战在于规划层面的上下文传播。多智能体系统中的工具调用追踪已经需要分布式追踪标识符来将单个智能体追踪缝合成一致的执行图。规划层追踪需要同样的缝合，但要跨越目标分解：编排者在派发该智能体时追求的是哪个子目标？它传递了哪些约束？委派是基于什么假设的？

如果没有这种链接，调试多智能体失败意味着要手动将编排者的工具调用追踪与每个子智能体的追踪关联起来，从提示词日志的上下文线索中重建规划上下文——这本质上是考古工作。有了它，你可以看到子智能体 B 正在运行编排者在第二步传递的陈旧约束，而该约束已被子智能体 A 在第四步的发现所作废，但从未得到传播。

行业内正在标准化的智能体间协议解决了智能体之间的消息传递问题。规划层上下文传播——跨智能体边界传递结构化目标状态、假设状态和约束上下文——是下一个待解决的问题。

拥有规划可见性后的调试体验

实际的区别就像阅读日志与使用调试器之间的区别。

使用工具调用追踪时，调试智能体失败是这样的：识别失败的工具调用，检查其输入，检查其输出，查看前面的调用以获取上下文。沿着链条重复，直到找到看起来不对劲的地方。对智能体推理中出错的地方提出假设。通过修改重新运行来进行测试。

使用规划层追踪时，调试是这样的：打开失败运行的目标树。找到被放弃或被错误满足的子目标。查看当时活跃的假设。找到失效的那个。查看修订事件——如果该有修订而没有修订，那就是你的根本原因。如果有修订，追踪发生了什么变化，以及新规划是否一致。

区别在于因果可见性。工具追踪是“果”。规划追踪是“因”。根据“果”来调试意味着从不完整的证据中推断原因。根据“因”来调试意味着直接读取智能体的推理过程。

LADYBUG 和 AGDebugger 等研究工具开始为受控环境提供交互式规划层调试——允许开发者在执行中修改智能体规划，跟踪子目标状态，并注入假设失效以测试智能体行为。这些能力的生产级版本正是可观测性工具的发展方向。

生产级智能体 (Agent) 可观测性究竟需要什么

适用于微服务的可观测性模型——展示哪些服务按什么顺序被调用的追踪 (traces)——对于具有复杂因果关系的分布式系统来说本就不够完整。对于具有非确定性、目标导向行为的智能体 (Agent) 来说，这种模型显然更加不足。

下一代智能体可观测性需要四种目前大多数平台所缺乏的能力：

规划层 Span (Planning-layer spans) 作为一等公民的追踪对象，而不是挂载在工具 Span 上的应用级属性。目标分解、子目标跟踪和计划修订需要标准化的表示方式，以便跨运行周期进行查询，并在不同智能体版本之间进行对比。

假设生命周期事件 (Hypothesis lifecycle events)，在假设形成时进行记录，在执行过程中进行跟踪，并将“未修订的失效”标记为可检测的异常，而非静默失败。

跨智能体计划传播 (Cross-agent plan propagation)，在多智能体系统中跨越边界传递目标状态和约束上下文，从而实现端到端追踪。这不仅能显示调用了哪些智能体，还能显示每个智能体是在何种规划上下文中运行的。

跨运行周期的行为聚合 (Behavioral aggregation across runs)——不仅是单次请求的追踪可见性，还要有能力提出诸如“在百分之几的运行中子目标 3 被放弃了？哪些条件预测了这种情况？”之类的问题。计划追踪 (Plan traces) 支持此类分析，而工具追踪 (Tool traces) 则不支持，因为数据中并不包含计划。

在 2026 年构建智能体的团队面临一个现实的选择：现在就显式地对规划状态进行埋点，以免日后积累下仅凭工具追踪无法诊断的故障；或者等待平台级的支持，并接受在支持到来之前，规划层的失败将一直是“黑盒”状态。

工具调用瀑布图并不是你需要的调试视图，它只是你目前仅有的调试视图。