现在比较合理的agent分工应该怎么设置

回复 群友 1942： 现在最合理的 Agent 分工原则是：抛弃模仿人类职位的“职能分工”（比如别搞什么产品、前端、后端、测试四个 Agent 开会），改成按上下文边界、权限隔离和算力成本来切分。 目前工程上最实用、最不容易翻车的分工架构主要有三种： 1. 主控编排 + 沙盒侦察工（Orchestrator + Explorer Sub-agents） 这是按“上下文污染度”来分工，也是目前主流 ca（比如 Claude Code）最核心的模式。 怎么分：一个高智商、长上下文的主 Agent 负责全局规划和最终改代码；配几个只读权限、便宜快速的轻量级子 Agent 专门干脏活（比如全库搜索某个函数的引用、翻几千行报错日志、抓网页正文）。 为什么要这么分：如果让主 Agent 自己去翻十几个文件，庞大的无关内容会把它的上下文窗口塞满，导致后面的推理降智。让子 Agent 在独立的上下文里把几万字消化掉，最后只向主 Agent 汇报 200 字的精确结论（比如“Bug 在 A 文件第 50 行，原因是空指针”），主 Agent 的脑子始终是清醒的。 2. 执行者 + 挂着确定性 Hook 的独立审查者（Maker + Checker） 这是按“权限与立场对立”来分工，用来解决 Agent 自己写代码自己夸、偷懒跳过测试的问题。 怎么分： 执行者（Maker）：有读写权限，目标只有一个，就是把功能写出来。 强校验层（Hook）：在 Maker 准备提交时，用确定性的后置 Hook 自动跑通编译、Lint 和单测，不靠模型自觉。 审查者（Checker / Reviewer）：完全独立的上下文，只有只读权限。它看不到 Maker 写代码时的纠结过程（防止被带偏），只拿群友 8334的需求文档和最终的 Git Diff，专门挑刺（查安全漏洞、越权风险、边界条件）。挑出毛病打回给 Maker 重改。 3. 按“模块/文件锁”切分的并行工人（Map-Reduce Workers） 这是按“物理隔离边界”来分工，适合大规模批处理。 怎么分：比如要把项目里 50 个旧接口迁移到新规范。主 Agent 先把公共的类型定义改好，然后同时拉起 10 个平级的 Worker Agent，每个 Worker 只分到 5 个互不重叠的文件路径。 关键机制：绝对不要让并行 Agent 共享状态或互相聊天。用 Git Worktree 或严格的文件锁把它们物理隔开，各自在独立沙盒里改完、跑通各自的单测，最后由主控统一合并。 总结一套直接能用的配置口诀： 第一，能一个 Agent 干完的绝不拆成两个，优先靠给单 Agent 配好工具和后置 Hook 解决问题。 第二，只有遇到这三种情况才拆新 Agent：需要吞吐大量脏数据怕污染主上下文（拆侦察工）、需要独立视角做对抗性审查（拆 Reviewer）、任务能完全解耦并行加速（拆独立 Worker）。 第三，Agent 之间的交接全部走精简的结构化结果，不传长篇过程废话。