如何通过 Harness Engineering 摆脱 AI Agent 的 Demo 幻觉困境？

在 AI 技术圈中，几乎每天都有新的“自主编程智能体（Coding Agent）”横空出世，伴随的往往是某条极具视觉冲击力的演示视频，以及评论区里“程序员即将绝版”的惊呼。 然而，剥开 Demo 阶段的狂欢，当真正前沿的工程团队试图将这些被吹捧上天的智能体投入真实的工程代码库，去执行跨越数小时甚至数天的长周期（Long-Running）任务时，现实却无比骨感。Anthropic 的工程团队在尝试用自家的前沿模型构建 Web 应用时，观察到了令人绝望的失效模式：智能体要么试图“一口气写完所有代码（one-shot）”最终耗尽上下文而崩溃；要么在半路突然出现幻觉，留下满地 Bug 后盲目自信地宣布项目已经完工。 大语言模型（LLM）的“智商”明明在呈指数级进化，为什么一遇到长周期、多步骤的复杂工程任务，就瞬间原形毕露？ Martin Fowler 团队近期发表了由 Thoughtworks 杰出工程师 Birgitta Böckeler 撰写的深度长文《Harness Engineering》。同时，Anthropic 团队也毫无保留地公开了他们题为《Effective Harnesses for Long-Running Agents》的实战架构报告。这两篇重磅文献在思想上产生了极其强烈的共振，共同指向了一个被业界严重低估、甚至完全无视的底层真相： 大模型本身，终究只是一个无状态的概率引擎。人类之所以能完成长周期的复杂软件工程，根本原因在于人类大脑里自带了一套极其严密的“隐式套件（Implicit Harness）”。 当我们要让机器接管系统时，真正的技术壁垒绝不在于继续堆砌模型的参数量，而在于如何将这套专属于人类的“隐式套件”，转化为工程化的“显式控制流”。这就是未来三年软件工程最重要的分水岭：套件工程（Harness Engineering）。 哲学起手：大语言模型的“裸奔”与人类工程师的“潜意识防线” 在剖析具体的代码与架构之前，我们必须先从认知科学与系统论的层面，彻底认清人类开发者与 AI 智能体之间的鸿沟。 当一个人类程序员坐在屏幕前敲击键盘时，他真的只是在“输出代码”吗？ Birgitta Böckeler 在她的文章中极其敏锐地点出：人类开发者在写代码时，其思维深处其实实时运行着一个庞大且复杂的“隐式套件”。 审美的边界： 当人类看到一个超过 300 行的臃肿函数时，会产生本能的“审美厌恶（aesthetic disgust）”并自觉停下重构。 社会化责任与恐惧： 人类知道自己的名字会永远刻在 git blame 的历史记录里。这种社会维度的问责机制，让人类在修改核心逻辑时充满敬畏感，如履薄冰。 微观的反馈闭环： 人类敲下两行代码，就会下意识地按下 Cmd+S，并用眼角余光扫一眼终端里 LSP（语言服务器协议）抛出的红色波浪线。 组织记忆的承载： 人类知道系统里有哪些“祖传代码”是不能碰的，也知道“在这家公司，我们不这么写代码”的潜规则。 然而，当我们将一个哪怕是 GPT-5 或 Claude 4.6 Opus 级别的顶级模型接入代码库时，这个至关重要的隐式套件瞬间就蒸发了。 LLM 没有社会责任感，不知恐惧为何物；它没有组织记忆，更没有对复杂度的本能厌恶。用 Böckeler 的精辟总结来说：“LLM 只是在处理 Token（they think in tokens）”。 如果我们不加干预，直接让一个 LLM 去读取和修改代码，那本质上就是让模型在没有任何操作系统（OS）、没有内存保护机制的情况下“裸奔”。 这牵扯出了软件开发领域最核心的哲学冲突：软件工程，本质上是一个高度依赖状态管理（State Management）、边界约束和历史文脉的“确定性游戏”；而大语言模型，偏偏是一个极度缺乏物理实体、没有长效记忆的“非确定性概率生成器”。 Anthropic 巧妙地用了一个比喻来形容长周期 Agent 的困境：这就好比一个软件项目由一群采取“轮班制”的工程师来开发，而接班的工程师对上一班发生的事情毫无记忆。因为 LLM 的每一次 API 调用（Session）都是独立的、无状态的。你如果不对它进行物理级别的约束，它前一秒还在写前端 UI，下一秒就可能因为一个幻觉生成的变量，决定把底层的数据库表结构给删了。 这就好比你拥有了一台动力无穷的 F1 赛车引擎（LLM），但如果你不给它配上坚固的底盘、精准的转向轴以及防抱死刹车系统（这些统称为 Harness），把它直接扔上赛道，它唯一的结局就是以极高的速度撞墙粉碎。