Agent编队:把 AI当团队带,不是当工具用

『帮我查下物流状态。』Agent想都没想，直接去算退款金额了。

这是2026年4月我碰到的真实情况。那个Agent挂了12个工具——查订单、查物流、算退款、生成工单、发通知。

塞一个2000字的prompt里，全堆在一个prompt里。

用户说查物流，Agent自己脑补了一条调用链：先查订单状态、发现已签收，觉得可能要退款，调退款接口，生成工单。

5步跑完，款都退完了才告诉你「物流已发出」。

😵Agent以为它在帮你。实际上它在跑自己的逻辑，工具一多谁先谁后它自己说了算。

我当时对着屏幕愣了好一会儿。

站在Agent的角度，它真没做错。它那2000字的prompt里，退款逻辑和查物流逻辑的权重一样高。

它只是挑了一条看起来最合理的路径。换谁不看场景都这么选。

就那一刻我意识到了一件事：单Agent不是调prompt能救的。这是架构问题。

💡组织方式错了，调prompt没用。一个人干全公司的活，不出问题才怪。

────────────────────────────────────────

我的组织：23个Agent，一支工程团队

后来我把整个系统拆成了23个Agent。

最开始只拆了5个，跑着跑着发现不够用，又加了3个，后来又陆陆续续塞了几个辅助角色进去。

最后一次对着列表数，12个是核心高频的，还有11个辅助。

拆完之后我才反应过来——这23个Agent的组织方式，跟我以前带团队时候的逻辑，基本是一模一样。

💡不是拆Agent，是建团队。每个角色有岗位、工位、SOP——跟管人一模一样。

▎ 身份：谁干什么，分工清楚

先是身份。架构设计Agent我叫它Architect，这家伙只看架构文档，代码它碰都不碰。

后端Agent叫Backend Dev，只管API和数据库那块儿，前端页面的事跟它没关系。

前端呢叫Frontend Dev，管页面和交互，数据库里存了啥它不管。

▎ 工作区：看不见别人的文件

然后是工作区。Architect的workspace里只有技术方案文档，Backend Dev的就只有API代码和数据库迁移脚本。

俩Agent互相看不见对方的文件，硬盘上物理隔离。

这会我学乖了——最开始没做隔离的时候，Architect偷偷摸摸去看Backend Dev的代码，Backend Dev反过来改Architect的文档，全乱套了。

▎ 规范：每个人都有一份SOP

最后是行为规范，这块最花时间。给Architect写了一份SOUL.md，身份、职责边界、输出格式全写在里面。

Backend Dev我也写了一份，直接写「你只写API逻辑，不设计页面」，明明白白。

每个Agent都有自己的一份规范，写不清楚它真的会偷懒乱搞。

你琢磨琢磨，平时带团队是不是也这套？岗位有职责、有工作台、有SOP。

你总不可能让一个开发又写前端又写后端还搞运维，那不乱成一锅粥了。Agent也是一样的。

📊这套系统最后跑起来：10套毕设Demo并行交付，55,000多行代码，364个文件。全程人类只做需求+验收。

────────────────────────────────────────

我的演进：从1人到23人

这条路不是一次就走通的，中间走了好几回弯路才慢慢摸清楚该怎么分。

▎ 阶段一：一个人干全部

一开始就是单人全能。一个Agent，一个很长的prompt，所有工具全挂上去。

能跑一阵子。但跑着跑着有两个问题越来越要命。

一个是tools加上history一多，token就超了，Agent自己都搞不清该调哪个工具。

二个是没有流程约束——一个问题触发五六次工具调用，中间哪个环节出问题了根本看不出来，debug都不知道从哪下手。

前面说的那个查物流变退款的，就是这个阶段出的洋相。

Agent有12个工具，它挑了一条它觉得最合理的路径，但那个「合理」是基于所有工具权重相等的前提。实际不是那么回事儿。

💡工具越多，Agent越「自信」地选错路径——12个工具在它眼里权重一样。

▎ 阶段二：加个前台分流

然后我就琢磨，能不能加一个前台？用户来了先过一下前台，判断归谁管——开发需求找开发组，客服需求找客服组。

就搞了一个Router Agent，这Router光分流，不下场干具体活。

这一步是个质变。每个专职Agent只干自己那一类事，prompt从2000字缩到500来字，工具从12个减到3到5个。

出问题也好定位了，一眼能看出来哪个Agent的环节出的事。

但新问题又来了。Router和专职Agent之间走的是同步调用，一个干完下一个才能上。

后端Agent在改API文档，Router就得等着，其他Agent全堵在后面动不了。

你要带过团队你肯定懂这种感觉——每个人干活都要等你当面安排，安排完一个才能安排下一个，串行嘛，效率不是低，是根本没法接受。

💡同步调用=一个人卡了，整条线停工。必须得改成异步。

▎ 阶段三：共享工作区，不等了

后面我就彻底把架构改了，搞共享工作区。每个Agent干完自己的活，往共享盘扔一份结果，下一个Agent自己来拿，不用等谁安排。

需求来了，Architect先出技术方案，写完就扔共享盘上，不管别人。

Backend Dev自己翻去看，写完API也扔上去。

Frontend Dev自己去取，写完页面再扔回去。

中间没人盯着传话，信息它自己流转，哪个环节慢了也不卡其他的。

────────────────────────────────────────

我的流程：七关交付流水线

光有组织结构还不行，还得有一套交付标准，不然Agent之间照样乱。

我设计了一套七关流水线。每个项目必须从头到尾走完这7关，哪关过不去就哪关打回去重来：

7关后面再加一关：人类CEO验收。全流程走完才能交付。

这7关不是硬串的。Architect出方案的同时，Backend Dev可以先写通用接口。

前端等API文档出来就开工，不用等代码全写完。

QA Agent是全程挂着的，代码提交就自动跑用例，P0/P1没清零不许进下一关。

我跑了几轮才觉出来，这套流程跟正经软件工程的项目管理逻辑是通的。区别就一个：以前人跑，现在Agent跑。。

────────────────────────────────────────

走一遍：一个需求怎么在团队里流转

拿一个真实项目走一遍你们就明白了。需求：开发一个漏洞监测平台。

CEO Bot先接需求。判断这是开发需求，拆成5个子任务：架构设计、后端API开发、前端页面、测试、部署。输出一张任务清单。

PM Agent拿到清单做能力匹配。架构设计指派给Arch Agent，后端API指派给BE Agent，前端页面给FE Agent，测试给QA Agent，部署给OPS Agent。

匹配完生成一张任务分配表，谁负责什么明明白白。

然后三条线同时开工。Arch Agent出技术方案，BE Agent写API框架，FE Agent画页面骨架。各干各的，谁不等谁。

💡这三步以前我得分头盯。现在它们自己跑，我喝茶等着就行。

QA Agent是全程挂着的。哪个Agent提交了代码，测试Agent自动跑用例。

漏洞扫描这块以前纯手动搞，现在Agent自己跑——发现毛病直接打回对应的Agent，改完重跑，P0/P1不清零不给过。

测试全过了，OPS Agent在干净环境里部署，Docker化打包，验证能跑。

CEO最后看一眼效果，没问题，交付。

这条链路跑通之后说实话，最大变化不是省时间。

是你不用盯了。以前做项目，我老得在中间每一步确认——做完了吗？

做对了吗？下一步能开始了吗？现在真不用了。

Agent自己走，我在开头说需求和结尾验收，中间爱咋跑咋跑。

────────────────────────────────────────

我的经验：23个Agent教我的事

搭这套东西的过程中碰到了不少问题，拣几个印象深的说说。

▎ 一：prompt别塞太多

别把所有逻辑往一个prompt里塞。这是最心疼的一条。单Agent那会儿prompt越长，Agent越会自己「脑补」。

它一看12个工具权重都差不多，就自己决定调用顺序了——这个顺序跟你想要的那个，八竿子打不着。

后来拆完，每个Agent的prompt就500字以内，工具3到5个。

一个Agent就管自己那一摊事儿，prompt里也不用整一堆if-else——什么「当用户说A的时候做X，当用户说B的时候做Y」。

出了问题也知道找谁，不用在2000字的prompt里排查来排查去。

💡prompt越短，Agent越听话。塞得越多，它给你脑补得越欢。

▎ 二：格式要统一

Agent之间说话格式得统一，这个问题也卡了我好久。

一开始没规定Agent之间怎么传信息，结果发什么的都有。

有的写「用户需要XX」，有的写「请完成XX任务」，下一个Agent收到信息还得先猜格式。

猜错了？整条链路直接跑歪，你还不知道歪在哪一步。

✅任务描述用JSON —— 结构化，不会歧义

✅输出文档用Markdown —— 人类和Agent都能读

✅状态标记用TODO/DOING/DONE —— 追踪进度方便

定了这三条以后，Agent之间的信息传递再没出过问题。

以前格式不统一那会儿，它们传信息跟猜谜似的。

当初为了这个事我debug了很多次。

💡格式不统一 = Agent之间传话是猜谜。JSON + Markdown + 状态标记，三条顶够。

▎ 三：共享盘还是转发？

还有个事儿就是共享工作区和消息转发我纠结了好久。

消息转发的问题在于中间环节一出事，后面全堵死。

跟团队里所有信息靠一个人转达似的，这人一卡壳，全组跟着停。

后来我选了共享工作区，每个Agent干完活直接往共享盘写结果，下一个Agent自己来拿。

就和公司共享盘一个意思——你写完文档往那一放，别人自己去看，不用你盯着挨个传。中间谁慢了，不影响别人干活。

▎ 四：测试别放最后

还有测试别放最后，血的教训。你看一开始我的测试就是最后一关。

功能全开发完了，跑测试，发现问题再回去改。

代价高得要命。一个bug在开发阶段改和在上线前改，成本差十几倍往上。

后来我让QA Agent全程挂着，代码一提交自动跑用例，P0/P1立刻打回去，改完再跑。

不会攒到最后才发现一堆烂摊子。

💡测试放最后 = 上线前才发现一堆烂摊子。全程介入，边写边测。

────────────────────────────────────────

现在这套系统跑起来了，人类管两头——需求对接、最终验收。

中间的架构设计、开发、测试、部署，全是Agent自己流转。

搭的过程中是真碰到了不少坎，但这些坎迈过去，整个团队才算立住了。