最近在智能体（Agent）领域，Harness 成为高频热词，但行业内对它的理解始终模糊且碎片化：有人将其简单等同于工具系统，有人视其为提示词（Prompt）的外层封装，还有人把它当作多智能体编排、记忆（Memory）、沙箱（Sandbox）、技能模块（Skills）的杂乱集合。这些解读虽有一定道理，却始终未触及其核心支撑价值——Harness 并非零散组件的堆砌，而是决定智能体从“Demo 可用”走向“生产可靠”的关键支撑。

反复研读 Akshay 所著的《The Anatomy of an Agent Harness》（智能体支撑架构解析），并结合行业实践案例后，我发现最具启发的并非产品案例的简单罗列，而是视角的根本性转变——从“过度关注模型能力强弱”，转向“重视模型外围系统的工程化价值”。本文不做逐字翻译，而是整合翻译内容与参考文章的核心细节，从全新角度解答行业核心困惑：使用完全相同的大语言模型（LLM），不同团队打造的智能体，为何在稳定性、准确率、任务完成度上会出现天差地别的差距？

核心结论先行：Harness（智能体支撑架构）是衔接模型与真实业务交付的完整软件系统，具备可运行、可恢复、可验证、可治理四大核心能力。明确这一定义后，Harness 便不再是空洞的技术热词，而是支撑生产级智能体落地的关键基石，更是同一模型产生不同表现的核心变量。

01

先理清三个核心概念

Prompt、Context、Harness，三层递进的工程体系

想要真正读懂 Harness，必须先明确它与提示词工程、上下文工程的关系——三者并非孤立存在，而是围绕模型形成的三层同心圆式递进工程体系，各司其职、相互支撑，共同构成智能体的运行基础：

1. 提示词工程（Prompt Engineering）：核心解决“如何向模型清晰下达指令”的问题，相当于给模型的操作手册，决定了模型接收任务的精准度，是智能体运行的基础前提。
2. 上下文工程（Context Engineering）：核心解决“模型每一轮交互能看到哪些信息”的问题，相当于模型的临时工作台，负责筛选、呈现与当前任务相关的信息，直接影响模型的推理方向。
3. 支撑架构工程（Harness Engineering）：核心解决“整套智能体系统如何稳定运行、状态如何持久化、结果如何验证、异常如何兜底”的问题，是智能体的“操作系统”，既涵盖前两者，又承担着完整的应用基础设施搭建职责。

Akshay 在文章中引用了 Beren Millidge 2023 年在《作为自然语言计算机的脚手架式大语言模型》中的经典类比，精准诠释了三者的关系：

裸 LLM 就像是一颗没有 RAM（内存）、没有磁盘、没有 I/O 接口的 CPU，只能进行基础运算，却无法实现复杂任务；上下文窗口充当 RAM，速度快但容量有限，负责临时存储交互信息；外部数据库承担磁盘存储的角色，容量大但速度慢，负责持久化长期数据；工具集则相当于设备驱动程序，让模型能够对接外部能力；而 Harness，正是让所有这些组件协同运转的调度、执行、校验与保护机制，是智能体能够稳定工作的“操作系统”。

这一类比也恰好解释了行业内的普遍痛点：很多团队搭建的聊天机器人，在 Demo 阶段表现完美——能思考、会调用工具、能给出看似合理的答案，但一旦进入真实长任务场景，就会彻底失效：模型会忘记自己三步之前做过的操作，工具调用出现静默失败却毫无反馈，上下文窗口被无效信息填满导致指令遵循能力下降，最终产出看似完整却无法落地的结果。其实，问题从来不在模型本身，而在于包裹模型的 Harness 太过薄弱，无法支撑任务的稳定交付。

02

7个关键事实

1. Harness 是包裹模型的完整运行系统，并非单一组件，核心涵盖主循环（编排循环）、工具系统、上下文管理、状态管理、权限与错误处理、验证与纠偏六大核心模块，12 个具体组件协同工作，构成完整支撑体系。
2. 2026 年 Harness 成为行业焦点，核心原因在于模型能力已趋于成熟，智能体的发展瓶颈从“能否回答用户问题”转向“能否稳定交付真实业务结果”，而 Harness 正是突破这一瓶颈的关键。
3. 同一模型仅更换 Harness、不修改任何模型权重，性能就能实现量级提升：LangChain 仅升级模型外围的 Harness 系统，便在 TerminalBench 2.0 榜单中从 30 名开外跃升至第 5 名；另一项独立研究显示，让 LLM 自主优化 Harness 本身，可实现 76.4% 的通过率，远超人工设计的系统。
4. 模型与 Harness 遵循协同进化原则：Claude Code 的模型在训练阶段就将特定 Harness 的逻辑纳入训练回路，二者深度耦合，若随意更换工具实现方式，反而会导致模型性能下降。
5. Harness 的演进方向是“轻量化”，而非“复杂化”：Manus 项目在六个月内被重构五次，每次重构都在降低架构复杂度——复杂的工具定义简化为通用 shell 执行，“管理智能体”简化为简单的结构化交接，让架构更简洁、更高效。
6. 长任务的误差会快速累积，Harness 是控制误差的核心：一个 10 步流程，即便每一步的成功率都达到 99%，端到端的最终成功率也仅约 90.4%，而 Harness 的错误处理、校验循环等组件，能有效避免误差累积，保障任务稳定推进。
7. 当智能体出现不稳定问题时，应优先排查 Harness，而非模型本身：多数情况下，模型的推理能力足够支撑任务，问题往往出在 Harness 的上下文管理、错误处理、权限控制等环节。

03

生产级 Harness 核心：6 大承重结构与完整运行链路

Akshay 在原文中将生产级 Harness 拆解为 12 个独立组件，参考文章则将其整合为更易理解的 6 大核心承重结构。结合两者细节，我们既保留 12 个组件的完整信息，又以 6 大结构为框架，清晰呈现 Harness 的完整运行逻辑，兼顾专业性与可读性：

（一）Harness 六大核心承重结构（含 12 个组件细节）

1. 主循环：智能体的心跳（对应组件：编排循环）

主循环是 Harness 的核心引擎，本质是一个简单的 while 循环，但核心复杂度不在于循环本身，而在于循环所管理的流程控制、终止条件与错误恢复机制。它实现了“思考-行动-观察（TAO）”循环，也被称为 ReAct 循环，具体流程为：组装提示词 → 调用 LLM → 解析输出 → 执行工具调用 → 将结果回传 → 重复直至任务完成。

Anthropic 将其运行时描述为一个“傻瓜循环”，因为所有智能决策都存在于模型中，Harness 的主循环仅负责管理交互轮次，确保循环不失控——避免出现无限转圈、提前收尾、误将中间结果当作最终输出等问题，这也是很多入门级智能体不稳定的核心原因之一。

2. 工具系统：智能体的执行手脚（对应组件：工具）

工具是智能体对接外部世界的“手和脚”，但工具系统绝非简单提供工具名称那么简单，而是一套完整的工具管理体系，核心负责五件事：工具注册、schema 校验（名称、描述、参数类型的标准化）、参数提取、沙箱隔离执行、结果捕获，并将结果格式化为 LLM 可读取的观测信息（Observation）。

不同框架的工具系统设计各有侧重：Claude Code 提供六大类工具，涵盖文件操作、搜索、执行、网络访问、代码智能、子智能体生成；OpenAI 的 Agents SDK 支持三类工具，包括通过 @function_tool 定义的函数工具、WebSearch、CodeInterpreter、FileSearch 等托管工具，以及 MCP 服务端工具。真正体现 Harness 价值的，从来不是工具数量的多少，而是工具调用的时机、参数的准确性、执行的安全性，以及失败后的容错能力。

3. 上下文与记忆：智能体的信息中枢（对应组件：记忆、上下文管理、提示词构建）

这一层核心解决“该记什么、什么时候记、什么时候删、该给模型看什么”的问题，分为记忆管理与上下文管理两大模块，同时衔接提示词构建，确保模型每一轮都能获取最有价值的信息。

记忆管理分为两个时间尺度：短期记忆是单次会话内的对话历史，负责支撑当前任务的连续交互；长期记忆是跨会话的持久化存储，负责沉淀任务相关的事实、决策与索引。Claude Code 采用三级记忆体系，兼顾效率与准确性：一是轻量级索引（每条约 150 字符，始终加载，快速提供线索）；二是按需拉取的详细主题文件（补充具体细节）；三是仅通过搜索访问的原始记录（确保信息真实性）。这里有一个关键设计原则：智能体将自身记忆视为“提示线索”，而非“绝对真相”，在执行关键操作前，必须回到真实文件、真实环境中二次校验，避免出现记忆幻觉。

上下文管理则是很多智能体静默失效的重灾区，核心问题是“上下文衰减”——当关键内容落在上下文窗口的中间位置时，模型性能会下降超过 30%（这一结论由 Chroma 研究得出，且得到斯坦福大学“中间丢失”理论的佐证），即便百万级 token 窗口，也会随着上下文不断膨胀，导致模型的指令遵循能力下降。

生产级上下文管理有四大核心策略：

• 压缩：当上下文接近窗口上限时，对对话历史进行摘要压缩，Claude Code 的做法是保留架构决策与未解决的 bug，丢弃冗余的工具输出，确保关键信息不丢失；

• 观测屏蔽：JetBrains 的 Junie 采用的策略，隐藏旧的工具输出，同时保留工具调用记录，减少无效信息占用窗口；

• 即时检索：维护轻量级标识符，不加载完整文件，而是通过 grep、glob、head、tail 等命令动态加载所需数据，提升上下文利用率；

• 子智能体委派：让子智能体对特定子任务进行深度探索，仅返回 1000–2000 token 的精简摘要，避免子任务信息占用过多主上下文。

提示词构建则负责组装模型每一步实际看到的内容，采用层级化结构，优先级从高到低依次为：系统提示词 → 工具定义 → 记忆文件 → 对话历史 → 当前用户消息。其中，OpenAI 的 Codex 采用更严格的优先级栈：服务端控制的系统消息（最高优先级）→ 工具定义 → 开发者指令 → 用户指令（级联 AGENTS.md 文件，有 32 KiB 限制）→ 对话历史，确保模型优先遵循核心规则。

4. 状态与检查点：长任务的生命线（对应组件：状态管理）

当任务周期拉长，状态管理就从“可选功能”变成“必备功能”——系统需要清晰记录当前任务的执行进度、失败后的恢复节点、值得保留的中间产物，避免任务失败后只能从头开始，从而大幅提升长任务的效率与稳定性。

不同框架的状态管理实现方式各有不同：LangGraph 将状态建模为流经图节点的类型化字典，通过归约器合并更新，并在超级步骤边界保存检查点，支持中断后恢复与回溯调试；OpenAI 提供四种互斥的状态管理策略，包括应用内存、SDK 会话、服务端 Conversations API、轻量级 previousresponseid 链式调用；Claude Code 则采用更具工程化的方式，将 git 提交作为检查点，进度文件作为结构化草稿板，确保状态可追溯、可恢复。

5. 权限、错误与安全护栏：生产环境的底线（对应组件：错误处理、护栏与安全）

这一层是区分“Demo 智能体”与“生产级智能体”的重要标志，核心是将“模型想做什么”与“系统允许做什么”彻底分离，同时做好错误控制，避免智能体成为“事故放大器”。

错误处理的重要性不言而喻：一个 10 步流程，每步成功率 99%，端到端成功率仅约 90.4%，错误会快速累积。LangGraph 将错误分为四类，并针对性处理：一是瞬时错误，采用指数退避重试策略；二是 LLM 可恢复错误，将错误作为 ToolMessage 返回给模型，让模型自主调整；三是用户可修复错误，中断任务等待人工输入；四是意外错误，向上抛出用于调试。Anthropic 的做法是在工具处理器内部捕获失败，以错误结果返回，确保循环持续运行，避免因单个错误导致整个任务终止；Stripe 的生产级支撑架构则将重试次数上限设为 2 次，平衡效率与稳定性。

安全护栏则负责管控智能体的操作边界，OpenAI 的 SDK 实现了三级护栏：输入护栏（在首个智能体轮次运行，校验输入合法性）、输出护栏（在最终输出运行，确保输出合规）、工具护栏（在每次工具调用时运行，管控工具使用权限），并设有“触发线”机制，一旦触发，立即终止智能体运行。Anthropic 则从架构上分离权限执行与模型推理：模型负责提出行动请求，工具系统负责判断是否允许执行，Claude Code 独立控制约 40 个离散工具能力，分为三个阶段：项目加载时建立信任、每次工具调用前进行权限检查、高风险操作需要用户显式确认，最大限度降低安全风险。

6. 验证与纠偏：Demo 与生产的分水岭（对应组件：校验循环、子智能体编排）

工具赋予智能体行动能力，而验证与纠偏则赋予智能体纠错能力，没有验证机制的 Harness，只会“更快地产出错结果”。Anthropic 推荐三种核心验证方式，可覆盖不同场景：

• 基于规则的反馈：通过测试用例、lint 工具、类型检查器等，实现确定性校验，确保输出符合技术规范；

• 视觉反馈：通过 Playwright 对 UI 任务进行截图，校验界面操作的正确性；

• LLM-as-judge：由独立的子智能体担任评估器，对主智能体的输出进行语义校验，捕获规则无法覆盖的问题。

Claude Code 的作者 Boris Cherny 明确指出，为模型提供校验自身工作的方式，可将输出质量提升 2 至 3 倍，这也是生产级智能体不可或缺的核心能力。

子智能体编排则是支撑验证与复杂任务拆解的重要组件，Claude Code 支持三种子智能体执行模式：Fork 模式（父上下文的字节级副本，共享上下文）、Teammate 模式（独立终端面板，基于文件邮箱通信，协同工作）、Worktree 模式（独立 git 工作树，每个智能体对应独立分支，避免相互干扰）；OpenAI 的 SDK 支持两种模式：智能体即工具（专家智能体处理限定子任务）与交接模式（专家智能体完全接管任务）；LangGraph 则将子智能体实现为嵌套状态图，实现更灵活的任务拆分与协同。

（二）一次完整的 Harness 执行循环（7 步闭环，无遗漏）

了解核心组件后，我们顺着一轮真实执行流程，看看 Harness 的各个组件如何协同工作——一套成熟的生产级 Harness，会严格执行以下 7 步流程，缺一不可，确保任务稳定推进：

1. 组装输入：Harness 按照层级结构，拼接系统提示词、工具 schema、记忆文件、对话历史与当前用户消息，同时将关键信息放置在提示词的开头与结尾，规避“中间丢失”现象，确保模型能精准获取核心信息。
2. 模型推理：将组装好的输入发送至模型 API，模型生成输出 token，输出内容可能是纯文本、工具调用请求，也可能是两者兼有。
3. 输出分类：Harness 对模型输出进行判断：若仅为无工具调用的纯文本，说明任务已完成，循环终止；若存在工具调用，则进入工具执行阶段；若请求子智能体交接，则更新当前智能体，重启循环。
4. 工具执行：针对每个工具调用，Harness 先进行参数校验，确保参数合法；再进行权限检查，判断是否允许执行；最后在沙箱环境中执行工具，捕获执行结果。其中，只读操作（如搜索、读取文件）可并发执行，提升效率；修改操作（如编辑文件、部署代码）需串行执行，避免冲突。
5. 结果封装：将工具执行结果格式化为 LLM 可读取的观测信息（Observation）；若执行失败，不静默吞错，而是将错误信息明确封装后返回给模型，让模型能够自主调整策略、修正错误。
6. 上下文更新：将工具执行结果（或错误信息）追加到对话历史中，同时更新记忆与状态；若上下文接近窗口上限，触发上下文压缩机制，保留关键信息，删除冗余内容。
7. 循环或终止：回到第一步，重复执行流程，直至满足终止条件。终止条件是多层级的，包括：模型生成无工具调用的响应（任务完成）、超出最大轮次限制、token 预算耗尽、安全护栏触发线触发、用户主动中断、系统返回安全拒绝。
   需要特别说明的是，针对跨多个上下文窗口的长时间运行任务，Anthropic 设计了两阶段“Ralph Loop”模式，确保任务的连续性：第一阶段是初始化，智能体搭建任务环境，包括执行初始化脚本、创建进度文件、整理功能列表、完成初始 git 提交；第二阶段是持续执行，在后续每个会话中，编码智能体读取 git 日志与进度文件，定位当前任务进度，选择优先级最高的未完成功能进行处理，完成后提交代码并生成总结，通过文件系统实现跨上下文窗口的任务连续性，避免因上下文窗口限制导致任务中断。了解核心组件后，我们顺着一轮真实执行流程，看看 Harness 的各个组件如何协同工作——一套成熟的生产级 Harness，会严格执行以下 7 步流程，缺一不可，确保任务稳定推进：

需要特别说明的是，针对跨多个上下文窗口的长时间运行任务，Anthropic 设计了两阶段“Ralph Loop”模式，确保任务的连续性：第一阶段是初始化，智能体搭建任务环境，包括执行初始化脚本、创建进度文件、整理功能列表、完成初始 git 提交；第二阶段是持续执行，在后续每个会话中，编码智能体读取 git 日志与进度文件，定位当前任务进度，选择优先级最高的未完成功能进行处理，完成后提交代码并生成总结，通过文件系统实现跨上下文窗口的任务连续性，避免因上下文窗口限制导致任务中断。

主流框架如何实现这一模式

* Anthropic Claude Agent SDK

通过单一 query () 函数暴露支撑架构，创建智能体循环并返回流式消息的异步迭代器。运行时是一个 “傻瓜循环”。所有智能都存在于模型中。Claude Code 使用收集 - 执行 - 校验循环：收集上下文（搜索文件、读取代码）、执行操作（编辑文件、运行命令）、校验结果（运行测试、检查输出）、重复。

• OpenAI Agents SDK

通过 Runner 类实现支撑架构，支持三种模式：异步、同步、流式。该 SDK 是 “代码优先” 的：工作流逻辑使用原生 Python 表达，而非图领域特定语言。Codex 支撑架构在此基础上扩展为三层架构：Codex Core（智能体代码 + 运行时）、App Server（双向 JSON-RPC API）、客户端界面（CLI、VS Code、网页应用）。所有界面共享同一套支撑架构，这也是 “Codex 模型在 Codex 界面上的体验优于通用聊天窗口” 的原因。

• LangGraph

将支撑架构建模为显式状态图。llm_call 与 tool_node 两个节点通过条件边相连：若存在工具调用则路由至 tool_node，若无则路由至 END。LangGraph 由 LangChain 的 AgentExecutor 演进而来，后者因扩展性差、缺乏多智能体支持在 v0.2 中被废弃。LangChain 的 Deep Agents 明确使用 “智能体支撑架构” 一词：内置工具、规划（write_todos 工具）、用于上下文管理的文件系统、子智能体生成与持久记忆。

• CrewAI

采用基于角色的多智能体架构：Agent（围绕 LLM 的支撑架构，由角色、目标、背景故事与工具定义）、Task（工作单元）、Crew（智能体集合）。CrewAI 的 Flows 层增加 “在关键位置具备智能的确定性主干”，管理路由与校验，同时由 Crew 处理自主协作。

• AutoGen（正在演进为 Microsoft Agent Framework）

开创了对话驱动的编排方式。其三阶段架构（Core、AgentChat、Extensions）支持五种编排模式：串行、并发（扇出 / 扇入）、群聊、交接、管理模式（由管理智能体维护动态任务台账，协调专家智能体）。

04

为何全行业都在聚焦 Harness？

Harness 并非 2026 年才出现的新概念，其核心逻辑早已在 Anthropic、OpenAI、LangChain 等团队的实践中落地，只是在 2026 年，它才被正式定义、成为行业焦点。这一变化的背后，是智能体发展的阶段跃迁——模型能力已经足够强大，“能否稳定交付”取代“能否思考”，成为智能体落地的核心瓶颈。

两个关键信号，清晰印证了这一行业趋势：

第一个信号：Harness 直接决定智能体的性能上限。同一模型、同一组权重，仅更换外围的 Harness 系统，性能就能实现大幅跃升。LangChain 的实验最具说服力：仅升级模型外围的基础设施（不改变模型与权重），便在 TerminalBench 2.0 榜单中从 30 名开外跃升至第 5 名；另一项独立研究项目，将“优化 Harness”本身作为优化目标，让 LLM 自主优化支撑架构，最终实现了 76.4% 的通过率，远超人工设计的系统。需要注意的是，榜单结果不能直接等同于真实产品体验，单个实验也不能覆盖所有场景，但这足以说明：智能体的表现，不仅由模型上限决定，更强烈依赖它所运行的 Harness 系统。

第二个信号：长任务的误差累积问题，只有 Harness 能解决。随着任务步骤增多，误差会快速累积，一个 10 步流程，每步成功率 99%，端到端成功率仅约 90.4%，任务再拉长，误差会更加明显。而 Harness 的错误处理、校验循环、状态管理等组件，能有效捕获错误、控制误差、恢复任务，确保长任务能够稳定推进，这也是生产级智能体的核心需求。

行业也由此形成共识：Harness 已经成为智能体的“战略资产”，其设计核心是“精简”而非“堆砌”。很多团队的实践都印证了这一点：Vercel 从 v0 版本中移除了 80% 的工具，智能体的表现反而更好；Claude Code 通过懒加载机制，实现了 95% 的上下文压缩，既提升了效率，又避免了上下文衰减问题。

回顾智能体的发展历程，我们能清晰看到行业焦点的变迁：2024 年，全行业都在卷提示词，比拼谁能通过更优的指令设计，让模型产出更好的结果；2025 年，大家开始补上下文工程的短板，关注如何让模型看到更有价值的信息；到了 2026 年，行业讨论的重心慢慢聚焦到 Harness，因为当模型智力不再受限，真正拉垮系统的，是那些更底层的工程化问题：上下文是否会逐轮变脏、工具失败后有没有显式反馈、状态能否跨会话延续、高风险动作有没有权限边界、结果到底由谁验收。

更重要的是，模型与 Harness 是协同进化的。Claude Code 的模型在训练阶段，就将特定 Harness 的逻辑纳入了训练回路，模型已经学会了如何适配这套支撑架构；反之，Harness 的设计也会反过来引导模型的优化方向，二者深度绑定、相互成就。如果随意更换 Harness 的工具实现方式，反而会导致模型性能下降，这也是 Harness 设计需要兼顾模型特性的核心原因。

05

Harness 设计的核心：7 大关键取舍，无标准答案

Harness 不是组件的简单堆砌，而是一系列架构取舍的集合。每个架构师在设计 Harness 时，都会面临 7 个核心选择，这些选择没有放之四海而皆准的标准答案，只能根据具体的业务场景、任务需求、模型能力，做出最适合的权衡，而每个选择，都会直接影响智能体的表现：

1. 单智能体 vs 多智能体

一个常见的误区是，一上来就搭建多智能体系统，认为“多智能体分工更明确、能力更强”。但实际上，多智能体并非无成本的收益，它会带来额外的路由开销、上下文丢失、角色边界设计复杂等问题，还会增加更多的失败点。Anthropic 与 OpenAI 均给出了相同的建议：优先最大化单智能体的能力，将单智能体的主链路做通、做稳，再考虑拆分——仅当工具过载（超过 10 个重叠工具）或任务域完全分离（如一个任务需要同时处理代码开发与 UI 设计，且两者无直接关联）时，再拆分多智能体。

2. ReAct 模式 vs 规划执行模式

两种模式各有优劣，核心取舍在于“灵活性”与“稳定性”：ReAct 模式是“边想边做”，每一步交替进行推理与行动，灵活度高，适合短任务、简单任务，能快速响应变化；规划执行模式是“先规划、后执行”，先让模型制定完整的任务计划，再逐段执行，稳定性更强，适合长周期、高代价、难回滚的任务（如代码重构、系统部署）。根据 LLMCompiler 的实验数据，规划执行模式相比串行 ReAct 模式，可实现 3.6 倍的速度提升，更适合复杂任务。

3. 上下文窗口管理策略

很多团队的默认思路是“上下文窗口越大越好”，但这是一个误区——窗口变大，不代表中间位置的信息能被模型有效识别，反而可能因信息冗余导致指令遵循能力下降。核心取舍在于“提升上下文的信号密度”，而非单纯扩大窗口。生产级有五种主流策略：基于时间清理（删除过期信息）、对话摘要（压缩冗余内容）、观测屏蔽（隐藏无效工具输出）、结构化笔记（提炼关键信息）、子智能体委派（隔离子任务信息）。ACON 研究表明，优先保留推理轨迹而非原始工具输出，可实现 26%–54% 的 token 减少，同时保持 95% 以上的准确率，是兼顾效率与效果的最优策略之一。

4. 验证方式选择

验证方式的核心取舍是“确定性”与“效率”：计算式校验（如测试用例、lint 工具、类型检查器）能提供确定性的校验结果，确保输出符合技术规范，但开发成本较高；推理式校验（LLM-as-judge）能捕获规则无法覆盖的语义问题，开发成本低、灵活度高，但会增加任务延迟，且存在一定的不确定性。Martin Fowler 所在的 Thoughtworks 团队，将验证方式分为两类：引导式校验（行动前的前馈控制，提前规避错误）与传感式校验（行动后的反馈观察，及时纠正错误），实际设计中，建议结合两种方式，兼顾确定性与灵活性。

5. 权限与安全架构

核心取舍是“效率”与“安全”：宽松型架构（自动批准大多数操作）速度快、效率高，但安全风险高，适合内部测试、低风险场景；严格型架构（每个操作都需要审批，高风险操作需用户显式确认）安全性高，但效率低，适合生产环境、高风险场景（如涉及资金操作、代码部署、数据删除的任务）。选择的核心是匹配部署场景，生产环境优先选择严格型架构，守住安全底线。

6. 工具范围策略

很多人认为“工具越多，智能体能力越强”，但实际情况恰恰相反——工具数量越多，模型的选择成本越高、误调用概率越高，反而会降低智能体的稳定性。Vercel 从 v0 版本中移除 80% 的工具后，智能体表现反而更好，这印证了一个核心原则：仅暴露当前步骤所需的最小工具集，避免工具过载。Claude Code 通过懒加载机制，实现 95% 的上下文压缩，本质也是通过控制工具的加载范围，提升智能体的效率与稳定性。

7. Harness 厚度权衡

核心取舍是“架构复杂度”与“模型依赖度”：Harness 厚度，指的是“多少逻辑放在 Harness 中，多少逻辑交给模型”。Anthropic 押注轻量化 Harness 与模型持续进化，随着模型能力提升，不断删除 Harness 中冗余的结构（如规划步骤），让模型承担更多的智能决策；基于图的框架（如 LangGraph）则押注显式控制，将更多逻辑放在 Harness 中，通过状态图实现更精准的流程管控。核心原则是：模型较弱时，Harness 补充结构，兜底模型能力不足；模型升级后，及时删除冗余脚手架，让 Harness 轻量化，避免过度复杂导致的效率下降。Manus 半年内重构 5 次，每次都在做减法，正是这一原则的实践体现。

06

从零搭建 Harness：最小可用实践原则

对于很多团队而言，搭建生产级 Harness 无需一步到位，可遵循“最小可用、逐步迭代”的原则，先守住 6 条核心原则，确保智能体的稳定性，再逐步扩展功能、优化体验：

1. 先稳单智能体主链路：优先打通“提示词组装→模型推理→工具执行→结果回写→错误处理→终止条件”的主链路，确保单智能体能够稳定完成简单任务，再扩展记忆、子智能体、复杂校验等模块，避免一开始就追求“大而全”，导致架构混乱、难以维护。
2. 严格控制工具数量：梳理当前任务的核心需求，仅保留必需的工具，删除职责重叠、使用频率低的工具，避免工具过载；同时，对工具进行标准化定义，明确工具的名称、描述、参数类型，降低模型误调用的概率。
3. 记忆仅作提示，不替代真相：将记忆视为“线索”，而非“绝对正确的依据”，在执行关键操作（如修改文件、提交代码）前，必须让智能体回到真实环境中二次校验，避免记忆幻觉导致的错误。
4. 验证外置，优先外部校验：尽量采用测试用例、lint 工具、真实 API 调用、UI 截图等外部验证方式，不依赖模型自评；若需使用 LLM-as-judge，可搭配外部校验，提升验证的准确性。
5. 显式状态与检查点，确保可恢复：预设任务失败的常见场景（如工具调用失败、token 耗尽），设计清晰的状态记录与检查点机制，确保任务失败后能够从最近的检查点恢复，无需从头开始，提升长任务效率。
6. 高风险操作隔离，守住安全底线：将删除文件、批量修改数据、系统部署等高风险操作，单独进行权限管控，设置明确的审批流程，避免智能体误操作导致严重事故；同时，对高风险操作进行日志记录，便于回溯排查。

07

被忽视的关键：AGENTS.md、Spec、Skills 也是 Harness 的核心组成

很多人误以为 Harness 只是“运行时（Runtime）”，只包含主循环、工具、状态管理等可执行组件，但实际上，团队经验固化的相关工件，也是 Harness 的核心组成部分——它们的核心作用是缩小模型的“临场发挥”范围，让智能体的行为更可控、更可复用，将零散的知识、规则、经验，固化为系统可执行的逻辑。

这三类核心工件，分别承担着不同的角色：

1. AGENTS.md：相当于智能体的“仓库地图”，定义了仓库的读取方式、标准入口、联动检查要求等默认规则，让智能体能够快速熟悉任务环境，避免因环境不熟悉导致的操作错误。
2. Spec（任务规范）：相当于智能体的“任务契约”，明确了任务的完成标准、交付内容、边界范围、验收条件，让智能体清楚“什么是完成任务”，避免产出“看似完整却不符合要求”的结果。
3. Skills（技能库）：相当于智能体的“程序性记忆”，沉淀了高频任务的操作规程、检查规则、团队经验，让智能体能够复用成熟的操作逻辑，提升任务效率与准确性，同时减少模型的推理负担。

这三类工件，与 Harness 的可执行组件相互配合，让软件工程对智能体“可见、可验证、可执行”，进一步提升智能体的稳定性与可复用性，也是生产级 Harness 不可或缺的一部分。

08

Harness 的本质：软件工程在智能体时代的新接口

如果只盯着 2026 年的行业热点，很容易把 Harness 看成一个全新的技术名词，但把时间拉长一点就会发现，它更像是软件工程演进过程中非常自然的一步——软件工程的核心使命，从来都是“把复杂系统转化为可控系统”，而 Harness，就是这种使命在智能体时代的延伸。

回顾软件工程过去 30 年的发展，复杂性的中心一直在迁移，而解决方案也在不断迭代：

• 1990 年代，设计模式的出现，解决了对象协作的复杂性，让代码更具复用性、可维护性；

• 2000 年代，分层架构与 DDD（领域驱动设计）的普及，解决了企业业务与系统边界的复杂性，让系统更贴合业务需求；

• 2010 年代，微服务与云计算的兴起，解决了分布式通信与运维的复杂性，让系统更具扩展性、可伸缩性；

• 到了 2020 年代后期，智能体的普及，带来了新的复杂性——一个会推理、会执行、会消耗上下文预算、会自主调整策略的新型系统，而 Harness，就是解决这种复杂性的核心方案。

从本质上看，Harness 并没有创造新的软件工程理念，而是将传统软件工程的“可控性、可验证性、可恢复性”等核心原则，适配到智能体这种新型系统中，让原本不可控的 LLM，变成可设计、可治理、可拆边界的生产级系统。它让工程师觉得熟悉，正是因为它延续了软件工程的核心逻辑，是“旧瓶装新酒”，是软件工程在智能体时代长出来的新接口。

09

结语：Harness 就是智能体的核心产品

随着模型技术的持续进化，模型的能力会不断增强，Harness 的演进方向会是“轻量化”——不断删除冗余组件，让模型承担更多的智能决策，但 Harness 本身永远不会消失。只要智能体还需要上下文管理、工具执行、状态持久化、错误恢复、权限控制、外部验证，Harness 就始终是智能体的核心竞争力。

行业里有一句经典总结：“如果你不是模型，你就在做 Harness。”这句话看似简单，却直指核心——当所有团队都能拿到相同的模型时，真正的差距，就在于包裹模型的 Harness 系统。使用相同模型的两款产品，仅因 Harness 设计不同，性能就可能天差地别，这也是 TerminalBench 榜单所印证的事实：仅更换支撑架构，就能让智能体的排名提升 20 位以上。

Harness 不是一个已解决的通用标准化层，也不是一个简单的工具集合，它是硬核工程的核心所在——是如何将上下文作为稀缺资源进行管理，是如何设计能在错误累积前捕获问题的校验循环，是如何构建不会引发幻觉的连续性记忆系统，是如何在搭建多少脚手架与交给模型多少能力之间，做出最合理的架构决策。

下次当你的智能体再次出现跑偏、遗忘、静默失败、输出不可用等问题时，别再归咎于模型——先检查它的 Harness，绝大多数问题，都藏在这一层。因为在 2026 年，一个真正的行业共识已经形成：Harness 本身，就是智能体的核心产品。

AI行业迎来前所未有的爆发式增长：从DeepSeek百万年薪招聘AI研究员，到百度、阿里、腾讯等大厂疯狂布局AI Agent，再到国家政策大力扶持数字经济和AI人才培养，所有信号都在告诉我们：AI的黄金十年，真的来了！

在行业火爆之下，AI人才争夺战也日趋白热化，其就业前景一片蓝海！

我给大家准备了一份全套的《AI大模型零基础入门+进阶学习资源包》，包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。😝有需要的小伙伴，可以VＸ扫描下方二维码免费领取🆓

人才缺口巨大

人力资源社会保障部有关报告显示，据测算，当前，****我国人工智能人才缺口超过500万，****供求比例达1∶10。脉脉最新数据也显示：AI新发岗位量较去年初暴增29倍，超1000家AI企业释放7.2万+岗位……

单拿今年的秋招来说，各互联网大厂释放出来的招聘信息中，我们就能感受到AI浪潮，比如百度90%的技术岗都与AI相关！

就业薪资超高

在旺盛的市场需求下，AI岗位不仅招聘量大，薪资待遇更是“一骑绝尘”。企业为抢AI核心人才，薪资给的非常慷慨，过去一年，懂AI的人才普遍涨薪40%+！

脉脉高聘发布的《2025年度人才迁徙报告》显示，在2025年1月-10月的高薪岗位Top20排行中，AI相关岗位占了绝大多数，并且平均薪资月薪都超过6w！

在去年的秋招中，小红书给算法相关岗位的薪资为50k起，字节开出228万元的超高年薪，据《2025年秋季校园招聘白皮书》，AI算法类平均年薪达36.9万，遥遥领先其他行业！

总结来说，当前人工智能岗位需求多，薪资高，前景好。在职场里，选对赛道就能赢在起跑线。抓住AI风口，轻松实现高薪就业！

但现实却是，仍有很多同学不知道如何抓住AI机遇，会遇到很多就业难题，比如：

❌ 技术过时：只会CRUD的开发者，在AI浪潮中沦为“职场裸奔者”；

❌ 薪资停滞：初级岗位内卷到白菜价，传统开发3年经验薪资涨幅不足15%；

❌ 转型无门：想学AI却找不到系统路径，83%自学党中途放弃。

他们的就业难题解决问题的关键在于：不仅要选对赛道，更要跟对老师！

我给大家准备了一份全套的《AI大模型零基础入门+进阶学习资源包》，包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。😝有需要的小伙伴，可以VＸ扫描下方二维码免费领取🆓

​