通用 Agent 进了企业，Data Agent 还要不要单独买？

今年春节前后，OpenClaw 爆火，我们围绕 OpenClaw 做了两次实验。

第一次，我们把 Aloudata CAN 语义平台接给 OpenClaw，再装上问数和归因两个 Skill，它就能查询企业数据，也能围绕一个业务异常继续往下分析。（给一个微信公众号的文章链接）第二次，我们又增加了异常检测、预测模拟、报告编排和定时执行等 Skills，让它看起来更像一名高阶分析师（给一个微信公众号的文章链接）。

既然 OpenClaw、WorkBuddy 这样的通用 Agent 已经能够通过接入语义引擎和安装分析 Skills 的方式，就能像模像样地进行数据分析，那么 Aloudata 为什么还要做自己的 Data Agent？

既然企业希望员工未来可能只面对一个统一的 Agent 入口，那还会有必要单独采购 Data Agent 吗？

相信不少同行和客户都已经遇到这个问题，以下是我对这个问题的思考。

会分析，不等于数字分析师能上岗

我先用一个员工求职上岗的过程来比喻说明。

员工求职上岗，需要经历简历评估、面试评估、试用期考核、转正后绩效考评、扩大岗位职责等过程。

简历评估主要考察背景、经历是否匹配，比如会不会使用 SQL、Python，掌握了哪些分析方法。对应到 Data Agent，就是会不会操作工具和具备哪些分析 Skills。

接下来是面试。给候选人一道分析题，看他怎么思考，能不能做出来。我们之前在 OpenClaw 中接上 Aloudata CAN 和 Skills 后完成问数、归因和报告，很像一次表现不错的面试，感觉候选人无所不知、无所不能。

但真正的考验发生在试用期：面对用户提出的没有说清楚的业务问题，Agent 会不会先反问；拿到一个数据时，会不会核验口径和数值；得出分析结论时，能不能完整呈现分析过程和分析依据；被纠正一次以后，同样的错误还会不会再次发生；……

所以，从“会分析”到“能够作为分析师上岗”，中间隔着“造工具”，还是“造人”的区别。

前两次 OpenClaw 实验证明的只是 Agent “会分析”，而企业采购 Data Agent，要求的是“能上岗”。

现实中，有太多的候选人是会面试，而不会干活。

所以，一个好的 Data Agent，应该像一个优秀的数据分析师一样：靠谱，越干越好。

员工靠谱，试用期才能转正，Data Agent 也一样

数据分析师要靠谱，前提是给的数据不能出错，客户采购 Data Agent 时，经常会提出一个听起来很苛刻的要求：数据必须 100% 准确。

这个要求是既合理，也不合理。合理的是数据准确是分析决策的前提，需要数据 100%准确，不合理的是现实中的数据分析师因为各种原因，也做不到数据 100%准确。

我对这个要求的看法是：数据 100% 准确是结果，分析过程 100% 可信是手段，只有分析过程 100%可信，才能保障数据 100%准确。

Data Agent 要实现分析过程 100%可信（Trusted），要体现在方方面面：

• 会做需求澄清，问题没有说清楚，就先通过强制反问补齐取数逻辑，比如：对比今年 6 月和 7 月的会员等级变化？这需要 Agent 能够理解会员等级变化是需要取时点值进行比对，那么 6 月和 7 月有可能是时点值，也有可能不是时点值，要看会员等级背后的更新逻辑是日更，还是月更，如果是日更，就要进行反问，到底是取哪一天的值进行比对；

• 会拒绝心算，好的分析师会跟财务人员一样，保持着拒绝心算的工作习惯，哪怕是 100+100 这种操作，也会在计算器上按出来，而不是自己心算。而大模型有时候遇到简单计算，会自己“心算”，从而常常导致数据不对。

• 会强制数据校验，对于数据和分析结论，需要有一套校验和评估机制，就像数据分析报告会有组内评审一样。

• 结果可验证，会保留完整的数据分析过程，通过提供角标、引用等功能，支持用户可以追踪每一个数据和每一条分析结论的运算过程和数据血缘，从 Agent 的动态 Python 计算，到语义引擎的查询接口，一直到下发数据库的查询 SQL，端到端可溯。

• ……

可以发现，上述对 Data Agent 的行为要求如果要 100%能执行，就不仅仅是在 Skill 这层修改 Prompt 可以实现，很多约束是要进入 Agent 的 Harness 工程里，比如 Context 上下文压缩时不能对数据链相关的内容进行压缩，否则会丢失数据分析关键步骤信息。

因此，脱离 Data Agent 的一体化设计，只是将 Skill 挂载到通用 Agent 里，交接的只是分析经验，而不是岗位责任。这也是我们不支持单独售卖 Skill 的核心原因：无法对任务完成率负责。

员工越干越好，其实是最低要求，Data Agent 也一样

企业招聘员工，要为员工创造上岗条件，比如指定导师（mentor），制订学习计划，然后员工就会先从简单任务开始逐步开展工作，然后越干越懂，越干越熟，越干越好。

真实情况下，企业并不会提前为新员工预置一份完全匹配岗位职责的工作手册，里面写清楚所有的工具、操作方法、标准流程、以及相应的业务知识和判断逻辑等，新员工只要照本宣科、依葫芦画瓢地开展工作就行。

实际情况是，新员工会与导师、领导、同事一起在工作中彼此磨合，逐步建立适合这家企业、这个部门、这个团队的工作技能和工作经验，成为团队中的一员。

学习能力是企业考评员工工作能力的一个关键项，而总结和自省是员工自我提升的关键动作。

同样的情形落到 Data Agent 也一样，企业无法为 Data Agent 上岗提前预置一份完整无误、持续保鲜的数据语义库和业务知识库，这需要 Data Agent 在实际工作中，通过每一次的任务互动获取知识，更新技能，比如如何将反问中获取到的业务知识、习惯用语、用户偏好等更新到 Agent 知识库、记忆里。

这就要求 Data Agent 需要建立一套自迭代、自进化的机制和系统能力，也就是递归自学习（RSI），其中高质量的评测任务是实现 RSI 的关键。这也是“造工具”与“造人”的主要区别。

任务评测就是数字分析师的绩效体系，一个好的 Data Agent 厂商一定会有自己的评测任务集，就像大模型厂商发布模型时，需要通过打榜 SWE-bench 评测 Coding 能力一样，需要有一个基准测试。

随着 Data Agent 任务执行的日志采集的越多，相应的 Harness 优化越做越深，最终这种 Data Agent 的进化，无论从通用 Agent 与专业 Data Agent 厂商在关注度的排序差异性上，还是从工程实践的细节实现上，都注定一体化的 Data Agent 在任务完成率、任务覆盖率和任务执行成本上会比通用 Agent + Skills 的方案要好。

产品独立与入口统一，是两件事，并不冲突

独立的 Data Agent，不一定意味着企业员工必须再打开一个聊天窗口。

未来企业完全可以只有一个统一的员工入口。通用 Agent 负责识别员工要完成什么工作，遇到数据任务时，再调用或跳转专业 Data Agent。员工在前台看到的是一个入口，后台承担任务的却是不同的专业 Agent。

但统一入口不等于把 Data Agent 拆成几个 Skills。前者统一的是用户体验，后者拆散的是产品责任。

所以，回到文章标题的问题：通用 Agent 进了企业，Data Agent 还要不要单独买？

如果企业希望自研 Data Agent ，可以采购 Aloudata CAN 企业级语义平台作为自研 Data Agent 的语义引擎；如果企业希望得到的是一名能够稳定地、准确地完成数据任务，并且越干越好的数字分析师，那么需要采购 Aloudata Data Agent。

无论是自研还是外采 Data Agent，都与员工办公入口不冲突，而如果是希望通过通用 Agent + Skills 的方式来实现 Data Agent，前期可以尝试，但长期的天花板并不高。

以上是我对“通用 Agent 进了企业，Data Agent 还要不要单独买”的思考：用户入口可以统一，产品责任不能被拆散，欢迎大家在评论区讨论。