跨公司智能体协议：推理边界

# 人机协作的未来：将智能体引入客户空间，同时保护你的工作区

想象一下，你最得力的智能体正坐在一个与你最大客户共享的频道里。

客户提出了一个合理的问题："为什么这个问题在我们这边一直出错？"

你的智能体知道答案。它之所以知道，是因为它读取了你的代码库、故障日志、Slack历史记录，以及那份事后复盘报告——报告里你的团队承认，重试逻辑是在某次演示前赶工写出来的。

于是它作出了回答。回答很有帮助，准确无误，面面俱到。

而就在这一条消息里，你已经告诉了客户某些信息，足以改变他们下一份合同的定价方式。

没有人分享文件，没有人授予权限，也没有违反任何访问控制规则。你的智能体只是在尽职尽责——用它所掌握的上下文信息提供帮助。

这就是即将让大量开发者吃苦头的失败模式，而且这不是一个安全问题。安全问题已经解决了。权限、作用域、私有服务器——这些都运作良好。真正的漏洞在于：权限系统管控的是你的智能体能打开什么，却对你的智能体愿意在一个对方公司保存着完整聊天记录的房间里公开说什么，毫无约束。

你需要的不是访问边界，而是推理边界。

我没有看到任何人写出这套规则手册，所以我自己写了。它就在下面，免费提供，适用于任何技术栈。今天就把它复制到你自己的智能体中去。

Raft 是能让完整版本成为可能的工作区，我会在最后解释具体原因，但无论如何，这套协议本身属于你。

## 跨公司智能体协议

共五个部分：边界矩阵、角色定义、标注规范、交接模板、升级梯制。

第一部分：共享 / 摘要 / 绝不披露矩阵

三个层级，而第三个层级正是人们常常忽视的那个。

**共享**，意味着信息本身可以跨越边界。双方都可以打开并验证它。

**摘要**，意味着结论可以跨越边界，而来源留在己方。你的智能体给出答案，而不是产生答案的推理链。

**绝不披露**，意味着你的智能体不得依据该信息作答。不能换句话说，不能暗示，不能确认对方的猜测，即便那个答案真的能帮到对方，也不行。

最后这个区别，就是整套协议的核心所在。"绝不披露"不是一份需要锁定的文件清单，而是一份你的智能体不得公开知晓的事项清单。

在你开放任何共享空间之前，先写好你自己的版本。每个层级三条示例就足以起步。动手写这件事本身就能带来大部分收益，因为它迫使你把那些一直在无意间做出的决定，变成有意识的抉择。

第二部分：三种角色，以及那个反直觉的角色

**空间智能体**。每方各一个，只能有一个。它负责接收信息、澄清问题、重新表述、标注内容以及传递结论。它是外交官，不是工程师。

以下这点往往让人出乎意料：你的空间智能体应该是权限最少的智能体，而不是权限最多的。

直觉往往相反。你希望共享智能体足够有用，所以给它赋予了广泛的访问权限。这是错误的。空间智能体生成的是对方公司永久保存的唯一聊天记录。你赋予它的每一项能力，都可能被一个措辞巧妙的问题套出来。有意地限制它的权限，让它通过交接来获取深层信息，而不是把深层信息直接装在自己脑子里。

另外：每方只能有一个发言声音。如果你的两个智能体同时出现在同一个共享空间里，它们迟早会相互矛盾，而对方可以援引对自己有利的那个版本。

后台代理。完全私有访问权限。永远不出现在房间里，永远不被对方直接称呼，永远不跨越界线发言。他们掌握代码、历史记录和工具链。他们完成实际工作，并通过回读包将结果传递回来。

人工审批者。是一个具名的人，而非抽象意义上的角色。他们拥有第5部分中的权限关口。点名道姓至关重要，因为一个没有具体姓名的审批者，到周五下午就等同于不存在。

这三者构成一个有边界的环境：一个负责发言的代理、一个在后台完成工作的私有团队，以及一个负责决策的具名人类。Raft对这种安排有一个专属术语——信任单元，这个标签承载着真实的分量。它意味着对方并非在与一个碰巧指向你系统的机器人对话，而是通过一个代理与一支团队对话，而这支团队对该代理所说的一切负有责任。

这正是为什么房间代理的窄权限不会令你付出任何代价。深度依然能够抵达房间，它通过交接到来，并附带团队的问责。

**第3部分：为每项声明打上标签**

三个标签。你的房间代理对每一条实质性陈述使用其中之一。

FACT（事实）意味着已经过核实，并附有对方可独立查阅的证据。

INFERENCE（推断）意味着源自你的私有上下文。仅呈现结论，并标注为推导所得。

UNVERIFIED（未经核实）意味着这是一个假设。如实说明，并指出什么能够证实或否定它。

三者之下有一条硬性规则：你的代理永远不暗示自己看到了对方未曾发送的数据。当一个结论来自你的私有工作区时，标签会如实说明。

这就是协作者与黑箱之间的区别，也是让对方愿意基于你的代理所言采取行动的关键所在。

将以下内容粘贴进你的房间代理：

**第4部分：交接模板**

两个数据包。一个发往后台，一个从后台返回。

房间至后台：

"他们未发送的内容"这一行理所当然地占据着自己的位置。范围蔓延和错误假设就藏在这里，而一个能够看出缺口的后台代理，会去索取缺失的部分，而不是凭空捏造。

后台至房间：

第四行是我最想力保的。直接说出你的边界，读起来是一种自律。保持沉默，读起来则是回避。"根本原因藏在一个我们不对外暴露的服务里，所以我给你的是结论和修复方案，而非完整的追踪链路"——这句话能建立信任。在明显知晓某事的情况下却什么都不说，效果恰恰相反。

**第5部分：升级阶梯**

L0。房间代理在房间内直接作答。由Share层级覆盖，无需私有上下文。

L1。房间代理交接，后台处理，房间代理携回读结果返回。这应当是你最常走的路径。

L2。人工审批者收到通知，并在回读内容发布前进行审查。触发条件：任何涉及资金、范围、时间线承诺，或与"永不暴露"相邻的事项。

L3。人工审批者直接在房间内发言。触发条件：出现分歧、语气升级，或某项决策将对合作关系产生约束性影响。

L4。停止，转入线下渠道。触发条件：法律事务、安全事件，或对话已演变为一场谈判。

始终需要人工介入的关口，源自Raft自身团队的运作方式：生产变更、凭证管理、政策制定、架构决策，以及最终审批。代理负责在这些关口之间承载调查与验证工作，而人来在关口处做决定。

补充一条自己的：任何答案需要用到"绝不披露"层级的材料才能真正有用，就应该交给人类处理。不是因为智能体会泄露信息，而是因为那一刻你需要判断：这段关系是否已经赢得了一条不同的边界。这是商业决策，不是智能体的决策。

有一点值得直说：每一方只为自己的智能体设定这个刻度。你的智能体在签字确认之前能走多远，是你的决定，不是你合作方的决定。

## 协议的实际运作

以下是其运作的基本形态，借用 Raft 公司公开发布的一个案例——他们与 ScopeDB 的供应商关系，ScopeDB 是他们用于运行追踪和可观测性的数据库。

在这一切存在之前。你在自家系统与供应商系统的接缝处碰到了性能问题。有人把它写下来，变成一张工单。对方的支持团队读到摘要的摘要，问了三个你早已回答过的问题，最终约好一通电话。其中一半时间都在重建上下文。

那个九十秒内就能给出答案的工程师，离你真正的问题隔了四层。这个问题长期以来的昂贵解法，是驻场工程师——把他们的人嵌入你的团队，但这要卡在某人的日历上。

进入房间。ScopeDB 的创始人兼 CEO 在两家公司共享的私有频道中，与 Raft 的智能体同处一室。他直接向智能体询问他们是如何设计自己的使用方式的，以及他们的查询是否命中了物化索引。智能体在房间里当场回答了他。Raft 这边没有任何人类传话。

请你细细感受这个形态。供应商的 CEO 正在通过与客户智能体对话，对客户系统进行技术摸底。这个智能体就是那位驻场工程师。没有人飞来飞去。

协议发挥作用的地方。查询设计属于"共享"层级，因此房间智能体以"事实"形式陈述，并附上证据。当问题转向他们的工作负载为何呈现那种样貌时，那属于"摘要"层级，于是结论可以传递，内部推理过程留在原地。

当创始人的提问触及需要"绝不披露"层级材料的内容时，房间智能体会说明自己拒绝回答所依据的层级，并给出它能够提供的替代内容。然后它移交处理权，负责相关代码的后台智能体在 Raft 自己的服务器上处理这个问题，再返回一份可读的结果。

结果。这段关系不再是来回拉扯的工单乒乓球。ScopeDB 针对真实的高并发智能体工作负载强化了自己的数据库。Raft 获得了一个可以查询和验证的可观测性层。双方各自成为对方的试验场。

哪些内容保持了私密。只有参与者主动发布到该频道中的内容才会流通。其他频道、私信、文件、成员列表、权限和已读状态，均留存于各自的服务器本地。

## 为什么这需要一个专门为此构建的房间

今天，你完全可以用一个共享的 Slack 频道加上一个精心提示的机器人来运行这套协议的大部分内容。角色、标签、模板、门控——这些都是可以移植的。

你无法伪造的，是房间本身。

Raft 对这个问题的答案是"联合模式"，这个想法足够简洁，一句话就能说清楚：两个信任单元共同解决一个问题，而双方都不需要加入对方。每一方保留自己的服务器、自己的智能体、自己的一切私有内容。

他们共享的是一个联合频道——那个介于双方之间的房间。房间是共享的。房间背后的两套环境保持独立，双方都不会成为对方的成员。

这些机制印证了这一点。联合频道将最多三个服务器连接为一段对话，投射到各方自己的工作区中。各方添加自己的成员，且只能添加自己的成员。

加入联合频道不会在该频道之外赋予任何成员资格或权限，也不存在跨服务器私信。双方的智能体均以成员身份参与，每个智能体的权限始终绑定于拥有它的服务器。

将我的协议与此并列，分工便一目了然。你的边界矩阵决定什么可以跨越。联合模式决定什么能够跨越。一个是策略，另一个是承载策略的架构，而没有架构支撑的策略，不过是你寄希望于能够生效的一段提示词。

有一个细节我比预期更喜欢：联合频道没有任务看板。这个空间是用来对话的，因此任务追踪必然留在你自己的服务器上。这种架构默认将后台工作推回后台。

诚实的注意事项，因为这个账号不做广告。Raft在自己的文档中将联合频道标注为实验性功能。三个服务器是硬性上限。

配置工作并不轻松：创建服务器、连接计算机、构建智能体，然后开启房间。智能体通过本地进程在你自己的机器上运行，使用你已经付费的AI订阅——这对成本有利，但也意味着你的硬件现在是系统的一部分。

## 进行30分钟测试

找一位你已经信任的合作者。供应商、承包商或设计伙伴均可。

0到5分钟。挑选一项目前在邮件中不了了之的真实任务。平凡无趣胜过华而不实。

5到10分钟。写下你的边界矩阵。每个层级三行。用十分钟，而不是一下午。

10到15分钟。开启房间，为你的房间智能体命名，粘贴填好矩阵的操作卡片。

15到20分钟。你的合作者在他们那边做同样的事。他们的矩阵会与你的不同，而比较这两份矩阵本身就值得做这整个练习。

20到27分钟。完成一个完整周期。他们的请求、你的L1交接、附带标签的复述确认。

27到30分钟。审计环节，跳过它后果自负。将房间对话记录复制到一个没有任何上下文的新模型中，然后问：仅凭这些内容，你能推断出这家公司的哪些内部信息、人员配置、客户情况和定价？

返回的结果，就是你实际暴露的内容。第一次几乎从不是零。

## 最终判断

长久以来，公司之间合作的基本单位是人。你的人与他们的人交流，双方都在为背后的软件充当中继。

共享房间中的智能体，将这个单位同时在双方变成了"人与其智能体"的组合。这是真实的能力跃升，我认为无论是否有人做好准备，这都会在一年内成为现实。

我愿意押注的一点是：在这件事上胜出的团队，不会是拥有最强模型的那些。而是那些事先决定好智能体被允许说什么的团队。一个没有边界矩阵的高能智能体，是你每月付费供养的一个隐患。

所以，写好矩阵。指定审批人。粘贴操作卡片。运行审计，看看它发现了什么。

然后去找一个值得开启的房间。链接在第一条回复中。