你打开了 20 个 Claude Code 窗口

这是很多 AI 重度用户的真实处境：一个窗口在写代码，一个在回邮件，一个在做市场分析，一个在运行客服……

问题随之而来：哪个窗口在做什么？它们之间如何协调？花了多少钱？如果你重启电脑，所有上下文都消失了。

Paperclip 是"AI 公司的操作系统"

Paperclip 的定位非常清晰：它不是一个 AI，而是管理 AI 的平台。就像公司需要 HR 系统、财务系统、项目管理工具，你的 AI 团队也需要一套管理基础设施。

Paperclip 解决了什么问题？

启动方式：一行命令

Paperclip 的设计哲学是零摩擦。整个平台本地自托管，内置 内嵌 PostgreSQL 数据库，无需额外配置：

# 方法一：最快启动（npx 直接运行）
npx paperclipai onboard --yes

# 方法二：手动安装
git clone https://github.com/paperclipai/paperclip.git
pnpm install
pnpm dev
            

真实公司的三层结构

Paperclip 的数据模型直接映射了真实公司的组织方式。想一想你熟悉的公司结构——

代理不只是"AI 实例"——它有身份

在 Paperclip 里，每个 代理 都有完整的"工作档案"：

AI 公司的"对话"

看看当 CEO 代理收到一个用户需求时，组织内部是如何流转的——

组织架构知识测试

AI 代理像什么？不是一直在线的服务员

很多人以为 AI 代理是"永远在线的机器人"。Paperclip 的设计更聪明：代理是按需唤醒的。

更准确的比喻是一位随叫随到的值班医生：有人呼叫（心跳触发），医生起来处理，处理完继续休眠，等待下次呼叫。这样既省资源，又能持续可用。

一次心跳执行的完整流程

当 Paperclip 决定唤醒一个代理时，内部走过了 9 个步骤。让我们一步步追踪：

持久会话：跨心跳的记忆

Paperclip 最重要的特性之一：会话状态持久化。代理不会每次唤醒都"忘了上次做了什么"。

// 心跳 #1（周一下午）
agent.execute({
  task: "实现用户登录功能",
  session_state: null  // 首次运行
})
// 运行 45 分钟后，心跳时间到
saveSessionState({ progress: "JWT 已完成，还需要 refresh token" })

// 心跳 #2（周一晚上）
agent.execute({
  task: "实现用户登录功能",
  session_state: { progress: "JWT 已完成，还需要 refresh token" }
})  // 从上次进度继续
            

心跳机制知识测试

AI 失控的两种方式

使用 AI 代理的人都遇到过这两个噩梦：

Paperclip 用两套系统同时解决这两个问题：预算控制和治理审批。

多层预算系统

Token 消耗被 Paperclip 在五个维度上追踪和限制：

治理审批：你才是最终决策者

有些操作太重要了，不能让 AI 独立决定。Paperclip 的治理系统给你设置一道"人工审查关卡"：

预算与治理知识测试

Paperclip 的完整技术架构

现在你了解了各个部分，让我们把它们拼在一起——Paperclip 服务器的 12 个子系统：

为什么 Paperclip 不只是另一个任务管理工具

很多人第一反应：把 AI 指向 Asana 或者 Linear 不就行了吗？这忽略了代理协调的核心难题：

// 问题 1：谁在处理这个任务？
// Asana 没有"代理正在运行"的概念
// 两个代理可能同时开始同一个任务

// 问题 2：代理能"读"任务但能做什么？
// 没有内置的 Secrets 注入
// 代理需要自己找 API 密钥

// 问题 3：花了多少钱？
// Asana 不知道代理调用了多少 token
// 没有预算约束机制
            

综合测试：你懂 Paperclip 了吗？