本文核心观点来自 Datawhale 的一次技术分享，结合自己的理解整理成笔记。

从模型智力到 Harness：2026 年的转折点

有一个很有意思的心理变化过程：

  • 2024 年：觉得自己比较聪明，模型笨笨的，但知识丰富
  • 2025 年：开始觉得自己比较傻，模型的高度超过自己一大块了
  • 2026 年：模型智力已经 OK，无论中外模型都过关了——我们现在比拼的是 Harness

DeepMind 的 Agents 团队做过一个很有说服力的实验：固定模型不动，只换 Harness（模型外围工程），性能就能产生巨大差异。

这说明 Harness，也就是模型的外围基础设施，才是现在真正的战略级资产。Claude Code 商业价值如日中天，本质上做的就是 Harness。

为什么需要 Harness？Agent 的核心困境

Agent 很厉害，但有一个问题越来越凸显：你不一定能真正掌控你搭建的系统。

如果把所有东西都让 Agent 生成代码，一个完全不懂软件工程的人，岂不是跟懂工程的人能设计出一样的系统？

这个前提不成立。当系统真正在产品级别上线时，你会发现东西飘在表面、处于失控状态——因为那不是你设计出来的。

Agent 时代，我们要回到一个基础问题：每个人对现代 IT 系统的理解到底有多深。 这是每个人在 Agent 时代能走多远的分水岭。

Harness 的历史必然性：30 年软件工程的启示

Harness 的出现不是偶然，是历史的必然。工程师一直在做同一件事：与系统的复杂度做斗争。两个字——抽象。

1994 年：驾驭对象的复杂性

GOF（Gang of Four）的《Design Patterns》，23 种设计模式：创建型、结构型、行为型。

第一次有了设计词汇——程序员之间沟通效率大幅提升。

驾驭的是：对象——类的生命周期、对象的职责、对象间的协作。

2002 年：驾驭企业架构的复杂性

Martin Fowler 的《企业应用架构模式》、Eric Evans 的《领域驱动设计》。

表现层、服务层、领域层、数据层——让代码的结构反映业务的结构。

驾驭的是：架构——系统分层、业务边界、领域模型。

2010 年：驾驭分布式系统的复杂性

互联网爆炸式流量把以前所有架构都打烂了。微服务、消息队列、最终一致性……

驾驭的是：分布式通信——几十个微服务之间如何通信、如何保证数据一致。

2017 年：驾驭数据系统的复杂性

Martin Kleppmann 的《Designing Data-Intensive Applications》（DDIA）指出：软件复杂性的中心不在业务逻辑，而在数据系统。

驾驭的是：数据在时间和空间维度上的流动——分区、复制、共识。

2026 年：驾驭智能体的复杂性

比数据还要复杂的东西出现了——Agent，自己会推理、会行动的系统。

Agent 是一个概率机器，输入一个东西，输出不一定按你的要求走。我们第一次要驾驭一个不确定性的系统。

而 Harness，就是我们驾驭 Agent 的缰绳。

1994  对象复杂性   → 设计模式
2002  企业复杂性   → 分层架构 / DDD
2010  分布式复杂性 → 微服务 / 消息队列
2017  数据复杂性   → DDIA / 流处理
2026  智能体复杂性 → Harness

Agent 工程的三次跃迁

第一阶段：Prompt Engineering（2023）

研究怎么让大模型理解我们、给出想要的回答。CoT（Chain of Thought）”让我们一步步思考”是有用的。

第二阶段：Context Engineering（2024-2025）

你给大模型什么，就能从大模型身上得到什么。

企业知识库、RAG、Agent 的上下文管理——都是在调教模型的上下文，让输入更有深度。

第三阶段：Harness Engineering（2026）

只做 Context Engineering 已经不够了。现在需要让 Agent 自动采集、自动审核、自动完成任务。

核心是设计：循环策略 + 工具系统 + 质量审核 + 权限治理 = 可控的系统。

什么是 Harness？

Agent = Model + Harness

所有模型外围的工具全都是 Harness。

底层是无状态的、纯推理的大模型。Harness 做的，是把大模型的大脑变成 Agent 的身体。

Harness 是运行时和基础设施：模型运行时、上下文管理、权限控制、状态持久化……

Harness 的六大核心组件

1. Agentic Loop（智能体循环）

最重要的心脏。接受输入 → 工具执行 → 循环迭代 → 返回最终结果。

复杂行为从这个简单循环中涌现出来，与早期的 ReAct（推理 + 行动循环）一脉相承。

用户输入
   ↓
[LLM 推理] → 需要工具？
   ↓ Yes          ↓ No
[工具执行]     返回结果
   ↓
[观察结果] → 回到 LLM 推理

2. Tool System（工具系统）

Agent 的手脚。通过调用各种工具和 API，把 LLM 从语言生成扩展到真实世界的行动。

3. Memory & Context Management（记忆与上下文管理）

如何压缩上下文、如何管理长对话记忆。Claude Code 在这方面领先业界——Context Engineering 这个概念本身就是 Anthropic 最先提出的。

4. Guardrails（护栏/缰绳控制）

Allow / Deny / Ask 三种权限策略。用 Claude Code 时它一直在询问是否执行某个操作——这就是 Guardrails 在工作。没有这个，系统就是失控的。

5. Hooks（钩子/守卫）

在关键节点插入自定义逻辑。例如：代码推送到 GitHub 前，检查有没有把 .env 文件也推上去了——这种前置守卫就是 Hook 的典型应用。

6. Session Management（会话管理）

控制运行时的连续性机制，保证跨多轮对话的状态一致性。

Harness 解决的五大落地难题

难题 说明
无限循环问题 Agent 陷入死循环无法退出
上下文爆炸问题 长任务导致 Token 超出上限
权限失控问题 Agent 执行了不该执行的操作
质量不可控问题 输出结果难以保证稳定性
成本不透明问题 不知道每次任务花了多少钱

当前 Harness 生态格局

纵深型（深度工程开发）：

  • Claude Code：公认的 #1，上下文管理、Sub-agent、Skill、MCP 均由 Anthropic 率先提出并实现
  • OpenAI Codex：开源，代码能力强，适合做 Code Review（有人的实践是用 Claude Code 编码 + Codex 做 Review）

横向型（自动化运营）：

  • OpenClaw / Hermes：能在 WhatsApp、飞书等平台做自动化运营

开发者工具：

  • Cursor / Windsurf：Claude Code 之前流行的 AI 编码 IDE
  • Agent SDK：Claude Code 之上的可编程库
  • OpenCode：Claude Code 的开源平替，可配合 DeepSeek 使用，免费且轻量

纵深型和横向型不冲突，可以配合使用。但作者更偏爱 Claude Code 这种”一来一往的深层次交互”——因为当所有东西都自动化后，反而会失去掌控感，深度也随之消失。

工程师 vs 码农：永不失业的秘诀

工程师永远不会失业，但码农可能会失业。

  • 码农：单纯写代码的人。当 Agent 能生成代码时，码农的价值被替代。
  • 工程师：能够设计并驾驭复杂系统的人。

工程师的核心能力不在于写代码，而在于：

  1. 理解系统的复杂性
  2. 抽象和结构化思维
  3. 驾驭不确定性

你永远不是在给系统编码，你是在设计并控制这个系统。这个高度完全不同。

在 AI 时代越来越重要的能力

懂业务：越是 AI 时代，个体需要懂得越多。企业业务的深度理解是护城河——Agent 能做的越多，懂业务的人能驾驭的就越多。

深度交互能力：不断追问、不断深入的能力。你给大模型什么，就能从大模型身上得到什么。输入有深度，输出才有深度。

Harness 设计能力：能设计循环策略、工具系统、质量审核、权限治理——设计可控的系统。

小结

这篇文章最打动我的是用 30 年软件工程史来解释 Harness 出现的必然性——工程师永远在做同一件事：把复杂的东西变得可控。

从对象、到架构、到分布式、到数据、再到 Agent，复杂性的中心一直在转移，但抽象和结构化的方法论从未变过。

Harness 不是一个工具，是一种系统设计能力。掌握它的人，才是真正驾驭 Agent 时代的人。

“万变不离其宗。不必焦虑，以不变应万变。”