当代码可以被无限生成，工程师的价值从写代码迁移到设计让代码产生的环境。
章节列表
范式转移 — Agent 不是懒，是没地图。工程师从干活的变成设计的。
让Agent拥有感官 — 给 Agent 装上眼睛。状态能读到、知识能搜到、建议能落地成规则。
成本、自主与熵增 — 成本降了、自主做完了、技术债自己还了。熵增？不存在的。
Harness即操作系统 — Harness 就是你的新 OS。用得上就留着，用不上就删掉。本质就：控制反是馈。
验证、工具与优化 — 就四条改动。核心思路就一句话：站在 Agent 的角度看问题。
争论与未来 — 大模型还是大框架？工具有多重要？Model × Harness 哪个更关键——聊点还没定论的东西。
范式转移
本章隶属 Hermes Engineering 系列第 I 模组第 1 章。
问题溯源
一套代码规范、CI 流水线及 Lint 规则的三个月工程投入，在 Agent 介入一周后便被大量非合规代码侵蚀，架构漂移速率超过了人工修补能力。这一现象的根源并非 Agent 的认知缺陷，而在于管理范式未能适配：以「指导人类编码」的逻辑去约束一个无需手写代码的系统，本质上是范畴错误。当代码可被无限供给，工程师的核心价值便从「代码生产」迁移至「代码生产环境的设计」。
OpenAI 案例
OpenAI 内部记录了一则值得深究的案例：一个三人团队在五个月内构建了一个规模达百万行代码的复杂系统，累计合并约 1500 个 PR。团队规模随后扩展至七人，人均产出不降反升。该现象难以用传统软件工程框架解释。
《人月神话》的核心论点是：人员规模扩张导致沟通成本超线性增长，进而压制整体效率。但在上述案例中，新增人员的职能发生了本质变化——他们并非在生产线上执行重复劳动，而是在升级生产线本身。当工作内容包括基础设施改进时，每一次投入均通过 Agent 的执行能力获得放大效应。
代码属性的系统性变化
代码生成的边际成本正趋近于零，其直接后果是：代码不再是稀缺资产，而是可再生的编译产物，具备随时生成、随时丢弃的属性。与此对应，环境上升为核心资产——仓库结构、CI 流水线、测试覆盖率、工具链等支撑代码正确生成的基础设施，才是真正需要长期维护的对象。
工程师的职能随之发生迁移：从关注每一行代码语法的实施者，转变为设计整个生产系统的架构设计者。
Harness 工程师的核心职能
在新范式下，工程师的工作聚焦于三项核心任务：
1. 环境设计
为 Agent 构建脚手架，涵盖仓库结构、CI 流水线、Lint 规则及开发者工具。缺乏上述基础设施时，Agent 在没有执行上下文的空白状态下作业，产出质量必然不可控。
2. 意图精确化
将需求拆解为 Agent 可无歧义理解的规范，而非「实现某功能」这类模糊描述。模糊性必然引入偏差，偏差累积即表现为架构漂移。
3. 反馈闭环构建
这是最关键的一环。Agent 需要一套自我审查机制：本地静态检查、集成测试、自动化验证——在代码提交前，Agent 应能在反馈闭环中自主完成多轮迭代。此能力不属于提示词工程范畴，而属于反馈闭环工程。
失败处理原则
Agent 执行任务时必然遭遇失败。关键问题并非如何避免失败，而是如何响应失败。
推荐处理流程：
Agent 执行任务 → 任务完成则合并代码；任务失败则进入诊断分支： （a）若卡在方向性决策节点 → 通知人类决策； （b）若否 → 诊断环境缺失的能力项； （c）将缺失能力补充至环境、工具或文档； （d）人类决策后重启执行。
核心原则：失败后的第一响应不是「重试」，而是诊断环境缺口。应补充环境定义，而非手动纠正 Agent 行为。所调试的对象不是程序，而是 Agent 的工作环境。
Vibe Coding
该概念源自独立开发者 Jeffrey Hunley，核心思路是将 AI Agent 置于一个迭代循环之中：给定目标后，Agent 反复执行「编码 → 审查 → 测试 → 修复」流程，直至任务通过所有检查。
实际操作方式为：工程师描述任务，Agent 启动后自行创建 Pull Request，随后在本地完成自我审查，再请求云端额外审查，根据反馈自动修正，循环往复直至所有审查方满意。在若干成熟实践中，几乎所有代码审查工作已交由 Agent 之间互相完成，人类不再需要逐 PR 介入审查。
与《人月神话》的关系
传统观点认定人员规模扩张会降低效率（沟通成本曲线单调递增）。但在 Harness Engineering 框架下，该逻辑不再成立：
传统开发：新增人员在生产线上执行重复任务；
Harness 开发：新增人员升级基础设施本身。
当工作内容包括基础设施改进时，每一单位投入均通过 Agent 的执行能力被放大。人员规模翻倍，人均产出不降反升——并非因为人员增加，而是因为杠杆增加。
本章要点
Agent 生成代码质量不足，根源在于环境定义不足——非能力不足，而是感知能力不足；
工程师职能从实施者迁移至系统设计师；
Harness 工程师三项核心任务：环境设计、意图精确化、反馈闭环构建；
代码从高价值资产转变为廉价编译产物，环境成为真正的核心资产；
失败处理原则：不重试，先诊断环境缺口；
Vibe Coding：使 Agent 在「编码 → 审查 → 测试 → 修复」闭环中自主迭代；
《人月神话》的效率递减定律在 Harness Engineering 框架下失效——新增人员升级基础设施，投入被 Agent 执行力放大。
赋予 Agent 感知能力
本章隶属 Hermes Engineering 系列第 I 模组第 2 章。
验证能力成为新瓶颈
代码生成速度不再构成瓶颈之后，验证能力便上升为新的约束条件。Agent 完成代码生成后，如何判断其正确性？OpenAI 的方案是：使 Agent 具备自我验证能力。但该方案存在一个前置条件——Agent 必须能够感知系统状态。
Agent 的感知缺失问题
人类工程师完成 Bug 修复后的典型行为序列包括：通过浏览器确认页面渲染正确性、检索日志以确认异常 absence、检查性能监控面板以确认响应时间处于正常区间。这一系列动作的本质是：工程师通过视觉与诊断工具获取系统状态的反馈信号。
此前的 Agent 不具备此类感知通道。其能力边界止于代码生成，随后即将任务移交给人类验证。页面渲染结果、系统异常、性能退化均不在其可观测范围内。验证环节依赖人类介入，以截图等形式将错误信息反馈至 Agent。
由此形成的瓶颈是：代码生成耗时仅为秒级，而验证环节需要人类工程师介入，时间成本相差数个数量级。
视觉通道：UI 可观测性
OpenAI 将 Chrome 开发者工具协议（CDP）接入 Agent 运行时环境。Agent 由此获得了应用启动、页面打开、以及获取页面中每个按钮、文本段、输入框的位置与状态的能力。
配套的专用技能被构建用于处理 DOM 快照、截图与页面导航。DOM 快照可被视为页面底层树状结构在某一时刻的完整状态捕获，其功能类似于结构扫描——Agent 借此分析页面结构的静态快照。
基于上述能力，Agent 能够自主复现 Bug、验证修复结果、推理 UI 行为。代码生成不再构成任务的终点；Agent 现在可以自主启动应用、获取渲染结果、检测异常并触发自主修复。
Agent 生成代码
↓
Agent 启动应用
↓
Agent 获取页面状态（CDP）
↓
Agent 检查日志与指标
↓
异常检测通过？
├─ 否 → Agent 自主修复代码 → 循环回启动应用
└─ 是 → 任务完成 → 触发 PR → Agent 自我审查 + 交叉审查 → 自动合并
图示说明：具备感知通道的 Agent 形成了「编码 → 验证 → 修复」的自主闭环，人类工程师从执行环节退出。
诊断通道：系统内部可观测性
UI 层面的可观测性不足以覆盖全部验证需求。OpenAI 对可观测性工具进行了同等程度的改造——日志、指标、链路追踪构成的三元组使 Agent 能够感知 UI 不可见的系统内部状态。
实现方式为：为每个 Agent 任务构建一套临时可观测性环境，各任务拥有独立的日志与指标体系，任务结束后即销毁。该设计的隔离性质确保了并行任务之间不存在诊断信号互相干扰的问题。
Agent 可通过 LogQL 在海量日志中精确检索特定错误记录，通过 PromQL 查询「最近五分钟平均响应时间」等时序指标。此类约束条件此前难以被 Agent 自主验证，依赖人类监控面板介入。当前 Agent 具备自主查询、判断、通过或打回的能力。
信息检索通道：知识可发现性
感知通道之外，Agent 还需要信息检索能力——即知晓去何处获取所需信息。OpenAI 的方案是：向 Codex 提供索引，而非提供一部超长操作手册。
初期尝试采用了巨型 agents.md 方案，将所有规则压缩入单一文件，结果以完全可预期的方式失败：
上下文属于稀缺资源——超长指令文件挤占任务代码的上下文空间；
指导过量等价于无指导——当所有条目均被标记为重要时，优先级信息丢失；
文档立即腐烂——巨型说明文件会成为过时规则的沉积层。
正确做法是将其作为索引使用——一百行量级的索引文件，指向 dox/ 目录中的具体文档。Agent 从一个小规模、稳定的入口出发，按图索骥获取后续信息，而非在任务起始即被信息过载淹没。
知识必须先进入仓库。从 Agent 的视角出发，任何在运行时无法经由上下文访问的信息，实质上不存在。Slack 频道中的讨论、Google Docs 中的方案、同事头脑中的 API 边界——均构成 Agent 的信息黑洞。Agent 所能感知的现实世界，仅限于仓库中的版本化文件。
从建议到强制：执行力约束
感知通道与信息检索通道之外，Agent 还需要行为约束。当 AI 接管代码生成之后，如何防止其以机器速度制造架构债务？
OpenAI 的思路是：严格约束。约束是速度的先决条件。边界必须刚性封死，边界之内则赋予 Agent 完全的实现自由度。
文档属于建议范畴，Agent 需要的是强制执行机制。当规则仅以文档形式存在时，Agent 会复制已有结构、放大已有模式，错误结构由此被指数级复制。正确做法是将建议转化为强制执行机制——通过自定义 Linter 实现机械执行。
此处存在一个精妙设计：Linter 不仅仅是报错工具，它们同时是上下文注入工具。 当 Linter 输出错误信息时，信息体中直接包含补救指令。Agent 读取该错误信息即等同于读取一条 Prompt，随后自主重构代码并重新运行 Linter，循环直至全部检查通过。
同一条规则，在人类工程体系中构成认知负担，在 Agent 工程体系中则构成能力杠杆。规则写入代码之后，瞬间在所有 Agent 的所有任务中生效。
投资回报率：6 小时自主工作时长
为 Agent 构建感知通道的最终效果是：单次 Codex 任务的工作时长经常超过 6 小时，通常发生在人类休眠时段。
Agent 具备感知通道与信息检索能力后，可以自主完成以下循环：代码生成 → 获取渲染结果 → 检索日志 → 异常检测 → 修复 → 再验证，无需人类介入。
状态可观测性使 Agent 能够感知 UI 状态、获取系统内部信号，从而实现闭环自主工作。
常见错误对照表
本章要点
状态可观测性的三层含义：可见（CDP）、可解析（LogQL / PromQL）、可验证（闭环反馈）
知识可发现性：提供索引而非操作手册；知识必须进入仓库
强制执行机制：Linter 即 Prompt，规则是能力倍增器
仓库可读性投资：一次性投入，多个 Agent 同时受益
约束力的三级递进：
建议（弱约束）
↓ 易被忽略，依赖人工执行
文档（中约束）
↓ 依赖 Code Review 人工执行
代码 / 自定义 Linter（强约束）
↓ 自动强制执行，瞬间全量生效
Agent 稳定产出
成本结构、自主边界与熵增控制
Harness Engineering 核心原则 · 第 3 章
代码生成成本趋近于零之后，等待成本上升为最昂贵的约束。Agent 接管全流程的同时，熵增问题随之浮现。
前两章建立了 Harness 的基础框架——工程师职能迁移至系统设计师，Agent 获得感知通道、信息检索能力以及强制执行约束。本章处理三个深层问题：成本结构如何演变？自主边界位于何处？大量自动生成代码所引入的熵增如何控制？
一、等待成本的反转
传统软件工程遵循一条熟悉的流水线路径：代码生成 → 开启 PR → 等待 Review → 测试全部通过 → 审批通过 → 合并。每一环节均构成一道门控。
对人类团队而言，该流程具备合理性——人工代码生成速度慢，每次合并均为高成本事件，值得投入检查成本。
当 Agent 接管代码生产之后，上述逻辑可能发生适得其反的效果。
成本函数的结构性反转
以工厂质检流程作为类比。传统场景下每小时产出 10 件，质检员在每件出厂前执行详细检查——成本收益比合理。当产量激增至每小时 1000 件，质检员成为整条产线的瓶颈节点，产线被单一检查环节阻塞。
与此同时，返修次品的成本趋近于零——自动返工耗时仅为秒级。
传统范式的成本逻辑是「修正成本高、等待成本低」→ 增加检查环节与审批层级，宁可延迟也不能出错。Agent 范式的成本逻辑是「修正成本极低、等待成本最高」→ 快速放行，快速暴露问题，快速修正。
传统开发范式：修正成本高、等待成本低 → 位于「谨慎检查」象限
Agent 开发范式：修正成本极低、等待成本高 → 位于「快速迭代」象限
成本函数发生结构性反转 → 工程实践必须随之调整
图示说明：传统开发位于「修正贵、等待便宜」象限，Agent 开发反转至「修正便宜、等待最贵」象限——工程实践必须随之反转。
三项具体应对措施
最小化阻塞门控。 并非取消检查，而是将「必须等待人工批准方可继续」转换为「自动检查 + 快速反馈」，将「层层审批」转换为「护栏 + 自动修复」。
保持 PR 短生命周期。 人类工程师倾向于花费数天时间构建单一大型 PR，导致 Review 周期拉长与合并冲突概率上升。Agent 流程采用高频小批量策略——合并冲突概率极低，即便出现异常，以短周期修复 PR 替代的成本仅为秒级。
禁止 Flaky Test 无限期阻塞进度。 同一段代码在多次运行中呈现非确定性通过/失败状态的幽灵测试，在传统做法中会阻塞全部流程并触发停机排查。Agent 时代的应对方案是引入重跑机制——绝不无限期卡住整体进度，等待成本的代价远超排查收益。
工程最佳实践并非绝对真理，而是约束条件的函数。当约束条件发生数量级变化时，最佳实践本身必须随之调整。
二、端到端自主：Agent 接管全流程
跨越某一工程临界点之后，Agent 将完整接管从代码生成到运维的每一环节。
Agent 生成范围超越代码本身
OpenAI 所称的「代码库由 Codex 生成」，所指并非仅限于产品代码与测试代码。Agent 的生成范围包括：
CI 配置与发布工具链；
内部开发管理工具；
架构设计的历史文档；
评估系统与测试框架；
PR 中的审查评论与回复；
仓库本身的脚本；
生产环境监控面板的定义文件。
Agent 正在以与人类工程师相同的方式使用标准开发工具——拉取审查意见、执行内联回复、推送更新、自主压缩并合并 PR。
人类工程师的职能迁移
执行环节被全面接管之后，人类的工作重心迁移至一个完全不同的抽象层级：
排定优先级——决策执行范围与非执行范围；
需求翻译——将用户反馈翻译为无歧义的验收标准；
最终验证——确认交付成果是否符合预期。
若 Agent 在执行过程中卡壳，人类工程师不会下场逐行修复代码。他们将 Agent 的失败行为本身视为一种错误信号，并据此排查：系统中是否缺失某种检测工具？是否缺少某种护栏？是否文档描述不充分？找到缺口并补充至系统之后，仍由 Agent 自主完成代码修复。
人类不再是执行者，而是环境与标准的设计者。
全自动闭环
当测试、评审、反馈、处理整个开发循环被完整编码至系统架构之后，Agent 跨越了决定性的自治阈值：
输入需求
↓
查验代码库现状
↓
遭遇 Bug → 自主复现 → 录制错误视频（证据留存）
↓
完成代码修复
↓
驱动应用自我验证 → 录制成功运行视频
↓
自主开启 PR → 响应审查意见
↓
遭遇构建报错 → 自主排查并修复
↓
涉及方向性抉择？
├─ 是 → 触发人类介入
└─ 否 → 自动合并代码
除涉及方向性决策的情形外，Agent 将自主执行至代码合并。从需求输入到最终合并，全程由机器接管。
冷峻的边界条件
OpenAI 随即给出了一个严格的限定条件：上述行为高度依赖于该代码库的具体结构与工具链，不应假设其具备普适可复制性——除非投入了同等量级的工程资源。
自治能力不能被简单复制粘贴。使大模型自动生成代码而不构建基础设施，只会加速系统崩溃。
自治程度越高，对环境设计与工程约束的严密性要求越高。
三、熵增控制：技术债的自动偿还
Agent 具备瞬间生成大量代码的能力之后，随之而来的是逐渐难以察觉但持续累积的代码熵增。
Agent 的复制与放大本能
无论投入多少精力设计架构护栏，Agent 的底层行为模式仍然是复制——模仿仓库中已有代码的模式。一旦某个局部出现细微技术债，这种低成本妥协会被 Agent 快速复制并放大，最终导致系统结构逐渐丧失连贯性。
恶性循环链：技术债 → Agent 复制 → 更多技术债 → 更快复制 → 系统失控。
人工清理的失效
OpenAI 团队曾尝试每周划拨约 20% 的工作时间由工程师专项执行代码清理。该方案在高度自动化、高吞吐量的环境中失效——代码生成速度远超人类清理速度，人工清理永远无法追上自动生产速度。
三层防御体系
第三层：自动偿还机制
↓ 持续小步清理结构偏移（类垃圾回收）
第二层：持续清理 Agent
↓ 自动生成重构 PR（快速 Review / 自动合并）
第一层：黄金原则（Linter 机械执行）
↓ 立即拦截违规
若跳过防御 → 代码熵增 → 技术债指数级增长
图示说明：三层防御构成持续运行的垃圾回收机制——不等待系统失控再执行大规模重构，而是小步自动清理。
第一层：黄金原则。 将工程师对代码的判断标准编码为一组可被机器检查并强制执行的明确规则。例如：优先使用共享工具库而非在各模块中各自实现工具函数；获取外部数据后必须先执行显式结构验证，不得直接假设字段存在。
第二层：持续运行的清理机制。 后台定期运行专项 Agent 任务，扫描代码库中是否出现偏离黄金原则的模式。一旦检测到问题，自动生成针对性重构 PR。此类 PR 改动范围小，可快速 Review 甚至自动合并。
该机制类似于系统底层的垃圾回收——不等待系统失控再执行一次性大规模重构，而是持续小步、自动清理结构偏移。
第三层：技术债的自动偿还。 Agent 时代的技术债具有复利性质——若放任不管，累积增速将超过偿还能力。唯一可持续的方案是建立持续小额自动偿还机制。
四、纪律的转移
上述实践背后存在一个明确的结论：
纪律正从代码本身转移到工程支架上。
代码本身不再是纪律的主要载体。支架所指为工具、执行环境、系统抽象、反馈回路——整个底层控制系统。
当前最困难的挑战并非如何最大化模型代码生成能力的上限，而在于能否构建一个具备足够稳健性的控制架构。
本章要点
成本反转——修正成本极低、等待成本最高；最小化阻塞门控，采用高频小批量策略；
端到端自主——Agent 接管从代码生成到运维的全流程，人类转变为标准制定者；
自治的门槛——高度自治需要极高的基础设施投入，并非撒手不管；
熵增控制——黄金原则 + 持续清理 Agent + 自动偿还机制，构成三层防御；
纪律转移——从代码本身转移到工程支架（工具、环境、反馈回路）。
Harness 即操作系统
Harness Engineering 核心原则 · 第 4 章
当代的操作系统是什么？是 Agent Harness。
前三章建立了 Harness 的基本框架：范式转移、感知通道、成本结构与熵增控制。本章将视角提升至最高抽象层级——Harness 的本质是什么？构建逻辑是什么？底层理论框架是什么？
答案分三层：Harness 是操作系统；但必须以可废弃为前提构建；而这一切的底层理论框架是控制论。
一、Harness = 操作系统
Google DeepMind 工程师 Filip Hráček 提出了一个精确的类比框架。
静态跑分的认知偏差
各顶尖模型在静态基准测试中的性能差距已收缩至极窄区间。但该指标可能存在系统性偏差——任务时长与复杂度提升后，模型之间的真实差距才会充分暴露。
具体场景：使模型在企业环境中执行长线自动化流程——读取数百页文档、检索代码以总结依赖关系、调用 API、创建工单、汇总报告。执行过程中模型逐渐偏离初始目标，或完全遗忘第一步设定的安全规则。
排行榜上的分差无法测得此类系统性失效。
四大核心功能
Agent Harness 是包裹于 AI 模型外围的基础设施层，用于管理长生命周期任务，具备四大核心功能：
生命周期钩子尤为关键——其为流程中预埋的检查节点。模型每执行完一步，钩子自动触发检查：输出格式是否正确？Token 是否超限？是否触发安全红线？检查未通过，钩子直接拦截并触发重试。
完整类比框架
计算能力 ← 大模型
↓
Harness（操作系统）
├─ 上下文管理 ↔ 内存（RAM）管理
├─ 启动引导 ↔ 注入基础 Prompt
├─ 生命周期钩子 ↔ 自动检查站
└─ 工具调用处理 ↔ 设备驱动程序
↓
Agent 应用（运行于操作系统之上的应用程序）
图示说明：Harness 是包裹于大模型外围的操作系统——大模型相当于 CPU，上下文窗口相当于 RAM，Harness 才是使各组件协同运转的操作系统层。
Harness 的本质是操作系统。它管理上下文、处理启动引导（注入基础 Prompt）、预埋生命周期钩子、提供标准化驱动程序（工具调用处理）。
2026 年的核心定位
Harness 弥合了基准测试分数与实际体验之间的鸿沟，释放模型潜力，构建闭环反馈——系统改进能力的上限，完全取决于验证输出的成本高低。
二、为废弃而构建
Harness 是操作系统，那么应当如何构建它？
直观思路可能是：输出格式异常则增加校验拦截与重试层；多步规划偏离则构建复杂状态机以强制纠偏。该思路在传统软件工程中具备合理性，但应用于 Agent Harness 时——失效。
苦涩的教训
计算机科学家 Rich Sutton 曾撰写著名短文 The Bitter Lesson，核心论点为：过去 30 年中，每一次依赖大规模算力的通用方法，均击败了人工编码嵌入系统的先验知识。无一例外。
该教训正在 Agent 开发领域真实重演。
顶级团队的代码削减行为
顶级团队并非在增加代码，而是在大幅削减代码。此前精心设计的「聪明逻辑」，在新模型面前全部成为累赘。
Build to Delete
Harness 的构建原则是：为废弃而构建。
新模型发布必然带来全新的 Agent 构建方式。2024 年需要复杂管道才能实现的功能，2026 年可能仅需一条 Prompt 即可实现。Harness 架构必须具备乐高积木式的松散耦合特性——允许随时流畅地移除昨日才写入的「聪明控制逻辑」。
若对控制流实施过度设计，下一次模型更新将直接击穿系统。
Harness 的真正价值：捕获崩溃数据
既然 Harness 代码注定被删除，其价值位于何处？
答案是模型漂移（Model Drift）。模型在短对话中表现良好，但在超长任务中逐渐「缺氧」——遗忘开局设定的规则，开始输出无意义内容。
Harness 像飞机黑匣子一样，精确记录模型在第 100 步之后究竟于哪个节点丧失了指令遵循能力。这些断点数据可直接反馈至训练集，反哺下一轮训练。
The Harness is the dataset.
何种 Harness 在真实场景中拦截到更多崩溃轨迹，何种团队便能提炼更高质量的后训练数据集，进而有可能训练出更优模型。
结论明确：不应抗拒重构与代码废弃。部署监控网络，记录大模型每一次失控瞬间——这些是用于训练更强模型的宝贵数据集。
三、控制论：闭环与校准
为何多个团队在引入 Coding Agent 后反而陷入更混乱的状态？代码产出量增加，但代码库质量下降。PR 合并速度加快，但架构漂移加速。
硅谷工程师 George 的判断是：这并非简单的 AI 代码生成问题，而是控制论进入代码生产层。
该模式的三次出现
第一次：18 世纪的蒸汽机调速器。 James Watt 发明离心调速器——一种机械装置感知转速并自动调节阀门。工人的职能从手动调节阀门迁移至调速器设计。
第二次：Google 的 Borg 服务器管理系统。 向系统声明目标状态，系统自动维持该状态。工程师的职能从手动重启服务迁移至编写精确的状态声明。
第三次：当前，OpenAI 的 Coding Agent。 工程师不再写代码，而是设计环境、构建反馈回路，使 Agent 执行代码生成。五个月，100 万行代码，零行手写。
Norbert Wiener 于 1948 年将该模式命名为控制论（Cybernetics）。核心概念只有一个——闭环。输出影响输入，系统自主纠偏。
设定目标 / 规范
↓
执行器
↓
系统输出
↓
传感器（感知输出）
↓
对比目标 → 偏差？
├─ 存在偏差 → 纠偏 / 修正 → 回到执行器
└─ 无偏差 → 稳定状态
图示说明：每一次技术跃迁——蒸汽机调速器、Borg、Coding Agent——本质都是在某一层级上首次成功实现闭环。
代码库为何是最后一个被攻克的？
代码库始终存在反馈回路，但仅处于低层级：编译器检查语法、测试检查行为、Linter 检查风格。这些仅能处理可机械检查的问题。
更高层级的问题从未被自动化——此次改动是否符合系统架构？随着代码库增长，此抽象是否会引发问题？此类问题既无传感器也无执行器，仅有人类能在这一层级操作。
LLM 同时改变了两者：它能感知架构质量，也能执行架构修改。历史上首次，反馈回路可以在重要决策发生的层级闭合。
闭环是必要条件，而非充分条件
Watt 的调速器需要调教。Borg 的控制器需要正确的 spec。接入 Agent 不等于任务完成——真正的工作是校准该回路，使其知晓「好」的定义。
工程师头脑中的判断力属于隐性知识，通过经验积累，难以言传。Agent 没有 Code Review、结对编程、口耳相传的渠道。必须将隐性知识转化为显性知识并记录于文档中，Agent 方能使用。
OpenAI 曾每周划拨 20% 时间执行代码清理，后续将标准编码入 Harness 本身才解决该问题。Anthropic 的 Nicholas Carlini 在执行 16 个并行 Agent 构建 C 编译器的实验中表述：「我大部分精力都花在设计 Claude 周围的环境上。」
为何引入 Agent 后反而更混乱？
文档、自动化测试、成文的架构决策——这些实践始终是正确的。过去 30 年几乎所有工程师均推荐这些实践，多人选择跳过是因为代价呈现缓慢。
Agent 工程将该代价放大至极端：
更危险的陷阱：若 Agent 根本不知道「整洁」的定义，甚至无法利用 Agent 清理其自身制造的混乱。缺乏校准，制造问题的机器同样无法解决问题。
实践本身未发生变化。发生变化的是忽视这些实践的代价，从可承受变为不可承受。
人类在 Agent 时代的定位
验证答案正确性比生成正确答案更容易。该规律在 LLM 上亦被实验证实。因此无需在实现速度上与机器竞争。
应专注于评估侧：定义正确性的标准、识别输出偏差、判断方向是否正确。
工程师不会消失，但工程师的工作将如同前两次一样——再上移一层。设计 Watt 调速器的工人并未回到阀门前手动操作，并非因为他们不能，而是因为此举不再具备意义。
本章要点
Harness = 操作系统——管理上下文、处理引导、预埋钩子、提供驱动；2026 年的核心定位是基础设施而非应用；
Build to Delete——Harness 代码注定被废弃，真正价值是捕获崩溃数据（The Harness is the dataset）；
控制论闭环——输出影响输入、系统自主纠偏；每一次技术跃迁都是在某一层级上首次成功闭环；
校准比闭环更重要——闭环是必要条件，校准是充分条件；必须将隐性知识显性化并编码入 Harness；
人类职能再上移一层——无需与机器在实现速度上竞争，专注于定义正确性、识别偏差、判断方向。
LangChain 实战与工具设计
本章隶属 Hermes Engineering 系列第 I 模组第 5 章。
LangChain 通过调优 Harness，使 Deep Agents 基准测试分数从 52.8 提升至 66.5，排名从第 30 位以外进入前五——模型基座保持不变，仅调整 Harness。
诊断机制：Trace 即反馈信号
Agent 发生偏离、报错或超时之后，遗留的是成千上万行运行轨迹。LangChain 将「检索日志以定位问题」重构为 Trace Analyzer Skill——从 LangSmith 拉取全部运行轨迹，按批次切分并启动多个分析子 Agent 并行执行，所有结论汇总为改进建议。
关键约束：改动必须具备通用性。针对特定任务过度拟合的修改可能导致其他任务表现退步。Trace 构成整个改进闭环的核心信号源。
四条有效改进路径
Trace 数据
↓
Trace Analyzer Skill
↓
并行分析子 Agent
↓
结构化改进建议
↓
实施四条改进
├─ 强制验证
├─ 上下文注入
├─ 循环探测
└─ 算力分配
↓
跑分提升：52.8 → 66.5
图示说明：LangChain 不更换模型、不修改架构，仅调优 Harness 即推动分数提升 13.7 分——Harness 是逼近模型能力上限的杠杆。
1. 强制验证
Agent 最常见的失败模式是：完成代码生成后直接宣告任务结束，未执行测试。
两道防线：提示词层面的「规划 → 构建 → 验证 → 修复」四步框架；系统层面的完结前检查中间件强制拦截未验证任务。
2. 上下文注入
Agent 启动时，系统自动扫描目录结构并注入环境地图；明确声明「你的产出将被自动化测试评估」；接近截止时间时注入时间预算提醒。Harness 应主动向模型交付运行条件，而非使 Agent 自行发现并组装。
3. 循环探测
Doom Loops——Agent 在同一文件上连续修改超过十次但思路未发生变化。循环探测中间件记录编辑次数，超过阈值则注入反思提示。该设计是针对当前模型缺陷的工程护栏，随模型能力进化将变得冗余。
4. 算力分配
全程使用 X-High 推理等级反而导致性能下降。采用分段式分配策略——规划阶段 X-High、实现阶段 High、验证阶段 X-High。推理算力差异化配置策略将分数推至 66.5。
工具设计哲学
Seeing Like an Agent——从 Agent 的视角观察，聚焦于调用频率、调用时机与输出质量。
ask_user_question 的三次迭代
三条经验：一个工具一种意图；Schema 约束而非格式约定；工具设计应使模型倾向于使用。
工具迭代：模型能力进化后的工具重构
模型能力增强后，旧工具可能成为约束。典型案例：todo_write 升级为 task——从单 Agent 清单演进为多 Agent 共享协作面板。
渐进式信息披露
Guide 子代理按需读取文档并仅返回精确答案，避免主模型认知负载膨胀。
常见错误对照表
本章要点
LangChain 通过 Harness 调优实现 13.7 分提升（52.8 → 66.5）；
四条改进路径：强制验证、上下文注入、循环探测、算力分配；
Seeing Like an Agent：一个工具一种意图，Schema 约束优于格式约定；
模型能力决定上限，Harness 决定逼近上限的程度。
争论与未来
Harness Engineering 核心原则 · 第 6 章
模型是计算引擎，Harness 是力量传递系统。模型决定理论性能上限，Harness 决定该上限有多少能被实际传递到负载上。
前五章建立了 Harness Engineering 的完整理论体系：范式转移、感知通道、成本结构、操作系统视角、实战调优方法。本章回归一个根本性问题——Harness 是否具备长期价值？
AI 工程领域对此存在激烈争论。两种观点、一条工具光谱，以及最终的调和方案。
一、Big Model vs Big Harness
一个 Agent 表现出色，究竟是因为底层基座模型能力极强，还是因为其外围工程 Harness 构建得极为精密？
该类比于金融领域的经典问题：一名交易员年度贡献 300 万美元利润，究竟是因为其个人操盘能力极为出色，还是因为其位于高盛交易席位上？
Big Model 派
以 Claude Code 为代表的大模型派认为：Harness 很可能仅为过渡性产物。Claude Code 的 Harness 被刻意设计为极薄的一层封装，核心设计原则是尽量减少对模型的干预，使模型自主发挥全部能力。
部分测试数据似乎支持该观点。在 Scale AI 的 SWE Atlas 编程基准测试中，Claude Opus 4.6 在 Claude Code 的 Harness 下表现略有提升，但 GPT-5.2 反而在通用 SWE Agent Harness 下表现稍优——分差极小，基本处于误差范围内。
高阶推理模型核心作者 Noam Brown 表述更为直接：推理模型出现之前，为使 GPT-4 表现出类似推理的能力，工程师在外围写入了大量复杂的重试逻辑与 Prompt。但当前底层推理模型已能自主完成多数推理步骤——若继续强行嵌入大量复杂脚手架，反而可能拖慢模型表现。
Big Model 派核心论断：模型能力越强，所需外围代码层越薄。一旦基座模型跨代升级，精心构建的数万行编排代码可能迅速变为历史遗留物。
Big Harness 派
LlamaIndex 创始人 Jerry Liu 持完全不同观点。他认为当前已具备极强模型与大量优秀工具，但企业真正难以解决的问题从来不是模型智能程度不足，而是是否具备将业务上下文正确组织并输入模型的能力。
具体场景：若欲使用 Claude Code 自动处理企业客户流程，必须先投入大量时间将业务类型、流程规范、权限规则完整写入清晰文档。一份标准 SOP 仅规则描述往往就需要反复修改数小时——该工作难以由模型自动完成。
Jerry Liu 的结论：未来几乎所有 AI 产品的本质均为两件事务——提供上下文与提供工作流。
一项有趣的实验
一名开发者维护着一个开源编程 Agent。某日下午仅调整了一项内容——未更换模型，也未重新训练任何参数，仅调整了 Harness 中代码编辑工具的输出格式。结果 15 个主流大模型在编程基准测试中均获得显著提升。
其结论极为形象：「模型出现问题，多数情况下并非因为其无法理解任务，而是因为其没有合适的语言来表达自身。一直归咎于飞行员，但实际上是起落架故障。」
调和：Model × Harness
AI 领域一直存在一种调和派观点称为 Compound AI——模型具备价值，系统工程也具备价值。但此次情况可能有所不同。随着 Cursor 估值突破 500 亿美元，随着越来越多企业 Agent 真正落地，「所有外围工程最终都会消失」的判断正在被市场质疑。欧洲 AI Eng Europe 大会已正式设立全球首个 Harness Engineering 专属议题轨道。
未来的竞争很可能并非 Model vs Harness，而是 Model × Harness。两者相乘，共同决定最终表现。
Harness 厚度
↑
强模型 + 厚 Harness │ 强模型 + 薄 Harness
（Deep Agents） │ （Claude Code）
────────────────────┼────────────────────
弱模型 + 厚 Harness │ 弱模型 + 薄 Harness
│ （纯 API 调用）
└────────────────→ Model 能力
图示说明：强模型不需要厚 Harness？但企业级难题从来不在模型智能程度——未来竞争是 Model × Harness 的乘法效应。
二、Framework vs Harness：工具光谱
多数工程师学习 AI 开发的第一步是学习 LangChain，随后发现还有 CrewAI、AutoGen、LangGraph……新工具持续涌现。但真正重要的问题在于——无人告知这些工具根本不属于同一类别。部分属于 Framework，部分属于 Harness。
工具光谱：从左到右
纯代码 ←——————→ Framework ←——————→ Harness
（最左侧） （中间） （最右侧）
纯代码——无任何封装层，直接调用大模型 API，手动管理全部状态。灵活性最大，但全部复杂性均由开发者承担。
Framework（LangChain、CrewAI）——提供封装好的组件、工具接口、任务调度、角色分工，屏蔽底层通信的复杂性。但系统如何设计仍由开发者决策，使用何种模型由开发者决策，如何存储记忆由开发者决策。类似于采购宜家家具——板材与紧固件均已提供，最终组装结果由开发者决定。
Harness（OpenAI Codex）——不提供零件，直接提供完整系统。填入 API 密钥即可运行，记忆如何存储、出错如何重试，全部由系统决定。类似于购置一台原厂完整调校的跑车——注入燃料即行驶，代价是无法修改其内部逻辑。Harness 以控制权换取执行速度上限。
LangChain 的自主扩张
值得注意的现象是，LangChain 自身也在向右扩张。其将技术栈分为三层：最底层 LangChain（Framework）、中间层 LangGraph（执行引擎）、最外层 Deep Agents（Harness）。单一机构完整覆盖整条工具光谱。
选型指南
工具选型之前，首先回答一个问题：是需要长期掌控每一行代码，还是需要赶进度以现成套件直接交付？
Anthropic 的忠告
Anthropic 在 Building Effective Agents 中明确表述：构建 Agent 应慎用复杂框架。框架的黑盒性质一旦引发错误，调试成本极高，且调用便利性容易导致团队陷入过度工程化。多数情况下直接写入数行代码连接大模型 API，反而更快更稳定。
三、回归 Harness Engineering
争论归争论，一个事实日益清晰：当代码开始由 Agent 生成，仓库便不再仅仅是人类协作空间——其转变为机器认知系统。
在该系统中，Harness 并非附加层级的框架，而是操作系统级别的基础设施。它管理上下文、约束行为、捕获崩溃数据、构建反馈闭环。
无论 Big Model 派与 Big Harness 派如何争论，有一点双方均会同意：改进系统的能力上限，完全取决于验证输出的成本高低。 而验证，恰恰是 Harness 的核心功能。
唯一可靠的方法仍然是持续实验、观察结果、迭代调整——Seeing Like an Agent。
本章要点
Big Model 派——Harness 是过渡性产物，模型越强外围层越薄，基座升级后编排代码变为遗留物；
Big Harness 派——企业级难题不在模型智能程度，而在上下文组织；未来 AI 产品的本质为两件事务：提供上下文 + 提供工作流；
调和：Model × Harness——两者相乘共同决定最终表现，市场正在验证 Harness 的长期价值；
工具光谱——纯代码（灵活性最大）→ Framework（宜家模式）→ Harness（原厂跑车），厘清区别方能正确选型；
核心共识——无论何种观点，均同意「验证输出的成本」决定系统改进能力的上限。
至此，第一篇完结。如果有什么地方觉得不好可以提出来，我会加以改正。
注：本人是从网络上从其他老师那里学到的Harness工程，可能会有一些观点如其他老师观点，请见谅！