本文永久链接 – https://tonybai.com/2026/06/17/deepmind-automation-agent-harness-ai-self-coding

大家好，我是Tony Bai。

过去的几个月，整个 AI 开发圈最火的词，无疑是 Agent Harness（智能体驾驭系统）。

从 Claude Code 到 OpenClaw，再到我自己的极客时间专栏，我们所有走在 AI 原生开发前沿的工程师，都在不遗余力地布道一个核心思想：大模型本身只是一个“毛坯大脑”，你必须为它手工打造一套精密的“外部骨骼（Harness）”，它才能真正干活。

我们研究 ReAct 循环、设计上下文压缩引擎、构建安全中间件……我们以为，掌握这套“驾驭工程学”，就是我们在 AI 时代的终极护城河。

但就在今年年初，AI 领域的“神殿”——Google DeepMind——直接掀了桌子。

他们发布了一篇名为《AutoHarness: a code harness for LLM agents by automatically synthesizing a code harness》的重磅论文，用极其详实的数据和实验，向全世界宣布了一个既震撼又令人脊背发凉的事实：

别再苦哈哈地手写 Harness 了，我们已经能让 AI 自己为自己编写“规则护栏”了。

这篇论文同时也像一面镜子，照出了即便是最顶级的 AI Agent，在没有“护栏”的情况下有多么“愚蠢”；更像一声警钟，预示着我们人类工程师在 AI 产业链中的角色，即将迎来又一次深刻的变迁。

78% 的败因，竟是“犯规”

在展示 AutoHarness 有多强大之前，DeepMind 的科学家们先用一个极其残酷的案例，揭示了为什么 Harness 是“必需品”。

在上一次的 Kaggle 线上国际象棋大赛中，被寄予厚望的 Gemini 2.5 Flash 模型，其 78% 的对局失败，竟然不是因为技不如人，而是因为它试图走出“非法步骤（Illegal Moves）”！

比如，它会尝试让“马”走直线，或者把“兵”横着走。

这个案例，完美地暴露了所有大模型的“原罪”：它们拥有惊人的“语言理解能力”，却没有足够的“规则遵守能力”。

AI 知道成千上万种开局策略，但它不知道在当前的棋盘状态下，哪些格子是它能走的，哪些是不能的。它只是在基于概率，模仿它在训练数据中见过的、最像“正确答案”的文本。

传统的解决方案是什么？

• 模型微调（Fine-tuning）：用海量的棋局数据去微调模型。代价极高，速度极慢，而且可能会损害模型在其他任务上的泛化通用能力。
• 手工编写 Harness：由人类工程师为每一款游戏，硬编码一套“规则校验器”。工作量巨大，且极度脆弱，换个游戏就得重写。

让 AI 成为自己的“规则老师”

面对这个两难的困境，DeepMind 的思路堪称“降维打击”：

既然 AI 这么会写代码，为什么不让它自己根据环境的反馈，为自己写一个“规则校验器（Code Harness）”呢？

AutoHarness 的核心流程，就像一个优雅的“自我进化”闭环：

1. 初始探索：让一个基础模型（比如 Gemini 2.5 Flash）在游戏环境中自由发挥，生成一个初始版的 Python 策略代码，包含 propose_action() 和 is_legal_action() 两个函数。
2. 试错与反馈：在 10 个并行的游戏环境中，同时运行这段代码。一旦 AI 走出了“非法步骤”，或者代码执行出错，系统会立刻终止，并将失败的步骤和环境给出的错误信息，一起打包发给一个“批评家（Critic）”。
3. 代码精炼：批评家将错误信息进行整理，连同原始的“问题代码”，一起喂给一个“精炼器（Refiner）”。“精炼器”的角色同样由一个 LLM 担任，它的任务是：“看，你写的这段代码犯了这些错，现在请你把它改对。”
4. 循环进化：精炼器生成一段新的、有望修复 Bug 的代码，然后再次投入到游戏环境中进行测试。如此循环往复。

这个过程，本质上是一个基于“树搜索”和“迭代式代码精炼”的自动化编程过程。

结果有多惊人？

• 在 145 个不同的文本游戏中，AutoHarness 平均只需要 14.5 次迭代，就能为 Gemini 2.5 Flash 生成一个达到 100% 准确率的“合法走步”校验器。
• 在国际象棋（Chess）和奥赛罗（Othello）这种极其复杂的游戏中，AutoHarness 也能在几十次迭代后，完美掌握所有规则。

以弱胜强：当“AI+护栏”轻松碾压“最强大脑”

AutoHarness 最令人震撼的是它带来的“以弱胜强”的恐怖效果。

DeepMind 组织了一场对战实验：

• 甲方：小模型 Gemini 2.5 Flash，但装备了由 AutoHarness 自动生成的“规则护栏”。
• 乙方：比 Flash 强大得多的当时的旗舰模型 Gemini 2.5 Pro，但没有任何护栏，“裸奔”上场。

在 16 款不同的双人对战游戏中，结果呈现出一边倒：

装备了“护栏”的小模型 Flash，在与大模型 Pro 的对战中，胜率高达 56.3%！而 Pro 的胜率仅为 38.2%。

这张图清晰地展示了在多款游戏中，“Flash+Harness”组合的绿色胜利条，是如何显著高于 Gemini-2.5-Pro 的。

这个实验也再次印证了：一个更小的、但被良好“驾驭”的模型，其战斗力是可以超越一个更大、更昂贵、但却在“裸奔”的模型的，足见Harness的重要性。

更极端的是，DeepMind 甚至让 AI 把整个游戏的策略，都写成了确定性的 Python 代码（Harness-as-Policy），在运行时完全不需要再调用 LLM。
结果，这段由小模型生成的纯代码，在 16 款单人游戏中的平均得分，甚至超越了 GPT-5.2-High！

人类的新角色——“环境设计师”与“评估者”

DeepMind 的这篇论文，给我们这些正在苦心钻研 Harness Engineering 的工程师，带来了极其深刻的反思。

它似乎在告诉我们：未来，我们最重要的工作，可能不再是亲手去为 AI 编写“规则”，而是为 AI 设计一个能够让它“自我学习规则”的环境。

我们的角色，正在从“手工艺人”，向两个更高级的职位迁移：

1. 环境设计师（Environment Designer）

AutoHarness 之所以能成功，是因为 DeepMind 的科学家们为它精心设计了一个能提供清晰、即时反馈的游戏环境。

未来，我们的核心任务，将是把我们复杂的业务系统，抽象成一个个能让 AI 安全“试错”、并能从错误中学习的“模拟环境”。

2. 评估体系架构师（Evaluation Architect）

AutoHarness 的另一个关键，是那套能自动判断“好坏”的评估体系。

在 DeepMind 的实验中，他们引入了“批评家”、“裁判”等多个 AI Agent，来自动化地评估新生成的代码。

这正是我在自己的专栏《从 0 开始构建 Agent Harness》中，反复强调的 Evals（自动化评估体系） 的重要性。

当 AI 能写 Harness 时，我们人类的终极护城河，就变成了定义“什么是好的 Harness”的能力。

小结：从“教它做事”到“教它学习”

AutoHarness 的出现，意味着我们可能正在从“授人以鱼”（直接给 AI 写好的规则），进化到“授人以渔”（教 AI 如何自己学习规则）。

这既可以解放了我们的生产力，更是开启了一条通往“AI 递归式自我改进”的、充满无限想象力的大门。

当然，这并不意味着手写 Harness 会立刻消失。对于极其复杂、安全要求极高的领域，人类专家的经验依然不可或缺。

但这篇论文，至少为我们指明了方向：不要再把 AI 当作一个需要你手把手教的“学徒”了。把它当作一个极具天赋、能够自我反思的“初级程序员”，为它提供清晰的测试用例、明确的错误反馈，然后，放手让它自己去进化。

这，或许才是 AI 原生时代，最高级的“人机协同”。

资料链接：https://arxiv.org/abs/2603.03329

今日互动探讨：

看完 DeepMind 的 AutoHarness，你对 Agent 开发的未来是感到兴奋，还是感到了“饭碗不保”的焦虑？你认为 AI 自动生成“规则护栏”的模式，离我们日常的业务开发还有多远？

欢迎在评论区分享你的看法！

认知跃迁：在 AI“自我进化”前夜，你的核心壁垒是什么？

当 AI 开始学会自己编写“驾驭系统”时，我们这些正在苦学 Harness Engineering 的人类工程师，价值何在？

答案是：回归第一性原理。

AutoHarness 虽然强大，但它依然需要人类去定义底层的循环机制、安全边界、成本审计和评估框架。这些，才是 AI 无法自我生成的、真正属于“架构师”级别的智慧。

如果你还在为写 Agent 框架频频死循环、上下文爆炸而束手无策，如果你想在 AI 彻底实现“自我编程”之前，抢先一步，成为那个“设计进化环境”的人——

我的新专栏 《从 0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启你的“AI 环境设计师”之路。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2026/06/16/why-if-it-compiles-it-runs-rust-engineering-aesthetics-and-logic

大家好，我是Tony Bai。

在软件工程界，有一句流传甚广、近乎玄学的名言：“如果你的 Rust 代码通过了编译，那么它就已经可以正确运行了。”

对于被 Java 的空指针异常（NullPointerException）折磨得彻夜难眠、被 C++ 的段错误（Segfault）逼到崩溃、或者在 TypeScript 里为处理各种隐式错误而心力交瘁的开发者来说，这句话听起来像是一个过于美好的谎言。

为了探寻这句话背后的真相，在最近的一期访谈中，Google Android Rust 团队成员、Rust 语言团队顾问、高并发异步运行底座 Tokio 的核心维护者 Alice Ryhl，深度拆解了 Rust 的底层设计。

从一个在高中为了写《我的世界》（Minecraft）模组而自学 Java 的少女，到在 Rust 官方论坛上累计解答 10,000 个问题的硬核专家，Alice 用她极具说服力的工程视角，为我们揭示了 Rust 是如何通过极致的编译器设计、数据结构约束以及民主化的社区治理，彻底改变现代软件工程的。

终结“十亿美元的错误”：Rust 怎么保证代码的绝对可靠？

大模型时代，写代码的门槛越来越低，但系统的可靠性却变得前所未有的脆弱。Alice 认为，要让一门语言写起来有“编译即正确”的底气，最核心的底座是其类型系统。

1. 彻底消灭 null 隐患

1965 年，图灵奖得主 Tony Hoare 发明了 null 引用，后来他痛苦地称其为自己的“十亿美元错误”。在 Java 中，每一次函数调用，你都必须时刻提防它可能返回一个 null，进而导致程序崩溃。

而在 Rust 中，null 这一概念根本不存在。

如果你需要表达一个变量可能为空，你必须显式地使用 Option 枚举。最关键的是：编译器会用铁律强迫你在使用该变量之前，必须进行解包和空值检查。 你无法偷懒，更无法遗忘，因为漏掉任何一种可能，编译器都会拒绝通过。

2. 显式且不容忽略的错误处理

与 Java 或 C++ 依赖隐式垃圾回收或异常抛出（Exceptions）不同，Rust 采用了一种极其务实的做法：将错误作为普通的值返回。

// Rust 中的经典错误处理模式
let file = File::open("config.json")?;

这里的 ? 操作符是 Rust 的标志性设计。它意味着：如果打开文件失败，立刻将错误向上抛出。如果你忘记写这个 ?，或者没有对返回的 Result 进行处理，编译器就会报出一个无法忽视的错误。

这里体现的 Rust 的工程美学在于：它不依赖开发者的细心和自律，而是用编译器的钢性约束，把所有可能在生产环境中暴雷的隐式错误，提前在开发期彻底榨干。

妙到极致的“文档即测试”（Doc Tests）

你是否经历过这样的绝望：接手一个项目，按照 README 里的示例代码复制粘贴，结果编译报了一堆错——原来代码重构了，但写文档的人忘了更新示例。

在 Rust 中，这个问题被一个近乎艺术级的设计解决了：文档即测试（Doc Tests）。

在 Rust 中，只要在代码前使用三个斜杠 ///，就可以为函数编写 Markdown 格式的文档：

/// 这个函数将两个数字相加。
///
/// # Examples
///
/// ```
/// let result = my_crate::add(2, 2);
/// assert_eq!(result, 4);
/// ```
pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

当你运行 cargo test 时，Cargo 会自动提取你文档注释中的所有代码示例，并把它们作为单元测试全部跑一遍！

如果你的代码发生了重构，导致文档里的示例代码跑不通了，你的整个 CI/CD 构建流就会直接宣告失败。这种设计逼迫开发者：要想代码通过编译，你的文档和示例就必须永远保持最新。 这种对代码 hygiene（工程卫生）的极致追求，让 Rust 成了开源界文档质量最扎实的生态。

新手的终极撞墙期：不要修改代码，去修改你的数据结构！

每一个从 TypeScript、Java 或 Go 转型到 Rust 的开发者，都经历过一段极其痛苦的时期——被“所有权（Ownership）”和“借用检查器（Borrow Checker）”无情蹂躏，俗称“与借用检查器肉搏”。

Alice 指出，几乎所有新手在这个阶段都犯了一个根本性的方向错误：他们试图通过不断修改局部代码逻辑来通过编译，而真正的解法往往是修改数据结构（Struct）。

1. 循环引用的噩梦

在 TypeScript 里，我们建一个“书（Book）”和“页面（Page）”的对象，习惯于让 Book 引用 Page，同时让 Page 也引用回 Book：

Book  ──────>  Page
  ▲              │
  └──────────────┘

这种循环引用在有垃圾回收（GC）的语言中很常见。但在 Rust 这种没有 GC、依靠变量作用域结束自动释放内存的语言中，循环引用会导致内存释放链条死锁（编译器不知道该先释放谁，容易造成内存泄露或双重释放）。

2. 金科玉律：“改变数据结构，而不是改变代码”

当你在 Rust 中遇到借用冲突时，正确的思路是：

• 消除循环引用：将数据结构重构为清晰的、无环的有向无环图（DAG）或树状结构（Tree）。
• 利用引用计数：如果一个对象确实需要在多个地方共享所有权，不要强行用引用，改用引用计数指针 Arc（Atomic Reference Counted）。

通过调用 Arc::clone(&my_obj)，你可以安全、轻量地在多线程中共享同一块只读内存。当最后一个 Arc 离开作用域时，内存会自动被安全释放。

写 Rust 会强迫你在落笔之前，先在脑海中画出极其清晰的数据所有权图谱。这种高强度的架构思考，正是“编译通过即安全”的底气来源。

揭秘 unsafe 的真相：它不是后门，而是高级特权的封装

对于 Rust 的批评者来说，unsafe 关键字经常被拿来作为攻击的靶子：“既然 Rust 声称安全，为什么还留了 unsafe 这个后门？”

Alice 对此给出了极其严密的工程解释：unsafe 绝不是用来关闭编译器检查的后门，它是一个用于向语言注入全新特权的封装箱。

1. unsafe 关不掉借用检查器

一个普遍的误区是，在 unsafe 块里，你可以为所欲为。

事实是：在 unsafe 块中，借用检查器依然在严密工作。unsafe 仅仅是允许你多调用几个被标记为 unsafe fn 的特殊函数，或者操作原始指针（Raw Pointer）。

2. 极致性能与安全边界的统一

在普通代码中，你访问数组元素 vector[5]，编译器会在运行时默默检查数组长度，防止越界崩溃。但如果你在写追求极致性能的音视频解码器，或者在写 Linux 内核驱动，这种运行时的边界检查（Bounds Check）积累起来会产生无法接受的开销。

此时，你可以调用 get_unchecked(5)，它是一个 unsafe 函数，会直接跳过长度检查，直接去读内存。

// 只有在确定不越界的前提下，包裹在 unsafe 中以提升极致性能
unsafe {
    let value = my_vector.get_unchecked(5);
}

3. 用“安全的 API”封装“不安全”

Rust 的核心哲学是：你可以在底层用 unsafe 制造一个高效率的基础构件（比如 Vector 容器的底层实现就是基于原始指针分配和释放），但你必须用极致私有的字段和严密的公共 API，把它包裹成一个绝对安全的、暴露给外部用户使用的安全接口。

只要你的 API 设计无懈可击，外部调用者无论写出多么愚蠢的代码，也绝对无法突破这道安全的封装线。这就是为什么在企业后端开发中，你的业务代码中 unsafe 的使用率应当为 0%。

民主化的工程奇迹：没有“独裁者”的团队是如何高效演进的？

不同于 Python 或 Linux 内核拥有创始人（如 Linus Torvalds）作为“终身仁慈独裁者（BDFL）”来进行终极仲裁，Rust 语言的治理是一个彻底去中心化的、基于共识和提案的民主体系。

这个体系主要由两个精妙的工程机制驱动：

1. 极其严苛的 RFC（Requests for Comments）模版

当你想给 Rust 增加一个稍微大一点的特性时，你必须提交一份 RFC 提案。这个提案的模版极其考验作者的工程思维，其中有两个非常天才的设计：

• Guide-level explanation（引导级说明）：你必须假设这个特性已经存在，写一段像新手教程一样的指南来介绍它。这逼迫提案者从用户体验和易用性的角度去审视特性，而不是一上来就堆砌底层实现细节。
• Reference-level explanation（参考级说明）：详细的技术规范，相当于语言参考手册的起草。
• Alternatives & Prior Art（替代方案与先验艺术）：你必须写清楚为什么不采用另外几种设计，以及 C++、Go 等其他语言在这一块是怎么做的。这能让你在被别人质问之前，先在文档里把所有漏洞堵死。

这种 RFC 流程类似于亚马逊（Amazon）推行的 PR/FAQ 撰写机制，它确保了每一项进入语言的特性，在写第一行编译器代码之前，就已经在逻辑和易用性上被推敲到了极致。

2. 解决破坏性更新的“版次（Edition）”机制

当一门语言发展到一定阶段，难免需要引入破坏性更新（Breaking Changes），比如增加新的关键字。Python 从 2 升级到 3 导致了整个生态长达数年的割裂，至今仍是社区的隐痛。

而 Rust 发明了 版次（Edition） 机制，完美解决了这一难题：

• 编译器的包容性：不同 Edition 的包（Crates）可以在同一个项目中完美混用。
• 无缝兼容：你的底层库可以用 2021 版次编写，而我的主业务可以用 2024 版次调用它，编译器在底层会把它们无缝融合成统一的二进制程序。
• 语法平滑过渡：大版本更新（如引入 async/await 关键字）只在特定的 Edition 里生效，旧 Edition 的代码中依然可以安全地将 async 用作普通变量名。

这种精密的后向兼容机制，确保了 Rust 既能保持激进的技术进化，又绝对不会把老用户丢在半路上。

小结：从“写完代码再调试”到“在安全网中优雅降落”

在 Alice 的工程世界里，写 Rust 并不是在追求一种虚无的技术时尚，而是在实践一种将人的主观失误降到最低的现代工程学。

Rust 并不是万能的，在 Web 前端等需要快速试错、频繁变更界面的场景中，它显然不如 TypeScript 轻量和灵活。但只要你的业务涉及到高并发的后端、高可用的微服务、极致性能的系统底层，或者不容许有任何安全漏洞的防御性工程，Rust 就是目前人类技术栈中最坚固的防线之一。

写 Rust 的过程，是一次编程习惯的洗礼：

你不再需要战战兢兢地把代码部署上线，然后盯着监控屏幕祈祷不要发生内存泄漏；你是在编译器的细心呵护下，将所有已知的安全隐患和逻辑死角在开发阶段一扫而空，然后在类型系统的安全网中，优雅、从容地平稳降落。

而这，正是“编译通过，即可运行”这句工程神话背后，最朴素也最震撼人心的底层逻辑。

资料链接：https://www.youtube.com/watch?v=q9xD36NCtZ8

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。