协作

ORG-2 中的一次智能体会话，是一条可回放的执行轨迹——这让它像 pull request 一样可以被审阅。协作正是围绕这个想法搭起来的：你决定队友能看到会话的多少内容，他们把它打开，针对具体事件发表评论，然后线程被标记为已解决。这里的一切都归属于某个组织（ORG）——怎么创建组织见组织（Organizations）。

注意： ORG-2 的 README 把自托管 Supabase 上的会话协作和群组 issue 工作流标记为进行中。本页会说明每项能力实际存在于哪条路径上；还没实现的地方也会明确写出来。

决定队友能看到什么

默认什么都不共享。在某个 ORG 的 设置 标签页里，Session 访问 控制哪些内容会离开你的机器：

光有模式还不够。你还要挑选 允许的 Workspaces——也就是可以被共享的仓库路径。至少选中一个 workspace 之后，才会开始共享。 仓库路径不在这个列表上的会话永远不会被推送；而移除某个路径，会在下一轮同步时撤回该路径下会话的元数据。应用会用大白话提醒你最高那一档：完整 replay 可能包含 prompts、输出、tool calls 和文件路径，所以只对你信任的 ORG 开启它。

在 ORG-2 Cloud 上，同一套阶梯在服务端体现为会话的 access_mode（metadata_only 或 full_replay），另外还多两项控制：

• 仓库范围。 管理员配置一份列表，规定这个 ORG 接受哪些仓库的会话。推送时带上范围之外的仓库会被拒绝，返回 ORG2_SCOPE_FORBIDDEN。没有配置任何范围的 ORG，一个会话也不接受。
• 共享下限。 管理员可以在 ORG 级别设定一个最低访问模式，再为单个成员设定更严格的下限。你实际生效的下限取两者中更高的那个；服务器会把推上来的会话提升到这个下限，而不是拒绝它——这样过期的客户端也没办法推送出低于策略的内容。

会话还有一个 可见性：org（每个成员都能列出它）或 restricted（只有所有者和持有定向分享的人能看到）。restricted 没有留给管理员的绕过通道。

拿到队友的回放

在自托管 Supabase 这条路径上，回放是按需拉取的，而不是持续上传。

1. 你在 ORG 的 Sessions 标签页点开队友的 session 卡片。如果它只以卡片形式共享，你会看到 此 session 仅共享元数据，无法打开完整 replay。
2. 如果它是以完整 replay 共享的，ORG-2 会提交一个 snapshot 请求，并显示 正在向所有者请求 session replay...
3. 所有者的应用会在下一轮同步时作答——自动完成，并且只在它自己的访问设置仍然允许时才答应。否则就会带上理由拒绝（会话回放不被所有者的设置允许，或会话在所有者的设备上不可用）。
4. 快照到了以后，会作为一个新的本地会话导入，标记为 Collaboration Snapshot，并为你打开。

同步按 10 秒轮询运行。每一轮都会校验 Supabase schema、发布或撤回你的会话元数据、交换快照请求，并拉取该 ORG 的成员、邀请、项目、工作项、会话和聊天记录。

在 ORG-2 Cloud 上，回放改成推送：会话以只追加的事件分段同步，冻结后的分段被卸载到私有的 replay 存储桶，成员在行级安全策略下直接读取它们。没有请求—批准的这一来一回。

分享链接与定向分享

在成员名单之外做分享，只在 ORG-2 Cloud 上存在。会话所有者创建的分享，恰好是以下两种形态之一：

• 定向分享 —— 授予某个指定的活跃 ORG 成员，所以名字写错会当场报错，而不是留下一个无效授权。接收方会看到该会话被标记为直接分享给自己，「与我共享」视图正是靠这个撑起来的。
• 链接令牌 —— 一个任何人都能使用的不透明令牌。数据库里只存它的 SHA-256 哈希，原始令牌从不落库。

每个分享都带一个级别——metadata 或 replay——以及一个可选的过期时间。会话所有者或 ORG 管理员都可以撤销分享；撤销是即时且幂等的。

链接分享永远不可能超出所有者已经选定的范围。要成功解析一个分享令牌，需要令牌是 replay 级别、ORG 处于有效状态、会话处于 full_replay，并且该会话落在套餐的回放时间窗之内。任何一项不满足都返回同一个不透明的未授权错误，所以没法拿令牌去试探哪些会话存在。访客读取存储桶里的回放分段，要经由一次性的、60 秒有效的授权中转，由服务端路由拿它去换签名 URL。

评论与线程

评论是 ORG-2 Cloud 的功能。任何能读到某个会话的成员，都可以对它发表评论。

• 一条评论要么是顶层评论，要么是对某条顶层评论的回复。线程只有一层深。
• 评论可以锚定到轨迹中的某个具体事件，你正是靠这个来审阅某一次工具调用或某一处修改。锚定要求该会话以完整回放共享；在仅卡片的会话上锚定会以 ORG2_REPLAY_NOT_AVAILABLE 失败。事件锚点和回复两者互斥。
• 正文长度为 1–4,000 个字符，单个会话最多容纳 500 条评论。
• 编辑 只有作者能做。删除 作者或管理员都能做，删除后留下一个正文被清空的墓碑，而不是在线程里留个洞。
• 解决 只适用于顶层评论，标记为 resolved 或 wont_fix。作者、会话所有者或 ORG 管理员都可以解决或撤销解决。
• 会话所有者可以发一条 agent_report 类型的评论——这是一个归属标签，专门留给所有者自己的智能体回复，其他成员伪造不出来。

每一行会话记录都带着实时的 commentCount 和 unresolvedCommentCount。这就是「这个到底审过了没有」的信号：一个还挂着未解决线程的会话，相当于一个还有未处理评审意见的 PR。

多人一起审阅智能体的工作

把这些拼起来，审阅闭环就是：智能体运行，它的轨迹同步进 ORG，队友回放它，在智能体做错的地方留下锚定到事件的评论，然后这些线程被解决或标记为不予修复。如果有人想在不打扰原会话的前提下把这份工作往前推，可以 fork 一个会话——fork 会记录它来自哪个源会话和根会话，而在查看 fork 时留下的评论算在这个 fork 头上，源会话依然是那条权威线程。轨迹查看器本身见回放。

群组工作项与项目

一个 ORG 的 Work Items 和 项目 标签页，映射的是它共享出来的结构。在 ORG-2 Cloud 上，这些是真正同步的记录：

• 工作项带有所属项目、短 ID、状态、优先级、负责人、里程碑、日期，以及用于子项的父项。短 ID 由服务端按项目级的前缀和计数器分配。
• 写入是乐观的：你把这次编辑所基于的版本一并发过去，过期的写入会被当作冲突拒绝，而不是悄悄覆盖别人的改动。
• 工作项可以被置于 执行锁 之下，好让某个智能体认领它。超过 30 分钟的租约即视为过期、可被接管，因此崩溃的智能体绝不会把一个工作项永久卡死。

在自托管这条路径上，项目和工作项以不透明元数据的形式在成员之间镜像，并且只读展示。面向 issue 和项目的组织级对齐界面，在 README 中被标记为进行中。

群聊

群聊 标签页是自托管 Supabase 路径上按 ORG 划分的消息流。只有 Human 身份可以发言——身份为 Agent 的成员在这里是只读的——面板只保留最近 100 条消息。

实时在线状态与变更信号

在 ORG-2 Cloud 上，每个 ORG 有一条私有实时频道 presence:org:<orgId>，只有活跃成员能加入。它承载两样东西：当前谁在线的在线名单，以及一条告诉客户端「有东西变了」的 org-db-changed 广播。信号按种类打标签——sessions、projects、workItems、comments、roster、policy——每种每秒最多去抖成一条，并且在事务提交时才发出，所以被回滚的事务绝不会惊动任何人。

那只是一次提醒，不是数据本体：客户端用增量游标重新拉取受影响的那一面，而不是让行数据经由这条链路传输。成员关系变更是例外，会被直接送达，这样即使成员是在离线时被移除的，重新连接时照样会被踢出去。

实时在线状态是一项付费权益。 它在免费套餐上关闭，在 Pro、Team 和 Enterprise 上开启。

还在进行中的部分

• 自托管 Supabase 路径 没有实时在线状态。队友的活动是从 10 秒轮询拿到的会话元数据里推断出来的；「今日活跃」来自最后活动时间戳，而不是一份真正的在线名单。
• 没有 跟随模式 能实时串流队友正在运行的会话。回放共享在自托管上基于快照，在 Cloud 上基于分段。
• 评论、线程和分享链接在自托管的 schema 上并不存在。 它们是 ORG-2 Cloud 的功能。
• 自托管应用 没有退出 ORG、转让所有权或修改角色的界面。管理员可以创建邀请、移除成员；成员管理的界面就只有这些。

下一步

• 组织（Organizations） —— 角色、邀请、配额，以及一个 ORG 划走了哪些数据
• 会话 —— 一次会话记录了什么
• 回放 —— 回放并审阅一条轨迹
• Cloud —— 托管后端与自托管 Supabase 的对比