Paperclip 是什么：一个自己不跑 Agent 的控制平面，怎么管住一整家 AI 公司
同时开着十几个 Claude Code 终端的人，大概都遇到过同一个尴尬：过两个小时你就分不清哪个窗口在干哪件事了，重启一次电脑全丢。于是很自然会想——把这些活儿丢进 Jira 或者 Linear 不就行了？
Paperclip 的回答是不行，而且它把理由写进了文档第一段：任务管理软件做得不够远。当你的整个劳动力都是 AI agent 时，你要的不是一份待办清单，而是一整家公司的控制平面（control plane）。
这个词是从基础设施领域借来的。它意味着 Paperclip 自己不干活——真正执行任务的 agent 跑在别处，通过适配器接进来向它汇报。这一条是理解这个项目的钥匙，也是它和普通任务管理工具最本质的分界线。
本文依据 Paperclip 官方仓库
github.com/paperclipai/paperclip的 README，以及文档站 Start 部分的 What is Paperclip / Core Concepts / Architecture 三篇，核对日 2026-08-17。我们没有安装也没有运行过这套软件，下文只讲文档写明的机制、配置项和命令，不涉及任何界面观感或实测数据。项目开源协议为 MIT，主语言 TypeScript。
一、它到底是什么：一个实例，多家公司
官方对自己的一句话定义是「自主 AI 公司的控制平面」，再往下一层说是「AI 劳动力得以带着结构、治理和问责运转的基础设施骨架」。
具体到形态：一个 Paperclip 实例可以运行多家公司。每家公司都有员工（都是 AI agent）、组织架构、目标、预算和任务管理——文档的原话是，一家真实公司需要的东西它都有，区别只在于这里的「操作系统」是真正的软件。
README 里把这件事说得更直白：如果说 OpenClaw 是一名员工，那么 Paperclip 是这家公司。这是官方 README 自己拿别的产品作的参照，原样转述。
它列出了自己作为「指挥、通信与控制平面」承担的六件事：
| 能力 | 官方描述 |
|---|---|
| 把 agent 当员工管 | 雇佣、编组、追踪谁在做什么 |
| 定义组织架构 | 组织架构图，agent 本身就在这张图里运作 |
| 实时追踪工作 | 任何时刻都能看到每个 agent 正在做什么 |
| 控制成本 | 每个 agent 的 token「薪水」预算、支出追踪、燃烧率 |
| 对齐目标 | agent 能看到自己的工作如何服务于更大的使命 |
| 治理自主性 | 董事会审批门、活动审计轨迹、预算强制执行 |
最后一句核心原则值得单独摘出来：你应该能看一眼 Paperclip 就明白整家公司的状况——谁在做什么、花了多少钱、有没有效果。
二、两层结构：控制平面不执行 agent
架构文档把系统分成两层，这一层分工是全篇最需要先吃透的。
第一层是控制平面，也就是 Paperclip 本体。 文档称它为「中枢神经系统」，管的是：agent 注册表与组织架构图、任务分派与状态、预算与 token 支出追踪、目标层级、心跳监控。
第二层是执行服务，也就是适配器（Adapters）。 agent 跑在外部，向控制平面回报。适配器负责连接不同的执行环境——Claude Code、OpenAI Codex、shell 进程、HTTP webhook，或者任何能调 API 的运行时。
架构文档里那句话可以直接当结论用：控制平面不运行 agent，它编排 agent。agent 该在哪跑就在哪跑，然后打电话回家。
这个设计决策在「关键设计决策」一节里被列在第一条：control plane, not execution plane。同一节还列了另外四条——公司范围隔离（所有实体严格归属于唯一一家公司）、单负责人任务（原子签出防止并发抢同一个任务）、适配器无关（任何能调 HTTP API 的运行时都能当员工）、默认嵌入式（本地零配置模式自带嵌入式 PostgreSQL）。
内置适配器有四个：claude_local、codex_local、process、http。文档说明也可以为任意运行时自建适配器。每个适配器是一个包，包含三个模块——服务端模块提供 execute() 函数负责拉起或调用 agent 并做环境诊断，UI 模块提供 stdout 解析器和创建 agent 时的配置表单字段，CLI 模块提供 paperclipai run --watch 的终端格式化输出。选型细节可以看适配器怎么选那篇。
三、六个核心概念，缺一个都串不起来
文档明确说 Paperclip 围绕六个概念组织工作，按顺序过一遍。
公司（Company） 是最顶层的组织单位。每家公司有一个目标（文档举的例子是「做出第一的 AI 笔记应用，做到 100 万美元月经常性收入」）、一批员工、一套组织架构（谁向谁汇报）、一份预算（以「分」为单位的月度支出上限），以及一套任务层级——所有工作都能回溯到公司目标。
Agent（员工） 每个员工都是一个 AI agent，身上挂五样东西：适配器类型与配置（决定它怎么跑）、角色与汇报关系（头衔、向谁汇报、谁向它汇报）、能力描述（一段简短说明它干什么）、预算（单个 agent 的月度支出上限）、状态（active / idle / running / error / paused / terminated 六种）。
关键约束在这句：agent 被组织成严格的树形层级，除 CEO 外每个 agent 恰好向一位经理汇报。这条链路被用于升级（escalation）和委派。
Issue（任务） 是工作的基本单元，带标题、描述、状态、优先级、一个负责人（同一时刻只有一个）、一个父任务（由此构成一路回溯到公司目标的可追溯层级），以及所属项目和可选的目标关联。
状态机在文档里画得很清楚：
backlog -> todo -> in_progress -> in_review -> done
|
blocked
终态是 done 和 cancelled。这里有个实现细节值得记住：转入 in_progress 需要一次原子签出（atomic checkout），同一时刻只有一个 agent 能持有某个任务；如果两个 agent 同时尝试认领同一任务，其中一个会拿到 409 Conflict。
委派（Delegation） CEO 是主要的委派者。你设定公司目标之后，CEO 会：先制定战略并提交给你审批 → 把批准后的目标拆成任务 → 按角色和能力把任务分给各个 agent → 需要时申请雇佣新 agent（你可以开启雇佣审批作为闸门）。文档的建议是你不必手工分派每一个任务，设好目标让 CEO 去组织，你只审批关键决策、监控进度。
心跳（Heartbeat） agent 不是持续运行的，它们在心跳里醒来——由 Paperclip 触发的短暂执行窗口。触发来源文档列了五种：
| 触发方式 | 说明 |
|---|---|
| Schedule | 周期性定时器，例如每小时一次 |
| Assignment | 有新任务分派给该 agent |
| Comment | 有人 @ 提到该 agent |
| Manual | 由人在 Web 界面手动触发调用 |
| Approval resolution | 某个待决审批被批准或驳回 |
每次心跳里，agent 的动作序列是固定的：确认自己的身份 → 查看分派给自己的任务 → 挑选工作 → 签出任务 → 干活 → 更新状态。这套东西官方称为心跳协议（heartbeat protocol），它以「技能」的形式放在仓库的 skills/paperclip/ 里。
治理（Governance） 有些动作必须经过董事会（也就是人）审批：agent 申请雇佣下属必须批准；CEO 的初始战略方案必须批准；董事会可以随时越权暂停、恢复、终止任意 agent，也可以重新分派任意任务。每一次变更都会记入活动审计轨迹。
四、一次心跳里到底发生了什么
架构文档给了完整的请求链路，六步：
- 触发 —— 调度器、手动调用，或事件（任务分派、@提及）触发一次心跳
- 适配器调用 —— 服务端调用所配置适配器的
execute()函数 - Agent 进程 —— 适配器带着 Paperclip 的环境变量和一段 prompt 拉起 agent（例如 Claude Code CLI）
- Agent 干活 —— agent 反过来调用 Paperclip 的 REST API，查看分派、签出任务、执行工作、更新状态
- 结果捕获 —— 适配器捕获 stdout，解析用量与成本数据，提取会话状态
- 运行记录 —— 服务端记录本次运行结果、成本，以及供下次心跳使用的会话状态
第 4 步是这套架构里最容易被误解的地方：agent 不是被喂了一堆参数然后被动执行，它是主动回调 REST API 来自己拿活、自己汇报的。这也解释了为什么「任何能调 HTTP API 的运行时都能当员工」这句话在技术上成立。
第 6 步的会话状态回传，对应 README 里说的「持久化 agent 状态」——agent 跨心跳恢复同一个任务的上下文，而不是每次从零开始。
五、技术栈：Node + Express + Postgres + React
架构文档给的技术栈表，原样列在这里，方便你判断部署成本：
| 层 | 技术 |
|---|---|
| 前端 | React 19、Vite 6、React Router 7、Radix UI、Tailwind CSS 4、TanStack Query |
| 后端 | Node.js 20+、Express.js 5、TypeScript |
| 数据库 | PostgreSQL 17（或嵌入式 PGlite）、Drizzle ORM |
| 认证 | Better Auth（会话 + API key） |
| 适配器 | Claude Code CLI、Codex CLI、shell 进程、HTTP webhook |
| 包管理器 | pnpm 9 + workspaces |
仓库是 monorepo，顶层目录职责很清楚：ui/ 是 React 前端，server/ 是 Express API（里面 src/adapters/ 放执行适配器），packages/ 下面有 db/（Drizzle schema 与迁移）、shared/（API 类型、常量、校验器）、adapter-utils/（适配器接口与助手）和 adapters/（claude-local、codex-local 两个内置适配器包），skills/ 放 agent 技能，cli/ 是 CLI 客户端。
手工跑起来的命令 README 写得很短：
git clone https://github.com/paperclipai/paperclip.git
cd paperclip
pnpm install
pnpm dev
这会在 http://localhost:3100 起 API 服务端，嵌入式 PostgreSQL 会自动创建，无需额外配置。环境要求是 Node.js 20+、pnpm 9.15+。另有一条托管安装路径（install.sh 加校验和），细节和坑放在快速安装那篇讲。
六、官方自己划的六条边界
README 有一节专门写「Paperclip 不是什么」，这是判断要不要用它最省时间的一节，原样转述：
| 不是 | 官方说明 |
|---|---|
| 不是聊天机器人 | agent 有工作，不是聊天窗口 |
| 不是 agent 框架 | 「我们不告诉你怎么造 agent，我们告诉你怎么经营一家由 agent 组成的公司」 |
| 不是工作流编排器 | 没有拖拽式流水线；Paperclip 建模的是公司——组织架构、目标、预算、治理 |
| 不是 prompt 管理器 | agent 自带 prompt、模型和运行时 |
| 不是单 agent 工具 | 这是给团队用的；只有一个 agent 大概不需要它，有二十个就确实需要 |
| 不是代码评审工具 | 它编排工作，不编排 pull request，评审流程自备 |
倒数第二条基本就是选型判据。README 的「Paperclip 适合你，如果……」清单里也是同一口径：想做自主 AI 公司、需要协调多种不同 agent（OpenClaw、Codex、Claude、Cursor）朝同一目标、同时开着二十个 Claude Code 终端已经数不清谁在干嘛、想让 agent 全天候自主跑但仍要能审计和随时插话、想监控成本并强制预算。
反过来说：如果你手里只有一个 agent、一个仓库、一条流水线，这套控制平面带来的组织建模成本大概率是负收益。
七、什么时候不适用，以及还有哪些没做完
先说成本这一层。预算是硬机制不是提示：README 写明 token 与成本按公司、agent、项目、目标、任务、供应商、模型多个维度追踪，预算策略带警告阈值和硬停止，超支会自动暂停 agent 并取消排队中的工作。这是好事也是坑——预算配小了，你会看到一群 agent 集体停摆。这块单独写了一篇预算超支。
再说尚未提供的能力。README 的 Roadmap 里有一批条目仍标为未完成，官方标注为计划中、目前尚未提供，包括：Memory / Knowledge（记忆与知识库）、Work Queues（工作队列）、Self-Organization（自组织）、Automatic Organizational Learning（自动组织学习）、CEO Chat、MAXIMIZER MODE、Desktop App、Bring-your-own-ticket-system（把 Asana / Linear / Jira 当入口）、Connected Apps（一键集成）。云端部署一项标为进行中，其中多租户隔离与公司导入导出已交付。
「自带工单系统当入口」这条尤其值得注意：如果你团队的现有流程强绑定 Jira 或 Linear，眼下没有官方桥接，只能在 Paperclip 里另起一套任务体系。README 在 FAQ 里也承认了这个问题的存在——有人问为什么不直接把 OpenClaw 指向 Asana 或 Trello，官方的回答是 agent 编排在「谁签出了哪个任务、会话怎么维持、成本怎么监控、治理怎么建立」这些地方有微妙之处，Paperclip 替你处理掉了；这是官方文档的说法。
还有几点是文档没有给出答案的，别指望从这篇文章里读到：单实例能撑多少 agent 并发、心跳调度的实际延迟、多大规模下 PostgreSQL 会成为瓶颈——这些官方文档都未说明，我们也没有实测数据可提供。
最后是心态上的：这套系统的默认假设是「你设目标，CEO 拆任务，agent 自己认领」。这意味着你交出去的不只是执行，还有一部分任务拆解权。审批门（战略审批、雇佣审批）是官方留给你的刹车，但刹车要你主动去踩。真要动手，建议从建第一家公司开始摸清这条链路——第一家公司怎么建那篇按顺序走了一遍。
延伸阅读
- 本专题共 40 篇，完整分组目录见专题页
- Paperclip 怎么装：onboard 一条命令背后的四种安装方式与更新回滚
- Paperclip 三种部署模式怎么选：local_trusted 与 authenticated 的私有、公网差别
本文依据 Paperclip 官方仓库（github.com/paperclipai/paperclip，MIT 协议）的 docs/ 用户文档
与 doc/ 下的规范、运维与连接器手册整理，核对日 2026-08-17。
我们没有部署或运行过 Paperclip，因此不涉及界面外观与操作手感；
部分规范文档描述的是目标架构而非当前实现，文中已就地标注，不构成对实际行为的保证。
请以仓库最新内容为准。