一年前我们把“企业 AI Agent”正式立项时团队最焦虑的问题是模型选型。市面上旗舰模型、轻量模型、开源权重模型挨个比评测集做了好几版从合同问答到工单摘要到报表解读来回测了小半年。但真正跑完这一年我发现一件很反直觉的事模型根本不是我该焦虑的重点。把大量精力花在模型对比上其实是在逃避三个更脏更累的问题——企业数据怎么喂进来、Agent进入业务流程后边界怎么定、上线之后拿什么机制持续评估和运营。这三件事每一件单独拿出来都比想象中复杂叠在一起才是企业级Agent落地真正的深水区。如果你正准备在企业里推Agent项目或者已经做完PoC但迟迟走不进生产环境这篇文章应该对你有用。我把这一年的真实复盘整理成下面五个部分尽量说人话少讲术语多讲我们是怎么踩坑、怎么调整的。1. 先放下模型焦虑一年里真正卡住我们的地方1.1 选型阶段的假问题立项第一天所有人都问我“能不能用最强的模型”。我的态度是先别急。因为Agent项目的效果好坏远不是模型一个变量决定的。我们当时建了一个评测集里面放了上百个真实业务问题用不同模型跑过一轮。结论很直接模型之间确实存在能力差距但差距远没有厂商宣传和媒体渲染的那么大。真正拉大效果差距的是另外三个变量喂给模型的数据干不干净、业务方有没有把任务边界定义清楚、出问题后有没有人能在几小时之内判断责任方。这三个变量任何一个塌了模型再强也救不回来。举一个我们自己的例子。某个合同问答场景用户反馈Agent答非所问第一反应是模型不行。排查之后发现合同原始文件是扫描件OCR解析完之后表格结构全乱模型读到的是错位内容。这能怪模型吗模型只是在一个烂数据源上做了最好的发挥。类似的情况这一年里出现无数次“模型不够好”往往只是数据、权限、流程这些更基础问题的替罪羊。1.2 “模型背锅”的三个真实场景我整理一下这一年来最常见的三类“模型背锅”现场第一类是知识过期。企业知识库里的制度文档经常改版但旧版本没有被标记失效。员工问新政策Agent从库里检索到了旧政策答得自信满满其实内容是错的。这不是模型能力问题是知识治理问题。第二类是权限缺失。同一个文档在不同部门眼里内容不同Agent用一套统一向量索引去检索结果把不该透露的数据答出去了。这也不是模型的问题从一开始就不该把所有数据放进同一个索引桶里。第三类是行为边界不清。模型把“可以推荐方案”理解成“可以自动执行操作”用户还没确认它就去改了状态。问题是任务设计和执行纪律不到位。所以我做了个决定从第二个月开始团队不再为模型争论把精力切到数据、边界、运营这三条线。后面的内容就是这三条线各自发生了什么。2. 第一件难事企业知识库不是文档是一片“数据沼泽”2.1 为什么RAG在Demo里惊艳一接真实数据就崩RAG是Agent落地最常用的技术路线几乎每个Demo都靠它出效果。但Demo和真实业务之间隔着一整片数据沼泽。先说数据规模。Demo里用的是整理好的几十篇文档目录清晰、格式统一。真实企业是几百个系统、几千万条记录、各种年代久远的文件格式堆在一起。你根本不知道答案在哪张表里也不知道哪份文档是最新版。再说权限模型。很多企业知识库里的文件本身没有精细的权限标注同一个知识域下混着对不同角色可见和不可见的内容。Agent如果只按语义相似度去检索就会把不该检索出来的内容送进上下文。我们在权限这一块吃过亏后来不得不给所有接入Agent的内容做“可见性标签”。还有一个被低估的问题是解析质量。PDF里的表格、流程图、扫描件PPT里嵌套的文本框甚至聊天记录截图每一样都可能在解析环节丢失信息。向量检索再强喂进去的是错位文本出来就是错位答案。我把RAG效果的几个影响因素按经验估了个比例影响因素大致影响占比说明数据清洗与索引质量50%-60%原始数据格式、权限、时效性是否治理清楚检索策略20%-30%混合检索、切分方式、重排逻辑是否合理模型能力10%-20%生成质量、指令遵循能力只是最终一环这个表不是精确统计数据但方向是准的绝大多数项目把精力放在最后10%-20%的模型比较上却忽略了前面占比最高的数据质量。这是我看过很多PoC死在沙滩上最核心的原因。2.2 我们如何先把一个业务域的数据“捋”干净我们在数据治理上踩过一轮弯路最后总结出一套可复制的操作流程。核心原则只有一句话不要试图一开始就治理全公司的数据先圈出一个业务域把它做透。第一步圈定最小闭环业务域。我们选了一个业务方痛点最明确、数据相对好拿的场景。这个选择很重要痛点明确才能让业务方愿意投入数据相对好拿才不会让项目死在数据对接上。第二步盘点数据资产。列出这个业务域涉及哪些系统、每张表谁维护、更新频率多高、有没有明确的负责人。这一步会暴露很多“无主数据”需要提前和业务方对齐责任归属。第三步统一实体与权限。同一个客户在不同系统里的ID不一致同一个订单在报表里和工单系统里的状态字段不一样。先把主数据ID对齐再给每条内容打上可见性标签。权限打标是后来排查问题时最值得的一笔投入不要省。第四步搭建解析与索引管线。文档解析、表格还原、OCR、图片转文字每一步都要验证输出质量尤其要校验表格结构。索引阶段建议做“关键词 向量”的混合检索比单纯向量检索稳定得多。第五步用业务样例验收。从业务方手里收集100个真实高频问题让业务方逐条打标正确答案做成这个业务域的测试集。每次改动数据管线都拿这份测试集跑一遍保证召回质量不后退。这套流程里前两步最容易被跳过去。很多团队一上来就建知识库、接模型、搭RAG等发现问题已经晚了。我们把复盘会开成“数据盘点周”虽然前两周很痛苦但后面所有环节都因为前两步做得扎实而少返工。2.3 数据治理不是搞平台是“用业务问题倒逼数据变干净”最开始我们犯过一个方向性错误想先做一个统一数据平台把所有数据源接进来做标准化。想法很正统推进极其困难因为各部门没有动力配合你改数据。后来换了个思路挑几个业务方最痛的问题先做Agent原型再把原型暴露出的数据问题列成整改清单由业务方牵头改源数据。为什么业务方愿意动了因为Agent好不好用直接关系到他们的日常效率和考核指标。数据烂他们的Agent就不好用他们比你还急。这个思路可以复刻给所有正在做企业内部数据治理的人不要把数据治理当成IT项目单独立项那样大概率变成PPT项目。把数据治理嵌进Agent落地过程用真实业务问题作为验收标准数据自然会被推着变干净。3. 第二件难事Agent进入业务流程边界比AI能力更复杂3.1 从“会聊天”到“会办事”的质变问答型Agent好做因为它是只读的答错了影响有限。但企业Agent真正的价值在“能办事”查订单、改状态、发通知、触发审批。一旦开始写操作问题立刻变得复杂。你可以把Agent想象成一个没有工牌的新员工。它不掌握权限规则不清楚什么操作需要审批也不知道什么时候该停下问人。如果没有清晰的边界纪律它就是一个能快速犯错、且犯错成本极高的自动执行器。我们定义了一条原则能读的不碰写能建议的不自动执行能小范围试的不全量铺开。这条原则写进了所有Agent开发规范里不是靠模型提示词约束而是靠工程手段强制。3.2 我给Agent定的“三段式”执行纪律每一个会触发写操作的Agent任务我们都套用一个三段式结构前置校验、人工确认、执行与回滚。用一段逻辑示意def handle_task(intent, payload): # 第一段前置校验 if not check_permission(intent): return block(当前身份无权执行该操作) # 第二段人工确认 if needs_confirmation(intent): request_user_approval(payload) return waiting_approval() # 第三段执行与回滚 result call_business_api(payload) if result.status ! ok: rollback() notify_admin() return failure(result.reason) trace_log.append(intent, payload, result) return success(result)第一段解决身份和权限问题Agent必须按最小权限原则运行。第二段是兜底凡是涉及钱、对外承诺、权限变更、批量操作的任务一律停在“建议模式”等真人确认再继续。第三段必须考虑失败回滚因为调用外部系统一定会遇到超时、重复提交、部分成功这些都需要提前设计。这个三段式看起来简单但它是我们这一年里最有效的一条工程经验。回头看凡是严格遵守这个纪律的场景上线后出问题的比例都很低凡是贪快跳过确认环节的场景基本都在一两个月内爆出过操作事故。3.3 权限、审批和旧系统三块绕不开的硬骨头先说权限。Agent一定要有独立的服务账号绝不能复用某个员工账号去调接口。独立账号好审计出了事能追责也方便做最小化授权。能读的模块只给读权限能写的模块严格限定范围跨域访问默认禁止。再说审批流。企业里本来就有一堆审批系统Agent发起操作申请时应该复用它现有的流程而不是自己再造一套。我们采用“建议→审批→执行→回执”四段流程Agent先提出建议审批人在既有系统里点同意Agent再执行最后把执行结果回报给审批人。这样业务方的使用习惯不用改合规审计也有迹可循。最后说旧系统。很多企业内部系统没有API只有老旧界面甚至半手工流程。我们的策略是有API就直连没API先用RPA兜底但要求每一步操作都截图留痕宁可慢一点也不能盲目执行。这块是本年度最耗工程师精力的地方一定要在立项时预留出足够的人力。这三块硬骨头最难的不是技术而是共识。需要在立项阶段就和业务方明确一个问题Agent能碰哪些数据、能执行哪些操作、哪些必须有人确认。谈清楚再开发比开发完再补边界容易十倍。4. 第三件难事上线不是终点评估与运营才是长期战场4.1 上线后重点盯的六个指标Agent上线后很多团队就把注意力挪走了等用户投诉再来救火。我们的经验是上线只是开始评估和运营体系如果没搭好Agent会以肉眼可见的速度变“傻”。我们线上每天重点盯六个指标指标说明目标设定逻辑任务完成率用户请求最终被成功处理的比例核心健康度低于70%需要立即介入人工介入率需要真人接管会话的比例太高说明自动化失败太低说明拒答过多首轮解决率一次交互就解决用户问题的比例反映意图识别和知识召回质量拒答率Agent明确表示答不了的比例太高说明太怂太低说明容易胡编单次会话成本平均一次完整会话消耗的模型费用决定规模化后的预算模型抽检满意度人工抽查对话后打分防止指标被“表面完成”欺骗盯这六个指标给了我们很多次提前预警。比如某段时间任务完成率从81%掉到70%排查下来不是模型问题而是上游某个系统更新了接口字段Agent没有感知。这类问题如果没有线上指标只靠用户投诉通常要滞后两周才发现。4.2 幻觉治理靠三层防线不靠提示词关于幻觉治理我的一句话经验是不要指望靠提示词解决幻觉幻觉治理是流程工程。我们搭了三层防线。第一层是知识召回检索不到相关内容就明确拒答不允许模型凭空编造。给Agent设置一个最低相关度阈值分数不够直接回答“这个信息我这边暂时查不到”。第二层是答案校验涉及事实和数据的内容必须从结构化字段或数据源里带出出处用户在界面上能看到来源编号和链接能做到“答案可追溯”。第三层是人工复盘每周抽检10%左右的会话把“模型自信但实际答错”的案例单独拉出来开会分析是知识缺失、反馈误判还是边界规则有问题。这套三层防线真正跑起来之后我们对线上效果的失控感明显减少。与其追求模型永远不犯错不如把错误控制在一个可以快速发现、快速修复的流程里。4.3 成本与模型路由的运营细节一个容易在立项时被忽略的问题Agent上线后模型成本会随着调用量翻倍增长。不是所有请求都需要用旗舰模型而是应该维护一张“意图→模型”的路由表。routes: - pattern: greeting|password_reset|leave_query model: cheap_model - pattern: contract_analysis|risk_eval|compliance_question model: strong_model - default: cheap_model简单的FAQ、状态查询、企业制度问答用轻量模型完全够成本能降一个数量级。复杂的合同分析、风险问答、长文本综合判断才需要上较强的模型。路由表要和评测集联动上线前跑离线评测上线后每周根据badcase调整。缓存也会显著降低成本。同一类常见问题在一段时间内可以直接命中缓存结果不需要每次都调用模型。运营团队每周复盘失败类型把高频失败案例送回数据侧做优化而不是天天改提示词——这是我这一年来反复强调的提示词能优化的事情很少数据和流程能优化的事情很多。4.4 团队配置建议别把运营工作扔给开发很多Agent项目上线后运营工作落到了原本的研发团队身上结果两边都做不好。研发要写代码没空逐条看会话日志业务方又不知道怎么看技术指标。一个可行的配置是一个“Agent业务运营”兼职角色最好来自业务部门每天花一两个小时看会话记录、处理人工介入、整理badcase再加一个数据工程师和一个后端工程师分别负责召回质量和接口稳定性。这个组合不用很大但必须固定下来。业务运营负责发现问题工程负责下手修复形成闭环。5. 复盘这一年我对企业Agent项目节奏的新认知5.1 先做“难而窄”的闭环再做“广而浅”的平台我们走过一段弯路一开始想做一个覆盖全公司的统一Agent平台连接所有系统支持所有问答场景。想法很大推进很慢半年过去还在搭底座。后来收窄到一个具体业务场景两个月就看到效果。我的感受是一个能解决真实痛点的窄场景远好过一个什么都能聊、但什么都不精的平台。从窄场景里沉淀出数据治理方法、执行纪律和运营机制再去复制到第二个场景成功率会高很多。5.2 团队构成决定落地上限这一年我最大的体会之一是Agent项目的边界不是由模型划定的而是由团队构成划定的。有没有一个业务接口人愿意持续整理badcase决定了Agent能不能持续变好用有没有一个后端工程师愿意去啃老旧系统API决定了Agent能不能真正接进业务流程。我建议在立项时就把这两个角色的时间明确预约下来否则Agent上线后会很快被差评淹没。5.3 模型可以换数据、边界、运营换不掉一年来我们换过两次模型方案每次切换都只涉及配置调整和回归测试真正的工程量并不大。但数据管线、权限标签、执行纪律、运营例会这些底层建设始终没变也最难变。这让我看清了一件事当初立项时焦虑的模型选型其实把注意力放错了地方。把这“三件事”——数据治理、边界设计、评估运营——做好模型层面的差距很快能补回来这三件事不做换最强的模型也救不了场。