把每个工具都当作 O(1) 的规划器

你的规划器输出了五次工具调用。从纸面上看，这是一个干净的解决方案：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。
• 影响半径：这次调用对世界造成了哪些不可逆变化。一次退款比一次读取昂贵得多。
• 可逆性：如果计划被证明是错的，这次调用能否撤销。可以回滚的数据库写入比一封发出去就收不回来的邮件便宜。

加载中…