Agent 工程化：从 Demo 到生产，你必须拆掉的四颗"隐形炸弹"

我要说一个可能冒犯很多 Agent 开发者的观点：你的 Agent 上不了生产，不是因为模型不够聪明，而是因为工程没做到位。

这话听起来有点狠，但数据站在我这边。

Gartner 预测，到 2027 年底，超过 40% 的 Agentic AI 项目将被取消或搁置——原因不是技术不行，而是成本失控、风险不可管、价值说不清。LangChain 2026 年的调研也印证了这一点：57% 的组织已经在生产环境跑 Agent 了，但排名第一的痛点不是"模型太笨"，而是"质量不稳定"（32%）和"延迟太高"（20%）。

换句话说，大家卡住的地方不是"能不能做个 Agent"，而是"怎么让这个 Agent 在生产环境里稳定、可控、不烧钱地跑起来"。

这中间的鸿沟，我总结了四颗"隐形炸弹"——你在 Demo 阶段感受不到，但一到生产环境就会炸：

1. 工具搜索空间爆炸：接了 100 个工具，Agent 选不对
2. Planning 层放错位置：规划和执行纠缠在一起
3. 停不下来：Agent 不知道什么时候该收手
4. 成本和延迟失控：一次调用烧掉比你预期多 10 倍的钱

接下来，我们一颗一颗拆。

---

100 个工具接进来，Agent 怎么选？

先想一个场景。

你给 Agent 接了 5 个工具——搜索、读文件、写文件、执行代码、发消息。它工作得挺好，像个靠谱的小助手。

然后你信心大增，一口气接了 100 个工具。数据库查询、日志分析、Jira 创建工单、Slack 发通知、K8s 扩缩容、飞书审批……

结果呢？Agent 开始"抽风"了。

该查数据库的时候去搜了 Google，该发 Slack 的时候创建了 Jira 工单。不是它变笨了，而是搜索空间爆炸了。

打个比方：5 个工具的时候，Agent 就像在点菜——菜单就一页，挑对不难。100 个工具的时候，它就像走进了一个巨型自助餐厅——光是转一圈就得花 10 分钟，更别说精确拿到你想要的那道菜了。

为什么"全部塞进 prompt"行不通？

最朴素的想法是：把所有工具的描述都写进 system prompt，让模型自己选。

这在工具少的时候可以。但工具一多，问题就来了：

• context window 被工具描述占满，留给真正任务的空间反而不够了
• 工具描述之间的语义相似度太高，模型分不清"搜索日志"和"查询日志数据库"到底该用哪个
• 选错工具的概率随工具数量指数上升，而不是线性上升

微软内部做过一个实验。他们最初给 Agent 配了 100 多个定制工具，"Intent Met"评分只有 45%——也就是说超过一半的时候，Agent 理解了你的意图，但选错了工具。

解法：三层漏斗，逐级收敛

经过反复踩坑，业界收敛出了一个核心模式：不要让 Agent 在 100 个工具里选，而是先把 100 个缩小到 5 个，再让它选。

具体怎么做？

第一层：意图分类器。用一个轻量模型（甚至规则引擎）先判断用户意图属于哪个领域——是"数据查询"、"运维操作"还是"沟通协作"？这一步的目的不是选对工具，而是排除 90% 明显不相关的工具。

第二层：工具注册表。每个领域维护一个工具分组。"数据查询"领域下可能有 SQL 查询、日志搜索、监控面板 API 这几个工具。分组可以用语义索引（embedding 相似度）动态匹配，也可以手动维护——取决于你的工具变化频率。

第三层：LLM 精选。把筛选后的 5-8 个候选工具描述，连同用户请求一起交给强模型。这时候 context window 清爽，语义区分度高，选对的概率大幅提升。

微软后来换了一种更激进的做法：把所有东西都暴露为文件系统，让 Agent 用标准的文件操作（读、写、搜索）来完成任务。"Intent Met"分数从 45% 飙升到 75%。

工具不是越多越好，是越准越好。

---

Planning 该放在哪一层？

解决了工具选择的问题，你发现 Agent 终于能调对工具了。但新问题来了：它调工具的顺序不对。

比如你让它"分析上周的用户流失原因并发到 Slack"。它应该先查数据库、再做分析、最后发消息。但实际上，它可能先发了一条空消息到 Slack，然后才想起来"哦，我还没查数据"。

这就是 Planning（规划）出了问题。

最常见的错误：让一个模型既规划又执行

大部分入门级 Agent 用的是 ReAct 模式——模型想一步、做一步、看一下结果、再想下一步。这在简单任务上没问题，但对复杂任务，它就像一个"边走边看地图"的游客：

• 容易走回头路（重复调用同一个工具）
• 容易漏步骤（忘了中间某个关键环节）
• 速度慢（每一步都要等一次完整的 LLM 推理）

根据 2026 年的 benchmark 数据，Plan-and-Execute 架构的任务完成率可以达到 92%，而纯 ReAct 模式只有约 70%。更关键的是速度——Plan-and-Execute 因为可以并行执行独立步骤，整体速度快了 3.6 倍。

解法：将军和士兵，各司其职

成熟的 Agent 架构，规划和执行是分开的。我喜欢用"将军和士兵"来比喻：

将军（Planner）负责拿到任务后，拆解成一个有向无环图（DAG）。"先做 A 和 B（可以并行），A 和 B 都完成后再做 C，最后做 D。"将军用的是重型推理模型，比如 Claude Opus 或 GPT o3——因为规划本身就是最需要智力的部分。

士兵（Executor）负责执行每个具体步骤。士兵可以用更快、更便宜的模型——因为单个步骤的指令已经非常明确了，不需要太多"思考"。

参谋长（Re-planner）负责在士兵汇报执行结果后，判断原计划是否需要调整。如果某一步失败了，参谋长决定是重试、跳过还是修改后续计划。

但这里有一个实战中特别容易踩的坑：什么时候该用 Plan-and-Execute，什么时候该用动态编排？

判断标准很简单：你在写任务的时候，能不能把所有步骤列出来？

如果能——用 Plan-and-Execute。比如"查数据→分析→发报告"，步骤在一开始就明确了。

如果不能——用 Orchestrator-Worker。比如"帮我调试这个 bug"，你不知道要查几个文件、跑几次测试，步骤是在执行中动态涌现的。

好的规划是让执行者不需要思考。如果你的士兵还需要自己判断下一步做什么，说明将军的工作没做好。

---

Agent 不知道什么时候该停下来？

聊一个 Agent 工程里最被低估的问题。

Glen Rhodes 说过一句话，我深以为然："终止逻辑是 Agent 系统中最被低估的设计问题——不是模型质量，不是 prompt 设计。"

为什么？因为传统程序的"完成"是确定的——函数返回值、HTTP 200、测试通过。但 Agent 的"完成"是模糊的。

你让 Agent "写一篇市场分析报告"。它写了一版。然后它觉得"好像还不够好"，又改了一版。然后又改了一版。又改了一版……

你一看 token 消耗，已经烧了 5 美元了，报告还在改第 17 版。

这不是模型的问题，这是你没告诉它什么时候该停。

"自信但错误"的陷阱

更危险的是另一种情况：Agent 很快就"完成"了，输出看起来也很漂亮——格式工整、措辞流畅、逻辑自洽。

但内容是错的。

Glen Rhodes 把这个叫"confidence laundering"（自信洗白）。模型输出的流畅程度让人产生了一种"它很确定"的错觉，但流畅不等于正确。在代码生成、法律文档、财务分析这些场景里，一个"错但自信"的 Agent，比一个"会报错"的程序危险一百倍。

解法：三层刹车，层层防护

我把有效的停止机制总结为"出租车计价器"模型——你不能靠乘客自觉说"到了"来停车，你需要一套机制：

第一层刹车：明确退出条件。

任务下发的时候，就要定义清楚"什么算完成"。不是"写一篇好报告"，而是"写一篇 500 字的报告，包含 3 个关键数据点和一个结论"。可度量的退出条件，是 Agent 停下来的前提。

第二层刹车：循环预算。

给每个 Agent 设一个"预算信封"——最多重试 N 次。第二次重试时，必须通过"delta 测试"：你这次跟上次到底改了什么？如果说不出实质性变化，立刻升级（escalate）给人类或上层系统，而不是继续循环。

// 每次 Agent 交出结果时，必须附带这个信封
{
  "status": "DONE | RETRY | ESCALATE | REFUSE",
  "attempt": 2,
  "loop_budget_remaining": 1,
  "delta_summary": "新增了 Q1 营收对比数据",
  "stop_reason": "三个关键数据点已齐全"
}

这段 JSON 就是"计价器"。Agent 每跑一步，你都能看到它还剩多少预算、这一步做了什么改变、为什么决定停下来（或继续）。

第三层刹车：硬超时。

无论 Agent 做什么，最外层必须有一个不可覆盖的时间墙。Karpathy 在他的自主研究 Agent 里就是这么做的——每次实验给 5 分钟，时间到了不管跑到哪一步，强制终止。这个约束是架构级别的，不是写在 prompt 里让模型"自觉遵守"的。

没有刹车的车，再快也没人敢坐。Agent 的停止机制，不是"加分项"，是"准入门槛"。

---

一次调用 5 美元，你扛得住吗？

最后一颗炸弹，也是最容易被忽视的：钱。

聊一个真实场景。你做了一个客服 Agent。Demo 很惊艳：用户问问题，Agent 自动查知识库、调 CRM、生成回复、发送。老板很高兴，说"上线"。

上线第一天，1000 个用户来了。你看了一下账单——

Token 消耗是普通对话的 5 到 30 倍。

为什么？因为 Agent 不是"问一句答一句"。它每处理一个用户请求，背后可能跑了 5-8 次 LLM 调用：意图识别、规划、工具选择、工具执行、结果验证、回复生成……每次调用都在烧 token，而且输出 token 的价格通常是输入 token 的 3-5 倍。

打个比方：普通对话就像家里开灯——电费可以忽略。Agent 就像开空调——你以为只是多了一个功能，但电费翻了 10 倍。

成本的四个控制杠杆

好消息是，业界已经沉淀出一套成熟的成本控制方法论。做得好的团队，可以在不明显降低质量的前提下，砍掉 50-70% 的成本。

杠杆	原理	效果
语义缓存	相似问题复用历史结果，不重复调 LLM	减少 30%+ 的重复调用
模型路由	简单任务走便宜小模型，复杂任务走强模型	平均单价降 40-60%
输出控制	限制回复长度，减少输出 token	输出 token 减少 50%+
规划缓存	相似任务复用历史规划方案	减少 50% 规划成本

其中最容易被忽视、但效果最立竿见影的是模型路由。

你不需要用 Claude Opus 来做意图分类，也不需要用 GPT-4o 来格式化输出。一个 Agent 工作流里，真正需要"最聪明的模型"的环节可能只有 1-2 步（规划、复杂推理），剩下的 6-7 步用 Haiku 或 Flash 就够了。

这就像公司用人：你不会让 CTO 去写每一行代码，你让他做架构决策，让实习生写 CRUD。模型路由的本质，就是"人岗匹配"。

延迟的红线：2 秒

成本之外，还有延迟。

在客服、代码生成这类交互式场景中，用户能忍受的等待时间上限大约是 2-3 秒。超过这个阈值，用户开始流失。

但一个典型的 Agent 工作流——规划（1-2 秒）+ 工具调用（0.5-1 秒）+ LLM 生成（1-3 秒）——很容易就超过 5 秒。

解法有两个方向：

并行化：Plan-and-Execute 架构的一个副产品就是——独立步骤可以并行执行。"查 CRM"和"搜知识库"没有依赖关系，就应该同时跑，而不是排队。

流式输出：用户不需要等所有计算完成才看到结果。先流式输出"正在查询您的订单信息……"，再逐步补充详情。感知延迟（perceived latency）比实际延迟更重要。

省钱的最高境界不是用便宜模型，而是少调用。每一次 LLM 调用，都应该问自己：这一步真的需要大模型吗？

---

写在最后：你的 Agent 及格了吗？

回顾一下这四颗炸弹和对应的拆弹方案：

• 工具搜索空间爆炸 → 三层漏斗，先分类再精选，让 Agent 每次只面对 5-8 个候选工具
• Planning 层错位 → 将军和士兵分离，规划用强模型只调一次，执行用快模型可并行
• 停不下来 → 三层刹车——明确退出条件、循环预算、硬超时，且必须是架构级约束
• 成本延迟失控 → 模型路由 + 语义缓存 + 规划缓存 + 流式输出，在不降质的前提下砍 50-70% 成本

这四件事有一个共同点：它们都不是靠"写更好的 prompt"能解决的。它们是架构问题、工程问题、系统设计问题。

这也是为什么 LangChain 的调研里，已经在生产环境跑 Agent 的团队，94% 都建了完整的可观测性体系——因为他们知道，光靠 Demo 阶段的"感觉还行"是不够的，你需要看到每一步发生了什么、花了多少钱、耗了多少时间。

我想给你一个挑战：

今天回去，打开你的 Agent 项目，问自己四个问题：

1. 我的 Agent 同时面对超过 10 个工具吗？
2. 我的 Planning 和 Execution 是同一个模型在做吗？
3. 如果 Agent 陷入循环，有什么机制能在 30 秒内强制停掉它？
4. 我知道 Agent 处理一个请求平均花多少钱吗？

如果四个问题你都能自信回答，恭喜——你的 Agent 已经过了工程化的及格线。

如果有任何一个答不上来——那你知道下一步该做什么了。

Agent 的成熟度，不看它能做多少事，看它知道什么时候不该做。