当 AI 从个人助手晋升为整个团队的同事,会有什么不一样?

凌晨两点多，张予收到了一条工作消息。按平时的习惯，他未必愿意起身打开电脑，配置并提交一个训练任务。但这一次，他把消息原封不动地转发给了工作群里的 Agent，让它继续处理。这个动作省下了一晚训练和评测的等待。

把 AI 与 IM 工具更紧密结合，让交代任务、补充要求和查看结果，都能在这里完成。更关键的是，Agent 能拿到企业 IM 和项目中的上下文，理解一条原封不动转发的消息，让人不必先把背景、目标和操作步骤重新整理成完整指令。这让人可以把更多真实工作直接交给它。

这场讨论背后的设想，酒嘉年用一句话概括为：一个近乎全知全能、永远在身边的 AI 同事。

“一个”，指组织中的人只需面对同一个 AI 同事，不必管理一支 Agent team；不同项目和任务，都由这个共同对象承接。“近乎全知全能”，指希望它能贯通公司的整体上下文，并调用完成工作所需的工具。“永远在身边”，则指它持续在场，人可以随时在熟悉的工作环境里与它协作。

“同事”意味着一种平等的协作关系：它能参与讨论、提出判断，也能在需要时主动推进任务。团队与它一起把事情做成。以这个隐喻为起点，任务交代、过程沟通、结果反馈和主动参与，才有了同一条设计主线。

张予和酒嘉年分享了在 RemoteLab 上接通飞书协作的一些实践，代睿则从共享 Agent、办公工具和组织环境的角度提出疑问。这里的 RemoteLab 是他们用来承接远程 Agent 任务的系统；他们希望把 Agent 的执行与飞书里的任务交代、过程沟通和结果反馈衔接起来。讨论中的许多设计仍在小范围使用和调整。

本文以 Claude Tag 这类企业主动 Agent 为参照，讨论这个设想怎样落到真实工作中：共享同一个 AI，与不同的人和项目协作，需要什么上下文；它怎样通过消息和文档沟通，怎样吸收人的反馈，又怎样把握主动介入的时机？后面的具体交互，都围绕这种协作关系展开。

一、从远程发指令，到让 AI 理解团队的工作

远程发指令改变了任务的入口；共享上下文则扩展了 AI 能承担的工作。它知道团队正在讨论什么、项目推进到了哪里，就能理解一句消息背后的目标，参与判断并主动推进，而不必每次都从头等人交代背景。从这个目标出发，后面的设计有了共同依据：消息和话题让任务能持续沟通，文档批注让反馈直接落在成果上，按人和项目管理上下文让它知道此刻在和谁、围绕什么事协作，长期运行和事件触发让它能主动关注需要跟进的变化。每一项最终都要落到同一个问题：这个 AI 员工能否把事做成，并让团队看得懂、改得动、放心继续交给它？

图1｜围绕同一个 AI 员工的协作关系

张予： 最早用 RemoteLab，比较直接的两个好处是即时通讯驱动和云端运行。它可以一直在，不会因为我的本地电脑关掉就停下来。后来我们又做了两类升级：一类是打通飞书的原生能力，另一类是让交互更接近真正的协作。

原来它主要是在飞书里提供一个对话入口。后来文档、表格、多维表、话题等逐渐接通。我们可以按项目和事项分群：一些群主要给人讨论，另一些群主要让 Agent 干活。一个话题承接一件事，就像给一个实习生安排任务。

酒嘉年： 开发环境也在往云端收。可以简单理解为，大家工作在远程开发机上，本地 Mac 更像前端界面。这样，工作记录和上下文就更容易集中起来。

张予： 接通这些入口之后，一件事才能走得比较完整。比如发现外部开源数据，我们希望把信息写进数据管理表，经过人的审核，再进入后面的处理流程。如果它只能把发现发到聊天里，人还得手动贴进表格，中间就断了一步。

交互上，初版是发一条需求，然后等它给最终结论。任务正在执行时，如果我想到补充信息，也没有很自然的方式加进去。

现在我想到什么就可以继续补充。它也可以在做事过程中，发现有重要信息就先告诉我。这样，我们不必等整件事结束，才发现它理解错了，或者才开始讨论一个关键选择。

代睿： 这个能力是靠 Skill，还是某个专门的工具实现的？

张予： 主要是把执行过程中接收补充指令的能力支持到飞书里。我们目前做的，是在工具执行结束这样的节点插入新消息，还在追踪更细的异步支持。但现在这个版本已经能改善使用体验。

飞书作为工作台有一个好处：人和人怎样沟通、任务怎样流转，这套交互已经打磨过了。如果你把 Agent 当成一个可以协作的人，很多交互自然就会回到即时通讯里。

它给我的进展也不需要展示所有执行细节。我更想知道值得关注的发现、结果，以及现在需要我判断的部分。我们还用了任务卡片，把几个重要的阶段展示出来，方便我检查中间成果。

这个变化在一次深夜任务里体现得很具体。

张予： 那次别人晚上两点多跟我说了一件事，我直接转发给它干。正常情况下，我肯定懒得爬起来到电脑上发任务；但在飞书上转发一下，我还是能做到的。这样，可能就省了一晚训练加评测的时间。

中间我看了些代码改动，但看完之后发现，在这个具体任务里，也许不需要我看得那么细。

飞书入口也不需要包办所有交互。如果任务是从聊天里发起的，后来我想更精细地控制它，就希望能移交回熟悉的开发工具。入口足够轻，深入操作仍然有地方可去，这两件事可以同时成立。

二、在结果上批注，比重新解释一遍更自然

能在聊天里交代任务，解决了开始工作的成本。接下来的问题是：结果出来之后，人怎样告诉 Agent 哪里不对？文档成为了这场讨论中的另一个重要入口。

代睿： 我还有一个比较头痛的问题。文档给 Agent 操作时，好像不如原生的 HTML 或 Markdown 顺，尤其内容长了之后，读写都有点笨。

张予： 我用飞书文档时，倒没有明显感受到这个问题。

酒嘉年： 我觉得要看工具和接口开放得怎样。我们最近用得比较自然的是评论：你可以精确地指到某个位置，一边往下读，一边看到哪里就评论哪里，它再异步回复。这和同事一起评需求很接近。

你评论之后，它可以在评论里回答，也可以同步修改文档正文。

图二｜基于文档的人与 AI 协同案例

张予： 日报就是一个例子。我们每个项目有相对集中的群聊，可以整理项目的进展，再汇总成一份日报：现在到了什么阶段，接下来做什么，每个人需要关心什么。

这种东西 Agent 很容易写出来，但最开始写得并不好，主要是它关注的东西不对。嘉年调了一段时间。我自己也会对其中一些部分评论，让它按反馈更新。

这里比较自然的地方是，我直接在那个计划或认识上和它交互，而不必离开文档，再到对话框里把问题重新描述一遍。

“把问题重新描述一遍”包含了一笔很容易被忽略的成本：人既要指出问题，还要把原文位置、前后关系和修改意图重新打包。评论把这些信息放在了一起，也使后续修改更容易核对。对张予来说，这种反馈还关系到记忆系统应该怎样进步。

张予： 我会把记忆分成存储、检索和反馈几个部分。把原始记录存下来，再做索引，让 Agent 能回头找到它们，这些已经有不少办法。

但在一个你很熟悉的领域，它对重点的把握还是可能让你不满意。同样留下一万 token 的信息，人会留下更值得记住的部分。人做实验、和同行交流之后，会逐渐知道哪些判断不成立，哪些信息不值得继续关注。

所以我关心的是：交互本身产生的反馈，能不能帮助它调整这些记忆和认识？

比如让它同时持有这份文档和相关任务的上下文，再通过评论、更正来更新。日报、项目认识、前沿追踪，背后都有类似的问题：怎样把对这些事情的判断维护起来。

这些反馈让人的判断留在文档和上下文中，成为之后工作的参考。

三、大家共用一个 Agent，会不会互相“调坏”？

交互顺畅之后，Agent 会接触更多人和项目。代睿提出的疑问是：一个共享入口，怎样保留不同人的工作习惯？

代睿： 这个机器人是你个人粒度的，还是组织粒度的？

张予： 我们希望它成为组织粒度的东西，现在也在三四个人的范围里这样用。

代睿： 我觉得这是这类产品的一个痛点。研发和算法的关注点可能不一样，未必能用同一套记忆。有人会希望有自己的小助手，可以很自由地调整它，不用担心为了满足自己的工作习惯，影响别人的体验。

如果大家共用一个机器人，虽然名义上属于组织，会不会实际上还是更适合最早调它的那几个人？

张予： 我并不认为所有人应该拿到同一套上下文。虽然它都叫同一个名字，但在不同的群里，可以理解成不同的 Agent。

我们的管理方式是：不同群里开启的任务，根据那个群的情况加载不同记忆。做同一个项目的人，需要的上下文比较接近；如果还要细分，也可以按具体事项或团队拆开。

酒嘉年： 也可以先把它想象成一个独立的人。一个人进不同群，本来就会想到不同的背景。

而且还要考虑具体的人。我和不同同事合作，模式就不一样。大家能感知对方习惯怎样协作，Agent 也应该能理解这种差别。

有人喜欢讨论比较上层、模糊的想法，有人更愿意钻具体细节。面对不同的人，它可以有不同的响应方式。我们现在还在调试，不能说已经做得特别好，但长期想做到这个状态。

张予： 我明白你的意思。人和项目是需要分别加载的两个维度。我把它理解成一组分层注入的上下文。

哪些信息经常需要，哪些只在某种任务里需要，加载的频率和长度应该不同。没有必要把组织里所有人的所有 Skill 和记忆，一次性都放进去。

代睿： 那我大概理解了。群和记忆的划分合适，它就能拿到这个领域需要的上下文；工具和 Skill 再按需要加载。

一次个人反馈，到底应该改个人习惯、项目做法，还是组织共同规则？分层的意义，要通过这些具体修改是否影响到了合适的人来验证。谈到多个 Agent 如何分工时，大家更关心的是人要面对多少个协作入口，以及错误会不会在多个 Agent 之间传播。

酒嘉年： 有些产品会鼓励把 AI 分成多个职能，让几个 Agent 相互讨论。我们这套和它们的视角不太一样。

张予： 我会更倾向于一个中控 Agent 管其他 Agent。你可以通过文档等方式，先和这个主要入口对齐认识。它负责把工作收回来，也更容易纠正其他地方的问题。

从上下文的角度看，整个组织有一部分经常需要的信息，具体群和项目再有自己的信息，也是类似的逻辑。

人的协作关系由此保持连续：交代任务、补充信息、追问结果，都面对同一个 AI 同事。

四、主动参与的前提，是它在这件事上帮得上忙

共享上下文让 Agent 有可能参与群里的工作，但也产生了另一个问题：它是否应该对每条消息都作出回应？

张予： 最近有两个让我觉得比较好的例子。一个是我本来在群里找同事改一个 Bug，它看到自己也能处理，就把这件事接过去做了。

另一个是大家在讨论训练进展，本来打算找人回答。它知道我们最近提交了哪些训练任务，也能回答这个问题。在成功率比较高的事情上，这种异步协作体验很好。

代睿： 但每条消息都有机会触发它的话，群里人数和消息密度上来，触发就会很频繁。是不是最后还是得回到艾特它才触发？

张予： 现在确实触发得有点频繁。我们给不同群设了不同模式：主动参与、旁听，或者暂停接收。

我更想逐渐把指标补全。组织里有不同领域，比如预训练、后训练、数据；任务也不同，有的是希望得到一个可靠的回答，有的是希望它直接做一个实验。这些组合起来，每类任务都可以看端到端的成功率。

在它比较熟悉、上下文比较齐全的方向，我的体感是有些事情可以直接交给它。但换到它没怎么做过、上下文也缺的方向，判断就明显不准。

如果它能可靠地帮忙，回复也不啰嗦，主动参与就容易被接受。还没有做到时，就得考虑大家能不能接受它参与，或者先让它旁听。

接下来要分清：哪些任务可以更多交给它，哪些还需要补上下文、限制介入或增加检查。主动做事也没有消除人的审阅。张予和酒嘉年随后谈到了他们各自怎样看代码和训练配置。

张予： 代码可以让它写，但我还是会审阅。我特别在意接口设计，比如函数或服务之间怎样交互；还有模型训练的细节，不同版本的代码和配置到底改了什么。

酒嘉年： 这也取决于任务的复杂程度和重要程度。训练模型的成本太高，所以我们希望在发起之前好好看一下。

同样是交给 Agent，一个容易验证和修改的产品功能，与一次昂贵的训练任务，需要人投入的注意力就可能不同。这里对“像同事一样协作”的期待，是让检查集中到真正影响结果的地方。

五、工具接通以后，协作还可能卡在哪里？

前面的使用体验并没有在所有环境里同样出现。讨论重新回到代睿最初对文档操作的疑问：差别究竟来自模型，还是来自它能调用的工具？

代睿： 我接触的一些办公系统比较碎片化：同事用不同的文档工具，待办、日历、知识库也不统一，上下文就容易隔开。

还有一些接口，读文档时只能拿到一整篇很大的内容，更新时也得把整篇重新写一遍。它不能很细地改某一部分，输出一长就容易出问题。真实使用时，会遇到很多这样的卡点。

张予： 也就是工具没有提供足够细的操作能力。

酒嘉年： 权限和接口会很明显地影响它的表现。好的 API 调起来更顺，效率也高。

代睿： 接口的名字和参数也很重要。如果和传统软件的常见设计接近，Agent 比较容易一次用对；设计得很奇怪，就容易写错。

这里的 API，可以理解为软件给 Agent 提供的操作接口。人只是在某一段上写一句评论，背后却需要定位原文、读取相关内容、修改相应位置，再保留后续讨论。只有“读整篇”和“重写整篇”，不一定足以支持这种细致的协作。

张予： 这些上下文其实很难绕过去。组织里的文档如果不能读，会很麻烦；我们现在这些能收集反馈的协作方式，也依赖原有的办公套件。没有它们，就得自己做一套，人也不习惯。

如果前面的基础设施已经把事情卡住了，就还没有走到下一步：记忆能不能结构化更新，反馈能不能继续改进它的判断。

酒嘉年： 验证就会很慢。为了验证一个想法，你得先做很多准备，每个想法的验证成本都会很高。

我们最近比较顺的一点是，想支持一个交互，通常能找到飞书已有的小能力，再把它接进来。它没有明显成为我们继续验证的瓶颈。

这也解释了为什么大家使用同一种“Agent 产品”，感受可能差很多：模型之外，相关信息是否在它能访问的地方，工具能否支持局部操作，人能否顺手反馈，都参与决定了体验。

六、真实工作，才能告诉它什么值得关注

当基础设施暂时难以接通时，能不能先搭一个理想环境，验证这些机制？这是讨论里一个值得保留的分歧。

代睿： 我还是想先做点东西。比如在很小的范围里搭一个模拟环境：先不考虑现实环境的各种问题，有一个模拟的聊天入口，文档操作也很舒服，把上下文接进去，再找一些任务放进去试，看能调出什么。

张予： 我会担心模拟环境验证不到最重要的部分。我做这件事，很看重这家公司的真实案例怎样积累下来。

通用功能是一部分，但组织自己怎样做事、遇到问题怎么判断，这部分经验依赖真实工作和反馈。如果只是让它打招呼，肯定体验不到完整能力。

我们曾经为了体验这类产品，把一个项目放到另一套协作工具里，但过程中还是要回飞书拿一些东西。对正常使用的人来说，这个来回已经让事情很难继续了。

我想优化的是不同领域真实任务的成功率。如果测的是另外一批任务，可能和最终要做的事情差得很远。

酒嘉年： 需要有一件真实的事，才能用好、看清这个体验。

这两种思路各自想回答的问题有所不同。模拟环境能帮助人检查一个交互或机制能否运转；真实工作则会暴露信息缺口、人的习惯，以及最终什么才算做成。对“组织里的 Agent 能否越来越会做事”这个问题，后者尤其重要。讨论随后又向前走了一步：把更多工作信息接进来，是否就能自然产生更好的判断？

代睿： 信息接得更深，会出现一些相互印证的机会。比如机器出现告警，同时用户行为的某个环节出现异常，就可以把两边联系起来。

这里大家举出的信息源也随工作而变：做产品可能需要用户反馈、错误日志、增长信号，做模型训练则更关注机器日志和训练任务的信息。

张予： 这里我还有一个疑问。如果人先注入一点判断经验，告诉它该关注什么，我觉得目前不难。但如果完全不告诉它重点，让它自己从大量信息里捞，我的体感还没有那么好。

可能得安排一些主动任务，比如每天做一次某个方向的分析，再看那些特定的信息源。

代睿： 对，还是会通过这样的任务，强调哪几个信息源适合关注，让它一起看、做关联。

张予： 那还是需要人把案例和判断放进去。这个过程合理，一个新来的实习生也得适应一段时间。

我想再往前做的是，让这个注入判断经验的过程本身能够更自动化。这是上面这些事情做完之后，下一步想推进的。目前还没有做到。

代睿： 是，仍然靠人从每天的工作里寻找这些东西，再放进去。

张予： 那就先从日常工作里积累。这个收益比较稳定，做完之后，再谈它能不能自己在更高一层发现新的东西。

这场讨论最后停在了一个具体的边界上：日常协作已经能提供案例、结果和人的反馈，但哪些经验值得留下、应该怎样改变下一次的判断，仍需要人的参与。从一句消息开始执行，到在文档上纠正认识，再到按人和项目加载上下文、选择介入时机，这些交互共同决定了 Agent 能进入多少真实工作。进入工作之后，才有机会继续检验：留下来的反馈，是否让下一次协作变得更好。