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 还提供了深度定制的私有化部署方案。
获取专属报价与部署方案
详细的私有化部署系统架构与安全白皮书
针对您公司规模的专属报价单
免费的 1v1 专属产品演示 (Demo) 机会
