跨编码代理的工作协调
您是协调者：您拥有任务定义、审查每个交付物，并决定下一步做什么。每个其他代理都是一个工作者：它接收规范、生成工件，然后停止。没有跨厂商的消息总线，所以协调是基于回合且以文件为中介的：
您编写 task.md -> 工作者无头运行 -> 工作者编写 result.md ->
您阅读、验证、决定下一回合
如果已安装 agent-sync，在委派任务前运行 agent sync，以便每个工作者都从您拥有的相同的综合记忆开始。
1. 编写任务目录
task/
task.md # 规范（见下文约定）
...inputs... # 工作者所需的一切；工作者没有其他上下文
result.md # 工作者编写此文件；其存在标志着完成
task.md 是一份承包商简报，必须包含：
- 目标，在一段中；
- 确切的交付物（一个文件，命名）；
- 可检查的完成定义；
- 编写交付物后停止的指令；
- 当工作者将编辑共享树时，第 2 节中的锁或工作树规则。
2. 在调用任何人之前选择共享模式
规则零：两个代理绝不能同时修改同一个工作树。
| 情况 | 模式 |
|---|---|
| 工作者仅读取（审查、分析、第二意见） | 同一目录，无锁 |
| 在一个树上的交替编辑 | 同一目录 + mkdir 锁 |
| 并行尝试或并行文件触碰子任务 | 每个工作者一个 Git 工作树 |
| 两个代理同时编辑一个树 | 永不允许；重构 |
同一目录锁（mkdir 是原子的；也要将这些指令放入 task.md）：
until mkdir .agent-lock 2>/dev/null; do sleep 1; done # 获取
echo "$(whoami):$$" > .agent-lock/owner
# ... 工作 ...
rm -rf .agent-lock # 释放
永远不要按年龄自动过期锁：一个慢的工作者看起来和一个死的工作者一样。在清除陈旧的锁之前，验证工作者进程是否已死亡。
工作树模式：每个工作者使用 git worktree add ../task-<worker> -b agent/<worker>，工作者从不推送，也从不触碰彼此的工作树，主检出保持只读，而您（协调者）作为唯一的串行化步骤执行所有合并。
3. 无头调用工作者
| 工作者 | 命令 |
|---|---|
| Claude Code | claude -p "Read task.md in this directory and complete it." |
| Codex CLI | codex exec --skip-git-repo-check --sandbox workspace-write "Read task.md in this directory and complete it." </dev/null |
| Gemini CLI | gemini -p "Read task.md in this directory and complete it." |
通过艰难方式学到的规则：
- 从任务目录内部运行工作者，并将其写入权限限定到该目录。
- 对任何后台工作者关闭标准输入（
</dev/null），否则它可能会挂起等待输入。 - 如果没有
--skip-git-repo-check，Codex 会拒绝不受信任的非 Git 目录。
4. 验证，然后决定
- 工作者的话不是交付物。阅读
result.md并根据完成定义进行检查；对于代码，自行运行测试。 - 缺失或错误的交付物会得到带有更清晰规范的新一轮，而不是重试相同的一轮。
- 您对您接受的任何内容负责：像审查人类承包商的 PR 一样审查工作者的差异。
边界
- 绝不给工作者凭据、部署权限或访问真实用户群体；工作者生产工件，协调者（与用户）发布它们。
- 即使对于“快速”任务，也绝不用此协议来并行化一个树内的编辑而不使用锁或工作树。
- 用户决定哪个代理担任协调者；不要将协调权移交给工作者。