DataAgent 评测：企业问数，怎样让答案值得信任

业务人员问一句“上个月销售额为什么下降了”，背后其实藏着一串问题：销售额指 GMV 还是退款后的净收入？上个月按今天算，还是按数据的最后一天算？渠道下降了多少，又能不能据此认定下降的原因？

这次我在本地 Docker 重新部署了 DataAgent，从企业登录入口进入零售工作区，连续验证经营指标、跨期贡献、趋势排名和会员复购四个场景。四次真实模型任务全部完成，查询数值与派生分析也通过了独立核对。

我的评价是：指标口径、分析复算和结果证据已经形成一套可用的经营问数流程。等待时间、探索范围和反馈处理仍有改进空间。下面先看本轮实际表现，再讨论这套架构为什么有价值，以及下一步该补什么。

DataAgent 的四个关键环节：业务口径、Agent 规划、系统复核与证据交付。

重新部署后，我先验证了四个电商场景

本轮补测于 2026 年 10 月 14 日完成。我保留了已有账号、数据卷和历史会话，重新构建应用镜像与电商数仓，再通过正常企业登录提交问题。测试使用电商合成数据，业务窗口为 2026 年 4 月 1 日至 6 月 30 日。

前三个任务在同一对话中完成，后两轮恢复了此前的分析会话；会员复购使用新对话。这里的耗时从任务提交到读取完成状态，包含轮询开销。对这四个问题，流程走通了；但每次等待约半分钟到一分钟，日常反复问数时仍然会感到慢。

六月的 GMV 为 1,466,462.00 元，净收入为 1,246,587.90 元，支付订单数为 2,490 单，客单价约 500.64 元，订单退款率约 6.7068%。页面中的退款率显示为 6.71%，采用了两位小数展示。

截取已完成任务的实际查询结果区域。页面同时展示期间、来源、数据日期和导出权限。

我没有只检查页面出现了数字。经营指标另外从原始订单、支付记录和客户标记独立计算；四个模型场景的查询结果再次按当前授权重执行，比较、贡献、趋势与排名也重新复算。期间、维度和指标是否符合问题，同样纳入核对。

这些检查各有作用：固定样例验证已知口径，专项对账验证数值，真实模型任务验证提问到分析交付的链路。四个场景都完成，可以说明本轮表现，不能直接推广成所有业务问题的准确率。

趋势任务中，六月净收入最高的日期是 6 月 18 日，金额为 80,576.43 元。折线图保留每日结果表，便于继续核对高点前后的变化。

实际工作台中的趋势图。日期和金额来自本轮已完成的查询，高点经独立核对。

渠道排名显示，app 净收入为 589,932.42 元，web 为 368,585.39 元，mini_program 为 288,070.09 元。我认为图表与表格同时保留比较实用：图表帮助快速看结构，表格便于取数和复核。

实际查询结果区域，保留渠道金额、来源和无导出权限提示。

先把“销售额”说清楚

DataAgent 当前有电商和制造两个参考业务域。电商场景覆盖交易规模、退款后收入、订单、渠道和买家结构这些日常经营问题。我的第一项评价，是它是否能把这些业务词解释清楚，再给出结果。

它会优先使用已经定义好的指标回答问题。用户不必每次重新说明测试账号要不要排除、退款订单如何处理，也能查看这次答案采用的口径。对于反复问同一类经营问题的团队，这种一致性很有价值。

我先检查指标口径。DataAgent 定义了六个认证指标：GMV、净收入、支付订单数、客单价、订单退款率和复购买家率。每项指标除了计算方式，还声明允许的维度、排除规则、负责人和适用限制。这里的“认证”指项目内经过治理的口径。

有效经营订单还要排除测试账号和取消订单。订单与商品明细之间是一对多关系，一笔订单包含多件商品时，订单数需要去重；一个订单涉及多个类目时，也不能把各类目的订单数相加当成全站订单。

这一部分的优点是规则具体，能减少同一个问题在不同人手里得到不同答案的情况。代价是前期维护：业务团队仍然需要确认口径、允许的分析维度和适用限制，不能指望接上数据库后就自动完成这些工作。

客单价：能否把看似简单的数字算对

假设渠道 A 的净收入是 1,000 元，支付订单 10 单；渠道 B 的净收入也是 1,000 元，支付订单 100 单。两边客单价分别是 100 元和 10 元。

直接平均得到 55 元。但整体客单价应当是 2,000 ÷ 110，约 18.18 元。订单量不同，两个渠道不能获得相同的权重。这个例子是为解释口径而设的，并非项目实测结果。

整体客单价 = SUM(净收入) / SUM(支付订单数)

DataAgent 对客单价、退款率这样的指标，会分别汇总分子和分母再相除；分母为零时返回空值。我认可这种处理，因为它直接影响渠道对比和月度汇总是否可靠。使用者也需要接受一个结果：遇到无法计算的范围，系统应该留空并解释，而不是补一个看起来完整的数字。

问数与探索：有灵活性，也有明显限制

用户可以围绕经营问题发起查询，系统检索相关指标和数据说明，再选择查询或分析方式。出现查询错误时，模型可以根据错误信息调整。这让它能够处理不同的问题组合，而不仅是重复几条固定报表。

业务知识也会参与问数。销售额、复购率等词对应什么定义，相对日期怎样解释，哪些情况需要提示用户，都有相应规则。对使用者来说，价值在于少一些反复解释，让后续问题沿用清楚的业务语境。

我的评价是，这种灵活性适合在已有指标和明确授权范围内展开分析。问题越接近已经维护好的业务定义，系统越有依据；问题超出范围时，产品需要明确告诉用户还缺什么。

当现有指标不能覆盖问题时，部分场景允许进入只读 SQL 探索。查询需要先审核，再执行；不同工作区和业务域的授权也会影响可查询的内容。这个入口扩展了问数能力，同时增加了权限和数据接入的配置要求。

目前企业 SQL 探索支持 PostgreSQL、MySQL 和 DuckDB，但仅对本业务域明确授权的单个外部资产开放。这个入口不能自由 JOIN 或跨源查询，内置合成域和关系域也没有开放相同的探索能力。如果需求是临时把多套系统的数据拼起来分析，当前能力还不够。

所以，我会把查询范围看成选用它之前必须确认的一项条件。已有指标能覆盖的经营问数，路径较清楚；跨源、复杂关联或尚未定义的业务问题，需要先确认支持情况。

比较、贡献、排名和趋势：分析能力更进一步

分析复算是我认为完成度较高的一部分。用户可以比较两个期间的收入，按渠道拆解净变化，查看分组排名和日期趋势。模型负责提出分析方式，关键数值从已执行的结果表重新计算。

两份数据是否可比，也会影响分析能否完成。指标定义、筛选、分组和权限需要一致；期间重叠、分组覆盖不全、结果截断或空值，会触发相应检查。我认可这层约束，因为一张好看的对比图并不能掩盖比较对象不同的问题。

这一部分的优点是能解释数字怎样得来，结论也能关联原查询。局限是分析类型仍然明确：期间比较、变化贡献、排名和日期趋势，不能据此认定它已经能够处理任意复杂分析。

举个变化贡献的例子：A 渠道从 100 增至 150，B 渠道从 100 降至 80，整体净增长为 30。A 的净变化贡献是 50 ÷ 30，约 166.67%；B 则是 −20 ÷ 30，约 −66.67%。这也是项目单测采用的构造示例，不是经营数据。

超过 100% 或出现负贡献，在这个定义下有明确含义：一个渠道推动增长，另一个抵消了部分增长。如果净变化为零，贡献比例就不能计算。

但算出贡献，并不能证明原因。“A 渠道带来了多少净变化”和“A 渠道为什么增长”需要不同的证据。项目将这项边界写进分析限制，没有把算术拆解包装成自动因果归因。

日期趋势也只描述已观测数据，不把缺失日期自动补成零，不凭一条曲线推断季节性或统计显著性。两个月天数不同时，期间总量比较会提示这一点，不默认换成日均值。

这次跨期任务还给出了一个实际结果：六月净收入比五月减少 26,193.50 元。app 减少 14,746.87 元，web 减少 13,998.57 元，mini_program 增加 2,551.94 元。增加的渠道抵消了部分下降，贡献分析正好可以展示这种关系。

截取已完成任务的变化贡献区域，并展开复算表。贡献是算术拆解，不能据此认定业务原因。

答案交付时，要能找到它的依据

一份可以继续核对的答案，应该能看到查询期间、指标口径、来源、SQL、结果表和派生计算。DataAgent 的对话工作台围绕这些内容组织结果交付，同时保留柱状图、日期折线图与已返回的表格行。

用户查看结论时，还能追到查询证据和派生计算所用的原始结果。对我而言，这比单独给一句“收入下降了”更实用：发现异常时，可以继续核对是口径、期间还是数据本身的问题。

数据日期尤其需要说清楚。电商示例固定窗口是 2026 年 4 月 1 日至 6 月 30 日，相对日期以 6 月 30 日为锚点。因此示例里的“上个月”对应 5 月，不能读成今天的上个月。最大业务日期也不等同一次成功刷新的时间，更不能据此宣称数据实时。

导出权限单独控制。能查看答案，不代表可以下载 CSV；没有导出权限时，下载入口会禁用。用户也可以针对数值、口径、来源或不完整结果提交反馈，并在刷新后查看记录。

结果交付的优势是把图表、表格和证据放在同一处，便于继续核对。我的保留意见是，反馈入口目前比处理流程走得更前：可以提交问题，还不能说明问题已经有人接手并解决。

我在网页上实际切换了两份查询证据，检查指标口径、结果和 SQL；刷新后零售工作区仍能恢复。未授权的其他工厂账号访问零售域被拒绝，当前示例账号的 CSV 下载也被拒绝。反馈提交后能够保存、刷新读取，但状态仍是“待处理”。

截取实际查询证据面板，展示渠道结果、指标口径和执行 SQL。390px 视口也检查了证据展示，未观察到页面横向溢出。

这套架构的优势，体现在责任怎么分

我把企业链路理解为五个环节：工作台和登录、API 校验、持久任务、独立 Worker，以及查询计算与结果发布。浏览器提交问题，API 校验并保存任务，Worker 领取后让模型选择工具；系统按当前权限执行查询、复算分析，最后保存并展示结果。

按当前实现整理的架构示意。业务结果截图来自实际运行，架构图用于说明各层职责。

第一项优势是口径管理与模型规划分开。模型选择指标、期间和维度，指标定义决定怎样计算。客单价和退款率按正确方式汇总，这次也与原始订单独立对账一致。代价是需要业务负责人持续维护定义，不能把口径确认全部交给模型。

第二项优势是任务不依赖页面一直打开。PostgreSQL 保存任务、会话和事件，独立 Worker 执行分析。本轮验证了多轮会话和刷新恢复；提交幂等、租约与执行版本校验，也为处理重试和旧 Worker 提供基础。崩溃后的完整恢复还需要单独的故障演练，不能用四次正常问答替代。

第三项优势是权限贯穿查询与交付。执行身份由受信配置确定，模型不能通过问句指定另一个用户；查询、发布和导出都复核权限。数据库还按工作区与结果所有者隔离访问。本轮越权访问和导出拒绝，验证了两个用户能够直接感知的边界。

第四项优势是分析可以重新计算。模型提出比较或贡献的计划，程序从已执行结果计算差额、占比和高点，再把结论关联回查询证据。我最认可这一点：用户对某个百分比有疑问时，可以追到具体数据和计算方式。

第五项优势是部署与执行职责分开。API 和 Worker 可以分别维护，身份服务与数仓也有独立角色。此次 API、登录入口和 Worker 使用同一应用镜像，相关源文件与本地一致，应用以非 root 身份运行、根文件系统只读。这为后续升级和扩展提供基础，但多工作区配额、公平调度和大规模并发仍需另外验证。

我的迭代顺序：先稳住，再扩展

第一优先级是复杂问答的稳定性和等待时间。当前四个场景完成了，仍需要更多没有提前写进提示词的业务问题：省略式追问、空结果、零分母、退款、错维度和两期覆盖不一致。我会同时记录首次完成率、参数纠错率、耗时和费用，而不只累计成功截图。

针对本轮约 36–71 秒的耗时，我会先看目录检索、重复工具调用和分析步骤分别花了多久，再优化重复获取的信息。缓存必须随授权、指标版本和数据变化失效，不能靠复用过期结果换速度。取消、撤权和 Worker 重启，也应纳入独立测试。

第二优先级是完成交付闭环。反馈需要明确谁负责、如何复核、怎样记录修正、何时通知用户；导出需要用隔离测试账号走完允许、禁止和撤权三种网页流程。随后选择一个真实电商数据源，与经营报表逐项对账，让指标定义有负责人和验收依据。

第三优先级才是扩大分析范围。先从经过审核的关联关系开始，验证订单粒度、关联键、重复计数和权限，再逐步增加问题类型。同时补齐数据新鲜度与结构漂移告警、工作区配额、可核对的费用预算，以及数据库和加密会话密钥的备份恢复。

我的评测结论

完成这轮实测后，我对 DataAgent 的判断更具体了：它已经能把经营问数、分析和证据交付接起来。四个模型场景都完成，原始数据对账与派生复算也一致。指标口径和可追溯结果，是我认为最值得保留的产品能力。

不足也很明确：等待时间还长，SQL 探索不能自由跨源关联，反馈尚未形成完整处置流程，有导出权限账号的浏览器下载仍需验收。历史记录出现过模型漏填分析维度，本轮四次任务没有出现同样问题；但要判断稳定改善，仍需要扩大测试问题与重复次数。

如果团队已有明确的经营指标和数据负责人，希望把重复查询、月度比较、渠道排名和趋势分析接到自然语言入口，我认为它值得做一轮范围清楚的试点。下一步的价值，要靠真实业务口径对账、复杂问题的稳定完成，以及反馈和交付流程来证明。