直接摆一组数据，看看 CLI+SKILL 方案对比 MCP 的实际表现。结果很清晰：工具调用次数更少、Token 浪费更少、错误恢复路径更短。这篇文章就来拆解，这些数字背后到底藏着什么。

核心问题

一个很直接的问题：那些听起来很美的理念和设计原则，放到实际任务里，真的能抗住压力吗？

答案是肯定的。但光说不练假把式。我们在内部挑了几个典型的用户任务，把 MCP 和 CLI+SKILL 两种方案放在一起，做了个对照实验。

实验任务概览

任务类型	描述
添加测试用例 + 验证	为某个 Endpoint 创建测试用例，并执行验证
维护测试场景	更新一个复杂的、涉及多步骤的测试场景
导入/验证项目资产	导入数据、确认结构无误，然后跑一遍测试

结果抠出来的，不只是“感觉上好一点”。而是实实在在、可以量化的改进。

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

用户给模型下的指令很简单：

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

来看看两种方案，模型内部各自走了什么样的路。

MCP 路径

阶段	发生过程
工具发现	Agent 在一堆工具列表里大海捞针
工具选择	反复挑选，判断哪个工具才是对的
字段发现	Agent 开始阅读工具自带的 Schema 描述
字段猜测	Agent 凭“经验”猜测需要填什么字段
写入尝试	调用创建工具，试图写入数据
错误响应	服务器拒绝请求。字段写错了，或者缺了必填项
重试	Agent 根据错误提示，调整参数再试
更多重试	反复重复“猜-错-改-错”的死循环，直到成功
运行测试	终于成功了，再找到运行测试的工具来执行

典型的行动路径：

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

CLI + SKILL 路径

阶段	发生过程
SKILL 引导	SKILL 识别任务类型，直接给出工作流
读取接口	CLI 读取接口的“事实”（fact）数据
生成测试用例	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 不知道 API 里字段的确切名称
猜测枚举值	Agent 只能靠猜。比如 comparator 该填什么、type 该填什么
写入尝试	服务器拒绝，因为值不对
网络重试	每次错误都是一次完整的网络往返
多次尝试	通常需要 3-5 次重试才能搞定

常见场景：

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

每一次错误 = 一次网络往返 + 处理错误响应 + Agent 消耗时间去分析重试。

CLI + SKILL 路径

阶段	发生过程
SKILL 引导 (同上)	SKILL 给出结构化写入的工作流
读取接口 (同上)	CLI 读取接口事实数据
生成结构 (同上)	Agent 基于真实数据生成
本地校验	CLI 的 Schema 在本地完成所有校验，拦截错误
写入 (同上)	CLI 一次性写入
回读 + 运行 (同上)	CLI 返回结构并建议下一个步骤

所有因字段猜测导致的错误，都被拦截在本地。没有一次不必要的网络重试。

结果

指标	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%

其中，因为结构化错误（比如填错 comparator）导致的无效重试，减少了大约 40%。

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

再看一个更贴近真实场景的指令：

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

MCP 路径

阶段	发生过程
创建场景	Agent 调用创建工具，成功了
成功响应	Agent 看到“创建成功”的提示
继续写入	Agent 惯性动作，立刻开始写下一批内容
跳过回读	Agent 没有去读取刚刚创建成功的实际结构
基于假设写入	Agent 靠“猜测”出来的 ID 和结构继续往里写
错误或不完整	结果自然不符合预期

问题的根源在于“执行惯性”。模型在成功响应后，倾向于埋头继续干，而跳过“回读”这个关键步骤。

CLI + SKILL 路径

阶段	发生过程
创建场景	与 MCP 类似
成功响应	与 MCP 类似
继续写入 (但…)	Agent 正准备惯性下笔
agentHints 介入	agentHints 明确建议“先回读再写入”
遵循建议后写入	Agent 遵循建议，先回读真实数据，再基于事实写入

关键在于 agentHints 明确给出了回读的建议。模型遵循了它。

结果

指标	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 调用的能力。而是在上下文、注意力、路径选择和用户成本之间的一系列权衡。

工程原则

目标很明确：

把这些成本从模型的上下文中剥离出来，交给更可靠的工程系统去承担。

成本	MCP 位置	CLI + SKILL 位置
工具发现	模型必须自己搜索	SKILL 直接提供
字段校验	模型必须自己知晓规则	cli-schema 负责校验
下一步引导	模型必须自己决策	agentHints 主动提供建议
产品语义	模型必须自己理解	CLI 负责处理底层逻辑

工程系统吸收了绝大部分复杂性。模型则被解放出来，专注于它最擅长的“生成”和“判断”。

这些数字意味着什么

这些数据解释了一个更具体的问题：

洞察	启示
工具调用减少 30%	复杂性从“模型自己去发现”转移到了“系统为你引导”
浪费的 Token 减少 25%	错误在联网之前就被拦截了
结构化重试减少 40%	本地校验关卡发挥了关键作用
跳转错误减少 21%	agentHints 阻止了盲目的后续操作

可以肯定地说，CLI + SKILL 方案带来的不仅仅是架构上的优雅。它转化为的是实实在在、可测量的效率提升。

下一步

既然数据已经验证了这条路径的可行性，接下来就该看看它具体的落地样子了。

在下一部分《从 PRD 到测试闭环：完整的 Agent 工作流》中，我们会用一个真实的场景来演示：

团队拿到一个关于“订单退款”的 PRD，Agent 如何利用 CLI + SKILL 方案，一气呵成地生成 OpenAPI、创建测试用例、进行校验并验证结果。

关键要点

• 工具调用步骤减少了约 30%
• 来自描述和重试的 Token 浪费减少了约 25%
• 结构化错误重试减少了约 40%
• 因跳过回读导致的跳转错误减少了约 21%
• 节省的来源是：引导式发现、本地校验、可操作的建议
• 复杂性从模型的上下文转移到了工程系统