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

![AI Agent 工程的必然演进](../assets/ai-agent-engineering-evolution-illustrations/01-cover-agent-engineering.png)

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

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

## MCP 只是中间产物

![MCP 是 CLI 主轨上的过渡转接头](../assets/ai-agent-engineering-evolution-illustrations/02-mcp-intermediate.png)

先说一个比较粗暴的观点：我认为 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 真正学会使用人类现有的工具以后，单独为它维护一套工具世界会越来越没有必要。

## Skills 把经验从对话里拿了出来

![Skill 把对话经验变成可版本化资产](../assets/ai-agent-engineering-evolution-illustrations/03-skills-from-conversation.png)

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

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

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

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

## Harness 这个词其实很准确

![Harness 让 Agent 保持在正确路径上](../assets/ai-agent-engineering-evolution-illustrations/04-harness-alignment.png)

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

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

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

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

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

## Loop 也不是 AI 发明的

![Issue 驱动的 Agent 自治循环](../assets/ai-agent-engineering-evolution-illustrations/05-agent-loop-pipeline.png)

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

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

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

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

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

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

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

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

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

![新概念只是给旧工程经验换上新标签](../assets/ai-agent-engineering-evolution-illustrations/06-old-tools-new-names.png)

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

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

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

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

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

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