Multi-Agent Veto Boundary

2026-05-22#agent-runtime#multi-agent#orchestration#guardrails#reliability

背景

MOSS 中文的一条观点大意是：多 Agent 协作里，每个 Agent 都应该有明确的“否决”边界。也就是它在什么情况下可以拒绝 orchestrator 的指令，什么情况下必须执行。

这句话不是一个我能找到的标准命名原则，但它很适合作为 agent runtime 设计里的工程判断来保存。

核心判断

多 Agent 协作不是“上游说什么，下游就做什么”的指令传话。Orchestrator 负责拆解任务和分配意图，但接收方 Agent 应该在执行前判断：

  • 这是不是我的角色 / 能力范围？
  • 前置条件、权限、上下文是否足够？
  • 上游输入是否符合约定的输出契约？
  • 指令是否和本地已验证事实冲突？
  • 是否触发隐私、安全、成本或副作用风险？
  • 如果拒绝，应该返回什么结构化理由和下一步建议？

一句话：

Agent 不是函数调用；delegation needs an acceptance contract.

没有这层边界，下游 Agent 就会把上游输出当成高可信事实继续传播。一旦上游错了，后面的 Agent 可能每一步都“看起来执行成功”，但整条链路已经偏航。

考证脉络

经典 Agent 理论里，autonomy 本来就意味着 Agent 对自身动作和内部状态有一定控制权，而不是只被外部系统直接驱动。Wooldridge & Jennings 对弱 Agent 概念的描述里，autonomy、social ability、reactivity、pro-activeness 是核心属性之一。

Contract Net / FIPA 这条更老的多 Agent 研究线，也没有把任务分配理解成单向命令。它把分配任务建模成协商：initiator 发出 call for proposals，participant 可以 propose 或 refuse，initiator 再 accept 或 reject。这里已经有“接收方先判断是否参与”的雏形。

现代 LLM Agent 工程里的 guardrails、tripwires、tool safeguards、human-in-the-loop interrupt，本质上也在处理同一件事：不要只在 orchestrator prompt 里声明规则，而要在 handoff 或 action 边界上做可执行的判断。

近期 LLM-MAS 失败研究提供了风险侧证据。Cemri et al. 提出的 MAST（Multi-Agent System Failure Taxonomy）把多 Agent 失败归到 system design、inter-agent misalignment、task verification 等类别；关于 error cascades、online auditing、constraint drift 的论文也都在说明：单个早期错误如果被下游 Agent 接受，会在长链路里变成轨迹级失败。

设计上的坑

Veto boundary 不能只写成“你可以拒绝”。真正可用的边界至少要返回：

  • 拒绝类型：scope / precondition / policy / evidence / budget / schema
  • 触发证据：是哪条输入、哪项约束、哪个工具风险
  • 可恢复建议：补什么上下文、降级到哪个工具、是否需要人工确认
  • 终止语义：这次拒绝是 hard stop（FATAL）、可重试（RETRYABLE），还是交给 orchestrator 仲裁（ESCALATION）

否则“否决权”会变成另一种不可靠：Agent 互相踢球、无限澄清、循环重试。

可发展的文章角度

可以写成一篇关于 Agent 协作边界的文章：

  • 标题方向：Agent 不是函数调用：多 Agent 协作为什么需要否决边界
  • 主线问题：orchestrator 的命令权和 sub-agent 的自治权如何划分？
  • 关键对照：prompt 里的角色声明 vs runtime 里的 acceptance contract
  • 可结合已有方向：Trace Log、tool result role design、agent iteration harness
  • 结尾落点：好的 Agent runtime 不是让所有 Agent 更听话，而是让每次交接更可审计、更可拒绝、更可恢复

参考来源