你的规划器输出了五次工具调用。从纸面上看，这是一个干净的解决方案：lookup_user、search_documents、call_external_api、spawn_sub_agent、request_human_approval。轨迹优雅、逻辑自洽，智能体最终也会给出正确答案。可在生产环境中，这五个步骤分别耗时 12 毫秒、800 毫秒、4 秒、2 分钟和 6 小时。规划器从未察觉，它这五步计划在成本上跨越了九个数量级。
这并不是幻觉。模型选对了工具，顺序也合理。它做不到的——工具模式根本没给它做这件事的途径——是去推理：计划的最后一步在性质上和第一步完全不同。在规划器眼里，工具就是工具，计划图中每个节点的权重都是 1。
结构性的失败在于：规划模型在推理工具序列时，就像程序员推理伪代码一样——每一步都被视作"一个工作单元"。只要序列在逻辑上有效，计划就被认为是正确的。至于这个序列是否"负担得起"，规划器根本不知道该问，因为它看到的输入——工具目录——是一种被剥去价签的词汇表。函数签名暴露了类型，却没有暴露延迟层级、金钱成本、影响半径，也没有暴露这一步是否会让工作流挂起等待人类。
不同工具属于完全不同的成本量级
感受这道鸿沟最直接的方式，是按照规划器可能输出的顺序，把常见智能体工具的实际延迟下限列出来：
内存查找或缓存命中：亚毫秒级。
针对索引键的本地数据库查询：数十毫秒。
中等规模语料上的向量搜索或全文搜索：数百毫秒。
调用第三方服务的外部 HTTP API：几秒，长尾可达几十秒。
调用一个本身会运行多步计划的子智能体：数十秒到数分钟。
需要人工审批的工作流：无界，仅由 SLA 兜底。
其中最便宜与最昂贵之间的比例大约是九个数量级。把这些层级混在同一个步骤图里的计划，根本无从"优化"，因为计划层级的成本由其中最差的那一层主导。一个由四个亚毫秒工具加一个人工审批步骤组成的计划，其尾延迟就等于那一步人工审批。其余四步在成本意义上是"免费"的。
而规划模型完全得不到这些信息。当它读取工具目录时，每个条目看起来都是一段 JSON Schema 片段——name、description、参数列表。模型靠把描述与意图匹配来选工具。标准模式里没有"这次调用通常要 4 秒"这种字段，也没有"这次调用可能挂起数小时"这种字段。智能体的词汇表是一个扁平的命名空间。
智能体计划里的"成本"到底意味着什么
团队第一次遇到这个问题时，往往会去看 token 成本。Token 容易测量、容易计费、容易在仪表盘上呈现。但 token 成本是错的框架，因为智能体计划中最昂贵的部分往往是消耗零 token 的部分——为等一笔付款人工审核而挂起的工作流、为等下游批处理完成而进行的长轮询、为应对不稳定外部供应商而陷入的重试循环。
更诚实的智能体成本分解至少要有四个维度：
延迟 ：调用返回所需时间，包括 p99 长尾。这是终端用户能感知到的部分。金钱 ：这次调用本身的美元成本，包括下游 API 费用、算力，以及为推理这次调用所花的 token。影响半径 ：这次调用对世界造成了哪些不可逆变化。一次退款比一次读取昂贵得多。可逆性 ：如果计划被证明是错的，这次调用能否撤销。可以回滚的数据库写入比一封发出去就收不回来的邮件便宜。
一个只数 token 的计划成本评分，会稳定地把"检索知识库然后给用户发邮件"评为大致等同于"检索知识库然后把备忘写进草稿文件夹"。它们并不等价。第二个计划是可逆的，第一个不是。规划器看不到这个区别。
最近的研究开始把这一点形式化——比如 CostBench 这类工作就专门评估：当存在多条工具路径时，模型是否会挑出成本最优的方案。结论令人沮丧：即便是强势的前沿模型，也常常无法识别"最便宜的正确计划"，在最难的样本上完全匹配率远低于 75%。模型能完成任务，但无法稳定地用便宜的方式完成任务。
弥合这道鸿沟的几种模式 修复并不在模型层。它在工具目录层。目录是规划器的输入；规划器的成本感知能力上限，就是目录所能允许的上限。下面几种模式组合起来，可以让规划在不重新训练模型的前提下变得对成本敏感。
第一种是在工具模式中加入层级标签 。每个工具被赋予一个数量级标签——sub-second、seconds、minutes、hours、human——作为模型与描述一起读到的顶级字段。当类别是显式的时候，模型的分类推理能力很强。告诉它 request_human_approval 属于 human 层级、lookup_user 属于 sub-second 层级，就足以改变它在两者都能解决问题时的选择。
第二种是把计划成本评分作为规划时的约束 。在规划器确定一个序列之前，让它先估算自己刚刚输出的计划的总成本。这听起来空洞，但实践中有效，因为它强迫模型把层级注解合成一个数字，从而暴露出模型本来会含糊带过的不匹配。当用户问的是"我的订单状态怎样"、而计划返回的估算成本是"分钟级 + 人工"时，错得显而易见，规划器往往会主动修正。
第三种是在框架层做层级过滤 。框架拒绝让规划器在没有升级到用户或上层监督模型的情况下，跨越超过两个层级地组合工具。如果规划器想把 sub-second 查找与 human 审批拼在一起，框架会暂停并询问："这个计划会阻塞不确定的时长，你确定要这样吗？"重点不是拒绝昂贵的计划——它们常常是正确的——而是在做决定的瞬间让成本跨度可见，而不是在收到账单的瞬间才暴露。
第四种是成本感知的推理提示 。规划提示要求模型在确定之前显式地推理成本。"在选择工具之前，请考虑是否有更便宜的工具足以胜任。"这是投入最少的干预，也是大多数团队跳过的一项——他们以为模型"应该懂"。其实它不懂。规划器挑的是描述上听起来最相关的工具；它对节俭没有任何原生压力。
评测里没人抓到的失效模式 绝大多数智能体评测套件都在给"答案质量"打分。智能体答对了吗？任务完成了吗？这些是必要的，但远远不够。一个本可以用一分钱的计划完成任务、却用十美元计划答对的模型，并不是你想部署的模型。
能抓到这种失败的评测纪律是：构造一类对抗性案例，其中存在多条正确但价位不同的工具路径。智能体不仅要被打"是否完成了任务"，还要被打"所选计划的成本相对于最便宜正确计划的比例"。这是智能体评估领域才刚开始认真对待的指标。计划成本（cost-of-plan）、计划最优比（plan-optimality ratio）、层级超额次数（tier-overshoot count）——正是这类指标，才能暴露模型默默偏好"听起来最相关的工具"而不是"最便宜的正确工具"。
让任何部署规划智能体的人都该警觉的失效场景是：评测一片绿、模型选的工具都正确、答案质量很高，而每月账单是架构预测值的三倍。这个差距不是 bug，而是没被测量的成本维度在生产流量中显现的超额。
架构层的领悟 更深的一点关于工具目录"是什么"。工具目录通常被定义为注册表——一个声明智能体能力的地方。但从模型的视角看，目录是一种词汇表 。模型读它的方式就像读自己的语法：一组带有"如何使用"注解的有限动词。如果词汇表没有编码成本，规划器就没有办法表达对成本敏感的偏好，即便这种偏好其实存在于它的训练分布中。
这不是模型能力问题，而是模式设计问题。同一个在扁平工具目录上 CostBench 失败的模型，给它一个分层的目录，就会挑出成本最优的计划，因为分层改变了模型能"看到"的东西。一个输出"优雅"的五步计划、实际成本却跨九个数量级的规划器，是被要求在一个成本函数不可见的世界里规划的规划器。
发布一个没有层级注解的智能体，团队不仅是在丢钱。他们是在搭建一个计划在轨迹里看起来都对、成本却每月都让所有人惊讶的系统。轨迹是干净的，账单不是。修复点在模型的上游：在让规划器读到工具目录之前，先给目录里的每个工具打上成本层级标签——然后规划器，不需要重新训练，也不需要花哨的提示工程，就会开始像一个懂"东西值多少钱"的工程师那样规划。
没有成本层级的工具目录是伪代码。带有成本层级的工具目录是一份预算。规划器的工作就是在预算内规划。给它一份预算。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
