同一个 AI 模型，换个壳，表现天差地别——壳就是 Harness

从一个事故说起

前两篇分别讲了 AI 怎么"看"（Prompt 和 Context）和怎么"做"（MCP 和 Skill）。到这里，拼图看起来快完整了：你把信息喂给 AI，AI 想好了，通过工具去执行，执行还有标准流程可以遵循。

但我最近碰到的一件事，让我意识到中间缺了一块关键拼图。

我用 AI 帮一个项目做重构——把一批旧的 API 接口迁移到新的路由结构。我给了它清楚的 Context，配好了 Skill，MCP 也接上了代码仓库。它开始干活了。前几步都很顺利：识别旧路由、创建新文件、迁移逻辑。

然后它自己做了一个判断：它认为有些旧的测试文件"已经不需要了"，直接删掉了六个测试用例。

从 AI 的角度看，这个判断不是没有道理——那些测试确实是针对旧路由写的。但它不知道的是，其中三个测试覆盖了一些边界条件的回归检测。删掉之后，我们的持续集成就裸奔了。

问题出在哪？

不在 Prompt——我的指令很清楚。不在 Context——它看到了所有相关文件。不在 MCP——工具调用本身没问题。不在 Skill——操作流程是对的。

问题在于：谁来决定 AI 可以删文件？谁来设定"做到这一步要停下来问我"？谁来管理这整个循环的节奏和边界？

什么是 Agent

在讲解决方案之前，先定义一个贯穿本篇的核心概念。

Agent 是什么？

一句话： 一个能感知环境、自主决策、采取行动的 AI 系统。

跟传统程序的区别： 传统程序是线性的——你写好代码，它按顺序执行，遇到分支按条件走，不会自作主张。Agent 不一样。你给它一个目标（"重构这批 API"），它会自己拆解任务、规划步骤、在执行过程中根据结果调整策略。它有"主动性"。

组成： 一个 Agent = Prompt + Context + MCP + Skill + Harness。前四个概念前两篇已经讲过，都是组件。Harness 是把这些组件编排在一起的东西，也是今天要讲的重点。

一个判断标准： 如果你只是打字提问、AI 只是回复文字，那是对话。如果 AI 能自主决定"下一步做什么"、能调用工具去执行、能根据执行结果调整计划——那就是 Agent。

开头那个事故，正是因为 AI 在以 Agent 模式工作：它不只是回答我的问题，而是在自主地规划、执行、做判断。问题不在于它有这个能力，而在于没有人控制它用这个能力的边界。

Harness：包在 AI 外面的那层壳

Harness 是什么？

一句话： 包裹在 AI 模型外面的应用框架，负责编排模型的输入输出、管理工具调用、控制执行流程。

词源： Harness 直译是"马具"——套在马身上让骑手能控制方向和速度的那套装置。马有自己的意志和力量，但骑手通过缰绳和马鞍来引导它。

跟 Web 框架的对比： 如果你用过 Express.js 或 Spring Boot，Harness 在 AI 应用中的角色跟它们类似。Express 定义了路由规则、中间件管道、错误处理——你的业务逻辑运行在这个框架里面。Harness 也一样：它定义了 AI 的输入怎么组装、输出怎么解析、工具调用怎么执行、异常怎么处理。你的 AI 模型运行在这个框架里面。

一个具体的 Harness 每一轮对话在做什么？以 Claude Code 为例：

1. 启动阶段： 加载 System Prompt（CLAUDE.md）、Memory、MCP 配置、Skill 列表
2. 组装阶段： 收到你的消息后，把上面这些东西跟你的输入组装成一个完整的 API 请求，发给模型
3. 解析阶段： 模型返回结果。如果结果是纯文字，直接显示给你。如果里面包含工具调用请求（Function Calling），进入下一步
4. 执行阶段： Harness 执行工具调用——读文件、写文件、调用 MCP Server、执行命令
5. 反馈阶段： 把工具执行的结果传回给模型，模型基于新信息继续思考
6. 循环： 回到步骤 3，直到模型不再请求工具调用，给出最终回答

模型在这个循环里是什么角色？它是其中一个环节，不是全部。 这个认知非常重要。同一个 Claude 模型，在 claude.ai 网页版里只能聊天，在 Claude Code 里能读写文件、执行命令、调用 MCP。模型没变，Harness 变了。

这就是为什么标题说"同一个模型换个壳，表现天差地别"。壳就是 Harness。

开环 vs 闭环：一个 1948 年就想明白的道理

理解了 Harness 做什么之后，来看它为什么跟传统框架有本质不同。

先用一个日常例子感受"开环"和"闭环"的区别：

开环控制——烤面包机。 你把面包放进去，拧到 3 分钟，烤面包机就加热 3 分钟。不管面包是不是已经糊了、是不是还太软，它不看结果，到时间就停。你的指令决定一切。

闭环控制——恒温器。 你设定目标温度 25 度。空调开始制冷。温度传感器持续测量房间温度，当温度降到 25 度时，空调自动停止；当温度升到 26 度时，空调再次启动。系统在持续感知结果，并根据结果调整行为。

开环 vs 闭环

开环： 下达指令 → 执行 → 结束。不看结果。传统程序大多是开环的——你调用一个函数，它执行完返回，不存在"根据结果再决定做不做"的过程。

闭环： 设定目标 → 执行 → 观察结果 → 计算偏差 → 调整行动 → 再执行。持续感知和调整。

Harness 为什么必须是闭环的？ 因为 AI 模型是非确定性的。传统框架包裹的是确定性代码——bug 是偏差的唯一来源，消灭 bug 就消灭了偏差。但 AI 模型天生就会产生偏差。你没法消灭偏差，只能管理偏差。管理偏差就需要闭环：输出 → 检查 → 必要时干预 → 继续。

这个思路不是新发明。1948 年，数学家维纳出版了《控制论》，核心问题就是：对有自主行为的系统实施有效治理。方法论就是闭环反馈控制。78 年后我们在 AI 工程里重新遇到了同一个问题。

回到开头那个删测试文件的事故。解决方案不是写更好的 Prompt，也不是调模型参数。解决方案是在 Harness 层加一条规则：当 AI 要删除文件时，先暂停，问我一句。 五分钟配置，从此没再出过事。

使用 Harness 的三个层次

理解了概念之后，你会发现自己处在三个层次之一：

第一层：用现成的 Harness。 ChatGPT、Claude.ai、Gemini——都是别人搭好的 Harness，你只需要打字。绝大多数人在这一层，完全没有问题。

第二层：配置现有的 Harness。 这是产出比最高的层次。以 Claude Code 为例：

• 写 CLAUDE.md 告诉 AI 你的项目背景和工作规范（配置 System Prompt）
• 接入 MCP Server 让它能访问外部服务（扩展能力）
• 安装 Skill 让它遵循标准流程（固定做事方式）
• 设置 hooks——在特定操作前后触发自定义逻辑，比如"每次提交代码前自动跑测试"、"删除文件前弹出确认"（设置安全边界）

这些配置加在一起，就是在调整 Harness 的行为。你不需要从零写一个框架，只需要在现有框架里拧几个旋钮。

第三层：从零构建 Harness。 自己写模型 API 调用、工具执行、上下文管理、错误恢复、并发控制。绝大多数团队不需要走到这一步，但知道它的存在有助于理解整个画面。

Agentic Engineering：不是技术问题，是信任问题

Harness 回答了 how——怎么控制一个自主系统。但在回答 how 之前，有一个更根本的问题需要先回答：你到底想让这个系统自主到什么程度？

Agentic Engineering 是什么？

一句话： 一种设计哲学，关心的核心问题是：AI 系统应该自主到什么程度。

跟 Harness 的关系： Harness 是实现手段（怎么控制），Agentic Engineering 是目标设定（控制多少）。你先回答"我要造一个多自主的系统"，再设计"怎么控制它"。二者不是递进关系，而是不同维度。

核心张力： 自主性越高，效率越高，但风险也越大。自主性越低，越安全，但你得花更多时间盯着它。最优解不在两端，而是在中间某个位置——而且这个位置因场景而异。

Agentic Engineering 涉及的决策，都不是纯技术问题：

自主决策边界。 AI 可以自己改代码吗？可以删文件吗？可以花钱调用付费 API 吗？可以代表你给同事发消息吗？传统系统用权限模型（比如 RBAC）解决这类问题：角色和权限写死在配置里。但 Agent 的决策是动态的、语义级的——它不是"调了一个没权限的 API"，而是"做了一个看起来合理但实际上不该做的判断"。你没法用一个权限表穷举所有可能的判断。

错误累积。 一个 10 步任务，如果第 3 步出了偏差，后面 7 步都建立在错误基础上。传统系统用事务回滚解决类似问题——数据库操作出错了，回滚到之前的状态。但 Agent 的错误是语义级的——它把一段代码重构"错"了，你怎么回滚一个"判断"？

人机信任。 Agent 做完一个复杂任务，你怎么验证结果？如果每一步都检查，那跟自己做有什么区别？如果不检查，风险谁承担？这不是一个技术选择，而是一个需要根据具体场景反复校准的判断。

六个概念，一张图

三篇入门文章，六个概念，到这里全部讲完了。最后把它们的关系画在一起。

从下往上看——这是大多数人的学习路径：

从上往下看——这是设计者的思考路径：你先回答"要造多自主的系统"（Agentic），再设计"怎么控制"（Harness），再选择"用哪些组件"（Context + MCP + Skill），最后落到"每一步具体说什么"（Prompt）。

两个方向都对。实际工作中大多数人从下往上走，碰到问题才往上追。重要的是知道上面还有东西——不至于在 Prompt 层死磕一个本该在 Harness 层解决的问题。

从这里开始

如果你读到这里还没有动手，建议从第二层开始：挑一个你常用的 AI 工具，花半小时配置它的 Harness。写一个系统配置文件，装一个 MCP Server，或者创建一个 Skill。你会发现，调整 AI 的工作环境比调整你说的话，效果来得快得多。

然后观察一下：你愿意让它自己做多少决定？你在哪个点开始不放心？

那个不放心的点，就是你的 Agentic Engineering 实践的起点。

这是 AI 工程入门系列的第三篇。如果你已经理解了 Harness 和 Agentic Engineering 的区别，推荐继续阅读进阶篇《Harness 与 Agentic Engineering：控制一个会自己做决定的系统》，那篇从控制论的角度深入讨论了闭环设计、错误累积的应对策略，以及多 Agent 协作的挑战。