多智能体的评估、成本与追踪

多智能体评估要判断任务拆分、上下文隔离和结果审查是否改善了最终交付，并测量这些协作步骤增加了多少成本和等待时间。它既看父任务是否完成，也追踪子任务之间的信息传递，找出问题发生在执行、交接还是汇总阶段。

例如，让一个 Agent 比较两个搜索服务，也可以让两个调研 Agent 分别查资料，再由主管生成对照表。第二种方案需要任务分派和结果交接，总调用次数也可能变化。只有在同一批任务和明确资源限制下比较，才能判断这种分工是否值得保留。

先建立可比较的基线

至少保留单 Agent 和固定工作流两种实现。它们分别帮助判断：任务是否需要拆给多个 Agent，以及执行顺序是否需要由主管动态决定。

实现	怎样完成搜索服务比较	用来回答的问题
单 Agent	一个执行循环查询两家服务，保留资料并写出对照表	分开上下文和职责有没有改善结果
固定工作流	程序固定安排甲、乙两路资料处理，再汇总	是否只需要稳定的步骤和并行执行
主管与子 Agent	主管根据问题拆分任务，工人执行，主管验收并决定是否补查	动态分工和补查带来了什么增量

固定工作流可以包含多个模型调用，也可以包含预先安排的 Agent 节点。这里比较的是预定流程和动态编排的差异，不能把它简单按“用了几个模型”分类。

各方案应使用同一批任务、同一版本的数据和工具，拥有相同的必要访问权限。单 Agent 若只能读一份摘要，而子 Agent 可以访问完整资料，结果差异就混入了信息可用性的变化。先使用相同模型配置比较编排方式；需要测试不同模型分工时，再把它作为另一项实验单独记录。

预算要限制整个父任务，包括主管规划、子任务、补查、审查和汇总。可以先在相同费用上限和截止时间内比较完成率，再逐步提高预算，观察各方案能取得怎样的质量。不要给每个子 Agent 都分配一份与单 Agent 相同的额度，却把结果解释为“同等资源下多 Agent 更好”。

搜索索引、网页内容和限流情况可能随时间变化。离线评测可使用保存的资料与工具响应；在线评测则应记录数据时间和依赖状态，并交错执行不同方案，减少某一方案恰好遇到服务故障造成的偏差。提示词调试样本与最终评测样本也应分开。

从任务要求判定成功

搜索服务比较任务的验收可以具体到：两家服务的部署条件都有来源；版本范围一致；私有部署、网络要求和数据导出条件没有遗漏；资料没有说明的内容保持未知。

每个子任务成功只能证明局部完成。A、B 各自查对了资料，主管仍可能在汇总时把“某版本支持”写成“所有版本支持”，因此最终产物需要独立验收。反过来，某个可选子任务失败，也不必自动判整个任务失败，完成规则应沿用父任务的交付要求。

评测样本要覆盖不同协作需求：两路任务完全独立，后一项依赖前一项的查询结果，资料存在冲突，以及其中一路缺失必要信息。按这些类型分别统计，才能发现并行方案只改善了独立任务，遇到依赖任务却增加了返工。

有明确结果的项目使用程序断言或人工核对；开放报告使用稳定的评分规约。不要让负责写作或运行时验收的主管同时充当唯一的最终评分者。模型裁判需要人工样本校准，并隐藏候选方案名称、随机呈现顺序，减少角色名和展示位置的影响。评分规约、重复运行和回归报告的实现可接着阅读 Agent 评估。

多次运行时，保留每条任务各次结果，按同一任务比较方案差异。除了平均通过率，还应报告样本数量、失败分布和结果波动。超时、预算耗尽和无输出都属于评测结果，不能从分母中删除。

用消融确定是哪一步起作用

消融实验每次移除或替换一个协作环节，再观察结果。比如多 Agent 版本优于单 Agent，还不能说明主管的动态拆分有效：收益可能来自并行取资料，也可能只是因为它多执行了一轮检查。

针对同一组任务，可以比较这些改动：

改动	其他条件尽量保持一致	可以定位什么
主管动态分派改成固定任务表	调研工具、模型与汇总方式	动态规划有没有必要
两个调研 Agent 合并为一个	可访问的资料、工具和总预算	隔离上下文与分工是否有收益
去掉独立审查步骤	原始草稿和最终评分标准	审查是否真正纠正错误
摘要交接改为结构化证据交接	上游已经找到的原文	改善是否来自信息传递方式

移除某一步后，可以先保持其他调用不变，观察质量损失和节省的成本；也可以把节省的预算交给剩余步骤，再比较同等总资源下的结果。这两种实验回答的问题不同，报告里应说明采用哪一种。

运行时的审查效果尤其适合从同一份草稿出发比较：一份直接交付，一份经独立审查后修订，再交给相同的外部评测流程。这样更容易判断修订是否改变了结果，而不是把两次不同草稿的波动归因于审查。

沿着交接定位信息损失

假设服务乙文档写着“私有部署仅在企业版提供”。调研 Agent 找到了这句话，但交接摘要只写“支持私有部署”；主管最终将它填进通用功能对照表。工具检索和上游判断都没有失败，错误发生在交接省略了版本条件。

排查这类问题需要保存可对应的四份信息：

上游依据：文档片段及其版本，包含企业版限制
交付物：结论、条件、来源引用
下游实际输入：汇总请求中真正包含的字段和引用
最终产物：对照表中的私有部署条件

如果交付物里有企业版限制，下游实际输入却没有，问题在上下文组装；如果下游已经看到了限制，最终仍然漏写，问题在汇总或验收。只保存最终对话记录，很难分清这两种原因。

对于有标注的任务，可以按预先列出的必要事实与限制逐项核对交接保留情况。这里的“损失”包括删去限定条件、丢失来源、把尚未确认的判断写成事实。字数压缩比例本身不能说明交接质量：有些句子可以删除，一个“仅”字却可能决定结论是否正确。

重复劳动也需要沿任务范围判断。两个 Agent 对同一资料快照执行等价查询，并生成同样的摘要，通常可以复用结果；审查 Agent 为核对关键结论再次读取原文，则可能是必要的独立验证。统计时保留调用目的、工具参数和数据版本，先区分补查、验证和重复搜索，再分析可节省的工作。

延迟看关键路径，成本看全部调用

并行任务的耗时不能直接相加。设规划耗时 2 秒，A、B 的调研耗时分别为 8 秒和 12 秒，汇总耗时 4 秒；暂不计排队、重试和调度开销，计算为：

串行调研：2 + 8 + 12 + 4 = 26 秒
并行调研：2 + max(8, 12) + 4 = 18 秒

这里 A、B 可以同时开始，汇总要等待两者。规划、B、汇总组成最长的依赖路径，也就是关键路径。如果 B 必须使用 A 查到的产品版本才能继续，两者就不能按这个公式并行，延迟仍要包含前后依赖。

实际 trace 还需要包含排队、工具等待、限流和重试。若 A、B 共用一个限流额度，并发可能使 B 等待更久；把两个调用同时发出不等于它们都立刻开始执行。

成本则累加所有实际计费的调用。继续用同一流程计算，假设规划、A、B、汇总的费用分别为 0.01、0.03、0.04、0.02 元，则总费用为：

0.01 + 0.03 + 0.04 + 0.02 = 0.10 元

把 A、B 并行执行，只改变了完成时间，并不使这两笔费用互相抵消。若 B 重试一次额外花费 0.02 元，总费用就是 0.12 元。实际报告应使用调用记录中的耗时、usage、价格版本和工具费用。

比较系统时可以同时报告总费用、端到端延迟和最终成功率。将整批评测的总费用除以成功任务数，可以得到每次成功交付的平均成本，其中也包含失败尝试的花费。只统计成功任务本身的费用，会低估失败较多的方案。

Trace 同时保留任务和执行层级

一次用户请求对应一个父任务，调研 task 可以有多个 attempt，每个 attempt 内又有模型和工具调用。这样的层级能同时回答“哪项工作没完成”和“哪一次调用出了问题”。

run-42
├─ supervisor.plan
├─ task-A
│  └─ attempt-A1
│     ├─ model.call
│     ├─ tool.search
│     └─ model.call
├─ task-B
│  ├─ attempt-B1
│  │  ├─ model.call
│  │  └─ tool.fetch：超时
│  └─ attempt-B2
│     ├─ tool.fetch
│     └─ model.call
└─ supervisor.synthesize

父子 span 表达执行归属，任务依赖还需要单独记录。汇总同时依赖 A、B，但一个 span 通常只有一个父 span，可以将汇总挂在父任务下，再用 span links 或 depends_on_task_ids 关联两个上游。不要为了画成树，丢掉真实的依赖关系。

任务结果被接收时，可以记录以下事件：

{
  "event": "task.result_accepted",
  "run_id": "run-42",
  "task_id": "task-B",
  "attempt_id": "attempt-B2",
  "parent_task_id": "task-root",
  "plan_revision": 7,
  "input_revision": "sources-v3",
  "result_ref": "result-B2",
  "acceptance_status": "passed"
}

模型调用记录再保留独立的 call_id、usage 和费用；交接记录保存产物引用及下游实际读取的版本。这样可以从错误的最终结论追到汇总输入、具体子任务和原始资料。

汇总时要避免两类重复计算。父 task 的耗时包含子 attempt，不能把父子 span 的 duration 全部相加当作端到端延迟。父 task 的费用如果已经是调用费用的合计，也不能再与子调用费用累加。可以在实际计费调用上记账，父层只保存派生汇总值；对同一调用重复上报的事件按稳定的调用标识去重。

B1 即使超时或结果被丢弃，仍可能产生费用。若供应商暂未返回 usage，就标记费用尚未确认，随后核对，不应直接记成零。缓存输入和不同模型的价格也应在调用层处理，字段适配与计价细节见 可观测性。

Trace 用于解释运行，任务存储负责恢复执行。被采样丢弃的成功 trace 不应影响任务恢复，也不能成为总费用统计唯一的数据源。

审查意见是否改变了最终结果

增加 reviewer 后，“发现了多少条问题”无法说明结果是否改善。需要把每条意见对应到原始缺陷、实际修订和修订后的验证结果。

例如 reviewer 指出“服务乙的私有部署缺少企业版限制”，主管补回限制，最终评分消除了这一错误，才形成了一次有效纠正。如果主管没有应用意见，或者修订只是把句子写得更长，结果质量并没有因此提高。审查也可能错误地删除正确结论，需要统计引入的新错误。

一份多智能体评测报告可以从具体变动写起：哪些任务原先失败、现在通过，哪些任务出现退步；交接在哪些位置丢失条件；独立审查修复了什么，又增加了多少调用。随后按任务类别列出通过率、成本和延迟，附上有代表性的 trace。

若固定工作流已经达到相同质量，动态主管却只增加规划和验收开销，可以保留固定流程；若复杂依赖任务确实受益于运行时拆分，则把动态编排用于这类任务。