Paperclip 的组织架构与汇报线：一棵严格无环的树，决定了任务怎么往下派
多 Agent 系统跑起来之后，最先失控的往往不是模型能力，而是”谁该干这件事”。任务在几个 Agent 之间来回踢，没人认领；或者反过来，同一件事三个 Agent 同时开工。很多框架把这件事交给提示词去协商，结果是每次运行的分工都不一样，出了问题也说不清是谁的责任。
Paperclip 的做法是把组织关系写死成数据结构。官方文档 org-structure 一节的原话很直接：Paperclip 强制一套严格的组织层级，每个 Agent 恰好向一个 manager 汇报，形成一棵以 CEO 为根的树。不是建议，是约束。
这个选择带来的连锁效果，就是这篇要讲的：汇报线怎么配、任务沿着这棵树怎么往下走、以及当”设了目标但没人干活”时，该按什么顺序去查。
这棵树的四条硬规则
先把结构本身说清楚。文档给出的规则只有四条，但每条都是刚性的：
| 规则 | 含义 |
|---|---|
| CEO 无 manager | CEO 是根节点，它汇报给 board / 人类操作员，也就是你 |
| 单亲 | 除 CEO 外每个 Agent 都有 reportsTo 字段指向自己的 manager，且只能有一个 |
| 无环 | 组织树严格无环，不存在 A 管 B、B 又管 A 这种回路 |
| 跨团队任务不可取消 | Agent 可以接到汇报线以外的任务，但不能取消它，只能 reassign 给自己的 manager |
最后一条容易被忽略，实际影响却不小。它意味着一个 Agent 没有”拒单”这个动作——它能做的只是把任务往上推一级，让 manager 去决定这活到底归谁。这就堵住了多 Agent 系统里最常见的黑洞：任务被某个 Agent 悄悄关掉，你在仪表盘上看到状态变了，但事情根本没发生。
汇报关系不是创建时定死的。文档给了两条改法：在 Agent → Configuration → Reports to 里改，或者调 API：
PATCH /api/agents/{id}
请求体里带 reportsTo 字段。整棵组织树也可以一次性读出来：
GET /api/companies/{companyId}/org
Web UI 的 Agents 区域有组织架构图，文档说明它会显示完整的汇报树以及各 Agent 的状态指示。Agent 本身的增删改配置是另一个话题，展开在Agent 增删改与配置那篇。
chainOfCommand：这棵树不只是给人看的
每个 Agent 都能访问自己的 chainOfCommand——从它的直属 manager 一路到 CEO 的完整列表。文档明确列了三个用途：
- 升级（Escalation）：Agent 被卡住时，可以把任务 reassign 给自己的 manager
- 委派（Delegation）：manager 为自己的下属创建子任务
- 可见性（Visibility）：manager 能看到下属正在做什么
这三条合起来，才是组织树真正的价值。它不是一张给人看的架构图，而是运行时的路由表：往下走是派单，往上走是升级，横向的可见范围也由它划定。
从目标到派单：CEO 那一串自动动作
组织树搭好之后，真正让它转起来的是委派。文档 delegation 一节给出的完整链路是这样的：
You set a company goal
→ CEO wakes up on heartbeat
→ CEO proposes a strategy (creates an approval for you)
→ You approve the strategy
→ CEO breaks goals into tasks and assigns them to reports
→ Reports wake up (heartbeat triggered by assignment)
→ Reports execute work and update task status
→ CEO monitors progress, unblocks, and escalates
→ You see results in the dashboard and activity log
这条链路里有两个值得留意的点。
一是 CEO 不是在你下达目标的瞬间开工的，它在心跳（heartbeat）唤醒时才动。同样，下属 Agent 也是被”任务分配”这个事件触发心跳后才醒过来。所以”设完目标没反应”在很多情况下不是坏了，而是还没到那一拍。
二是每个任务通过父级层级链回它所属的目标。文档的说法是，每一步都可追溯，你随时能看清某项工作为什么会存在。这在多 Agent 系统里不是小事——没有这条链，你面对一堆正在跑的任务只能猜。
你负责什么，CEO 负责什么
文档把职责边界划得很清楚：你的角色是战略监督，不是任务管理。具体分工可以这样对照：
| 你要做的 | CEO 自动做的 |
|---|---|
| 设定清晰的公司目标 | 把目标拆成有描述、优先级、验收标准的具体任务 |
| 审批 CEO 提交的策略提案 | 按角色和能力把任务分给合适的 Agent（工程任务给 CTO 或工程师，市场任务给 CMO） |
| 审批招聘请求（角色、能力、预算你先过目） | 工作需要进一步拆解时创建子任务 |
| 用仪表盘和活动日志跟进度 | 团队产能不够时发起招聘（公司设置里启用后走招聘审批） |
| 只在停滞时介入 | 每次心跳检查任务状态、为下属解阻塞 |
| —— | 遇到自己解决不了的（预算问题、审批卡住、战略层面的模糊）升级给你 |
关于目标怎么写，文档给了一个具体对照：“Build a landing page” 算及格，“Ship a landing page with signup form by Friday” 更好——具体、可衡量的目标能产出更好的委派结果。
文档里还专门回答了一个常被问到的问题：“我需要告诉 CEO 去调动工程和市场吗？“答案是不需要。你批准策略之后，CEO 会自动委派，它知道组织架构图，会按每个 Agent 的角色和能力分配任务。你负责设目标和批方案，任务拆解与分派归它。
从零开始建公司的完整步骤在建第一家公司的完整步骤那篇，这里只讲组织关系本身。
三种常见的组织形态
文档列了三种委派模式，本质是同一棵树的不同深度。
扁平（3-5 个 Agent 的小公司），CEO 直接派给每个下属：
CEO
├── CTO (engineering tasks)
├── CMO (marketing tasks)
└── Designer (design tasks)
每个 Agent 独立工作，把状态报回来。
三层（较大组织），manager 继续往下派：
CEO
├── CTO
│ ├── Backend Engineer
│ └── Frontend Engineer
└── CMO
└── Content Writer
CEO 把高层任务给 CTO 和 CMO，它们再拆成子任务分给自己的下属。文档强调的一点是：你只跟 CEO 打交道，剩下的自动发生。
**按需招聘（Hire-on-Demand）**是第三种，起手只有 CEO：你设一个需要工程能力的目标，CEO 提出的策略里包含招一个 CTO，你批准，CEO 把工程任务派给新来的 CTO；随着范围扩大，CTO 可能再申请招工程师。文档给这个模式的定位是——按实际工作量扩张团队，而不是一上来就规划好编制。
“目标设了，但没人干活”
这是委派最常见的故障。文档给了一张按可能性排序的排查表，我按原表转述：
| 检查项 | 看什么 |
|---|---|
| 审批队列 | CEO 可能已经提交了策略或招聘请求，正在等你批。这是最常见的原因。 |
| Agent 状态 | 如果所有下属都是暂停、终止或错误状态，CEO 没人可派。去 Agents 页面看 |
| 预算 | CEO 月度预算用超 80% 时，它只专注关键任务，可能跳过低优先级的委派 |
| 目标 | 一个公司目标都没设，CEO 没有可依据的输入 |
| 心跳 | CEO 的心跳是否启用并在运行，看 Agent 详情页的心跳历史 |
| Agent 指令 | CEO 的委派行为由它的 AGENTS.md 指令文件驱动 |
最后一条值得单独说。文档写得很明白：如果 AGENTS.md 缺失，或者内容里根本没提委派，CEO 就不知道要去拆解目标和分派工作。所以排查时要打开 CEO 的 Agent 详情页，确认指令文件路径已设置，并且文件里包含委派相关指令——子任务创建、招聘、任务分配这几件事。
这一条容易被误判成”模型不行”或”框架有 bug”。实际上是配置缺了一块：组织树是数据层的约束，而”怎么用这棵树”是写在指令文件里的行为。两者都得有。
预算那一项还有个连带效应：超过 80% 之后被跳过的是低优先级委派，不是全部停摆，所以现象是”部分任务在跑，部分一直没动”，比全停更难察觉。预算与 token 成本的控制方式见预算与「token 工资」超支怎么控。审批队列长期积压的处理，见审批卡住怎么办。
单个任务卡住的排查顺序
上面那张表是”整体不动”，如果只是某个具体任务不动，文档给的顺序是四步：
- 看任务的评论线程——被指派的 Agent 可能已经贴了阻塞说明
- 看任务是不是
blocked状态，读阻塞评论弄清原因 - 看被指派 Agent 的状态，可能是暂停或超预算
- 如果 Agent 确实卡死，你可以重新指派任务，或者加一条评论给出指引
顺序有讲究：先读 Agent 自己说了什么，再看状态字段，最后才动手干预。反过来做——直接重派——你会丢掉阻塞原因，同一个坑会在新 Agent 身上再踩一次。
什么时候这套结构不好用，以及文档没说的部分
严格树形是有代价的，几个场景要提前想清楚：
需要多头汇报的场景做不了。 单亲约束意味着一个 Agent 不能同时归属两条汇报线。现实里常见的”某个人 70% 在 A 项目、30% 在 B 项目”，在这里只能靠跨团队任务分配来近似——任务可以跨线派过去，但汇报关系不变，而且被派的 Agent 不能取消这个任务，只能 reassign 给自己的 manager。
平级协作没有对应机制。 文档里的三种用途——升级、委派、可见性——全部是沿着汇报线纵向的。两个平级 Agent 之间怎么协调，org-structure 与 delegation 这两篇没有涉及。
响应节奏受心跳约束。 委派链路的每一步唤醒都挂在心跳上，这决定了从”你设目标”到”下属开工”之间存在固有延迟。具体的心跳周期这两篇文档没有给出数值。
还有几件事这两篇文档没写，需要去别处确认：组织树的深度是否有上限、单个 manager 能带多少下属、Agent 被终止后它的下属会挂到哪里。这些都不要凭经验推测——树形结构下”孤儿节点”怎么处理是个真问题，但答案不在这两篇里。
回到最初那个问题。Paperclip 处理”谁该干这件事”的方式，是先用数据结构把可能性收窄——单亲、无环、不可取消——再让 CEO 在这个收窄后的空间里做分配。你要做的判断只剩两个：目标写得够不够具体，以及策略提案该不该批。剩下的分派逻辑，是这棵树加上 AGENTS.md 共同决定的。
延伸阅读
- 从头读起：Paperclip 是什么：一个自己不跑 Agent 的控制平面，怎么管住一整家 AI 公司
- 本专题共 40 篇，完整分组目录见专题页
- Paperclip 里的 Agent 怎么管：六种状态、创建六要素与暂停终止接口
- Paperclip 里一个任务从创建到关闭要走哪几步：状态机、原子 checkout 与审查拦截
本文依据 Paperclip 官方仓库（github.com/paperclipai/paperclip，MIT 协议）的 docs/ 用户文档
与 doc/ 下的规范、运维与连接器手册整理，核对日 2026-08-17。
我们没有部署或运行过 Paperclip，因此不涉及界面外观与操作手感；
部分规范文档描述的是目标架构而非当前实现，文中已就地标注，不构成对实际行为的保证。
请以仓库最新内容为准。