AI Agent落地企业：比模型更难的是需求、知识与可靠性

过去一年我一直在公司里带一个和 AI Agent 相关的落地项目。立项之前团队内部讨论最多的是“选哪个底座模型”“要不要微调”“上下文窗口多大才够”所有人都默认模型能力才是成败的关键。一年之后回头看真正卡住进度的、消耗最多精力的、让我一度怀疑方向的恰恰是三件跟模型没有多大关系的事说不清的需求、接不进系统的知识、以及上线之后无休无止的可靠性问题。这篇文章不聊模型排行榜也不聊提示词花活就聊聊这三件事到底难在哪、我是怎么一步步趟过去的。如果你正准备在企业里推 Agent希望这些踩坑经验能让你少走点弯路。1. 需求关“不知道要什么”比“选不好模型”更致命1.1 一场需求会下来我发现“智能助手”是个伪需求年初某业务线负责人找过来说他们部门想要一个“智能客服助手”。听起来很明确对吧我当时也这么以为。结果一聊下去发现“智能客服助手”这五个字在不同人脑子里是完全不同的东西。有人以为是要一个能自动回复客户的聊天机器人有人以为是帮客服查订单、查工单、查知识库的检索工具还有人以为是能替客服写工单摘要的辅助工具。我们连续开了三轮需求会最后才发现他们真正痛的不是“没有对话机器人”而是客服每天要切六七个系统查答案平均一单要花十来分钟。他们真正要的是一个“能把散在各系统的答案聚到一起、并且标注来源”的辅助工具而不是一个能闲聊的对话窗口。这里我要先说一个结论企业里大多数“做个智能助手”的需求本质上都是伪需求。它往往是一个未被拆解的痛点被业务方用一句听起来很时髦的话概括了。真正要做的事情是在动手之前把这句话拆成能验证的颗粒度。我们后来沉淀了一份需求澄清清单每次新场景进来都先过一遍谁在什么环节使用这个 Agent是员工自助还是客服代查输入是什么用户会怎么问输出给谁看、以什么形式看成功标准是什么准确率要到多少、响应时间要多少、能省多少工时如果答错了后果是什么谁来兜底有没有人工复核环节数据在哪个系统里能不能访问权限范围跟业务岗位是否一致这些问题看着简单但在项目初期我们一条都没问全导致第一个版本的 Agent 做成了“四不像”能聊、能查、能生成但没有一个场景真正可用。后来才明白需求不澄清后面所有工作都像是在沙地上盖楼。1.2 demo效果和生产要求之间隔着一道预期管理的鸿沟第一个版本的 demo 我们两周就做出来了。拿的是精心挑选的测试数据业务方看完眼睛发亮觉得“太聪明了”当场就要安排上线。但一旦放进真实流量问题一个接一个地冒出来。真实用户的问题口语化特别严重比如“报销单咋填来着”“这个月的业绩数帮我拉下”“我客户说发票还没到啥情况”跟 demo 里那种结构完整的问法完全不搭边。再加上上下文缺失、中英文混写、部门术语不一致我们当场测出来原本 95% 的 demo 准确率直接掉到了 70% 左右。这是我在这个项目里学到最深刻的一课demo 阶段大家评价的是“看起来像不像人”生产阶段评价的是“错了能不能追责”。这是两种完全不同的评价体系如果不在项目一开始就跟业务方对齐后面所有优化都会陷入“你觉得好我觉得不好”的拉扯里。后来我们专门做了一次预期管理工作坊把三条红线讲清楚第一Agent 不是人它答错一次就可能造成客诉所以必须保留人工兜底第二准确率是渐进式上升的不是上线即满分第三效果好不好不以“看起来聪明”为准而以“能不能减少一次人工查询”为准。预期对齐之后业务方反而平和了很多愿意陪我们一起打磨。1.3 场景收敛宁可做窄不要做宽如果说这一年我最后悔的事就是早期太迷信“企业级智能助手”这个概念了。我们一度想把员工手册、IT 报障、财务报销、销售查询全部塞进一个 Agent 里做了一版“全能助手”出来结果每个技能都是 60 分用户问两句觉得不准就不用了。后来我们彻底换了个思路场景宁可做窄不要做宽。先找一个高频、低风险、数据链路短、效果可评估的场景把整条链路跑通跑稳再往旁边延展。我们选的第一个生产场景是“内部制度问答”。原因很简单问题范围可控、答案基本有标准、答错了也不至于造成业务损失。把它做扎实之后才逐步接入订单查询、工单摘要这些风险稍高的场景。这个选择看起来保守但正是它让项目活了下来——因为团队有了一个能持续使用的真实场景而不是一个永远在演示的空中楼阁。2. 知识关企业数据从权限到质量处处是暗坑2.1 企业内部知识的三层结构接入方式完全不同模型聊得再好答不出企业内部的制度、价格、流程就毫无价值。所以 Agent 真正要吃的是企业的私有知识。我把企业内部知识粗略分成三层每一层的接入方式完全不同第一层制度文档、SOP、产品手册存在 OA、知识库、文件服务器里适合做 RAG 检索增强。第二层订单、库存、客户信息、业绩数据存在 CRM、ERP、数据库里适合做成 API 工具让 Agent 调用。第三层专家经验、历史邮件、聊天记录里的隐性知识散落在各个角落最难复用。我一开始以为“把文档灌进向量库就完事了”后来发现只有第一层适合这么干。第二层必须走结构化查询因为文档里没有实时数据第三层根本没法直接用只能靠人工沉淀成标准问答对才能喂给 Agent。这一层认知直接决定了后续的工程排期。如果你给业务方承诺“两周上线一个能查所有数据的助手”而实际上你们连 CRM 的只读接口都还没申请下来那这个承诺就是给自己埋雷。2.2 权限必须继承现有体系Agent不能成为越权查询器知识接得越深权限问题就越致命。我见过不少项目死在“Agent 能查到超出员工权限的数据”上这已经不是效果问题而是合规问题了。有一次我们在测试一个销售场景的 Agent突然发现它能查到所有销售线索的报价明细而正常员工按权限只能看到自己负责的区域。问题出在我们为了让 Agent 能流畅回答给了它一个权限过大的服务账号。这种漏洞一旦上了生产任何员工都可以借着“帮我查一下”把全公司数据拖出来性质非常严重。我们的解决办法是定了一条铁律Agent 底层账号的权限不能大于普通员工的最小权限。所有数据检索都必须带上当前用户的身份上下文接口层再做一次部门和岗位的过滤。权限不能由 Agent 自己决定而是完全继承公司现有的权限体系。这里还要提醒一点权限过滤不要只在前端做。很多系统以为“页面隐藏了字段就安全了”但 Agent 要是直接查数据库绕过了页面所有隐藏都形同虚设。所以要查数据就必须走专门为集成场景设计的只读接口或视图把所有越权路径都堵死。2.3 PDF扫描件、过期制度文档……脏数据比想象中多企业知识接入最折磨人的其实不是“没有数据”而是“数据在但没法用”。我们当时接了一批 PDF 制度文档一开始直接切分丢进向量库结果检索质量惨不忍睹。后来打开一看一半是扫描件压根没有文字层另一半是带复杂表格的附件切分后表格全被拆碎了模型根本读不连贯。这一步必须做预处理扫描件先过 OCR带表格的文档要先做表格还原、转成 Markdown 或结构化文本再按语义段落切分。OCR 的准确率直接决定了后面 RAG 的上限OCR 出来的错别字会让检索召回一堆没用的片段。比扫描件更麻烦的是文档过期的问题。有一回制度在 3 月 1 日改版了知识库里还留着 2 月的旧版本Agent 照样引用了旧报销额度员工按错误金额提交报销差点出事。后来我们规定文档进知识库必须登记生效日期、失效日期和责任部门检索时按时间过滤大版本更新时旧版本要标记成“已失效”不能再被引用。知识库的维护不是一次性工程而是一个需要持续运营的管理体系。3. 可靠性关幻觉、评测、可观测上线才是开始3.1 “用提示词让模型别乱说”是最不靠谱的解法模型最让人头疼的问题就是幻觉——它会在检索结果里没有任何依据的时候依然流畅地编一个看起来无比合理的答案。我见过不少人试图用“请基于给定材料回答不要编造”这类提示词来压制幻觉实测下来只能说效果极其有限。它不是从机制上解决问题而是把希望寄托在模型自己的“自觉”上。我的做法是用工程手段兜底检索结果为空时直接拒答并引导用户转人工回答必须强制附带引用来源所有关键结论都要求能在上下文里找到依据对检索结果特别少或者置信度不高的题目先回复“我不确定建议你咨询某部门”而不是硬答。工具调用也是一样的逻辑。Agent 调数据库、调 API 做操作类任务时凡是涉及写操作下单、改单、发消息必须做二次确认而且要遵循最小权限原则。我们团队内部甚至定了一条规矩宁可让 Agent 少做一步也不能让它多做一步错事。企业场景里一个正确的拒绝远比一个错误的执行更有价值。3.2 从真实请求里建回归集优化才不是盲人摸象没有评测集你优化了一版提示词到底是变好了还是变差了全凭感觉。这是很多 Agent 项目后期优化失控的根源。我们建立评测集的方法很简单从真实请求日志里抽样整理出两百条用户问题按场景分类人工标注参考答案和允许引用的材料范围。以后每次改提示词、换模型、调检索参数都用同一批用例回归跑一遍记录准确率、拒答率、响应时延这些指标。一个评测用例大概长这样{ query: 销售岗的差旅报销标准是多少, expected_answer: 销售岗差旅报销按最新制度执行单日上限是 XX 元具体见制度编号 SOP-2024-018, allowed_docs: [SOP-2024-018], expected_behavior: answer_with_citation }除了准确率我们还会看这几个维度引用有效性引用的文档是否真的支持结论、拒答合理性该拒答的有没有拒答、不该拒答的有没有误拒、响应速度、权限合规。每周新增的线上 bad case 都会进评测集让评测集跟真实请求的分布一起生长而不是永远停留在上线那一刻。有了评测集之后团队内部的争论立刻少了很多。以前“我觉得变好了”这种话没法讨论现在都是拿数据说话改没改好跑一遍就知道。3.3 全链路trace和灰度发布是生产环境的最后防线Agent 链路比传统接口长得多意图识别、知识检索、上下文构造、模型生成、工具调用任何一个环节出错用户看到的都是“它答错了”。问题是用户只说一句“它答错了”你要怎么知道错在哪一环我们当时的做法是给每次请求一个 trace_id贯穿全链路把每一段日志串起来。线上报了 bad case直接查请求轨迹是检索没召回正确文档还是模型生成时编了上下文里没有的内容还是工具调用传参传错了。这一步不做整个 Agent 就是一个黑盒优化效率会低到让人绝望。上线策略上我们也不再搞“一次性全量发布”。Agent 本质上是一个线上系统变更必须走灰度流程先内部小范围试运行再按 10%、50%、100% 的节奏放量每个阶段都盯着拒答率、准确率和用户反馈一旦指标异常立刻一键关闭。把 Agent 当成一个需要持续监控的生产系统来管理而不是当成一个聊天玩具。4. 让这三件事真正跑通靠的是团队与节奏4.1 团队配置算法工程师只占一小块项目做了一年我越来越确定一件事企业里做 AI Agent算法工程师只是拼图的一小块。真正决定项目生死的是懂业务、懂工程、懂数据的人。我们现在的配置大致是业务/产品分析师 1 人后端工程 2 人算法工程师 1 人数据工程 1 人测试/交付 1 人。业务分析师负责把模糊的需求拆成可执行场景后端工程负责接系统、做权限、搭评测和 trace 链路数据工程负责清洗文档、搭知识库算法工程师反而可以把更多精力放在提示词模板、检索调优和 bad case 分析上。如果从一开始只招算法工程师这个项目大概率会卡死在业务对接和数据接入上。模型能力大家拉不开太大差距差距在工程、数据、业务定义这些看起来很“不 AI”的事情上。4.2 一次只动一个变量否则出了bug你都不知道是谁干的团队磨合期我们犯过一个典型的错误有一版同时换了底座模型、改了提示词模板、还调了检索的 top_k 参数结果整体效果掉了一截谁都不知道是哪一步导致的。排查了两天才发现是新的底座模型对旧提示词的格式不敏感。那次之后我们定了一个死规矩每次迭代只改一个变量并且先跑评测集再上线。改了提示词就不动检索参数换了模型就不动提示词模板。虽然听起来很土但确实让团队从“靠运气优化”变成了“可控地推进”。再复杂的系统也耐不住一次改太多东西出了错连归因都做不了。4.3 业务侧一定要有一个“背KPI的owner”最后一条经验也是最容易被忽略的一条一定要在业务侧找到一个愿意为 Agent 效果负责的 owner。如果没有项目再热闹也会慢慢变成 demo。我们早期吃过这个亏技术团队自己 K 推进业务方只是“配合给需求”结果上线之后没人真正用也没有人愿意为效果兜底。后来换了个打法让业务侧的一位关键负责人当 owner每周固定看 bad case参与效果标定把 Agent 的指标写进他们的月度工作目标里。有了 owner反馈循环才能转起来线上问题有人确认是不是该优化的新需求有人排序优先级效果好不好有人拍板。没有这个角色Agent 就像没有主的项目永远在“做得出来”和“用不起来”之间徘徊。要说这一年最深的体会其实就是别把 Agent 当成一个魔法盒子。它不是换个更强的模型就能自动变好而是一个需要边界、需要喂养、需要有人负责的新成员。你告诉它哪些能做哪些不能做给它看公司真正的资料让它每天把做对的事、拿不准的事都记录下来还得有人在它犯错的时候兜底。这个过程很琐碎远没有“部署一个模型”听起来那么有科技感但我越来越觉得企业里 AI Agent 的竞争本质上就是看谁能把这三件“不 AI 的事”做得足够扎实。