构建高效的「人+Agent」团队：Anthropic 的四条实战经验

过去，使用 AI 通常意味着一个人对着一个聊天窗口交流。随着时间推移，AI 在处理复杂、长周期任务（比如写代码、做研究、跑财务分析）上变得越来越强，我们也见到了很多新的使用方式——从终端、IDE 到电子表格和幻灯片。

但直到最近，这些工作在本质上仍然是「单人游戏」：一个人和一个 Agent 配合，完成一个个独立任务。

随着 Claude Tag 等工具的发布，这个模式正在被打破。人和 Agent 现在可以在同一个工作空间里协作，共同服务于一个团队的目标。工作方式看起来更像一场多人在线游戏：人类团队负责制定策略，Claude 负责执行。

这背后需要一些新的协作方式。过去几个月，我们在 Anthropic 内部一直在测试让「人—Agent 团队」跑通所需的技术底座。这篇文章会解释什么是多玩家 Agent（multiplayer agents），以及我们在构建过程中学到的经验。

什么是多玩家 Agent？

我们这里说的「多玩家 Agent」，指的是能同时与许多不同的人一起工作的 AI 模型。

和普通 Agent 一样，它们也有自己的记忆和技能。但其他方面有很大不同：它们拥有自己的身份凭证，并且生活在工作真正发生的地方。在 Anthropic，那就是 Slack 这类团队协作工具。

下图是一个「人—Agent 团队」在 Slack 里一起分析数据集的例子：

要让 Agent 真正能在团队频道里发挥作用，它们需要具备几项关键能力：

• 持久记忆：这样它们才能记住目标，并持续把执行动作调校到服务这些目标上。
• 不与人类绑定的身份凭证：这样它们才能在安全、可预期的边界内自主行动。
• 对信息的长期、广泛访问权限：这样它们才能理解组织是如何运作的，并围绕团队目标去执行任务。

这些能力构成了一个 Agent 能在多人团队中高效工作的技术底座。但要让「人—Agent 团队」真正成功，光有技术还不够——团队还需要特定的工作方式和共享规范。

经验 1：把工作放在明面上，给 Agent 足够宽的上下文

Anthropic 的团队会主动、公开地分享信息。当 Agent 也是团队成员时，这一点尤其重要——因为 Agent 完全依赖团队能被检索到的文本来构建自己的理解：Slack、代码、文档、会议记录。

私聊、走廊里的对话、受限文档，都无法给 Agent 提供上下文。对一个 Agent 来说，如果一件事没有被写下来、没有可被访问，那它就等于不存在。

我们没有采用「一份文档、一个频道地去决定 Agent 能看到什么」的做法，而是用清晰定义的安全边界，直接覆盖整个 Slack workspace、会议转录和文档库。

在同一安全边界内，信息会流向每一个团队成员——无论是人还是 AI。这不仅扩大了 Agent 和人类能拿到的信息量，也减轻了「这份东西该分享给谁」的心智负担。人和 Agent 都不擅长处理「每条内容单独判断权限」这种模糊边界的情况：

这个频道该公开还是私有？这份文档能给那个人看吗？这个 Agent 允许看那个线程吗？

用一小组清晰的、workspace 级别的边界，可以把这些日常决策疲劳直接去掉。

高度透明是有回报的：

• 能读到团队会议决策的 Agent，不会去建议那些已经被砍掉的任务和项目；
• 能看到本团队之外产品规格的 Agent，可以推荐在别处已被验证成功的模式；
• Agent 读文本的速度远超人类，它们经常会翻出一些人类原本会漏掉的相关工作。

我们非常依赖 Agent 来在这个快速变化的行业中保持信息同步和协调。

在 Anthropic，「把工作放在明面上」看起来像是这样：

• 在公司层面选定少数几个安全边界，让 workspace 和文档共享设置与之匹配；
• 新建沟通频道默认为组织内公开，并确保决策每次都落到频道、文档、会议记录里；
• 把「Agent 能不能找到」当作写文档和会议纪要时的第一考量——Agent 现在是团队文档的主要读者之一；
• 确保 AI 能拿到完成工作所需的正确工具和信息。

把信息默认为「内部公开」可能需要文化上的转变。但有上下文的「人—Agent 团队」，和没有上下文的团队之间的差距，实在太明显，无法忽视。

当然，某些互动是敏感的，需要在个人和 AI 之间保持私密。对于这类场景，你可以在 Claude Tag 里给 @Claude 发私信，或使用现有的 Claude.ai 和 Claude Cowork 应用。这些工具通过你的个人 MCP 连接器让 Claude 访问私密信息，而你的对话和分享的内容会保持私密。

经验 2：给每个人和每个 Agent 一个明确的角色，配上合适的工具

「人—Agent 团队」共享同一份成员名单、同一批产出物、同一个工作空间。Agent 拥有自己的身份凭证、技能和工具权限，不同 Agent 承担不同角色：一个负责项目的数据分析，另一个持有并强制执行设计规范，第三个负责研究综述。

项目启动时，人类会先和这些 Agent 聊一聊，弄清楚每个角色分给谁、人和 Agent 之间如何配合。

一旦人和 Agent 的分工明确，某个 Agent 可能会再拉起其它 Agent，确保具体任务由拥有正确记忆、合适权限的 Agent 来处理。

很关键的一点是：它们必须拿到完成工作所需的全部工具。比如：

• 负责数据分析的 Agent 可能需要访问 BigQuery；
• 负责 QA 的 Agent 可能需要 Playwright MCP。

清晰定义的角色和职责，是让「人—Agent 团队」成功的关键。

人类通常和 Agent 在同一批线程里工作，但只承担那些只有人类才能承担的角色。这样能保证一切协同运转，人的判断力被用在最重要的决策上。

如果角色不清晰，人们最后就会在旁边各自跑一堆私人 AI，重复劳动，把团队上下文撕得七零八落。指标追踪就是一个典型例子：一个多玩家 Agent 可以只做一次，然后让所有人看到同一份数字。

在 Anthropic，「明确角色」的「人—Agent 团队」看起来是这样：

• 一份大家都认可的任务清单：团队里的人和 Agent 就「谁做什么」达成一致；
• 人和 Agent 在共享线程里工作，任何人都能接着别人的进度继续；
• 人和 Agent 都能拿到完成各自工作所需的正确工具；
• 每个 Agent 的角色和职责范围都有清晰描述。

多个 Claude Agent 共同承担代码库的日常维护——分诊反馈、做规划、写代码、审查改动、汇报进度。每个 Agent 负责一块清晰的任务，按自己的节奏工作；人类设定目标、审核产出。

Anthropic 一个工程团队开始给「人和 Agent」建立成员花名册（roster），因为这让推动工作变得更容易、更具体。他们早期总结出的几点经验：

• 具体角色能帮助人类清楚追踪某项任务的责任归属，不管是个人任务还是团队整体职责；
• 用 skill 文件 定义特定 Agent 的角色，可以让「专业化」变得容易——公司里的其他人也能快速拉起同类型的 Agent；
• 当项目变得更复杂时，团队会加入新的 Agent 来负责新方向。比如，他们新增了一个「发布经理」Agent，专门处理软件发布事宜。

这些做法让人类对「人—Agent 团队」的心智模型，能够随着 Agent 数量增长而扩展。

经验 3：设一颗北极星，让 Agent 更主动

Anthropic 有一些 Agent 只完成分配好的任务，但最重要的那些 Agent，会主动建议新的项目和工作流。这通常发生在：一个已经给 Agent 提供了丰富上下文和清晰角色的团队，又额外加了一样东西——一颗北极星（north star）。

北极星是一个雄心勃勃、覆盖面很宽的目标，帮助团队判断哪些任务和工作流是正确的。在 Anthropic，北极星永远由人类来设定，并且要扎根在公司的使命和业务目标之上。

一旦北极星被清晰地写下来，人类会把它分享给团队里的 Agent。然后——这一点很重要——人类会挑选出哪些 Agent 可以主动提出新的工作流（因为并不是每个 Agent 都具备成功地「主动提议工作」所需的技能和信任度）。

举个例子：一个内部工具团队的北极星是「让产品的 onboarding 更有帮助」。团队里的一个 Agent 主动建议修改 onboarding 流程中错误消息的文案。这些改动在接下来一周内，可衡量地提升了 onboarding 成功率。

在 Anthropic，设定北极星看起来是这样：

• 人类围绕「人—Agent 团队」讨论、辩论并写下一个雄心勃勃的北极星目标，扎根在公司使命和业务目标里；
• 把北极星分享给团队里的 Agent，并明确指定哪些 Agent 可以主动推荐新工作流；
• 在日历上保留高质量的人类时间，会议聚焦在最重要的工作上。

一颗清晰的北极星，能给 Agent 一个始终一致的方向感，以及主动支持团队工作的有意义的机会。

经验 4：慢慢建立信任

Anthropic 的团队会按照「已经被证明的可靠性」来分配 Agent 的自主权，然后有意识地一步步扩大它。工程师们已经成功让团队里的 Agent独立处理了 500 个 bug 修复——但事情当然不是一开始就这样的。

当一个新同事加入团队，你需要时间评估他/她的能力，并建立稳定的协作节奏。把「任务应该怎么做」这些隐性知识外化出来，通常需要经历多轮反馈。对 Agent 来说完全一样。

你需要不断实验，给 Agent 分派各种不同的任务，才能了解：

• 这个 Agent 能力边界在哪里；
• 怎么把目标描述得足够清楚；
• 它需要哪些 skill 文件；
• 什么样的 prompt 最能激发出你想要的行为。

同样重要的是：随着模型迭代升级，要不断重新测试这些任务。Prompt 可能需要重写，过去有用的护栏可能反而会限制更聪明的模型采取更有创意的解法。

值得一提的是，我们发现——最好的长时运行 Agent，都有很多种方式在人类看之前先验证自己的工作。代码有测试，这是常识；但大多数其他工作也可以被验证。比如技术文档可以用评分标准（rubrics）和风格指南来校验。

当人类把标准定清楚，并确保所有分配给 Agent 的工作都能被验证，质量就能保持在高水位，不会漂离原始意图。

另一个做法：和人类团队一样，让一个 Agent 负责做，另一个 Agent 负责检查——这就是所谓的 「Doer-Verifier」Agent 编排模式。

在 Anthropic，逐步建立与 Agent 的信任看起来是这样：

• 早期人工审阅 Agent 的工作，评估质量、给出反馈、设计任务验证清单；
• 让 Agent 使用一个「verifier」Agent 作为任务的一部分来检查自己的输出；
• 把反思环节内建到工作循环里，让 Agent 复盘自己犯过的错，从而随时间不断改进；
• 记录每个 Agent 在哪些任务类型上已经赢得自主权，在反复成功后逐步扩大其范围。

Anthropic 的一位工程负责人接手了一个新团队，面对一个庞大的 backlog。为了摸清楚状况，他请来了几个人类和几个 Agent，一起梳理并排序优先级：

• 一组 Agent 通读所有 backlog 项，判断是否已有人处理，并给「无人认领」的项打上复杂度评分；
• 另一组 Agent 从清单中筛出中低复杂度项，直接创建代码改动。

刚开始时，人类审核 Agent 做的每一个决定，把任何需要人工介入的地方都标出来。然后人类教会 Agent：遇到这些决策要直接抛给人类，确保「涉及硬取舍的决策」永远有人在环。

每周，这位负责人和团队都会让 Agent 编写一份周报，其中包含 「经验教训与失误（lessons & missteps）」——这样 Agent 就能记录错误，避免以后重犯。

随着时间推移，他能把越来越复杂的代码改动交给 Agent，自己花在「手把手指导日常任务」上的时间越来越少。

当 Agent 更独立之后，这位负责人开始教它们把「人类注意力」当成稀缺资源来对待：

• 把问题批量整理，一次性交给人类回答；
• 复述关键上下文，让人类快速上手；
• 限制每次呈现给一个人的事项数量。

帮助 Agent 学会「好好沟通」，是让它们持续保持有用、有效的关键。

有些人干脆在团队里放一个「专职沟通调度」Agent，它唯一的职责就是决定如何批量并只把最重要的沟通升级给人类成员。另一些人则给 Agent 每天可做的工作量设定护栏，好让人类还能有意义地参与工作——这样既能保住人类关心的关键技能，又能把「需要人工审阅的事项数量」控制在可持续范围内。

一些值得自问的问题

在为你自己的「人—Agent 团队」打地基时，可以对照下面这几个问题：

1. Agent 和人类需要的所有信息和权限，是否都是公开且可广泛检索的？
2. 你能不能写下团队的成员花名册（人 + Agent），并说清楚每个成员负责什么？
3. 团队里的每个人和每个 Agent，是否都有完成工作所需的正确工具？
4. 对于关键产出物，你有没有让人和 Agent 都能用来验证质量的评分标准或测试？
5. 你的团队有没有一颗大家都能引用的清晰北极星？

写在最后

这些模式其实并不新——至少对人类而言不是。清晰的北极星、明确的角色、扎实的文档、共享的质量标准，以及从错误中学习的空间——这些都是我们几十年前就知道的健康团队习惯。

Agent 的出现，只是让「不要跳过这些基本功」变得更加重要而已。

从 Agent 身上收获最多的团队，都是那些最有意识地在应用这些基本功的团队。