主题
一文了解 Harness Engineering
来源: WXG技术能力提升 KM平台 | 作者: tobiazhang | 日期: 2026-03-30
导语: Harness Engineering 是包裹在大模型外部，使 Agent 能在真实环境中长期、安全、可控执行任务的系统工程层。其核心架构由确定性外壳（状态机 / 检查点 / 幂等 / 错误恢复 / Token 预算）包裹非确定性内核（LLM），五大子系统（Environment → Tools → Control → Memory → Evaluation）+ Task Loop + 上下文工程 + 可观测性形成闭环。
1. 为什么要谈 Harness
大模型已经可以读代码、写前端、连数据库、驱浏览器，但真正拉开差距的不再是"能不能生成一个像样的答案"，而是**"能不能在真实系统里，稳定地把一件复杂事做完"**。
把 Agent 放进生产环境时，几乎所有团队都会撞上同样的问题：
| 问题 | 表现 |
|---|---|
| Demo 惊艳，上线即崩 | 循环卡死、工具乱用、任务半途而废 |
| 跨天长任务无法延续 | 一断会话就"失忆" |
| 代码库被 AI 写碎 | 风格不一致、架构漂移、测试常挂 |
| 审计与回溯不可能 | 出了问题不知道哪一步开始跑偏 |
这些问题的共同点：和模型本身关系不大，而是系统工程问题。因此业界用一个统一的词来指代"模型外面的所有东西"——Harness。
Agent = Model + Harness。如果你不是模型，那就是 Harness。
2. 核心概念：什么是 Harness
2.1 定义：模型外面的"操作系统"
围绕 LLM/Agent 所构建的确定性控制系统，使其在不确定的模型内部之上，仍然能长期、可恢复、可审计地完成复杂任务的工程方法论与实践集合。
Harness 不是"某个库"，而是一整套系统能力的组合：
- Context Injection（上下文注入）: 角色、目标、当前任务状态、技能说明
- Tools & Environment（工具与执行环境）: 文件系统、Bash、语言运行时、浏览器、API、MCP
- Control / Orchestration（控制与编排逻辑）: 调用顺序、循环结构、中止条件、配额限制
- Persistence / Memory（持久化与状态管理）: 进度文件、任务状态、日志、Git 历史
- Observe & Verify（观察与验证）: 测试结果、日志、浏览器截图、监控指标与审计
"计算机四件套"类比：
| 类比 | 对应 |
|---|---|
| CPU | Model（算力与决策） |
| 内存 | 上下文窗口（短时工作区） |
| 操作系统 | Harness Runtime（资源管理、进程调度、约束、I/O） |
| 应用程序 | Agent（跑在"AI OS"之上的具体智能体） |
模型决定"上限能做什么"，Harness 决定"实际能做成多少、能撑多久"。
2.2 与 Prompt / Context Engineering 的演进关系
| 阶段 | 时间 | 核心关注点 |
|---|---|---|
| Prompt Engineering | 2022–2024 | 如何写好一次性 prompt（few-shot、CoT、角色扮演） |
| Context Engineering | 2025 | 如何为每次调用动态构建完整上下文：相关文件、历史对话、检索 |
| Harness Engineering | 2026 起 | 如何设计一个长期运行的控制系统：状态、约束、工具系统、反馈 |
演进本质：
- Prompt 问："这句话怎么说更好？"
- Context 问："模型应该看见哪些信息？"
- Harness 问："整个系统应该怎么运行，才能保证模型在几小时、多轮、多工具、多会话的条件下，仍能稳定交付结果？"
2.3 Harness 与传统软件工程的异同
| 维度 | 传统软件工程 | Harness Engineering |
|---|---|---|
| 核心执行体 | 确定性代码，给定输入可静态分析 | LLM：概率性、会幻觉、对隐含约束理解不稳定 |
| 推理与控制 | 逻辑与控制都在代码里 | 推理在 LLM 内部，控制逻辑留在"外壳"——状态机 |
| 状态管理 | 内存 / 存储对象 | 除此之外还有"语言上下文"（Chat history、RAG 文档） |
| 评估与验收 | 单元测试 + 集成测试 + Code Review | LLM Evaluator + 工具做自动验证 |
本质差异: 软件工程假定核心逻辑是确定的；Harness 假定核心执行者是概率性的、会犯错，工程目标从"让程序按 spec 跑"变成**"在一个不可靠但很聪明的执行体上，构建可靠系统"**。
3. 模型边界：为什么必须有 Harness
3.1 模型天然的限制
大模型本质就是一个函数 f: (文本, 图像, 其他模态) → 文本，天然不具备：
- 长期记忆: 只看到当前上下文窗口
- 外界执行能力: 不能直接运行代码、读写文件、访问网络
- 状态持久化: 每次调用都是"无副作用的函数"
- 安全隔离: 不知道"哪些操作危险"
| 你想让 Agent… | Harness 需要提供… |
|---|---|
| 记住昨天改过哪个文件 | 状态写到文件或数据库 |
| 真的跑测试 | 可控的代码执行环境 |
| 不无限循环 | 步数、时间、状态机约束 |
| 挂掉后恢复 | 任务日志和恢复流程 |
3.2 最小 Agent Loop：为什么 Demo 能跑，生产就崩
python
while not finished:
observation = environment()
thought = model(observation)
action = choose_action(thought)
result = run_tool(action)
update_state(result)致命缺陷：
| 缺陷 | 表现 |
|---|---|
| 无进度感知 | 不知道完成度、剩余工作量 |
| 无阶段划分 | 所有步骤混在一起 |
| 无系统级失败恢复 | 错误可能在错误路径上一错再错 |
| 终止条件完全由模型感知 | 容易"还没做完就宣布完成"或"已完成还在瞎忙" |
| Context rot | 历史对话越积越多，关键信息被淹没 |
| 单次崩溃导致整个长任务报废 | 没有恢复点 |
4. 核心设计哲学：确定性外壳 vs 非确定性内核
4.1 总体模式
用一个尽可能确定性的外壳（deterministic shell），包裹一个高度能力但非确定的模型内核（stochastic core），让系统整体表现出可预测、可恢复、可审计的行为。
| 层 | 职责 |
|---|---|
| 内核（LLM/Agent） | 自然语言理解与生成、复杂规划与抽象、代码生成与文档撰写 |
| 外壳（Harness） | 任务生命周期管理（Task Loop/State Machine）、资源预算与限流、错误分类与重试 |
凡是能用确定性机制表达的约束，就不要只写在 Prompt 里。
4.2 状态机设计
Task Loop 是一个显式状态机，运行在模型外部，由控制层驱动；模型只在特定状态被调用执行"思考 + 生成"。
典型状态流转：
INIT → PLANNING → EXECUTING_STEP → WAITING_QA → APPLYING_FIX → WAITING_HUMAN → DONE / FAILED4.3 检查点（Checkpoint）与幂等性
长任务必须接受的现实：中断几乎必然发生（网络波动、API 限流、服务重启、部署更新）。
Checkpoint 机制承担两件事：
- 周期性持久化任务状态: 当前阶段、执行到第几步、中间结果、关键 artifact
- 提供可恢复入口: 从最近一次 checkpoint 恢复，而不是从 0 开始
Checkpoint 不是上下文压缩。压缩是在同一会话里做摘要；Checkpoint 是把状态写出模型、交给系统保存，新会话只注入必要片段。
结合幂等性: 恢复后对外部世界的副作用不能重复。例如发送邮件前先写 outbox 表，用业务 idempotency key 保护支付、工单创建等 API。
4.4 错误恢复与重试策略
Harness 引入系统级错误分类与恢复策略：
| 类别 | 场景 | 策略 |
|---|---|---|
| A：临时性 | 超时、短期限流 | 指数退避重试，限制次数 |
| B：幂等可回滚 | 写中间状态失败 | 回滚到上一个 checkpoint |
| C：权限/安全 | 越权访问 | 直接 fail + 触发人类检查 |
| D：逻辑错误 | 代码 bug、设计缺陷 | 生成详细 bug 描述交给 Generator 修复 |
LLM 的角色变为"生成修复方案"，而不是"自己当错误分类器 + 调度器"。
4.5 上下文管理与 Token 预算控制
上下文不是内存，是"注意力预算"。
两个核心挑战：
- 任务目标被"稀释": 执行几十步后，最初任务描述被压到 Context 边缘
- 错误链式传播: 中间错误被后续步骤当作真相
上下文管理策略：
- 任务目标/全局 spec 放在持久化文档中（
product-spec.md、AGENTS.md） - 当前阶段关键信息从 Task State/Memory 中抽取摘要
- 模型历史对话利用自动 compaction/摘要压缩
Token 预算两层控制：
| 层级 | 机制 |
|---|---|
| 全任务级 | "本任务最多 10M token"，到达阈值前必须收敛或人工介入 |
| 阶段/步骤级 | 每个阶段单独设上限，防止一个子问题吃掉所有预算 |
5. 核心架构：生产级 Harness 像一个小型操作系统
5.1 五大核心子系统
Environment（环境） —— 给 Agent 一个受控的工作世界
- 文件系统（代码库、配置、文档）、沙箱终端、浏览器环境、网络访问
Tool System（工具系统） —— 对环境能力做抽象封装
read_file(path)/write_file(path, content)/run_test(test_name)/search_code(query)- 要求接口简单、能力强、行为可预期
Control（控制层） —— 管理 Agent Loop 的执行边界
- 步数/时长限制、循环与分支的结构约束、权限控制与危险操作拦截、错误处理
Memory（记忆/状态系统） —— 解决长任务/跨会话的状态问题
- 任务进度文件、Feature list、角色与架构文档（
AGENTS.md）、Git 历史、长期记忆文件
- 任务进度文件、Feature list、角色与架构文档（
Evaluation（自动化检查/验证） —— 让系统自己知道"做得好不好"
- 单元测试、集成测试、Linter、UI 自动化、第二模型/规则引擎做结果评审
5.2 典型分层视图
| 层 | 组成 |
|---|---|
| 知识层 Knowledge | AGENTS.md / CLAUDE.md 作为地图、docs/ 设计文档 / 产品 spec |
| 约束与流程层 | 架构分层规则、模块依赖方向、访问策略等硬约束；Task Loop 状态机 |
| 反馈与运行时层 | 工具系统（浏览器、测试框架、日志/指标查询、CI/CD）；可观测性 |
| Agent 层 Personas | Planner / Architect / Researcher；Generator / Coder；Evaluator |
| 接口层 Interface | 与用户系统集成（API、CLI、IDE 插件）；与第三方 Agent 框架集成 |
5.3 Anthropic 架构模式
模式一：两角色接力 —— Initializer & Coding Agent
- Initializer Agent: 创建/同步仓库 → 写 feature list → 初始化 progress file → 配置环境脚本 → 写基础架构文档
- Coding Agent: 读取 progress file → 选择未完成 feature → 围绕任务工作 → 跑测试 → 更新 progress file → 提交 Git commit
关键设计：任务完成条件是结构化的（JSON），每次只拿一个任务跑一个短闭环。
模式二：三 Agent Harness —— Planner + Generator + Evaluator
| 角色 | 职责 |
|---|---|
| Planner | 从一句短 prompt 展开为详细产品 spec 和多 sprint 计划 |
| Generator | 按 sprint 逐个实现 feature，并自评 |
| Evaluator | 独立 QA，基于 Playwright 驱动真实页面/API/DB 执行，按预先约定的 contract 打分 |
两类运行时机制：
- Context Reset + 结构化 Handoff: 清空历史、生成 handoff artifact 让后续会话续跑
- 外部 Evaluator: 将"评价"从生成者身上剥离，通过单独调教使其更苛刻
5.4 与 LangChain / CrewAI 等框架的关系
| 维度 | LangChain / CrewAI | Harness |
|---|---|---|
| 聚焦 | Prompt 模板、RAG 链、工具调用、Agent 间信息传递 | 任务级状态管理、资源预算、错误恢复 |
| 与工程设施关系 | 较浅 | 与仓库/测试/浏览器等深度集成 |
| 知识管理 | RAG 向量检索 | 显式化文档 + 架构硬约束 |
两者不互斥：可以在 LangChain 内定义长任务链，由 Harness 管理执行环境。
6. Task Loop：长任务执行引擎
6.1 五个核心机制
6.1.1 任务分解与阶段管理
- 先规划后执行：短 prompt → Planner 生成详细 spec / backlog / sprint 列表
- 每个阶段有明确目标与可验证输出（contract）
- 好处：上下文简化、错误定位清晰、自然与 checkpoint 对齐
6.1.2 检查点与断点续跑
中断不是异常，是常态。
断点续跑流程：
- 任务重启 → 从存储系统加载最近 checkpoint
- 初始化新 Agent 会话，仅注入必要摘要
- Task Loop 从对应状态继续推进
6.1.3 错误处理与自动恢复
三层策略：
- 工具级重试: 网络/限流类自动退避重试
- 步骤级回滚: 逻辑失败 → 回滚到前一个 checkpoint → 尝试 alternative plan
- 任务级降级或人工介入: 多次失败 → 标记需要人类干预
6.1.4 资源管控与终止条件
- Task Loop 必须显式管理最大步数/阶段数、每步最大 token/响应时间、整体成本预算
- 终止判定不能只依赖 LLM "我觉得已完成"：编码任务以测试全部通过为准；UI 功能以 Playwright 清单通过为准
6.1.5 人机协作节点（Human-in-the-Loop）
必须人来拍板的操作：不可逆操作（删库、批量退款）、超预算任务继续与否、高风险修改（安全策略、权限变更）。
进入 WAITING_HUMAN → 记录 snapshot → 向审批 UI 发送结构化问题 → 人完成后继续。
6.2 四条工程原则
- 规划与执行必须分离: 路线先走通再开始跑；规划可用更强推理模型，执行用更便宜模型
- 每一步都要有可观测的输出: 记录每步的输入/思考/输出/工具调用，不允许"黑盒 step"
- 幂等性是硬要求: 任何可能被重放的动作必须幂等
- 任务状态要与模型上下文解耦: 状态由系统管理，模型在每步只被告知"当下必需信息"
7. 工程实践模式
7.1 Context Reset vs Compaction vs Handoff
| 策略 | 机制 | 优点 |
|---|---|---|
| Compaction | 同一会话内对早期对话做摘要 | 连续，开销低 |
| Context Reset + Handoff | 完全清空聊天历史，用结构化文档 handoff.json 向新会话传递状态 | 给模型"干净的起点"，避免错误污染 |
Compaction 是模型自己给自己写笔记；Handoff 是 harness 从外部事实拼出交接报告。Handoff 能更好地避免错误污染。
7.2 Heartbeat 与 Watchdog
对于几小时乃至几十小时的 Agent 任务，必须有外部监护机制：
- Heartbeat: 将健康信号写入存储（当前 step、最近成功工具调用时间、累计 token/错误次数）
- Watchdog: 独立进程监控 heartbeat——心跳超时 → 标记异常；发现环路 → 触发循环检测
7.3 工具编排与调度策略
- 工具描述与分组: 按风险等级/域分组（只读工具、高风险写工具、系统工具）
- 工具可见性控制: 根据任务/当前状态/角色暴露不同子集（Planner 不给数据库写权限）
- 路由与策略: path 黑名单拒绝调用、特定文件必须走特定工具
- 并发与序列化: 某些工具可并行（多文件静态分析），某些必须顺序（数据库 schema 迁移）
7.4 并发与并行执行模式
| 模式 | 适用场景 |
|---|---|
| 队列 + Worker Pool | 高吞吐、任务间高度独立 |
| Session per branch / worktree | 每次改动起一个 git worktree，Agent 在该环境中跑完变更 |
| 多 Agent 分职责并行 | Evaluator 跑 QA 时 Planner 预先拆解下一大块任务 |
7.5 人机协作（Human-in-the-Loop）
Harness 需要把人纳入闭环，而不是只在"失败时找人背锅"：
- 明确审批节点: Task Loop 定义
HUMAN_REVIEW状态 - 结构化呈现上下文与选项: Evaluator 列出 QA 条目供人查看
- 双向影响: 人的决策可进入 Harness 配置，形成"错误 → 修补 → 持续改进"
8. 控制论视角：三次历史重演
| 时代 | 系统 | 变化 |
|---|---|---|
| 18 世纪 | 瓦特离心调速器 | 工人从"实时拧阀门" → 设计调速器，系统自动感知转速并调节 |
| 2010s | Kubernetes 控制器 | 工程师从"手动重启/扩容" → 声明期望状态，K8s 自动调整差异 |
| 2026 | Harness Engineering | 工程师从"逐步提示 Agent" → 设计环境、约束、反馈回路 |
反馈回路在更高一层闭合，人的工作从"亲手调参"变成"设计控制系统"。
9. 实证数据与真实案例
9.1 改壳不改模，性能翻倍
| 实验 | 结果 | 唯一变量 |
|---|---|---|
| Nate B Jones | 编程基准 42% → 78% | 仅更换 Agent Harness |
| LangChain（Terminal Bench 2.0） | 52.8% → 66.5%，排名第 30 → 前 5 | 优化 Harness |
| Pi Research | 一个下午内 15 个 LLM 编码表现整体提升 | 统一优化 Harness |
9.2 Stripe "Minions"：每周 1300 个无人值守 PR
- Blueprint 编排：将流水线拆成确定性节点和 Agentic 节点
- CI 最多两轮：第一轮失败 → Agent 修复 → 再跑一次 → 仍 FAIL 则交给人类
- 工具平台 Toolshed 注册了 ~500 个 MCP 工具，但给单个 Agent 的是精挑细选的子集
- 递归 Planner-Worker 结构，峰值 ~1000 commit/h，一周千万级工具调用
- 经历了 5 次 Harness 重构，最终版：递归 Planner + Worker，每个 Agent 在隔离上下文与仓库副本中工作
9.3 Cursor "Self-Driving Codebases"：每小时 1000 个 commit
- 递归 Planner-Worker 结构，峰值 ~1000 commit/h
- 经历 5 次 Harness 重构
9.4 OpenAI Codex：100 万行代码，人类零行
5 个月，7 个工程师，从空仓库开始：~100 万行代码、~1500 个 PR，人类一行代码没写。
关键 Harness 实践：
- 仓库即大脑: 对 Agent 来说，看不见的知识等于不存在
- AGENTS.md 作为"地图": 约百行，指向架构、规范、技能文档
docs/树形结构: 包含design-docs/、product-specs/、exec-plans/、references/- 强分层架构 + 静态约束: Types → Config → Repo → Service → Runtime → UI，只允许"向前依赖"
- 可观测性接进 Agent: Chrome DevTools、日志、指标、trace 暴露给 Agent
- CI 错误信息内嵌修复指引: 既面向人也面向 Agent
- 持续"工程化修补": 每当 Agent 频繁犯某类错，就增加对应规则或工具
他们最大的挑战，不在于写代码，而在于设计环境、反馈循环和控制系统。
9.5 Retro 2D 游戏编辑器：单 Agent vs Harness
| 维度 | 单 Agent | Harness（三 Agent） |
|---|---|---|
| 时长 | 20 分钟 | 6 小时 |
| 成本 | ~$9 | ~$200 |
| 表面效果 | 有项目创建界面、关卡编辑 UI | 精灵动画、行为模板、音效、AI 辅助关卡 |
| 实际质量 | 运行时实体无响应，功能未正确触发 | 功能丰富且真正可玩 |
Harness 的真正价值不是提升模型能力，而是让能力有机会转化为"真正完成的产品"。
9.6 Web DAW（浏览器数字音频工作站）
- 使用简化 Harness（Opus 4.6）：保留 Planner 和 Evaluator，去掉 sprint 机制
- 总运行 3h50m、$124.70
- 产出功能：时间轴、Mixer、Transport、基于 Web Audio API 的音频处理、内嵌 AI Agent
- Evaluator 多轮 QA 发现具体问题并修复
Harness 可以随模型升级而减重，但验证层不会消失。
10. 反模式与常见陷阱
| 反模式 | 问题 | 改法 |
|---|---|---|
| 把所有规则都写进 Prompt | 长列表遵守率随轮次下降、文档腐烂 | AGENTS.md 百行内作为索引，约束落在 linter/CI/sandbox/状态机中 |
| 只追求"多 Agent"忽略 Task Loop | 缺少任务状态模型，通过"聊天转发"通信 | 单 Agent + 清晰 Harness 先跑稳 → 再按责任边界引入关键 Agent |
| 长期状态只放在上下文中 | 目标被稀释、无法断点恢复 | 引入外部 Task Store，每步只注入必要片段 |
| 没有系统级 QA，只让模型自评 | 模型倾向乐观评价 | 引入独立 evaluator agent + 真实运行测试 |
| 没有幂等性 | Checkpoint 恢复后重复操作 | 为所有可能重放操作设计业务级幂等 key |
11. 路线之争：Big Model vs Big Harness
11.1 "拐杖论" —— Harness 会被更强模型淘汰吗？
Noam Brown（OpenAI）观点: 新一代推理模型出来后"花里胡哨的脚手架很多不仅不再需要，甚至会拖后腿"。
METR 的评估: Claude Code / OpenAI Codex 这类高级 Harness 与简单脚手架在 SWE-Bench 上差距并不显著。
11.2 Big Harness 阵营 —— 车速越快护栏越重要
- 护栏悖论: 时速 30km 可以没护栏 → 时速 120km 必须中央隔离带 → 时速 300km 高铁整条线路封闭 → 引擎越强、速度越快，"护栏"越重要
- 约束提升效率: Vercel 工具 15 → 2，准确率 80% → 100%
- Harness 设计要轻量与可废弃: Start simple, Build to delete
综合判断:
- "复杂编排/多层路由的脚手架"确实有被更强模型淘汰的趋势
- "控制论意义上的 Harness"（状态、约束、工具、安全、验证）不会消失，只会标准化并下沉为基础设施
- 真正的风险是"花 6 个月造一个又厚又僵硬的 Harness"
12. 七大模块与五大工程原则
12.1 七大模块
| 模块 | 目标 | 核心实现 |
|---|---|---|
| Environment | 给 Agent 受控的工作世界 | Git worktree、隔离文件系统、沙箱终端/Docker |
| Tools | 离散、可审计的 action 操控环境 | 接口简洁、每个工具只做一件事、纯函数+幂等 |
| Control | 系统始终在护栏内运行 | 步数/时长限制、异常检测、任务状态机、危险操作拦截 |
| Memory / State | 解决长期/跨会话持续性 | progress file、feature list、AGENTS.md、Git |
| Evaluation | 系统自己知道做得好不好 | 单元/集成测试、Linter、UI 自动化、第二模型评审 |
| Context Engineering | 有限 token 下喂最重要的信息 | 历史压缩、工具输出卸载、按需加载 Lazy skill |
| Observability | 构建 Agent 的"黑匣子" | 每 step 的 request/response、状态变更事件流 |
12.2 五大工程原则
- 尽量减少模型需要记住的内容: 系统状态储存在 Harness 持久化层，模型只需关心当下决策所需信息
- 把规则写进系统，而不是写在 prompt 里: "提交前必须跑测试" → CI 中必跑；"禁止跨层依赖" → 静态依赖分析强制
- 工具接口要尽可能简单:
read_file + write_file比"同时读取+分析+写回"的超级工具更稳；Vercel 15 个工具 → 2 个，准确率 80% → 100% - 任务状态必须持久化: Feature list + Progress file 组合；Agent 崩溃后可从文件/DB 恢复
- 系统必须可观测、可诊断: 记录每轮 LLM 调用、状态变更、资源消耗、错误与异常
13. 从 0 到 1 构建路线图
第一步：最小可用 Harness
只需三样：
- 隔离环境: 工作目录或仓库副本 + sandbox
- 两三个基础工具: 读写文件 / 运行测试 / 执行命令
- 简单 Agent Loop: 人手触发，每次只解决一个小任务
第二步：把"经验"写进 Harness
Engineer the Harness：每当 Agent 犯一次"可复现的错"，分析原因并选择方式写回系统。
| 原因类别 | 写回方式 |
|---|---|
| 缺少文档 | 在 AGENTS.md 增加规则 |
| 工具设计有坑 | 改进工具接口 |
| 缺少结构化约束 | 增补 linter / test |
| 没有验证/测试 | 增加新的状态字段或测试用例 |
第三步：拆出 Control / Memory / Evaluation
- Control: 给任务一个状态机，给 Agent Loop 设硬边界，危害大的工具增加审批
- Memory: 推出 progress file / task DB，把任务进度从对话中剥离
- Evaluation: 把最重要的检查自动化，明确"什么算 done"
这一步是从"能跑 Demo"到"敢跑生产"的分水岭。
第四步：引入多 Agent 与角色接力
- Anthropic Init / Coding Agent 做角色拆分
- 引入 Planner → Worker 结构
- 独立 Verifier Agent 负责评审关键步骤
多 Agent 不一定更好，只有在任务天然分层/分角色时才有价值。
初期落地：五件最值得先做的事
- 建立统一的 AI 知识入口 —— 架构概览、规则、约束写入仓库，准备简洁的
AGENTS.md - 把能硬编码的约束移出 Prompt —— 目录权限、依赖方向、测试/lint 规则通过工具/CI 表达
- 设计一个最小但完整的 Task Loop —— 即便只有
INIT → EXECUTE → QA → DONE四个状态 - 引入至少一个独立 Evaluator —— 可以从"运行单元测试 + 对测试失败做自然语言解析"开始
- 从真实错误出发，持续工程化修补 —— 每当 Agent 犯错，把修复方式写入 Harness
14. 适用场景与边界
值得投入 Harness:
| 特征 | 代表性应用 |
|---|---|
| 长周期（跨多个会话、跨天/周） | 大型代码库维护/重构/升级 |
| 多步骤、多工具 | 持续运营型 Agent（监控、巡检、运维） |
| 高置信度需求（出错代价高） | 金融、医疗等高敏感领域 |
| 需要审计与回滚 | 企业流程自动化 |
| 多人/多 Agent 协作 | 团队级 Agent 系统 |
不需要 Harness:
- 单轮或少量轮次的问答/写作
- 不依赖真实环境的简单探索
- 一次性无须状态保留与审计的操作
15. 面向未来
15.1 Harness 标准化与 Agent OS
- 标准化 Agent Runtime: 统一的 environment / tools / control / memory / evaluation 原语
- 可配置的 Harness 模板: 针对不同领域（coding、客服、运营、安全），类似 K8s 的 Operators
- 训练数据反哺: Harness 中捕捉的失败轨迹成为训练下一代模型的高价值数据
- 与工作流引擎融合: Temporal / Restate 等持久化工作流在 Agent 场景中应用增多
- Harness 描述语言化: 如 NLAH（Natural-Language Agent Harness）
15.2 技术栈的"Harness 友好度"
当 Agent 成为开发常态时，越容易构建高质量 Harness 的技术栈越有优势：好的测试生态、强类型与静态分析、规范的框架与约定、易解析的声明式接口。
15.3 模型进步下的 Harness 进化
- 随着模型迭代，某些 Harness 组件会自然"失业"（如 context reset 在更强模型上可去掉）
- 但边界不会消失，只会外移：对"自评不足""长期任务可靠性"，Evaluator 与 Task Loop 仍是刚需
15.4 工程师角色演化
- Harness Engineering 不是让你"不写代码"，而是让你把代码写在模型外面的系统里
- 未来工程师的时间会越来越多花在：设计环境（tools, env）、写规则（linter, 测试, 架构约束）、调整反馈回路（CI 策略、可观测性）、审查 Agent 的决策
16. 总结（十大要点）
- Agent = Model + Harness: 模型是大脑，Harness 是操作系统与骨架
- 模型边界决定 Harness 必要性: 没有状态、不能执行、没有长期记忆 → 一切超出函数调用的能力都需要 Harness
- 核心哲学: 确定性外壳包裹非确定性内核
- 生产级 Harness 像一个小 OS: Environment → Tools → Control → Memory → Evaluation
- Task Loop 是长任务引擎: 分解 → 检查点 → 错误恢复 → 资源管控 → 人机协作
- 实证：壳比模重要: 换壳不换模，编程基准 42% → 78%
- Harness 本质是控制论: 在更高层闭合反馈回路
- 五大工程原则: 减少记忆负担、规则写进系统、工具保持简单、状态持久化、完整可观测性
- 适用场景: 长、复杂、需高置信度和可审计的任务
- 未来机会: 通用 Harness Runtime 平台、领域模板化 Harness、Agent 管理者角色