一个自主智能体一个周末发布了十个子系统

一个从第一天起就由智能体构建的引擎,长出的形状和一个把 AI 事后加装上去的引擎是不一样的。而那个形状,恰恰是当 AI 是一等原语——而不是旁边挂着的一个功能——时,运行时所需要的形状。

周六早上打开笔记本电脑。运行时仓库一夜之间累积了 139 次提交。其中大部分是由一个自主编码智能体落地的,它一直在针对我上周末提交的一批工单工作。十个子系统级别的拉取请求,全都已经准备好接受审查。

当人们问我,团队里有 AI 智能体时,构建一个 3D 运行时实际是什么样子,他们通常会假设两种情况之一。要么智能体只是套了个聊天面板的自动补全,要么它们是一个后加的功能,是在”真正的”引擎已经由人类构建完成之后才加上去的。

这个周末我所处的版本,两者都不是。

在整个周六和周日,运行时仓库累积了 139 次提交。其中 110 次由一个自主智能体撰写。20 次来自创始时代的 BladeWireless 账号。10 次是我的。在这 139 次提交中,落地了十个子系统级的拉取请求:

• 骨骼动画系统
• 运行时场景编辑 API
• 场景序列化
• 遮挡剔除
• 关卡流式加载
• 预制体系统
• GPU 粒子系统
• 高级渲染
• 地形与环境系统
• 后期处理管线

这些子系统没有一个是 AI。它们是一个 3D 运行时要成为一个 3D 运行时所需要的那些枯燥、承重的部分。而它们在一个周末内跨并行分支发布,大部分由一个自主运行的智能体撰写,我负责搭框架、审查和合并。

这篇文章讲的是:基础是由智能体构建的,而不是为智能体构建的,这意味着什么。

差异体现在每一个架构决策中

这个故事有一个版本是:你按照引擎一直以来的构建方式构建一个”正常”的引擎,然后在上面加 AI。AI 作为一个功能落地。它是加装上去的。它活在引擎之外,因为引擎当初设计时并未考虑要承载它。这是当前行业中的主流模式,而且这不是一个错误的模式。它只是当你在 AI 加入开发团队之前就决定好引擎该长什么样时,你会得到的模式。

当 AI 智能体从第一天起就在团队里时,引擎长出来的形状是不同的。有三件事会改变。

第一,每个子系统都要经过代码审查才能发布。 因为智能体必须参与审查循环,这个循环就必须能接受智能体撰写的 diff。每一个 PR。每一个 diff。每一次合并。这种纪律不仅仅是为了让智能体参与进来而设的。事实证明,如果 AI 有朝一日要成为运行时的一等原语,而不是编辑器的一个功能,这恰恰是你需要的那种纪律。同一条能在剔除头文件里抓到智能体打字错误的审查流水线,也能在行为树里抓到智能体的打字错误。这条流水线不在乎它活在技术栈的哪一层。

第二,每个子系统都有干净的公共接口。 多个智能体并行处理多个子系统,只要边界模糊,每次都会产生无法合并的冲突。补救办法是在任何人写代码之前就把边界画硬。一旦边界画硬了,子系统就变得可以从任何地方寻址,而这恰恰是你想让引擎承载那些可以调用运行时其余部分而不产生耦合的 AI 行为时所需要的。

第三,每个子系统都能独立测试。 一个 139 次提交的周六是不可能靠人工来做 QA 的。测试必须随 diff 一起交付,否则这个 diff 就落不了地。这就是处于循环中的人类能对这个 diff 建立起哪怕一点信任的方式。它的副作用是一个测试表面,能让你在不重写调用方的情况下替换实现,而这正是一个引擎要能持续演进所需要的纪律。

这些都不是 AI 功能。它们是团队里有智能体这件事所带来的开发流程后果。开发流程塑造了架构。

这个工作流实际长什么样

产出这个周末的模式:

• 我搭好了引擎接下来需要哪些子系统的框架。
• 一个自主智能体在十个分支上并行运行,每个分支实现一个子系统。
• 每个分支都产出一个带实现、测试和文档的 PR。
• 我进行审查和合并。智能体做错的地方,我要么关闭这个 PR,要么要求修改。

坐在这里回顾这个周末,让我印象深刻的是,已经有这么多东西是真正在起作用的。开发循环就是开发循环。智能体正在做我五年前本该雇十个人来做的工作。我在做架构判断和合并决策。这是一种和我过去的长周末不同的长周末。

这个特定周末的自主智能体不是一个由四个助手组成的多供应商栈。它是一个单一智能体(Copilot 的 SWE agent),在许多并行任务上运行。我预期多助手模式会到来,而且来得很快。这个模式已经以单智能体的形式出现在这里了。

哪些是难的

坦率地说,因为这确实很难。

智能体不是免费的。 一个 139 次提交的周末,有着 139 次提交的审查成本。每个 PR 都需要真正的关注,因为这些子系统我并不熟悉,不能只是略读一遍。我很累。这种疲惫是真实的,值得为它预留预算。

在新工作上信任一个自主智能体,是一种技能。 这个周末发布了大部分子系统的 Copilot SWE agent 很出色。它并非万无一失。这项技能在于知道什么时候该快速合并,什么时候该放慢速度,什么时候该把一份草稿直接扔掉。我已经合并过一些本该重来的东西。我正在通过付出代价来学习。

在智能体运行之前,架构必须先被勾勒出来。 如果你给智能体一个提示”给我造一个渲染器”,你会得到一个和引擎其余部分不搭的渲染器。如果你给它的是”实现一个导出这个 C API、并通过这些句柄与场景图集成的遮挡剔除子系统”,你得到的东西就能干净地落地。搭框架的工作才是真正的工作。智能体做的是敲代码。

测试是没有商量余地的。 我差点让这个周末的一个 PR 带着薄弱的测试覆盖率落地。那是我在悄悄承诺要去对抗的一个未来回归。补救办法是从提示的第一行开始,就把测试要求作为智能体提示的一部分。

我从这个周末带走的东西

两个观察。

智能体显然会持续变得更好。更快,更准确,能在一个”头脑”里容纳更多的引擎知识。这是容易预测的部分。

不那么容易预测的是,人类在这个工作流中的角色会变成什么样。它已经不是我作为一名高级工程师所受训练的那个角色了。打字更少,搭框架更多。综合更少,选择更多。少一些”我是这行代码上的瓶颈”,多一些”我是决定这个分支是否值得跑一次的架构决策上的瓶颈”。

那是一份不同的工作。它动用的是不同的肌肉。我认为它动用的这些肌肉在各个领域之间异常可迁移,而我认为在接下来两年里发展出这些肌肉的人,看待行业其余部分的方式,将会像今天的行业看待那些仍然不用版本控制来构建东西的人一样。

对一个周末来说,这已经足够多的思考了。

周日晚上合上笔记本电脑。下周六继续。