从单人对话到团队协同:为什么开通企业级 AI 后大家依然各聊各的?

把 AI 主要用于个人私聊时,往往局限在独立对话框内;从各自单聊走向跨角色的团队协同,需要看清人机协作的真实增益、工程目标与权限边界。

作者:Sergey Karayev / Superconductor09-07 · 15 分钟
THE MULTIPLAYER AI MANIFESTO · 2026.09

把 AI 主要用于个人私聊时,跨角色协作仍需人工搬运信息,带来上下文损耗与流程割裂。

多人协同 AI 的核心价值在于让团队跨端接续同一共享任务,并将人机交互中的纠偏沉淀为可复用的技能与资产。

过去十几年,办公软件大多完成了向多人协同的转变:写文档从邮件来回抄送 Word 附件,变成了多人在线实时编辑;做界面设计从各自导出本地文件,变成了全团队在同一个画布上协作;日常沟通也从封闭的个人收件箱,迁移到了按项目公开讨论的工作群组。

但引入大语言模型后,团队使用方式却常常退回到各自单聊:企业统一采购了 AI 账号,大家依然是在各自桌面上打开独立的对话框提问。一个人摸索出的好用提示词、排查出的关键业务陷阱,基本都留在了自己的聊天历史里,其他人看不到,也接不上手。

要理解这种脱节,可以先看两个基础概念:

  • 智能体(Agent):不同于只能被动回答文字问题的传统聊天机器人,智能体被授予了调用工具的能力,可以根据指令读取代码库、查询数据库、调用软件接口(API),并在外部系统中执行具体操作。

  • 共享会话(Shared Session):它不是把聊天记录导出为网页链接供同事只读浏览,也不是多个人盯着同一块屏幕,更不是让进入会话的所有人自动继承相同的系统权限;而是在各自权限受控的前提下,让不同角色(如产品、研发、运营)共同接入一个持续运行的任务环境,随时查看任务进度、共享上下文,并能从各自常用的工作工具中向同一个运行中的任务追加指令与反馈。

从单人各自开窗口走向支持团队协同的人机协作,需要弄清楚人际协同与 AI 结合的真实价值,以及背后的工程目标与安全边界。


一、单人对话模式的实际瓶颈

很多团队以为给全员开通账号后效率就会自然倍增,但在跨岗位的复杂业务中,单人对话很快会遇到两重阻碍。

1. 跨人流转的“上下文税”(Context Tax)

当智能体只能与单个员工绑定时,员工就不得不充当不同模型、不同同事之间的“人工中继器”。

以常见的产品定价调整为例:

  1. 市场运营人员在 AI 对话框中梳理出一套新版定价方案;

  2. 她将生成的结论复制到即时通讯工具,发送给研发负责人;

  3. 研发为了评估对结算代码的影响,把这段文字复制进自己的 AI 窗口,追问改动范围与依赖项;

  4. 研发确认后通过邮件回复说明;

  5. 测试人员收到邮件,再把内容复制进第三个 AI 窗口生成测试用例。

在这个链路中,团队付出了隐性的流转成本:

  • 前置约束损耗:第一位同事在多轮对话中确认的业务边界和推导逻辑,在复制出来的简略结论中被省略,后续同事只能看到断章取义的结果。

  • 重复解释背景:每个新介入的同事,都必须向自己的 AI 重新编写提示词,把前置背景重新描述一遍。

  • 工作节奏割裂:原本连贯的任务,在多次人工复制与等待回复之间被打散成了碎片。

2. 个人电脑宿主的局限

当 AI 具备了调用脚本和操作文件的能力时,如果依然沿用个人模式,有些技术人员会选择在自己的笔记本电脑上运行自动化智能体。这在团队协作中会带来两个实际问题:

  • 缺乏连续可用性与可接手性:个人电脑会面临休眠、断网或因系统配置而暂停进程等情况。一旦设备失联,运行中的任务可能中断,其他团队成员既无法随时查看最新执行状态,也无法在原上下文中直接接手继续推进。

  • 权限与审计边界模糊:个人电脑通常直接保存着员工本人的浏览器登录态、各类系统凭证与本地配置文件。若缺乏统一的访问控制与出站网络审计,一旦智能体在处理外部数据时出现误操作,容易在本地环境混淆使用权限,事后排查与追溯也更为困难。

将团队协同任务部署在独立的服务环境或受控沙箱中,主要是为了保障任务的连续可用与团队成员随时接手,并建立统一的权限边界与审计记录,而不是断言本地系统天然不安全或云端必然绝对安全。


二、现有方案做到了哪一步?

面对这种割裂,企业通常会采购企业版账号,或在内部工作群中接入对话机器人。这两种做法各有价值,但并未完全解决协同连续性的问题。

常见方案 当前支持的能力 仍存在的协作断层
企业版/团队版项目
(如 ChatGPT Projects 帮助文档 所支持的功能)
支持团队统一结算与权限管理;可在项目内共享自定义提示词、工作区参考文件与会话;成员可以查看已有对话并建立分支(Branching Chats)独立探索,分支与原聊天并列保留。 共享资料与分支历史,不等于具备跨入口接续同一任务的实时运行状态。
成员从历史会话开启分支后,各自分支是彼此独立的衍生对话,并不支持技术、运营等不同角色在各自的工作软件中共同驱动同一个正在执行的任务。
群聊接入机器人
(如 Slack 或飞书等群聊中的 @AI 助手)
入口公开、门槛低;在群聊成员已有访问权限的前提下,所有人都能看到提问与回答过程,有利于经验的公开流动。 交互通常脱离了实际业务系统。
核心业务数据分布在代码仓库、文档系统、工单平台和数据库中;若机器人无法直接联动这些系统执行操作,员工仍需手动在专业软件与群聊窗口之间复制粘贴数据。

因此,群聊机器人迈出了公开化的一步,但团队协同的核心不在于聊天窗口设在何处,而在于不同角色能否跨系统接入同一个具有工具执行能力的任务上下文中。


三、实证与案例:人际协作加 AI 带来了什么?

团队协作与 AI 的结合,究竟能产生怎样的实际改变?学术研究与企业实践给出了两组参考。

1. 宝洁实地对照实验:冲击顶尖成果

哈佛商学院等机构的研究人员在宝洁公司开展了一项实地对照实验,成果收录于 NBER 工作论文。这项研究涉及 776 名专业员工,他们在为期一天的产品开发工作坊中完成真实业务任务的设计。实验对比了四组条件:个人独立工作、个人使用 AI(GPT-4/4o)、商业与研发各一人的跨职能双人团队无 AI、以及跨职能双人团队使用 AI。

实验发现了两层重要结果:

  • 在方案平均质量上:AI 显著拉升了产出质量,使用 AI 的单人表现追平了无 AI 的双人团队;而团队使用 AI 后的平均质量与单人使用 AI 相比,在统计上并没有显著差异,表明在该任务中未检出团队相对单人加 AI 的平均质量优势。

  • 在冲击前 10% 的顶尖方案上:表现截然不同。以单人无 AI 组为基线,其产出顶尖方案的基准概率为 5.8%;而跨职能团队配合使用 AI 时,产出顶尖方案的概率相对该基线增加了 9.2 个百分点(达到 15% 左右),提升至基准的近三倍。相比之下,在该实验中,单人配合 AI 在冲击顶尖成果上的提升幅度并不显著。

该实验结果表明,在具体产品开发任务中,跨职能人际协作(商业洞察与技术研发的结合)与 AI 的结合更有利于冲击顶尖成果。需要指出的是,该研究说明仅针对该实验设置,且实验使用的是常规模型对话界面,而非专门的多人共享会话软件,它反映的是跨职能人际协作结合 AI 的放大效应,不能直接等同于某种特定软件架构的必然证明。

2. Shopify 的实践:公开交互的车间效应

在企业实践中,电商平台 Shopify 内部推行的 AI 助手“River”提供了一个观察窗口(相关情况由《多人协同 AI 宣言》转述自其创始人 Tobi Lütke 的公开说明)。

Shopify 将 River 限制在授权员工可见的内部公开 Slack 频道中,而非一对一私聊。推行一个月内,公司内部约有八分之一(1/8)的代码合并请求(PR,即向主代码库提交修改的审查申请)包含了 River 的协作参与。

这种在企业内部公开使用智能体的方式,被形容为“车间现场学习”:当员工与智能体的交互过程在授权组织范围内可见时,优秀的提问思路、业务约束定义以及排查问题的方法,能够自然地被其他同事观察并复用,展现了开放交互对经验传播的实际价值。


四、多人协同 AI 的五项目标与实现条件

以下五条原则是多人协同 AI 的核心设计目标,它们代表了团队人机协作的演进方向,而不能当成购买现有工具就能直接拥有的现成功能。理清这些目标,有助于团队看清人机协同的真实需求与落地条件:

原则 1:减少人工复制粘贴(Never copy-and-paste)

智能体不应孤立在单独的网页标签页中,而应接入工作发生的场所(代码库、项目文档、工单系统)。参与同一项目的成员,无论身处即时通讯、邮件还是文档工具,都应能够介入同一个处于运行状态的任务中。

跨系统接续任务的设计示意 图注:跨系统接续任务的设计示意。展示多角色从不同入口接入同一个运行中的任务,由智能体联动代码库与通信工具,减少人工搬运信息。

在上述示意中,市场人员在即时通讯中询问新版定价 PR #482 的修改详情;智能体自动读取代码并发现年付折扣被设为了 15%,与规划方案要求的 20% 不符;研发负责人在邮件端回复要求修正;智能体随即向代码仓库提交代码修改(Commit),并在公开频道中同步完成通知。整个过程不需要人工反复搬运中间状态。

同一任务的流转方式对比

以 PR #482 折扣修正(将年付折扣由 15% 调整为 20%)为例,对比各自聊天与共享任务的流转差异。本对比为概念演示,各自聊天路径为示意过程。

各自聊天
  1. 运营人员在个人聊天窗口中让 AI 读取 PR #482,发现年付折扣被设为 15%,与规格要求的 20% 不符。
  2. 运营人员将排查结论手动复制并发送给研发负责人,原本多轮对话沉淀的业务背景被留在个人窗口中。
  3. 研发负责人在自己的 AI 窗口中重新整理提示词交代背景,追问改动涉及的代码文件并确认方案。
  4. 研发确认后通过邮件回复并手动提交代码,支持人员随后再次复制邮件摘要到新窗口生成对客文案。
共享任务
  1. 运营人员在群聊中向任务提问,智能体调阅代码库比对 PR #482,指出年付折扣被设为 15% 而非 20%。
  2. 研发负责人在邮件中直接回复该任务,在已有上下文中补充指令,要求修正代码并通知市场。
  3. 智能体在已有工具权限与必要批准下向仓库提交修正代码,并在团队公开群同步完成状态说明。
  4. 支持人员在同一任务中直接查看最新处理进展并跟进排期,全流程无需团队跨窗口反复复制粘贴。

两者的根本差异不在于沟通工具,而在于任务上下文能否连续保持。在已有工具权限与必要批准的前提下,共享任务可以减少跨岗位反复解释背景与人工转述的摩擦,让团队围绕同一运行中的任务协同。

原则 2:在透明环境中工作(Work with the door open)

私密对话容易让使用经验局限在个人手中,而向组织内有权限的成员开放交互过程,有助于经验扩散。

计算机科学家理查德·汉明(Richard Hamming)曾提到:关起门来工作,短期内手头的事情可能推进得更快;但开着门工作的人,更容易看清哪些问题真正重要。在企业内部,允许有权限的成员查看同事与智能体的交互记录,能够加快优质提示词与排查方法的流动。

原则 3:纠错沉淀为可复用技能(Continuously improve)

人类对智能体输出的调试与纠偏,应当沉淀为可继承的知识,而不是随着对话窗口关闭而遗失。

  • 一次纠偏应该保存什么:系统需要沉淀的不是散落的文字记录,而是结构化的技能配方(Skill)——明确输入条件、业务规则与约束(例如“修改年付定价时必须对照最新的定价策略表”)、期望的输出格式,以及执行结果的检查步骤。

  • 一次纠错不能未经检验直接变成全局规则:在某个具体场景下的修正,往往依赖特定的上下文;如果未经检验就直接对全员生效,很可能干扰其他正常任务。因此需要配套基准评测集(Evals),用历史真实案例进行回归检验,确保新规则不会引起意外偏差。

  • 高频任务需要持续追踪评测:评测集不仅是在规则制定初期跑一次验收测试;随着业务环境与调用场景的演进,高频工作需要随时间持续追踪评测表现,及时发现准确率下降或逻辑漂移。

原则 4:人不充当消息路由(People are not routers)

在日常协作中,骨干员工经常花费大量时间回答各类事务性状态,例如“某客户的测试环境何时到期”、“某份合规报告是否有效”、“预算负责人是谁”。

凡是智能体通过连接内部系统能够准确回答的客观信息,应由智能体直接处理与同步,人类员工则集中精力于需要业务判断、权衡取舍与架构决策的核心事务。

原则 5:项目历史随时接续(Nothing starts from scratch)

当任务的执行过程持久保存在系统中时,设计文档、测算表或代码修改都会伴随一份活的操作上下文。

新成员接手一个已有项目时,可以通过关联的会话记录,了解该项目当时达成了哪些结论、排除了哪些备选方案、遗留了哪些待办风险。这无法替代必要的业务培训,但能有效降低从零还原历史背景所需的时间。


五、工程落地与安全防线

搭建一个支持多角色、多系统协同的人机环境,必须处理好底层的工程约束与安全规则:

1. 运行环境:连续可用与团队接管

将需要长期运行或跨角色协作的智能体部署在独立的服务环境或云端沙箱中,主要出于稳定运行与权限管理的考虑:

  • 保障服务连续:任务不会因员工个人电脑休眠、关机或网络断开而失去响应;

  • 支持随时接管:授权团队成员能够随时查看进度,并在原任务中继续操作;

  • 规范凭证范围:通过受控的服务凭证调用外部接口,避免直接使用员工个人工作站上的各类凭据。

2. 安全边界:防范外部诱导与出站校验

当智能体被授予跨系统操作权限,并需要读取外部邮件、第三方文档或网络页面时,必须防范数据被诱导外泄的风险(例如外部文本中隐藏诱导性指令,诱使智能体调取并转发内部未公开信息)。

针对这种风险,系统通常会配置网络出站白名单(Allowlist)限制外联域名,并对关键写操作设置人工审批。但这并不意味着配置了白名单就能高枕无忧:白名单只能限制数据不被发往未批准的外部服务器;如果目标服务本身属于合规的白名单服务(例如公司内部使用的协作软件或邮件系统),智能体依然可能在已获准的服务中把敏感数据发送到错误的公开频道或非授权人员。因此,获准接入的各个系统内部,依然必须具备严格的权限与对象校验。

3. 权限交集陷阱与历史信息隔离

这是多人共享会话中最容易出现疏漏的环节:当不同权限的员工进入同一个会话时,系统如何展示数据?

所谓“权限交集”,是一种可选的保守策略:共享任务只调阅所有参与者均有权访问的资料范围;系统也可以采用按人区分可见内容的策略。但无论采取哪种方案,都不是加入会话就自动授予全部资料或操作权限。

共享会话中权限隔离的设计示意 图注:共享会话中权限隔离的设计示意。展示成员介入会话时,智能体对未授权数据拒绝复述的交互逻辑。

在多人共享会话中,仅仅让智能体在生成新回复时“拒绝复述未授权内容”是不够的。如果一位成员此前在会话中查询了敏感数据(例如包含商业底牌的客户邮件或报价),随后另一位未获授权的同事加入同一个会话,若界面依然显示先前的完整历史记录、任务摘要或会话附件,敏感信息依然会暴露。

因此,协同环境中的权限控制必须覆盖整个会话生命周期:不仅在生成时判断当前提问者及所有能看到回复的接收者是否有权调阅数据,对中途加入的成员,还需要对历史消息卡片、中间推理摘要和附件文件进行动态脱敏或视窗隔离;调取受限数据时,应当由有权批准的数据负责人显式授权,而非由调用者单方决定。

共享任务中的权限控制(概念演示)

本示例为概念演示,用于说明共享任务不等于共享系统权限。网页视角切换仅为了帮助理解,实际的数据访问控制必须在服务端执行。当不同权限的成员介入同一任务时,系统需要对受限信息做差异化处理。

Marcus 未获得该邮箱的系统访问权限。共享任务遵循最小权限原则:新回复不复述未授权内容,历史记录、摘要及文件如包含受限信息同样予以遮蔽,防止通过共享产生越权访问。

可见内容
  • 本人提问记录:询问首席财务官关于价格的内容。
  • 智能体回复:提示该内容来自受限邮件,需经数据所有方或组织批准的权限策略授权后方可查看,当前无法复述。
  • 公共任务信息:任务标题、参与成员列表、更新时间及未涉密的公开讨论记录。
权限边界
  • 邮件敏感内容:报价和服务条款不显示。
  • 历史记录与摘要:如包含邮件中的受限信息,也应受同样权限约束,对未获授权的 Marcus 动态遮蔽。
  • 关联文件:如包含邮件中的受限信息,也应受同样权限约束,不向未获授权成员提供查看入口。

多人协同的安全基线必须覆盖整个任务过程。仅在生成新回复时拒绝回答并不够;历史记录、摘要与文件如包含邮件中的受限信息,也应受同样权限约束。按人区分可见内容是一种实现选择,统一任务也可按参与者权限交集限制输出。

4. 架构解耦与弹性

大语言模型更迭迅速,团队在架构上可以考虑将业务逻辑与具体模型适当解耦,根据任务难度按需匹配不同算力(例如常规信息检索使用轻量模型,复杂逻辑推导使用高阶模型),并在单个供应商出现故障或接口变动时保留切换的弹性。

5. 审计追溯与资产可控

在面对合规要求或业务排查时,团队必须能完整复盘任务执行的四项要素:调用的智能体版本、发起操作的人员、调阅的数据范围、对生产系统做出的实际写入改动。

在落地路径上,自研、采用开源方案或采购商业工具三条路线都可行。搭建一个基础版本往往能较快跑通,但要实现完整顺畅的协同体验需要大量工程投入,容易挤占主业精力。真正的难点在于长期维护跨工具的任务接续、权限隔离与审计追溯。

无论团队选择哪条路线,核心都在于确保关键数字资产具备明确的可掌控与可迁移性:在日常业务运转中沉淀的工作流经验、验证过的技能配方(Skills)以及针对自身业务建立的评测基准(Evals),应当属于团队自主可控的数据资产,能够以通用格式导出、迁移和备份,避免被绑定在任何单一厂商或封闭平台内。


团队 AI 协同能力自检清单

请选择一个具体的实际业务项目,逐项核对并勾选团队已验证的协同能力,在对应项后记录真实业务证据,并在文末梳理当前现状与下一步改进计划。

维度一:任务接续与跨端协作

核对重点:团队成员是在孤立窗口中重复沟通,还是能基于统一任务上下文接力推进?

维度二:纠错沉淀与持续评测

核对重点:对 AI 的纠偏是否能转化为团队可继承的资产,并随时间持续检验?

维度三:运行环境与连续可用

核对重点:自动化任务是否具备脱离个人设备的连续可用性,便于团队接管?

维度四:多人权限与历史隔离

核对重点:多名不同权限的成员介入同一任务时,敏感信息是否能有效防护?

维度五:资产掌控与可追溯性

核对重点:团队核心数据与技能是否自主可控,任务执行过程是否可审计查验?


团队实际项目协同复盘

已核对 0 / 15 项

来源

《多人协同 AI 宣言》(The Multiplayer AI Manifesto)Sergey Karayev 与 Superconductor 团队,系统讨论多人协同 AI 的核心目标与工程考量。

延伸

NBER 工作论文 w33641: The Cybernetic Teammate:Fabrizio Dell’Acqua、Ethan Mollick 等,关于宝洁 776 名员工跨职能团队与 AI 协同实验的研究论文。

Ethan Mollick 关于该研究的专栏说明:研究作者对实验设计与结果意义的详细解析。

OpenAI 官方文档:Using Projects in ChatGPT:关于 ChatGPT Projects 共享提示词、参考文件与会话分支功能的官方说明。

↑ 正文结束
✓ 本篇全文免费开放

会员可复制、下载全文 Markdown,还能让你的 AI 订阅和提问。

阅读原文 ↗
📮 新解读第一时间进邮箱

读完觉得有用?留个邮箱,每篇新解读发布就送达,随时退订。