Data Copilot 是一个以 Chatbot Web UI 为界面入口的、用来做数据工作的 agent 产品。它正在成为一个以 AI data agent 为核心的数据平台。

我们是在 2025 年 11 月的一个 hackathon 上启动它的，当时我们想：既然 Codex/Claude Code 这么厉害，我们设计它工作的目录（workspace），然后据此做个产品怎么样？hackathon 的效果不错。到了 2026 年 3 月，我终于找到整块时间，大概花了两周到一个月，和另一位 partner 一起做出了初版。然后我们在公司 Slack 群里面说了一下，没有强制推动，没有大规模 marketing。

我们之前已经尝试过多次做 AI data 产品，均没有取得成功，因此这次并没有假设它会获得很快的 adoption——而且我们也不愿意强迫别人为了用而用，所以并未有多大的预期。直到有一天，我的合作者跟我说："好像有很多人在用我们的 Data Copilot 耶！"

我记得当时我们查看了一下后台，前一天大概有十几个用户，问了拢共几百个问题。我们就有点信心了。然后就在那几天，我们发现了产品的一个 bug，这个 bug 导致用户看到 response 的首字要等一两分钟，一个 response 完成大概都五到十分钟了。

可是我们看后台，那十几个用户还是在孜孜不倦地和它互动，每天几百个问题，平均每个人几十个。

那个时候我就知道这个产品行了。我跟我那位合作者说：我们终于看到了成功产品的样子，成功产品就是只要核心价值足够成立，用户会忍着不可想象的麻烦来用它。 因为如果是我用这个产品，慢成这样，我会砸了手机，发誓再也不给它任何机会。

那么问题就来了：这些用户手上都有 Codex 和 Claude Code，他们为什么还在用这个东西？

用户确实在自愿高强度使用，当他们有其他选择的时候

上个月的情况：

留存极高，没有衰减。 说明用户在持续高强度使用这个产品。

我们还做过一次小范围调研，25 个人回答，其中 60% 说如果 Data Copilot 消失会"非常失望"，88% 的人回答"非常失望"或者"有些失望"。

这个产品我们没有强制任何人使用，也没有做过高强度推广。并且在公司内部也一直是按照 free market 的原则发展的，就是说，我们从来没有尝试努力对它进行组织锁定（作为一个组织决策决定用它不用别的东西）。

我这么说不是为了追求虚幻的"公平"，而是因为：

第一，在这样一个变革的时代，我们通过组织决策来固定一个内部产品的"地位"是没有多少意义的，如果它不行，它会很快被淘汰；

第二，只有在相对 free market 的环境里面，我们才能得到真实的信号，指引产品的迭代。如果我们可以强迫用户用，我们只需要考虑怎么强迫用户就可以了——而这在企业软件里面有时候是存在的。

当然了，我个人也有一种价值观，就是我希望我造的东西，用户用的时候让他们的生活变得更容易，这样会积累福报，否则积累怨气。

同时，我也要对其他情况进行说明：

  1. 我们的用户一多半有 Codex/Claude Code，有很多用户本身就是混合使用的，Data Copilot 也提供了这些通用 agent 的集成能力（命令行和 MCP），所以用户是在通用 agent 和 Data Copilot 之间选择了我们的产品。
  2. 因成本控制的原因，我们后来要求用户 connect 他们自己的 Codex，我们使用他们的订阅来跑他们的请求。在这种情况下，使用量没有任何下降，因此用户用 Data Copilot 不是因为有免费的 token。
  3. 在使用命令行和 MCP 集成的用户中，大部分用户仍然同时使用 Web UI，并且，其通过命令行和 MCP 问的问题和通过 Web 问的没有本质差别，均以有相当复杂程度和业务意义的分析和工程任务为主，很少是简单的数据拉取。因此，用户不是仅仅因为 Data Copilot 有其他 agent 没有的集成能力而使用它的。

综上，Data Copilot 是在和通用 agent 的竞争中，被用户选择作为数据分析和数据工作入口进行高强度使用的 agent 产品。使用的原因可以排除简单的权限和 access 摩擦，即：不是因为没有 Codex/Claude Code，不是因为有免费 token，也不是简单因为 Data Copilot 有通用 agent 没有、不能集成的数据访问能力。

那么，用户为什么用 Data Copilot 呢？

因为 Data Copilot 就是那个做数据工作的产品

Manus 流行的时候，我听到一句话："这不就是 Claude Code 套壳吗？"在 Data Copilot 上面，也会有这种看法。Manus 和 Data Copilot 确实都是通用 agent 套壳，literally。但是，这是一种技术视角，一种实现视角，不是用户视角。

而用户视角是什么？是我在什么情况下想起这个名字，想起来的时候脑子里面浮现出来的画面是什么，我期待从它那得到什么东西，我对它的期待能不能得到满足。

对于 Manus 的用户来说，Manus 是不是 Claude Code 套壳，who cares？Manus 是那个：打开一个优雅的聊天输入框，我早上八点半到达办公室喝上咖啡跟它说，关于 $TSLA 给我生成一个汇报 report，这是我们的内部数据表格，这是之前的模板；然后过了半个小时，我回来一看，做了八九成，我又提示了几句它改掉了，我下午就拿着这个 report 去汇报了。Claude Code 能做到吗？也可以，也许要 5 倍的 effort。

同样的，Data Copilot 对于用户来说，不是什么 Codex 套壳，而是那个浅绿色网页上的输入框。我早上一醒来就问它，把那个 sales 的 report 发给我，我看看趋势，然后你就得到了 Metabase report 链接，下面是 inline 在 chat 里面的 table 和 chart；然后我说，你给我加个 filter，我要按照 channel 看，它就给你一个 channel breakdown。

所以什么是产品？产品就是承载某种认知形式及对应的功能期望的物理和数字装置。这正说明了什么不是产品——能力不是产品。而用户要的是产品，不是能力。

在上面 Data Copilot 的例子中，通用 agent 有所有这些能力，但它不是那个产品。

首先，它给用户的自我介绍就不是做数据的。我为什么要去一个名字里面带"Code"的东西里做"数据分析"？用户的脑子里面没办法把通用 agent 和做数据这件事自然地联系起来，这就造成第一步的摩擦。

其次，它的上下文不是为了做数据设计的。你问它要 sales report，它可能找来销售部门给你写的书面报告——你可能不喜欢，但这就是它被期待做的事情，按照定义，它就是要在一个广阔的工作空间里面，做最有可能满足你期待的事情。你让它看看销售趋势怎么样，它可能几句话告诉你最近势头不错，你一下子就火大了：你就不能把原始数据表格和图表给我显示出来吗？它立即道歉，对不起，我忘了你要销售趋势的时候要把表格和图表给你——事实上不是它忘了，而是作为通用 agent，它就应该那么做，除非你告诉它应该用别的方法做。而你告诉它这件事，就是在 ad-hoc 地发明产品。

再次，它的 UI 是为了通用上下文而设计的，不是为了数据上下文设计的。例如，在 Data Copilot 中，一个报表可能给你一个卡片，你点开可以看见数据，然后可以快速地回到 chat 里；而在通用 agent 里面，一个报表是一个链接，链接把你送到另一个软件、另一个上下文。这些都是产品错位导致的摩擦。

所以简单来说：做产品就是做产品。 产品就是要做到认知形式—品牌—功能的对齐，我管这个叫 Product-Cognition Fit。所有不对齐的地方都会产生摩擦：品牌认知摩擦，我得说服自己去一个叫 Code 的地方做数据分析；上下文摩擦，我让它给我找一个 report，它给我找的是一堆文档；UI 摩擦，我想要一个可交互图表，它返回的是 Python matplotlib 生成的静态 png。

所有这些摩擦，在技术上、在实现上都是可以理解的、可以解释的，但是从用户视角来说都是错误，而用户没有义务听我们解释，他们用脚投票。

那么我们要做什么呢？我们就是要做产品，要做到 Product-Cognition Fit：用名字承载一种已经存在的认知形式（数据工作），从广阔的通用上下文中切割出一个刚巧匹配数据分析的角度，然后在产品的每一个细节上，把它执行得符合用户的期待。当我们做得越过了阈值的时候，用户就会忍受着不可想象的不便来使用它。

我们到底做对了什么？

一个简单的产品愿景

我们到底做对了什么，使它成为了那个（the）人们会使用的 data agent 产品——在用户有 Claude Code 和 Codex 的时候？

首先，是一个不值一提的 vision：一个名字里面带着 Data 的 chatbot，用户想起来做数据工作就打开它，发送请求，拿到结果。为什么说不值一提呢？因为当我们说出来的时候，它没有任何令人惊讶的地方。而正是因为如此，它在最基本的形态上，就完全符合了用户的期待。

你可能认为，我做了一个内部产品，所以有一个重大优势是用户随时可以找到产品创造者解决问题——事实上，在过去的半年里，我们的用户极少找我，包括经常一天问几十个问题的超级用户。

这就说明，我们的产品形态没有任何用户需要学习的地方，他们就是会用。这当然不是智力的问题，也不是因为我们执行产品的能力世界顶尖，而是因为我们找到了对的事情，并且基本做对了。用户在使用一个产品的时候，他的头脑不是一片空白，他是带着某种产品想象来的，他的脑袋里面非常清楚：我干的这件事有多复杂，从而我在这个产品/工具上应该期待多大的复杂性。

我见过太多复杂的 BI 产品不工作，不是因为它们的功能不好——它们都做了很多在特定情况下"强大"的功能，但很遗憾，用户的期待不是这样的。在没有选择的时候，用户会妥协，而妥协的一个信号，就是使用这个产品变成一种技能。比方 Tableau，你可以在简历上看见有人写"精通 Tableau"。为什么是精通呢？因为它是一种技能。而当它是一种技能的时候，就说明它不符合一个平均用户的产品想象——因为当它符合的时候，它就不是技能。

使用 Data Copilot 当然不是一种技能。我敢保证，我们的用户没有一个会在简历上写"会用 Data Copilot"——这就是我们符合了用户产品想象的证据。

其次，用户之所以不找我，是因为我们的产品越过了能力阈值。我们从访谈和调查里面还是能看到用户有很多意见甚至抱怨，但是用户都 workaround 了这些问题。例如有时候口径不是完全对齐的，用户需要指导它如何对齐——这当然是我们可以让产品更好的绝佳机会，但是从评价这个产品的角度，这也是产品完备性的一个信号：用户可以在产品里面解决掉他的问题，而在其他产品中，他可能解决不掉，例如传统的数据和 BI 平台。

当然，用户能够解决掉他的问题，技术上的原因是底层有一个通用 harness 的底座（Codex）。原则上，用户付出足够的努力，在 Claude Code 和 Codex 中也可以解决这些问题，但是这里面有一个成本的问题：Data Copilot 刚好在一个相当大的范围里把这个成本降到了用户能自己搞定的程度，而通用 agent 没有。这就是用户为什么在通用 agent 和 Data Copilot 的竞争中，仍然用 Data Copilot。

多租户和 workspace 分发系统

这个产品的源头，就是我们闪电般地意识到：原来可以通过组装 Claude Code/Codex 工作的那个目录，来创建一个产品。

而当我们把它做成一个产品的时候，我们就面临一系列真实的问题：

首先，它必须是多租户的。

其次，它必须有一个中心化的 workspace 模板，这个模板还可以推送到每一个用户那里，否则何谈产品呢？

最后，用户还需要在 workspace 上进行定制化，保留自己喜欢的结构、规范和资源。

这就是 workspace 管理和分发。我们实现了一个三层架构：

  1. 中心化的 workspace template。 这里面对通用 agent 进行了大量的"默认"重置，包括输出的逻辑、格式、输出 UI 的元数据协议、数据源的选取与校验、重要的 SOP 和静态 infra 知识。最终用户工作的目录里面还需要各种资源，例如代码仓库、知识库、文档库，我们在 template 中通过一种元数据协议声明它们。
  2. workspace base。 通过对 template 进行实例化，我们得到一个 base，实例化的核心就是把 template 中声明的资源组装到 workspace 里面。我们一般同时有多个 base，用户的 workspace 从 base 继承和拉取。
  3. 用户 workspace。 这是用户最终用的，也就是 Codex 真正工作的目录环境。它根据一定的条件，定时从最新的 base 拉取更新、合并进自己的 workspace，这样用户自己对 base 的覆盖也得以保留。我们同时也做了并发控制，使得这一同步不中断用户的任务。

要让这个三层体系稳定、平滑地工作，我们需要一开始就设计好 workspace 的结构，同时设计好实例化和分发的时序与机制。幸运的是，我们一开始就做对了，在这上面一次问题都没有出过。

SEKE：自演化知识引擎

workspace 解决的是"产品的默认从哪里来"。但数据工作里真正难的那一部分，不在默认里，在组织的隐性知识里。

同一个指标，不同业务线的口径不一样；某张表在某个时间点之后才可信；某条 pipeline 上周挂过，那几天的数据要绕开；两种用户标识在不同场景下要用不同的那一种，有时还要从一种推导出另一种才能做关联查询。这些东西不在任何模型里，也不在任何文档里（尽管我们认为应该在）——它们在做这件事的那群人的脑子里。

通用 agent 处理不了这一层，不是因为它笨，是因为它每次都从零开始。你教它一次，这次对了；下一次是另一个人、另一个会话，又错了。抽象地看，每次教一遍好像是件小事，但这些细节摩擦是累加的，加到某个点，用户就不来了。

所以我们做了一套自演化的知识引擎（SEKE）。它的想法很简单：既然这些知识是在真实工作中被反复说出来的，那就在真实工作中把它捕获下来、精炼、并让所有人共享。

有三点是它和"给 agent 加一个 memory"的根本区别：

第一，知识不是记忆。 记忆随经历线性增长，你做得越多，它就越大越乱；知识通过抽象增长，十次同类的纠正应该收敛成一条规则，而不是十条记录。所以引擎的核心不是存储，是精炼：从具体的交互中提炼出可复用的规则，并在新的证据出现时修正旧的规则。

第二，我们不要用户显式反馈。 让用户点赞、打分、写评语，在真实工作场景里是不成立的——他在干活，不是在训练模型。所以知识是从交互本身推断出来的：用户是接受了这个结果，还是改了口径重问一遍，还是把答案拿去用了。行为比表态可靠得多。

第三，评判者是现实，不是系统。 这是我认为最重要的一条。一个自我演化的系统最容易被质疑的地方是错误会不会自我放大——学错了一条，然后一直错下去。但在数据这个领域，判据是外部的：SQL 跑出来的数字对不对，报表拿到会议上会不会被人当场质疑，一个口径错了下游马上就有人喊。这个领域自带一个负反馈回路，而这正是它适合做自演化的原因。

同时，知识树不能完全交给系统。我们保留了一层人类设定的、精炼过程不可覆盖的结构性约束——哪些是不可动摇的定义，哪些边界不能越过。系统可以在这层之下自由生长，但不能改写它。

结果是这样的：一个人教一次，全公司此后都是对的。 有人纠正了某个口径，第二天另一个部门的同事做一个完全不同的分析，那个口径已经是对的了，而他根本不知道发生过这件事。

这也是它和通用 agent 最本质的差别。通用 agent 的知识来自训练，属于全世界；Data Copilot 的知识来自这家公司的这群人在这半年里干过的活，只属于这里，而且每天都在变厚。

关于这套架构的完整设计，我写在另一篇文章里。

领域智能为什么存在，以及 agent 作为接口

上文叙述了为什么应该有一个 data chatbot（agent）产品。我们在这里稍微更宽泛地谈一下领域智能的问题。

什么是领域智能？如果有一个任务集合，在用户心智中有一个概念去识别它（例如"数据分析"），而通用 agent 不能开箱即用地做好，那么这个东西就叫做领域，把这个任务集合做好的智能就叫领域智能。如果一个领域足够强、足够高频，那么做这个领域的产品就能够成立，能够成功。

今天是 agent 时代，人们会有这样的问题：能不能把这个能力挂载到通用 agent 和通用 agent 产品上？

首先，从领域智能的角度讲，它按照定义就是需要隔离于通用智能去建设的。这里的核心不是物理能力的问题，而是角度选择的问题：通用智能被要求、被定义按照一个通用的角度去处理通用的任务，那么你要让它拥有一个领域的角度，你就必须对它进行隔离，也就是限制。例如"给我找一个 sales report"，在不同的语境中意思不同。通用智能不能干好这个数据分析工作的原因，正是它是通用智能的原因。 因此它不能实现领域智能是本质的。

要实现领域智能，就要进行限制和隔离，而这个限制和隔离的最终形态，就是一个领域 agent。从产品形态上讲，我们或许可以把领域 agent 挂载到通用 agent 的 UI 上去，但是你最终必须要解决上面谈及的上下文和 UI 定制的问题。同时，你又必须要付这样的心智税：用户到了通用 agent 的 UI 上，再去选择它要干哪个领域的事——这个形态也许是可以工作的，但确实是一种摩擦。

另外一个重要的问题，是安全和权限隔离。Data Copilot 集成的一部分能力，是不可能直接开放到每个人笔记本上的，直接开放的风险大到不可想象。把这些能力和权限集成到企业内部某个相对通用的 agent 上去或许是可能的，但这就又回到了上面那个领域智能需要隔离的问题。

所以在领域存在的历史时期，领域 agent 和领域 agent 产品，存在的理由恐怕还是大于不存在的理由。这是笔者的判断。

关于"套壳"

回到"套壳"的质疑。

Manus 刚出来的时候我研究过它，当时非常惊讶——我认为它做到的那个水平，大多数团队根本做不到，我反正肯定是做不到。后来 Meta 提出收购它的时候，有人吐槽说"你收购了啥，不就是几十 G 的 Markdown 吗"。

这句话是错的，但从它可以理解产品到底是什么。

当 agent 的底层能力可以被自然语言轻易塑造和组装的时候，产品的本质就暴露出来了：你要造的是一个承载用户认知形式的东西。 而这件事的难度，可能被普遍地低估了——因为到今天为止，并没有另一个 agent 产品在 Manus 擅长的领域做到 Manus 的水准，连远远接近的可能都没有。

这就说明，做一个 agent 套壳没有那么容易。其实从逻辑上想就明白它非常困难：你在和 Claude Code 和 Codex 竞争，用户要在 Claude Code/Codex 和你的"套壳"之间选择你，那你一定做了特别对的事情，对吧？因为 Claude Code/Codex 的产品团队是世界上最强的。

那么具体难在哪里呢？

我想首先是你必须要非常准确地抓出一种或者一系列具体的用户产品想象，就是你对用户期待什么样的结果和过程有非常深刻的理解。然后你要在所有细节上，把那个产品想象执行好，使得用户在你的产品上的体验越过"能用"的阈值。

这两件事都非常难。

下一步：以 data agent 为中心的 data platform

在 Data Copilot 之前，数据工作的瓶颈在 query 的产量。大部分精力花在写 query、以及把 query 写对上。所以你不可能写特别多的 query，或者需要做一堆基础设施来避免频繁写大量 query。

Data Copilot 基本解决了这个瓶颈。需要论证一件事的时候，AI 基本都能写出正确的 SQL。于是你可以用大量查询去解决原来用别的方式解决、甚至原来根本不会去解决的问题。

但瓶颈一旦转移，下游的一切都要重建。

产量上来了，原有的固定 server 撑不住，弹性也不够，拆开跑容易挤占资源。所以我们做了 ClickHouse Serverless，用弹性实例来支撑高并发。现在需要并行跑几十个查询再汇总结论，是可以做到的。

更进一步：对于复杂请求，可以让 agent 把它编排拆分成一个并行化的 DAG，再分发到 serverless 上执行。

这样，agent 就不只是调用一个已有能力，而是这个能力本身有 agent 的深度介入。

这也是为什么"在现有引擎上加一层 agent"不会完全成立——不是加得不好，是原有的执行模型是为"接收一条确定的查询"设计的，而 agent 产生的是一个还在演化的意图。而当我们能在意图的层次上工作的时候，我们就可以做很多不同的、但是 make sense 的工作。

Data Copilot 正在改造并渗透进数据底层的 infra。这就是我们说的以 data agent 为中心的 data platform。

治理对象变了

还有一件事在同时发生。

在 agent 时代之前，我们主要靠"report 产品化"来做数据治理：精心维护和 audit 几十个带参数的 core report，通过组合参数覆盖大部分需求，然后集中力量优化它们。控制点在 query 层。

在 agent 时代，我们依然依赖这些 report，但治理的核心对象已经变成了知识。只要知识是准确的，agent 就能生成正确的 query。链路更直接，bootstrap 的成本也更低。

这里有一个真实的让渡：你放弃了 query 层的强控制。

我判断这个让渡是值得的，理由是它能让组织自然发育、鼓励更多的数据分析和更快的迭代。当然，基于沉淀下来的知识，将来也可以让 agent 自动生成一组 core report 再由人工 review。

但方向我认为是清楚的：用户在与 agent 交互过程中沉淀下来的知识，会成为数据治理的主要对象。

最后

这个产品是我做的。它能做的事情大概用 Claude Code 和 Codex 都能搞定。

但今天我处理任何和数据相关的事情，依然几乎全部用 Data Copilot。

原因很简单：当我作为一个使用者的时候，我不想去发明产品。

我在写一个关于生产环境 AI agent 的系列——架构、产品判断，以及那些只有真正做过才会遇到的问题。如果你也在做这类东西，可以在这里订阅：blog.dreambubble.ai