多智能体协同的过程评测：面向执行轨迹的协调机制设计

本文基于笔者在 2026 中国 AI 智能体大会·多智能体协同技术研讨会上的主题分享整理扩写。文中工程细节来自笔者的四个开源项目：三个业务形态不同的多智能体系统：多角色决策会议 Meetkat、研究写作助手 FlockMind、视频创作流水线 MuseCraft（short-video-maker），以及在三者经验之上沉淀的多智能体 harness 框架 HydraMind。HydraMind 的四层架构直接来自 MuseCraft，Meetkat 与 FlockMind 提供跨场景参照。

2025 年末到 2026 年当下，多智能体系统开始进入长程任务和真实工作流，常见评测却仍集中在最终结果：任务是否完成、产物是否合格。近期研究从失败归因、假成功和过程违规三个方面暴露了这种做法的信息缺口。

第一个方向是失败归因。MAST 通过专家标注归纳出 14 种多智能体失败模式，数据集覆盖 7 个框架的 1600 余条轨迹，跨标注者一致性 κ=0.88。其三类上位原因是系统设计缺陷、agent 间失配（inter-agent misalignment）和任务验证缺失[1]。这套分类把分析重点放在系统结构、agent 互动和验证环节，但不能据此推出基础模型能力与失败无关。

第二个方向是假成功。From Confident Closing to Silent Failure 发现，agent “自信宣称完成、环境真实状态不符”的静默假成功在失败案例中的占比随场景显著变化：常见场景为 45%–48%，最高场景达 75.8%，也有场景仅 3%。用 LLM judge 读取收尾陈述来甄别时，5 种模型 × 5 种提示词的全部组合无一 AUROC 超过 0.65（0.5 相当于随机判别）[2]。

第三个方向是过程违规。Procedure-Aware Evaluation 复查“报告成功”的运行，发现其中 27%–78% 虽然到达目标终态，却违反了规定的执行程序[3]。终态正确，并不等于过程合规。

三类问题都与结果评测的信息不足有关。终态分数可以说明结果是否达标，却不能说明结果如何产生、失败从哪里开始，也不能判断一个正确结果是否经过了合规且可复查的过程。过程评测需要进一步保留动作、状态、证据及其前后依赖，使执行能够被定位、解释和复查。

在多智能体系统中，最终结果还会省略协作过程。交接传递了哪些上下文，委派附带了什么权限，多个结论按什么依据聚合，门控为何放行，系统又因何终止或返工，这些信息分别存在于调度状态、门控记录和 agent 调用上下文中，无法由最终答案完整还原。协作失败的归因因而需要同时检查 agent 输出和协调机制，包括交接、验证、聚合与恢复规则是否按预期执行。

面向执行轨迹的协同机制设计，最终要落到 harness loop 中。协调机制在控制面定义交接、授权、聚合、门控与终止规则；harness 在数据面承接授权，运行模型与工具，并产出 observation、artifact、proposal 和 evidence；控制面与数据面的事件共同组成实际执行轨迹。过程评测对照预期协作结构与实际轨迹识别偏差，控制面再把诊断转成 continue、revise、replan 或 reject，并将机制变更纳入回归准入。harness 因而是把协调机制、执行轨迹和过程评测接成运行闭环的载体。

执行轨迹：把结果成败展开成可诊断的机制链

单 agent 轨迹通常围绕一次执行循环，按模型轮次、工具调用和环境反馈串联。多智能体轨迹还要关联多个执行循环与控制面决策。系统级事件因此需要携带统一的 trace / execution 标识、事件生产者、顺序或父子关系，以及交接上下文、产物引用、门控结论和终止原因；缺少这些字段，各组件日志无法重建为同一条协作链。一次执行可以抽象为：

τ = (goal, plan, turn₁, call₁, obs₁, artifact₁, gate₁, handoff₁, turn₂, …, termination)

结果评测对应 τ 的最后一项；过程评测检查整条 τ。轨迹保留了产生结果的步骤与依赖，使失败可以进一步定位到协调、执行器、门控或控制状态：

从最终结果展开为系统级执行轨迹

从最终结果展开为系统级执行轨迹

日志不等于轨迹。日志通常是面向人的文本流；轨迹是服从 schema 的结构化事件序列，每个事件有明确归属、顺序和依据。Meetkat 是一个多智能体决策会议系统：supervisor 安排“谁何时说”，四个领域 specialist 决定“说什么”。其设计文档 ADR-003 要求 handoff 必须作为显式事件记录，不允许只存在于 prompt 文本中。一次交接在事件账本 RoomEventJournal 中包含以下字段：

{
  "room_seq": 47,                      // 单调递增、写入即持久化
  "producer_id": "agent.host.1",
  "event_type": "agent.handoff",
  "idempotency_key": "…",
  "payload": {
    "to_role": "risk_specialist",
    "reason": "…",
    "expected_output": "…",
    "context_slice": "…",              // 只传摘要与焦点，不传全量对话
    "artifact_refs": ["host.next_focus", "host.focus_points"]
  }
}

同一时刻的日志可能只有一行 INFO: 移交 risk_specialist。交接是否携带上下文，在轨迹中可以直接检查 context_slice，在日志中通常无法判断。事件按 room_seq 全序持久化，SQLite 存储以 (room_id, room_seq) 为主键；replay(after_seq) 因而可以从指定位置继续重放，会议纪要则由事件流确定性投影生成。idempotency_key 保留在事件信封中，但当前持久化幂等由序号主键和 INSERT OR IGNORE 保证。

这种转向也出现在近期框架和研究中。Google ADK 把 final response evaluation 与 trajectory evaluation 分开，支持实际路径与预期路径逐步对比[4]；OpenAI Agents SDK 的 tracing 覆盖模型生成、工具调用、handoff 和 guardrail[5]。研究侧则分别讨论了可配置协调层[6]、轨迹级安全基准[7][8]、执行溯源[9]、workflow graph 静态验证[10]、agent/tool/委派路径覆盖[11]，以及 harness 评测与优化[12][13]。这些工作关注的对象不同，但都把评测范围从最终回答扩展到执行结构和轨迹。

多智能体工作流中的协作失败：交接边界的验证缺口

MuseCraft 是一个多智能体视频创作流水线。一条视频从创意到成片依次经过 concept、script、image、video、voice、compose、audio 和 quality 八个节点。每个节点的产物会成为下游节点的输入，控制面根据节点状态和门控结果决定是否继续推进。流水线的可靠性同时取决于节点产出和交接边界验证。

MuseCraft：音轨探测结果进入显式 runtime decision

MuseCraft：音轨探测结果进入显式 runtime decision

在一次流水线执行中，video 节点生成的部分场景视频没有音轨，但文件存在、节点状态为完成，编排器继续放行。下游 compose 使用无音轨素材完成合成，quality 节点对时长、分辨率和文件完整性的检查也全部通过，最终由人工抽查发现问题。

上游模型或外部服务输出缺少音轨属于组件层缺陷。该缺陷没有在 video→compose 交接边界及后续质量检查中被拦截，则暴露了交接验证、放行规则与质量门控的问题。

第一处缺口在 video→compose 边界：这里没有验证，所谓“完成”只是上游的状态声明。后续治理复盘（内部编号 PLAN-066）又发现一组成体系的 fail-open 缺口：编排决策异常时默认放行下一步，媒体完成度检查把“输出集合非空”当作充分证据。由于这些路径不报错，它们也很难进入常规故障统计。

最后，quality 节点检查了时长、分辨率和文件完整性，却没有“音轨存在”这一项。下游需要什么，没有被转换成上游出口的检查义务。单个节点都按自身定义完成，并不意味着跨节点契约已经满足。

这个案例同时包含静默假成功（状态宣称与产物真实状态不一致）和任务验证缺失。该流水线既有自主决策的 agent，也有确定性编码阶段。过程评测检查的是责任边界及其契约：只要产物跨越边界，接收方依赖的条件就必须被验证，与上游成员是否由 LLM 驱动无关。

Silo-Bench 通过 1620 次受控实验发现，多 agent 能够形成拓扑并交换信息，仍可能在分布式信息整合上失败[16]。MAFBench 则报告，在模型集合不变时，仅改变多智能体架构，协同成功率可从 90% 以上降至 30% 以下[17]。前者表明消息完成传递并不代表信息已被正确整合，后者表明架构选择本身会影响协同结果。MuseCraft 中，消息和产物已经传到下游，缺失的是对下游依赖条件的验证：video→compose 交接契约没有把“音轨存在”设为放行条件。

要把这类失败定位到协调机制，轨迹至少需要保留上游完成声明、产物探测结果、门控裁决和下游接收动作。缺少这些证据，系统只能发现成品缺少音轨，无法确定缺陷从哪个边界漏过，也无法据此修改交接契约、补充门控规则并建立回归测试。轨迹完备性因此同时约束失败归因和修复闭环。

轨迹完备性对失败归因的约束

现有研究表明，将失败定位到具体 agent 和具体步骤的准确率仍然有限。

Who&When 构建了 127 个多智能体系统失败日志的细粒度标注集，标注责任 agent 和决定性错误步骤。结果显示，最佳方法对责任 agent 的识别准确率为 53.5%，对错误步骤的识别准确率只有 14.2%；部分方法低于随机基线，o1、DeepSeek-R1 级别的推理模型也远未达到工程可用水平[18]。直接把失败轨迹交给推理模型，仍不足以支持步级修复。

Seeing the Whole Elephant 对比了两种归因输入：只提供各 agent 的输出，以及提供每一步输入、上下文和输出组成的完整轨迹。完整轨迹使步级归因准确率最高提升 76%；至少 21% 的案例无法仅凭输出可靠归因，因为决定性证据存在于执行时的输入和上下文中[19]。错误传播又增加了一层困难：错误沿 agent 间的信息依赖传递，根因与最终暴露症状可能位于不同步骤。FAMAS 通过重放失败任务和谱分析定位可疑步骤[20]，AgentEval 则把执行表示为评估 DAG，沿依赖边回溯根因[23]。

MuseCraft 的失败定位按这一要求设计。每个节点的每次执行都有一条带租约的尝试记录（WorkflowNodeAttempt：attempt_no、trigger_reason、租约字段、状态、error_code），门也有独立记录（WorkflowGate：状态、reason_code、allowed_actions）。失败因此可以定位到 node / attempt / gate / reason_code 四元组：哪个节点、第几次尝试、卡在哪个门、对应什么原因，例如 lease_validation_failed、missing_continuation_checkpoint 或 awaiting_gate_decision。这些字段使多次重试保持可区分、可查询。

失败归因也开始从事后分析转向在线干预。Early Diagnosis of Wasted Computation in Multi-Agent LLM Systems 在 orchestrator、search agent 和 execution agent 组成的三 agent 架构中，将结构化事件转换为循环、预算压力、低信息增益和工具不稳定等在线信号。在触发 warning 的失败运行中，平均 58.1% 的 token 消耗发生在首次 warning 之后；其 10 项 GAIA Level-2 pilot 进一步用 warning 触发搜索分流或补充证据要求，将 warning 后 token 占比从 0.638 降至 0.304[21]。

AgentForesight 则把多智能体失败归因改写为前缀级在线审计：审计器在每一步只读取当前轨迹前缀，决定继续执行或在最早的决定性错误处报警。在 AFTraj-2K 和外部 Who&When 基准上，论文报告最高 +19.9% performance gain，并将 step localization error 降至对照方法的约三分之一[22]。在这两种设计中，轨迹信号都直接进入运行决策：审计器负责发现风险，orchestrator 或控制面负责分流、补证、阻断或重规划。这要求协调机制持续产生结构化事件，并在 harness loop 中提供稳定的干预点。

协调机制的可设计变量：控制面与数据面

要让协作事件由机制自动产生，协调规则就不能只存在于 prompt 和胶水代码中。谁先做、如何交接、何时终止，需要成为有明确归属和 schema 的架构对象。否则，变更协调协议需要同时修改代码和 prompt，两版系统的差异难以归因，协作动作也不会自然留下结构化记录。Coordination as an Architectural Layer 对实验比较提出了同样的约束：如果两种架构在工具访问、检索上下文或对话长度上同时有差异，性能差异就不能归因于协调机制，必须把协调层单独配置并控制信息变量[6]。

在三个垂直 MAS 中反复遇到同类控制问题之后，我们把这些模式沉淀成 harness 框架 HydraMind。这里的 harness 指包裹在模型之外、承载执行循环、工具派发与副作用的运行层。其关键边界是控制面/数据面切分，概念源自网络工程与 Kubernetes 谱系，近一年也被用于讨论 agent 架构[25]。

控制面、数据面与轨迹事件的所有权边界

控制面、数据面与轨迹事件的所有权边界

归属判定可以简化为一个问题：该组件是否直接调用模型、执行工具或修改外部世界？如果是，归入数据面；如果只负责决策、授权和记账，归入控制面。在这个切分上，HydraMind 编码了两条可在类型层面检查的不变量：

第一条是数据面只提案，控制面负责落账。执行器完成一个 episode 后，产出 ExecutionStateTransitionProposal，而不是直接修改状态；其 docstring 写明 “A state transition proposed to, but not applied by, Control”。会话状态 RuntimeSession 只能由 SessionService 修改，并通过版本号 CAS（compare-and-swap，乐观并发控制）拒绝过期写入，相关架构不变量由 AST 检查约束。第二条是行动权通过租约授予。控制面签发带 TTL 的轮次租约 NativeTurnLease，包含 token、owner、heartbeat 和 expires，执行侧负责续租心跳，过期进入统一恢复路径。

这种控制/执行分离并非主流做法。Claude Agent SDK 允许 subagent 派生 subagent，OpenAI 将 handoff 表示为工具调用，CrewAI 的委派也在 agent 内部完成[26]。HydraMind 选择分离，是因为委派、交接和落账需要经过负责授权与记账的控制面。若这些动作只发生在 agent 对话流内部，轨迹就难以完整记录交接载荷和授权依据。协作动作经过控制面后，事件成为机制处理动作时产生的记录，而不是事后附加的埋点。HydraMind 的观测事件设计体现了这一点（真实枚举值节选），每个事件还带 trace_id / execution_id / parent_event_id 以支持跨步关联：

AGENT_TURN_STARTED / AGENT_TURN_COMPLETED        # 轮次
AGENT_MESSAGE_SENT / AGENT_HANDOFF               # 消息与交接
TOOL_CALL_STARTED / TOOL_CALL_COMPLETED          # 工具
GATE_RECORDED / DECISION_APPLIED                 # 门控裁决与落账
EXECUTION_LEASE_GRANTED / _HEARTBEAT / _RELEASED # 租约生命周期

ObservationEvent 是用于审计和关联执行过程的观测证据；RuntimeSession 才是控制面维护的状态真相源（SoT, source of truth），trace 不参与推进运行时状态。

在这一分层下，协调机制可以拆成五个设计变量，每个变量有归属、有事件、有评测问题：

角色缺位或职责集中时，检查拓扑；发言权不清或少数意见在聚合中被忽略时，检查决策权与聚合；交接丢失上下文时，检查交接契约；循环不收敛或错误级联时，检查终止与升级。MAST 的三类上位原因可以分别映射到这五类变量中的一个或多个。这种映射只是诊断索引，不意味着两套分类完全等价。

Meetkat 的会议最终要产出可执行的决策记录，运行时必须区分三种状态：主要分歧仍未解决，应继续讨论；候选决策已经稳定，可以结束；信息不足，需要转交人工或后续行动。固定轮数无法表达这些语义，完全依赖一次 LLM 判断又不利于复现和回归，因此当前实现采用混合收敛机制。

各 specialist 自主形成论点，synthesis agent 结合 agreement、disagreement、open questions、candidate decision 和本轮活动信号，输出 should_end_meeting 或 recommended_next_action，语义上的结束决定由它负责。与此同时，系统仍计算一组确定性观测量：claim 按 token-Jaccard 相似度聚类，得到分歧指数和前两簇置信度差 margin_top1_top2；支持度、置信度和风险惩罚组成共识得分。这些阈值只作为可比较、可回归的收敛信号，不再直接覆盖 synthesis agent 的结束决定。

consensus.check 事件同时记录得分、支持度、置信度、分歧指数、margin、阈值判断，以及最终是否结束和结束原因。复盘时既能看到 synthesis agent 为什么认为会议可以结束，也能用确定性指标检查该判断是否与讨论状态一致。项目通过 ConsensusStrategy 接口隔离具体算法，路线图也保留动态 specialist 和更自主协作拓扑的演进空间；新策略仍需保持事件契约，并经过 A/B 评测和回归验证后替换现有实现。

预期结构与实际轨迹的对照：门控与结构覆盖

机制显式化后，workflow graph 可以声明允许、禁止和必须检查的结构义务，而不是规定唯一正确路径。图上的节点和边可以携带 agent、工具、权限、委派、门和终止语义，评测据此核对实际轨迹。2026 年两类工作分别覆盖静态与动态两端：Agentproof 对 workflow graph 做结构检查、时序策略验证并生成 witness trace，可在部署前发现绕过门等路径[10]；Structural Coverage Criteria 则把图上的声明转换为可达 agent、允许工具边、受限工具边和委派边等覆盖义务[11]。结合本文的门契约，工程检查可以整理为四类：声明的 agent 是否真实参与；允许的工具和委派边是否被覆盖；受限边是否经过主动探测并被正确拦截；每个 gate 的不同出口是否都在测试中触发。

多智能体工作流的四类结构覆盖义务

多智能体工作流的四类结构覆盖义务

与传统代码覆盖相比，受限边和门控出口更容易被遗漏：代码被执行过，并不能说明禁止路径真的拦得住，也不能说明 gate 的每种裁决都经过验证。这两类检查并非多智能体系统独有，但在权限、委派和验证责任分散到多个 agent 后，会直接影响协作边界是否可靠。未经探测的禁止规则，无法证明其在运行时有效。

MuseCraft 的 video→compose 边界原本只读取节点完成状态，没有验证下游依赖的音轨。修复时，“下游需要音轨”被转换为运行时可执行、测试可覆盖的边界规则，具体包括三项改动。

第一，门控直接验证产物。 video→compose 边界上增加系统评估门 workflow_video_audio_delivery，评估器使用 ffprobe 逐个探测场景视频是否包含音频流，并将结论与 reason_code（如 audio_missing_or_unknown）写入门记录。文件存在和节点状态完成不足以证明音轨满足下游要求。

第二，声明门控的合法触发主体。 控制面维护授权表：workflow_video_audio_delivery 只接受 VIDEO_GENERATOR 的 scene_video_completed 边界事件触发，未授权触发直接抛错。触发主体因此成为可静态检查的 workflow graph 边约束。

第三，验证失败不能静默放行。 治理复盘发现的缺口包括决策异常时默认继续，以及把“输出集合非空”当作完成。对于可以确定判断的完整性条件，验证不通过时直接阻断；音轨探测得到 fail 或 inconclusive 时，则把事实和原因送入显式 runtime decision，由控制面选择继续、启用待命的 Audio Agent 或终止，而不是仅凭节点完成状态自动推进。FlockMind 的检索证据门采用更严格的 fail-closed：证据包为空、来源不可用、术语无法消歧时，编排器直接返回 blocked（blocked_reason="search_evidence_gate"）；配套冒烟测试断言阻断时下游规划器调用次数必须为零。

静态 graph 验证只能排除声明层面的路径与时序问题，无法判断运行时生成内容是否正确。结构覆盖只能确认相关路径和门控结果被测试过，也不能证明输出质量。因此还需要运行时内容评测和执行溯源。

证据溯源：轨迹要能解释结果如何产生

结构化事件支持轨迹重放和失败定位，执行溯源则进一步记录结果如何产生。From Agent Traces to Trust 要求中间结论绑定证据、动作绑定结论，使最终答案能够回溯到相关工具输出、记忆和中间产物[9]。TRACE 进一步指出，长程任务中的关键信号可能分布在相距较远的步骤，评测需要跨步骤聚合证据；孤立评判每一步再取平均，无法识别这种跨步骤依赖[8]。

结构化依赖建模已有量化结果：AgentEval 把执行建成评估 DAG，让错误沿依赖边回溯到根因。其消融实验报告，结构化依赖建模带来 +22pp 的失败检出召回和 +34pp 的根因准确率；产线试点中，根因定位时间从 4.2 小时降至 22 分钟[23]。

FlockMind 是一个多智能体研究写作系统，检索、大纲、写作和评审分别由不同角色承担，阶段之间通过结构化产物交接。检索结果进入下游时，需要同时保留来源、适用章节和所支撑的论点；如果只传递一段摘要，写作与评审阶段就无法恢复 claim 与 source 的对应关系。因此，FlockMind 将检索交付物 EvidencePack 中的每条证据表示为结构化对象：

EvidenceItem:  citation_id · title · summary · source · year · url
               · quality_level · quality_signals      # 来源质量维度
               · section_groups · claim_focuses       # 服务哪些章节、支撑哪些论点

EvidenceItem 记录单条证据的来源和用途，写作与评审还需要知道论点由哪些证据支撑，以及各章节的证据是否充足。ClaimLinkageItem 记录 claim → supporting_citation_ids 的对应关系，并标记 supported/missing；EvidenceCoverageItem 将 matched_citation_ids 与 minimum_citations 对比，并标记 missing/partial/sufficient。两类关系分别提供论点级溯源和章节级覆盖检查，并随结构化产物从检索阶段传递到大纲、写作和评审阶段。

FlockMind 曾对已有引用做来源质量检查。每条 EvidenceItem 都保存 citation_id 和原始 url，审查时可以直接打开对应来源，而不必根据正文中的引用描述重新搜索。检查发现部分证据来自 SEO 营销博客后，系统在 quality_signals 中增加 vendor_blog 标记，在构建引用包时过滤这类来源，并补充相应测试。问题因此可以从具体引用追溯到来源，再落实为过滤规则和回归测试，后续检查不需要重新执行整套研究流程。

评测驱动机制迭代：诊断 → 修订 → 回归

过程评测若只停留在离线报告，就无法改变系统行为。它既要在运行中影响门控和重规划，也要在版本迭代时把反复出现的失败转化为机制修订与回归测试。诊断—修订—回归由此成为 harness 演进的闭环：

诊断 → 修订 → 回归

诊断 → 修订 → 回归

以 MuseCraft 的音轨缺失问题为例，轨迹把问题定位在 video→compose 交接前缺少音轨检查，而不是笼统归因于视频模型不稳定。修订后，workflow_video_audio_delivery 在视频生成完成的边界检查交付物是否包含音轨，并限制只有 VIDEO_GENERATOR 能在 scene_video_completed 时触发该检查。检查结果作为 observation 进入控制面，由控制面选择继续、启用待命的 Audio Agent 或终止执行。test_audio_orchestration_runtime_gate 等测试覆盖音轨探测、越权触发、待命 Agent 激活和终止路径，防止同类问题在后续修改中重新出现。这已经形成围绕特定机制的诊断—修订—回归闭环；更完整的版本准入还需要将这类测试组织成稳定的评测集。

FlockMind 把评审结果接入重规划流程。评审 agent 不只给出分数，还通过五档 ReplanScope——none / writer_only / research_only / research_and_writer / outline_and_writer——区分问题来自写作、检索还是大纲。derive_resume_action 将评审范围映射为明确的修订动作：writer_only 重写受影响章节，research_and_writer 补充研究并重写正文，outline_and_writer 修订大纲并重写。submit_resume_replan 随后创建新的重规划任务，携带原任务 ID、评审结论和重规划请求，后续流程据此决定需要重新执行的环节。相关映射由回归测试固定，避免重规划语义在后续修改中发生漂移。

FlockMind：评审驱动的阶段化重规划

FlockMind：评审驱动的阶段化重规划

离线评测用于发现反复出现的失败模式，运行时 gate 则根据当前边界上的事实决定下一步。HydraMind 将 gate 的结果定义为三值 PASS / REQUIRES_DECISION / BLOCK，需要进一步决策时再选择 APPROVE / REVISE / REPLAN / REJECT，多个 gate evaluator 按 halt-wins 规则组合。MuseCraft 的人审门也区分 approve / revise / replan，并在 WorkflowGateDecision 中将 revise 记录为节点范围、将 replan 记录为工作流范围，后续恢复路径据此区分局部修订与重新规划。gate 因而不只是记录评测结果，还负责把边界上的判断转换为后续控制动作。

更进一步，历史轨迹还可以用于优化 harness 本身。RHO 把过往轨迹作为自监督信号进行 harness 优化[24]，AHE 要求每次 harness 修改都提出可证伪的预测，再用后续结果检验[13]。现有项目中的轨迹主要用于审计、定位和回归，自动修改 harness 仍属于下一阶段的探索。即使引入自动优化，也需要独立 holdout、回滚预案和变更审查，避免系统只适应有限的评测集，或出现离线分数提高而生产表现下降。

从垂直 MAS 到可替换 harness：协调职责的框架化

三个垂直 MAS 对协同机制提出了不同约束。Meetkat 需要在复盘时还原立场变化和共识形成过程，因此把 handoff、challenge 和 consensus check 写入事件账本，纪要由事件流投影生成。FlockMind 要保证研究结论能够回到原始来源，并在评审不通过时只重跑受影响的环节，因此把证据引用、质量评审和重规划范围做成结构化对象。MuseCraft 的媒体生产链路长、单次重跑成本高，需要通过尝试记录、行动租约和阶段门控制并发与返工范围。

这些机制分别服务于会议协作、研究写作和媒体生产，但承担的协调职责可以归入编排、状态与门控、执行、观测与治理四个位置：

四层划分的关键是明确所有权。Orchestration 决定由谁执行、何时交接以及任务如何展开；Control Plane 校验状态转换并持有最终写入权；harness 负责实际的模型—工具循环，向控制面提交结果和运行事实；Observability/Governance 汇集事件、产物和评测记录，但不反向修改运行状态。这样，协调机制中的预期路径与运行时产生的实际轨迹才有稳定的对照边界。

HydraMind 的四层结构主要从 MuseCraft 的运行时治理中抽取，框架文档的 heritage 表保留了逐模块映射。Meetkat 和 FlockMind 不是这套架构的上游实现，但它们提供了另外两类场景参照：事件账本检验协作动作能否被统一记录，证据与评审流程检验 gate 和 provenance 能否跨越不同交付物形态。

HydraMind 所说的“可替换 harness”不包括替换模型。模型及其 API 适配由 ModelProvider 负责，从 DeepSeek 切换到 Kimi 或 GLM 属于 provider routing；ExecutionHarness 替换的是模型外部的执行壳，包括上下文组织、模型—工具循环、权限与副作用约束、终止和恢复策略。评测某次 harness 替换时，模型、任务、工具、协调拓扑和 gate 应保持不变，才能看清执行策略本身带来的差异。

这种拆分的价值不在于让一套 harness 永久不变，而在于把模型演进与执行机制演进分开。模型能力或 API 更新时，可以在 provider 和行为配置层完成适配，协调拓扑、状态所有权、门契约和轨迹结构不必随之重写；如果新模型改变了工具调用、上下文利用或终止行为，也可以单独校准或替换 harness。近期研究已经观察到 harness 能在不同模型之间复用，但同一 harness 与不同模型组合后的表现仍会变化，因此能力应当按 model–harness configuration 评测，而不能假定一次适配永久有效[14][15][13]。

HydraMind 目前已有 HydraMindExecutionHarness 和 ExplicitSubmitExecutionHarness 两套实现。契约测试和端到端测试让它们在 provider、工具、Control Plane、gate 和 orchestration 保持不变时运行同一条 native-team 路径，验证替换不会越过既定的协调边界。下一阶段需要把这种验证扩展到真实模型与多类任务，比较两套 harness 的轨迹覆盖、门控结果、产物质量和恢复成本，而不只验证接口和确定性执行路径的一致性。

实践归纳：工程准则、成本与适用边界

笔者在 Meetkat、FlockMind、MuseCraft 和 HydraMind 的开发与重构中，反复遇到几类返工：协作动作只存在于日志和提示词中，状态可以被多个组件修改，门控给出分数却不改变执行，结论与原始证据脱节，已经修复的问题又在后续版本中出现。围绕这些问题形成了五条工程准则：

这套方法的主要成本并不只是 token，而是持续维护事件 schema、门契约、产物引用和回归集。结构化轨迹会增加存储与索引开销，保留中间产物会提高归档成本，在线 gate 还会延长关键路径。只有涉及语义判断的门才需要模型评审；音轨存在性、字段完整性、权限、引用可达性和状态转换都应优先采用确定性检查。成功轨迹可以采样或缩短保留周期，失败、重规划和高成本任务则保留完整事件与产物引用，以控制长期存储成本。

引入深度应当与链路风险匹配：

过程评测能够判断已经声明并记录的协作义务是否执行，却无法恢复从未写入轨迹的上下文，也不能用一次路径覆盖证明所有运行都正确。扩大系统自治范围之前，应先确认关键交接有事件、关键副作用有授权、关键产物有引用、已知失败有回归用例；否则链路越长，留下的只会是更多无法归因的日志。

结语

最终结果仍是交付验收的必要依据，但不能单独说明多智能体系统是否可靠。相同的结果可能来自不同的执行过程，其中可能存在交接上下文缺失、行动权未经确认、产物未验证或终止条件误判。保留这些过程信息，才能区分“结果未达标”和“协作机制未按预期工作”。

系统级执行轨迹提供了这部分依据。协调机制在控制面定义交接、授权、聚合、门控和终止规则；harness 在数据面运行模型与工具，产生 observation、artifact、proposal 和 evidence；观测层再把两侧事件关联为同一次执行。轨迹记录实际发生了什么，workflow graph、门契约和状态转换规则描述预期应当发生什么，两者的差异构成失败定位与机制诊断的入口。这里，轨迹是审计证据而非状态真相源，harness 是执行载体而非协调机制本身。

这些证据在两个时间尺度上影响系统。运行时，gate 消费当前边界上的事实，决定继续、修订、重新规划还是阻断；一次或一批运行结束后，过程评测对照预期结构与实际轨迹，识别反复出现的偏差并定位到协调变量。修订后的规则应通过相应的评测和回归后再进入下一版本，否则诊断只能解释过去，同类缺陷仍可能在后续迭代中重新出现。

模型、execution harness 与协调机制的分层，也为持续演进保留了空间。模型升级通过 provider 和行为配置完成适配，执行策略可以在 ExecutionHarness 边界内独立校准或替换，协调拓扑、状态所有权、gate 和轨迹结构不必随之一起重写。与此同时，模型与 harness 的组合仍需重新评测；解耦降低了改动的波及范围，并不意味着一套执行策略可以永久适配所有模型。

仍有一些问题需要继续解决。开放式任务通常不存在唯一正确的执行轨迹，workflow graph 必须容纳多条合理路径；在线诊断需要区分必要探索与无效偏离；跨 agent 的错误传播还缺少稳定的因果归因方法；利用历史轨迹自动修改 harness 时，也要处理评测集过拟合、变更审查和安全回滚。这些问题决定过程评测能否从固定工作流扩展到动态组队、长程运行和持续演化的多智能体系统。

随着模型被用于更长、更动态的任务链路，系统可靠性将越来越少由单次模型调用决定，而更多取决于交接、授权、验证和恢复能否持续工作。执行轨迹把协作过程变成可检查的证据，过程评测把证据转化为诊断，协调机制再把诊断沉淀为下一次执行的约束。多智能体系统能够获得多大自治空间，将越来越取决于它能否在行动发生时留下可核验的协作证据，在偏离扩散前介入，并把一次失败转化为下一版本的机制改进。

参考文献

学术论文与官方文档

1. *Why Do Multi-Agent LLM Systems Fail?*（MAST）, arXiv:2503.13657, NeurIPS 2025 Datasets & Benchmarks Track（接收信息见 NeurIPS 官方 proceedings 页）. https://arxiv.org/abs/2503.13657↩︎ 2. *From Confident Closing to Silent Failure: Characterizing False Success in LLM Agents*, arXiv:2606.09863, 2026. https://arxiv.org/abs/2606.09863 （占比按场景异质：tau2-bench 单控场景 45–48%、AppWorld 自报完成轨迹 75.8%、tau2-bench 双控场景仅 3%，不可当统一比率；单智能体基准，此处仅支撑"收尾语言不可信"这半边。）↩︎ 3. *Do It Right: Evaluating Procedural Integrity in Agentic Tasks*, arXiv:2603.03116, 2026. https://arxiv.org/abs/2603.03116 （论文提出 Procedure-Aware Evaluation；单智能体程序完整性研究，此处仅支撑“结果评测有盲区”。）↩︎ 4. Google ADK Evaluation 文档：final response 与 trajectory evaluation 的区分及 expected/actual trajectory 对比。https://google.github.io/adk-docs/evaluate/↩︎ 5. OpenAI Agents SDK Tracing 文档。https://openai.github.io/openai-agents-python/tracing/↩︎ 6. *Coordination as an Architectural Layer for LLM-Based Multi-Agent Systems*, arXiv:2605.03310, 2026. https://arxiv.org/abs/2605.03310 （作者自我定位为方法论验证的首个实例。）↩︎ 7. *ATBench: A Diverse and Realistic Trajectory Benchmark for Long-Horizon Agent Safety*, arXiv:2604.02022, 2026. https://arxiv.org/abs/2604.02022↩︎ 8. *TRACE: Trajectory Reasoning through Adaptive Cross-Step Evidence Aggregation for LLM Agents*, arXiv:2606.07054, 2026. https://arxiv.org/abs/2606.07054↩︎ 9. *From Agent Traces to Trust: Evidence Tracing and Execution Provenance in LLM Agents*, arXiv:2606.04990, 2026. https://arxiv.org/abs/2606.04990↩︎ 10. *Agentproof: Static Verification of Agent Workflow Graphs*, arXiv:2603.20356, 2026. https://arxiv.org/abs/2603.20356↩︎ 11. *Testing Agentic Workflows with Structural Coverage Criteria*, arXiv:2605.26521, 2026. https://arxiv.org/abs/2605.26521↩︎ 12. *ADK Arena: Evaluating Agent Development Kits via LLM-as-a-Developer*, arXiv:2606.05548, 2026. https://arxiv.org/abs/2606.05548↩︎ 13. *Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses*, arXiv:2604.25850, 2026. https://arxiv.org/abs/2604.25850↩︎ 14. *Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows*, arXiv:2605.27922, 2026. https://arxiv.org/abs/2605.27922 （在 6 种 harness、8 个模型后端的组合上比较完成率、过程质量、效率与失败行为，主张按 model–harness configuration 报告能力。）↩︎ 15. *Adapting the Interface, Not the Model: Runtime Harness Adaptation for Deterministic LLM Agents*, arXiv:2605.22166, 2026. https://arxiv.org/abs/2605.22166 （由 Qwen3-4B-Instruct 轨迹得到的 harness 迁移到另外 17 个模型，用于说明环境侧执行结构具有跨模型复用的可能，不代表所有 harness 都能无条件迁移。）↩︎ 16. *Silo-Bench*, arXiv:2603.01045, 2026. https://arxiv.org/abs/2603.01045 （任务为合成/算法类，失败定位为阶段级。）↩︎ 17. *MAFBench*, arXiv:2602.03128, 2026. https://arxiv.org/abs/2602.03128 （结果级框架基准，数量级仅示意。）↩︎ 18. *Which Agent Causes Task Failures and When? On Automated Failure Attribution of LLM Multi-Agent Systems*, arXiv:2505.00212, ICML 2025. https://arxiv.org/abs/2505.00212↩︎ 19. *Seeing the Whole Elephant: A Benchmark for Failure Attribution in LLM-based Multi-Agent Systems*, arXiv:2604.22708, 2026. https://arxiv.org/abs/2604.22708↩︎ 20. *Who is Introducing the Failure? Automatically Attributing Failures of Multi-Agent Systems via Spectrum Analysis*（FAMAS）, arXiv:2509.13782, 2025. https://arxiv.org/abs/2509.13782↩︎ 21. *Early Diagnosis of Wasted Computation in Multi-Agent LLM Systems via Failure-Aware Observability*, arXiv:2606.01365 v2, 2026. https://arxiv.org/abs/2606.01365 （orchestrator、search agent、execution agent 三 agent 架构；165 条 GAIA validation traces；10 项 Level-2 pilot 将 warning 后 token 占比从 0.638 降至 0.304。）↩︎ 22. *AgentForesight: Online Auditing for Early Failure Prediction in Multi-Agent Systems*, arXiv:2605.08715 v2, 2026. https://arxiv.org/abs/2605.08715 （AFTraj-2K 与外部 Who&When 基准；作者报告最高 +19.9% performance gain 和 3× lower step localization error。）↩︎ 23. *AgentEval*, arXiv:2604.23581, ACL 2026 Industry Track（接收信息以官方页为准）. https://arxiv.org/abs/2604.23581 （偏单管线 workflow；数字为作者自报。）↩︎ 24. *Retrospective Harness Optimization*, arXiv:2606.05922, 2026. https://arxiv.org/abs/2606.05922↩︎ 25. control/data plane 切分采纳自 IBM「Agent Control Plane」、Futurum ACPF（2026-04）等来源；提案/落账分离参考 Faramesh（arXiv:2601.17744）；harness/scaffold 术语切分参考 Hugging Face agent 术语表（2026-05）。↩︎ 26. 对立立场：Golem Cloud, *Rise of the Agent Runtime*, 2026-06（主张持久化与授权融合进 per-agent runtime）；loop 内直接派生的主流实践见 Claude Agent SDK subagents、OpenAI Agents SDK handoffs、CrewAI delegation 各自官方文档。↩︎

本文涉及的开源项目（均为笔者个人项目）

• • Meetkat：native-agent 决策会议室—supervisor 排"谁何时说"、specialist 决定"说什么"，协作动作全事件化（RoomEventJournal），纪要为事件流纯投影。Apache-2.0. https://github.com/ChristopheZhao/Meetkat
• • FlockMind：多智能体研究写作助手—EvidencePack/CitationPack 证据血缘，五档 ReplanScope 评审归因，fail-closed 证据门。https://github.com/ChristopheZhao/FlockMind
• • MuseCraft（short-video-maker）：多智能体视频创作流水线—带租约的节点尝试（WorkflowNodeAttempt），阶段门控（含 ffprobe 音轨探测门），失败定位到 node/attempt/gate/reason_code。https://github.com/ChristopheZhao/MuseCraft
• • HydraMind：承接上述 MAS 运行时经验的多智能体 harness 框架（四层架构蒸馏自 MuseCraft 生产系统）—RuntimeSession 单写者 + CAS，GateContract 类型化门契约，ExecutionHarness 执行壳契约，统一 ObservationEvent 轨迹事件族。Apache-2.0. https://github.com/ChristopheZhao/HydraMind