企业官网建设流程全解析

1. 为什么Multi-Agent会走到“垂直化”这一步

1.1 通用工具能演示、不能交付的三个真实痛点

我最早做的Multi-Agent产品形态就是一个通用编排工具：可以在界面上拖拽几个Agent，给每个角色写系统提示词，然后让它们围绕一个主题开会、写方案、做总结。演示效果确实唬人，销售拿去给客户看的时候，客户眼睛是亮的。但真把工具交付到业务部门，问题马上暴露：业务方提出一个很具体的需求——把过去三个月的工单按故障类型整理一下，再统计高频问题TOP5——通用工具里的Agent会把这个问题当成一次策划任务来处理，输出一篇漂亮的报告，而不是业务方可直接使用的结构化表格。

这类问题我后来总结成三个痛点。第一，角色目标不落地。通用工具里Agent可以叫“市场分析师”“产品经理”，但这些角色只靠提示词撑出来，没有行业行为约束，它们输出的内容像行业报告，不像业务数据。第二，领域术语理解差。同样是“抖动”，在设备维保里是振动故障，在视频处理里是画面不稳，通用Agent缺少领域消歧能力。第三，流程不固定。业务场景要求先查权限、再查库存、最后生成处理建议，每一步有严格顺序，但通用工具默认所有Agent都可以自由发言，顺序一乱，结果没法用。

1.2 垂直化的本质：把业务确定性变成系统设计

我见过不少团队以为垂直化就是给通用Agent接一个向量数据库，问什么就去知识库里找一段文本，然后拼进上下文。这个思路不能说错，但太浅。垂直行业解决方案的核心不是“多了一些资料”，而是“多了业务约束”。业务约束包括三样东西：角色边界、流程顺序、输出格式。角色边界决定每个Agent能管什么、不能管什么；流程顺序决定谁先执行、谁后执行、哪些步骤可以并行；输出格式决定最终交到用户手里的是表格、工单还是自然语言报告。把这些约束做进系统，产品才从“能聊天”变成“能干活”。

我为什么坚持用Multi-Agent而不是简单做一个大Prompt？因为行业场景里天然的决策点很多，一个Agent把所有事情做完，既难维护，也难以解释。把任务拆给多个Agent，每个节点独立观察、独立更新，出问题可以定位到某个环节。另外一个原因在于权限和数据隔离：垂直行业里不同角色能看到的数据范围不一样，比如售后Agent可以看故障记录，但不能看合同价格，拆成独立Agent之后，访问控制更好落地。所以垂直化不是退回到单Agent，而是让Multi-Agent从表演走向生产。

2. 从通用到垂直的产品设计思路

2.1 先画业务流，再定Agent：需求拆解三板斧

很多做技术的人拿到垂直场景第一反应是：这里可以用三个Agent，一个理解用户意图，一个查知识库，一个生成回复。这个方向没错，但容易拍脑袋。我自己的做法是先画业务流，再定Agent，核心是三步。第一步，跟着业务人员走一遍完整任务链路，把每一个需要人工判断的节点标出来。比如做设备售后，业务链路是：客户报修进来，客服判断问题类型，查设备档案，给排查建议，如果解决不了就生成维修工单，维修完成后回访。第二步，对每个节点问三个问题：这里需要自然语言理解吗？需要检索某个数据源吗？需要做决策吗？答案全部为否的节点，用普通规则代码解决，不建Agent。

第三步，把“需要理解但不需要决策”的节点设计成子Agent，把“需要综合判断”的节点设计成主Agent或者流程节点。举个例子，设备售后场景我最终只保留四个角色：入口分类Agent负责判断用户说的是故障报修、资料查询还是投诉建议；知识检索Agent负责从手册和案例库里找材料；故障排查Agent负责按照排查树一步一步引导；工单生成Agent负责把前面的结论格式化成工单。这个数量比最初想象少很多，但每个角色都能对应到业务链路里的真实环节。经验是：Agent数量最好不要超过业务决策点的数量，不然就会出现好几个Agent抢同一个活的情况。

2.2 领域知识注入和工作流固化：把“行业常识”装进系统

领域知识注入有三条路。第一，提示词内嵌规则：适合那些量不大但很关键的硬规则，比如“如果设备处于保修期内，不能自动生成收费工单”“所有回复必须包含故障代码”。第二，RAG：适合大量非结构化资料，比如操作手册、历史工单、常见问题。第三，微调：适合表达方式高度特殊、且样本量足够的情况，但我接触的多数垂直场景前期并没有那么多高质量样本，所以微调放在后期再做。前期我最推荐“硬规则+RAG”的组合：硬规则保证底线，RAG提供灵活性，两条路都方便更新。

工作流固化是另一个容易忽视的点。通用Multi-Agent工具喜欢让Agent自由对话，但自由对话在垂直场景里是灾难。我的做法是引入一个轻量状态机：整个任务被分成几个阶段，每个阶段只允许指定的Agent执行，阶段之间有明确的产物交接。比如在售后场景里，入口分类Agent先输出一个分类标签，然后状态机根据分类标签决定走“知识问答”还是“故障排查”分支；在故障排查分支里，排查Agent按排查树走，每走一步都要判断是否满足下一步条件。这个设计让产品变得可预测，也让测试变得简单：你不需要模拟所有对话可能，只需要覆盖状态分支。

2.3 技术底座选型：别被“编排框架”带着走

技术选型方面我比较反直觉的建议是：不要迷信大而全的编排框架。通用框架解决了“Agent能连起来”的问题，但垂直产品要解决的是“Agent按业务规则连起来”的问题，后者往往需要自己写调度代码。我当时评估过几个方案：直接用某开源编排框架，优点是上手快、自带工具调用；缺点是流程控制能力弱，遇到分支和人工审批要绕很多弯。后来选择自研一个轻量调度层，只做三件事：解析业务状态机的下一跳、调用对应Agent、把结果写入共享上下文。工具调用本身仍然用成熟框架的能力，但流程控制在自研层做。

架构上我建议分成五层：接入层、调度层、Agent层、工具层、知识层。接入层处理渠道和权限；调度层维护状态机和路由；Agent层只关注单个任务的输入输出；工具层把订单、工单、知识库API统一封装；知识层管理向量库和规则库。分层带来的好处是，你可以单独替换某个Agent而不用动流程，也可以单独更新知识库而不影响角色定义。对于团队而言，分层还有一个隐藏价值：新人上手快，每个人负责一层，沟通成本低。这个架构放在通用工具里可能显得笨重，但在垂直行业里，它换来的是可控性和可维护性。

3. 落地实操：一个垂直Multi-Agent产品的完整构建过程

3.1 场景选择与需求边界：先选一把“窄而深”的铲子

讲完思路，讲一个我完整做过的案例。背景是某制造型企业的售后服务部门，他们每天要处理几百条来自电话、网页和在线聊天渠道的售后咨询，客服人力严重不足。我们一开始也犹豫过要不要做一个通用的企业助手，后来被一个真实细节说服：售后咨询里超过四成集中在故障排查和资料查询，而且这两类任务都有标准作业指导书，流程非常固定。这就是一个典型的“知识密集+流程稳定+交付物明确”的场景。于是我们把产品定位为“售后知识助手”，并且明确三个不做：不做开放式闲聊、不做主动营销、不做需要审批的售后决策。边界一收，后面所有设计都顺了。

需求边界为什么重要？因为Multi-Agent最怕的是“全权负责”。用户抛来一句话，如果系统要判断是闲聊、投诉、退货还是技术问题，每个分支都要准备对应的Agent、知识库和评测集，复杂度和风险都会翻倍。我们选择只承接三类任务：售后知识问答、故障排查引导、工单摘要生成。这三类任务的共同点是答案相对有据可查，Agent发挥空间小，出错影响也可控。边界定完之后，产品和客户对齐也容易，客户知道系统能干什么、不能干什么，预期管理反而更成功。

3.2 角色编排与协作机制：一个主管加三个执行

我们最终的角色结构是一个主管加三个执行：入口分类Agent相当于主管，它不直接回答问题，而是先判断用户意图，再把任务分发给对应执行Agent。知识检索Agent负责从向量库和规则库里找材料；故障排查Agent按排查树引导用户，并决定何时升级人工；工单摘要Agent把整个对话过程压缩成结构化工单摘要。这套结构和纯闲聊式Multi-Agent最重要的区别在于：Agent之间不直接对话，所有信息都通过调度层传递。主管拿到执行Agent返回的结果后，再决定要不要追问、要不要转给下个环节。这种模式可以避免两个Agent越聊越偏。

协作机制在实现上主要靠状态机。我给每个任务定义了几个状态：initial、classifying、searching、troubleshooting、summarizing、escalated、done。状态的流转由调度层控制，不是由大模型自己决定。为了让大家有个直观参考，我贴一段简化版的角色编排配置，实际生产里会比这个复杂，但骨架是这样：

agents: - name: entry_classifier role: 意图分类 input: 用户原始问题 output: intent model: light temperature: 0 rules: - 仅输出枚举值: fault, knowledge_query, complaint, other - 不确定时输出other - name: knowledge_retriever role: 知识检索 input: intent, user_question output: knowledge_refs model: light temperature: 0 tools: [knowledge_search, rule_lookup] - name: troubleshooting_guide role: 故障排查引导 input: fault_code, product_model output: next_step model: flagship temperature: 0.2 flow: step_tree - name: ticket_summarizer role: 工单摘要生成 input: trace, resolution output: ticket_json model: flagship temperature: 0.1

这个配置文件的背后是几个关键参数。temperature：分类和检索任务用0，让输出尽量稳定；生成任务用0.2左右，保留一点自然表达。model：把便宜的小模型放在路由和检索上，把更强的大模型放在需要推理的排查和摘要上。rules：硬规则优先于模型判断，比如分类结果必须落在枚举值里。这套配置跑下来，单次任务平均调用的Agent数量从3.5个降到了1.8个，因为很多简单问答只需要分类后走一次知识检索就够了。

3.3 工具接入与知识库建设：让Agent有据可查

垂直场景的Agent能不能干活，很大程度上取决于工具和知识库做得好不好。工具层面，我们把售后系统里的订单查询、设备档案、工单创建封装成统一API，Agent通过工具调用去获取实时数据，而不是靠模型记忆。这一步的坑是：不能把API返回的原始JSON直接塞给Agent。我见过不少实现，工具返回一长串嵌套字段，大模型直接被绕晕。我们的做法是在工具层做一个schema精简，比如订单查询只返回订单号、产品型号、保修状态、购买日期这几个字段，多余字段不进上下文。

知识库建设同样有讲究。原始手册拿来直接用效果很差，因为手册是给工程师看的，用户的语言和手册语言差很多。我们把手册拆成两种粒度：一种是面向用户的问题答案对，主要来自历史工单里已经被验证过的答复；另一种是面向故障排查的分步指导，主要来自标准作业指导书。然后再给每个知识块打上产品线、故障码、适用型号这些标签，检索时先用标签过滤，再做向量召回。这个“先标签后向量”的顺序很重要，纯向量检索在专业术语多的场景里经常召回不相关的内容。

3.4 评测与迭代闭环：把失败案例变成产品需求

垂直产品和通用工具最大的区别之一是评测方式不同。通用工具可以靠“好不好玩”“逻辑顺不顺”来验收，垂直产品必须有量化指标。我们从真实历史工单里抽了200条作为回归评测集，每条都标注了期望输出里的关键要素。比如一条故障排查用例，关键要素包括：是否问了正确的故障代码、是否推荐了正确的排查步骤、是否在最后给出了人工升级入口。测试时不是让模型逐字比对答案，而是检查关键要素有没有覆盖，这样既允许表达多样，又保证业务完整性。

每轮迭代的流程是：先把评测集跑一遍，把失败case聚成几类，然后针对每一类定位根因。根因通常有三个来源：知识库缺资料、提示词约束不够、状态机分支漏掉了场景。知识库问题去补文档；提示词问题去改描述；状态机问题则要回到流程设计，把漏掉的分支补上。我特别想提醒的是，不要让研发自己去定义评测集，要让业务人员一起参与。我们第一次评测集是开发写的，里面大量“模型应该理解上下文”这种模糊标注，后来跟客服主管重新过了一遍，才把“用户说设备开不了机”应该检索哪类知识这种真实场景补进去。评测集不是一次性工作，它本身就是产品资产，每加一个功能就要同步加一批用例。

4. 关键难点与踩坑实录

4.1 幻觉问题：给Agent一个“不知道”的出口

垂直行业最怕Agent一本正经地编造答案。我们早期版本里，知识检索Agent在向量库里没找到相关内容时，会基于训练记忆随便给一段听起来合理的操作步骤，这在售后场景里可能造成生产事故。后来我们从三个方向解决这个问题。第一，提示词里明确写：如果检索结果为空或置信度低，必须回答“需要进一步确认”，并且提供人工处理入口。第二，在工具层增加一个“无结果标记”，当向量检索的分数低于阈值时，不把任何知识块拼进上下文，同时强制Agent走“不知道”分支。第三，输出模板里要求引用知识ID，没有知识ID的回答会被系统拦截。

这里有一个关键认知：防幻觉不能只靠提示词。提示词是软约束，模型在压力下还是会编。真正有效的是系统层面的硬约束，比如无结果即走兜底分支、输出必须带引用、关键操作必须查工具。我们把这个原则叫做“给Agent一个不知道的出口”。很多模型胡编，是因为它没有被允许说不知道，或者说了不知道之后没有下一步动作。一旦你给它设计好“不知道之后怎么办”的路径——转人工、重新问、缩小范围——幻觉比例会显著下降。我们上线后统计，在故障排查场景里，无结果时直接编造答案的比例从最初的近10%降到了1%以下。

4.2 上下文污染：多Agent聊天不是越丰富越好

Multi-Agent第二个大坑是上下文污染。最早我们用对话式架构，所有Agent共享一份对话记录，任何一个Agent说了什么，后面所有Agent都能看到。结果就是：入口分类Agent把用户问题判断错了，后面所有Agent都基于错误意图工作；或者排查Agent提到了一个不相关的型号，工单摘要Agent把它当成关键信息写进工单。这就是典型的上下文污染。后来我们改成“黑板上只写结构化状态”：每个Agent只有两个输入来源——用户原始问题和上一个节点写入的关键字段，完整聊天记录不传给执行Agent。

举个例子，故障排查Agent需要知道的是“故障代码是什么”“产品型号是什么”“已经试过哪些步骤”，这些以结构化字段的形式写在黑板里；至于用户中途说了句“最近天气好热”，这类信息根本不会进入执行Agent的上下文。这样既减少Token消耗，也让每个Agent的关注点更集中。实现上要注意一个细节：黑板信息要做版本管理，因为多Agent协作里会出现并行分支，如果没有版本号，后写的节点可能覆盖先写的字段。我们实际开发中就在黑板上加了updated_at和version字段，调试时定位问题快很多。

4.3 Prompt和模型选型：不同角色要用不同的“性格”

我在这个项目里最大的感悟之一是：不要一套Prompt、一个模型打天下。入口分类Agent的核心诉求是稳定，所以temperature设为0，提示词里只给枚举值和几条简单规则，模型用能力足够但成本低的小模型。知识检索Agent也是稳定优先，它要做的是把用户问题改写成适合检索的查询，这需要模型有摘要和改写能力，但不需要生成能力。故障排查Agent则不一样，它需要按照排查树一步一步走，还要根据用户每次回答判断下一步，这个任务涉及推理和多轮记忆，必须用更强的主模型，temperature可以稍微调到0.2。

模型选型还有一条容易被忽略的原则：垂直场景里优先选领域理解好的模型，而不是榜单分数最高的模型。我们试过两个主模型，综合分数高的那个在通用对话上明显更好，但在处理设备型号、故障代码这些专业名词时反而更容易混淆，因为它的注意力被更多通用语料分散了。另一个在领域语料上做过专门优化的模型，虽然通用问题回答不如它，但在售后场景里的关键要素覆盖率高出一截。所以做垂直产品，应该用一批垂直领域评测用例去做模型选型，而不是直接看公开榜单。

4.4 成本与延迟优化：能省则省，能并行则并行

Multi-Agent的成本和延迟容易被低估。一个看似简单的问答，如果每次都把所有Agent跑一遍，Token开销可能是单Agent的三到四倍。我们的优化思路是“能省则省”：在入口就分流，只调用当前意图需要的Agent；知识检索结果可以做缓存，同一个故障码对应的知识块重复查询时直接命中；路由和分类用便宜的小模型，只在生成最终答案和复杂推理时调用大模型。这套组合拳做下来，单次任务平均成本比最初版本下降了40%左右。

延迟方面，最直接的手段是把无依赖的Agent并行执行。比如知识问答类任务，知识检索和工具查询可以同时发起，等到两个结果都返回后再做汇总。但这要吃透业务流程，不能盲目并行。我们踩过的坑是把故障排查和工单摘要并行执行，但排查还没结束就生成摘要，摘要内容当然是不完整的。后来我们给每个Agent标注了依赖关系，调度层只在依赖满足时才放行。垂直产品的延迟目标不用追求极致，关键是不能比人工处理慢太多。我们当时定的目标是P95响应时间小于10秒，超过这个时间就转人工，这样既保护体验，也让系统压力可控。

5. 未来演进与个人经验

5.1 从“定制项目”到“可复制产品”：把行业模板沉淀下来

垂直行业解决方案有个通病：做一单成一单，但每一单都要从零开始。原因在于每次客户的知识库、角色定义、流程节点都不一样，如果全部硬编码，三个月后你就会发现自己其实在给人做项目外包。要走向可复制产品，必须把项目里的共同部分沉淀成模板。我们后来抽象出一套“行业套件”：角色模板、流程模板、知识库schema、评测集框架。新客户进来时，先复制套件，再调整差异，而不是重新画一张架构图。

比如售后知识助手这套东西，实际上可以复用到很多行业：不同行业的售后流程差异主要在知识库内容和排查树，但“入口分类、知识检索、排查引导、工单摘要”这个角色骨架几乎是通用的。我们把排查树做成可视化编辑器，业务人员自己在后台画流程，新增故障码就新增一个节点，不需要开发介入。这个方向才是从通用工具到垂直行业解决方案的正解：不是做一个什么都懂的万能Agent，而是做一个可以快速配置出无数个垂直方案的产品平台。接下来我们会把更多精力放在配置体验和模板积累上，让产品迭代速度不再受限于开发资源。

5.2 给正在做Multi-Agent产品的团队几条建议

最后分享几条我踩过坑之后总结出来的建议，不一定正确，但应该能帮后来者少走弯路。第一条，先找一把窄而深的铲子，不要做瑞士军刀。通用Multi-Agent工具看起来很宽，但每条行业赛道都有护城河，宽度换不来深度。第二条，把评测集当产品资产。垂直产品的竞争力一半在算法一半在数据，那些标注好的历史工单和失败case，才是别人拿不走的壁垒。第三条，一定要设计人工兜底。产品上线不是终点，Agent不可能覆盖所有边界，你要让用户知道什么时候该找真人，而不是让他们在Agent循环里打转。

第四条，不要被概念热度带着走。Multi-Agent是不是比单Agent更好，取决于场景里是否有多个需要独立决策的节点，如果本来一个Prompt就能解决，硬拆成三个Agent只会增加成本和故障点。我见过太多团队为了在汇报里写上“Multi-Agent”而强行设计角色，最后产品稳定性一塌糊涂。我的体会是：用户不会关心你用的是几个Agent，他们只关心问题有没有被解决。把业务价值放在第一位，把架构作为实现手段，才是产品创新的正确姿势。这个项目做到今天，我最庆幸的是当初没有继续把通用工具做下去，而是选择了一个具体行业、一批具体用户、一堆具体问题慢慢啃，这条路走得慢，但是每一步都算数。