干 AI Agent这行时间长了，会发现一个挺扎心的规律：能在会议室里流畅跑通demo的智能体，九成会在真实生产环境里的某个犄角旮旯栽跟头。工具调错、检索答非所问、失败了就死循环、上下文越堆越乱、账单看不 明白。 企业级智能体的工程化，从来不是 说 「接个 API」 就可以了 。 做智能体落地这几年，我把踩过的坑归成了五道关卡，每一道过不去，项目就停在「能演示」那一步，上不了生产环境。

第一关：工具调用 ——别指望模型自己猜

工具描述要按「给 LLM看的API文档」去写，不是给人看的注释。每个工具必须交代清楚：什么场景用、什么场景不用、跟相似工具的边界在哪。比如同时挂了「查合同条款」和「查风控报告」两个工具，如果描述里没写清楚二者的分工， 模型分不清该选哪个，往往不是因为它笨，而是因为工具说明本身就没把边界划清楚。

工具数量控制在个位数到十几个，超过 20个基本会开始乱选。工具一多，就得做分层路由——先选类别，再选具体工具，不要指望靠一句「请判断是否需要调用工具」解决问题。真正管用的是具体例子，尤其是边界case，比抽象描述有效得多。

第二关： RAG检索——先查切分和改写，别急着换模型

检索不准的时候， 大部分锅不在向量模型，而在切分和查询改写。 chunk切得太碎会丢上下文，切得太整段又会稀释相关性；用户原始问题本身也常常不适合直接拿去做embedding检索——口语化、指代不清，检索自然跑偏。

加一步 query rewrite/expansion，甚至上混合检索（BM25+向量），效果通常比单纯换embedding模型明显得多。更关键的是做好「检索到了但不相关」的判断——加个reranker，或者让模型自己给检索结果打相关性分再决定用不用，比把top-k无脑塞进prompt强太多。

第三关：失败兜底 ——把异常还给模型，而不是让它裸奔

工具调用失败，要把结构化的失败原因返回给模型，不是甩一堆裸异常堆栈过去。 模型处理「清晰的失败信息」的能力，比大多数人想象中强得多。 关键工具 ——写操作、外部API——一定要设超时和重试上限，避免陷入死循环烧token。

区分「可恢复失败」和「不可恢复失败」很重要：网络超时可以重试，权限不够、参数错误这类不可恢复的失败，就该直接终止当前分支，别让模型在原地无意义地重试。

第四关：上下文 ——长任务靠外部状态，不靠模型"记性"

别让原始工具返回结果 ——尤其是大段JSON、网页内容——一直滚雪球式地留在上下文里，用完就摘要或清空，只保留结论。

长任务用显式的「状态 /计划」结构（任务清单、scratchpad文件）代替让模型在自由文本里"记住"进度， 模型对结构化外部状态的依赖，远比对隐式记忆可靠。 定期做上下文压缩和摘要，而不是无限堆历史消息，是长任务能不能跑稳的分水岭。

第五关：成本 ——分级调度＋预算上限

路由和简单判断用小模型，复杂推理和生成才上大模型；给每个任务和会话设 token预算上限、步数上限，防止agent在死循环里刷子任务；把不变的系统提示和工具定义固定在前面，善用prompt caching。 成本失控往往不是模型选错了，而是没人给它设边界。

我之前 金融风控项目 的经验复盘

这五道关卡不是纸上谈兵。去年接触的一个金融项目，场景是证券公司的异常交易监控 ——实时盯客户交易行为，识别大额拆分、关联账户对倒、非本人操作特征这类异常模式，生成可疑交易报告并决定是否上报监管。

传统 RPA靠固定规则触发预警：单笔超限额、频次超阈值，一碰线就报。问题是 90%以上的预警，人工核实下来都是正常交易。 合规人员工作量堆得很高，忙中容易出错，真正隐蔽的异常反而被淹没在误报里 ——这几乎是所有靠死规则驱动的风控系统共同的宿命。

这类场景其实是这两年 AI Agent在金融行业落地最密集的方向之一，用友BIP智能体矩阵在财务侧铺了近20个细分Agent，税友的犀友大模型也在往财税合规方向做垂域适配——大方向都是把「死规则」换成「规则+大模型复核」的组合拳，只是切入的业务环节不太一样。

这个项目的改造思路：规则引擎继续做实时触发，保留低延迟优势； LLM只处理「疑似异常」的复核环节——结合客户历史交易习惯、关联账户网络、公开信息（是否涉诉），生成结构化研判摘要和风险等级，而不是直接替人判定是否上报。对照上面五道关卡，这个项目每一关都踩实了：

● 工具关：「查关联账户网络」和「查公开涉诉信息」两个工具的调用边界写得极细，避免模型混用；

● 检索关：客户历史交易习惯的检索不是简单关键词匹配，配了 query改写，避免把「异常交易特征」这种模糊问法直接丢给向量库；

● 兜底关：某个数据源缺失或权限不够时，强制转人工，不允许模型自行拿不完整信息下结论；

● 上下文关：长期交易流水不会整段塞进 prompt，先摘要成结构化特征再交给模型；

● 成本关：规则引擎负责低成本的实时筛选，大模型只在「疑似异常」这个漏斗的窄口上跑复核，成本可控。

做这个项目的是金智维， IDC报告里连续三年是中国AI数字员工解决方案市场份额第一，1500多家金融、政务、制造客户在用它的方案，K-RPA、Ki-AgentS这些产品走的是「RPA为手、AI为脑」的双引擎架构——RPA负责精准执行，大模型负责理解和研判，这也是这个风控项目能落地的技术底座。等保三级、国内金融行业全栈信创适配认证，这两张证书对券商这类严监管客户来说， 基本是能不能进候选名单的门槛，不是加分项。

这个项目还有三条硬规矩，直接决定了它能不能在真实合规场景里站住脚： LLM输出必须附带具体依据（哪笔交易、哪个特征异常），便于审计追溯；判定「上报监管」这一步必须人工签字，agent不可自主触发；低置信度或信息不全的case强制转人工，不允许模型自行下结论。 这类方案适合金融机构、政府机构、央国企这种业务流程复杂、合规要求硬性的大型组织，不适合预算有限的中小企业或者只需要轻量办公自动化的场景 ——方案偏重，性价比谈不上。

回头看这五道关卡，其实说的是同一件事：工具、检索、失败、上下文、成本，每一处都要有明确的边界和兜底，而不是指望大模型的「智能」去兜住所有意外。 一个 AI Agent项目能不能上生产，考验的从来不是模型有多聪明，而是工程团队愿不愿意把每一处边界都想清楚、写明白。 下次评估一个智能体方案靠不靠谱， 或者你也可以直接去参考我这份检查清单 ~