企业有了 AI 助手,为什么工作还在人手里?

AI 参与分析，工作仍由人推进

“最近这个指标怎么掉了？按区域和品类拆一下，再看看接下来怎么调。”

这句话来自我们经历过的一次实际任务。单看它，AI 已能写 SQL、跑表格、总结数据。但实际用起来，人得先翻群聊确认指标、找文档核对规则，再问数据同学查哪张表、申请权限；之后把结果整理成 AI 能懂的输入，拿到分析再逐项核对；核对完也只完成一半，还要写文档、沟通、跟踪。

企业里 AI 助手不少，但工作常被切成很多段——消息、规则、数据、权限和 AI 各自分散，人得在系统间来回搬运上下文。先把群聊、文档和数据整理成 Agent 能执行的任务，再把结论推成文档、资源和任务。这恰恰是很多 AI 项目容易忽略的地方：我们习惯用准确率和工具数判断 AI 好不好，可这些衡量的是“能不能解决一个问题”，而非“能不能推进一项工作”。两者的边界，并不相同。

阿里云 AI 原生数据库服务（AIDBS）想回答的，正是后者。它让 Agent 真正读懂企业数据，也让 Agent 在身份、权限和审计的边界内安全地使用数据——前者靠 Meta Agent 维护企业的语义知识，后者靠 Agent 数据网关管住访问，再配合协作工具负责消息与任务流转，Agent 才可能把一项工作完整推进。

解决问题 ≠ 推进工作

一次对话通常从问题开始，以答案结束，但一项工作则有更长的生命周期：

中间任何一项需要人重新整理，工作就会退回人工衔接。Agent 能读群消息，却不知道这句话算不算一项任务；能生成 SQL，却不懂企业内部的指标口径；即使找到了数据，也未必有与任务匹配的身份和权限；等到建议生成后，还要判断该发给谁、哪些能发、哪些必须由人确认。

模型已经能完成分析，缺的是一套让工作继续运行的机制。AIDBS 所代表的企业 AI Native，是把工作的上下文、数据、权限和协作重新组织到同一项任务里：Agent 依据已确认的结论继续执行，业务判断、授权和责任仍由人承担。任务从哪里开始，决定了谁还要继续搬运工作现场。

让 Agent 直接进入工作现场

企业里很多工作，最初并不是结构化任务，而是一条群消息：背景留在前面的讨论里，资料散在文档和历史消息中，后续沟通也要回到钉钉。

既然钉钉已是工作发生的第一现场，我们让 Agent 从群消息开始。这和加一个群机器人、或新增一名“数字员工”都不同：机器人是新的沟通节点，数字员工是新的执行主体。我们把第三种形态称为“数字替身”：Agent 读取本人的工作上下文、在授权范围内代为执行，最终的表达、承诺和责任仍归本人。

围绕这种方式，我们开发了 cc-stand 并把它开源：一个连接钉钉、飞书与 Agent 的协作工具。在这次任务里，cc-stand 按预设策略读取群消息、引用和上下文，判断这是普通讨论还是要继续处理的任务；确认后把相关信息整理成 Agent 可执行的输入，并记录四件事：谁提问、需要什么资料、结果发到哪里、由谁确认。任务识别和上下文筛选，不再只存在经办人脑子里。

Agent 读完消息，会确认指标定义、查询数据、拆解变化、判断原因，再依据现有规则形成调整建议。

先懂企业怎么用数据

数据库里的表名、字段名，和一句自然语言之间并不存在天然对应。同一个“成交”，可能按下单、支付或完成计算；同一个“区域”，可能按用户位置、商家归属或组织分区划分；看似清楚的“最近”，也可能是自然日、业务日或某个活动周期。把这些直接丢给大模型，Agent 很容易得到一段逻辑完整、业务上却用不了的分析——它未必算错，只是从第一步就理解错了问题。

AIDBS 用 Meta Agent 解决这个问题。Meta Agent是面向数据资产管理的智能体，从表结构、字段说明、历史 SQL、业务文档和样本数据中提取数据知识，并持续维护 DataWiki，记录业务术语、指标算法、字段对应关系、数据关联方式，以及定义适用的时间和规则版本。业务 Agent 在分析前先查询这些知识，再把自然语言问题映射成可执行的数据对象。

回到这次任务，Agent 先对齐了指标定义、统计周期、区域与品类的关系和需要排除的异常情况，才开始生成查询和分析步骤。这里有一条重要边界：DataWiki 不替业务人员创造口径。已确认的知识直接引用；遇到缺失或冲突，由人确认后补进 DataWiki，并保留来源和适用范围，Agent 不该每次分析都把企业口径重新猜一遍。

但理解正确，只解决了“它知不知道”的问题。接下来还要回答：它能不能使用这些数据？

懂数据 ≠ 能用数据

在人工流程里，数据权限常以申请、导出、转交的方式存在：业务人员提问，数据同学确认范围，再把结果交回。当 Agent 开始直接使用企业数据，这种人工转交很难再承担全部控制。

AIDBS 的 Agent 数据网关（Agent Data Gateway）统一处理 Agent 的数据查询。Agent 不再借公共账号查全部数据，而有自己的身份，实际访问范围同时受 Agent 权限、发起人权限和任务范围三重约束：任一范围不满足，系统都不会放开。于是同一句业务问题，不论交给哪个 Agent 都对应同一套指标口径；换一个发起人，能看到的数据范围可能不同。

数据网关还负责脱敏、审批和审计：只需区域汇总时 Agent 没必要读更细的敏感字段；下钻超出当前权限时系统暂停并进入授权；任务完成后谁以什么身份访问了哪些数据、做了哪些操作，都能追溯。这些不直接产出结论，却决定 Agent 能否在企业里长期稳定地用数据，而不是一次次依赖人工导出和临时判断。

数据语义和访问边界确定后，Agent 才完成后续查询、维度拆解和原因分析，并生成一版带有证据和待确认项的调整方案。答案已经有了，但工作仍然没有结束。

分析完成只是工作的一半

我们先确认分析结论、调整方向、要沟通的对象，以及 Agent 可继续执行的范围。确认后，Agent 把分析过程、指标口径、主要证据和调整建议写入钉钉文档，cc-stand 再按角色分发：提问的人看结论和证据，区域或品类负责人关心自己范围内的变化，上下游团队要知道为什么申请资源、需要配合什么。Agent 据此发起资源申请、补齐材料并持续跟踪；新反馈出现后连同原有分析、文档和未完成事项放回当前任务，继续判断下一步。

但这里的自动化并非无限授权：已确认的沟通对象、信息范围和任务动作可以自动执行；一旦涉及新增预算、资源优先级变化、新的协作对象，或要对其他团队作出新承诺，系统就停下来请人确认。判断自动化的边界，不能只看 Agent 会不会做，还要看这一步的责任能不能转移。

工作要继续，系统必答五问

回看这次任务，系统必须回答五个具体问题。