Data Agent 上下文工程指南：业务规则、指标语义和用户意图如何进入执行链路

为什么企业需要 Data Agent 上下文工程？

企业把大模型接入数据库后，很容易发现：模型会写 SQL，并不等于它能够正确完成企业分析。

例如用户问：“为什么这个月华东收入下降了？”其中隐含了大量业务上下文：“收入”是确认收入、开票收入还是回款收入？“华东”按客户归属还是销售组织划分？下降是同比还是环比？当前用户能查看哪些组织？确认下降后，应该继续分析订单量、客单价，还是客户结构？

这些问题无法只靠数据库 Schema 或模型参数解决。

传统 Text-to-SQL 主要处理“自然语言如何转换成查询”，而企业级 Data Agent 还需要确定：用户真正想解决什么问题、采用哪套业务定义、遵循哪些规则、调用什么分析方法，以及结果如何验证。

因此，上下文工程解决的不是单次提示词设计，而是整个执行过程中，什么信息应该在什么时候进入哪个执行节点。只有把企业已有的指标体系、数据资产、业务规则、权限和分析经验组织成可动态调用的上下文，Agent 才能从“会查数据”进一步走向“按企业规则分析数据”。

常见做法和问题所在

做法一：把企业知识全部塞进 System Prompt

把指标定义、业务术语、SQL 示例和分析规则集中写入 Prompt，是最容易实现的方式。但随着指标和规则增加，上下文会迅速膨胀，相似指标和无关规则反而可能干扰模型判断。

真正的问题不是模型“知道得不够多”，而是系统没有筛选当前任务真正需要的信息。生产环境需要的是按任务动态装配上下文，而不是不断扩张 Prompt。

做法二：用 RAG 检索指标文档和业务制度

RAG 能帮助 Agent 找到指标手册、制度和数据字典，但“找到规则”并不等于“严格执行规则”。

例如文档规定“GMV 排除取消订单”，如果规则只以文本形式提供，模型仍需再次解释并转化为查询逻辑。指标公式、时间口径、维度关系等可结构化知识，更适合进入可执行语义层；RAG 则补充难以结构化的业务知识。

做法三：把数据库 Schema 当作主要上下文

表、字段、DDL 能告诉模型“数据在哪里”，但无法完整说明“业务是什么意思”。即使 SQL 语法和 Join 都正确，Agent 仍可能选错收入字段、客户口径或组织维度。

因此，Schema 属于数据结构上下文，语义层负责业务含义和计算约束。两者不能相互替代。

推荐方法框架

建议企业建立六层动态上下文架构。六层信息不需要同时进入大模型，而是随着“理解问题—确定语义—约束执行—完成分析—验证结果”的过程动态装配。

这套架构的关键在于职责分离。

意图层负责理解问题，语义层负责确定计算，规则层负责控制边界，Skill 层负责分析方法，证据层负责验证结果。 Agent 不需要自己重新推理所有企业规则，而是在这些上下文约束下完成任务规划。

完整执行链可以概括为：用户问题 → 意图识别 → 语义匹配 → 规则校验 → 任务规划 → Skill / 工具调用 → 数据执行 → 结果验证 → 回答生成。

这也是上下文工程与“超长 Prompt”最大的区别：上下文不是一个静态输入包，而是随任务运行不断装配和更新的执行环境。

Step-by-Step 落地路径

Step 1：建立上下文资产清单

先选择一个真实分析场景，梳理 Agent 完成任务需要的用户身份、指标、维度、业务规则、权限、数据资产和分析方法，并标记其来源、Owner 和更新方式。同时区分结构化语义、文档知识和实时状态。最终产出“上下文资产地图”，明确哪些信息必须进入执行链、从哪里获取，以及由哪个系统负责维护，为后续架构设计建立边界。

Step 2：将用户问题转化为结构化意图

不要让自然语言直接进入 SQL 生成。首先识别任务属于查数、趋势、异常还是归因，再抽取指标、维度、时间和过滤条件，并判断歧义。例如“最近华东销售怎么样”，需要明确“销售”对应什么指标、“最近”对应哪个时间范围。最终形成结构化 Intent Object，为后续语义检索、权限校验和任务规划提供统一输入。

Step 3：把核心业务知识变成可执行语义

收入、利润、订单、客户等核心对象，应建立统一指标定义、计算公式、维度关系和时间口径。这样 Agent 识别“收入”后，可以直接匹配治理后的语义对象，而不是重新阅读文档、猜测字段和生成计算逻辑。该阶段重点产出可复用的 Metric、Dimension 和 Semantic Model，让业务语义真正参与查询执行。

Step 4：将规则放到正确的执行节点

不要把所有业务规则都写进 Prompt。指标公式进入语义层，数据权限在查询前校验，资源和扫描量限制进入执行预检，归因方法进入 Skill，难以结构化的制度知识再通过 RAG 补充。最终形成“规则—执行节点映射”，使高风险、确定性的规则由系统强制执行，而不是依赖模型自行理解和遵守。

Step 5：建立动态上下文装配机制

根据任务阶段加载必要信息。用户只问“昨天收入多少”时，无需加载完整归因规则；继续追问“为什么下降”后，再加入相关业务维度和归因 Skill。通过 Context Router 根据用户、Intent 和当前执行状态选择上下文，可以减少无关信息干扰和 Token 消耗，同时让复杂任务逐步获得更丰富的分析信息。

Step 6：形成执行与证据闭环

每一步执行结果都应成为下一步上下文。例如发现华东贡献了主要收入下降后，后续分析应自动聚焦华东。同时记录指标口径、查询条件、数据来源、中间结果和执行路径，形成 Execution Trace。最终输出的不只是结论，还包括能够支撑结论的关键证据，使分析结果可解释、可复核，也便于后续错误定位和 Skill 优化。

Aloudata 技术方案

企业级 Data Agent 的上下文工程，需要语义、元数据、数据访问与 Agent 执行体系协同，而不是依靠单一的大模型模块。

在业务语义层，Aloudata CAN 自动化指标平台可以管理指标定义、计算逻辑、业务维度和维度层级，并通过指标服务向 Agent 提供可执行语义。对于标准指标问数，Agent 可以先识别指标、维度、时间和过滤条件，再调用统一指标服务，而不是根据底层 Schema 临时生成一套指标算法。

在数据上下文层，Aloudata BIG 主动元数据提供表、字段、任务、SQL 和血缘等元数据信息，帮助分析过程理解数据来源及上下游关系；Aloudata AIR 则通过逻辑数据编织提供跨源访问能力，使不同数据源能够在不必全部提前集中搬迁的情况下进入分析链路。

Aloudata Agent 可信数据分析智能体位于执行层，通过 Agentic Harness 组织用户意图、语义资产、工具和分析 Skill。标准指标优先使用确定性语义服务，明细分析、文件分析、归因和报告等复杂任务则根据目标动态调用相应工具与 Skill。

最终形成的是一套“语义确定计算、规则控制边界、Agent 规划任务、Skill 执行分析、证据验证结果”的体系，而不是让大模型独立承担所有业务判断。

常见误区

误区 1：上下文越多，Data Agent 越准确

正解：真正重要的是相关性和进入时机。一次加载大量指标、Schema 和规则可能增加歧义，生产级系统应该根据任务动态选择上下文。

误区 2：指标文档做成 RAG，就完成了语义治理

正解：RAG 解决知识检索，不能天然保证计算一致。指标公式、维度关系和业务过滤等确定性逻辑，应尽量成为可执行语义。

误区 3：业务规则都可以交给大模型执行

正解：权限、指标公式、成本阈值等高风险规则应由确定性系统强制执行。Agent 更适合负责复杂任务规划和开放式分析，而不是替代所有规则系统。

典型场景

场景一：经营指标问数中的动态语义装配

某集团的“收入”在不同部门存在多套历史 SQL。业务人员询问“华东本月收入同比怎么样”时，Agent 首先解析收入、华东、本月和同比，再从 Aloudata CAN 获取统一收入指标及业务维度，并结合当前用户权限执行查询。Agent 不需要浏览整个指标库，也不重新生成收入算法，而是把自然语言意图映射到治理后的语义对象，使问数从“模型猜口径”转变为“模型理解问题、语义系统确定计算”。

场景二：经营异常归因中的上下文逐步扩展

某零售企业发现销售额下降并询问原因。Aloudata Agent 首先调用销售额统一指标确认异常，再加载归因 Skill 和区域、渠道、商品等相关维度；当华东被识别为主要影响来源后，后续分析继续聚焦华东。此前产生的指标结果和维度贡献成为新的上下文，最终形成从异常识别、维度拆解到关键证据的完整分析链，而不是每轮对话都重新开始查询。

常见问题（FAQ）

Q1：Data Agent 上下文工程与 Prompt Engineering 有什么区别？

Prompt Engineering 主要优化模型指令，上下文工程则覆盖整个 Agent 执行过程。它需要组织用户身份、业务语义、权限、数据、工具、Skill 和中间结果，并决定这些信息什么时候进入执行链。前者主要优化模型交互，后者更接近生产级 Agent 的运行架构。

Q2：业务规则应该写进 Prompt，还是放进语义层？

指标公式、维度关系和时间口径等确定性规则，应尽量进入可执行语义层；权限和资源限制应由系统强制执行。只有难以结构化、主要用于辅助理解的业务知识，更适合通过 RAG 或 Prompt 提供。

Q3：RAG 能否替代企业语义层？

不能。RAG 擅长检索指标解释、制度和知识，但模型仍需要把文本转化成查询逻辑；语义层则直接约束指标如何计算。两者更适合形成“RAG 补充知识、语义层约束计算”的关系。

Q4：为什么不能把所有指标和 Schema 一次性提供给 Agent？

大量相似指标、表和字段同时进入上下文，会增加歧义、Token 成本和错误选择概率。更合理的方式是先识别用户意图，再动态检索相关语义和数据资产。上下文工程追求的是精准装配，而不是最大装载。

Q5：如何判断上下文工程已经具备生产条件？

至少应验证三个方面：相同业务问题能够稳定匹配相同语义，关键权限和规则能够在执行前生效，最终数字和结论能够追溯到数据及分析路径。如果正确性仍主要依赖模型临场理解 Prompt，就还没有真正建立生产级上下文体系。