当 AI 助理开始＂分工协作＂,单一工具时代就结束了

我最近和一个AI助理”吵”了三次。 第一次让它查股票，它给了分析没给价格；第二次让它写代码，它写了代码没跑测试；第三次让它整理会议纪要，它整理得挺漂亮——但漏掉三个关键action item。 我逐渐意识到：AI更像一个”员工”，而员工要想干好活，需要的是协作，不是独斗。

痛点：单agent很多事都能干，但什么都不精

你一定遇到过这种情况：问 AI 一个问题，它答得头头是道，但仔细一看，要么缺关键数据，要么缺行动项，要么逻辑看似完整但经不起推敲。

这不是AI笨，而是它太”全才”了。

一个单agent系统，就像一个什么都会但什么都不精的员工。它可以写代码、查资料、整理想法，但它无法同时在多个维度上保持高水准。你让它查股票，它把精力花在”分析为什么涨”上，就忘了最基础的”当前价格”；你让它写代码，它写完功能就累了，没精力再跑一遍测试；你让它整理会议纪要，它语言组织得漂亮，但漏掉action item这种”脏活累活”。

问题的本质是：单一agent无法在复杂任务的不同阶段保持专业度。

就像一个创业公司，所有事一个人干，初期还能跑；一旦业务复杂起来，就必须分工。

方案：5+3 Agent 架构

我花了将近一个月的时间，重构自己的openclaw协作系统，最终形成了一套 5+3Agent架构。

5 个基础Agent

3 个开发Agent

这个架构的核心逻辑是：让专业的人干专业的事。

research专门负责”找信息”，它的prompt里没有”写东西”这回事；draft专门负责”写”，它的prompt里没有”查资料”这一项；ops专门负责”执行”，它的KPI里只有”做完没有”而不是”做得好不好看”。

单一agent需要在多个模式之间切换，每次切换都有认知开销和精度损失。多 agent架构则像流水线，每个环节只做一件事，做完就传给下一个。

核心：任务路由策略

架构搭好了，关键是怎么用。什么时候该走research路线？什么时候该走draft →review路线？什么时候该走ops路线？

决策规则

什么时候该走research路线？

• 任务需要外部信息（搜索、查文档、找数据）
• 任务需要结论 + 证据 + 不确定点
• 任务不是关于本地机器配置

什么时候该走draft→review路线？

• 任务是写东西（文章、报告、消息、提纲）
• 任务需要结构化输出
• 任务完成后需要质量检查

什么时候该走ops路线？

• 任务需要创建/修改文件
• 任务需要运行命令
• 任务需要本地安装/测试

什么时候该走coder→debugger→code-reviewer路线？

• 任务是开发一个可运行的工具
• 任务涉及代码编写、测试、审查完整流程

举两个例子

场景一：写一篇AI Agent的科普文章

main → research（调研Agent最佳实践）     → draft（基于调研结果写初稿）     → review（检查数据准确性）     → main（合成最终输出）CODE

如果缺少research环节，draft只能凭记忆写，容易出现”我记得某篇文章说……”这种模糊引用；如果缺少review环节，可能把过时信息当成最新实践。

场景二：开发一个股票查询工具

main → ops → coder（写代码）    → ops → debugger（报错调试）    → ops → code-reviewer（代码审查）    → main（交付工具）CODE

这里不需要research，不需要draft，甚至不需要review——因为工具本身可以通过测试来验证质量。ops负责调度coder开发功能，debugger负责修Bug，code-reviewer负责把控代码质量，最后main合成一个可交付的工具。

路由选对了，效率翻倍；路由选错了，绕路半天。

实战案例

案例一：股票查询工具

我自己需要一个小工具：输入股票代码，返回当前价格、涨跌幅、一句话点评。

单一agent的做法：

• 给一个prompt：”写一个查询股票价格的 Python 工具”
• agent写完代码，任务结束
• 但没测试、没打包、没考虑API限流

多agent协作的做法：

1. main分发任务：开发一个股票查询CLI工具，需要包含”价格查询 + 涨跌幅计算 + 一句话点评”三个功能
2. coder接收任务：写代码，实现股票查询功能。coder按照main的拆分，分别实现：价格API调用、涨跌幅计算逻辑、一句话点评生成模块
3. debugger接收代码：本地运行测试，发现”一句话点评”模块返回格式不统一（有时是纯文本，有时带emoji），统一修复为结构化输出格式；发现API 限流没有处理，加上重试机制
4. code-reviewer接收修复后的代码：检查代码风格、异常处理、资源释放，确保没有硬编码API Key外泄
5. main合成结果：一个可用的、经过测试的股票查询工具

最终交付的不只是一段代码，而是一个真正能用的工具。

这里的关键是：”一句话点评”作为独立需求，在coder阶段被拆分出来作为独立模块开发；在debugger阶段被专门测试并修复格式问题；在code-reviewer阶段被检查是否有prompt注入风险。整个流程确保了这个看似简单的”一句话”功能，也能达到可交付的质量标准。

这个案例让我意识到：开发任务天然适合多agent流程，因为开发本身就是”写→调→审”的循环。

案例二：AI 写代码不稀奇，稀奇的是把工具真的交付出来

我最近在用一个开源项目 cli-anything，它能把自然语言需求直接变成一个本地 CLI 工具。

比如一句：

帮我做一个一键截屏并上传到OSS的工具。

按理说，大模型走到这里，通常只能做到“给你一段代码”。但代码和工具之间，其实还差很远。

代码未必能跑。能跑，未必依赖齐全。依赖齐全，未必处理好了异常。都没问题，用户也未必知道怎么安装到系统里当成命令来用。

所以这个案例真正让我觉得有意思的，不是它会生成脚本，而是它背后那条多agent协作链：

• 一个agent负责写
• 一个agent负责本地调试
• 一个agent负责审查代码质量和风险
• 一个agent负责安装和接入系统环境

这时候你会发现，多agent不是为了把一件事“说得更复杂”，而是为了把一件事“做完整”。

很多AI产品演示，看起来都很惊艳；但一到真实使用，就会卡在调试、审查、安装这些脏活累活上。而这些环节，恰恰才是多agent最有价值的地方。

所以我现在越来越觉得：

单模型适合回答问题，多agent更适合交付结果

效果：系统 vs 单一工具

我做了几个月的对比测试，效果很明显：

数字不一定精确，但趋势是确定的：多agent系统在复杂任务上的优势，是结构性的，不是微调的。

单一agent不是不好，它是基础能力；但多agent是在基础能力之上加了一层组织能力。

就像一个人可以做完所有事，但一个团队可以做完更多事、更好地做事。

结尾：可扩展性

5+3 Agent 架构不是终点。

我现在已经在实验一些新的agent角色：比如scheduler（负责排程和提醒）、notifier（负责把结果推送到不同渠道）、memory（负责长期记忆和上下文管理）。

每一个新agent的加入，都是在为系统增加一种新能力。

回到开头的问题：为什么我的 AI 助理总是”差一点”？

因为它在用一个人的精力，干一个团队的活。

现在，我的AI助手是一个团队。团队之间有分工、有协作、有审查、有交付。这才是 AI 工具的正确打开方式。

单一工具时代结束了。协作时代开始了。