Asana 的销售和客户成功人员有一个共享 Slack 频道，专门问产品问题。新功能不断发布，同样的问题被反复提出，每次都要 @ 一位领域专家。他们想过建可搜索的知识库，结论是不可行——用他们首席产品官 Arnab Bose 的原话说：「答案很微妙、而且会变化，你需要有人对『产品当前状态』做出带品味的判断。」
现在这个频道里有一个 Asana 应用，把每个问题转成任务，交给一个 Agent 接手。大多数人介绍这个案例时，讲的是它答得多好。我读了 Claude 官方博客这篇访谈（2026-09-29，「构建人机协作团队」系列第三篇），读出来的是另一件事：这个 Agent 最值钱的设计，是它答不上来的时候会发生什么。
它有两种「答不上来」，每一种都有一个出口：没有获批口径、且问题暴露了产品缺口，它会在产品团队的受理项目里建一条任务，进 backlog；同一个问题反复出现、它反复贴同一条记录，它会建一条任务，让赋能团队去更新培训材料和文档。失败不蒸发，不硬答，全部变成结构化的组织信号。
这一刻，Agent 从一个应答机器，变成了一个组织缺口探测器。
上个月一个 CIO 给我看他们的 AI 成果清单，讲得很顺：接入了多少个 Agent、开了多少智能体账号、买了多少 token、做了几场全员培训。我听完问了他一句：「你们每天真实发生的业务里，有多大比例是 Agent 参与完成的？」
他停住了。停了几秒，说：「这个我们没统计过。」
这不是个例。绝大多数企业的 AI 成绩单，记的都是投入项——买了多少、接了多少、开了多少。而真正决定 AI 能不能产生业务价值的那个数字，没人算过。
通用 Agent 之后，企业要解决的，不是再做一个更聪明的 Chat，而是把 AI 真正嵌进每天发生的协同工作流。
过去企业数字化的路径大致是：
业务流程 → 表单 / 审批系统 → 人来操作系统
# generated by hugo AI
AI 时代正在变成：
业务目标 → Agent 理解与执行 → 人做判断与审核
# generated by hugo AI
所以引入通用 Agent 只是第一步。真正的问题是：你的企业有没有一个能让 Agent 进入、理解、执行、反馈、持续优化的工作流载体。 没有载体，Agent 再聪明也只是停在对话框里。
给 AI Agent 排定时任务，正在变成一件新的麻烦事。
最早我们写 cron，后来写脚本，再后来各种 Agent 框架自带调度器。结果是：定时配置散落在 crontab、launchd、代码常量、框架配置文件里，改一个执行时间要翻好几个地方；想知道「现在到底有哪些任务在跑、几点跑、跑完发到哪」，没有任何一个地方能一眼看全。
任务本身其实很简单——「每天下午一点，去小红书搜几个关键词，各出一份报告」。难的不是执行，而是管理：谁来记、谁来改、谁来排查。
上个月，我去一个客户的运营部门看他们的周报流程。
过去的方式：周五下午，运营主管花两小时从三个系统里扒数据，手动填 Excel，写总结，发邮件给 VP。每周一早上开会讨论。
现在的方式：周一早上 8 点，数字员工「数据周报 Agent」自动从三个系统拉数据，生成周报，发到运营群里。主管花 10 分钟审核、批注，回复两个字：「OK」。
这看起来只是效率提升——从两小时变成 10 分钟。但仔细看，主语变了。
过去的周报流程，主语是 人：人去扒数据、人去写报告、人去发邮件。AI 最多是个辅助工具。
现在的周报流程，主语是 Agent：Agent 去拉数据、Agent 去生成报告、Agent 去发送。人变成了审核者和决策者。
这不是工具升级。这是工作流范式的迁移。
周一早上九点，小林到了客户的运营部。
他不是来做产品演示的，也不是来签合同的。他的工牌上写的是「Forward Deployed Engineer」——一个在钉钉内部新设立的岗位，外部还没有对应的职称。
上周客户提了一个需求：「每天有 20 个人整理会议纪要，能不能用 AI 提效？」
普通工程师听到这句话，想到的是做一个会议纪要工具。
小林想到的是：
会议
↓
纪要
↓
任务拆解
↓
责任人
↓
审批
↓
提醒
↓
知识沉淀
他要做的不是一个纪要工具，而是一个 会议 Agent。
上周，一个做 HR 的朋友给我发了张截图——某 SaaS 产品的面试评估表界面，问我：「这个东西，你们悟空能做吗？」
我没回答能不能做。我问她：「你手上有没有一个你已经在用的、类似的东西？哪怕是 Excel。」
她说有，一个用了两年的 Excel 模板，里面有公式、有下拉选项、有自动算分。
我说：「把它给我。」
拿到之后我想：如果我对悟空说一句 /goal 复制这个 Excel 模板的功能，生成一个钉钉 AI 表格工作流，面试评估表自动算分，结果推送到群聊——悟空能不能跑通？
技术上完全可以。dws CLI 有 AI 表格的建表、写数据命令，有审批流的提交命令，有群消息的发送命令。数据统一存在钉钉平台上，悟空通过 CLI 就能访问。整个路径是通的。
问题不在技术。 问题在于：当每个 HR、每个运营、每个项目经理都看到「我也想要一个那样的东西」，这种需求的总量是无限的。谁来供给？
[Read More]上周和一个做制造业的朋友吃饭。他的工厂有一条产线质检流程，沉淀了八年的 SOP，写在 47 页 Word 文档里，涵盖了从来料抽检到成品出货的 23 个检查节点。
他说：「这套流程是我们最值钱的资产之一。但执行全靠人——培训一个质检员要三个月，离职率 30%，新人上来又得重新学。」
我问他：「你想过把这套 SOP 变成 AI 驱动的工作流吗？」
他愣了一下：「谁来帮我做这个？我手下的 IT 团队连 ERP 都维护不过来。」
这就是当下最大的供需错配： 企业最有价值的资产是沉淀多年的 SOP，但没有人把它变成可执行的数字员工。
[Read More]周三晚上 9 点，供应链主管小林在钉钉里收到一条告警：「供应商 A 本周交货延迟率从 3% 升至 12%」。他看了一眼，回了句「知道了，季节性波动，不用管」。这条消息随即被淹没在后续 200 条群聊里。
两个月后，另一个团队的采购经理在审批供应商 A 的新合同时，完全不知道这段历史。合同正常通过。三个月后，供应商 A 果然出了大问题——产能不足导致全线延迟。
这个故事里， 信息是存在的——告警推了，人判断了，反馈也有了。但信息在人与人之间断裂了。小林的处理经验没有被结构化地沉淀下来，后来的决策者无从获取。
这正是大多数企业 AI 落地时撞上的第一堵墙： 不是 AI 不够聪明，而是企业的「神经系统」还没建好。
