Table of contents
一、背景与问题
核心问题：为什么同样的模型，效果差距悬殊？
很多团队在构建 Agent 系统时都碰到同一个令人困惑的现象——相同的底座模型、相近的提示词，不同产品的稳定性和任务成功率却天差地别。直觉上的怀疑方向往往是：
- 模型不够强？
- 提示词没调好？
- RAG 没配对？
但越来越多的团队最终发现：真正决定系统能不能稳定跑起来的，往往不是模型本身，而是模型外面那套运行系统——这就是所谓的 Harness Engineering。
📡 扩展 2026 年初，OpenAI 发布工程博客，记录了一支三人团队借助 Harness Engineering 与 Codex 构建出百万行代码库的案例，每人每天产出 3.5 个 PR，且零人工键入代码。LangChain 的案例同样说明问题：仅改变包裹在同一 LLM 外的基础设施，其 Agent 在 TerminalBench 2.0 的排名便从榜单 30 名开外跃升至前 5 名，模型权重分毫未动。正如业界所说：“Harness makes or breaks an AI product”（Harness 决定 AI 产品的成败）。
二、核心概念
2.1 三代 AI 工程的演化
AI 工程经历了三个层层递进的阶段，每一步都是对”更深层问题”的响应：
flowchart TB
P1["第一阶段<br/><b>提示词工程</b><br/><span style='font-size:11px'>Prompt Engineering</span>"]
Q1["核心问题：模型有没有听懂？<br/>本质：信息表达问题<br/>目标：提升意图表达上限"]
P2["第二阶段<br/><b>上下文工程</b><br/><span style='font-size:11px'>Context Engineering</span>"]
Q2["核心问题：模型有没有拿到正确且足够的信息？<br/>本质：信息供给问题<br/>目标：补足运行时知识缺口"]
P3["第三阶段<br/><b>Harness 工程</b><br/><span style='font-size:11px'>Harness Engineering</span>"]
Q3["核心问题：模型在真实执行中能不能持续做对？<br/>本质：执行保障问题<br/>目标：实现稳定交付与合规运行"]
P1 --> Q1 --> P2 --> Q2 --> P3 --> Q3
classDef phase fill:#ffffff,stroke:#222222,stroke-width:1.8px,color:#111111,rx:6,ry:6;
classDef note fill:#fafafa,stroke:#b8b8b8,stroke-width:1px,color:#333333,rx:4,ry:4;
class P1,P2,P3 phase
class Q1,Q2,Q3 note
linkStyle default stroke:#666666,stroke-width:1.4px| 阶段 | 名称 | 核心问题 | 本质 | 典型实践 |
|---|---|---|---|---|
| 第一代 | 提示词工程 | 模型有没有”听懂”？ | 信息表达问题 | 角色设定、Few-shot、格式约束 |
| 第二代 | 上下文工程 | 模型有没有拿到正确、足够的信息？ | 信息供给问题 | RAG、长上下文、动态信息注入 |
| 第三代 | Harness 工程 | 模型在真实执行中能不能”持续做对”？ | 执行保障问题 | 编排、状态管理、评估、约束恢复 |
这三者是包含关系，而非替代关系，每一代都在前者的基础上扩大了工程边界。
2.2 “Harness” 一词的本意与 OS 类比
Harness（缰绳/马具）的本意是对马匹力量的约束与引导装置。马天生强大，但没有缰绳就无法耕田；模型天生智能，但没有 Harness 就无法在生产环境中可靠工作。
📡 扩展 Anthropic 工程师提出了一个更精准的系统类比：
flowchart TB
subgraph H["硬件 / 资源层"]
direction LR
CPU["LLM 模型<br/>CPU · 算力核心"]
RAM["上下文窗口<br/>RAM · 易失内存"]
DISK["外部数据库<br/>Disk · 持久存储"]
end
subgraph I["接口层"]
DRIVER["工具集成<br/>设备驱动 / I-O"]
end
subgraph S["系统层"]
OS["Harness<br/>操作系统式调度与协作"]
end
H --> OS
DRIVER -. 外部能力接入 .-> OS
classDef hardware fill:#ffffff,stroke:#52525b,stroke-width:1.4px,color:#18181b,rx:6,ry:6;
classDef interface fill:#fafafa,stroke:#71717a,stroke-width:1.2px,color:#27272a,rx:6,ry:6;
classDef system fill:#f4f4f5,stroke:#27272a,stroke-width:2px,color:#111827,rx:6,ry:6;
classDef group fill:#ffffff,stroke:#d4d4d8,stroke-width:1px,color:#52525b,rx:6,ry:6;
class CPU,RAM,DISK hardware
class DRIVER interface
class OS system
linkStyle 0 stroke:#52525b,stroke-width:1.8px
linkStyle 1 stroke:#71717a,stroke-width:1.4px,stroke-dasharray: 4 3你可以换更好的 CPU（模型），但操作系统（Harness）才是让所有硬件真正协作、让应用稳定运行的关键。
2.3 Harness 的正式定义
LangChain 给出了目前业界最简洁的定义：
即：在一个 Agent 系统里，除了模型本身以外，几乎所有能决定其能否稳定运行的部分，都属于 Harness。
📡 扩展 Mitchell Hashimoto 于 2026 年 2 月正式将 Harness Engineering 这一名称落地，其核心哲学是：每一次 Agent 的失败，都不是偶然，而是系统设计的漏洞。不是让它”下次更努力”，而是工程化这个漏洞，让它下次不可能再以同样方式出错。 数天后 OpenAI 发布工程博客印证了这一理念，该术语由此在业界正式流通。
三、主体内容：Harness 的六层架构
视频将一个成熟的 Agent Harness 拆解为六层，由内到外、层层递进，每一层解决不同维度的工程问题：
flowchart TB
%% 定义统一的节点样式
classDef core fill:#5e81ac,stroke:#2e3440,stroke-width:2.5px,color:#eceff4,rx:10,ry:10;
classDef support fill:#e5e9f0,stroke:#4c566a,stroke-width:1.6px,color:#2e3440,rx:8,ry:8;
classDef safe fill:#d8dee9,stroke:#81a1c1,stroke-width:1.8px,color:#2e3440,rx:8,ry:8;
classDef layer fill:#eceff4,stroke:#81a1c1,stroke-width:1.2px,color:#4c566a,rx:8,ry:8;
subgraph Harness_Architecture [SearchClaw Harness 核心架构]
direction TB
%% 第四层：认知与记忆 (顶层，类似大脑皮层)
L4["**④ 记忆与状态 (Memory)**<br>跨步骤/会话的连贯性管理"]
L1["**① 上下文重新审视 (Context)**<br>动态调整信息边界与权重"]
%% 第三层：控制与调度 (中枢，核心逻辑)
L3["**③ 执行编排 (Orchestration)**<br>串联研究步骤与行动轨迹"]
%% 第二层：执行与交互 (底层，对外接口)
L2["**② 工具系统 (Tooling)**<br>插件/API 调用与实时数据抓取"]
%% 第一层：保障与反馈 (地基，异常处理)
subgraph Stability [稳定性保障层]
direction LR
L5["**⑤ 评估与观测**<br>自我状态监控"]
L6["**⑥ 约束与恢复**<br>自愈与容错机制"]
end
end
%% 纵向逻辑连接
L4 & L1 --> L3
L3 <--> L2
L3 ==> Stability
Stability -.->|"反馈纠偏"| L3
%% 应用样式
class L3 core;
class L1,L4,L2 support;
class L5,L6 safe;3.1 第一层：上下文重新审视
站在 Harness 的视角，模型能否稳定发挥，很大程度取决于它看到了什么。这一层的核心职责是让模型在正确的信息边界内思考。
包含三件关键事项：
flowchart LR
%% 核心概念使用圆角矩形，视觉上作为起点
A(["**上下文重新审视**<br>(Context Perimeter)"])
%% 三大核心法则 (文本精炼，控制在 1-3 行)
B["**① 角色与目标定义**<br>让模型知道：自己是谁？<br>任务是什么？成功标准是什么？"]
C["**② 信息裁剪与选择**<br>上下文绝非越多越好<br>而是越精准、越相关越好"]
D["**③ 结构化组织**<br>规则/当前任务/运行状态/外部证据<br>必须严格分区域摆放"]
%% 使用加粗连线表示强拆解关系
A ==> B
A ==> C
A ==> D
%% 样式美化：认知层采用统一的蓝色系，主节点加粗边框
style A fill:#bbdefb,stroke:#1976d2,stroke-width:3px
style B fill:#e3f2fd,stroke:#2196f3,stroke-width:1px
style C fill:#e3f2fd,stroke:#2196f3,stroke-width:1px
style D fill:#e3f2fd,stroke:#2196f3,stroke-width:1px信息一旦乱掉，模型就容易丢重点，甚至出现”自我污染”（将错误推断当成事实输入到后续推理中）。
📡 扩展 上下文腐化（Context Rot）是指随着 Token 数量增加，模型准确召回早期信息的能力系统性下降，根本原因在于 Transformer 需要为 n 个 Token 建立 n² 级别的注意力关系，越长的上下文越容易稀释关键信息。Anthropic 的 Agent Skills（技能系统）是上下文工程的高级实践：不是一次性把所有工具说明塞给模型，而是只在需要时动态加载对应能力的详细说明——渐进式披露，按需给，在正确的时机给。
3.2 第二层：工具系统
没有工具，大模型本质上只是一个文本预测器。工具赋予了模型真正的”手”：搜索网页、读取文档、执行代码、调用 API……
但 Harness 在这一层要解决的绝不是简单地”把工具挂上去”，而是三个具体的工程问题：
flowchart LR
%% 核心中枢使用圆角矩形
T(["**工具系统的三大工程问题**<br>(Tooling System Challenges)"])
%% 三个并行子节点 (控制在 1-3 行，提炼核心矛盾)
T1["**① 给什么工具？(Provisioning)**<br>太少导致能力不足，太多导致滥用与分心<br>需精准配置 Agent 专属工具集"]
T2["**② 何时调用？(Invocation)**<br>避免不必要的随意检索调用<br>确保在关键节点进行严格的事实查证"]
T3["**③ 结果如何处理？(Distillation)**<br>禁止将原始冗长结果原封不动塞回<br>需提炼、筛选并对齐当前任务目标"]
%% 使用加粗连线表示强拆解关系
T ==> T1
T ==> T2
T ==> T3
%% 样式美化：工具系统属于执行层，采用统一的橙/黄色系
style T fill:#ffe0b2,stroke:#fb8c00,stroke-width:3px
style T1 fill:#fff3e0,stroke:#ff9800,stroke-width:1px
style T2 fill:#fff3e0,stroke:#ff9800,stroke-width:1px
style T3 fill:#fff3e0,stroke:#ff9800,stroke-width:1px📡 扩展 OpenAI SDK 实现了三级 Guardrail（护栏）机制：输入护栏（作用于首个 Agent）、输出护栏（作用于最终输出）、工具护栏（每次工具调用时触发），并通过”熔断机制（Tripwire）“在触发时立即中止 Agent。Anthropic 则在架构层面将权限执行与模型推理完全分离：模型决定”要做什么”，工具层独立判断”是否被允许”。Claude Code 对约 40 项工具能力独立设权，采用三阶段流程：项目加载时建立信任、每次工具调用前做权限检查、高风险操作前要求用户显式确认。
3.3 第三层：执行编排
这一层解决的核心问题是：模型下一步该做什么？
很多 Agent 的问题不是某一步不会，而是不会把所有步骤串联成完整链路——它会搜索、会总结、会写代码，但整个过程想到哪做到哪，最终交付一堆半成品。
一个成熟的执行编排，应当驱动 Agent 形成如下的完整反馈闭环：
flowchart TD
%% 节点定义：采用圆角/菱形等不同形状区分节点属性
A(["**① 理解目标 (Plan)**<br>明确任务定义与成功标准"])
B["**② 判断信息 (Check)**<br>确认是否需要额外检索或确认"]
C["**③ 执行行动 (Action)**<br>检索 / 调用工具 / 生成内容"]
D["**④ 产出输出 (Output)**<br>生成阶段性或最终结果"]
E{"**⑤ 满足要求？**<br>对照成功标准自检"}
F["**⑥ 修正与重试 (Retry)**<br>调整策略、补充信息并回滚"]
G(["**⑦ 完成交付 (Deliver)**<br>提交最终结果"])
%% 主干流程
A --> B --> C --> D --> E
%% 反馈闭环机制 (使用带警示的虚线，强调纠错回环)
E -- "❌ 否 (未达标)" --> F
F -. "携带修正经验重试" .-> C
%% 成功出口 (使用加粗连线，强调最终成果)
E == "✅ 是 (已达标)" ==> G
%% 样式美化与阶段色彩分组
%% 准备阶段 (蓝色系)
style A fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
style B fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
%% 执行阶段 (橙色系)
style C fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
style D fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
%% 验证与分支阶段 (紫色中枢、红色容错、绿色成功)
style E fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
style F fill:#ffebee,stroke:#e53e3e,stroke-width:2px,stroke-dasharray: 5 5
style G fill:#e8f5e9,stroke:#43a047,stroke-width:3px这个循环在结构上已经非常接近人类工作时的思维闭环。区别在于：人靠经验来做判断，Agent 靠 Harness 提供的运行环境来驱动这一轨迹。
📡 扩展 这一模式在学术上称为 ReAct 循环（Thought-Action-Observation，简称 TAO 循环）：组装提示词 → 调用 LLM → 解析输出 → 执行工具调用 → 将结果反馈 → 重复直到完成。Anthropic 将其运行时描述为”愚蠢的循环”——循环本身机械简单，所有智能都在模型内；但循环管理的上下文、状态和错误处理，正是 Harness 工程的价值所在。
3.4 第四层：记忆与状态
没有状态的 Agent 每一轮都像失忆了一样——不知道自己做了什么、哪些结论已经确认、哪些问题还没解决。
Harness 必须清晰管理三类状态，且三者不能混在一起：
flowchart TB
S(["**状态管理与记忆分层**<br>(State & Memory Hierarchy)"])
subgraph MemoryGroup[" "]
direction TB
S1["**① 当前任务状态 (Task State)**<br>追踪本次执行进度<br>明确当前步骤的子目标"]
S2["**② 会话中间结果 (Session Context)**<br>本次对话流中积累的<br>中间产物与临时推断"]
S3["**③ 长期记忆 (Long-term Memory)**<br>跨会话持久化的全局知识<br>用户偏好与历史经验资产"]
end
WARN{"**❌ 边界混淆的致命后果**<br>Agent 无法区分'确凿事实'与'临时猜测'<br>最终导致逻辑崩溃与错误累积"}
S ==> S1
S ==> S2
S ==> S3
S1 -.->|隔离失败 / 状态污染| WARN
S2 -.-> WARN
S3 -.-> WARN
style MemoryGroup fill:transparent,stroke:transparent
style S fill:#fff7ed,stroke:#d97706,stroke-width:3px,color:#1f2937
style S1 fill:#ffffff,stroke:#64748b,stroke-width:2px,color:#1f2937
style S2 fill:#ffffff,stroke:#64748b,stroke-width:2px,color:#1f2937
style S3 fill:#ffffff,stroke:#64748b,stroke-width:2px,color:#1f2937
style WARN fill:#fef2f2,stroke:#dc2626,stroke-width:2.5px,color:#1f2937
linkStyle 0 stroke:#d97706,stroke-width:2.4px
linkStyle 1 stroke:#d97706,stroke-width:2.4px
linkStyle 2 stroke:#d97706,stroke-width:2.4px
linkStyle 3 stroke:#64748b,stroke-width:1.8px,stroke-dasharray: 5 4
linkStyle 4 stroke:#64748b,stroke-width:1.8px,stroke-dasharray: 5 4
linkStyle 5 stroke:#64748b,stroke-width:1.8px,stroke-dasharray: 5 4📡 扩展 Anthropic 在长时运行 Agent 研究中，将状态管理问题类比为”换班的软件工程师”——每个新班次的工程师到来时，对前一班做的事毫无记忆。其解决方案是双 Agent 架构 + 状态外化：Initializer Agent 在首次会话建立结构化环境（功能清单文件、进度日志
claude-progress.txt、Git 基线、init.sh启动脚本），后续 Coding Agent 每次会话从这套外化记忆中读取状态、推进一小步、提交进度。状态不住在模型记忆里，而住在文件系统和 Git 历史中。
3.5 第五层：评估与观测
这是最容易被团队忽视的一层。 很多系统不是生成不出来，而是生成完之后根本不知道自己做得好不好，从而长期处于”自我感觉良好”的状态。
这一层通常包括以下能力：
flowchart LR
%% 核心中枢
EV["**⑤ 评估与观测**<br>(Observability)"]
%% 五大并行支柱 (文字稍微精简，更具结构感)
EV1["**输出验收**<br>对生成结果做结构化验证"]
EV2["**环境验证**<br>在真实环境中运行并观测"]
EV3["**自动测试**<br>涵盖单元/集成/UI截图"]
EV4["**日志与指标**<br>保留可追溯的运行记录"]
EV5["**错误归因**<br>精准定位故障环节与根因"]
%% 连线 (使用带箭头的粗线段，强调派生关系)
EV ==> EV1
EV ==> EV2
EV ==> EV3
EV ==> EV4
EV ==> EV5
%% 样式美化：主节点突出，子节点统一
style EV fill:#f3e5f5,stroke:#8e24aa,stroke-width:3px
style EV1 fill:#fafafa,stroke:#ab47bc,stroke-width:1px
style EV2 fill:#fafafa,stroke:#ab47bc,stroke-width:1px
style EV3 fill:#fafafa,stroke:#ab47bc,stroke-width:1px
style EV4 fill:#fafafa,stroke:#ab47bc,stroke-width:1px
style EV5 fill:#fafafa,stroke:#ab47bc,stroke-width:1px系统不仅要会做，还要知道自己有没有真的做对。
📡 扩展 Anthropic 发现了一个普遍存在的问题：自评失真（Self-Evaluation Bias）。当模型被要求评估自己刚刚生成的内容时，它倾向于给出偏乐观的正面评价，即便输出质量在人类看来明显一般——在设计体验、产品完整度等没有标准答案的领域，偏差尤为显著。根本原因在于：生成者与评估者使用的是同一套参数和推理路径，天然存在”自我辩护”的倾向。解决方案是生产与验收分离，引入独立的 Evaluator Agent，使用 Playwright 等工具真实操作页面、执行测试用例、检查实际交互结果，而非仅做代码审查。
3.6 第六层：约束、校验与恢复
这往往才是真正决定一个系统能不能上线的关键环节。
真实环境里，失败不是例外，而是常态：搜索不准、API 超时、文档格式混乱、模型误解任务……没有恢复机制，Agent 每次出错只能从头再来。
flowchart TD
%% 融合了静态概念定义与动态执行工作流
%% 节点定义与语义化形状
R1(["**① 约束 (Guardrails)**<br>定义边界：明确哪些被允许，哪些绝对禁止"])
EXEC["**执行与捕获 (Execution)**<br>运行任务并捕获产出或异常状态<br>⚠️ 含: API超时 / 格式错 / 模型误解"]
R2{"**② 校验 (Validation)**<br>输出前格式预检<br>输出后结果正确性自检"}
R3["**③ 恢复 (Recovery)**<br>阻断错误蔓延，从检查点回滚至最近稳定状态"]
OK(["**✅ 继续后续编排**<br>(Proceed)"])
RETRY(["**🔄 补偿策略**<br>降级 / 延时重试 / 人工介入"])
%% 核心执行流 (加粗连线)
R1 ==>|"前置防线通过"| EXEC
EXEC ==>|"提交运行时产出"| R2
%% 决策分支
R2 == "✅ 校验通过" ==> OK
R2 -- "❌ 校验失败/捕获异常" --> R3
%% 恢复与自愈闭环 (虚线表示容错回路)
R3 -. "触发" .-> RETRY
RETRY -. "携带修正策略重新执行" .-> EXEC
%% 样式美化与色彩工程学
style R1 fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
style EXEC fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
style R2 fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
style R3 fill:#ffebee,stroke:#e53e3e,stroke-width:2px
style OK fill:#e8f5e9,stroke:#43a047,stroke-width:3px
style RETRY fill:#ffebee,stroke:#e53e3e,stroke-width:2px,stroke-dasharray: 5 5📡 扩展 LangGraph 将运行时错误细分为四类，并对应不同处理策略：短暂性错误（指数退避后重试）、LLM 可恢复错误（作为 ToolMessage 返回，让模型自行调整）、用户可修复错误（中断执行，请求人工输入）、意外错误（冒泡至调试系统，禁止自动重试）。Anthropic 的做法是将工具调用失败作为错误结果返回给 Agent，保持主循环继续运行而非崩溃退出。Stripe 的生产 Harness 将自动重试上限定为两次。
四、实践案例
4.1 Anthropic 的实践：两大工程难题与解法
问题一：上下文焦虑（Context Anxiety）
任务越长，上下文越撑满，模型开始丢细节、丢重点，甚至出现一种有趣的现象：它好像感知到自己”快装不下了”，于是着急草草收尾。
Anthropic 的解决路径是分层递进的：
flowchart TD
%% 节点定义与语义化形状
A(["**① 上下文压缩 (Context Compaction)**<br>将早期对话就地摘要，维持会话连续性"])
B{"**② 触发上下文焦虑？**<br>(Context Overflow / Anxiety)"}
C["**③ 上下文重置 (Context Reset)**<br>启用全新干净的 Agent 接管任务<br>通过文件或 Git 等持久化存储交接状态"]
D(["**④ 自动滚动续写 (Continuous Run)**<br>依赖超长上下文能力无缝继续<br>无需干预 (如旗舰级新模型)"])
%% 连线与分支逻辑
A ==>|"窗口占用持续攀升"| B
%% 异常/干预干线 (使用橙色警告色调)
B -- "⚠️ 是 (模型能力达标上限)" --> C
%% 常规/成功路线 (使用绿色加粗安全连线)
B == "✅ 否 (长文本模型支持)" ==> D
%% 样式美化与视觉焦点分组
%% 起点认知层 (蓝色)
style A fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
%% 决策中枢 (紫色)
style B fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
%% 外部干预重置 (橙色/警告)
style C fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
%% 顺📡 扩展 Anthropic 在测试中发现，Claude Sonnet 4.5 的上下文焦虑严重到仅靠压缩无法解决，上下文重置成为当时 Harness 设计的必要环节。但当将同一套 Harness 迁移至 Claude Opus 4.5 后，这一行为几乎完全消失，上下文重置也随之从 Harness 中移除。这揭示了一个重要原则：Harness 是对当前模型局限性的编码，这些假设必须随模型迭代而持续重新审视，而不是一次性固化下来。 Claude Opus 4.6 引入 100 万 Token 上下文窗口后，上下文焦虑作为一个实际问题已基本消除。
问题二：自评失真（Self-Evaluation Bias）
让干活的人给自己打分，结果必然偏乐观。Anthropic 的解决方案是引入三角色分离架构：
sequenceDiagram
autonumber
participant U as 用户/需求方
participant P as Planner(规划者)
participant G as Generator(执行者)
participant E as Evaluator(验收者)
rect rgb(227,242,253)
Note right of U: 【阶段一】需求规划
U->>+P: 提交原始模糊需求
P->>P: 将模糊需求扩展为<br/>完整PRD/测试规格(200+条)
P-->>-G: 下发完整规格与功能清单
end
rect rgb(255,243,224)
Note right of U: 【阶段二】执行与验收闭环
loop 增量开发与验收(每个功能点)
G->>G: 编写/修改单个功能代码
G->>+E: 提交运行时产出发起验收
E->>E: 启动E2E验证(如Playwright)<br/>模拟真实点击与状态断言
alt 验收失败(验证未通过)
E-->>G: 驳回：反馈具体报错日志与截图
Note right of G: 根据反馈修正策略
else 验收成功(验证通过)
E-->>-G: 确认：该功能点验收通过
end
end
end
rect rgb(232,245,233)
Note right of U: 【阶段三】最终交付
E->>U: 所有规格均验收通过，交付成品
end关键原则：Evaluator 不只看代码，而是真实操作页面，检查具体交互和实际结果。 这是工程原则”生产与验收必须分离”在 Agent 系统中的直接映射，确保系统形成真正有效的生成—检查—修复闭环。
4.2 OpenAI 的实践：重新定义工程师的角色
OpenAI 提出了一个颠覆性的工作方式：人类工程师在环境中不需要写一行代码，只需要负责设计环境。
工程师的工作浓缩为三件事：
flowchart LR
%% 核心角色定义 (圆角矩形，视觉起点)
ENG(["**工程师的新使命**<br>(Harness 时代)"])
%% 三大核心工作转变 (修复了原生双引号导致的语法错误，统一使用 <br> 换行)
E1["**① 任务拆解 (Decomposition)**<br>将宏大的产品目标分解为<br>Agent 能力级别的细粒度微型任务"]
E2["**② 能力诊断 (Diagnostics)**<br>失败时不再要求模型'更努力'<br>而是诊断环境缺失了何种结构性能力"]
E3["**③ 构建反馈链路 (Feedback Loop)**<br>打通运行沙盒与日志<br>让 Agent 真正'看到'自己的工作结果"]
%% 使用加粗连线表示职责的强关联
ENG ==> E1
ENG ==> E2
ENG ==> E3
%% 样式美化与色彩工程学 (采用代表工程师与架构的深蓝到浅蓝过渡)
style ENG fill:#e8eaf6,stroke:#3f51b5,stroke-width:3px
style E1 fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
style E2 fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
style E3 fill:#e3f2fd,stroke:#1e88e5,stroke-width:2pxOpenAI 还将大量资深工程师的经验直接编码为系统规则，内嵌到 Harness 中自动执行：
- 模块怎么划分？哪一层不能依赖哪一层？
- 什么情况必须拦截？发现问题后该按哪个流程修复？
重点是：这些规则不只是报警，还会把”怎么修”一起反馈给 Agent，进入下一轮上下文。
📡 扩展 这已经不是传统意义上的代码规范，而是一套可运行的自动治理系统（Automated Governance System）。Anthropic 将其进一步产品化为 Claude Managed Agents 服务（2026 年 4 月进入公测），通过三层抽象将 Harness 基础设施从开发者身上剥离：Session（追加写入的完整事件日志）、Harness（调用 Claude 并路由工具调用的主循环）、Sandbox（安全隔离的执行环境）。这一设计类比操作系统对硬件的虚拟化——接口保持稳定，底层实现随模型进化自由演进。
五、核心结论
5.1 三层工程的边界与包含关系
flowchart TD
%% 采用最基础的节点语法，放弃嵌套
HE["**Harness Engineering (最大边界)**<br>整个运行系统的工程化"]
CE["**Context Engineering (中间边界)**<br>输入环境的工程化"]
PE["**Prompt Engineering (最小边界)**<br>指令的工程化"]
%% 用无向线段表示包含/底层支撑关系
HE ---|包含| CE
CE ---|包含| PE
%% 最基础的直接样式注入
style HE fill:#fff3e0,stroke:#ff9800,stroke-width:2px
style CE fill:#e3f2fd,stroke:#2196f3,stroke-width:2px
style PE fill:#f3e5f5,stroke:#9c27b0,stroke-width:2px| 工程层级 | 解决的问题 | 代表工具/实践 | 适用场景 |
|---|---|---|---|
| 提示词工程 | 怎么把任务讲清楚 | 角色设定、CoT、Few-shot | 简单单轮生成 |
| 上下文工程 | 怎么把信息给对 | RAG、记忆管理、动态注入 | 依赖外部知识的任务 |
| Harness 工程 | 怎么让模型持续做对 | 编排、状态、评估、约束恢复 | 长链路、低容错生产 Agent |
5.2 五条关键洞察
flowchart TD
%% 采用最基础安全的语法，避免渲染失败
I1["**① 模型决定上限**<br>Harness 决定能否落地"]
I2["**② Agent 的失败是系统的失败**<br>不是模型的失败"]
I3["**③ 评估者必须独立于生产者**<br>生成与验收分离才有效闭环"]
I4["**④ Harness 必须随模型迭代**<br>今天的必要设计可能是明天的负担"]
I5["**⑤ 上下文是稀缺资源**<br>渐进式披露 > 一次性全给"]
%% 使用虚线连接，表示向下阅读的引导，而非严格的流程依赖
I1 -.-> I2 -.-> I3 -.-> I4 -.-> I5
%% 扁平化彩色卡片样式
style I1 fill:#e3f2fd,stroke:#2196f3,stroke-width:2px
style I2 fill:#f3e5f5,stroke:#9c27b0,stroke-width:2px
style I3 fill:#e8f5e9,stroke:#4caf50,stroke-width:2px
style I4 fill:#fff3e0,stroke:#ff9800,stroke-width:2px
style I5 fill:#ffebee,stroke:#f44336,stroke-width:2px5.3 场景适用建议
| 你的场景 | 建议层级 | 核心投入方向 |
|---|---|---|
| 简单 Q&A / 单次内容生成 | 提示词工程 | 提示词设计，Harness 是过度设计 |
| 需要外部知识、实时信息 | 上下文工程 | RAG 管道、上下文裁剪与排序 |
| 多步骤任务、工具调用 | 上下文工程 + 工具系统 | 工具选型、调用时机、结果处理 |
| 长链路 Agent、生产环境 | 完整 Harness | 六层架构全量设计 |
| 自动化代码生成 / 复杂工作流 | 完整 Harness + 独立评估 | 三角色分离 + Playwright 验收 |
参考资源
- Anthropic Engineering: Effective harnesses for long-running agents
- Anthropic Engineering: Harness design for long-running application development
- Anthropic Engineering: Effective context engineering for AI agents
- Anthropic Engineering: Claude Managed Agents
- Martin Fowler: Harness engineering for coding agent users
- The Anatomy of an Agent Harness – Daily Dose of DS
- Agentic Harness Engineering: LLMs as the New OS
📌 查看说明： 本笔记所有图表均使用 Mermaid 语法编写。 推荐使用 VSCode + Markdown Preview Enhanced 插件 查看，可完整渲染所有流程图与时序图。 在线渲染可访问 mermaid.live。