当前位置：首页 > news >正文

为何 CLI 是 Harness 工程的最佳载具？

news 2026/4/23 17:36:05

为何 CLI 是 Harness 工程的最佳载具？

一个争论的本质误读

Reddit 上有一个高赞帖子，一位使用 GitHub Copilot 四年的工程师在问：IDE 插件和 CLI 工具，到底哪个更好？

评论区里，一位西班牙语工程师拿到了最高赞：

“作为工程师，terminal 工具没有任何价值——那是 vibe coders 才用的东西。VSCode 里你可以控制一切，逐行 review、只接受部分改动、把 commit 作为上下文…… VSCode + Copilot > 任何终端工具。”

这个观点听起来有道理，但它偷换了一个概念。

把 CLI 工具打上"vibe coding"的标签，本质上是把使用方式和工具架构混为一谈。用 IDE 插件一样可以不看代码乱接受，用 CLI 一样可以逐行审查每个 diff。真正的问题不是"谁更严谨"，而是：哪种载具，更适合承载 harness 工程的复杂性？

答案是 CLI。不是因为它更酷，而是因为它在架构上天然更优。

什么是 Harness 工程？

在讨论载具之前，需要先明确"harness 工程"是什么。

一个 AI coding 工具，核心价值不是"调了哪个模型"，而是模型和真实开发环境之间的那一层：

上下文管理：如何把大型代码库切片、索引、检索，让模型不在 token 窗口里迷失
工具调用编排：文件读写、终端执行、Git 操作、diff 合并的可靠链路
错误恢复机制：代码跑错了怎么自动回滚、重试、调整策略
多步任务规划：把"帮我重构这个模块"分解成可执行的子任务序列
外部工具集成：测试框架、lint 工具、CI 系统、自定义脚本的接入

这整套工程，就叫 harness。它决定了同一个模型在不同工具里表现天差地别的原因。

问题是：IDE 插件和 CLI，谁更适合承载这套工程？

IDE 插件的天花板：GUI 的架构诅咒

IDE 插件的本质是一个GUI 组件，它运行在 IDE 的进程沙箱里，通过 IDE 提供的扩展 API 与编辑器交互。

这个架构带来了几个根本限制：

1. 工具调用受限于 IDE 的权限边界

IDE 插件能做什么，完全取决于 IDE 开放了什么扩展 API。想集成一个自定义测试工具？要看 IDE 是否提供了对应的钩子。想在代码修改前自动运行 lint？要看 IDE 的扩展生命周期是否支持。想把 CI 的失败日志自动喂给模型？这在大多数插件架构里根本无法实现。

插件的上限，就是 IDE 扩展 API 的上限。

2. 自动化和编排无法实现

一位高级工程师在帖子里说出了 CLI 最关键的优势：

“CLI 工具更容易在上面构建自己的 harness。你怎么自动化一个 GUI 插件？CLI 只是一条终端命令。”

这句话触及了本质。GUI 是为人设计的，不是为程序设计的。你可以用一行 shell 命令驱动 CLI agent：

claude-code"分析 test/ 目录下所有失败的用例，找到共同根因，生成修复方案"

然后把这行命令嵌进 CI 流水线、Make target、cron job、Git hook——任何地方。

同样的事情，怎么用 IDE 插件实现？你需要打开 IDE，打开聊天窗口，手动输入，等待响应，手动 review，手动接受。每一步都需要人在场。

IDE 插件是交互工具，CLI 是可编程工具。这是本质差异。

3. IDE 绑定，限制了工具链的自由度

IntelliJ 的 Copilot 插件，几个月前才加上 Agent 模式。VS Code 的 Copilot 插件，某些功能比 CLI 版晚了将近一年。

更重要的是：你写 Rust 用 CLion，写 Python 用 PyCharm，写前端用 WebStorm，偶尔还要改一个 Vim 里的配置文件——你需要给每个 IDE 单独配置、单独维护插件。

CLI 没有这个问题。启动 Claude Code 或 Copilot CLI，它感知的是文件系统和 Git 仓库，不是你的编辑器。它是 IDE-agnostic 的。

CLI 的架构优势：为什么它天然适合 Harness

1. 进程即边界，隔离是默认能力

帖子里有一个评论代表了 CLI 最被低估的使用场景：

“我用 CLI 是因为可以在 Docker 容器里跑，让 agent 随便搞，不用担心把本机弄坏。”

把一个 AI agent 跑在隔离容器里，意味着：

它可以真正"放开手脚"执行命令，不用担心误删文件
多个 agent 实例可以并行跑，互不干扰
执行环境完全可控、可复现
结果可以通过标准 I/O 传递给下游

这在 IDE 插件架构里是完全不可能的。CLI 的进程模型，天然支持隔离、并行、自动化。

2. 标准 I/O：最强大的集成协议

Unix 哲学的核心是"做一件事，并做好；通过标准 I/O 与其他工具协作"。

CLI agent 遵循这个哲学：

# 让 agent 分析 git log，输出结果给下游处理gitlog--oneline-50|claude-code"从这些提交里找出可能引入 regression 的变更"|teeanalysis.md# 让 agent 的输出触发另一个 agentclaude-code"生成单元测试">tests.py&&codex"review 这些测试，找出边界条件遗漏"<tests.py

标准 I/O 是 40 年积累的集成协议，比任何 IDE 插件的扩展 API 都更稳定、更通用、更强大。

3. Harness 可以在 CLI 之上自由叠加

这是 CLI 作为载具最核心的优势：它是可编程的 agent 入口，上层建设的空间无限。

你可以在 Claude Code 或 Copilot CLI 之上构建：

# 自定义 harness 示例：# 1. 跑测试，捕获失败# 2. 把失败日志喂给 agent，生成修复方案# 3. 应用修复，重跑测试# 4. 循环直到通过或达到最大重试次数MAX_RETRIES=3foriin$(seq1$MAX_RETRIES);doTEST_OUTPUT=$(python-mpytest2>&1)ifecho"$TEST_OUTPUT"|grep-q"passed";thenbreak;fiecho"$TEST_OUTPUT"|claude-code"分析这些测试失败，生成最小化修复补丁"|gitapplydone

这段脚本实现了一个最简单的 agentic loop：测试→分析→修复→验证。

在 IDE 插件里，这需要写一个复杂的扩展，依赖 IDE 的 task runner API，可能还不支持循环执行。在 CLI 里，它就是 10 行 shell 脚本。

“但我需要 diff review”——这不是 CLI 的问题

IDE 派最有力的论点是：可视化 diff review 更安全，更容易发现问题。

这个论点成立，但它指向的不是"CLI vs IDE"，而是"headless agent vs review-in-loop agent"。

两者可以共存：

Copilot CLI支持直接在 VS Code 里展示 diff，CLI 执行，GUI review，两者结合
Claude Code可以在 VS Code terminal 里运行，diff 在编辑器侧边栏展示
OpenCode直接集成了 TUI（终端 UI），在终端里提供类 IDE 的 diff 体验

CLI 不等于"不看代码"。CLI 是执行层，review 可以嵌在任何地方。

Cursor 被收购传闻的启示

最近 SpaceX 据报以 600 亿美元期权收购 Cursor，震动了整个开发者社区。

这件事从另一个角度印证了 harness 工程的价值。Cursor 作为一个 IDE-based 的 harness，估值 600 亿，但它面临的最大风险也恰恰是 IDE 绑定带来的：一旦强制绑定 Grok，开发者会迁移，因为迁移成本极低——Cursor 的 VSCode 基因反而降低了用户黏性。

而 CLI 工具的迁移成本更低，这看起来是弱点，实际上是强点：因为迁移成本低，工具必须靠真实价值而不是锁定效应维系用户。这是更健康的竞争格局。

Claude Code 今天的口碑建立在工程质量上，不是锁定效应。这正是 CLI 作为载具的另一层优势：它逼迫工具不断打磨真实的 harness 能力，而不是依赖界面粘性。