夜雨聆风每一代软件架构的本质，都是用新的抽象去驯服新的复杂性。AI Agent 时代，这个抽象叫 Harness。
如果你是一个写了十年代码的开发者，2025 年第一次认真搞 AI Agent 开发的时候，大概率会有一种强烈的"既视感"——
这混乱的场面，我好像见过。
Prompt 到处散落、上下文管理全靠手动拼接、权限控制形同虚设、调试全靠看日志猜……这不就是 2005 年 Java 企业开发的噩梦吗？那时候 Service 层跟 DAO 层纠缠不清，业务逻辑散落在 Servlet 里，每个项目都在重新发明轮子。
后来我们怎么解决的？架构。
设计模式、分层架构、微服务、数据密集型系统设计……每当复杂性膨胀到人脑管不住的时候，软件工程的回答永远是同一个：加一层抽象，把复杂性关进笼子里。
2026 年，AI Agent 开发遇到的复杂性，终于也迎来了它的架构层。
它叫 Harness。
为什么叫这个名字？Harness 的英文原义是马具——缰绳、鞍具、胸带，套在马身上的那整套装备。
一匹野马力量惊人，但没有马具，你骑不了它，更别说让它拉车、犁地、上战场。马具不提供力量，它做的事情是：把力量变得可驾驭、可引导、可用。
AI 模型就是那匹马——强大、但不可控。而 Harness，就是套在模型上的那副缰绳。
这个名字起得精准。因为 Harness 要解决的问题，从来不是"让模型更聪明"，而是**"让模型的聪明变得可用"**。
软件架构30年演进到Harness
先说结论：Agent = Model + Harness
理解了这个类比，公式就很直觉了：
Agent = Model + Harness
Model 是那匹马——LLM 负责思考和生成，提供原始智力。
Harness 是那副马具——负责感知环境、调用工具、管理记忆、控制权限、处理异常……一切"让这匹马能在真实世界干活"的装备。
这个公式的重要性，被一个实验彻底证实了。
2025 年，Google DeepMind 在 SWE-bench 上做了一组对比：同一个底层模型，套上不同的 Harness，性能差距巨大。 不是微调的差距，不是 Prompt 的差距——是整个"外壳"工程能力的差距。
换句话说：模型决定了智商上限，Harness 决定了实际表现。
这就像同一台发动机，装在不同底盘上——一个是赛车，一个是拖拉机。发动机一样，上路体验天差地别。
如果你还觉得"做 Agent 就是调 Prompt"，这个实验应该能让你清醒过来。Agent 开发的核心战场，早就从模型转移到了 Harness。
Agent = Model + Harness
30 年架构史：每一代都在打同一个怪
为什么说 Harness 不是凭空冒出来的？因为它是软件架构演变的第五章。
回看过去 30 年，每一代架构解决的核心问题都是同一个：复杂性管理。只是"复杂性"的来源在不断变化。
第一章：GoF 设计模式（1994）—— 驯服"对象的复杂性"
1994 年，四人帮（Gang of Four）出版了《设计模式》。
那时候面向对象编程刚起步，大家兴奋地创建各种类和对象，然后发现——对象之间的关系很快变成一团乱麻。谁创建谁？谁依赖谁？改一个类，崩一片功能。
GoF 给出了 23 种设计模式：工厂模式管创建、观察者模式管通信、策略模式管变化……
本质是什么？用模式把对象之间的复杂关系"标准化"。 你不再需要每次都从零设计对象交互，有了可复用的"解题套路"。
第二章：企业架构模式（2002）—— 驯服"业务系统的复杂性"
到了 2000 年代初，问题变了。单个类的复杂性搞定了，但整个企业系统变得无比臃肿——几十万行代码缠在一个巨型单体应用里，数据库调用散落各处，业务逻辑和展示逻辑混为一谈。
Martin Fowler 在 2002 年出版了《企业应用架构模式》，提出了分层架构、Repository 模式、工作单元模式等一套体系。
本质：用"分层"和"边界"把企业系统的复杂性隔离开。 表现层、业务层、数据层各管各的，改一层不影响另一层。
第三章：微服务（2010s）—— 驯服"分布式的复杂性"
系统越做越大，单体应用扛不住了。一个服务挂掉，整个系统跟着崩。部署一次，全量发布。团队规模一大，代码冲突不断。
微服务架构在 2010 年代兴起：把大系统拆成独立的小服务，每个服务独立部署、独立扩展、独立演进。Netflix、Amazon 是最早的大规模实践者。
但微服务也带来了新的复杂性——服务发现、负载均衡、链路追踪、分布式事务……一个新的基础设施层应运而生（Service Mesh、API Gateway 等）。
本质：用"拆分 + 基础设施层"来管住分布式系统的复杂性。
第四章：DDIA（2017）—— 驯服"数据的复杂性"
Martin Kleppmann 在 2017 年出版的《设计数据密集型应用》（DDIA）几乎成了分布式系统工程师的圣经。
它解决的核心问题是：当系统的核心瓶颈从"计算"转向"数据"——海量数据的存储、复制、分区、一致性、流处理——该怎么架构？
本质：为"数据密集型"这个新的复杂性来源，提供了系统化的架构思维。
四代架构演进
第五章：Harness（2026）—— 驯服"智能体的复杂性"
现在轮到 AI Agent 了。
2023 年 ChatGPT 爆发后，所有人都开始做 Agent。Demo 阶段一切美好——调几个 API，写几段 Prompt，Agent 就能"自主完成任务"了。
然后问题来了。
跟过去 30 年每一次一模一样——当你试图把 Demo 变成产品，复杂性会指数级爆炸。
Agent 开发中的复杂性长什么样？五个典型深坑：
| 死循环 | ||
| 上下文爆炸 | ||
| 权限失控 | ||
| 质量不可控 | ||
| 成本黑箱 |
有没有很熟悉？
死循环 → 像不像没有断路器的微服务调用链？ 上下文爆炸 → 像不像没有分页的数据库全表扫描？ 权限失控 → 像不像没有 RBAC 的企业系统？ 质量不可控 → 像不像没有测试框架的单体应用？
每一代新技术带来的混乱，本质上都是同一种病：复杂性超过了现有工具的管控能力。
而每一次的药方也都一样：在混乱之上，加一层架构。
Harness，就是 AI Agent 时代的那层架构。
Agent深坑与传统架构问题对比
Harness 到底长什么样？
说了半天 Harness 重要，它到底包含什么？
拆开来看，一个完整的 Harness 系统有 6 个核心组件：
1. Agentic Loop（智能体循环）
这是 Agent 的"心跳"。它定义了 Agent 的基本行为模式：感知 → 思考 → 行动 → 观察 → 再思考……
关键不是循环本身，而是循环的控制机制——什么时候该停？出错了怎么回退？陷入死循环怎么打断？
这就像操作系统的进程调度器——不是让程序"跑起来"难，是让它"跑得稳、停得住"难。
2. Tool System（工具系统）
Agent 的能力边界，取决于它能调用什么工具。代码执行、文件读写、API 调用、数据库查询……
Tool System 要解决的问题是：工具的注册、发现、描述、调用、错误处理，以及最关键的——权限控制。
哪些工具可以自动执行？哪些必须人类确认？哪些绝对不能碰？这套权限体系不亚于 Linux 的文件权限模型。
3. Memory & Context Management（记忆与上下文管理）
LLM 有 context window 限制。对话越长，早期信息被挤出窗口。Agent 在长任务中会逐渐"失忆"。
记忆系统要解决：什么信息该保留？什么该压缩？什么该持久化存储？怎么在需要的时候精准召回？
这像不像数据库的缓存策略？热数据留内存，冷数据落磁盘，LRU 淘汰，按需加载。
4. Guardrails（护栏系统）
Agent 不是人——它没有"常识"。你让它优化代码，它可能把整个目录删了重写。你让它发邮件，它可能给错误的人发了敏感信息。
Guardrails 是 Agent 的"安全围栏"：内容过滤、操作限制、输出验证、危险操作拦截。
5. Hooks（钩子系统）
在 Agent 执行流程的关键节点插入自定义逻辑——工具调用前后、消息生成前后、错误发生时。
这跟 Web 框架的中间件、Git 的 pre-commit hooks 是同一个思路：在不修改核心逻辑的情况下，扩展行为。
6. Session（会话管理）
管理 Agent 与用户之间的交互状态：对话历史、任务进度、中断恢复、多轮协作。
Harness六大组件架构
三个阶段：从 Prompt 到 Harness
理解了 Harness 的组成，再回头看 Agent 工程的演进，你会发现它经历了三个清晰的阶段：
阶段一：Prompt Engineering（2023）
ChatGPT 刚火的时候，所有人都在研究怎么写 Prompt。
"你是一个资深产品经理……请按以下格式输出……" 各种 Prompt 模板、技巧、框架层出不穷。
这个阶段的隐含假设是：只要 Prompt 写得好，模型就能干好活。
很快大家发现不够。Prompt 控制不了工具调用，管不了上下文窗口，防不住幻觉。
阶段二：Context Engineering（2024-2025）
Prompt Engineering 不够用了，问题出在"上下文"——模型看到了什么，决定了它输出什么。
于是大家开始琢磨：怎么组织上下文？怎么做 RAG（检索增强生成）？怎么管理对话历史？怎么注入系统指令？
Andrej Karpathy 甚至说："与其叫 Prompt Engineering，不如叫 Context Engineering。"
这个阶段的本质是：从"优化一句话"升级到"优化模型看到的全部信息"。
进步很大，但还是不够。因为 Agent 不只是"看"和"说"——它还要"做"。调用工具、操作环境、管理状态、处理异常……这些不是 Context 能搞定的。
阶段三：Harness Engineering（2026）
当你把 Agentic Loop、Tool System、Memory、Guardrails、Hooks、Session 全部加在一起，你就从"优化上下文"升级到了**"构建完整的智能体运行时"**。
这就是 Harness Engineering。
它跟前两个阶段的关系不是替代，而是包含：
Harness Engineering ⊃ Context Engineering ⊃ Prompt EngineeringPrompt 是一句话，Context 是一页纸，Harness 是整个操作系统。
从Prompt到Context到Harness三阶段
Claude Code：第一个"跑通"的 Harness
说了这么多架构和理论，有没有真正落地的产品？
有。目前做得最好的，是 Anthropic 的 Claude Code。
Claude Code 不是一个简单的"AI 编程助手"。它是目前市面上最完整的 Harness 实现——六个组件全部做到了产品级。
来看它怎么解决那五个深坑的：
| 死循环 | |
| 上下文爆炸 | |
| 权限失控 | |
| 质量不可控 | |
| 成本黑箱 |
更关键的是，Claude Code 的 Harness 是开放的。你可以自定义 Hooks、配置权限策略、接入自己的工具、管理自己的记忆系统。
这让人想到一个类比：Claude Code 之于 Agent，就像 Linux 之于服务器。
它不是一个封闭的产品，而是一个可组装、可扩展的基础设施。你在上面搭什么，取决于你自己。
Claude Code Harness架构全景
一张图看懂：30 年架构演变的底层逻辑
现在把整条线串起来：
1994 GoF 设计模式
复杂性来源：对象交互
解法：23种标准化模式
↓
2002 企业应用架构模式 (Fowler)
复杂性来源：业务系统膨胀
解法：分层架构 + 边界隔离
↓
2010s 微服务架构
复杂性来源：分布式系统
解法：服务拆分 + 基础设施层
↓
2017 DDIA 数据密集型系统
复杂性来源：海量数据
解法：数据分区/复制/一致性模型
↓
2026 Harness Engineering
复杂性来源：智能体行为
解法：6组件运行时架构每一代的模式完全一样：
新技术带来新能力 新能力催生新的复杂性 复杂性膨胀到人脑管不住 新的架构范式诞生，用抽象"驯服"复杂性 行业标准化，进入下一轮循环
Harness 不是什么全新的发明。它是软件工程30年来"用架构管理复杂性"这条主线的最新延伸。
理解了这一点，你就不会把 Harness 当成一个流行词汇，而是看到它在技术史中的必然位置。
30年架构演变全链路时间线
给开发者的启发
1. 别再只关注模型了
DeepMind 的实验说得很清楚：同一个模型，不同 Harness，性能天壤之别。
如果你在做 Agent 产品，花 80% 的精力研究"用哪个模型"，不如花 60% 在 Harness 工程上。模型是军备竞赛，Harness 是护城河。
2. 你过去的架构经验没有白费
如果你做过微服务——服务发现、熔断、限流那套东西，迁移到 Harness 里几乎是降维打击。
如果你做过分布式系统——状态管理、一致性、容错那些概念，Agent 的记忆系统和会话管理对你来说毫无障碍。
Harness Engineering 不是一个全新的学科。它是传统软件架构能力在 AI 时代的投射。
3. 现在入场，不早不晚
2026 年的 Harness Engineering，大概相当于 2014 年的微服务——概念已经清晰，先行者已经验证（Claude Code），但行业标准还没有固化，开源生态还在早期。
这意味着：你现在积累的 Harness 实践经验，在两年后就是稀缺资产。
结语
回看软件架构这 30 年，最让人感慨的是这条线的一致性。
从 GoF 到 Fowler，从微服务到 DDIA，再到今天的 Harness——我们一直在解同一道题：怎么用抽象驯服复杂性。
工具在变，语言在变，范式在变，但这道题从来没变过。
AI Agent 的出现，带来了一种前所未有的复杂性：你管理的不再是确定性的代码逻辑，而是一个会"思考"、会犯错、会自主行动的智能体。
Harness，是我们目前找到的最好答案。
不一定是最终答案。但如果 30 年的历史能说明什么的话——每一次我们以为"这次不一样"的时候，架构思维最终都会回来。
这次也不例外。
参考资料：
黄佳/Datawhale [万字综述Harness革命：从Prompt Engineering到Harness Engineering] Gamma et al. [Design Patterns: Elements of Reusable Object-Oriented Software (1994)] Martin Fowler [Patterns of Enterprise Application Architecture (2002)] Martin Kleppmann [Designing Data-Intensive Applications (2017)] Google DeepMind [SWE-bench Harness 对比实验 (2025)]