让我们用一组真实数据来直面问题：在实际业务场景中，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%
- 节省的来源是：引导式发现、本地校验、可操作的建议
- 复杂性从模型的上下文转移到了工程系统
