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 会不会做，还要看这一步的责任能不能转移。
工作要继续，系统必答五问
回看这次任务，系统必须回答五个具体问题。
边界 |
这项工作需要回答的问题 |
工作周期（session） |
一项工作到分析完成就结束，还是要持续到文档、资源和任务有了明确结果？ |
上下文与记忆（memory） |
群聊、指标口径、分析证据、沟通记录和未完成事项保存在哪里，什么时候更新或失效？ |
身份与权限（permission） |
Agent 以什么身份使用数据，发起人权限和任务范围如何共同限制访问？ |
消息流转（message I/O） |
谁读取消息、触发执行、发送结果；哪些内容只能保存为草稿，哪些可以按策略正式发送？ |
责任归属（responsibility） |
谁确认业务结论、预算、优先级和承诺，系统在哪些位置必须暂停？ |
这五个问题，共同决定 Agent 能把工作推进到哪里、又该在哪里停下。它们并不限于数据分析：产品经理整理需求、销售准备跟进材料、财务解释指标波动、研发从一条报错进入排查——岗位会变，工作对象会变，但数据、权限、协作和责任始终都在。
工作向前，责任留人
再回到开头那个问题：企业有了 AI 助手，为什么工作还在人手里？因为模型虽然能分析，工作却仍要人来推进，每一段衔接都靠人。企业 AI Native 要减少的正是这些重复动作：确认后的查询、整理、发送和跟踪交给 Agent，业务判断、预算、优先级、承诺和最终责任仍由人承担。
在这里，协作层让消息和上下文进入 Agent、让确认后的结果回到文档与人员，AIDBS 则让 Agent 读懂企业数据，并在身份、权限、脱敏和审计的边界内安全使用数据。AI 助手证明了模型能回答问题，而当 Agent 能在明确的边界内把工作继续做下去，企业使用 AI 的方式才真正开始改变。
免费试用：Agent数据网关在公测期间，每个用户可享1个实例14天免费试用
立即体验：内置体验数据源，开箱即用 https://aidbs.console.aliyun.com/agent-gateway
了解产品详情：https://help.aliyun.com/zh/document_detail/3041356.html
加入钉群了解更多咨询：钉钉群号： 164015027096
