企业官网建设流程全解析

我的很多读者朋友都发现，身边越来越多人在谈“智能体”，但大家嘴上说的是同一个词，脑子里想的可能完全是两码事。有人拿智能体做了一个简单的问答机器人，有人搞了一套多角色协作的写稿系统，还有人把智能体嵌进了公司审批流程里当“自动执行节点”——它们都叫智能体，但架构思路、开发方式、踩坑方向截然不同。这篇文章我想把最具代表性的三种智能体范式拆开来讲清楚，它们分别是：单体自主决策式、多智能体协作式、工作流编排式。你不需要一次性掌握全部三种，但至少要知道自己正在做的是哪一种，以及为什么要选它。

这个区分之所以重要，是因为智能体项目失败的原因，往往不是模型能力不够，而是范式选错了。有人用多智能体解决一个本该用单体就能解决的问题，结果token成本翻了十倍；有人用单体智能体处理强流程业务，结果每次运行都要重新调参、结果不可控。我希望这篇文章能让你少走这些弯路。

1. 为什么要聊智能体范式

先承认一个事实：智能体这个词，已经从技术术语变成了营销词汇。产品经理会说“我们这个平台支持智能体”，前端工程师说“我这个页面里调用了智能体”，算法工程师说“我这个Agent的ReAct循环还在优化”——大家用的词是一样的，可实际做出来的东西从结构到能力都完全不在一个量级。

1.1 先给“范式”这个概念祛魅

范式这个词听起来高深，实际上很简单：它回答的是三个问题——决策逻辑落在哪里、记忆放在哪里、反馈从哪里来。你把这三个问题的答案确定下来，你的智能体属于哪种范式就清楚了。

单体自主决策式智能体的答案很直接：决策逻辑放在一个大模型的推理回路里，记忆通常就是上下文窗口，反馈来自工具执行结果或外部环境。多智能体协作式把决策权分散给多个角色，每个角色有各自的记忆和职责，反馈通过角色间的消息传递。工作流编排式则把决策逻辑拆解成多个固定的节点，智能体只负责其中一部分节点的推理，其余节点由规则、人工、普通代码来接管。

这三种答案没有优劣，只有适合不适合。我在某公司做技术顾问时遇到过一件事：对方说要做“一个能自动处理售后工单的智能体”，结果他们内部已经跑了两套方案——一套是让大模型全程自主处理，另一套是人工先分类再交给模型处理。两套方案都叫智能体，但前者是单体范式，后者更接近工作流范式。如果硬把前者改成后者或者反过来，都会导致项目推倒重来。

1.2 三种范式各自的生存空间

单体范式适合什么？适合目标是“开放探索型”的场景：用户丢一个模糊需求，智能体自己研究如何完成。比如让它去网上搜集竞品资料、写一份对比分析，或者让它自动排查一段代码的Bug。这类任务的共同点是结果不确定、路径不固定，需要智能体自由发挥。

多智能体范式适合任务本身可以被拆成多个视角的场景：写一篇文章需要策划、写作、审校三个角色；做一个复杂决策需要“提出方案的人”和“挑毛病的人”同时存在。这种范式的优势在于“冲突产生质量”——不同的角色互相纠偏，比单个智能体自问自答更能暴露问题。

工作流范式适合流程必须确定的业务场景：订单处理、工单分派、内容审核、合规检查，每一步都有明确的输入输出边界，智能体只是流程里的一个环节，承担自然语言理解、内容生成这类“人话”和“机器数据”之间的翻译工作。

看到没有，这三种范式适用的任务类型是互相错开的。你把它们理解成三种武器，而不是一条进化路线，就不会选错了。

2. 范式一：单体自主决策式智能体

单体自主决策式是目前讨论度最高、做的人最多的范式。一个模型、一个系统提示词、一套工具集，让这个智能体自己去完成目标。它结构简单，但因为简单而显得特别神秘——你给它一个目标，它自己拆解、自己运行、自己迭代，直到完成或失败。

2.1 单体范式是怎么转起来的

几乎所有单体智能体的底层都是同一个循环逻辑，核心思路叫ReAct，也就是推理和行动交替进行。智能体先根据已有信息思考“下一步应该做什么”，然后调用工具去执行，观察执行结果后再次思考、再行动。这个循环一直持续到目标完成或达到某个终止条件。

用伪代码写出来大概是这样的：

while not task_finished: thought = llm_think(current_context) # 推理：下一步做什么 action = parse(thought) # 解析出具体的动作 result = execute_tool(action) # 执行工具并拿到观察结果 current_context += result # 把结果加入上下文

这个循环看起来平淡无奇，但工程落地时会冒出一堆细节问题。举个最常见的例子：循环怎么终止？很多第一次做单体智能体的人都会忽略这个设计，结果智能体在某个子任务上反复重试，永远不结束。正确的做法是在系统提示词里明确写清楚“当目标完成时，必须输出最终答案”，并且代码层面还要加一个最大迭代次数兜底。我曾经见过一个项目没有设置迭代上限，模型在一个API返回错误格式的BUG上重试了四十多次，把预算烧掉了一大截才发现问题。

2.2 实践中的关键设计选择

单体范式里，系统提示词的作用再强调也不过分。这个范式没有多角色、没有外部流程，模型唯一的行为指南就是那段提示词。写提示词时要做到三点：角色清晰、目标明确、边界清楚。

所谓角色清晰，是告诉模型“你现在是一个什么样的助手，负责什么，不负责什么”。目标明确，是要把衡量“完成”的标准写出来。边界清楚，则要告诉它“遇到什么情况应该停下来问人，什么情况可以直接猜测继续做”。这三点分开说很简单，但合在一起工程化时，效果差异非常明显。

工具描述同样关键。单体智能体每次调用工具前，模型需要根据工具的名称和描述来决定用哪把工具。如果你的工具描述写得太模糊，模型常常会选错。我习惯的做法是在每个工具描述里加上三个部分：这个工具做什么、输入的格式要求、输出的大致形态以及常见错误。比如一个查询天气的工具，不要只写“获取天气信息”，而要写“输入城市名，返回该城市当前天气和未来三天预报，如果城市不存在返回错误码404”。

还有一个细节容易被忽略，就是上下文的管理。单体智能体在循环过程中，每执行一次工具调用，观察结果就要写回上下文，几轮之后上下文就可能堆得很长。虽然长窗口模型越来越多，但更实用主义的做法是定期让模型把历史结果“压缩”成一句话摘要，再继续后续推理。我实测下来，把超过5轮的历史做一次摘要，不仅能控制成本，还能让模型的注意力更集中，幻觉率反而下降。

2.3 单体范式的好处和暗坑

先聊好处。单体范式最大的优点是灵活，它的推理回路可以适应各种意外情况。你不知道用户会问什么方式的问题，不知道外部工具会返回什么格式的数据，没关系，只要模型够聪明、提示词写得够细，总能绕回来。对于任务结果不固定、输入形式千差万别的场景，这个优势是其他范式很难替代的。

其次是调试简单。因为只有一个决策主体，你只需要把它的推理日志打出来，就能看清楚每一步是依据什么做的判断。我调试单体智能体时常用的套路是：让模型在输出动作前，先输出一段100字以内的“思考过程”，这些过程写到日志里。一旦结果不对，翻日志就能定位问题出在“没找到合适的工具”还是“工具返回的数据理解错了”。

暗坑也不少。最大的暗坑是“单点脆弱”。模型一旦在某个环节产生了幻觉，后面所有依赖这个环节的判断都会跟着出问题。比如它错误地认为某份文件已经保存成功，后续动作全都会建立在错误前提上。对这种问题我的对策有两个——一个是前面说的工具描述写清楚，让错误更容易被发现；另一个是在提示词里强调“每一步行动之前，都要先确认前置条件是否满足，如果无法确认，必须先查证再做”。

另一个暗坑是成本不可控。单体智能体在一次真实任务里的调用次数，往往远超你的预估。特别是当任务比较开放时，模型会自己延伸出很多“自作主张”的工具调用。我习惯在开发阶段把所有工具调用的日志完整记下来，跑完一轮之后回看哪些调用是无意义的，然后针对这些无意义调用在提示词里加上禁令。

3. 范式二：多智能体协作式智能体

多智能体协作式是这三年来最出圈的一种范式。它的基本思路是：用多个智能体角色，每个角色有独立的系统提示词、独立的任务目标和独立的工具权限，它们之间通过消息传递来协作，共同完成一个复杂目标。

这种范式的一个典型做法是模拟一个小团队——策划、执行、审查各司其职。不同的角色因为立场不同，会给出不同的判断，最终经过几轮“讨论”得到一个更稳健的结果。它不像单体智能体那样靠一次推理堆到底，而是靠反复互动来逼近目标。

3.1 三种常见的协作方式

多智能体协作并不是只有一种形态，常见的至少有三种。

第一种是主管分配式。一个主管智能体不干活，只负责分析任务、拆解步骤、把子任务分配给下游的具体执行智能体。执行智能体完成任务后把结果返回给主管，由主管决定是否继续分配、是否汇总出最终结果。这种方式的优点是分层清晰，适合任务边界相对明确的场景。

第二种是平等辩论式。几个智能体角色处于同等地位，针对同一个问题各自提出方案并互相质疑。比如甲方智能体提出一个方案，乙方智能体负责找漏洞，经过几个回合之后，由一个裁判智能体决定最终采用哪个版本。这种方式的优点是质量高，适合需要强校验的内容生成或决策分析，缺点是token消耗非常大。

第三种是流水线式。每个智能体处理一个环节，前一个的输出是后一个的输入，不回头、不重叠。它和多智能体其实已经不太像团队，更像一条流水线。这种方式的优点是速度快、可预期性强，缺点是后续环节无法修正前面产生的错误。

你可以根据自己任务的特性选择协作方式。如果是步骤明确的任务，用流水线式；如果任务需要多轮打磨，用辩论式；如果任务是“目标只有一个但路径不明”，用主管分配式更合适。

3.2 角色设计和通信机制

多智能体范式最核心的工作，是角色设计和通信机制。

角色设计要避免一个经典误区：让每个角色都拥有“全知视角”。换句话说，不要把所有信息都塞给每个智能体。角色A只需要知道自己的岗位职责和当前任务，不需要知道角色B的内部逻辑。这样一方面能减少干扰信息，另一方面也在客观上形成了“信息隔离”，逼着智能体之间通过正常的消息沟通来交换必要信息，而不是每个人都知道所有事还能假装协作，实际上各干各的。

角色提示词的写法也和单体不同。多智能体的每个角色提示词要包含三块内容：你是谁、你的输出格式是什么、你的限制是什么。限制尤其重要，比如“你是执行者，只负责执行主管分配下来的任务，不要自主新增需求”这种话，能有效防止角色各自发散产生混乱。

通信机制方面，最简单易行的做法是结构化消息。所有角色间的传递都用统一的JSON格式报文，包含发送者、接收者、消息类型、内容、附带数据。比起让模型自由发挥用自然语言对话，结构化消息有两个好处：一是机器层面好处理，能做校验和路由；二是能有效限制模型输出的信息范围，避免它在一句话里塞进大量无关内容。

还有一点，通信里必须设计“终止机制”。多智能体系统最容易出现的问题就是“聊起天来没完没了”。我见过一个三智能体讨论系统，两个角色因为互相质疑僵持了九轮，还没得出结论。解决办法是在系统提示词里约定最大讨论轮数，达到轮数后无论是否达成一致，由最后收尾的那个角色直接做决定。

3.3 多智能体系统的坑和调试

多智能体的第一个大坑是成本失控。每个角色都在调用模型，单轮讨论消耗就是单体的数倍。所以我在设计多智能体系统时，第一件事不是调角色提示词，而是先做一个“成本预演”：把任务跑一遍，看每个角色的调用次数，然后再决定哪些角色可以合并、哪些环节可以砍掉。

第二个大坑是责任定位困难。单体智能体出了问题，翻日志就能定位；多智能体系统出了问题，可能需要同时看几个角色的日志，还要把消息流转的时序拼起来。为了降低定位难度，我坚持要求每个角色在发送消息时带上自己的“决策摘要”——这个摘要说明我为什么发这条消息、依据是什么。这样出问题时，能快速定位到是哪个角色在哪个环节产生了错误理解。

第三个大坑是信息衰减。无论用结构化消息还是自然语言，消息在多次传递中都会丢失细节。第一环的执行者输出了一份10页的分析，传了三手之后，最后一个汇总角色可能只剩下一句“该方案可行”。如果最终结论严重依赖某个细节，这个细节很可能已经丢了。我的处理办法是：重要的中间结果必须附上原文链接或完整数据文件的引用，不允许只传摘要。

调试多智能体系统，我强烈建议从“两个角色”起步，先把这两个角色之间的逻辑理顺，再逐步增加角色。一次上线太多角色，出了问题根本没法查，因为变量太多了。我自己踩过这个坑，当初一次性上了五个角色，结果系统跑出来的结果莫名其妙，后来只能逐个角色禁用去排查问题，白白浪费了不少时间和预算。

4. 范式三：工作流编排式智能体

工作流编排式是我前几年在企业落地项目中最常负责的一种范式，也是被大多数技术爱好者低估的一种。它既不追求“模型自主决策一切”，也不追求“多个智能体互相对话”，而是把智能体当作整个业务流程中的一个环节——该调模型的时候调模型，该走规则的时候走规则，该等人工确认的时候就必须停下来等人。

它的本质，是现代软件工程里的状态机与工作流引擎和大模型能力的融合。

4.1 从Agent到工作流：状态机视角

你把任何一个业务需求画成一条流程图，它天然就是一个状态机：每个节点是一个步骤，节点之间有明确的迁移条件。传统实现里，节点里跑的是固定代码；工作流编排式智能体的区别，是让其中一部分节点由智能体来承担。

举一个实际例子。一个采购申请审批流程，通常有几个节点：提交申请、系统预检、主管审批、财务复核、执行采购。在传统系统里，预检节点全靠写死的规则判断，比如金额是否超预算、物品是否在目录内。如果你用工作流智能体范式来改造，预检节点可以变成一个智能体节点——它读取采购申请的自然语言描述，自动判断申请内容是否合规、是否需要补充材料，然后给出预检结论。

而其他节点，比如主管审批，仍然是人工节点；执行采购，仍然是代码自动触发。你会发现，智能体在这里并不是整个系统的“大脑”，它只是一个更聪明的“节点处理器”。这种设计有另一个好处，就是业务人员自己也能看得懂整个流程，因为流程图画的还是原来那张图，只是把某个节点的实现换掉了。

工作流编排式的核心，是把“控制权”留在程序手里，把“判断权”部分地交给模型。从状态机的视角看，模型的每次调用只是一个会产生输出并且在输出之后决定下一步迁移的事件。它不会像单体智能体那样自己循环探索，因为循环和跳转逻辑都被写死在流程里了。

4.2 实现工作流编排式智能体的关键点

第一，状态持久化。工作流式系统通常要跑几天甚至几周，中途可能有大量等待节点。智能体的运行状态、中间结果、工具调用的上下文都必须落库，不能只靠内存。否则进程一重启，整个流程状态就丢了。我一般把Agent状态存储设计成一张表，字段包括流程实例ID、节点ID、输入参数、输出结果、状态、重试次数、最后更新时间。

第二，明确的节点输入输出约定。传统流程里，每个节点的输入输出都由代码定义好；智能体节点也必须这样。你要给这个节点定义一个输入Schema——它接收哪些字段，字段类型是什么；再定义一个输出Schema——它必须返回哪些字段。智能体输出的JSON必须经过强校验，不符合Schema要求的直接让模型重试，而不是抱着“反正格式差不多能用就行”的心态往下走。

第三，人工确认节点不能省。很多做智能体的人有个冲动，希望全流程全自动，把人工环节全部去掉。但在企业落地场景里，这是最危险的想法。模型确实能处理大量常规情况，但涉及金额、合规、对外承诺这类高影响动作时，必须保留人工审批节点。不要为了“看起来很智能”而删掉这些安全阀。

第四，重试与失败处理。智能体节点不是每次都能成功，模型可能输出超时、格式错误、内容不合格。所以工作流引擎里一定要设计重试策略，比如最多重试3次，每次间隔30秒，超过次数进入人工处理分支。没有这套兜底机制，工作流会因为一个节点的失败卡死整个实例。

4.3 工作流编排和另一种可选对比

工作流式与多智能体式的最大区别在于“谁掌控流程”。多智能体式的流程是涌现出来的，你只给了角色和初始目标，它们之间的协作顺序是动态的，事前不可预测。工作流式的流程是预设的，所有节点和迁移条件在运行前就已经定义好了。

所以，如果你的业务需要强可控性，需要流程审计记录，需要明确每个环节的输出可靠，“工作流编排式”就是底线。反过来，如果你的目标本身高度开放，连你自己都不知道该怎么拆步骤，那你就不适合用工作流把它框死，用单体或几个智能体先探索，再考虑沉淀为流程。

在我的实践中，一个常见的做法是先用单体智能体快速试跑整个任务，看它的自然行为和拆解逻辑，然后把其中最稳定、最频繁出现的路径，固化成一个工作流节点。这是从探索到工程化的自然演变路径。我不建议一上来就画一个完整的智能体工作流图，因为你还不了解模型在处理具体任务时有哪些失败模式，画的流程大概率是错的。

5. 三种范式的选型建议与组合策略

很多读者会问：既然三种范式各有利弊，那到底怎么选？我的回答是，不要拿范式当信仰，拿它当手段。一个成熟的智能体系统，往往不是纯某一种范式，而是几种范式的组合。

5.1 按任务特性维度来选型

看这个任务的结果是否可预期：如果结果形态是开放的，你无法预设路径，优先考虑单体或小规模多智能体；如果结果形态是固定的，输入输出字段都能定义得很清楚，优先考虑工作流。

看任务需要的质量从哪来：如果质量来自反复校验、对抗性讨论，用多智能体辩论式；如果质量来自“一个靠谱的角色一步一步做”，用单体配好工具即可。这里有一个经验数据，两个角色的比对一个角色的质量提升，通常不如成本提升的幅度大，所以不要为了质量盲目上多角色。

看系统的容错度：如果是面向消费者的产品，偶尔出点小错可以接受，单体自主式效率高；如果是企业生产环境，一次错误可能导致连锁后果，那必须用工作流范式，把高风险动作拆出来加人工节点。

5.2 工程层面的一些实在建议

预算有限时，优先做单体。把一个单体的提示词、工具、迭代逻辑打磨到稳定，远比搭建一个豪华的多智能体系统更划算。很多业务问题，通过优化单体提示词就能解决，不需要叠角色。

需要快速上线时，也优先做单体。单体系统的开发周期最短，调试最快，上线后边跑边迭代都很方便。多智能体系统一旦角色多了，调试时间是指数增加的，不适合快速验证。

需要稳定演进时，用组合策略。我的标准做法是“工作流打底、单体做节点、必要时多智能体做高难环节”——主流程跑工作流引擎，控制方向；流程里某些确实需要理解自然语言的节点，内嵌一个单体智能体；当某个节点需要特别高质量的分析，再在这个节点内部临时拉起一个两角色的多智能体讨论，得到结论后关掉。

5.3 一张表说清差异

这张表是我自己的经验总结，不一定适用所有项目，但大部分情况下可以用来做初步判断。

最后分享一个我自己的项目体会

前两年我负责一个供应链数据分析的项目，最初方案是用一个多智能体系统——一个角色负责查数、一个角色负责分析、一个角色负责写报告。结果跑完一轮demo，光是中间的沟通开销就把模型调用量推得很高，而且三个角色之间的信息传递总是缺关键字段，后期调试极其痛苦。后来我换了个思路：主流程用工作流编排，把“查数据”和“生成报告”拆成两个独立节点，各自内嵌一个单体智能体；只有分析这一环，因为结论质量要求高，临时拉起两个角色做一次小规模辩论。最后系统跑得稳定，成本也降下来了。做完这个项目我才真正相信：范式是工具箱，不是擂台，没必要厚此薄彼。

我希望你在读完这篇文章后，下一次再有人问你“你做的智能体是用哪种范式”时，你能不只是说“用了智能体”，而是能讲清楚它属于哪种范式、为什么选它、它有哪些局限。如果你正在切换或组合另一种范式，欢迎在评论区说说你的选型理由和踩坑经验，我也很期待看到不同领域的真实案例。