业务负责人问：“这个月新客转化为什么下降了？”
如果系统立刻吐出一条 SQL，这通常不是效率高，而是跳过了最危险的部分。它还不知道“新客”按注册时间还是首购时间认定，不知道转化窗口是 7 天还是 30 天，也不知道本月渠道口径是否刚刚调整。SQL 可以运行成功，结论仍然可能是错的。
一个可用于生产的数据智能体，必须把这类模糊问题变成一条可检查的证据链：确认意图，找到被批准的数据和定义，制定分析计划，在受控环境里执行，验证结果，最后把结论和限制交给有权限的人。模型只负责其中一部分。
下面这张图把这条链路拆成七层。它不是厂商产品清单，而是一张职责地图：当结果不可信时，团队可以据此定位究竟是哪一层失守。
先看清三张相互叠加的网
七层并不是一条只能从上往下走的流水线。一次分析会在规划、执行和验证之间多次往返，而权限、审计与评估贯穿始终。更准确的理解，是三张网叠在一起：
- 数据面负责让智能体找到数据、理解业务语义并运行工具；
- 控制面决定智能体可以看到什么、调用什么、在什么成本和风险范围内行动；
- 评估面检查单次答案，也持续衡量系统在一组真实任务上的表现。
很多原型只有数据面最显眼的一小段——“问句转 SQL”。一旦进入生产，真正拉开差距的往往是另外两张网：系统能否拒绝不该做的事，能否说明结论从何而来，失败后能否定位和修复。
第一层：接入与任务入口
入口可以是聊天框、Notebook、BI 侧边栏、API，也可以是定时触发的工作流。它的责任不是“做一个像 ChatGPT 的界面”，而是收集完成任务所需的最小上下文：用户身份、业务范围、时间窗口、期望输出和风险等级。
仍以转化率下降为例。一个合格的入口至少要知道提问者能看哪些地区的数据，并在定义不明确时主动追问：“这里的新客按注册还是首购计算？”
这一层的典型失败，是系统流畅地解决了另一个问题。产品设计上应允许用户低成本纠正假设，而不是把澄清隐藏在一长段回答之后。
第二层：语义、本体与可信上下文
物理表告诉模型有哪些字段，语义层告诉它这些字段在业务上意味着什么。这里需要管理指标、维度、实体关系、同义词、时间口径、Join 路径、负责人和版本。
例如，“新客转化率”可能被定义为：首个有效触点后 14 天内完成首购的新用户数，除以符合条件的新用户数。这个定义还要说明排除哪些渠道、退款如何处理、历史版本何时失效。只有把这些知识变成可检索、可引用、可执行的对象，智能体才不必每次凭字段名猜测。
上下文也不等于把所有文档塞进提示词。系统需要按任务路由：指标问题优先取指标定义和血缘，客户问题取实体关系和权限，重复出现的分析则可参考已验证的历史查询。上下文越多不一定越好；过期定义和相似但错误的 SQL 会把错误包装得更像答案。
第三层：规划与编排
规划器把目标拆成有依赖关系的步骤。对“新客转化下降”这类问题，一份可检查的计划可能是：
- 确认指标版本和比较周期；
- 先复算整体指标，确认下降确实存在；
- 按渠道、地区、设备和新客来源做贡献分解；
- 对主要异常分组检查漏斗步骤与数据质量；
- 运行替代口径或对照查询，排除定义变更；
- 汇总证据，标出不能从现有数据确认的部分。
规划的价值不在于写出一段漂亮的步骤说明，而在于让依赖、预算和停止条件显式化。某个分组样本过小，就不该继续生成强结论；关键数据延迟，系统应停止并提示，而不是用昨天的数据补齐今天的故事。
单智能体配工具、Planner–Executor–Verifier、多智能体协作都可以实现这一层。角色越多，协调和状态管理成本越高。先把计划、工具契约和验证点做扎实，通常比先增加 Agent 数量更重要。
第四层：工具与受控执行
智能体通过 SQL 引擎、Python 沙箱、Catalog、文档检索、可视化组件和业务 API 把推理变成证据。每个工具都应该像一个受约束的服务，而不是给模型一把万能钥匙。
一个可上线的工具契约至少应写清：输入参数、输出结构、身份传递、数据范围、超时、成本上限、幂等性和失败码。查询默认只读；大扫描、敏感字段和写操作需要单独的审批或策略门槛。代码在隔离环境运行，产物和日志可追溯。
这也是 Agent Harness 的核心工作：把模型调用、上下文装配、工具选择、策略检查、状态与记忆连接起来。模型可以替换，Harness 中积累的权限、工具契约和失败处理才是系统工程的主体。
第五层：验证、反思与修正
“工具调用成功”只说明系统得到了一份结果，不说明结果值得相信。验证层需要同时检查计算和结论。
计算侧可以做 SQL 编译、空值与基数检查、时间范围检查、与可信总数对账、替代查询比较；结论侧要检查每个判断能否回到数据证据，相关性是否被误写成因果关系，以及样本量和数据延迟是否足以支撑措辞。
当验证失败时，系统应回到规划或执行层修正，而不是简单地“再生成一次”。例如两个渠道的合计对不上整体，正确动作是检查重叠归因或 Join 扩张；让模型换一种说法，并不会修复数字。
第六层：治理、安全与可观测性
治理不是上线前加的一道审批，而是沿整条链路传播的约束。用户身份必须传到语义对象、数据源和执行工具；脱敏、行列级权限、用途限制和保留策略也要在运行时生效。
可观测性则记录这次回答使用了哪个指标版本、检索了哪些上下文、生成了什么计划、调用了哪些工具、花费多少、在哪一步被人工修正。没有这些 Trace，团队只能看到“回答错了”，却无法判断是语义缺失、数据延迟、检索污染、工具异常还是模型判断失误。
高风险动作还需要人与系统共同控制。发送外部报表、修改生产数据或触发业务策略时，审批点应与行动后果匹配，并向审批者展示足够的证据，而不是只弹出一个“是否继续”。
第七层：交付与持续学习
好的交付物不只是一个数字。它应包含结论、关键证据、口径、适用时间、限制条件和可继续追问的路径。不同任务需要不同形态：经营诊断可能是一页摘要加可下钻图表，数据排障可能是可复现的 Notebook，自动化任务则需要结构化输出和告警。
交付之后，系统还要把反馈变成可治理的改进。用户确认过的指标映射可以进入候选语义资产；被人工否决的计划要进入失败案例；高价值任务沉淀为 Golden Tasks，随模型、提示词、语义层和工具升级持续回归。不能把每次对话原样写进长期记忆，那会同时积累噪声、过期信息和隐私风险。
用一条请求检查整套架构
设计评审时，可以要求团队现场跑通一条真实请求，并逐层回答以下问题：
| 检查点 | 应能看到的证据 |
|---|---|
| 意图 | 系统记录了关键假设，并在歧义处发起澄清 |
| 语义 | 指标、实体、时间口径和 Join 路径有版本与负责人 |
| 规划 | 步骤、依赖、预算和停止条件可以检查 |
| 执行 | 身份随工具调用传递，查询与代码运行在受限环境 |
| 验证 | 结果经过对账或替代方法检查，结论能够回链到证据 |
| 治理 | 敏感访问、高风险动作和人工审批留下审计记录 |
| 交付 | 输出说明口径、限制和复现路径，而不只给一句答案 |
如果其中某一项只能靠演示者口头解释，它通常还没有真正进入系统。七层架构的意义就在这里：它不承诺一次把所有能力做满，却迫使我们把“会回答”拆成一组可以建设、测试和负责的工程对象。