从能回答到能干活这句话我在过去一年里跟不少团队聊过几乎每个人都会在某个时刻突然意识到Demo里那个对答如流的AI和生产环境里真正能替人分担工作的Agent中间隔着的不是模型能力的差距而是一整套工程能力的鸿沟。我见过太多项目卡在能回答这一步——用户问一句它答一句看起来挺聪明但一旦要求它去查数据库、调接口、走审批、生成凭证、处理异常立刻就露馅了。这篇文章想聊的就是这道鸿沟到底由什么填平一个能落地的AI Agent在RAG、Tool调用、Workflow编排、记忆管理、可观测性这些环节上分别需要什么样的工程能力以及我在实际搭建过程中踩过的那些坑。适合正在做Agent落地、或者准备从Demo往生产推的开发者也适合想搞清楚Agent到底难在哪的技术负责人。1. 先搞清楚能回答和能干活的本质差别1.1 一个问答系统和一个执行系统的分水岭很多人第一次接触AI Agent是从一个RAG问答机器人开始的把文档切块、向量化、存进向量库用户提问时检索相关片段拼进Prompt让大模型生成答案。这套流程跑通之后你会觉得AI已经能用了。但当你把同样的架构放到真实业务里问题就来了——用户问帮我查一下上个月华东区的销售异常订单然后给对应的负责人发一封提醒邮件这时候RAG检索出来的只是销售异常订单相关的文档说明它没法真的去查数据库也没法真的发邮件。这就是分水岭。问答系统的输出是文本执行系统的输出是状态变更。前者只需要保证答案在语义上正确后者需要保证操作在业务上正确、可追溯、可回滚。这个差别决定了工程复杂度的量级完全不同。我经常用一个类比问答系统像一个图书馆管理员你问他什么他告诉你Agent像一个助理你说帮我把这件事办了他得自己规划路径、找工具、执行、汇报。从工程视角看这个转变带来几个硬性要求第一Agent必须能调用外部工具Tool而且工具调用要可靠、要有错误处理第二Agent必须能编排多步流程Workflow因为真实任务很少一步完成第三Agent必须有记忆Memory否则每次对话都从零开始多轮任务根本没法做第四Agent必须有可观测性否则出了问题你根本不知道它在哪一步走偏了。1.2 为什么模型能力提升解决不了工程问题有一种很常见的误解等模型再强一点Agent就能自己搞定一切了。我不同意这个判断。模型能力提升确实能让Agent的规划更合理、工具选择更准确但它解决不了几个根本性的工程问题。比如工具调用的幂等性。模型可能会因为一次超时重试把同一个订单创建两次。这不是模型聪明不聪明的问题是工程上必须做幂等键和去重的问题。再比如权限控制。模型不知道当前用户有没有权限查财务数据这个必须在工具层做鉴权不能指望模型自己判断。还有错误恢复。工具调用失败了模型可能会换个参数重试也可能会编一个假的成功结果返回给用户——后者在Demo里看不出来在生产里是灾难。我自己的经验是Agent的可靠性上限由工程能力决定模型能力只决定它的下限。你把工程做扎实了一个中等能力的模型也能稳定干活工程做得糙再强的模型也会在某个边界条件下翻车。所以这篇文章的重点不在模型选型而在那些模型之外的东西。1.3 一个真实场景拆解从提问到完成任务的完整链路拿AI做凭证这个场景来说用户说根据这张发票生成记账凭证。看起来简单拆开看链路很长首先要识别发票内容可能是OCR也可能是结构化数据然后要匹配会计科目这需要查科目表可能还要用RAG检索历史相似凭证接着要生成凭证草稿这需要按借贷平衡规则计算再提交到财务系统Tool调用最后要记录操作日志可观测性。这条链路上每一步都可能出问题OCR识别错了怎么办科目匹配不到怎么办借贷不平衡怎么办财务系统接口超时怎么办用户中途改主意了怎么办这些问题没有一个是靠模型更聪明能解决的全部要靠工程手段——校验、重试、回滚、人工介入点、状态持久化。所以我在设计Agent时习惯先把任务链路画出来标出每一步的输入输出、失败模式、恢复策略然后再去考虑用什么样的Prompt和模型。这个顺序很重要反过来做的话你会被模型的聪明带偏忽略掉那些真正决定成败的工程细节。2. RAG在Agent里不是检索增强而是知识供给2.1 从静态知识库到动态知识供给的转变传统RAG的定位是检索增强生成——用户问一个问题检索相关文档增强这次生成的准确性。但在Agent场景里RAG的角色变了。Agent在执行任务的过程中会在不同步骤需要不同的知识规划时需要知道有哪些工具可用、每个工具能干什么执行时需要知道业务规则、字段含义、历史案例校验时需要知道约束条件、异常处理规范。这意味着RAG不能只是一个用户提问时查一下的被动组件而应该是一个随时可被Agent调用的知识供给服务。我通常会把知识分成几类分别管理工具知识工具描述、参数说明、调用示例、业务知识规则、流程、字段定义、案例知识历史处理记录、相似任务、约束知识权限、合规、边界条件。每一类的检索策略、更新频率、精度要求都不一样。举个例子工具知识需要极高的准确性因为Agent要根据它决定调哪个工具、传什么参数检索错了直接导致调用失败。而案例知识可以容忍一定的模糊性它的作用是给Agent提供参考不是精确匹配。把这两类混在一个向量库里用同一套检索策略效果往往不好。2.2 分块策略为什么按语义切比按字数切更靠谱分块是RAG里最容易被低估的环节。我见过太多项目直接用固定字数切分比如每500字一块重叠50字。这种做法在通用文档上勉强能用但在业务文档上经常把一条完整的规则切成两半检索出来的是半句话Agent根本没法用。我的做法是按语义结构切分。业务文档通常有清晰的层级章节、条款、步骤、表格。切分时优先按这些结构边界切保证每一块是一个完整的语义单元。如果一块太长比如超过1000字再考虑按段落切如果一块太短比如一个标题就和相邻内容合并。还有一个细节是保留上下文路径。比如一个条款在第三章 第二节 第5条切分后这一块的内容里应该带上这个路径信息这样检索出来时Agent能知道这条规则的出处和适用范围。我通常会在块的元数据里存路径检索时一起返回。表格的处理要特别小心。很多业务规则藏在表格里直接按文本切会把表格切碎。我的做法是把表格转成结构化的键值对或者自然语言描述比如当订单金额大于10000元时审批级别为A级这样检索和生成都更友好。2.3 检索质量的决定因素不只是向量相似度很多人以为RAG的检索质量就是向量相似度其实远不止。在实际Agent场景里我通常会用混合检索向量检索负责语义匹配关键词检索比如BM25负责精确匹配两者结果融合后再做重排。为什么需要关键词检索因为业务场景里经常有精确匹配的需求。用户问订单号SO20240115的物流状态向量检索可能给你返回一堆订单物流相关的文档但真正需要的是那个特定订单号对应的记录。这种精确匹配向量检索做不好关键词检索一查一个准。重排Rerank也很关键。初步检索出来的Top-K结果用一个专门的重排模型重新打分排序能显著提升精度。我实测下来加了重排之后Top-3的命中率能提升20%以上。重排模型可以选择开源的也可以调用专门的API成本不高但收益明显。还有一个容易被忽略的点是检索结果的去重和多样性。如果Top-5结果里有4条是同一段内容的重复那实际有效信息只有1条。我通常会在重排后做一次去重保证返回的结果覆盖不同的信息点。2.4 知识更新Agent的知识怎么保持新鲜业务知识是会变的——规则调整、流程优化、新工具上线。如果RAG的知识库不更新Agent就会用旧知识干活这在生产环境里是危险的。我的做法是建立知识版本管理机制。每次知识更新都生成一个新版本Agent调用时带上版本号这样出问题可以追溯到具体是哪版知识导致的。同时更新要支持增量不能每次全量重建向量库那样成本太高、停机时间太长。具体实现上我会给每个知识块加一个生效时间和失效时间字段检索时只返回当前有效的块。更新时不是删除旧块而是把旧块的失效时间设为当前时间插入新块。这样既保留了历史又保证了检索的准确性。还有一个实践是知识质量监控。我会记录每次检索的结果和Agent最终的使用情况如果某个知识块被检索出来但从未被采用或者被采用后导致任务失败就标记出来人工review。这个反馈闭环能让知识库越用越准。3. Tool调用Agent的手要稳不能抖3.1 工具描述写得好不好直接决定Agent选得对不对Tool调用的第一步是让Agent知道有哪些工具可用。这一步看起来简单实际上非常关键。工具描述写得太简略Agent不知道什么时候该用写得太复杂Agent又容易被干扰。我的经验是一个好的工具描述应该包含四要素功能一句话说明、适用场景、参数说明含类型和示例、返回结果说明。比如一个查询订单的工具描述不能只写查询订单而要写清楚根据订单号查询订单详情适用于需要获取订单状态、金额、收货信息的场景参数order_id为字符串类型的订单号返回包含订单状态和明细的JSON。还有一个技巧是给工具起一个语义明确的名字。query_order比qo好send_notification比notify好。名字本身就是给Agent的强信号。我见过有的项目工具名用缩写结果Agent经常选错工具改成全称后准确率明显提升。工具数量也要控制。我一般建议单个Agent可用的工具不超过20个超过之后Agent的选择准确率会下降。如果确实需要很多工具就做分层——先让Agent选工具类别再在类别内选具体工具。3.2 参数校验在模型和真实系统之间加一道闸模型生成的工具参数不能直接传给真实系统中间必须有一道校验。这道校验要做几件事类型检查字符串、数字、日期格式对不对、范围检查金额是不是正数、日期是不是合理范围、业务校验这个用户有没有权限、这个订单状态允不允许这个操作。我通常会在工具层做一个参数Schema用类似JSON Schema的方式定义每个参数的类型、格式、约束。模型生成的参数先过Schema校验不通过就返回错误让模型重新生成而不是直接调用真实系统。这样能挡掉大部分低级错误。还有一个重要的点是参数默认值和补全。有些参数模型可能不传但业务上需要。比如时间范围模型不传时应该默认最近7天而不是报错。这种默认逻辑要在工具层做不要指望模型每次都传全。提示参数校验失败时返回给模型的错误信息要具体比如order_id格式错误应为以SO开头的12位字符串而不是笼统的参数错误。具体的错误信息能帮助模型快速修正。3.3 幂等与重试为什么同一个操作不能执行两次这是生产环境里最容易出事的地方。模型调用工具超时了它可能会重试网络抖动导致响应丢失它也可能重试。如果工具不是幂等的重试就会导致重复操作——重复下单、重复发邮件、重复扣款。解决方案是幂等键。每次工具调用生成一个唯一的幂等键可以是任务ID步骤ID的组合工具层收到请求先查这个键有没有处理过处理过就直接返回上次的结果没处理过才真正执行。这样无论重试多少次实际效果只有一次。重试策略也要设计。不是所有失败都值得重试——参数错误重试没用网络超时重试有意义。我通常会把错误分类可重试错误超时、限流、临时故障和不可重试错误参数错误、权限不足、业务规则冲突。可重试的错误用指数退避策略重试不可重试的直接返回给Agent让它决定下一步。3.4 工具调用的可观测性出了问题要能定位工具调用出问题的时候你需要知道调了哪个工具、传了什么参数、返回了什么、耗时多少、成功还是失败。这些信息如果不记录排查问题就是盲人摸象。我的做法是每次工具调用都记一条结构化日志包含调用ID、任务ID、工具名、参数、结果、耗时、状态。这些日志汇总起来可以做监控哪些工具失败率高、哪些参数经常出错、哪些调用耗时异常。有了这些数据优化就有方向了。还有一个实践是调用链路追踪。一个任务可能涉及多次工具调用这些调用之间有依赖关系。用Trace ID把这些调用串起来出问题时能看到完整的调用链快速定位是哪一步出的问题。4. Workflow编排让Agent从随机应变到有章可循4.1 什么时候该用Workflow什么时候该让Agent自由发挥这是设计Agent时最纠结的问题。完全让Agent自由规划灵活但不可控完全用固定Workflow可控但不灵活。我的判断标准是流程确定性高、步骤固定的任务用Workflow需要根据情况动态决策的任务用Agent自主规划。比如生成月度报表这种任务步骤基本固定取数、计算、格式化、发送。这种就适合Workflow每一步做什么、失败怎么办都提前定义好。而处理客户投诉这种任务情况千变万化需要Agent根据投诉内容决定是查订单、查物流还是查退款记录这种就适合Agent自主规划。实际项目里我通常用混合模式外层用Workflow定义主干流程内层在某些节点让Agent自主决策。比如一个审批流程主干是提交-审核-批准-执行但审核这一步具体查什么、怎么判断交给Agent根据具体情况决定。4.2 状态管理多步任务不能失忆多步任务最大的挑战是状态管理。Agent执行到第三步时需要知道第一步和第二步的结果。如果状态没管好Agent就会失忆重复劳动或者逻辑断裂。我的做法是显式维护任务状态。每个任务有一个状态对象记录当前步骤、已完成步骤的结果、待处理的信息。Agent每一步操作前先读状态操作后更新状态。状态要持久化不能只放内存否则服务重启就丢了。状态设计要注意几点一是结构化不要用一段自然语言描述状态要用结构化的字段方便程序读取和校验二是可追溯每次状态变更都记录时间和原因出问题能回溯三是可恢复任务中断后能从上次的状态继续不用从头再来。4.3 人工介入点哪些环节必须留给人完全自动化的Agent在生产环境里是危险的必须留人工介入点。哪些环节需要人工我的经验是三类高风险操作涉及资金、权限变更、对外发送、低置信度决策Agent自己也不确定的时候、异常情况Agent没见过的场景。人工介入点的设计要考虑用户体验。不能动不动就弹个框让人确认那样用户会烦。我的做法是设置置信度阈值Agent置信度高于阈值自动执行低于阈值才请求人工确认。同时人工确认的界面要清晰展示Agent的决策依据让人能快速判断。还有一个细节是超时处理。人工介入点如果没人响应怎么办要有超时策略——超时后是自动拒绝、自动通过还是转给其他人要提前定义好。4.4 失败恢复任务中断了怎么接着跑生产环境里任务中断是常态——服务重启、网络故障、依赖系统不可用。Agent必须能从中断处恢复而不是从头再来。实现上我会把任务状态和步骤结果都持久化任务恢复时先读状态判断执行到哪一步了然后从下一步继续。这里有个关键是步骤的幂等性——恢复时可能会重复执行某一步这一步必须幂等否则会出问题。还有一种情况是部分成功。比如一个批量任务处理了100条处理到第50条时中断了。恢复时不能重新处理前50条要从第51条开始。这要求状态里记录处理进度而且要精确到每一条。5. MemoryAgent的经验怎么积累和调用5.1 短期记忆和长期记忆的分工Agent的记忆分两种短期记忆是当前任务的上下文长期记忆是跨任务的经验积累。短期记忆好理解就是对话历史、任务状态这些。长期记忆容易被忽略但它决定了Agent能不能越用越聪明。短期记忆的管理关键是控制长度。上下文窗口有限不能把所有历史都塞进去。我通常会用滑动窗口加摘要的方式最近几轮对话保留原文更早的对话压缩成摘要。摘要要保留关键信息——用户的核心诉求、已达成的结论、待办事项。长期记忆的管理关键是提炼和检索。不是把所有历史都存下来而是提炼出可复用的经验——比如这类问题通常这样处理这个用户偏好这种方式。存的时候要结构化检索的时候要能快速找到相关的经验。5.2 记忆的写入时机不是所有对话都值得记记忆不是越多越好无关的记忆会干扰Agent的判断。我的原则是只记有价值的信息用户的偏好和习惯、任务的成功处理模式、遇到的特殊情况和解决方案、明确的纠正和反馈。写入时机也很重要。我通常在这几个时刻触发记忆写入任务成功完成时记录成功模式、用户明确纠正时记录纠正内容、遇到新情况时记录新知识、任务失败时记录失败原因。不是每轮对话都写那样噪音太大。还有一个实践是记忆的时效性。有些记忆会过期比如用户当前的项目是X项目结束后这条记忆就没用了。我会给记忆加时效标记过期的记忆降低权重或者归档。5.3 记忆检索怎么在需要的时候想起对的事记忆检索的核心是相关性判断。当前任务需要什么经验就从记忆库里找最相关的。实现上可以用向量检索把当前任务描述向量化和记忆向量做相似度匹配。但纯向量检索不够还要考虑时效性和重要性。最近的记忆、被多次验证有效的记忆权重应该更高。我通常会用加权打分相似度占主要权重时效性和重要性作为调节因子。还有一个技巧是主动回忆。不是等Agent需要时才检索而是在任务开始时就把相关记忆加载进来作为上下文的一部分。这样Agent在规划时就能考虑到历史经验而不是执行到一半才想起来。6. 可观测性与评测Agent的体检报告6.1 日志、指标、追踪三件套一个都不能少Agent的可观测性和传统服务类似也是日志、指标、追踪三件套但内容有特殊性。日志要记录Agent的决策过程——它为什么选这个工具、为什么走这条路径。指标要关注Agent特有的维度——任务成功率、平均步数、工具调用准确率、人工介入率。追踪要能还原完整的任务执行链路。我特别想强调决策日志的重要性。传统服务的日志记录发生了什么Agent的日志还要记录为什么这么发生。比如Agent选择了工具A而不是工具B这个决策依据要记下来否则出问题时你只知道它选错了不知道它为什么选错。6.2 评测集怎么衡量Agent到底行不行Agent的评测比传统模型评测复杂因为它涉及多步决策和外部交互。我的做法是构建场景化的评测集收集真实的任务场景标注期望的执行路径和结果然后让Agent跑这些场景对比实际路径和期望路径。评测指标不能只看最终结果对不对还要看过程合不合理。一个任务最终完成了但中间绕了很多弯路、调了很多不该调的工具这也是有问题的。我通常会用几个指标综合评估任务完成率、路径准确率、工具调用准确率、平均步数、人工介入率。评测集要持续更新。Agent上线后会遇到评测集里没有的场景这些场景要补充进去让评测集越来越贴近真实。6.3 线上问题的排查思路从现象到根因Agent线上出问题排查思路和传统服务不太一样。传统服务出问题通常是某个环节报错Agent出问题可能是结果不对但没报错。这时候要从结果倒推结果不对是因为哪一步的决策错了决策错了是因为输入信息不对还是判断逻辑不对输入信息不对是因为检索错了还是上下文丢了我通常的排查顺序是先看任务执行链路定位是哪一步出的问题再看这一步的输入上下文、检索结果、工具返回判断信息是否充分最后看Agent的决策逻辑Prompt、模型输出判断是信息问题还是逻辑问题。这个顺序能快速缩小范围。7. 从Demo到生产的工程化清单7.1 上线前必须过的几道关Agent上线前我通常会过一遍这个清单工具调用的幂等和重试做了吗参数校验做了吗权限控制做了吗状态持久化做了吗人工介入点设了吗失败恢复做了吗日志和监控接了吗评测集跑了吗这些不是可选项是必选项。还有几个容易被忽略的限流和熔断——Agent调用外部系统要有频率限制外部系统故障时要能熔断不能把对方打挂成本控制——Agent可能调用很多次模型和工具要有成本监控和上限数据安全——Agent处理的数据可能包含敏感信息要有脱敏和访问控制。7.2 灰度上线和持续迭代Agent不要一次性全量上线要灰度。先小范围试用观察指标收集问题修复后再扩大范围。灰度期间要特别关注人工介入率和任务失败率这两个指标高说明Agent还不够成熟。上线后要持续迭代。迭代的依据是线上数据——哪些场景失败率高、哪些工具调用经常出错、哪些决策经常需要人工纠正。针对这些问题优化Prompt、补充知识、调整工具形成闭环。7.3 我踩过的几个典型坑第一个坑是过度信任模型。早期我让模型直接生成工具参数不做校验结果经常出现参数格式错误导致调用失败。后来加了Schema校验问题基本解决。第二个坑是忽略幂等。有一次Agent重试导致重复创建了订单虽然最后人工处理了但暴露了幂等设计的缺失。从那以后所有写操作的工具都必须支持幂等键。第三个坑是状态管理太随意。早期用内存存状态服务重启后任务全丢了。后来改成持久化并且做了状态版本管理问题才解决。第四个坑是评测集太理想化。早期评测集都是精心设计的场景Agent跑得很好上线后遇到真实场景就露馅。后来评测集加入了大量真实场景包括各种边界情况评测结果才靠谱。7.4 给准备入场的团队的建议如果你正准备做Agent落地我的建议是先把工程骨架搭好再考虑模型和Prompt优化。工程骨架包括工具层、状态管理、可观测性、评测体系这些是地基。地基不牢上面盖什么都会塌。另外不要追求一步到位的全自动。先从半自动开始人工介入点多一些随着Agent成熟逐步减少。这样风险可控也能积累经验。最后重视数据积累。Agent的优化依赖数据——任务日志、评测结果、用户反馈。从第一天就要把这些数据收集好后面优化才有依据。这个领域变化很快但工程的基本原则是稳定的。把幂等、校验、状态、可观测性这些基本功做扎实无论模型怎么迭代你的Agent都能稳定干活。我在实际项目里最大的体会就是Agent的竞争力不在模型在工程。