How to Build Team Agents

2026年可以说是智能体的一年。

从年初的OpenCLAW，到现在的Muse、GrokBot和Instinct等平台，这些平台让人们真正开始利用这些极其强大的自主工具，帮他们完成越来越多的工作。我们确实已经从智能体是下一件大事，走到了它们就在眼前的阶段。

问题在于，我们的工作并非只是独立完成的。

我们通常会和别人一起团队合作。

然而到目前为止，大多数智能体都是单打独斗的，只覆盖我们独立完成的那部分工作。

我认为现在这种情况正在转变，我把这种趋势称为多人AI，或者共享智能体、团队智能体。

但到底什么是构建团队智能体呢？

需要考虑哪些因素？

它与仅仅为自己构建一个智能体到底有多大不同？

这些问题正是我在AI Daily Brief的Operator's Cut版中与Noufar Gaspar探讨的内容。

《AI每日简报》是一个每日更新的播客和视频节目，关注AI领域最重要的新闻和讨论。

好了朋友们，在正式开始之前，先快速宣布几件事。

进入正题前还有几点要提一下。

显然，这是一期预先录制的节目。

今天有不少事情正在酝酿。

我们会有很多要聊的，所以明天我们会恢复常规形式回来。

我还想分享一些即将到来的机会。

好了，闲话少说，让我们来谈谈如何构建团队智能体。

好的，Nufar，欢迎回到节目。

我今天准备了一期Operator's Cut。

是的。

很高兴再次来到这里。

这期的起源是我们在入秋前的一些对话，关于我们想在这个秋季的免费自主学习训练项目中做些什么。

我们当时聊了很多关于多人AI的概念，以及一种正在转变的模式：从人们只为自己构建单独使用的智能体，转向我们预测将要开始看到——我想我们已经开始看到早期迹象了——更多存在于共享工作空间中的智能体。

这其实只是遵循了人们自然的工作方式。

你的很多工作是独立完成的，但也有大量的工作是在与其他人交汇的地方完成的，而团队智能体就可以存在于这些地方。

当我们正在构建那门课程（目前可以在Multiplayer AI上获取）并更广泛地思考这个概念时，我们反复提到的一个点是，这个领域还太新了，以至于实际构建一个团队智能体意味着什么并不一定非常明显。

所以今天这期Operator's Cut的目标是帮助大家真正思考如何构建团队智能体，理解团队智能体是什么样子的，了解它们与人们可能已经构建的智能体类型有何不同——或者我认为我们在这里会论证的是它们其实很相似——以及人们接下来可以往哪个方向发展。

所以非常高兴你能回来，也很兴奋能深入探讨这个问题。

太棒了。

所以我要拓宽你的定义，把它叫做团队智能体。

这个概念就是，你的整个团队都能用的智能体，要么是因为它们之间协作完成工作，要么就是它们可以在团队成员之间共享。

简单来说，有些智能体应该保持个人私用，而另一些应该变成团队级别的智能体。

那些成为团队智能体的，需要有意做出几个决策。其中一些决策，就像你说的，跟任何好的智能体配置都一样，另外一些则更独特，或者至少需要更刻意地考虑。

这就是我们要讨论的内容。

我想先通过两个故事来激励你们，这两个故事你们在自己的公司或生态里很可能也见过。

第一个故事说的是一个人——跟我合作过的每家公司、每个人身边至少都有这么一号人。

这个人非常清楚定价例外是怎么运作的，数据是怎么回事，或者我们最大的客户三年前是怎么配置的。

当ta忙得不可开交时，工作就得等着ta，因为只有ta知道。

ta休假的时候，还是会有人给ta打电话。

ta一旦离职，公司的一部分也跟着走了。

在我合作过的一家公司里，每个领域都有这么一个角色。

所以没人能休假而不被同事打电话打扰。

显然，这不是理想的状态。

第二个场景是没人完全负责的工作。

比如一个客户从销售转到市场再转到客户成功，销售在谈交易时做了承诺，市场又在用稍微不同的信息做活动，然后客户成功在续约前几周才发现这些承诺，每个团队都有自己那一块，但没有一个人掌握全局，因为工作分散在各个团队之间。

就像你说的那样。

就算每个环节都用了AI，这些智能体之间也不沟通，很多时候反而让问题更严重。

所以一个为整个团队打造的智能体可以帮我们解决这两个问题——当然，这两个问题性质很不一样。

还有一个原因我觉得现在这件事很重要，你应该关注起来，哪怕你觉得这有点超出你的理解范围——那就是我们在最前沿的AI公司中开始看到的模式。

这个模式大致分三步。

第一步，每个人都建自己的智能体，生产力提高了，大家都很开心。

但如果跑着太多这样的智能体，就会出现智能体泛滥的情况。

很多智能体在做重复的工作，每个都由一个人维护，每个对公司情况的了解都略有不同，而且一旦维护者失去兴趣或离职，这个智能体就报废了。

然后，在最前沿的AI公司里，你会看到他们开始把一些智能体合并成团队级别的智能体。

这些智能体通常数量少得多，范围广得多，每个都有明确的负责人，被很多人使用，并且随着团队不断了解它们该做什么不该做什么，会逐步优化。

这种事情正在非常公开地发生。

已经有很多公司在讨论了。

我记得你提到过Everys的经验。

他们年初的时候给每个员工都配了一个智能体，然后到了五月份，已经转向了共享的团队智能体。

Sierra 把他们很多专门化的 agent 合并成了一个。

Shopify 的内部 agent。

所以我们看到很多这样的例子，出现在各地非常公开的、面向公众的公司里。

而我看到的大多数团队可能都还处在第一步或第二步，但我认为我们所有人都很重要的一点是去看这些 AI 领先的公司，理解怎么到达第三步，以及怎么正确地做。

这就是今天整期的目的。

为了确保我们说的是同一件事，因为基本上同一个东西有好多不同的名字。

有些人，包括你自己，叫它 multiplayer AI。

你可能也听过 shared agents。

有些人称它们为 AI teammates，甚至有时候还会把 company brain 也混进来，或者说跟它混用，都是指在公司范围内使用共享知识的 agent。

在这个节目里，我会一直称它们为 team agents。

我的意思是，我们有一个 agent，很多人跟它对话。

共享的知识、共享的记忆，还有一个单独的配置。

指令、技能、访问权限，还有所有者，全都是共享的。

你可能在听到我这么说的时候想，我们不是已经共享 skills 了吗，对吧？

大多数公司都有一个很棒的 skill library，或者正在搭建 skill library，这很棒。

这是你们在公司里做工作的一种很好的标准化。

但一个 skill 是针对特定任务的 playbook，而 team agent 是你的整个团队用来处理各种不同任务的。

既有临时性的，也有重复性的工作。

它确实携带团队知识，记住学到的东西，并且使用团队级别的 skills，如果你们有的话。

当然，那些也可以接入 skills 市场等等。

所以 skill library 也许是其中的一个要素，但它们是两码事。

而我希望你今天思考的是，如何以及何时开始构建你的下一个 team agent。

关于范围再补充一点，因为现在大家对各种 personal agents 非常兴奋。

我说的是 Muse、Instinct，还有其他一些这个类别里的东西。

那些是用在家里或者私人生活中的。

今天我们的重点是工作。

所以这是第一件事，确保范围清楚。

我们说的是你为工作构建的 agents。

好的。

我想确保大家明白这期节目是给谁做的。我觉得它是为所有人做的，不只是那些在搞最尖端东西的前沿专业人士。

如果你正要构建一个，当然要留意，因为它会为你提供或验证完整的操作手册。

它也是针对那些尚未完全掌握的人，因为正如你所说，这些决策确实适用于你构建或使用的任何智能体，而团队智能体只是让其中一些决策变得更加关键。

而且即使你是独自工作，并且你有一组智能体或者正在考虑构建一组智能体，你也会面临同样的决策。

你生态系统中的其他参与者可能不是你的同行，因为你独自工作，但也许你是在为你的客户构建它，或者为未来的自己构建，以确保它足够稳健，并且能充分代表多样化的工作任务。

所以这就是哪些人需要关注的原因。

我想确保一点非常清楚，那就是并非每个智能体都应该被共享。

这里有一个拨盘或者说一个频谱，有三个档位。

我们有一个私有智能体，它属于你，用于你的工作，体现你的品味和你的权限。

例如，我自己的社交媒体智能体就是私有的。

我可能无法与任何人分享它，因为我是唯一一个想以特定方式在社交媒体上分享或发帖的人。

所以没有人应该像我一样说话。

然后我们有共享知识。

这些可以是共享的知识和技能，但仍然是私有智能体，意味着团队维护一个知识体系。

例如，我们销售什么，我们如何工作，我们的用语是什么意思，通常还有一个共享技能库，然后每个人将自己的智能体指向那个库。

但顺便说一句，这就是技能库所在的地方。

而且这通常是正确的答案，也是最容易的起点。

另一个具体例子，比如每个销售员都有一个根据自己风格和偏好调整的寻找客户智能体。

保持这些智能体的原样，因为每位销售员都想拥有自己的声音，但给他们所有人都提供相同的维护良好的理想客户画像和公司传达的信息。

所以这是一种混合模式，某些公司或某些用例应该保持这种模式。

最后，我们确实有团队智能体。

在这种情况下，我们有一个智能体，多个人与之协作，它有自己的工作和自己的所有者。

并且智能体可以在这些档位之间移动。

如果你遇到这样的情况，同事不断要求借用你的私有智能体，那很可能表明你需要把它变成团队智能体，或者考虑与他人共享它。

所以我想回答的下一个问题是，所有团队智能体都来自同一个原型吗？还是它们都遵循相同类型的用例？

答案是否定的。

比如，在我合作的团队中，我大致可以将现有或未来构建的团队智能体分为四种。

了解你的类型，不仅有助于你识别用例，还能帮你优化用例。

它还能告诉你需要注意什么才能做对。

所以第一种团队智能体，我称之为专家智能体。

它是一个人或者一个小团队的专有知识。

它对所有依赖它的人来说都是可用的。

你可以通过那个能休假的人认出它来，还记得开头说的吗？

如果你想再举个例子，可以是那个能回答公司里多个部门任何数据问题的数据助手，或者是一个服务于很多市场团队的定价和交易台助手，还有合规助手，等等。

要想把它做对，知识必须来自公司里掌握这些知识的专家。

他们需要被访谈。

他们需要——你需要收集他们在多个场合已经给出的答案，比如即时消息、邮件和其他地方，而且这些专家必须从一开始就参与进来，因为对他们来说，这最终让休假成为可能，但也带来很多工作不安全感，所以在处理这个领域时要小心。

第二种类型我称之为通用工作助手。

这种情况是很多人都在做类似的重复性工作，并且只有一种共同的方法来做。

识别这种用例的方法是，当三个人各自建了自己的同一个助手时。

你可以想一个团队研究和会议准备助手。

这是很经典的一个，或者市场团队的内容助手。

我相信你还能想到其他的。

要想把这个类型做对，你得就工作方式达成一致，这说起来容易，做起来难，因为你是在合并三个版本的最佳部分，这实际上是一场关于你在公司标准上达成什么共识的对话。

所以，一旦你开始考虑统一这样一个助手，这至少会是一场有趣的对话。

然后我们有桥梁助手。

这是那种在角色之间流动的工作，没人能独自完成。

当交接出问题时你就能认出来。

每个阶段都必须解释上下文，或者这些助手必须在不同部门之间协同工作。

例子可以是一个跨越销售方案、客户成功和交付的客户助手。

这是非常经典的一个。

要想把它做对，每个功能都必须有自己的知识片段输入到这个助手里。

拥有不同权限的人最终都会用到它。

所以我们必须非常非常注意权限问题，并且需要在这方面下大功夫。

最后，我们有参谋长助手。

团队运营都由这个助手掌管，比如日常工作的运作执行。

它可以处理决策、承诺、状态、入职培训，当团队不断重复自己，新成员需要几周才能站稳脚跟时，你就能认出这个助手。

要想把它做对，你需要明确界定它允许学习什么，如何学习流程和正在进行的部分，以及如何自动做到这一点，这可不是件简单的事。

当然，还有很多关于权限之类的问题。

所以，当你在思考这些类型，以及它们中哪一个可能适合你正在考虑或应该考虑的一些用例时，在我给你构建团队助手的实操指南之前，先快速绕个弯，因为我想做个简单的现实检查。

有些迹象表明，团队助手是个错误的选择，或者至少现在对你不合适。

所以一个你不应该构建团队智能体的迹象，至少是现在还不行，就是当个人品味胜过统一标准的时候。

如果不同的人真的需要不同的答案，或者不愿意同意一个标准，并且他们自己的判断或他们自己的声音才是重点，那么这些就应该保持为私人智能体，这样人们才能保持真实，不必为基本事实而争论。

第二个不应构建的迹象是，没有人能拥有这些知识。

如果团队不能就工作如何完成达成一致，或者没有人愿意长期拥有和维护共享知识，智能体将在几周内，有时甚至是几天内偏离轨道。

所以在你去构建团队智能体之前，先理清所有权问题，因为那会是一个不可行的情况。

最后，每当你意识到尝试构建一个共享智能体，一个团队智能体，只是让事情变得更复杂而不是更简单，因为你有相互冲突的需求或纠缠不清的权限，无休止的协调。

如果你意识到结果比智能体能为你提供的价值还要多的工作量，那就是答案。

不要构建它，至少在你能够理清一些复杂性之前不要。

当然，注意列表里缺少了什么：敏感数据和高风险。

那些是设计问题，它们会塑造你如何构建它，这也是我们接下来要讨论的。

所以我不认为数据过于敏感是反对的理由，它只是需要额外小心的关注。

为了构建候选用例，希望你已通过了之前分享的决策检查清单，这归结为你的智能体的5个核心设计决策。

它们包括它做什么，它在哪里，它知道什么，它能接触什么，以及你如何运行它。

这些是核心问题。

为了让它更具体，我将从头到尾使用一个例子。

它将是一个客户智能体，是那种桥梁型的，意味着它持有公司对每个客户所知道的一切。

以及我们承诺给他们的一切，它可能会被销售、解决方案工程、客户成功交付等使用。

他们将使用那个示例智能体来进行各种与客户相关的活动。

那么让我们分解其中一些决策，让它变得可操作。

首先，你必须做出的决策是它做什么。

这里有一个快速的提醒，对于任何认真的工作智能体来说，有很多范围界定是非常相似的。

它需要有一个清晰的工作描述，一个完成的定义，以及一个它不做什么的列表。

我在这里将坚持讲，当它是为团队构建时，与为你自己构建的智能体相比，有什么变化。

所以第一个决策是按角色划分，它为谁服务。

例如，销售问它的东西和交付团队不同。

所以要写下每个角色以及他们会来找智能体做什么，以确保你覆盖了所有的范围。

当然，你可以瞄准一个广泛的工作领域。

因为我认为团队智能体应该是相当有能力的智能体，否则很难证明它们存在的合理性。

在我们的例子中，我预期客户智能体能够准备会议答复，我们与这个客户的关系进展如何，能够标记涉及其他团队的承诺，并且草拟每一次交接。

例如，我有一个相当广泛的范围，让它保持专注的是工作领域。

在我们的情况下，这主要指的是客户。

我还想让你注意一下团队禁止清单。

这部分人们经常容易跳过。

比如，它绝不代表别人做承诺，也绝不解决人与人之间的分歧。

这些事都交给它的主人。

你可以想想你们那边还有没有类似的例子。

还要确保禁止清单里包含权限和数据处理的条目。

举个例子，它绝不会把某个私人空间的信息带到共享空间里。

所以它不会在另一位客户的空间里讨论某位客户，也不会代替某个人对另一个人发言。

当然，跟任何 agent 一样，最好从较窄的范围开始，比如读取和起草。

只有当它获得了足够的信任并且经过充分验证之后，你才能随着信心的增长逐步扩大范围。

那么这就是第一个决策，接下来我们可以进入下一个。

第二个问题是 agent 存放在哪里，这个问题也是问得最多的。

所以我们具体一点来说。

基本上，如果我尽量简化的话，大概有三种分享 agent 的方式，从最简单的到最复杂的。

最简单的方法就是用一个共享文件夹，搭配你们公司已有的工具。

然后每个人把自己的工具指向这个共享的 agent，文件夹里会包含指令以及如何存储新信息的方式，作为 agent 整体行为的一部分。

这是一种非常初级和基础的方式，但作为构建共享 agent 和团队级 agent 的垫脚石，它是一个很好的起点，特别是如果你的团队成员已经在使用类似的 agent 工具，或者可以指向文件夹作为信息来源的 agent 工具。

这就是第一种也是最简单的方法。

第二种方式是使用供应商预制的 agent，我们看到越来越多这样的产品，并且相信在未来几周和几个月里我们会持续看到更多。

我们后面会详细讲，但它的工作方式是供应商托管它，然后你来配置。

这类工具中有很多最近很火的，比如 Claude Tag。

OpenAI 有自己的 ChatGPT Workspace agent。

Copilot 也有自己的类似产品可以用来做这件事。

Notion 和其他很多工具都已经提供了共享空间。

你可以跟别人一起在 agent 上协作，只需要配置好它们的细节就行。

最后，当然也是最复杂的，就是自己托管的 agent，也就是你自己运行的。

比如，它可以是一个开源 agent，像 OpenCLaw 或 Hermes，放在你自己的服务器上或者租用的云上，有些公司甚至会根据这些需求自己定制 harness。

这是最复杂的方式，显然技术上的要求也最高，但同时自由度也最大，可以围绕它进行构建。

这就是团队 agent 可以存放的三个大方向。

除了怎么构建工具这些决策之外，还有两个随之而来的问题。

第一个问题是，谁能看到每个人和智能体之间的对话？

也许只有正在和智能体对话的人才能看到。

也许是整个频道，或者是会话里的所有人。

在这方面，不同工具之间差别很大。

在某些工具里，每个人都能读到所有聊天记录。

比如在 Slack 里的 Claude，频道里每个人都能看到智能体在做什么、它跟别人聊了什么，而且还能引导它。

而很多其他智能体，你的聊天是私密的。

所以这有时是厂商的设计决策。

有时是你可以配置的。

第二个问题是它存储在哪里。

以及谁能读到？

所以理想的智能体不是那种明显固定死的，而是拥有大量记忆、能随时学习的。

然后问题是，这些学习内容存储在哪里？又是怎么发生的？

它是按人来发生的，智能体只从和你的互动中进化；还是按频道或团队来？又或者整个工作区有共享的学习和记忆，智能体在公开场合和所有人一起进化？

当然，有一件事，绝不要跨越客户之间的界限。

所以在第一个真实任务之前，一定要检查、选择，并告诉你构建的团队智能体处于什么状态，因为信任的建立或丧失就在于此。

我的原则是选择最简单的方案，只要这周真的有两个人会用就行。

对我们的客户智能体来说，那可能是频道智能体，或者一个简单的，比如工具智能体。

因为完整的功能需要它。

如果我把它搞得太复杂，人们就得先弄懂怎么去连接那个东西，而不是直接进入 Slack 或 Teams 频道，那肯定行不通。

所以以我们的情况，那可能就是正确的解决方案。

这个决策，我可以说，大概是最重要的决策，那就是它知道什么。

我觉得如果你构建过任何智能体，这个方法听起来会很熟悉。

对团队来说，不同的是，这正是团队对‘基本事实’达成一致的时刻。

工作到底是怎么完成的，我们用哪些定义，哪个版本的价格政策才是真的，而且我觉得这些对话很值得进行，哪怕你永远不发布这个智能体。因为在大多数团队里，哪怕只是就知识达成一致都是一件大事，而且也是团队智能体变难的地方。因为知识一旦共享，就会有更多的贡献者、更多的矛盾，也就会有更多地方可能让重要的事情被遗漏。

所以围绕知识的管理过程，比在你的个人智能体里任何时候都重要得多。

所以你需要非常注意这一点，理想情况下你应该经历这四个阶段。

我想让你从收集智能体开始，方法是采访掌握知识的人，并去收集那些已经写在各个频道和所有信息所在地的内容，而且我希望 AI 在汇总和收集数据方面多做一些重活。

所以对我们的客户智能体来说，我会确保销售、解决方案、客户成功和交付这些团队都贡献自己的一份力量。

然后我希望你进行优化。

我希望你整合来自不同来源的信息，把矛盾的地方摆出来。

我敢肯定你会发现真相有五个版本，然后给所有信息标上日期，把那些绝对不该分享的内容剔除出去。

当然，这包括密码、关于他人的备注、一个客户的信息出现在另一个客户的空间里等等。

然后我们需要审批它。

每一条信息都应该由它所属的人签字确认，然后 agent 的管理者把它们整合在一起。

最后，这些信息很容易过期，所以你必须持续维护。

你需要决定 agent 可以根据自己的工作经验向记忆中添加哪些内容，以及哪些信息在进入知识和记忆之前必须先由人审核。

我们希望确保，不会出现某个人对最新信息的定义悄无声息地变成所有人的标准，而大家并没有达成一致。

当然，还要把维护工作排入计划，因为你希望 agent 定期提出更新建议，并且需要有人来审核和批准这些更新。

这一点真的需要非常细心和自律，因为如果你在 agent 所依赖的知识的获取、维护和验证上没有一个足够好且能自我维持的流程，那它可能直接决定你的团队 agent 的成败，因为一旦出了问题，你没法快速修复。

如果你的团队 agent 对关键事项没有足够好的理解，它可能会给公司造成很大的混乱。

第四个决定是 agent 能接触到什么，这是团队 agent 和个人 agent 的不同之处，因为个人 agent 代表你个人，而团队 agent 为很多人服务。

所以当然有大量的安全基础原则需要在这里应用。

那些适用于所有 agent 的原则肯定要遵守，我重点说说针对团队 agent 的四条特定规则。

首先要决定的是它使用谁的权限，你有三种选择。

你可以让它使用提问者的权限来操作。

这样它就只能看到提问者能看到的内容。

这可能是最安全的选择，但执行起来有时也是最复杂的，除非供应商已经帮你做好了。

当团队成员的访问权限不同时，这可能是正确的方式。

另一个选择是为它设置一个独立的账号，只赋予工作所需的权限。

当整个团队都使用同样的共享资料时，这个方式就很合适。

最后，它也可以使用某个人的登录权限。

但只建议在只读和非敏感材料上这么做，因为所有与 agent 对话的人实际上都获得了那个人的权限。

所以我不建议走那条路。

对于我们的客户 agent，我可能会让它以提问者的身份操作，因为销售、客户成功和交付团队在 CRM 和其他系统中看到的内容各不相同。

所以我不希望 agent 向他们回复他们不应该看到的信息。

这是关于 agent 能看到什么的第一条规则。

第二条规则是决定谁能向它提问。

当 agent 有自己的账号时，所有能与它对话的人都可以使用这个账号。

如果你把一个有权访问定价表的 agent 放在一个40人的频道里，其中还有几个承包商，那么突然之间，这40个人都可以通过询问来获取价格了。

这个 agent 知道的比一些能接触到它的人还多。

所以，决定谁能和它对话时，要像你决定它能看什么一样谨慎。

好吗？

所以这是人们不注意时经常发生的事情。

我还想让你决定答案落在哪里。

这个正好相反。

agent 使用提问者自己的权限，而提问者完全有权利问这个问题。

问题是答案会出现在共享空间里，而那些没有权限的人也会看到。

所以这是现在正在发生的事情。

如果你看 Claude 在 Slack 里的文档，它可以使用提问者在团队频道内的连接。

在用户批准后，Anthropic 的文档目前指出，它不会考虑频道里还有谁。

所以如果我批准使用我的连接器，获取所有我允许查看的信息，然后这些信息被扔进频道，其他人也能看到，这就是目前现有 Claude 实现的现实。

所以如果信息敏感，答案必须私下发给提问者，而不是放在共享频道里。

最后，记录谁问了什么，这很重要，是日志记录。

因为当 agent 用自己的账户工作时，日志显示是 agent 做的，对吧？

而你想知道是哪个人问的，这样你就能回溯，确保没有意外行为。

其他一切，比如从最小权限开始，以及让人批准任何不可撤销的操作，对所有 agent 都是一样的。

所以我不是在给你做一对一的安全培训。

好的。

最后，最后一个决定，也是让你的团队 agent 活过第一周或第一个月的决定。

这就是完整的操作手册了，基本上。

当然，多人冲刺计划有更全面的思考方式，但这四点在实际中决定了 agent 的成败。

第一件事是只有一个负责人。

团队中的任何人都能处理工作，但我希望有一个人或一个很小的团队来负责优先级、维护 agent，并在两个人提出相反要求时决定如何改进 agent 的知识或功能。

他们还决定常设指令等等。

这是第一点。

我想提的第二点是明确的互动规则。

我希望你告诉人们如何使用它，它能做什么、不能做什么，它能看什么，谁能看到他们与它的对话，以及我们目前讨论的所有内容。

我们还需要明确指示如何纠正 agent 的错误。

而且我觉得，人们对他们正在使用的 Agent 和团队 Agent 的信任程度，会随着他们越了解 Agent 在学习什么以及学习过程而增加。

接下来我想让你做的事情是，把决策放在它能看见的地方。

所以，一个团队 Agent 只能知道那些写在它能够访问的位置上的东西。

如果你的团队在私聊或者走廊里聊天中决定事情，Agent 永远不会知道这些。

要让 Agent 平稳运行，一部分工作就是让它能够实时了解团队中正在发生的事情，并确保团队决策和日常工作的进展能被 Agent 自己学到。

最后，我希望你持续观察，因为你可能一开始会从很小的规模开始——理想情况下，你应该从一个小型试点小组开始，并准备几个测试问题，这样每当有变化时都可以重新跑一遍。

但我也希望你持续监控，因为我们知道事情变化得非常频繁。

所以，不仅仅是当你想引入新模型、新工具、新知识或者指令上的新变化时要有合适的流程，还要监控一切是否正常运行。

当然，在某些情况下，如果团队 Agent 的行为不符合我们的预期，我们可能就需要把它淘汰掉。

我们讨论了很多内容，如果要在结束前做个总结的话，首先我希望我已经让你相信团队 Agent 对每个人都重要，即使你——可能需要一段时间才能真正构建一个，而且正确构建它们才是关键所在。

当然，并不是每个 Agent 都需要共享。

私人 Agent，或者共享知识和技能但配以私人 Agent，又或者是团队 Agent，这些都是可行的选择。

并且在适当的地方使用它们。

我们讨论了团队 Agent 的四种类型：专家、通用工作 Agent、桥梁和参谋长。知道你自己的使用场景属于哪一种，会告诉你很多关于如何把它做好的信息。

我们还讨论了什么时候该等待的三个信号：是品味胜过标准，还是没人能拥有知识，或者是它并没有简化工作。

而当你开始构建时，我们按照顺序讨论了五个决策：它做什么、它住在哪里、它知道什么、它能触碰什么，以及你如何运行它。

如果你记住这些，你就有了正确构建团队 Agent 所需要的东西。

如果你想具体操作，有一个快速的方法。

最后，一切都在变化。

很可能每周我们都会有相关的发布，等你们听到这期节目时，可能已经有东西发布了。但我确实认为今天讨论的所有内容，无论接下来推出什么，都依然成立，因为当一个 Agent 被正确构建、决策得当，它就和任何特定的工具或功能是正交的。

业务决策和团队标准化比工具重要得多，而随着更多发布，工具只会让事情设计得更好。

如果我要对今年余下的时间做些预测，我认为我们会看到今天所讨论的内容越来越正式化，也会有更多工具和功能帮助我们在身份、权限、所有权等方面做得更好更简单。

同时，我们总能信赖实践者们在公开场合分享他们的很多经验教训，这样我们就能从许多其他 AI 前沿领域的个人和公司那里学到东西，看看他们是怎么做的。

就这些了。

太棒了。

内容很棒，Noufar。

在结束之前，我有几个想法想以讨论的方式抛出来。

首先，我想问的是，你给出了四种你见过的 Agent 原型。

根据你的观察，团队起步时，有没有哪种原型比其他的更常见？

我觉得从理论上讲，那种存在于个人之间或团队之间的 Agent 定义是最吸引人的，但也是执行起来最困难的。

所以我觉得这些其实是我看到的，不太会优先去尝试的。

我见过很多非常成功的第一个版本，就是那种专家型智能体，帮团队创造更多冗余，我说的冗余是好的那种，还能减轻公司里那些瓶颈环节的压力。

这类我已经看到很多实际落地了，而且我觉得工具越容易上手，这些就越容易搭建。

所以这些大概是最容易摘的果子。

有意思，因为那正好是我脑子里想的。

我个人特别被那些我觉得最难做的吸引。

我也见过很多那种专家型的简单实现——其实我们聊了很久都没意识到它算这种团队智能体——就是代理化的团队内部知识库，比如各种政策，像早退啊之类的，就是公司数据库里的信息，你可以通过聊天机器人直接查。

很多公司从一开始就在这个用例上取得了巨大成功，它简单、快速、容易上手。

我还有个问题想问你，就是肯定有很多人在犹豫，在 GrokBot、Microsoft Copilot 或者他们用的那些核心工具——比如 OpenAI、Anthropic——还没推出原生版本之前，他们该投入多少来搭建这些东西？

而且很明显，有些迹象表明他们正在往这个方向想。

我觉得 Claude Tag 是目前最好的例子。但问题是，现阶段深入做这件事的价值是不是在于让你理解理论、学会定制化，等未来更好的工具出来时就能用上？还是你怎么看这个取舍？

我觉得最核心的工作永远是配置和知识梳理。

所以我会选一个跟你现有工具生态最接近的工具，然后想办法把其他功能都实现出来。

如果有更好更新的工具出现，你也能准备好，因为你们已经在基础事实、这些智能体的禁忌、使用场景上达成共识了。

所以哪怕一开始实现得很笨拙，也能为未来打好基础。

至于要不要自己从头搭建一个类似竞争产品或者团队级别的框架，如果你有那个本事，做起来不难，也有合理的理由，那你可以做。

但我现在不会把精力花在自建一个 Claude Tag 或类似的东西上，因为我们俩都同意这些功能都会来，而且很可能变得非常易用、非常智能。

你的护城河很可能在于所有那些这些公司无法掌控的东西上。

嗯，老样子，感谢又一场精彩的 Operator's Cut，期待你很快再回来。

谢谢。

拜。