1. 从Demo到生产企业级Agent落地的真实门槛过去一年我几乎把全部精力都扑在了一个企业级AI Agent项目上。从最初在本地跑通一个能查天气、能调API的Demo到后来把它塞进真实的业务流里让它每天处理成千上万条工单、自动执行跨系统操作这中间的落差比我想象的要大得多。刚开始团队里所有人都觉得模型能力是瓶颈——是不是得换个更大的是不是得微调是不是Prompt写得不够好但一年跑下来真正卡住我们的根本不是模型本身。模型每几个月就迭代一次能力肉眼可见地涨可我们的Agent还是会在同一个地方摔倒。问题出在三个更“土”的地方上下文工程、工具调用的可靠性、以及评估与迭代的闭环。这篇文章不聊虚的就聊聊这三件事为什么难以及我们是怎么一步步填坑的。如果你正在或者准备把Agent往生产环境推不管你是开发者、产品经理还是技术负责人这些经验应该都能帮你少走几个月弯路。2. 上下文工程不是塞得越多越好而是给得越准越妙2.1 为什么“把文档全塞进去”是第一个要避开的坑项目刚启动时我们犯了一个特别典型的错误觉得Agent不够聪明是因为它知道得太少。于是我们把产品手册、历史工单、内部Wiki、甚至会议纪要一股脑全塞进上下文窗口。结果呢Agent的回答变得又慢又飘经常抓着一个无关的细节大做文章真正关键的信息反而被淹没了。后来我们才明白上下文工程的核心不是“信息量”而是“信息密度”和“信息相关性”。大模型虽然支持很长的上下文但注意力机制在长文本里会稀释无关内容越多模型越容易分心。这就像你让一个新员工去处理客户投诉却给了他公司十年的所有文件他反而不知道该看哪一页。我们后来做了一个实验同一个工单处理任务一组给Agent塞了完整的知识库另一组只给经过筛选的、和当前工单最相关的5条历史记录加当前产品版本说明。结果第二组的准确率比第一组高了将近30%响应时间还缩短了一半。这个数据让我们彻底转变了思路——上下文不是仓库是手术台只放当前手术需要的那几把刀。2.2 动态上下文组装让Agent自己决定“看什么”那怎么做到“只给需要的”我们最终落地的方案是动态上下文组装。简单说就是不再预先写死一个巨大的Prompt模板而是把上下文拆成多个独立的“信息块”每个块有明确的元数据标签比如来源、时间、类型、置信度。当用户请求进来时先用一个轻量的检索或分类步骤判断当前任务需要哪些块再动态拼装成最终的Prompt。具体实现上我们用了三层过滤第一层意图识别。用一个小的分类模型或规则引擎先判断用户到底要干什么。是查状态、改配置、还是投诉不同意图对应不同的信息块集合。第二层实体链接。从用户输入里提取关键实体比如订单号、设备ID、产品型号然后用这些实体去检索最相关的历史记录和文档片段。第三层时效性加权。给每个信息块打一个时间衰减分数越新的信息权重越高。企业环境里很多政策、价格、配置都是会变的旧信息不仅没用还可能误导。这套东西听起来复杂但落地后效果非常明显。Agent的回答变得“聚焦”了不再东拉西扯。而且因为上下文短了推理成本也降下来了。这里有个经验不要试图让模型自己去大海捞针你要做的是先把针捞出来再递给它。2.3 上下文压缩与摘要在有限窗口里塞进更多有效信息有时候即使经过筛选信息量还是太大。比如处理一个复杂的售后工单可能需要参考过去三个月的所有沟通记录。这时候就需要上下文压缩。我们的做法是对长文档先做一次摘要但摘要不是随便摘而是带着“任务视角”去摘。比如当前任务是判断是否满足退货条件那摘要就重点保留和退货政策、时间节点、产品状态相关的句子其他寒暄、内部备注全部丢掉。我们还试过用模型自己来压缩让一个便宜的模型先读长文档输出一个结构化的摘要再把摘要喂给主模型。这样成本可控效果也不错。但要注意压缩是有损的关键细节不能丢。我们的做法是压缩后的摘要必须保留原始文档的引用ID一旦Agent在回答里引用了某个摘要点系统能追溯到原文方便人工复核。这个追溯机制在生产环境里特别重要后面讲评估的时候还会提到。2.4 上下文里的“负样本”告诉Agent什么不能做还有一个容易被忽略的点上下文里不仅要放“正确示例”还要放“错误示例”。我们早期只给Agent看成功的工单处理案例结果它遇到边界情况时会强行套用成功案例的逻辑导致误操作。后来我们在上下文里加入了一些“反例”明确标注“这种情况不能这样处理因为……”。比如“如果客户没有提供订单号不要尝试用手机号去猜订单必须要求客户提供”。这些负样本极大地降低了Agent的“自信犯错”率。提示负样本不要太多否则会干扰模型对正确路径的学习。我们的经验是正负样本比例控制在5:1左右比较合适而且负样本必须附带清晰的“为什么错”的解释。3. 工具调用Agent的“手”比“脑”更容易出问题3.1 工具调用的失败模式参数错、顺序错、重试错模型再聪明如果调不动工具或者调错了工具整个Agent就是废的。我们统计过生产环境里Agent的失败案例超过60%的问题出在工具调用环节而不是模型推理本身。常见的失败模式有三种参数错误模型生成了工具调用但参数格式不对、缺字段、或者值超出了允许范围。比如调一个查询接口把日期格式写成了“2024年1月1日”而接口要求的是“2024-01-01”。顺序错误有些操作有严格的依赖关系必须先创建再查询但模型可能跳步或者乱序。重试错误工具调用失败后模型不知道该怎么重试要么无限重试同一个错误参数要么直接放弃并编造一个结果。这些问题在Demo里很少出现因为Demo的场景简单、工具少、参数固定。但生产环境里工具有几十个参数组合上千种模型不可能每次都一次做对。3.2 工具描述的设计给模型写“说明书”的学问我们踩过最大的坑就是工具描述写得太随意。早期我们觉得工具描述嘛写个名字和功能就行了。结果模型经常选错工具或者传错参数。后来我们才意识到工具描述就是给模型看的API文档必须极其严谨。一个好的工具描述应该包含功能说明一句话说清楚这个工具是干什么的什么场景下用。参数说明每个参数的类型、格式、是否必填、取值范围、默认值。最好给出示例值。返回值说明返回什么结构哪些字段是关键的。错误码说明常见错误有哪些分别代表什么含义模型应该怎么处理。使用限制比如频率限制、权限要求、前置条件。我们后来甚至给每个工具写了一个“反例”明确告诉模型“不要用这个工具做XX事”。比如“不要用查询工具去修改数据”。这些细节看起来琐碎但能极大降低工具调用的错误率。3.3 参数校验与容错在模型和真实API之间加一层“安全网”即使工具描述写得再好模型还是可能犯错。所以我们在模型和真实API之间加了一层参数校验与容错层。这层做几件事格式校验检查参数类型、格式是否符合预期。不符合就拦截并给模型返回一个清晰的错误信息让它重新生成。值域校验检查参数值是否在允许范围内。比如日期不能是过去的时间金额不能为负。依赖检查检查前置条件是否满足。比如调“取消订单”之前必须先确认订单状态是“未发货”。幂等处理对于写操作确保重复调用不会产生副作用。我们给每个写操作都加了一个唯一的请求ID如果同一个ID重复调用直接返回上次的结果。这层“安全网”上线后工具调用的成功率从最初的70%多提升到了95%以上。而且因为错误信息清晰模型自己就能纠正大部分问题不需要人工干预。3.4 工具编排让Agent学会“先做什么再做什么”单个工具调用搞定后更复杂的是多工具编排。一个完整的业务操作往往需要调好几个工具而且有严格的顺序。比如处理退货要先查订单、再查库存、再生成退货单、再通知物流。模型有时候会跳步或者并行调用有依赖关系的工具。我们的解决方案是把常见的业务流程抽象成“工作流模板”每个模板定义了步骤、依赖关系、每个步骤用哪个工具、参数怎么传递。Agent不需要自己规划整个流程只需要在模板的框架下填充具体的参数。这有点像给Agent一个“剧本”它负责演但不负责编。当然对于特别复杂的、非标准的任务我们还是让Agent自由规划但会加上严格的步骤校验确保它不会跳步。注意工作流模板不是万能的它牺牲了一定的灵活性。我们的经验是对于高频、标准的业务用模板对于低频、探索性的任务让Agent自由发挥但要有兜底的人工审核。4. 评估与迭代没有度量就没有改进4.1 为什么传统的评估指标在Agent场景下失效了做模型评估大家习惯用准确率、召回率、F1。但在Agent场景下这些指标往往不够用。因为Agent的输出不是一个简单的分类或标签而是一系列动作和自然语言回复的组合。一个Agent可能回答的内容完全正确但调用了错误的工具或者顺序不对导致实际业务失败。反过来它可能工具调用全对但回复的语气让用户不爽。我们早期用人工抽检来评估但效率太低而且主观性强。后来我们设计了一套多维度的评估体系把Agent的表现拆成几个可量化的维度任务完成率用户的问题是否被真正解决了这个最终以业务系统的状态变更为准比如工单是否关闭、订单是否修改成功。工具调用准确率调用的工具是否正确参数是否正确顺序是否正确回复质量回复是否准确、完整、语气合适这个用人工评分或模型评分。效率完成一个任务需要多少轮对话多少Token多少时间安全性有没有越权操作有没有泄露敏感信息有没有产生有害内容每个维度都有明确的定义和计算方式这样我们才能客观地比较不同版本、不同策略的效果。4.2 构建评估集从真实日志里“挖”出好案例和坏案例评估集不是拍脑袋想出来的而是从真实的生产日志里“挖”出来的。我们每周会从线上随机抽取一批对话日志然后人工标注哪些是成功的哪些是失败的失败的原因是什么。成功的案例进入“正样本集”失败的进入“负样本集”。随着时间推移这个评估集越来越大覆盖的场景也越来越全。这里有个技巧评估集要定期更新而且要包含“边界案例”。比如用户输入特别模糊、包含错别字、或者夹杂了情绪化表达的情况。这些案例最能考验Agent的鲁棒性。我们还会故意构造一些“对抗性案例”比如用户试图诱导Agent执行越权操作看看它会不会上钩。4.3 自动化评估流水线让每次迭代都能快速验证人工评估太慢我们后来搭建了一套自动化评估流水线。每次模型或Prompt有改动就自动在评估集上跑一遍生成一份报告对比新旧版本的各项指标。如果某个指标下降超过阈值就自动告警阻止上线。自动化评估的核心是用模型来评估模型。我们用一个能力较强的模型作为“裁判”根据预设的评分标准对Agent的回复和工具调用进行打分。当然裁判模型也会有偏差所以我们定期用人工评分来校准裁判模型确保它的评分和人工评分有较高的一致性。这套流水线让我们从“凭感觉迭代”变成了“看数据迭代”。以前改一个Prompt要等几天才能知道效果好不好现在改完几分钟就能看到评估报告迭代速度提升了十倍不止。4.4 从评估到迭代找到那个“最小改动最大收益”的点评估的最终目的是指导迭代。但面对一堆失败案例从哪改起我们的经验是先做失败归因再按影响面排序。把所有失败案例按原因分类比如“上下文缺失”占30%“工具参数错误”占25%“模型推理错误”占20%“其他”占25%。然后优先解决占比最高的那类问题。因为解决一个高频问题收益远大于解决十个低频问题。另外不要试图一次性解决所有问题。Agent的迭代是一个持续的过程每次只聚焦一两个关键指标改完验证再改下一个。我们曾经想一口气把准确率从80%提到95%结果改了一大堆东西反而引入了新的问题指标不升反降。后来学乖了小步快跑每次只动一个变量效果反而更稳。5. 那些文档里不会写的实战心得5.1 关于模型选型别迷信“最强模型”适合的才是最好的项目初期我们总想用最强的模型觉得贵点没关系效果好就行。但实际跑下来发现最强模型不一定最适合你的场景。有些任务比如意图分类、实体提取用一个小模型微调一下效果不比大模型差但成本和延迟低了一个数量级。我们的策略是分层使用模型简单的分类、提取任务用便宜的小模型复杂的推理、生成任务用大模型对实时性要求极高的场景甚至用规则引擎兜底。还有一个反直觉的发现模型的能力越强对上下文和工具描述的要求反而越高。因为强模型更“聪明”它会尝试理解你的意图如果你的工具描述有歧义它会“自作主张”地做出错误解读。所以用强模型的时候工具描述和上下文工程要做得更精细。5.2 关于人机协作Agent不是替代人是增强人我们一开始的目标是让Agent完全自动处理工单不需要人工介入。但跑了一段时间发现有些复杂情况Agent确实搞不定强行自动处理反而会引发客户投诉。后来我们调整了策略把Agent定位为“第一响应者”它处理大部分标准问题遇到不确定的、复杂的、或者高风险的场景自动转人工并且把已经收集到的信息、已经尝试过的操作整理好交给人工。这样人工的效率也提高了因为不用从头问起。这个转变让我们意识到Agent的价值不在于“全自动”而在于“人机协作”。把Agent当成一个能力很强但经验不足的新员工它需要人的指导和兜底。设计系统的时候一定要把“转人工”的路径设计得顺畅、无感。5.3 关于成本控制Token很贵但更贵的是错误决策Agent跑起来之后Token消耗是实打实的成本。我们算过一笔账如果上下文不加控制一个复杂工单的Token消耗可能是简单工单的几十倍。所以上下文压缩、缓存、分层模型这些手段不仅是为了效果也是为了成本。但比Token更贵的是错误决策带来的业务损失。比如Agent错误地给客户退了款或者错误地修改了配置导致系统故障。这些损失远不是省几百万Token能弥补的。所以我们在成本控制上有一个原则在关键决策路径上不要为了省钱而牺牲准确性。该用大模型就用大模型该加校验就加校验该转人工就转人工。5.4 关于团队协作Agent项目需要“全栈”思维做Agent项目最怕的是“各管一段”。算法团队只管模型工程团队只管API产品团队只管交互结果就是模型不知道工具怎么用工程不知道模型需要什么上下文产品不知道Agent的能力边界。我们后来成立了一个跨职能的小组算法、工程、产品、业务方坐在一起每周对齐。这个小组的沟通成本很高但决策效率也高很多。还有一个体会业务方的深度参与是成功的关键。Agent要解决的是业务问题不是技术问题。业务方最清楚哪些场景高频、哪些操作风险高、哪些错误不可接受。让他们从一开始就参与设计、参与评估能避免很多“技术自嗨”。6. 如果重新来过我会优先做这三件事如果让我重新启动一个企业级Agent项目我不会再一上来就调模型、写Prompt。我会先把这三件事做了第一定义清楚“成功”和“失败”的标准。和业务方一起把Agent要完成的任务拆解成可量化的指标明确哪些错误是绝对不能接受的哪些是可以容忍的。这个标准不是写在文档里就完了而是要变成评估集和自动化流水线的一部分。第二把工具层做扎实。工具描述、参数校验、容错重试、幂等处理这些看起来是“脏活累活”但它们是Agent的“手”和“脚”。手不稳脑子再聪明也没用。我会先花时间把工具层打磨好再让Agent去调用。第三建立快速迭代的闭环。从第一天起就收集日志、标注数据、搭建自动化评估。不要等到“模型调好了”再想评估的事因为“调好”的标准本身就需要评估来定义。迭代速度决定了项目成败而迭代速度取决于反馈闭环的效率。这一年下来我最大的感受是Agent落地是一场工程仗不是算法仗。模型能力会越来越强但上下文工程、工具可靠性、评估迭代这些“脏活”永远需要有人去干。干得好Agent就是生产力干不好它就是玩具。希望这些经验能帮你少踩几个坑把Agent真正用起来。