Appearance
Harness Engineering — Advanced Topics
理论框架在真实世界中的检验：当 Guides × Sensors 控制论框架被产品级实现验证时暴露的结构性裂缝，以及 Meta-Harness 抽象与现有体系的深层矛盾。
Guides × Sensors 框架的产品级验证
Birgitta Böckeler 在 Martin Fowler 博客上提出了 Guides × Sensors 控制论框架——一个 2×2 矩阵（前馈/反馈 × 计算性/推理性），将 Harness Engineering 从工程直觉升级为系统分类学。
但当这个理论框架被一个完整的产品级开源实现——claude-code-harness v4.2 "Hokage"（MIT 许可证，全部代码和配置可读，已迭代至 v4.2）——全量实现后，框架和产品互相暴露了五个结构性张力。
张力 1：Advisor Strategy 装不进 2×2 矩阵
Böckeler 的预设： 推理性传感器（如 LLM-as-judge）昂贵、不是每次都跑，所以放在反馈侧。
产品级实现的现实： v4.2 引入了 Advisor agent，它既不在每次提交跑（不像 reviewer），也不预先注入（不像 skills），而是按三类触发条件被动唤起：
- 高风险任务的 preflight consultation
- 重复失败的 corrective consultation
- 检测到 plateau 时的 escalation consultation
这是一种条件激活的推理性控制——既不算前馈（行动前注入），也不算标准反馈（行动后审查）。它更像一个**"按需上线的备用推理回路"**。
Böckeler 的矩阵把控制按"何时执行"切了一刀（前/后），但 Advisor 揭示了第三个时间维度：「按条件何时唤起」。框架需要一个新轴：控制的激活策略（always-on / per-commit / conditional / human-summoned）。
张力 2：Guardrail 越严，前馈和反馈的边界越模糊
Böckeler 的清晰二分： 前馈在行动前引导，反馈在行动后纠正。
产品级实现的现实： v4.2 的 R01–R13 共 13 条规则在 PreToolUse hook 层拦截——R06 git push --force 直接 deny，R05 rm -rf 触发 ask，R12 push to main/master 给 warn。
问题是：当一条规则的反应是 "deny"（直接拒绝执行），它到底是前馈还是反馈？
- 从智能体的视角：它没行动就被打回，类似前馈
- 从系统视角：它已经发出了 tool call，被传感器拦截后才回滚——类似反馈
13 条规则的反应严格度形成了前馈/反馈的连续光谱，不是离散象限。当机械化执行做到 hook 层时，这条边界彻底消失了——guardrail engine 同时承担前馈和反馈职责，这恰好是 OpenAI "机械化执行"概念的成熟形态，但 Böckeler 框架没给它留位置。
张力 3：行为 Harness 在 v4.2 里被绕过了，没被解决
Böckeler 的诊断： 三类调控对象中，行为正确性"最弱、是房间里的大象"。
产品级实现的现实： v4.2 看似认真——reviewer agent 的 4 视角（Security/Performance/Quality/Accessibility）、xhigh effort、Plans.md 强制四态状态机（pm:依頼中 → cc:WIP → cc:完了 → pm:確認済）。
但仔细看，这些机制全部是结构性的——4 视角检查"代码是否符合 X 类问题模式"，状态机检查"流程是否走完"。没有任何一个机制能回答"这段代码做对了用户真正想要的事吗"。
闭环里唯一握有"行为是否正确"裁决权的依然是人类——状态从 cc:完了 推进到 pm:確認済 的那一步，没有 harness 替你做。
核心发现： 行为 Harness 不是同维度下的"最弱"项，而是根本不在同一维度——前两类（可维护性、架构适应度）是工程问题，第三类是认识论问题。一个产品级 harness 能做的不是覆盖它，而是为人类的最终判断保留高质量的输入。这其实是 Böckeler 自己说的"将人类输入引导到最重要的地方"——但没强调这是结构性绕过而非渐进解决。
张力 4：Harness 的自我演化压力被框架低估
Böckeler 把 harness 当作主动设计产物——工程师设计反馈回路、选择引导器。
产品级实现的现实： v4.2 的 7 项主要变更（README v4.2 update 表格）逐项归类：
| # | 变更 | 触发源 |
|---|---|---|
| 1 | PreCompact hook 阻止任务被压缩切断 | 上游：Claude Code 2.1.105 新增 PreCompact hook |
| 2 | 改用 monitors/monitors.json 公共 schema | 上游：plugin spec 收紧 |
| 3 | harness sync 双层 guard | 自修：4 次自伤事故修复 |
| 4 | 1 小时 prompt cache opt-in | 上游：CC v2.1.108 新能力 |
| 5 | Reviewer/Advisor 升 xhigh effort | 上游：CC v2.1.111 + Opus 4.7 新能力 |
| 6 | Agent prompts 重调以匹配 Opus 4.7 字面遵循 | 上游：Opus 4.7 语义变化 |
| 7 | R01–R13 重新对齐 CC 2.1.110 hook 协议 | 上游：hook 协议演化 |
6/7 是被动追赶上游，1/7 是修自己的 bug——零项是"harness 主动添加新能力"。 harness 的真实形态是对宿主运行时变化的被动追赶产物——95% 的迭代精力花在"不被宿主升级搞坏"或"修自伤"，几乎没有花在"主动改善能力"。
Böckeler 框架把 harness 当作封闭系统分析，但 harness 真正的成本中心是与宿主（Claude Code）和模型（Opus 4.x）的接口维护。这层在框架里完全不可见。
张力 5：Harness 必然带价值观锁定
Böckeler 的中性预设： Guides 和 Sensors 是技术工具，可移植、可替换。
产品级实现的现实： v4.2 的 CLAUDE.md 硬编码"All responses must be in Japanese"——任何用户装上这个 harness，Claude 立刻切日语回应。这不是 bug，是设计决策。它揭示了：任何成熟的 harness 必然携带其设计者的价值观/约定/语言/审美。
R01–R13 编码了"什么不该做"，5 verb 编码了"什么是合理工作流"，强制日文编码了"谁是预期用户"。装上 v4.2，你接受的不仅是 13 条 guardrail，还接受了"日文为母语""Conventional Commits""GitFlow 分支命名"等一整套日本企业开发文化的隐式假设。
Harnessability 应被扩展： 一个仓库的 harnessability 不仅取决于强类型/模块边界/框架成熟度（技术维度），还取决于仓库的文化约定与可用 harness 的预设是否对齐（社会维度）。
产品验证总结
| 维度 | 框架验证 | 框架补充 | 框架反驳 |
|---|---|---|---|
| 2×2 矩阵 | 四象限可作为分析起点 | 需要加"激活策略"维度 | 前馈/反馈在 hook 层会融合 |
| 三类调控 | 可维护性最成熟 ✓ | 行为 Harness 是结构性绕过 | — |
| Harnessability | 强类型/模块边界 ✓ | 应包含文化对齐维度 | 技术中立性是幻觉 |
| Harness 演化 | 模板会分叉 ✓ | 95% 维护成本在追宿主升级 | 框架低估了被动追赶压力 |
最准确的判断： Böckeler 的框架是一份优秀的体检表，但不是手术台。把一个真实产品放上手术台后，会看到框架没标的解剖结构——尤其是 harness 与宿主、与人类、与文化的三层接口。
Meta-Harness 与现有体系的五个张力
Anthropic 的 "Scaling Managed Agents" 引入了一个新的抽象层次：不再讨论"如何设计好的 harness"，而是追问"如何让 harness 本身成为可替换的基础设施"。这个 Meta-Harness 概念与既有 Harness Engineering 体系存在五处深层张力。
张力 1：Meta-Harness 是否消解了 Harness Engineering 的投入价值？
现有共识： Agent = Model + Harness，工程师应精心设计 harness（AGENTS.md、linter、Sprint 合同）。
Managed Agents 的隐含主张： Harness 是牲畜，应该可替换。投入应放在接口层（session、sandbox 的标准化），而非 harness 细节。
矛盾点： 你花两周打磨 AGENTS.md 和验证闭环，但下个模型发布后这些可能全部过时（Anthropic #4 已有实证：Sonnet → Opus 升级后 context reset 变死重）。那 harness engineering 的 ROI 如何计算？
判断： 两者不矛盾，但作用在不同时间尺度上。Harness engineering 是当前模型的战术优化，meta-harness 是跨模型代际的战略设计。问题是大多数团队只有战术预算。
张力 2：Session 外部存储 vs Context Rot 的笨办法
LangChain 的方案： 在 harness 层解决 context rot——compaction、Ralph Loop、渐进式披露。
Managed Agents 的方案： 别做不可逆决策。把完整事件流存到 session，getEvents() 按需切片取回。
质疑：这是在用存储换智能吗？ 如果模型在 200k token 的事件流中挑选相关切片的能力不够强，这个设计就退化为"全都存、全都丢给模型"——和不做上下文管理没区别。
当前实际情况： Opus 4.6 的 compaction 质量达 84%——说明模型已经能做较好的上下文筛选。但 84% 不是 100%，16% 的信息丢失在长时间任务中可能累积成致命错误。LangChain 的"笨办法"在当前模型能力下可能更稳健，因为它们是确定性的。
张力 3："多大脑、多双手"的认知负担
文章的乐观叙事： "Claude 必须推理多个执行环境并决定将工作发送到哪里"，随着智能扩展，这不再是问题。
现有证据的悲观信号：
- Anthropic #4：Sonnet 4.5 连单容器内的 self-evaluation 都做不好
- HumanLayer："便宜模型做子任务，贵模型做编排"——编排消耗大量认知预算
- Anthropic #6：上下文焦虑在单环境下就存在
核心质疑： 多双手意味着模型需要同时维护多个执行环境的心智模型。这和"上下文焦虑"直接矛盾——模型在单环境下都焦虑，多环境下能不焦虑？文章用 TTFT 数据证明了基础设施收益，但完全没给出多环境下的任务完成率数据。
张力 4：安全边界的转移，而非消除
Managed Agents 的安全方案： 令牌不进沙箱，通过 MCP proxy 和 vault 隔离。
质疑： execute(name, input) → string 本身就是能力入口。如果 Claude 能通过工具调用 provision 新容器、传递任意 input，那攻击面只是从"沙箱内读环境变量"转移到了"说服 harness 路由恶意工具调用"。
文章没有讨论：Harness 层的工具调用审计机制、对 provision({resources}) 的权限限制、大脑传递双手给其他大脑时的信任链。
张力 5：缺失的成本维度
已有成本数据： Anthropic #4：Solo $9 → V1 $200 → V2 $125；YDD："AI 写得快但交付没变"的效率悖论。
Managed Agents 给了什么： TTFT 性能数据，但零成本数据。
质疑： 多大脑 + 多双手 + 持久化 session + MCP proxy + vault = 显著的基础设施和推理成本。如果 meta-harness 的运营成本高于它节省的工程师时间，那它只适用于 Anthropic 自己这个量级的组织。对于中小团队，meta-harness 可能是过度工程。
Meta-Harness 张力总结
Managed Agents 的价值不在具体方案，而在于它标记了 Harness Engineering 演进的方向：从设计 harness 到设计容纳 harness 的系统。但这篇文章比已有文章更"愿景导向"——它展示的是 Anthropic 希望世界变成的样子，而不是世界现在的样子。
Transformative Insight
这些高级话题揭示了一个共同主题：Harness Engineering 的理论框架正在被真实世界的实践拉伸到极限。 理论提供了分类学和语言，但只有在产品级检验中暴露的裂缝（接口维护成本、行为验证的认识论困境、价值观锁定、成本维度缺失），才真正指出了下一代 Harness Engineering 需要攻克的方向。
Related Concepts
- Harness Engineering — Harness Engineering 方法论概述
- Harness Engineering — The Evaluation Problem — 评估问题是整个体系的短板
- Harness Engineering — Implementation Patterns — 不同规模下的实践模式
- AI Agents — AI Agent 系统形态
- Workflow vs Agent — 预定义编排流程与动态 Agent 决策的工程权衡
Open Questions
- 控制的激活策略应该如何分类？ always-on / per-commit / conditional / human-summoned 的连续光谱——框架需要升维吗？
- 当 guardrail engine 同时做前馈和反馈，是否应合并为"运行时控制"这个第三类？
- Harness 的接口维护成本如何衡量？ v4.2 显示 95% 的迭代花在追上游——这是否是所有成熟 harness 的常态？
- 行为 Harness 的"结构性绕过"是否应该被正式承认为一种合法策略？
- harness 的价值观锁定如何披露？ 是否应有 "Harness Manifesto" 明示隐含的工作文化假设？
- Meta-Harness 的运营成本结构是什么？ 在什么规模之下它是过度工程？
- 跨模型可移植的 harness 是否可能？ 还是说每个模型提供商最终都会捆绑自己的 harness？