AI Agent 工程的必然演进：CLI、Skills、Harness 与 Loop

过去一年，我深度使用了 Claude Code、Codex，以及各种 Vibe Coding 工具。用得越多，我越觉得最近流行的这些词并没有那么新。MCP、Skills、Harness、Loop，看起来像一波接一波的新概念，其实都能在过去的软件工程里找到原型。它们只是到了 AI 时代，换了一个执行者，也终于有了自己的名字。

把这些东西放回历史里看，会比追着新名词跑有意思得多。

MCP 只是中间产物

先说一个比较粗暴的观点：我认为 MCP 会被淘汰。

这里说的“淘汰”，不是指协议和代码会在某一天彻底消失，而是它不会一直作为 AI 调用工具的主流入口存在。在大家真正意识到 CLI 才是 AI 使用工具的最佳形态之前，MCP 会很重要；等 Agent 能够普遍、稳定地驾驭终端以后，它的任务也就完成了。

在我看来，MCP 本质上就是给 AI 使用的 OpenAPI。它告诉模型外部系统有哪些能力、需要什么参数、会返回什么结果。过去的 OpenAPI 面向开发者和应用，MCP 把主要使用者换成了 Agent。这个转换当然有价值，但还谈不上创造了一套全新的工程范式。

我不喜欢 MCP 的第一个原因，是很多 MCP 客户端会把工具定义直接放进模型上下文。接入的服务越多，模型背着的说明书就越厚。当前任务明明用不到，它还是得看见，还得在一堆工具里做选择。这是在浪费 token，也在浪费模型的注意力。

这个问题不能全怪 MCP。协议本身有 tools/list，客户端也可以做渐进式发现，不必一次塞入所有工具。可现实中的朴素实现确实经常这么干。相比之下，Skill 的思路更自然：先让模型知道某项能力存在，真正需要时再读取完整说明。

第二个原因是 CLI 已经站在一套成熟的工程体系上。一个 CLI 可以自己处理鉴权、状态、日志和更新，可以打包成 .exe，也可以通过包管理器安装。输入输出怎么设计，由工具自己决定。人、脚本、CI 和 Agent 都能调用同一份东西。MCP 往往是在已有能力外面再包一层专供 AI 使用的接口，我不确定这层包装能长期抵消它带来的适配和配置成本。

尤其重要的是，CLI 同时给人和 AI 使用。Agent 可以直接执行一条命令，也可以把命令交给用户。用户复制到终端，自己运行一遍，马上就能核实结果。换成 MCP，普通用户通常还得先进入一个支持 MCP 的客户端。人并非不能调用 MCP，只是它没有给人留下一个像命令行这样直接的入口。

CLI 还有一个长期优势：它是大模型的能力压缩接口。

模型只需要输出一条很短的命令，就能让成熟程序完成搜索、计算、构建、测试或者部署。没必要把每个步骤都写进上下文，更没必要用 token 模拟程序早就能做好的计算。模型负责判断，工具负责执行。一点 token 可以撬动很大的工作量。

当然，写得一团糟的 CLI 也不好用。它至少要有稳定的非交互模式、结构化输出、明确的退出码和能看懂的帮助信息。CLI 并不会天然拥有这些品质。但只要工具设计得当，这条路比重新维护一套 Agent 专用接口更直接。

我的判断可能很武断，MCP 也可能吸收渐进发现、统一分发等能力继续演化。可我仍然认为，当 Agent 真正学会使用人类现有的工具以后，单独为它维护一套工具世界会越来越没有必要。

工具解决“能做什么”，Skill 解决“什么时候用、为什么用、怎么用”。这两件事不是一回事。

以前我们会在对话里反复教 AI：先看哪个文件，什么情况下运行哪条命令，遇到什么结果应该停下来。对话结束，这些经验也就散了。Skill 把它们写进文件，需要时加载，不需要时不占上下文。API 说明和 CLI 用法同样可以放进去，由 Skill 负责组织，底层仍然调用现成工具。

我在《为什么你需要一个自己的 Agent Skills 仓库》里写过自己的做法：用 GitHub 和 Git 管理不同类型的插件，保留多个版本，需要什么就启用什么。核心 SKILL.md 只维护一份，外面再做不同平台的适配。换设备、换 Agent、换项目，这套经验还能跟着我走。

这当然不能解决全部环境问题。运行时、依赖、密钥、权限和网络仍然需要管理。但至少，最容易丢失的那部分东西，也就是“我到底是怎么把 AI 用顺手的”，已经从个人记忆变成了可以版本控制的资产。

Harness 这个词其实很准确

我第一次看到 Harness Engineering，也就是“驾驭工程”这个词时，感觉有点奇怪。用着用着，反而觉得它形容得很准。

AI 是一个工具，而且是一个能力很强、行为却不总是稳定的工具。给它一个目标，不等于它能把事情做完。它可能忘记最初的要求，跳过步骤，在局部问题上绕很久，最后交出一个看起来完成、实际没有验证的结果。想把它用好，就得驾驭它。

这里的“驾驭”不是多写几句提示词。上下文怎么提供，工具怎么组织，任务状态放在哪里，出错后怎么恢复，结果怎么验证，这些东西要放在一起考虑。Harness 就是围绕模型搭出来的那套运行环境。模型相同，Harness 不同，最后的表现可以差很多。

真正熟练使用 AI 的人，往往会自然形成自己的 Harness。他会把反复验证过的提示、规则、脚本和工作流留下来，不再每次从头教。最初可能只是几个文件，后来有了分类、版本、依赖和验证，慢慢就长成一套看得见的架构。

我的 Skills 仓库就是其中一部分。它还不是 Harness 的全部，但已经开始解决一个很实际的问题：无论我在哪台设备、哪个项目、哪个 Agent 里工作，都尽量不要把已经积累的使用方法弄丢，也不要让它在一次次复制中悄悄变形。

Loop 也不是 AI 发明的

Loop 最近很火，但循环这件事在“古法编程”阶段就存在了。

用户提出 Bug、Feature 或需求，团队创建 Issue。开发者读取 Issue，修改代码，运行测试，提交 PR，再根据评审继续修复。任务状态变了，人就知道下一步该做什么。读取任务、执行、检查、更新状态，这本来就是一个循环。

AI 时代没有发明 Loop，只是把循环里的执行者换成了 Agent。Issue 依然可以是触发源：

Issue 触发
    ↓
Agent 修改并验证
    ↓
提交代码，创建 PR
    ↓
自动检查或其他 Agent 审查
    ↓
修复、再验证、合并
    ↓
更新 Issue

过去，这套流程靠人的责任感和注意力维持。人会主动看任务，记住做到哪里，发现失败后回来修。Agent 没有这种默认存在的工作习惯，所以我们得把触发条件、状态变化和完成标准明确写出来。只要这些东西足够清楚，Agent 就可以沿着流水线持续往前走。

我不认为正常的 Agent Loop 应该依赖人工审批。如果每走一步都要等人点一下确认，它仍然是 AI 辅助的人工作流，算不上真正的自治循环。Agent 可以 24 小时运行，人做不到。既然如此，就不该再让人的工作时间成为流水线的时钟。

人的工作应该前移：先定义权限、预算、验收规则和停止条件。Agent 在边界内自己执行，成功就继续，失败就重试、回滚或者停止。涉及资金、生产数据和外部发布时，也可以通过预授权、沙箱和策略门禁限制，而不是在每一轮临时找人批准。

无需人工审批不等于无限循环。连续失败、需求冲突、预算耗尽或者越过权限边界，流水线都应该停下来。人工处理异常，不要阻塞正常路径。

新概念，只是给旧经验起了名字

回头看，Skills、Harness、Loop 都有迹可循。过去不这样叫，是因为没必要。

一个熟练工程师会主动补全信息、选择工具、记住状态、检查结果。很多东西藏在人的经验和责任感里，大家默认他会做，也就不需要专门发明一个词去描述。现在执行者换成了 AI，这些隐性的部分必须写进文件、工具链和状态机，否则 Agent 就接不住。

所以我更愿意把这些新词理解成一种提醒：原来藏在人脑里的东西，现在得摊开来写了。它们没有创造新的工程规律，只是 AI 的发展逼着我们把过去无需言明的常识说清楚。有人恰好找到了一个准确的词，大家一听，发现说的正是自己已经在做的事。

这也是我观察 AI 工具演进时最感兴趣的地方。一个新概念出现，我不太关心它听起来有多新。我更想知道它继承了什么，为什么偏偏在现在被说出来，以及它到底是一个阶段性的外壳，还是会留下来的东西。

所以想明白这件事以后，面对 AI 领域层出不穷的新名词，也就不必焦虑了。下次再遇到一个听起来很吓人的新词，先别急着觉得自己又落后了。先想一想，它背后的逻辑是不是人类工程里早就存在的东西。大多数时候，答案都是肯定的。AI 时代的很多“新”，只是把旧经验换了个执行者、起了个新名字。

看清这一点，反而是一种优势。你不需要从零学起，只需要把已经理解的工程常识迁移过来，再补上 AI 特有的那一层差异。这样的适应是快速的，也是能真正落到自己生产实践里的。