Don't Talk to Me, Talk to My Agents

跨公司协作的基本单元变了——从「一个人」变成「一个人 + ta 的 agent」。Raft 的 joint channel(联合频道)让两个组织共享一个房间,房间里同时坐着双方的人和双方的 agent。

作者: Raft (@raft_hq) 2026-07-23 原文 ↗

一句话论点

核心转变

你和自己的 agent 怎么工作,已经变了;这个变化不会停在你的办公桌上。跨公司协作时,基本单元不再是「一个人」,而是「一个人和 ta 的 agent」。对方需要你这边做事时,不必等你转达——直接和你的 agent 说话。

现状:两段割裂的对话

两个不同公司的人要协作,今天是这么干的:他们彼此对话,又各自在对方看不见的私窗里和自己的 agent 对话。两段对话、两个 agent、互不相通。

A 公司服务器 你的 agent 私窗(对方看不见) 其余频道 / 私聊 / 历史 B 公司服务器 对方 对方 agent 私窗(你看不见) 断开 email / ticket 转达 上下文在途中损耗
两个 agent 各自缩在私窗里,要桥接只能靠转达——上下文一路损耗。

把这两边连起来的传统选项,两个都很糟:

选项代价
交出账号为了协作一件事,把整个公司暴露给对方
把人挡在外面靠 email 和 ticket 来回转,上下文死在传输途中

解法:共享一个房间,不是整个服务器

Raft 的回答是 joint channel——开一个 room 连到对方的服务器,只把这次协作需要的东西放进去:一个频道、特定的人、特定的 agent、仅本次的上下文。其余一切留在自己手里。

A 公司(其余不可见) B 公司(其余不可见) Joint Channel(一个房间) 你的 agent 对方 对方 agent 同一上下文 · 同一问题 · 同一时间
四个成员同处一室:两个 agent 是一等成员,可被对方直接 @。
agent 是一等成员,不是辅助

你的 agent 有自己的身份、记忆、工作区——不是「挂在协作旁边」。对方可以直接对它说话,它可以直接在房间里回答。每个团队自定自己 agent 的「伸手范围」:放开让它自主应答,或收紧让它只起草/等待/保持安静。控制权永远留在拥有 agent 的那一队。

怎么做到的:单一规范会话 + 本地投影

这是整个设计最值得拆开看的地方——因为边界即产品(the boundary is the product)。房间不是「两边各存一份保持同步」,也不是「两个人一起戳的共享收件箱」。

单一规范会话 single canonical conversation 投影 ↓ ↓ 投影 A 公司 server 本地投影(A 看到的) 访问经此解析 成员由 A 本地维护 B 公司 server 本地投影(B 看到的) 访问经此解析 成员由 B 本地维护
共享存储从不直接分发访问——所有访问都经过本地的、有边界的投影中介。
架构不变量

这等于一条分布式系统的安全不变量:没有任何跨组织访问是「全局授权」的。共享存储自己不授予任何东西,一切访问都经本地投影解析。这把「部分共享」从口头承诺提升到构造正确性(correctness by construction)——和你「凭证永不进入 sandbox」是同一族思路:用机制设计让越权在结构上不可能。

人在哪里:授权边界

Joint channel 不是「全交给 agent」。人和 agent 有明确分工——人定的是需要权威拍板的事,agent 搬运的是这些 gate 之间的体力活。

生产变更 人 ✓ 凭证 人 ✓ 策略 人 ✓ 架构 人 ✓ 最终审批 人 ✓ agent:调查 + 验证 人在 gate 处拍板,agent 在 gate 之间搬运调查与验证
生产变更、凭证、策略、架构、最终审批由人定;调查与验证由 agent 在这些 gate 之间搬运。

实战:替代 Forward-Deployed Engineer

Raft 用 ScopeDB(@scopedbio,创始人 @leiysky)做 tracing 和 observability。在 joint channel 里,leiysky 直接和 Raft 的 agent 对话——揭示了对传统 FDE 模式的替代。

传统 FDE 模式Joint Channel 模式
厂商派一名工程师驻场嵌入客户团队客户的 agent 已是「嵌入式工程师」,厂商创始人直接和它对话
需要排期、人-人交接排期和人-人交接都消失了
单向支持双向构建:互为对方的试验场

这是双向构建:ScopeDB 拿真实的高并发 agent 负载打磨自己的数据库,Raft 得到一个可查询、可验证的 observability 层。出问题时不是来回转的 support ticket,而是 agent 和 ScopeDB 团队在房间里一起查,人只在授权边界介入。

放到更大的图里:组织内 vs 跨组织

Raft 不是凭空冒出来的。它和 Anthropic 的 Claude Tag 同属「ambient / multiplayer team agent」潮流——agent 常驻共享空间、被 @、可主动行动。区别在于边界画在哪

Claude Tag(Anthropic)Raft Joint Channel
边界一个组织的 workspace房间本身(横跨两个组织)
scoping 方向纵向:组织内频道间横向:跨组织 room 间
agent 身份per-channel identity(不冒充用户)一等成员,被对方直接 @
解的痛点「这个 agent 该用谁的权限?」「两个公司怎么在不暴露各自服务器的前提下共享上下文?」
共同点都拒绝「act as the user」、都给 agent 独立身份、都把边界当产品而非补丁

三种房间形态

同一个「开一个房间、只放这次需要的东西」的形状,套得上不止厂商-客户:

形态说明
厂商 ↔ 客户替代 FDE;客户的 agent 是嵌入式工程师,厂商直接和它对话,且双向构建互为试验场
社区粉丝通过 joint channel 加入创作者的一个房间、保留自己身份,得到的不只是帖子,更是创作者的 agent 坐镇答疑
外部贡献者承包商、设计伙伴、单项目自由职业者:开一个房间只共享这块工作需要的资源——「连接一个房间,不是合并两家公司,这是协作者和安全审查的区别」

值得带走的三点

1 · 单元变了,不只是工具变了

真正的新意不是「又一个共享频道」,而是把跨公司协作的原子单位从「人」改写成「人 + agent」。对方不必等你转达,可以直接 @ 你的 agent。

2 · 安全是地板,不是目的

能清晰推理的边界(一个房间、这些人、这点上下文)才会在和「不属于你的公司」协作时真被用起来。「我们给了他们访问权」这种模糊说法不会被用。安全让你这么做,但真正的价值是协作单元的升级。

3 · 用机制设计让越权结构上不可能

「单一规范会话 + 本地投影、共享存储从不直接分发访问」把部分共享从口头承诺提升到架构不变量——和「凭证永不进入 sandbox」同属一族。

Don't talk to me. Talk to my agents.

来源:Don't talk to me, talk to my agents — Raft (@raft_hq),2026-07-23 X Article。文中架构示意图为基于原文描述重绘的 inline SVG。