企业官网建设流程全解析

1. 先讲结论：为什么“人多力量大”在LLM Agent协作里经常失效

最近这段时间，Multi-Agent 几乎成了大模型应用里最容易被高估的选项。我见过不少团队，包括我自己折腾过的内部模拟项目，一开始都是抱着“一个智能体搞不定，那派四个智能体分工协作总该行”的思路，结果把任务一拆、角色一设、流程一接，跑出来的数据相当难看。我这边实测到的最极端一组对比是：同样的任务，单 Agent 基线耗时约 3 分钟出头，消耗约 2.8 万 Token；换成 4 角色的 Multi-Agent 团队协作流程，耗时接近 2 小时 40 分钟，消耗 37 万 Token。换算下来，时间大约是 32 倍，Token 大约是 13 倍，而最终交付质量不但没有提升，在关键字段的准确率上反而低了近 10 个百分点。

先说清楚，我这不是要全盘否定多智能体。而是想说，很多项目在没有想清楚任务结构之前，就先把“多智能体”当作银弹，结果踩进了一个非常典型的反模式：分布式协作没有带来分布式收益，反而引入了成倍的通信开销、决策延迟和信息损耗。这篇文章就是我踩完坑之后的完整复盘，包括实验设计、开销拆解、质量劣化路径，以及我后来总结出来的几条可复用判断标准。如果你想评估“自己的任务要不要上多 Agent”，或者已经被多 Agent 流程折磨得想退回单 Agent，这篇应该能帮你少走不少弯路。

我要特别强调，这里说的“多 Agent 团队”，指的是由多个 LLM 实例分别扮演不同角色，比如规划者、执行者、质检员、优化者，通过互相传递文本结果来协同完成任务的架构，而不是多个独立进程简单并行处理不同数据分片。这两者有本质区别，前者是串行协商，后者才是真正可并行的吞吐架构。我的反例主要集中在第一种。

1.1 一次本可避免的“妄想式”改造

这个实验的起点是个很普通的任务：从一份企业内部产品手册里抽取结构化信息，包括产品型号、版本号、适用场景、主要卖点、注意事项等 20 个字段，最后整理成一份带校对说明的 JSON。任务量不算大，大概 60 多页 PDF，字段有些字符化，来源分散，需要做一点推理和合并。

单 Agent 做这件事完全可以胜任，我当时已经写好了一个工具循环，让模型反复调用 PDF 解析、文本检索和片段提取工具，答案是能落地的，只是偶尔漏字段或者混淆同义词。本来按我的习惯，下一步应该是调整提示词和检索逻辑，把准确率从 80% 提到 90% 以上。但那时候正好受到多智能体理念的影响，脑子里全是“规划者拆解任务、执行者细化落地、质检者挑错、优化者返工”这种理想流程。于是头脑一热，决定把这个任务改造成一个 4 角色的 Multi-Agent 流水线，想看看团队协作到底能不能把质量拉上去。

后来的结果大家都知道了：没有拉上去，反而赔了利润。我后来反思，这种“本来单智能体只是小问题，却想通过增加智能体数量来根治”的决策，在认知上就有 bug。因为单智能体表现不好，通常不是因为没有人手，而是因为工具、上下文和评判信号不够。加智能体不解决这三个问题，只会把问题从一个地方复制到四个地方。

1.2 我最先记录的对比数字

先给结论性数据，后面再解释这些数字是怎么来的。为了防止单次运行抖动，每一套配置我都用同一个输入文件重复跑了 3 轮，取中间值。对比的关键指标是三条：端到端耗时、总 Token 消耗、结构化字段的准确率与完整率。

耗时 32 倍，Token 13 倍，指标还倒退。这个反差如果发生在性能或成本上还能忍，关键跌到质量上，就比较难解释了。理解这个现象要从任务的执行过程、通信模型和决策结构入手，下面三个部分我会分别把实验细节、开销来源和劣化路径拆开讲。

2. 对比实验是怎么设计的：同一个任务，两套执行路线

很多人看到 32 倍这种数字，第一反应是“是不是多 Agent 流程写得有问题”。确实有那种把整本书塞进每个 Agent 上下文导致指数膨胀的低级错误，但我想说，我这次的设计其实已经算克制了：角色只有四个，每轮只允许传递一次结构化结论，评审和修订循环也设了轮数上限。它不是最糟糕的实现，但它仍然失败得很彻底。这说明问题可能出在架构本身的假设上。

2.1 任务选型与评估口径

我特意选了一个“看起来非常适合多 Agent”的任务，原因有三个：第一，任务可以拆成“通读目录—定位字段—提取文本—交叉校验—生成 JSON”几个阶段，符合直觉上的流水线结构；第二，字段之间没有强烈依赖，理论上可以分块并行；第三，质检和优化环节看起来能带来明显增益，因为模型的输出确实需要“第二双眼”检查。

评测口径方面，我做了 20 个字段的标注答案。准确率指字段值本身与原文档语义一致的比例，完整率指非空字段占全部字段的比例。对于多 Agent 流水线，我还额外记录了一条“最终输出是否经过人工修改”的日志，这样做是为了理解质量损耗到底发生在链路中哪个位置，而不是只看最终结果。

2.2 单 Agent 基线配置

单 Agent 的流程很简单：一个模型实例，配一个系统提示词，说明输出目标与工具接口；模型在循环里自主决定下一步调用什么工具，包括“读取前 3 页”“定位某关键词”“抽取某段落”“把结果写入 JSON”。每个工具调用后模型都会拿到新的观察结果，再决定继续调用还是给出最终答案。这种模式在 Agent 工具调用的技术选型里属于“单一执行者 + 工具护栏”，类似一个人带了一整套工具箱完成全流程。

它的资源模型也很简单：上下文里始终只有一个思考链条，模型读到什么、分析了什么、纠正了什么，都在同一条上下文中线性推进。不会出现“规划者说的话，执行者没听懂”的情况，因为根本不存在“说给别人听”，模型的所有推理都是为自己服务的。这也是为什么单 Agent 在大多数手工知识任务里其实是性价比非常高的选择：它没有通信成本，只有推理成本。

2.3 多 Agent“团队”配置与角色分工

多 Agent 流水线设置了四个角色，分别是规划者、检索执行者、质检者、修正者。

规划者的任务是把 20 个字段分成 5 个字段组，生成检索策略清单；检索执行者按清单逐一调用工具，并把每个字段组的“原始证据片段 + 初步提取值”整理成表格交给下游；质检者不接触工具，只读取检索执行者提交的表格，对照“是否遗漏、是否凭空捏造、是否符合手册语气”给出质检意见；修正者根据质检意见，决定重新调用工具还是修正既有值，最终生成 JSON。

乍一看合理，实际跑起来就有几个问题：检索执行者为了“交接清楚”，会把大量原文片段复制到输出里，导致质检者的上下文非常大；质检者并不掌握工具调用能力，只能凭经验判断，经常把“原文里其实没有的信息”误判成“执行者遗漏”，然后触发修正者再跑一遍工具。这还没算规划者每启动一次流程就要重新读取全部任务描述，等于同样的规划逻辑反复被重算。

2.4 我如何保证对比的公平性

这里有一个常见的坑：对比单 Agent 和多 Agent 时，两个流程的可用工具集和最大步骤数必须保持一致，否则你无法判断差异来自“多智能体”还是来自“额外附送了能力”。我这次的公平性控制包括：两者使用同一个 LLM 供应商、同一个模型规格，不允许多 Agent 使用更高级的模型；两者都具备 PDF 解析、关键词检索、片段抽取和 JSON 生成工具，数量与接口完全一致；两者的最大外部工具调用次数都限制为 30 次。

另外，我把多 Agent 团队里每一个角色产生的中间日志都存了下来，包含时间戳、Token 计数和工具调用记录，这样后面做开销拆解时有账可查，而不是拍脑袋说“因为多智能体所以贵”。

3. 时间与Token到底烧在哪些环节：日志里的四个黑洞

这是整篇里最该细看的部分。32 倍耗时和 13 倍 Token 不是平均分配的，而是集中在四类行为里。我把日志分别导出来，按累计 Token 排了序，发现几个大头特别明确。

3.1 黑洞一：上下文重复加载而不是并行计算

多 Agent 架构最常见的内在代价，是上下文被重复计入。单 Agent 循环中，模型只看一段持续增长的上下文；多 Agent 流水线里，每个角色启动时都需要一段“任务说明 + 上游交接材料”，这些材料里往往包含大段原始证据。我把 20 个字段的证据片段汇总后发现，光是把所有原始片段复制给质检者，就占掉 4.6 万 Token。而这些 Token 不是用来产生新信息的，只是把已经生成过的结果在角色之间搬运一遍。

更要命的是，部分角色为了“保险”，会把整个系统提示词和所有可能的工具说明再次加载。这就好比一队人分工写一份报告，每个人的文件夹里都放着一份完整的原始资料汇总。你以为是四个各带部分资料的工人，实际上是四个各带图书馆的搬运工，大量的加载都在做重复功。

3.2 黑洞二：串行握手、等待超时与内容重试

很多人在设计多 Agent 时想过“并行”，但真正落地时发现角色之间通常存在依赖：规划者要先给出策略，执行者才能按策略干活；执行者要先返回证据表，质检者才能审查；质检者给出意见后，修正者才能动工。这意味着整个链路是严格串行的。我统计了一下，这个流水线实际走了 37 个串行接力步，每步都要等前一步完整跑完。

串行步数直接决定了耗时天花板。更麻烦的是，模型服务在长上下文场景下响应不稳定，偶发超时、偶发上限报错，我设置了 3 次重试，这部分又额外吃掉了不少事件。你在单 Agent 流程里遇到同样的问题，最多影响一个内部循环；在多 Agent 流程里，任何一次超时都会让整个链条停下来重新协商，错误被放大了不止一个数量级。

3.3 黑洞三：评审—修订循环的死亡螺旋

泛善可陈的质检环节，是这次运行中最大的 Token 消耗来源。流程设定是“质检者挑毛病，修正者改答案”，听起来有效，实际运行起来，质检者每轮都会从自己的判断角度提出新的修改意见。比如它觉得某字段“证据不足”，修正者就会重新搜索并补充证据；补充后质检者又觉得另一处解释和原文不一致，要求再次调整。如此循环往复。

我设的是最多 5 轮评审修订，实际全部撞满。每一轮都要重读完整上下文，所以光这个循环就烧掉了约 13 万 Token。这还只是保守设计，如果我不加轮数上限，很可能无限循环下去。本质上，这个循环是一个“没有终止条件”的优化过程。模型的判断分布于每一轮之间并不稳定，有时候新的修改会让旧字段受影响，评审意见之间还会互相产生新的矛盾。

3.4 黑洞四：工具调用被重复执行

工具重复调用也很值得注意。单 Agent 执行时，模型自己知道已经搜索过什么、结果是什么，所以不会再去重复。多 Agent 流程里，执行者把“搜索结果摘要”交给修正者后，修正者如果觉得证据不够，并不会去找执行者要更多数据，而是直接自己调用同一个工具再搜一遍。这导致同一个 PDF 解析动作被重复执行了 5 次，其中的 3 次完全是没有信息增量的重复劳动。

我后来在日志里数了一下，单 Agent 全程工具调用 17 次，多 Agent 流水线全程工具调用 46 次。其中 21 次属于“重复检索”，有 9 次甚至检索的是同一个关键词。工具调用多，Token 消耗自然高，而且每次工具调用后模型都要重新生成一段“分析结论”，这部分输出 Token 完全没有产出新价值。

3.5 一次简单的 Token 账本推演

把开销再抽象一下，可以写出一个很粗糙的 Token 模型。假设整个任务的信息熵是 E，单 Agent 一次流程消耗大约 2 倍的 上下文冗余，也就是 2E。多 Agent 因为每个角色都要读上游材料，总消耗至少是“角色数量 × 全量上下文”，也就是 4 × 2E = 8E。再乘上评审修订的迭代系数，每轮额外叠加约 1.5E，5 轮下来又是 7.5E。

这样粗略算，总量在 15E 到 20E 之间，和我实测的 13 倍基本吻合。而这还属于比较理想的线性推算，如果角色的交接材料里包含大段原始证据副本，膨胀系数会更高。也就是说，多 Agent 的 Token 成本不是“人数×单人成本”，而是“人数×全量上下文×迭代系数”，这是一个乘法关系，不是一个加法关系。

4. “结果可能更差”的根源：三条质量滑坡路径

成本翻 32 倍还能找借口说是为了“更高质量”，但质量本身也跌了，这才是这个反例最扎心的地方。我把整个流水线的中间产物和最终输出逐行对齐后，发现质量劣化主要来自三条路径：信息折损、幻觉合法化、责任真空。三条路径不是独立出现的，它们经常互相加强。

4.1 信息折损：自然语言交接是不可靠的“数据库”

第一类问题出在角色之间的交接方式上。检索执行者把“原始证据片段 + 初步提取值”整理给质检者时，不可避免要压缩信息。它可能在摘要里写了“型号字段提取成功”，却把原文里更准确的前置条件删掉了。质检者看到的永远是一份二手信息，而不是原始文档。

这种信息折损和人类团队里的口头汇报非常像。但人有常识，能识别“这个结论听起来缺乏支撑请去翻原文档”，LLM 质检者没有这种常识，它只会基于传递过来的摘要做推理。一旦上级拿到的信息不完整，即使它是“认真检查”，也只会得到“认真但有缺陷”的结果。我统计过，最终输出里 7 个错误字段中，有 4 个的源头都可以追溯到某个交接摘要里遗漏了关键原文。

4.2 幻觉被流程合法化：下游比上游更自信

第二条路径更有意思。多 Agent 流水线有个隐藏的背书效应：一个结论经手了执行者、质检者、修正者三道程序后，在终输出里就被默认为“经过了充分验证”。但实际上，整个链条上没有任何一个角色直接面对全部原始证据。执行者可能只看了局部，质检者只看了摘要，修正者只修改了局部。

更夸张的是，某些质检意见本身也是幻觉。质检者对某字段的“疑问”并不总是基于真实缺失，它只是觉得“这里没有理解成常见格式”就不安心，于是让修正者去改。修正者当然照做，把本来正确的答案改成了错误答案，然后写了一句修改理由。最终输出里“看起来被验证过”的错误，往往比单 Agent 里明显的错误更难被发现，因为没有任何流程标记过它的验证来源。

4.3 责任真空：局部优化取代了整体目标

第三类问题是流程层面的：每个角色都在做局部优化，但没有人对全局结果负责。规划者关心的是一次总览计划；执行者关心的是按清单完成检索；质检者关心的是找出“可疑字段”；修正者关心的是让质检意见清零。这里没有任何一个角色去检查“最终 JSON 是否能被下游直接使用”。

这个结构在系统工程里有个非常明确的名称：责任分散，而且比人类组织里更严重。人类团队里至少还有一个人知道最终目标，但 Multi-Agent 流水线里，每个角色都只拿到局部 prompt 和局部上下文。如果整体方向从一开始就偏了，这个偏差会像一个 bug 一样沿着流程一路传导，且每一站都会给上一个站点的输出盖上“已处理”的印章。你是永远不会知道偏差到底发生在哪一步的，除非你像我一样去完整复盘。

4.4 评测结果：三条路径同时出现

最终评测时，我把 20 个字段的错误全部归了类。发现 6 个错误字段里，2 个是原始信息折损造成，2 个是把正确值改错，2 个是规划策略本身偏了。没有一个错误能被归结到“模型能力不足”，全是协作结构导致的人为损耗。这跟我最初判断的方向完全不同，也让我意识到：多 Agent 不是“升级”，而是“再造”。再造过程中引入的新问题，通常比它们试图解决的旧问题更难以预料。

5. 多Agent架构的正解与反模式：先判断任务再动手

踩坑之后，我也读了一些其他场景下的成功和失败案例。更多的结论是：多 Agent 并非没有用，但它有非常明确的适用边界。这个边界的核心在于“任务能不能被拆成低耦合的独立子问题”，以及“拆开后的输出能不能被低成本合并”。如果两个条件不成立，多 Agent 就是负优化。

5.1 适合多Agent协作的四个特征

我后来总结出四个比较可靠的特征，用来判断一个任务是否真的适合多 Agent。第一，切分后的子任务之间不需要频繁交换中间结果，或者交换成本可以忽略；第二，每个子任务都有明确的验收条件，能独立判断“是否已完成”，而不需要看别人的最终产出；第三，子任务的结果可以直接拼接或投票合并，不需要复杂的协商机制；第四，整体任务的错误容忍度较高，允许某些角色输出不定，靠汇聚来纠偏。

最典型的是“多个 Agent 并行阅读不同的报告，每个 Agent 独立提炼要点，最后合并要点列表”。这种场景下没有串行流水线，每个 Agent 只看自己的那份文件，结果合并也不存在交叉影响，多 Agent 的并行红利才能落地。另一个例子是“同一道数学题让三个 Agent 各自独立求解再投票”，然后靠多数投票去掉随机噪声，这其实也适合，但前提是三个 Agent 必须完全独立，不能互相看到答案。

5.2 经典反模式清单：对号入座

与之对应的，我列了一份“经典反模式”清单，中一条就要警惕。第一，流水线式交接：规划→执行→评审→修正，每一步必须等前一步，每一步输出又是后一步的全部输入；第二，评审本身没有硬指标：质检者只能凭感觉找错，无法用字段完整率、格式合规率这类客观指标验收；第三，上游职责过大：把所有原始材料一次性丢给第一个 Agent，让它在没有完成的情况下必须产出一份“完整方案”；第四，所有角色共享全部上下文：每个 Agent 的 prompt 都包含完整任务描述和完整历史，导致上下文成本的平方级膨胀。

如果你的设计命中两条以上，我建议你停下来重新考虑。不是因为多 Agent 不好，而是因为你设计了一个“高压串行链路”，在这种链路里任何一点波动都会被放大，而这种放大对最终质量毫无帮助。

5.3 替代路线：先做单Agent增强，再考虑微团队

我自己现在的原则是“先榨干单 Agent，再考虑团队”。单 Agent 的增强空间其实非常大：给模型更高质量的工具接口、把任务说明拆成更清晰的验收 QA、给每个工具加上自动结果校验、引入外部知识库做检索增强、允许模型调用多个候选路径再自选最优。这些手段通常能把质量推高一大截，而且成本增长是线性的。

只有当单 Agent 方案做到不能再优化，并且任务本身满足上一小节描述的“低耦合、可独立验收”特征时，我才会认真设计多 Agent。而且即使设计，我也不会一上来就四五个角色，而是从“两个角色”开始：一个干活，一个拿独立标准验收，看看是否真的比单 Agent 多出收益。如果没有，就继续退回单 Agent。多 Agent 应该是层层验证后的结果，而不是一开始的预设。

6. 如果非要上团队协作，这四条经验能帮你止损

即使按照上面的标准判断后，业务场景还是需要多 Agent，我也建议你在架构里带上下面四条保护机制。这些不是我凭空想的，是我在跑完反例流程后从日志里一条条抠出来的止损方案。

6.1 给流程加硬预算：轮次上限与停止条件

第一要素是“硬预算”。给评审修订轮次设上限，比如最多 2 轮，超过上限后无论意见是否清零，直接把当前版本提交为最终结果；给每个角色的工具调用次数设上限，超过就只能基于现有可能输出，不允许再重新搜索；给整体耗时设上限，超过就自动退化为“单 Agent 优先完成版本 + 质检注释”模式。

我上面实验失败时，修订轮次上限是 5，结果每轮都撞顶。改成 2 轮之后，质量没有显著变化，Token 消耗约降到原来的 60%。这说明大部分修订实际上是在空转。

6.2 状态外置，不要让Agent用对话传“状态”

第二个建议是把状态放到 Agent 之外的共享存储里。不要用自然语言摘要来传递“当前进度”“已完成字段”“证据来源”，而是用 JSON 文件、向量索引或者结构化数据库记录。每个 Agent 只从共享存储里读取自己需要的那一部分，也不允许在输出里粘贴大段原始文本，只允许给出引用地址和键值。

这种方式彻底切断“上下文搬运”的核心链路。Agent 之间的文本交互缩减到最少的指令和确认，原始材料数据只在需要时由工具重新加载，而不是在对话里复制来复制去。

6.3 用并行采样替代“评审修订”：一次多份，择优录用

第三个建议更激进一步：把“串行评审—修订”改成“并行采样—择优”。具体做法是，让同一个执行 Agent 独立生成 3 份完整结果，然后再用一个独立的判断 Agent 对这 3 份结果做一致性对比和评分，选出最可靠的一版输出。没有修订，没有迭代，只有一次选择。

这个方法把质量提升的来源从“迭代修订”换成了“多样性冗余”，成本模型也从串行乘数变成了并行加法。我实测下来，在同样的预算里，并行采样 3 份加一次择优，最终准确率比串行修订 5 轮高了约 5 个百分点，耗时还低了一大截。

6.4 把团队缩小为“两个半”角色

最后一条是关于角色数量的。我见的很多设计里动辄规划者、执行者、检索者、总结者、质检者、元质检者六七个角色，实际上大部分角色都在做重复的事情。我的建议是，角色最多保留三个：执行者负责完整任务；验收者负责对照客观标准给结果打分并指出不合格项；如果一定要“修改”，不要闭环成“评审—修订”循环，而是让执行者拿到验收意见后，以一条新的完整执行路径重新生成结果，而不是打补丁。

这种做法等于把“管理员—工人”的二级结构变成了“工人—验收员—重新开工”的三级结构，但避免了循环纠缠。验收者存在的核心目的是提供独立判断信号，不是为了给执行者逐条改错。毕竟，真正让多 Agent 有意义的不是“多几个人”，而是“有人能提供独立于执行者的误差信号”。

最后再分享一个经验：我在之后做任何类似任务时，都会先写一份“反向验收清单”，明确问自己“如果加了多智能体，最终质量变差，我能不能在流程日志里找到原因”。如果连这个答案都是模糊的，那说明架构本身还没有达到可以被信任的程度。多 Agent 不是不能碰，而是要带着止损措施去碰。希望我这篇反例复盘，能帮你少烧几十万个 Token。