给 AI 排班：别让一个 Agent 把活全干了
你大概也干过这种事：让一个 AI 同时改代码、写测试、查安全漏洞。结果它改到一半忘了测试要改什么，查漏洞时又把刚改好的代码覆盖掉。不是模型不够聪明，是你把三个人的活派给了一个人。
米其林后厨从来不指望一个大厨同时盯十个灶台。后厨真正的秘密是编制：主厨拆解菜单、只负责指挥和把关，酱汁、冷菜、甜品各有专人，每道菜出餐前还有一道验菜关。多 Agent 协作做的就是这件事——把"一个全能员工"换成"一支有编制的团队"。
我把 DeepSeek Harness（DSH）里多 Agent 协作那一套完整学了一遍，从 4 个派活工具到 1 个团队插件，顺手把"什么时候不该用"也查了个底朝天。按"怎么拆、怎么派、怎么管、何时收手"的顺序整理给你。
派活的四把刀
DSH 内置 4 个派活工具，区别全在"交接协议"上：
| 工具 | 干什么 | 什么时候用 |
|---|---|---|
| subagent | 开一个上下文全新的子 Agent | 独立小任务 |
| subagent_fork | 子 Agent 带走父会话历史 | 子任务需要前文背景 |
| workflow | 脚本编排，多任务并行 | 一次拆多路 |
| ralph | 每轮换全新 Agent 推进同一目标 | 长任务反复迭代 |
subagent 最简单：子 Agent 看不到父会话的任何历史，适合和主线无关的独立工作，干完把结果送回来。需要它带着前文干活，就换 subagent_fork——比如让它基于上一份审查报告接着写总结，不用重新贴一遍报告。
workflow 是并行形态：一段脚本里定义多个任务同时跑，全部返回后再交给下一个 Agent 汇总。变更总结、风险检查、测试清单三路并进，最后合成一份发布前清单，就是这个打法。
最特别的是 ralph。它面向一个不可变的目标，每一轮都换一个全新的 Agent 上场——不继承对话历史，只靠一份结构化交接报告传递进展，工作区文件就是长期记忆。官方给它的定位是"目标稳定、需要反复试错的长任务"。它治的病是 AI 干久了钻牛角尖：换个人从新角度看问题，第二轮就能修正第一轮的优先级误判、合并重复项、补上遗漏，干完直接判定收工。
派出去还得管得住。配套 3 个管理工具：list_agents 看谁在干活、send_message 随时补充新要求、interrupt_agent 打断当前这轮任务。注意最后一个只是打断本轮——Agent 本体还在，排队的消息也不会丢。
编制的完全体：Agent Teams
手动派两三个 Agent 够用了。但任务一多——谁负责什么、哪些有依赖、执行到哪一步——光靠脑子记就开始吃力。
社区插件 Agent Teams 给出完全体形态：当前会话自动升任 Captain 队长，负责拆任务、分工、汇总；成员 Agent 各管一个方向，任务带依赖关系，Web 界面里有一块实时活动面板能看到谁在跑。装插件只要一条命令：
dsh plugin --profile web add @nanmicoder/dsh-agent-teams@latest
典型打法：检查一个前端项目，拉三个成员——前端 Agent 查页面结构和交互，代码质量 Agent 查依赖和可维护性，安全 Agent 查敏感信息泄露。三路并行，各自完成后回传 Captain 出总报告。
更值钱的是团队可复用。第一轮跑完，追问一个 WebGL 降级问题并指定交给前端成员——活动面板里只有它重新上线，另外两个不挨调度。这就是 Agent Teams 和临时派子 Agent 的本质区别：它不只是派活，还管成员、依赖、调度、持久化状态。
限制也摆在明面上：一个 Captain 同时只带一个活跃团队；团队状态存在当前工作区，不跨设备同步；多个进程同时操作一个团队会打架。另外它是社区开发者 NanmiCoder 维护的插件，不是官方组件——往生产里放之前，把这个因素算进去。
代价清醒：人多的事故率
写这部分之前，我专门去翻了学术圈的数据，先泼盆冷水。
NeurIPS 2025 的 MAST 分类学研究给过多 Agent 系统的生产失败率区间：41% 到 86.7%。更扎眼的是故障归因——79% 的故障源于规格歧义和协调崩溃，不是模型蠢，是活没交代清楚。
Galileo 测过协调复杂度：4 个 Agent 有 6 个潜在故障点，10 个 Agent 是 45 个。故障点不按人数线性涨，按组合数涨。
成本端更狠：有研究统计 AI Agent 的 token 消耗是普通聊天的千倍量级，同一任务的 token 用量能差 30 倍——而多 Agent 并行就是把这条曲线再乘个 N。Reddit 上那句"光协调开销就让账单翻了三倍"不是段子；从业者更直接的吐槽是"到第 4 个 Agent 时基本在编造信息"。谷歌研究者干脆写了篇文章，标题就叫 Multi-Agent is not all you need。
这些数字不是判死刑，而是划重点：多 Agent 不是"人多力量大"，是拿协调成本换执行吞吐。交接协议糊弄（活没拆清、上下文没给够），烧出去的钱买到的是事故。ralph 靠结构化交接报告、Agent Teams 靠任务依赖——这些设计之所以存在，就是在给 79% 的那类故障打补丁。
判断：什么时候该排班
该用：任务天然需要不同专长；单 Agent 上下文装不下；流程有清晰的阶段边界。
不该用：一个 Agent 能搞定（别为了架构图好看硬拆）；任务高度耦合拆不开；没人盯协调异常；token 预算紧。
DSH 官方文档那张选型表其实就是最好的口诀：一两件独立小事，普通 subagent；一次多路拆分，workflow；一个稳定目标反复换人推进，ralph；只有长期推进、成员反复协作、要管依赖看状态，才值得上 Agent Teams。
一句话收尾：AI 团队的战斗力，不取决于你雇了几个 Agent，取决于你有没有把活讲清楚、把班排明白。编制先于人数，协议先于智能。
相关链接：
- DSH 官方文档（Workflow 与 Ralph）：https://deepseekdocs.com/en/docs/features/workflow
- Agent Teams 插件开源仓库：https://github.com/NanmiCoder/dsh-agent-teams
- 鱼皮的开源 AI 编程教程：https://github.com/liyupi/ai-guide
暂无评论。