首页 > 基础资料 博客日记
AI Agent 走出 Demo 幻觉的唯一解药：Harness Engineering
2026-04-10 15:30:02基础资料围观1次
在 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），把它直接扔上赛道，它唯一的结局就是以极高的速度撞墙粉碎。
因此，Harness Engineering（套件工程）的本质，就是一场逆向工程——我们要把人类大脑中潜意识的防线（隐式套件）抽离出来，变成代码化、显性化的“控制论系统（Cybernetic Governor）”。
在 Böckeler 提出的心智模型中，一个真正可用的 Agent 架构，必须建立两条绝对硬核的防线：
- 前馈引导（Feedforward / Guides）：收敛状态空间的“防暴盾”
我们不能等模型犯错。在 Agent 行动之前，Harness 必须通过强引导（例如注入严格的代码规范AGENTS.md、强制运行环境脚手架脚本），将其接下来可能采取的非确定性行为，死死压缩在一个极小的合法状态空间内。 - 反馈传感（Feedback / Sensors）：强制物理接地的“电击项圈”
由于 LLM 活在纯文本的“潜空间（Latent Space）”里，它极其容易陷入逻辑自洽的幻觉中。Harness 必须在环境里部署密集的计算型传感器（如测试用例、Linter、类型检查器）。一旦 Agent 越界，立刻用毫秒级、绝对确定性的真实报错信息去“电击”它，强制将它的视角从高维概率空间拉回冰冷的物理现实（Grounding）。
从“隐式套件”到“显式控制”，这不是在写什么微调提示词（Prompt Tuning），这是在构建未来 AI 时代的操作系统内核。
二、 架构级剖析：Anthropic 是如何用“状态机”强行接管“概率论”的？
在 Anthropic 尝试用 Claude 构建复杂的、包含数百个组件的 Web 应用（如完整克隆一个 Claude.ai 前端）时，他们遇到了一道几乎让所有 Agent 框架折戟的叹息之墙：长周期崩溃（Long-Running Collapse）。
当 Agent 运行到第 50 步或者耗时数小时后，它会不可避免地陷入三种绝望的死局：
- 目标偏移（Goal Drift）： 彻底忘记了自己最初是要实现一个登录页面，转而去疯狂优化一个无关紧要的 CSS 动画。
- 幻觉盲信（Hallucinated Confidence）： 在破坏了核心的路由文件后，没有做任何测试，就沾沾自喜地输出：“项目已完美竣工”。
- 级联灾难（Cascading Failures）： 为了修复一个微小的拼写错误，Agent 越改越错，最终把整个项目的依赖树连根拔起。
面对这些绝境，Anthropic 没有选择“再给模型加一层反思（Reflexion）Prompt”，也没有去乞求更高阶的模型能力。相反，他们用纯正的软件工程思维，在模型外部构建了一套重型装甲（Harness）。
这套 Harness 的架构精髓，可以凝练为三大核心机制：
核心机制一：状态固化（State Pinning）——对抗目标的熵增
物理学告诉我们，孤立系统总是趋向于无序（熵增）。而长上下文中游荡的 LLM，就是软件工程里最大的“孤立系统”。只要让它自由发挥，它的目标一定会随着 Token 的堆积而逐渐模糊。
为了对抗这种“目标的熵增”，Anthropic 引入了一种极其粗暴但极为有效的架构设计：切断大包大揽，强行固化中间状态。
- 分离“规划器”与“执行器”： 他们设计了一个极其纯粹的
Initializer Agent（初始化智能体）。这个智能体绝对不写一行功能代码，它的唯一任务是生成一个包含了数百个微小节点的feature_list.json文件。 - 外部化记忆（Externalized Memory）： 这绝不仅仅是一个 To-Do 列表，这是在进行状态的硬编码。因为大模型的 Context Window（上下文窗口）是流动的、不可靠的，Harness 必须把“当前项目的进度（State）”从大模型的隐空间（Latent Space）里抠出来，钉死在文件系统里。
- 强前馈控制： 负责写代码的
Coding Agent每次被唤醒，Harness 都会强迫它先读取这个 JSON。Agent 的主观自信在这里毫无意义，只有 Harness 验证 JSON 中的状态标志从false变为true时，状态机才会向前拨动一格。
架构洞见： Harness Engineering 的第一法则就是“不信任模型的记忆”。优秀的 Harness 会将复杂任务降维，把原本由模型内部维护的“隐式状态”，强行接管为受版本控制的“显式文件状态”。
核心机制二：强制空间感知（Spatial Anchoring）——打破“盲人摸象”的幻觉
你有没有想过，当一个 Coding Agent 准备修改 src/components/Button.tsx 时，它脑子里的那个文件结构是从哪来的？
答案是：大部分时候，是它“猜”出来的。
模型习惯于通过概率去推测常见的工程目录，这就导致它经常在没有确认当前路径的情况下，向一个根本不存在的目录写入代码。
为了打破这种“盲人摸象”的幻觉，Anthropic 在其 Harness 中植入了极其严格的环境感知传感器（Feedback Sensors）。
- 把 Agent 降级为系统调用（Syscall）： 在 Anthropic 的架构里，Agent 绝对不允许直接获得文件系统的修改权限。Agent 输出的所有命令，都必须经过 Harness 这个“操作系统内核”的拦截与鉴权。
- 强制的感知循环： 每当接班的 Coding Agent 醒来，Harness 会强制它执行
pwd（查看当前路径）、ls（列出目录）、甚至是git log（查看上一个轮班的 Agent 做了什么）。就像一个失忆症患者每天醒来，必须先阅读昨天的日记一样。 - 端到端真实测试反馈： 当 Agent 认为前端 UI 写好时，Harness 会在沙盒中启动 Puppeteer，像真实人类一样去点击浏览器，并将报错日志（甚至是浏览器截图）狠狠地砸在 Agent 脸上。
架构洞见： 在 Harness Engineering 中，Agent 输出的代码仅仅是“假设（Hypothesis）”，而 Harness 从物理环境中提取的运行时报错和文件状态，才是绝对的“地表真理（Ground Truth）”。优秀的 Harness 会通过密集的计算型反馈，将模型强行“锚定（Anchor）”在物理现实中。
核心机制三：分支与回溯（Branching & Backtracking）—— Harness 里的时间旅行
这是长周期 Agent 架构中最令人惊叹，也是传统 Prompt 工程绝对无法做到的防线。
如果 Agent 在第 40 步犯了一个致命错误，并试图在 41 到 50 步疯狂修补却越弄越糟，该怎么办？
人类程序员在这个时候会怎么做？人类会绝望地叹口气，然后敲下 git reset --hard。
但大模型没有这种“止损”的直觉，它会像一个赌徒一样，试图用更多的代码去弥补上一个代码造成的 Bug，最终导致（Cascading Failures）级联灾难。
Anthropic 在构建 Harness 时深刻认识到了这一点。因此，他们在外围包裹了一套极其坚固的快照回滚机制（Snapshot Reversion）：
- 高频 Git Checkpoint： 每当 Agent 通过了一个微小测试，完成了一个子节点，Harness 就会在底层自动执行一次
git commit，将这完美的一刻冻结。 - 断路器（Circuit Breaker）与强制时间回溯： Harness 会持续监控 Agent 的轨迹。如果 Harness 发现 Agent 在同一个任务上连续失败了 3 次（或者消耗了超过阈值的 Token），Harness 的断路器就会“啪”的一声切断 Agent 的运行。接着，Harness 会执行最高权限：将代码库状态、测试环境状态强行回滚到上一个干净的 Checkpoint，然后向 Agent 注入新的上下文重新开始。
架构洞见： 这就是 Harness Engineering 最暴力的美学——用系统工程的确定性，去抹杀模型的非确定性错误。 既然我无法阻止你犯错，那我就赋予系统“时间回溯”的能力。只要我的快照打得足够密，你的灾难性故障就永远无法逃逸。
三、 范式转移：从 TDD（测试驱动开发）到 HDD（套件驱动开发）
过去的二十年里，软件工程界的最高法则之一是 Martin Fowler 等人极力推崇的 TDD（测试驱动开发）。它的核心理念是：先写测试，再写业务代码，测试是用来防止人类犯错的“安全网”。
但在 AI Agent 时代，这个逻辑被彻底颠覆了。
对于 LLM 来说，测试代码不再仅仅是“安全网”，而是它在黑暗中摸索前行的“唯一视觉器官”与“方向盘”。
这催生了一种全新的工程流派——HDD（Harness-Driven Development，套件驱动开发）。
在传统开发中，如果你的测试没写好，顶多是线上多几个 Bug；但在 Agent 时代，如果你的 Harness（测试套件与运行环境）存在漏洞，Agent 就会像一辆没有传感器的自动驾驶汽车，不仅会偏离航线，还会以 200 Token/秒 的速度把你的整个代码库撞得稀巴烂。
HDD 的核心开发流转变为以下四步：
- 构建沙盒边界（Define the Boundary）： 在让 Agent 写第一行代码前，先配置好 Docker 容器、隔离的数据库和网络白名单。切断 Agent 毁灭宿主环境的物理可能性。
- 铺设高密度传感器（Deploy Sensors）： 编写极其严苛的自动化测试、部署强类型的语言检查（如 TypeScript/Rust 的严格模式）、配置极度敏感的 Linter。在 HDD 中，测试越吹毛求疵，Agent 干活就越聪明。 因为计算型报错（Computational Feedback）是打破模型幻觉的唯一解药。
- 释放 Agent 并捕获轨迹（Capture Trajectory）： 让 Agent 在套件中运行。我们不再只关注它最终是否输出了正确的代码（Final Result），而是像监控黑匣子一样，监控它的“思维轨迹（Trajectory）”。它在第几步走弯路了？在哪一次终端报错时陷入了死循环？
- 迭代套件，而非微调模型（Iterate Harness, not Model）： 当 Agent 失败时，HDD 工程师的第一反应不是去修改 Prompt，更不是去微调模型，而是去问：“为什么我的 Harness 没有在它犯错的第一时间把它拦下来？”然后，去升级你的测试用例和拦截器。
架构洞见： 未来的软件开发，20% 的算力用于模型生成代码，80% 的算力将在 Harness 中运行无穷无尽的测试与验证。代码的验证成本，将彻底取代代码的编写成本，成为工程界的核心矛盾。
四、 行业终局：“可接管性（Harnessability）”将成为衡量代码质量的唯一标准
如果你理解了 Harness Engineering，你就会对当前网上泛滥的“程序员失业焦虑”产生一种降维打击般的免疫力。
那些惊呼“AI 一秒钟写完贪吃蛇”的人，根本不懂软件工程的悲哀在于维护，而不是从零创建。
当你想让一个顶级 AI Agent 接手你们公司那祖传的、跑了 5 年的、充满全局变量和幽灵依赖的核心业务系统时，Agent 的表现绝对不会比一个刚入职的实习生好到哪里去。为什么？因为你的系统“不可接管（Unharnessable）”。
在过去，Robert C. Martin 定义的“Clean Code（整洁代码）”是为了人类的“可读性（Readability）”——变量名要见名知意，函数不要超过 20 行。
但在未来三年，高级架构师的核心考核指标将变成代码的“可接管性（Harnessability）”，即：你的系统对 AI Agent 是否友好？
什么样的系统具备极高的“可接管性”？
- 状态与逻辑极度解耦： Agent 最怕处理那些到处乱飞的隐式状态。函数越是纯粹（Pure Functions），副作用越少，Agent 越不容易犯错。
- 强类型与显式契约： 动态弱类型语言（如老旧的 JavaScript/Python）将成为 Agent 的噩梦，因为缺少编译期的强反馈。而带有严格类型签名的 Rust 或 TS，其实是在给 Agent 提供免费的、即时的“微型 Harness”。
- 高内聚与微模块： 如果你的系统牵一发而动全身，Agent 的一个小修改就会引发级联雪崩。只有物理隔离边界清晰的模块，才能被安全地放入沙盒中交由 Agent 迭代。
你的系统架构越烂，Agent 的智商就越低；你的工程套件越完善，Agent 的超能力就越恐怖。 这就是技术圈最真实也最残酷的守恒定律。
结语：重夺控制权，做新时代的“系统编排者”
回到最初的问题：AI 会取代程序员吗？
答案是：“翻译官”会死，但“架构师”将迎来属于他们的黄金时代。
如果你的核心竞争力仅仅是把产品经理的中文需求，翻译成一段连你自己都不知道为什么能跑通的循环代码（For-loop），那你的确岌岌可危。因为在“语法生成”的赛道上，碳基生物永远无法战胜硅基的概率引擎。
但正如 Anthropic 和 Birgitta Böckeler 所揭示的，真正的软件工程，是一场用确定性的逻辑去驯服非确定性混乱的战争。
当拖拉机发明时，农民并没有被淘汰，他们只是从“拉犁的人”变成了“驾驶机器的人”。对于未来的软件工程师而言，Harness Engineering（套件工程）就是那个驾驶座。
停止在语法熟练度和背诵 API 上内卷吧。不要去和模型比拼谁写代码快，要去构建坚不可摧的测试网、设计优雅的时间回溯沙盒、制定严密的 CI/CD 断路器。
当你从一个“代码生成者”蜕变为一个“系统编排者（System Orchestrator）”时，当你能够亲手为那些狂野的 AI 巨兽戴上你打造的 Harness 项圈时……
在那片绝对受控的、确定性的系统疆域里，你，依然是唯一的造物主。
source 1: https://martinfowler.com/articles/harness-engineering.html
source 2: https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！
标签：
上一篇：AI Agent中6种常用的设计模式
下一篇：wso2几个核心项目介绍
相关文章
最新发布
点击排行
本站推荐
