引言：为什么模型之外的世界更重要

2026 年初，LangChain 做了一个实验：只改了包裹 LLM 的基础设施，模型权重完全没动，在 TerminalBench 2.0 上的排名从 30 名开外直接跳到第 5。另一个研究项目让 LLM 自己优化基础设施，通过率达到 76.4%，超过了人工设计的系统。

这两件事指向同一个结论：当模型本身的智能已经足够强大时，真正决定它能走多远的，是包裹在模型外面的那层系统——Agent Harness。

你也许搭过一个聊天机器人，接入了 ReAct 循环，挂了几个工具，演示效果不错。但一旦尝试把它做成生产级产品，问题就来了：模型记不住三步前做了什么，工具调用静默失败，上下文窗口被垃圾填满。问题不在模型，而在模型周围的一切。

什么是 Agent Harness

从 CPU 类比理解 Harness

Beren Millidge 在 2023 年的文章《作为自然语言计算机的脚手架 LLM》里给了一个精准的类比：裸 LLM 是没有内存、没有硬盘、没有 I/O 的 CPU。上下文窗口是内存，快但有限；外部数据库是硬盘，大但慢；工具集成是设备驱动；Harness 是操作系统。

正如 Millidge 所写：我们重新发明了冯·诺依曼架构，因为这是任何计算系统的自然抽象。

Harness 的正式定义

Anthropic 在 Claude Code 文档里直接写明：SDK 就是「驱动 Claude Code 的 agent harness」。OpenAI 的 Codex 团队也用同样的框架，把「agent」和「harness」视为等价概念，专指让 LLM 变得有用的非模型基础设施。

LangChain 的 Vivek Trivedy 给出了一个清晰的定义：如果你不是模型本身，你就是 harness。

很多人容易混淆的区分在这里：「agent」是涌现出来的行为，是用户交互的那个有目标、会用工具、能自我纠正的实体。Harness 是产生这种行为的机器。当有人说「我做了一个 agent」，他们其实是做了一个 harness，然后把它对准了一个模型。

三个工程层级

围绕模型有三个同心圆层级：

提示词工程：负责设计模型接收的指令。

上下文工程：管理模型看到什么、什么时候看到。

Harness 工程：包含前两者，再加上完整的应用基础设施：工具编排、状态持久化、错误恢复、验证循环、安全执行、生命周期管理。

Harness 不是提示词的包装层，而是让自主 agent 行为成为可能的完整系统。

Harness 的核心设计模式

翁荔（Lilian Weng）在她的博客《Harness Engineering for Self-Improvement》中系统性地梳理了 Harness 的三种核心设计模式。这些模式构成了构建可靠 Agent 系统的基础。

模式一：工作流自动化

给模型定义一个可以操作、测试、迭代的工作流，是实现自动化的关键设计。Karpathy 的 autoresearch 仓库是一个简洁的示例。常见的工作流遵循一个目标导向的循环：规划、执行、观察/测试、改进，再次执行，直至目标达成。

这个循环不是静态的 prompt 模板，而是一个「运行时」，模型可以在其中分析自己的执行轨迹和失败案例，然后迭代。

python
简化的 ReAct 循环伪代码
def agent_loop(task, max_steps=20):
    context = [{"role": "system", "content": build_system_prompt()}]
    context.append({"role": "user", "content": task})
    
    for step in range(max_steps):
        response = llm.invoke(context)
        
        if response.has_tool_calls():
            for tool_call in response.tool_calls:
                result = execute_tool(tool_call)
                context.append({"role": "tool", "content": result})
        else:
            # 没有工具调用，视为最终答案
            return response.content
    
    return "Max steps reached."

模式二：文件系统作为持久化记忆

在长周期 Agent 系统中，一个反复出现的模式，是用简单的方式管理丰富的状态和产出物。Harness 不应该把整个工作流和所有日志都塞进上下文；相反，它应该把持久化状态保存在文件中。

在长周期的 Agent 执行过程中，实验日志、代码 diff、论文摘要、报错记录、过去的执行轨迹这些产出物，长度往往远超模型训练时习惯的上下文窗口。

学会通过 bash 命令读写和编辑文件系统，是 LLM 的一项基础能力。因此，用文件这种简单形式管理持久化记忆，会自然地随着核心模型能力的提升而受益。

模式三：子 Agent 与后台任务

一个 Harness 可以派生多个子 Agent 并行执行，同时监控后台任务。这在主 Agent 需要搜索多个假设、并发跑多组实验，或者把独立子任务委派出去而不污染主上下文时很有用。

关键设计选择是让并行过程显式且可检查。如果子 Agent 的产出只存在于临时的聊天上下文里，它们很快就会过期、被隐藏起来；但如果存成文件、日志和状态记录，模型就能在中断后恢复，并对自己的执行历史进行推理。

生产级 Harness 的 12 个核心组件

综合 Anthropic、OpenAI、LangChain 和更广泛的实践者社区，一个生产级 Agent Harness 包含以下 12 个独立组件。

组件功能描述关键设计要点

1. 编排循环实现思考-行动-观察（TAO）循环往往只是一个 while 循环，复杂性藏在循环管理里 2. 工具Agent 的手，以 schema 形式定义注册、验证、沙盒执行、结果捕获 3. 记忆短期（对话历史）和长期（跨会话持久化）分层管理：索引、按需拉取、搜索访问 4. 上下文管理避免上下文腐烂和「迷失在中间」压缩、观察屏蔽、即时检索、子 Agent 委托 5. 提示词构建组装模型每一步实际看到的内容分层：系统提示、工具定义、记忆文件、对话历史 6. 输出解析处理模型返回的结构化工具调用原生 tool_calls 对象，Pydantic 约束 7. 状态管理跟踪 Agent 的当前状态检查点、中断恢复、时间旅行调试 8. 错误处理区分瞬时错误、LLM 可恢复错误等重试、降级、人工介入 9. 护栏与安全输入/输出/工具三层护栏权限分离、断路器、审计日志 10. 验证循环玩具 demo 和生产 Agent 的分水岭规则反馈、视觉反馈、LLM 评判 11. 子 Agent 编排派生并行执行单元Fork、Teammate、Worktree 模型 12. 生命周期管理启动、监控、终止、清理超时、预算、中断处理

编排循环的逐步演练

提示词组装：Harness 构建完整输入：系统提示 + 工具 schema + 记忆文件 + 对话历史 + 当前用户消息。重要上下文被放在提示词的开头和结尾（来自「迷失在中间」的发现）。

LLM 推断：组装好的提示词发送给模型 API，模型生成输出 token：文本、工具调用请求，或两者都有。

输出分类：如果模型只输出文本且没有工具调用，循环结束。如果请求了工具调用，进入执行。

工具执行：对每个工具调用，Harness 验证参数、检查权限、在沙盒环境中执行、捕获结果。

结果打包：工具结果被格式化为 LLM 可读的消息。错误被捕获并作为错误结果返回，让模型可以自我纠正。

上下文更新：结果追加到对话历史。如果接近上下文窗口限制，Harness 触发压缩。

循环：返回第 1 步，重复直到终止。

Harness 如何优化：从上下文到自我改进

Harness 系统中被优化的对象大致经历了这样的演进：指令提示词 → 结构化上下文 → 工作流 → Harness 代码 → 优化器代码。随着模型变得越来越智能，我们也在朝着更复杂的优化目标和更通用的方法迈进。

上下文工程

Agentic Context Engineering (ACE) 把上下文当作一本不断演化的「操作手册」，而不是一段越写越长的提示词。它维护一份由要点组成的上下文手册，每条要点都有编号和说明，靠三个组件运作：

生成器：产出任务执行轨迹，参照现有的要点。

反思器：从成功和失败的轨迹里提炼洞察。

策展人：把这些洞察更新成增量的、条目化的新条目。

ACE 的一个关键设计是，策展人不会重写整段 prompt，而是只输出一批结构化的条目（编号加说明），再用确定性的逻辑合并进上下文手册。

Meta Context Engineering (MCE) 往前多走一步：把「怎么管理上下文的机制」和「上下文里具体装什么内容」拆开，在元优化层面做技能演化，在基础层面做上下文优化。

工作流设计

工作流设计这一层，可以由领域专家手工搭建，也可以被当作搜索问题来优化。

AI Scientist 搭了一条从提出研究想法、写代码、跑实验、分析结果、写论文，到执行同行评审的完整流水线。

AFlow 把工作流表示成一张图，用蒙特卡洛树搜索去寻找更优的图结构。

自我改进型 Harness

到这一层，模型不只是使用 Harness 完成任务，而是开始分析 Harness 哪里不好，并提出对 Harness 的修改。

Self-Harness 的循环非常清楚：

弱点挖掘：系统先收集 Agent 执行任务时留下的轨迹，包括工具调用、错误日志、失败结果、验证器反馈等。然后从中挖出反复出现的失败模式。

Harness 提案：模型基于这些失败模式，提出对 Harness 的小范围修改。重点在于「小范围」和「可验证」。

提案验证：候选修改不能直接合入，而是要经过测试验证。只有确认它确实提升表现，并且没有引入明显回归，才会成为下一版 Harness 的一部分。

这套流程在 MiniMax M2.5、Qwen3.5、GLM-5 等不同模型上跑 Terminal-Bench-2 时，确实学出了针对不同模型薄弱点、各不相同的 Harness 配置。

进化搜索

如果说 Self-Harness 更像是从失败中修补自己的工作系统，那么进化搜索则是把 Harness 直接变成一个可搜索对象。

Darwin Gödel Machine (DGM) 直接让一个 coding agent 去修改自己的 Harness 代码仓库本身。实验里，用 Claude 3.5 Sonnet 做基座模型，从简单的初始配置出发，DGM 进化出来的 agent 效果惊人：

在 SWE-bench Verified 上的表现从 20% 提升到 50%

在 Polyglot 上从 14.2% 提升到 30.7%

达到甚至超过了人工设计的 agent

这说明，即使不动模型权重，Harness 本身也已经可以成为能力提升的搜索空间。

本体驱动的可控执行

绝大多数 Harness 实践仍停留在工程拼接层面——写 Prompt、列规则、搭流程、做权限控制。这些手段在简单场景下有效，但一旦进入复杂业务，就暴露出同一个深层问题：约束是「外加的」，语义是「隐式的」，合规依赖模型对规则的理解，而模型的理解本身不可靠。

本体的切入点

本体的不同之处在于：它不试图「拦住」Agent，而是从一开始就定义好它的行为空间。约束不是外加的围栏，而是内建于业务结构的骨架。

传统本体主要解决「是什么」的分类问题，而 Knora 平台在本体层引入了 Action 和 Logic，把本体从静态知识描述变成了可执行的业务规范，可以直接驱动 Agent 的工具调用和流程编排。

架构约束：从「外加围栏」到「内建骨架」

约束的执行发生在 Agent 输出之后、操作落地之前：系统将 Agent 的执行意图拿回来与本体做比对，如果违反了既定规则，直接打回重推，不会静默放行。校验依据是结构中可追溯的具体节点和关系路径，结论是确定性的，不依赖模型理解。

上下文工程：从「补记忆」到「重构记忆方式」

本体的切入点不同：企业中的数据、流程和关系本来就不是线性的，而是一个复杂的关联网络。本体所做的，是把这种关系显式地表达出来，构建一个可查询、可演化的业务语义网络。

这个结构为上下文管理带来三项实质改善：

精准检索替代全量注入：在 Agent 启动前，认知引擎从本体中抽取与当前任务相关的语义子图，将最相关的上下文动态注入推理语境。

一致性保障：业务知识由统一的语义网络管理，Agent 始终基于最新一致的信息推理。

跨任务复用：同一语义结构可服务于不同任务的 Agent，无需为每个场景重新组织上下文。

反馈闭环：从「主观评估」到「可追溯校验」

本体提供了一条更直接的路径：不依赖主观评估，而是基于结构进行客观校验。企业中大量的判断本质上是可以被规则化的——是否超出额度、是否满足前置条件、是否符合流程逻辑。这些判断不需要「理解」，可以直接验证。

反馈闭环的另一个价值，是让本体本身持续进化。本体与 Agent 之间不是单向的约束关系：本体定义 Agent 的能力边界，Agent 在真实执行中接触大量业务数据，这些数据可以反哺本体——识别尚未覆盖的概念和关系，标记推理路径中频繁出错的位置，指导本体的修正和迭代。

成本控制与 Token 优化

Token 成本失控是 Agent 落地中最现实的挑战之一。一个每步成功率 99% 的 10 步流程，端到端成功率仍然只有约 90.4%。错误会快速累积，无效的 Token 消耗会成倍放大。

Token 浪费的三个源头

重复注入：每一次都把一大堆规范、背景、代码框架全部塞进去，没有区分当前任务到底需要什么。

知识没有分层：需求阶段把开发规范给进去了，开发阶段又把过时的历史经验塞进去，知识不精准，读错了还要返工。

没有过程资产的复用：当前对话框关掉，下一次打开还得重新来一遍。

降本增效的实践路径

毛卓（碧桂园服务技术总监）分享了一个惊人的数据：他们的月度成本下降了 88%，同时开发效率提升了 3 到 4 倍。核心做法是：让产品、开发、测试全部投入需求撰写和评审，只留四五个人执掌 AI Coding 工具。需求写精准了，一把喂给 AI，效率就大幅提升了。

况雨平（深圳价值网络科技技术副总监）的团队构建了一套 Spec-First 支撑的 AI Coding Harness 体系，把优秀工程师的经验沉淀为标准化流程节点。不是简单地减少模型调用，而是让每一次调用都更接近有效交付——少写 Bug、少返工、知识可复用，整体成本一定是下降的。

挑战与未来方向

评估器太弱太模糊

现在能跑通自我改进循环的，基本都是写代码、解数学题这类有明确、快速、客观反馈的任务。而研究品味、创新性、长期科研价值，几乎没法量化。

上下文和记忆的生命周期问题

任务越自主、越独立，需要管理的记忆就越多。这件事未来可能会成为智能本身的一部分，而不只是停留在软件系统层面。

多样性坍缩

进化和强化学习类的循环容易反复利用已知的高回报模式，如果没有额外机制去防止，种群会逐渐坍缩成同一种方案的变体。

Reward Hacking

自我改进循环会优化给定的任何信号——奖励来自单元测试，模型可能就去过拟合测试；来自评委模型，就可能学会针对性地「讨好」评委；来自榜单分数，就可能去利用榜单本身的漏洞。

长期健康和短期成功之间的矛盾

以 coding agent 为例，它们已经能实实在在提升软件工程的日常生产力，但优化目标大多还是短期的——能不能把眼前任务做完，而非能不能保护一个由成百上千工程师共同维护的代码库的长期健康。

人类的角色

人类不会被踢出循环，而是要往「环外」移动——在合适的时机、合适的抽象层级上提供监督。这也是系统设计时需要考虑清楚的问题。

结语

过去，大模型竞争主要看参数、数据、算力和推理能力。但现在，另一个变量已经越来越难被忽略：Harness。

同一个模型，放进不同 Harness 里，可能表现出完全不同的能力——这件事已然从少数人的观察成为了行业共识。

从翁荔的博客也能看出，「AI 自进化更现实的工程入口是什么」，将会是下一阶段要讨论的重点。Harness 工程将朝着「元方法论」的方向演进：优化的是「获得更好答案的机制」本身，而不只是答案。Harness 系统本身会成为优化目标，规则会越来越少靠硬编码的启发式，越来越多靠通用机制。

最终，很多 Harness 层的改进可能会被内化进核心模型的行为里，但与外部上下文和工具的接口应该会保留下来。这个模式在 prompt engineering 的历史上已经出现过一次比较温和的版本：随着指令微调和模型推理能力的提升，手工 prompt 技巧变得不那么核心，但指定目标、约束、上下文和评估的需求，并没有消失。

FAQ

什么是 Agent Harness，它和 Agent 框架有什么区别？ Agent Harness 是包裹在大语言模型之外的完整软件基础设施，包括编排循环、工具、记忆、上下文管理、状态持久化、错误处理、安全护栏等。而 Agent 框架（如 LangChain、LangGraph）是构建 Harness 的工具集。Harness 是运行时的完整系统，框架是构建这个系统的脚手架。更深入的理解可参考 AI Agent 与多智能体。

Harness 工程如何解决 Agent 的「可控性」问题？ Harness 通过三层机制实现可控：架构约束（用工具集和权限系统限定行为边界）、上下文工程（用结构化上下文管理信息输入）、反馈闭环（用规则引擎和验证器校验输出质量）。本体驱动的方法更进一步，将业务规则显式建模为可查询、可校验的结构，使约束不再依赖模型对自然语言的理解。相关实践可参考 工作流与编排。

Harness 的自我改进真的能提升模型能力吗？ 是的。实验证明，即使不动模型权重，只优化 Harness 层也能带来显著提升。Darwin Gödel Machine 用 Claude 3.5 Sonnet 作为基座，通过让模型修改自己的 Harness 代码，在 SWE-bench Verified 上的表现从 20% 提升到 50%。这说明 Harness 本身已经可以成为能力提升的搜索空间。更多关于模型部署与优化的内容可参考 模型部署。

生产级 Harness 中最容易被忽视的组件是什么？ 验证循环和错误处理。一个每步成功率 99% 的 10 步流程，端到端成功率只有约 90.4%。Claude Code 创建者 Boris Cherny 指出，给模型一种验证自身工作的方式能将质量提升 2 到 3 倍。错误处理需要区分瞬时错误、LLM 可恢复错误、用户可修复错误和意外错误，并分别制定策略。

Token 成本失控的主要原因是什么？ 三个主要源头：重复注入（每次把全部规范塞进去）、知识没有分层（不区分当前任务需要什么）、没有过程资产复用（关掉对话框就丢失所有上下文）。解决方案包括：精准的需求输入、知识分层管理、以及 Spec-First 的流程化方法。

Harness 工程未来的发展方向是什么？ 朝着「元方法论」的方向演进——优化的是「获得更好答案的机制」本身，而不只是答案。Harness 系统本身会成为优化目标，启发式规则减少，通用机制增多。同时，许多 Harness 层的改进最终会被内化为核心模型行为，但与外部上下文和工具的接口应当保留。