企业智能体落地五大路径：工作流、RAG与权限治理的工程实践

1. 企业智能体平台卡在哪儿：不是模型不够聪明，是工程欠账太多

我从去年开始密集接触企业智能体平台的落地项目，前后经手了制造、零售、金融科技方向的七八个案例。一个很扎心的现象是：几乎所有项目在Demo阶段都惊艳全场，一到生产环境就翻车。有的平台采购进来半年，只有一个客服问答机器人在跑；有的连这个都没跑起来，卡在安全评审上。问题出在哪？不是说大模型不够聪明，而是围绕智能体平台的那套工程体系——工作流编排、RAG知识库、权限治理——根本还没跟上。

1.1 "工作流"三个字，在不同人嘴里是三种东西

先说一个特别有意思的细节。我平时会关注一些技术社区的热搜词，发现"工作流"这个话题下的搜索意图极其分裂：有人搜"nginx中location工作流机制"，有人搜"comfyui满血版整合包下载"，有人搜"coze工作流搭建"，还有人搜"markdown转word工作流coze"。同样一个词，后端工程师想的是请求处理链路，AIGC玩家想的是绘图节点的连线，低代码用户想的是自动化流程，企业IT想的是OA审批流。

这个现象看起来是搜索习惯问题，但它恰恰是企业智能体平台落地的第一道坎：需求评审会上，业务方说"我们要一个自动流程"，算法工程师理解成"让Agent自主决策"，IT运维理解成"部署一套BPM流程引擎"，产品经理理解成"在低代码平台上画几条线"。三方聊了两个小时，最后发现说的根本不是同一个系统。

我在一个制造企业的项目里就栽过这个跟头。他们说要做一个"设备故障报修智能体"，业务方的预期是：员工拍照上传，系统自动识别故障类型、派单、跟踪维修进度。但IT部门理解的是：把现有的工单系统流程接进来，做一个表单自动填写和流转。算法团队想的是：用多模态大模型直接分析图片、判断故障原因。三方对"工作流"的理解完全不同，结果需求文档改了四版才对齐。所以我现在做任何项目，第一件事永远不是选技术栈，而是把"工作流"这个词在每个人嘴里的含义先掰扯清楚。

1.2 RAG、权限治理这些词，站在"听起来会"和"真会"之间

继"工作流"之后，第二道坎是RAG。这个词现在太火了，随便一搜就是"rag教程""rag实战""怎么在mac上搭建rag知识库"。个人开发者在Mac上跑通一个RAG demo，和企业在生产环境里维护一个RAG知识库，完全是两码事。个人只要把文档切碎、向量化、扔进向量库就能出结果，而企业要考虑的是：文档版本怎么管理？切片策略怎么定才不会把一句话拦腰截断？上下文超长了怎么办？召回不准了怎么调？这些才是真正决定RAG能不能用的环节。

权限治理就更不用说了，它是智能体平台里最容易被忽视、但出事最严重的部分。智能体和人的一个本质区别是：人可以用制度约束"不该看的别看"，Agent不行，它天生就是个数据饕餮，你给它多少权限它就会用多少。如果权限体系设计不到位，轻则数据泄露，重则整个平台被IT封禁下架。我一个朋友的公司，测试阶段就把权限全放开了，结果一个实习生通过智能体查到了全员的薪资数据，第二天平台就被安全部门封了，项目直接停摆三个月。

我把这些年在企业智能体落地过程中反复踩的坑梳理了一下，大体可以归纳成表格里的几个维度：

卡点维度	常见表象	热搜词背后暴露的用户需求	真正的工程难点
工作流编排	流程画好了却跑不通，或跑通了但遇到异常就挂	工作流搭建、工作流编码、上下文超长	状态管理、分支条件、人工兜底、可控性
RAG知识库	问答效果时好时坏，文档更新后答案还是旧的	rag瓶颈、kg知识库、知识库能存图片吗	召回质量、切片策略、多知识库协同
权限治理	要么管太死导致没人用，要么管太松导致数据泄露	权限治理（平台建设方痛点）	细粒度授权、数据隔离、审计追踪

1.3 三个我亲眼见过的失败姿势

失败的姿势其实都长得差不多。第一种是从Demo直接上线，没有做确定性控制。业务人员看演示时觉得太神奇了，什么都能答，结果一上线面对真实数据就胡言乱语，而且没有工作流兜底，错得毫无章法，业务部门当场失去信心。第二种是买了大模型API就以为万事大吉，数据治理一塌糊涂，RAG检索出来的内容连基本的事实一致性都保证不了。第三种就是刚才说的权限问题，全员放开之后出了安全事故，整个项目被一票否决。

这三种失败有个共同的底层原因：把一个需要分层设计、逐步验证的系统工程，当成了一次性的大模型接入。接下来我要讲的五种实现路径，本质上就是针对"工作流、RAG、权限治理"这三个维度，给不同处境的企业提供不同的切入顺序和架构组合。它们不是互斥的，更多时候是同一家企业不同阶段的选择。

2. 路径一：工作流优先，先求确定性再求智能

如果你所在的企业容错率极低——比如财务、生产、法务这类场景，那我强烈建议第一条路走"工作流优先"。这个路径的核心思路是：先把能确定的业务逻辑全部用工作流固化下来，让智能体在划定的轨道里发挥作用，而不是一上来就给它完全的自由。

2.1 为什么先做工作流而不是先上Agent

很多团队一提到"智能体平台"就兴奋，觉得终于可以让AI自己规划任务、自己调用工具了。但企业环境的现实是：业务方最怕的不是"不够智能"，而是"不可控"。工作流解决的核心问题，就是把决策路径显性化。每一步做什么、什么条件走哪个分支、遇到异常怎么办，全部画在图上，可回退、可审计、可替换。出了问题，你能指着流程图说"就是这一步错了"，而不是对着一团黑色的Agent行为日志挠头。

我自己的经验是这么把握边界的：凡是业务逻辑里有明确的判定条件（比如"金额大于一万走二级审批""学历是本科以上才进入下一轮"），一律写成工作流节点；凡是需要语义理解、没有标准答案的（比如"总结这份合同的风险点""判断这张图片的故障类型"），才交给大模型。这个原则帮我在好几个项目里避免了"Agent自由发挥闯祸"的悲剧。

2.2 低代码平台选型：Coze、Dify、n8n怎么选

工作流优先路径上，绝大多数团队不会从零自研引擎，而是选一个低代码平台起步。我实际用过Coze、Dify、n8n，也见过不同规模企业的选型，简单分享下我的判断：

• Coze（扣子）：上手最快，插件生态丰富，和国内主流模型平台衔接顺畅。适合想快速验证场景、且对数据隐私要求不那么苛刻的团队。很多"毛坯房拍照生成效果图"这类创意工作流，用Coze搭建非常快。但它的私有化部署能力偏弱，深度定制要受平台约束。
• Dify：开源力度大，可以私有化，RAG能力相对完整，适合要做知识库问答、且需要一定程度定制的企业。搜"Dify工作流上下文超长"的人特别多，说明大家都在这类细节上卡过壳。
• n8n：定位是自动化连接，擅长把各种系统串起来，但它的AI原生能力不如前两者。适合已经有成熟业务系统、只差流程打通的企业。

我的建议是：中小团队用Dify或Coze起步，大型企业可以把Dify私有化后作为工作流底座之一，但不要指望一个平台解决所有问题。我见过太多团队花三个月说服领导引入某个平台，结果它既做不好复杂流程编排，又做不好权限管理，最后沦为玩具。

2.3 一个真实案例：简历筛选工作流的搭建全流程

拿"简历筛选"这个热门场景举个例子。一家中型公司HR每天收几百份简历，人工初筛耗费大量时间，想做个智能体先过滤一轮。很多人一上来就想让大模型"读简历、给判断"，但我落地时是先拆工作流的：

1. 输入解析节点：接收PDF/Word简历，转成统一文本格式，提取姓名、学历、工作年限、技能标签等字段。这个节点是纯规则加少量模型调用，不需要自我规划。
2. 硬性条件过滤：学历门槛、工作年限、必备技能关键词，这些都用确定性规则写死。比如"全日制本科以上"就是一道布尔判断，不需要大模型参与。
3. 语义评估节点：对通过硬性条件的简历，让大模型进行综合素质打分，比如项目经历匹配度、技能深度。
4. 结果入库与通知：把评分结果写回表格，通知HR在后台查看。注意，这里没有做"自动拒信"，因为HR要求保留人工确认环节。

整个流程跑下来，简历初筛效率提升了约七成，但真正有价值的是那个"人工复核"节点。最开始我没有加这个节点，直接自动淘汰了一批简历，结果用人部门发现有几个明明很合适的候选人被误杀了，因为简历里写了"自考本科"被规则判为不达标，但业务方其实不介意。这种纠错成本完全可以在工作流里通过一个"低分复议"分支来规避。

2.4 工作流路径的边界：上下文超长、循环、分支复杂性

工作流不是银弹，用多了也有麻烦。最常见的是"上下文超长"问题。比如用Dify搭工作流时，如果在某一步把大量知识库内容塞进上下文，很容易就把模型窗口撑爆，造成回答质量下降甚至报错。我的做法是尽量让每个节点的输入瘦身——能用规则完成的用规则，能查表的查表，最后只把必要信息拼进提示词。

还有一个容易失控的是循环。有些平台允许在工作流里写循环，但循环意味着Token消耗和成本不设上限。我见过一个团队在调试阶段写死循环造成的高额账单，这其实不算平台坑，而是工程意识问题。我的建议是给所有循环设最大次数，超过就走兜底分支，输出告警让人介入。工作流路径适合的是"路径基本固定、异常可枚举"的场景，真遇上完全不可预料的开放式任务，它确实力不从心，那就得看后面的路径了。

3. 路径二：RAG核心，知识库的质量决定智能体的上限

第二条路，也是最容易被神化的一条：RAG。但凡做企业智能体，基本绕不开知识库问答。但RAG真正的瓶颈从来不在模型，而在检索链路和知识治理。

3.1 RAG瓶颈不是模型，是"召回"和"上下文"

搜"rag瓶颈"的人很多，大家的体感基本一致：一开始跑个demo觉得效果惊艳，放到真实数据上就现原形。问题通常出现在两个地方。

一个是召回。向量检索的TopK设置、相似度阈值、切片粒度、重排序（Rerank）环节，每个都直接影响召回质量。我见过一个售后知识库项目，最初没做重排序，用户问"退换货政策是什么"时，系统召回的前几条全是"退换货流程注意事项"之类的内容，答非所问。后来在召回后加了一道Rerank，把语义相关性最高的几条顶上去，效果立刻不一样了。很多教程不会提这一点，因为单条文档demo里根本看不出来。

另一个是上下文窗口。模型窗口有限，不可能把所有相关资料都塞进去。"Dify工作流上下文超长"这个热搜，本质就是这类问题。我的处理思路是先做"答案候选排序"，只取最相关的3~5个chunk进上下文；如果这3~5个chunk不够回答，再触发二次检索，而不是一上来就贪多。这样既控制成本，又能显著提升回答的精准度。

3.2 三种知识库的正确区分：RAG知识库、KG知识库、结构化知识库

"kg知识库、rag知识库和结构知识库区分以及应用场景"这个热搜词背后，是很多人把三种知识库混为一谈。这三种东西在企业落地中各有各的位置，我用一张表说清楚：

类型	存储/查询方式	擅长场景	主要局限
RAG知识库	非结构化文档切片后向量化，语义检索	制度文档、产品手册、FAQ等自由文本问答	召回不稳定，多跳推理弱，更新管理麻烦
KG知识库	实体、关系、属性构成的知识图谱	供应链关系、系统拓扑、人员组织等关系密集型查询	构建成本高，需要本体设计，维护难
结构化知识库	数据库/表格，SQL或接口查询	指标、参数、配额等精确数值类问答	语义理解弱，需要跟自然语言中间层配合

实际项目里，往往还会提到"ontology rag"——就是把本体建模的思路融进RAG，用知识图谱辅助多跳查询。比如用户问"哪个供应商同时给A产品线供货并且位于华东地区"，纯RAG很难跨文档关联，但如果有一张供应商图谱，就能一步步推理出来。但这里要泼一盆冷水：构建KG成本很高，如果不是高频关系查询场景，先别急着上图谱，用结构化表格加规则查询往往就够了。

3.3 实操：从文档到可用的RAG知识库，以及"知识库能存图片吗"这类问题

搜"怎么在mac上搭建rag知识库"的开发者很多，个人版搭建教程遍地都是。但企业级的搭建没有本质差别，差在数据源管理和维护流程。我一般按这几步走：

1. 文档清洗：剔除页眉页脚、重复段落、无意义表格。这一步最耗时，但决定了下游质量。
2. 切片策略设计：不要机械地按字数切，而是按语义块切。比如一个合同章节、一个FAQ问答对、一段产品参数说明，各自作为一个chunk。很多翻车案例都是因为把一个完整句子拦腰截断，导致检索时语义残缺。
3. 向量化与索引：选择合适的Embedding模型，建立索引时带上元数据（文档来源、版本、部门），方便后续过滤。
4. 检索链路设计：召回 + 重排序 + 相关度阈值控制。
5. 答案引用溯源：每条回答都要能指向原始文档，这是企业场景的硬要求。

至于"rag知识库能存储图片嘛"这个问题，我的回答是：RAG知识库本身不适合存图片，因为向量模型是文本导向的，图片进去了也检索不出有效信息。但图片里的知识值得存。我做过一个售后场景，把产品手册里的示意图用OCR识别成文本，再按图片用途重新结构化，结果相关的问答准确率提升非常明显。如果你确实要保留原始图片，正确做法是对象存储加元数据索引，图片本身不作为检索对象，而是作为附件返回。

3.4 RAG的"翻车"案例与对策

两个典型的翻车案例。第一个是切片导致的语义分裂：一份合同里，前面写"甲方为张三"，后面隔了两页写"乙方为李四公司"，被切成了两个chunk，用户问"甲乙双方分别是谁"时，系统只召回了一半，答了个寂寞。对策是把"合同主体信息"这类高内聚内容单独提取成结构化字段，不依赖chunk召回。

第二个是文档新旧版本混存。企业知识库经常是PPT、Word、PDF多版本并存，老版本没下线，新版本也没上线，结果同一个问题，系统时而答新版时而答旧版。这个问题没有技术捷径，必须在入库前做版本核对和数据更新机制，我甚至见过团队专门开发了一个"知识库文档生命周期管理"的脚本，定时扫描过期文档并自动下线。知识库这东西，建起来容易，维护起来全是脏活累活。

4. 路径三：权限治理先行，管住数据才能放手智能

第三条路径是我的压箱底建议：如果企业处在强监管行业，或者数据敏感度极高，请把权限治理放在所有技术之前。这不是锦上添花，而是生死线。

4.1 权限治理为什么是智能体落地的咽喉

我前面提过那个因为越权查询导致平台被封的案例，那不是孤例。智能体这类系统有一个很尴尬的特性：它没法像人一样"自觉"。你给一个人开权限时，可以反复叮嘱他"只能看自己部门的数据"，他大概率能记住；但Agent不会，它会忠实地把你授予的接口权限全部用满，直到某个用户通过它摸到了不该看的数据。

另一个现实是，很多智能体平台的权限设计还停留在"登录认证"层面——只要你能登录系统就能调用全部知识库。这在个人工具里没问题，但在企业里完全行不通。企业普遍存在多部门、多层级、多角色，你必须做到"用户只能检索到他有权限看到的内容"，否则项目根本过不了安全部门的评审。

权限治理路径的三件套是：身份认证、细粒度授权、审计追踪。身份认证负责确认"你是谁"，细粒度授权负责决定"你能看什么"，审计追踪负责记录"你实际看到了什么、做了什么"。缺少任何一环，平台在强监管环境下都寸步难行。

4.2 落地细节：文档级、行级、API级三层权限

从工程实现角度，我一般把权限切成三层来设计，每一层解决一个问题：

• 文档级权限：主要作用于RAG检索链路。用户在发起问答前，系统先根据用户所属角色过滤知识库索引，只在他可见的文档集合内做检索。比如销售部的员工只能检索销售制度，不能检索薪酬文档。这一层是在向量检索之前干的。
• 行级权限：主要作用于结构化数据查询。比如老板能看到全公司销售报表，普通销售只能看到自己的业绩。实现上可以做成SQL动态拼接、视图隔离，或者查询中间件统一注入权限条件。智能体调用数据库时，必须先过这一层。
• API级权限：主要作用于Agent调用外部系统执行操作。比如让智能体帮你提交报销单、改工单状态，它调用的是业务系统的API。这里要用服务账户、OAuth令牌、最小权限角色来限制Agent能执行什么操作，并且每一次操作都要留痕。

我见过最常见的坑是把三层混为一谈。有的团队只做了登录认证，结果用户在对话里诱导Agent"顺便查一下其他人的工资条"——如果文档级权限没做，系统真的会去检索本不该返回的文档。还有的团队只限制了检索，但没限制API操作权限，导致Agent被提示词注入后改了系统数据。这三层一个都不能省，不是说都做得很重，但每一层都至少要有一个最小可行的控制点。

4.3 一个最小可行的治理方案

有些团队听到"权限治理"就头大，觉得要先搞一套复杂的权限引擎。其实从最小可行方案做起，完全够用：

1. 数据分类分级：把知识库和数据库里的内容按敏感度分等级，比如公开、内部、敏感、机密。
2. 角色权限矩阵：定义平台上有哪些角色（普通员工、部门主管、HR、财务、管理员），每个角色能看哪些等级的数据，能执行哪些操作。
3. Agent角色绑定：每个智能体服务一群固定角色，在系统层直接绑定最小权限集，用户不可越权。
4. 审计日志：记录所有对话中实际检索过的文档和实际调用过的API。哪怕平时不怎么看，出了事能查。
5. 定期复核：每季度检查一次权限矩阵是否有松动，尤其是离职员工的服务账号是否已回收。

这个方案不高大上，但它足够让智能体平台在安全评审里过关，而且后续扩展也不费劲。权限治理的核心理念就四个字：默认拒绝。宁可先让员工觉得"这个AI怎么好多东西查不到"，也不能让他们觉得"这个AI什么都能查到"。

5. 路径四：混合架构，让工作流和Agent各干各擅长的事

真正做得顺的项目，到后期都会走向混合架构。纯工作流解决不了开放性问题，纯Agent解决不了确定性和安全问题，两者必须配合。

5.1 为什么纯工作流和纯Agent都有天花板

纯工作流的天花板很明显：一旦遇到流程定义之外的情况，它就"挂"在那儿了。比如简历筛选工作流里突然出现一份视频简历，规则节点就不知道怎么处理。纯Agent的天花板同样明显：自由度太高，幻觉和越权风险居高不下，业务部门很难放心让它直接执行生产操作。

所以我现在落地项目的通用原则是：凡是"可判定的"交给工作流，凡是"需要语义理解的"交给Agent，凡是"需要外部事实的"交给RAG/知识库。实际操作中，Agent主要承担"理解用户意图、规划子任务、做综合判断"这三个角色，而真正执行任务时，优先走确定性工作流节点。

5.2 一个可落地的混合编排模式

拿智能客服工单处理举例。一个用户提交"打印机坏了，报修"，整个链路是：Agent先理解意图（这是设备报修类的意图），然后进入工作流：填写工单字段 → 查询资产台账 → 匹配维修维保服务商 → 生成派单。到了"匹配服务商"这一步，如果台账里没有明确对应关系，Agent再介入做语义匹配。这就是典型的"入口由Agent理解，执行由工作流兜底，特殊情况再由Agent补位"。

混合架构里最难管的是上下文。Agent每多轮对话，前面聊的内容都会占窗口，多轮之后就容易出现"忘记前面说过什么"的问题。我在工程上一般做两个控制：一是给Agent设置最大轮数和最大工具调用次数，超了就主动转人工；二是做"上下文压缩摘要"，把冗长的历史对话压缩成一句摘要，保持关键信息不丢失、Token不爆量。

5.3 工程实现层面的坑

混合架构最大的坑，其实出现在"低代码平台原型转正式系统"的时候。搜"dify工作流转成spring ai java代码github"的人很多，说明不少团队先把原型在Dify里跑通，然后想转成正式的Java工程。我的经验是：转换不是简单翻译节点，低代码平台里隐含的状态管理、错误传播、重试机制，都要在代码里重新设计。否则你只是把原型的缺陷原封不动搬进了生产环境，还多了一层技术债。

另一个工程坑是可观测性。混合架构里一个请求可能横跨Agent调用、多个工作流节点、若干次RAG检索，一旦出错，排查链路极其痛苦。所以一定要提早做追踪（Trace）。我在项目里要求所有关键节点都输出结构化日志，包含节点ID、输入输出摘要、耗时、Token消耗。有了这个，生产环境出问题才算有救，否则就是在黑暗里摸象。

6. 路径五：渐进式集成，不推翻现有系统的改造路线

最后一个路径，说的是无数企业面临的一个现实：不可能为了上智能体平台，把整个IT系统推翻重来。渐进式集成，是风险最低、也最容易被业务和IT同时接受的路。

6.1 从Copilot到Agent，企业级智能体的爬坡路线

我现在的口头禅是：先做Copilot，再做Agent。所谓Copilot，是"人做决策，AI做辅助"，比如在客服系统里加一个实时回答建议（人工客服决定是否发送），在报表系统里加一个数据解读功能（业务人员自己核对），在代码平台里加一个代码补全。这个阶段，AI的容错空间很大，因为人在兜底，业务影响可控。

等Copilot模式跑顺了、数据链路稳了、权限模型验证过了，再升级成真正的Agent——也就是AI可以独立完成某些动作，比如自动回复常见工单、自动生成日报、自动提交低风险申请。这么做的好处是，每一步的ROI都好计算，业务部门不会因为一次翻车就全盘否定，IT部门也有足够时间打磨底层基础设施。

我见过一个零售企业就是这么爬坡的：第一年只做"智能商品描述生成"，运营人员人工确认后再发布；第二年才把"自动同步到多平台店铺后台"做成Agent。因为第一年把商品数据的标准、权限隔离、审核流程全理顺了，第二年的Agent上线几乎没费劲。

6.2 与Java后端生态集成的现实问题

国内企业大量系统是Java技术栈（Spring Boot/Spring Cloud），这件事绕不开。"dify工作流转成spring ai java代码"这个热搜说明很多人正在做类似的集成。我的建议分两层看：

如果只是调用大模型能力做问答，没必要把整个AI逻辑写进业务代码，更合理的做法是搭建一个独立的AI服务层，统一封装模型调用、知识库检索、Token计费和权限校验，业务系统通过API网关调用它。这样模型升级、换供应商，都不影响业务系统。

如果要实现复杂的流程编排，不要把编排逻辑全部塞进业务代码。AI服务层应该通过消息队列（比如Kafka/RocketMQ）与业务系统解耦：AI服务发起"待办任务"，业务系统消费消息后执行具体操作，再把结果回传。这种事件驱动的方式，能最大程度避免智能体故障时把主业务流程拖挂。

6.3 我从几个成功项目里总结的落地顺序

综合看下来，渐进式集成的落地顺序基本固定，也不太容易出错：

1. 选一个高频、小范围、低风险的场景切入。比如内部知识库问答、工单分类，不要一上来就碰核心交易链路。
2. 把它端到端跑通，注意不只是Demo，而是接真实数据、服务真实用户。跑通的意思是"业务部门愿意用，而不是迫于领导压力点两下"。
3. 建立反馈闭环。每一个AI输出都要有"有用/没用"的评价入口，定期用这些反馈做效果评估和提示词优化。
4. 验证了技术和组织协同之后，再横向复制到第二个、第三个场景。

这个顺序听起来平淡，但确实就是我见过最稳的玩法。企业智能体落地不靠一场大决战，靠的是一个个小战役攒出来的信任。

7. 落地前问自己十个问题，以及我最后的建议

说了这么多路径，最后绕回到落地判断。我把它总结成一张检查清单，你在立项之前逐条过一遍，能省掉后面大半的返工。

1. 有没有明确且可度量的业务场景？如果只能说"我们要做个智能助手"，那说明还没想清楚。
2. 数据源理清了吗？数据在哪、什么格式、谁来维护、时效性如何？没有数据源的智能体是无米之炊。
3. 知识库是单一的还是多源的？多源场景下，版本冲突和更新策略有没有预案？
4. 业务流程边界清晰吗？哪些步骤可以自动化，哪些必须人工兜底？
5. 权限模型能覆盖所有用户角色吗？尤其是跨部门、跨层级的查询场景，能不能做到数据级隔离？
6. 有没有审计追踪和不可抵赖机制？出了问题能不能定位到人、定位到对话、定位到数据？
7. 评估标准是什么？回答准确率、任务完成率、节省工时，还是用户满意度？没有评估标准，优化无从谈起。
8. 成本模型算过吗？高峰期并发下的Token消耗、向量库存储、模型调用费用，是不是可持续？
9. 模型和平台的可替代性如何？如果厂商涨价或能力不达标，你能不能平滑迁移？
10. 有没有Plan B？当智能体抽风时，人工接管通道是否畅通？

最后再分享一点个人体会。我经手的项目里，最容易成功的不是技术最强的团队，而是愿意先砍需求、先把小场景做透的团队。企业智能体平台这件事，成功的标志从来不是"AI有多聪明"，而是业务部门是否愿意把真实的生产动作交给它。你不需要在一次落地中同时搞定工作流、RAG和权限治理，你可以按我的路径建议，先选择最贴合你当前痛点的那一条走通，剩下的再一步步补齐。这本身就是一条值得完整走一遍的路径。