Paperclip（paperclipai/paperclip）：把一群 AI 智能体管成一家「公司」的控制平面

一、导读

Paperclip 是 paperclipai 团队开源的智能体编排控制平面（MIT，TypeScript，2026-03-02 创建）：它不生产智能体，而是给智能体发工牌——职位、汇报线、预算、审批与审计。当日涨星 +2,589（GitHub Trending daily，2026-09-26 抓取），总星 87,097。核心结论是：它把「多智能体协作」从框架问题重写成组织问题与控制平面问题——用 heartbeat 心跳代替常驻进程、用单指派原子 checkout 代替并发抢占、用预算硬停代替事后账单、用 MCP 网关代替裸工具调用；代价是它只解决「协调」不解决「能力」，且自托管与 markdown-first 的组织描述在复杂企业里会撞墙。

二、项目速览

项目	详情
仓库	paperclipai/paperclip（数据经 GitHub API 于 2026-09-26 抓取）
作者/团队	paperclipai（联合创始人之一使用化名 Dotta，来自第三方访谈口径，待确认）
主语言	TypeScript（83.0 MB，另有 Rust 2.6 MB、PLpgSQL、Shell、CSS、Python 等）
Star 总数	87,097（fork 15,412，开放 issue 5,738，仓库约 280 MB）
当日涨星	+2,589（GitHub Trending daily，2026-09-26 抓取）
License	MIT
首次发布	仓库创建 2026-03-02，最近推送 2026-09-26；最新 Release v2026.916.1（2026-09-21），releases/ 目录自 v0.2.7 起累计 28 份版本说明
形态	自托管控制平面：Node.js 服务端 + React 19 前端 + PostgreSQL 17（或嵌入式 PGlite），pnpm monorepo
关键依赖	Node.js 24.11+、pnpm 9.15+、Drizzle ORM、Better Auth、Express 5

三、为什么是它

问题背景：多智能体从「能跑」到「能管」的断层。 2026 年 agent 生态的瓶颈已从「模型够不够聪明」移到「组织够不够可控」。第三方汇总的行业数据里，仅 6% 的公司完全信任智能体，Gartner 预计 40% 以上的 agentic AI 项目会在 2027 年前被取消，CMU 等机构的基准显示智能体自主完成复杂任务的比例不超过 30.3%（均为第三方口径，见第八节）。与此同时，开发者手上的现实是 README 里那句自嘲——「你开着 20 个 Claude Code 终端，却不知道谁在干什么」。Paperclip 的答案不是再做一个更强的 agent，而是补上缺失的那一层：控制平面。

定位：它是「公司」，不是「员工」。 README 的比喻很准：「如果 OpenClaw 是一名员工，Paperclip 就是那家公司。」它自己划清了边界——不是聊天机器人、不是 agent 框架、不是工作流拖拽器、不是提示词管理器、不是单智能体工具。它要回答的是四个运营问题：谁有权做什么、钱花到哪、谁在等谁、出事谁负责。

涨星动因拆解。 一是叙事自带传播力：「零人类公司」这个说法把 agent 编排包装成可想象的商业形态，第三方报道称项目三周内到 33K 星、如今 80K+（时点口径差异见第八节），并衍生出 Felix、Polsia 等案例叙事。二是踩中多 agent 并行的真实痛点：不是演示里的三个 agent 聊天，而是二十个编码 agent 同时改一个仓库。三是工程完成度高得不像周末项目：monorepo 13 个 package、12 个适配器、MCP 网关、promptfoo 评测、PRP 协议与 Rust runner，releases/ 里从 v0.2.7 到 v2026.916.1 的版本说明连续可查。四是给出了可审计的治理答案：预算硬停、审批门、不可变活动日志——这正是企业采购时最先问的三个问题。

四、架构原理

4.1 整体架构：四层栈与一次心跳的完整数据流

Paperclip 是 pnpm monorepo，官方 docs/start/architecture.md 把它概括为四层：

┌──────────────────────────────────────────────┐
│  React UI (Vite)                             │
│  看板 / 组织管理 / 任务 / 审批 / 成本          │
├──────────────────────────────────────────────┤
│  Express.js REST API (Node.js)               │
│  routes / services / auth / adapters         │
├──────────────────────────────────────────────┤
│  PostgreSQL 17 (Drizzle ORM)                 │
│  schema / migrations / 嵌入式 PGlite 模式      │
├──────────────────────────────────────────────┤
│  Adapters                                    │
│  Claude Code / Codex / Cursor / HTTP / ...   │
└──────────────────────────────────────────────┘

官方列出的五条关键设计决策：控制平面而非执行平面——Paperclip 编排 agent，不运行 agent；company-scoped——所有实体属于且仅属于一家公司，数据边界严格；单指派任务——原子 checkout 防止同一任务被并发处理；适配器无关——任何能调 HTTP API 的运行时都能当 agent；默认嵌入式——零配置本地模式自带 PostgreSQL。

一次心跳的六步数据流（docs/start/architecture.md 的 Request Flow）：

1. 触发：调度器、手动 Invoke，或事件（任务指派、@提及）唤醒；
2. 适配器调用：服务端调用已配置适配器的 execute()；
3. 拉起进程：适配器以 Paperclip 环境变量与提示词启动 agent（如 Claude Code CLI）；
4. agent 干活：agent 反过来调用 Paperclip 的 REST API——查指派、checkout 任务、更新状态；
5. 结果捕获：适配器采集 stdout、解析用量与成本、提取会话状态；
6. 落库：服务端记录本次 run 结果、成本与会话状态，供下一次心跳续接。

注意第 4 步的方向：是 agent 调用控制平面，而不是控制平面驱动 agent 的每一步。这决定了它的定位——提供协议与账本，不提供运行时。

4.2 分层模块拆解

层	组成	职责与关键接口
适配层	packages/adapters/ 12 个适配器：claude-local、codex-local、cursor-local、cursor-cloud、gemini-local、grok-local、kimi-local、opencode-local、pi-local、hermes、hermes-gateway、openclaw-gateway，另有 process（通用 shell）与 http（webhook）	每个适配器含三个模块：服务端 execute()、UI 的 stdout 解析器与配置表单、CLI 的 paperclipai run --watch 格式化器。接入新运行时的最小契约就是这三件
控制平面层	server/src/（Express 5）：routes / services / adapters / auth / middleware	身份与访问（本地信任或鉴权两种部署模式、board 用户、agent API key、短时 run JWT）、任务与工作、心跳执行、治理与审批、预算与成本、活动审计
数据层	packages/db/（Drizzle schema + migrations）	公司/项目/目标/任务/评论/文档/附件/工作产物/审批/成本事件；迁移编号可查（如 0236、0229）
前端层	ui/（React 19 + Vite 6 + React Router 7 + Radix UI + Tailwind 4 + TanStack Query）	操作者视角的看板：扫描状态、判断「是否需要我」、给出决策；DESIGN.md 要求「密度来自信息而非装饰」
扩展层	packages/plugins/、packages/mcp-server/、packages/paperclip-runner/	插件走进程外 worker + 能力门控；MCP server 是 REST 的薄封装；Runner 是 Rust 原生执行引擎 + PRP 协议
技能层	skills/（paperclip、agentmail、slack、paperclip-board、paperclip-create-agent、para-memory-files 等）与 packages/skills-catalog/	以 SKILL.md 为开放标准、运行时注入；Skills Manager / Skill Studio / Skills Store 负责发现、创建、测试与分发

4.3 核心机制与算法原理

① 心跳协议：把「常驻 agent」换成「短执行窗口」。 官方 docs/agents-runtime.md 写得很直白：agent 不持续运行，它们在心跳中醒来——启动适配器、拿到当前提示词与上下文、干活直到退出/超时/取消，然后落库状态、token 用量、错误与日志。唤醒有四种来源：timer（如每 5 分钟）、assignment（任务被指派或 checkout）、on_demand（人工按钮/API）、automation（系统触发）。关键细节是合并（coalescing）：若 agent 已在运行，新唤醒会被合并而不是再起一个 run——这是防止重复劳动烧钱的第一道闸。运行时参数包括 enabled、intervalSec、wakeOnAssignment、wakeOnOnDemand、wakeOnAutomation，以及 cwd、timeoutSec、graceSec。

② 单指派与原子 checkout：用 409 解决并发。 任务状态机是 backlog → todo → in_progress → in_review → done，另有 blocked；终态为 done/cancelled。进入 in_progress 必须原子 checkout，同一时刻只有一个 agent 能拥有该任务，两个 agent 同时抢会有一个拿到 409 Conflict。doc/execution-semantics.md 把四个容易混淆的概念拆开：结构（父子任务）、依赖（阻塞关系）、归属（谁现在负责）、执行（控制平面是否还有活跃路径）。blocked 也不是随便能进的：必须给出可路由的等待路径——一等公民阻塞关系、指名响应者的待处理交互或链接审批，或结构化 unblock 描述符 {owner, action}；只在评论里写散文式的「被谁阻塞了」会被 API 拒绝或自动归类，因为「散文式阻塞不路由给任何人」。

③ 预算与成本：把自主性换算成钱，并允许硬停。 成本按公司、agent、项目、目标、任务、供应商、模型多个维度追踪，预算策略带警告阈值与硬停；超支会自动暂停 agent 并取消排队中的工作。这条机制是「零人类公司」叙事里最实在的一环：自主性必须有价格上限。

④ MCP 网关：把工具调用从「能不能调」变成「这次调用该不该放行」。 doc/MCP-ACCESS-GOVERNANCE.md 给出四段式心智模型：Application（逻辑分组）→ Connection（一个 MCP 端点，传输为 remote_http 或受信任部署下的 local_stdio）→ Catalog（发现到的工具，带 read/write/destructive 风险分级与 active/quarantined/disabled 状态）→ Profile（允许/拒绝条目，经 Binding 绑到 company/agent/project/routine/issue）。调用时再叠加正交的 Policy：allow、block、require_approval、rate_limit、trust_rule，拒绝优先于允许。文档里那句话值得抄下来：「profile 决定这个 agent 能不能看见这个工具；policy 决定这一次调用此刻是否被允许。」 网关会记录 Call Event 进审计日志，必要时打开 Action Request 等人工批准。packages/mcp-server/ 则是反向的——把 Paperclip 自己的 REST API 包成 MCP 工具（读、写、审批与逃生舱四类）。

⑤ 看门狗与执行语义：给「停下来的工作」做二次验证。 doc/TASK-WATCHDOG.md 区分了三个同名的 watchdog：任务看门狗（盯一棵被指定的任务子树，当整棵子树静止且没有活跃延续路径时唤醒，读证据判断这次停止是否合法）、静默活跃 run 看门狗（盯单个仍在跑但长时间无输出的进程）、存活性恢复（周期性扫描里发现停滞的 in_progress 任务）。任务看门狗是逐任务 opt-in 的，没有全局开关，且它是「验证形状而非执行形状」——不重跑原指派者，只检查别人声称的完成是否有证据。

⑥ Runner 与 PRP 协议：把执行下沉到 Rust。 packages/paperclip-runner/ 是原生 runner 的独立开发边界：Rust 负责生产 runner，TypeScript 提供控制平面参考实现、浏览器 SDK、场景工具与一致性判定器。协议 PRP 已有 v1/v2：JSON Schema 是语言中立的真相源，消费者遇到不支持的必要版本或 schema 判别符时 fail closed；v2 增加了供应商中立的持久会话目标生命周期（session.goal.get/set/clear），并明确会话目标状态与公司的业务目标层级是两回事。已合格的驱动包括 Codex、OpenCode、ACPX、Claude Managed 与 AWS AgentCore。

4.4 性能与设计取舍

取舍	为什么这么做	代价
心跳而非常驻	抗崩溃、成本可预测、每次唤醒都是一个可审计的 run	agent 是「片段式」的，跨心跳维持复杂上下文要靠会话状态与技能注入
单指派 + 原子 checkout	从根上消灭重复劳动与写冲突	并行度受限，任务粒度必须切得够细
控制平面不跑 agent	不绑定任何运行时，适配器可插拔	能力上限完全取决于你自带的 agent，它不能替你变强
预算硬停	把「自主」关进钱的笼子	复杂任务可能在关键时刻被掐断，需人工加预算
组织用 markdown 描述（AGENTS.md / SOUL.md / HEARTBEAT.md）	透明、可 Git 版本化、人机同读	难以适配已有 CRM/财务/工单等复杂数据（第三方批评口径）
插件进程外 + 能力门控	扩展不 fork 核心，权限可收窄	当前插件 UI 与主应用同源、按受信代码对待；动态安装尚未云就绪
默认嵌入式 PostgreSQL	零配置起步	生产要换成自管 Postgres 并自担运维

4.5 与其他架构路线的差异

与 LangGraph / CrewAI / AutoGen 等 agent 框架相比：那些框架回答「如何构建一个 agent 或一张图」，Paperclip 回答「如何管理一群已经建好的 agent」。它明确声明不是 agent 框架——「我们不告诉你如何构建 agent，我们告诉你如何运营一家由它们组成的公司」。

与 n8n / Dify 等工作流平台相比：工作流是拖拽出来的确定性管道，Paperclip 是「目标 + 组织 + 预算」驱动的非确定性协作，且带审批与审计。

与 OpenClaw / Claude Code 等单体 agent相比：它们是员工，Paperclip 是公司——README 的定位句就是这个意思。

与 Kubernetes 式调度相比：两者都是控制平面，但 K8s 调度的是无状态容器，Paperclip 调度的是有身份、有预算、有汇报线、会自己调用 API 的「员工」。

五、应用场景

场景一：把二十个编码 agent 收进一个看板

痛点：同时开多个 Claude Code / Codex 终端改同一个仓库，谁改了哪个文件、谁卡住了、重启后上下文丢没丢，全靠人脑记。 做法：装好 Paperclip，建一家公司，把每个终端注册成一个有职位与汇报线的 agent，之后所有活儿走任务票据。

curl -fsSLO https://paperclip.ing/install.sh
curl -fsSLO https://paperclip.ing/install.sh.sha256
shasum -a 256 -c install.sh.sha256
bash install.sh                      # 装 Node 24.11+ 与管理式 CLI 到 ~/.paperclip/cli
paperclipai onboard --yes            # 非交互初始化，默认本地回环信任模式
# 想先空跑看看，不落任何服务：
ANTHROPIC_API_KEY=... npx paperclipai test-drive

收益与量化：任务是票据制、会话跨重启保留；每次心跳落一条 run 记录（状态、token 用量、错误、日志），「谁在干什么」变成可查询的数据。 适用边界：README 自己划了线——「如果你只有一个 agent，大概不需要 Paperclip；如果你有二十个，你肯定需要。」单 agent 场景引入它是纯负担。

场景二：定时运营任务（Routines）

痛点：客服巡检、周报、社媒排期这类周期性工作，过去要靠人记得手动踢一脚；而让 agent 常驻轮询又会持续烧 token。 做法：用 Routines 声明周期任务，支持 cron、webhook 与 API 三种触发；每次执行会生成一个被追踪的任务并唤醒被指派的 agent，而不是让它空转。

Routine: 每周一 09:00（cron）
  触发 → 创建任务「汇总上周支持工单并生成周报」
  指派 → 运营 agent（wakeOnAssignment = true）
  产出 → 任务下的工作产物（文档/附件），进入 in_review 等审批

收益与量化：官方已把 Scheduled Routines 列为完成里程碑，支持并发与补跑；agent 只在被唤醒时执行，空闲期成本为零。 适用边界：Routine 适合「有明确产出物」的周期工作；把需要连续上下文的探索性研究做成 Routine 会反复冷启动，效果通常不如人工触发一次长会话。

场景三：预算硬停与成本归因

痛点：多 agent 最大的风险不是模型不够强，而是失控循环——第三方复盘里反复出现的场景是「几百美元的 token 在你知道之前就被烧光」。 做法：给公司、agent 设月度预算上限，超支自动暂停 agent 并取消排队中的工作；成本按公司/agent/项目/目标/任务/供应商/模型多维归因。

公司预算: $200 / 月（以分为单位存储）
  agent: CTO    上限 $60   → 达 80% 警告，100% 硬停
  agent: 工程师 上限 $40

收益与量化：README 明确「触到上限就停下，没有失控成本」；治理面还可暂停/恢复/终止任意 agent。第三方复盘把预算模型列为最受认可的功能之一。 适用边界：硬停会在关键路径上掐断任务，复杂项目需要预留人工加预算的流程；另外预算只能约束「花多少钱」，约束不了「做错多少事」——错误仍可能跨 agent 复合放大。

场景四：用 MCP 网关治理工具调用

痛点：agent 一旦拿到 GitHub、Linear、云的凭据，就等于拿到了「王国钥匙」；只靠提示词说「不要删库」不是安全边界。 做法：把外部 MCP 端点登记为 Connection，工具进 Catalog 并打上 read/write/destructive 风险分级，再用 Profile 决定可见性、用 Policy 决定放行方式。

# 官方文档给出的最快验证路径：安装示例应用 + 连接 + Profile，然后跑冒烟
curl -fsS -X POST -H "Authorization: Bearer $BOARD_API_KEY" -H "Content-Type: application/json" \
  "$PAPERCLIP_URL/api/companies/$COMPANY_ID/tools/examples/safe-read-only-todo-kv/install" -d '{}' | jq .

收益与量化：策略正交叠加且拒绝优先于允许；require_approval 会把调用变成 Action Request 等人工批准，每次调用落 Call Event 进审计日志。仓库自带 promptfoo 评测集覆盖 MCP 网关 12 个用例（允许读、默认拒绝写、待审批、审批被拒、限流退避、凭据修复不泄露、会话吊销、目标漂移等），本地基线 12/12 通过（evals/promptfoo/mcp-gateway-run-summary.md，2026-06-16；该次未跑真实模型矩阵，官方标注为残余风险）。 适用边界：local_stdio 传输仅限受信任部署；插件 UI 当前与主应用同源、按受信代码对待，不是沙箱边界；动态插件安装尚未云就绪（均为官方文档自陈）。

场景五：任务看门狗兜底「假完成」

痛点：agent 会因为错误原因停下来——误读阻塞、接受了过期的计划确认、没有证据就宣布完成、把任务挂在 in_review 却没有真正的评审者。这些失败不会自动唤醒任何人，任务树就那样静止着。 做法：在关键任务上挂一个看门狗 agent（逐任务 opt-in，无全局开关）。当被监视子树的每个叶子都静止且没有活跃延续路径时，Paperclip 唤醒它去读证据并判断这次停止是否合法。

配置位置: 单个任务 → 看门狗设置（UI 或 API）
监视范围: 该任务 + 其非看门狗后代
触发条件: 整棵子树静止（done / cancelled / blocked / in_review / 等待交互）且无活跃延续路径
看门狗职责: 验证形状（读证据、接受或恢复活跃路径），不重跑原指派者

收益与量化：把「验证」从执行里独立出来，避免用同一个 agent 自查；官方同时区分了静默活跃 run 看门狗与存活性恢复，三者职责不重叠。 适用边界：官方明确「不是所有任务都值得挂看门狗」；它是第二遍检查，会额外消耗 token，对低风险任务不划算。

六、快速上手

# 方式一：托管安装（推荐）
curl -fsSLO https://paperclip.ing/install.sh && bash install.sh
paperclipai onboard --yes                    # 默认本地回环；--bind lan / --bind tailnet 切鉴权模式

# 方式二：零安装试跑（隔离实例，自带一个 CEO agent，前台运行）
ANTHROPIC_API_KEY=... npx paperclipai test-drive
OPENROUTER_API_KEY=... npx paperclipai test-drive --harness opencode --model openrouter/anthropic/claude-sonnet-4.5

# 方式三：源码开发
git clone https://github.com/paperclipai/paperclip.git && cd paperclip
pnpm install && pnpm dev                     # API 起在 http://localhost:3100，自动创建嵌入式 PostgreSQL

要求 Node.js 24.11+ 与 pnpm 9.15+。官方提醒：install.sh 的校验和与脚本同源，只能发现传输或发布错误；需要独立来源时应改用 release tag 或 commit 固定的 GitHub 副本。

七、横向对比

维度	Paperclip	LangGraph / CrewAI / AutoGen	n8n / Dify 工作流平台	托管型 agent 平台（如 O-mega 等）
抽象单位	公司 / 职位 / 任务 / 预算	图、角色、对话	节点与连线	订阅内的托管 agent
执行模型	心跳唤醒，短执行窗口 + 合并	进程内编排，随主程序运行	事件触发，确定性管道	云侧常驻
治理与审批	一等公民：审批门、审计日志、暂停/终止	需自行实现	部分支持	平台内置
成本控制	多维归因 + 预算硬停	无内置	无内置	平台侧计费
工具治理	MCP 网关：Catalog 风险分级 + Profile + Policy + 审批	自行接工具	内置连接器	平台内置
可复现与可移植	组织可导出/导入（secret 擦洗 + 冲突处理）	代码即配置	工作流 JSON	不可迁移
部署与成本	自托管，MIT，付自己的 LLM 账单	自托管，MIT/Apache	自托管或云	订阅制（第三方称约 12 美元/月起，待确认）
最适合	多 agent 并行 + 需要审计与预算的团队	构建单个/少量 agent 应用	确定性业务流程自动化	要开箱即用、不碰运维的运营者

口径：竞品定位来自官方文档与第三方对比文章（2026-09 检索）；托管平台价格来自第三方评测，未核对官网。

八、局限、风险与社区观察

一、成熟度与星数不匹配。 仓库 2026-03-02 创建、2026-09-26 仍高频推送，6 个月内累计 28 份版本说明，但破坏性变更密集：v2026.831.0 把 Node.js 底线抬到 24.11、移除「廉价模型档」、让 agent API 不再回传明文凭据、退役自动生产力评审。第三方复盘称 2026 年 9 月仍有 2,242 个开放 issue 与 3,160 个开放 PR（我抓取 API 时 open issues 为 5,738，两处口径与时点不同，以 API 为准）。想上生产，先锁 commit 与版本。

二、自托管是真实负担。 官方插件规范自陈当前部署模型是单租户、自托管、单节点；插件 UI 与主应用同源、按受信代码对待；动态插件安装对水平扩展或临时实例「尚未云就绪」，没有共享产物存储与跨节点分发。

三、安全面需要主动经营。 第三方转述称 OpenClaw 曾被 Cisco 描述为「安全噩梦」，并有审计发现 512 个漏洞与 3 万多个暴露实例（待确认）。Paperclip 自身提供了 Secrets Manager、逐 agent 密钥访问与 MCP 网关的拒绝优先策略，但这些是工具，不是默认安全。

四、组织描述偏 markdown-first。 用 AGENTS.md / SOUL.md / HEARTBEAT.md 描述 agent 让配置透明、可 Git 版本化，但第三方一致指出它难以适配已有 CRM、财务、工单等复杂数据的存量企业。

五、能力边界要认清。 第三方复盘称其缺少浏览器自动化与邮件通信，记忆是文件式 PARA 三层、缺语义向量检索（均为第三方口径，待确认）；它自己也声明不是 agent 框架。

六、多智能体的数学现实。 第三方汇总的 Google DeepMind / MIT 180 组实验显示：集中协调在可并行任务上提升 80.9%，在顺序任务上反而下降 39–70%；独立 agent 的错误放大倍数约 17.2 倍，集中式降到约 4.4 倍；agent 数量超过 4 个后收益趋于平台（以上均为第三方转述，待确认）。这解释了 Paperclip 为什么把「组织与预算」放在「更多 agent」之前——编排的价值在并行与制衡，不在堆数量。

七、叙事与现状的落差。 「零人类公司」在多个第三方来源里被一致描述为愿景而非现状：策略、质量保证、责任与审批仍需要人。

八、License 与商业化。 代码 MIT，无 License 风险；但生态是分层的：自托管开源版与商业云服务并存（第三方称云端约 12 美元/月起，待确认），采用前需确认哪些能力留在开源侧。

九、小结与行动建议

Paperclip 真正的贡献不是「让 agent 更像员工」这个比喻，而是把三个工程问题做成了默认能力：并发归属（原子 checkout + 单指派）、成本上限（多维归因 + 预算硬停）、责任追溯（不可变活动日志 + 审批门）。

1. 先用 test-drive 跑一个隔离实例，亲手走一遍「建公司 → 设目标 → CEO 拆任务 → 审批 → 看成本」闭环，再决定是否自托管。
2. 把预算当第一道防线：给每个 agent 设月度上限与 80% 警告阈值，先跑两周观察真实 token 曲线，再谈放开自主性。
3. 工具权限走网关而不是提示词：外部 MCP 端点一律进 Catalog 打风险分级，写操作设 require_approval，破坏性操作默认拒绝。
4. 锁定版本与 commit，并预留升级窗口——这个项目每两周左右就有破坏性变更，追最新版等于自担回归风险。
5. 从「并行 + 可验证」的任务开始：可切分、有明确产出物、能自动验收的工作（批量重构、巡检、报表）收益最大；需要连续上下文的长链推理与高风险决策，仍应保留人在环。

资料来源（抓取日期 2026-09-26）：GitHub REST API（paperclipai/paperclip 元数据、releases/tags、顶层目录树、packages/server/docs 等子树）与 GitHub Trending daily 页面；仓库一手文档：README.md、DESIGN.md、ROADMAP.md、adapter-plugin.md、docs/start/architecture.md、docs/start/core-concepts.md、docs/agents-runtime.md、doc/PRODUCT.md、doc/MCP-ACCESS-GOVERNANCE.md、doc/TASK-WATCHDOG.md、doc/execution-semantics.md、doc/plugins/PLUGIN_SPEC.md、packages/mcp-server/README.md、packages/paperclip-runner/README.md 与 protocol/README.md、skills/paperclip/SKILL.md、evals/README.md、evals/promptfoo/mcp-gateway-run-summary.md，以及 releases/v2026.916.1.md、v2026.916.0.md、v2026.831.0.md；第三方：o-mega.ai 的多智能体格局长文（含行业数据、16 个公司模板、用户反馈与批评）、flowtivity.ai、websearchapi.ai、towardsai、theaiarchitects、contabo 等评测与解读文章。所有一手行为均以仓库源码与官方文档为准；第三方测算、案例与批评性数据已逐处标注来源与性质，无法核实处标「待确认」，未作补全。