“Agent Harness”这个概念在 AI 工程圈突然火了起来。

它是一系列技术与部件的组合，负责把“桀骜不驯”的大模型，驯化成真正可长期运行、受控制、可治理的 Agent 系统。Harness 不会让 LLM 变得更聪明，但会让它更像一个系统。 正如给发动机配上变速箱、底盘、外壳等 — 它无法让发动机本身变得更强劲，但能让这辆车平稳、受控地跑起来。

我们将分两篇为大家深入拆解与展望 Harness 这套“系统外壳”。

01 为什么我们开始在意 Harness？

现在人人都在谈论 Agent，但你是不是还在把 Agent 当作一个“更聪明的聊天机器人”：给点 Prompt，给几个工具和技能，就能自动化地跑完整个任务流程。

或许在一些简单场景下它工作得还算不错，比如整理个最新行业资讯并发送到邮箱。但当你真正开始面临“生产化”落地，你才会意识到问题的严重性。

我们以较成熟、效能最显著的Coding Agent（编程智能体）为例。

如果你只是需要写一个算法函数、一个“贪吃蛇”游戏、个人 Todo 管理，甚至带有前后端的小型文档管理系统，只需要简单地给点提示和要求，AI 的完成度就会很高。

但是，当你面临以下情况时：

• 复杂的长程任务： 任务不再是一个孤立的函数或工具，而是跨越多个系统与模块、涉及复杂调用链路、独有的设计要求、私有技术栈的上百个步骤的工程。Agent 或许能写出语法正确的片段，却难以端到端地交付高质量成果。
• 庞大的遗留代码库： AI 瞬间会淹没在上万个源代码文件、复杂的层次与依赖关系、晦涩的业务逻辑中 — 每一行新代码都可能触动隐藏的回归风险。
• 从生成到交付的断裂： 特别是在企业级软件中，代码生成只是一个环节。更多的挑战还包括环境搭建、依赖安装、测试覆盖以及 CI/CD。一个断掉的链路，只会让 Agent 退化成一个需要人类频繁“擦屁股”的半成品。
• 确定性与安全性的考验： 在很多企业环境中，我们不能接受“幻觉”带来的逻辑漏洞，也不能容忍随意的敏感信息泄露。那么，如何在一个受控、安全且可重复的环境中来运行 Agent？

然后，问题就会接踵而至：

• 不稳定： 相同的任务，今天能跑通，明天可能就会发现它调用了错误的工具，但它总是会很“自信”地告诉你已经完成！
• 不可控： 你很难控制 Agent 完整地按照你的意图行事，并在过程中不会“跑偏”，特别是当你的任务有上百个步骤时。
• 难治理： 出了问题，你很难去追溯：AI 为什么这么做？哪些是幻觉生成？推理依据是什么？为什么不听我的指令？

大部分时候，你可能会抱怨：

“这个模型太差了，我需要更厉害的模型！”

但事实上，这并非总能奏效。强大的基础模型或许能让任务完成度从 30 分提高到 60 分，但很多时候，企业生产需要的是 90 分甚至满分。

这就是为什么我们需要 Agent Harness —

你需要一套用来驾驭马匹（Model）的马具（Harness）；它关注的不是让马变得更聪明，而是驯服它、约束它，让它不跑偏。

事实上，围绕如何构建能完成更复杂任务、更受控的 Agent，行业内一直有大量的实践与产品在展开。可以认为：“Harness”只是给我们一直在死磕的很多 Agent 工程化工作，取了一个贴切的统称。

02 从 Test Harness 到 Harness Engineering

在软件工程领域，Harness 可以追溯到为测试而搭建的一套模拟基础设施（Test Harness）：用 Stubs/Drivers等把被测组件包起来，在一个可控环境里驱动它、观察它、校验它。

Agent Harness 将这个逻辑平移到了 AI Agent 上：

由于大模型就像一个不可预测的“被测件”，为了让它可以长期稳定、可预测地运行并完成任务，必须给它一个控制“外壳”，把它真正转化为工作引擎（Agent）。而构建这个外壳的工作，就是“Harness Engineering”。

借助 LangChain 的观点来简化 Harness：

Agent = Model（智能） + Harness（系统外壳）

LangChain 认为：在一个 Agent 的组成部分中，如果它不是 Model（模型），那么它就属于 Harness。

理解了基本概念后，现在我们来回顾主流大厂的一些 Harness 实践与方法：

在这个演进时间线里，我认为最重要的几篇工程实践披露（推荐阅读）：

1. Anthropic： 发布了两篇针对 Long-running Agents（长任务 Agent）的实践方法，主要针对编程智能体。
2. OpenAI： 2月份发布了一篇关于 Codex 的 Harness 工程实践 — 揭秘 Agent 如何自主构建了一个百万行代码的应用。
3. LangChain： 剖析了其深度智能体 DeepAgents 在 Harness 上的实践方法。

通过对这些文章中 Harness 工程实践的深入理解，非常有助于我们：

• 理解 Harness 的内涵、方法与工具组合。
• 借鉴这些普遍来自 Coding Agent 的实践，更好地实施 AI Coding。
• 为未来构建真正可用的“生产就绪”的 Agent 系统打下基础。

下面我们来逐个解析这三家的 Harness 工程实践，建立更直观的认识。

03 Anthropic Harness实践：

长程任务的“脚手架”与“指挥官”

在 Anthropic 的 Harness 工程实践中，其核心任务是挑战 AI Coding 中最棘手的长程任务（Long-running tasks）。他们主要解决了两个痛点：

1. 当 Agent 需要在多次上下文窗口中处理长时任务时，会面临**上下文割裂 —**就像工程师轮班却不做交接。
2. 在“评估 -> 迭代 -> 完善”的工作流中，单个 Agent 会过于“自我感觉良好”，从而影响最终交付质量。

Anthropic 采用的核心 Harness 实践包括：

1. 任务拆分 -> 增量式完成 -> 做好交接

为了解决任务间“不交接”导致失忆的问题，其采用的方法是：

把长程编码任务拆分成多个功能列表，然后做增量式开发；并在此过程中强制做好任务之间的“交接”。

• 初始化 Agent： 负责初始化环境，制定详尽的任务计划，并准备进度表。
• 执行 Agent： 一次只专注完成一个子任务，完成后更新进度、任务摘要等。

通过这种方式，每当一个子任务（一次会话）完成，Agent 都会留下清晰的“痕迹”（进度、摘要、Git 日志）。从而在下一次子任务会话启动时，能够快速了解之前的工作状态，消除“换班失忆”，并通过上下文重置节约 Token 空间。

2. 独立评估器：让 Agent 跳出“当局者迷”

为了解决执行 Agent 自我感觉良好的问题，其采用的方法是：

引入一个与执行 Agent 隔离的评估 Agent，让其“批判”前者并反馈意见。

简单来说就是：

• 执行者负责干活，而评估者负责“挑刺”（两者会在 Harness 的框架下协商一份完成标准）。
• 如果评估 Agent 发现工作成果没有通过标准检测，则会生成一次具体的反馈，并交给执行 Agent 开启下一次迭代。

通过这种由 Harness 编排的外部反馈机制形成的闭环，能让长程任务的成功率实现极大的提升。

小结：

Anthropic 设计的这套增量任务推进、独立评估 Agent 以及反馈闭环机制，是典型的 Harness 工程。其使命是与模型一起，构建出一套容错、纠错并自动化的复杂任务系统，让大模型在预设的轨道上高质量地工作。

04 OpenAI Harness 实践：

百万行代码后的“自动驾驶系统”

如果说 Anthropic 关注的是如何让 Agent 在长任务中不迷路，那么 OpenAI 在《Harness engineering: leveraging Codex in an agent-first world》这篇文章中披露的实践，则展示了如何通过严谨的 Harness 约束，实现 0 行人工代码构建出百万行规模的企业应用。

在这个实践中：OpenAI 从一个空的 Git 仓库开始，由 Codex 在五个月内完成了一个百万行代码的内部软件产品。不仅是代码，包括仓库内的各种文档、CI/CD 工具、配置都由 Agent 生成。人类被禁止参与具体的代码编写，其核心职责转变为：

明确需求、设计环境、设计反馈/迭代回路、优化控制等。

— 这正是 Harness Engineering 的核心范畴。在这个项目中，OpenAI 的 Harness 实践可以总结为以下几点：

1. 上下文工程：基于“动态地图”的注入

OpenAI 放弃了早期“给 Agent 塞一个 1000 页的规则文档（AGENTS.md）”的粗暴做法，因为巨大的指令会挤占有限的上下文窗口，导致模型注意力涣散。他们的解法是构建一个**“Agent-first 的层次化知识库”**：

• 目录（索引）化： AGENTS.md 仅保留约 100 行，仅作为上下文的“地图”，指向深层次的架构、设计与参考文档。
• 知识库检修 Agent： 专门设置一个后台 Agent，定期扫描文档。如果发现过时或与代码偏离，会自动提交 PR 修正文档，确保上下文的新鲜度。

2. 执行闭环：让 Agent 能持续自我驱动

OpenAI 构建了一套让 Agent 可以独立完成开发闭环的执行环境。在这套沙箱中，Codex 不仅能写代码，还可以自主启动应用、操作浏览器、查看日志与指标、复现开发中的 Bug，并验证修复效果。在这种环境下，一个任务可以持续运行数小时，在无人干预的情况下完成从问题定位到修复提交的全过程。

这与Anthropic 的评估器机制类似：自我验证并迭代完善。

3. 架构约束：用“刚性外壳”防止系统失控

在百万行代码的体量下，Agent 极易产生架构与设计漂移。OpenAI 的做法不是依靠人工 Review，而是施加可执行的架构约束规则：

• 固定系统分层架构，严格限制代码的层次与依赖方向。
• 自定义 Linter（静态检查工具）和结构测试，禁止非法依赖。
• 强制执行数据边界校验、日志规范、命名规则等。 核心思想是：不依赖于人的肉眼检查，而是让系统自己保证 Agent “不乱写”。

4. 垃圾回收：持续的自我质量维护

在长期的编码任务中，Agent 可能会在后续工作中复制早期质量不佳的代码模式，随着时间的推移会导致整个系统架构退化。

OpenAI 引入了一种持续自动化的代码治理机制： 他们定义了一系列“黄金原则”（比如优先使用标准库），并通过后台定期的自动任务来扫描代码库，识别不好的代码模式，并主动发起重构。

这种类似于编程语言中“垃圾回收（GC）”的机制，让代码库能够持续、小步、自动地进行自我质量维护。

小结：

OpenAI 的 Harness 工程的一个重要思想是 —

想要获得极高的 Agent 自主权，就必须极大地限制其自由度。

这套由上下文、反馈闭环、物理约束与持续治理组成的 “Harness”，让模型能在约束下持续构建百万行级系统的执行体。

05 LangChain Harness实践：

DeepAgents 编码能力的跃升

LangChain 提供了一个极具说服力的定量案例：在底层模型（GPT-5.2-Codex）完全不变的情况下，仅仅通过优化 Harness 工程，就让他们的 DeepAgents 在 Terminal Bench 2.0 测试集上的得分排名从 Top 30 直冲 Top 5。

LangChain 认为，大模型的能力是“参差不齐”的。Harness 工程的目的就是通过重塑外部环境，将这种不稳定的模型智能塑造成面向目标的可靠系统。考虑到 LangChain 并非底层模型厂商，其实践对于广大的 Agent 开发者/应用层企业更具普遍的借鉴意义：

1. Trace（追踪）分析技能：持续改进的基础

LangChain 将对运行轨迹（Trace）的错误分析本身做成了一个 Agent Skill。 它会自动抓取 LangSmith 记录的 Trace 信息，诊断模型是在推理、工具调用还是超时上失败，并生成诊断建议。在人类工程师的辅助下，对 Agent 系统的中间件或提示词作针对性的修改，避免盲目试错。

本图片来自Langchain官方

2. 强制“构建-验证-改进”闭环：打破模型的懒惰

最初的 Coding Agent 存在一个通病：写完代码，自己看一眼觉得不错，就直接结束任务了。为了让其能够自我提升，LangChain 采用了“强制拦截”策略：

• 在系统提示中强制规定了“规划-构建-验证-修复”的闭环步骤。
• 利用 LangChain 的 Middleware（中间件）机制，在 Agent 企图结束任务前设置“退出钩子” ，强制要求智能体回答：编写测试了吗？覆盖边缘情况了吗？只有跑通测试并对比原始需求无误，才允许任务结束。

3. 退后一步：打断思考“死循环”

在开发 Agent 的过程中，我们经常会遇到这种情况：Agent 在尝试自我修复时，会陷入“局部修改->报错->再局部修改”的死循环。

LangChain 的防卡死方案是：当一个 Middleware 检测到模型反复修改同一个文件达到阈值（如 10 次）却依然报错时，会强制向上下文注入提示，类似于：

“你已经在这里卡了很久了，请退一步，重新考虑你的整体方案。”

4. 推理算力的“三明治”分配策略

在有严格时间限制（Timeout）的任务中，如果把模型的推理能力一直开到最大（如全部使用 gpt 模型 xhigh 模式），会导致频繁超时失败。

LangChain 实施了一种动态的算力调度策略：在任务规划阶段和最终的代码验证阶段设置使用最高推理，而在中间的执行构建阶段使用常规模式。这种精细化的预算调度，可以提高长任务的成功率。

本图片来自Langchain官方

当然，如果你是在多模型环境下，也可以采用动态的模型调度策略，比如：规划与验证使用强模型，而实施使用一般的模型。

小结：

从 LangChain 的实践中可以看出，Harness 工程的价值，就是设计出能够包容、检测并纠正模型自身缺陷的脚手架 — 不指望模型自己变聪明，而是要为其准备并交付足够的上下文与控制流，使其真正能够自主地完成工作。

06 从散装 Agent 到标准化的 Harness 组件

纵观这几家行业头部披露的工程实践，我们可以清晰体会到 Agent Harness 的核心内涵，即：用系统工程来兜底模型能力的不足。

同时也能看到，尽管各家的切入点不同，但还是能提炼出 Harness 工程中的一些通用实践：比如精细化的上下文工程、基于验证与测试的闭环等。

在实际应用中，不同类型的业务场景也需要调整不同的 Harness 策略：

• 比如 Coding Agent，借助“测试驱动”的反馈闭环来动态纠正行为是可行的；但在其他生产任务中，你可能就无法“测试驱动”。
• 而对于拥有庞大代码库和领域知识的大型行业软件，Harness 的重心则需要考虑如何将企业私有的架构、代码的理解注入。
• 对于处理内部敏感业务流程的通用 Agent，Harness 则又需要倾斜于安全边界、权限管控与人工审批拦截等。

没有放之四海而皆准的 Harness，只有最契合你业务形态的 Harness。

不过我们仍然可以把 Harness 拆解成标准化组件，以便按需组装。结合前文的一些实践与方法论，这里将 Harness 划分为以下 7 大核心组件，其中每个组件都有它针对的问题与实践方法：

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】