Data Agent 怎么做：把 23 篇内容收成一张工作地图

Sun, 04 Oct 2026 00:00:00 +0000

看过很多 Data Agent 产品，真正开始建设时，团队仍会回到几个朴素的问题：它到底替谁完成什么工作，应该使用哪些数据，怎样安全执行，如何证明结果可靠，失败后谁负责。

这五个问题比厂商名单更耐用，也把定义、架构、自治等级、评测和落地串在了一起。

下面这张图进一步把问题映射到一条端到端工作链：任务怎样进入系统，数据语义怎样约束规划与执行，证据、审批、回读和反馈又怎样闭环。

一、先决定它接手哪类工作

企业问数、端到端分析、自动化数据科学、多源研究和数据工程是不同路线。问数要求稳定语义和只读权限；开放分析要求多步证据链；数据工程还涉及变更、审批和回滚。

不要先决定“做一个万能 Agent”。选一个具体工作流，写清输入、交付物和失败影响。路线回答做什么，L0–L5 回答人和 Agent 怎样分工，两者不能混为一谈。

二、正确答案从找对数据开始

SQL 能运行，只证明程序没有报错。Data Agent 还要在当前身份范围内找到权威数据，确认 Schema 与数据水位，再绑定指标、实体、时间、粒度和 Join 规则。

数据目录回答“有什么”，语义层回答“代表什么、怎么算”。模型可以检索和整理这些知识，却不应自行决定收入、客户和退款口径。没有版本化语义，系统每次都在用自然语言临时猜企业规则。

三、七层架构服务于一个任务

一条完整链路可以概括为：

接入与路由找到相关、授权、足够的数据；
语义层绑定业务定义和关系；
规划与编排把目标变成可恢复状态机；
受控执行校验、授权并运行 SQL、代码和工具；
验证与评测检查来源、语义、程序、分析和交付；
治理与安全贯穿身份、策略、缓存、文件和动作；
交付与行动把声明、证据、制品、审批和反馈连接起来。

这些层不是采购七个系统，也不是强制微服务拆分。它们是一组责任边界：团队必须知道每项控制在哪里实施、失败回到哪里。

四、自治升级等于责任转移

L1 提供草稿，人执行；L2 能调用工具，人编排；Proto-L3 在限定目标内自主规划，人监督。越往后，Agent 获得越多发起、规划、执行和验证权，治理与恢复要求也越高。

同一产品可在不同工作流上处于不同等级。只读问数可能是 L2，生产变更仍保持 L1。等级应标注在“工作流 × 环境 × 权限”上，而不是品牌上。

五、公开榜单只能帮你找候选

Text-to-SQL、代码分析、异构数据和报告基准测量的是不同边界。看排名时记录数据版本、Oracle 输入、模型与工具、重试、评分器、成本和日期。

最终决策需要企业自己的任务集：正常任务之外，还要有歧义口径、迟到数据、同名测试表、越权、工具故障和无法回答的样本。比较任务成功、证据支持、人工修改、p95 延迟和总成本，并把越权与错误写入设为独立阻断项。

产品案例应该变成检查问题

不同厂商案例最有价值的部分，不是功能名单，而是设计线索：

内部 Data Agent 提醒我们，数据发现和组织上下文可能比 SQL 生成更难；
Skills 模式说明分析经验可以变成可复用、可评审的工作协议；
云平台产品展示了数据、语义、身份和运行时如何复用现有控制面；
只读设计说明查询与业务动作应拥有不同权限边界；
多 Agent 架构只有在职责、上下文或权限需要隔离时才有意义。

把每条线索变成自己的 POC 问题，而不是照抄厂商架构。

企业落地 Data Agent，第一步不是选模型

Tue, 15 Sep 2026 00:00:00 +0000

企业做 Data Agent，第一步往往不是选最强模型，也不是搭多 Agent。先找一段频繁发生、答案可复核、失败影响可控的工作，把“做对了长什么样”写清楚。否则 Demo 再顺，上线后也没人知道它是否值得信任。

落地过程可以理解为逐步转移责任：每向生产前进一步，Agent 多接手一项工作，团队就要补一份证据和一条回退路径。

选择第一站：高频、可验证、低风险

合适的首个任务通常具备：有人反复完成，有历史问题和人工结果；口径有负责人，关键数字能复算；以只读为主，失败可转人工，不直接改变生产系统。

例如每周净收入复盘，比“自动发现全公司经营问题”更适合试点。前者可以固定身份、指标、时间、来源和交付物，后者连完成定义都很难写清楚。

先写任务卡，不急着写 Prompt

任务卡至少包含：

谁发起，支持哪项决定，最终由谁负责；
使用哪些数据与指标版本，时间、粒度、退款和去重规则；
允许读取和禁止访问的资产，是否允许代码、文件和外部工具；
期望产物、关键证据、允许误差和必须拒答的条件；
最大延迟、扫描量、模型/工具预算和人工接管点；
失败、取消、权限撤销和版本回退路径。

Prompt 只是实现细节。任务卡才是业务、数据、工程、安全和评测可以共同签字的契约。

建立真实任务集

从 20–50 个真实高频任务起步，再派生不同问法、角色和边界样本。不要只准备系统知道答案的正常题，还要加入：

指标歧义和定义冲突，系统应澄清；
数据迟到、来源缺失和空集，系统应保留未知；
同名测试表和过期报表，系统应排除；
无权限、敏感字段和外发请求，系统应拒绝；
查询超时、工具故障和状态未知，系统应安全恢复；
相关性被要求写成因果结论，系统应说明证据不足。

近重复样本应分组切分，避免同一个模板同时出现在开发和测试中。

六个阶段与门禁

1. 范围定义

业务 Owner 确认任务、人工基线、价值假设和不可接受的错误。数据团队确认口径与来源；安全团队确认身份和风险边界。

2. 只读 POC

接入最小数据范围和语义资产，在沙箱中保存查询、代码、上下文和验证轨迹。先证明系统能稳定找对数据、算对指标、知道何时停。

3. 离线回归

固定快照，按任务切片评分。红线错误独立阻断；质量、延迟、成本和人工复核分别报告。任何模型、语义或工具变更都重新跑核心集。

4. 影子运行

处理真实请求，但结果不直接交给用户，不产生业务动作。对比人工结果，发现分布漂移、权限、数据水位和长尾成本问题。

5. 有限生产

只开放明确用户、任务和数据域；保留人工入口、速率和预算上限、熔断开关。先交付只读结果或草稿，高影响动作继续人工执行。

6. 规模化

达到稳定门禁后再扩数据域、用户和动作。每次扩张都视为新风险边界，需要新的任务集和回归，而不是复用一次 POC 结论。

上线门禁不要只看平均正确率

红线门禁包括越权、泄密、危险写入、错误接收者和无法停止的副作用，一次有效触发就应阻断对应版本或能力。

质量门禁看关键任务成功、口径错误、证据支持、拒答和人工修改。运营门禁看 p95 延迟、单位任务成本、人工接管、故障恢复和审计完整性。

阈值来自业务风险和人工基线，不存在通用的“90% 就能上线”。财务报送和探索性分析允许的错误不同。

组织责任必须长期存在

业务负责人维护任务优先级、指标口径与可接受错误；数据负责人维护来源、语义和质量；工程/评测负责人维护版本、轨迹、回归和故障归因；安全/运维负责人维护权限、红线、灰度停止和事件恢复。

企业落地 on DataAgentX