v我们在典型用户任务中对比了 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、创建测试、校验并验证。

关键要点

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

下载 Apifox，在一个工作区内完成 API 的 设计、Mock、测试 和 文档。了解更多关于 Apifox CLI 的信息，助力命令行 API 测试、CI 自动化和 AI Agent 工作流。

开发必备：API 全流程管理神器 Apifox

介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。

如果你正在开发项目，不妨试试其极其友好的界面设计，它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。

值得一提的是，除了个人和常规团队使用，针对有高安全合规要求、或需要在内网环境协作的企业，Apifox 还提供了深度定制的私有化部署方案。