Asana 的销售和客户成功人员有一个共享 Slack 频道，专门问产品问题。新功能不断发布，同样的问题被反复提出，每次都要 @ 一位领域专家。他们想过建可搜索的知识库，结论是不可行——用他们首席产品官 Arnab Bose 的原话说：「答案很微妙、而且会变化，你需要有人对『产品当前状态』做出带品味的判断。」
现在这个频道里有一个 Asana 应用，把每个问题转成任务，交给一个 Agent 接手。大多数人介绍这个案例时，讲的是它答得多好。我读了 Claude 官方博客这篇访谈（2026-09-29，「构建人机协作团队」系列第三篇），读出来的是另一件事：这个 Agent 最值钱的设计，是它答不上来的时候会发生什么。
它有两种「答不上来」，每一种都有一个出口：没有获批口径、且问题暴露了产品缺口，它会在产品团队的受理项目里建一条任务，进 backlog；同一个问题反复出现、它反复贴同一条记录，它会建一条任务，让赋能团队去更新培训材料和文档。失败不蒸发，不硬答，全部变成结构化的组织信号。
这一刻，Agent 从一个应答机器，变成了一个组织缺口探测器。
三个案例，其实是三级深度
这篇访谈里 Asana 一共讲了三个 Agent 案例。表面上是三个功能点，但我把它们排在一起看，看到的是 Agent 进入工作流程的三级深度——每一级，Agent 碰的东西更贵一层：
深度 案例 Agent 碰到的东西 失败治理机制
─────────────────────────────────────────────────────────────────────────
应答面 Slack 频道答产品问题 一线员工的提问 答不上来 → 建任务
（浅，高频，低风险） （组织知识的路由） 缺口被结构化吸收
决策面 At-Risk Renewal 晨报 高管的注意力 报告不准 → 被教练
（中，每日，直接进决策） （管理判断的合成） 每跑一次就更好一次
生产面 Command 工程周期管理 组织的产能 排期偏了 → 人定取舍
（深，人机混合调度） （生产计划本身） Agent 提单，人拍板
# generated by hugo AI
三级深度对应三种失败：答不上来、报告不准、排期偏了。每一级能不能站住，关键都不是 Agent 的能力上限，而是它的失败如何被吸收。
先回应一个显而易见的反驳：把活干好才是入场券，上来就谈失败是不是太早？不是。能力决定它能不能进场，但「答不上来」是常态而非例外——知识在变、缺口常在、需求永远会超出预设口径。能力再强也消不掉失败，真正决定它能在这个岗位上待多久的，是失败发生之后去了哪里。一级一级看。
第一级：应答面——把「答不上来」产品化
回到开头的 Slack 问答。这个案例有三个细节值得放慢看。
第一，入口没有变。这些问题仍然发在 Slack——因为那是一线人员最顺手的提问场所。没有新 App、新入口、新习惯，Agent 嫁接到人已经在的地方。这一点和我在 钉钉数字员工架构与落地实践 里的判断完全一致：能被 @ 到的那一刻，模型能力才真正进入组织的协作面；没有这个入口，模型再强也只是挂在组织外面的一个 API。
第二，可信沉默。有获批口径，Agent 才作答，而且附上来源链接；没有获批口径，它不猜、不编，走建任务的出口。它被设计成宁可不答，不可错答——因为应答面 Agent 的信用是一次性的：错上几次，一线员工就回去 @ 专家了，这个 Agent 等于白建。
第三，也是最值钱的：失败路径全部被组织原生对象吸收。产品缺口进受理项目的 backlog，培训缺口进赋能团队的任务队列。注意这两条出口的去向——不是「记录日志供管理员查看」，而是直接变成另一个团队工作流里的任务。Agent 答不上来的每一个问题，都在替组织做缺口扫描：哪块知识没沉淀、哪块培训没跟上、哪个产品能力被反复追问。这些问题以前也天天在频道里出现，只是被专家一次次口头回答后就蒸发了。
我在 Team Bots 最贵的不是 Bot，是那份两年的技能库 里说过，技能库的原料是真实使用中的更正流。Asana 这个案例是同一件事的另一面：「答不上来」是最诚实的更正流——它标记的不是 Agent 错了，而是组织的知识 map 上哪里有洞。
第二级：决策面——管理注意力是最贵的客户
第二个案例：At-Risk Renewal。Asana 的首席客户官 Josh Abdulla 过去每周要为高管团队做一份「风险续约简报」，输入是几千个客户里 CSM 们标记的风险续约和状态更新。更新量太大，没有专人综合就保不住时效，Arnab 的描述很扎心：「Josh 是在领导们告诉他时才知道问题，而不是数据最初显现时。」
现在一个 Agent 每天读全球客户组合里每一个风险续约任务——CSM 的更新、状态备注、评论——生成三桶结构的每日摘要：正向势头、负向势头、建议跟进。先跑全局，再按区域切分，每天早上自动推送给首席客户官、首席营收官和各区域负责人。
这个案例的表面卖点是「自动化报告」，真正的卖点是 Arnab 自己点破的那句反问：
「他们大概可以让 Claude 各自给自己生成一份报告。但怎样才能做到报告标准化、有共享工作区，并且每跑一次就更好一次？」
三个判据，每一个都在打「个人用 AI」和「组织用 AI」的分界线：标准化产出、共享工作区、可教练复利。这正是我在 AI 让每个人都变快了，为什么公司没有变快 里写的问题的产品化答案——个人生产力在涨，流程还是人传人，单点提效换不来整体提效。每人一份的 AI 报告，就是单点提效的标准形态。
「每跑一次就更好一次」的机制也藏在共享工作区里：摘要落在所有人都看得见的地方，领导可以追问——某个客户的流失预测背后，先行指标是什么？——并且教练 Agent 记住要点，供下次运行参考。在 数万名员工，是一块活的评测集 里我说过，活评测集的 case 来源要活、主人要钉死。这个晨报就是活评测集的微型版：CCO 的每一次追问都是活 case，教练动作就是标注，而且主人明确——客户体验团队构建它，首席客户官每天消费它。
还有一个容易被忽略的设计：Agent 的输入是 CSM 本来就在做的 任务更新。没有要求任何人为这个晨报新增一份输入。决策面 Agent 想活下来，必须吃组织已有的数据流，而不是逼人喂它——多一道录入，就少一半真相。
第三级：生产面——代码生成不再是瓶颈之后
第三个案例最深。Asana 在自己的产品上跑自动化编码循环——从各渠道收集客户反馈、综合归纳、触发编码 Agent 把反馈变成 PR。这种循环在软件公司已经很常见，但 Asana 遇到了新问题：周期时长和发布节奏开始滑坡，循环被自动生成的变更撑得臃肿。
Arnab 的判断值得每个管理者抄下来：「代码生成已不再是瓶颈，瓶颈在规划、决策和打磨。」
执行端被 Agent 加速之后，管理动作成为新瓶颈。Asana 的解法是把管理本身做成一个人机都可读写的界面（他们的工程组织跑在 Command by Asana 上）：Agent 从客户反馈和团队 Slack 反馈频道提取工单，填入「未规划看板」；由人决定哪些工单进入迭代周期；Command 用乐观、均衡、保守三档估计预测周期完成时间；一张工单可以指派给人，也可以指派给编码 Agent；周期数据全部集中在一处，经理直接在聊天里问「为什么这次发布偏离轨道、做什么取舍能拉回来」。
注意这个分工的形状：Agent 提单、估点、归因、答取舍选项，但「哪些进迭代」这个取舍权留给人。这和我在 钉钉数字员工架构与落地实践 里处理「AI 筛简历」案例时是同一条原则——AI 减负，人做评估，结果的把关必须留在人手里。区别只在深度：简历案例里人把的是单次结果的关，Command 里人把的是产能分配的关。Agent 进入生产面，不是替人做计划，是让计划本身变成人机共同读写的数据。
托住三级的四个机制
三级深度不是三个孤立功能，底下垫着四个通用机制。这部分是全文最值得抄作业的地方。
一、不为 AI 另起上下文结构。 Asana 多年前就构建了 Work Graph——把每个任务、项目、目标和对话映射成一张关系网，有负责人、参与者、依赖关系。开始做 Agent 时，他们决定不为 AI 另建一套上下文，让 Agent 直接在这同一个模型里运作。Agent 没有自己的世界，它就活在组织已有的工作结构里——所以它的产出天然落在任务里、能被指派、能被追踪。
二、角色先行。 每个 Agent 围绕角色构建（内容写手、洞察分析师、项目经理、工作受理专员……），并且有一个档案页：名称与用途、可使用它的人员、管理员、指令、技能、集成、权限。官方给的操作建议，是像给新员工写第一个季度的入职计划一样，写下 Agent 的用途、指令，以及它具体负责哪些工作。这就是 别配置 Agent 了，给它一个岗位 的现成产品形态——岗位说明书不是比喻，是一个字段齐全的档案页。
三、使用和训练分离，学习要签字。 这是四个机制里最精细的一个。任何人对任何任务都可以给 Agent 反馈，但反馈只作用于当前任务；只有管理员和编辑能把反馈写入永久记忆，也只有他们能撤销或删除。谁有资格当管理员？原则是「谁拥有 Agent 所执行的标准（如品牌语调、规划惯例），谁就拥有（或管理）这个 Agent」——Asana 的传播团队掌握公司语音语调的笔杆子，所以写作类 Agent 归他们管；Arnab 作为 CPO 可以用它起草内容，但不能修改它的行为。
在 评测集是一份没人签字的文件 里我立过一个判据：没有签字人的评测集不是资产。Asana 把这条判据做进了权限模型——连「学习」这个动作本身都有签字人。而且它还顺手解决了规模化问题：「团队里有一两个人成为专家，把它配置正确，其他所有人从此都能享受同样的收益。」
四、工作留在看得见的地方。 Agent 接手任务时，把研究计划和执行步骤发布在共享任务里，所有有权限的人能阅读、评论、引导。Arnab 点破了一对一用 AI 的组织成本：「如果你 AI 素养很高，一对一的 AI Agent 也许能给你质量很好的回复。但那样的话，其他审阅内容的人不知道 prompt 是什么、来回了哪些轮次。如果他们不认同你提供的某些引导，就根本无从对齐。」共享任务上，请求、质疑和产出都在同一个地方——审阅产出的人，也能修订产生它的指令。审 AI 的活，不能只审结果，要能审到过程。
一条裂缝：谁触发，谁封顶？
四个机制之外，Asana 还有一条安全设计：「Agent 的有效访问权限以触发它的人的权限为上限」——防止任何人借 Agent 套取它在私有上下文学到的信息。
这条设计在应答面没问题：有人在 Slack 里问，Agent 用提问者的权限视野作答。但把它放到第二个案例上，裂缝就出来了——At-Risk Renewal 晨报是 每天早上自动推送 的。早上七点，没有人触发它。它读全球客户组合里所有风险续约任务的时候，用的是谁的权限？
访谈里没有回答。这不是挑刺，这是我在 权限跟着人走，还是跟着工号走 里论证过的那条结构性裂缝：凡是定时的、被动的、无人值守的 Agent 任务，权限只能来自组织授予，不可能来自触发者。「触发者封顶」是 personal 权限模型的护栏，而 7×24 的晨报天然要求 shared 权限模型——Agent 以组织成员的身份持有岗位权限。Asana 被自己最好的案例推向了后一种模型，尽管叙事还挂在前一种上。
有意思的是，这个裂缝反过来验证了三级深度的排序：应答面可以容忍 personal 权限（有人问才动），决策面开始就必须 shared（定时运行），生产面更是如此（Agent 是排期里的常驻产能）。进入工作流程越深，Agent 越不可能靠「借用某个人的权限」活着。
方向：把失败治理当地基，一层一层进
把三个案例、四个机制、一条裂缝合起来，Agent 进入工作流程的路径就清楚了——它不是能力问题，是治理梯度问题：
- 应答面先行：入口嫁接在人已在的地方（群、文档、审批流），Agent 只在有获批口径时作答，答不上来就按缺口类型生成任务给对应 owner。这一层风险最低、频次最高，而且是组织缺口扫描器。
- 决策面跟进：把组织已有的工作数据合成管理者每天必看的摘要，落在共享空间可追问、可教练，反馈分级写入永久记忆。这一层天然无人值守，权限必须组织授予。
- 生产面收口：当执行端被 Agent 加速、管理成为新瓶颈时，把计划与调度做成人机共同读写的数据面——Agent 提单、估点、归因，人保留取舍权。
每一级往上走，Agent 碰的东西更贵（提问→注意力→产能），失败的代价更大，所以失败治理也要更重（建任务→签字写入→人拍板）。反过来说也成立：一个组织的 Agent 能进多深，看它对失败的吸收能力有多强。
Arnab 在访谈结尾说了三句话：一份人与 Agent 共同使用的共享上下文；每个 Agent 有独立身份，贡献和访问可被审计；Agent 所学沉淀为持久记录，让团队的知识不断复利，而不是蒸发消散。这三句话拿来当 checklist，任何一家想做数字员工的团队都能对着自查。
我只想补第四句，也是这篇文章的全部主张：每一条 Agent 答不上来的问题，都应该有一个去处。 下次你评估一个数字员工产品，别只问它答得多好——问它答不上来的时候，那条信息去了哪里。答案蒸发在聊天记录里的，是玩具；答案变成组织任务的，才是员工。
你的数字员工答不上来的时候，会发生什么？欢迎留言讨论。
事实核对自：Claude 官方博客 Agents you can coach: how Asana builds human-agent teams with Claude（2026-09-29，对 Asana 首席产品官 Arnab Bose 的访谈，「构建人机协作团队」系列第三篇）。三个案例的细节、引语、「触发者权限封顶」机制均为厂商口径，Asana 内部实际运行效果未经独立核实；「每天早上自动推送」与「触发者封顶」的矛盾是本文基于公开描述的推断，访谈未正面回答无人值守场景的权限来源。