4.0 KiB
Harness Engineering 的本质拆解
-
Harness Engineering 的本质是用确定性的工程控制系统，把大模型的非确定性输出压缩进可预测的轨道里，让“概率生成”变成“可验收的产出”
-
大模型在系统里只承担两件事：理解意图、把意图翻译成文本（代码/配置/文档），它更像算力与语言编译器，而不是可靠性来源
-
可靠性不来自“更聪明的模型”，而来自外部机制对输出的四类动作：拦截意图、校验结果、拒绝不合格、注入必要上下文
-
最小可运行 Harness 的关键不是生成代码，而是闭环：生成→编译/运行→抓取错误→反馈重写→直到通过，这把一次性聊天改造成可迭代的生产流程
-
第一类硬问题是上下文与遗忘：任务一复杂就会撑爆上下文、目标漂移、前后端混写，本质是模型没有稳定的工作记忆与任务边界
-
对应解法是动态上下文注入与记忆管理：把规则与知识拆成可插拔技能包，按“当前意图”精准装载与卸载，让上下文保持短、准、相关
-
记忆的工程化含义不是“多存点东西”，而是把踩坑与验证过的结论自动提炼成规则沉淀下来，使系统具备跨任务的抗重复犯错能力
-
第二类硬问题是自评幻觉：让模型自己审查等于既当运动员又当裁判，它会用讨好与自洽掩盖逻辑错误，漂亮但不可用
-
对应解法是评估驱动与机械测试：引入独立的、可执行的第三方判定（编译器、单测、端到端 UI 测试、独立 QA Agent），用硬指标决定通过与否
-
质量下限从“模型聪明程度”迁移到“验收机制完备性”，系统真正的生产力来自可重复运行的判定器，而不是一次灵感式输出
-
第三类硬问题是时间维度的熵增：长期运行后模型会为了更快过测试而走捷径，架构漂移、耦合蔓延，最终形成不可维护的腐化代码库
-
对应解法是架构强约束与持续清理：用静态规则提前阻断跨层依赖等结构性违规，再用专职清理机制持续重构、更新文档、回收技术债，对抗代码腐化
-
当系统拥有规划者、执行者、评估者、硬约束钩子、清理机制时，Harness 才从脚本升级为“Agent 操作系统”，长期稳定性来自分工与制衡
-
那些看似“AI 自己写出百万行代码”的魔法，核心不在模型，而在工具与 Harness 组合出来的现实校验、反馈重试、规则约束与持续治理
-
Harness 不是回到古法逐行写代码，而是把工程重心从实现细节迁移到边界、接口、约束、断言与验收标准，编码对象从业务逻辑变成生产流水线
-
Harness 的门槛高于写业务代码的根因在于：它要求你先把“什么算对、什么算好、什么必须禁止”形式化成可执行规则，否则系统会高速产出结构化垃圾
-
Harness 的维护成本来自业务变化：当目标函数变了，你必须同步重写评估器与测试桩，否则闭环会失真并进入死锁或错误优化
-
最大误解之一是指望模型升级解决跑偏，现实规律是无论马多强，没有缰绳都会把车拉进沟里，可靠性必须由外部约束提供
-
最大误解之二是工具越多越好，工具过载会导致选择震荡与时间浪费，工具集应该为评估与执行最小充分，而非堆权限展示强大
-
最大误解之三是把无约束的氛围式开发当工业未来，它只能在无历史负担的小项目里成立，一旦进入长周期协作与演进，没有硬边界就必然灾难
-
Harness 的上限由评估器决定：如果你无法把“好结果”编码为可检验的规则与测试，系统就无法稳定优化，模型也无法替你完成这层战略定义
-
未来工程师的分化本质是控制权分配：一类在代码生成速度上竞争，另一类在规则、评估、架构与闭环设计上竞争，后者决定系统长期生产力与可维护性