Paperclip：開源 AI 智慧體編排應用

过去一两年，单个 AI 编程智能体已经相当好用，真正的麻烦出现在「用得太多」之后。很多人同时开着十几个甚至二十个 Claude Code 终端，每个终端里一个 agent 在干活，时间一长就没人说得清谁在做什么、花了多少钱、哪些结果可以信。Paperclip 瞄准的正是这个缺口。它的自我定位很直白：如果 OpenClaw 是一名员工，那么 Paperclip 就是那家公司。它不去做又一个更聪明的单体智能体，而是在智能体之上补一层管理系统，让你管理的对象从一个个 pull request，变成业务目标本身。在整个智能体生态里，它处在编排与治理层，位置介于各家编码智能体和人类管理者之间。项目在 GitHub 上已有一万多颗星，topics 里出现了 agent-orchestration、ai-governance、agent-skills 等关键词，说明社区关心的已不只是「让智能体跑起来」，而是「让一群智能体可控地跑下去」。Paperclip 的能力可以用它自己提出的四根支柱来理解。第一根是智能体任务管理器：你只需声明意图，由智能体去做，再由你验证产出。它覆盖任务、审批与评审关卡、主动出击的智能体同事、可审计的例行流程与工作流，并支持通过 diff、截图和测试来核对结果。

第二根是智能体的组织架构图：人类和智能体共处同一张图里，有明确的职责、委派与分工，还有谁能做什么的治理规则、受限范围的密钥、公司边界、连接权限以及责任人身份。这一层是它和普通任务看板最大的区别，看上去像任务管理，底层却是组织、预算、治理和目标对齐。第三根是智能体员工培训，包括 Skill Studio 与组织内共享技能、评测与保存下来的测试运行、主动学习循环与质量指标、对智能体的绩效评估、技能的版本历史与恢复，以及可复用的团队模板。第四根是承载这一切运行的基础设施层，简介里这一部分被截断，这里不作展开。在接入方面，Paperclip 的门槛设得很低：模型和运行外壳可以按智能体分别选择，只要对象能接收心跳就算被雇佣，自定义进程、HTTP 端点和外部 adapter 包也能扩充名册。从上手路径看，Paperclip 是一个 Node.js 服务端加一个 React 界面，部署形态对前端和 Node 开发者很熟悉。README 把使用流程压缩成三步：先定义目标，比如「把某个 AI 笔记应用做到百万美元月收入」；再组建团队，从 CEO、CTO 到工程师、设计师、市场人员，任何机器人、任何提供方都行；最后审批并运行，审阅策略、设定预算，然后启动并在仪表盘上监控。它列出的兼容对象包括 OpenClaw、Claude Code、Codex、Cursor（含云端）、Gemini CLI、OpenCode、Pi、Hermes（含网关）、Grok Build 和 Kimi Code，adapter 的设置与能力可以在官方文档的 adapter 概览页查到。README 还明确说，它适合想让智能体 24 小时自主运行、同时保留审计和随时插话能力的人，也适合想用手机管理自主业务的人。项目提供 Quickstart 与文档站，配有 Discord 和 Twitter 社区，另有 Paperclip Cloud 的候补名单，说明作者在开源自托管之外也在探索托管服务。

对于已经在混用多种编码智能体的团队，最现实的试用方式，是先挑一个小目标，接入两三个熟悉的智能体，观察任务流转与成本记录是否真的比手动开终端更清晰。Paperclip 的意义在于，它把「如何管理一群 AI 员工」当成一个独立的工程问题来对待，而不是附属在某个模型或某个 IDE 里的功能。当智能体数量上来之后，权限边界、预算上限、审批关卡和绩效评估这些原本属于企业管理的概念，会变成真实的工程需求，而且谁都不想把它们重复造一遍。它选择和各家智能体保持中立，用心跳作为最小接入标准，这降低了迁移成本，也让团队不必押注单一供应商。当然风险同样明显。其一，让智能体 24 小时自主运行并围绕商业目标行动，意味着错误决策和成本失控的代价更高，预算与审批机制是否足够稳健，需要在实际使用中检验。其二，组织架构、技能训练这类抽象一旦做得太重，可能反过来增加配置负担。其三，项目依赖多个外部智能体 CLI 和接口，这些上游变动较快，adapter 的维护节奏值得关注。接下来值得观察的方向有三个：评测与技能版本管理能否真正带来可量化的质量提升，云端托管版本的形态，以及外部 adapter 生态能否持续壮大。无论结果如何，它已经给「智能体团队怎么管」这个问题提供了一个具体、可运行的答案。