一、引言：agent 住在团队工作的地方
原文链接：Agents you can coach: how Asana builds human-agent teams with Claude
来源：Claude Blog / Anthropic · 作者：Aleksandra Todorova、Kristen Swanson · 受访者：Arnab Bose（Asana 首席产品官）
发布时间：2026 年 9 月 29 日 · 本文是该系列第三篇
这是"构建 human-agent teams"系列的第三篇。第一篇（Anthropic 的高效人机协作团队实战）讲的是多人智能体在理念上该具备什么；第二篇讲 Slack 如何把职场对话变成 agent 需要的上下文；这一篇把镜头对准一个更具体的问题：当 agent 运行在团队实际工作的同一个平台上时，会发生什么？
Asana 给的答案有点反直觉。它没有走"给每个员工配一个更聪明的 AI 助理"这条路——那种做法你已经很熟了：一个人、一个窗口、一份结果，然后在 Slack 里贴出来。Asana 走的是另一条：让 agent 成为团队里一个有角色的成员，和人类出现在同一份名册、同一份工作产物、同一张工作图里。
这张封面的重点不在左右两个方框，而在底部那条共享带。人类团队和 AI teammates 不是两个平行世界，它们的底座是同一张 Work Graph。Asana 全篇的四条策略、三个案例，本质上都在回答一件事：怎么让 agent 真正落进这张图，而不是挂在图外面。
二、不另立体系：让 agent 进入同一张工作图
先补一段背景。在引入 AI agent 之前，Asana 已经花了很多年做一件事：把"结构与问责"编码进团队协作的方式里。产物就是 Work Graph®——把每个 task、project、goal、conversation 映射成一张关系网络，每个对象都带明确的 owner、contributor 和 dependency。
到了要建 AI agent 的时候，Asana 做了一个很关键的减法：不为 AI 增加新的上下文结构。让 agent 直接在这套已有模型里跑——
- 它拥有定义好的角色，而不是一个聊天框；
- 它被分配任务，和人类同事一样；
- 它能读写消息；
- 它和人类协作者一起出现在 activity feed 里。
当然，它不是"像人一样"就够了。Asana 在 agent 能访问什么、能分享什么上加了额外的安全措施，这里有两条设计值得单独抄下来：
- 显式访问控制。 你可以授权它访问一组特定项目、一组特定文档，或者"文档 + 应用"的组合。Arnab Bose 的原话是：“Asana 是一个受控的工作界面（contained work surface）。”
- 有效权限上限。 agent 的 effective access 由触发它的那个人的权限来界定。这一条设计得非常精妙——它让 agent 可以对公开内容有很宽的访问面，同时把"某人在私密语境里告诉过 agent 的事，被别人通过 agent 反查出来"的风险压到最低。
我想在这里停一下，因为这是全文最容易做错的一步。
大多数团队落地 agent 的第一反应是做加法：新建一层知识库、一套向量检索、一个专门的"AI 上下文层"。结果就是组织里出现了两套真相——人类在项目管理工具里维护一套，agent 在检索层里维护另一套。两套真相会不可逆地漂移：人改了任务状态，检索层里的文档还停在昨天；agent 基于过期上下文给出建议，人类开始不信任它，然后把它退回成一个玩具。
Asana 的减法避开的就是这个陷阱。agent 不是外挂，它是这张图上的一个节点；它读的就是人类正在编辑的那个对象，它写的也留在人类正在看的那条线程里。上下文没有副本，就没有漂移。
三、四条策略：从"能不能干"到"敢不敢放手"
进入正题。原文把 Asana 的做法拆成四条策略，每一条末尾都附了一份 “How to put this into practice” 落地清单。这四条不是并列的清单，而是层层递进的：前两条解决"agent 能不能干"，后两条解决"干得好不好、敢不敢放手"。
3.1 先结构化工作，再让 agent 行动
这是整套方法论的前提。Arnab 描述得很具体：
一个人理解自己一天的方式，是把非结构化数据——一个想法、一段 Slack 对话、一份 Zoom 会议录音、一张 Databricks 报表、一条 Google Docs 里的信息——先和 Claude 谈一遍，然后把这一切"泵入"Asana 提供的 projects 和 tasks 结构里。
顺序很重要：先谈透，再结构化，最后才是 agent 行动。结构就位之后，可执行项进入 Work Graph，agent 和同事才能接手。
这里有一句值得贴在墙上的隐含判断：agent 不能替你决定"该做什么"。它只能在已经被结构化的对象上行动。所以"结构化"这一步不但没有被 AI 省掉，反而变得更贵、更不可省——因为过去你可以靠脑内记忆和走廊对话来兜底，现在这些兜底对 agent 全部失效。
落地清单：
- 先带上自己的想法：把你一天里零散的想法、Slack 对话、文档笔记交给 Claude；
- 和 Claude 辩一辩：把它当 thinking partner，把想法谈透，直到下一步清晰；
- 把可执行项落到 Work Graph：移进 projects 和 tasks，让人和 agent 都能接手。
3.2 给每个 agent 一个角色，以及它需要的工具和权限
Asana 员工可以在任何 project 里和 AI agent 协作，体验和跟人类同事协作一样。但团队构成由人设计——每位员工会拿到一份推荐 agent 清单，而不是一个空白的"创建你自己的助手"按钮。
agent 是按角色/工作类型来建的，原文举了六类：content writer、insights analyst、project manager、work intake specialist、campaign analyst、campaign coordinator。
每个 agent 有几样标配：
- 预置 skills——基于 Asana 对"客户如何做这类工作"的研究沉淀下来的；
- 所需 integrations——比如 Hubspot、文档盘；
- 一个 profile page，明确列出七件事：名称与用途、可以使用它的人、管理员、指令、技能、集成、权限。
七项里我认为最关键的是后面三项。“可以使用它的人"和"管理员"是分开的——很多人能用它，但只有一小群被点名的人负责治理它的访问权限与行为。这个"使用者 / 治理者"分离，是 3.3 的前提。
落地清单：
- 先定角色，再建 agent：像给新员工定第一季度的期望一样，写下它的 purpose、instructions 和它负责的具体工作；
- 划定权限范围：明确它能读哪些项目与文档、能用哪些应用、能执行哪些动作；
- 分开点名使用者和管理员。
3.3 把"使用 agent"与"训练 agent"分开
这是全文最有辨识度的一条，也是标题里 “agents you can coach” 的来历。
Asana 的 agent（它管这叫 AI teammates）有一个关键机制：shared memory（共享记忆）。它保留此前指令中的信息，让多个用户可以复用这条记忆，从而更快完成任务。Arnab 的说法是：
AI teammates 可以像团队里的真人一样被教练、被训练。
但"可以被教练"不等于"谁都能改它”。Asana 在权限上做了一个刻意切开的设计：
- 任何人都可以就任务给 agent 反馈——但反馈只对当前任务生效，下一次运行不会记住；
- 只有 admins 和 editors 能把反馈写入永久记忆，并且有权撤销或删除记忆。
这个区分不是技术限制，是组织设计。原文给了一个特别清楚的例子：Asana 的 communications 团队掌握公司的语气与风格（“hold the pen on the company’s voice and tone”），所以他们天然就是一个写作类 agent 的 editors/admins；Arnab 作为 CPO 可以用这个 agent 起草东西，但他改不动它的行为。
Arnab 把背后的取舍讲得很直白：
团队里不是每个人都需要理解 skills、behavior、memory 这些概念。团队里会有一两个人成为专家，他们把它配置正确，之后团队里其他所有人都能拿到同样的收益。
这句话其实回答了很多团队卡住的那个问题：要不要给全员做 AI 培训？ Asana 的答案是——不必要，也不划算。真正需要的是在每个工作领域里挑出一两个 SME，让他们成为 agent 的治理者。剩下的人只需要会"用"，以及会"在任务上给反馈"，就够了。
落地清单：
- 想清楚谁训练、谁使用：识别内部 SME 来构建团队共用的 agent，其他人只能给任务级反馈；
- 让拥有标准的人拥有 agent：品牌语气、规划惯例这类标准的持有方，才是它对应的 agent 的 owner；
- 在工作过程中积累记忆：让 agent 记住值得保留的决定，删掉已经不相关或不再正确的记忆。
3.4 让 agent 的工作留在所有人都能看到的地方
最后一条是信任的地基。当任务被分配给一个 AI teammate，所有人都能看到是 agent 在做、以及它做了什么。agent 会发布它的 research plan 和所采取的步骤，任何有该任务访问权的人都能阅读、评论、引导它的产出。
原文里有一个很有画面感的场景：Asana 的 communications 团队请 Arnab 审阅一份演讲活动的 briefing document，他在 task 上 @-mention 了 agent，要求把此前演讲的 talk track 也纳入考量。这条消息很短——因为他已经用过这个 agent 很多次，引用的材料也已经在 Work Graph 里。而 communications 团队的同事能看到他的请求和 agent 的回复，并同时和 agent 来回沟通。
Arnab 用一段话解释为什么非要在共享空间里做这件事：
如果你 AI 用得很溜，你一个人对着 AI 也能拿到很高质量的答复，把文档拿出来贴回 Slack 或 Asana。但到那一步，其他审阅这份内容的人并不知道你的 prompt 是什么、中间的来回是什么。如果他们不认同你给出的某些指引，他们根本没法跟你对齐。
这段话把"透明"从文化偏好拉成了工程约束。在一对一的窗口里，agent 的产出是一个黑盒结果，审阅者只能对结果提出意见，改不了产生结果的指令。而在共享任务上，请求、反驳（pushback）和输出都在同一个地方——审阅输出的人，同时也能修改指令。
这就是"可教练"的技术前提：指令可见，才能被教练。
落地清单：
- 在团队审阅工作的地方引入 agent：让请求、agent 步骤、结果同处一地；
- 让 agent 的工作明显是 agent 的工作：别让人误以为是人类同事做的；
- 让审阅者能教练 agent 的工作：agent 在共享任务上公布 plan 和步骤，其他人可以继续补充指令或反馈。
四、三个真实案例：agent 到底在干哪些活
原文强调了一句：Asana 内部所有生成文档、或运行复杂任务的 agentic work，都由 Claude 提供动力。下面是它交给 agent 的三类活。
4.1 在 Slack 频道回答产品问题
原来的痛点：Asana 发布功能时，销售和客户成功人员在共享 Slack 频道里提问。接入 AI teammate 之前，同一个问题被反复发帖，每次都要 @-mention 领域专家。
为什么不用知识库：Arnab 说可搜索知识库并不实际，因为答案有细微差别、而且会变。原文的原话是：“你多少需要对’产品当前状态是什么’有一种品味判断（taste-making）。”
机制：问题仍然发在 Slack（对一线来说最省事）。频道里的一个 Asana app 把每个问题转成 Asana task，agent 接手：
- 有已批准指引 → agent 回复并附来源链接；
- 没有已批准答案、且问题指向产品空白 → agent 在产品团队的 intake project 里建 task，进 backlog；
- 同一问题反复出现、agent 反复贴同一条记录 → 它会给 enablement 团队建 task，去更新培训材料与文档。
效果：释放了 enablement 团队的时间去做更高优先级的战略性工作。更有意思的是它产生了反向信号——某个新产品的相关问题集中出现，本身就是"enablement 该加大培训投入"的早期预警。
注意这里 agent 的处理方式：它不是"能答就答，不能答就装死"，而是把每一次答不出来的问题，转成一条组织该处理的工作项。这是把客服机器人升级成工作流入口的关键一步。
4.2 向高管汇报"有流失风险的续约"
原来的痛点：Asana 首席客户官（CCO）Josh Abdulla 过去每周手动制作 at-risk renewals 简报，依据是全球 CSM 标记风险、并随情况变化不断更新的账户信息。全球几千个客户，更新量之大，没有专人综合就无法保持最新；而且这份工作枯燥、流程被动。
Arnab 一句话点出问题本质：“Josh 是在领导告诉他问题时才知道问题，而不是数据最早显示问题时。”
机制：客户体验组织在 Asana 里建了一个叫 At-Risk Renewal 的 agent。它读取全球组合里每一个 at-risk renewal task——包括每位 CSM 的更新、状态备注和评论——生成结构化的每日 digest，分成三个桶：
- positive momentum（正向势头）
- negative momentum（负向势头）
- recommended follow-ups（建议的跟进事项）
运行方式：先跑全球视图，再按区域切分，每天早上自动推送给 CCO、CRO 以及每位区域客户成功负责人。
可教练性在这里体现得最清楚：因为 digest 落在共享空间，领导们可以追问——比如"这个账户的 churn forecast 背后的 leading indicators 是什么"——并且可以教练 agent 记住某些内容，供下次运行使用。报告不是每天重新生成一份，而是每天变好一点。
Arnab 的反问很值得玩味：“他们完全可以自己让 Claude 生成一份报告。但我们要怎么走到那一步——报告有标准化、工作空间是共享的、而且每一次运行都让它变得更好？”
这其实就是"个人用 AI"和"团队用 agent"的分水岭：前者优化的是这一次的输出，后者优化的是下一次的起点。
4.3 用 Command 规划工程迭代
背景：Asana 在自己的产品上跑自动编码循环（automated coding loops）时，cycle time 和发布开始滑坡——因为循环被自动生成的变更"膨胀"了。这个循环在软件公司已经很常见：从各渠道收集客户反馈 → 综合 → 触发 coding agent 生成 PR。
Arnab 的判断是这一段的点题句：
代码生成已经不再是瓶颈。瓶颈在规划、决策与细化（planning, decision-making, and refinement）。
机制：Asana 的工程组织跑在 Command by Asana（管理大型工程团队的产品）上。
- 一个 team space 容纳 10 到 12 名工程师，负责一个产品；
- agents 用从客户反馈和 Slack 反馈频道评论里拉取的 tickets，填充团队的 unplanned board；
- 由人决定哪些从该 board 进入 cycle；
- Command 预测该周期的完成时间，给出乐观 / 平衡 / 保守三档估计；
- ticket 可以分配给人，也可以分配给一个 coding agent；
- 因为 cycle 数据都在一处，经理可以在 chat 里问"某个发布为什么偏离轨道"“做哪些 tradeoff 能拉回正轨”，Command 从数据回答；
- 全部通过 Asana 的 MCP server 暴露出来——这个连接让 Claude 这类 assistant 能读取它。
最后一点最有延展性：Arnab 或他对口的 CTO 不需要打开 Command，直接问 Claude 就能知道什么在正轨上。这不是"又做了一个 AI 功能"，而是让已有的数据资产被 AI 以标准协议接走。回到第二节那句话——上下文没有副本，就没有漂移；而现在，连"问数据"这件事都不需要再造一个新的入口了。
五、结语：让知识复利，而不是蒸发
原文最后用 Arnab 的一段话来收束，我认为它把整篇的立意说完了：
人类在团队能毫不费力地协作时蓬勃发展，而今天每一个团队都是部分人、部分 agent。这正是我们设计的工作方式：一个人类与 agent 都能使用的共享上下文；每个 agent 有独立身份，使它的贡献与访问可被审计；以及 agent 所学内容的持久记录，让团队知识不断复利，而不是蒸发。
把 Asana 的做法压到最短，是六条：
- 同一结构：agent 不另立上下文体系，而是进入 Work Graph，有角色、被派任务、读写消息、出现在活动流；
- 有界权限：显式访问控制，且 agent 的有效权限不超过触发它的那个人；
- 分工明确：人人都能与 agent 共事，少数人被点名治理它的访问与行为；
- 使用与训练分离：反馈人人可给，写入永久记忆的权力归 admins / editors；
- 工作可见：agent 公布 plan 与步骤，请求、反驳、输出同处一地，审阅者可直接改写指令；
- 知识复利：共享记忆 + 持久记录，让团队知识 compounds instead of evaporating。
如果把它和本系列第一篇放在一起看，会有一条很清楚的线索：Anthropic 那一篇讲的是规范——公开工作、明确角色、设定北极星、随时间建立信任；Asana 这一篇讲的是这些规范要在什么样的产品结构里才落得下去。规范需要载体：上下文要有地方公开，角色要有个 profile 去承载，反馈要有条路径能写进记忆，信任要靠一份可审计的活动记录来积累。缺了载体，规范就只是一页 PPT。
而最值得带走的一句，其实是那句标题里的隐喻的另一种说法：
一对一用 AI，你也能拿到高质量产出——但那只是个人的收益，组织什么都没有学到。
把 agent 放进共享任务、给它一个身份、把教练权交给拥有标准的那一两个人，你换来的不是一个更快的助手，而是一支会随每一次运行变好的团队。
「真诚赞赏，手留余香」
爱折腾的工程师
真诚赞赏，手留余香
使用微信扫描二维码完成支付
