过去几年，大语言模型的发展有一个非常容易被忽略的变化：
我们真正进步的，并不只是模型本身越来越聪明，而是我们越来越擅长给模型建立“约束”。
最早，我们相信一个足够好的 Prompt 就可以让 AI 按照我们的要求工作。
后来，我们发现仅靠 Prompt 不够，于是给模型增加了思考过程；再后来，我们给它工具、函数调用、MCP、Skills、记忆、代码执行环境、测试系统、浏览器和各种反馈回路。
最终，我们逐渐得到今天所谓的 Agent。
但如果把这些技术抽象到一起，会发现它们背后其实存在一个非常统一的思想：
Agent 并不是简单地让模型“自己做事情”，而是在模型之外建立一个 Harness，不断规定它应该如何行动、如何获取信息、如何验证自己的行为，以及失败以后如何重新行动。
换句话说：
Agent = Model + Harness。
而 Harness 的核心任务，就是把一个概率性的语言生成器，变成一个能够在约束环境中不断行动、验证和修正的执行系统。
这可能才是 Agent 这几年真正的发展主线。
最初的大语言模型并没有今天意义上的 Agent。
我们通常只是把一段指令放进 Prompt：
你是一名专业程序员，请帮我修复这个 Bug。 请仔细分析问题。 不要编造 API。 如果不确定，请告诉我。 输出最终代码。
看起来已经非常像一个 Agent 了。
但实际上，这里面几乎没有任何真正的“控制”。
模型依然只有一个动作：
生成下一段 Token。
它没有真正的文件系统，没有真正的数据库，没有编译器，没有浏览器，也没有一个外部机制能够判断它说的到底对不对。
于是出现了一个非常核心的问题：
模型知道“应该正确”，并不意味着它能够做到正确
例如：
请使用 Next.js 16 最新 API。模型可能非常自信地写出一个实际上属于 Next.js 13 的 API。
因为模型真正拥有的知识并不是：
“Next.js 16 的 API 是什么？”
而更接近：
“根据我见过的文本，什么样的 Token 序列最可能出现在这里？”
这就是幻觉问题最底层的原因之一。
Prompt 可以告诉模型规则，却不能保证模型遵守规则。
所以早期所谓的 Prompt Engineering，本质上是在研究：
如何用自然语言最大程度地改变模型的概率分布。
这非常有用，但它天然存在上限。
接下来出现了一个极其重要的变化：
不要让模型直接回答。
而是：
问题
↓
思考
↓
检查
↓
答案这就是 Reasoning Model 的核心思想。
DeepSeek-R1 是这个阶段非常具有代表性的公开案例。DeepSeek 在 R1 的后训练中大量使用强化学习，并强调推理过程中存在大量反思与验证；官方 API 也将 reasoning content 与最终 content 分开。
这时候模型的行为从：
Input → Output变成：
Input
↓
Reasoning
↓
Output看起来只是多了一段文本。
但从 Harness 的角度来看，它实际上引入了一个非常重要的概念：
中间状态。
模型不再必须一步从问题跳到答案。
它可以先提出假设：
我认为答案可能是 A。然后重新检查：
如果答案是 A，那么条件 X 是否成立？再发现：
等等，X 不成立。最后：
所以 A 不正确，应该重新推导。这就是所谓的 self-verification / self-correction 的雏形。
DeepSeek 官方文档也明确说明，思考模式是在输出最终答案之前先生成推理过程，以提升最终答案的准确性。
这里有一个非常重要的区别。
很多人会把：
思考得更多
理解成：
验证得更多。
实际上两者完全不同。
如果让模型：
请仔细思考这个问题。它可能只是生成了更多 Token。
甚至可能出现：
错误假设
↓
非常详细的推理
↓
非常自信的错误答案因此真正重要的不是：
模型有没有思考。
而是：
模型有没有获得检查自己答案的能力。
这也是 Harness 开始真正发挥作用的地方。
当模型开始具备 Reasoning 之后，下一个问题就出现了：
如果模型认为自己需要验证某件事情，它应该去哪里验证？
于是我们开始给模型工具。
例如：
模型
↓
我要计算 12345 × 67890
↓
调用 calculator
↓
得到结果
↓
继续推理或者：
模型
↓
我要查询数据库
↓
调用 SQL Tool
↓
得到真实数据
↓
继续推理或者：
模型
↓
我要检查代码
↓
调用 TypeScript Compiler
↓
得到类型错误
↓
修改代码这一步非常关键。
因为模型第一次拥有了：
语言世界之外的反馈。
之前模型只能说：
“我觉得这个 API 存在。”
现在它可以：
import ...
↓
TypeScript
↓
error TS...它不需要“相信自己”。
现实环境会告诉它答案。
于是 Agent 开始从：
Think → Answer变成：
Think
↓
Act
↓
Observe
↓
Think
↓
Act
↓
Observe
↓
Answer这已经非常接近现代 Agent 的基本循环。
Function Calling 解决了：
模型可以调用工具。
但还有一个问题：
工具从哪里来？
如果每个 Agent 都需要自己定义：
github_search()
github_issue()
github_pr()
notion_search()
database_query()
browser_open()
...生态很快就会碎片化。
MCP（Model Context Protocol）解决的正是这一层问题。
它把 AI 应用与外部数据源、工具以及工作流之间的连接标准化。官方定义中，MCP 可以让 AI 应用连接本地文件、数据库、搜索引擎、计算器等外部能力。
于是 Agent 不再只是：
“我知道很多东西。”
而变成：
“我可以去很多地方获取事实。”
例如：
LLM
│
├── MCP → GitHub
│
├── MCP → Database
│
├── MCP → Browser
│
├── MCP → Figma
│
└── MCP → Documentation这实际上是把模型从一个封闭的语言系统，变成了一个开放的执行系统。
MCP 更像是：
这里有一把锤子。
而 Skill 更接近：
当你遇到钉子的时候，应该拿这把锤子，并按照下面的流程操作。
这就是 Skills 的重要意义。
一个 Skill 往往包含：
什么时候触发
↓
需要读取什么上下文
↓
应该使用什么工具
↓
按照什么步骤执行
↓
哪些事情禁止做
↓
完成后如何验证因此 Skill 本质上已经不是简单的知识库。
它更像是：
一份可以被模型执行的行为规范。
这也是为什么现在越来越多 Agent 系统开始出现：
AGENTS.md
SKILL.md
CLAUDE.md
rules/
instructions/
workflows/这些东西看起来都是 Markdown。
但它们真正改变的并不是模型的知识。
而是：
模型的行为轨迹。
近期关于 Skill-Use 的研究甚至把 Skill 使用拆成了 Trigger、Compliance 和 Boundary 三个部分：模型是否正确触发 Skill、是否遵守流程，以及是否避免执行禁止操作。实验结果也表明，Skill 的效果高度依赖 Harness，而不是模型本身的固定能力。
这其实非常能说明问题：
一个模型有多强，和一个 Agent 有多可靠，是两件不同的事情。
到这里，我们已经拥有：
Prompt
Reasoning
Tools
MCP
Skills但仍然存在一个致命问题：
谁来判断 Agent 做得对不对？
如果最后还是：
AI：
“我检查过了，代码没问题。”那么实际上什么都没有改变。
因为：
让模型自己评价自己的答案，依然属于模型内部闭环。
真正可靠的 Harness，需要把验证过程尽可能放到模型之外。
于是出现了：
Agent
↓
生成代码
↓
TypeScript
↓
ESLint
↓
Unit Test
↓
E2E Test
↓
Browser
↓
真实环境这就是现代 Coding Agent 非常重要的思想：
不要让 AI 直接解决问题，让 AI 生成一个可以被机器验证的解决方案。
因为代码有一个非常特殊的属性：
它可以被机器验证。
例如 AI 说：
我已经把类型修好了。
不需要相信它。
直接：
tsc --noEmitAI 说：
页面应该可以正常运行。
不需要相信它。
直接：
pnpm buildAI 说：
登录流程没有问题。
不需要相信它。
直接：
playwright test于是我们获得了一个非常漂亮的反馈循环：
┌───────────────┐
│ LLM │
└───────┬───────┘
│
▼
修改代码
│
▼
┌───────────────┐
│ Type Checker │
└───────┬───────┘
│
Fail?
/ \
Yes No
│ │
▼ ▼
修复 E2E Test
│
Fail?
/ \
Yes No
│ │
▼ ▼
修复 Done这时候 Agent 的可靠性不再完全依赖：
“模型有多聪明。”
而开始依赖：
“我们能不能建立一个足够强的反馈系统。”
这也是为什么现代 AI Workflow 越来越像软件工程。
传统 AI：
Question
↓
LLM
↓
Answer现代 Agent：
Goal
↓
Plan
↓
Generate
↓
Execute
↓
Observe
↓
Validate
↓
Repair
↓
Validate
↓
...
↓
Success这里最重要的不是 Plan。
甚至也不是 Generate。
而是：
因为只要存在一个可靠的验证器，Agent 就拥有了一个明确的优化方向：
继续行动，直到通过验证。
这和传统软件工程中的测试驱动开发非常接近。
不是：
“我觉得代码应该没问题。”
而是：
“测试通过了，所以在当前测试覆盖范围内，它满足了这些可验证条件。”
这也是 Harness 的核心：
把模糊的自然语言目标转换成可验证的状态。
如果把 LLM 看成一个大脑，那么 Harness 就非常像：
大脑
+
眼睛
+
耳朵
+
手
+
工具
+
记忆
+
环境
+
规则
+
反馈一个裸 LLM 只能预测：
接下来应该说什么？而一个 Agent Harness 让它面对：
接下来应该做什么？
↓
做完以后发生了什么？
↓
结果符合预期吗？
↓
如果不符合，应该怎么办？所以：
Agent 的本质不是让模型拥有“自主意识”，而是给模型建立一个可行动、可观察、可反馈的闭环。
这个趋势甚至已经开始反过来改变框架本身。
2026 年的 Next.js 已经把 AI Agent 当成了一等使用者。
Next.js 官方现在会将与安装版本匹配的文档直接放进：
node_modules/next/dist/docs/然后通过项目根目录的 AGENTS.md 告诉 Agent：
Before any Next.js work, find and read the relevant doc in
node_modules/next/dist/docs/.
Your training data is outdated —
the docs are the source of truth.也就是说：
不要相信模型训练时记住的 Next.js。
而应该：
当前项目
↓
当前 package.json
↓
当前安装的 Next.js
↓
当前版本对应的本地文档
↓
AgentNext.js 官方文档明确解释了这一设计：安装 next 时会将版本匹配的文档放在 node_modules/next/dist/docs/，而 AGENTS.md 的作用就是要求 Agent 在写代码之前读取这些文档。
这其实是一个非常漂亮的 Harness。
因为它解决的是 Agent 最常见的问题之一：
模型知道 Next.js，但不知道你现在使用的是哪个 Next.js。
更有意思的是，Next.js 团队的评估显示，这种“始终可用的版本匹配上下文”在其评测中优于依赖 Agent 自己决定是否检索 Skill 的方案。
这说明了一个很重要的 Harness 原则：
不要把关键验证交给模型自己决定是否进行。
如果“读取文档”非常重要，就应该把它设计成流程的一部分。
所谓 PUA，并不应该简单理解成“骂 Agent”。
真正值得关注的是它背后的控制思想：
你说完成了？
↓
证据呢？
↓
运行测试。
↓
失败了？
↓
继续修。
↓
再测试。
↓
还有问题？
↓
继续。它把 Agent 从：
“完成任务”
变成：
“证明任务已经完成”。
这两个目标完全不同。
前者优化的是：
生成一个看起来像完成了的答案后者优化的是：
产生一个能够通过验证的结果这就是 Harness 思维。
如果继续沿着这条路线发展，会出现一个更加有趣的方向：
World Model。
在文本世界里：
Agent
↓
文字
↓
文字反馈而在物理世界：
Agent
↓
动作
↓
物理世界
↓
状态变化
↓
传感器
↓
反馈例如一个模型学习机器人控制。
它可能预测：
如果向前移动 10cm，
物体应该移动到这里。然后真正执行。
如果现实世界告诉它：
物体没有移动。那么这个错误就是一个非常强的监督信号。
它不能靠一句：
“我觉得应该移动。”
来覆盖现实。
物理世界本身就是 Validator。
这就是为什么世界模型、机器人、模拟器、游戏环境会成为 AI 发展的重要方向。
因为游戏天然提供了：
状态 State
动作 Action
奖励 Reward
失败 Failure
目标 Goal
环境 Environment这几乎就是一个完美的 Agent Harness。
例如：
Agent：
我要通过这个关卡。
Game Engine：
你可以选择：
↑
↓
←
→
攻击
跳跃
Agent：
跳跃。
Game Engine：
失败。
Agent：
重新规划。
Agent：
攻击 + 跳跃。
Game Engine：
成功。
Reward = +1这和现实世界的 Agent Loop 非常相似：
Observe
↓
Think
↓
Act
↓
Observe
↓
Evaluate
↓
Retry只不过游戏引擎提供了一个成本低、反馈快、状态明确的世界。
因此游戏并不仅仅是 AI 的娱乐应用。
它本质上是：
一个廉价、可重复、可自动评分的世界模型实验场。
再看一个看起来完全不同的例子：
AI + Remotion 视频生成。
如果让 AI：
“帮我做一个科技感视频。”
那么结果很难验证。
但是如果把任务变成：
AI
↓
生成 React / Remotion Code
↓
TypeScript
↓
Render
↓
生成视频
↓
检查视频帧
↓
发现问题
↓
修改 Code
↓
重新 Render事情就完全不同了。
AI 不再直接“描述一个视频”。
它生成：
一个可以被渲染器执行的程序。
而 Render Engine 就变成了 Validator。
于是：
Natural Language Goal
↓
LLM
↓
Program / Code
↓
Type Checker
↓
Renderer
↓
Video
↓
Judge
↓
Repair这其实和 Coding Agent 完全是同一种思想。
只是 Validator 从：
TypeScript Compiler换成了：
Browser / Renderer / Vision Model / Video Evaluator如果把这些案例全部放在一起：
| 技术 | 实际增加了什么 | | ---------------- | ---------------------- | | Prompt | 行为规则 | | Chain of Thought | 中间推理状态 | | Reasoning Model | 更强的内部搜索/反思 | | Function Calling | 外部行动能力 | | Tools | 外部验证与信息获取 | | MCP | 标准化工具/数据连接 | | Skills | 程序化行为规范 | | Memory | 跨任务状态 | | Code Execution | 可执行反馈 | | Type Checker | 形式约束 | | Unit Test | 局部行为验证 | | E2E Test | 系统行为验证 | | Browser | 真实环境反馈 | | AGENTS.md | 持久化行为规则 | | World Model | 模拟环境反馈 | | Game Engine | 可重复的环境与奖励 | | Remotion | 将创意转换为可执行程序 | | Evaluator | 外部质量判断 |
你会发现：
它们并不是互相独立的技术。
它们全部在解决同一个问题：
如何限制一个概率模型的行为，使它最终产生我们真正想要的结果？
所以，我更愿意把 Harness 定义为：
Harness 是包围在模型外部的一层控制系统，它负责提供上下文、约束模型行为、管理工具、执行动作、获取环境反馈、验证结果，并在失败时驱动模型重新尝试。
它至少可以拆成几个部分：
┌──────────────┐
│ Goal │
└──────┬───────┘
↓
┌────────────────────────────────────────┐
│ HARNESS │
│ │
│ Context ───────→ LLM │
│ │ │
│ Rules ───────────→│ │
│ ↓ │
│ Decision │
│ │ │
│ ↓ │
│ Tools │
│ │ │
│ ↓ │
│ Environment │
│ │ │
│ ↓ │
│ Feedback │
│ │ │
│ ↓ │
│ Evaluator │
│ │ │
│ ┌────┴────┐ │
│ │ │ │
│ Pass Fail │
│ │ │ │
│ ↓ └────→ Retry │
│ Done │
└────────────────────────────────────────┘因此：
Prompt 是 Harness 的最早形态。
Agent 是 Harness + Model 的系统化形态。
而现代 Agent 的竞争，也正在逐渐从：
谁的模型参数更多？
转向：
谁能设计出更好的 Harness？
这是整个发展史中最值得注意的一点。
一个没有 Harness 的模型：
犯错
↓
输出
↓
结束一个有 Harness 的 Agent：
犯错
↓
测试失败
↓
获得反馈
↓
重新思考
↓
修改
↓
再次测试
↓
……Harness 并没有消灭模型犯错的能力。
它做的是另外一件事情：
让错误无法轻易通过系统。
这是一种非常工程化的思想。
软件工程从来没有假设程序员不会犯错。
所以我们建立：
Type System
Linter
Compiler
Unit Test
Integration Test
E2E Test
CI
Code Review
Production MonitoringAI 现在正在逐渐获得完全类似的一套东西。
所以未来的 Agent，很可能不会是：
一个越来越聪明、什么都知道的超级模型。
而更可能是：
一个普通模型 + 极其优秀的 Harness。
过去我们评价 AI：
GPT-4 比 GPT-3 强
R1 比某模型强
新模型 Benchmark 更高但 Agent 时代，这种评价方式正在变得越来越不完整。
因为最终效果可能是：
Model A + Harness A = 80%
Model B + Harness B = 85%
Model A + Harness B = 95%
Model B + Harness A = 72%这时候你很难再说：
B 是一个更强的模型。
因为真正决定任务成功率的，是整个系统。
2026 年已经出现了直接研究 Harness 本身的工作。例如 MemoHarness 将 Agent Harness 定义为管理上下文、工具、编排、记忆、解码和输出处理的外部控制层，并尝试让 Harness 从执行经验中持续学习。
甚至更进一步，Harness-R1 开始研究让一个专门的模型根据 Agent 的失败轨迹去修改其运行时 Harness，也就是：
Agent 失败
↓
分析失败轨迹
↓
修改 Harness
↓
重新运行
↓
观察成功率
↓
继续优化 Harness这意味着一个非常有意思的递归：
我们不再只训练模型，也开始训练“如何控制模型”。
如果把整个 AI 发展史继续往前推，我们甚至可以得到这样一个循环：
模型生成答案
↓
Harness 验证答案
↓
发现错误
↓
Harness 修改上下文 / 工具 / 流程
↓
模型重新执行
↓
再次验证
↓
发现 Harness 本身存在问题
↓
优化 Harness
↓
……于是：
Model
↓
Agent
↓
Harness
↓
Meta-Harness
↓
Self-Improving Harness这可能是 Agent 下一阶段真正值得关注的方向。
如果一定要用一句话总结：
Agent 不是一个“会自己做事的 LLM”，而是一个被 Harness 包围的 LLM。
它通过：
Context
+
Rules
+
Reasoning
+
Tools
+
Memory
+
Environment
+
Verification
+
Feedback形成一个闭环。
而这个闭环最重要的性质不是：
AI 能不能一次性给出正确答案。
而是：
AI 能不能发现自己的错误，并且在外部反馈的约束下不断逼近正确答案。
这也是为什么我们会看到一条非常清晰的发展路线：
Prompt
↓
Instruction
↓
Chain of Thought
↓
Reasoning
↓
Function Calling
↓
Tools
↓
MCP
↓
Skills
↓
Code Execution
↓
Tests
↓
E2E
↓
Environment
↓
World Model
↓
Self-improving Harness表面上看，这是十几个完全不同的技术。
但从更高的抽象层来看，它们其实都在做同一件事情：
把“生成答案”变成“在约束环境中搜索正确答案”。
我们曾经认为：
AI 不够聪明，所以要训练更大的模型。
后来我们发现：
即使模型很聪明，它仍然会犯错。
于是我们开始给它思考。
然后给它工具。
给它搜索。
给它浏览器。
给它代码执行环境。
给它 MCP。
给它 Skills。
给它数据库。
给它编译器。
给它测试。
给它模拟器。
给它真实世界。
最后甚至开始研究：
如何让 Harness 自己学习。
这条路线的终点并不是把 AI 变成一个永远不会犯错的神。
恰恰相反。
我们逐渐接受了一个更加现实的工程事实：
模型一定会犯错。
真正重要的是：
不要让错误直接变成最终结果。
让模型思考。
让模型行动。
让环境反馈。
让程序验证。
让测试拒绝。
让 Agent 修复。
让它再次运行。
直到结果满足约束。
这或许就是 Agent Engineering 最核心的思想：
不是相信 AI，而是构建一个让 AI 必须不断证明自己的系统。
而所谓 Harness，本质上就是这样一个系统。
它不是限制 AI 的“笼子”。
它更像是 AI 能够可靠工作的轨道。
没有轨道，模型只能自由生成。
有了轨道，模型才真正开始执行。
而当轨道本身也能够从失败中学习时，我们才可能真正走向下一代 Agent。