夜雨聆风别再把 Harness 当“编排层”了：它其实是 AI 时代最重要的控制系统。
这两个月，关于 Agent、Claude Code、Codex、Skills、Memory、Long-running Tasks 的文章满天飞。很多人读完很兴奋，觉得未来已来，仿佛只要把模型接上工具、写几段 prompt、再串一个 workflow，一个能持续工作的 AI 员工就出来了。
这套想法，太浅了。
它的问题不在于错，而在于只看到了表皮，没有看到骨头。
绝大多数人今天谈 Harness，谈的是：
- 怎么编排流程
- 怎么接工具
- 怎么写 prompt
- 怎么拆多 Agent
- 怎么做 memory
- 怎么跑 benchmark
这些当然都重要。但如果你把 Harness 只理解成这套东西，你最后做出来的大概率不是一个生产级系统，而是一套会动、会说、会调用工具，但不稳定、不收敛、不可恢复、不可审计的半成品。
我现在越来越确信一个判断：
Harness 不是编排层。Harness 本质上是控制系统。
一旦你用这个视角去看，很多原本模糊的工程问题会突然变得清晰；很多团队今天浪费在 prompt、模型切换和“感觉它这次怎么又不对劲了”的时间，也会立刻暴露出问题的真正位置。
这篇文章，我不想再讲那些已经被讲烂的“最佳实践”。我想直接把我认为最值钱的几条洞察讲清楚。它们不一定都舒服，但我认为它们对真正做长期 AI 系统的人最有用。
一、Harness 的职责不是“让模型更聪明”，而是“让系统别失控”
很多人一上来就问：
- 怎么让模型更强？
- 怎么让它规划更好？
- 怎么让它代码写得更对？
- 怎么让它自己修 bug？
这些问题没错，但它们默认了一个很危险的前提：
系统的核心矛盾是“模型不够聪明”。
这通常是误诊。
真实世界里，一个 Agent 做不好事，最常见的原因不是它不会，而是整个闭环有问题：
- 它看到了错误的状态
- 它拿到了不干净的反馈
- 它没有清晰的退出条件
- 它修 A 破 B
- 它反复在同一个局部盲修
- 它没有被及时打断
- 它没有可恢复的中间工件
- 它把无关信息也当成了当前任务状态的一部分
这不是智力问题，这是系统动力学问题。
所以我越来越反感一种说法：
“我们再换个更强的模型看看。”
很多时候，换更强模型只是在给一辆刹车失灵的车换更大马力的发动机。你不会因此更安全，你只会翻车翻得更快、更远、更像一次大胜利后的灾难。
真正成熟的 Harness，不是让模型偶尔显得更神，而是让系统做到：
- 出错可定位
- 失败可恢复
- 过程可审计
- 权限可限制
- 回路可收敛
- 代价可控
- 结果可验证
说白了：
Harness 的核心价值不是增智，而是驯化。
二、有反馈，不等于可控
很多团队今天很喜欢说自己有闭环：
- 生成 → 测试 → 修复
- 输出 → 验证 → 重试
- 执行 → 检查 → 再执行
他们觉得，只要有反馈，这就是一个闭环系统了。
这又是错觉。
反馈存在，不等于可控。
如果一个系统只能告诉 Agent：
- “你错了”
- “测试红了”
- “输出不符合预期”
- “再试试”
那这不叫有效反馈，这叫低质量责骂。
真正有价值的反馈，至少要满足三个条件：
1. 足够及时
错误刚发生，系统就应该尽量在局部把它暴露出来，而不是等到集成层、最终层、全局层才爆炸。
2. 足够可定位
要尽量把错误压缩到某个边界、某个接口、某个状态层，而不是把所有问题都变成一句模糊的“最后结果不对”。
3. 足够可操作
Agent 看完反馈之后，应该知道下一步该修哪里、先修什么、哪些不能碰，而不是到处乱试。
这意味着什么？
意味着验证器不是越多越好，日志不是越长越好，测试不是越晚越好。
你要做的是分层反馈系统：
- 结构约束负责早发现
- 类型与契约负责边界纠偏
- 测试负责行为确认
- trace 负责动态症状定位
- 人工审阅负责高阶判断与否决
你如果把所有反馈都堆到最后一层，系统一定会震荡。
它看起来在“自愈”，其实只是高增益盲修。
所以我有个很粗暴的判断：
绝大多数所谓“模型没想明白”，本质上是你给它的误差信号太脏、太晚、太粗。
三、上下文窗口不是记忆槽，而是观测器
这一点，我认为是今天整个行业里被误解得最严重的问题之一。
大家总在说：
- 长上下文
- 超长上下文
- 1M context
- 把所有历史都塞进去
这套叙事听起来很爽，但问题是：更长的上下文不等于更好的记忆。
更准确地说：
上下文窗口的职责不是存储，而是状态估计。
模型靠当前上下文去判断：
- 我现在在做什么
- 已经做到哪一步
- 哪些约束还有效
- 哪些假设已经失效
- 当前问题的真正边界在哪
于是问题就变成了：
你塞进去的每一段信息，都在影响它的状态判断。
这时候，旧计划、过时日志、已推翻的假设、无关工具输出、冗余中间稿、重复规则、历史碎屑，统统都不再只是“多一点内容”，而是观测噪声。
这也是为什么很多系统一开始很好用，越跑越差。
不是模型累了，是状态观测被污染了。
所以成熟系统必须做三件事：
1. 稳定状态外置
把真正长期有效的东西外化成可重访工件，比如：
- spec
- plan
- architecture map
- decision log
- rules
- session card
2. 高噪声任务隔离
用 sub-agent、side task、局部工作区，把高噪声过程隔离出去，只把压缩后的结果带回来。
3. 工具输出治理
工具输出不是越完整越好，必须截断、摘要、落盘、引用化，而不是原样把几十屏日志塞回主线程。
一句话：
上下文管理的核心，不是装多少，而是看得准不准。
四、Prompt 的高级形态，不是咒语，而是输入整形
很多人把 prompt engineering 当成一种语言魔法，仿佛真正的高手，就是会写那句神奇的提示词。
这在早期玩 Demo 的时候还说得过去。
但一旦系统进入真实生产环境，这种想法就幼稚了。
高级阶段的 prompt，不是在“激发模型灵感”，而是在约束系统动力学。
它更像什么？
更像操作规程，更像输入整形，更像：
- 规定相位顺序
- 明确 done when
- 给出 stop-and-fix 规则
- 限定作用域边界
- 指定验证顺序
- 约束动作面
- 降低冲动式操作的概率
也就是说，prompt 的高级形态不是文学，而是工程。
更重要的是：
凡是能被 hook、policy、linter、schema、type system 接管的约束，就不要长期压在自然语言里。
因为写在 prompt 里的规则，有三个天然缺陷：
- 会被忘
- 会被挤出上下文
- 会被模型策略性解释
所以成熟 Harness 的一个重要标志，不是 prompt 越来越长，而是：
结构开始替语言承担更多行为塑形责任。
五、工具不是越多越强，而是越多越容易把系统阶数抬高
这一点很多人不爱听。
工程师天然喜欢加工具：
- 浏览器
- 搜索
- Shell
- MCP
- 第三方 API
- 内部工具
- 各种自动化入口
大家会觉得，工具越多，系统能力越强。
这是静态软件思维。
在 Agent 系统里，工具不仅是能力增量，它还是：
- 新的状态源
- 新的延迟
- 新的噪声
- 新的分支路径
- 新的故障模式
- 新的上下文污染来源
每多一个工具，系统就多一个极点。
特别是那些“看起来功能很强”的工具，往往是最危险的。因为它们：
- 描述冗长
- schema 很大
- 输出噪声重
- 延迟高
- 失败形式复杂
- 容易诱发错误归因
所以我的观点一直很克制：
工具面要默认收窄，按任务进度渐进暴露。
能用模型熟悉的原始能力解决的，就不要急着再包一层漂亮抽象。
能不用就别给，能延迟暴露就别预加载。
未来最强的 Harness，很可能不是工具最多的那个，而是：
- 接口最克制
- 信号最干净
- 时延最可控
- 渐进暴露做得最稳
六、更强模型，往往更难控
这是今天最反直觉，但也最重要的一条。
大家都默认：
模型越强，系统越好。
这句话只在开环里成立。
在闭环里，不一定。
因为更强的模型，意味着：
- 更大的可达动作空间
- 更强的局部合理化能力
- 更像样的错误解释
- 更深的错误后果
- 更低的“看起来有问题”的可见度
弱模型的问题是笨。
强模型的问题是：它能把错做得更像对。
所以每一次模型升级，真正要升级的从来不只是 API 调用代码，而是整套控制面：
- 权限边界
- diff budget
- 验证前置
- milestone gate
- rollback
- sandbox
- escalation 机制
没有这些，强模型不是资产，是放大器。
说得再直白点：
AI 工程最大的风险，不是模型太弱，而是模型变强的速度，超过了 Harness 成熟的速度。
七、Self-evaluation 失效的根因，往往不是同模型，而是同上下文
很多人已经接受了一个结论：
Agent 不擅长评估自己。
但我觉得这个结论还不够精确。
更准确的说法应该是：
真正失效的，通常不是“同模型评估”，而是“同上下文评估”。
一个刚刚生成完方案、做过一堆妥协、跳过一堆边角、在当前上下文里已经形成自我合理化轨迹的模型，很难再公正地审判自己。
因为它看到的不只是结果，它还看到：
- 自己为什么这么做
- 哪些地方其实是赶工
- 哪些地方本来就有点心虚
- 哪些地方“先这样也行”
这些东西一旦共享，评估器就会被污染。
所以真正有效的做法，不一定是换模型，而是切上下文：
- 主执行体只负责做
- 审查体只看 diff、规则、产物
- 审查体不知道你刚才的全部内心戏
- 审查体不知道你做过哪些妥协
这时候，即便是同一个模型，效果也会大不一样。
这对成本很重要。
因为很多团队一上来就想跨模型验证，结果成本、延迟、复杂度全上去。
但大量场景下，上下文隔离比模型隔离更划算，也更关键。
八、长期系统的核心不是“会不会做”，而是“会不会形成错误先验”
这是我最近思考越来越深的一点。
短任务里，失败就是失败。
但长时间运行的 Agent，不是一次性生物。它会积累：
- 记忆
- 偏好
- 经验
- 启发式
- 失败模式
- 成功捷径
这时候，最大的风险就变了。
你最怕的，已经不是它忘了什么，而是它记住了错误的东西，而且在未来持续调用。
比如：
- 一次糊弄过关，被它记成可复用策略
- 一次偶然相关，被它记成稳定因果
- 一次临时用户情绪，被它记成长期偏好
- 一次错误修复路径，被它记成默认套路
这就不是一次错误，而是行为倾向漂移。
所以我现在越来越相信：
长期 Agent 的下半场，不是推理竞赛，而是记忆治理。
你得回答这些问题：
- 什么值得留下？
- 由谁批准进入长期记忆？
- 单次事件先打标还是立即固化？
- 何时整合？
- 何时降权？
- 何时遗忘？
- 什么能从情景记忆升级成规则记忆？
没有这套机制，Agent 不会成长，它只会堆积。
九、真正成熟的系统，一定是多时间尺度控制栈
你如果只看 Demo，会以为 Agent 系统就是一个 loop：
plan → act → verify → repair
这只是最里面那层。
真实成熟系统至少有三层时间尺度：
内环：秒级到分钟级
负责：
- plan
- edit
- verify
- repair
- 小范围回退
中环：分钟级到小时级
负责：
- review
- approval
- diff 审核
- rollout
- canary
- rollback
- 部署门禁
外环：天级到周级
负责：
- trace 分析
- 失败模式归纳
- harness 参数更新
- policy 修订
- memory 整合
- 经验蒸馏
真正决定系统长期稳定性的，往往不是那个最炫的内环，而是更慢、更钝、但真正拥有制度权力的中外环。
所以人类的正确位置，也不该停留在“人肉执行补丁层”，而应该上浮到：
- 规则定义
- 风险边界
- 升级否决
- 外环演化
换句话说：
人不该成为低价值执行瓶颈，但必须成为高价值制度节点。
十、最值得记住的四条运行时不变量
如果让我把这么多文章、源码、案例、讨论，最后压缩成最值得团队记住的四条不变量，那就是这四句：
1. 轨迹拓扑不能破
tool_use 必须闭合到 tool_result，推理轨迹不能被随意切断，恢复时的因果链必须能补回去。
2. 缓存前缀不能漂
一旦系统看到过某段历史，它后续在 API 前缀中的命运就不能随意改变。
once seen, fate frozen。
否则缓存、恢复、可重复性都会崩。
3. 能力面不能一次性敞开
工具、技能、上下文、权限，必须按时机、路径、模式渐进展开。
全量暴露看似自由，实则是系统阶数爆炸。
4. 连续性不能只靠 transcript
长期连续性至少要靠：
- 规则与指令连续性
- 能力面连续性
- 语义记忆连续性
- 操作状态连续性
任何试图靠一份超长聊天记录扛起一切连续性的系统，最后都会烂掉。
十一、最后的结论：Harness 不是“模型外壳”，而是 AI 时代真正的护城河
过去大家以为，模型是核心，外面的都是配套。
我越来越不这么看。
模型当然重要，但模型正在越来越像公共基础设施。
真正把模型变成可用生产系统的，不是那层“会不会聊天”的壳，而是：
- 你的控制结构
- 你的反馈分层
- 你的上下文治理
- 你的权限系统
- 你的记忆治理
- 你的工具面管理
- 你的恢复路径
- 你的外环演化机制
这些东西加起来，才叫 Harness。
所以我最后给团队的建议很简单，也很不讨好：
不要再把 Harness 当成“模型旁边那层杂活”。
它不是 plumbing，它是主系统。
谁先意识到这一点，谁就会停止在 prompt 和模型切换里空转；
谁先把 AI 系统当成闭环控制系统去设计，谁才真正有机会做出能长期工作的 Agent。
模型会越来越强。
这件事几乎可以确定。
但真正决定你能不能吃到这一轮红利的，不是你有没有最快接上新模型，而是：
当模型越来越凶、越来越快、越来越像会做事的人时，
你有没有一个足够稳的系统，把它关进价值生产的轨道里。
这才是 Harness Engineering 最值钱的地方。
一个更冷的结论
很多人今天还在争论：
- 该用 Claude 还是 GPT
- 该单 Agent 还是多 Agent
- 该 RAG 还是 memory
- 该 workflow 还是 autonomous
这些讨论当然重要，但说到底，很多还停留在“术”的层面。
真正的“道”其实更简单，也更残酷：
未来 AI 系统的核心竞争力，不是谁先拿到更强的模型，而是谁先学会约束更强的模型。
模型能力会继续上涨，这是大概率事件。
但模型越强，系统就越不能靠侥幸维持。
你不能指望：
- 靠更长的 prompt 解决结构问题
- 靠更多的工具掩盖状态失真
- 靠更大的上下文解决记忆治理
- 靠更强的模型绕过反馈设计
- 靠更频繁的重试代替真正的恢复路径
这些办法，短期也许能骗过 demo，长期一定骗不过生产环境。
生产环境只认三件事：
- 能不能稳定跑
- 出错能不能及时止损
- 失败之后能不能继续活
所以，真正成熟的团队，最终都会从“提示词工程”走向“系统工程”，从“模型崇拜”走向“控制思维”，从“追求一次神迹”走向“构造长期稳定”。
给团队最后的一句话
如果我要把整篇文章压成一句最适合发给团队的话，那就是：
不要再问“模型这次为什么又没想明白”。
先问：我们是不是又拿一个高波动执行器，去跑一个没有被认真控制的系统。
这是很多团队最该补上的认知升级。
Agent 时代真正稀缺的，不再只是会写代码、会调 prompt、会接工具的人。
真正稀缺的，是那些能把：
- 反馈
- 状态
- 权限
- 记忆
- 恢复
- 风险边界
- 多时间尺度监督
这些东西，组织成一个可长期运转系统的人。
这类人，未来不会少赚。
因为他们做的不是模型调用，他们做的是新一代生产系统的底盘。
最后一刀
模型决定上限，Harness 决定你会不会死在达到上限之前。
没有 Harness 的强模型，只是更危险的能力。
有 Harness 的模型，才有资格变成生产力。
所以别再把 Harness 当成“模型外面那层脏活”了。
在 Agent 时代，它不是配角，它才是主系统。
