第 16 期：Q&A (一) 多 Agent 架构与任务分配

⏱ 预计阅读 8 分钟 更新于 2026/5/7
💡 进群学习加 wx: agentupdate
(申请发送: agentupdate)

本期场景：本期重点解答开发者在尝试从“单打独斗”的单 Agent 模式升级到多 Agent 架构时，最常遇到的任务调度、并发冲突和性能瓶颈问题。

Q1：路由分发机制 (Routing Mechanism)

问：Router Agent（即 Team Lead）是如何决定把任务分发给哪个 Sub-Agent 的？如果分发错了该如何回退？

答：Team Lead 依赖于项目初始化时你在 TeamCreate 或 CLAUDE.md 中定义的角色描述 (Role Description)。

当接收到任务时，Team Lead 会通过语义匹配职责。例如，如果 ui-dev 的描述是 "专注 React 组件和 CSS"，而新任务是 "修复计算器的溢出 Bug"，Lead 会更倾向于将任务分配给 logic-dev。

如果分发错了（例如前端 Agent 去改后端库）： 你不需要杀掉整个进程。由于各个 Agent 有独立的 Inbox，Team Lead 可以随时调用 SendMessage 发送一条强制中断指令："停止当前操作，该任务已转交给 backend-dev。清空你所做的修改 (git checkout) 并退出"。

Q2：【Mermaid 泳道图】并发写冲突 (File Conflict Resolution)

问：当两个并行执行的 Sub-Agent 同时尝试修改同一个文件（例如 Calculator.ts）时，系统底层是如何处理的？

答：Claude Code Teams 没有内置神奇的实时协同编辑（OT/CRDT）机制，而是完全依赖于 OS 级文件锁 和 Git 冲突合并。真实的底层处理流程如下：

sequenceDiagram
    participant Lead as Team Lead
    participant A1 as Agent 1 (UI)
    participant A2 as Agent 2 (Logic)
    participant FS as 本地文件系统
    
    Lead->>A1: 任务: 修改 Calculator.ts 界面
    Lead->>A2: 任务: 修改 Calculator.ts 算法
    
    A1->>FS: 读取 Calculator.ts (版本 v1)
    A2->>FS: 读取 Calculator.ts (版本 v1)
    
    A1->>FS: 写入界面修改 (成功, 变为 v2)
    A2->>FS: 尝试写入算法修改...
    
    rect rgb(254, 252, 232)
        Note over A2, FS: 检测到文件在读取后被外部修改!
        FS-->>A2: 抛出 FileModifiedError 拦截修改
    end
    
    A2->>A2: 重新读取最新文件 (版本 v2)
    A2->>FS: 基于 v2 重新应用算法修改 (成功, 变为 v3)

防坑指南：虽然底层会自动重试（如上述时序图），但高频并发修改同一文件极易造成逻辑覆盖。最佳实践是：永远在路由阶段进行文件隔离分配，或者利用 TaskUpdate(blockedBy) 强制它们串行操作。

Q3：并行性能瓶颈 (Parallel Bottlenecks)

问：为什么我开启了并行 Teams 模式，项目重构的速度反而比串行（单 Agent）更慢了？

答：通常是因为触碰了大模型的 Token 并发限制或工具读写锁竞争。

  1. API 并发限流（429 报错）：如果 4 个 Agent 同时发起请求，极易触发 Anthropic/Gemini 的每分钟并发数（RPM）或 Token 数（TPM）上限，导致所有 Agent 陷入长达几十秒的指数退避（Exponential Backoff）等待中。
  2. 锁争用：如果多个 Agent 同时高频执行 git status、npm install 或是写入不同的日志文件，底层系统的锁竞争会导致大量 I/O 等待。

解决方案：不要为了并行而并行。控制活跃的 Sub-Agent 数量在 2-3 个以内，并且尽量分配CPU 密集型（如静态分析代码）或网络请求独立的任务去并行。

Q4：基于角色的架构 (Role-based Architecture)

问：能否硬性规定一个 Agent 只负责写前端，另一个只负责后端，第三个专职写测试？应如何配置？

答：可以，而且这是最高效的架构。关键在于结合 Prompt 注入和工作区挂载：

  1. 在 TeamCreate 时，为 frontend-dev 注入提示词："你只能读取和修改 src/components 和 src/pages 目录。如果任务涉及后端，立即退回任务"。
  2. 为 tester 注入规则："你只能在 tests/ 目录下创建文件，且只能执行 npm test，禁止修改 src/ 下的核心业务代码"。

Q5：宪法 Token 优化 (Optimizing CLAUDE.md)

问：CLAUDE.md 中的系统规则太长，导致每个 Sub-Agent 每次对话都消耗大量 Token，如何进行指令折叠与优化？

答：在 Teams 模式下，冗长的 CLAUDE.md 会导致 Token 成本翻倍膨胀，因为每个独立 Agent 进程在每次 API 请求时都会携带它。

优化策略：使用渐进式规则树而非平铺式文档。 不要把所有规则写死在 CLAUDE.md 里。将其瘦身到只有两句话：

"1. 本项目采用 React+Node 栈。 2. 根据你的角色，请首先读取 .agent/rules/frontend.md 或 .agent/rules/backend.md 获取详细规则。"

这样，只有前端 Agent 才会去读取并加载前端的详细规则集，极大降低了初始 Token 开销。

Q6：进程生命周期 (Process Lifecycle)

问：如果我通过 Ctrl+C 强行停止了主控 Agent，那些还在后台运行的 Sub-Agents 会发生什么？会产生孤儿进程吗？

答：默认情况下，会产生孤儿进程。

因为 Claude Code 的每个 Sub-Agent 是在独立的 Tmux 会话（Tmux Sessions）中派生（Spawned）的。当你杀掉主控 Agent（Team Lead）时，它可能来不及向所有的 tmux sessions 发送终止信号。

清理方案： 执行 tmux list-sessions 查看残留的 Agent。然后运行团队销毁工具 TeamDelete，或者直接粗暴清理： tmux kill-server（注意这会杀掉你电脑上所有的 tmux 会话）。

Q7：上下文共享 (Context Sharing)

问：在 Teams 模式下，不同 Agent 之间能共享内存缓存或 ChromaDB 的历史向量上下文吗？

答：默认隔离，但可通过插件桥接。

在内存级别，Agent 是完全隔离的独立 Node.js 进程。ui-dev 不知道 logic-dev 刚刚向大模型发了什么 Prompt。

但是，如果项目中集成了类似 claude-mem 这样的持久化记忆插件，所有的 Agent 在触发 PostToolUse 钩子时，都会把操作摘要写进同一个本地的 SQLite/ChromaDB 库。当 Team Lead 需要汇总进度时，它就可以通过 search() 查看到所有并行 Agent 的集体记忆，这实际上形成了一个基于数据库的**“中央黑板 (Blackboard Pattern)”**。