# Multi-Agent 协调：从竞争到协同的三种编排哲学

## 概述

当单个 agent 的能力边界遇到复杂工程任务时，multi-agent 协调成为自然的下一步。但"多个 agent 如何协同工作"并非只有一种答案。本文综合 Hermes 生态中八个 multi-agent 相关项目的分析，揭示三种截然不同的协调哲学——竞争（Gladiator）、对抗审议（Council）、协同（Swarm/Ankh/ACP）——以及它们在跨平台委派、AI-native SDLC（Big Iron）和大规模专业化编队（OpenCode Hermes Multi-Agent）中的具体实现。这些实验共同勾勒出 multi-agent 系统从"概念验证"走向"工程可用"的演进路径，并与 Anthropic 的 multi-agent research system 形成有趣的对照。

## 三种 Multi-Agent 哲学

### 竞争式：Gladiator 的达尔文主义

Gladiator 采用了最具戏剧性的 multi-agent 模式——**让两个零人类 AI 公司竞争改进同一开源产品**。Blitz（增长型，4 agents）和 Craft（质量型，5 agents）两支团队在 5-6 分钟内完成 10 个任务的竞赛。评分公式 `(tasks × 8) + (unique skills × 5) + (skill versions × 3)` 揭示了核心设计意图：**不仅评估任务完成度，更评估学习能力**——unique skills 和 skill versions 的权重意味着能在竞赛中创建新 SKILL.md 并迭代改进的团队得分更高。

竞争模式的核心价值在于**可观测性**。通过九区域实时 Dashboard（side-by-side 代码比较、Gantt 图、审计轨迹）和量化指标（SKILL.md 创建事件、MEMORY.md 增长曲线、skill usage events），将"agent 是否在学习"变成了可直观观测的过程。Post-competition merge 更验证了一个重要假设：**竞争中产生的知识可以跨团队迁移**——这暗示了一种"先竞争后合并"的知识蒸馏模式。

架构上使用 Paperclip 作为外部编排层（Node.js + PostgreSQL 16），Hermes Agent 作为执行层，配合 Anthropic prompt caching（5min TTL）和非代码 agent strip unused skills 的 token 优化策略。每次竞赛成本约 $5-6。但 600 秒硬性超时可能截断未完成任务，Paperclip adapter v0.1.1 的已知 bug 需手动 patch——竞争模式更适合作为 agent 能力的**评估与展示框架**，而非日常工程实践。

### 对抗审议式：Council 的认识论多元主义

Hermes Council 走了一条截然不同的路——不是让 agent 竞争完成任务，而是让 agent **围绕决策进行结构化辩论**。五个 persona 各有明确的认识论方法论：

- **Advocate**：Steel-manning 传统，构建最强支持论证
- **Skeptic**：Popperian falsificationism，系统性寻找反证
- **Oracle**：经验基准推理，锚定历史数据和先例
- **Contrarian**：Kuhnian paradigm critique，质疑底层假设框架
- **Arbiter**：Bayesian synthesis，概率综合裁决并输出 confidence scores

Council 的设计洞察是：**单一 LLM 的回答本质上是一次采样，多视角辩论则提供了近似于集成学习的效果**。五个 persona 的认识论多样性不是标签装饰——Popperian falsificationism 指导 Skeptic 必须系统性地寻找反证，Bayesian synthesis 指导 Arbiter 必须用概率框架综合矛盾证据。输出不仅包含裁决结论，还包含 confidence scores、evidence links 和 **DPO preference pairs**——后者使辩论结果可直接用于 RLHF 训练，形成"辩论 → 偏好数据 → 模型改进"的闭环。CouncilEvaluator 类提取 normalized rewards（0.0-1.0），意味着 Council 不仅是决策工具，还是训练数据生成器。

三个工具分别覆盖不同场景：`council_query`（五人完整辩论）用于重大决策、`council_evaluate`（对抗性质量评估）用于内容审查、`council_gate`（三人快速安全筛查）用于安全把关。

作为独立 MCP server 的架构选择值得注意——项目诞生于 hermes-agent PR #848 的反馈，刻意设计为独立服务以避免"core tool injection, provider bypass, hidden LLM costs, and brittle parsing"。任何支持 MCP 的 agent 都可以使用，不限于 Hermes。代价是五次顺序 API 调用带来的延迟（默认 60 秒 timeout）和成本（每次 council_query 消耗五次 LLM 调用，默认使用 hermes-3-llama-3.1-70b）。`~/.hermes-council/config.yaml` 支持自定义 persona 或覆盖默认配置。

### 协同式：Swarm 与 Per-Project Scoping

Zouroboros Swarm Executors 和 Ankh.md 代表了协同式的两个层面。

**Swarm Executors** 将异构 CLI 工具（Claude Code、Hermes、Gemini、Codex）统一为可被 orchestrator 调度的 **AI persona**，核心抽象是 bridge protocol："accept a prompt as input, return text via stdout"。每个 persona 声明 expertise domains 和响应时间特征（Claude Code 25-120s 处理复杂代码变更，Gemini 2-12s 处理 1M+ token 大上下文分析，Codex 3s 快速代码生成），orchestrator 据此进行语义级任务路由。共享身份系统（SOUL.md/IDENTITY 文件）确保所有 executor 具有一致的价值观和行为边界。通过 `executor-registry.json` 注册发现，Fallback chain（orchestrator resolved model → executor env var → CLI default）提供多层容错。自定义 executor 仅需模板 bridge script + registry 注册两步。虽然该仓库已 archived（迁移至 Zouroboros monorepo），但其"异构 agent 统一接口"的设计模式仍具参考价值。

**Ankh.md** 解决了协同的前提问题——**per-project agent scoping**。通过 `.agent/` 文件夹（含 `config.yaml`、`skills/`、`agent.jsonc`）实现项目级 agent 配置隔离，PATH-based 透明拦截使同一 `hermes` 命令在不同目录自动使用不同配置。全局 `~/.hermes` 与本地 `.agent/` 的配置合并策略借鉴了 `.gitconfig` 的分层模式。内置五个示例 agent（docs-explorer、web-researcher、ascii-designer、diagram-maker、plan-writer）降低了上手门槛。团队可通过 Git 共享 `.agent/` 文件夹，实现 agent 配置的版本控制——这是 multi-agent 协同在组织层面的基础设施。支持 sub-agent spawning 的设计也为项目内的 multi-agent delegation 留出了空间。

三种哲学并非互斥。一个成熟的工程团队可以：用 **Ankh** 做项目级 agent 定制，用 **Council** 做关键决策审议，用 **Gladiator** 做 agent 能力评估，用 **Swarm** 做日常异构任务路由。

## 跨 Agent 平台委派：ACP 协议

hermes-agent-acp-skill 解决了 multi-agent 系统中最实际的问题之一：**如何让一个 Hermes agent 将子任务委派给不同平台的 agent？** 通过 `delegate_task()` 接受包含 goal 定义和 agent 指定的任务数组，用 `agent=...` 语法路由到 Hermes subagents、Codex 或 Claude Code。

关键设计原则是 **context isolation**——委派的工作不污染父执行状态。Context isolation 的重要性不能被低估：在 multi-agent delegation 场景中，如果子任务的上下文泄漏到父 agent，会导致两个严重问题：context window 膨胀（子任务可能产生大量中间输出）和推理干扰（子任务的上下文可能误导父 agent 的后续决策）。ACP skill 通过严格隔离解决了这个问题，同时用 `external_timeout_seconds`（默认 900）和 `external_max_output_chars`（默认 24000）做安全兜底。

ACP 模式展示了一种重要的架构趋势：**agent 不是孤立的，而是可以作为更大编排系统中的"可调用服务"**。Hermes 可以调用 Codex 做快速代码生成，调用 Claude Code 做复杂重构——每个 agent 平台的优势被按需组合，而非被锁定在单一平台中。这与 Zouroboros Swarm 的设计理念高度一致，但 ACP 更侧重于单个 Hermes Agent 向外委派任务，而 Swarm 更侧重于全局编排。

## AI-Native SDLC：Code Graph 驱动的开发流程

Big Iron（虽已弃用，迁移至 supermodel CLI 的"supermodel factory"）提出了一个前瞻性的命题：**AI agent 不应该"读文件"，而应该"查询代码图"**。通过 Supermodel 的 multi-layered code graphs（call graph / dependency graph / domain graph / AST），agent 在每个 SDLC 阶段获得结构化的代码理解，而非原始文本。

其 8 阶段 AI-native SDLC 覆盖了从规划到夜间健康检查的完整开发周期：

1. **Planning**：graph-grounded scoping，基于代码图精确评估变更影响范围
2. **Architecture Check**：自动检测循环依赖和分层违规
3. **Code Generation**：graph-aware 生成，agent 在生成代码时已知完整的调用链和依赖关系
4. **Quality Gates**：graph-diff 验证新增 edge 和 coupling 变化，无需人工 gatekeeping
5. **Test Ordering**：拓扑排序确保测试按依赖顺序执行
6. **Code Review**：graph-enriched feedback，reviewer 能看到结构化的变更影响
7. **Refactor**：leaf-first sequencing + debt scoring，从依赖图叶节点开始重构
8. **Health Cron**：夜间自主健康检查和 drift detection

三种运行模式提供了灵活性：`factory run`（完整 8 阶段）、`factory health`（只读评估）、`factory improve`（评估+重构）。**Phase Gate 设计**是核心创新——`graph_gate.sh` 脚本返回 PASS/FAIL exit codes，可直接集成到 CI pipeline。

Big Iron 与 OpenCode Multi-Agent 在 AI-native SDLC 的目标上殊途同归，但方法论形成鲜明对比：Big Iron 强调**代码图结构理解**（提升单个 agent 的上下文质量），OpenCode 强调 **agent 专业化分工**（通过数量和分工覆盖复杂度）。这两种路径可能最终需要融合——既需要结构化的代码理解，也需要专业化的 agent 分工。

## 17 专业化 Agent 编队

OpenCode Hermes Multi-Agent 是 Hermes 生态中 agent 数量最多、分工最细的编排方案。17 个专用 agent 由 Hermes master orchestrator（使用 `openai/gpt-5.2-high`）统一调度，分为六大类：

| 类别 | Agent | 职责 |
|------|-------|------|
| Research | @finder, @analyst, @researcher | 快速代码扫描、依赖/风险评估、最佳实践调研 |
| Planning | @architect, @planner | 组件设计、原子任务分解 |
| Implementation | @coder, @editor, @fixer, @refactorer | 新代码生成、安全修改、bug 修复、结构增强 |
| Quality | @reviewer, @tester, @debugger, @security | 质量评估、测试创建、根因分析、漏洞检测 |
| Documentation | @documenter, @commenter | 技术文档、代码注释 |
| Infrastructure | @devops, @optimizer | 部署自动化、性能分析 |

七个预定义 workflow pipeline 覆盖了标准特性开发、安全敏感特性、未知 bug 调查、已知 bug 修复、重构、性能优化和基础设施变更。四个关键设计决策值得关注：

- **强制质量门**：每次代码变更后必须 code review + testing，不可跳过
- **安全优先级**：`security > quality > implementation`，认证/用户数据/凭证变更必须安全审计
- **三次修订限制**：超限后 escalation，避免无限重试循环
- **Checkpoint 系统**：workflow 阶段间需用户确认，保持 human-in-the-loop
- **Session Learning**：从 recurring issues 中适应，越用越好

这种激进的专业化分工有明确的逻辑——每个 agent 有窄而深的 expertise scope，减少了单个 agent 需要的 context 量，理论上提高了每个子任务的执行质量。配合 MCP Servers（Context7 库文档 + mcp-server-fetch web 内容）提供外部知识支持。但 17 个 agent 的编排复杂度也是显著的风险：调试困难、故障定位复杂、model 分配固定（GPT-5.2/Claude variants/Gemini）缺乏运行时可配置性、每个工作流可能消耗大量 token 和 API 调用。

## 与 Anthropic Multi-Agent Research System 的对比

Anthropic 在其 multi-agent research 中提出的架构原则，为评估 Hermes 生态的 multi-agent 实验提供了参考基准。

**编排拓扑：层级 vs 多元**。Anthropic 采用严格的 lead agent + sub-agent 的 hub-and-spoke 层级模型，OpenCode Multi-Agent 的 master orchestrator + 17 sub-agent 完全契合这一模式。但 Gladiator 的竞争模式和 Council 的对抗审议模式突破了层级假设——agent 之间可以是对等的竞争者或辩论者，而非上下级。Zouroboros 的 swarm 模式则更接近 peer-to-peer，通过共享身份（SOUL.md）而非层级命令来协调。Hermes 生态展示了比 Anthropic 更丰富的编排拓扑空间。

**Context 管理的共识与分歧**。Anthropic 和 ACP skill 都将 context isolation 视为 multi-agent 的核心设计原则——子 agent 在独立的 context window 中工作，只将结构化结果返回父 agent，保护了父 agent 的 context 清洁度。但 Gladiator 的 post-competition merge 和 Zouroboros 的统一 memory 集成展示了另一种可能：**跨 agent 知识共享**而非严格隔离。两者的适用场景不同：任务执行需要隔离（避免干扰），知识积累需要共享（避免重复学习）。

**工具使用 vs 代码图**。Anthropic 的 multi-agent 依赖标准的文件读写和搜索工具，Big Iron 则提出了更结构化的"代码图查询"替代方案。前者最大化了通用性（任何项目都有文件），后者最大化了信息质量（resolved signatures、imports、caller annotations 比原始文件更精确），但增加了对特定基础设施（Supermodel API）的依赖。

**安全控制的深度差异**。Anthropic 的 permission system（sandbox / supervised / autonomous 三级）比 Hermes 生态中大多数项目更成熟。ACP skill 的 timeout + output limit 是最基本的安全控制，OpenCode 的强制质量门和安全审计更进一步（security > quality > implementation 优先级），但都未达到 Anthropic 的"权限分级 + 人类审批门控"的系统化水平。Council 的 `council_gate`（三人快速安全筛查）提供了一种独特的"审议式安全检查"，是 Anthropic 框架的有益补充。

**Agent 同质性 vs 异构性**。Anthropic 的实验通常涉及少量同质高能力 agent（2-5个），注重单个 agent 的深度推理；Hermes 生态的特色在于异构性——不同平台（Hermes + Codex + Claude + Gemini）、不同能力（research / coding / security / documentation）、不同哲学（竞争 / 辩论 / 协同）。这种异构性带来了更大的设计空间，也带来了更高的编排复杂度。

| 维度 | Anthropic Multi-Agent | Hermes 生态 Multi-Agent |
|------|----------------------|------------------------|
| 编排拓扑 | Hub-and-spoke 层级 | 层级 + 竞争 + 对抗 + Swarm |
| Agent 同质性 | 同质 sub-agents | 异构专业化 agents |
| 跨平台 | 单一平台（Claude） | Hermes + Codex + Claude + Gemini |
| 知识流动 | 严格隔离 | 隔离 + 共享并存 |
| 决策模式 | Lead agent 裁决 | 辩论 / 竞争 / 分层裁决 |
| 安全控制 | 三级权限系统 | Timeout + 质量门 + 审议式筛查 |

## 跨项目洞见

**编排复杂度与收益的非线性关系**。从 Ankh（1 agent per project）到 Swarm（4 executors）到 Council（5 personas）到 OpenCode（17 agents），agent 数量的增加带来的编排复杂度是超线性的，但收益并不一定同比增长。找到特定场景的"甜点"非常重要——不是越多越好，而是分工足够细、协调开销足够低的平衡点。对于大多数场景，ACP Skill 的按需委派（3-5 个 sub-agents）可能是最务实的选择。

**已弃用项目的信号价值**。Big Iron 和 Zouroboros Swarm Executors 都已 archived，但它们探索的设计模式（code graph query、persona bridge protocol）仍然有效。弃用的原因更多是项目整合（迁移至 monorepo 或 supermodel CLI），而非设计方向的否定。这些模式很可能在新的承载形式中延续。

**MCP 作为 multi-agent 的通用胶水**。Council 作为 MCP server、ACP 通过 MCP 集成外部工具、Big Iron 通过 MCP 连接 Supermodel、OpenCode 使用 Context7 和 mcp-server-fetch 获取外部知识——MCP 协议正在成为 Hermes multi-agent 生态的连接标准。这降低了 agent 间的集成成本，但也意味着 MCP server 的可靠性成为系统性风险。

**对抗机制作为质量保障手段**。Council 的对抗审议和 Gladiator 的竞争机制揭示了一个被低估的应用方向——agent 不仅可以协作完成任务，还可以对抗性地检验决策质量和代码质量。将 Council 集成到 code review 或架构决策流程中，将 Gladiator 用于 agent 配置的 A/B testing，是高投资回报的质量保障策略。

## 对技术管理者的建议

1. **根据决策类型选择协调模式**：需要 agent 能力评估用 Gladiator 竞争模式（$5-6/次，适合定期评估）；需要高风险决策审议用 Council 辩论模式（五次 LLM 调用/次，适合架构选型和安全决策）；需要日常任务执行用 Swarm/ACP 协同模式（按需委派，成本可控）。三者不互斥，可按场景组合。

2. **从小规模开始，按需扩展 agent 数量**：先用 2-3 个 agent 的 ACP delegation 验证基础编排能力和 context isolation 效果，确认有效后再考虑 OpenCode 的多 agent pipeline。编排复杂度是最容易被低估的成本——17 个 agent 的 pipeline 出了问题，故障定位时间可能远超单 agent 场景。

3. **将 context isolation 作为不可妥协的设计原则**：无论采用哪种 multi-agent 模式，子 agent 的 context 必须与父 agent 严格隔离。context 泄漏导致的推理质量下降比显式的 timeout 错误更难诊断。ACP skill 的 timeout（900s）+ output limit（24000 chars）是最低限度的安全基线。

4. **利用异构 agent 平台的互补优势**：不要锁定在单一 agent 平台中。Zouroboros 的 bridge protocol 思路证明了异构 agent 可以通过统一接口协同——Claude Code 做复杂推理、Gemini 做大上下文分析、Codex 做快速生成。按任务特征路由到最合适的平台。

5. **关注 MCP 生态的成熟度**：Council、ACP、Big Iron 和 OpenCode 都依赖 MCP 协议或 MCP server，确保团队有 MCP server 的运维能力。建立 MCP 连接的健康检查和 fallback 机制，避免 MCP server 故障导致整个 multi-agent pipeline 失效。

6. **Code Graph 是值得跟踪的方向**：虽然 Big Iron 已弃用，但"查询代码图替代读文件"的思路在 agent 理解大型代码库时有明确优势。关注 supermodel CLI 的"supermodel factory"后续发展，以及类似的结构化代码理解方案。

7. **利用对抗机制做质量保证**：将 Council 模式集成到 code review 或架构决策流程中（`council_evaluate` 做代码质量评估，`council_gate` 做安全筛查），将 Gladiator 模式用于 agent 配置的 A/B testing。DPO preference pairs 的输出还可以反哺模型训练。这些不是日常执行工具，而是高价值的质量保障手段。

## 引用来源

- [Ankh.md: Per-Project Agent Scoping](../notes/05-multi-agent/01-ankh-md.md)
- [Gladiator: 竞争式 Multi-Agent 演示](../notes/05-multi-agent/02-gladiator.md)
- [Big Iron: Code Graph 驱动的 AI-Native SDLC](../notes/05-multi-agent/03-bigiron.md)
- [OpenCode Hermes Multi-Agent: 17 专用 Agent 编排](../notes/05-multi-agent/04-opencode-hermes-multiagent.md)
- [Hermes Agent ACP Skill: 跨平台 Agent 委派](../notes/04-integrations/07-hermes-agent-acp-skill.md)
- [Hermes Council: 对抗性多视角审议](../notes/04-integrations/09-hermes-council.md)
- [Zouroboros Swarm Executors: 异构 Agent Persona 编排](../notes/04-integrations/05-zouroboros-swarm-executors.md)