企业做 Data Agent，第一步往往不是选最强模型，也不是搭多 Agent。先找一段频繁发生、答案可复核、失败影响可控的工作，把“做对了长什么样”写清楚。否则 Demo 再顺，上线后也没人知道它是否值得信任。
落地过程可以理解为逐步转移责任：每向生产前进一步，Agent 多接手一项工作，团队就要补一份证据和一条回退路径。
选择第一站：高频、可验证、低风险
合适的首个任务通常具备：有人反复完成，有历史问题和人工结果；口径有负责人，关键数字能复算；以只读为主，失败可转人工，不直接改变生产系统。
例如每周净收入复盘，比“自动发现全公司经营问题”更适合试点。前者可以固定身份、指标、时间、来源和交付物，后者连完成定义都很难写清楚。
先写任务卡，不急着写 Prompt
任务卡至少包含：
- 谁发起，支持哪项决定，最终由谁负责；
- 使用哪些数据与指标版本，时间、粒度、退款和去重规则；
- 允许读取和禁止访问的资产，是否允许代码、文件和外部工具；
- 期望产物、关键证据、允许误差和必须拒答的条件；
- 最大延迟、扫描量、模型/工具预算和人工接管点；
- 失败、取消、权限撤销和版本回退路径。
Prompt 只是实现细节。任务卡才是业务、数据、工程、安全和评测可以共同签字的契约。
建立真实任务集
从 20–50 个真实高频任务起步，再派生不同问法、角色和边界样本。不要只准备系统知道答案的正常题，还要加入：
- 指标歧义和定义冲突，系统应澄清；
- 数据迟到、来源缺失和空集，系统应保留未知；
- 同名测试表和过期报表，系统应排除；
- 无权限、敏感字段和外发请求，系统应拒绝；
- 查询超时、工具故障和状态未知，系统应安全恢复；
- 相关性被要求写成因果结论，系统应说明证据不足。
近重复样本应分组切分，避免同一个模板同时出现在开发和测试中。
六个阶段与门禁
1. 范围定义
业务 Owner 确认任务、人工基线、价值假设和不可接受的错误。数据团队确认口径与来源；安全团队确认身份和风险边界。
2. 只读 POC
接入最小数据范围和语义资产，在沙箱中保存查询、代码、上下文和验证轨迹。先证明系统能稳定找对数据、算对指标、知道何时停。
3. 离线回归
固定快照，按任务切片评分。红线错误独立阻断；质量、延迟、成本和人工复核分别报告。任何模型、语义或工具变更都重新跑核心集。
4. 影子运行
处理真实请求，但结果不直接交给用户，不产生业务动作。对比人工结果，发现分布漂移、权限、数据水位和长尾成本问题。
5. 有限生产
只开放明确用户、任务和数据域；保留人工入口、速率和预算上限、熔断开关。先交付只读结果或草稿，高影响动作继续人工执行。
6. 规模化
达到稳定门禁后再扩数据域、用户和动作。每次扩张都视为新风险边界，需要新的任务集和回归，而不是复用一次 POC 结论。
上线门禁不要只看平均正确率
红线门禁包括越权、泄密、危险写入、错误接收者和无法停止的副作用，一次有效触发就应阻断对应版本或能力。
质量门禁看关键任务成功、口径错误、证据支持、拒答和人工修改。运营门禁看 p95 延迟、单位任务成本、人工接管、故障恢复和审计完整性。
阈值来自业务风险和人工基线，不存在通用的“90% 就能上线”。财务报送和探索性分析允许的错误不同。
组织责任必须长期存在
业务负责人维护任务优先级、指标口径与可接受错误；数据负责人维护来源、语义和质量；工程/评测负责人维护版本、轨迹、回归和故障归因；安全/运维负责人维护权限、红线、灰度停止和事件恢复。
如果某个任务没有 Owner，它不适合交给 Agent 自主运行。上线也不是项目终点：数据、口径、模型、工具和用户行为都会变化，黄金任务集必须持续更新。
先交付一个可信闭环
试点的成功标准不应是“能聊”“接了多少表”或“演示很惊艳”，而是一个真实任务在明确边界内反复完成，结果能复算，错误能被发现，成本可接受，失败有人接手。
当团队证明了这一点，再把更多责任交给 Agent。企业落地不是一次技术发布，而是一系列有证据支撑的责任转移。