企业官网建设流程全解析

1. 垂域 Agent 的本质：为什么说“龙虾时代”拼的是行业纵深

做智能体开发这几年，我最大的感受是：通用大模型越来越强，但真正能落地赚钱、能稳定产出价值的，反而是那些看起来没那么“炫”的垂域智能体。所谓垂域 Agent，就是限定在特定行业、特定业务场景里的智能体，比如销售智能体、工业质检智能体、旅游推荐智能体、法律文书审阅智能体。它不是要取代通用大模型，而是把模型的能力“焊”在某个具体的业务流程上，让它变成业务闭环里的一环。

为什么说是“龙虾时代”？因为通用大模型赛道已经像深海捕捞一样，拼的是算力、数据和底座实力，普通团队根本挤不进去。但龙虾是底栖生物，贴着海底走，在水草丛里找机会——垂域智能体干的就是这个活。它不需要和巨头拼通用能力，只需要在一个足够窄、足够深、足够痛的业务场景里，把数据、流程、模型、工具全部串起来，做到“比通用方案好用十倍”即可。

举一个我参与过的销售智能体例子。最初老板的需求很简单：能不能让销售团队在客户问价后，由系统自动整理报价单？听起来像是做一个接口调用加模板填充，但真正做进去才发现，销售场景里的坑比想象中多得多——客户问的“能不能便宜点”背后可能隐含着付款周期调整、批量折扣、物流成本分摊等多种因素；销售话术里同一句话在不同地区、不同客户类型下的含义完全不同。如果只做一个“关键词触发回复”的玩具，那根本撑不起业务量。这就是垂域智能体和通用聊天的本质差异：它必须理解业务本身，而不是只理解人类语言。

这套逻辑放到任何一个垂域都一样。旅游推荐智能体不是把携程的酒店列表搬给用户，而是要根据预算、同行人、出行目的、历史偏好做综合决策；工业界的设备运维智能体不是把设备说明书丢给用户，而是要根据实时传感器数据、维修工单、备件库存判断故障根因。垂域 Agent 的核心价值，就是“业务知识 + 业务数据 + 业务动作”的三位一体，通用模型提供推理底盘，垂域系统提供业务灵魂。

所以这篇内容，我不打算堆概念，而是从开发视角把这几年做垂域 Agent 的真实路径、框架选型、踩坑记录和部署经验全部拆开讲清楚。适合谁看？想在企业里落地智能体但不知道从哪下手的开发者和产品经理，打算用 AI 改造自家业务但又被各种框架搞晕的团队，以及已经在做智能体但觉得效果不稳定、想看看别人怎么解决的同学。

2. 从零搭建垂域智能体的整体设计拆解

2.1 先搞清楚架构层次再动手，别急着调 API

很多人一上来就问“用哪家大模型”，这个顺序其实反了。垂域智能体开发的第一步，不是选模型，而是搭架构。我自己习惯把一个完整的垂域 Agent 拆成四层：接入层、认知层、工具层、协作层。

接入层负责管对话入口，可能是公众号、企微、网页挂件，也可能是内部 OA 系统。认知层是核心，负责把用户的模糊输入理解成结构化意图，结合 RAG（检索增强生成）从企业知识库里捞相关上下文。工具层负责执行动作，比如查库存、下工单、算价格、建客户档案，这一层是真正的业务抓手，也是让 Agent 从“聊天机器人”升级为“干活机器人”的关键。协作层则是多智能体场景下的调度中枢，当任务复杂到需要几个不同专长的智能体配合时，由它来决定派活顺序。

以销售智能体为例。用户问“你们 50 台设备，月结 45 天，什么价能谈？”这个输入，接入层把它收进来，认知层识别出意图是“询价”，并且提取到两个关键参数（台数：50，账期：45天），工具层去 ERP 调出该客户的历史成交价、竞品对标价、毛利底线，生成一个阶梯报价方案，协作层再判断是否要拉财务智能体确认账期风险。整个过程用户只看到一次自然对话，背后四层都在转。

2.2 框架选型的核心逻辑：不是越重越好，也不是越轻越好

框架选型是垂域 Agent 开发里最纠结的环节，没有之一。市面上能用的东西太多：Dify、Coze、百炼这类零代码/低代码平台，LangChain、LangGraph 这类代码框架，还有各种自研编排层。我的建议是：先看业务的复杂度天花板，再决定技术路线。

如果业务是“信息密集型 + 动作简单型”，比如企业内部的制度问答、产品知识问答、客服话术辅助，那用 Dify 或 Coze 这类平台完全够用。原因很简单：这类场景的核心是 RAG，没有复杂的状态流转，不需要自定义代码做深度控制，低代码平台的调试速度和界面友好度优势能发挥到最大。

但如果是“流程密集型 + 多步骤决策型”的业务，比如一个智能体要承接从线索清洗、需求确认、方案定制到报价审批的完整销售流程，那低代码平台就开始吃力了。这时候 LangGraph 这种支持状态图、分支条件和循环的框架会更合适。它把整个业务流程定义成一张图，智能体在图上按照业务规则游走，每个节点可以挂不同的模型调用、工具调用和人工审批节点，逻辑清晰、可测试、可回退。

还有一个很多人忽略的点：团队维护成本。低代码平台上手快，但后续要加复杂逻辑时容易碰天花板；代码框架初期慢，但后期几乎什么都能改。我的经验是，超过 20 个节点的业务流，果断用代码框架或混合架构，这一步决策能帮你少走好几个月的弯路。

2.3 “龙虾时代”的两条路线：平台集成 vs 代码开发

垂域 Agent 开发目前分化出两条很明显的路线，可以叫“搭积木路线”和“写代码路线”。两者没有优劣，只有适配场景不同。

搭积木路线以 Dify、Coze、百炼为代表，核心优势是快。我有一次给一家做外贸的公司搭询盘回复智能体，从导入产品手册、配置提示词到上线到企业微信，总共用时半天。这在代码框架下几乎不可能完成。而且这类平台普遍内置了知识库分段、向量检索、会话历史管理等工程实现，对非深度技术背景的团队非常友好。

写代码路线则以 LangChain、LangGraph、自研 harness 架构为代表，核心优势是可控性强。模型输出想怎么约束就怎么约束，工具调用想怎么编排就怎么编排，数据想在本地处理就在本地处理。适合业务链路复杂、数据敏感、对响应时延和推理成本有精细控制需求的企业。

我个人目前比较推崇的是一种混合姿态：用低代码平台做业务原型验证，跑通了再迁到代码框架做深度调整；或者反过来，用代码框架搭核心链路，把知识库管理等相对标准化的部分放到平台上托管。这种灵活切换的能力，就是“龙虾时代”开发者最值钱的生存技能。

3. 关键细节与实操要点：提示词、RAG 与工具调用的门道

3.1 垂域提示词不是写作文，是定义决策边界

提示词工程在垂域 Agent 里的地位被我排得很高，但这里的提示词不是那种网上流传的“你是一位擅长XXX的专家”套话，而是真正的业务决策规则。写好垂域提示词的核心，是把隐性业务知识显性化成模型可执行的“if-then”。

举个实际例子。我在做装修报价智能体时，遇到的第一个难题是用户描述风格差异极大——有人说“喜欢温馨点的”，有人说“要侘寂风”，还有人直接发一张参考图。这些描述需要被转化成可计算的装修等级参数。提示词里就不能只写“分析用户需求”，而是要把判断逻辑写得非常明确：

• 当用户提到“温馨”“舒适”“居家”时，归入“中档简装”分类，预算区间默认 1200-1800 元/平米，并准备在后续追问中确认家具偏好。
• 当用户提到特定风格名词如“侘寂风”“工业风”时，归入“中高档定制”分类，预算默认 1800-2500 元/平米，并联动设计资源库。
• 当用户上传图片时，触发“图片理解”工具，提取空间面积、风格元素、装修程度三个关键属性，再继续走分类逻辑。

这样做的价值是：模型不会自由发挥，它必须在业务框架内做选择。即便遇到没见过的说法，也会基于最接近的分类兜底，而不是给出一个天马行空的回答。还有一点很关键，垂域提示词要留“退出通道”——当模型判断输入超出业务边界时，必须明确说“这个需求我暂时无法处理，已转人工”，而不是硬回答。这一步能把虚假承诺带来的业务风险降到最低。

3.2 RAG 不是“传文件进去就完事”，清洗分块决定智能体智商

RAG 是垂域智能体的地基，但很多团队的 RAG 效果差，不是因为模型不行，而是因为数据进知识库之前就没洗干净。我见过太多团队直接把几十个 PDF、Word 仍进 Dify，然后抱怨回答不准确。正确的做法是：在入库前做数据血缘分析、格式归一化和结构拆分。

数据清洗这块，最容易被忽略的是“上下文断裂”问题。比如一份产品手册里，页面 3 写着“该型号支持 220V 供电”，页面 8 写着“选配参数参见表 2-5”，如果分块策略机械地按页拆分，检索时只捞到后半句，前半句的关键型号信息就丢了。我的经验是，要结合文档本身的逻辑结构来切分，而不是按固定字数切。具体做法是：先经过版面分析识别标题、表格、段落，再按“章节—小节—段落”的层级关系合并成语义完整的分块，每个块控制在 500 到 1000 字之间，重叠区域控制在 100 字左右。

还有一块是索引优化。除了把文本向量化，我会同时保留关键词倒排索引。原因是垂域场景里有很多专业术语和产品型号，比如“LC-3000 型空压机”，向量检索对这种精确匹配往往不如关键词检索精准。混合检索方案（向量召回 Top20 + 关键词召回 Top10 再融合排序）能显著提升垂域问答的命中率。这一步在 Dify 的 Retrieval 配置里可以直接设置，在 LangChain 里则要用 EnsembleRetriever 组合。

3.3 工具调用的稳定压倒一切：给工具穿上“防弹衣”

垂域智能体的工具调用，核心不是“会不会调”，而是“调得稳不稳”。业务工具往往涉及订单、库存、价格这些敏感数据，如果模型在调用工具时传了一个格式错误的参数，轻则返回空数据，重则产生错误业务操作。所以我的原则是：所有工具都做成极简接口，并且再加一道参数校验和固定输出格式的保险。

工具设计上，建议每个工具只做一件事。不要做一个“获取客户所有信息”的大工具，而是拆成“获取客户基本信息”“获取客户历史订单”“获取客户信用等级”三个独立工具。这样既方便模型按需选择，也方便后续权限控制。参数命名要直观，比如 query_customer_orders(customer_id: string, limit: int)，并配上不超过三句话的功能描述，让模型一眼看懂什么时候该用。

输出格式上，强制要求 JSON 结构化返回，并且固定字段名。比如查询订单接口，统一返回：

{ "order_list": [ { "order_id": "SO20250115", "amount": 128000, "status": "delivered" } ], "total_count": 1 }

这样无论模型后续是生成自然语言回答，还是把数据传给下一个工具，都能稳定消费。另外，工具层必须做容错兜底。API 超时、返回空数据、字段缺失这些异常情况，都要在工具内部先处理，给模型返回一个“查询失败，原因：XXX”的明确信息，而不是让模型在缺数据的情况下硬编答案。

4. 实操过程与核心环节实现：从零跑通一个智能体开发案例

4.1 场景定义与数据准备：我要做一个什么样的 Agent

这里我以一个“多维工单处理智能体”为例，完整跑一遍实操流程。这个场景非常典型：一个做设备运维的公司，每天收到大量售后工单，工单内容五花八门，有问使用方法的、有报故障的、有投诉物流的，需要一套系统来自动分类、判断优先级、回复常规问题并把复杂问题转给对应工程师。

第一步是定义好智能体的边界和动作范围。我明确告诉模型：这个智能体只做四件事——工单自动分类（咨询/故障/投诉）、故障优先级判断（紧急/普通/低）、基于知识库回复常见咨询、把超出能力范围的工单转人工并附上预诊断信息。超出这四件事的任何需求，不允许回答，一律转人工。这个边界定义直接决定后面整个系统的复杂度。

数据准备上，我拉了近一年的历史工单数据、对应的处理结果、维修记录和常见问题手册，做了三轮清洗。第一轮去隐私，工单里的客户姓名、手机号、地址全部脱敏为占位符；第二轮打标签，每条工单人工标注类别（咨询/故障/投诉）和优先级（紧急/普通/低），这些标签后续既用来做效果评估，也用来做少样本示例；第三轮拆分，把维修手册按照设备型号拆成独立知识块，确保检索时按型号命中。

4.2 工作流搭建：选择 Dify 平台快速验证业务闭环

因为要快速验证业务逻辑，这个项目我第一版先用 Dify 搭建。流程设计是：入口节点接收工单原文 → 意图识别节点判定类别 → 分支节点按不同类别走不同子流程 → 子流程里分别调用知识库检索、模型生成或转人工接口。

配置层面有几个关键点。第一个是模型选择，分类和生成我用了不同的模型参数档位：分类任务温度调到 0，生成任务温度 0.3。原因是分类要确定性，生成要适度自然度。第二个是检索参数，知识库检索的 TopK 设成 4，相似度阈值 0.5，低于阈值的检索结果不采用，直接转人工，避免模型拿不相关的知识硬答。第三个是会话变量，我把工单编号、客户等级、设备型号全程作为变量传入子流程，保证多轮对话中上下文不丢。

Dify 里最值钱的功能我觉得是“变量聚合节点”。工单里往往包含“客户说设备老是报警”和“客户说三天前刚修过”等多条信息，聚合节点能把分散信息整理成结构化上下文，再交给后续节点做判断。这个小设计大大提升了模型对工单全文的理解准确率。

4.3 升级 LangGraph：处理复杂分支和人工审批

低代码版本跑通两星期后，客户提出了两个新需求：一是工单升级后要自动给售后主管发审批通知，二是同一个客户短时间内的多张工单要自动合并为一个事件。这两个需求在低代码平台上能做，但逻辑一复杂就变得很难维护，所以我决定把核心链路迁到 LangGraph 上重写。

LangGraph 的核心思想是把流程定义成状态图。我建了这些节点：entry（接收工单）、classify（分类）、check_duplicate（查重合并）、priority_assess（紧急度判断）、auto_reply（知识库回答）、route_to_human（转人工）、notify_manager（通知主管）、finalize（写结果回工单系统）。

其中 check_duplicate 节点会调用一个自建接口，按客户 ID 和故障类型查过去两小时内的工单，如果命中则把当前工单合并到原事件，并触发一个 return_updates 逻辑，把合并信息追加到原工单记录里。priority_assess 节点不只依赖模型判断，还叠加了规则：凡是工单里出现“停机”“冒烟”“无法开机”等关键词，直接判定为紧急，不经过模型。这种“规则 + 模型”的混合决策，是垂域智能体稳定性的压舱石。

这里也分享一个编码层面的心得：LangGraph 的 State 对象是全局共享的，节点函数需要显式声明读写哪些字段，我建议所有字段用类型注解写清楚，比如：

class OrderState(TypedDict): ticket_id: str content: str category: str priority: str merged_event_id: str | None final_reply: str

这样每个节点函数里改动什么字段一目了然，多人协作时不会出现莫名其妙的 KeyError。

4.4 部署与前端嵌入：百炼智能体的 Web 端接入实战

系统逻辑完成后，还有一个很现实的问题：从哪里访问这个智能体？我这次选了两种方式，一是 Dify 自带的 WebApp 嵌入链接，二是通过阿里云百炼平台把智能体嵌入到公司自己的官网后台。

百炼的嵌入方式其实很直接，官方提供了前端 JavaScript SDK，类似引入一个聊天组件，核心代码如下：

<script src="https://bailian.aliyun.com/static/embed-chat/sdk.js"></script> <script> const chatConfig = { appId: "your_agent_app_id", apiKey: "your_api_key", containerId: "chat-widget-container", userName: "customer_name", welcomeMessage: "您好，我是工单助手，请描述您遇到的问题", }; BailianChat.init(chatConfig); </script>

接入后还要注意两件事。一是安全策略，不要在前端暴露主 API Key，最好通过自己的后端做一层转发，由后端校验用户登录态后再调用百炼接口。二是会话隔离，每个用户要有独立的会话 ID，否则不同用户的数据会串，这在垂域场景是绝对不允许的。所以我在自己后端加了一个 session 管理器，每次用户进入页面就生成 UUID 作为会话标识，再传给智能体接口。

5. 常见问题与排查技巧实录：从调不通到稳定运行

5.1 知识库检索答非所问：别再盲目调阈值，先检查数据切片

这个问题几乎每个做 RAG 的团队都会遇到。排查路径我一般按三步走：第一步，打开检索测试页面，看召回的前几条到底是什么内容——很多情况下根本是切片切坏了，一个完整问题被腰斩成两半，哪条都答不准；第二步，看查询改写，用户口语化提问和知识库里的书面表达差太远，需要为大模型专门配置一个 query 改写提示词，比如把“这玩意儿老响”改写成“设备异常报警原因及处理方法”；第三步，才轮到调相似度阈值和 TopK。

结合经验，我强烈建议在检索调试期把 RAG 的中间结果打印出来或直接可视化。Dify 的调试面板能看到每个提问命中了哪些知识块，LangChain 的 RetrievalQAWithSourcesChain 可以返回来源文档，这些信息远比最终的“答案漂不漂亮”更能帮你定位问题。

5.2 多智能体协作时指令冲突：给每个 Agent 建“职责说明书”

多智能体是最近热度非常高的话题，但我的实测经验是：多智能体之间的冲突，90% 不是模型能力问题，而是职责边界没划清。比如我做过一个项目，同时有一个“客服 Agent”和一个“销售 Agent”，同一个用户进来，两个智能体抢着回复，场面一度非常混乱。

解决办法是引入一个调度层 Agent，类似路由中枢。它不负责回答具体业务问题，只做两件事：确认用户意图属于哪个域，把上下文完整传给对应智能体。具体在代码框架里，就是定义一个 supervisor 节点，先调用分类模型判断任务归属，再 condition edge 跳转到对应子图。每个子智能体的系统提示词里，我也加了一句硬性约束：“你不是万能助手，你只负责 XX 域的提问；当用户提出其他域需求时，告知用户‘该问题由 XX 同事负责，正在为您转接’，不要自行回答。”效果立竿见影。

5.3 会话存储膨胀与记忆混乱：上 Mem0 做长期记忆压缩

垂域 Agent 跑一段时间后，会话历史会越来越长，尤其是做销售跟进的场景，一个客户的对话可能持续数月。直接把全部历史拼进上下文，成本高不说，模型还容易抓不住重点。我的方案是引入 Mem0 做长期记忆管理。

Mem0 的核心逻辑是：从对话里抽取出“事实型记忆”，比如“该客户偏好月结 30 天”“该客户上次询价 50 台，未成交”，按用户或会话维度存储；后续对话触发时，只把相关记忆注入提示词，而不是把聊天记录全部堆进去。实际操作上，Mem0 提供向量存储加图存储的混合结构，能按时间和关联度做记忆检索，我用下来最大的感受是“记忆很准，不会翻旧账翻错地方”。

部署上我用 Docker 起了一个 mem0 服务，配置好 OpenAI 兼容接口的向量模型，然后通过它提供的 SDK 在对话循环里做 add 和 search。需要注意的是，记忆的写入要克制，不是每句话都值得记忆，一般只抽离包含决策倾向、时间节点、具体数量等特征的实体关系。否则记了一堆噪音，检索时反而干扰判断。

5.4 常见问题速查表

5.5 避坑技巧：什么场景坚决别用智能体

最后分享一个从反面学来的经验。垂域智能体不是万能的，我踩过最大的坑，是试图用一个智能体同时处理“标准流程”和“异常特例”。比如工单系统里，80% 是标准流程，20% 是需要商务特批或者现场定制的单子。一开始我想让智能体把全部 100% 都消化掉，结果就是标准单处理得不错，特例硬答时漏洞百出。后来调整策略：智能体只负责那 80% 的标准单，遇到特例直接转人工，速度反而上去了，客户满意度也上来了。

这个经验放到任何垂域都适用。智能体适合的场景是高频、规则相对明确、容错率尚可的环节；涉及大额资金、人身安全、法律效力和复杂多方博弈的环节，智能体只能当辅助，不能当决策主体。定义清楚“不做什么”，比定义“要做什么”更重要。

6. 记忆与伴生能力：能不能让智能体用一次比一次聪明

垂域 Agent 的另一个进化方向，是把记忆系统和强化学习真正用起来。前面提到的 Mem0 属于轻量记忆，能记住用户偏好。但更高阶的做法，是让智能体在每次成功处理完一个工单后，自动 “复盘” 自己的决策链路，把有效路径沉淀回提示词或知识库，把失败路径复盘成“反例”。

这个思路我已经在试了，具体做法是：每个工单处理完，把当时的输入、中间检索的召回结果、模型最终输出、人工或客户的反馈四样东西打包，离线跑一个“经验萃取”任务，让大模型总结“下次遇到类似问题，应该优先检索哪些知识块、使用什么回复模板、必须避开的坑是什么”。萃取出来的经验经过人工抽检后，写回到知识库的“经验沉淀”区。这个机制的直观价值，是让智能体在新项目冷启动后的两周内，准确率肉眼可见地提升。

当然，这件事对数据闭环要求很高，必须有足够多的带反馈的历史数据才能启动。如果团队刚起步，建议先用人工定期审查日志的方式代替自动化萃取，等数据攒够了再上。相比一开始就追求全自动，这种半自动“喂料”的方式更稳妥，也更能保证沉淀下来的经验的准确度。

我在实际项目中还有一个很深的体会：智能体的进化不是一次开发完成的，而是一个持续运营的活儿。把它当作一个需要定期投喂、修剪、纠偏的“活系统”，而不是发布后就不管的死代码，这是垂域 Agent 从“能跑”走向“好用”的分水岭。

最后再分享一个小技巧，也是我现在每次做项目都会留的一手：无论如何设计，都要在智能体的后台保留所有人机交互的原始日志，并且给每条日志加上唯一追踪 ID。别小看这个设计，它既是排查线上问题的救命稻草，也是将来优化提示词、迭代知识库最重要的数据原料。没有这些原始日志，所谓“进化”就只是一句空话。