35,000个GitHub星标，21天。这个数字放在任何开源项目上都算炸裂，但Paperclip的爆发速度尤其扎眼——它解决的不是什么酷炫的AI能力，而是一个让开发者集体头疼的脏活：管代理。
Claude Code在终端重写后端服务，OpenAI Codex在另一个窗口跑测试，Cursor改着前端组件，还有三四个标签页被忘在后台。没人知道谁在干什么，账单蹭蹭涨，任务重复做，代理们像无头苍蝇一样跑上几小时。Anthropic前员工Ivan Vendrov团队做的Paperclip，本质上就是给这群散兵游勇配了个"HR系统"。
它不是什么，比它是什么更重要
Paperclip的定位很刁钻：只做编排，不做替代。它不生成代码，不跟你聊天，不抢Claude或Cursor的饭碗。你可以把它理解为AI代理的"中间管理层"——你继续用习惯的AI工具，Paperclip负责派活、盯进度、管预算、记台账。
支持列表直接点名行业主流：Claude Code、OpenAI Codex、Cursor、Gemini CLI，任何能接webhook或heartbeat的代理都能塞进来。三五个代理以内？确实没必要。但一旦超过这个数，Paperclip就成了那个"早知道早装"的基础设施。
技术栈门槛不高：Node.js 20+、pnpm 9.15+。自带PostgreSQL，零配置开箱。一行命令npx paperclipai onboard --yes，CLI下载、模式集成、3100端口启动，一气呵成。本地模式用local_trusted认证，用户名叫"Board"，连注册都省了。
文件结构也透着一股"别让我操心"的务实：~/.paperclip/instances/default/底下config、db、secrets、logs、workspaces分门别类。每个代理有自己的workspace，数据落盘明明白白。出问题跑paperclipai doctor，自带修复 flag --repair。
"公司化"不是比喻，是字面意思
Paperclip的产品设计直接把组织管理那套搬进了代码。不是隐喻，是真正的organograma（组织架构图）、funções（职能分工）、gestão de tarefas（任务管理）、limites de orçamento（预算上限）、logs de auditoria（审计日志）。
这套抽象层的选择很有意思。开发者熟悉的工具链是原子化的——每个代理独立运行，上下文隔离。Paperclip反其道而行，用"公司"这个所有人都能直觉理解的概念做统一界面。CEO代理、Dev代理、QA代理，谁汇报谁、谁阻塞谁，一眼看清。
预算控制是另一个痛点解法。AI代理的计费模式决定了"跑飞了"是真金白银的跑飞。Paperclip给每个代理、每个任务设硬 ceiling，超支即停。审计日志则回答了那个事后必问的问题：这行代码谁让写的？什么时候？花了多少？
开源策略也选得准。GitHub仓库一公开，issue区迅速变成需求集散地。35,000星标里估计有不少是"先star为敬，等有空折腾"的观望派，但热度本身已经验证了市场——多代理编排的痛点足够普遍，足够痛。
从"能用"到"好用"的距离
快速启动之后，真正的功课才开始。Paperclip的文档在推一个概念：agent company design（代理公司设计）。不是技术配置，是组织设计——你的"公司"该有几个部门？汇报链怎么设？什么决策需要人工卡点？
这套方法论还在早期。社区里能看到各种实验：有人按微服务边界划团队，有人按开发阶段（设计-编码-测试-部署）设流水线，还有激进派在试"CEO代理"自主招聘"下属代理"的递归结构。哪种最优？没定论。Paperclip只提供脚手架，架构得自己搭。
集成深度也是个待填的坑。目前webhook/heartbeat的接入方式对主流工具够用了，但细粒度控制——比如让Paperclip直接读取Claude Code的thinking过程，或干预Cursor的编辑决策——还做不到。代理本身的黑箱属性，限制了编排层的能见度。
竞争格局也在快速变化。OpenAI、Anthropic、Google都在推自己的"代理生态"，平台级编排可能是下一个战场。Paperclip的先发优势在于中立性：不绑定任何模型厂商，开发者可以混用最优工具。但这个优势能维持多久，取决于大厂愿不愿意开放足够深的集成接口。
一个值得玩味的细节是项目命名。回形针（Paperclip）是办公桌上最不起眼的小工具，却能把散落的纸张固定成有序的整体。这个隐喻精准得有点过分——它要做的，就是把那些散落在各终端、各标签页的AI代理，别成一个能运转的组织。
你现在同时在跑几个AI代理？如果超过三个，你的"回形针"在哪里？
热门跟贴