Agent 效能实测:减少 30% 的工具调用与 25% 的 Token 消耗

时间:2026-07-25 08:48:48 来源:互联网

通过对比MCP与CLI+SKILL在典型用户任务中的表现,数据揭示了后者在工具调用、Token消耗及错误恢复方面的显著优势,本文将深入分析其具体差异。

核心问题

我们分享的所有理念和设计原则是否真的有效?

我们在内部针对两种方案对比了许多典型的用户任务:

任务类型 描述
添加测试用例 + 验证 为 Endpoint 创建测试用例并运行测试
维护测试场景 更新复杂的多步骤场景
导入/验证项目资产 导入数据、确认结构并运行测试

结果不仅仅是主观上的改进,而是可衡量的减少。

任务 1:基于 Endpoint 添加测试用例

用户请求:

"为这个接口添加一个测试并运行验证"

MCP 路径

阶段 发生过程
工具发现 Agent 在工具列表中搜索
工具选择 多轮选择正确的工具
字段发现 Agent 阅读工具的 schema
字段猜测 Agent 猜测必填字段
写入尝试 Agent 调用创建工具
错误响应 服务器拒绝(字段错误/缺失必填项)
重试 Agent 调整后再次尝试
更多重试 重复直到成功
运行测试 Agent 找到运行工具并执行

典型模式:

搜索工具 → 选择工具 → 阅读 schema → 猜测字段 → 写入 → 错误 → 重试 → 写入 → 错误 → 重试 → 成功 → 寻找运行工具 → 运行

CLI + SKILL 路径

阶段 发生过程
SKILL 引导 SKILL 识别任务类型,提供工作流
读取接口 CLI 读取接口事实(facts)
生成测试用例 Agent 根据实际接口数据生成
本地校验 cli-schema 在写入前进行校验
写入 CLI 创建测试用例
回读 CLI 返回创建的结构 + agentHints
运行测试 agentHints 建议运行,Agent 遵循建议

典型模式:

SKILL 引导 → 读取接口 → 生成 → 校验 → 写入 → 回读 → 运行

结果

指标 MCP 路径 CLI + SKILL 提升
工具调用步骤 ~15-20 ~10-12 ↓ ~30%
来自描述的 Token 加载约 50,000 加载约 2,000 ↓ ~96%
来自重试的 Token 约 5,000+ 浪费 约 500 浪费 ↓ ~90%
总 Token 浪费 ~55,000 ~2,500 ↓ ~25%

工具调用步骤减少了约 30%。由于无效工具描述和错误重试导致的 Token 消耗减少了约 25%。

任务 2:结构化写入(处理器、断言、提取器)

用户请求:

"为此测试用例添加后置操作断言和变量提取"

MCP 路径

阶段 发生过程
猜测字段名 Agent 不知道确切的名称
猜测枚举值 Agent 猜测 comparator、type
写入尝试 服务器拒绝错误的值
网络重试 每次错误都需要一次往返
多次尝试 通常需要 3-5 次重试

常见错误:

错误猜测 正确值 重试次数
comparator: "contains" comparator: "include" 1-2
type: "global" type: "globals" 1-2
subject: "responseBody" subject: "responseJson" 1-2

每次错误 = 1 次网络往返 + 响应 + Agent 处理。

CLI + SKILL 路径

阶段 发生过程
SKILL 引导 SKILL 识别任务类型,提供工作流
读取接口 CLI 读取接口事实(facts)
生成测试用例 Agent 根据实际接口数据生成
本地校验 cli-schema 在写入前进行校验
写入 CLI 创建测试用例
回读 CLI 返回创建的结构 + agentHints
运行测试 agentHints 建议运行,Agent 遵循建议

所有错误都在本地拦截。没有因字段错误导致的网络重试。

结果

指标 MCP 路径 CLI + SKILL 提升
工具调用步骤 ~15-20 ~10-12 ↓ ~30%
来自描述的 Token 加载约 50,000 加载约 2,000 ↓ ~96%
来自重试的 Token 约 5,000+ 浪费 约 500 浪费 ↓ ~90%
总 Token 浪费 ~55,000 ~2,500 ↓ ~25%

由结构化错误导致的重复调用减少了约 40%。

任务 3:创建后的连续操作

用户请求:

"使用这些接口创建一个测试场景"

MCP 路径

阶段 发生过程
创建场景 Agent 调用创建工具
成功响应 Agent 看到 "created"
继续写入 Agent 立即更新/添加更多内容
跳过回读 Agent 不读取实际结构
基于假设写入 Agent 使用猜测的 ID/结构进行写入
错误或不完整 结果不符合预期

问题:执行惯性。

模型倾向于在成功后直接继续,跳过回读(read-back)步骤。

CLI + SKILL 路径

阶段 发生过程
创建场景 Agent 调用创建工具
成功响应 Agent 看到 "created"
继续写入 Agent 立即更新/添加更多内容
跳过回读 Agent 不读取实际结构
基于假设写入 Agent 使用猜测的 ID/结构进行写入
错误或不完整 结果不符合预期
agentHints 明确建议回读。Agent 遵循了该建议。

结果

指标 MCP 路径 CLI + SKILL 提升
继续操作前主动回读的比例 ~20% ~85% ↑ ~425%
直接跳转导致的错误重试 ~3-5 ~0-1 ↓ ~21%

Agent 主动回读、校验并运行验证的比例显著增加。由于直接跳转到下一步导致的错误重试减少了约 21%。

总结:节省来自哪里

节省来源 说明
工具发现 CLI 命令有清晰的名称;SKILL 引导选择
Schema 校验 本地校验在网络调用前拦截错误
错误恢复 agentHints 提供可操作的建议,而不仅仅是 "失败"
回读引导 防止基于假设的写入
工作流顺序 SKILL 减少了决策点

真实的成本分析

核心洞察:

产品对 Agent 的赋能并非工具越多越好。

模型真正消耗的是:

成本类型 MCP 负担 CLI + SKILL 负担
上下文 (Context) 工具描述、Schemas 仅限任务相关的 SKILL
注意力 (Attention) 在众多工具中选择 遵循引导式工作流
路径选择 猜测执行序列 SKILL 定义的序列
用户 Token 成本 重试、失败的调用 经过校验的写入、更少的调用

当工具数量增加后,模型真正消耗的不再是 API 调用能力,而是在上下文、注意力、路径选择和用户 Token 成本之间的权衡。

工程原则

目标:

将这些成本从模型上下文中移出,转交给工程系统承担。
成本 MCP 位置 CLI + SKILL 位置
工具发现 模型必须搜索 SKILL 直接提供
字段校验 模型必须知晓 cli-schema 进行校验
下一步引导 模型必须决策 agentHints 提供建议
产品语义 模型必须理解 CLI 负责处理

工程系统吸收了复杂性。模型则专注于生成和判断。

这些数字意味着什么

这些数字解释了一个更具体的问题:

洞察 启示
工具调用减少 30% 复杂性从“发现”转移到了“引导”
浪费的 Token 减少 25% 错误在联网前被拦截
结构化重试减少 40% 校验关卡发挥了作用
跳转错误减少 21% agentHints 防止了盲目后续操作

CLI + SKILL 不仅仅是架构上的优雅,它带来了可衡量的效率提升。

下一步

既然我们已经用数据验证了这一方案,让我们看看它的实际应用。

在第 7 部分 《从 PRD 到测试闭环:完整的 Agent 工作流》 中,我们将通过一个真实的例子——团队有一个“订单退款”的 PRD,Agent 如何使用 CLI + SKILL 生成 OpenAPI、创建测试、校验并验证。

关键要点

  1. 工具调用步骤减少了约 30%
  2. 来自描述和重试的 Token 浪费减少了约 25%
  3. 结构化错误重试减少了约 40%
  4. 因跳过回读导致的跳转错误减少了约 21%
  5. 节省源于:引导式发现、本地校验、可操作的提示
  6. 复杂性从上下文转移到了工程系统

综上所述,CLI+SKILL方案通过引导式发现、本地校验和可操作提示,将复杂性从模型转移至工程系统,显著提升了效率,这些数据充分验证了其设计原则的有效性。