这是我们的构建人类-智能体团队系列中的第三篇文章。第一篇分享了我们在 Anthropic 使用多人 AI 的经验。第二篇分享了 Slack 如何将工作场所对话转化为智能体所需的上下文。这一篇则探讨当智能体在团队工作的同一平台上运行时，会发生哪些变化。
在推出 AI 智能体多年前，Asana 的团队就在不断迭代，试图将结构和问责机制编码进团队协作的方式中。他们最终构建了 Work Graph® 模型，它将每个任务、项目、目标和对话映射到一张关系网中，并明确指定负责人、贡献者和依赖关系。
当他们开始构建 AI 智能体时，他们决定不为 AI 添加新的上下文结构，而是让智能体在同一个模型中运行。智能体将拥有明确的角色，被分配任务，读写消息，并与人类协作者一起出现在活动流中——同时在智能体可以访问和分享的内容上增加了额外的防护措施。
我们与 Asana 的首席产品官 Arnab Bose 进行了交谈，聊了 Asana 自己的团队如何使用 Claude 并与这些智能体协同工作，其中 Claude 模型为复杂任务提供支持：每个智能体如何获得自己的角色和访问权限，谁来训练它，工作如何对所有人保持可见，以及智能体在 Asana 的人类-智能体团队中承担哪些类型的工作。
在智能体对你的工作采取行动之前，先思考并构建好你的工作
对 Asana 员工来说，Claude 是默认的 AI 工具，连接到员工用于工作的平台，包括 Google Drive、Slack，当然还有 Asana。
“一个人通过将非结构化数据——一个想法、一段 Slack 对话、一段 Zoom 会议录音、一份 Databricks 报告、来自 Google Docs 的信息——整理清楚来理解自己的一天，”Arnab 说。“他们与 Claude 讨论这些内容，然后可以把所有这些都注入到 Asana 通过项目和任务提供的结构中。”一旦结构就位，智能体就可以对其采取行动，凭借我们在这个系列第一篇文章中描述的三项能力，构建有效的人类-智能体团队：持久记忆、自己的凭证，以及共享上下文。
如何将其付诸实践：
- 从你自己的想法开始。把你一天中零散的内容、一个想法、一段 Slack 对话，或散落在各个文档中的笔记，带到 Claude 里。
- 与 Claude 辩论和讨论。把它当作思考伙伴：把想法聊透，直到下一步变得清晰。
- 把可执行的条目记录到 Work Graph 中。把可执行的内容移入项目和任务，让智能体和同事可以接手。
给每个智能体一个角色，以及它所需的工具和访问权限
Asana 员工可以在任何项目中与 AI 智能体协作，就像与人类同事协作一样。人类设计自己所参与的团队；每位员工都会获得一份推荐智能体列表，可用于推进其团队的目标。
智能体围绕角色或工作类型构建，例如内容写作者、洞察分析师、项目经理、工作受理专员、活动分析师或活动协调员。每个智能体都自带预置技能，这些技能基于 Asana 对其客户如何开展此类工作的研究，并配备所需的集成，例如 Hubspot 或文档网盘。
每个智能体还有一个个人资料页面，列出其名称和用途、可以使用它的人员、管理员、指令、技能、集成和权限。Asana 为你提供工具，让访问权限的授予是有意为之的。“Asana 是一个受控的工作界面，”Arnab 说。“你可以选择只授予对一组特定项目的访问权限，而不是所有内容，或者只授予对一组特定文档的访问权限，或者文档与应用的组合。”
与人类用户一样，智能体也受到明确的访问控制约束，但还有一层额外的保障：Asana 表示，智能体的实际访问权限受触发它的人的权限所限制。这使智能体可以对公开内容拥有广泛访问权限，同时将任何人访问智能体在私密情境中所获信息的风险降到最低。
如何将其付诸实践：
- 在创建智能体之前先定义角色。想一想智能体可以在你的团队中承担哪些类型的工作，然后写下该智能体的用途、指令，以及它具体负责哪些工作，就像你为新员工的第一季度所做的那样。
- 限定访问范围。确定该智能体可以读取哪些项目和文档、可以访问哪些应用，以及可以执行哪些操作。
- 将用户和管理员分开命名。许多人可以与一个智能体协作，但只有一小部分被指定的人应当管理它可以访问什么以及它如何行为。
将使用智能体与训练智能体分开
Asana 的智能体（它称之为 AI teammates）的一个关键特性是共享记忆，这使智能体能够保留先前指令中的信息，让多个用户可以复用该记忆来更快地完成任务或工作。“AI teammates 可以像团队中的一个人一样被指导和训练，”Arnab 说。
共享记忆的运作方式中有一项基于角色的限制。虽然任何人都可以就某项任务向智能体提供反馈，但只有管理员和编辑者可以将反馈提交到永久记忆，以及撤销或从该记忆中删除。对于其他所有人来说，他们提供的反馈仅适用于当前任务。
这种区分是有意为之的，Arnab 说。Asana 的传播团队掌握着公司声音和语调的笔杆，因此他们将是撰写类智能体的编辑者和管理员。Arnab 可以用它起草，但他不能修改它的行为。而且大多数人根本不需要接触这套机制：“并非团队中的每个人都需要理解这些概念，比如技能、行为和记忆。团队中有一两个人成为专家，他们正确地设置好，团队中所有其他人都能从此以后获得同样的好处。”
如何将其付诸实践：
- 决定谁训练每个智能体，谁与它协作。找出你业务内部能够帮助构建团队所用智能体的主题专家。其他所有人都可以就任务提供反馈，但不能改写智能体。
- 让编辑者与专业知识相匹配。拥有智能体所应用标准（如品牌语调或规划惯例）的团队，拥有（或管理）该智能体。
- 在工作过程中构建记忆。反馈可以随着时间推移改进智能体。让智能体记住值得保留的决策，或删除那些不再相关或不真实的决策。
让智能体的工作处于所有人都能看到的地方
类似于Slack 中的智能体在频道中透明地发布当一项任务被分配给 AI 队友时，每个人都能看到是智能体在做这件事，以及它在做什么。智能体会发布活动记录，包括它的研究计划和所采取的步骤，因此所有能访问该任务的人都可以阅读它做了什么、发表评论，并引导它朝着他们想要的结果推进。
当 Asana 的传播团队请 Arnab 审阅一份演讲活动的简报文档时，他在任务中 @ 了该智能体，并要求它同时把他早前一次演讲的讲稿内容也纳入考虑。这条消息很简短，因为他已经多次使用过该智能体，而且他引用的材料已经在 Work Graph 中了。传播团队的一位同事可以看到他的请求和智能体的回复，并同时与智能体来回沟通。
"如果你是高度熟悉 AI 的人，你或许可以从一对一的 AI 智能体那里获得高质量的回复，把那份文档拿出来，再发回 Slack 或 Asana 中，"Arnab 说。"但到了那个时候，其他审阅该内容的人并不知道提示词是什么、来回沟通了什么。如果他们不同意你提供的某些指导，他们就不可能就此达成一致。"在共享任务中，请求、反驳和输出都在同一个地方，审阅输出的人也可以修改产生该输出的指令。
如何将其付诸实践
- 在团队审阅工作的地方引入智能体。这样一来，请求、智能体的步骤和结果都在同一个地方，审阅者可以修改指令或输出。
- 让智能体的工作明显是智能体做的。这样一来，人们就会知道这项工作是由 AI 智能体完成的，而不是人类同事。
- 让审阅者能够指导智能体的工作。Asana 的智能体会在共享任务中发布它们的计划和步骤，因此其他审阅者可以提供进一步的指令或反馈。
Asana 交给智能体的三项工作
在 Asana，Claude 为任何生成文档或运行复杂任务的智能体工作提供支持。以下是来自公司不同团队的三个例子：
从 Slack 频道回答产品问题
随着 Asana 推出新功能，销售人员和客户成功团队员工可以在一个共享的 Slack 频道中提问。在 AI 队友出现之前，同样的问题会被反复发布，每次都要 @ 相关领域的专家。Arnab 表示，可搜索的知识库并不是一个实际的解决方案，因为答案往往很微妙，而且会不断变化。“你多少需要对产品当前的状态有一些品味判断，”他说。
这些问题仍然会发到 Slack，因为那是外勤团队提问最简单的地方。现在，频道里的一个 Asana 应用会把每个问题转成一个 Asana 任务，然后由一个智能体接手处理。如果存在已批准的指导内容，智能体会回复并附上来源链接。如果没有已批准的答案，而问题又指向产品中的某个缺口，智能体会在产品团队的接收项目中创建一个任务，并将其加入待办列表。而如果同一个问题反复出现，智能体也反复发布同样的记录，它就会为赋能团队创建一个任务，去更新培训材料和文档。
这一流程为赋能团队腾出了宝贵的时间，让他们能够专注于战略性的、优先级更高的工作，同时也为业务的其他领域提供信息。例如，如果围绕某个新产品有大量关于某一主题的问题，这就是一个信号，提示赋能团队应通过额外的培训或信息来重点关注它。
向高管汇报有风险的续约情况
Asana 的首席客户官 Josh Abdulla 过去每周都会为高管团队制作一份有风险的续约简报，依据是客户成功经理（CSM）的更新——他们会标记出有风险的续约，并在情况变化时更新账户信息。在全球数千名客户中，更新量之大使得没有专人去综合整理就不可能保持最新状态，而这是一项繁琐的工作，也让整个流程变得被动。“Josh 是在领导告诉他时才知道问题的，而不是在数据最初显示出问题时，”Arnab 说。
客户体验组织在 Asana 中构建了一个名为 At-Risk Renewal 的智能体 AI 队友。它会读取全球组合中每一个有流失风险的续约任务，包括每位 CSM 的更新、状态备注和评论，并生成一份结构化的每日摘要，分为三类：积极势头、消极势头和建议的后续跟进。它先运行全球视图，然后按地区细分，并在每天早晨自动将摘要推送给首席客户官、首席营收官以及每位区域客户成功负责人。由于摘要会落在共享空间中，这些负责人可以提出后续问题，比如某个特定账户流失预测背后的领先指标是什么，并引导智能体记住一些事项以供下次运行使用，因此报告每天早上都会变得更好。
“他们或许可以让 Claude 为自己生成一份报告，”Arnab 说。“但我们如何达到这样一种状态：报告实现标准化、有一个共享工作空间，并且每一次运行都让它变得更好？”
用 Command 规划工程周期
当 Asana 在其自身产品上运行自动化编码循环时，其周期时间和发布都出现了延误，因为这些循环被自动生成的变更弄得越来越臃肿。这种循环本身在软件公司中已变得很常见：从各种渠道收集客户反馈，对其进行综合整理，并触发编码智能体将其转化为拉取请求（PR）。“代码生成如今不再是瓶颈，”Arnab 说。“瓶颈在于规划、决策和精炼。”Asana 的工程组织现在运行在 Command by Asana 上，这是一款用于管理大型工程团队的产品，并用它来管理这一循环。
在 Command 中，一个团队空间容纳 10 到 12 名工程师，他们负责一个产品。智能体会用从客户反馈以及团队在 Slack 中反馈频道的评论里提取的工单，填充团队的未规划看板。由人来决定哪些内容从该看板进入周期，而 Command 会以乐观、平衡和保守三种估算来预测该周期的完成时间。
工单可以分配给一个人或一个编码智能体，而且由于周期数据都集中在一处，管理者可以在聊天中询问为什么某个发布偏离了轨道，以及哪些权衡取舍能让它重回正轨。Command 从数据中给出答案，说明是什么在驱动信号，以及该权衡哪些变更。所有这些都通过 Asana 的 MCP 服务器暴露出来，这个连接让像 Claude 这样的助手能够读取它，因此像 Arnab 或他对口的 CTO 这样的人，无需打开 Command 就能问 Claude 哪些在正轨上。
“当团队能够毫不费力地协作时，人类就会繁荣，而如今每个团队都是部分人类、部分智能体，”Arnab 说。“这正是我们为之设计的工作方式：一个人类和智能体都能共同使用的共享上下文，每个智能体都有独特的身份，以便其贡献和访问权限可以被审计，还有一份智能体能学到什么的持久记录，让团队的知识不断累积而不是蒸发。”