企业官网建设流程全解析

做多智能体（Multi-Agent）系统有一段时间了，中间踩过的坑比写出来的代码还多。老实说，把项目命名为“agency-agents”，不只是因为它在仓库里的目录名叫这个，而是因为我越来越确信一件事：真正能落地的Agent系统，不应该叫“助手”，应该叫“机构”。一个助理再能干，也扛不住调研、分析、撰写、复核、汇报这一整套生产流程；但一家代理机构可以，因为它有岗位、有流程、有复核机制。这篇文章就把我搭建这套系统的完整思路、架构设计、踩坑经历和实测数据全部分享出来，希望能给正在做Agent编排、或者准备把AI从“聊天”推向“干活”的朋友一些参考。适合对多智能体架构有一定基础、但是还没系统做过协作编排的读者阅读，也适合那些已经在跑单Agent流程、正被上下文爆炸和输出幻觉折磨的团队。

1. 为什么单Agent会撞墙：从“全能助手”到“代理机构”的转变

先讲一段真实经历。我最早做自动化流程时，思路很朴素：一个大模型，给它长Prompt，让它一口气完成“查资料→写方案→做PPT”。结果第一版跑出来的东西，结构完整、措辞漂亮，细看全是坑——引用的数据一半是编的，三个章节的数据互相矛盾，最离谱的是它把两个不同渠道的统计口径混在一起还浑然不觉。后来我花了整整两天逐条核对，最后只能全部推翻重来。这件事让我意识到，问题不在模型能力，而在工作模式。

1.1 单Agent的三个隐性天花板

第一个天花板是上下文长度幻觉。当单Agent的上下文里塞进大量检索资料、历史对话和中间推理时，它很容易“读到后面忘了前面”，更糟的是它会为了保持回答连贯性而主动补全那些它记不清的细节，这就是幻觉的一个主要来源。你在接口层看Token消耗并没有超限，但输出的可靠度实际上已经断崖式下降。

第二个天花板是单点反思失效。很多人靠“让模型自己检查一遍”来兜底，我也试过。结果发现，反思的流程如果只是在同一个上下文里继续对话，它的立场会被前面自己写的内容锁定，最后变成自我肯定。说白了，让同一个模型既当运动员又当裁判，裁判视角会被运动员的叙述带偏，不可能真正客观。

第三个天花板是任务串行导致的效率瓶颈。单Agent哪怕能力再强，也只能一次干一件事。遇到“先收集十个渠道的数据，再逐个交叉验证，再出报告”这种天然可并行的流程，它也只能老老实实排队，时间成本直接乘以渠道数量。

1.2 转折点：把“全包”拆成“分工”

真正让我下决心重构的是一次竞品调研任务。当时任务要求覆盖某一个行业方向，涉及公开报告、社交平台口碑、平台榜单、历史案例四类信源。我试着在单Agent里设计了一个子步骤循环，让它按顺序处理四类信源。结果跑到第三类信源时，前面第一类的结论已经被模型自己“优化”得面目全非了。

后来我开始研究多智能体协作模式，发现一个有意思的现象：人类职场里，重大产出从来不是靠一个人全流程包办，而是靠分工、复核、会签。于是我把系统重新定义为“虚拟代理机构”——每个Agent有明确的岗位职责、有独立上下文、有协作边界。这不再是“一个更聪明的模型”，而是“一组有纪律的员工”。

1.3 “机构”隐喻的工程价值

用“机构”这个隐喻来设计系统，最大的好处是让工程约束变得清晰。你会自然地追问：岗位有哪些？每个岗位对什么产出负责？产出由谁验收？信息通过什么格式流转？这些问题的答案，直接变成系统的模块边界和数据协议，而不是靠大模型在对话中自由发挥。

我在实际落地时，给“agency”加了一组明确条件：每个Agent只能访问它职责范围内的数据；所有跨Agent消息必须是结构化JSON；每一个交付物必须有校验环节；项目经理Agent对所有任务拥有最终调度权。这四个条件，就是从“一群模型聊天”走向“一个机构运转”的分水岭。

2. 系统架构：角色清单、通信协议与任务状态机

这一节是整套系统的骨架。我先说明整体设计，再拆开讲角色定义、消息协议和任务状态流转。这里面每一个设定都直接回应了第一节说的那些天花板，所以读的时候可以对照着看。

2.1 角色列表与职责边界

我把系统分成六个核心角色，最小可行版本可以砍到四个，但常规任务建议全上。每个角色的定义包括四项：职责范围、输入依赖、交付物、越权红线。

这里面最关键的是“越权红线”。一开始我没写这一栏，结果系统跑起来就乱套了。交叉验证员会顺手“修正”采集回来的数据格式，质量检察官会直接改报告措辞，最后你根本不知道哪句话是哪个环节写的。加上红线约束后，每个Agent的输出边界清晰，出问题就能精准定位到具体环节。

2.2 结构化通信协议

Agent之间不直接对话，而是通过一个共享消息总线交换结构化消息。每条消息由五个字段组成：sender、receiver、intent、payload、ref_id。其中intent决定了这个消息要被怎么处理。

{ "sender": "project_manager", "receiver": "collector", "intent": "task_assign", "payload": { "task_id": "TASK-20241201-001", "requirement": "收集某品牌过去三个月的用户口碑关键词", "source_list": ["社交平台", "投诉平台", "行业论坛"], "output_format": "fact_card", "deadline": "2024-12-02T12:00:00Z" }, "ref_id": "MSG-00123" }

intent一共有六类：task_assign（派单）、fact_submit（提交事实卡）、verify_report（提交验证报告）、analysis_result（提交分析结果）、draft_submit（提交报告初稿）、review_opinion（提交质检意见）。不同intent会被路由到不同的处理函数，而不是丢给模型自由解读。这个设计的核心价值是：模型只负责生成payload内容，调度逻辑全部走代码分支，不让模型决定下一步该让谁干活。

2.3 任务状态机

每个任务实例都运行在一个有限状态机里，不允许自由跳转。这样做的直接收益是：系统只会在确定的状态组合下调用确定角色的模型，不会有“一个Agent顺手把别人的活也干了”的灰色地带。

• 待受理：任务进入队列，项目经理尚未拆解
• 执行中：已分配角色正在处理某个子任务
• 待复核：交付物已提交，等待下游验收
• 已驳回：验收未通过，退回上流角色重做
• 已完成：所有环节验收通过，任务归档
• 已终止：超时、重试超限或用户主动取消

每个状态转移都必须附带转移条件和操作记录。例如从“待复核”到“已驳回”，必须带上验证员的驳回理由和对应的ref_id，方便回溯。这套状态机是整个系统的“底盘”，我之前因为省事跳过它，直接让Agent自由流转，结果就是任务跑到一半，三个Agent各说各话，谁也不知道该等谁，教训很深刻。

3. 任务编排与上下文治理：防漂移、防堵塞的实操方案

架构定完之后，最大的工程难点不是“每层调用什么模型”，而是“上下文怎么给”。我见过很多多Agent系统失败在主提示词里塞了太多东西，结果是每个Agent都在读一堆跟它无关的历史消息，推理质量直线下降。这里分享三个经过多次调优的实操方案。

3.1 工作记忆与项目结论区分离

我给每个Agent设计了两种上下文：工作记忆和项目结论区。工作记忆只包含它自己的历史操作记录，比如信息采集员的工作记忆就是它采集过的全部事实卡，和验证员的驳回记录；项目结论区则是所有角色共享的、已经通过验证的结论集合。

信息采集员读取上下文时，只看到验证员对上一批卡片的驳回意见，看不到分析师写的趋势判断；质量检察官读取终稿时，只看到检查清单和终稿本身，不看前面对话。这样设计的原因是：Agent的注意力是稀缺资源，而上下文里的无关信息是幻觉的最大催化剂。

3.2 三段式Prompt封装

我统一采用“角色卡片+任务卡片+数据卡片”的三段式结构来组装每个Agent的最终Prompt。角色卡片固定不变，写清楚岗位职责、输出格式、越权红线；任务卡片由项目经理动态生成；数据卡片只放结构化信息，不放原文。

【角色卡片】 你是一名信息采集员。你的任务是从指定来源收集客观事实。 你只能输出JSON格式的事实卡片，不得输出分析结论、建议或评价。 你无权修改验证员给出的验证规则。 【任务卡片】 任务编号：TASK-20241201-001 采集主题：某品牌用户口碑关键词 采集渠道：社交平台、投诉平台、行业论坛 重点采集维度：产品缺陷、价格敏感度、客服体验 【数据卡片】 已验证事实示例： - 事实编号：F-001，来源：投诉平台，结论：多人反映续航衰减明显 - 事实编号：F-002，来源：行业论坛，结论：新品价格引发讨论 请严格参照示例格式采集新事实，不得混入未经验证来源的信息。

这个三段式结构，我调了大概四版才稳定。最初我试图把“行业背景知识”也塞进去，后来发现那只会让采集员在输出里夹带“私货”。背景知识应该放在分析师的上下文里，每个角色只对它那一环负责，效果反而最好。

3.3 阶段Checkpoint与事实卡机制

任务拆解后不是直接一次性跑到底，而是设置若干个Checkpoint。每到Checkpoint，项目经理会把当前已验证的事实做一个阶段性合并，更新项目结论区，再生成下一步的任务卡片。这套机制有效防止了任务漂移——如果让所有角色从头到尾自由跑，经常出现采集员在任务后期还在补第一阶段的数据，分析师的结论已经开始引用“预测数据”了。

事实卡机制也值得一提。信息采集员被严格要求只能输出结构化事实卡，每张卡片包含：编号、来源渠道、原文摘录、采集时间、关联主题。分析师只能基于已通过验证的事实卡做分析。这个“不下结论”的约束最初执行得并不好，因为大模型太爱“发挥”了。后来我在数据卡片的示例里明确标注了“被驳回的反例”，让采集员看到什么叫做“越界”，效果立刻改善。模型不是不懂规则，而是需要看到规则的具体边界。

4. 多智能体协作的稳定性：死循环、角色串位的排查链路

系统跑起来之后，不太会出现“模型答不上来”的问题了，新的麻烦变成了流程稳定性问题。这一节分享两个我实际遇到并且完整排查过的故障场景，顺便给出通用排查方法。这部分内容我觉得是整个系统最值得记录的，因为文档里几乎不会写。

4.1 故障现场：验证环节陷入无限驳回循环

现象是：交叉验证员连续驳回了同一张事实卡四次，采集员每次按驳回意见重采，但验证员每次给出不同的驳回理由。从日志看，驳回理由分别是“来源不可信”“结论与原文不符”“该事实已在其他卡片中存在”“格式不符合要求”。

我一开始以为是模型理解能力的问题，后来把消息日志完整回放了一遍才发现根因：验证员的输入里没有携带“该卡片是哪一批次提交”的信息，只看到了最终卡片状态。也就是说，它每次检查的都是“当前版本”，而采集团队在下一次提交时又基于旧版本修改，两边的版本基线对不上，导致永远在追一个移动的靶子。

4.2 排查链路与根因定位

我的排查流程分四步，这套路子现在已经成为团队的固定方法，分享给各位参考：

1. 全量消息回放。把消息总线里所有与故障任务相关的消息按时间线排列，先不看模型输出质量，只看“谁在什么状态下发了什么消息”。
2. 协议字段核对。检查每次驳回消息里是否携带了足够的上下文标识，比如task_id、card_id、batch_id。
3. 状态机轨迹比对。看任务的状态转移是否出现了异常循环路径，结合消息时间戳定位循环的起止点。
4. 触发词分析。看越权行为是否发生在系统Prompt中出现了特定授权句式之后。

这次循环的根因，是验证环节缺少“版本对齐”机制。修复方式是给每张事实卡增加version字段，采集员每次修改必须自增版本号；验证员验证时以“版本号+批号”为准，而不是以“当前最新内容”为准。修复后同样的任务没有再出现过连续驳回超过两次的情况。

4.3 角色串位：系统Prompt里的授权陷阱

另一个高频故障是角色串位。表现是：质量检察官在验收报告时，不动声色地修改了报告里的核心结论；交叉验证员在验证事实时，顺手“补全”了采集员遗漏的数据点。

排查过程发现，根因在日常容易忽视的位置——系统Prompt里的“你可以”句式。比如我在质量检察官的角色卡片里写了一句“你可以对报告中的结构性问题提出修改建议”，模型的注意力被“修改”两个字放大了，它就会把“建议”直接理解为“动手改”。修复方案是把角色卡片的每一条权限都写成“你只负责输出检查结论，不修改任何内容”，同时把“建议”改为“提出结论性意见”。用词从“可以”改成“只负责”之后，串位问题减少了绝大多数。

4.4 重试熔断与失败降级机制

无限重试是最容易拖垮整套系统的隐性事故。加了一层简单的熔断逻辑：同一个子任务的重试次数上限是3次，超过后任务自动降级为“人工介入”。同时，在验证环节增加“阈值熔断”——如果同一个环节连续驳回次数达到5次，系统会暂停该任务并触发告警。这个机制看起来简单，但没有它的时候，系统试过在一个错误的事实卡上反复空转将近40分钟。

遇到超过上限的驳回时，说明大概率不是生成质量问题，而是流程本身的输入条件有歧义。这时候让模型继续改没有意义，正确做法是人工介入修正规则或场景定义。我在系统告警日志中把这些事件单独标记为“流程缺陷”，当前的版本里已经靠这些标记迭代优化掉了两处隐性规则冲突。

5. 一次完整演练：竞品调研任务从拆解到交付的实跑记录

前面讲了这么多原理，用一个完整例子把整个流程串起来。我选了一个虚构的竞品调研任务，设定是“某个生鲜零售品牌想了解竞争对手过去一个季度的用户口碑变化”，完全按照系统实际运行轨迹来记录。

5.1 项目启动与任务拆解阶段

项目经理接收原始需求后，首先产出任务分解书。这次的任务被拆成五个子任务：口碑关键词采集、渠道质量评估、趋势分析、竞品对比、终稿撰写。

派单的消息里明确写清了每个子任务的输入输出和验收标准。比如口碑关键词采集子任务的验收标准是“每个关键词必须附带至少两个独立来源”，渠道质量评估子任务的验收标准是“结论必须使用已验证事实卡”。这些验收标准是拆解阶段最重要的产物，没有它，后续的质检环节就没有依据。

5.2 信息采集与交叉验证的过程记录

信息采集员收到任务后并行跑了三个渠道，提交了首批12张事实卡。交叉验证员核查后发现，其中3张卡片存在“来源无法回溯”问题，1张卡片存在“结论与原文明显不符”问题，共驳回4张，附带了具体的驳回理由。

项目经历了几批拉锯之后，第4批提交时，12张卡片全部通过验证。随后，项目经理把通过验证的卡片汇总进项目结论区，并给分析师派发了分析任务。这里有一点值得留意：采集阶段并不追求一次成功，批次越早暴露的问题越值钱——因为它们都发生在“验证成本”最低的阶段。

5.3 分析与报告阶段的质量把关

策略分析师拿到9条已验证事实后，产出了分析框架，包含“口碑关键词集中度”“差评高发环节对比”“竞品应对动作效果评估”三个维度。报告撰写员据此生成了初稿。

质量检察官按验收清单检查终稿后，提出了两个驳回意见：一是报告第二部分引用了“客户满意度提升”的表述，但对应的事实卡中没有采集到能支撑该结论的一手数据；二是对比表格里缺少数据来源标识。这两条异议都很具体，报告撰写员按意见修订后，终稿在第二轮通过验收。整个任务从开始到归档，系统共完成四次状态回调，实际耗时约12分钟。

5.4 成本与收益对比

这次任务账面上最直观的是Token消耗和用时。按照记录估算，系统一共消耗了约45万Token（采集和验证环节占六成以上），费用在可接受范围内；而换人工来做的话，哪怕熟练员工也要至少一整天。

Token大头在“验证-重试”环节，这个印象很深。后来我做了一个优化，把验证员的重试上限从3次下调到2次，并在它觉得“信息不足”时直接要求采集员附带原文链接，而不是让它自行猜测。这个改动将Token消耗降低了大概三成，报告的最终交付质量却没有下降。

6. 工程化上线要补的课：并行、持久化、成本控制与隔离

如果只在本地跑着玩，前面五节的内容已经够用了。但真要拿它处理固定业务流，还需要解决几个更“脏”的工程问题。这里分享的是我目前正在生产环境实际使用的方案，未必最优，但能跑、好维护、出问题好排查。

6.1 并行策略：同环节并发，而非全流程并发

很多人一听到“多智能体”就觉得并行是默认能力，其实不是。我的策略是：阶段内并行、阶段间串行。也就是“多个采集员跑不同渠道”可以并行，“分析师和采集员同时干活”就不行。

并行要控制粒度。为每个子任务分配一个Agent实例，不同的子任务如果互相没有依赖关系，可以并行跑；但下游分析必须在采集验证全部结束后才开始，维护一个简单的依赖检查表，判断每一对子任务之间是否有数据依赖。粒度太粗会导致串行浪费时间，太细则陷入调度地狱，这个平衡经过三轮迭代才调出来。

6.2 状态持久化与故障恢复

任务状态机的所有信息都会以JSON文档形式实时落盘，每次状态转移都写入一条日志。这样即使模型调用中途报错、容器重启或网络抖动，系统也能从最近一次落盘状态恢复，而不是从头再来。

恢复策略是：每个子任务记录自己的当前状态和输入输出引用地址；重启后，项目经理扫描所有未完成任务，对“执行中”的子任务发起状态询问，如果检测到没有输出，就重新派单。配合第4节讲的版本机制，恢复后不会出现重复提交或者版本覆盖的问题。

持久化目录结构建议按“task_id/round/step”来维护，每一轮Checkpoint生成一个快照，避免用单个大文件存所有状态导致写入竞争。这个设计在排查时很管用，可以直接对比相邻快照找出是哪一步出了问题。

6.3 成本控制：按角色动态分配模型规格

成本优化不是靠压缩Prompt字数，而是给不同角色分配不同规格的模型。信息采集员处理的是重复性结构化提取，用一个小型模型就够了；策略分析师需要推理深度，必须上更强的模型；交叉验证员也在强模型阵营，因为它的职责是挑错，弱模型挑不动错。

同时，我加了一条硬性规则：只有状态机的特定节点允许调用大模型，任何Agent发起“自行补充信息”的请求，一律拒绝。这条规则直接封死了一个隐性黑洞：模型为了表现更好而擅自调用工具去搜资料，Token消耗直接翻倍，但任务进度并没有提升。

6.4 隔离与数据安全

多Agent系统在生产环境里还有一个容易被忽略的问题：一个环节的脏数据会顺着消息总线污染全链路。目前我在每个角色的输入输出端口都加了校验层，字段缺失、格式不对的消息会在进入队列前直接被拦截，不走模型推理。这个校验层的代码不多，但能挡掉至少一半以上的流程异常。

提示词注入也是要重视的问题。如果让承接外部信源的Agent直接处理未经净化的文本，外部内容里的恶意指令可能被模型“采纳”，进而影响后续所有环节。我现在采取的做法是：采集员只负责从网页截取固定字段，原始文本一律不进上下文；需要总结时，截取固定字段后先经过“脱敏/清洗”再合成卡片。

我还做了数据隔离：不同客户的任务使用独立命名空间，消息总线按命名空间路由，Agent的工作记忆不跨任务共享。这样既隔离了业务数据，也保护了账号资源，排查问题时能更快定位是哪批任务互相影响导致状态错乱。

到这里，这套“agency-agents”系统的核心结构、设计逻辑和实际运行数据都交代完了。回看整个开发过程，我最大的感受是：多智能体系统的复杂度不在于写多少代码，而在于你是否清楚“每一步谁在看什么、谁有权对什么负责”。每次觉得要失控的时候，打开消息日志看一遍状态流，大多数问题都能找到答案。这套系统的下一轮迭代，我计划把每个Agent的“决策依据”也做成可回溯的结构化数据，让整个系统的运行过程能像看班组日报一样一目了然。如果你正准备搭自己的多智能体系统，建议先从最小闭环跑起来，再把约束一条一条加上去，别一开始就追求“全自动智能”——把流程跑稳了，比让模型显得聪明更重要。