企业官网建设流程全解析

1. Demo与生产之间：智能体平台落地卡在哪三件事上

我在过去两年里接触过不少准备上智能体平台的企业，从制造业到零售，从金融到政务，开局几乎一模一样：某个团队用扣子（Coze）或者Dify搭了一个demo，老板看到AI自动读合同、自动筛选简历、自动写周报，当场拍板“下个月上线”。但三个月后，大部分项目还停在原地，demo能跑，生产不敢上。

不是模型能力不够，也不是团队不努力，而是企业级落地要面对的三件事，在demo里完全看不见。

第一件事是可控性。demo里AI答错了，重新问一次就行；生产环境里AI答错了，客户投诉、财务对不上账、法务要找你谈话。工作流跑一半断了、模型超时没响应、某个节点返回了意料之外的数据格式，这些在demo阶段都是小概率事件，在生产环境是每天都要处理的常态。

第二件事是知识供给。很多企业以为给Agent配一个知识库就行，实际上RAG落地比想象中复杂得多。PDF切出来是乱码，表格没了结构，图片里的信息模型看不见，老板问“昨天签的那份合同里违约金怎么写的”，系统里翻半天检索不到。知识库建了，模型还是靠“编”。

第三件事是权限边界。企业里的数据是有密级的，财务数据、客户隐私、人事信息各有归属。一个Agent如果什么都能查，看起来很强，实际上没人敢用——出了事谁负责？我在一个项目里亲眼看到，AI把某个员工的薪资信息当闲聊内容回答给了另一个员工，那一刻所有人都沉默了。权限治理不做清楚，智能体平台功能越强，风险越大。

这篇文章我想把这几年在企业智能体平台上的实际经验拆开讲。标题里写了“五种实现路径”，其实准确说是一条路径上的五个关键环节：工作流、RAG、Agent编排、混合架构、权限治理。每一环都有成熟做法，也有常见的坑，我尽量把踩过的、看见过的都记录下来，给准备做大模型应用落地的团队一个参考。

2. 第一种路径：工作流优先，把SOP变成可执行的数字流程

2.1 工作流平台的价值不在“画图”，在“确定性”

最早一批做智能体平台的人，方向特别容易被技术带着跑——Agent、多模态、自我进化，怎么炫酷怎么来。但企业客户问的第一个问题往往是：“这个AI能不能按我规定的流程走？能不能每一步都留记录？”

这个问题背后，就是工作流（Workflow）的核心价值：确定性。

一个申请审批的流程、一份合同会签的流程、一个售后处理的流程，企业里大量业务本质是SOP（标准作业程序），里面每一步做什么、什么条件走哪个分支、谁来审批、超时怎么处理，都是提前定义好的。智能体平台里加工作流引擎，本质上就是把SOP从纸质文档变成可执行、可监控、可追溯的数字化流程。

我在实际项目中见过两种极端做法。一种是完全不搞工作流，所有逻辑都让Agent自由发挥，结果模型今天用这个工具、明天用那个工具，输出格式也不稳定，业务部门根本不敢对接。另一种是过度设计，把工作流引擎做成BPM了——流程节点是写死的，模型只是某个节点里的一个“插件”，AI的灵活性完全没发挥出来。

正确的姿势是折中：把流程的骨架定死，把每个节点里的弹性交给模型。比如报销审批流程，发起、校验发票、判断金额、走审批链、打款这五个节点是确定的，但在“识别发票信息”这个节点里，用大模型来抽取抬头、金额、税号就比写规则灵活得多。这就是工作流和智能体结合的典型形态。

2.2 一个简历筛选工作流的完整节点拆解

热搜词里有一条“简历筛选工作流”，我拿这个做例子，因为它足够典型：规则明确、有判断空间、需要多步骤协作。

简历筛选看起来简单，实际上一个完整的智能体工作流至少需要以下几个节点：

第一步，文件接入与文本抽取。简历可能是PDF、Word、图片格式，甚至有压缩包。这一步要用解析组件把内容提取成纯文本和结构化数据。常见方案是直接调文件解析API，或者用开源的unstructured做本地解析。这个节点最容易出问题的是扫描版PDF——没有文本层，直接解析出来就是一张图片，这时候需要OCR组件兜底。

第二步，规则预筛。用确定性代码或简单的关键词规则把明显不符合条件的先筛掉，比如工作年限不符、学历不符、期望薪资区间差距过大。这一步的意义是缩小后续大模型处理的量，也避免模型在简单条件判断上“自由发挥”。

第三步，大模型综合评估。把简历文本、岗位JD（职位描述）一起丢给模型，让它按预设维度打分，比如项目匹配度、技能匹配度、稳定性风险，然后输出JSON格式的结果。这里要特别注意提示词的稳定性设计——岗位JD和评价维度必须是参数化的，不能写死在提示词里，否则每次换个岗位都要改工作流。

第四步，人工复核节点。建议在系统自动筛选通过、分数处于边缘区间的简历上设置人工复核节点，让HR在30秒内看一眼模型判断依据。这一步既是把关，也是在收集数据——HR修正的地方就是后续微调或调提示词的样本。

第五步，消息通知。对接企业IM或邮件系统，把筛选结果、预约面试的链接发给候选人。

这个工作流跑通之后，效果非常明显。有个制造业客户用GitHub上开源的工作流平台改造了他们的人力资源部，简历初筛时间从一天压缩到二十分钟，而且每个筛掉的简历都有一句话的原因说明，HR不再需要逐个打开看。

2.3 工作流平台怎么选：Coze、Dify、n8n还是自研

选工作流平台是躲不开的问题。市面上的选择大致分四类：老牌n8n、新生代Dify、云端扣子，以及基于Java生态的自研。

我自己的使用体感是：n8n更偏“数据管道”，适合做系统集成，但AI组件的封装不够细。Dify的定位更贴合“AI应用开发”，工作流节点里直接有“LLM节点”“知识库检索节点”“条件分支节点”，对中文界面和国产模型的支持也相对好。扣子的优势是上手快、插件生态活跃，经常能看到“毛坯房拍照就能生成效果图的扣子工作流”这类玩法，适合快速验证想法，但企业私有化部署时灵活性差一些。

有个客户问过一个问题：“Dify工作流转成Spring AI Java代码，能用吗？”这类需求通常是企业IT部门希望把原型中的工作流逻辑迁移到自己的Java工程里。我的建议是：Dify这类平台的价值在编排和调试，不在生成代码。你可以在Dify里验证流程逻辑，然后把每个节点的调用逻辑手写成Java代码，对接Spring AI的ChatClient，这样比直接翻译生成的代码靠谱得多。

如果是制造业、金融业这种有强合规要求的场景，自研工作流引擎往往绕不开。Java 8环境下比较成熟的开源审批流有Flowable和Camunda，它们能解决“状态流转、会签、驳回、条件网关”这些底层问题，但要注意：这类BPM引擎的建模语言是BPMN，是为“人工审批流”设计的，接入AI节点时你需要自己开发一个服务任务（Service Task）用来调用模型接口。这个改造的工作量不小，但做成了以后，流程的稳定性、审计能力都远强于通用AI平台。

3. 第二种路径：RAG底座先行，让Agent有据可依

3.1 基础RAG链路：切分、向量化、召回、重排

工作流解决的是“流程怎么走”，RAG解决的是“模型依据什么回答”。这两个问题不解决清楚，Agent就是一个空转的聊天机器人。

一个基础RAG系统的链路很清晰：文档切分、向量化、向量检索、重排、上下文注入。听起来不难，但每一步都有坑。

文档切分是最容易被轻视的环节。很多人直接用固定字符数切，比如每500个字符切一块，结果段落被腰斩，语义被切断。我常用的切分策略是“结构优先”：按标题层级（Markdown标题或Word/PDF的标题样式）切出树状结构，每个标题下作为一个候选块；如果正文过长，再在段落边界处二次切分。块的大小一般在300到800 token之间，具体要看你的模型上下文窗口和业务需要。

向量化环节的选型直接影响检索效果。国内团队常用BGE系列或智源的嵌入模型，效果不错。要提醒的是，中文场景下不要直接用英文社区默认的那几个embedding模型，对中文支持差的模型检索命中率会明显偏低。命中率这个概念最近在RAG讨论里出现频率很高，它衡量的是“检索结果中真正包含正确答案的比例”——数据源再全，召回率上不去，模型再强也是巧妇难为无米之炊。

召回之后的“重排”环节，很多人第一次听说，但它对最终效果影响非常大。向量检索召回Top 20，但把这些结果全部提交给模型，占上下文又容易引入噪音。做一步重排（Rerank），用专门的排序模型把最相关的5条排到前面，然后把答案生成的范围缩小到这5条里，质量会有肉眼可见的提升。BGE-reranker和cohere的rerank模型都能做这件事。

3.2 知识割裂怎么破：从GraphRAG到Ontology RAG

基础RAG能做到“给定段落精准解答”，但企业级知识库往往不是一段一段的文档，而是一张网。比如规章制度A里提到“报销必须附发票”，报销制度B里提到“会议餐费每人不得超过200元”，两篇文档分开看都没问题，但组合起来才是一个完整答案。基础RAG按向量相似度检索，往往把这层关系切碎了。

解决知识割裂，目前有两个方向比较成熟：GraphRAG和Ontology RAG。

GraphRAG的思路是在RAG之外加一层知识图谱。先把文档抽取成实体和关系，比如“张三—任职于—财务部”“财务部—负责—报销审核”，然后在这个图上做社区检测和信息聚合，查询的时候既看向量相似度，也看图上的关联路径。微软开源的GraphRAG就是代表实现。实际效果是，面对“跨文档关系型问题”时，GraphRAG的答案完整度明显高于纯向量RAG，缺点是建图成本高，对算力要求也多，中小企业要考虑成本接受度。

Ontology RAG是另一个思路——给知识库预先定义一套本体模型，也就是领域的概念和关系结构。比如做设备运维的智能体，先定义“设备、传感器、告警、维修工单、故障原因”这几个类，以及它们之间的关联。文档进来以后，首先做“本体映射”，把内容塞进预设的结构里去，检索的时候也按本体结构去取。这种方式把RAG问题部分转化成了结构化数据库问题，查询的可解释性非常好，但需要领域专家参与设计本体，前期投入大。如果你所在的领域知识体系相对固定，比如法律、医疗、设备运维，Ontology RAG很值得关注。

3.3 文本之外的RAG：图片、表格与多模态

热搜词里有个问题特别真实：RAG知识库能存储图片吗？

答案是能，但路径和文本RAG不一样。图片不能直接做向量化后按文本方式检索——视觉向量模型发展的程度还做不到理解“图片里的业务含义”并关联到问答逻辑上。目前大家普遍用的两段式方案：第一步，用多模态大模型（如GPT-4V、Qwen-VL）给图片生成详尽的文本描述——包括图中的表格、数字、结论性信息；第二步，把这个描述作为文本块入库。检索时，命中的是文本描述，但可以同时返回原图和描述，让用户在界面上核对。

表格数据也是RAG落地的高频痛点。直接把Markdown格式的表格喂给切分器，结构会被拆坏。我建议的做法是：对表格执行“按行转条目”的预处理，每一行变成一个带有列名的自然语言句子，比如“编号GD-102的员工张三，部门为技术部，职级为P7”。这样切分后，检索的单元清晰，回答引用的准确度也高很多。

跑RAG项目时还有一个实用建议：先用本地离线工具做文本解析测试。很多人问我有没有本地的文本拆解工具、不想把企业文档传到云上。我一般推荐先用开源的unstructured或者PDFPlumber做本地解析验证，观察切分后的块是否语义连贯、表格是否保留了结构。这一步不花多少钱，却能把整个RAG链路里最脏最累的部分提前消化掉。

4. 第三种路径：Agent自编排，把决策权交给模型

4.1 Agent的本质：把“怎么做事”从代码搬到提示词

前两条路径本质上都是“把流程定死”，但智能体之所以叫智能体，是因为它有一个区别于工作流的核心能力：在未知场景里自己决定下一步做什么。

一个Agent系统的构成要素包括：大模型作为推理核心、一组可调用的工具（API、数据库查询、代码执行器）、系统提示词（规定它的角色和约束）、以及记忆模块（历史对话、长期记忆）。和传统工作流的区别在于，Agent的“流程”不是预先画好的，而是模型根据当前用户请求实时生成的。

2024年以来，从LangChain到AutoGen，再到各类轻量级Agent框架，用提示词描述目标和约束、让模型自己规划任务的方式已经很成熟。这就是大家常说的ReAct模式——模型交替进行“思考（Reason）”和“行动（Act）”，先想清楚当前要做什么，再去调用工具，观察结果后再想下一步。

4.2 从ReAct到Agentic RAG

最近还有个趋势，叫Agentic RAG。它跟基础RAG的区别在于：基础RAG是“检索一次，交给模型”，Agentic RAG则是“模型根据检索结果，判断要不要追问、要不要换一种检索方式、要不要去调用另一个知识源”。

举个例子。用户问“我们公司上个月的销售额是多少”，Agentic RAG的第一步可能直接去向量库里检索相关报表文档。如果检索结果不够精确，它会意识到这个问题需要查数据库而不是查文档，于是切换工具，调一个SQL查询接口去把具体数值拉出来。如果数值拉出来了但用户还问“环比增长呢”，它再去查上月数据做计算。

这种能力在复杂、跨数据源的问题上价值非常大。但代价也很明显：不可预测。你不知道模型会在第几步决定切换工具，也不知道它凭什么判断“检索结果不够精确”。在演示场景里很丝滑，在生产环境里要准备大量的异常兜底。

4.3 纯Agent路径在财务、合同场景翻车的原因

我观察到一个现象：很多团队第一版产品直接用纯Agent路径，在财务、合同、合规审核这类场景里几乎都会翻车。翻车原因并不是模型笨，而是这些场景有三个特点不匹配纯Agent。

第一个特点是操作不可逆。合同审核错了，钱打出去了，再让Agent自我修正已经晚了。Agent路径天然假设“出错了可以重试”，但企业大量核心场景不允许重试。

第二个特点是需要完整的操作留痕。财务要有一本账，每一步是谁做的、依据什么做的，要能追溯。纯Agent的思维链日志虽然完整，但它产生的操作记录、中间状态没有统一建模，审计方看不懂。

第三个特点是模型在长链路里容易“失焦”。一个合同审核任务，步骤超过五六步，中间涉及金额计算、日期判断、条款比对，模型容易在前面某一步做了错误的决定，后面所有步骤都建立在错误基础上，而且它自己意识不到。这类“错误累积”问题，靠调提示词很难根治。

所以在合同审查这类场景，我强烈建议不要上来就做纯Agent，而是把流程拆成工作流，让Agent负责流程里最适合它的节点（条款语义判断、风险点总结），其余节点用确定性规则锁定。

5. 第四种路径：混合编排，规则与模型的动态平衡

5.1 状态机与超时：混合编排的工程骨架

如果只让我总结一条落地经验，那就是：生产级智能体平台一定是混合架构，工作流打底、Agent嵌入、模型在每个节点里“做判断”。

混合编排的工程基础是状态机。每个流程实例有一个明确的状态，比如“待解析”、“待审核”、“待审批”、“已完成”。工作流引擎负责根据事件推动状态流转，Agent只是其中一个状态里被触发的执行器。这样设计的好处是：出问题时，你可以精准地知道是哪个节点失败了，error可以重试，也可以人工介入，而不是对着一个黑盒子的完整对话记录发呆。

超时处理也必须提前设计。大模型接口的响应时间不像普通API那样稳定，高峰期可能几秒，也可能一分钟以上。在线上环境，我建议每个调用模型或Agent的节点都设置两档超时：第一档是软超时，比如15秒，到达后通知监控系统预警但不中断；第二档是硬超时，比如40秒，超了就标记任务为失败，进入降级处理。降级策略可以是直接拒绝该步骤并通知人工，也可以是切换到备用小模型做简化回答。

5.2 按节点选择执行策略：规则、模型调用还是Agent

混合编排的具体落地，是给每个节点配置执行策略。我在实际工作中按复杂度给任务分了四档，每档对应一种实现方式：

简单规则型任务，比如“金额大于5000则转人工审批”“日期解析失败则修正格式”，直接用代码或条件分支节点搞定，不需要模型参与。

标准化提取型任务，比如“从发票图片中提取发票代码和金额”“从合同PDF中提取合同期限”，用一次性的模型调用，提示词固定，输出强制JSON格式。这类任务比规则更抗干扰，又不会有Agent那种自由发挥的风险。

综合判断型任务，比如“根据简历内容给候选人匹配合适度评分”“根据合同条款判断付款条件是否满足”，需要用几次模型调用，中间可以带少量工具调用。这类任务在一轮评估周期内完成，不涉及多轮自主规划。

复杂决策型任务，比如“一个售后咨询需要跨订单库、产品库、政策库才能回答”“一场供应链异常要综合多条链路信息找原因”，才用完整的Agent编排，让模型自主调用多个工具，多轮推理。

这样分层之后，绝大多数业务节点落在前两档，真正用到Agent的节点不超过20%。随之而来的好处非常明显：第一，系统整体可控性大幅提升；第二，算力成本下降，因为大部分节点只是单次模型调用，用不上多轮Agent的高额token消耗。

5.3 一个合同审查工作流的混合编排实例

拿合同审查这个最典型的场景走一遍混合编排。

流程启动后，第一步文件解析节点。如果上传的是Link类型的合同，就用解析服务做结构化抽取，这个节点是确定性规则，不涉及大模型。

第二步条款完整性校验节点，这里开始用模型做单次调用。把合同原文的关键条款要求作为提示词参数，要求模型输出一个JSON对象，列出“合同名称、签约双方、合同金额、有效期、违约责任”等字段填写情况，对缺失字段标记“缺失”。这一步的效果取决于提示词写得是否细——你给的条款字段列表越清晰，模型输出越稳定。

第三步规则引擎审核节点（确定性代码），根据模型抽取出的字段做初步判断：合同金额大于设定阈值自动进入人工会签流程；有效期缺失自动打回；合同类型为“采购合同”则触发第四步的专家Agent路径。

第四步是真正的Agent节点，只有高风险合同走到这里。它的任务是深度审查：比较合同条款与模板库中的规范条款差异、搜索该供应商的历史履约记录、查看内部风控政策库，最终生成一份审查意见。整个链路可能跨三四个数据源，用Agent自主编排是合理的。

第五步是人工复核节点，审批人看到一个完整的处理链：谁解析的、模型识别了什么、规则引擎哪里拦下了、专家Agent发现了什么风险点。每一步都有据可查。这样设计，法务人员才愿意点击“同意”。

做完这一步，才真正理解为什么说企业智能体平台要“模块化”而不是“一体化”——工作流管流程，RAG管知识，Agent管判断，权限管边界。四者缝合得好，才是一个可以商用的平台。

6. 第五种路径：权限治理闭环，决定平台能走多远

6.1 权限为什么是智能体的“隐形天花板”

功能强大但没人敢用的系统，在企业里很常见。智能体平台如果权限治理做不好，就属于这种。

我见过一家公司的云端Agent因为一个配置失误，能调用内部所有数据库的查询接口。运维发现的时候，Agent已经被业务同事当搜索引擎用了两周，问出了包括全公司薪资中位数在内的一堆敏感数据。那一周团队所有人的状态是“慌”，不是在查日志，而是在反复确认Agent没有对外输出过内容。

权限治理在智能体平台里的特殊性在于：传统系统的权限是基于“人”的，登录了才知道你是谁、你能干什么。而智能体的权限体系要加几层概念：这个Agent是谁授权创建的？它被允许访问哪些知识库？它可以调用哪些工具？它回答问题时禁止调用的数据范围是什么？这些都要细化到数据行和字段级别。

6.2 三层权限控制：接入层、工具层、数据层

在企业里做权限治理，可以按这个顺序逐层落地：

第一层是接入层控制。前置网关对每个访问智能体平台的用户做身份认证，拿到用户的组织归属和角色标签。这一层可以复用企业现有SSO（单点登录）系统，重点是把RABC（基于角色的访问控制）模型建立起来——销售总监、HR专员、普通员工能访问的Agent入口和功能模块完全分开。

第二层是工具层控制。每一个Agent能调用的工具（查询订单的API、提交报销的接口、读合同库的通道）必须有显式的授权清单。Agent发起工具调用时，网关要检查“这个Agent是否拥有该工具的调用权限”。这里经常被忽视的是Agent的API Key权限——不要在Agent配置里放一个拥有全库权限的数据库账号，应该每个Agent用独立的服务账号，配合最小权限原则创建，宁可创建五十个账号，也不要一个账号通吃。

第三层是数据层控制，也是最难的一层。即使Agent通过了接入认证和工具授权，它在RAG检索时仍然可能检索到它“不该知道”的数据。数据层控制要求向量检索之前先做权限过滤：查询条件里带上用户所属组织、数据密级等过滤条件，只从该用户有权访问的文档分片中进行向量检索。更细致的做法是行级权限（Row-Level Security），在知识库表结构里增加一个“可见性”字段，检索SQL里强制拼接这个条件。这样，一个用户问“公司今年给员工的平均薪酬是多少”，模型检索到的候选文档里根本不包含他无权访问的薪酬明细。模型只能基于“它看到的文档”回答，数据权限守住的是“它能看到什么”这个源头。

有个容易踩坑的细节：很多团队的权限过滤做在“回答之后”，即在模型输出答案后再做敏感信息过滤，比如用关键词匹配“薪资”“绩效”就拦截回答。这种做法非常脆弱——企业数据不是靠几个敏感词就能覆盖的，模型可能用“这个人每月的固定收入”这种语义绕开关键词拦截。权限过滤必须前置在数据接入和检索阶段，而不是后置在输出阶段。

6.3 审计日志与可观测性：Agent也可以“留痕”

最后一个关键动作是审计日志。传统系统留痕的是“谁在什么时间对什么数据做了什么操作”，Agent平台的审计日志需要多记录两块：它“认为”自己在做什么，以及它实际调用了什么工具和参数。

我第一次看某团队Agent日志的时候，吃了不小一惊——模型在中间步骤里想过要调一个权限之外的API，但因为工具清单里没有这个API而自动放弃了。日志里能看到这个“想法”，说明模型知道边界。但我在日志里看不到的是：模型为什么没有尝试从别的数据源“绕过”边界。模型自我约束这件事，不总是可靠的，还是要在每一层工具调用时配置强制访问检查。

为Agent做审计日志设计时应当把每次请求分成三个维度记录：身份维度（用户是谁、Agent是谁）、行为维度（调用了哪个工具、传了什么参数、拿到了什么结果）、推理维度（模型的思考摘要、关键的规划步骤）。这样，无论审计还是排障，都可以像查传统系统日志一样，快速定位到具体某个操作。

权限治理的意义不只是“不出事”，它还有一层实际的商业价值：只有把权限边界定义清楚，业务部门才敢把核心数据交给智能体平台，平台才能真正进入生产环境产生价值。权限治理不是限制，而是为Agent“松绑”的前提。

在给客户做架构评审时，我每次都问三个问题：如果这个Agent被注入恶意指令，它能拿到什么？如果它拿到的工具权限膨胀了，谁能第一时间发现？如果它执行了一个代价高昂的操作（比如批量发送邮件），有没有一票否决的开关？这三个问题答不上来，架构先别急着上线。智能体平台的落地没有捷径，工作流是骨骼、RAG是血肉、Agent是大脑、权限是免疫系统，把不完整，平台就是脆弱的。反过来，把这些环节逐一打磨清楚，智能体平台的价值释放只是时间问题。