让API工具同时服务编辑器、CI和代理

HTTP Forge 已经有 VS Code 扩展，作者却又做了一个 CLI，原因很直接：编辑器适合查看响应、调试请求，但 CI、Shell 脚本和 AI agent 需要能直接执行的入口。他的结论是，开发者工具应该尽早拥有 CLI，同时让不同入口共用执行引擎。

这篇值得看的，是它对三种入口的分工：扩展负责交互查看，CLI 负责自动执行，MCP 负责需要结构约束的操作。不过，「更省 token」和「结果可复现」都有适用前提，不能只凭接口形式下结论。

同一个引擎，为什么还需要三个入口

HTTP Forge 的 CLI 不是重新实现一遍扩展功能，而是给共享核心 @http-forge/core 加了一层薄适配。VS Code 扩展、CLI、MCP server 都调用这个核心，由它处理执行、请求集合、测试套件和发现能力。

这样做首先减少了行为分叉。执行器修好一个问题，三个入口都能受益；本地和 CI 也不必分别维护执行逻辑。其次，CLI 直接读取同一套工作区文件，不需要另存一份「CI 专用格式」。集合、环境、断言、报告这些概念也保持一致。

多个入口可以有不同交互方式，但测试行为应该由同一个核心决定。

作者也给 CLI 划了边界：不做终端交互界面（TUI），没有菜单和交互浏览器；不部署服务，不创建环境；命令全部委托给共享引擎。需要直观地检查响应，仍然打开扩展。

这里真正值得借鉴的是架构约束。业务能力一旦藏进按钮回调，后续做自动化就得拆出来重写。先保证核心能在没有界面的情况下运行，其他入口才容易复用。

CI 需要的是退出码和报告

作者最初的实际需求，是每次 pull request 都运行测试套件。构建服务器没有编辑器和显示界面，也不能等待交互确认，因此执行结果必须能被程序直接判断。

下面这条命令运行 staging 环境的冒烟测试，并写出 JUnit XML：

http-forge run suite "smoke-tests" \
  --environment staging \
  --reporter junit:results/junit.xml \
  --exit-code

要留意最后一行 --exit-code：按作者说明，全部通过时返回 0，断言失败时返回 1。junit:results/junit.xml 则用于接入 GitHub Actions、GitLab、Jenkins、Azure DevOps 的报告流程。

CLI 的另一个优势是组合。加上 --output json 后，可以接 jq '.failedRequests[].name' 提取失败请求名称。只检查认证模块时，可以执行 http-forge run folder "Auth" --collection "My API" --output json，再接 jq -e '.allPassed == true' 判断结果。

跨环境运行也能交给 Shell：用 for env in dev staging production; do 遍历环境，把 --environment "$env" --exit-code 传给命令，再用 || exit 1 在失败时终止。

这些做法把测试结果接进了现成的脚本体系。作者认为，相比 Newman 或自定义脚本，共享引擎减少了第二套运行时、参数和行为差异。但它只能减少执行逻辑不一致，网络、凭据、依赖服务造成的差异仍然存在。

AI 执行走 CLI，修改走 MCP

作者对 AI agent 的建议是：执行测试用 CLI，修改状态用 MCP。

他的理由是，MCP 工具通常需要向模型提供名称、描述和 JSON schema，工具越多，上下文开销越大。而已有终端权限的 agent，可以直接执行命令，拿到精简结果。

例如，下面这条命令展示了运行集合并获取 JSON 的调用方式：

http-forge run collection "My API" --environment staging --include failedOnly --output json

要留意 --include failedOnly。原文没有解释它的准确筛选语义，不能仅凭名字认定它表示「只重跑上次失败的请求」。

对于「跑一下测试，告诉我哪里失败」这样的任务，CLI 的路径确实直接。但创建请求、编辑套件节点、选择环境、修复断言时，作者更倾向于 MCP，因为经过校验的结构化参数更适合修改操作。

复杂排查也有区别。MCP 的 explain_failure 会在一个结构化结果中返回请求、响应、断言结果和诊断；CLI 路径则需要执行命令并解析 JSON。此时，调用短不代表整个排查过程更短。

CLI 还承担了功能发现入口。http-forge discover --path ./backend --output table 用于发现能力；http-forge generate-suite --path ./backend --collection "My API" --dry-run 用于预览套件生成；http-forge drift --path ./backend 检查漂移；http-forge qa --path ./backend --base-url http://localhost:3000 执行 QA gate。原文没有展开漂移检查和 QA gate 的具体判定规则。

我的判断

我赞同共享核心和入口分工。对已经维护请求集合的团队，直接让 CI 读取同一工作区，比再维护一份导出产物更容易控制差异。

但「CLI 最省 token」目前只是作者的经验判断。原文没有给出工具数量、模型、上下文长度或任务完成率的对照数据。MCP schema 是否每轮完整进入上下文，也取决于客户端如何加载工具。比较时应看完整任务的消耗，包括命令帮助、错误重试和输出解析。

本地优先同样需要拆开看。作者称 CLI 不回传数据、不要求登录、不启动后台服务，也没有按席位或运行次数收费。这些特性有利于受限网络使用，但 API 测试能否运行，还取决于目标服务是否可达。

「相同二进制和工作区产生相同结果」也有条件：环境变量、测试数据和外部服务状态都会影响结果。原文没有提供可复现性验证。

与 Newman 或自定义脚本相比，共享引擎的价值取决于现有资产。如果团队已经稳定运行另一套流程，仅凭架构更统一，还不足以证明迁移划算。

能拿来做什么

• 如果已有 HTTP Forge 集合，可以先用 npm install -g @http-forge/cli 安装，再通过 http-forge launch --examples 克隆示例工作区并打开 VS Code，确认集合、环境和报告的使用方式。
• 给 Node 后端接入 CI 时，可以从一个冒烟套件开始，启用 --exit-code 和 JUnit 报告，验证失败断言确实能让流水线失败。
• 为 AI 编程助手设计流程时，可以尝试让 CLI 承担测试执行，让 MCP 承担结构化修改，并记录完整任务的 token 消耗和重试次数，检验这种分工是否适合自己的工具链。
• 自己开发调试工具或测试平台时，可以先把执行、配置读取和结果输出做成无界面核心，再接编辑器和 CLI，减少后续接入自动化时的重复实现。