Multi-agent work in three spoonfuls: what worked for me and what did not
Multi-agent work in three spoonfuls: what worked for me and what did not
多智能体工作的三勺心得：哪些对我有效，哪些无效
This started as a practical annoyance: long tasks interrupted by quota limits, conversations that became too heavy, and reviews that required copying context across windows in clumsy and inefficient ways. To deal with that, I built a multi-agent workflow in VS Code, on Arch Linux. I first called it tri-agent; after a couple of months it became penta-agent, a still imperfect way of coordinating agents, roles, permissions, and traces in my own workflow. 这一切始于一个实际的困扰：长任务被配额限制中断、对话变得过于沉重、以及需要笨拙且低效地在窗口间复制上下文来进行审查。为了解决这些问题，我在 Arch Linux 上的 VS Code 中构建了一个多智能体工作流。我最初称之为“三智能体”（tri-agent）；几个月后，它演变成了“五智能体”（penta-agent），这是一种在我自己的工作流中协调智能体、角色、权限和追踪记录的尚不完美的方法。
It is not a new idea, and it is not a promise of full autonomy. In fact, maintaining it takes work. But it is a local work contract that orders who executes, who reviews, when MCP is used, when Gemini/Antigravity enters, when Copilot remains only support, which skills are loaded, and what evidence or artifact should exist at the end. I am writing from my own cases: memos, regulatory review, spreadsheets, statistical models, scripts for a home server, system timers, self-hosted cloud, router security, backups, this blog, and everyday maintenance. In those cases, having some agentic governance has helped me. Maybe it is also a false sense of digital sovereignty. I am not immune to that. 这并不是什么新点子，也不是对完全自主的承诺。事实上，维护它需要付出努力。但它是一份本地工作契约，规定了谁来执行、谁来审查、何时使用 MCP、何时引入 Gemini/Antigravity、何时让 Copilot 仅作为辅助、加载哪些技能，以及最终应该产生什么样的证据或产物。我基于自己的案例撰写此文：备忘录、监管审查、电子表格、统计模型、家庭服务器脚本、系统定时器、自托管云、路由器安全、备份、本博客以及日常维护。在这些案例中，拥有某种智能体治理机制对我有所帮助。也许这只是一种数字主权的虚假感，我也无法免俗。
The thesis is simple: a multi-agent system without roles, permissions, and traces may look sophisticated, but in practice it can feel too much like a meeting without minutes. Three ideas to start with: Codex has worked for me as the main executor: it reads files, applies patches, runs validations, and can close diffs with evidence. It is not infallible, so it should not be the only validator on critical changes. Claude has worked for me as a strong reviewer, especially with Opus: architecture, regulation, statistical assumptions, and argumentative risks. I use it as a brake and as support for the main executor. Gemini/Antigravity, Copilot, and LiteLLM with DeepSeek and Z.ai work better when bounded: exploration, validation, canary work, or small tasks. When they start deciding with too little context, the workflow gets worse. 核心论点很简单：一个没有角色、权限和追踪记录的多智能体系统看起来可能很复杂，但在实践中，它感觉就像一场没有会议纪要的会议。先从三个想法开始：Codex 作为主要执行者对我很有用：它能读取文件、应用补丁、运行验证，并能带着证据关闭差异（diffs）。它并非万无一失，因此不应成为关键变更的唯一验证者。Claude 作为强有力的审查者对我很有帮助，尤其是 Opus 模型：它擅长架构、法规、统计假设和论证风险。我把它当作刹车和主要执行者的支持。Gemini/Antigravity、Copilot 以及结合 DeepSeek 和 Z.ai 的 LiteLLM 在有边界的情况下表现更好：例如探索、验证、金丝雀测试或小任务。当它们在上下文不足的情况下开始做决策时，工作流就会变差。
Spoonful 1: the problem was not using agents, it was losing continuity. In a long task, the cost of a pause is not only the time without an answer. The expensive part is losing continuity: what was being tested, what file changed, which hypothesis failed, which validation remained pending, and which context should no longer be dragged along. My first mistake was treating each model or agent as a symmetric second opinion. That does not scale. In a memo or a regulatory review, I ended up with useful comments that were hard to reconcile. The fix was more boring and more useful: separate roles. Not because it is the right way for everyone, but because in my workflow it lowers the cost of returning to a task without having to recap everything from scratch. 第一勺：问题不在于使用智能体，而在于失去了连续性。在长任务中，暂停的代价不仅仅是等待答案的时间。昂贵的部分在于失去了连续性：正在测试什么、哪个文件被修改了、哪个假设失败了、哪个验证仍未完成，以及哪些上下文不应再被拖累。我犯的第一个错误是将每个模型或智能体视为对称的“第二意见”。这无法扩展。在备忘录或监管审查中，我最终得到了有用的评论，但却难以调和。解决方法更枯燥但也更有用：分离角色。这并不是因为这是适合所有人的正确方式，而是因为在我的工作流中，它降低了重新开始任务的成本，无需从头开始回顾一切。
I read provider convergence from there. Codex documents configuration, sandboxing, permissions, MCP, AGENTS.md, skills, and subagents; GitHub Copilot supports repository instructions; Gemini Code Assist describes an agent mode with tools, MCP, and approval of changes; and Claude Code exposes hooks such as PreToolUse, PostToolUse, and SessionStart. 我从中看到了供应商的趋同。Codex 记录了配置、沙箱、权限、MCP、AGENTS.md、技能和子智能体；GitHub Copilot 支持仓库指令；Gemini Code Assist 描述了一种带有工具、MCP 和变更审批的智能体模式；而 Claude Code 则暴露了诸如 PreToolUse、PostToolUse 和 SessionStart 等钩子。
Table 2 — Current roles in penta-agent
表 2 — penta-agent 中的当前角色
| Component | Actual role | Limit I impose |
|---|---|---|
| 组件 | 实际角色 | 我施加的限制 |
| ChatGPT/Codex | Local technical orchestrator, planner, and executor | It should not self-validate as the only source of truth on critical changes |
| ChatGPT/Codex | 本地技术编排者、规划者和执行者 | 不应在关键变更上将其作为唯一的真理来源进行自我验证 |
| Claude | Reviewer, auditor, and co-planner | It should not take operational control by default |
| Claude | 审查者、审计员和共同规划者 | 默认情况下不应获取操作控制权 |
| Gemini/Antigravity | Explorer, validator, and fallback | It should not enter the critical path unless explicitly promoted |
| Gemini/Antigravity | 探索者、验证者和后备方案 | 除非明确提升权限，否则不应进入关键路径 |
| Copilot | Canary and IDE/GitHub-native support | It should not be treated as an independent architectural arbiter |
| Copilot | 金丝雀测试和 IDE/GitHub 原生支持 | 不应将其视为独立的架构仲裁者 |
| LiteLLM | sidecar Cheap, narrow delegation | I do not use it for architecture, security, or final decisions |
| LiteLLM | 边车（Sidecar），廉价、狭窄的委派 | 我不将其用于架构、安全或最终决策 |
| Human | Closure, privacy, and acceptance | Final judgment is not delegated when risk is involved |
| 人类 | 闭环、隐私和验收 | 涉及风险时，最终判断权不予委派 |
The local architecture makes that explicit. In routing.yaml, the penta_agent_ops rule keeps Codex as primary, Claude as reviewer, Gemini as validator/fallback, and the human as checkpoint.
本地架构明确了这一点。在 routing.yaml 中，penta_agent_ops 规则将 Codex 设为主要执行者，Claude 为审查者，Gemini 为验证者/后备方案，人类为检查点。
The key detail is mcp_policy.mode: conditional. Not everything goes through MCP. Not everything deserves a handoff. Not everything deserves a second provider. After some iterations, I made evaluation proactive, as with skills, but invocation still needs a signal. Early on, skills were not activated when I wanted them to be, and handoffs were scarce.
关键细节是 mcp_policy.mode: conditional。并非所有事情都通过 MCP。并非所有事情都值得移交。并非所有事情都值得引入第二个供应商。经过几次迭代，我使评估变得主动（就像技能一样），但调用仍然需要信号。早期，技能在我想要激活时并未激活，且移交也很少。
Spoonful 2: the repository as a work contract. The piece that helped me most was not a model. It was a startup rule: if a task touches multi-agent work, MCP, Claude, Gemini, Copilot, routing, handoffs, or penta-agent, first read the local canon. In my case, that canon lives in files such as: router/routing.yaml, shared-references/arquitectura-multiagente.md, playbooks/puente-mcp-codex.md, .mcp.json.
第二勺：将仓库作为工作契约。对我帮助最大的不是模型，而是一条启动规则：如果任务涉及多智能体工作、MCP、Claude、Gemini、Copilot、路由、移交或 penta-agent，首先阅读本地准则（canon）。在我的案例中，这些准则存在于诸如 router/routing.yaml、shared-references/arquitectura-multiagente.md、playbooks/puente-mcp-codex.md 和 .mcp.json 等文件中。
This prevents a common vice: generic probing of CLIs, models, and commands before understanding the project’s contract. For small things, it may not matter. For a regulatory review, a statistical run, or a local security change, it does. Drift burns tokens and sometimes leaves the task stranded in the wrong place. A useful AGENTS.md does not need to be a novel. Long instructions consume context. I think it should mostly prevent bad practices. 这防止了一个常见的恶习：在理解项目契约之前，对 CLI、模型和命令进行通用探测。对于小事，这可能无关紧要。但对于监管审查、统计运行或本地安全变更，这很重要。偏差会消耗 Token，有时还会让任务陷入错误的境地。一份有用的 AGENTS.md 不需要写成小说。长指令会消耗上下文。我认为它主要应该用于防止不良实践。