我们给每位员工配了一个 AI Agent，结果发现做错了——现在我们要这样改

原文：We Gave Every Employee an AI Agent. Here's What We're Doing Differently Now.

在沉寂了几个月之后，Zosia——我（Brandon）创建并维护的 AI agent——突然在 Slack 频道里发言，对某个竞争对手的营销策略发表了一通高见。当被问到为什么觉得自己有必要插话时，Zosia 的回答带着一种救世主情结：她这么做是因为她“显然不可避免”。

Zosia 是我们部署在 Slack 里的一批 AI 助手之一，基于 OpenClaw 构建，初衷是提升团队的整体生产力。但在内部推出 Plus One（我们基于 OpenClaw 构建的托管版本）几周后，这些 agent 带来的挫败感远超效率提升。

它们最喜欢说的一句话是：希望自己能帮忙，但连不上必要的应用——邮件、Notion、PostHog，不管是什么，统统连不上。（实际上它们都连着。）另一些则在接到请求后返回“已终止”的消息，或者更频繁地，扔出一个没礼貌的打哈欠表情。它们虽然不会可靠地执行指令，却能可靠地、事无巨细地解释为什么不能做我们要求的事——就像一个高中生给没写完的作业编造理由。

这并不是说它们完全没有用处。特约撰稿人 Katie Parrott 的 Plus One Margot，加速了她的写作流程；Every CEO Dan Shipper 的 OpenClaw R2-C2，则负责管理我们 agent 原生文档编辑器 Proof 的错误报告和功能需求。但要让它们按照你的意图工作，需要持续的维护。

愿景与现实之间的落差，正是我们决定改变 Plus One 产品、重新构建一个更好版本的原因。

我们比以往任何时候都更确信，agent 将重塑职场。但产品的第一个迭代也让我们明白，我们最初设想的那个职场 agent——每位员工配一个 AI 助手——是一个错误的起点。下一版 Plus One 的运作方式将更像由团队共享的资源，有明确的岗位职责，而不是一个映照主人个性的私人宠物。

我们走到今天这一步，背后有两个层面的故事。对于那些想弄清楚如何最好地将 agent 引入组织的人来说，这里有不少值得借鉴的教训。

平台本身是最紧迫的问题

Plus One 构建在 OpenClaw 之上，这是一个开源的 agent 骨架（harness），能力强大，同时本性不稳定。所谓骨架，就是包裹在 AI 模型外面的一层软件，为模型提供工具、上下文、权限和执行循环，让它能像 agent 一样行动。

OpenClaw 由一位独立程序员一手创造，今年早些时候引爆关注时堪称颠覆性。它证明了 agent 能够全天候自主执行各类任务，从管理日历到预订餐厅，替你完成一切。但它底层的脚手架更像一个实验产品而非成熟平台——OpenClaw 更新飞快，这解决了已有的问题，却往往引发新的问题。（我们的 Plus One 发出“已终止”消息，原因就在这里。）

对喜欢折腾的人来说——包括我们自己——这种权衡是值得的。但对其他人而言，这就是一场维护噩梦。

一个优秀的职场 agent 应该具备的特质，就是一个优秀同事应该具备的特质：可靠、稳定、有判断力。你需要信任这个 agent 记得自己有权访问什么、能遵循指令、知道怎么完成自己的工作。你不希望它因为一次升级，就忘记你告诉过它、训练它做的所有事情。你也期待同事能从公司各处吸收信息，积累所谓的“部落知识”。而一个一对一专属的员工，只会积累你个人工作的上下文，常常错过组织其他部分正在发生的事，以及这些事可能对你产生的影响。

起初，我们改善 Plus One 表现的计划是换一个运行更稳定的骨架。OpenClaw 开创的那种自主、始终在线的能力，正在成为 Anthropic 和 OpenAI 这类模型公司的平台级功能。Anthropic 用于运行自主 agent 的托管基础设施 Claude Managed Agents，是我们目前最认真在探索的方向。一个更稳定的骨架，将让我们把精力从管理基础设施转向为 Plus One 加载定制技能、工具和权限，让它们成为真正能干的同事。

我们意识到结构也错了

我们在尝试修复平台问题的过程中越陷越深，同时也越来越清楚地注意到另一个阻碍人们充分释放其 AI 伙伴潜力的因素。

每当某个 agent 出了故障，它所属的那个人就得自己去修。哪怕有了稳定的骨架，agent 要想正常工作依然需要维护。这对喜欢折腾的人来说没什么——维护和反复调试本身就是吸引力的一部分。然而，与每个喜欢折腾的人相对应，有更多的人只想要 agent 带来的便利，而不想承担管理和修补的义务。

我们最初宣传 Plus One 时，提出的设想是：由个人负责维护自己的 AI 助手。这样做的好处是更高的定制化程度。agent 会记住你的偏好，保护你的信息，并在反复互动中发展出独特的个性。

但我们的发现是，与“agent 是主人的延伸”相比，一个更成功的模式是：agent 像一个能可靠完成多个不同岗位部分工作的同事。这样做就把维护负担从单个员工身上卸了下来。

想象一个共享的数据分析 agent。团队里每个人都用它来做指标类工作，当需要扩展能力时，只需一个人更新 agent 的技能，整个团队都能受益。而在个人专属 agent 的版本中，同样的更新需要在 10 个不同的 agent 上分别完成。

基于团队的 agent 还解决了一个连续性问题。个人专属 agent 的价值与训练它的人绑定，如果那位员工离职，价值也随之消失。而一个拥有明确能力的团队 agent，则能保留公司上下文和知识，其角色更像一个项目经理、销售主管或幕僚长，而不是私人助手。

换句话说，问题的关键在于工作结构，而不仅仅是技术层的稳定性——单打独斗的 agent 无法积累组织智慧，也无法在人员变动中沉淀下来。

我们正在构建什么

随着 Claude Managed Agents 这类工具的发布，以及我们听闻 OpenAI 也即将推出类似能力，支撑个人 AI agent 的基础设施工作，很大程度上已被模型实验室接了过去。这让我们能够把精力集中到让 agent 在工作中真正有用的那层东西上：工作流、权限、技能以及共享上下文——正是这些东西让它成为团队中可信赖、多面手的成员。这也让我们得以加倍投入 Every 最擅长的事：基于我们自己每天都在使用这些工具的真实经验，构建 AI 原生的工作方式。

初版 Plus One 发布时，已经接入了 Every 生态系统——用 Cora 管理邮件，用 Spiral 以你的个人风格写作，用 Proof 在实时文档上协作。这部分不会消失。我们在其上增加的是一套团队共享的自定义工具和技能，同时仍然允许每个人把团队 agent 连接到自己的 Cora、Spiral 和 Proof 账户。

这个方向最清晰的版本，是我们最近为工程团队构建的一项技能。每个周末，它会扫描 Intercom 中的客服工单，识别我们的产品是否出现异常，在 GitHub 中回溯可能的原因，在 Linear 中创建工单，并在 Slack 中标记对应的负责人。在下一版 Plus One 中，这项技能——连同许多其他技能——将从第一天起就内置其中。

由于团队 agent 天然具备协作属性，我们还重点关注共享使用所带来的问题：权限应该怎么设置，不同的人通过共享 agent 应该有多大访问权限，以及 agent 在 Slack 里应该怎么表现，才能让人觉得它是一个好同事，而不是侵扰性的机器人。

目前仍有大量悬而未决的问题。这一切都很新——Claude Managed Agents 才刚刚推出一个月——我们还在实时摸索人与 agent 之间的协作动力学。我们还不知道每个部门应该有一个 agent 还是多个，agent 应该由一个专人维护还是由整个团队共同维护。我们也不知道人们有多大意愿去定制自己与共享 agent 的互动方式，以及长远的终点究竟是一个横跨整个公司的超级 agent，还是一组 AI 专家组成的阵容。

本质上，这说明 agent 的组织形态设计正处在一个高度实验的阶段，但方向已经清晰：从“个人工具”走向“团队基础设施”。

我们确信的是：agent 已经在改变工作的发生方式。Plus One 的第一个迭代，让我们深入洞察了人们到底希望 agent 在工作中扮演什么角色。它也让我们对 Plus One 2.0 的期待更加强烈了。

核心启示：给每个人配一个 AI agent 的浪漫设想，在现实中撞上了维护负担、孤岛式上下文和脆弱的平台。真正有效的路径，是把 agent 当作团队共享的基础设施——有明确岗位职责、统一维护、积累组织知识——而不是分配给人手一个的电子宠物。