企业智能体平台落地：工作流编排、RAG与权限治理的工程实践

1. 企业智能体平台落地难的根因不在模型，而在工程链路

过去一年我参与过三个企业级智能体平台的选型与落地，从最初的兴奋到中期的怀疑再到最后的冷静，这个心路历程相信很多同行都经历过。Demo阶段一切都很美好：接上大模型，挂一个知识库，写两段提示词，智能体就能回答问题了。但一旦进入真实业务场景，问题就像潮水一样涌出来——回答不准、权限混乱、工作流跑不通、知识库更新滞后、审计追不到责任人。企业智能体平台难落地，根本原因不是模型不够强，而是从工作流编排、RAG检索增强、到权限治理这一整条工程链路没有打通。

这篇文章我想把踩过的坑和验证过的路径完整梳理一遍。核心围绕五个方向展开：工作流引擎的选型与编排逻辑、RAG从朴素检索到知识图谱增强的演进、权限治理与行为审计的设计、平台化智能体与代码化智能体的取舍、以及五种可落地的实现路径对比。适合正在做企业智能体平台选型的技术负责人、正在从Demo转向生产的开发者，以及想搞清楚RAG和工作流到底怎么配合的产品经理。全文基于实际项目经验，不堆概念，直接讲什么方案在什么场景下管用、什么方案看着美好但落地就崩。

先说一个反直觉的结论：企业智能体平台落地失败的项目里，超过七成不是败在模型能力上，而是败在工程链路的断裂。模型可以换，但工作流编排、知识库结构、权限体系这些东西一旦设计错了，后期改造成本极高。所以这篇文章的重点不在模型选型，而在模型之外的那些“脏活累活”。

2. 工作流引擎：从轻量级编排到复杂业务流转的选型逻辑

2.1 为什么企业场景离不开工作流，而不是纯对话

很多人一开始会问：智能体不就是对话吗，为什么还要工作流？这个问题我在项目初期也被问过无数次。答案很简单：企业业务不是一问一答就能完成的。比如简历筛选这个场景，它不是“用户问一句、智能体答一句”就结束了，而是需要经历简历解析、条件匹配、打分排序、人工复核、结果通知这一整条链路。纯对话式智能体只能完成其中某一环，而工作流引擎负责把这一环一环串起来。

工作流的核心价值在于确定性。大模型的输出是不确定的，但企业业务要求某些环节必须确定——比如权限校验必须通过才能进入下一步，比如打分低于阈值必须触发人工复核。工作流引擎提供的条件分支、循环、并行、异常捕获这些能力，就是把不确定的模型输出嵌入到确定的业务流程中。

我见过一个典型的失败案例：某团队用纯对话方式做简历筛选智能体，用户上传简历后智能体直接给出“推荐/不推荐”的结论。上线一周就被业务方叫停了，原因是无法追溯——为什么推荐这个人？打分依据是什么？哪个环节出了问题？没有工作流，就没有中间状态的记录，也就没有可解释性和可审计性。

2.2 轻量级工作流与重型工作流的分界线在哪里

工作流引擎的选型，核心是判断你的业务复杂度落在哪个区间。我把工作流大致分为三档：

轻量级和重型的分界线，我的经验是看三个指标：人工介入节点的数量、跨系统调用的次数、以及状态需要持久化的时长。如果人工介入超过两个节点，或者需要调用三个以上外部系统，或者一个流程可能跨越数天，那就必须上中量级以上的方案。

轻量级工作流（比如Coze工作流、Dify工作流）的优势是上手快、可视化编排、调试方便。但它们的短板也很明显：上下文长度受限、复杂条件分支表达能力弱、状态管理简单。我遇到过Dify工作流上下文超长导致流程中断的情况，也见过Coze工作流在复杂嵌套条件下编排混乱的问题。所以轻量级方案适合快速验证，但不适合直接承载核心业务。

2.3 工作流编码：可视化编排和代码化编排怎么选

这是我在项目中纠结最久的一个问题。可视化编排（拖拽式）和代码化编排（写代码定义流程）各有优劣，我的结论是：原型阶段用可视化，生产阶段用代码化，或者混合使用。

可视化编排的优势在于沟通成本低。业务方能看到流程图，产品经理能直接调整节点，开发只需要关注每个节点的具体实现。但可视化编排的致命问题是版本管理和测试困难。当流程变得复杂时，拖拽出来的流程图很难做diff，很难写单元测试，很难做CI/CD。

代码化编排（比如用LangChain4j、Spring AI或者自研DSL）的优势是版本可控、可测试、可复用。但缺点是业务方看不懂，沟通成本高。我的折中方案是：用可视化工具做流程设计和沟通，用代码化方式做最终实现。具体做法是让业务方在Dify或Coze上拖出流程原型，确认逻辑无误后，开发用代码重新实现一遍，保证可维护性。

这里分享一个实操技巧：工作流编码时，每个节点都要设计成幂等的。因为工作流重试是常态，如果节点不幂等，重试就会产生重复数据。比如“发送通知”这个节点，如果不做幂等处理，重试三次就会发三封邮件。我的做法是给每个节点加一个唯一执行ID，执行前先检查该ID是否已执行过。

2.4 工作流与智能体的边界：什么该交给模型，什么该交给流程

这是设计工作流时最容易犯的错误——把太多东西交给模型。我的原则是：确定性逻辑交给工作流，模糊判断交给模型。

举个例子，简历筛选工作流中，“学历是否满足本科以上”这是确定性逻辑，应该用代码判断，不应该让模型去判断。而“工作经历与岗位的匹配度”这是模糊判断，适合交给模型。如果把确定性逻辑也交给模型，不仅浪费token，还会引入不确定性——模型可能今天判断对，明天判断错。

再比如客服场景，用户问“我的订单到哪了”，这是确定性查询，直接调订单系统API就行，不需要模型介入。用户问“我想退货但不知道怎么操作”，这才需要模型理解意图并生成回复。工作流负责路由和编排，模型负责理解和生成，各司其职。

我见过一个反模式：把所有节点都做成“模型节点”，每个节点都调一次大模型。结果是一个简单流程跑了十几次模型调用，延迟高、成本高、还不稳定。正确的做法是只在真正需要语义理解的地方调用模型，其他环节用规则、用代码、用API。

3. RAG的深水区：从朴素检索到知识图谱增强的演进路径

3.1 朴素RAG为什么在企业场景下不够用

RAG（检索增强生成）刚出来的时候，大家都觉得找到了银弹——把文档切块、向量化、存进向量库，查询时检索相关片段喂给模型就行了。但真正在企业场景用起来，问题一大堆。

最典型的问题是检索不准。用户问“公司年假政策是怎样的”，朴素RAG可能检索到的是“请假流程”而不是“年假政策”，因为两者在向量空间里距离很近。或者用户问“报销标准”，检索出来的却是“报销流程”。这种语义相近但意图不同的情况，在向量检索里非常常见。

第二个问题是上下文碎片化。文档被切成小块后，每个块只包含局部信息。用户问一个需要跨段落综合的问题，比如“对比去年和今年的差旅报销标准变化”，朴素RAG只能检索到零散片段，模型拼不出完整答案。

第三个问题是无法处理结构化查询。用户问“研发部门有多少人”，这需要查数据库，而不是检索文档。朴素RAG只能处理非结构化文本，遇到结构化数据就无能为力。

我在一个项目中做过统计：朴素RAG在简单事实性问答上准确率能到80%左右，但在需要推理、对比、综合的问题上，准确率直接掉到40%以下。这就是为什么企业场景需要更高级的RAG方案。

3.2 知识图谱增强RAG：什么时候值得上，什么时候是过度设计

知识图谱增强RAG（KG-RAG）是这两年的热门方向。核心思路是把文档中的实体和关系抽取出来，构建知识图谱，检索时同时利用向量检索和图谱查询。这样做的好处是能处理关系型问题，比如“A项目的负责人是谁的上级”。

但我要泼一盆冷水：知识图谱增强RAG不是万能药，很多场景下是过度设计。构建知识图谱的成本极高——需要实体抽取、关系抽取、图谱构建、图谱维护，每一步都是坑。而且图谱的质量高度依赖抽取模型的准确率，抽取错了，图谱就是错的，检索结果更差。

我的判断标准是：如果你的业务问题中超过30%涉及实体间关系查询，才值得上知识图谱。比如医疗诊断、金融风控、供应链溯源这些场景，实体关系是核心，图谱增强有价值。但如果只是文档问答、政策查询、产品说明，朴素RAG加上好的切块策略和重排序就够了。

这里要区分三个概念：KG知识库、RAG知识库和结构化知识库。KG知识库存储的是实体和关系，适合关系推理；RAG知识库存储的是文本片段和向量，适合语义检索；结构化知识库存储的是表格和字段，适合精确查询。三者不是替代关系，而是互补关系。我的做法是根据问题类型路由到不同的知识库：关系型问题查KG，语义型问题查RAG，精确型问题查结构化库。

3.3 RAG知识库能不能存图片：多模态检索的工程实践

“RAG知识库能存储图片吗”这个问题我被问过很多次。答案是能，但要看怎么存、怎么检索。

最简单的做法是图片转文字描述再向量化。用多模态模型给图片生成描述，把描述文本存进向量库。检索时检索到描述，再把原图返回。这种做法实现简单，但丢失了图片的视觉信息，对于需要看图的场景（比如产品外观对比）效果不好。

进阶做法是用多模态嵌入模型直接对图片向量化。比如CLIP这类模型可以把图片和文本映射到同一向量空间，检索时可以用文本查图片，也可以用图片查图片。这种做法效果好，但工程复杂度高，需要部署多模态嵌入模型，存储成本也更高。

我的建议是：如果图片是辅助信息，用第一种方案就够了；如果图片是核心信息，才考虑第二种方案。大多数企业场景下，图片只是文档的配图，转成文字描述完全够用。真正需要多模态检索的场景（比如电商以图搜图、工业质检图像对比）才值得上多模态嵌入。

3.4 RAG实战中的切块策略与重排序：决定效果的关键细节

RAG效果好不好，切块策略和重排序比模型选型更重要。我见过太多团队花大量时间选模型，却用默认的切块参数，结果效果一塌糊涂。

切块策略的核心是块大小和重叠度。块太小，上下文不完整；块太大，检索精度下降。我的经验值是：中文文档块大小512-1024字符，重叠100-200字符。但这个值不是固定的，要根据文档类型调整。技术文档结构清晰，可以按标题切块；对话记录没有明显结构，只能按固定长度切。

更高级的做法是语义切块——用模型判断句子之间的语义边界，在语义完整的地方切。这种做法效果好，但计算成本高。我的折中方案是先用规则切块，再用模型对边界做微调。

重排序是另一个关键环节。向量检索返回的Top-K结果，顺序往往不是最优的。用一个重排序模型（比如Cross-Encoder）对候选结果重新打分排序，能显著提升精度。我实测下来，加上重排序后，RAG准确率能提升15-25个百分点。重排序模型不需要太大，一个小型的Cross-Encoder就够了，延迟增加在可接受范围内。

还有一个容易被忽略的点：元数据过滤。检索时不仅要看语义相似度，还要看元数据。比如用户问“2024年的政策”，就应该只检索2024年的文档。如果不在检索时加元数据过滤，模型可能拿到2023年的文档，给出过时答案。

4. 权限治理与行为审计：企业智能体平台的安全底座

4.1 智能体行为审计到底审什么

“智能体行为审计”这个词听起来很虚，但落到实际项目中非常具体。审计的核心是回答四个问题：谁、在什么时候、让智能体做了什么、结果是什么。

具体来说，需要记录的信息包括：用户身份、会话ID、调用的智能体、输入内容、模型调用记录、工具调用记录、知识库检索记录、输出内容、执行时长、token消耗。这些信息不仅要记录，还要能关联查询——比如查出某个用户在过去一周内所有涉及敏感数据的操作。

我在项目中遇到过一个问题：智能体回答了一个不该回答的问题，但排查时发现日志只记录了最终输出，没有记录中间过程。不知道它检索了哪些文档、调用了哪些工具、模型是怎么推理的。后来我们强制要求每个环节都要打点，包括检索到的文档ID、工具调用的参数和返回值、模型的完整输入输出。这样才能做到可追溯。

审计日志的存储也有讲究。日志量很大，不能全量存热存储。我的做法是热存储保留最近7天，温存储保留最近90天，冷存储归档一年。查询时根据时间范围路由到不同的存储层。

4.2 权限治理的三层模型：用户权限、数据权限、操作权限

权限治理是企业智能体平台最容易被低估的部分。很多团队一开始只做了简单的用户登录，上线后才发现问题：销售能看到财务的数据，普通员工能调用管理员的工具，外部用户能访问内部知识库。

我的经验是权限治理要分三层设计：

第一层是用户权限，解决“谁能用这个智能体”的问题。这层相对简单，基于角色做访问控制就行。但要注意的是，智能体可能被分享、被嵌入到其他系统，所以权限校验不能只在入口做，要在每次调用时都校验。

第二层是数据权限，解决“智能体能访问哪些数据”的问题。这层最复杂。同一个智能体，不同用户使用时，能检索的知识库范围应该不同。比如HR智能体，普通员工只能查自己的信息，HRBP能查所负责部门的信息，HR总监能查全公司的信息。这要求RAG检索时在向量检索之前先做权限过滤，而不是检索完再过滤——检索完再过滤会导致结果数量不够，而且有信息泄露风险。

第三层是操作权限，解决“智能体能执行哪些操作”的问题。智能体可能调用工具，比如发邮件、改数据、调API。不同用户能触发的操作应该不同。我的做法是给每个工具定义权限标签，用户调用时校验标签。比如“发送邮件”工具需要“邮件发送”权限，“修改订单”工具需要“订单修改”权限。

4.3 多租户场景下的数据隔离：踩过的坑和验证过的方案

如果企业智能体平台要服务多个部门甚至多个子公司，多租户隔离就是必须解决的问题。我踩过最大的坑是向量库的租户隔离。

最初的做法是所有租户的数据存在同一个向量库里，用元数据字段区分租户。查询时加一个租户ID过滤条件。这个方案看似简单，但有两个问题：一是性能问题，数据量大了以后，带过滤条件的向量检索会变慢；二是安全风险，一旦过滤条件写错或者被绕过，就会发生跨租户数据泄露。

后来我们改成了每个租户独立的向量库集合。隔离性好，性能也好，但管理成本高——租户多了以后，集合数量爆炸，运维复杂。

最终的方案是混合模式：大租户独立集合，小租户共享集合但加严格过滤。同时在应用层做双重校验——不仅向量库查询时加过滤，返回结果后再校验一次租户ID。虽然多了一次校验，但安全性大大提升。

还有一个容易忽略的点：模型调用的数据隔离。如果用的是公有云模型API，数据会出企业边界。对于敏感数据，必须用私有化部署的模型，或者对数据进行脱敏后再调用。这个决策要在项目初期就定下来，后期改造成本极高。

5. 平台化智能体与代码化智能体的取舍：不是二选一

5.1 平台搭建的智能体和Python搭建的智能体到底有什么不同

这个问题在热搜里反复出现，说明很多人都在纠结。我的答案是：平台化智能体和代码化智能体不是替代关系，而是不同阶段的工具。

平台化智能体（比如Coze、Dify上搭建的）的优势是快。拖拽式编排、内置工具、可视化调试，一个下午就能搭出一个能用的智能体。对于验证想法、做原型、非核心业务，平台化方案效率极高。

代码化智能体（用Python、LangChain、LangChain4j等搭建的）的优势是可控。可以自定义任何逻辑，可以集成任何系统，可以做精细的性能优化，可以做完整的测试和CI/CD。对于核心业务、高并发场景、复杂集成需求，代码化方案是必须的。

我实际项目中的做法是混合架构：用平台化工具做前端交互和简单流程，用代码化服务做核心逻辑和复杂集成。平台负责“面子”，代码负责“里子”。两者通过API对接。

具体来说，Coze工作流适合做用户交互层——接收用户输入、做简单意图识别、调用后端服务、展示结果。而复杂的RAG检索、权限校验、业务逻辑放在代码化服务里。这样既保证了开发效率，又保证了核心逻辑的可控性。

5.2 什么阶段用平台，什么阶段转代码：一个决策框架

我总结了一个简单的决策框架，帮助判断什么时候该从平台转向代码：

这个框架不是绝对的，但能帮你在早期做出合理判断。我的建议是先用平台快速验证，验证通过后再用代码重写核心部分。不要一上来就写代码，也不要一直停留在平台上。

5.3 从Dify工作流转成Spring AI Java代码：迁移的实操要点

“Dify工作流转成Spring AI Java代码”这个需求我在项目中实际做过。迁移的核心是把可视化节点映射成代码组件。

Dify工作流中的节点类型主要有：LLM节点、知识库检索节点、代码节点、条件分支节点、HTTP请求节点。映射到Spring AI的思路是：

• LLM节点 → ChatClient调用
• 知识库检索节点 → VectorStore.similaritySearch
• 代码节点 → 自定义Function实现
• 条件分支节点 → Java的if-else或Switch
• HTTP请求节点 → RestClient调用

迁移时最容易出问题的是上下文传递。Dify工作流中，节点之间的变量传递是隐式的，平台自动管理。转成代码后，需要显式定义每个节点的输入输出，手动传递上下文。我的做法是定义一个WorkflowContext对象，贯穿整个流程，每个节点从Context读取输入，处理完后写回Context。

另一个坑是错误处理。Dify工作流中，节点失败会自动重试或走异常分支。转成代码后，需要自己实现重试逻辑和异常捕获。我的做法是用Spring Retry做重试，用全局异常处理器做兜底。

迁移完成后，一定要做并行验证——同一批输入，同时跑Dify工作流和Java代码，对比输出是否一致。我遇到过因为模型参数不同导致输出差异的情况，也遇到过因为知识库检索参数不同导致结果不同的情况。并行验证能发现这些细节差异。

6. 五种实现路径的对比与选型建议

6.1 路径一：纯平台化方案（Coze/Dify为主）

这是最轻量的路径，适合快速验证和小型项目。核心是用Coze或Dify搭建全部智能体逻辑，不写或只写少量代码。

优势：上手快、成本低、可视化调试、非技术人员也能参与。劣势：定制能力有限、上下文长度受限、权限治理弱、难以做深度集成。适用场景：内部工具、原型验证、非核心业务、预算有限的团队。

我实测下来，纯平台化方案在单智能体、简单流程、低并发的场景下完全够用。但一旦涉及多智能体协作、复杂权限、高并发，就会遇到瓶颈。

6.2 路径二：平台+代码混合方案

这是我最推荐的路径，也是实际项目中用得最多的。平台负责交互层和简单流程，代码负责核心逻辑和复杂集成。

优势：兼顾开发效率和可控性、灵活度高、可以渐进式迁移。劣势：架构复杂度增加、需要维护两套系统、对接成本。适用场景：大多数企业级应用、需要快速上线但又要保证核心逻辑可控的项目。

混合方案的关键是定义清晰的边界。我的做法是：平台只负责用户交互和流程编排，所有涉及数据访问、权限校验、复杂计算的逻辑都放在代码服务里。平台通过API调用代码服务，代码服务不依赖平台。

6.3 路径三：全代码化方案（LangChain/LangChain4j/Spring AI）

这是最重但最可控的路径。全部用代码实现，不依赖任何低代码平台。

优势：完全可控、可测试、可CI/CD、性能可优化、权限治理完善。劣势：开发周期长、对团队要求高、前期投入大。适用场景：核心业务、高并发、高合规要求、有专职开发团队。

全代码化方案的关键是框架选型。Python生态用LangChain，Java生态用LangChain4j或Spring AI。我的经验是：如果团队是Java背景，选Spring AI更自然，和现有系统集成更方便；如果团队是Python背景，LangChain生态更成熟。

6.4 路径四：知识图谱增强方案

这是在RAG基础上增加知识图谱的路径，适合关系密集型场景。

优势：能处理关系推理、能处理结构化查询、答案更精准。劣势：构建成本高、维护复杂、需要图谱专家。适用场景：医疗、金融、供应链、法律等关系密集型领域。

我要强调的是：知识图谱增强不是必须的。大多数企业场景下，优化切块策略和重排序带来的收益，比上知识图谱更大、成本更低。只有在关系查询是核心需求的场景下，才值得投入知识图谱。

6.5 路径五：多智能体协作方案

这是最前沿但也最不成熟的路径。多个智能体各司其职，通过消息传递协作完成任务。

优势：能处理复杂任务、可扩展性好、每个智能体可以独立优化。劣势：协调复杂、调试困难、成本高、容易出现死循环。适用场景：复杂决策、多角色协作、研究性项目。

多智能体协作目前在生产环境落地案例还不多。我试过用多智能体做客服场景——一个智能体负责意图识别，一个负责知识检索，一个负责回复生成。效果确实比单智能体好，但延迟增加了三倍，成本增加了两倍。所以我的建议是：除非单智能体确实搞不定，否则不要上多智能体。

6.6 五种路径的选型决策表

选型的核心原则是匹配当前阶段的需求。不要为了技术先进而选复杂方案，也不要为了省事而选不够用的方案。我的建议是从混合方案起步，根据实际瓶颈决定往哪个方向深化。

7. 落地过程中那些文档不会写的经验

7.1 模型选型不是越强越好，匹配场景才是关键

很多团队一上来就选最强的模型，结果成本爆炸、延迟感人。我的经验是分级使用模型：简单意图识别用小模型，复杂推理用大模型，格式转换用专用模型。

具体来说，意图识别、分类、抽取这些任务，7B级别的小模型完全够用，速度快、成本低。只有需要复杂推理、长文本理解、创意生成的任务，才需要大模型。我实测下来，分级使用模型能降低60%以上的推理成本，延迟降低一半。

还有一个细节：模型输出格式要约束。企业场景下，模型输出往往需要被程序解析。如果模型自由发挥，输出格式不稳定，程序解析就会失败。我的做法是用JSON Schema约束输出格式，或者在提示词里明确要求输出JSON。LangChain和Spring AI都支持结构化输出，用起来很方便。

7.2 知识库更新：比构建更麻烦的是维护

知识库构建是一次性的，维护是持续的。我见过太多项目，知识库上线后就不管了，半年后用户发现答案全是过时的。

知识库维护的核心是建立更新机制。我的做法是：文档变更时自动触发重新索引。具体来说，把知识库和文档管理系统对接，文档新增、修改、删除时，自动同步到向量库。同步时要处理增量更新——只重新索引变更的文档，而不是全量重建。

另一个问题是知识库质量监控。怎么知道知识库检索效果好不好？我的做法是记录每次检索的命中率和用户反馈。如果某个问题的检索命中率持续偏低，说明知识库缺少相关内容，需要补充。如果用户对某个答案点了“不满意”，说明检索或生成有问题，需要排查。

7.3 智能体客服接入业务系统的那些坑

“智能体客服怎么接入千牛客户端”这类问题，核心是系统对接。我做过类似的对接，踩过的坑包括：

身份传递问题。用户在业务系统里是登录状态，但智能体是独立系统，怎么知道当前用户是谁？我的做法是业务系统生成一个短期token，智能体通过token换取用户身份。token要有有效期，要能撤销。

上下文同步问题。用户在业务系统里的操作历史，智能体能不能看到？我的做法是通过API按需拉取，而不是全量同步。用户问订单问题，智能体才去拉订单信息，而不是提前把所有订单都同步过来。

回复格式问题。业务系统对回复格式有要求，比如千牛客户端可能只支持特定格式的富文本。智能体生成的Markdown需要转换成业务系统支持的格式。这个转换逻辑要单独做一层适配。

7.4 成本控制：token消耗的隐形黑洞在哪里

智能体平台的成本大头是token消耗。我统计过，token消耗的隐形黑洞主要有三个：

第一个是系统提示词过长。很多团队把大量业务规则、示例、说明都塞进系统提示词，导致每次调用都要消耗大量token。我的做法是把系统提示词精简到核心规则，其他信息通过RAG按需检索。

第二个是历史对话全量携带。多轮对话时，如果把所有历史消息都传给模型，token消耗会随轮次线性增长。我的做法是只保留最近N轮对话，更早的对话做摘要。

第三个是重复检索。同一个问题，如果多个节点都去检索知识库，就会重复消耗。我的做法是在流程中缓存检索结果，同一个会话内相同查询只检索一次。

7.5 上线前的最后一道关：红队测试怎么做

智能体上线前，一定要做红队测试——模拟恶意用户，尝试让智能体做不该做的事。我总结的红队测试清单包括：

• 提示词注入：尝试让智能体忽略系统提示词，执行用户指令
• 越权访问：尝试让智能体返回其他用户的数据
• 敏感信息泄露：尝试让智能体输出系统提示词、内部配置
• 有害内容生成：尝试让智能体生成违规内容
• 工具滥用：尝试让智能体调用不该调用的工具

红队测试发现的问题，要在上线前全部修复。修复方式包括：加强提示词防护、增加输出过滤、收紧权限校验、限制工具调用。上线后也要持续监控，发现新的攻击方式及时修补。

8. 回到起点：企业智能体平台落地的核心是工程能力而非模型能力

写了这么多，回到最开始的那个结论：企业智能体平台难落地，根因不在模型，而在工程链路。工作流编排决定了流程能不能跑通，RAG决定了答案准不准，权限治理决定了能不能安全地用，审计决定了出了问题能不能查。这四件事做好了，即使用中等能力的模型，也能做出可用的企业智能体平台。这四件事做不好，即使用最强的模型，也落不了地。

我在实际项目中的体会是：不要追求一步到位，要小步快跑。先用平台化方案快速验证，验证通过后用混合方案落地，遇到瓶颈再针对性优化。RAG效果不好就优化切块和重排序，权限不够就加权限层，性能不行就做缓存和分级模型。每一步都解决一个具体问题，而不是一开始就设计一个完美架构。

最后分享一个实用建议：建立智能体效果评估体系。不要凭感觉判断智能体好不好，要建立量化指标——准确率、召回率、用户满意度、平均响应时间、token成本。每次优化后对比指标，用数据驱动决策。我见过太多团队凭感觉优化，改了半天不知道有没有变好。有了评估体系，优化才有方向。