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