随着 Data Agent 逐步进入业务使用，最近在和几个客户讨论 Data Agent，能够明显感觉到，大家问的问题变了。
过去，客户最关心的是准确率。为了验证产品能力，客户会准备一批问题，让不同厂商回答，再看谁答得更准、过程更可信。这套方式很像招聘时的面试：先出几道题，看看候选人的基本能力，再决定要不要进入下一步。
现在，越来越多客户已经不满足于“面试”了，他们更直接地问：能不能先放到一个业务部门里试用一段时间？看看它是不是还像演示时那么好用？
从“面试”到“试用”，客户开始关心它能不能在真实环境中真正承担一个分析师岗位的工作。
Data Agent 的竞争，也因此开始从“面试”进入“试用”。
客户想试用，Agent 却还在等实施
Data Agent 系统上线之后，一个很现实的问题就会暴露出来： Data Agent 比一名新入职的分析师更慢开始工作。
企业招聘一名新的数据分析师，通常会给他开通账号和权限，告诉他负责哪个业务域，再给他一个数据仓库权限、几张常用报表，以及过去的需求和 SQL。如果条件好一些，还会安排一个主管或者导师，有问题可以随时问。
新分析师当然不可能第一天就理解业务，他需要先熟悉表结构、字段取值和表与表的关系，通过了解需求和 SQL 来熟悉指标口径。他一边学习，一边先接一些简单任务，比如复用一段历史 SQL 来查一个数、答疑一张报表的取值逻辑等。
换句话说，人不是学完了才开始工作，而是在工作中边干边学，完成上岗。
但企业引入 Data Agent 时，顺序往往反了过来。业务人员还没有真正开始试用，IT 和数据团队先要准备环境、开通权限、接入元数据、整理指标口径、补充语义、配置知识，再由厂商实施和调试。忙了三五个月以后，业务部门才终于可以打开产品，问第一道问题。
客户很容易产生一个朴素的判断：招一个分析师，过几天就能先做点简单的事；买一个 Data Agent，却要先做三五个月项目。既然如此，还是人更好用。
问题不在模型能力，也不完全在语义层做得好不好。更根本的问题是：我们把本来应该由 Agent 自己完成的上岗学习，搬到了 Agent 之外，变成了一项由 IT、数据团队和厂商共同完成的实施工作。
我们嘴上说交付的是“数字分析师”，实际交付方式却仍然像一个传统软件项目。
Agent 需要完成岗前准备
对传统软件来说，上线通常意味着系统已经部署完成，账号、权限、接口和页面都可以使用。至于用户能不能用好，往往留给后续培训和运营。
但 Data Agent 不一样。既然它承担的是一个岗位，就不能把“学会怎么工作”的责任全部留给使用者。产品上线，只代表它有了工位；真正上岗，还需要它知道自己负责什么、应该使用哪些数据、数据大致长什么样、常用表之间是什么关系、哪些指标和报表可以作为校准依据，以及哪些地方自己还不确定，需要在任务中边提问边校对。
这就是我们提出“30 分钟上岗”的原因。
在部门和岗位已经确定，元数据、数仓和报表访问已经配置的前提下，Data Agent 应该先给自己一段冷启动时间。它需要自主筛选核心数据资产，探查字段、取值和数据新鲜度，理解常用报表和历史查询，自主生成练习题，再通过真实执行结果、历史 SQL 或已有报表校准自己的理解。
这 30 分钟里，是 Agent 先主动熟悉岗位环境的时间；然后，才是它开始完成第一项正式任务的开始时间。
30 分钟不是一个科学测算出来的绝对时间，它更像是一条产品约束：要把原来按月进行的 Data Agent 上岗前的准备工作，尽可能沉淀为标准化的连接、数据探查和自主学习过程。
“30 分钟上岗”意味着不仅 Data Agent 需要具备主动熟悉环境的“冷启动”能力，还需要具备越干越好、自我进化的“热加载”能力。
让 Data Agent 也走一次“试用期”考评
我建议企业评估 Data Agent 时，可以少准备几道“面试题”，多设计一次真实试岗。
先给它一个明确岗位，开放必要的数据和工具，提供一名新分析师正常会拿到的历史需求、SQL、报表和分析文档，然后先看它能不能自主完成岗位冷启动。冷启动结束以后，再给它几项日常任务，看看它的“开工”表现。
这比准备几十道题，更接近企业真正“招聘”一个 Data Agent 时需要做出的判断。
10 月 23 日，我会在 DaCon 北京站公开演讲中，进一步讨论“30 分钟上岗”这个话题， 欢迎大家找我讨论。
当下， 随着客户从“面试 Data Agent ”走向“试用 Data Agent”，一个更现实的问题已经摆在面前：
Data Agent 系统上线之后，到底还要多久，才能真正开始工作？
