Harness Engineering 实战

核心公式

Agent 产出质量 = 模型能力 × 设计水平

模型能力你左右不了（用现成的 SOTA），但设计水平完全是工程问题。这门课最有冲击力的一个数据：

只改 Harness（system prompt + 工具 + middleware Hooks），模型一行没动，+13.7pp。作为对比，换一个更强的模型只 +6.8pp——Harness 工程的收益是换模型的约 2 倍。（课程还提到「Reasoning Sandwich」：xhigh 推理因超时反而掉到 53.9%，high 才是 63.6%——推理强度不是越高越好。）

四大支柱

                Agent 运行时环境（Harness）
    ┌──────────────┬──────────────┬──────────────┬──────────────┐
    ① 代码库即真相源   ② 机械化架构约束   ③ 反馈循环        ④ 熵管理
   声明式知识注入     自动化行为约束     多层反馈循环      系统熵管理

① 代码库即真相源（声明式知识注入）

知识不写在 prompt 里，写在配置文件里：Anthropic 的 CLAUDE.md、OpenAI 的 AGENTS.md。关键不是写得多，而是写成 ~100 行的「行军指南」，不是百科全书——Agent 启动就「知道这个项目长什么样」。

② 机械化架构约束（自动化行为约束）

一句话点透：「CLAUDE.md 是建议，Hooks 是法律」。

• CLAUDE.md 是软约束，模型可以不听
• Hooks 是硬约束：PreToolUse / PostToolUse 生命周期钩子在工具调用前后强制拦截——比如 rm -rf / 直接拦死
• OpenAI Codex 用的是「六层分级约束体系」

③ 反馈循环（多层反馈）

「轮班工程师没有交接记录」就是没有反馈循环。四层反馈：

• 即时反馈：Hooks 在工具调用前后立刻给结果
• 构建反馈：CI/CD 在 PR 上跑
• 再加两层跨会话反馈

④ 熵管理（系统熵管理）

AI 协作有四类特有的「熵增」要对抗：文档漂移 / 架构侵蚀 / 风格不一致 / 重复代码。

五大平台的 Harness 深浅

课程横向对比了 5 个平台的 Harness 设计：

生产部署与数据主权（AI 业务流架构师视角）

Harness 不只在写代码时——把 Agent 跑到生产同样是「驾驭工程」。从「AI 业务流架构师」的视角补一层 ops：

• Local-First 是架构决策，不是偏好：数据主权 / 避免 vendor lock-in / 合规（GDPR、数据安全法、信创物理隔离）——自托管 Agent gateway 是 2026 的关键决策
• 安全边界：自托管的 OpenClaw 控制端口（如 18789）属于「Hooks 是法律」那条铁律的延伸——绝不裸暴露到公网（业界出现过 localhost 鉴权绕过类 CVE，数万实例被扫到）。正确姿势：守护进程化（systemd/launchd）+ 零公网 IP 的安全穿透 + Dashboard 安全直连
• 角色升维：架构师从「工具执行者」变成「业务编排者」——把 130+ 个割裂 SaaS 用 Agent 经 API / 浏览器自动化 / 文件系统 连成一层

部署的具体云厂商/穿透工具命令来自一门纯视频课，材料里未给出，这里只陈述架构原则，不复述未经核实的命令。

价值点

• 理解「模型 × 设计」这个乘法：知道为什么同模型不同人产出差一个量级
• 四大支柱可落地：CLAUDE.md/AGENTS.md（知识）+ Hooks（约束）+ CI（反馈）+ 反熵实践
• 平台选型判断力：深 Harness（Claude Code/Codex）vs 轻 Harness 广覆盖（OpenClaw），按场景选
• 数据驱动：拿 Terminal Bench 52.8%→66.5% 这种实测说话，而不是「感觉变好了」