Learn Harness Engineering 课程全总结12 讲核心要点本文是 Learn Harness Engineering 课程全部 12 讲的系统总结。从理解 Harness 的本质到搭建完整的 Agent 运行环境每一讲的核心论点、关键概念、实践方法和真实案例均已完整收录无省略。目录第一讲模型能力强不等于执行可靠第二讲Harness 到底是什么第三讲让代码仓库成为唯一的事实来源第四讲把指令拆分到不同文件里第五讲让跨会话的任务保持上下文连续第六讲让 agent 每次工作前先初始化第七讲给 agent 划清每次任务的边界第八讲用功能清单约束 agent 该做什么第九讲防止 agent 提前宣告完成第十讲跑通完整流程才算真正验证第十一讲让 agent 的运行过程可观测第十二讲每次会话结束前都做好交接第一讲模型能力强不等于执行可靠核心论点模型能力和执行可靠性是两回事。遇到失败先检查 harness后考虑换模型。同一个模型在空白环境里和在有完整 harness 的环境里产出有本质差异。模型没变变的是马具。关键概念能力鸿沟Capability Gap模型在基准测试如 SWE-bench Verified上的表现和真实任务上的表现之间的巨大落差。SWE-bench Verified 通过率仅 50-60%意味着近一半的真实 issue 解不了。Harness 诱导失败模型本身能力足够但因为执行环境有结构性缺陷而失败。Anthropic 的对照实验证明Opus 4.5 配完整 harness 6 小时 $200 做出可玩的游戏裸跑 20 分钟 $9 游戏核心功能跑不起来。诊断循环执行 → 观察失败 → 定位到 harness 的哪一层 → 修补那一层 → 重新执行。这是 harness 工程的核心方法论。完成定义DoDDefinition of Done一组可以用命令验证的条件——测试通过、lint 没报错、类型检查通过。没有显式的 DoDagent 就会自己编一个。五种 Agent 典型失败模式需求描述模糊agent 只能自己猜猜错概率大隐性约定没写下来agent 无从遵守——它不知道所有 API 必须走 OAuth 2.0这条规矩环境配置有缺口agent 把上下文花在修环境上真正该干的活反而没精力做验证手段缺失没有测试、没有 lintagent 自己觉得做完了就算完成跨会话状态丢失每个新会话都要重新探索项目超过 30 分钟的任务失败率急剧上升核心要点模型能力和执行可靠性是两回事千里马也得配上好马具。失败的时候先看 harness再看模型。换模型是成本最高的选择。每次失败都是一个信号你的 harness 有结构性缺陷。五层防御排查任务规范、上下文供给、执行环境、验证反馈、状态管理。一个AGENTS.md文件可能比你换一个更贵的模型更有效。第二讲Harness 到底是什么核心论点harness在 AI coding agent 圈子被用得越来越多但大部分人说 harness 时指的只是一个 prompt 文件。一个 prompt 文件不是 harness。Harness 由五个子系统组成指令、工具、环境、状态、反馈。不是模型权重的部分全是 harness。关键概念什么是 Harness模型权重之外的一切工程基础设施。OpenAI 把工程师的核心工作概括为设计环境、表达意图、构建反馈循环。Anthropic 直接把 Claude Agent SDK 称为通用 agent harness。仓库是唯一事实来源agent 看不到的东西对它来说就不存在。所有必要的上下文都必须在仓库里通过结构化的文件和清晰的目录组织来呈现。给地图不给说明书AGENTS.md应该是目录页不是百科全书。100 行左右就够了放不下就拆分到docs/目录里让 agent 按需去读。约束而非微操好的 harness 用可执行的规则约束 agent而不是在指令里逐条叮嘱。OpenAI 说执行不变量不要微管实现Anthropic 发现解决方案是把干活的人和检查的人分开。控制变量排除法量化价值保持模型不变逐个移除五个子系统看哪个移除后性能下降最多。下降最多的组件边际贡献最大。但要定位真正瓶颈还需结合失败记录和归因分析不能只靠拆除实验。Harness 五子系统模型子系统职责关键实践指令让 agent 看懂项目规则创建 AGENTS.md / CLAUDE.md含项目概览、技术栈、硬约束、文档链接工具确保 agent 所需的工具可随时调取不要因为安全考虑禁掉 shell按最小权限原则开放工具权限确保环境状态自描述环境运行环境可重现pyproject.toml/package.json锁定依赖.nvmrc/.python-version指定运行时版本状态跨会话连续性用 PROGRESS.md 记录进度用 DECISIONS.md 记录决策原因反馈验证结果反馈显式列出验证命令核心要点Harness 指令 工具 环境 状态 反馈五个子系统缺一不可。五个子系统中反馈子系统投入最少、回报最高——先把验证命令写清楚。用控制变量排除法量化各子系统边际贡献定位瓶颈需结合失败记录和原因归因。Harness 和代码一样会腐化需定期审计像还技术债一样还 harness 债。真实案例一个 TypeScript React 项目约 20,000 行代码四个阶段阶段 1只有 README5 次运行成功 1 次20%阶段 2添加 AGENTS.md技术栈版本、命名约定、架构决策成功率升到 60%阶段 3添加验证命令yarn test yarn lint yarn build成功率升到 80%阶段 4引入进度文件模板成功率稳定在 80-100%模型一个字没改成功率从 20% 到接近 100%。第三讲让代码仓库成为唯一的事实来源核心论点不在仓库里的知识对 agent 来说等于不存在。Agent 的输入只有三样——任务描述、仓库文件内容、工具执行的输出。不在仓库里的信息 agent 永远看不到。你必须给它一张足够好的地图。关键概念知识可见性缺口项目总知识中不在仓库里的比例。缺口越大agent 失败概率越高。系统记录System of Record代码仓库是项目决策、架构约束、执行状态和验证标准的权威信息源。仓库说了算。全新会话测试开全新 agent 会话只让它看仓库测试能否回答五个基本问题——这是什么系统怎么组织的怎么跑怎么验证现在进度如何答不上来的问题越多地图空白越大。发现成本agent 为了在仓库里找到关键信息需要消耗的上下文。信息越隐蔽发现成本越高。知识衰减率仓库中单位时间内变得过时的知识条目比例。过时的文档比没有文档更危险——它会误导 agent 还以为自己是对的。画好地图的四条原则知识靠近代码API 认证规则放在 API 代码旁而不是藏在全局文档里标准化入口文件AGENTS.md 作为着陆页50-100 行快速回答三个问题最小但完备删掉不影响 agent 决策质量的规则但全新会话测试的每个问题都必须有答案和代码一起更新把知识文档放在对应模块目录里改代码时自然看到ACID 类比管理 Agent 状态原子性Atomicity每个逻辑工作单元一个 git 提交要么全做要么不做一致性Consistency定义一致状态的验证谓语——所有测试通过lint 无报错。不一致的中间状态不要提交隔离性Isolation多 agent 并发时用独立进度文件或 git 分支隔离持久性Durability关键知识必须写进 git 跟踪的文件里。脑子里的不算真实案例一个约 30 个微服务的电商平台架构决策散落在 Confluence部分过时、Slack难以搜索、资深工程师的脑子里不可扩展。引入 AI agent 后 70% 的任务需要人工干预——几乎每次失败都涉及 agent 违反所有人都知道但从未写入仓库的隐性约束。改造根目录创建 AGENTS.md → 每个微服务目录添加 ARCHITECTURE.md → 创建集中的 CONSTRAINTS.md → 每个服务目录添加 PROGRESS.md → 改造后同一 agent 能在冷启动时回答所有关键项目问题。第四讲把指令拆分到不同文件里核心论点加条规则是短期的止痛药、长期的毒药。入口文件是路由器不是百科全书。50-200 行就够了。巨型指令文件的问题上下文预算被吃掉600 行 AGENTS.md 占用 10K-20K tokens对 128K 窗口就是 8-15%中间迷失Lost in the MiddleLiu 等人 2023 年研究表明LLM 对长文本中间部分的信息利用效率显著低于两端分不清轻重硬约束不得使用 eval()和软建议优先使用函数式风格以相同格式呈现agent 无法区分维护衰减指令只增不减信噪比持续下降矛盾累积不同时期加的指令出现矛盾agent 每次随机选一条指令信噪比Instruction SNR定义入口文件中与当前任务相关的指令条数 ÷ 总指令条数现状文件膨胀到 600 行时SNR 常低于 0.3目标理想 SNR 应为 0.7-1.0大部分指令与当前任务相关作用SNR 是衡量入口文件质量的量化指标 SNR 越低agent 上下文利用率越差注意SNR 不是一个绝对值标准而是相对参考。它会受任务类型影响——做 bug 修复和做新功能的相关指令不同。推荐的文件结构入口文件 AGENTS.md50-200 行项目概览 快速开始命令 全局硬约束不超过 15 条 指向专题文档的链接专题文档50-150 行/每个按主题放在 docs/ 目录下agent 按需读取信息直接放在代码里类型定义、接口注释等——agent 读代码时自然看到维持指令健康的核心原则每条指令标明来源为什么加这条、适用条件什么时候需要、过期条件什么时候删重要信息放顶部或底部利用中间迷失效应定期审计删掉必要的 vs 不必要的——像管理代码依赖一样管理升级/降级/依赖管理指令关键数据某 SaaS 团队的 AGENTS.md 从 50 行膨胀到 600 行重构后裁剪到 80 行 创建 3 个专题文档成功率从 45% 升到 72%安全约束遵循率从 60% 升到 95%。第五讲让跨会话的任务保持上下文连续核心论点上下文窗口是有限的资源。长任务一定会跨会话跨会话一定会丢信息。解决方案不是更大的窗口而是更好的状态持久化。关键概念上下文焦虑Anthropic 观察到当 agent 感觉上下文快满了它们会表现赶工收尾行为——匆忙结束、跳过验证、选简单方案而非最优方案重建成本新会话恢复到可执行状态所需的时间。好的 harness 能把重建成本从 15 分钟压到 3 分钟漂移Driftagent 的理解跟代码仓库实际状态之间的偏差。每个会话边界都会引入漂移两种上下文管理策略压缩Compaction同一会话内把早期对话摘要化。优点是保留连续性缺点是为什么经常丢失且上下文焦虑并未消除——agent 知道上下文曾经很大重置Context Reset全新会话从持久化工件重建。优点是干净的心理状态我没赶时间缺点是依赖交接工件的完备性四个工具进度文件PROGRESS.md记录当前状态commit hash 测试状态 lint 状态 已完成 进行中 已知问题 下一步决策日志DECISIONS.md记录什么决策 为什么 什么时候。让新会话理解设计意图git 检查点每完成一个原子工作单元就 commit标准化流程每次上班读 PROGRESS.md DECISIONS.md make check每次下班更新 PROGRESS.md make check commit混合策略短任务30 分钟内同一会话内完成长任务用结构化工件维持连续性判断标准任务需要的上下文超过窗口的 60% → 开始准备交接关键数据定量对比一个含 12 功能点的博客系统需要 5 个 agent 会话。没有状态持久化12 点只完成 7 个58%隐含缺陷 43%重建 15 分钟。有状态持久化12 点全部完成100%隐含缺陷降到 8%重建 3 分钟。重建时间减少约 78%第六讲让 agent 每次工作前先初始化核心论点初始化和实现的优化目标不同混在一起只会互相拖后腿。Agent 在做功能前必须先经历一个独立的初始化阶段。初始化的五个产出可运行的环境项目能启动、依赖装好可验证的测试框架至少有一个示例测试通过启动就绪清单告诉后续会话怎么跑 怎么测 做到哪了任务分解把项目拆成有序的任务列表 每个任务有验收标准git 检查点提交干净的 checkpoint启动就绪清单四个条件条件说明验收方式能启动从零开始make setup成功全新环境验证能测试make test至少一个测试通过验证测试框架能看进度新 agent 只看仓库就能回答怎么跑 怎么测全新会话测试能接手下一步任务分解文件存在 至少 3 个任务检查清单热启动 vs 冷启动冷启动从空目录开始agent 需自行推断项目结构效果差热启动用项目模板create-react-app / fastapi-template 等预置标准目录结构和依赖配置做法把通用初始化步骤预置到模板里只留下项目特有的初始化工作关键数据Anthropic 实验使用独立初始化阶段的项目多会话场景中功能完成率比混合方式高 31%React 项目对比-混合100 行功能代码 基础设施重建 20 分钟-独立初始化20 分钟只做初始化后续 3-4 个会话中把时间全部收回-总重建时间混合比独立初始化多约 60%第七讲给 agent 划清每次任务的边界核心论点Agent 天生就有多做一点的冲动——看到相关的事情就顺手一起做了。但注意力是有限的资源同时做太多事情往往每件都做不好。WIP1 是 agent harness 的默认安全设置。两个共生问题过度延伸Overreach一次会话中激活的任务数超过最优值。量化同时做 5 个功能但 0 个跑通不足完成Under-finish已启动的任务中通过端到端验证的比例低于阈值。仅写了代码不等于做了两者互相加剧overreach 导致注意力分散 → under-finish → 半成品代码增加系统复杂度 → 下一个任务的 overreach → 恶性循环Little 法则的启示L lambda × W在制品 交付率 × 前置时间。如果 L 过大同时做太多事每个任务的 W 必然增加。对 agent 而言这意味着每个功能从开始到验证通过的时间被拉长失败概率被放大。四个实施方法强制执行 WIP1明确写进 CLAUDE.md——每次只做一个功能点 当前功能点端到端验证通过后才能开始下一个 不要在实现功能 A 时顺便重构功能 B显式完成证据每个功能任务都有可执行的验证命令范围表面外部化用可读写的文件JSON/ Markdown记录所有任务的状态——哪个在做 什么行为算完成 通过了什么验证监控 VCRVerified Completion Rate 已通过验证的任务数 / 已启动的任务数。VCR 1.0 → 阻止新任务启动关键数据Anthropic 实验使用小下一步策略WIP1的 agent任务完成率比使用宽泛提示的 agent 高 37%REST API 项目8 个功能点对比-无约束第一个会话同时启动 5 个 → 3 个会话结束时完成 3 个37.5%-WIP1每个会话只做 1 个 → 4 个会话结束时完成 7 个87.5%-总代码WIP1 更少800 vs 1200 行但有效代码更多第八讲用功能清单约束 agent 该做什么核心论点功能清单不是备忘录——它是整个 harness 的基础数据结构。调度器靠它选任务验证器靠它判完成交接器靠它生成报告。没有它所有组件就没有可以依赖的共识。三元组结构每个功能项包含三个要素 —— 缺一项就不完整behavior行为描述告诉 agent 做什么verification验证命令告诉 agent 怎么算做完state当前状态告诉 agent 现在到哪了用 JSON 格式举例json { id: F03, behavior: POST /cart/items with {product_id, quantity} returns 201, verification: curl -X POST http://localhost:3000/api/cart/items ... | jq .status 201, state: passing, evidence: commit abc123, test output log }状态机模型状态含义可转移至not_started未开始→activeactive进行中→passing/blockedblocked被阻塞→activepassing已验证通过不可逆通过状态门控active→passing的唯一方式是验证命令执行成功。agent 不能自己改状态——它只能提交验证请求harness 执行验证并根据结果决定是否允许转移。这是最基本的约束——也是作为原语primitive的关键所在。为什么功能清单必须是原语primitive文档可以被忽略——原语不能被绕过功能清单服务四个 harness 组件调度器读状态 → 选下一个not_started 验证器执行验证 → 判断状态转移 交接报告自动生成交接摘要 进度追踪统计状态分布 → 提供健康度指标反向压力not_started项的数量 harness 对 agent 的压力压力归零 项目完成粒度校准每个功能项应该是一次性会话能完成的范围✅合适粒度用户可以添加商品到购物车❌太粗实现购物车一次性会话完成不了❌太细创建 Cart 模型的 name 字段管理开销大关键数据电商平台 10 个功能项对比-备忘录模式3 个会话后笔记成了购物车基本完成但还有 bug——新会话花 20 分钟推断状态-结构化模式一次性读取功能清单 → 3 分钟内知道F01-F05 是passing F06 是active F07-F10 是not_started→ 直接从 F06 继续-完成率结构化模式比自由形式高 45%零重复实现第九讲防止 agent 提前宣告完成核心论点Agent 系统性地过度自信。Guo 等人 2017 年ICML经典论文证明——现代神经网络系统性地过度自信。Agent 也一样——它觉得做完了但实际上差得远。解决方案把干活的人generator和检查的人evaluator分开且 evaluator 需要专门调校。过早完成声明的常见套路代码语法正确、逻辑看起来合理静态检查没有明显错误跳过了实际运行或只跑了部分测试单元测试全部通过但集成测试/E2E 测试都没跑得出结论嗯做完了三层终止检查层级成本检查内容第 1 层静态分析最低语法正确 类型检查通过第 2 层运行时行为验证中等单元测试/集成测试通过 应用能正常启动第 3 层系统级确认最高E2E 测试通过 完整用户流程走通完成优先级约束第 1 层没通过 → 不许进第 2 层第 2 层没通过 → 不许进第 3 层核心功能没验证通过之前 → 不许做重构Generator Evaluator 分离的价值Agent 在评估自己的工作时系统性地过度正面评价——同一个模型既生成又评估内在地倾向于对自己慷慨。Anthropic 实验数据同一任务 同一模型 Opus 4.5架构成本时长核心功能单一 agent 裸跑$920 分钟❌ 不可用三 agent 架构planner generator evaluator$2006 小时✅ 可用Evaluator 也需要调校Evaluator不是一开始就那么强——早期版本的 evaluator 也会识别出合理的问题然后说服自己这些问题不过 ——最终也会……但……调校的关键信号当 evaluator 使用尽管/但是/虽然/…… 这种权衡 的方式为代码变更辩护 → 这一面红旗就是需要被校准的信号错误消息设计OpenAI Codex 实践——面向 agent 的错误消息必须包含三种要素什么出了问题what为什么是问题why该怎么改fix例❌测试失败✅测试失败POST /api/reset-password 返回了 500。请在环境变量中检查邮件服务配置是否已正确设置。邮件模板文件应位于 templates/reset-email.html。第十讲跑通完整流程才算真正验证核心论点单元测试对组件边界缺陷系统性盲视——隔离设计恰好使其无法检测交互问题。只有 E2E 测试能证明系统级缺陷不存在。单元测试的五种盲区缺陷类型描述单元测试E2E 测试接口不匹配渲染进程传给 preload 的文件路径格式不一致✗✓状态传播错误ORM 缓存层持有旧结构✗✓资源生命周期问题文件句柄获取/释放跨越多个组件✗✓环境依赖性在 mock 环境正确但在真实环境失败✗✓错误传播服务层异常未能传到 UI 层✗✓E2E 测试的两个效应检测效应E2E 测试捕获了 5 个跨组件边界缺陷在一个 Electron 文件导出功能中单元测试一个都没发现行为效应当 agent 知道它的工作要过 E2E 测试时它的编码行为也会改变- 写代码时会考虑这个接口和上游怎么对接- 尊重架构边界在有约束的系统里E2E 测试迫使 agent 遵守边界规则- 处理异常路径E2E 测试包含故障场景迫使 agent 考虑异常处理架构规则的可执行原则每条架构约束必须有对应的测试或 lint 规则来机械执行执行不变量不微管实现——OpenAI Codex 工程实践的核心原则每次提交自动检查——不能只写在文档里等人来看审查反馈提升Review Feedback Elevation流程发现 agent 的新类型错误 → 转化为自动化检查规则每个被捕获的缺陷类别都变成永久防线harness 自动变强第十一讲让 agent 的运行过程可观察核心论点可观察性是 harness 的架构属性——设计时必须考虑的核心能力不应仅作为事后追加的功能。缺少可观察性导致的四类问题问题描述无法区分正确与看似正确代码审查看起来正确但运行时因边界条件在特定输入下产生了错误结果只有运行时追踪能揭示实际执行路径偏离了预期评估变成玄学没有评分标准和验收条件评估者只能依赖隐式假设同一输出不同评估者可能给出截然不同的结论重试变成盲猜agent 不知道失败原因重试方向随机——可能在错误方向反复尝试修复无关代码路径忽略真正故障根源会话交接信息断崖缺乏可观察性意味着新会话必须从零诊断系统状态Anthropic 观察发现这占会话总时间的 30-50%双层可观察性运行时可观察性和过程可观察性——两者缺一不可相互增强。层级职责内容运行时可观察性回答系统做了什么日志、追踪、进程事件、健康检查过程可观察性回答为什么这个变更应被接受冲刺合同、评分标准、验收条件冲刺合同Sprint Contract在每个任务开始前生成者和评估者协商一份合同明确这次做什么、怎么做算通过要素内容范围Scope修改哪些组件 每个组件的验证标准验证标准Verification Criteria例如每个组件的 Lighthouse 评分 ≥ 80排除项Exclusions例如不处理打印样式 不处理第三方组件暗色模式没有冲刺合同生成者和评估者的隐式预期不一致循环 3-4 次总耗时约 45 分钟。有冲刺合同一次迭代出高质量结果总耗时约 15 分钟。效率差 3 倍区别只在可观察性。评估评分标准把好不好从主观判断变成基于证据的多维结构化评分维度ABCD代码正确性所有测试通过主流程通过部分通过编译失败架构合规完全合规轻微偏离明显偏离严重违反测试覆盖主流程边缘场景仅主流程仅有骨架无测试第十二讲每次会话结束前都做好交接核心论点OpenAI 和 Anthropic 一致指出——单次运行成功并不够每个会话退出时的状态质量直接决定下一个会话的效率。清洁状态是完成的必要条件。软件演化定律Lehmans Law一个持续变更的系统如果没有人主动管理它的复杂性一定会增加。OpenAI 在长达 5 个月的 Codex 实验中观察到一个清晰的现象- Agent 会复制仓库中已有的模式即使那些模式是不一致或次优的- 每个会话都会引入新的偏差- 熵增是默认方向- 只有主动的清洁操作才能对抗它来源Lehman《Programs, Life Cycles, and Laws of Software Evolution》清洁状态 ≠ 代码能编译清洁状态的要求远比代码能编译要多。构建通过是最基本的前提——下一个会话不应该一上来就先修别人的构建错误。所有测试也必须通过包括会话开始前就存在的旧测试——你这次改动不能破坏已有的功能。清洁状态五个维度——缺一不可维度要求验证方式构建通过项目能够正常构建npm run build成功测试全部通过所有测试通过含先前的旧测试npm test成功进度已记录功能清单/进度文件已更新为机器可读的工件文件存在且内容最新临时工件已清理无残留的调试日志、临时文件、注释掉的代码、过时的 TODO 标记显式扫描确认启动路径可用新会话可不依赖人工干预直接开始工作环境初始化 代码加载 上下文获取 任务选择可达双模式清理策略模式时机任务原则即时清理每个会话结束时清理本次会话的临时文件、更新功能清单、确保构建和测试全部通过谁产生的垃圾谁负责清掉像引用计数一样定期清理每周一次系统扫描处理累积的结构性问题、更新质量文档、跑基准测试检测质量漂移定期全身体检不让小问题拖成大病质量文档质量文档是一份持续更新的文件对代码库中每个模块记录质量评分和评价。新会话一打开就能直接看到当前每个模块的状态。评估项每模块评分验证状态通过 ✓ / 部分通过 ✗测试稳定性稳定 / 不稳定架构边界合规 / 有违规 / 严重违反代码规范遵循 / 部分遵循 / 不遵循agent 可理解性容易 / 中等 / 困难逻辑分散在多个文件Harness 简化Harness 中每个组件的存在都源于模型在某个方面尚无法独立完成。随着模型能力不断演进这些前提会逐渐过时。推荐做法每月挑选一个 harness 组件暂时禁用它跑一遍基准任务集如果结果没有退化就永久移除如果退化恢复该组件或换一个更轻量的替代方案幂等清理定义一个操作无论执行一次还是一百次结果都一样。为什么需要清理失败时你需要重跑一遍重跑必须产生相同的结果。幂等清理操作举例rm -f /tmp/debug-*.log # -f 确保文件不存在时不报错 git checkout -- .env.local # 恢复到已知状态多跑几次结果相同 npm run test # 验证清理没有破坏任何功能清洁状态——实测数据对比一个使用 agent 持续开发的 Electron 应用12 周演化过程的实际对比指标无清洁策略第12周有清洁策略第12周构建通过率68%97%测试通过率61%95%新会话启动时间60 分钟以上9 分钟过时工件数量103 个11 个到第 12 周的差距- 构建通过率高 29 个百分点- 测试通过率高 34 个百分点- 新会话启动时间减少约 85%每个会话只多花 5 分钟做清理12 周下来却省了几十个小时的混乱时间。课程总览——全表讲次主题核心概念01模型能力强≠执行可靠能力鸿沟、诊断循环、完成定义02Harness 到底是什么五子系统指令工具环境状态反馈03仓库作为唯一事实来源知识可见性缺口、全新会话测试、ACID 类比04把指令拆分到不同文件巨型文件陷阱、中间迷失效应、信噪比 SNR05跨会话上下文连续上下文焦虑、重建成本、漂移06独立初始化阶段启动就绪清单、热启动策略07给 agent 划清边界过度延伸 Overreach、不足完成 Under-finish、WIP1、VCR08功能清单是 harness 原语三元组结构、状态机模型、通过状态门控09防止提前宣告完成三层终止检查、校准偏差、GeneratorEvaluator 分离10E2E 测试组件边界缺陷、架构约束可执行、审查反馈提升11可观察性双层可观察性、冲刺合同、评估评分标准12会话结束做好交接清洁状态五维度、质量文档、幂等清理、Harness 简化一句话总结课程Harness 指令 工具 环境 状态 反馈。失败的时候先检查 harness再检查模型。让 agent 真正可靠的唯一途径是显式、可验证、持久化的工程基础设施而不是一个更强的模型。来源本文内容总结自 Learn Harness Engineering 全部 12 讲中文版完整内容及引用来源请参见原文。