从聊天到组织记忆：Slack 如何搭建真正的人类与Agent协作团队

一、Slack追了近十年的问题：对话为何没有自动变成知识？

Jaime 于 2017 年加入 Slack，最初负责搜索与机器学习。她当时承担的任务，是把日常工作中的对话转化为可沉淀、可调用的组织知识。

在近期 The Work is the Conversation 中，她把这一判断进一步延伸到 Agent：围绕工作形成的对话，正是 Agent 发挥作用所需的上下文，也是散落知识真正转化为生产力的基础。

这背后有一个长期存在的设想：团队成员每天在工作中产生大量讨论、决定、提问与解释。这些对话虽然看起来像协作留下的“尾气”，但只要能够被持续积累，理论上就会逐渐变成公司的集体记忆。

现实却并非如此。Jaime 回忆，Slack 早期的多项研究都指向同一结果：对话本身不会自动变成知识。大量内容只是停留在消息流中，人们依然需要不断重复已经说过的话、重新解释已经做过的决定。

问题不在于组织缺少信息，而在于人类很难从庞杂的对话中持续提炼出结构、因果与变化。保存消息相对容易，理解“为什么当时这样决定、后来哪些条件发生了变化”却需要巨大的认知成本。

Agent 改变的，正是这一环。它不只是帮助团队找到一条旧消息，还可以跨越讨论记录，重建决策产生时的理由，并判断当下语境与过去相比发生了什么变化。于是，过去只能沉在频道里的对话，才第一次有机会被重新组织为可复用的知识。

原文给出了三项具体做法：

• 频道默认公开。 Agent 只能学习它能够访问的内容。发生在私信或私密讨论中的决定，对 Agent 不可见，也更容易从组织记忆中消失。
• 追问理由，而不只是检索结论。 与其只问“最后决定了什么”，团队更应让 Agent 还原“为什么这样决定”，以及此后有哪些条件已经改变。
• 扩大上下文的覆盖面。 当会议、邮件、日历与文档库逐渐被连接起来，Agent 能看到的工作全貌更完整，团队也越不需要反复从头解释。

换言之，知识库不再只是一个专门维护的文档目录。只要工作过程足够开放、连续且可访问，对话历史本身就可以成为知识层。

二、人类—Agent 团队的核心，不是自动化，而是“交接”

在 Slack 描述的工作方式中，人类与 Agent 并不是各自完成一整块任务。两者之间更典型的节奏，是一轮又一轮的交接。

由 Claude 驱动的 Slack 内 Agent 先承担生产性工作，例如起草、总结、监控与会前准备；随后把结果交给人。人类负责审阅、判断和调整方向，再把明确后的下一步交回 Agent 执行。

Jaime 的周一早晨，是这种节奏的一个缩影。她开始工作时，Agent 已经生成了每日简报。等待她审阅的，还有上一周产品工作坊的回顾与升级事项、全网 AI 动态报告、当天会议的背景材料，以及一份由 Agent 重新改写的过时个人简介。

这些工作并没有因为交给 Agent 就脱离人的判断。每一轮结束时，仍由人类检查结果、确定优先级并作出决定。Agent 接过的，是下一段清晰的生产工作，而不是最终责任。

为了让这种交接自然发生，Slack 的实践包括：

• 让 Agent 生成晨间简报、会议准备、升级事项与行业动态，由人类统一审阅；
• 把相关工作放在共享频道中，让人和 Agent 面对同一组材料共同分流；
• 把轻量信号变成可执行入口，例如 Jaime 所在频道中的一个 emoji 反应，就可以把事项加入列表，再由 Agent 接手。

这里最重要的变化，是 Agent 不再只是等待单次提问的聊天窗口。它开始进入团队持续运转的工作流，在明确节点接活、交付，再等待下一轮判断。

三、Agent 也需要岗位说明，而不是越多越好

当一个团队开始同时使用多个专业 Agent 时，如果成员仍把它们理解为“一对一聊天机器人”，很容易迅速失去方向：每个 Agent 到底负责什么？什么时候应该找它？一个任务应该交给谁？

Jaime 给出的理解方式并不技术化。她更愿意把 Agent 看作同事。

就像人类同事需要明确的职责与目标，Agent 也应拥有清楚的关注范围。一个 Agent 的价值如果只能靠管理层强制推动，而一线使用者无法直接感受到、也说不清它解决了什么问题，那么团队很难长期记住它的用途。

因此，Slack 的建议不是不断增加专用 Agent，而是先把角色说清楚：

• 高频、重复、事务性的任务，可以交给通用 Agent，例如提交服务台工单，或把上一周的指标整理进状态更新；
• 如果团队成员无法准确说明某个 Agent 的用途，组织就应考虑调整甚至停用它。

这套逻辑与软件工具时代并不相同。过去，企业常常要求员工记住不同系统的入口；在人类—Agent 团队中，更理想的状态是让少数角色清晰的 Agent 代为处理分散工具背后的事务。

四、公开默认，私密有意：上下文与心理安全必须一起设计

Slack 从早期就主张共享频道默认公开。Jaime 认为，公开工作的意义，是为接下来发生的一切建立共同理解与共同语境。

AI 出现后，这一原则多了一层作用：Agent 也需要通过可访问的历史了解项目、组织与人的工作方式。上下文越连续，它给出的结果通常越贴近实际；相反，一个私密频道不仅对其他同事不可见，也会成为相关 Agent 的盲区。

开放上下文还会产生复利。新成员加入团队时，可以继承已有讨论，而不是面对一个空白收件箱重新问起；Agent 从历史中获得的工作记忆，又会通过摘要、准备材料与行动建议重新流回团队。

但“公开默认”并不意味着取消隐私边界。原文明确建议，真正敏感的材料仍应被隔离。关键在于，团队需要有意识地决定哪些内容必须受限，而不是让日常工作因为惯性全部退回私信。

Jaime 进一步把问题指向了心理安全。在敏感信息被合理隔离后，许多工作之所以仍躲进私信，并不是因为保密，而是因为人们不愿让同事看到尚未完成的过程。

如果公开协作只允许出现最终答案，团队就无法留下真正有价值的推理过程。成员需要相信，粗糙草稿、半成品与尚未成形的问题也可以被善意对待。只有这样，开放才不会变成表演，Agent 看到的也才是工作真实发生的过程。

信任会因为被率先给予而逐步积累。

五、推广新工作方式，最有效的不是培训，而是让同事看见实例

新的协作方式很难靠抽象规定推广。Jaime 在 Salesforce 观察到，更有效的方法是让员工直接看到别人如何使用。

Salesforce 内部有一个名为 How I Slackbot 的公司级频道。按照 Jaime 的说法，这个公开频道已有数千名成员，员工在其中分享技能、调试技巧与工作流窍门。一个来自销售流程的方法，可能因此被工程团队看见，随后改造另一个完全不同的流程。

Slack 内部推动产品经理使用 Claude 时，也出现了类似的自组织扩散。

最初，一名产品经理请开发者体验负责人帮助完成设置，随后用 Canvas 写下自己做了什么、具体如何操作。其他产品经理开始复制这种格式，各团队又自行组织工作坊，并建立各自的 Git 仓库。

在这一过程中，采用并不是由一套统一命令驱动的，而是通过可见、可复制的例子扩散。原文因此建议企业建立一个全公司可见的“展示与交流”频道，并鼓励员工留下简短的“做了什么、怎么做”说明。一次个人探索由此可以变成团队模板，进一步沉淀成可复用的技能。

六、真正需要衡量的是结果，而不是消息数和 Token 数

从加入 Slack 早期开始，Jaime 就一直面对一个难题：生产力应当如何衡量？

发送更多消息，并不必然意味着团队从 Slack 中获得了更多价值。消息变多，甚至可能说明人们找不到需要的信息，或第一次没有把问题说清楚。

同样的误区正在 AI 时代重现。

Token 用量可以说明系统正在被使用，却不能单独证明它创造了价值；它更像一项运行状态指标，而不是业务结果。使用次数、活跃人数和调用规模可以帮助组织判断采用是否发生，但无法回答工作是否真的变好。

目前没有一种干净的方法，能够直接证明某种 AI 使用方式一定带来更好的业务结果。把工具使用与最终绩效连接起来，仍然需要大量判断，任何单一仪表盘都无法替代这种判断。

因此，组织至少需要区分两类问题：

• 活动指标： 有多少人在用、调用了多少次、消耗了多少 Token；
• 结果判断： 重复劳动是否减少、决策准备是否更充分、交接是否更顺畅、关键问题是否更快得到解决。

前者能够显示采用，后者才接近价值。

七、Slack 给出的起点：尽早开始，但从一个小团队开始

Jaime 对准备搭建人类—Agent 团队的组织提出了两层建议。

第一层，是重新想象每一条工作流。企业需要改变工作的组织方式，而不只是用 AI 把原来的动作加速一遍；这项改变也不会由某个个人或单一技术团队独立完成，它本质上是一项团队运动。

第二层，则非常具体：尽早开始，但从小处开始。

一个可行的起点，是让一小组成员与 Claude 进入同一个共享频道，为人和 Agent 提供同一组资源，并让真实工作在其中发生。团队随后观察哪些交接有效、哪些角色清晰、哪些上下文仍然缺失，再逐步调整。

如果 Slack 的经验具有参考意义，这种可见、可复制的实践会比自上而下的全面推广更容易扩散。