Appearance
Harness 失效模式与演化方向
方向定位：把 Agent 在 Harness 中"为什么会出错 / 怎么把反馈做成系统 / 又会随模型如何演化"放在同一条主线上。涵盖五大根本挑战、五种典型故障、Context Anxiety 与 40%/60% 阈值、2×2 反馈矩阵、GAN 三角色、Dry-Run、Harness 减重诊断、协同演化双刃剑、HL 反向通道、Skills/SkillHub。 不涵盖：Harness 概念定义、六层架构总述、技术原语（→ Harness 概念与架构体系）；具体落地杠杆与 AGENTS.md（→ 工程实践）。 当前版本：v0.4（由"失效模式与反馈机制"v0.3 + "演化与未来形态"v0.3 合并精简） 首次构建：2026-05-12 最近更新：2026-05-20 文件名日期同步：2026-05-20 来源数：14 篇
方向定位
本方向研究三组互相缠绕的问题：
- 失效模式（Anti-patterns）：Agent 在长任务中为什么会出错——状态丢失、目标漂移、自评虚高、Context Anxiety、熵增、过早停止。这些故障的根因往往不在模型，而在 Harness 设计假设的失效。
- 反馈机制（Feedback Mechanisms）：发现"做错了"和保证"做对了"是两件不同的工程任务——独立 Evaluator、2×2 矩阵、Hooks、Sprint Contract、Dry-Run、In-the-loop vs On-the-loop。
- 演化方向：Harness 不是静态架构，而是随模型能力演化的动态系统——哪些组件正在变冗余、哪些是核心承重墙、Skills/SkillHub 跨框架流通、HL 反向通道。
核心命题：
- 仅靠模型自身无法形成有效的质量闭环，必须在模型外部建立独立的评估机制。
- Harness 是一个会移动的边界，不会消失但会重塑。架构必须建立在稳定假设上，不是当前模型的暂时缺陷上。
- "目的地"问题永远是人的责任，再强的模型也不能自己生成。
不在本方向范围：基础概念定义、六层架构、技术原语（→ Harness 概念与架构体系）；四大工程杠杆与 AGENTS.md 设计要点（→ 工程实践）。
知识图谱
- 失效模式分类：状态记忆类（Context Anxiety、跨 session 失忆）；评估质量类（自我评估偏差、Evaluator 误判）；控制流类（无限循环、过早停止、目标漂移）；资源类（上下文爆炸、40%/60% 阈值）；系统类（熵增 / AI slop）
- Agent 五大根本挑战：状态持久性、目标一致性、行动可验证性、熵增抑制、人机边界
- 反馈机制设计：GAN 三角色（Planner / Generator / Evaluator）；2×2 矩阵（Guides × Sensors × Computational × Inferential）；Sprint Contract；Hooks（软约束 → 硬约束）；Dry-Run Harness
- 核心工程升级路径：In-the-loop（手改产物） → On-the-loop（改 harness） → L4 Meta-Harness 化（稳定抽象层）
- 演化规律：每个组件都编码"模型做不到"的假设；假设失效 → 组件冗余 → 应该删
- 协同演化双刃剑：原语 → 训练 → 模型变强 → 新原语；但泛化能力下降，Harness 难解耦
- Skills / SkillHub：跨框架通用的自然语言能力单元 → 跨 Harness 流通平台
- Heuristic Learning：经验从权重转移到代码、测试、回放——梯度之外的第二条学习通道
- 不变的核心：人的"目的地"责任不可吸收，模型越强，对人的能力要求越高
第一章 失效模式
1.1 五大根本挑战：Harness 存在的"宪法"
论断（22）：长任务的可靠性不会因为模型单步更聪明就自动获得。五个挑战每一个都不能靠更聪明的模型单独解决。
| 挑战 | 本质 | 为什么模型解决不了 |
|---|---|---|
| 状态持久性 | 跨时间、跨 session 记住做过什么 | 模型无状态，context window 有上限 |
| 目标一致性 | 长任务中防止漂移、提前宣布完成 | 缺少外部锚点，无法稳定校准"真正完成" |
| 行动可验证性 | 区分"做了"和"做对了" | 自我评价天然存在自我表扬和误判倾向 |
| 熵增抑制 | 持续产出累积冗余、漂移、不一致 | 模型复制已有模式，包括坏模式 |
| 人机边界 | 何时自主、何时交人 | 没有可靠的"不确定性自觉" |
为什么这五个挑战是"根本"：不是模型能力提升能消除的，不是接一个工具就能解决的，都需要在模型外部建立机制——这恰好是 Harness 存在的根本理由。
与失效模式的对应：状态持久性 ↔ Context Anxiety / 跨 session 失忆；目标一致性 ↔ 过早停止 / 目标漂移；行动可验证性 ↔ 自我评估偏差；熵增抑制 ↔ AI slop / 坏模式复制；人机边界 ↔ Agent 在哪个节点该交回给人。
这五大挑战为什么不会随模型升级消失（即"核心承重墙"不可被吸收），是第三章"减重诊断"反向不变项的依据。
1.2 五种典型失效模式
1.2.1 Context Anxiety（上下文焦虑）
定义（12、18、22）：Agent 感觉 Context Window 快满了 → 提前收尾任务（不是因为完成了，而是"焦虑"了）。
典型表现：任务未完成时主动宣布"已完成"；优先输出"看起来完整"的内容；剩余 token 不多时倾向于做总结而非继续推进。Anthropic 发现 Sonnet 4.5 出现此行为，Opus 4.5 已基本消除。
两种应对策略：
| 应对策略 | 机制 | 权衡 |
|---|---|---|
| Compaction（压缩） | 摘要历史对话，同一 Agent 继续 | 保住连续性，但无法消除焦虑感 |
| Context Reset（重置） | 清空上下文，启动新实例 + handoff artifact | 消除焦虑，但交接文件必须完整 |
本质（12）：在连续性 vs 清醒度之间选边。
为什么 Compaction 不够（22）：即使压缩后 token 数下降，agent 仍因"上下文太满"的感觉而行为退化——解决方案不是更好的 compaction，而是给新 agent 全新 context + 外化状态工件续航。类似"重启进程解决内存泄漏"，而非无限加内存。
与 Durable State 的关联：Context Reset 只在 Durable State 设计良好时才有效。关键判据：agent 冷启动后能否在 30 秒内读取、理解、续航？ 状态 ≠ "保存聊天记录"；真正的 durable state 是结构化工件。
CU 场景实测数据（Anthropic 2026-05-13）：Computer Use Agent 是 Context Anxiety 的最密集触发场景——每步生成一张截图消耗约 1,000-1,800 token（取决于分辨率），200K context window 在不做任何管理的情况下 100 步之内即可填满。这使 CU 成为 Context Anxiety 的"极端工况"：不是"聊多了会焦虑"，而是"操作几十次就必然焦虑"。CU 场景下 Compaction 和 Context Reset 不是优化手段而是生存必需品。
1.2.2 自我评估偏差
核心论断（多源一致）：
- 17（Anthropic）：当 Agent 评估自己刚完成的工作时，它会自信地表示"做得很好"，即便在人类看来质量明显不行
- 18：开箱即用的 Claude 是一个很差的 QA Agent
- 12：Agent 评价自己时倾向虚高分——先发现真正的问题，然后说服自己"不是大事"，最后通过验收。这不是"看不见问题"，而是"看见了但放过自己"
为什么模型自评不可靠：训练目标导致正向偏好；缺少独立验证锚点；长 context 中 Generator 和 Evaluator 角色混合导致"自圆其说"。
关键洞察（22）：
调教一个独立的 Evaluator 让它保持怀疑，远比让 Generator 批判自己的作品容易得多。
1.2.3 上下文利用率阈值（40% / 60%）
两个关键阈值（多源比较）：
| 来源 | 阈值 | 表述 | 工程含义 |
|---|---|---|---|
| 05（Dex Horthy） | 40% | Smart Zone（0-40%）vs Dumb Zone（>40%）；168K token 窗口超过约 40% 后幻觉增多、代码质量下降 | 触发交接/总结 |
| 16（外部研究引用） | 60% | 上下文利用率达约 60% 后继续塞信息反而让 agent 表现变差 | 上限警戒 |
| OMC 案例 | 40% | OMC 把 40% 直接编码为框架默认：子 Agent context > 40% 即触发 Orchestrator 创建结构化交接文档并启动新 Agent | 工程化为框架默认 |
冲突分析：40% 是"质量开始下降"的早期信号；60% 是"明显变差"的临界点；不矛盾，是同一现象的两个阶段。⚠️ 两个阈值都标注为"观察"或"研究引用"，不是硬性规律，模型版本不同会有差异。
Context Rot（上下文腐烂）（16）：随着上下文膨胀，模型会出现 recall 下降、推理偏移、忽略约束。
正确做法：让 Agent 始终运行在"干净、相关"的上下文里——不是压缩塞更多，而是让它在任何时候都运行在干净相关的上下文里。三种对抗策略（07）：压缩机制、工具调用卸载（大输出只保留头尾）、技能渐进式披露。
与 Context Anxiety 的关系：40-60% 阈值是外部观察的质量下降点；Context Anxiety 是 agent 内部主观感受导致的行为退化。即使物理上没满，主观焦虑也会触发提前收尾。两者一起说明：单纯的"压缩"既解决不了客观质量下降，也解决不了主观焦虑。
1.2.4 熵增（Entropy Increase）
定义（22）：全自动 agent 代码库不断复制既有模式，包括糟糕的模式。系统噪声持续累积——AI slop（冗余代码）、过时文档、不一致命名、技术债。
为什么会发生：LLM 倾向于"重新实现已有功能"而不是复用；没有架构约束时全局一致性丢失；没有定期清理时垃圾积累速度 > 维护速度。
典型代价：OpenAI 初期人每周花约 20% 时间清理"AI slop"。
关键指标（05）：清理速度 ≥ 生成速度。一旦反过来，系统会快速崩坏。
系统化解法（22）：documentation consistency agents 定期验证文档一致性；refactor agents 计划清理技术债；architectural enforcement 通过 CI 机械维护模块边界。
设计原则：Harness 不只负责"让 agent 跑起来"，还负责持续抑制 agent 放大的系统噪声——这是它与简单框架最本质的区别。
工业级落地：AutoDream 后台整合（charrli 源码解析）：某顶级 Coding Agent 在源码层面实现了一个静默运行的熵治理子系统——让 Agent 在"空闲时"像人类睡眠一样整理和巩固记忆。
- 三重门控：时间门控（距上次至少 24 小时）→ 会话门控（至少 5 次对话）→ 锁门控（文件锁未被其他进程持有）
- 四阶段：Orient（读取记忆索引）→ Gather（扫描会话提取知识）→ Consolidate（新旧融合，更新/合并/创建）→ Prune & Index（删除过时/冗余，重建索引）
- 锁机制：基于文件 mtime，超过 1 小时视为 stale，失败时完整 rollback
灵感直接来自人类睡眠的 REM 阶段记忆巩固理论。OpenAI 的"每周 20% 清理时间"是人力解法，AutoDream 是机器解法——证明熵治理可以完全后台化。
1.2.5 无限循环 / 过早停止 / 目标漂移
源 26 提出 Harness 必须能解决的五个具体工程难题（"作业清单"）：
| 难题 | Harness 解法 | 对应组件 |
|---|---|---|
| 无限循环 | Agentic Loop 设置终止条件 | Agentic Loop |
| 上下文爆炸 | 压缩策略与滑动窗口管理 | Memory & Context Management |
| 权限失控 | Guardrails 的 Allow / Deny / Ask 三级控制 | Guardrails |
| 质量不可控 | 循环内嵌入质量审核节点 | Hooks + Evaluator |
| 成本不透明 | Token 追踪与预算约束 | Session |
关键认知（26）：底层是无状态的纯推理大模型；Harness 做的是把大模型的大脑变成 Agent 的身体。无限循环、上下文爆炸这些问题，本质都是"大脑没有身体的协调机制"，必须由 Harness 补齐。
典型失败案例——"错得合理"（16）：用户说"做一个后台新增商品功能"，缺失幂等性、权限、API 合约等关键信息。Agent 实现一个 MVP，再次点击按钮重复插入。这是目标一致性 + 行动可验证性双重失败——很多"AI 写错了"的问题，本质是反馈系统没有在前端介入——验收标准没有显式化，Agent 就只能猜。
1.3 In-the-loop vs On-the-loop：核心升级路径
定义（22）：
| 模式 | 工程师做什么 | 心智模型 |
|---|---|---|
| In-the-loop | 手改 agent 产出的具体产物（bug、错误代码） | "AI 写错了，我来改" |
| On-the-loop | 改 harness 让系统下次自动做得更好 | "AI 又写错了，规则/工具/反馈哪里需要改？" |
论断：大多数团队还停留在 In-the-loop。
为什么 On-the-loop 是核心升级：In-the-loop 是线性投入，错一次修一次；On-the-loop 是平台化投入，每次改 harness 都减少未来某类错误——复利效应是 In-the-loop 的 N 倍。
类比 Mitchell Hashimoto 的工作流（12）：
每当我发现 Agent 犯了一个错误，我就花时间工程化一个解决方案，让它永远不再犯同样的错误。我叫这个过程 Harness Engineering。
关键判据：不满意 agent 输出时，低层做法是手改产物；高层做法是改 harness，让系统下次自动做得更好。从 in the loop 到 on the loop，这才是工程师在 agent 时代的核心升级路径。
升级阶梯的更高层级（L4 Meta-Harness 化）见第三章框架 3。
第二章 反馈机制
2.1 框架：2×2 反馈矩阵
核心思想（22）：反馈系统在两个维度上各有两种性质——作用时机（行动前 vs 行动后）和反馈性质（确定性 vs 推断性）。Harness 必须在四个象限同时投入。
| Computational（确定性，便宜快） | Inferential（推断性，贵慢） | |
|---|---|---|
| Guides（行动前约束） | 代码规范检查、类型校验 | AI 评估代码设计合理性 |
| Sensors（行动后反馈） | 测试套件、linter 结果 | AI 评估 UI 美观度、代码风格 |
关键洞察：
- 只有 guides 无 sensors → 规则生效与否无从知晓（约束悬空）
- 只有 sensors 无 guides → 不断重复同样错误再纠正（白白消耗 token）
- 只有 computational 无 inferential → 错过设计质量、用户体验等不可机械化检测的问题
- 只有 inferential 无 computational → 浪费 AI 调用做本该机械化的事
与四大杠杆的映射：Custom Rules → 左上（Guides × Computational，规则文本）；Linter / Type check → 左上（最硬的 Guides）；Tests → 左下（Sensors × Computational）；Code Review Agent → 右下（Sensors × Inferential）；Sprint Contract → 右上（Guides × Inferential）。
注意事项：矩阵的价值不在分类，在强迫团队检查四个象限是否都有投入。大多数团队只在 Sensors × Computational 一格投入（写测试），其他三格空白。
2.2 框架：GAN 式三角色架构
核心思想（12、18）：把 Generator 和 Evaluator 彻底拆开，引入 Planner 作为高层目标守门人。
| 角色 | 职责 | 失败模式抵抗 |
|---|---|---|
| Planner | 把一两句描述展开成完整 product spec 和分步 feature list | 抵抗目标漂移、错误级联 |
| Generator | 逐 feature 落地，每完成一个 commit | 抵抗局部决策导致的全局不一致 |
| Evaluator | 独立验收，用 Playwright 真正跑页面 | 抵抗自我评估虚高 |
Sprint Contract 机制：单 Sprint 包含 27 条验收标准，在写代码前先就"完成的定义"达成共识；写代码时只看 Sprint Contract，不看完整 product spec（避免 context 过载）。
为什么 Planner 不写代码、Evaluator 独立运行：Planner 只聚焦产品上下文和高层设计，不规定技术细节（避免错误级联）；Evaluator 独立调教为挑剔审查者，不被 Generator 的"自我说服"影响。设计原则：计划必须是一等工件——写入文件系统、被版本管理、可被后续 agent 读取、被验证门引用。
成本与价值：三 Agent 是 Solo 的 20 倍成本，但从"不能用"跨越到"能用"。适用边界：不是所有任务都值得 20x 成本——长任务、高容错要求场景 → 必要；小任务、快速原型 → 浪费。
OMC 工程化范例：oh-my-claudecode（28.3k Stars）把 GAN 思路推到 5 个泳道：规划（Planner/Orchestrator/PRD-Writer）/ 执行（Coder/Feature-Dev）/ 验证（Verifier/Tester/Reviewer）/ 修复（Bug-Fixer）/ 维护（Documenter/Cleaner）。Verifier 完全不参与生成，机制上避免"自审"；Bug Fixer 与 Coder 上下文隔离，避免 Generator "对自己代码已经满意"的虚高评估。GAN 角色分离从"逻辑分工"（同一框架内不同 prompt）升级到"工程隔离"（完全独立的 Agent 实例 + 上下文）才是彻底实现。
2.3 框架：Hooks 把软约束升级为硬约束
核心思想（16）：Agent hooks 把验证逻辑挂到 Stop hook，agent 完成任务前必须通过这些检查。
| 类型 | 实现方式 | Agent 行为 |
|---|---|---|
| 软约束 | 在 system prompt 里写规则 | 可能遵守也可能不 |
| 半硬约束 | Linter 规则、Type check | Agent 必须修复才能通过 |
| 硬约束 | Stop Hook、PR 拦截 | Agent 无法绕过 |
关键变化：软约束是"建议你去跑一下测试"，硬约束是"必须先过门槛"。
典型用法：Stop Hook（完成任务前强制跑测试 / lint / type check）；Pre-commit Hook（禁止提交特定文件、敏感信息）；Pre-tool Hook（执行前确认权限边界）。
2.4 框架：Context Reset 流程
核心思想（12、18、22）：当 Context Anxiety 触发或上下文利用率接近上限时，不压缩，而是清空 + 重启。
1. 触发条件检测：上下文利用率 > 60% OR Agent 行为退化迹象
↓
2. 写入结构化交接文件（durable state artifact）：
- 当前任务进度（JSON 格式 feature 列表）
- 已完成的 commit / PR
- 待解决的问题清单 / 关键决策日志
↓
3. 结束当前 Agent，启动全新 Agent
↓
4. 新 Agent 冷启动：不加载历史对话；读取结构化交接文件；30 秒内重建任务理解
↓
5. 继续推进关键约束：新 Agent 必须能在冷启动后 30 秒内读取、理解、续航。如果做不到，说明 Durable State 设计失败。
CU 场景的 LLM-based Compaction 工程化（Anthropic 2026-05-13）：Computer Use Agent 的上下文膨胀速度远超对话式 Agent（每步一张截图 ≈ 1,000-1,800 token），Context Reset 之外还需要精细化的 Compaction 策略：
| 层 | 策略 | 机制 |
|---|---|---|
| Cache-aware 滚动缓冲 | 保留最近 3 张截图原图，每 25 张批量替换旧截图为占位符 | 批量修剪保持 message prefix 字节一致，prompt cache 命中率不降 |
| LLM-based Compaction | 输入 token 达 ~150K 时触发，用 8 段结构化 prompt 生成摘要 | 保留用户指令/任务模板/约束/进度/当前状态/下一步/错误记录/关键上下文 |
| 服务端 Compaction beta | compact-2026-01-12 beta header | 服务端自动执行摘要替换历史，客户端无需自行实现 compaction 逻辑 |
8 段结构化 COMPACT_PROMPT：LLM-based Compaction 的 prompt 要求模型从历史中提取 8 类结构化信息——这与 Context Reset 的交接文件是同源思想，区别在于 Compaction 让同一 Agent 继续（保连续性），Reset 启动新 Agent（保清醒度）。Anthropic 推荐默认参数：1 个 cache breakpoint 在 system prompt + 3 个 breakpoint 在最近 tool_result 上，每轮前移并清理旧 breakpoint。
（来源：Anthropic CU 最佳实践博客"Context management"节，2026-05-13）
OMC 工程化为框架默认行为：Anthropic 在博客中提出 Context Reset 是手动管理策略，OMC 把它编码为框架默认行为——子 Agent context 超阈值时，Orchestrator 自动创建 JSON 格式结构化交接文档，启动全新 Agent 加载继续；用户全程无感知。这从"用户需要懂得手动重置"升级到"框架自动处理"。
2.5 框架：Dry-Run Harness 安全模式
核心思想：在生产 Agent 真正执行动作前，先把动作 dry-run（模拟执行）一遍，让人或 Checker Agent 审批通过后才进入真执行。是 In-the-loop 范式的工程化标准实现。
Agent 提议动作（plan）
↓
模拟器执行 dry-run（预测影响：哪些文件/数据/API 会被改）
↓
Checker（人 或 独立 Agent）审批 → 通过则真执行 / 拒绝则回退重规划与其它框架的关系：
| 框架 | 约束粒度 | 触发时机 | 拒绝代价 |
|---|---|---|---|
| Hooks 硬约束 | 单工具调用 | 调用前/后 | 仅当次工具失败 |
| On-the-loop L3 | 系统层级 | 事后 | 已造成影响 |
| Dry-Run Harness | 完整 plan | 执行前 | 零影响回退 |
适用场景：生产环境部署（数据库迁移、上线发布、计费动作）；不可逆 / 高代价动作（删除资源、发送邮件、转账）；Debug 与回归验证。
核心论断：Dry-Run 不是"让 Agent 慢一点"，而是 把"问责面"从结果前移到 plan——一旦 plan 通过审批，执行失败的责任被明确（要么是模拟器不准、要么是执行器 bug，不再是 Agent 推理失误）。
实现要点：模拟器必须对 Agent 透明——Agent 不知道自己在 dry-run，否则会"演戏给审查看"；Checker 必须独立于产生 plan 的 Agent，避免自洽陷阱；审批 UI 要让人能一眼看出 diff。
2.6 框架：max_output_tokens 三层恢复机制（charrli 源码解析）
核心思想：模型输出被截断（stop_reason = 'max_output_tokens'）不应直接 surface 错误，而应通过分层恢复让回合继续。
| 层级 | 动作 | 上限 | 实施要点 |
|---|---|---|---|
| L1 Token 升级 | 默认 8K 上限 → 升到 64K，重发同一请求 | 一次 | 仅在使用默认 8K 时触发 |
| L2 多轮恢复 | 注入恢复消息，要求模型从中断处继续 | 最多 3 次 | 措辞："Resume directly — no apology, no recap" |
| L3 放弃 | surface 错误 | — | 3 次恢复后仍截断 |
恢复消息措辞要点：禁止道歉（避免浪费 token 在 "Sorry for the cutoff..."）；禁止 recap（避免重复之前已说过的内容）；提示拆小任务（防止再次截断）。
transition 字段把恢复过程做成可断言的状态机：测试可以直接断言"这次循环因 max_tokens 恢复继续"，比传统"看消息内容判断"更稳。
模型降级 tombstone 容错：当主模型过载时，为已 yield 的 assistant 消息生成 tombstone（告知 UI 移除）→ 清空消息和工具结果 → 切换 fallback 模型重试 → 如有 thinking 签名（模型绑定），strip 签名块防止 400 错误。
第三章 演化方向
3.1 演化规律：Harness 动态减重
核心论断（12）：
Harness 里的每个组件，都编码了一个模型自己做不到的假设——而这些假设，会随着模型能力的提升逐渐失效。
演化模型：
新模型发布 → 审视整套 Harness → 找出不再是承重墙的组件 → 删除
组件存在的前提 = 模型做不到的假设
假设失效 → 组件变成冗余 → 增加系统复杂度 → 降低效率实例：
| 组件 | 历史必要性 | 当前状态 |
|---|---|---|
| Sprint 分解 | Opus 4.5 必要 | Opus 4.6 可删 |
| Context Reset | 早期模型必要 | Opus 4.5+ 可删 |
| Context Slice 精细管理 | 短窗口模型必要 | 长上下文模型可粗放 |
| AGENTS.md 大量约束 | 弱模型必要 | 强模型只需地图模式 |
| Compaction 摘要策略 | 长任务必要 | 大窗口模型可减少 |
反向不变的组件（18）：Evaluator 永远去不掉——独立评估的需求边界会随模型移动，但边界本身不会消失。
评估器的价值取决于任务是否处于当前模型独立可靠完成的边界之外。这个边界会随模型能力移动，但边界本身不会消失。
第一章 §1.1 的五大根本挑战（状态持久性、目标一致性、行动可验证性、熵增抑制、人机边界）每一条都不能靠"更强模型"消除，构成了 Harness 不可减重的核心承重墙。
3.2 框架：Harness 减重诊断法
核心思想：每次模型版本升级，做一次 Harness 减重诊断。
Step 1：列出当前 Harness 的所有组件
↓
Step 2：对每个组件回答："它在防止什么模型缺陷？"
↓
Step 3：测试新模型是否还有这个缺陷
↓
Step 4：如果缺陷消失 → 标记为"待删除"
↓
Step 5：分阶段移除，观察是否有回退
↓
Step 6：把"曾经必要但已删除"的组件存档（不删代码，备查）典型可减重项：上下文压缩策略（长窗口模型出现后）；Sprint 强制分解（推理链变长后）；Context Reset 触发（Context Anxiety 消失后）；工具调用重试机制（工具调用稳定后）；AGENTS.md 详细规则（in-context learning 改善后）。
不应减重的组件（对应五大根本挑战）：独立 Evaluator（自评偏差是根本性的）；状态持久化（context window 不可能无限大）；权限边界与凭证隔离（安全不能依赖模型不作恶）；熵增抑制（不会因模型变强而自动消失）；人机交接点（"目的地"永远是人的责任）。
注意事项：减重必须有回退机制；一次只减一个组件，不要批量删；记录每次减重的前后对照数据。
对工程师工作内容的暗示：新模型发布时，Harness Engineer 的第一件事是找哪些组件可以删，而不是"加新功能"——删除是演化的常态动作。
3.3 协同演化的双刃剑
核心论断（07）：
有用的框架原语被发现 → 加进框架 → 训练下一代模型 → 模型在这些框架里越来越强 → 发现新原语。但这种协同演化有个副作用：泛化能力会变差。
正循环（好的一面）：Harness 原语成为训练数据的一部分；模型在原语对应的能力上越来越强；反过来催生新原语；整个生态共同演化。
副作用（坏的一面）：模型过度拟合训练时用的 Harness；换一种工具逻辑就性能下滑；最适合你任务的 Harness ≠ 模型后训练时用的 Harness。
关键案例：
| 案例 | 现象 | 启示 |
|---|---|---|
| Codex-5.3 泛化问题（07） | 换一种补丁应用方式，模型性能直接下滑 | 模型与训练时 Harness 深度耦合 |
| Opus 在 Claude Code Harness 下表现（05） | Opus 在 Claude Code Harness 下的得分远低于在其他 Harness 下的得分 | "最好的 Harness 不一定是模型默认的那个" |
对选型的指导（05）：the best harness for your task is not necessarily the one a model was post-trained with——为你的任务选择 Harness 时，不要被模型的默认 Harness 束缚。
与失效模式的呼应：协同演化副作用与第一章失效模式同根——都是"Harness 设计假设的失效"。但失效模式的应对在反馈机制（第二章），协同演化的应对在稳定抽象层（下一节 Meta-Harness）。
3.4 Meta-Harness 的稳定抽象哲学
核心论断（30）：
几乎所有 Agent 框架都在犯同一个错误：把模型当前的能力缺陷，硬编码成了系统永久性的架构设计。
典型的"补丁固化"案例：
| 模型缺陷 | 框架做法 | 真实身份 |
|---|---|---|
| 模型不会规划 | 加固定 DAG 步骤拆解 | 这是补丁，不是架构 |
| 模型记不住长上下文 | 加向量记忆检索模块 | 这是对局限的妥协 |
| 模型调工具容易出错 | 加多层校验重试路由 | 这是保护机制 |
风险：模型能力是指数级进化的——你花几个月打磨的"完美框架"，可能一次版本升级就完全过时，反而成为限制模型能力的性能瓶颈。
Anthropic 的解答：Meta-Harness 三层架构：
应用层：Agent 业务逻辑
↓
Session（执行事实流） ← append-only 不可变事件日志
Harness（调度脑干） ← 无状态、可热替换、标准接口
Sandbox（可插拔执行） ← 大脑与手解耦
↓
基础设施层：工具 / MCP 服务 / Vault三个关键设计原则：
- Session 不是 context window：是 append-only 的不可变事件日志。可查询、可回放、可恢复、可重组。即使上下文窗口被压缩，原始执行事实永远存在——这是"事实流 vs 摘要流"的根本区别。
- Harness 无状态 + 可热替换：不保存任何会话状态，只从 Session 日志查询。标准接口
execute(name, input) → string。模型变强了 → 直接换一个更简单的 harness → 其他部分完全不用动。 - Sandbox 与大脑完全解耦：大脑（Claude 模型 + Harness 调度层）只负责决策；手（Sandbox + 工具 + MCP 服务）只负责执行。Sandbox 独立、可共享、可传递、懒加载。
核心承诺：不承诺 harness 具体长什么样，只承诺几类长期稳定的接口。Anthropic 的赌注：我们不相信今天的 Agent Harness 会是最终形态，所以我们优先投资于稳定接口，而不是一次性的最优实现。
性能数据：Sandbox 懒加载改造后，p50 首 Token 延迟降低 60%、p95 延迟降低 90%+。原来的瓶颈不是模型推理，而是预启动整个执行环境的开销。
凭证隔离架构（安全升级）：
Claude 模型（只看到代理凭证，看不到真实密钥）
↓
MCP Proxy（Session Token 验证）
↓
Vault（存储真实 Git Token / API Key）安全不建立在"模型不会做什么"的假设上，而是建立在系统架构的权限隔离上。对应新型安全威胁——Tool Poisoning Attacks（恶意指令藏在 MCP 工具描述里，对用户不可见，对模型可见）：模型即使被诱导调用工具，也拿不到敏感凭证。权限模型升级：必须从静态"可以/不可以"升级为动态"在什么条件下可以、到什么上限可以、需要人类确认后才可以"——对应 Allow / Deny / Ask 三级。
3.5 框架：In-the-loop → On-the-loop → Meta-Harness 升级阶梯
| 阶段 | 工程师做什么 | 来源 |
|---|---|---|
| L0：人工调试 | 看到错就改 agent 输出 | 22 |
| L1：规则化 | 错了把规则写进 AGENTS.md | 16、Hashimoto |
| L2：机械化 | 错了把规则做成 Linter / Hook | 16、OpenAI 路线 |
| L3：平台化 | 系统化反馈循环（Code Review Agent / Eval 平台） | 22 |
| L4：Meta-Harness 化 | 设计稳定抽象层，不固化模型暂时缺陷 | 30 |
各层级的核心动作：L0 → L1 把一次性错误变成永久规则；L1 → L2 把文本规则变成机械检测；L2 → L3 把单点检测变成系统反馈；L3 → L4 把当前实现变成稳定接口。
为什么 L4 最难：需要预判哪些是稳定的、哪些是暂时的；需要管理层支持长期工程投入；需要承认"今天的最优实现是明天的技术债"。
3.6 模型"长出手脚"与人的责任不可吸收
核心论断（17）：
随着模型能力的持续增强，上下文窗口越来越大，记忆能力不断提升，推理链条越来越长，模型正在自己长出手脚。今天需要外部搭建的工具调用、上下文管理、反馈循环、记忆系统，模型正在一项一项地内化。外面的这套脚手架正在变薄。
当前内化进程：上下文窗口越来越大 → Context Slice 精细管理需求下降；记忆能力提升 → 外部记忆系统可减重；推理链条变长 → 部分编排逻辑可省略；工具调用准确率提升 → 多层校验重试可简化。
但有些事永远不变（17 的关键转折）：
即便模型吸收了所有的工具和流程，有一件事它永远无法自己生成：目的地。去哪里，为什么去，到了之后怎么判断值不值，这些关于方向、意义和价值的问题，永远是人的责任。模型越强，这个责任越重。
"目的地不可吸收"清单：方向（去哪里）、意义（为什么去）、价值判断（到了之后怎么判断值不值）、品味（什么是好的、对的、值得做的）。
双层结构（17）：
| 群体 | 在 AI 时代的位置 |
|---|---|
| 顶尖驾驶员 | 产出最优秀作品；竞争壁垒是品味、判断力、创造性 |
| 大多数人 | 享受 AI 能力提升，不需要成为高阶驾驶者 |
Harnessability（可 Harness 度）（22）：一个系统天然有多容易被 agent 驯化——是 agent 时代的关键变量。
| 高 Harnessability | 低 Harnessability |
|---|---|
| 强类型、测试完备、边界清晰 | 弱类型、测试少、模块耦合 |
| 文档版本化、运行时可观测 | 文档散落、黑盒难诊断 |
| 知识在仓库 | 知识在人脑/Slack |
工程基础设施质量已不只是"工程素养"问题，而是直接决定 agent 能在系统上走多远。棕地项目的 Harnessability 通常较低——这是为什么所有公开成功案例都是绿地项目。
3.7 Skills / SkillHub：跨 Harness 流通
核心思想（17）：基于自然语言描述的 Skills 可以跨框架复用，可能成为 AI 时代的"应用商店"。
Skills 定义：大模型能直接读懂的、基于文本描述的能力单元——告诉模型"这个工具是什么、能干什么、怎么调用"。
| 维度 | 传统 API | Skills |
|---|---|---|
| 描述方式 | 精确参数、严格调用格式 | 自然语言描述 |
| 调用主体 | 编程语言绑定 | 模型可理解 |
| 跨平台 | 需要适配 | 跨框架通用 |
SkillHub 的产品形态：为 Harness 时代搭建的 Skills 流通平台——让能力可沉淀、可复用、可跨框架共享。
OMC 两层 YAML 作为 Skills 流通的雏形基础设施：OMC 已经把 Skills 从"prompt 模板"升级到"两层 YAML 自动注入"——
- 用户级
~/.omc/skills/（跨项目复用，个人习惯、通用工作流） - 项目级
.omc/skills/（项目特定规范，团队共享） - YAML 字段：
name/description/trigger（manual/auto）/inject_to（orchestrator/all）/content - 框架按触发条件自动注入对应 Agent，不需要手动 prompt
意义：这是 17 提出的 Skills 概念走向"可版本管理 + 可触发 + 可定向注入"的产品化雏形。它还不是 SkillHub（仍局限在 OMC 框架内），但提供了 Skills 标准化的最小可行模板。距离真正 SkillHub 还差：跨框架兼容（OMC 强绑定 Claude Code）、分发机制、激励模型。
开放性问题：SkillHub 是否能成为现实，取决于标准化程度和激励机制；公司是否愿意把内部 Skills 开放（知识产权与竞争优势的权衡）；跨 Harness 兼容性是否能保持。
3.8 Heuristic Learning：梯度之外的反向通道
核心论断（33，翁家翌 2026-05-08）：
当 coding agent 足够强，AI 不必把经验压进神经网络权重，而是可以通过自主写代码、跑测试、看回放、改逻辑的循环，"养"出一套 Heuristic System（HS）——纯 Python 程序化策略。经验被写进代码、测试、日志和回放，变成可阅读、可修改、可复查、可审计的软件系统。
HL vs Deep RL 关键对照：
| 维度 | Heuristic Learning | Deep RL |
|---|---|---|
| 策略形式 | 规则、状态机、控制器、宏动作的代码 | 神经网络参数 |
| 状态形式 | 显式变量、检测器、缓存 | 网络可读的观测向量 |
| 反馈形式 | 测试、日志、回放都是有效信号 | 主要依赖固定奖励函数 |
| 记忆形式 | 显式存储试验、摘要、失败原因、版本 diff | on-policy 几乎无；off-policy 依赖 replay buffer |
| 更新方式 | coding agent 编辑代码 / 配置 / 记忆 | 反向传播 + 梯度更新 |
HL 改写灾难性遗忘的性质：Deep RL 灾难性遗忘是结构性的（权重被冲掉），难以根治；HL 灾难性遗忘是工程性的（新规则破坏旧场景）——有现成工具链：回归测试、版本 diff、固定种子回放、golden trace。HL 把"如何更新参数"这个数学问题，改写成"如何维护一套不断吸收反馈的软件系统"这个工程问题——后者未必更容易，但更接近人类已有的能力边界。
HL 表达力上限（必须正视）：Montezuma's Revenge 反例：Codex 拿到 400 分但策略文件是 86 个动作的硬编码序列、对应 1769 个环境步——背了一条固定路线。普通程序策略本质是"看到什么状态就做什么动作"的反应式逻辑，难以处理严格动作时序、从中间状态接续计划、长视野规划。HL 不能完成神经网络能做的所有事情——尤其在复杂感知和长视野泛化上。
HL 维护循环九步法（翁家翌 Breakout 从 99 分到 864 满分的关键转折）：
1. 探测动作和观测 → 2. 写状态检测器 → 3. 写策略 → 4. 跑完整 episode
→ 5. 记录 trials.jsonl 和 summary.csv → 6. 生成视频或曲线
→ 7. 检查失败模式 → 8. 修改策略 → 9. 简化代码 + 跑回归 → 回到 4为什么"直接交 policy.py"失败：低分本身不提供任何信息——动作语义、状态检测、评估流程、策略结构都可能是问题。必须把这些维度全部暴露成显式产物，agent 才能定位问题。
HL 与 Harness 工程的本质关系：HL 把 Harness Engineering 从"为 Agent 搭脚手架"扩展到"让 Agent 维护自己的脚手架"。Coding Agent 既是 Harness 的使用者、也是 Harness 内策略代码的维护者——这是 Harness 演化方向上的一条反向通道：不是 Harness 内化进模型，而是模型外化为可读代码。
HL 落地的成本陷阱（翁家翌冷静划界）：Atari57 中位 HNS 0.83 看起来与 PPO 0.80 打成平手，但 PPO 总成本透明（GPU + 数据），HL 总成本目前是黑箱（Token + 工程师审查 + 失败迭代 + 环境步）。任何 HL 落地实验必须先建立完整成本模型，否则会被"看起来很美"误导。
适用场景：安全规则库、漏洞 payload 模板、误报抑制规则等"规则+测试+回放"型场景；CI 阶段的轻量化 AI 测试策略；合规、监管、责任追溯敏感场景——可审计性比模型能力更稀缺。
关键洞察（跨章融合）
跨多源融合后的发现。
五大根本挑战是 Harness 存在的"宪法"——22 提出的五大挑战每一条都不能靠"换更强模型"解决，构成了 Harness 不可被模型吸收的核心理由。这也是减重诊断的"反向不变项"。
失效模式有"时效性"——并非永恒——Context Anxiety 在 Sonnet 4.5 严重，Opus 4.5 基本消除。每次模型升级后，团队必做的"诊断动作"是审视哪些失效模式已经不再发生。别把对当前模型缺陷的应对固化成永久架构（呼应 30 的"补丁不该变架构"）。
40% 和 60% 不是两个数据，是同一现象的两个阶段——40% 是"质量开始下降"，60% 是"明显变差"。工程实施：40% 是触发主动总结/交接的时机，60% 是强制 Context Reset 的警戒线。
反馈系统的成熟度可以用"四象限覆盖率"测量——22 的 2×2 矩阵强迫团队对照检查四个象限里投入了几个。大多数团队只覆盖一个（Sensors × Computational：写测试）。
熵增是 Agent 时代的"隐性税"——OpenAI 每周 20% 时间清理 AI slop 是这个税的真实价格。Harness 的真正价值之一是抑制 agent 放大的系统噪声——这是它与简单框架最本质的区别。
In-the-loop → On-the-loop → Meta-Harness 是工程师在 Agent 时代的核心升级——大多数团队卡在 L0；On-the-loop 的复利效应被严重低估；L4 Meta-Harness 化要求"承认今天的最优实现是明天的技术债"。
Evaluator 独立性是 GAN 式架构的真正灵魂——核心不是"分工"，而是 Evaluator 必须独立于 Generator。这同样适用于其他场景：写 PRD 的人不能验收、做需求的人不能写 acceptance criteria。
Harness 是会移动的边界，不会消失但会重塑——17 说"脚手架变薄"（减重）、22 说"五大挑战不消失"（承重墙）、30 说"投资稳定接口"（抽象层调整）——三个说法不矛盾：Harness 的具体内容会变，但 Harness 的位置不会消失。类比：操作系统的具体功能在变（图形界面、虚拟内存、容器），但 OS 这个层级永远存在。
协同演化的副作用是"路径依赖"——模型在特定 Harness 下训练，换 Harness 就掉分。解药 1：Anthropic 的 Meta-Harness 三层架构（稳定接口）；解药 2：Skills/SkillHub 跨框架抽象层。但路径依赖的力量很大，能否真正解耦仍是开放问题。
"补丁固化成架构"是 Agent 工程的最大风险——30 把这个问题点得最透。工程师在 Agent 时代的反直觉技能：学会删自己写过的代码。
Harnessability 把"工程素养"升级为"基础设施差异"——强类型、测试、文档、可观测性，过去是"加分项"，现在是"决定 Agent 能在系统上走多远"的硬约束。这暗示了未来工程能力的两极分化。
"模型长出手脚" vs "人的责任不可吸收"的精准切分——会被吸收：工具调用、上下文管理、反馈循环、记忆系统（"如何做"）；不会被吸收：目的地、意义、价值判断、品味（"做什么"）。工程上：在"如何做"上少投资长期方案，在"做什么"上多投资团队能力。
安全模型从训练时约束升级到运行时架构——传统是"训练模型不要做坏事"，Anthropic Meta-Harness 是"模型即使想做坏事也拿不到凭证"。启示：靠模型不作恶的产品架构，在模型变强后会非常脆弱。
Coding Agent 是 Harness 演化的反向通道——17、30、22 共同的演化方向是 Harness 变薄、被模型吸收；33（翁家翌 HL）给出反方向通道：经验从权重外化为代码、测试、回放。两个方向不矛盾：模型能自己处理 → 外部脚手架变薄；模型能自己维护脚手架代码 → 脚手架可以变厚但人不维护。
HL 把"灾难性遗忘"从模型问题改写为工程问题——Deep RL 灾难性遗忘是结构性的，HL 灾难性遗忘是工程性的，有现成工具链（回归测试、版本 diff、golden trace）。对安全/合规/金融等高责任追溯场景：HL 让"AI 决策"能进入正常的代码评审 + CI 拦截流程，是合规产品的杀手级差异化。
案例库（精选）
案例 1：Anthropic 三 Agent vs Solo 对比（12）
同一编程任务（游戏开发）的两种实现路线：Solo 结果游戏能启动但连线断裂、界面无提示；三 Agent 结果正常游玩 + AI 关卡生成 + 精灵动画 + 音效。成本：三 Agent 是 Solo 的 20x，但从"不能用"跨越到"能用"。失效模式角度：Solo 失败的不是"代码写错"，而是 Generator 自评虚高导致"看起来完成了但核心交互断裂"。
案例 2：Anthropic Sonnet 4.5 Context Anxiety（12、18）
上下文快填满时倾向于提前收工，哪怕任务未完成。Opus 4.5+ 已基本消除此行为。演化角度：失效模式不是永恒的——Harness 组件随模型迭代会变成冗余，需要定期审视哪些可以删（→ §3.2 减重诊断）。
案例 3：OpenAI 自定义 Linter——错误消息嵌修复指令（12）
Linter 不只是"指出错误"，是"教 Agent 怎么改"。配套：业务域依赖方向固定（Types → Config → Repo → Service → Runtime → UI），违反 PR 自动拦截。启发：好的 Sensor 不只是 pass/fail，还应该包含修复指引——把 Sensor 升级成 in-context learning 的高质量例子。
案例 4：OpenAI 每周 20% 时间清理 AI slop（22）
百万行代码项目的熵增管理：初期人工清理"AI slop"占每周约 20% 时间。系统化方案：documentation consistency agents / refactor agents / architectural enforcement。启发：熵增是隐性税；不主动清理，项目会被自己生成的代码淹死。
案例 5：MercadoLibre 独立 Code Review Agent（16）
2 万开发者、数千仓库的质量保障。独立 review agent 接入 CI，对所有 PR（人写 + AI 写）做自动分析。收益：人类 reviewer 更聚焦高层设计与架构决策；更早发现 bug；质量控制能力随 PR 数量扩展，而非依赖 reviewer 人数。启发：Code Review Agent 是反馈系统的工业化形态。
案例 6：Codex-5.3 泛化问题 / Opus 在 Claude Code Harness 下反常表现（07、05）
Codex-5.3 换一种补丁应用方式，模型性能直接下滑；Opus 在 Claude Code Harness 下得分远低于其他 Harness。演化角度：协同演化副作用已经显现——模型与训练时 Harness 深度耦合。选型时不要假设"用官方框架就是最优"。
案例 7：Anthropic Meta-Harness 三层架构与凭证隔离（30）
Session（执行事实流）/ Harness（无状态调度脑干）/ Sandbox（可插拔执行）。Sandbox 懒加载改造后，p50 首 Token 延迟降低 60%、p95 延迟降低 90%+。凭证隔离：Claude 模型 → MCP Proxy → Vault，模型全程看不到明文密钥。启发：把"补丁不该变架构"作为工程哲学落地；安全从"赌模型不作恶"升级到"系统架构隔离"。
案例 8：Tool Poisoning Attacks（22）
Invariant Labs 2025.04 披露：恶意指令可藏在 MCP 工具描述里（对用户不可见，对模型可见），诱导 agent 执行未授权操作。进阶威胁：通过不可信 MCP server 联动可信 WhatsApp MCP 实现数据外流。启发：攻击目标从数据变成 Agency；权限模型必须从静态升级为动态条件式判断。
案例 9：Breakout HL 实验——99→864 满分演进（33）
翁家翌业余维护 EnvPool 时发现"每次都跑神经网络太贵"，启动 HL 实验。RAM 版本分数演进：baseline 99 分 → 加隧道偏移 387 → 加循环打破 507 → 加 fast_low_ball_lead_steps=3 839 分 → 后期偏移释放 864 满分。首次满分在第 81 个 episode、累计 150 万环境步。演化角度：HL 让"经验沉淀为可读代码 + 测试 + 回放"成为可行——Coding Agent 是这种沉淀的维护通道。
案例 10：Atari57 批量验证——HL 与 PPO 打成平手（33）
57 款游戏 × 2 种观测模式 × 3 次重复 = 342 条无人值守搜索轨迹。最佳输入聚合中位 HNS 0.83（OpenAI Baselines PPO2: 0.80; CleanRL EnvPool PPO: 0.98）。能力分布不均匀：几何结构清晰类（Breakout、Boxing）两者都强；有明确规则类（Asterix、Tennis）HL 反而更强；节奏快、模式复杂类（Atlantis、VideoPinball）PPO 仍碾压。启发：HL 不是 Deep RL 替代品，是互补的第二条通道——选哪条取决于任务特征。
案例 11：oh-my-claudecode（OMC）28.3k Stars——Harness 作为独立产品形态
建在 Claude Code 之上的多智能体编排框架，没有训练新模型，只做 Harness 工程。19 个专业化 Agent × 5 条功能泳道；两层 Skill 系统（用户级 + 项目级 YAML 自动注入）；Context Reset 编码为框架默认行为（子 Agent context > 40% 自动交接）；声称综合节省 30-50% token。
- 印证 §1.2 40% 阈值作为工程实施触发点的可行性
- 印证 §2.2 GAN 角色独立性——独立性不仅指 prompt 分离，更指实例与上下文的完全隔离
- 印证 §3.7 Skills/SkillHub——两层 YAML
description + trigger + inject_to三字段是 Skills 标准化的最小可行模板 - 平台路径依赖警示：OMC macOS only + Claude Code 强绑定，是协同演化副作用的产品级表现——能力越深、绑定越紧
待探索问题
- 失效模式的诊断框架：当 Agent 出问题时，如何快速判断是哪类失效模式？能否给出"失效模式决策树"？
- 2×2 矩阵的量化测量：能否给出覆盖率、强度、响应时间等量化指标？
- Evaluator 的失效模式：Evaluator 本身会不会过度严苛？Evaluator 与 Generator 共谋的可能性？
- 熵增的早期预警指标：AI slop 累积是否有可观测信号？在"清理速度被生成速度反超"前能否预警？
- Context Reset 的代价：频繁 Context Reset 会损失什么？30 秒冷启动续航的边界在哪？
- Harness 最终会变成什么形态：完全被模型吸收？保留为薄层抽象？上升为 AgentOS 内核？
- 协同演化的解耦是否可能：Codex-5.3 案例说明 Harness 解耦很难。Anthropic Meta-Harness 是否能真正解决，还是演变成"换一种耦合方式"？
- Skills/SkillHub 能否成立：跨公司、跨框架的能力流通有技术可行性吗？商业模式是什么？激励谁开放 Skills？
- 棕地项目的 Harnessability 提升路径：哪些改造能立即受益？投入产出比怎么测量？
- 新型安全威胁的演进方向：Tool Poisoning 之后还有什么？Agency 攻击的防御边界在哪？
- "目的地"问题的可工程化：即使"目的地是人的责任"，能否做工程化辅助（如自动生成多个备选目的地让人选择）？
来源索引
| # | 标题 | 来源标识 | 收录日期 | 贡献章节 |
|---|---|---|---|---|
| 1 | 05-Harness-Engineering-AI-Agent架构方法论 | 已归档-05-Harness-Engineering-AI-Agent架构方法论-2026-04-13.md | 2026-05-12 | §1.2.3、§3.3、案例 4/6 |
| 2 | 07-Agent-Harness技术原语拆解 | 已归档-07-Agent-Harness技术原语拆解-2026-04-03.md | 2026-05-12 | §1.2.3、§3.3、案例 6 |
| 3 | 12-Harness-Engineering实战-百万行代码与动态演化 | 已归档-12-Harness-Engineering实战-百万行代码与动态演化-2026-04-03.md | 2026-05-12 | §1.2.1/§1.2.2、§1.3、§2.2/§2.4、§3.1/§3.2、案例 1/2/3 |
| 4 | 16-Coding-Agent-Harness-规模化落地的四大杠杆与反馈闭环 | 已归档-16-Coding-Agent-Harness-规模化落地的四大杠杆与反馈闭环-2026-04-10.md | 2026-05-12 | §1.2.3/§1.2.5、§2.3、案例 5 |
| 5 | 17-汤道生-AI正式进入Harness时代-发动机线束驾驶员三角框架 | 已归档-17-汤道生-AI正式进入Harness时代-发动机线束驾驶员三角框架-2026-04-13.md | 2026-05-12 | §1.2.2、§3.6、§3.7 |
| 6 | 18-Harness三层结构-知识约束反馈 | 已归档-18-Harness三层结构-知识约束反馈-2026-04-03.md | 2026-05-12 | §1.2.1/§1.2.2、§2.2/§2.4、§3.1 |
| 7 | 22-HarnessEngineering深度解析-Agent治理时代的系统工程学 | 已归档-22-HarnessEngineering深度解析-Agent治理时代的系统工程学-2026-04-13.md | 2026-05-12 | §1.1/§1.2/§1.3、§2.1/§2.2/§2.4、§3.5/§3.6、案例 4/8 |
| 8 | 26-Agent等于Model加Harness-30年软件工程演进与六大组件解析 | 已归档-26-Agent等于Model加Harness-30年软件工程演进与六大组件解析-2026-04-14.md | 2026-05-12 | §1.1、§1.2.5、§3.4 |
| 9 | 30-Anthropic-AgentOS-Meta-Harness三层架构 | 已归档-30-Anthropic-AgentOS-Meta-Harness三层架构-停止写框架转向Agent基础设施-2026-04-16.md | 2026-05-12 | §3.4、§3.5、案例 7 |
| 10 | 33-Heuristic-Learning范式假设-翁家翌让Codex养策略代码 | 综述/33-Heuristic-Learning范式假设-2026-05-09.md | 2026-05-15 | §3.8、案例 9/10 |
| 11 | oh-my-claudecode 多智能体编排框架深度分析 | 产品案例研究（Yeachan-Heo/oh-my-claudecode） | 2026-05-18 | §1.2.3、§1.2.4、§2.2、§2.4、§3.7、案例 11 |
| 12 | All Agentic Architectures（Dry-Run 部分） | FareedKhan-dev/all-agentic-architectures | 2026-05-19 | §2.5 |
| 13 | 技术教科书：顶级开发团队设计的 Harness 工程项目源码 | charrli，2026-05-19 | 2026-05-19 | §1.2.4（AutoDream）、§2.6（max_output_tokens 三层恢复） |
演进记录
| 日期 | 版本 | 变更摘要 |
|---|---|---|
| 2026-05-12 | v0.1（原失效模式） | 首次构建：由 7 篇源文件合成。建立失效模式系统分类（五大根本挑战、Context Anxiety、自评偏差、40%/60% 阈值、熵增）和反馈机制完整框架（2×2 矩阵、GAN 三角色、Hooks、Context Reset、On-the-loop 升级路径）。 |
| 2026-05-12 | v0.1（原演化） | 首次构建：由 7 篇源文件合成。建立 Harness 演化完整理论框架——动态演化规律、协同演化双刃剑、Meta-Harness 稳定抽象哲学、模型内化趋势、AgentOS 层级关系、Harnessability、人的责任不可吸收。提出五阶段升级阶梯、Harness 减重诊断法、凭证隔离架构。 |
| 2026-05-15 | v0.2（原演化） | 纳入翁家翌 Heuristic Learning 范式假设：HL vs Deep RL 对照、System 1/2 分工、HL 维护循环九步法、HL 总成本测算清单、Breakout 99→864 满分演进、Atari57 中位 HNS 0.83、Montezuma 反例。 |
| 2026-05-18 | v0.2/v0.3 | 两侧分别纳入 OMC 多智能体编排框架案例：失效侧补充 Context Reset 与角色独立的工程化默认；演化侧补充 OMC 28.3k Stars 作为 Harness 即产品的市场验证 + 两层 YAML Skill 系统作为 SkillHub 雏形。 |
| 2026-05-19 | v0.3（原失效模式） | 纳入 FareedKhan-dev/all-agentic-architectures：新增 Dry-Run Harness 安全模式；纳入 charrli 源码解析：新增 AutoDream 后台熵治理、max_output_tokens 三层恢复机制。 |
| 2026-05-20 | v0.4 | 合并：把"Harness 失效模式与反馈机制"v0.3 与"Harness 演化与未来形态"v0.3 合并为本文件，按"失效模式 → 反馈机制 → 演化方向"三章重新组织。去重项：Context Anxiety/40%/60% 阈值集中在 §1.2；Skills/SkillHub 集中在 §3.7；协同演化在第三章 §3.3 给出对策。保留差异化：失效侧的五大根本挑战、五种典型故障、2×2 矩阵、GAN 三角色、Dry-Run；演化侧的减重诊断、协同演化双刃剑、HL 反向通道、SkillHub。来源索引合并去重至 13 条，演进记录合并去重。 |
| 2026-05-20 | v0.4.1 | 由 /route-knowledge-pm 路由触发（Anthropic CU 最佳实践 2026-05-13）：§1.2.1 Context Anxiety 新增 CU 场景实测数据（1,000-1,800 token/张截图、100 步填满 200K window）；§2.4 Context Reset 新增 CU 专用 LLM-based Compaction 三层策略（Cache-aware 滚动缓冲 / 8 段结构化 COMPACT_PROMPT / 服务端 Compaction beta compact-2026-01-12）。来源数 13 → 14 |