AI-Agent-的-Harness-机制学习思考.md31.5 KBit/ai/AI-Agent-的-Harness-机制学习思考.md
> OpenAI的实验揭示了一个革命性趋势：3人工程师小组仅用5个月就通过AI Agent构建了百万行代码的产品，效率跃升300%。Harness Engineering正掀起软件工程的第三次范式转移——用约束换取AI自主权。本文深度拆解了OpenAI、Anthropic等顶尖机构的实践案例，呈现可立即落地的四大核心模块，带你看懂如何用'缰绳'驾驭AI这匹烈马。
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 的价值所在。
本文由 @要成为产品小李 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议