paperclip
我们不需要死读硬记，我们需要用基本的知识来发展和增进每个学习者的思考力。—— 列宁
Paperclip：当 AI Agent 不再只是工具，而是成为一支可以被管理的团队
项目地址：https://github.com/paperclipai/paperclip
当 AI Agent 的数量从一个、两个，逐渐增长到十个、二十个，真正令人头疼的事情，往往不再是“它能不能完成任务”。
而是：
谁正在做什么？
谁应该向谁汇报？
这项工作服务于哪个目标？
多个 Agent 会不会重复执行同一件事？
成本会不会在无人察觉时不断攀升？
一个 Agent 做出的判断、调用过的工具、留下的成果，能否被完整追溯？
Paperclip 给出的答案很直接：不要只把 AI Agent 当作一个个独立的聊天窗口、命令行终端或自动化脚本，而要把它们组织成一家公司。
它是一套开源的 AI Agent 团队编排系统，由 Node.js 服务端与 React 界面构成。用户可以接入自己的 Agent，为它们分配目标、任务、职责与预算，并在统一面板中追踪工作进展、成本、审批、活动与交付结果。
如果说一个 Agent 像员工，那么 Paperclip 想成为管理这些员工的公司本身。
从管理任务，走向管理业务目标
许多协作系统从任务开始：创建一张卡片、分配一个负责人、记录进度、等待完成。
Paperclip 的起点更靠上游。
它强调管理的是业务目标，而不只是某一条待办事项。
一个组织可以先定义目标，再组建由 CEO、CTO、工程师、设计师、营销人员等角色构成的 Agent 团队。每个 Agent 都可以承担不同职责，并在组织结构、权限边界、预算限制与治理规则之下工作。
任务不再是一张孤立的工单，而能够沿着项目、目标与公司使命向上回溯。
于是，Agent 不只知道“做什么”，还能够获得“为什么做”的上下文。
这种目标对齐机制，让工作不只是从任务列表中被取走，而是被放进一条具有方向感的业务链路里。
一个看起来像任务管理器的 Agent 公司控制台
Paperclip 的界面看起来像任务管理工具，但其底层并不止于工单。
它涵盖组织架构、Agent 协调、预算、治理、工作区、例行任务、密钥存储、插件、活动记录与公司迁移等系统。
从结构上看，Paperclip Server 是一个控制平面，围绕多项核心能力展开：
1 | PAPERCLIP SERVER |
在这个控制平面之下，Claude Code、Codex、命令行 Agent、HTTP 或 Web Agent 等不同执行方式，都可以接入同一个组织体系。
Paperclip 并不要求所有 Agent 使用同一种模型、同一种运行时或同一种交互方式。
只要一个 Agent 能够接收心跳信号，它就可以被纳入团队。
自带 Agent，而不是被单一运行时绑定
Paperclip 的一个关键思路，是让组织层与 Agent 实现层分离。
它不是一个要求你按照固定模式构建 Agent 的框架，也不是要求所有 Agent 使用相同模型的运行平台。
相反，它允许用户带入自己的 Agent。
Claude Code、Codex、Cursor、Bash、HTTP Agent，以及其他可接收心跳信号的运行时，都可以成为组织里的成员。
这意味着 Paperclip 更关注的是：
- Agent 在组织中承担什么角色
- Agent 可以访问什么资源
- Agent 被分配什么工作
- Agent 的任务如何与目标关联
- Agent 的成本如何被约束
- Agent 的工作如何被审批和审计
它不替用户规定 Agent 的内部实现，而是管理 Agent 所在的组织与工作环境。
四根支柱，搭起一支 Agent 团队
Paperclip 将 AI Agent 组织的运转归纳为四个支柱。
| 支柱 | 面向对象 | 覆盖内容 |
|---|---|---|
| Agentic Task Manager | 日常协作中的所有参与者 | 任务、审批、审核关卡、主动工作的 Agent 同事、可审计例行流程与工作流 |
| Org Chart for Agents | 管理者 | 人类与 Agent 混合组织架构、职责、委派、专业分工、角色与权限边界 |
| Agent Employee Training | 能力建设者 | Skill Studio、共享组织技能、评估、测试运行、主动学习循环与质量指标 |
| Agentic OS | IT 与平台团队 | 跨提供商运行时、沙箱、集成、MCP 服务、单点登录、治理、基于角色的访问控制与成本控制 |
这四部分并非彼此独立。
任务需要执行者，执行者需要角色与权限，角色需要技能与评估，所有工作又需要运行基础设施、预算控制与治理体系托底。
Paperclip 试图把这些层面放到同一个系统中，让 Agent 团队不只是“同时运行很多机器人”，而是具备组织、协调与监督能力。
组织架构，让每个 Agent 有岗位、有汇报线、有边界
当 Agent 数量较少时，人们或许还能通过窗口标题、终端标签或笔记记住每个 Agent 在做什么。
但随着任务增多，这种方式会迅速变得混乱。
Paperclip 提供组织架构能力，让 Agent 拥有角色、职位、汇报关系、权限与预算。
在这里，Agent 不再只是一个临时启动的执行进程。
它可以是一名工程师、一名设计师、一名市场人员，也可以承担特定项目中的管理职责。它知道自己的工作边界，也可以在组织层级中接收或发起委派。
组织架构不只是为了让界面看起来像一家公司。
它承担着责任划分、权限控制、任务委派与治理边界等实际作用。
当多个 Agent 同时参与同一项业务时，谁负责执行、谁负责审核、谁能够批准、谁拥有预算，都会成为系统中的明确结构。
心跳机制，让 Agent 在合适的时候醒来工作
Paperclip 通过 Heartbeats 让 Agent 按计划唤醒、检查任务并执行行动。
这种机制让 Agent 不必始终处于人工盯守状态。
当任务被分配、有人提及 Agent、例行工作到达执行时间，或者系统满足特定触发条件时，Agent 可以被唤醒并进入工作流程。
README 中描述的心跳执行系统包括数据库支持的唤醒队列、任务合并、预算检查、工作区解析、密钥注入、技能加载与适配器调用。
每一次运行都会形成结构化日志、成本记录与工作输出。
对于例行任务，Paperclip 支持基于 cron、Webhook 与 API 的触发方式。
每次例行任务执行时，系统会创建可追踪的工单，并唤醒被分配的 Agent。
这意味着客户支持、社交内容、报告生成等重复性工作，可以被组织为持续运行的业务节奏，而不是依赖人工记忆去逐项触发。
任务系统，不只是待办清单
Paperclip 的任务系统以工单为核心。
工单可以关联公司、项目、目标和父级任务，也可以记录阻塞依赖、评论、文档、附件与工作产物。
任务领取与预算限制采用原子执行方式。
这意味着任务的领取与预算约束能够在同一个受控过程内完成，避免多个 Agent 重复处理同一任务，也避免工作在预算已被耗尽时继续失控执行。
对于多 Agent 协作而言，这种细节非常重要。
当多个 Agent 都具备处理同类任务的能力时，系统需要清楚地知道任务是否已经被领取、是否存在阻塞、是否需要审批、是否已经完成，以及下一步应该由谁接手。
Paperclip 将这些状态放进正式的工作系统里，而不是散落在各个 Agent 的上下文中。
上下文不会在下一次心跳时消失
Agent 在重复唤醒时，一个常见问题是上下文断裂。
它可能记得上一次的任务标题，却忘记已经完成了哪些部分、为什么采取了某种方案、接下来该处理什么阻塞。
Paperclip 强调持久化 Agent 状态。
Agent 可以跨越多次心跳恢复同一项任务上下文，而不是每次启动都从零开始重新理解工作。
这使得工作过程更接近持续推进，而不是一连串互不相连的短暂执行。
任务上下文还可以从任务一路向上关联到项目与目标。
对于 Agent 而言，获得的不是一句孤立的指令，而是带着目标祖先关系的工作背景。
成本控制，为 Agent 团队装上刹车
多个 Agent 并行运行时，成本管理往往不是锦上添花，而是基础设施的一部分。
Paperclip 提供按公司、Agent、项目、目标、工单、提供商与模型维度追踪 Token 与成本的能力。
它支持作用域化预算策略、预警阈值与硬性停止机制。
每个 Agent 可以拥有月度预算。当预算达到限制时，Agent 会停止继续执行。
这让成本不再只是事后汇总的统计数字，而能够在运行过程中参与控制。
对于可能存在循环执行、重复调用或大规模并行的 Agent 环境而言，预算硬停止机制让系统具备明确的边界。
Paperclip 不只是告诉用户“花了多少钱”，也尝试在成本不断扩大之前阻止失控。
治理不是附加功能，而是运行的一部分
当 Agent 开始承担持续性工作，治理问题会自然浮现。
谁能批准新的 Agent 加入组织？
谁能修改策略？
谁能暂停某个 Agent？
哪些工作必须经过审核？
哪些操作需要进入审批流程？
Paperclip 提供审批工作流、执行策略、审核与批准阶段、决策追踪、预算硬停止、Agent 暂停、恢复与终止，以及完整审计日志。
治理配置本身也具备版本化与回滚能力。
当某项变更不符合预期时，系统可以回退到此前的配置状态。
这使得治理不只是口头上的规范，而成为可以在系统中实际执行的约束。
对于需要让 Agent 自主工作，同时又希望保留人工控制点的团队而言，这种设计提供了一种折中：让 Agent 推进工作，但不让重要边界脱离管理。
每一次对话、决定与工具调用，都可以留下痕迹
Paperclip 的 Ticket System 强调对话追踪、决策解释、工具调用追踪与不可变审计日志。
活动与事件系统会记录会改变状态的操作、心跳状态变化、成本事件、审批、评论与工作产物。
这些记录不是为了制造更多日志，而是为了让运营者能够回看：
- 哪个 Agent 在什么时间执行了什么工作
- 任务如何被领取、推进与完成
- 某项审批为何被通过或拒绝
- 成本在何处产生
- 哪个工具调用参与了某次执行
- 某项工作成果由谁产生
- 某个 Agent 为什么被暂停或恢复
当 AI Agent 参与实际业务时，可追溯性会成为组织能力的一部分。
Paperclip 将活动记录设计成持久化的运行历史，让团队能够理解已经发生的事情，而不是只看到当前状态。
多公司隔离，一套部署可以管理多个组织
Paperclip 支持多公司模式。
单个部署可以运行多个公司，并且每个实体都以公司为作用域，从而实现独立的数据与审计记录。
这意味着一个控制平面可以服务多个彼此隔离的组织。
不同公司可以拥有自己的 Agent、项目、目标、工单、预算、活动和审计轨迹。
README 中还提到公司可移植性能力，可以导出和导入完整组织结构，包括 Agent、技能、项目、例行任务与工单。
导出与导入过程会进行密钥清理与冲突处理。
1 | paperclipai company export <company-id> --out ./my-export |
组织不再只是某个部署内部不可移动的一组数据，也可以被打包、迁移与重建。
工作区与运行时，让 Agent 在正确的位置工作
Agent 要完成工作，不只需要任务描述，还需要合适的执行环境。
Paperclip 提供项目工作区、隔离执行工作区与运行时服务。
隔离工作区包含 Git worktrees 与操作员分支等形式，运行时服务则覆盖开发服务器与预览地址等能力。
这意味着 Agent 不只是被告知“请完成这项工作”，还能够在对应的目录、分支与运行环境中开展执行。
任务、执行环境、Agent 身份与成本记录之间，被组织在同一套控制平面中。
对于代码、文档、内容、运营等不同类型的工作，这种工作区概念让 Agent 的执行过程更接近实际团队协作，而不只是一次脱离环境的模型调用。
技能注入，让 Agent 在运行时获得组织能力
Paperclip 提供技能管理、Skill Studio 与组织共享技能能力。
README 中将其描述为运行时技能注入：Agent 可以在不重新训练的前提下，于运行时学习 Paperclip 工作流与项目上下文。
这意味着技能可以作为组织资产被管理和复用。
一个团队不必让每个 Agent 都从头理解相同的工作流程。组织可以形成共享技能，让不同 Agent 在执行时获得一致的操作方法、项目背景与质量要求。
与此同时，Paperclip 也提供 Agent 评估与已保存测试运行能力。
评估框架覆盖任务领取、进度更新、阻塞报告、审批请求、公司边界、MCP 网关调用、限流处理、缺失凭据处理、会话撤销、记忆提供方绑定与记忆溯源审计等行为。
这让 Agent 的可靠性不只依赖主观感受，也可以通过行为测试被持续观察。
插件与 MCP 网关，让系统可以继续延伸
Paperclip 提供实例级插件系统。
插件通过进程外 Worker 运行，并通过能力控制的宿主服务、任务调度、工具暴露与界面扩展机制参与系统。
这种设计让系统能够在不直接修改核心代码的情况下扩展能力。
README 中还列出 MCP Tool Gateway 与 Apps，用于受治理的工具访问。
在多 Agent 环境中，工具调用并不仅仅是“能不能调用”的问题。
它还涉及权限、审批、凭据、审计记录、访问范围与行为边界。
Paperclip 通过治理与网关能力，将工具使用纳入组织运行规则之中。
密钥不该无意间进入提示词
AI Agent 在处理实际工作时，常常需要访问令牌、密钥、服务配置与其他敏感信息。
Paperclip 提供实例级与公司级密钥管理，支持加密本地存储、提供商支持的对象存储、附件与工作产物管理。
敏感值不会在没有适当范围的情况下进入提示词。
这一点与工作流、预算和审批一样，都属于 Agent 组织化运行的基础条件。
当多个 Agent 同时使用不同服务时，密钥如何存储、向谁暴露、在何时注入，都会直接影响系统边界。
它不是什么
Paperclip 的定位同样清晰。
它不是聊天机器人。
Agent 在这里拥有工作岗位，而不是只存在于聊天窗口中。
它不是 Agent 框架。
它不规定用户该如何构建 Agent，而是用于组织和运行由 Agent 构成的团队。
它不是拖拽式工作流构建器。
它用组织架构、目标、预算与治理来建模公司，而不是用可视化连线来描述流水线。
它不是提示词管理器。
Agent 可以携带自己的提示词、模型与运行时，Paperclip 管理的是这些 Agent 所属的组织。
它也不是面向单个 Agent 的工具。
如果只有一个 Agent，Paperclip 未必是必须的；但当 Agent 数量开始增长，协调、追踪、预算、审批与上下文管理就会变成真实的管理问题。
快速启动
Paperclip 支持开源、自托管运行，不需要 Paperclip 账号。
可以通过命令启动引导流程：
1 | npx paperclipai onboard --yes |
默认快速启动路径使用受信任的本地回环模式。
如果需要使用局域网绑定或 Tailnet 绑定，可以在初始化时明确选择绑定方式。
1 | paperclipai onboard --yes --bind lan |
1 | paperclipai onboard --yes --bind tailnet |
也可以从源码启动开发环境。
1 | git clone <repository-url> |
启动后，API 服务运行在本地 3100 端口，并会自动创建嵌入式 PostgreSQL 数据库。
开发环境需要 Node.js 20 或更高版本，以及 pnpm 9.15 或更高版本。
面向移动端的管理体验
Paperclip 强调可以从手机管理自主运行的业务。
这一点背后并不是简单地把桌面页面缩小到移动设备，而是承认 Agent 团队的运行不一定发生在电脑前。
任务是否积压、某个 Agent 是否卡住、预算是否接近阈值、审批是否等待处理、例行任务是否已经执行，这些运营信息需要被随时掌握。
Paperclip 提供移动端开发命令，用于在手机和平板设备上提供预构建界面，并将 API 请求代理到服务端。
1 | pnpm dev:mobile |
如果需要同时运行完整开发环境与移动端界面，可以使用：
1 | pnpm dev:both |
Paperclip 试图解决的，不只是 Agent 调用问题
一个人同时打开许多 Claude Code 终端时，最先失去的可能不是计算资源，而是可见性。
不知道哪个终端在处理哪个任务，不知道哪个 Agent 已经卡住，也不知道系统重启后上下文还能否延续。
当工作需要跨项目、跨角色、跨工具推进时，靠人工在不同窗口之间收集上下文会越来越吃力。
当 Agent 运行成本开始累积，缺乏预算限制可能让问题在被注意到之前扩大。
当日常工作需要反复触发时，依靠手动提醒又会让自动化失去意义。
Paperclip 的目标，就是把这些分散问题放进一个组织级系统中。
它把任务管理、组织架构、运行时、预算、心跳、审批、审计、技能、插件、密钥和可移植性连接起来，让 AI Agent 不再只是若干彼此独立的自动化工具。
从“盯着 Agent 工作”，到“运营一支 Agent 团队”
AI Agent 的价值并不只在于单次完成某个任务。
当它们能够持续承担工作、协同处理事务、沿着目标推进、接受预算限制、经过审批流程并留下完整活动轨迹时，Agent 才开始具备组织成员的形态。
Paperclip 想构建的，正是这样一个运行环境。
它让 Agent 有岗位、有目标、有权限、有预算、有上下文、有工作区，也有需要遵循的治理边界。
在这里，用户不必只是在多个终端之间来回巡视。
用户可以开始像经营一个团队那样，定义方向、配置组织、分配责任、设置限制、审查结果，并持续观察一群 AI Agent 如何把工作向前推进。