Asana推出智能体工作管理系统：让AI成为可训练、有记忆、守机密的团队成员

构建AI智能体的企业团队不断遭遇同一堵墙：一个能回答提示词的聊天机器人，却记不住此前五个人向它提出的问题，也无法告诉你上个月的版本是否真正奏效。

在VentureBeat记者Sam Witteveen主持的炉边对话中， VB Transform 2026大会上，Asana首席产品官Arnab Bose深入剖析了其团队如何解决这一难题，从而构建了一套全新操作系统：智能体工作管理（Agentic Work Management, AWM）。该产品将AI智能体视为可训练的团队成员，使其与人类协同作业，而非一对一的助手。

对于试图超越基础集成的产品构建者和开发者，Bose展示了系统内部运作机制。他详细阐述了Asana如何设计AWM，为解决现实世界中的瓶颈问题、规模化构建智能体系统提供了蓝图。

工作图谱（Work Graph）：复用18年企业数据

为构建面向人机协作团队的操作系统，Asana需要一个现成的企业级上下文图谱。他们基于自身已有18年的架构——工作图谱（Work Graph）——来构建AWM。 

这种基于图谱的数据库通过该公司称之为“清晰度金字塔（Pyramid of Clarity）”的结构组织信息。最小的工作单元是一项任务，包含指派人和截止日期；任务隶属于项目，项目汇总至投资组合，而投资组合则关联公司整体目标。该图谱可追踪例如一项延迟的设计任务如何影响公司营收目标。工作图谱提供了一份实时账簿，记录谁在何时、为何执行何事。 

AWM利用该架构打造了一个多人协作的智能队友。标准AI副驾驶（copilot）是无状态的，且仅绑定于单个用户的提示词。由于AWM接入工作图谱，AI能够查看公司整体目标、更新项目状态，并与人类同事共享记忆。 

Bose表示：“因为[该智能体]接入了工作图谱，它所依据的并非你发送给它的某个特定提示词，也非某位员工本地文件系统中的某个特定Markdown文件。它运行所依赖的是整个公司的共享账簿。”

AWM目前已投入生产环境使用。Bose称Asana已有“若干客户上线并成功应用该系统”，其中包括联邦快递（FedEx），后者已就此次转型发布了自己的案例研究。

为机密工作构建护栏

将AWM交付给企业客户，要求Asana解决若干技术障碍。首要挑战是数据治理。若AI队友在全公司范围内运作，它会通过学习工作流及人类反馈来构建共享记忆。 

Bose强调了一个关键的边界问题：若某位高管使用AWM为一项机密项目构建工作流，系统必须确保该智能体更新后的记忆不会泄露给后续与同一智能体交互但无权访问该项目的员工。 

Bose表示：“当我运行AI队友时，我不应能利用该共享记忆——倘若你曾使用同一AI队友在某个我无权访问的机密并购（M&A）项目中创建了该记忆。” Asana为此设计了一套访问控制机制，以界定何种操作触发记忆创建，何种操作仅为简单任务执行。

其次，AWM采用动态模型路由机制，将提示工程从用户端抽象出来。当用户向AI队友分配任务（例如起草一位总经理职位的岗位描述）时，AI会交叉比对公开的职位招聘信息、Asana内部写作风格指南以及产品需求文档。对于复杂任务，系统自动将提示词路由至计算密集型前沿模型——Bose以Anthropic的Opus及OpenAI的模型为例；而对于较轻量级任务，则降级至更快、更经济的模型。 

Bose表示：“我们不希望知识工作者必须自行思考，完成该任务所需的最优提示词、上下文工程及附件究竟是什么。它应当让人感觉就像把任务分配给了一个人类同事。”

这种动态路由引入了第三个挑战：计费抽象化。智能体任务的计算复杂度各异，导致信用点消耗速率难以预测。

Bose表示：“我们不希望陷入这样一种局面：我们的客户不得不去推断某些任务……远比其他任务复杂，因而将以不同速率消耗信用点。”他补充道，不可预测的定价风险可能导致客户通过限制员工运行AI队友的频次，从而自我限制员工使用。

为使AWM具备商业可行性，Asana设计了其计费架构，按每项任务完成收取固定费用。平台承担模型选择、token数量及运行次数等复杂性，以确保企业客户获得可预测的定价。

无状态聊天机器人的弊端

AWM旨在解决当前企业AI部署中一个特定问题：无状态性。开发者可轻松借助模型上下文协议（Model Context Protocol, MCP）集成，将大语言模型连接至Slack、Google Drive或Databricks等企业工具。然而，基于基础聊天界面的智能体缺乏持久性。

Bose详述了一个场景：用户要求聊天智能体基于历史表现与竞品调研草拟一项营销活动方案。该智能体从外部工具获取数据以回应提示词，但执行过程处于真空状态。这是一次性任务，仅惠及单个个体，无法为下一位构建类似活动的人创建可复用的工作流。

Bose表示：“该模式的问题在于，这些调用是无状态的，且未利用公司共享‘大脑’——即这个基于图谱的数据库或上下文图谱。” 

AWM通过创建永久状态来解决此问题。当AWM内部的AI队友完成一项任务时，系统会记录元数据，登记该完成是否改善了项目状态，以及如何推动更高层级的公司目标。 

CoreWeave产品发布内幕

云服务商CoreWeave是早期采用者之一，正利用AWM彻底重构复杂的新产品发布流程。 

Bose透露：“CoreWeave同时使用了我们的确定性AI工作室工作流规则以及多个AI队友来开展新产品发布。” 

过去，CoreWeave的产品经理需填写复杂的表格，详述基础设施、参数及成本。人工审核员手动评估这些表格，并将其拆解为财务、市场及硬件团队的具体任务。 

在AWM工作流下，产品经理只需撰写一份标准Google文档，并指向其产品需求文档。一个确定性AI工作流读取该文档，自动生成项目结构并分配任务。随后由专业智能体接管执行：一个智能体监控整体项目状态并标记瓶颈；另一个智能体在具体任务内预测基础设施成本，并在数值符合历史预算时推荐审批。该系统自动分流琐碎事务，而人类则专注于评估AI的输出结果。

亦敌亦友问题

这种动态关系因以下事实而变得复杂：在幕后为Asana工作流模型（AWM）提供支持的同一批前沿模型供应商——Anthropic、OpenAI——也在推出各自竞争性的智能体产品，例如Anthropic推出的Slack版Claude（Tag）。当被问及二者重叠问题时，博斯并未否认其中存在的张力。

"我认为这就是我们必须共同面对的现实，"他说。

他主张AWM具备持久生命力的理由在于Asana长达18年的用户使用体验与工作流数据积累，以及为特定行业预构建的标准操作流程——他强调，这些是未经打磨的前沿模型所不具备的专业能力。他表示，像Tag这样的产品在Slack中运行效果良好，但它需要高度精选的频道，并且对所对接的每一个下游应用都需单独配置凭证。

"模型能力加上一种轻量级方式来展示其价值，与专为真正端到端使用而预构建的产品之间，存在巨大差异，"博斯表示。