Paperclip 建第一家 AI 公司：官方六步顺序，以及每步跳过会留下什么坑
服务跑起来之后，真正让人愣住的是下一步：控制台里空空的，你手上有一堆想让 AI 干的活，却不知道该先建哪个对象。很多人的第一反应是直奔「加一个 Agent」，加完发现它没有可对照的目标、没有预算、也不知道该向谁汇报，于是又回头补。
Paperclip 官方给 board operator（也就是「董事会操作者」这个角色）的上手指南把这件事拆成了六步。这六步不是随便排的顺序，是依赖关系：后一步要填的字段，往往来自前一步创建出来的对象。看懂依赖关系，你就不会来回返工。
这篇按官方那份 Creating a Company 指南逐步拆解，重点讲三件事——每步要填什么、为什么必须排在这个位置、跳过或填错会在哪一环暴露出来。需要先说明：本文只依据官方文档的文字描述，我们没有在本地跑过这套界面，所以不会描述按钮长什么样、放在页面哪个角落，只讲文档写明的对象模型和配置项。
先认一个前提：company 是顶层单位
文档开头一句话定了整个数据模型的调子：company 是 Paperclip 里的顶层单位，agents、tasks、goals、budgets 全部挂在某一家 company 下面。
这句话的份量比它看上去大。它意味着：
- 你不可能先建一个「游离的 Agent」再决定把它放进哪家公司，公司必须先存在；
- 预算、目标、任务这些东西天然带公司边界，多家公司之间是隔开的容器；
- 如果你想同时跑两条互不相干的业务线，官方模型给的答案是建两家 company，而不是在一家公司里靠命名前缀硬分。
想先补一下 Paperclip 到底在解决什么问题、它把「公司」当成什么单位来抽象，可以看 什么是 AI 公司控制平面 那篇。
六步全景：谁依赖谁
| 步骤 | 官方要求填的内容 | 依赖前面哪一步 | 跳过的直接后果 |
|---|---|---|---|
| 1. 创建公司 | 名称；描述（文档标注为可选但推荐） | — | 后面所有对象没有容器可挂 |
| 2. 设定目标 | 公司顶层 goal，要求具体、可衡量 | 公司已存在 | 按文档说法「所有工作都要能追溯回目标」，没有目标就没有这条追溯线 |
| 3. 创建 CEO Agent | 名称、role、adapter、prompt 模板、预算 | 公司已存在 | 组织树没有根节点，后面的下属挂不上去 |
| 4. 搭组织树 | 从 CEO 往下建 CTO、CMO 等直接下属 | CEO 已存在 | 只有一个 CEO 在扛所有活，没有可委派的对象 |
| 5. 设预算 | 公司级 + 每个 Agent 级的月度预算 | Agent 已存在 | 触发不到官方那两道阈值，花销失去闸门 |
| 6. 启动 | 给 Agent 开启心跳，从仪表盘观察 | 前五步齐备 | Agent 配好了但不会自己开始干活 |
把这张表读一遍，前面说的「依赖关系」就具体了：第 3 步要填的 role 和预算，只有在公司这个容器里才有意义；第 5 步的 per-agent 预算，得先有 agent 才谈得上；第 6 步的心跳，是让前五步的静态配置开始转起来的开关。
第 1 步：公司名和描述，别把描述当摆设
文档只要求两个字段：Name 和 Description，后者标注为可选但推荐填写。
推荐的理由文档没有展开，我也不替它编。可以确定的是，这是这家公司在整套对象体系里唯一一处能写下「我们到底做什么」的自由文本位置，而 Paperclip 的 Agent 是靠提示词驱动的。描述具体会不会、以什么方式进入 Agent 的上下文，官方这一节没有说明，需要你在自己的部署里对着实际配置确认。
务实的做法：把描述当成写给后来接手的人和写给 Agent 的双份说明，一两句话把业务范围讲清楚，比留空强，成本也就几十个字。
第 2 步：目标为什么必须排在建 Agent 之前
文档对 goal 的定位用了「north star」这个说法，并要求所有工作都能追溯回它。判断标准给得很直接：好的目标是具体的、可衡量的。官方举的两个例子是这种形态：
- 「做出排名第一的 AI 笔记应用，三个月内月经常性收入达到 100 万美元」
- 「建一家营销代理公司，第二季度前服务 10 家客户」
注意这两句的共同点：都带了量化指标和时间窗。「提升产品竞争力」这种目标在这个模型里是失效的——它没法被追溯，也没法用来判断某个任务该不该做。
为什么这一步必须在建 CEO 之前？因为下一步你要给 CEO 写提示词，而文档要求 CEO 的提示词包含「审视公司健康度、制定战略、把活派给下属」。这三件事都需要一个对照物。目标还没定就先写 CEO 提示词，写出来的只能是空泛的角色扮演指令。
第 3 步：CEO Agent 的五个字段，逐个说清
CEO 是你创建的第一个 Agent。文档列的配置项如下：
| 字段 | 文档说明 | 容易出问题的地方 |
|---|---|---|
| Name | Agent 名称，例如 “CEO” | 只是显示名，别指望它决定权限 |
| Role | 填 ceo | 这是角色标识，和显示名是两回事 |
| Adapter | Agent 具体怎么跑（Claude Code、Codex 等） | 文档说 Claude Code 是个不错的默认选择 |
| Prompt template | 每次心跳时这个 Agent 要做什么的指令 | 它是「每次心跳」执行的，不是一次性开场白 |
| Budget | 月度花费上限，单位是分（cents） | 单位填错就是 100 倍偏差 |
两个细节值得单独拎出来。
一是 prompt 模板的语义。文档写的是「instructions for what the CEO does on each heartbeat」——每次心跳做什么。这跟很多人习惯的「系统提示词」不完全一样：它更像一份周期性执行的工作清单，而不是人格设定。按这个语义写，内容应当是「检查哪些东西、按什么标准判断、发现问题后做什么动作」，而不是「你是一位经验丰富的 CEO」。
二是 预算单位是分。月度上限用 cents 表达，想设 500 美元就得填 50000。这类单位约定在配置里出错的代价不对称：多填两个零，闸门形同虚设；少填两个零，Agent 刚起步就被停。填完回看一眼是最省事的检查。
Adapter 的几种类型怎么选、各自要准备什么前置条件，是另一条独立的线，这里不展开。
第 4 步：组织树只允许一个上级
从 CEO 出发建直接下属，文档举的例子是 CTO 管工程类 Agent、CMO 管市场类 Agent，其余高管按需添加。每个 Agent 都有自己的 adapter 配置、role 和预算——也就是说下属不会继承 CEO 的配置，每一个都要单独配。
这一节最硬的一条约束是：组织树强制严格层级，每个 Agent 恰好向一个 manager 汇报。
这条约束决定了你的组织设计空间。矩阵式的双线汇报在这个模型里不成立，你不能让一个 Agent 同时挂在 CTO 和 CMO 下面。真要做跨职能协作，得靠层级之外的机制来完成，而不是靠画一张双线组织图。这也是为什么组织架构值得在动手前先想一轮，而不是边建边改——树的形状一旦被下面几十个任务依赖，调整起来牵动的东西比想象中多。汇报线该怎么切、委派怎么落，可以接着看 组织架构与汇报线怎么搭。
第 5 步：两层预算和那两道阈值
文档要求在公司和每个 Agent 两个层级都设月度预算，并给了 Paperclip 强制执行的两道线：
- 80% 利用率：软告警（soft alert）
- 100%：硬停（hard stop），Agent 被自动暂停
为什么两层都要设，而不是只设公司总额？因为只有公司级一道闸门时，任何一个 Agent 卡在某种循环里反复烧 token，吃掉的是整个公司的额度，等你看到 80% 告警时，其他 Agent 的可用空间已经被挤没了。per-agent 预算的作用是把故障隔离在单个 Agent 身上——它被硬停了，别人还在正常跑。
需要留白的地方：文档这一节没有说明「完全不设预算」时系统的默认行为是什么，也没有说硬停之后恢复的具体路径。这两点建议在自己的环境里先确认清楚，再放开跑。预算和超支这条线的完整机制见 预算与超支控制。
第 6 步：开心跳，然后盯仪表盘
最后一步文档写得很短：给 Agent 启用心跳，它们就会开始工作；从仪表盘（dashboard）观察进展。
短归短，这一步是前面所有配置的开关。心跳不开，前五步建出来的是一套静态的组织结构，不会有任何动作发生。反过来，如果你发现 Agent 建好了却始终没有产出，第一个要排查的就是心跳是否启用——排在改提示词、换 adapter 这些动作之前。心跳、看门狗和「Agent 不干活」这类现象的排查路径，见 Agent 不干活怎么查。
一份可以照着走的顺序清单
把六步压成实际操作时的检查项：
- 建公司，名称 + 一两句业务描述；
- 在 Goals 里建公司顶层目标，带数字和时间窗；
- 建 CEO：role 填
ceo，选定 adapter，提示词按「每次心跳做什么」来写，预算用分为单位； - 从 CEO 往下建高管层，记住每人只能有一个上级；
- 公司级和每个 Agent 级预算都填上，确认单位；
- 开启心跳，去仪表盘看第一轮跑起来的样子。
这一篇解决不了的部分
官方这份指南是 board operator 视角的最短路径，它有明确的边界，下面这几类问题它没有覆盖：
- 只讲了界面路径。用 CLI 或 API 建公司、把公司配置写成文件版本化管理，这一节完全没提，属于另一条线的内容。
- 没给字段的完整取值范围。role 只举了
ceo一个例子，adapter 只提到 Claude Code、Codex「等」，实际可选项要看适配器那部分文档。 - 没说改动的生效方式。改了提示词或预算之后，是下一次心跳生效还是需要别的动作，这一节没写。
- 没有回滚和试跑的说法。目标写得不好、组织树搭歪了怎么改、改动会不会影响已经在跑的任务，都不在这份指南范围内。
- 界面细节一律以你的版本为准。我们没有实际运行过这套界面，任何关于页面布局、控件位置的描述都不该从二手文章里取，打开自己的部署看一眼最可靠。
真正需要花心思的其实只有第 2 步和第 4 步——目标写得含糊，后面所有任务都会漂；组织树搭错，改起来牵动一大片。剩下四步都是照着字段填，填完核对一遍单位就行。
延伸阅读
- 从头读起：Paperclip 是什么：一个自己不跑 Agent 的控制平面，怎么管住一整家 AI 公司
- 本专题共 40 篇，完整分组目录见专题页
- Paperclip 的组织架构与汇报线：一棵严格无环的树，决定了任务怎么往下派
- Paperclip 里的 Agent 怎么管：六种状态、创建六要素与暂停终止接口
本文依据 Paperclip 官方仓库（github.com/paperclipai/paperclip，MIT 协议）的 docs/ 用户文档
与 doc/ 下的规范、运维与连接器手册整理，核对日 2026-08-17。
我们没有部署或运行过 Paperclip，因此不涉及界面外观与操作手感；
部分规范文档描述的是目标架构而非当前实现，文中已就地标注，不构成对实际行为的保证。
请以仓库最新内容为准。