Paperclip把20个AI塞进一台电脑

7399字。这是过去7天GitHub上增长最快的开源项目之一，也是第一个让「AI代理公司化」从概念变成可运行代码的工具。

它的名字叫Paperclip。开发者给它写的slogan很嚣张：「不是代理框架，我们不教你怎么造员工，我们教你怎么开公司。」

这话听着像吹牛。直到你发现，它真的在用HR、财务、组织架构那一套，管理20个同时运行的AI代理——而每个代理可能来自不同厂商：Claude Code、OpenClaw、Codex、Cursor，甚至你自己写的脚本。

如果你同时开过12个以上的AI编码窗口，你会立刻理解这个痛点。每个代理独立运行，互不知道对方存在，没有共享上下文，没有统一成本追踪，电脑重启一切归零。

你不是在写代码，你是在当客服。

从游戏服务器架构偷来的灵感

Paperclip的创始人显然在游戏行业待过。他把这套系统比作UE5多人游戏的专用服务器（Dedicated Server）编排层。

玩过大型多人在线游戏的都知道：当10到20个服务器实例同时运行时，你需要一个编排层来监控状态、分配负载、故障回滚。编排器从不触碰游戏逻辑本身，它只收集状态、平衡负载、重启死掉的实例。

Paperclip的工作逻辑一模一样。

它不干涉代理内部怎么干活，只负责三件事：追踪谁在做什么、掐断超预算的代理、失败时回滚。用创始人的话：「如果它能接收心跳，就能被雇佣。」

这句话写在README里，概括了整个哲学。能响应定时ping？那就可以挂牌上岗。

LangChain是单个员工的操作手册，CrewAI是团队的任务看板，Paperclip是整个公司的组织架构图加HR加财务。

这个类比精准到有点刻薄。但它确实帮你在30秒内理解三者的关系：LangChain设计单个代理的内部管道，CrewAI把多个代理链成任务流水线，Paperclip坐在两者之上，管的是编制、目标层级、预算、治理、审计追踪。

换句话说，前两者解决「怎么让AI干活」，Paperclip解决「怎么让AI不把你搞破产」。

「公司化」到底意味着什么

打开Paperclip的配置文件，你会看到熟悉的职场术语：职位（Title）、汇报线（Reports To）、OKR（目标与关键结果）、预算上限（Budget Cap）、审计日志（Audit Trail）。

每个代理被分配一个职位，比如「后端开发工程师」或「文档撰写专员」。职位附带目标层级：公司级目标拆解到部门，部门拆解到个人。预算按职位分配，花光就强制停机。

最狠的是治理规则。你可以设置：当代理尝试执行敏感操作（如删除生产环境数据库）时，必须获得上级代理的审批。审批链路可配置，支持多级会签。

这直接把AI代理的「幻觉」风险，转化成了组织流程问题。

单个Claude Code实例可能突然决定重构整个代码库，但在Paperclip里，这个操作需要「技术负责人」代理审批，而技术负责人的预算和权限也被限制。就算它疯了，公司不会跟着疯。

审计日志记录了每个代理的完整操作链：谁、在什么时间、基于什么上下文、做了什么、花了多少token。这对调试和追责至关重要——当你的「员工」是20个黑箱模型时，你需要知道是哪个黑箱搞砸了。

多厂商代理的「混合编制」

Paperclip不挑代理来源。Claude Code、OpenClaw、Codex、Cursor、甚至你自己用Python写的脚本，都可以注册为「员工」。

注册方式极简：提供一个HTTP端点，能响应心跳检查即可。Paperclip通过标准化的「雇佣协议」与代理通信，协议封装了任务分发、状态上报、预算查询等接口。

这意味着你可以把最贵的Claude Opus放在核心架构岗位，把便宜的GPT-3.5级别模型丢去写单元测试，让Cursor专啃前端代码。每个代理的token成本独立核算，部门预算超支时自动触发「裁员」——暂停低优先级代理。

一位早期用户在Discord分享了他的配置：技术负责人是Claude 3.5 Sonnet，前端专员是Cursor，测试工程师是本地运行的Llama 3，DevOps是一个调用AWS API的Python脚本。四者协作完成一个全栈项目，总成本比单用Claude Opus低67%。

这种「混合编制」在传统代理框架里几乎不可能实现。LangChain和CrewAI通常假设你使用统一的模型后端，Paperclip则把模型差异抽象成了「人力成本差异」——这正是公司管理的日常。

状态持久化：重启电脑不丢进度

用过Claude Code的人都知道一个噩梦：电脑崩溃或重启后，所有对话历史、文件修改状态、中间产物全部消失。你得从头解释需求，代理也得重新理解代码库。

Paperclip把状态管理做成了基础设施。每个代理的运行状态、任务队列、上下文窗口、中间产出，全部持久化到本地数据库。系统重启后，代理自动恢复到最后一个检查点，继续执行未完成的任务。

更进一步，Paperclip支持「组织记忆」。代理之间的通信记录、共享文档、决策依据，都被结构化为可检索的知识库。新入职的代理（新注册的模型实例）可以快速「阅读」历史会议纪要，跟上团队节奏。

这解决了多代理系统的一个核心难题：上下文碎片化。没有共享记忆，20个代理就是20个孤岛；有了组织记忆，它们才成为一个公司。

成本控制的「财务纪律」

AI代理的token成本是个无底洞。一个失控的Claude Code实例，几小时就能烧掉上百美元。20个实例同时失控？你的AWS账单会教你做人。

Paperclip的预算系统分三级：公司级、部门级、个人级。每级设置token上限和告警阈值。超支时，系统可以选择：发送告警、暂停非关键任务、或强制下线代理。

更精细的控制是「任务预算」。你可以为单个任务设置成本上限，比如「重构这个模块最多花5美元」。代理在执行过程中实时查询剩余预算，超支时优雅退出并汇报进度。

一位用户设置了「测试部门」的日预算为20美元。当某个代理的单元测试生成任务消耗了15美元仍未完成时，系统自动将任务降级为「仅生成测试框架，具体用例由人工补充」。财务纪律转化为技术决策。

这种设计把「成本意识」编码进了系统架构。不是事后看账单肉疼，而是事前设好红线，让代理在约束条件下优化方案。

故障隔离与「组织韧性」

20个代理同时运行，必然有人掉链子。Paperclip从游戏服务器编排里借鉴了故障隔离机制。

每个代理运行在独立的沙箱进程中，崩溃不影响其他代理。编排器持续收集心跳，超时未响应的代理被标记为「失联」，其任务自动重新分配或进入待处理队列。

关键设计是「无状态代理、有状态编排」。代理本身不保存重要状态，所有状态通过编排器持久化。这意味着你可以随时杀死并重启一个代理，就像重启一个卡死的员工电脑，而不会丢失工作进度。

「回滚」功能更激进。当某个代理的操作导致系统异常（如测试全部失败、构建中断），Paperclip可以回滚到该代理介入前的状态，并自动提交bug报告。这相当于给AI代理配备了「撤销」按钮——不是撤销单条指令，而是撤销整个「员工」的工作日。

一位开发者描述了他的使用场景：让Claude Code重构数据库层，结果引入了一个微妙的竞态条件。Paperclip在测试阶段捕获异常，自动回滚到重构前，并生成报告指出「员工#7的操作与员工#3的缓存策略冲突」。人类开发者花了10分钟修复策略，重新派遣代理，避免了数小时的调试噩梦。

与现有工具的对比：不是替代，是分层

很多人第一次看Paperclip，会以为它是LangChain或CrewAI的竞品。README里的那句话就是为了打断这种联想。

LangChain的核心是「链」（Chain）——把模型调用、工具使用、记忆管理串成可复用的管道。它解决的是「单个代理如何高效工作」。

CrewAI的核心是「团队」（Crew）——把多个角色代理按流程编排，完成复杂任务。它解决的是「多个代理如何协作完成一个项目」。

Paperclip的核心是「组织」（Organization）——把多个代理视为持续运营的公司实体，管理目标、资源、风险。它解决的是「代理规模扩大后如何不崩盘」。

三者可以叠加使用。你可以用LangChain构建单个代理的能力，用CrewAI设计项目级的工作流，再用Paperclip把多个Crew纳入长期运营的组织架构。

这种分层架构符合软件工程的基本规律：关注点分离。让专业的工具做专业的事，而不是指望一个框架解决所有问题。

开源社区的狂热与质疑

Paperclip在GitHub上线7天，收获3400星标，150个fork，30多位贡献者提交PR。这个增速在开发者工具类别里相当罕见。

兴奋点很明显：它是第一个把「AI公司」从科幻概念变成可运行代码的项目。之前大家都在讨论「AI CEO」「AI员工」，Paperclip直接给了你一套HR系统。

但质疑同样尖锐。Hacker News上的高赞评论指出：「这只是在传统运维工具上套了一层商业隐喻。」另一位开发者说：「我可以用Kubernetes + Prometheus + 一些脚本实现同样的功能，为什么要学一套新抽象？」

创始人回应了这种质疑：「你可以用K8s管游戏服务器，但为什么还有专门的Game Server Orchestrator？因为领域抽象有价值。Paperclip不是通用编排器，它是为AI代理的特定失败模式设计的——幻觉、成本失控、上下文丢失。」

这个回应有说服力。Kubernetes不懂什么是「token预算」，Prometheus不会告警「代理产生了自相矛盾的输出」。领域特定的抽象，意味着更精准的治理策略。

早期用户的真实反馈

在Discord和GitHub Issues里，能看到一些具体的使用报告。

一位独立开发者用Paperclip管理他的「一人公司」：3个Claude Code实例分别负责产品、工程、运营，1个Cursor实例做设计，1个Python脚本处理客服邮件。他每天花30分钟审阅代理提交的「日报」，调整优先级和预算。产出效率据他估计提升了3倍，但「管理开销从写代码变成了当经理，不确定是不是进步」。

一个5人创业团队尝试了更激进的配置：完全取消人类工程师的编码职责，只保留架构设计和代码审查。3周后他们回退了这个实验——「代理能写能跑，但架构债务累积速度远超预期，没有人类把控方向，系统很快变成一团糟」。

最有趣的反馈来自一位游戏行业的老兵：「这让我想起了20年前MMO的运维噩梦。当时我们手动管理服务器集群，后来有了自动化编排。现在AI代理处于同样的阶段——Paperclip可能是那个转折点。」

技术实现的几个关键细节

Paperclip用Rust编写核心编排引擎，追求低延迟和高可靠性。状态存储默认SQLite，支持PostgreSQL扩展。代理通信采用gRPC，心跳间隔可配置。

配置系统基于YAML，支持环境变量注入和动态重载。这意味着你可以在运行时调整预算、重组汇报线，而不重启整个组织。

一个设计亮点是「政策即代码」（Policy as Code）。治理规则用DSL编写，比如「删除生产数据库需要CTO审批」可以表达为：

policy:

action: delete_database

environment: production

require_approval_from: [cto]

max_budget: 0

这种设计让合规审计变得可自动化。你可以用git管理政策变更，用CI/CD流程审批政策更新——用软件工程的方法治理AI代理。

扩展机制基于WebAssembly。自定义的代理适配器、成本计算逻辑、告警处理器，都可以用Rust或AssemblyScript编写，动态加载到编排引擎。

局限性与 roadmap

创始人坦诚列出了当前局限。最突出的是「代理间通信」——Paperclip提供了消息总线，但如何设计高效的代理协作协议，仍依赖用户自己摸索。

另一个痛点是「视觉代理」的支持。目前的架构主要针对文本代码任务，处理图像、视频、3D模型的代理可以接入，但缺乏专门的优化。

Roadmap上优先级最高的功能是「自动招聘」——根据工作负载动态创建或销毁代理实例，类似K8s的HPA（Horizontal Pod Autoscaler）。这会让「AI公司」真正具备弹性伸缩能力。

长期愿景是「代理市场」——标准化的代理能力描述、信誉评分、成本基准，让用户可以像招聘网站一样「雇佣」第三方代理。

对行业的影响预判

Paperclip的出现，可能标志着AI代理基础设施的分层成熟。

第一层是模型能力（GPT-4、Claude、Gemini），解决「能做什么」。第二层是代理框架（LangChain、CrewAI），解决「怎么做」。第三层是组织编排（Paperclip），解决「怎么规模化」。第四层可能是垂直领域的「代理公司模板」——法律事务所、软件外包公司、咨询公司的AI化运营方案。

这种分层降低了创业门槛。未来可能出现「AI原生公司」：没有人类员工，只有创始人设定的目标和预算，由Paperclip类系统管理数十个代理持续运营。

但风险同样明显。当AI代理的「公司」可以7×24小时运转，人类管理者的监督能力成为瓶颈。Paperclip提供了审计日志，但阅读日志、识别模式、做出判断，仍然需要人类注意力——而这种注意力是稀缺的。

一位评论者说：「Paperclip让我能管20个代理，但我的大脑还是只能同时跟踪3-5个任务。瓶颈从『代理不够』变成了『我作为经理不够』。」

这或许是AI时代的新常态：工具扩展了执行能力，但人类的认知带宽仍是硬约束。Paperclip没有解决这个问题，它只是把问题暴露得更彻底。

项目地址：paperclip.ing。GitHub仓库搜索「paperclip-os」即可找到。