AI Agent 的 Harness 机制学习思考

 

2026 年 2 月，OpenAI 官方博客发布了一篇震撼业界的文章：《Harness Engineering: Leveraging Codex in an Agent-First World》。

文章讲述了一个看似不可思议的实验：一个仅有 3 人的工程师小组，在完全禁止手写代码的条件下，利用 AI Agent 在 5 个月内构建了超过 100 万行代码的完整产品。

人均每天合并 3.5 个 Pull Request，团队吞吐量从传统的 0.25 人/工程师跃升至 3-10 人/工程师。更令人惊讶的是：新成员越多，整体效率反而越高——这就是所谓的”知识飞轮效应”。

这个实验揭示了一个深刻的认知转变：软件工程正在经历继瀑布模型到敏捷开发、单体架构到微服务架构之后的第三次重大范式转移。

那么，什么是 Harness Engineering？它与我们熟悉的 Prompt Engineering、Context Engineering 有何本质区别？作为产品经理或技术负责人，我们该如何在自己的团队中落地这套方法论？

本文将结合 OpenAI、Anthropic、LangChain 等权威机构的实践案例，尽可能的从产品视角拆解 Harness 工程化的四大核心模块，并提供可立即落地的实战指南。

一、什么是 Harness？从”马具”隐喻说起

1.1 Harness 的本质定义

“Harness”这个词的原意是马具——缰绳、鞍具、嘴套，是骑手用来连接、保护、控制马匹的整套装备。

用它来描述 AI Agent 的管理框架，比喻非常精准：

• 马（模型）：强大、快速，但不知道该往哪跑。它有巨大的能力，但没有方向感。
• 骑手（工程师）：提供方向和判断，但不自己去跑步。负责决定做什么和为什么。
• 缰绳（Harness）：连接骑手和马，确保力量被正确引导，防止失控。它不做实际工作，但让工作成为可能。

LangChain 工程师 Vivek Trivedy 给出了一句精炼的定义：

“如果你不是模型，你就是 Harness。”

这句话精准地概括了 Harness Engineering 时代工程师角色的根本转变。

1.2 从 Prompt 到 Context 再到 Harness：三次范式演进

我们可以用同心圆式的嵌套关系来理解三者的演进：

Harness Engineering 的哲学基础可以用四个字概括：“约束换自主”。

这是一个看似悖论却极其深刻的思想：规矩越明确 → Agent 独立做的事越多；约束越严格 → 信任越高 → 自主权越大。

二、方法论：Harness 工程化的四大核心模块

模块一：地图而非百科全书——对抗上下文稀缺

2.1.1 OpenAI 的教训：为什么不能把一切都塞进 AGENT.md？

在 OpenAI 的实验中，他们就发现了一个常见误区：试图把巨大的信息塞进一个巨大的 AGENT.md 文件里。

这种做法的问题在于：模型的上下文窗口是稀缺资源。巨大的指令文件会挤掉重要的任务信息、代码片段和中间结果，导致 Agent 在执行过程中”失忆”或”注意力分散”。

2.1.2 正确做法：AGENT.md 作为导航地图

OpenAI 团队的做法是：将 AGENT.md 设计为一个约 100 行的目录文件，指向结构化的文档目录。

# AGENT 核心记忆文件（导航地图）

## 项目架构

– 参见 `/docs/architecture/system-design.md`

– 参见 `/docs/architecture/data-flow.md`

## 编码规范

– 参见 `/docs/coding-standards/python.md`

– 参见 `/docs/coding-standards/frontend.md`

## API 配置

– 参见 `/config/api-endpoints.json`

– 参见 `/config/environment-variables.md`

## 关键约束

– 所有数据库操作必须通过 Repository 层

– 禁止在 Controller 中直接调用外部 API

– 所有接口必须有单元测试，覆盖率不低于 80%

## 历史决策记录

– 参见 `/docs/decisions/2026-03-20-orm-selection.md`

– 参见 `/docs/decisions/2026-03-21-error-handling.md`

Agent 拿到这张”地图”后，可以按需跳转检索具体文档，而不是把所有内容一次性加载到上下文中。

2.1.3 记忆力机制和经验库

除了静态文档，Harness 还需要提供动态的记忆力机制：

• 持久化记忆：Agent 学到的新知识、团队的新规范，自动写入 AGENT.md 或专门的记忆文件，下次启动时自动加载。
• 经验库：将常见的错误模式、最佳实践、陷阱案例整理成结构化数据，Agent 在执行前可以快速检索参考。

产品启示：不要试图让 Agent”记住一切”，而是给它一张清晰的地图，让它知道去哪里找答案。这就像给新员工一本员工手册的目录，而不是把整个公司的制度打印出来塞给他。

模块二：机械化架构约束——从”软性建议”到”硬性卡口”

2.2.1 拒绝”建议式”软性约束

很多团队在引入 AI Agent 时，会在 Prompt 中写下这样的约束：

“请遵循 MVC 架构，不要在 Controller 中直接调用数据库。”

“请编写单元测试，确保代码质量。”

这种建议式软性约束的问题在于：它依赖 Agent 自身的“自觉性”和“记忆力”。当上下文变长、任务变复杂时，Agent 很容易忘记或绕过这些约束。

2.2.2 正确做法：Hook + 结构化测试

Harness Engineering 的核心原则是：用自动化工具把约束写进执行流程里，不依赖 Prompt 的软性约束以及 Agent 自身的自觉性。

具体做法是：采用 Hook 和结构化测试，即在 Agent 执行某个操作后，自动触发一段检查程序。

原则：仅在模型出错的问题上设置约束，将”好/不好”量化成 0/1，判断是否进入下一步，作为下一步的关键令牌。

这和状态机单向通行一致：每一层必须由上一层审查无误后可推进到下一步的进程，仅允许单向逐层通行，违反则自动报错，重新执行。

2.2.3 Claude Code 的 Hooks 系统：24 个生命周期事件 × 6 种处理器类型

Anthropic 的 Claude Code 提供了一个成熟的 Hooks 系统，可以作为参考标杆。

24 个生命周期事件覆盖了 Agent 执行的各个阶段，例如：

• SessionStart：会话开始
• PreToolUse：工具调用前
• PostToolUse：工具调用后
• PreCommandExecute：命令执行前
• PostCommandExecute：命令执行后
• PreFileWrite：文件写入前
• PostFileWrite：文件写入后
• SessionEnd：会话结束对外暴露的 4 类处理器:内部使用的 2 类处理器:

2.2.4 实战示例：强制代码规范检查

假设我们希望 Agent 在提交代码前自动运行 Lint 检查，不符合规范的代码不允许提交。

传统做法（软性约束）：

在 Prompt 中写道：”请在提交代码前运行 eslint，确保没有错误。”

问题：Agent 可能忘记，或者为了省事跳过这一步。

Harness 做法（硬性卡口）：

// 在 PostFileWrite Hook 中注册检查

hooks.register(‘PostFileWrite’, async (context) => {

if (context.file.path.endsWith(‘.ts’) || context.file.path.endsWith(‘.tsx’)) {

const result = await executeCommand(‘npx eslint ‘ + context.file.path);

if (result.exitCode !== 0) {

// 返回 exitCode 2 表示阻断

return { exitCode: 2, message: ‘Lint 检查失败，请修复后重试’ };

}

}

return { exitCode: 0 };

});

这样，无论 Agent 是否“记得”运行 Lint，系统都会自动拦截不符合规范的代码。

产品启示：好的 Harness 不是让 Agent”更聪明”，而是通过协议约束让 Agent”无法偷懒”。将人类的品味和标准编码成自动化规则，实现”品味捕获一次，强制执行无限次”。

模块三：反馈闭环——让 Agent 不再”蒙眼狂奔”

2.3.1 为什么 Agent 需要反馈？

Agent 没有办法像人一样去理解页面、理解操作是否做得对。不能获得反馈的 Agent，就像蒙眼的烈马——它可能跑得很快，但方向可能是错的。

即时的反馈能够确保每一个 Agent、在每一个时间点都知道：

• 做到哪里了
• 做得对不对
• 下一步要做什么

2.3.2 分层实现反馈机制

正确的做法是：分层实现反馈机制，从即时到跨对话逐层递进，相互补充。

2.3.3 GAN 架构：规划 – 评估 – 生成

一种高效的反馈闭环设计是借鉴 GAN（生成对抗网络）的思想，构建多角色协作架构：

• 规划者（产品经理角色）：负责任务拆解、目标设定、路径规划
• 生成者（开发工程师角色）：负责代码实现、功能开发
• 评估者（QA 工程师角色）：负责质量检查、测试验证、提出改进建议

这三个角色可以是同一个 Agent 在不同阶段的切换，也可以是多个独立的 Agent 协同工作。关键在于：每个角色都有明确的职责边界和反馈机制。

2.3.4 LangChain 的实践：Trace Analyzer Skill

LangChain 在优化 Deep Agents 时，发现人工排查成千上万行运行轨迹（Trace）几乎不可能形成快速迭代。

于是他们开发了一套Trace Analyzer Skill，将”读日志找问题”这件事做成了一个可复用的系统组件：

三步流程：

抓取数据：从 LangSmith 日志平台，把这次实验里所有 Agent 的运行轨迹原始数据全部拉下来。

并行分析：系统按批次把这些 Trace 切分开，同时启动多个分析子 Agent 并行跑。每个子 Agent 负责一批，专门做错误分析。找到报错点之后，所有子 Agent 的结论汇总到一个主 Agent 那里，由主 Agent 统一提炼成结构化的发现和改进建议。

人工审查：主 Agent 给出的是”下一次实验要改什么”的完整建议清单。工程师在这里参与，核对建议是否合理，批准后才进入下一轮改动。很重要的一点是：改动必须是通用的，对特定任务过度拟合的修改，可能让其他题目的表现退步。

这三步加在一起，把原来需要几个小时的日志排查，压缩成一个可以快速循环的工程流程。

追踪记录（Traces）是整个改进闭环的核心信号。很多所谓”模型不够聪明”的问题，其实是系统没有在合适的时机，把正确的上下文和约束交给模型。没有 Trace，就无法定位这种缺口，问题只会被归结为”模型能力不足”。

产品启示：Agent 的提升不只是模型能力问题，更是系统设计问题。建立可重复、可自动化的反馈闭环，比单纯优化 Prompt 更有效。

模块四：熵管理——把代码债当作垃圾回收

2.4.1 为什么需要熵管理？

Coding 工具生成代码会积压很多的技术债，可以理解成一种文档漂移、架构侵蚀和风格异化。如果不进行管理，那么将逐步累积，越来越难维护，被逐渐腐蚀。

这种现象被称为代码熵增——随着时间推移，代码库会自然地趋向混乱和无序。

2.4.2 正确解法：持续运行，定期回收

正确的做法是：把代码熵的管理当作编程语言的垃圾回收（Garbage Collection）来看待，是一种持续运行、定期回收的状态。

具体做法包括：

把编码原则固化为 Linter 规则：通过规则编码为自动化检测，比如命名规范、修复错误信息。

后台定期 Agent 扫描：专门的清理 Agent 进行周期性的运行扫描，检查文档不一致、约束违规、架构飘逸。例如：

• • 检查注释与代码的一致性
  • 检查是否有 Controller 直接调用数据库的代码
  • 检查是否有重复代码块

生成代码健康日报：每天自动生成一份代码库健康报告，列出发现的问题和建议。

发现问题立即修复：而非以后再说的 backlog。Agent 发现一个重复代码块，立即提取为共享函数/工具/原语工具。

2.4.3 OpenAI 的金句：品味捕获一次，强制执行无限次

OpenAI 团队有一句非常精炼的概括：

“Taste captured once， enforced infinitely.”

品味捕获一次，强制执行无限次。

这意味着：把你讨厌的一切模式（重复代码、缺少重试、加密库不标准、前端组件过大……）全部写成 Lint 规则 + 测试 + 审查 Agent，直接静态禁止。

更绝的是：把团队里每个工程师的“品味”和“专长”全部编码进代码库。新来的前端大牛把 Hooks 拆小的偏好、后端专家对异常处理的坚持，都可以变成自动化规则，永久生效。

2.4.4 为删除而构建：Start Simple, Build to Delete

Harness 的设计也不是一成不变的。今天复杂的管线任务，明天可能一个提示词就搞定了。

因此，Harness Engineering 的一个重要原则是：为删除而构建（Build to Delete）。

• Start simple（从简单开始）：不要一上来就搞复杂的控制流，先提供稳健的原语工具。
• 模块化设计：让每个组件都可以独立地替换或删除。
• 定期审视：随着模型能力的提升，某些 Harness 组件可能变得多余，应该果断删除。

这体现了 Harness 工程的现实主义哲学：Harness 本质上是在为当前模型的短板提供临时支撑，随着模型进化，这些补丁会逐步消失。

产品启示：好的架构不是追求永恒的完美，而是在解决今天问题的最简单架构的同时，为明天升级留足空间。定期”修剪”你的 Harness，保持其简洁和高效。

三、实战项目：从理论到落地

3.1 LangChain：控制变量实验，排名从第 30 跃升至前五

背景

2026 年 3 月，LangChain 官方发布了一篇题为《Improving Deep Agents with Harness Engineering》的文章，展示了他们如何通过优化 Harness，在不改变模型基座的前提下，让 Deep Agents 的跑分从 52.8 提升到了 66.5，从榜单第 30 开外一路进到前五。

实验设计

他们刻意把 Harness 优化空间压缩到三类变量：

1. 系统提示词（System Prompt）
2. 工具体系（Tools）
3. 中间件 Hook（围绕模型和工具调用的中间件）

保持模型不变，只调整这三个 Harness 变量，观察性能变化。

关键改进点

改进一：强制模型自检

LangChain 在 Trace 记录里发现，最常见的失败模式是：Agent 写完代码，回头读了一遍自己刚写的内容，觉得逻辑上看起来没问题，然后直接停工宣告完成。它根本没有去运行测试，拿实际的执行结果来验证。

针对这个问题，LangChain 上了两道防线：

• 第一道：提示词层面的约束。在系统提示词里明确规定四步走的解题框架：规划 → 构建 → 验证 → 修复。特别强调：验证时必须拿结果去对照最初的任务要求，而不是去对照自己写的代码。
• 第二道：系统层面的卡口。加入完结前检查中间件（PreCompletionChecklistMiddleware）。当 Agent 准备退出、宣告完成时，系统会直接拦截它，强制要求它对照任务规格做一次验证，确认跑过测试后才允许退出。

改进二：上下文注入——给 Agent 提供环境和约束信息

Agent 对自己所处的环境、约束条件和评估标准了解得越多，它就越能自主地指导自己的工作。LangChain 做了三件事：

注入工作环境地图：Agent 一启动，系统自动扫描当前工作目录、父子文件夹结构、工具路径以及 Python 安装信息，把这些环境信息结构化后直接注入上下文。

明确自动评估标准：在系统提示词中明确声明：产出会直接被自动化测试评估，任务规格里提到的文件路径必须严格遵守，否则自动评分会失败。

注入时间预算：当接近截止时间时，系统引导 Agent 收敛问题，进入验证与收尾阶段。

改进三：循环探测中间件

在大量 Trace 日志里，存在一个典型问题：当 Agent 确定了一个方向后，会高度执着地推进。即使路径已经走不通，它仍会在同一个文件上反复做微小修改，尝试局部修补，而不是整体重审。这种现象被称为 Doom Loops。

LangChain 的解决方式是加入 LoopDetectionMiddleware：通过工具调用的钩子，持续记录每个文件的编辑次数。当某个文件的修改次数超过阈值时，系统向 Agent 上下文中注入提示，要求它重新审视整体方案，而不是继续局部修补。

改进四：算力分配策略——“推理夹心”

后台多步思考的推理型模型通常有不同的推理强度档位。LangChain 采用了一个直观有效的策略：“xhigh-high-xhigh”。

• 规划阶段使用 xhigh：理解任务、制定整体方案最容易决定成败，值得投入更高算力。
• 中间实现阶段降到 high：按计划写代码，不需要每一步过度推演，节省大量时间。
• 最后的验证与收尾阶段，再拉回 xhigh：查错、确认结果需要谨慎。

这种分段式算力分配，把最终分数推到了 66.5%。

成果

通过上述 Harness 优化，LangChain 的 Deep Agents 在 Terminal Bench 基准测试中的得分从 52.8 提升到 66.5，排名从第 30 名以外跃升至前五。

核心洞察：模型能力决定上限，而 Harness 决定你能逼近上限多少。

3.2 Gstack：个人开发者的 Harness 标杆

背景

在日常开发中，我们常常陷入一种困境：向 AI 助手请求功能，它确实写出了代码，但代码能跑却不符合业务逻辑，或者缺少关键的错误处理。我们花费大量时间修正 AI 生成的”字面正确但语义错误”的代码，本质上是因为通用助手缺乏对工程上下文的深度理解。

它们像是一个只会听令行事的初级程序员，缺乏架构师的全局视野和 QA 的严谨态度。

gstack 项目的出现，正是为了解决这一核心痛点。它不是一个新的模型，而是一套基于 Claude Code 的意见化工作流层，将单一的 AI 助手拆解为 CEO、工程经理、发布经理等十个专属角色，通过 slash 命令按需调用，让开发过程从”对话”升级为”协作”。

核心原理与架构设计

Gstack 的核心价值在于**”角色分离”**。传统的 AI 编程助手试图用一个模型解决所有问题，导致上下文污染和注意力分散。Gstack 通过预设的 Prompt 模板和工具链，将不同的工程任务路由给特定的”虚拟专家”。

这种设计哲学认为：代码审查应该由专注于质量的角色处理，而架构规划则应由关注业务价值的角色主导。

工作流逻辑架构：

用户指令（自然语言/命令）

↓

gstack 路由层（角色识别与上下文注入）

↓

Claude Code 核心（执行与生成）

↓

[CEO] 规划与需求分析

[Eng Manager] 代码实现与管理

[QA] 测试与质量保障

[Doc Engineer] 文档生成

[Release Manager] 发布与部署

在这种架构下，gstack 充当了中间件的角色。它不直接生成代码，而是优化输入给 Claude Code 的上下文。例如，当你使用发布命令时，gstack 会自动注入关于版本控制、changelog 生成和部署检查列表的指令，确保 AI 不会遗漏发布流程中的关键步骤。

这种**”意见化”（Opinionated）**的设计，意味着它强制执行了一套最佳实践，减少了开发者需要反复提示 AI 遵守规范的成本。

实战安装与配置

Gstack 基于 TypeScript 构建，依赖 Node.js 环境。安装过程简单：

# 克隆 gstack 仓库到本地开发目录

git clone https://github.com/garrytan/gstack.git

# 进入项目根目录

cd gstack

# 安装项目所需的 TypeScript 及运行时依赖

npm install

# 配置环境变量，此处需填入有效的 Anthropic API Key

echo “ANTHROPIC_API_KEY=你的密钥” >> .env

# 验证安装是否成功

npm run check

配置完成后，gstack 会作为 Claude Code 的插件层加载，用户可以在终端中直接通过斜杠命令触发特定工作流。

深度使用场景解析

场景一：架构规划与需求分析（CEO 角色）

在开始编码前，使用 /plan 命令可以激活 CEO 角色。通用助手往往会直接开始写代码，而 gstack 的 CEO 角色会先询问业务目标、用户场景和潜在风险。

用户：/plan 我想做一个内部使用的文件分享工具

gstack(CEO): 收到。在开始之前，我们需要明确几个关键点：

1. 目标用户是谁？内部全员还是特定部门？

2. 安全性要求是什么？是否需要审计日志？

3. 预期的并发量是多少？

4. 是否需要权限管理？如果有，权限粒度是怎样的？

…

场景二：代码实现与管理（Engineering Manager 角色）

使用 /implement 命令激活工程经理角色。它会负责代码的具体实现，同时确保符合团队的编码规范和架构约束。

场景三：测试与质量保障（QA 角色）

使用 /test 命令激活 QA 角色。它会自动生成测试用例，运行测试套件，并生成质量报告。

成果与启示

Gstack 证明了一个重要观点：即使是个人开发者，也可以通过精心设计的 Harness 体系，让 AI Agent 的表现达到专业团队的水平。

它的成功关键在于：

1. 角色分离：避免单一 Agent 承担过多职责导致的上下文污染
2. 意见化设计：强制执行最佳实践，减少重复提示成本
3. Slash 命令体系：提供清晰的操作入口，降低使用门槛

产品启示：Harness 不仅是大型团队的专利，个人开发者同样可以通过模块化、角色化的设计，构建适合自己的轻量级 Harness 体系。

四、外部核心：OpenAI vs Anthropic 的工程化路径对比

4.1 核心思想对比

4.2 演变路径

OpenAI 的路径：

1. 自动补全时代（幽灵文本）：GitHub Copilot 式的代码补全
2. 结对编程时代（IDE 里一起写代码）：Codex CLI，人类与 AI 协同
3. Agent 全委托时代（你只提需求，多个 Agent 自己规划、写代码、测试、提 PR）：Codex 桌面端应用 + GPT-5.4

Anthropic 的路径：

1. 启动期（2-4 月）：终端聊天、CLAUDE.md、基础命令
2. 爆发期（5-7 月）：IDE 集成、MCP、自定义命令、Hooks、Subagent
3. 深化期（8-10 月）：Plan Mode、背景任务、插件系统、Skills
4. 成熟期（11-12 月）：Claude in Chrome、LSP、Opus 4.5、异步 Agent

4.3 关键金句（中英对照）

OpenAI：

“Taste captured once， enforced infinitely.”

品味捕获一次，强制执行无限次。

“If you‘re not the model， you’re the Harness.”

如果你不是模型，你就是 Harness。（Vivek Trivedy, LangChain）

“Harness Engineering is about designing the environment where AI can work reliably.”

Harness Engineering 是关于设计 AI 能够可靠工作的环境。

Anthropic：

“Constraints enable autonomy.”

约束赋予自主。

“The best Harness is the simplest one that solves today‘s problem， while leaving room for tomorrow’s upgrade.”

最好的 Harness 是解决今天问题的最简单架构，同时为明天升级留足空间。

LangChain：

“Model capability determines the ceiling， while Harness determines how close you can get to it.”

模型能力决定上限，而 Harness 决定你能逼近上限多少。

“Traces are the core signal of improvement. Without them， problems are attributed to ‘model inadequacy’.”

追踪记录是改进的核心信号。没有它们，问题只会被归结为”模型能力不足”。

4.4 工程化思考借鉴

从 OpenAI、Anthropic 和 LangChain 的实践中，我们可以提炼出五条可复用的原则：

原则一：追踪即反馈

没有 Traces，就没有改进方向。建立可重复、自动化的日志分析和错误诊断流程，比单纯优化 Prompt 更有效。

原则二：代劳上下文工程

把模型需要的环境信息提前整理好，主动递给模型，而不是让 Agent 自己去发现和组装运行条件。外围喂的信息越精准，模型就越能把算力集中在真正的解题步骤上。

原则三：强制自我验证

让模型真正面对客观的测试结果，而不是主观判断。模型天然偏向接受自己的第一个答案，必须主动推一把，让它真正面对客观的测试结果。

原则四：识别并修补坏模式

循环探测、早期停止、上下文腐烂……这些都是当前模型的典型缺陷。通过工程护栏（如 LoopDetectionMiddleware、PreCompletionChecklist）提供阶段性补丁，虽然未来可能变得多余，但在今天能显著提高成功率。

原则五：为特定模型定制 Harness

不同模型在提示风格、推理节奏上都有差异。若想把某模型的表现推到极限，需为它单独跑几轮迭代。通用 Harness 只能达到平均水平，定制化 Harness 才能发挥极致性能。

五、落地指南：如何为你的团队构建 Harness 体系

5.1 从零开始：三步搭出最小可用 Harness

看到这里，你可能会觉得 Harness 很复杂。其实不是，你不用一上来就做一个完整的系统。从这三步开始，就能搭出一个能用的最小化 Harness。

第一步：搭最小化文件系统 + Git 工作区

创建一个专属的工作区，初始化 Git 仓库，写好你的 AGENTS.md 核心记忆文件，把项目规范、架构要求全写进去。这一步，就解决了 Agent 的持久化和记忆问题。

第二步：封装代码执行 + 沙箱环境，做最小闭环

用 Docker 搭一个简单的隔离沙箱，给 Agent 封装 Bash 和 Python/Java 代码执行能力，让它能自己写代码、跑代码、验证结果。这一步，就给了 Agent 自主解决问题的核心能力。

第三步：加记忆注入 + 上下文管理，解决核心痛点

写一个简单的上下文管理模块，Agent 启动的时候自动注入 AGENTS.md，上下文快满的时候自动做压缩，工具输出自动做卸载。这一步，就解决了 Agent 失忆、上下文腐烂的问题。

做完这三步，你就有了一个最小可用的 Harness，你的 Agent 能力，绝对会比你之前搭的 ReAct 循环强 10 倍都不止。

5.2 进阶：引入 Hooks 系统和反馈闭环

当最小可用 Harness 运行稳定后，可以逐步引入更高级的功能：

引入 Hooks 系统：

• 在关键操作（如文件写入、命令执行）前后注册检查 Hook
• 将团队的编码规范、安全要求编码成自动化规则
• 实现“违反即阻断”的硬性卡口

建立反馈闭环：

• 接入 CI/CD pipeline，在 PR 创建时自动运行测试和 Lint
• 部署可观测性工具，监控 Agent 执行过程中的日志、指标、性能
• 引入独立评估 Agent，定期对已完成的功能进行质量评分和改进建议

5.3 高阶：熵管理与持续优化

当 Harness 体系运行一段时间后，需要关注代码熵的管理：

定期扫描与清理：

• 后台运行一个周期性 Agent，定期扫描代码库里的技术债
• 检查过时的依赖、被注释的死代码、违反架构约束的模块
• 自动提交修复 PR，人类工程师只需审核即可

定期审视与删除：

• 每季度回顾一次 Harness 的各个组件
• 随着模型能力的提升，某些组件可能变得多余，应该果断删除
• 保持 Harness 的简洁和高效，避免过度工程化

5.4 组织变革：从”写代码”到”设计环境”

Harness Engineering 不仅是一套技术方案，更是一种组织变革。它要求工程师的角色发生根本转变：

传统工程师：

• 核心工作：手写代码
• 价值体现：代码行数、功能交付速度
• 技能要求：编程语言、框架、算法

Harness 工程师：

• 核心工作：设计让 Agent 能可靠工作的环境
• 价值体现：Agent 吞吐量、代码质量、知识飞轮效应
• 技能要求：系统设计、自动化、规则编码、反馈闭环设计

这种转变意味着：未来的程序员，核心竞争力绝对不再是手写代码的速度，而是设计 Harness 系统的能力。你能设计出越好的 Harness，就能把模型的能力释放得越充分，你的生产力就越强。

结语：Harness Engineering 的未来

很多人会问：模型越来越强，以后会不会把 Harness 的能力都吸收了，Harness Engineering 就没用了？

LangChain 给出的答案是：不会。

就像现在大模型已经很强了，但 Prompt Engineering 依然非常重要一样，未来不管模型有多强，Harness Engineering 依然是做好 Agent 的核心。

因为 Harness 从来不止是补模型的短板，更是围绕模型的智能，设计一套能落地、可控制、符合业务需求的系统。模型再强，也需要有人告诉它该往哪走，该遵守什么规则，该怎么和你的业务系统结合——这些，都是 Harness Engineering 要做的事。

Harness Engineering 的本质，是把“人类写代码”的思维，改成“为 Agent 写代码”的思维。

这不是技术的堆砌，而是一种范式的转变。它要求我们从产品的角度思考：如何让 AI 更好地理解我们的业务？如何让 AI 的输出更符合我们的标准？如何让 AI 的工作更可预测、更可控？

当你开始用这种思维看待 AI Agent 时，你会发现：真正的瓶颈不在模型，而在你为它设计的环境。

而这，正是 Harness Engineering 的价值所在。