企业智能体平台这两年成了很多技术团队的必答题但真正上线跑起来、并且被业务方持续使用的案例比例低得惊人。我参与过几个从立项到落地的完整周期也旁观过不少中途夭折的项目发现一个共性卡点几乎从来不在模型能力上而是卡在工作流的编排方式、RAG的知识组织、以及权限治理这三件事的耦合关系上。很多团队把智能体当成套壳对话来做结果一进生产环境就暴露出一堆问题——流程断点、检索答非所问、越权访问、审计缺失。这篇内容我想把踩过的坑和验证过的路径摊开讲围绕工作流、RAG、权限治理三条主线梳理出五种可落地的实现路径适合正在做企业智能体平台选型、架构设计或落地推进的工程师、产品和技术负责人参考。不管你是刚接触智能体开发还是已经踩过一轮坑应该都能从中找到对得上号的场景。1. 先搞清楚企业智能体平台到底难在哪1.1 难的不是模型是最后一公里的工程化很多人对智能体平台的想象是接一个大模型写几个提示词业务就能用。实际做下来会发现模型只是整个链路里最标准化的一环。真正消耗人力的是它周边的东西——知识怎么进来、流程怎么串、权限怎么控、行为怎么审计。我见过一个项目模型选型讨论了两周结果知识库清洗和权限映射做了三个月还没收敛。企业场景和消费级场景最大的区别在于消费级可以容忍差不多对企业级必须可解释、可追溯、可控制。一个销售智能体如果给客户报错了价格这不是体验问题是事故。所以企业智能体平台的难点本质是把一个概率性的能力包装成一个确定性的、可治理的服务。1.2 三类典型卡点流程断点、检索失准、权限失控把落地失败的项目复盘一遍问题基本落在三个筐里。流程断点智能体只能完成单轮问答一旦涉及多步骤任务比如查订单→判断是否符合退款条件→发起退款→通知客户中间任何一步需要调用外部系统或等待人工确认流程就断了。这不是模型不行是工作流编排能力不够。检索失准RAG搭起来容易调好难。用户问上季度的返修率是多少知识库里存的是PDF报表、Excel明细、Wiki页面三种格式检索出来的片段要么是过期数据要么是无关章节。RAG的瓶颈往往不在向量模型而在知识的结构化程度和切分策略。权限失控这是最容易被低估的。智能体一旦接入企业内多个系统它就成了一个超级账号。如果权限治理没做好一个普通员工通过智能体就能查到HR的薪酬数据。权限治理不是加个登录校验就完事它要贯穿知识检索、工具调用、行为审计全链路。1.3 为什么平台搭建和Python手搓是两种物种热词里有个高频问题利用平台构建的智能体与用Python构建的智能体有什么不一样这个问题问到了根子上。用Python手搓你拥有完全的灵活性但你要自己实现会话管理、工具注册、检索链路、权限校验、日志审计。平台搭建则把这些能力封装成可视化组件代价是灵活性受限但换来的是标准化和可治理性。企业级场景下后者往往更重要——因为你需要让非技术角色运营、业务也能参与智能体的维护而不是每次改个提示词都找开发排期。理解了这个差异就能理解为什么企业智能体平台的架构设计必须把可治理放在和能力强同等的位置。2. 工作流编排从能跑通到能维护的三种路径2.1 路径一可视化拖拽工作流适合业务侧快速验证以扣子Coze、Dify这类平台为代表的可视化工作流最大的价值是把编排权交给最懂业务的人。一个简历筛选工作流HR自己就能拖出来上传简历→解析字段→调用模型打分→按阈值分流→写入表格。整个过程不需要写代码。但可视化工作流有个隐藏成本当流程变复杂时画布会变成意大利面条。我见过一个审批工作流节点超过40个连线交叉到没人敢改。所以可视化工作流适合的是中等复杂度、变更频繁的场景比如营销内容生成、客服话术分流、简历初筛。一旦涉及复杂的条件分支和循环就要考虑代码化。实操建议可视化工作流一定要做节点命名规范和版本管理。给每个节点起有意义的名字不要用节点1节点2每次大改前导出备份。这是血泪教训改崩了没法回滚的痛经历过一次就懂。2.2 路径二代码化工作流适合复杂逻辑和系统集成当流程需要调用内部API、做复杂数据转换、或者有严格的错误处理要求时代码化工作流是更稳的选择。LangChain、LangChain4j、Spring AI这类框架提供了编排能力你可以用代码定义节点、条件、重试策略。代码化工作流的核心优势是可测试、可版本控制、可复用。一个封装好的订单查询工具节点可以在多个智能体里复用。而且代码化的流程能接入CI/CD改完自动跑测试。代价是门槛高。业务方改不了必须开发介入。所以我的经验是核心链路用代码化边缘链路用可视化。比如退款审批这种涉及资金的核心流程必须代码化并加严格校验而生成产品介绍文案这种低风险流程可视化就够了。2.3 路径三混合编排用子工作流解耦复杂度混合编排是我目前最推荐的路径。思路是把复杂流程拆成若干个子工作流每个子工作流用最适合它的方式实现。比如一个完整的销售智能体可以拆成线索识别子工作流可视化、报价计算子工作流代码化因为涉及价格规则、合同生成子工作流可视化模板。子工作流之间通过标准接口通信每个子工作流可以独立测试、独立部署、独立迭代。这样既保留了可视化的灵活性又保证了核心逻辑的严谨性。这里有个关键设计子工作流的输入输出契约要严格定义。我一般用JSON Schema来约束避免上游改了字段下游崩掉。这个契约就是子工作流之间的API文档必须版本化。2.4 工作流编码的几个实操细节关于工作流编码有几个细节值得单独说。上下文超长问题Dify工作流在长对话场景下容易触发上下文超长。解决办法是在工作流里加一个上下文压缩节点把历史对话做摘要后再传入。不要指望模型自己处理超长上下文成本和稳定性都不可控。错误处理每个调用外部系统的节点都必须有超时和重试配置。我一般设3次重试、指数退避超过就降级到人工兜底。企业场景下优雅降级比硬扛重要得多。幂等性涉及写操作的节点下单、发消息、改状态必须做幂等。智能体可能因为重试或用户重复触发而多次执行同一操作没有幂等保护就是灾难。3. RAG知识组织决定智能体答得准不准的底层工程3.1 RAG的瓶颈从来不在向量检索本身很多人调RAG第一反应是换更好的embedding模型。但实测下来检索失准的根因八成在知识组织两成在检索策略。知识库里的文档如果本身结构混乱、版本混杂、颗粒度不一再好的向量模型也救不回来。我做过一个对比实验同一批文档一组直接切分入库一组先做结构化清洗再入库。同样的检索问题后者的准确率高出近一倍。所以RAG优化的第一步永远是把知识整理干净而不是调参。3.2 三种知识库的区分Wiki、RAG、KG各管什么热词里有个很好的问题wiki和rag、kg知识库和结构知识库的区分以及应用场景。这三者经常被混为一谈但它们的定位完全不同。类型本质适合场景不适合场景Wiki知识库人工维护的文档集合制度、流程、FAQ等相对稳定的知识高频变更、需要推理的知识RAG知识库向量化检索的文档片段非结构化文档的语义检索精确计算、多跳推理KG知识库实体-关系图谱需要关系推理、精确查询的场景大量非结构化文本实际企业场景里这三者往往是组合使用的。比如一个客服智能体制度类问题走Wiki产品文档走RAG订单状态查询走KG或者直接查数据库。不要指望一种知识库解决所有问题。3.3 知识切分颗粒度决定检索质量切分是RAG里最容易被忽视、又最影响效果的环节。切太大检索出来的片段包含大量无关信息模型容易被干扰切太小语义不完整检索不到。我的经验值是中文文档按语义段落切单块控制在300-500字。技术文档可以按标题层级切每个小节一块。表格和图片要单独处理——表格转成结构化文本图片要么OCR要么走多模态检索。关于rag知识库能存储图片嘛答案是能但要看怎么存。纯向量库存图片的embedding检索时只能做相似度匹配无法理解图片内容。更好的做法是图片走多模态模型生成描述文本再把描述文本入库这样检索和生成都能用上。3.4 检索策略从单路召回走向混合检索单一向量检索在企业场景下不够用。我一般用混合检索向量检索负责语义匹配关键词检索BM25负责精确匹配两者结果做融合排序。这样既能召回语义相近的内容又能保证专有名词、编号、型号的精确命中。再进一步可以加重排序Rerank。先召回Top 50再用重排序模型精排到Top 5。这一步对准确率提升明显代价是增加延迟。我的建议是对准确率要求高的场景如法务、财务加重排序对延迟敏感的场景如实时客服可以省掉。3.5 知识更新RAG最容易被忽略的运维问题RAG上线不是终点知识更新才是长期挑战。企业知识每天都在变如果知识库不更新智能体就会给出过期答案。我的做法是建立知识变更流水线源文档变更→触发重新切分→重新向量化→增量更新索引。关键是增量更新不要每次全量重建成本和耗时都受不了。同时要保留版本快照出问题时能回滚到上一个可用版本。还有一个坑删除同步。源文档删了知识库里的向量也要删。我见过知识库里堆着一堆已废弃文档的向量检索出来全是过时信息。删除同步必须和新增同步一样重视。4. 权限治理企业智能体最不能省的一环4.1 智能体是超级账号权限必须收窄智能体接入企业系统后它拥有的权限往往远超单个用户。如果它用管理员账号去查数据那所有通过它访问的用户都间接获得了管理员权限。这是企业智能体最大的安全风险。正确做法是权限透传智能体以当前用户的身份去访问后端系统用户能看什么智能体就能看什么。这要求智能体和后端系统之间做身份映射技术上可以通过OAuth令牌透传或服务账号用户上下文的方式实现。4.2 权限治理要贯穿三个层面权限治理不是单点的事它要覆盖三个层面。知识检索层不同用户能检索到的知识范围不同。HR能查薪酬制度普通员工不能。这要求知识库支持按权限过滤检索时带上用户权限标签只召回有权限的片段。工具调用层智能体能调用的工具要按角色授权。销售智能体能查订单但不能改价格。工具注册时要绑定权限策略调用前做校验。行为审计层智能体的每一次检索、每一次工具调用、每一次生成都要留痕。热词里问智能体行为审计是什么意思简单说就是记录智能体做了什么、以谁的身份做的、结果是什么。审计日志不仅是合规要求也是排查问题的依据。4.3 权限模型设计RBAC还是ABAC企业权限模型主流是RBAC基于角色的访问控制和ABAC基于属性的访问控制。RBAC简单按角色授权ABAC灵活按属性组合授权。智能体场景下我倾向于RBAC为主、ABAC为辅。大部分场景用角色就够了销售、客服、财务少数需要细粒度控制的场景如只能看自己负责的客户用属性补充。纯ABAC虽然灵活但策略维护成本高容易失控。4.4 审计日志不只是合规更是调试利器很多人把审计日志当成合规负担其实它是排查问题的利器。当用户反馈智能体答错了审计日志能告诉你它检索了哪些片段、调用了哪些工具、模型输入输出是什么。没有审计日志排查全靠猜。审计日志要记录的关键字段用户身份、会话ID、时间戳、检索query、召回片段ID、工具调用参数和结果、模型输入输出、耗时。这些字段能还原完整的决策链路。存储上审计日志建议单独存不要和业务数据混在一起。保留周期根据合规要求定一般至少6个月。5. 五种实现路径的选型对照与落地建议5.1 五种路径的适用场景对照把前面的内容收敛成五条可落地的路径方便对照选型。路径核心特征适合团队典型场景路径一纯可视化平台拖拽编排零代码业务主导、技术薄弱内容生成、简单客服路径二代码化框架全代码编排高灵活技术主导、逻辑复杂核心业务流程路径三混合编排子工作流解耦中大型团队复杂销售/审批智能体路径四RAG优先知识检索为核心知识密集型客服、法务、技术支持路径五治理优先权限审计为核心强合规行业金融、医疗、政务这五条路径不是互斥的实际项目往往是组合。比如一个金融智能体可能是混合编排治理优先的组合。5.2 选型时最容易犯的三个错错误一一上来就追求大而全。想做一个什么都能干的智能体结果什么都做不好。正确做法是从单点场景切入跑通一个再扩展。错误二忽视非功能需求。只关注能不能答对忽视延迟、并发、成本、可维护性。上线后才发现响应要10秒、成本超预算、改个提示词要发版。错误三权限治理后置。先做功能权限以后再加。结果架构定型后权限很难插进去只能推倒重来。权限治理必须从第一天就设计。5.3 落地节奏小步快跑但架构要留余地我的建议是小步快跑但架构要留余地。第一个版本可以只做一个场景、一个知识库、一套简单权限但架构上要预留扩展点工作流引擎要支持子流程、知识库要支持多源接入、权限模型要支持角色扩展。这样当业务提出新需求时是配置而不是重构。企业智能体平台的成败往往不在于第一个版本多惊艳而在于能不能持续迭代、持续被业务使用。5.4 一个容易被忽略的细节智能体的人设和边界最后说个软性的点。企业智能体一定要有清晰的能力边界声明。当用户问超出范围的问题时智能体要明确说这个我处理不了建议联系XX而不是硬编一个答案。这既是对用户负责也是对智能体本身的保护。我在实际项目里会给每个智能体配一份能力清单和拒答话术明确它能做什么、不能做什么、遇到边界怎么引导。这份清单要随版本更新和功能同步维护。踩过几轮坑之后我最大的体会是企业智能体平台的落地本质是一场工程化能力的比拼而不是模型能力的比拼。工作流编排决定了它能不能跑通复杂任务RAG知识组织决定了它答得准不准权限治理决定了它敢不敢上生产。这三件事做好了模型用哪个反而是次要的。如果你正在推进这类项目建议先把这三条主线的架构想清楚再动手写第一行代码。
企业智能体平台这两年成了很多技术团队的必答题但真正上线跑起来、并且被业务方持续使用的案例比例低得惊人。我参与过几个从立项到落地的完整周期也旁观过不少中途夭折的项目发现一个共性卡点几乎从来不在模型能力上而是卡在工作流的编排方式、RAG的知识组织、以及权限治理这三件事的耦合关系上。很多团队把智能体当成套壳对话来做结果一进生产环境就暴露出一堆问题——流程断点、检索答非所问、越权访问、审计缺失。这篇内容我想把踩过的坑和验证过的路径摊开讲围绕工作流、RAG、权限治理三条主线梳理出五种可落地的实现路径适合正在做企业智能体平台选型、架构设计或落地推进的工程师、产品和技术负责人参考。不管你是刚接触智能体开发还是已经踩过一轮坑应该都能从中找到对得上号的场景。1. 先搞清楚企业智能体平台到底难在哪1.1 难的不是模型是最后一公里的工程化很多人对智能体平台的想象是接一个大模型写几个提示词业务就能用。实际做下来会发现模型只是整个链路里最标准化的一环。真正消耗人力的是它周边的东西——知识怎么进来、流程怎么串、权限怎么控、行为怎么审计。我见过一个项目模型选型讨论了两周结果知识库清洗和权限映射做了三个月还没收敛。企业场景和消费级场景最大的区别在于消费级可以容忍差不多对企业级必须可解释、可追溯、可控制。一个销售智能体如果给客户报错了价格这不是体验问题是事故。所以企业智能体平台的难点本质是把一个概率性的能力包装成一个确定性的、可治理的服务。1.2 三类典型卡点流程断点、检索失准、权限失控把落地失败的项目复盘一遍问题基本落在三个筐里。流程断点智能体只能完成单轮问答一旦涉及多步骤任务比如查订单→判断是否符合退款条件→发起退款→通知客户中间任何一步需要调用外部系统或等待人工确认流程就断了。这不是模型不行是工作流编排能力不够。检索失准RAG搭起来容易调好难。用户问上季度的返修率是多少知识库里存的是PDF报表、Excel明细、Wiki页面三种格式检索出来的片段要么是过期数据要么是无关章节。RAG的瓶颈往往不在向量模型而在知识的结构化程度和切分策略。权限失控这是最容易被低估的。智能体一旦接入企业内多个系统它就成了一个超级账号。如果权限治理没做好一个普通员工通过智能体就能查到HR的薪酬数据。权限治理不是加个登录校验就完事它要贯穿知识检索、工具调用、行为审计全链路。1.3 为什么平台搭建和Python手搓是两种物种热词里有个高频问题利用平台构建的智能体与用Python构建的智能体有什么不一样这个问题问到了根子上。用Python手搓你拥有完全的灵活性但你要自己实现会话管理、工具注册、检索链路、权限校验、日志审计。平台搭建则把这些能力封装成可视化组件代价是灵活性受限但换来的是标准化和可治理性。企业级场景下后者往往更重要——因为你需要让非技术角色运营、业务也能参与智能体的维护而不是每次改个提示词都找开发排期。理解了这个差异就能理解为什么企业智能体平台的架构设计必须把可治理放在和能力强同等的位置。2. 工作流编排从能跑通到能维护的三种路径2.1 路径一可视化拖拽工作流适合业务侧快速验证以扣子Coze、Dify这类平台为代表的可视化工作流最大的价值是把编排权交给最懂业务的人。一个简历筛选工作流HR自己就能拖出来上传简历→解析字段→调用模型打分→按阈值分流→写入表格。整个过程不需要写代码。但可视化工作流有个隐藏成本当流程变复杂时画布会变成意大利面条。我见过一个审批工作流节点超过40个连线交叉到没人敢改。所以可视化工作流适合的是中等复杂度、变更频繁的场景比如营销内容生成、客服话术分流、简历初筛。一旦涉及复杂的条件分支和循环就要考虑代码化。实操建议可视化工作流一定要做节点命名规范和版本管理。给每个节点起有意义的名字不要用节点1节点2每次大改前导出备份。这是血泪教训改崩了没法回滚的痛经历过一次就懂。2.2 路径二代码化工作流适合复杂逻辑和系统集成当流程需要调用内部API、做复杂数据转换、或者有严格的错误处理要求时代码化工作流是更稳的选择。LangChain、LangChain4j、Spring AI这类框架提供了编排能力你可以用代码定义节点、条件、重试策略。代码化工作流的核心优势是可测试、可版本控制、可复用。一个封装好的订单查询工具节点可以在多个智能体里复用。而且代码化的流程能接入CI/CD改完自动跑测试。代价是门槛高。业务方改不了必须开发介入。所以我的经验是核心链路用代码化边缘链路用可视化。比如退款审批这种涉及资金的核心流程必须代码化并加严格校验而生成产品介绍文案这种低风险流程可视化就够了。2.3 路径三混合编排用子工作流解耦复杂度混合编排是我目前最推荐的路径。思路是把复杂流程拆成若干个子工作流每个子工作流用最适合它的方式实现。比如一个完整的销售智能体可以拆成线索识别子工作流可视化、报价计算子工作流代码化因为涉及价格规则、合同生成子工作流可视化模板。子工作流之间通过标准接口通信每个子工作流可以独立测试、独立部署、独立迭代。这样既保留了可视化的灵活性又保证了核心逻辑的严谨性。这里有个关键设计子工作流的输入输出契约要严格定义。我一般用JSON Schema来约束避免上游改了字段下游崩掉。这个契约就是子工作流之间的API文档必须版本化。2.4 工作流编码的几个实操细节关于工作流编码有几个细节值得单独说。上下文超长问题Dify工作流在长对话场景下容易触发上下文超长。解决办法是在工作流里加一个上下文压缩节点把历史对话做摘要后再传入。不要指望模型自己处理超长上下文成本和稳定性都不可控。错误处理每个调用外部系统的节点都必须有超时和重试配置。我一般设3次重试、指数退避超过就降级到人工兜底。企业场景下优雅降级比硬扛重要得多。幂等性涉及写操作的节点下单、发消息、改状态必须做幂等。智能体可能因为重试或用户重复触发而多次执行同一操作没有幂等保护就是灾难。3. RAG知识组织决定智能体答得准不准的底层工程3.1 RAG的瓶颈从来不在向量检索本身很多人调RAG第一反应是换更好的embedding模型。但实测下来检索失准的根因八成在知识组织两成在检索策略。知识库里的文档如果本身结构混乱、版本混杂、颗粒度不一再好的向量模型也救不回来。我做过一个对比实验同一批文档一组直接切分入库一组先做结构化清洗再入库。同样的检索问题后者的准确率高出近一倍。所以RAG优化的第一步永远是把知识整理干净而不是调参。3.2 三种知识库的区分Wiki、RAG、KG各管什么热词里有个很好的问题wiki和rag、kg知识库和结构知识库的区分以及应用场景。这三者经常被混为一谈但它们的定位完全不同。类型本质适合场景不适合场景Wiki知识库人工维护的文档集合制度、流程、FAQ等相对稳定的知识高频变更、需要推理的知识RAG知识库向量化检索的文档片段非结构化文档的语义检索精确计算、多跳推理KG知识库实体-关系图谱需要关系推理、精确查询的场景大量非结构化文本实际企业场景里这三者往往是组合使用的。比如一个客服智能体制度类问题走Wiki产品文档走RAG订单状态查询走KG或者直接查数据库。不要指望一种知识库解决所有问题。3.3 知识切分颗粒度决定检索质量切分是RAG里最容易被忽视、又最影响效果的环节。切太大检索出来的片段包含大量无关信息模型容易被干扰切太小语义不完整检索不到。我的经验值是中文文档按语义段落切单块控制在300-500字。技术文档可以按标题层级切每个小节一块。表格和图片要单独处理——表格转成结构化文本图片要么OCR要么走多模态检索。关于rag知识库能存储图片嘛答案是能但要看怎么存。纯向量库存图片的embedding检索时只能做相似度匹配无法理解图片内容。更好的做法是图片走多模态模型生成描述文本再把描述文本入库这样检索和生成都能用上。3.4 检索策略从单路召回走向混合检索单一向量检索在企业场景下不够用。我一般用混合检索向量检索负责语义匹配关键词检索BM25负责精确匹配两者结果做融合排序。这样既能召回语义相近的内容又能保证专有名词、编号、型号的精确命中。再进一步可以加重排序Rerank。先召回Top 50再用重排序模型精排到Top 5。这一步对准确率提升明显代价是增加延迟。我的建议是对准确率要求高的场景如法务、财务加重排序对延迟敏感的场景如实时客服可以省掉。3.5 知识更新RAG最容易被忽略的运维问题RAG上线不是终点知识更新才是长期挑战。企业知识每天都在变如果知识库不更新智能体就会给出过期答案。我的做法是建立知识变更流水线源文档变更→触发重新切分→重新向量化→增量更新索引。关键是增量更新不要每次全量重建成本和耗时都受不了。同时要保留版本快照出问题时能回滚到上一个可用版本。还有一个坑删除同步。源文档删了知识库里的向量也要删。我见过知识库里堆着一堆已废弃文档的向量检索出来全是过时信息。删除同步必须和新增同步一样重视。4. 权限治理企业智能体最不能省的一环4.1 智能体是超级账号权限必须收窄智能体接入企业系统后它拥有的权限往往远超单个用户。如果它用管理员账号去查数据那所有通过它访问的用户都间接获得了管理员权限。这是企业智能体最大的安全风险。正确做法是权限透传智能体以当前用户的身份去访问后端系统用户能看什么智能体就能看什么。这要求智能体和后端系统之间做身份映射技术上可以通过OAuth令牌透传或服务账号用户上下文的方式实现。4.2 权限治理要贯穿三个层面权限治理不是单点的事它要覆盖三个层面。知识检索层不同用户能检索到的知识范围不同。HR能查薪酬制度普通员工不能。这要求知识库支持按权限过滤检索时带上用户权限标签只召回有权限的片段。工具调用层智能体能调用的工具要按角色授权。销售智能体能查订单但不能改价格。工具注册时要绑定权限策略调用前做校验。行为审计层智能体的每一次检索、每一次工具调用、每一次生成都要留痕。热词里问智能体行为审计是什么意思简单说就是记录智能体做了什么、以谁的身份做的、结果是什么。审计日志不仅是合规要求也是排查问题的依据。4.3 权限模型设计RBAC还是ABAC企业权限模型主流是RBAC基于角色的访问控制和ABAC基于属性的访问控制。RBAC简单按角色授权ABAC灵活按属性组合授权。智能体场景下我倾向于RBAC为主、ABAC为辅。大部分场景用角色就够了销售、客服、财务少数需要细粒度控制的场景如只能看自己负责的客户用属性补充。纯ABAC虽然灵活但策略维护成本高容易失控。4.4 审计日志不只是合规更是调试利器很多人把审计日志当成合规负担其实它是排查问题的利器。当用户反馈智能体答错了审计日志能告诉你它检索了哪些片段、调用了哪些工具、模型输入输出是什么。没有审计日志排查全靠猜。审计日志要记录的关键字段用户身份、会话ID、时间戳、检索query、召回片段ID、工具调用参数和结果、模型输入输出、耗时。这些字段能还原完整的决策链路。存储上审计日志建议单独存不要和业务数据混在一起。保留周期根据合规要求定一般至少6个月。5. 五种实现路径的选型对照与落地建议5.1 五种路径的适用场景对照把前面的内容收敛成五条可落地的路径方便对照选型。路径核心特征适合团队典型场景路径一纯可视化平台拖拽编排零代码业务主导、技术薄弱内容生成、简单客服路径二代码化框架全代码编排高灵活技术主导、逻辑复杂核心业务流程路径三混合编排子工作流解耦中大型团队复杂销售/审批智能体路径四RAG优先知识检索为核心知识密集型客服、法务、技术支持路径五治理优先权限审计为核心强合规行业金融、医疗、政务这五条路径不是互斥的实际项目往往是组合。比如一个金融智能体可能是混合编排治理优先的组合。5.2 选型时最容易犯的三个错错误一一上来就追求大而全。想做一个什么都能干的智能体结果什么都做不好。正确做法是从单点场景切入跑通一个再扩展。错误二忽视非功能需求。只关注能不能答对忽视延迟、并发、成本、可维护性。上线后才发现响应要10秒、成本超预算、改个提示词要发版。错误三权限治理后置。先做功能权限以后再加。结果架构定型后权限很难插进去只能推倒重来。权限治理必须从第一天就设计。5.3 落地节奏小步快跑但架构要留余地我的建议是小步快跑但架构要留余地。第一个版本可以只做一个场景、一个知识库、一套简单权限但架构上要预留扩展点工作流引擎要支持子流程、知识库要支持多源接入、权限模型要支持角色扩展。这样当业务提出新需求时是配置而不是重构。企业智能体平台的成败往往不在于第一个版本多惊艳而在于能不能持续迭代、持续被业务使用。5.4 一个容易被忽略的细节智能体的人设和边界最后说个软性的点。企业智能体一定要有清晰的能力边界声明。当用户问超出范围的问题时智能体要明确说这个我处理不了建议联系XX而不是硬编一个答案。这既是对用户负责也是对智能体本身的保护。我在实际项目里会给每个智能体配一份能力清单和拒答话术明确它能做什么、不能做什么、遇到边界怎么引导。这份清单要随版本更新和功能同步维护。踩过几轮坑之后我最大的体会是企业智能体平台的落地本质是一场工程化能力的比拼而不是模型能力的比拼。工作流编排决定了它能不能跑通复杂任务RAG知识组织决定了它答得准不准权限治理决定了它敢不敢上生产。这三件事做好了模型用哪个反而是次要的。如果你正在推进这类项目建议先把这三条主线的架构想清楚再动手写第一行代码。
