多智能体可靠性应检查交接链路

单个 Agent 检查合格，多 Agent 系统依然可能交付错误结果。问题常出在交接处：上游漏了上下文，下游却把它当成事实继续执行，分支和并行任务又让错误更难追踪。

这篇文章汇集了三位从业者的观点，主张把检查重点放到 Agent 之间的路径上：记录交接、校验输入、分别评估能力，再用模拟环境和审批限制行动权限。对正在搭建 AI 编程工作流的团队，它提供了一套可落实的检查思路，但没有给出经过对照实验验证的可靠性提升数据。

为什么每个 Agent 都过关，整个流程还是会出错

Mikiko Chandrasekhar 在 2025 年 7 月分享过一个现场观察：AI Engineer World's Fair 上，大约 80% 的听众表示正在构建 Agent，表示已经投入生产的人数几乎一样，可能只少一两人。但问到是否第一次就能 100% 正常工作，没有人举手。

这只能说明现场参与者的经历，不能当成行业故障率。它指出的问题却很实际：能运行、能上线，与稳定交付之间还有距离。

作者援引 Chandrasekhar 的说法，即使工作流已经结构化，也可能每 100 次出现一次不同答案；任务更复杂时，可能每 20 次出现一次。原文没有交代测试集、模型或实验条件，因此这两个数字更适合作为经验描述，不能直接用于估算自己系统的风险。

多 Agent 会进一步放大这种不稳定。上游产生一份不完整的结果，下游没有核对就继续推理，局部遗漏便进入后续决策。最终失败的 Agent，未必是最初犯错的那个。

单个 Agent 的合格分数，覆盖不了交接过程中的错误。

Chandrasekhar 建议把 Agent 拆小，每个负责一到三项任务，并按各自职责设定标准，然后再检查整个系统。对于 coding agent，她提到准确性、运行效率和建议被接受的次数，也明确反对用代码行数衡量效果。

这里有两层检查：专门负责生成代码的 Agent，要看代码是否正确；整个工作流，还要看需求、代码和验证结果是否在交接中保持一致。只留一个总分，很难找到哪个环节偏离了任务。

交接检查应该拦住什么

Giovanna Carofiglio 在 2025 年 7 月的讨论中，强调让 Agent 通信、数据流转和工具调用可见。开发者需要据此调试，生产运维团队也需要据此追查问题。

最小的交接记录包含发送方、接收方和载荷（payload）。接下来按照接收方要求的结构定义（schema）校验：缺字段，可能是上下文丢失；类型错误，可能让下游把错误输入当成有效事实。

下面这段原文示例，把记录、校验和调用串在一起：

class HandoffRejected(Exception):
    def __init__(self, receiver):
        super().__init__(receiver)

def trace_span(name, fields):
    return {"name": name, "fields": fields}

def schema_ok(payload, schema):
    # schema 将接收方需要的各字段映射到预期类型
    return isinstance(payload, dict) and all(
        isinstance(payload.get(field), kind) for field, kind in schema.items()
    )

def call_agent(receiver, payload):
    return {"receiver": receiver, "payload": payload}

def handoff(sender, receiver, payload, schema):
    trace_span(
        "agent_handoff",
        {"from": sender, "to": receiver, "payload": payload},
    )
    if not schema_ok(payload, schema):
        raise HandoffRejected(receiver)
    return call_agent(receiver, payload)

关键是 if not schema_ok(payload, schema):：校验失败就抛出 HandoffRejected，阻止执行走到 call_agent。

不过，原文明确说这只是待改造的草图。trace_span 仅返回字典，调用方没有保存返回值，并没有真正把日志写到任何地方；call_agent 也只是返回字典。直接复制，得不到可用的追踪系统。

schema 校验还有明确边界。一个字段可以类型正确、内容错误。书名是字符串，不代表这本书存在；代码是字符串，也不代表可以通过构建。它能挡住一部分结构错误，内容是否可信仍要单独评估。

Carofiglio 还建议探索 Agent 可能遇到的状态和解答空间，观察相似输入能否产生一致输出。实际落地时，需要把这转成具体测试用例；原文没有提供可直接采用的覆盖方法。

并行执行时，人应该在哪一步介入

Kris Lovejoy 在 2026 年 6 月的讨论中，提出把关键系统里的 Agent 当作特权用户管理。她给出的顺序是：建立清单，在模拟环境中评估行为，制定并监控策略，保留审计与合规报告，再由人承担监督职责。

模拟环境的价值，是在接触真实系统前，检查 Agent 是否会执行团队不希望发生的操作。权限越大，越不能只测试正常任务能否完成。

她也质疑把人放进每个执行环节的 human in the loop 模式，提出 human on top：让人监督系统，并在行动完成前设置二次评估和审批。多个任务并行时，每条分支都等人确认，容易拖住整个流程。

这不是取消人工检查，而是重新选择检查位置。

Lovejoy 同时提醒，把确定性规则贴到自主系统上，并不能覆盖所有行为。规则漏掉某种情况后，编排 Agent 和小型任务 Agent 可能继续追求各自目标，造成系统故障。她提到一个近期租车案例，但原文没有展开经过，无法据此判断具体失败机制。

我的判断

我赞成优先检查交接。它把「模型偶尔不稳定」转成了可以定位的工程问题：谁传了什么、接收方要求什么、错误从哪里开始传播。对已有多 Agent 工作流的团队，这比只调整提示词更容易建立排查依据。

但文章提供的是工程建议与从业者经验，没有给出引入这些措施前后的对照数据。现场举手、答案变化频率和租车案例，都不足以证明某套架构能达到特定可靠性。

还要防止为了拆分而拆分。文章建议每个 Agent 负责一到三项任务，却没有比较这种做法与单 Agent 加工具、固定流水线的效果。任务边界不清时，拆分会增加需要检查的交接点。简单任务是否需要多 Agent，应先看分工带来的收益。

校验结构、验证内容和限制行动权限，需要分别落实。

另外，建议被接受的次数适合辅助评估 coding agent，但接受不等于正确。运行效率也需要明确口径，原文没有说明是延迟、成本还是生成代码的执行效率，团队需要按任务自行定义。

能拿来做什么

• 如果你的 AI 编程流程已经拆成需求分析、代码生成和验证几个 Agent，就为每次交接记录发送方、接收方和载荷，并在下游调用前检查必填字段与类型，让不完整输入尽早失败。
• 为 coding agent 分别评估准确性、运行效率和建议接受情况，同时保留端到端检查，验证最终代码是否满足原始需求，避免局部得分掩盖整体失败。
• 在扩大 Agent 的自主操作权限前，先在模拟环境中测试不希望发生的行为，并明确哪些行动完成前必须经过二次评估或人工审批。
• 并行工作流可以把人工监督放在关键行动完成之前，同时保留 Agent 清单、策略监控和审计记录，让故障发生后能够追溯执行路径。