Harness架构揭秘：秒懂与ReAct、CoT等模式的区别

1. 先把概念说透：Harness 到底是什么？

很多人第一次听到 Harness，会以为它是一种新的 Agent 推理套路。
其实不是。

Harness 不是一种“思考方法”，而是一层“运行控制层”。

说得再直白一点：

• 模型负责想
• Harness 负责让它真的能做
• 并且做得稳定、可控、可追踪、可恢复

LangChain 对这个概念说得非常明确：模型本身提供智能，而 Harness 把这种智能变成真正可用的工作能力；模型之外那些负责状态、工具、执行、记忆、治理的代码和机制，都属于 Harness。Microsoft 也把它定义为模型推理连接真实执行的那一层。

1.1 为什么会有 Harness 这层东西？

因为大模型虽然会推理、会生成、会对话，但它天生并不会这些生产级能力：

• 长时间维护任务状态
• 安全调用工具
• 访问外部环境
• 管理执行权限
• 保存中间结果
• 失败后重试和恢复
• 压缩上下文并持续推进任务

这些能力，并不是“模型自己长出来的”，而是 Harness 补上的。LangChain 明确提到，模型默认并不会开箱即用地维护持久状态、执行代码、访问实时信息或搭建环境；这些都属于 Harness 的职责范围。

Agent 的三层结构：最中间是模型，负责理解、推理和生成；外层是 Harness，负责工具调度、上下文管理、记忆、状态、安全、审批和观测；最外侧是真实环境，包括浏览器、代码执行器、文件系统、数据库和外部 API。这个图的重点不是“模型多聪明”，而是说明Agent 真正能落地，靠的是模型外面这套运行骨架。
Harness 不是模型的替代品，而是模型的工程外壳。
没有这层外壳，模型再强，也往往只能停留在“会回答”；有了 Harness，它才可能升级成“会执行任务、会调用工具、会记住上下文、会在失败后继续推进”的生产级 Agent。这个理解和 LangChain、Microsoft 对 agent harness 的定义是一致的。

1.2 Harness 到底是做什么的？

你可以把 Harness 理解成 Agent 的“外层操作系统”。

它通常负责六件事。

1.2.1 管上下文

该保留什么历史、删掉什么历史、什么时候做摘要、什么时候补充外部检索内容，这都归它管。长任务如果没有上下文治理，做到一半就会“记忆混乱”。

1.2.2 管工具

什么工具能调用、什么时候调、参数怎么传、失败了怎么处理、结果怎么回填，都要由 Harness 来兜底。

1.2.3 管状态和记忆

会话状态、任务阶段、中间产物、长期记忆，这些如果不保存，Agent 每一轮都像“失忆重来”。

1.2.4 管执行环境

浏览器、shell、文件系统、数据库、代码沙箱，这些都不是模型自己原生具备的，而是 Harness 提供的执行载体。

1.2.5 管安全和审批

哪些命令能跑，哪些文件能改，哪些动作需要人工审批，企业里这部分经常比“推理能力”本身更重要。

1.2.6 管观测和回放

为什么调用这个工具、为什么失败、哪一步出错、能不能回放执行轨迹，这些都直接决定系统是否可维护。近期关于 AI Agent Harness 的研究，也把上下文管理、工具系统、安全机制和编排机制列为高频的架构维度。

2. 为什么说 Harness 不是 CoT、不是 ReAct、也不是 Reflection？

这一步是全文最关键的地方。

因为很多人会把这些词混成一团，感觉都在讲 Agent。
但它们其实不在一个层级上。

• CoT：是一种推理方式
• ReAct：是一种推理 + 行动方式
• Plan-and-Execute：是一种规划 + 执行方式
• Reflection / Reflexion：是一种反馈 + 复盘方式
• Harness：是把这些方式装进真实系统里的运行框架

也就是说，前四个更像是在回答：

“模型应该怎么思考、怎么行动、怎么修正？”

而 Harness 在回答的是：

“这些思考和行动，怎样才能在真实环境里长期稳定运行？”

3. CoT：先想清楚，再一次性回答

CoT 全称是Chain-of-Thought。
它最核心的思想就是：让模型先产出中间推理步骤，再给最终答案。

经典论文指出，生成中间推理过程，能够显著提升复杂推理能力，尤其在算术、常识和符号推理任务上表现明显。

CoT 的运行方式很简单：

用户提问 → 模型分步推理 → 一次性输出结果

它的优点很明显：

• 简单
• 成本相对低
• 不依赖复杂工具系统
• 对推理题、解释题很友好

但它也有天然短板：

• 它通常是开环
• 中间推理错了，后面可能一路错下去
• 它默认不去主动调用工具
• 它不擅长复杂外部交互任务

所以 CoT 更适合“脑内解决”的任务，而不适合那种需要不断观察环境、边做边修的长流程任务。

用户问题进入模型后，模型先进行分步推理，再一次性给出答案。它的重点是“中间推理链条”，但这个链条基本发生在模型内部，不强调外部工具交互，也不强调执行反馈。
CoT 本质上是一种“先想后答”的单轮推理策略。
它擅长解题、解释、分析，但不擅长处理需要实时观察、工具交互和多阶段执行的复杂任务。所以 CoT 是很多 Agent 思路的基础，但它本身还不算完整的生产型 Agent。

4. ReAct：边想边做，边做边看结果

ReAct 的全称来自Reasoning + Acting。
它最经典的点就在于：把“推理”和“行动”交错起来，不再是只在脑子里想。

ReAct 论文明确提出，模型会交替生成 reasoning traces 和 task-specific actions；推理帮助更新计划，行动帮助连接外部知识源或环境。论文还指出，在问答任务中，ReAct 通过与外部知识源交互，能缓解单纯 CoT 容易出现的幻觉和错误传播。

它的节奏通常是：

Thought → Action → Observation → Thought → Action

你可以把 CoT 和 ReAct 这样理解：

• CoT像坐在桌前做题
• ReAct像一边想，一边查资料，一边试操作，再根据反馈继续推进

所以 ReAct 非常适合：

• 搜索问答
• 工具调用
• 浏览器操作
• API 调用
• 环境交互类任务

Thought 负责思考下一步，Action 负责执行动作，Observation 负责接收环境反馈，然后再进入下一轮 Thought。这个结构最大的特点是不是一次性想完，而是每一步都根据外部反馈动态调整。
ReAct 比 CoT 更像真正的 Agent 雏形。
因为它已经不满足于“脑内推理”，而是开始借助外部环境来校正自己的下一步动作。这也是为什么 ReAct 到今天依然是很多工具型 Agent、浏览器 Agent、代码 Agent 的基础循环。

5. Plan-and-Execute：先把全局路线画出来，再逐步执行

Plan-and-Execute 的核心思想，不是边走边看，而是先规划，再执行。

LangChain 对这种架构的说明很直接：它把任务拆成两个角色，一个是 Planner，先制定步骤；另一个是 Executor，按步骤逐一完成。LangChain 后续又把这种“计划型 Agent”扩展到了更多变体，比如 ReWOO、LLMCompiler 等。

它的典型流程是：

用户目标 → 规划器先列出步骤 → 执行器逐步完成 → 必要时局部重规划

和 ReAct 相比，它的最大特点是：

• ReAct：更像边走边看地图
• Plan-and-Execute：更像先把全程路线画好，再开始动手

这使它更适合：

• 长任务
• 多阶段任务
• 目标明确但过程较复杂的任务
• 需要把大任务拆成多个小任务的场景

当然，它也有代价：

• 前期规划如果偏了，后面会被连带影响
• 调用链可能更长
• 运行成本通常高于简单 CoT

但对于复杂任务，它比“想到哪做到哪”的模式更稳。

Plan-and-Execute 解决的不是‘会不会做一步’，而是‘能不能把长任务拆开做’。
当任务跨越多个阶段、需要多个工具协同、还要避免上下文越来越乱时，这种“先规划、后执行”的结构通常比纯 ReAct 更容易管理。

6. Reflection：不是先想，而是做完以后复盘再修正

Reflection 在 Agent 里常被泛指“反思式闭环”，学术上很有代表性的工作是Reflexion。

Reflexion 的核心不是重新训练模型参数，而是用语言化反馈来帮助 Agent 从失败中学习。论文给出的思路是：Agent 在一次任务尝试后，根据反馈进行 verbal reflection，把反思文字写进 episodic memory，下一轮再利用这些经验改进决策。

它的流程更像：

执行任务 → 得到反馈 → 反思失败原因 → 记录经验 → 再试一次

所以 Reflection 类架构特别适合：

• 允许重试的任务
• 代码生成与测试
• 有明确反馈信号的环境
• 对正确率要求更高的复杂任务

这里要注意一个关键区别：

• Plan-and-Execute关注的是“开始之前如何拆任务”
• Reflection关注的是“做坏之后如何修正”

这是两个完全不同的重点。

Agent 先执行任务，获得反馈后不直接结束，而是先做一次反思总结，把经验写入记忆，再进入下一轮尝试。它的重点不是“多想一步”，而是“从失败中提炼经验，下一次别再犯同样的错”。
Reflection 真正提高的，不只是单次输出，而是多轮尝试中的成功率。
它很像给 Agent 增加了一个“事后复盘”的能力。对于代码、测试、复杂操作任务，这种机制往往比单纯加长 prompt 更有效。

7. Harness 和前面四种架构，到底是什么关系？

说到这里，就可以把最核心的一句话讲出来了：

CoT、ReAct、Plan-and-Execute、Reflection，更像是 Agent 的认知策略；
Harness，则是把这些认知策略接进真实系统的运行骨架。

也就是说：

• CoT 负责“怎么推理”
• ReAct 负责“怎么边推理边行动”
• Plan-and-Execute 负责“怎么先拆任务再执行”
• Reflection 负责“怎么根据反馈复盘修正”
• Harness 负责“怎么把这些能力接到工具、记忆、状态、安全、审批、日志和执行环境中”

这也是为什么最近关于 Agent Harness 的研究，不再把它看成某个单点技巧，而是把它当成一组架构决策：包括子代理结构、上下文管理、工具系统、安全机制和编排方式。

8. 为什么说真正的生产级 Agent，最后几乎都会走向 Harness 化？

因为 Demo 和生产系统，完全不是一回事。

一个简单 Demo 往往只需要：

• 一个模型
• 几个工具
• 一段 Prompt
• 一个基础循环

但只要进到真实业务里，问题立刻就来了：

• 上下文越来越长，怎么裁剪
• 工具调用失败，怎么恢复
• 任务做一半断了，怎么续跑
• 改文件、跑命令，怎么审批
• 多轮任务怎么保存中间状态
• 出错了怎么回放
• 多 Agent 协同时，谁调谁、谁持久化、谁负责安全边界

这些都不是单纯靠 Prompt 能解决的。
这也是 LangChain 最近不断强调 Harness 的原因之一；Microsoft 也把 context management、approval flows、filesystem access 放进了 Agent Harness 的核心能力范围。

换句话说：

模型决定上限，Harness 决定落地。

9. 企业里到底该怎么选？

如果你做的是简单推理问答，优先 CoT。因为轻、快、够用。

如果你做的是搜索、工具调用、环境交互，优先 ReAct。因为它天然适合“边观察边决策”。

如果你做的是复杂长流程任务，优先 Plan-and-Execute。因为它更擅长先拆解、再推进。

如果你特别看重正确率，而且任务允许多次尝试，就加 Reflection。因为它能让 Agent 从失败中积累经验。

如果你要做真正上线的生产系统，最终一定要引入 Harness 思维。因为状态、治理、安全、审批、回放、执行环境，这些才是系统能不能长期稳定跑下去的关键。

CoT 是先想，ReAct 是边想边做，Plan-and-Execute 是先规划再做，Reflection 是做完复盘再改，Harness 是把前面这些能力统统装进系统。
读者看到这里，基本就不会再把这些概念混在一起了。

10. 总结：一句话讲透 Harness 的本质

最后你只要记住一句话：

Harness 不是一种新的推理技巧，而是 Agent 的运行控制层。

它不负责替模型思考，
它负责让模型的思考真正变成：

• 可执行
• 可恢复
• 可治理
• 可观测
• 可上线

所以，CoT、ReAct、Plan-and-Execute、Reflection 解决的是“怎么想、怎么做、怎么改”；
而 Harness 解决的是“这些能力怎样才能在真实世界里稳定运转”。

也正因为这样，今天越来越多团队发现：

做 Demo，可以只聊 Prompt。
做 Agent，必须聊架构。
做生产级 Agent，绕不开 Harness。