AI 编程 Agent 需要在真实仓库里跨会话完成任务、验证结果，并留下下一次可以继续工作的状态。代码生成只是其中一步。

模型已经可以补函数、生成页面和解释报错，但这些单次结果还不足以说明项目能够完成。

但把任务放进真实项目，问题很快就会暴露出来：它可能没有先读项目规则，改了不该动的文件；可能写完代码却没有跑测试；也可能在上下文越来越长以后忘记原来的目标，最后用一句「已经完成」结束任务。

排查这类失败时，除了模型能力，还需要检查任务规则、进度保存和验证方式。缺少这些安排，生成的代码就难以成为可以验收的结果。

这正是开源项目 Learn Harness Engineering 想解决的问题。

Learn Harness Engineering：让 AI 编程从生成代码走向可靠交付

Harness 管理执行规则、状态与验证

Harness 是模型执行任务时使用的工程环境。模型负责推理和生成，Harness 规定工作范围、资料来源、状态保存方式、验证方法和完成条件。

项目 README 把这套工作环境拆成五个可以操作的子系统。

Instructions：指令

用 AGENTS.md、项目文档和功能清单告诉 Agent：开始前要读什么，允许改什么，按什么顺序做，完成标准是什么。重点不是把所有规则塞进一个超长文件，而是让 Agent 能按需找到正确的信息。

State：状态

把进度、未完成事项、验证结果和 Git 历史保存在仓库里。这样即使换了会话，下一次也不必依赖模型「记住上次聊了什么」。

Verification：验证

测试、Lint、类型检查、冒烟运行和页面回读才是完成证据。验证结果用于判断代码是否真的符合要求，不能只依据代码看起来合理。

Scope：范围

一次只处理一个有明确边界的功能，避免 Agent 同时铺开多个方向，最后留下三份都没收尾的半成品。

Session Lifecycle：会话生命周期

开始时初始化环境，结束时清理状态、记录交接信息，并确保下一个会话有一条可恢复的路径。

Harness Engineering 的五个子系统：指令、状态、验证、范围与会话生命周期

这五部分组成一个可以继续执行和核对的流程：

读取规则 → 初始化环境 → 完成一个范围明确的任务
      ↑                         ↓
恢复状态 ← 留下交接记录 ← 验证、修正、再验证

Harness 的作用是约束任务执行过程，减少遗漏关键步骤的机会。

用同一个任务比较两种执行方式

根据本文 2026 年 8 月 20 日核对的资料，Learn Harness Engineering 提供 14 讲、8 个递进实践、15 种语言版本和资源模板，使用 MIT License 开源。课程会持续更新，这些数量对应当时版本。

学习安排从一个小任务开始，逐步加入状态保存、验证和任务编排。

第一阶段：先看见差异

Project 01 使用同一个任务比较「纯提示词驱动」和「最小 Harness 驱动」。

为两种执行方式使用相同任务，并记录完成率、人工介入次数、返工次数和验证结果。没有基线，就无法判断新增规则是否改善了交付。

第二阶段：让仓库可以被 Agent 持续接手

接下来的实践逐步加入 Agent 可读的仓库结构、跨会话状态、运行反馈、独立验证和可观测性。

这些实践分别处理会话交接、失败定位、独立评审和完成状态核对，避免测试尚未运行就将任务标为完成。

第三阶段：从单次执行走向自动循环

Project 07 进入 Loop Engineering。分别练习 Goal Loop、Timer Loop 和 Maker-Checker Loop。

Maker-Checker 将实现和检查交给不同 Agent。状态文件记录每轮结果，停止条件决定循环何时结束；用户仍需控制目标、预算和退出条件。

第四阶段：当循环变复杂，把它画成图

Project 08 继续走向 Graph Engineering：显式写出节点、边、共享状态和路由规则，再加入并行分支、条件回退和人工审批节点。

这一步不是鼓励所有任务都上复杂编排。相反，可以据此判断：什么时候一个简单循环已经不够，什么时候并行和审批带来的价值能够覆盖协调成本。

Harness 学习路径：从单次任务到可靠循环，再到带回退与人工审批的图结构

它还拆了四种真实 Harness 设计

课程新增了「前沿 Harness 拆解」，用统一框架分析 Pi、Claude Code、Codex 和 DeepSeek Harness。

这部分的价值不在于比较谁的模型更强，而在于观察不同团队怎样处理同一类工程问题：

  • Pi 选择极简内核和可编程扩展；
  • Claude Code 强调分层记忆、压缩、权限、钩子与子 Agent；
  • Codex 把仓库作为事实来源，并用 AGENTS.md 和 worktree 管理信息与隔离；
  • DeepSeek Harness 采用 「Everything is a Plugin」 的运行时思路。

先学课程框架，再看这些真实实现，会比单独背某个工具的命令更容易迁移。

用两小时完成一次最小练习

前 30 分钟：读第一讲和第二讲，先弄清楚「模型能力」和「执行可靠性」为什么不是同一个问题。

接下来 60 分钟：完成 Project 01。选一个足够小、可以重复验证的真实任务，用相同模型和相同需求分别跑一次无 Harness 基线和最小 Harness 版本。

最后 30 分钟：只把四样东西带回自己的仓库：

  1. 一份简短的 AGENTS.md；
  2. 一份可检查的功能或任务清单；
  3. 一个统一的初始化入口；
  4. 一条机器可以执行的验证命令。

先在小任务中检查这四项安排是否降低返工，再决定是否加入状态交接、独立评审、循环和图结构。

学习时不要只看「代码有没有生成」

判断 Harness 是否有效，至少记录下面五个指标：

  • 任务完成率：验收标准是否真的全部通过；
  • 人工介入次数：中途需要人纠偏多少次；
  • 错误完成率：Agent 宣布完成，但验证没有通过的次数；
  • 返工量：为了修复越界修改或遗漏步骤，需要重做多少；
  • 恢复时间：换一个新会话以后，多久能准确继续上次工作。

文件是否齐全不能替代效果评测。如果指标没有改善，应检查规则是否适用于任务。

谁适合学，谁可以先不学

经常让 Codex、Claude Code、Cursor 或其他 Agent 修改真实仓库，且任务跨会话、涉及测试与部署，或需要自动循环的开发者，可以按课程逐步实践。

偶尔生成一次性脚本时，可以先采用清晰的任务说明和基本代码审查。完整 Harness 有维护成本，应根据任务复杂度选择。

还要注意：这是一套快速更新的开源课程，不是装上就能保证生产交付的框架。资料核对时，仓库顶部信息和具体目录已列出 14 讲、8 个实践，个别概览页仍可能保留旧数字。学习时应以主分支目录和具体项目页为准。

从一个可重复验证的小任务开始

选择真实仓库里的一个小任务，从 Project 01 开始比较两种执行方式。记录遗漏、返工和验证结果，再决定哪些规则需要留在项目中。课程提供的是练习方法，能否改善交付仍需要用自己的任务验证。

开源仓库：https://github.com/walkinglabs/learn-harness-engineering

在线课程：https://walkinglabs.github.io/learn-harness-engineering/zh/

开源协议：MIT License

资料核对：本文依据该仓库 main 分支截至 2026-08-20 的 README、中文课程目录和项目文档整理；课程仍在持续更新。