企业官网建设流程全解析

1. 为什么单智能体撑不住了：从"一个人扛所有"到"拆给团队干"

做了大半年单智能体落地项目，我最大的感受是：单智能体就像一家只有一个全能员工的初创公司。活儿少的时候效率惊人，老板让干什么就干什么，不用沟通、不用对齐、不用开周会。可一旦任务复杂起来——需要同时处理多路信息、执行多步骤决策、对接不同专业领域——这个全能员工就开始出乱子。要么答非所问，要么在一个环节上无限循环，要么上下文一长就把前面交代的事忘得干干净净。

我印象最深的一次是在做一个保险理赔场景的智能体应用。单智能体要完成：识别客户意图、查保单条款、计算赔付金额、生成理赔说明、合规审查、最后输出结论。这个链条听起来不算长，但每个环节需要的技能、数据源、判断标准都不一样。智能体在"查条款"和"生成说明"之间反复横跳，上下文里塞满了中间步骤，结果最后生成的理赔说明里出现了原始条款的错误引用。用户问一句"为什么这条不赔"，它就懵了。

所以当我看到"单智能体到多智能体"这个话题时，第一反应不是"这是个趋势"，而是"这是被逼出来的方案"。多智能体的价值一句话就能说清：把一个大而全的任务，拆成多个小而专的角色，每个角色只做自己最擅长的事，再通过协作机制把结果拼起来。

适合读这篇内容的，是那些已经在用大模型做应用、但发现单智能体在复杂任务上性能见顶的开发者，还有准备上多智能体架构但不知道怎么分角色、怎么设计协作流程的团队。我会结合几种主流的落地方式和框架，把角色分工和协作机制这两件事讲透，包括我实际跑项目时踩过的坑。

2. 角色分工怎么分才不出乱子：边界、颗粒度与职责定义

多智能体系统里，角色分工是最容易被低估的环节。很多人以为"分角色"就是给每个智能体起个名字、写个system prompt就完事。真跑起来你会发现，名字取得再好听也没用，关键是边界划得清不清、职责定得死不死、信息流走得顺不顺。

2.1 按语义边界切分：从"谁懂什么"开始

我见过一个翻车案例。有人把客服系统拆成了"售前智能体"和"售后智能体"，一个管咨询，一个管退换货。结果用户问"这个产品适合敏感肌吗？"——这明明是售前问题，但用户是在退换货入口问的。售后智能体没权限也答不了，就硬答，输出一堆模棱两可的废话。

这就是典型的语义边界没划清。正确的切法是：不要按入口切，要按领域切。售前智能体负责产品知识、规格参数、适用场景；售后智能体负责订单状态、退换政策、物流追踪。用户从哪里进来不重要，问题属于哪个语义域才重要。前置需要一个路由层来判断问题的归属——这个我们后面讲协作机制的时候细说。

按语义边界切分的好处是职责没有重叠区，模型不会在"这个问题该不该我答"上花费多余的推理消耗。我在实际项目里的经验是：如果两个智能体的system prompt中有超过两成的内容描述的是同一类业务规则，就要考虑合并或者重新划分。

2.2 按任务粒度配置模型：不是所有角色都配最强模型

多智能体系统有个天然优势：可以用不同能力的模型去匹配不同角色的复杂度。这是单智能体很难做到的——一个智能体里要塞进所有能力，你就只能全部用强模型，成本高得离谱。

我目前跑的一个项目里，四类角色用的是三种不同规格的模型：

这样配置下来，成本大约只有全用最强模型的40%。强模型负责"想"，弱模型负责"做"，性能不但没降，因为职责单一化了，每个环节的准确率反而提升了。

2.3 职责定义的三个一：一个目标、一个出口、一个Owner

给智能体写system prompt时，我总结了一个"三个一"原则，实测下来能少掉一半以上的协作问题：

• 一个目标：每个智能体只对一个KPI负责。执行者的KPI是"按时产出格式正确的中间结果"，审查者的KPI是"找出每一个不合规的输出"。不要写"既要又要还要"，模型一旦面对多目标就失去优先级的判断力。
• 一个出口：每个智能体的输出只有一个接收方。输出给协调者就只给协调者，不要同时广播给所有人。否则下游会收到互相矛盾的信息，还要额外花精力做版本比对。
• 一个Owner：每一类问题最终由谁兜底，必须在系统设计时就定死。没人兜底的问题就会在各个智能体之间踢皮球——模型可太会踢皮球了。

3. 协作机制怎么设计才跑得动：消息传递、协商与共享状态

角色分清楚了，只是把"员工"找齐了。真正难的是让他们"配合起来干活"。多智能体的协作机制决定了系统是"越跑越顺"还是"越跑越乱"。我把协作机制拆成四层来讲：消息层、决策层、状态层、失败处理层。

3.1 消息传递：给通信格式定死规矩

多智能体之间的通信，最怕的就是格式混乱。早期我甚至见过用自然语言段落互相传消息的——协调者让执行者"查一下上个月华东区的销售额"，执行者回了一大段"好的，我查了，结果如下……"——这种非结构化消息在单个环节还能凑合，一旦超过三跳协作，解析成本就会爆炸。

我的做法是给消息定一个统一的Structured格式，至少要包含这几个字段：

Message { id: 唯一消息ID from: 发送方角色 to: 接收方角色 type: request / response / broadcast / heartbeat intent: 这次通信要干什么（例如 fetch_data / confirm / submit_result） payload: 业务数据（必须是结构化对象或JSON） timestamp: 时间戳 trace_id: 全局追踪ID }

其中trace_id是我强烈建议一定要加的字段。多智能体系统出问题时，排查链路会非常痛苦——没有trace_id你根本不知道一条消息经过了几个智能体、谁改了内容、谁产生了错误分支。有了它，至少能把整个流转过程拉出来看。

消息格式的规矩还包括不要让智能体用markdown表格当通信载体。我踩过坑：让执行者把统计结果用markdown表格返回来，结果上游解析的时候转义处理不当，数据直接错位。

3.2 三种主流协作模式：编排、协商、黑板

协作模式直接影响系统的复杂度和可控性。目前业界主流的就三种，我分别说下它们的使用场景和取舍。

模式一：编排（Orchestration）模式

一个中心化的协调者（Coordinator）负责任务拆解、分配和结果汇总。其他智能体都是"打工的"，接受任务就干活，干完就交差，彼此之间不直接通信。

这个模式是最容易落地、也最容易复现的。适合的任务类型是流程清晰、步骤有先后依赖关系的场景，比如：信息收集 → 分析 → 生成 → 审查。编排模式下协调者变成了系统瓶颈，但它带来的可控性值得这个代价——至少你知道问题的源头在哪里。

模式二：协商（Negotiation）模式

多个智能体地位平等，通过多轮交互达成一致结论。适合复杂的决策题，比如产品定价、方案评审。协商模式的效果上限高，但下限也低——模型之间会互相"客气"，A说"我觉得这个方案可行"，B说"我也觉得"，一轮就结束了，根本达不到讨论的效果。

想让协商有质量，必须在system prompt里写清楚"每个角色必须给出至少一个反对意见"。但你也要有心理准备：有时候会为了反对而反对，产出一些没有信息量的对抗内容。我一般只会在需要多样性视角时用协商模式——跨部门评审类的场景很合适。

模式三：黑板（Blackboard）模式

所有智能体共享一个"工作台"，各自往上面写信息、读取需要的信息，通过黑板完成隐性协作。这个模式适合子任务之间有信息依赖但依赖关系不固定的场景，比如一套复杂的文档生成任务，不同章节由不同智能体产出，但章节之间需要相互引用。

黑板模式最大的坑是状态管理。谁先写、谁后读、读到的是不是最新版本、冲突怎么解决，都需要额外设计。我做过一次实验，三个智能体同时往黑板上写内容，结果相互覆盖，最终产出的文档里有两段自相矛盾。从那以后我在黑板模式里加了行级锁——每段内容只能由Owner写入，其他智能体只能读。

3.3 决策机制：怎么收口才不算"假协作"

多智能体最经典的翻车场景是：几个智能体讨论了一轮又一轮，最后协调者自己拍板，完全没采纳讨论结果——这就是"假协作"。花了算力、花了时延，结果和单智能体没区别。

我把决策机制分了几个层次，按任务的确定性来选：

• 规则优先：任务结果可以用规则判断的，比如"数值是否在阈值范围内""日期是否合法"，直接走规则校验，不需要智能体讨论。这是性价比最高的决策方式，永远不要用模型去解决规则能解决的问题。
• 投票表决：适合分类型的决策。三个智能体各自独立给出判断，多数决定结果。投票前必须隔离信息，不能让它们先聊再投，否则会产生羊群效应。
• 层级仲裁：低层智能体产生分歧时，由更高层级的智能体做最终裁决。比如执行者说"数据缺失"，分析师说"数据存在"，那就让协调者重新拉取数据源做最终确认。
• 人在回路（Human-in-the-loop）：涉及高风险决策（金额、合同条款、医疗建议）时，把最终决定权交给人。多智能体的能力边界就在这里——它可以做评估、出建议、列方案，但负责任的保全必须回到人身上。

3.4 共享状态与记忆池：多智能体怎么"记住"事情

多智能体系统里，每个智能体的上下文窗口都是有限的，不可能也不应该让它们各自记住所有信息。我建议引入一个独立的共享状态层，存三类东西：

• 任务元数据：当前任务的全局状态、完成进度、当前处于哪个阶段。
• 领域事实：业务层面的常识性信息，比如产品列表、政策规则。这些信息应该由后台数据源统一提供，而不是让每个智能体各自维护。
• 中间产出物索引：每个智能体产出的中间结果存到对象存储里，共享状态里只放"索引"，要用的时候再捞出来。

这样设计有个明显的好处：某个智能体需要重启或者重新初始化时，它只需要从共享状态层恢复自己的上下文，而不需要其他智能体重发历史消息。

4. 从单智能体平滑迁移：不推翻重来，加一个路由层就够

说到多智能体，很多人第一反应是"要不要换个框架重新开发"。我的建议是：别急着推翻，先在单智能体和多智能体之间加一个路由层（Router），就能完成一半的迁移。

4.1 先想清楚：哪些任务必须多智能体？

不是所有场景都适合多智能体。我见过强上多智能体的项目，性能没提升，反而因为额外的通信开销让响应时间翻了三倍。我判断一个任务是否需要多智能体的标准：

• 强：任务涉及两种以上专业知识，单个模型的知识覆盖面不够。
• 强：任务有明确的阶段划分，不同阶段需要不同的处理逻辑。
• 强：任务的中间结果需要交叉验证，比如生成内容之后必须审查。
• 弱：任务流程简单、线性执行即可——这种直接用单智能体，别折腾。
• 弱：用户交互是单轮问答，上下文不需要多跳协作——单智能体加RAG就足够。

4.2 路由器的三种实现：PromptRoute、语义Route、可微Route

接入路由层，不必一上来就用多复杂的架构。我按工程复杂度从低到高用过三种。

第一种是简单规则路由。用分类提示词让模型为每个请求打标签——属于哪个域、需要几步处理、要哪些角色配合。然后根据标签把请求流转到对应的处理链路上。这个方式最简单，但也最容易出错——分类本身是一个语言理解任务，分类错了后面全歪。

第二种是嵌入语义路由（Semantic Routing）。把历史对话中的处理路径做成示例集，计算当前请求和历史示例的向量相似度，匹配最相似的路径作为处理方案。这个方式不需要模型做显式标签分类，而是直接匹配行为模式。我在客户意图识别上用这个方案，准确率比PromptRoute高了不少——因为"意图"本身就不止一种准确答案，语义相似更稳。

第三种是交叉编码器路由（Rerank / 交叉编码）。把当前请求和每条候选处理路径拼在一起交给交叉编码器打分，直接排序出Top1路径。这个方式准确最高，但每来一个请求都要做一次全量推理，成本也最高。适合对路由准确率极度敏感的场景，比如医疗分诊、法律咨询。

从单智能体迁移到多智能体的第一步，就是先实现一个"能判断单智能体是否够用"的路由器。超过阈值，才走多智能体链路。这个设计看着保守，但能让你平滑过渡——先让多智能体链路在部分流量上跑稳了，再逐步放开比例。

4.3 迁移过程中最容易踩的坑

我经历过一次迁移，当时把系统从单智能体升级到多智能体，上线客户反馈"变笨了"。排查下来发现原因很无语——迁移后，有些原本单智能体能直接回答的简单问题，被路由转到了多智能体链路，经历了一圈拆解、分配、汇总，中间任何一环的微扰都可能会被放大。这就是典型的"杀鸡用了牛刀"。

后续我在路由器里加了一条规则：凡是历史记录里单智能体已经能稳定回答的问题，直接走快路径，不进多智能体链路。快路径和慢路径并行，只有慢路径失败或者不满足置信度时才升级到多智能体。这个"渐进式升级"的策略，说实话比一开始就all in多智能体要稳得多。

5. 多智能体框架怎么选：Dify、AgentScope、ClawSwarm与自研的取舍

市面上的多智能体框架越来越多了，每个的宣传语都能把人看得热血沸腾。但框架选型必须回到自己的业务场景进行评估——没有一个框架是万能的。

5.1 Dify：低门槛平台化，适合先跑通逻辑

Dify现在支持多智能体编排，最大的优势是你不需要写太多代码就能把多智能体的"角色-任务-流转"搭出来。它的可视化编排界面很适合做MVP验证——你可以在半天内配出一个3个智能体的协作demo，验证角色分工逻辑是否合理。

但Dify的局限也很明显。一是编排深度有限，复杂的协商逻辑、自定义决策策略在界面上很难配置；二是状态管理能力比较弱，跨会话的状态恢复基本靠外部数据库自己维护；三是在自由度和约束力上都存在一定的框架成本——但作为起步阶段的验证工具，它真的能把时间压缩到极致。

我的建议是：拿Dify做原型验证，确认链路逻辑没有问题之后，再用代码框架做生产化封装。不要在一个低代码平台上试图构建一个超高复杂度系统——那不是平台的设计意图。

5.2 AgentScope：适合研究和团队协作模拟场景

AgentScope是阿里开源的智能体开发框架，它的特点在于消息传递机制设计得比较系统，提供了比较清晰的消息中间层和智能体通信原语。适合需要精细控制消息流的团队，比如做社会模拟仿真、多智能体游戏、复杂协商模式研究的场景。

AgentScope的优势是它的通信层与业务逻辑解耦得比较好——你可以先专注定义消息结构和流转协议，再把具体业务逻辑挂载到每个Agent上。这和直接在一个单体脚本里写死"Agents调函数"的方式相比，后期的可维护性高出一个量级。

5.3 ClawSwarm：高热度不等于高成熟度

ClawSwarm最近热度很高，网上都在讨论它"多智能体像蜂群一样协同"的概念。客观说，这类新兴框架的画面感很强，概念很有吸引力，但生产级可用性你需要自己验证。

我现在评估这类新框架的标准有三条：社区活跃度能不能支撑问题排查、文档是否覆盖到异常处理、有没有至少两个不同领域的真实案例。如果三条里占了至少两条，我会花时间做技术预研。如果只是个Demo或者README，那先等等，让浪潮先过去。

5.4 自研多智能体编排：什么条件下才值得自己造？

如果你面对的是强业务定制的场景——比如消息格式必须适配企业内部协议、状态管理必须对接已有的规则引擎和工单系统、协作流程必须满足审计要求——那自研一套轻量编排层完全合理。自研不等于从零开始，而是基于已有的LLM SDK（如LangChain、LlamaIndex）做编排层封装。

自研时先把通信协议、状态存储、任务队列这三个基础组件做扎实。我在第一阶段的项目里就是自研的协调层，核心代码量不到2000行，但把消息格式、角色注册表、任务状态机定义得足够稳健，后面扩展新角色的时候基本没动过核心结构。

6. 实测中暴露的多智能体协作故障：完整排查链路与解法

多智能体的坑，只有真正跑过才敢说自己懂。这部分我写五个我在生产环境里真实出现过的问题，每个都附上排查思路和最终解法——这些都是文档里不会写的。

6.1 故障一：智能体A等智能体B，B等A——隐式死锁

现象：任务进入多智能体链路后就卡住不动了，超时后才报错。看日志发现，协调者等执行者返回，执行者在等协调者确认"下一步做什么"。

排查链路：先从任务队列的pending状态发现任务卡在"等待响应"阶段。查消息流，发现协调者和执行者互相发了一条request类型的消息，处于互相等待状态。底层原因：协调者发出的"任务指令"消息在执行者看来是一条"需要确认"的消息，双方都在等对方"回话"。

解法：两层修复。第一层是在消息协议里明确request的响应语义——协调者发的request，执行者只需要回response，不需要回request；第二层是给所有协作任务加watchdog超时机制，超时未完成的自动上报并降级到单智能体链路。这两层缺一不可，协议层解决根因，超时层兜底防护。

6.2 故障二：讨论轮数失控导致时延爆炸

现象：协商模式下，三个智能体讨论一个"方案选型"问题，你来我往讨论到第五轮还在继续。单轮响应要8秒，五轮就是40秒，用户早走了。

排查链路：查协商机制的终止条件，发现代码里写的是"当所有智能体都达成一致或达到最大轮数（10）时终止"。但并没有对"达成一致"的定义做约束——模型很容易在最后补一句"我同意"，就算达成了；而如果它们不想同意，就能无限讨论。

解法：设定协商硬性规则——最多三轮，每轮必须有新增信息或者明确反对，否则提前终止。用投票表决替代过度讨论：三轮内若无法收敛，就交由最高层级仲裁人决策并结束流程。在协议上先约束"讨论深度"，再谈"讨论质量"。

6.3 故障三：审查者永远"通过"，审查机制失灵

现象：审查者角色上线后，拦截率几乎是0。一开始以为是内容质量太好，后来发现是审查者的prompt写得跟"鼓励者"似的——"请对结果进行审核，给出改进建议"。模型把这个当成了一次无监督的对话练习，干的全是领导式点评。

排查链路：构造了一批明显有错的测试案例丢进系统，审查者全部通过。进一步检查发现，审查者输出的是"建议"而不是"结论"。

解法：把所有审查类的智能体prompt统一改成"结论先行"格式，要求输出必须是"通过/不通过"二选一，必要时附带违规原因清单。这是我又一个"三个一"原则的体现——一个出口，不通过就是不过。加上这个约束之后，审查拦截率从0%升到大约15%，有实际价值了。

6.4 故障四：上下文漂移导致执行者忘掉最初目标

现象：执行者连续处理多轮协作后，开始执着于"自己的当前步骤"而忽略"任务的最终目标"。比如协调者最初要求"只提取结构化数据，不要评论"，执行者在处理到第三轮时输出了一大段评价性文字。

排查链路：翻执行者的输入序列，发现它的上下文里塞满了中间轮次的对话消息——协调者的确认、另一个智能体的历史输出、自己之前的中间结果。而最初的system prompt（"只提取数据，不评论"）已经滑出了有效上下文范围。

解法：两条路并行。第一，执行者的prompt里把关键任务指令放在最后，避免被中间长文本挤出上下文窗口——大模型对末尾内容的关注度通常更高；第二，把"任务级约束"写入共享状态层，在执行者准备生成输出前主动调用一次约束校验，不依赖模型自身的"记忆力"。

6.5 故障五：多智能体让情绪化表达被"传染"

现象：用户在输入中表达了不满情绪（"你们这服务太差了！"），结果协调者、执行者、审查者每个角色的回复都带着道歉的语气，最终输出反而失去了专业感。

排查链路：看消息流转时发现，用户输入的原始情绪文本被原封不动地传递给了每个角色。每个角色都在试图处理"情绪"而不是"业务"。

解法：在路由层做一次情绪剥离——把用户输入拆分为"事实"和"情绪"两部分，事实走业务流程，情绪单独进入客服安抚话术模块。业务链条里的智能体不再接触原始情绪信息，角色的专业度就保住了。

7. 从分工到协同的落地路径：先闭环，再横向扩列

多智能体系统的落地，最忌讳的是一步到位。如果一开始就规划10个角色、5层协作、全自动决策，大概率上线即爆炸。我的建议是遵循"最小闭环 → 横向复制 → 纵向优化"三个阶段。

7.1 第一阶段：跑通一个最小闭环

选一个单一业务场景，配置2到3个角色。比如最早我做的客服工单处理闭环：工单分诊 → 处理 → 质检，三个角色互相配合，全部消息走日志，所有人能实时看到每次协作的过程。这个阶段的目标不是性能，是把消息格式、状态流转、失败处理这套基础设施磨稳定。

7.2 第二阶段：横向扩列

最小闭环稳定跑了两周以上，再开始加角色。加角色的原则是一次只加一个。加之前先在影子模式（Shadow Mode）下跑一段时间——新角色和旧系统的输出并行，比较两者的质量差异，确认新角色确实比没有它强，再让流量切过来。

7.3 第三阶段：纵向优化

当角色数量超过5个时，重点转向优化协作质量：训练路由器的分配策略、优化决策收敛机制、建立更细粒度的监控面板。到这一步时，你对整个系统的理解会比任何框架文档都深刻——因为每个角色、每条消息、每个流转都是自己从零养出来的。

所以回到标题那句话：多智能体的核心，不在于你有多少个智能体，而在于你如何定义角色、设计沟通方式与协作流程。分工是骨架，协作才是血肉。先把这两件事想透，再决定用哪个框架、写多少代码——这个顺序决定你项目的天花板。