系列: 与 AI 一起学编程

在编写引擎之前先规划智能体

六个智能体角色围绕着一支受治理的舰队:Product、SDK、Studio、Marketing、Operations 和 AI strategy。

先规划团队,再造引擎 一个人,一支智能体舰队,以及覆盖整体之上的一层治理 人类(你) 智能体治理 Product SDK Codex Dev Studio Dev Relations Marketing Strategic Partnerships Operations AI & Data Strategy 十个角色,明确的交接,在偏差累积之前就被发现
这是一张工作流的组织结构图,其中大多数方框是智能体,连接线是自动化的交接。

构建你的空间运行时的团队,应该像运行时本身一样被精心设计。RakuAI 从团队形态开始——一个人,一支智能体舰队——因为架构是由构建它的人决定的下游产物。

这个周六进行了一场白板演练,任何旁观者都会觉得这为时过早。产品离交付还有很长的路。引擎还不是一个仓库。没有代码。没有演示。有的是一份硬件路线图、一份可以追溯到十多年前的专利资产,以及一个关于下一代 AR 眼镜应该是什么样子的清晰论点。而我,坐在厨房餐桌前,正在规划将要构建这个东西的智能体。

这是故意的。

为什么智能体要先出现

在项目的这个阶段,常规做法是开始写代码。打开仓库。构建概念验证。当概念验证需要帮助时招聘工程师。发布 MVP。迭代。

我已经沿着这条常规路径建立过三家公司。我决定这一次要不一样。构建这个引擎的团队将是一个人加上一支在明确角色中工作的 AI 智能体舰队。引擎的架构、SDK 的形态、代码审查的纪律、开发循环的节奏,所有这些都是团队形态的下游产物。如果我不先把团队形态想清楚,我最终会得到一个为另一支团队设计的引擎,而不是真正要来构建它的这支团队。

所以今天是团队形态日。

名单

我正在敲定的智能体名单,以及每个角色应该负责的事情。

Product Agent。 负责规格说明。跟踪硬件更新、供应商路线图、SDK 依赖关系、公开发布日历。Product Agent 是”引擎应该做什么”这件事的权威真相来源。其他智能体都要对照 Product Agent 对规格说明的理解来核对自己的工作。

SDK Agent。 负责 SDK 本身。文档、上手流程、兼容性测试、包发布。SDK Agent 是开发者最常打交道的智能体,以生成的文档、示例应用和上手报错信息的形式出现。它产出的东西必须让人感觉像一个真正的开发者关系团队。

Studio Agent。 负责与游戏工作室和独立开发者的外联。演示准备。联合营销素材。专门面向工作室的上手文档。Studio Agent 的指标是转化率:一个和我们聊过、之后真的在这个引擎上发布了产品的工作室。这个指标还很遥远,而 Studio Agent 的日常工作就是缓慢积累最终能产生这个指标的关系。

Marketing Agent。 负责对外的公开面。媒体资料包。如果这条路径合适的话,Kickstarter 素材。网红追踪。硬件活动素材。落地页的 A/B 测试。这个智能体的产出是世界最先看到的东西。它必须做得好。

Operations Agent。 负责节奏。站会(和我)。Notion / 甘特图管理。瓶颈预警。执行摘要。Operations Agent 是我每个周六一开始就会找它对齐的智能体,借此了解我不在的这一周里其他智能体都做了什么。

AI and Data Strategy Agent。 负责数据飞轮。从 SDK 和眼镜端采集遥测数据。构建最终将驻留在设备端的小型语言模型。打磨 AI 护城河。这是一个随时间推移复利效应最强的智能体,因为它产出的数据和模型会成为无人能复制的差异化优势。

Codex Dev Sub-Agent。 写代码。集成运行时 API。构建 Unity 和 Unreal 演示。在技术性上手方面支持 SDK Agent。这是自主编码智能体。它在指令下工作,不设定自己的优先级。

这就是奠基名单:七个角色明确的智能体,彼此之间有明确的交互。

我要新增的三个角色

奠基名单让我们完成了大部分工作。还有三个我认为需要但没有出现在最初草案里的角色。这个周六把它们加上。

Developer Relations Agent。 GitHub issue。Discord。Reddit。当开发者提出问题而 SDK Agent 还没有相应文档时,由这个智能体来回应。这是接待性质的工作,也是布道性质的工作。担任这个角色的合适人选(或合适的智能体)能以任何营销素材都无法复制的方式,与工作室和独立开发者建立信任。

Strategic Partnerships Agent。 B2B 外联。授权许可谈判。与游戏网吧、电竞场馆等任何产品可能先被非工作室人士体验到的地方进行联合营销合作。这是负责开拓非消费者收入渠道的智能体。

Agent Governance Agent。 监督其他智能体的智能体。提出升级建议。管理版本。在某个智能体做出糟糕决策时处理回滚。这是我认为对这种工作方式而言真正的解锁点所在的那种递归。没有它,智能体会漂移。有了它,它们会随时间变得更好,因为有人在监督这些监督者。

交互图长什么样

白板上的版本,简化后:

  • 执行层监督(我)位于顶端。
  • Agent Governance Agent 位于我之下,监督其下的一切。
  • Product、SDK 和 Codex Dev 构成技术工作的一个三角。
  • Studio 和 Developer Relations 构成面向开发者的界面。
  • Marketing 和 Strategic Partnerships 构成对外的界面。
  • Operations 和 AI/Data 作为横切关注点位于底层。

每个智能体都与其他智能体有明确的交互。SDK 与 Codex Dev 对话。Studio 与 Marketing 对话。Operations 与所有人对话。Governance Agent 监督整体,并在某个智能体的产出开始偏离其角色时进行干预。

这不是一家传统公司的组织结构图。这是一张工作流的组织结构图,其中大多数方框是 AI 智能体,大多数连接线是自动化的交接。图中唯一的人类位于顶端,负责框架搭建和判断性的工作。其余全部是智能体。

为什么现在是做这件事的正确时机

三个理由。

引擎架构将由团队塑造。 如果要让智能体参与文档、测试和代码审查这类横切关注点,就必须从第一天起把它们设计进代码库。如果我先写代码库,之后再试图把智能体塞进去,大部分工作就得做两遍。

专利资产给了我从容规划的时间窗口。 支撑这款产品的专利是十年前的现有技术。竞争时机不是”三个月内发布,否则别人会抢先”。而是”在正确的时刻发布正确的东西”,这个时刻比过去十年中的任何一个时间点都更近,但仍然留有一个规划季度的余地。我正在使用这个季度。

智能体本身需要被设计。 每一个都需要一份系统提示词、一套工具、一套护栏。先写引擎再写智能体,意味着在工作已经开始之后才招募团队。这就是引擎项目最终把智能体硬塞进代码库根本没有设计来支持的角色里的原因。

接下来是什么

下一个周六进入 SDK 设计。文件夹结构、模块界面、开发者与每个部分交互的方式。再下一个周六进入演示套件:规范示例应用是什么、它们要证明什么、要教会什么。到夏天结束时,设计阶段应该完成,真正的仓库就可以开放了。

按照传统的风险投资节奏来看,这是一次缓慢的构建。但完成之后,它看起来绝不会缓慢。

构建你的 AI 本该栖居的运行时

RakuAI 是一个从团队层面就精心设计的 AI 原生空间运行时——来看看一支深思熟虑的智能体舰队如何构建出一个 LLM 厂商和眼镜厂商都能信赖的引擎。

← 所有文章