AI智能体协作不可靠？关键在于构建可观测、可度量的控制层

在多智能体系统中，各个智能体单独来看可能是正确的，但当它们协同工作时仍可能产生错误结果。一个智能体的输出会成为另一个智能体的上下文。信息在交接过程中可能丢失或被误解，共享状态可能漂移，智能体还可能陷入循环或死锁。当多个智能体依赖同一底层模型时，它们甚至可能强化相同的错误，而非相互发现并纠正这些错误。

这使得多智能体系统从根本上区别于单智能体应用。仅单独考察每个智能体，或仅检查最终答案，并不能告诉我们协作过程本身是否成功。

解决方案在于评估智能体之间的交互过程。我们需要观察信息如何在工作流中传递、智能体如何交接结果、共享状态如何变化，以及不同智能体是否确实提供了独立的推理。

本文提出一种实用方法，用于评估这些交互，并利用评估结果构建更强大的工程控制机制。目标并非使大语言模型（LLM）具备确定性，而是使其不可预测的行为变得可见、可测量、可界定且可恢复。

为何智能体协作需要评估（evals）

大语言模型（LLM）本质上是非确定性的。在多智能体系统中，这种不确定性并不会消失。一个智能体生成信息，另一个智能体消费并解释该信息，其输出又可能成为下一个智能体的上下文。任何虚假生成或错误解释的内容都会在整个工作流中传播并放大。

多智能体本质上是在彼此消费上下文。我们可以像评估检索增强生成（RAG）系统那样评估它。智能体之间的交互可遵循相同的原则与方法论。

典型的RAG流水线可分解为：

用户查询 → 检索器 → 检索到的上下文（评估） → 生成 → 生成的答案（评估）

我们分别评估内容检索与生成，以识别问题究竟源于检索环节、上下文质量，还是生成环节。

多智能体系统扩展了这一理念：

用户查询 → 智能体A → 交接 → 智能体B → 共享状态 → 智能体C → 验证 → 最终输出

仅评估最终响应——甚至仅独立评估每个智能体——都无法告诉我们协作过程本身是否正确运行。我们需要对智能体之间的交互过程具备可观测性。

捕获多智能体执行轨迹

在评估协作之前，我们需要观测完整的工作流。正如LangSmith可为RAG应用捕获提示词、检索到的文档、工具调用及模型响应，多智能体追踪也应捕获：

• 哪些智能体被调用及其调用顺序

• 每个智能体的输入与输出

• 智能体之间的交接载荷（handoff payloads）

• 路由与委派决策

• 共享状态的读取与更新

• 工具调用及结果

• 重试、循环与终止决策

• 每一步的延迟、token用量及成本

该轨迹实质上构成了多智能体工作流的执行历史。若缺乏该轨迹，我们或许知道最终结果失败了，却几乎无法判断协作究竟在何处中断。

评估工作流死锁与循环

与单智能体应用不同，多智能体系统是一种分布式工作流，其中各智能体相互依赖以决定下一步操作。每个智能体可能等待来自另一智能体的信息、批准或动作。由于这些依赖关系通常通过由大语言模型驱动的决策而非固定程序逻辑来表达，工作流可能进入无任何智能体能够推进的状态，或智能体反复触发彼此的状态。

死锁 发生在智能体之间存在循环依赖时。例如，协调器（orchestrator）等待工作智能体（worker agent）返回结果，而工作智能体则等待协调器的确认或额外指令。双方均无法继续推进，导致工作流无限期停滞。

无限循环（活锁，Livelocks） 发生在智能体持续交互却始终无法取得进展时。例如，知识智能体可能将请求发回事务智能体以寻求澄清，而事务智能体因同样缺失该澄清而反复将其退回。智能体处于活跃状态，但工作流从未达到决策、动作或终止状态。

此类故障是执行图（execution graph）的属性，而不一定是任一单个智能体的属性。因此，我们使用以下指标评估工作流轨迹：

这些指标使我们得以判断智能体网络是否确实在取得进展并抵达有效的终止状态，而非仅仅生成各自看似合理的响应。

评估智能体交接

在多智能体系统中，一个智能体的输出会成为另一个智能体的输入或上下文。即使每个智能体单独表现良好，若信息在跨越智能体边界时丢失、被更改或被错误解释，工作流仍可能失败。

我们可以将每次智能体间的交接视作一条小型信息管道：

智能体A的输出 → 传递给智能体B的上下文 → 智能体B的解释

类似于RAG评估，我们需要分别评估每个智能体的检索质量与生成质量。此外，多智能体系统还需进行接口级验证，以确保智能体间通信契约得到维持。

评估上下文传递

首要问题是上游智能体生成的正确信息是否实际到达下游智能体。

典型问题包括：

• 代理A的所有相关信息是否都传递给了代理B？

• 交接过程中是否有任何重要信息丢失？

• 是否包含了不必要或无关的信息？

• 提供给代理B的上下文是否包含其执行任务所需的内容？

RAG评估中常用的相同上下文质量指标可应用于代理边界：

评估下游解释能力

正确传递上下文仅完成了交接的一半。我们还需确定下游代理是否正确理解并使用了其所接收的信息。

典型问题包括：

• 代理B的输出是否得到其从代理A接收到的信息的支持？

• 代理B是否保留了上游结果的原意？

• 它是否引入了交接内容未支持的信息？

• 它是否基于所提供信息作出了正确决策？

RAG评估中使用的相同生成质量原则可在此处适配：

LLM-as-a-judge 通常用于语义评估。它将上游输出、下游代理接收到的上下文以及下游结果进行比对。

评估接口完整性

代理协作还引入了传统RAG流水线中不太突出的另一层评估：代理之间的接口契约（interface contract）。

只要可能，即使处理长文本，代理也应交换结构化输出，而非无约束的自然语言响应。JSON模式（JSON schemas）、Pydantic模型或其他类型化契约（typed contracts）可在下游代理执行前对部分交接内容进行确定性评估。

有用的指标包括：

这为我们提供了三层互补的交接评估：

代理A输出 → 上下文质量 → 接口完整性 → 代理B解释能力

上下文指标告诉我们是否传递了正确的信息；接口验证告诉我们信息是否以预期结构传递；生成指标告诉我们下游代理是否正确理解并据此采取了行动。

评估共享状态

共享状态是整个智能体工作流的持久化工作记忆。多智能体工作流依赖共享状态在智能体之间传递客户信息、对话历史、中间结果、决策及约束条件。随着工作流推进，该状态可能变得过时、矛盾、不完整或噪声日益增加。 

因此，状态评估将每次状态转换视为一个检查点：比较智能体执行前后的状态，并验证重要信息是否被正确保留。

例如，考虑一个SaaS客户支持工作流的共享状态：

{ "customer_id": "C1024", "plan": "Enterprise", "issue": "duplicate_charge", "identity_verified": true, "refund_eligible": true,

  "refund reason": xxx 长文本 }

解决方案是创建一个名为状态管理器（state manager）的函数，该函数可通过两类检查来评估更新后的状态。

确定性检查 验证可表达为规则的属性：

• 模式验证（Schema validation）： 必需字段是否存在且类型正确？

• 不可变字段验证（Immutable-field validation）： 智能体是否意外更改了 customer_id 或其他受保护字段？

• 一致性检查（Consistency checks）： refund_eligible = true 是否与其他状态字段或业务规则冲突？

• 新鲜度检查（Freshness checks）： 智能体是否正在使用已过期或已被取代的值？

• 上下文大小检查（Context-size checks）： 对话历史或共享上下文是否已超出预定义阈值？

语义检查用于评估无法通过固定规则可靠捕获的变化。大语言模型（LLM）评估器可对比先前状态、最近智能体输出及更新后的状态，以判定：

• 重要事实或约束是否丢失？

• 摘要是否改变了对话的含义？

• 是否有未经支持的信息被引入状态？

• 更新后的状态是否仍代表客户的原始请求？

• 无关信息是否正在累积，从而分散下游智能体的注意力？

这些检查可通过状态级关键绩效指标（KPI）进行量化：

• 状态验证率（State validation rate）： 通过模式及业务规则检查的状态转换所占百分比

• 状态一致性率（State consistency rate）： 无冲突状态值的状态转换所占百分比

• 约束保留率（Constraint preservation rate）： 重要需求是否在各次状态转换中得以延续

• 摘要保真度（Summary fidelity）： 压缩后的状态是否保留了原始上下文的含义与关键事实

• 过时状态率（Stale state rate）： 下游智能体消费过时信息的频率

• 上下文增长（Context growth）： 随着工作流推进，活跃状态或token用量的增长情况  

因此，状态管理器的功能类似于数据流水线中的一个检查点：

先前状态 → 智能体执行 → 更新后的状态 → 状态评估 → 下一智能体

这使我们不仅能评估单个智能体是否生成了正确的输出，还能评估当信息在多个智能体间流转时，工作流的共享理解是否持续准确。

评估关联推理（模型单一文化，model monoculture）

多智能体系统的一项关键优势在于，专业化的智能体可相互验证彼此的推理。然而，当多个智能体依赖同一基础模型时，它们可能共享相似的推理模式与盲点。若规划智能体（planner agent）得出了看似合理但实际错误的结论，则基于相同模型构建的评审智能体（reviewer agent）可能强化该错误而非检测出它。结果是，每个智能体单独运行表现良好，而整体系统却系统性地出错。

此类故障并非存在于任一单个智能体内部，而是源于智能体之间缺乏独立性。因此，检测模型单一文化需衡量智能体是否实际提供了多样化的推理、证据、决策及失败模式。

• 输出多样性（Output diversity）： 智能体对同一任务是否生成相似响应——嵌入余弦相似度、BERTScore、LLM-as-a-judge

• 推理多样性（Reasoning diversity）： 智能体是否遵循不同的推理路径——推理轨迹相似度、图编辑距离

• 工具多样性： 代理是否使用不同的工具或工作流——工具使用熵、工具分布

• 检索多样性： 代理是否依赖不同的证据——Jaccard相似度、文档重叠率

• 决策多样性： 代理是否持续达成相同决策——决策熵、决策一致率

• 失败相关性： 代理是否在相同任务上失败——错误一致率、成对失败相关性

• 视角多样性： 代理是否从不同视角切入问题——基于LLM的推理分类  

在这些指标中，失败相关性尤为重要。不同的措辞、推理轨迹或检索到的文档，并不一定意味着代理具有不同的盲点。如果多个代理反复在相同的基准测试用例上失败，则其表面的多样性所提供的额外保护作用十分有限。一个健康的多代理系统应展现出互补的失败模式，即一个代理能够检测或弥补另一代理所犯的错误。

从评估到工程化控制

本文讨论的评估框架最终目标是使一个非确定性系统变得更可预测、更可控。这引出了一项重要的工程原则：代理协作不应完全依赖于LLM的决策。由于LLM行为具有概率性，应在工作流中嵌入确定性控制机制，以强制执行代理必须遵循的接口、执行规则和状态管理。

工程化代理交接 使用结构化输出（例如JSON Schema或Pydantic模型）明确定义接口。在下游代理消费结果之前，验证必填字段、数据类型及业务规则。若验证失败，系统可拒绝该载荷、重试上游代理，或将工作流路由至替代路径。此举可在保持语义推理灵活性的同时，确保通信接口具备确定性。

工程化工作流协调 编排层应显式追踪代理调用、路由决策、交接、迭代次数、执行时间及终止状态。此处确定性编排尤为关键。LangGraph等框架允许将工作流表示为具有显式节点、边、分支和检查点的状态图。最大迭代次数、超时和终止条件等确定性控制机制，可防止死锁和无限循环，而非完全依赖LLM来决定何时停止。随后可通过LangSmith捕获执行轨迹，从而提供评估工作流进展及诊断异常执行所需的可见性。

工程化状态管理 共享状态应由状态管理器管理，而非在代理之间无限传递。

代理执行 → 状态管理器 → 状态更新／裁剪 → 下一代理

状态管理器采用确定性规则监控上下文大小，并判定何时需执行裁剪。当达到阈值时，它调用轻量级摘要代理压缩对话内容。随后状态管理器以确定性方式用摘要替换较早的消息，同时保留近期上下文。这形成一种混合模型：LLM执行语义摘要，而确定性代码控制状态变更的时机与方式。此举可保持共享状态紧凑，并防止上下文无限增长。

工程化模型选择：首要且最重要的原则是，不应对所有代理统一使用单一基础模型。不同代理承担不同职责，因此对推理能力、延迟、成本及可靠性等方面的要求也各不相同。

例如，SaaS客户支持系统可能使用：

• 路由／分诊代理： 一种快速、低成本模型，用于分类与路由。

• 知识／RAG代理： 一种在上下文理解与基于事实生成方面表现优异的模型。

• 事务代理： 一种更强的推理模型，用于解读策略并判断某项操作是否被允许。

• 审核代理： 一种不同模型家族，以降低共享推理盲点。

模型选择应基于实证而非模型声誉。为每个代理的具体任务构建评估数据集，让候选模型在相同测试用例上运行，并比较准确率、忠实度、工具调用成功率、延迟及成本等任务特定指标。目标并非为整个系统寻找最佳基础模型，而是为每个代理的具体职责选择最合适的模型，同时在需要独立验证之处维持有意义的多样性。

这些工程实践将评估框架转化为生产级架构：结构化接口控制信息流，编排控制工作流执行，状态管理控制共享上下文，模型选择则控制代理的多样性与能力。评估则提供所需反馈，以持续验证这些控制机制是否按预期运行。

最终，构建可靠的多代理系统，关键不在于增加更多能力强的代理，而在于对代理之间的边界进行工程化设计——使这些边界可观测、可度量，在必要时具备确定性，并在某个代理出错时具备韧性。

徐树华（Shuhua Xu）是一名首席数据工程师。

欢迎加入VentureBeat社区！

我们的客座投稿计划面向技术专家，旨在分享洞见，并就人工智能、数据基础设施、网络安全及其他塑造企业未来前沿技术提供中立、无利益关联的深度剖析。

阅读更多 来自我们的客座投稿计划——并查看我们的 投稿指南 若您有意撰写并投稿自己的文章，请参阅相关指南！