Paperclip：把一群 AI 代理当成公司来管理的开源工作台
Paperclip 是一个用于分配、跟踪和审查多个 AI 代理执行的工作的工作区。
秒懂
- 它是什么？
- Paperclip 是一个用 Node.js 和 React 构建的开源编排层，把多个 AI 代理组织成带职位、预算和审批流程的团队。它解决的是多代理并行工作时无人追踪、成本失控的问题，但它的治理模型也带来新的管理负担。
- 适合谁用？
- Paperclip 适合已经同时运行多个 AI 代理、并且愿意为这些代理建立正式组织结构的团队。它不适合只跑一两个临时脚本的个人开发者，因为组织图、预算和审批流程会变成额外的管理开销。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是多代理协作时的失控问题
单个 AI 代理很好管，开一个终端，给一个提示，等结果。但当你有二十个 Claude Code 终端同时开着，每个都在跑不同的任务，情况就变了。你分不清哪个终端在做什么，重启电脑就丢失所有上下文，月底看到账单才发现成本已经失控。Paperclip 就是为这个场景设计的。它把代理当作组织里的员工，给它们职位、预算和汇报关系。你不再管理终端，而是管理一个由代理组成的公司。这个定位很明确，README 里有一句话概括了它的野心：如果 OpenClaw 是员工，Paperclip 就是公司。
心跳机制是它组织代理的核心手段
Paperclip 不要求代理持续在线，也不要求它们主动汇报。相反，它依赖心跳。代理按照调度醒来，检查待办工作，然后行动。这个设计很实用，因为它把异构的代理统一成一个模型。无论是 OpenClaw、Claude Code、Codex、Cursor，还是普通的 Bash 脚本，只要能接收心跳，就能被纳入管理。README 的原话是：如果它能接收心跳，它就被雇用了。心跳的另一个好处是持久性。任务以工单形式存在，对话有线程，会话在重启后不会丢失。这解决了多终端场景下最让人头疼的上下文丢失问题。
预算和审批：控制成本的两道闸门
成本失控是多代理系统最常见的失败模式。Paperclip 给每个代理设月度预算，一旦达到限额，代理就停止工作。这是一个硬性约束，不是事后提醒。审批流程则提供人为干预的节点：你可以审查策略、批准或否决任务、随时暂停或终止某个代理。这两个机制合在一起，构成了治理的基础。文档里强调的 governance 不是抽象概念，而是具体的操作：批准雇佣、覆盖策略、暂停代理。对于要长时间自主运行的代理团队，这种控制是必要的。但也要注意，它意味着你需要在任务开始前就设定预算和审批规则，这本身是一种前期投入。
组织图：给代理一个职位和老板
Paperclip 引入了组织图的概念。代理有层级、角色和汇报线，有老板、头衔和职位描述。这听起来像是把企业管理软件搬到代理世界，但它的实际作用是明确的：任务可以沿着组织图上下委派。CEO 代理可以把任务分解给 CTO 代理，CTO 再分配给工程师代理。每个任务都能追溯到组织的使命。这种结构适合需要分工协作的复杂目标。但它的代价是，你需要先设计这个组织图，决定谁向谁汇报，谁有什么权限。对于只有两三个代理的小项目，这个设计是过度的。README 也承认，它面向的是想要构建自主 AI 组织的用户。
运行方式和上手路径
Paperclip 是一个 Node.js 服务器加 React 前端。要运行它，你需要先克隆仓库，然后按照 README 中的 Quickstart 指引操作。具体的命令在 README 里没有完整列出，但文档站点 docs.paperclip.ing 提供了详细说明。仓库的发布节奏是版本号带日期，比如 v2026.824.1，最近一次更新在 2026 年 8 月 25 日。这说明项目处于活跃开发状态。安装后，你需要配置代理的接入方式。因为支持多种代理类型，接入方式会因代理而异。如果你用的是 OpenClaw 或 Claude Code，需要让它们能接收心跳；如果是自定义脚本，则需要实现心跳协议。这个步骤是上手的主要门槛。
局限：治理模型不适合所有场景
Paperclip 的治理模型是它的卖点，也是它的局限。如果你只是想让一个代理帮你写代码，或者跑一个简单的自动化任务，组织图、预算、审批这些概念都是多余的。你需要的可能只是一个终端复用工具。另一个问题是，它假设代理能可靠地接收心跳并执行任务。如果某个代理不支持心跳协议，或者心跳不稳定，整个编排就会出问题。README 没有提到如何处理代理故障或心跳超时的情况，这部分文档是缺失的。还有一点，多组织支持虽然提供了数据隔离，但也意味着你需要管理多个组织的配置，这增加了运维复杂度。
替代方案：任务队列与专用编排器
如果你不需要组织图和治理模型，可以考虑更轻量的方案。一个简单的任务队列，比如 BullMQ 或 Celery，可以让你把任务分发给多个 worker，并追踪完成状态。这些工具没有代理的概念，它们处理的是函数和作业，而不是有职位的员工。另一种替代是专用的 AI 代理编排器，比如 LangGraph，它提供了更细粒度的图执行控制，适合需要精确控制代理状态的场景。Paperclip 的差异在于它把管理视角放在组织层面，而不是任务层面。它关心的不是单个代理如何执行任务，而是多个代理如何像一个公司一样协作。这个差异决定了它适合的团队规模。
维护与许可：MIT 下的活跃项目
Paperclip 采用 MIT 许可证，这意味着你可以自由使用、修改和分发，只要保留版权声明。这是一个宽松的许可，适合商业使用。项目的更新频率看起来是每周一个版本，版本号直接带日期，说明维护是持续的。但要注意，活跃开发也意味着 API 和配置可能变化。如果你的团队要长期使用，需要跟踪每次发布的变更。仓库的默认分支是 master，没有提到长期支持版本。文档站点是独立托管的，但它的完整程度无法从 README 判断。在采用之前，建议查看 docs.paperclip.ing 上的文档是否覆盖了你需要的代理类型，以及是否有迁移指南。
编辑结论
Paperclip 适合已经同时运行多个 AI 代理、并且愿意为这些代理建立正式组织结构的团队。它不适合只跑一两个临时脚本的个人开发者，因为组织图、预算和审批流程会变成额外的管理开销。采用前需要先验证三件事：你的代理能否稳定发送心跳，你的业务目标能否拆解成可审查的任务，以及你是否接受把代理当作有职位的员工来管理。如果只是想要一个简单的任务队列，Paperclip 的治理模型是多余的。
社区笔记