多 Agent 任务总失控？11 万 Star 的 Paperclip 给它们补了一张工单桌

开三个 Agent 干活，最容易丢的不是上下文，是责任。

一个在改页面，一个在跑测试，一个看着像是卡住了。你转回来时，通常得先翻终端、看聊天记录、对比文件时间，再判断它到底完成了什么、有没有碰不该碰的地方、这一轮又烧了多少额度。

GitHub 上的 Paperclip 在 11 月 2 日公开快照里已经有 110,189 个 Star。它想解决的不是“让 Agent 更聪明”，而是把现成的 Claude Code、Codex、脚本或其他运行时，收进一张有任务、有负责人、有预算、有验收的工单桌。

官方给的最短入口只有一条命令：

npx paperclipai@latest onboard --yes

先把边界说在前面：这篇不是实测报告。我没有拿生产项目去跑它，下面所有能力都来自 Paperclip 官方 README 和它的 公开 release。所以不谈“用了以后效率翻倍”这种话，只聊它把哪些原本散在终端和脑子里的事，变成了可以复查的状态。

你缺的通常不是一个 Worker

多 Agent 一开始很好玩。把需求拆几块，分别扔给不同窗口，似乎马上就有一支小队了。

但工作一旦跨过两三个回合，问题会变得很朴素：谁现在拥有这个任务？它依赖谁？有人改了配置，为什么改？一个 Agent 失败后，另一个该接着做、等人决定，还是直接停？

这些问题没有模型味，都是项目管理里最土的东西。可 Agent 跑得越快，越不能靠口头同步糊过去。

Paperclip 的核心做法，是让每件工作留在一个任务线程里。官方 README 写得很具体：讨论、计划、阻塞、文件、产物和运行历史都挂在任务上；领取任务有原子操作和执行锁，避免两个运行实例误拿同一件活。

这比“给 Agent 起几个角色名”实在得多。角色名能让提示词好看一点，不能回答“这份 PR 谁该验收”“这个失败能不能重试”“为什么今天的账突然高了一截”。

图：本文依据官方 README 梳理的工作关系，不是 Paperclip 官方界面截图。

如果你同时在用 Claude Code 和 Codex，这个差别尤其明显。它们不需要被改造成同一个 Agent；更有用的是给它们一个共同的任务状态。哪个负责实现，哪个负责复核，什么时候必须停下来等人，别再只存在某个终端的滚屏里。

它把四类“回头再说”搬上台面

第一类是目标。

很多 Agent 只拿到一句“把这个 Bug 修掉”。Paperclip 会让任务、项目和组织目标关联起来，Agent 不只是看到一个标题，也能带着上层目标工作。听着很管理学，落到日常就是：你不必每次重新解释为什么这个小改动现在比另一个需求优先。

第二类是权限。

多 Agent 的危险并不总在写错代码，更常见的是它们拿着不同连接、不同密钥、不同仓库权限，最后没人说得清哪个动作是被谁授权的。官方文档把连接的动作分成允许、先问和关闭；人和 Agent 对同一个连接的使用资格也可以分别设定。

这不等于配好以后就安全了。权限系统只是把“默认放行”改成了“有地方能看、有地方能拦”。涉及部署、付款、删数据、发外部消息，还是应该保留人工确认。别让一个漂亮仪表盘替你做风险判断。

第三类是成本。

长任务最怕的不是一开始慢，而是它悄悄重试、悄悄扩大上下文、悄悄跑过预算。Paperclip 有按公司、Agent、项目和任务追踪用量、预算阈值和暂停的能力；最新稳定版还把费用记录做成了可恢复的账本，并能标出估算、未定价和重试的状态。

这里有个很值得抄走的判断：预算不是报表上的红黄绿，而应该参与“要不要继续执行”的决定。 如果花费还没法可靠定价，官方默认可以把预算策略设成阻断。对需要无人值守跑几小时的任务，这比月底看总账靠谱。

第四类才是交付。

Agent 报“完成”不是验收。一个能交付的任务，至少要能回看它改了什么、产物在哪里、测试或检查结果是什么、谁在什么条件下放行。Paperclip 的审批阶段、运行历史、文件与评论都服务于这件事。它不是替你判断产品是否正确，而是让“我为什么相信这个结果”有地方落脚。

图：把 Agent 的“完成”改成可回看的交付回路，人工仍保留最终决定权。

先别急着搭一间“AI 公司”

Paperclip 最容易被讲成“一个人带着一群 AI 开公司”。这个比喻很抓眼球，也容易让人误以为先把组织架构、CEO、部门和周报全搭起来，生产力就会自己出现。

我觉得顺序应该反过来。

先挑一个已经让你头疼的重复工作：例如每周跑一次代码审查，或者让一个 Agent 处理改动、另一个 Agent 收集测试证据。只建一个项目、两类角色、一个预算上限和一个人工验收点。运行两三轮后再看：任务是否真的更容易追，失败是否更容易定位，成本有没有被看见。

如果答案都是否定的，别继续加组织图。你可能只是需要一个清楚的 issue 模板，或者一个能保存终端输出的脚本，而不是一套新的控制面。

这也是官方安装说明里值得注意的一点。onboard 的默认路径是本机回环地址，适合先在自己的机器上做隔离试跑；要给局域网或私网访问，应该显式选择绑定方式，并按文档启用认证。它要求 Node.js 24.11+；若要在主机上使用本地 Claude 或 Codex 订阅登录，还需要 Python 3 和相应 CLI。

不要为了看一眼界面，就把有生产密钥、有客户数据的环境直接接进去。先用一个无敏感信息的仓库、一组无写权限的连接和可随时暂停的预算，看看它的任务流是不是刚好补上你现在的缺口。

一张工单桌，不能替你当负责人

我喜欢 Paperclip 的地方，不是它把 Agent 包装成了什么职位，而是它承认 Agent 真正进入工作后，需要被当作一个会产生状态、成本、权限和后果的执行者来对待。

11 万 Star 只能说明很多人盯上了这个问题，不代表每个团队都该装。只有一个短任务、没有持续运行、也不需要追责时，轻一点的工具反而更舒服。可一旦你开始在多个 Agent 之间交接任务，最该先补的往往不是再开一个 Worker，而是这一张能看到负责人、证据和刹车的位置。

你现在最难追的，是 Agent 的任务状态、权限，还是成本？

小岛 AI

记录一线实战、踩坑与成长