AI Agent的浪费从何而来：模型调用还是编排层？

被忽视的问题：不是"调用了什么"，而是"为什么调用"

随着AI Agent在生产环境中的大规模落地，可观测性（observability）成了绕不开的话题。市面上大多数工具都能告诉你一个Agent调用了哪些接口、消耗了多少token、花了多少钱。但一位Reddit开发者在深入研究后提出了一个更尖锐的问题：这些调用究竟为什么会发生？

这位开发者在AUDR发布后开始关注这一领域，并构建了一个名为 KORA Doctor 的开源CLI工具，专门用于检查Agent的执行轨迹（traces）。他的核心观点是：当前的Agent可观测性仍然停留在"结果层"，缺乏对"动机层"的洞察。知道花了多少钱是一回事，知道这笔钱为什么被花掉、能不能省掉，是完全不同的另一回事。

可观测性（observability）一词源自控制理论，在软件工程中指通过系统的外部输出来推断其内部状态的能力。传统的应用监控（monitoring）侧重于预定义的指标和告警，而可观测性则强调在未知故障场景下的"事后追因"能力，通常依赖三类数据支柱：日志（logs）、指标（metrics）和分布式追踪（traces）。在AI Agent语境下，traces尤为关键——它记录了一次完整Agent运行中每个步骤的调用链、耗时与上下文，是还原"Agent到底在做什么"的主要手段。当前大多数Agent可观测性工具（如LangSmith、Langfuse等）已能较好地捕获traces数据，但正如本文所指出的，捕获"发生了什么"与理解"为什么发生"之间，仍存在相当大的分析鸿沟。

KORA Doctor 盯住的几类典型浪费

这个开源工具目前聚焦于几类在真实Agent运行中反复出现的浪费模式：

• 重复的模型调用：同样的推理被反复触发，没有缓存或复用机制
• 缓存与复用缺失：本可命中缓存的请求却重新走了一遍完整流程
• 确定性工作被交给LLM：一些可以用规则或代码直接完成的任务，却动用了大模型
• 大材小用：用昂贵的高端模型去处理极其简单的任务
• 过度的规划与编排：planning和orchestration环节本身消耗了大量资源

这些模式的共同点在于，它们并不总是出现在"模型调用"这个最显眼的环节。很多浪费其实隐藏在Agent运行流程的更深处。

来自生产环境的关键反馈：浪费始于模型调用之前

真正改变作者思路的，是一条来自生产环境用户的反馈。这位在生产环境中运行Agent的用户表示，他们最大的浪费来源并不是重复推理，而是在多个步骤中反复抓取同样的工具数据（re-fetching the same tool data）。

这个发现的意义在于：浪费可以在模型调用发生之前就已经产生。编排层（orchestration layer）会制造出不必要的检索（retrieval）、工具调用（tool calls）和重试（retries），而这些冗余操作之上还会再叠加一层推理成本。换句话说，一次不必要的工具调用，可能会连锁触发后续一整串的检索与推理开销。

这就把问题从单纯的"LLM成本优化"推向了一个更广的维度——整个Agent运行过程中的执行浪费（execution waste）。

编排层（orchestration layer）是AI Agent架构的核心组件，负责协调多个子任务的执行顺序、决定何时调用哪个工具、如何处理中间结果以及何时终止循环。常见的编排框架包括LangChain、LlamaIndex、AutoGen等。由于编排逻辑通常以代码形式存在，而非直接是LLM的输出，传统的token计量工具对这一层的开销几乎是"盲区"。工具数据的重复抓取问题尤为典型：当Agent在多步推理过程中没有对中间结果进行缓存，每一步都会重新发起相同的API请求或数据库查询，这些调用本身不消耗token，却会产生真实的延迟成本、API费用和下游的推理冗余。这一层面的浪费只有通过完整的执行轨迹分析才能被识别。

从"模型成本"到"执行成本"的视角转变

长期以来，Agent成本优化的讨论往往默认等同于"降低token消耗"或"换用更便宜的模型"。但这位开发者的实践表明，这种视角可能抓错了重点。

真正的浪费地图应该覆盖整个执行链条，至少包括以下几个潜在源头：

模型调用（Model calls）

直接的推理成本，最容易被监控，也最容易被当作唯一的优化目标。

工具调用与检索（Tool calls & Retrieval）

这是生产用户反馈中最隐蔽也最昂贵的一类。重复抓取相同数据、冗余的检索请求，往往在不知不觉中累积成巨大开销。

重试与验证（Retries & Validation）

失败重试、反复的结果校验，都会在不增加实质价值的前提下成倍放大资源消耗。

规划循环（Planning loops）

当Agent陷入过度规划或低效的编排循环时，大量算力被消耗在"决定下一步做什么"上，而非真正完成任务。

这种从"模型成本"到"执行成本"的视角转变，意味着Agent的优化需要一个能够还原完整执行轨迹的工具，而不仅仅是一个token计数器。

对生产环境开发者的启示

作者明确表示，KORA Doctor 的构建方向正是围绕"真实轨迹中实际出现的问题"展开的，因此他特别希望征集来自生产环境的真实案例。他抛出的问题也很值得每一个运行Agent的团队自问：你的浪费主要来自哪里——模型调用、工具调用、重试、检索、规划循环，还是重复验证？

对于正在生产环境中部署Agent的团队，这个讨论至少带来两点可操作的思考：

第一，不要把成本优化简单等同于换模型或压缩prompt。如果浪费的根源在编排层，那么再便宜的模型也只是在为冗余流程买单。

第二，可观测性工具的价值在于追因，而非仅仅记账。能回答"这次调用为什么发生"的工具，才能真正指导优化决策。

随着Agent架构日益复杂，编排层正逐渐成为性能与成本的隐性瓶颈。KORA Doctor 这类开源工具的出现，代表了一种值得关注的趋势：把Agent的可观测性从结果层下沉到执行逻辑层。

相关项目地址：AUDR（https://openaudr.dev/）与 KORA Doctor（https://github.com/Krako-Labs/kora-doctor）。