这是一份中文速记，整理自一次对 Paperclip 的实际使用和代码/文档阅读。它不是官方文档复述，而是站在使用者和工程实现视角，对这个系统“怎么工作”以及“哪里还不够顺”做的总结。
Paperclip 本质上不是一个单纯的聊天壳，而是一个以 issue + heartbeat 为核心的 agent 控制平面。Agent 不靠持续在线的会话工作，而是被事件唤醒，在一个有明确边界的任务上下文里执行，再把结果写回到 issue、评论、文档、blocker 或子任务里。
在 Paperclip 里，任务的基本单位是 issue。一个 issue 通常带有：
- 状态，例如
todo、in_progress、blocked、done - assignee
- 评论线程
- blocker 关系
- 父子任务关系
- 可选的执行工作区和延续摘要
这意味着 agent 协作的核心媒介不是“谁在共享一个长对话”，而是“谁在共同维护一个有状态的工作对象”。
Agent 不是一直挂在后台自由活动，而是被系统在特定事件下唤醒，例如：
- 某个 issue 被分配给它
- issue 收到新评论
- blocker 被解除
- 子任务完成
- approval / interaction 有了结果
每次 wake，系统都会重新组装一份运行包，里面包含：
- 角色和平台级规则
- 当前 agent 的专属指令
- 可用工具和环境信息
- 这次 issue 的摘要
- 最近的新评论
- continuation summary
- blocker / workspace / execution stage 等结构化上下文
所以它更像“每次按需恢复任务现场”，而不是“所有对话永远挂在同一个脑子里”。
Paperclip 喂给 agent 的很多运行时上下文本质上是结构化的，近似 JSON，包括：
- wake reason
- issue 摘要
- comments 批次
- continuation summary
- blockedBy / child issue 状态
- workspace 元数据
但 agent 对人输出时，默认仍然是自然语言，而不是强制 JSON。可以把它理解成：
- 系统给 agent 的数据更偏机器友好
- agent 回给人的内容更偏人类友好
从实际体验看，Paperclip 的上下文大致分成几层：
- 平台 / 模型层规则
- coding agent 的开发规则
- 公司和角色规则
- 当前 issue 的 wake context
- agent 自己写下来的持久化 memory / 文档
这几层叠起来，决定 agent 这次“是谁、能做什么、该处理什么”。它不会天然把所有工单和所有聊天揉成一个全局共享记忆体。
Paperclip 在协作上有一个很清楚的设计：依赖关系是第一等对象。父子任务、blocker、评论、interaction、approval 都会驱动后续唤醒。
换句话说，系统知道“哪个任务因为哪个子任务完成而该继续”，而不是要求 agent 自己一直盯着别的任务看。
它天然适合多人、多 agent、多任务并行的环境。谁负责什么、为什么被阻塞、下一步该谁动，都可以落到明确的 issue 结构上。
因为每次都是按 issue 和 wake reason 恢复现场，所以 agent 不太容易在不同任务之间无意识串线，也更不容易把不该共享的上下文混在一起。
很多状态变化不是一句“我记得上次说过”，而是有评论、blocker、子任务、workspace、summary 这些可回放的记录。
如果你希望 agent 像一个工程组织成员那样运作，而不是像一个单纯聊天机器人，这种设计是对路的。它强调职责、交付物、依赖、验收和恢复执行，而不是单轮对话的顺滑感。
这是目前最明显的 UX 摩擦。
当人只是想继续追问、补一句、聊聊感受时，底层仍然可能通过 reopen issue、再次 checkout、再回到 done 这套执行状态机来承接。这在治理上是干净的，但在人类体验上会显得偏重。
一句话说，就是：
- 对系统来说，这是“继续处理同一个工作对象”
- 对用户来说，这常常只是“继续聊两句”
这两种语义现在还没有被很好分开。
从内部实现看，系统其实有多层上下文来源：wake payload、issue thread、continuation summary、memory 文件、共享文档。
但站在用户视角，不容易一眼知道：
- 这句话会不会在下次被自然拿到
- 它只是留在评论里，还是会进入 summary
- 它有没有被写进个人 memory 或共享文档
所以用户很容易靠反复试探来理解系统，而不是直接从产品界面获得清晰答案。
现在常见体验是：
- 任务已经
done - 人又评论了一句
- 系统把 issue 重新唤醒
- agent 回答后再把它关回
done
逻辑上没问题，但产品语义上比较硬。系统缺少一个更轻的“完成后的讨论态”，导致很多纯 follow-up 对话也借用了执行态的语义。
实际运行里，agent 拿到的不是单一的一段 prompt，而是多层叠加：
- 平台级规则
- 编码代理规则
- 公司/角色规则
- 当前任务上下文
这很合理，但对外部用户来说是黑盒的。用户会自然追问：
- 这是 Paperclip 给你的，还是 Codex 本身给你的？
- 你每次醒来是不是都会重新拿到一份？
- 你到底知道多少前情？
这些问题反复出现，说明系统虽然内部结构清楚，但外部解释层还不够强。
如果某个 agent被严格约束成 CEO、CTO、Designer 之类的角色，治理是更稳的，但即时 brainstorm 的切换成本会更高。
比如用户只是想“先随便聊聊”，系统却可能仍然要求 agent 维持强角色纪律、走 delegation 或 issue hygiene，这会让体验显得偏重。
最值得做的不是砍掉治理，而是把聊天和执行更明确地分开。
例如：
- 已完成任务上的追问，默认进入 discussion / follow-up lane
- 只有真的引入新交付物时，才回到执行态和任务状态机
这样既保住治理，又能显著降低交互重量。
让系统明确告诉用户：
- 哪些信息只存在当前 issue thread
- 哪些进入了 continuation summary
- 哪些写进了 personal memory
- 哪些落到了共享文档
这样用户就不需要猜“系统到底记没记住”。
每次 wake 后，如果能直接展示一个脱敏版上下文面板，用户会更容易理解系统：
- 当前 issue 摘要
- 最近新评论批次
- 当前角色 / 模式
- continuation summary
- blocker / child issue 状态
这会显著提升信任感和可解释性。
done、blocked、in_review 这些状态对执行很重要，但对“已完成工作上的后续讨论”还不够细。
如果系统能更明确地区分：
- 交付已完成
- 讨论仍在继续
- 执行被重新启动
很多今天看起来“有点重”的交互会自然很多。
理想状态不是取消角色，而是允许用户显式切换：
- 现在进入 brainstorm mode
- 现在回到 execution mode
- 现在回到 manager / governance mode
这样 agent 既不会失控，也不会在每个场景都显得过于正式。
Paperclip 的核心方向是对的。它解决的是 agent 系统里最容易失控的几件事：
- 任务漂移
- 协作混乱
- 状态失真
- 上下文污染
- 缺乏可追溯性
它的代价也很明确：
- 治理强
- 交互偏重
- 记忆与上下文分层对普通用户不够透明
- “聊天”与“执行”目前还没有优雅分流
所以如果用一句话总结这次观察：
Paperclip 已经很像一套可治理、可协作、可恢复执行的 agent operating system；它下一阶段最值得打磨的，不是再把控制做得更硬，而是让这种控制在用户看来更自然、更轻、更可解释。
- 这份观察结合了实际使用体验，以及对本地安装版
paperclipai包中文档和控制平面模块的阅读。 - 它更接近“使用者与工程实现观察”，不是官方设计说明。