企业官网建设流程全解析

1. 别被概念带偏：多智能体和工作流到底在争什么

这两年AI圈有个特别有意思的现象，只要聊到Agent落地，十个人里有八个会跟你提“多智能体协作”。什么角色分工、什么圆桌会议、什么互相评审，听起来就像给AI组建了一支梦之队，仿佛只要把几个Agent凑在一起，它们就能自己商量着把活干完。但真到了项目交付的时候，你会发现一个很尴尬的事实：那些跑得最稳、维护成本最低、老板最满意的系统，往往不是什么多智能体架构，而是一条老老实实的工作流。

我先把结论撂在这儿：大多数业务场景，工作流就够了，而且比多智能体更靠谱。这不是说多智能体没价值，而是说它的适用边界比很多人想象的要窄得多。你如果正在纠结要不要上多智能体，或者已经被各种“Agent协作机制”的概念绕晕了，那这篇内容就是写给你的。我会从实际项目出发，把工作流和多智能体的本质区别、选型逻辑、落地细节、踩坑经验全部拆开讲清楚，让你看完就能判断自己手里的活到底该用哪种方案。

先对齐一下基本概念，不然后面聊起来容易鸡同鸭讲。工作流，说白了就是一条预先定义好的执行路径：第一步做什么、第二步做什么、什么条件下走哪个分支、每一步调用什么工具或模型，全都是你提前编排好的。它本质上是一张流程图，只不过这张图能被代码执行。你在Coze、Dify、扣子这些平台上拖拖拽拽连出来的东西，就是典型的工作流。多智能体，则是把任务拆给多个具有自主决策能力的Agent，每个Agent有自己的角色设定、工具集和记忆，它们通过某种协作机制（比如消息传递、共享黑板、投票仲裁）来共同完成任务。关键区别在于：工作流的控制权在你手里，多智能体的控制权在Agent自己手里。

这个区别听起来很学术，但落到实际项目里，它直接决定了你的系统是“可预测”还是“开盲盒”。工作流你跑一百遍，只要输入一样，输出基本一样，出了问题你能精确定位到是哪一步的哪个参数配错了。多智能体你跑一百遍，可能给你一百种不同的执行路径，有时候结果惊艳，有时候直接跑飞，排查问题像破案。我见过太多团队一开始被多智能体的“智能感”吸引，搭了个花架子，最后因为稳定性问题又灰溜溜地退回工作流。

所以这篇文章的核心就一件事：帮你建立一套判断标准，知道什么场景该用工作流，什么场景才值得上多智能体，以及如果用了工作流，怎么把它搭得足够健壮。我会用简历筛选、内容生成、数据处理这几个典型场景来举例，这些都是热词里反复出现的，也是实际需求最集中的地方。

2. 工作流的底层逻辑：为什么它才是大多数场景的最优解

2.1 工作流的本质是确定性编排

工作流的核心价值就两个字：确定。你定义好节点和连线，系统就按这个顺序执行，不会自作主张。这听起来好像不够“智能”，但恰恰是业务系统最需要的品质。你想想，一个简历筛选流程，你需要的是它每次都用同样的标准去判断候选人，而不是今天觉得这个人不错明天又觉得不行。一个数据清洗流程，你需要的是它每次都按同样的规则处理异常值，而不是自己发明一套新规则。

工作流的确定性来自它的结构。一个典型的工作流包含这几类节点：输入节点负责接收数据，处理节点负责调用模型或工具做具体操作，条件节点负责根据结果走不同分支，输出节点负责汇总结果。节点之间的连线定义了数据流向和执行顺序。整个结构是一张有向无环图，不会出现循环依赖，也不会出现某个节点突然决定要跳过前面几步直接执行后面的。

这种结构带来的好处是可调试性极强。任何一个节点执行完，你都能看到它的输入是什么、输出是什么、耗时多少、有没有报错。如果最终结果不对，你可以沿着链路一步步往回查，很快就能定位到问题节点。而多智能体系统里，Agent之间的消息传递是动态的，你很难复现它当时的决策上下文，排查起来非常痛苦。

2.2 工作流能覆盖绝大多数业务需求

很多人低估了工作流的能力边界。他们觉得工作流就是简单的“A到B到C”，做不了复杂逻辑。但实际上，现代工作流引擎支持的能力已经非常丰富了。条件分支、并行执行、循环迭代、子流程调用、人工审核节点、异常重试，这些都能在工作流里实现。你甚至可以在工作流里嵌入代码节点，写一段Python或JavaScript来处理复杂逻辑。

拿简历筛选这个场景来说，一条完整的工作流可以这样设计：简历解析节点提取关键信息，条件节点判断学历是否达标，并行节点同时做技能匹配和经历匹配，汇总节点计算综合得分，最后根据得分走不同的分支——高分直接进入面试邀约流程，中等分进入人工复核队列，低分自动归档。整条链路清晰可控，每个环节的规则都是你定的，不会出现“AI觉得这个人还行但说不出为什么”的情况。

再比如内容生成场景，工作流可以做到：先调用模型生成大纲，再根据大纲逐段生成内容，然后调用另一个模型做事实核查，最后做格式化和敏感词过滤。每一步的输入输出都是明确的，你可以在任何一步插入人工审核，也可以在任何一步做缓存来节省成本。这种精细控制是多智能体很难做到的。

2.3 工作流的成本优势被严重低估

聊技术选型不能只聊能力，还得聊成本。工作流的成本优势体现在三个方面：开发成本、运行成本、维护成本。

开发成本上，工作流有大量现成的平台和工具，Coze、Dify、扣子这些都提供了可视化编排界面，拖拽连线就能搭出一个可用的流程。你不需要写复杂的Agent通信代码，也不需要设计协作协议。一个熟悉业务的人，培训几天就能上手搭建。而多智能体系统，你需要定义每个Agent的角色、能力、工具、记忆机制、通信协议，开发周期至少是工作流的三到五倍。

运行成本上，工作流每一步调用什么模型、传多少token都是你控制的。你可以给简单任务配便宜的小模型，给复杂任务配贵的大模型，整体成本可控。多智能体系统里，Agent之间会互相发消息、互相评审，token消耗量往往是工作流的几倍甚至十几倍。我实测过一个内容审核场景，同样的任务，工作流方案每次消耗约2000 token，多智能体方案因为要多个Agent反复讨论，每次消耗接近15000 token，成本差了七倍多。

维护成本上，工作流的修改非常直观。业务规则变了，你改一个条件节点的判断逻辑就行。多智能体系统里，你改一个Agent的提示词，可能会影响它和其他Agent的协作效果，牵一发而动全身。而且Agent的行为是概率性的，你今天改完测试通过，明天可能又出现新的边界情况。

2.4 什么时候工作流会不够用

当然，工作流也不是万能的。它的短板在于处理高度不确定的任务时比较吃力。什么叫高度不确定？就是任务的执行路径无法提前穷举，需要根据中间结果动态决定下一步做什么，而且这个决定需要理解语义、权衡多个目标。

举个例子，你让系统“帮我调研一下竞品最近三个月的动态，整理成报告”。这个任务里，“调研”本身就是一个开放性的动作，可能需要搜索新闻、查看社交媒体、分析财报、对比产品更新，具体走哪条路取决于你搜到了什么。这种场景工作流就很难提前编排，因为你不知道会遇到什么情况。多智能体在这种场景下就有优势，它可以有一个“规划Agent”先分析任务，然后动态决定调用哪些“执行Agent”。

但注意，这种场景在真实业务里的占比其实很低。大多数企业级应用，任务边界是清晰的，规则是可枚举的，只是步骤多、环节杂。这种“复杂但确定”的场景，恰恰是工作流的主场。

3. 多智能体的真实面目：它强在哪，又坑在哪

3.1 多智能体的核心机制拆解

多智能体系统不是简单地把几个Agent放在一起，它背后有一套协作机制在支撑。常见的协作模式有几种：消息传递式，Agent之间通过发送消息来协调，比如一个Agent完成任务后把结果发给下一个Agent；共享黑板式，所有Agent读写同一个共享空间，通过观察黑板上的内容来决定自己做什么；市场竞价式，任务被拆成子任务后，Agent们竞标认领；投票仲裁式，多个Agent对同一个问题给出答案，然后投票决定最终结果。

这些机制听起来很美好，但每一种都有它的代价。消息传递式需要设计消息格式和路由规则，消息多了容易乱；共享黑板式需要解决并发读写冲突，还要防止某个Agent把黑板写爆；市场竞价式需要设计合理的激励机制，否则Agent可能都不愿意接难活；投票仲裁式需要保证Agent的多样性，如果所有Agent都用同一个模型同一个提示词，投票就没有意义。

3.2 多智能体真正适用的场景

多智能体不是没有用武之地，但它的适用场景确实比较特定。我总结下来，主要有三类：

第一类是任务路径高度不确定的探索型任务。比如前面说的竞品调研，或者学术文献综述，或者复杂问题的头脑风暴。这类任务没有标准答案，需要不断尝试和调整方向，多智能体的动态规划能力就能派上用场。

第二类是需要多视角交叉验证的高风险决策。比如医疗诊断辅助、金融风控评估，单个模型的判断可能有偏差，让多个Agent从不同角度分析再综合，能提高准确率。但这类场景对可解释性要求极高，多智能体的黑盒特性反而可能成为障碍。

第三类是需要模拟多方博弈的场景。比如谈判策略模拟、市场供需模拟，多个Agent代表不同利益方进行交互，能产生更丰富的策略空间。但这更多是研究性质的应用，生产环境里很少见。

除了这三类，其他场景我建议优先考虑工作流。特别是那些流程固定、规则明确、对稳定性要求高的业务系统，多智能体带来的不确定性往往是负资产。

3.3 多智能体的隐性成本清单

很多人只看到多智能体的“智能”，没看到它背后的隐性成本。我列一个清单，你对照自己的项目看看能不能承受：

• 调试成本：Agent的行为是概率性的，同一个输入可能产生不同输出。你很难复现一个bug，因为下次运行可能就不出现了。排查问题需要记录大量的中间状态，对日志系统要求很高。
• 测试成本：工作流可以写单元测试，每个节点单独测。多智能体系统很难做单元测试，因为Agent之间的交互是动态的，你只能做端到端的集成测试，而且测试用例很难覆盖所有分支。
• 成本控制：Agent之间会互相调用，token消耗量不可预测。你可能设了预算上限，但某个Agent突然决定要“深入分析”，一下就把预算烧完了。
• 安全风险：多个Agent互相通信，如果某个Agent被恶意输入影响，可能会通过消息传递把影响扩散到整个系统。工作流里每个节点的输入输出都是隔离的，风险可控得多。
• 人才要求：搭工作流，一个懂业务的工程师就能干。搭多智能体，你需要懂Agent架构、通信协议、提示词工程、分布式系统的人，这种人不好招也不好留。

3.4 一个真实的选型翻车案例

去年我参与过一个电商客服系统的选型。团队一开始特别兴奋，想用多智能体做一个“智能客服团队”：一个Agent负责理解用户意图，一个Agent负责查订单，一个Agent负责处理退换货，一个Agent负责安抚情绪，还有一个“主管Agent”负责协调。听起来很完美对吧？

实际跑起来问题一大堆。用户问“我上周买的鞋子什么时候到”，意图理解Agent判断为“物流查询”，但查订单Agent需要订单号，用户没提供，于是它去问意图理解Agent，意图理解Agent又去问用户，用户觉得客服在踢皮球。更麻烦的是，安抚情绪Agent有时候会过度介入，在用户只是正常询问的时候发一堆安慰话术，显得很假。主管Agent的协调逻辑也很难写，它经常在不需要协调的时候强行协调，增加了延迟。

最后这个项目回退到了工作流方案：一个入口节点做意图分类，然后走不同的分支——物流查询分支直接调物流接口，退换货分支走标准退换货流程，投诉分支转人工。整个系统稳定、快速、成本低，用户满意度反而更高。这个案例让我深刻体会到，多智能体的“智能”很多时候是开发者的一厢情愿，用户要的是快速解决问题，不是看AI们开会。

4. 工作流实战：从零搭建一条简历筛选流水线

4.1 需求拆解与流程设计

光说理论没意思，我们拿一个具体场景来走一遍完整的工作流搭建过程。场景是简历筛选，这是热词里高频出现的需求，也是很多HR团队的真实痛点。需求很简单：每天收到几百份简历，需要快速筛出符合岗位要求的候选人，减少人工初筛的工作量。

先拆解需求。一份简历进来，我们需要做这几件事：提取关键信息（姓名、学历、工作年限、技能、项目经历），判断硬性条件是否达标（比如学历要求本科以上、工作年限要求三年以上），评估技能匹配度（岗位要求Python和机器学习，简历里有没有相关经历），评估经历匹配度（有没有相关行业经验），最后综合打分并给出建议。

这个流程里，哪些步骤是确定的？信息提取是确定的，硬性条件判断是确定的，技能匹配可以用关键词加语义相似度来做，也是相对确定的。经历匹配稍微模糊一点，但也可以用模型打分。综合打分就是加权求和，完全确定。所以整条链路都可以用工作流来实现，不需要多智能体。

流程设计上，我建议这样编排：简历解析节点→硬性条件过滤节点→技能匹配节点→经历匹配节点→综合评分节点→分支路由节点。其中硬性条件过滤如果不过，直接走淘汰分支，不再往下走，节省计算资源。技能匹配和经历匹配可以并行执行，提高效率。

4.2 关键节点的参数配置与调优

每个节点的配置都有讲究，我逐个说。

简历解析节点：这个节点负责把PDF或Word简历转成结构化数据。建议用专门的文档解析模型，不要用通用大模型直接读，因为通用模型对表格和复杂排版的解析准确率不够。解析出来后，用JSON Schema约束输出格式，确保后续节点能稳定拿到字段。这里有个坑：不同候选人的简历格式千差万别，有的用表格有的用段落，有的把技能写在项目经历里。我的经验是，解析节点要输出一个“原始文本”字段作为兜底，后续节点如果结构化字段缺失，可以从原始文本里再提取。

硬性条件过滤节点：这个节点用规则引擎就够了，不需要模型。比如学历要求，解析出来的学历字段直接和“本科”做比较。工作年限直接做数值比较。用规则的好处是快、准、零成本。注意要处理边界情况，比如“本科在读”算不算本科，“三年经验”是精确三年还是三年以上。这些规则要提前和业务方对齐，写死在配置里。

技能匹配节点：这个节点需要模型介入。把岗位要求的技能列表和简历中的技能描述做匹配。我试过两种方案：一种是纯关键词匹配，快但漏报率高，比如简历写“用过sklearn做分类”但没写“机器学习”，关键词就匹配不上；另一种是用embedding做语义相似度，准确率高但需要额外调用。我的建议是两者结合：先用关键词做粗筛，命中的直接算匹配，没命中的再用语义相似度做补充。这样兼顾效率和准确率。

经历匹配节点：这个节点评估候选人的项目经历和岗位的相关性。把岗位描述和项目经历分别做embedding，算余弦相似度。这里有个技巧：不要只算整体相似度，要把项目经历拆成多条，每条单独算，然后取最高分。因为候选人可能做了五个项目，只有一个和岗位相关，整体算相似度会被不相关的项目拉低。

综合评分节点：加权求和。权重要根据岗位特点调整。技术岗技能匹配权重高一些，管理岗经历匹配权重高一些。权重不要拍脑袋定，找业务方要几十份历史简历，人工标注哪些是好简历，然后反推权重。这个步骤很多人跳过，导致评分和实际需求偏差很大。

4.3 分支路由与人工兜底设计

评分出来后，需要决定怎么处理。我的建议是设三个档位：高分直接通过，进入面试邀约流程；中等分进入人工复核，由HR做最终判断；低分自动归档，但保留申诉入口。

这里的关键是阈值怎么定。阈值定太高，漏掉好候选人；定太低，HR复核工作量太大。我的经验是，先用历史数据跑一遍，看分数分布，然后根据HR的复核容量来定。比如HR每天能复核50份，那就把阈值定在能让50份左右进入复核的位置。这个阈值不是固定的，业务旺季可以调低，淡季可以调高。

人工复核环节一定要在工作流里体现出来，不能跳过。具体做法是加一个“人工审核节点”，工作流执行到这里会暂停，把简历和评分推送给HR，HR在界面上做通过或拒绝的操作，然后工作流继续执行。这个节点保证了系统的可控性，也给了HR参与感。

4.4 效果验证与迭代方法

工作流搭完不是终点，要持续验证和迭代。我建议做两件事：离线评估和在线监控。

离线评估就是拿一批历史简历，人工标注好结果，然后跑工作流看准确率。重点看两个指标：召回率（好候选人有没有被漏掉）和精确率（通过的是不是真的好）。如果召回率低，说明阈值太高或者匹配逻辑太严；如果精确率低，说明阈值太低或者匹配逻辑太松。

在线监控就是看实际运行数据。每天有多少简历进来，各分支的分布比例是多少，人工复核的通过率是多少，HR对系统的满意度如何。如果发现某个分支的简历特别多但通过率特别低，说明这个分支的规则需要调整。

迭代的时候，一次只改一个变量。比如这周只调阈值，下周只调技能匹配的权重，这样才能知道每个改动带来的效果。同时改多个变量，出了问题都不知道是哪个引起的。

5. 多智能体落地：什么情况下值得折腾

5.1 一个适合多智能体的场景长什么样

说了这么多工作流的好话，也得公平地聊聊多智能体什么时候真的有用。我举一个我实际做过的场景：行业研究报告自动生成。

这个任务的需求是：给定一个行业名称，自动生成一份包含市场规模、竞争格局、技术趋势、政策环境、未来预测五个部分的报告。这个任务的不确定性在于：不同行业的数据来源不一样，有的行业新闻多，有的行业只有财报，有的行业需要查学术论文。你没法提前编排一条固定的工作流来覆盖所有情况。

多智能体方案是这样设计的：一个规划Agent先分析行业特点，决定需要收集哪些类型的信息；然后搜索Agent根据规划去不同的数据源收集信息；分析Agent对收集到的信息做交叉验证和深度分析；写作Agent负责组织成报告；最后审核Agent检查事实准确性和逻辑一致性。Agent之间通过共享工作区来交换信息，规划Agent会根据搜索Agent的反馈动态调整后续步骤。

这个场景里，多智能体的动态规划能力确实发挥了作用。工作流方案我也试过，但需要为每个行业单独配置数据源和流程，维护成本太高。多智能体方案虽然开发复杂，但泛化能力更强，新行业进来基本能自动适配。

5.2 多智能体系统的架构设计要点

如果你确定要用多智能体，有几个架构设计要点必须注意。

Agent角色要精简。不要为了“看起来厉害”设一堆Agent。每个Agent都应该有明确的、不可替代的职责。我见过一个系统设了七个Agent，结果其中三个的职责高度重叠，经常互相抢活或者互相推诿。我的经验是，Agent数量控制在三到五个比较合适，超过五个协调成本会急剧上升。

通信协议要简单。Agent之间怎么交换信息，要有明确的格式约定。建议用结构化的JSON，包含发送者、接收者、消息类型、内容、时间戳。不要用自然语言自由对话，那样很容易产生歧义和无限循环。我试过让两个Agent用自然语言讨论，结果它们互相客气了十几轮还没进入正题，token烧了一大堆。

要有全局状态管理。多智能体系统里，每个Agent有自己的局部状态，但需要一个全局状态来记录整体进度和共享信息。这个全局状态要设计好读写权限，避免多个Agent同时写导致冲突。可以用一个中心化的状态管理器，Agent通过API来读写。

要有终止条件。多智能体系统最容易出的问题就是无限循环。Agent A等Agent B的结果，Agent B等Agent A的结果，或者两个Agent互相评审没完没了。必须设置硬性终止条件，比如最大轮次、最大token消耗、最大执行时间，到了就强制结束并返回当前结果。

5.3 多智能体与工作流的混合架构

实际项目里，纯多智能体或纯工作流都少见，更多是混合架构。我的建议是：用工作流做主干，用多智能体做局部。

具体来说，整个业务流程用工作流编排，保证可控性。在需要动态决策的环节，嵌入一个多智能体子系统。比如客服系统里，常规问题走工作流分支直接处理，遇到复杂投诉时，触发一个多智能体子系统来做深度分析和方案生成，生成的结果再回到工作流里走后续流程。

这种混合架构的好处是兼顾了稳定性和灵活性。主干流程稳定可靠，局部环节有智能。而且多智能体子系统的输出是工作流的一个节点，你可以对它做校验和兜底，不会让它的不确定性影响整个系统。

5.4 多智能体的评估与监控体系

多智能体系统的评估比工作流复杂得多。工作流你只需要看最终结果和每个节点的执行情况，多智能体你还需要看Agent之间的协作质量。

我建议监控这几个维度：任务完成率，有多少任务最终成功完成；平均执行轮次，Agent之间交互了多少轮才完成，轮次太多说明协作效率低；token消耗分布，哪个Agent消耗最多，是不是有Agent在做无用功；冲突率，Agent之间出现意见分歧的比例，太高说明角色定义有问题；人工干预率，有多少任务需要人工介入才能完成。

这些指标要持续跟踪，发现异常及时调整。比如某个Agent的token消耗突然飙升，可能是它的提示词被注入了奇怪的内容，或者它在某个边界情况下陷入了循环。

6. 选型决策框架：三分钟判断该用哪个

6.1 五个关键判断问题

聊了这么多，最后给你一个实用的决策框架。面对一个具体需求，问自己五个问题：

第一，任务的执行路径能不能提前画出来？如果能画出完整的流程图，每个分支都能枚举，那工作流就够了。如果画不出来，或者画出来发现有大量“视情况而定”的节点，那可能需要多智能体。

第二，对结果稳定性的要求有多高？如果是业务系统，每次输出必须一致，那工作流更合适。如果是探索型任务，允许每次结果不同，多智能体可以尝试。

第三，团队的技术储备够不够？工作流一个中级工程师就能搞定，多智能体需要架构师级别的设计能力和运维能力。如果团队里没人懂Agent架构，建议先从工作流做起。

第四，预算充不充足？多智能体的token消耗通常是工作流的五到十倍，开发周期也是三到五倍。如果预算紧张，工作流是更务实的选择。

第五，出错了能不能接受？工作流出错你能快速定位和修复，多智能体出错可能连原因都找不到。如果业务对错误容忍度低，工作流更安全。

6.2 决策对照表

我把上面的判断整理成一张表，方便你对照：

这张表不是绝对的，但能帮你快速建立判断。大多数情况下，如果你在某一列打勾超过四个，那就选那个方向。

6.3 从工作流起步的渐进式策略

我的建议是：除非有明确证据表明工作流搞不定，否则一律从工作流起步。工作流搭起来快，跑起来稳，维护起来简单。你先用工作流把业务跑通，积累数据和经验。如果发现某些环节确实需要动态决策，再把这些环节抽出来用多智能体做增强。

这种渐进式策略的好处是风险可控。你不需要一开始就投入大量资源做多智能体，而是先用低成本方案验证需求。如果工作流就能满足业务，那就省了一大笔钱和时间。如果确实需要多智能体，你也有工作流作为兜底，不会因为多智能体不稳定导致整个系统瘫痪。

我见过太多团队一上来就追求“先进架构”，结果项目延期、预算超支、上线后问题不断。反而是那些从工作流起步、逐步迭代的团队，最终做出了真正好用的系统。技术选型不是比谁更时髦，而是比谁更合适。

7. 实操中的避坑经验与常见问题

7.1 工作流搭建的五个常见坑

坑一：节点粒度太细。有人把工作流拆得特别碎，一个简单的文本清洗拆成五个节点。结果流程图画了几十步，维护起来极其痛苦。我的经验是，一个节点只做一件有业务意义的事，不要把技术细节拆得太细。文本清洗就是一个节点，内部怎么实现是代码的事。

坑二：条件分支没有兜底。条件节点只写了“是”和“否”两个分支，但实际数据可能既不是“是”也不是“否”，比如字段为空。这时候流程就卡住了。每个条件节点都要有默认分支，处理所有未预期的情况。

坑三：并行节点结果不同步。并行执行的两个节点，一个快一个慢，后续节点如果直接取结果，可能拿到空值。要用同步节点等待所有并行分支完成，或者设置超时机制。

坑四：没有错误重试。调用外部API的节点，网络抖动导致失败是常事。每个外部调用节点都要配重试策略，比如重试三次，每次间隔递增。但要注意，重试次数不是越多越好，有些错误重试也没用，比如参数错误，重试只会浪费时间。

坑五：日志记录不完整。工作流出问题时，你需要知道每个节点的输入输出。如果日志只记了成功失败，没有记具体数据，排查起来就很困难。建议每个节点都记录输入、输出、耗时、错误信息，方便回溯。

7.2 多智能体开发的三个致命错误

错误一：Agent职责重叠。两个Agent都能做同一件事，结果要么互相推诿，要么重复劳动。每个Agent的职责必须唯一且明确，不能有模糊地带。

错误二：没有全局超时。Agent之间互相等待，如果没有全局超时，可能永远卡住。必须设置最大执行时间，到了就强制终止并返回当前状态。

错误三：提示词没有边界约束。Agent的提示词如果只说“你要帮助用户解决问题”，它可能会尝试做超出能力范围的事。提示词里要明确写清楚能做什么、不能做什么、遇到不确定的情况怎么处理。

7.3 常见问题速查表

7.4 我的个人经验总结

做了这么多项目，我最大的体会是：技术选型要克制。不要因为多智能体听起来高级就硬上，也不要因为工作流听起来简单就嫌弃。合适的才是最好的。

另一个体会是：先跑通再优化。不要一开始就追求完美架构，先用最简单的方式把业务跑通，拿到真实反馈后再迭代。很多问题在纸上是想不出来的，只有跑起来才会暴露。

最后一个体会是：监控比开发更重要。系统上线只是开始，持续监控和调优才是长期工作。工作流相对好监控，多智能体需要更完善的监控体系。如果你没有精力做监控，那就选工作流，至少出问题你能快速定位。

这个内容后续还可以这样扩展：如果你对工作流的具体搭建感兴趣，可以深入研究Coze或Dify的节点配置；如果你对多智能体的协作机制感兴趣，可以从经典的合同网协议入手了解Agent协商的基本原理。但无论往哪个方向深入，都建议先把工作流吃透，它是你理解自动化系统的基石。