creeta 1小时前 · 2026-09-01 04:46:12 · 1 阅读

Paperclip 招聘的是智能体，而不是提示词——还有一个人类董事会

Paperclip（73.5k stars）运行着一家公司式的 AI agent 协作系统：由 CEO、营销、工程、运营等 agent 分工协作，并设有严格的预算上限，

Sungjae Lee 2026 年 7 月 13 日 Paperclip hires agents, not prompts — and a human board

Screenshot of https://github.com/paperclipai/paperclip

Paperclip 是一个开源编排层。它不是让单个助手回答 prompt，而是把一家公司建模为由多个专业 AI agent 协同组成的团队——正如它的宣传语所说：“如果 Claude 是一名员工，那么 Paperclip 就是一家公司。”你无需面对一个聊天窗口，而是先定义使命，再由 Paperclip 搭建一套按职责划分的 agent 组织架构，让它们围绕共同目标逐级汇报、分派任务并推进工作。

在架构上，Paperclip 刻意采用了传统方案：以 Node.js 服务器和 React 控制面板为核心，底层使用 PostgreSQL，并支持完全自托管，无需注册 Paperclip 账号。运行一条 onboarding 命令，就能在浏览器向导中创建你的第一家公司：

npx paperclipai onboard --yes

这条命令同时记录在代码仓库和官方网站中，是最快体验“公司，而不是聊天机器人”这一抽象方式的途径。下面将进一步介绍 Paperclip 如何招募、限流和治理这些 agent。

使命如何变成一个部门

How a Mission Becomes a Department (source: i.mscdn.ai)

“招聘”这一步，让 Paperclip 的公司抽象真正落地。在引导过程中，你只需提供一项使命和一个目标，AI CEO agent——多篇报道中称其为“Zeus”——就会分析目标，判断需要哪些角色，并生成一份由专职 agents 组成的组织架构，包括职位名称、岗位描述和汇报关系。这样一来，在任何工作开始前，营销、工程、销售和运营 agents 就已经被接入同一套层级体系，而不是由一个 assistant 单独响应 prompt。

之后，每张工单都会携带项目所称的“目标溯源”（goal ancestry）：使命 → 目标 → 项目 → 任务。接手任务的 agent 可以沿着这条链路追溯上层的“为什么”，而不是只根据一条孤立指令行动。实际效果是：相比只被告知“起草一封发布邮件”的 agent，另一个同时看得到发布目标和上层使命的 agent，更能准确把握邮件应服务的方向，从而决定语气、内容主张和优先级。

执行依靠的是心跳机制，而不是由用户驱动的轮询循环。Agents 按计划唤醒，检查分配给自己的工作，执行任务，并根据需要沿汇报链向上或向下委派。底层还提供了两项可靠性机制：

原子化任务签出——任务以原子方式被认领，确保两个 agents 不会同时接手同一张工单、重复劳动。
跨心跳持久化 agent 状态——agent 再次唤醒时，会带着此前的上下文继续任务，而不是从头开始。

这个状态模型值得提前说明：在单个任务的生命周期内，上下文可以跨心跳持续保留；但实际体验者指出，agents 默认不会记住此前的会话，因此更长周期的记忆仍需要额外设计一层机制。组织架构负责安排工作；要让上下文超越单个任务持续存在，仍然要靠操作者。

强制限流与董事会席位

组织架构决定谁负责工作，控制平面则决定在人工介入前，代理最多能推进到什么程度。Paperclip 从五个层级追踪 token 和资金消耗——公司、代理、项目、目标和 provider——因此每笔成本都能明确归属，而不是混在一起。系统会在达到上限前触发预警；当使用率达到 100% 时，它会自动限流并暂停超支的代理，而不是指望代理自行停下。这样的设计理念非常明确：

“由系统强制执行硬性限制，而不是靠约定。”——Paperclip 项目文档（来源：paperclipai/paperclip）

对于那些见过工具循环一夜之间耗尽 API 配额的人来说，这种区别至关重要。大多数代理运行时都把预算控制交给调用方；而在 Paperclip 中，预算是一个一等、可限定作用域的基础能力。这也是 Paperclip 与需要自行拼装的底层框架之间，更清晰的区别之一。

治理机制采用董事会模式。人类负责批准招聘和战略，并始终拥有暂停、恢复、重新分配、覆盖或终止任何代理的权力。整个设计建立在两条硬性约束之上：代理不能自主招聘其他代理，AI CEO 也不能执行未经审核的战略。其明确原则——“自治是你授予的特权，而不是默认状态”——可以看作是对多代理演示中挥之不去的失控焦虑的直接回应。你拥有的是一个董事会席位，而不是旁观者的入场券。

责任追溯依靠一条只追加、不修改的审计记录。每张工单都有负责人、状态和讨论串；每次工具调用和 API 请求也都会被记录，且不允许编辑或删除。对运营人员来说，这种不可变性决定了你能否还原代理究竟做了什么，而不是只能祈祷它表现良好——这也是成熟的 workforce platform 会将自治能力与审计导出、审批阈值配套使用的原因。还有一点值得注意：这些防护措施的价值，取决于是否有人真正查看它们。因此，最好把预算预警和审计日志接入团队实际关注的渠道。

73.5k Stars，v2026.707.0：仓库快照

Paperclip 的发展势头，从 GitHub 数据中可见一斑。不过，这些数据更适合视为项目方公布的数据，而非经过独立审计的结果。这个开源项目于 2026 年 3 月初发布，约三周内就突破了 30,000 个 star。到 2026 年 7 月抓取数据时，该仓库已有约 73,500 个 star 和 13,700 个 fork，最新版本为 2026 年 7 月 7 日发布的 v2026.707.0。这种带日期的版本编号，加上持续发布的节奏，说明项目处于积极维护状态，而不是发布后短暂走红。

它采用的是常见的自托管技术栈：基于 PostgreSQL 的 Node.js 服务端和 React 控制面板，由 Paperclip Labs, Inc. 以 MIT 许可证发布。在本地运行需要 Node.js 20+ 和 pnpm 9.15+。项目内置了 Postgres，方便快速本地运行；生产环境则建议使用外部 Postgres。首次配置只需执行一条命令：npx paperclipai onboard --yes，随后会在浏览器中打开向导，用于创建第一家公司。

对于正在评估 Paperclip 的团队来说，README 中有两项说明尤其值得关注。一次部署可以支持多个公司彼此隔离，每家公司都拥有完全独立的数据；同时，公司还可以作为模板导出和重新导入，过程中会自动清理密钥，便于安全分享。需要注意的是：另一轮并行调研未能通过实时搜索找到官方文档、定价信息或安全页面，因此这些数据应视为来自代码仓库和官方网站的资料，尚未经过第三方验证。

接入任意执行器——只要它能接收心跳信号

Paperclip 刻意不绑定特定模型或运行时：任何能够接收心跳信号的 agent，都可以加入组织架构。这也是代码仓库明确提出的设计原则：“任何 agent、任何运行时，共用一套组织架构。只要能接收心跳信号，就能被雇用。” 实际上，Paperclip 并不试图充当编码 agent。它位于编写代码、发送邮件或创建 pull request 的工具之上，通过更高一层的抽象来协调任务分工、追踪支出并落实治理规则，具体工作则由底层执行器完成。

目前列出的执行器覆盖了主流 agent 生态，此外还提供了两个通用入口，用来接入清单之外的工具：

执行器	类型	与 Paperclip 的关系
Claude、OpenAI Codex、Google Gemini	前沿模型驱动的编码／agent 运行时	以特定角色和汇报关系加入组织，作为工作人员运行
Cursor	以 IDE 为核心、由 linter 驱动自我纠错的 agent	由 Paperclip 编排的执行者，而非竞争对手
OpenCode	开源终端编程 agent	由 Paperclip 编排的执行者
Hermes、OpenClaw、Pi	其他 agent 运行时	通过 heartbeat 接入
Bash 适配器、HTTP webhook	通用执行钩子	可脚本化或可调用任务的通用入口

这样一来，那些看似竞争对手的工具也可以被纳入团队、充当员工。OpenCode 是一款终端编程 agent，发布时默认搭载 Grok Code Fast 免费模型（视频：DevOps Toolbox）；Cursor 则能根据 linter 输出进行自我纠错，并且一直在打造自己的多 agent 管理界面（视频：Greg Isenberg）。它们都不是 Paperclip 的架构竞争者，而是 Paperclip 可以分配任务、控制预算并进行审计的执行者。一个 Cursor 实例可以担任工程岗位，同时由 webhook 适配器向内部运营端点发送请求；二者都沿着同一条 mission → goal → project → task 链路向上汇报。

这种架构的实际优势，是在避免供应商锁定的同时兼容不同类型的执行器：团队可以把代码任务交给能力更强的编程 agent，把文案初稿交给成本更低的模型，再通过 Bash 或 HTTP 钩子完成衔接步骤，而所有工作都处于同一治理平面之下。不过，前文提到的限制依然存在——执行器列表依据的是代码仓库和官方网站，而不是经过独立验证的集成目录。因此，在用这些适配器接入自己的技术栈并完成测试前，最好先把这份名单视为厂商自述。

Paperclip vs. LangGraph、CrewAI、Relevance AI：横向比较

Paperclip 的同类产品大致分为两类：需要自行组装的框架，以及可以直接部署的产品。LangGraph、CrewAI 和 OpenAI 的 Agents SDK 都是库：你需要自己连接图结构、加入持久化机制，并自行构建治理能力。Relevance AI，以及在一定程度上 Zapier、Lindy 和 Cloudflare Agents，则以产品形式提供服务，但它们各自面向的是相邻问题，而不是“运行一家公司”这一组织架构抽象。Paperclip 的主张并不是“全面胜过它们”：它提供的是一层可部署的协调层，内置逐 agent 的预算上限和审计轨迹，而大多数框架都把这些工作留给开发者自行完成。

LangGraph 是一个面向有状态 Agent 图的底层运行时，提供持久化执行、流式处理、状态持久化和人工介入检查等能力，并通过 LangSmith 支持链路追踪与评估（来源：LangGraph 文档）。它提供了重建 Paperclip「心跳—签出」模型所需的基础能力，但不提供组织架构 UI，也没有原生的 Agent 独立支出账本。这些功能需要自行构建，否则就不存在。

CrewAI 的理念与之最为接近：它将确定性的 Flows（状态、事件、分支）与自主

原始来源： creeta