[程序员] 多步骤 MCP 的 token 损耗，可能主要来自每一步的模型重入

事件核心：发生了什么

Tura-AI 在 V2EX 分享了一套针对 MCP（Model Context Protocol）工作流的优化思路，核心产品是 Tura 的 command_runMacro 功能。常见 MCP 演示通常只有一次工具调用，但真实项目往往要连续执行“创建项目 → 获取 ID → 导入素材 → 导出 → 交付”等多步操作。普通 agent 每完成一步都要把结果带回模型，由模型决定下一步参数，形成一次“模型重入”。

Tura 的做法是让用户一次描述完整依赖图：前一步成功产生的变量，直接在运行时解析给后续步骤，无依赖的命令则并行执行。公开的电商广告工作流基准显示，Tura Direct 只用 3 次模型请求，对照流程是 11 次；总 token 为 56,372 对 262,915。值得注意的是，MCP 调用次数反而是 11 对 9——优化节省的是反复回传上下文的开销，而不是减少实际操作。

帖子还引用了 mini-swe-agent 的对比：在 debug 场景下，该开源 harness 的 token 消耗比 codex 和 Claude Code 低约 50%，成功率高出约 15%。相关代码和完整 trace 已公开在 GitHub 和 Tura 官方博客上。

为什么重要

当前 AI agent 的主流架构有一个隐性瓶颈：每一步工具调用结果都要拼进对话上下文，再送进模型重新推理。任务链条越长，累计上下文越大，重复计费越严重。Tura 的测试数据说明，通过显式的依赖关系描述，可以让变量在运行时直接传递，减少模型反复“阅读”无关历史。这个思路对 agent 框架设计有直接参考价值——它提示改进方向不一定在模型本身，也可以在执行引擎和上下文管理层面。

这也呼应了 mini-swe-agent 的结果：同样的模型，换一套执行 harness 就能明显改变 token 消耗和成功率。对于正在构建 agent 产品的团队而言，这意味在切换更大模型之前，先优化“每次调用带回什么、怎么带”可能是一个更划算的杠杆。

对用户/开发者/创作者的影响

对开发者：如果你正在用 MCP 搭建多步自动化工作流，可以关注任务中哪些变量需要跨步骤传递，试着用依赖图而不是“让模型自己记”的方式组织流程。Tura 的开源实现（github.com/Tura-AI/tura）提供了一个可直接测试的参考。

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

对企业采购/技术选型：token 费用在大规模 agent 落地中是实打实的运营成本。Tura 基准显示，同一工作流在相近产出下 token 差出 4 倍以上，意味着“哪家 agent 框架更省 token”应该成为选型的重要指标，而不只是关注模型本身的定价。

对关注 AI 效率的普通用户：目前公开信息显示，这种优化对依赖链较长的任务收益更明显；但缓存、重试、任务是否线性都会影响最终结果，不是所有场景都能直接套用 78.6% 的节省比例。

值得关注的后续

一，Tura 的 command_runMacro 是否会被更多 MCP 生态工具采用，或出现类似的“上下文交接”标准；二，基准是否扩展到 debug 等非线性任务——mini-swe-agent 的数据已经在暗示，不同任务结构下 harness 的收益差异很大；三，OpenAI、Anthropic 等官方 agent harness 是否会跟进这种变量继承与依赖图设计，毕竟各家的闭源框架也在持续优化上下文开销。

来源：V2EX (创意工作者社区)