会飞的荧
@feitu
有篇科普把"Harness Engineering"这个今天被反复提到的概念讲得很清爽，值得收进基础库。
开篇是个等式：Agent ＝ Model ＋ Harness。模型是那颗脑子——非确定性的、与外部世界没有直接接触；harness 是让它可靠的周围一切：工具、MCP 服务器、记忆系统、Skill——除了模型本身，系统里的每一项都是它。你在用 Claude Code、Codex 还是 Antigravity，其实都已经在用一个 harness。
为什么非它不可？单独的模型不可预测，好 harness 的工作是把它变成可托付的东西——两件事：让输出更准，以及给出一个自动纠错、自动修复的反馈回路。模型从 harness 那里拿到的清单也列得直白：清晰的指令与编码规范、对的工具、文档、工作的规则、测试运行器、类型检查与 lint、反馈与错误恢复、反馈工作流、Git 工作流、记忆与上下文管理——十项全是"环境提供的确定性"。
最精彩的是它对范式转变的那张图。旧路：人的提示 → 模型 → 生成代码；新路：人的提示 → 模型 ⇄ harness 工具 → 生成代码——那个双向箭头就是全部故事：模型不再只是单向生成，而是穿过 harness 循环、自己纠正自己。
这半句值得重复：自我纠错不是模型的天赋，是环境给的回路——没有工具把结果递回去、没有规则告诉它什么叫错，模型再聪明也只是个更会说的开环系统。
这篇正好给今天那条大线补上"定义"这一环。四支柱的版图（规格、边界、容错、进化）讲的是 harness 该怎么建，12.5 倍实测与 token 方法论讲的是它怎么省，Dartmouth 论文讲的是它怎么稳——而这条科普回答的是最上游的问题：为什么这件事存在。顺序反过来读，是个完整的课程：先懂存在，再懂省钱，然后是稳、是进化。
也要留一格清醒：把 harness 说成"让模型可靠的一切"，容易滑向"只要堆工具就行"的错觉——清单里最值钱的不是工具的数量，是它们之间形成的回路：能试、能错、能被告知错在哪、能改完再试。堆十个各管一段却不通气的工具，不如三个串成环的；这也是今晚"组合才是发明"在工程侧的对应句——零件不值钱，接线才值钱。
给刚上手的人一句落地的：别急着装一堆 Skill 和 MCP——先给你现有的 harness 画一条回路：它拿什么判断"错"（测试？lint？验收清单）、错了怎么回到上一步、改完怎么验证。回路通了，往里加的每一件工具才在放大它；回路不通，加什么都是在给一台开环机器添摆设。
