企业官网建设流程全解析

1. 先复盘：我是怎么把效率改慢的

这是多Agent实战记录的第二篇。上一篇好不容易把基础编排架子搭起来，流程能跑通，我当时还挺得意。结果真往里面加Agent的时候，效率非但没起来，反而肉眼可见地变慢。同样的任务，之前一个Agent串行跑大概30分钟；我调成多个Agent并行，想的是“五个环节一起干活那不是快五倍吗”，实测将近一小时才出结果。这篇文章就把这段踩坑经历掰开揉碎讲清楚：为什么加了更多Agent，工作效率反而快不起来。

先说结论：加Agent不等于加生产力。在很多任务里，Agent每多一个，通信、上下文、验证这三类成本都会跟着涨，涨到一定程度，收益就被成本吃光了。更麻烦的是，这些成本大多数不会直接出现在任务耗时里，藏得很深，等你看出来的时候往往已经浪费了大半天。

当时的场景是一个内容整理加分发的Demo（某跨平台内容整理系统）。流程拆成：资料搜集、主题提炼、正文初稿、摘要生成、关键词标注、质量检查。最初是一个Agent按顺序从头做到尾；我嫌慢，改成能并行的环节同时跑。结果总耗时从差不多40分钟涨到了近70分钟，第一反应是底层模型变慢了，翻日志查了半天，问题其实出在编排方式上，模型推理根本背不了这个锅。

那次复盘让我意识到一个很容易被忽略的事实：所谓“并行加速”，前提是任务之间真的没有强耦合，而且结果的合并成本要足够低。我这批任务恰好两头都不沾——子任务之间既有依赖，合并的时候还得额外做一轮一致性检查。这两部分成本，在“加Agent能提速”的直觉里，完全没被算进去。

1.1 直觉错在哪

人的直觉很朴素：工作分给N个人，每人干1/N，总工时变成1/N。这句话成立的条件是，工作可以被无损耗地切分，切完之后不需要额外沟通，也不需要有人统一整合。现实里几乎不存在这种任务——哪怕是把一篇长文切成几段让不同人写，最后也要有人统一文风、核对衔接、补上过渡。这部分整合消耗的时间，在初始的“分配”模型里根本看不见。

类比一下就很好懂：编辑部来了十个编辑，一篇文章按段落分出去。最快的那个早就写完了，卡壳的还在中间；写完的段落还得有人审、有人改、有人拼接。折腾一圈，很可能比一个老编辑从头写到尾还慢。Agent系统也一样，数量上去以后，瓶颈往往从“干活”转移到“协调”。我当时没有意识到这点，一头把Agent堆上去，结果就是局部快、整体慢。

1.2 慢的不只是模型，还有协调

还有一种“慢”是看日志才发现的：单个Agent的模型调用耗时其实没怎么变，但Agent之间的等待时间长得离谱。有的Agent早就完成任务，却要等着别的Agent把中间结果送过来；有的Agent把同样的原始资料从头读了一遍又一遍，只是为了拿到里面一小段关键信息。这些等待和重复读取，全被排进了总耗时里。

所以后半篇文章要做的，就是把这笔“协调账”一笔笔拆开。

2. 喊破喉咙也没用：五个真正吃掉性能的黑洞

下面这五个坑，是我在多个实际场景里反复踩过的，也是“加Agent反而变慢”最常见的五个根源。如果你想排查自己的多Agent系统，拿这五点对号入座就行。

2.1 通信成本随Agent数量指数膨胀

Agent之间如果要两两同步消息，需要维护的通信关系数量是 n(n−1)/2。3个Agent，3对关系；6个Agent，直接变15对。Agent数量翻倍，通信开销差不多翻了四倍还不止。这是数学上绕不开的，跟具体用什么框架没关系。

在真实系统里，每条通信消息都有内容，都要消耗输入token，都要等模型处理完才能继续。Agent越多，系统用来“聊天”的时间就越长，真正拿来“干活”的时间反而变少。我后来在编排层加了一轮日志打点，发现改版后的架构里，Agent之间同步消息消耗掉的token占了总消耗的六成。那个数字把我吓到了——大部分成本其实花在了互相说话上。

实操中能不两两交换就尽量不要两两交换。我把全链接式的同步改成“结果写进公共状态、需要的人主动取”之后，通信量下降非常明显。

2.2 上下文窗口被“聊爆”了

第二个坑更隐蔽：每个Agent都会带上一大段公共上下文，里面有任务说明、历史对话、其他Agent的中间结果。模型对上下文长度是有限制的，塞进去的内容也不是无限期保留。消息一多，早期写下的关键约束很容易被后面的长对话挤掉，Agent就会照着变形的信息往下走。

我碰到过一个典型事故：主控Agent在任务说明里写了“不要改动公共模块X”，跑了几个来回之后，下游一个Agent完全无视了这条约束，直接对公共模块下了手。查日志发现，这条约束确实在早期上下文里出现过，只是被中间大量无关的讨论记录淹没掉了。

解决办法就一条：把共享上下文打薄。公共消息尽量精简成结构化状态，而不是把整段历史一股脑塞给每个Agent。讨论过程保留在主控日志里就够了，下游Agent只需要拿到“结论+必要约束”，不需要看全过程。

2.3 串行依赖，并行救不了

硬件性能优化里有个经典结论：系统整体加速的上限，取决于任务里不可并行部分占的比重。如果一个任务中间有一段必须串行——比如A产出的东西B才能用，那就算其他部分拆成100个Agent并行，整体耗时也被这段拉死。

实操里串行依赖比想象的普遍得多。我那套内容系统就是个例子：主题提炼必须先做完，摘要、关键词、正文才有依据。这几个环节表面看起来是能并行的，但它们吃的都是同一个上游结果，真正跑起来的时候，大部分时间花在等待上游出结果上，Agent全在空转。

所以判断能不能并行，不能只看环节名称，要看数据依赖。谁依赖谁，谁就在逻辑上排队，排队的环节不管加多少Agent都偷不了时间。

2.4 分工不清导致返工，返工比慢慢做还贵

多Agent系统里，角色边界不清晰是最容易翻车的事。我在代码重构的场景踩过一次：一个Agent负责模块A的重构，另一个Agent负责全局依赖梳理，两个Agent都发现要动同一个公共函数，各自改完，冲突了，最后把所有改动回滚，让其中一个Agent从头再做一遍。

返工的代价不是简简单单“再做一遍”：它需要回退、需要重新验证、需要额外消耗模型调用和token。一次冲突造成的返工，成本可能顶得上正常做三遍。所以分工边界一定要定得比“听起来合理”更严格，最好细到文件级、函数级，让每个Agent只能动自己那一亩三分地。

2.5 验证与纠错成本被严重低估

Agent越多，产出的可信度就越需要单独验证。以前一个Agent从头生成一篇文章，结尾检查一次格式就行；现在是五六个Agent各自输出，总得确认它们之间的结论一致不一致、有没有互相矛盾的内容。单独看每个Agent的检查都不贵，加在一起非常惊人。

更麻烦的是错误传播：上游Agent把输出当成“事实”传给下游，下游Agent不会质疑，只会在此基础上继续发挥。一旦上游错，下游会错得更彻底，等人工发现问题的时候，返工范围已经非常大了。我后来立了一条规矩：凡是下游要依赖的上游结论，先走一道独立校验，再进下一环。多一步看起来啰嗦，实际上省掉的返工远大于校验成本。

3. 实测现场：三种配置的耗时差在哪

理论说一堆，不如直接看数据。我把同一个任务（把一份原始资料变成一篇带标题、摘要、关键词的文章）用三种方式各跑了好几轮，取稳定值做了个对比。

3.1 纯串行怎么跑

整个流程按顺序执行：资料搜集 → 主题提炼 → 写正文 → 写摘要 → 标关键词 → 质量检查。一个Agent干完传给下一个，逻辑最简单，几乎没有沟通损耗。缺点也很明显：总时间等于所有环节耗时相加，任何一个环节卡壳，后面全部等着。这套跑下来差不多30分钟，作为基准线。

3.2 无脑全并行怎么跑

我把搜集、主题、正文、摘要、关键词、质检六个Agent全部放开，让系统“尽量并行”。第一次跑完我愣了半天，耗时不仅没降，反而直接涨到50多分钟。拆开看原因，非常清楚：

• 每个Agent都拿到同一份原始资料，六个Agent同时读全文，数据量直接乘了六倍，token开销暴涨，模型处理变慢。
• 摘要和关键词本来依赖正文，全并行配置里它们只能空转，或者先读一份还没定稿的中间版本，等正文出来后再补一轮修正。
• 六个并行跑完，还需要额外的合并步骤把所有结论整合成一个最终版本，合并本身又是时间和模型成本。

这就是最典型的“看着能并行、其实并不了”的错配。

3.3 两阶段并行怎么跑

这是踩完坑之后重新设计的方案。阶段一先串行跑：资料搜集 + 主题提炼，产出统一的精简任务包。阶段二再把正文、摘要、关键词、质检并行放开；摘要和关键词不再去读正文全文，而是依赖任务包里一个“内容骨架+关键片段”的中间产物。最后主控做一次轻量合并，把四个产出拼成最终文章。

这个流程跑下来稳定在19分钟左右，比纯串行快了三分之一还多，比无脑全并行快了将近一半。最关键的是，它没有靠增加Agent数量，而是靠理清了依赖关系。谁和谁真正互不依赖，谁才该并行，全并行和两阶段并行的区别全在这。

4. 效率排查清单：用数据代替感觉

如果你的多Agent系统也出现“越加越慢”的情况，别急着猜，先拿数据定位。下面是我常用的排查顺序和检查项。

4.1 先打点，再谈优化

第一件事一定是在编排层加日志和统计：每个Agent的开始时间、结束时间、输入token量、输出token量、等待时间、重跑次数。没有这些数据，后面所有讨论都是感觉。看日志的时候尤其重点看等待时间——如果某个Agent早早结束，却花费大量时间等别的Agent响应，问题多半出在编排或资源锁上，而不是模型本身。

4.2 画任务依赖图

把任务拆成节点，把“谁需要谁的输出”画成连线。有依赖关系的节点不要安排在同一层并行；没有连线的节点才是能并行的候选。画完你大概率会发现一件事：很多看起来独立的子任务，其实共享同一个上游，本质上还是在排队。这时候与其加Agent，不如优化上游的产出速度，或者把上游结果缓存起来，让各下游直接打缓存。

我自己的习惯是：先跑通单向流程，再挑候选环节做并行。一次只改一个变量，数据变化才说得清理由。

4.3 做一次“最少Agent实验”

这是我最推荐的做法：从1个Agent开始，跑同一个标准任务，记录总耗时；然后逐步加到2个、3个、4个，每次只加一个。最后把耗时画成一条曲线，基本能看到“先下降、后回升”的拐点。拐点之前的收益是真实的，拐点之后就是在为通信成本买单。

按我的经验，大多数任务在2到4个Agent之间就已经覆盖了主要分工，超过这个数之后，收益通常是负的。如果你的实验结果真的显示“5个比3个强很多”，那是任务本身可拆分性极强，值得深挖；但别忘了把最终合并成本也算进去，有些收益会在合并那一步吐回去。

4.4 检查上下文是不是在“重复造轮子”

重点看日志里每个Agent收到的公共上下文有多大。如果每个Agent都把原始资料完整带一份，但它们实际需要的只是其中30%，那就该改：主控先对资料做一轮预处理，输出精简任务包，再把任务包发给各个Agent。聊天记录的长度也要控制，该截断就截断，该转成结构化数据就转。

一个经常被忽略的细节是：不要把所有历史消息都塞给下游Agent。它们只需要“结论+必要约束”，不需要围观讨论全过程。讨论记录留在主控日志里供人工排查，比挤占下游Agent的上下文更有价值。

4.5 关注接口限流和排队

Agent数量涨上去之后，模型接口的并发调用量也会同步涨。很多接口都有速率限制，并发一多就开始排队，排队等待的时间可能比并行省下来的时间还长。如果耗时曲线在Agent数增加后出现一整段平直的等待区，多半就是被限流了，这时候要降并发或错峰，而不是继续加Agent。

注意：加Agent之前，先确认资源侧没有被提前打满。我之前排查过一轮“变慢”问题，查了半天发现是并发请求被接口排队了，把并发数从8降到4，总耗时反而掉了20%。方向搞反的话，越调越折腾。

5. 什么时候加Agent是真正有用的

说了这么多坑，并不是要全盘否定多Agent。有些场景加Agent的收益非常明显，但通常得满足下面几个条件。

5.1 三个前提条件

第一，子任务之间没有强依赖，结果能自动合并，而且合并成本要低。典型例子是批量处理多篇独立文档、为多个独立模块分别跑测试、对多个不相关的资料主题做并行检索。

第二，单个子任务的耗时本身要足够长，长到并行收益能盖过通信成本。如果每个子任务两秒就干完了，Agent之间消息传递的时间比干活时间还长，这种场景就别并行。

第三，要有明确的主控，Agent的角色是执行者而不是决策者。决策集中、执行分散，系统出问题的概率和协调成本都会低很多。

5.2 不适合并行的场景

反过来，如果一个任务的核心是一条深度推理链，比如从需求分析一路到架构设计再到代码实现，这类任务往往串行的单Agent或两三个Agent链式协作更稳、更快。强行拆分成并行，等于把完整的推理链路切成几段，每一段Agent都看不到全局，最终合并出来的方案大概率是散的。

我写过一段代码生成的需求尝试过：前期的需求理解、技术选型、代码骨架设计全部分给不同Agent并行，结果每个Agent自我感觉良好，拼到一起连接口都对接不上。后来回到“一个Agent全链路思考，两个Agent分别做复查和测试”的结构，产出质量和速度反而都正常了。

5.3 我的选择标准

现在我的选择标准很简单：先在纸面上画依赖图，如果能清楚标出两三个互不依赖的大块，才考虑并行；否则就维持串行或极少数Agent。工具为任务服务，不是任务为架构服务。这个道理听起来像废话，但在我自己身上，就是吃了几次亏才真正执行下去的。

6. 最后说点私货

在这个项目上踩过几轮之后，我对多Agent的一个核心看法是：Agent数量是结果，不是目标。市场上很多介绍把“并行Agent”包装成一个万能加速器，但在真实系统里，它的价值高度依赖任务结构。如果你现在正打算把Agent从3个加到6个，开工之前先问自己三个问题：

1. 新增的Agent各自负责什么，和现有角色有没有重叠？
2. 新增Agent需要读哪些上下文，这些上下文能不能不重复、不冗余？
3. 它们的产出由谁来验证，验证成本由谁承担？

这三个问题要是答不上来，先别加。我自己现在的常规配置一般就是2到4个Agent：一个主控负责拆解、合并和验证，两到三个执行Agent负责真正的分工。大部分内容处理和轻度开发辅助场景，这个配置比豪华的六七个Agent阵容稳定，总耗时也更短。

最后再分享一个亲测有效的小技巧：做效率对比测试时，固定一个标准任务，连续跑三到五轮，取中间值或平均值，不要只跑一次。模型输出有随机性，单次结果波动很大，一不小心就会被一次偶然的快或慢带到错误结论上。多测几轮，把波动平均掉，数据才有参考价值。这一条，比任何优化技巧都省钱省时间。