360 Secure SkillHub
360 安全技能中心

Multi Agent

核心功能:提供Coordinator/Fork/Swarm三种多agent委托模式选型,及任务协调、文件锁、工作空间隔离、结果综合等设计方案。典型场景:多阶段复杂任务、需继承上下文的子任务、同质独立工作流,或多agent并发编辑文件、需隔离工作空间等场景。输出含任务清单、综合文档等标准产物,不适用于单agent、跨阶段知识传递场景。

lanyasheng
lanyasheng
热度 42.62
最近更新 2026-05-11 17:40:44
分类:知识依赖:纯提示词应用场景:概念解释 / 工作流 / 任务管理

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add eh-multi-agent
Metadata
name
multi-agent
version
2.0.0
category
knowledge
description
多 agent 协调设计模式。当需要选择 coordinator/fork/swarm 模式或设计跨 agent 协作时使用。不适用于工具重试(用 tool-governance)或上下文管理(用 context-memory)。参见 execution-loop(coordinator 持续执行)。
license
MIT
triggers
["multi agent","多 agent","coordinator","fork vs swarm","agent coordination","workspace isolation","file conflict"]
author
OpenClaw Team

Multi-Agent Coordination

多 agent 系统设计模式:委托模式选型、任务协调、并发控制、质量保障。纯设计指南。

When to Use

  • 选择 Coordinator/Fork/Swarm → Three delegation modes
  • 多 agent 同时编辑同一文件 → File claim and lock
  • 需要隔离工作空间 → Agent workspace isolation
  • 协调者需要综合 worker 结果 → Synthesis gate

When NOT to Use

  • 只有 1 个 agent → 用 execution-loop
  • 跨阶段知识传递 → 用 context-memory

Patterns

4.1 Three Delegation Modes

三种模式各有适用场景:

模式 特点 适用
Coordinator Worker 从零开始,4 阶段(Research→Synthesis→Implementation→Verification) 多阶段复杂任务
Fork Child 继承 parent 完整上下文和 prompt cache(首次调用只付 cache read 价格 $0.003/1K vs 全量 $0.036/1K),单层限制 需要 parent context 的子任务
Swarm 扁平名单,file-based mailbox,不能递归 spawn 长期独立的同质工作流

不确定选哪个→ Coordinator,覆盖最广。Fork 限制:child 不能再 Fork、不能 clarify、不能 memory writes。 → 详见

4.2 Shared Task List Protocol

共享任务板 .coordination/tasks.json:

{
  "tasks": [
    {"id": "t1", "description": "重构 auth 模块", "status": "pending", "claimed_by": null, "result": null}
  ],
  "updated_at": "2025-03-15T10:00:00Z"
}

四状态:pending → claimed → done/failed。领取任务通过原子锁 mkdir ".coordination/tasks.lock"(POSIX 上 mkdir 是原子操作),10 次重试,指数退避 50-500ms,释放用 rmdir。

Claude Code Swarm 使用 per-agent inbox ~/.claude/teams/{team}/inboxes/{agent}.json 替代共享 tasks.json,减少锁竞争。 → 详见

4.3 File Claim and Lock

编辑文件前写排他锁:

// .claims/src_handlers_ts.lock(路径中 / 替换为 _)
{"session_id": "abc123", "file": "src/handlers.ts", "claimed_at": 1710489600, "expires_at": 1710490200}
  • 10 分钟 TTL(expires_at = now + 600),防 crash 死锁
  • PreToolUse hook 拦截 Write/Edit,读 tool_input.file_path,检查 lock 是否被其他 session 持有且未过期
  • 过期 lock 清理:find .claims -name "*.lock" -mmin +15 -delete

粒度是整个文件。需更细粒度→用 workspace isolation。 → 详见

4.4 Agent Workspace Isolation

每个 worker 独立 git worktree:

git worktree add .worktrees/${WORKER_ID} -b work/${WORKER_ID} HEAD
claude -p --cwd .worktrees/${WORKER_ID} "..."

共享 .git 仓库但独立工作目录和 index,彻底消除并发冲突。代价是 merge 阶段冲突集中爆发。三种 merge 策略:git merge --no-ff(保留历史)、cherry-pick(只取最终结果)、git diff main...branch > patch(最安全,人工 review)。清理:git worktree remove + git branch -d。 → 详见

4.5 Synthesis Gate

Research → Implementation 之间的强制关卡。核心原则:coordinator must synthesize, not delegate understanding。

Gate 脚本检查 .coordination/synthesis.md:

  1. 文件存在且非空
  2. 最少 10 行
  3. 必含匹配 Conclusion、Action Plan|Implementation Plan、Evidence|Rationale 的 section

通过后 implementation worker 启动:claude -p --max-turns 50 "$(cat .coordination/synthesis.md)"。

把原始 research 结果直接转发给 implementation worker 是反模式。 → 详见

4.6 Review-Execution Separation

Implementation 和 review 由两个隔离 session 的 agent 分别执行,盲审消除确认偏误。

  • Implementation agent:claude -p --max-turns 60
  • Review agent:claude -p --max-turns 20,只接收 git diff main 和任务描述,不知道 implementation agent 的推理过程
  • Review 输出:.coordination/review-result.json 含 {approved: bool, issues: [...], suggestions: [...]}
  • approved == false → issues 喂给一个新 implementation session(不是原来那个),避免锚定

→ 详见

E4.x Extended Patterns

Cache-safe forking、完整 context 隔离、file-based mailbox(per-agent inbox JSON + lockfile)、permission delegation、结构化消息协议。 → 详见

Workflow

选模式用决策树,选完后按对应路径执行。

需要多 agent?
├── Worker 需要 parent 已加载的 context?
│   └── 是 → Fork
│         · child 继承完整上下文 + prompt cache,首次调用只付 cache read 价格
│         · 单层限制:child 不能再 Fork
│         · 任务和 parent context 无关时别用 Fork,浪费 context 装无关内容
│
├── Workers 之间需要分阶段协调?
│   └── 是 → Coordinator(4 阶段)
│         1. Research — 多 worker 并行探索
│         2. Synthesis — coordinator 独占,综合所有结果产出 synthesis.md
│            (不可委派,不可跳过——直接转发原始结果会让下游无所适从)
│         3. Implementation — 按文件集分配,同文件串行防 merge conflict
│         4. Verification — 独立 review agent 盲审,不看 implementation 推理
│
└── 各自独立、同质任务?
    └── 是 → Swarm
          · 扁平名单:teammate 不能 spawn 新 teammate
          · 通过 file-based mailbox 通信(per-agent inbox JSON + lockfile)
          · 用 .coordination/tasks.json 共享任务状态

所有模式通用:每个 worker 分配独立 worktree(Pattern 4.4),编辑文件前写 claim lock(Pattern 4.3)。

Output

产物 路径 说明
任务清单 .coordination/tasks.json 所有 worker 的任务分配、状态、认领记录
综合文档 .coordination/synthesis.md coordinator 综合 worker 结果的结构化决策文档
文件锁 .claims/*.lock 每个 worker 编辑文件前写入的排他锁,防止并发冲突

Related

  • execution-loop — Ralph 持续执行循环,用于 coordinator 的长时间持续执行
  • context-memory — handoff 文档,用于跨阶段(研究→综合→实现)的知识传递
  • tool-governance — component-scoped hooks,用于给不同 worker 配置不同的工具权限