语义层 vs Context Engineering：Data Agent 的业务规则应该固化在哪里？

什么是语义层？

语义层（Semantic Layer）位于底层数据与 BI、Data Agent、API 等消费端之间，把数据库中的表、字段和技术逻辑转换成统一的业务语义。它通常沉淀：业务对象 → 指标 → 维度 → 关系 → 计算口径 → 统计周期 → 权限规则。

例如企业定义“净销售额”为：

已支付订单金额 - 已完成退款金额，不统计测试订单，按支付完成时间归属自然日。

这不是一段用于帮助大模型理解业务的背景材料，而是一项必须被系统确定执行的数据规则。无论销售 Agent、财务 Agent、BI 看板还是业务 API 查询“净销售额”，理论上都应该获得相同的定义和结果。

因此：

语义层管理的是企业业务事实的定义权。

什么是 Context Engineering？

Context Engineering（上下文工程）关注的是：在每一次模型推理发生之前，应该给模型提供哪些信息。Anthropic 将其定义为对模型推理时上下文信息进行选择、组织和维护的工程实践，其范围已经不只是 System Prompt，还包括工具定义、MCP、外部数据、消息历史以及 Agent 运行过程中不断产生的状态。

例如业务人员问：

“华东为什么连续三周销售下滑？”

这一轮 Agent 可能需要获得：

• 当前用户身份与权限；

• “销售额”的标准语义；

• 华东区域定义；

• 当前日期；

• 最近三周相关指标；

• 可调用的归因分析 Skill；

• 企业近期促销活动信息；

• 此前对话中用户指定的分析范围。

这些信息没有必要全部永久写入一个超长 Prompt。

Context Engineering 的任务，是在运行时判断：

这一次解决这个问题，模型最需要看到哪些高价值上下文？

核心区别：一个固化事实，一个组织认知

真正容易混淆的是：一条业务规则既可以写进 Context，也可以定义在语义层。技术上两种方式都能让模型“知道”，但工程后果完全不同。

对比一：稳定规则应该被“执行”，而不是反复让模型“理解”

假设企业规定：

“活跃会员 = 最近 30 天至少完成一次有效购买的会员。”

最简单的 Agent 实现方式，是把这句话写进 System Prompt：

当用户询问活跃会员时，请按照最近 30 天至少购买一次进行计算。

PoC 阶段这样做完全可行。

问题在于，当企业出现销售分析 Agent、会员 Agent、营销 Agent、经营报告 Agent 后，这条定义可能进入十几个 Prompt、Skill 或知识文件。半年以后规则改为“最近 60 天”，企业就必须找到所有副本逐一修改。更严重的是，大模型拿到文字定义以后，仍然需要自行判断：

• 哪张订单表；

• 什么叫“有效购买”；

• 使用哪个时间字段；

• 退款订单如何处理；

• 会员 ID 如何关联。

因此，把确定性的计算规则放进 Context，本质上只是把规则“告诉模型”，而不是让系统“执行规则”。

语义层更适合这类规则，因为定义最终可以转换成确定性的查询逻辑。

判断标准是：

只要同一个规则要求不同用户、不同 Agent、不同时间调用都得到一致数据结果，就不应只存在于 Context 中。

对比二：动态任务信息不应该全部固化进语义层

反过来，也不能因为语义层能够沉淀业务知识，就把所有 Agent Context 都建模成语义资产。

例如用户说：

“这次先别看线上渠道，只分析华东直营门店，而且重点检查上周营销活动有没有影响。”

这里包含：

• 本次分析范围；

• 用户临时偏好；

• 当前任务重点；

• 对话历史；

• 当前时间条件。

这些内容只对当前任务有效。把“本次不要分析线上渠道”永久写进企业语义层显然不合理。

同样，Agent 可调用哪些工具、当前步骤已经执行到哪里、之前生成了什么中间结论，也属于运行时状态。Anthropic 对 Context Engineering 的讨论特别强调，上下文是一种有限资源，Agent 需要从不断增长的信息中选择最相关、高信号的内容，而不是简单把所有可能相关的信息全部塞进上下文窗口。

因此：

语义层追求稳定与复用，Context Engineering 追求相关与及时。

一个负责沉淀，一个负责调度。

对比三：业务规则是否应该进入 Context，要看它是“事实”还是“指导”

这是企业建设 Data Agent 时最实用的一条分界线。

例如以下规则：

“GMV 不扣除退款。”

这是事实定义。

它决定 GMV 怎么算，应该优先进入语义层。

而另一条规则：

“分析销售下降时，优先检查订单量、客单价和退款率。”

这是分析指导。

它告诉 Agent 应该怎样开展任务，更适合被沉淀为 Skill、System Instruction 或其他可动态加载的上下文。

再比如：

“华东包括上海、江苏、浙江和安徽。”

如果这是集团长期统一的区域维度定义，应进入语义层。但：

“本次经营会把安徽暂时归到华中比较。”

这是此次任务的临时分析条件，应进入 Context。

所以可以使用一个简单规则：

事实规则 → Semantic Layer

方法规则 → Skill

任务规则 → Context

执行能力 → Tool

这种分层，比讨论“业务知识到底放知识库还是 Prompt”更有意义。

对比四：Context Engineering 越成熟，越需要可靠的语义源

有人可能据此得出另一个结论：

既然 Context Engineering 可以动态检索业务规则，那么是不是不再需要提前建设语义层？

恰恰相反。Context Engineering 解决的是怎么选择上下文，但它本身不会自动保证被选择的信息正确。

如果企业存在三个版本的“销售额”定义：

• BI 文档一个版本；

• 数据仓库 SQL 一个版本；

• 业务知识库又一个版本；

Context Engineering 即使检索准确，也只是把冲突更高效地送进模型。Agent 最终依然需要猜哪个是真的。

Aloudata 曾将语义层视为企业自身的“世界模型”：模型、Skills、Tools、Memory 等承担不同职责，语义层负责让 Agent 理解稳定的企业业务事实，而具体场景的方法和工具使用则分别进入 Skills 和运行时规划。

因此更成熟的体系应该是：

企业语义层：管理权威业务事实
        ↓
Context Engineering：按任务检索相关语义
        ↓
Skills / Tools / Memory：补充方法、能力和历史
        ↓
LLM：理解、规划与推理

Context Engineering 不是语义层的替代品，而是语义资产进入 Agent 推理过程的“配送系统”。

哪些业务规则应该放在哪里？

企业可以用三个问题判断。

1. 这条规则改变后，是否应该影响所有应用？

如果回答“是”，通常应该进入语义层。例如“有效订单定义”一旦改变，BI、Agent 和 API 都应该统一变化，而不是分别更新 Prompt。

2. 这条规则是否需要确定性计算？

如果回答“是”，也应优先结构化到语义层或其他确定性系统。企业正式经营数据不能依赖 LLM 每次重新解释自然语言规则。

3. 这条规则是否只与当前场景或任务有关？

如果回答“是”，则适合由 Context Engineering 动态组织。例如当前分析目标、近期政策文件、用户角色、临时筛选范围和对话状态，没有必要永久写入核心语义模型。

因此，所谓“业务规则固化在哪里”，并不是选择一个统一存储库，而是建立不同确定性等级的规则分层。

Aloudata：语义层不是 Agent 的全部 Context，而是可信 Context 的底座

在 Aloudata Agent 企业级可信数据分析智能体的架构中，标准指标首先由 NoETL 可信语义层提供，指标口径、维度关系、筛选条件和权限边界由统一语义资产约束；复杂问题再由 Agentic Harness 架构进行任务拆解、工具调用和多步分析。

这意味着 Agent 不需要把所有指标 SQL、业务口径长期硬编码在 Prompt 中。例如用户问：

“为什么华南区域本月销售额下降？”

Agent 可以先从语义层获得“销售额”“华南”“本月”等确定性业务语义，再结合当前用户权限、任务历史、相关 Skill、业务知识和分析中间结果动态构造 Context。

于是不同层分别解决：

• 语义层：沉淀企业长期有效的指标、维度、业务模型与业务口径。

• Context Engineering：决定当前任务应该加载哪些语义、知识、历史、状态和工具说明。

• Skills：沉淀“销售归因应该怎么分析”这样的可复用方法。

• Agentic Harness：根据当前问题动态规划和编排执行过程。

这也解释了为什么不能简单把企业 Context Engineering 理解为“建设一个更大的知识库”。

真正可信的 Data Agent 需要的是：

稳定语义负责确定性，动态 Context 负责适应性，Agent 负责推理。

三者职责越清晰，系统越容易治理。

常见误区

误区一：把所有业务知识都塞进 System Prompt

这样可以快速完成 Demo，却很难形成企业级架构。

当规则数量增长后，Prompt 会不断膨胀，同时产生版本冲突、维护困难和上下文噪声。Anthropic 也指出，把大量复杂逻辑硬编码进 Prompt 容易形成脆弱且维护复杂的 Agent。

稳定业务事实应该被结构化、服务化，而不是长期依赖自然语言提示。

误区二：建设语义层后就不需要 Context Engineering

语义层只提供企业事实，不知道当前用户为什么提问、此前说过什么、应该调用哪个工具，也不会自动决定本轮应该加载哪些信息。

企业拥有再完善的语义资产，如果 Agent 每次把几万个指标全部送入模型，上下文效果仍然可能很差。

所以语义层解决 可信来源，Context Engineering 解决 有效使用。

误区三：Context 越完整，Agent 越准确

LLM 的注意力并不是无限资源。

高质量 Context Engineering 追求的并不是“把能找到的东西全部提供给模型”，而是找到当前任务所需的最小高信号信息集合。

因此，企业更应该追求 Right Context，而不是 More Context。

企业建设 Checklist

• 核心指标、维度和业务对象是否已经有唯一权威定义，而不是散落在 Prompt、SQL 和文档中？

• 需要跨 BI、Agent 和 API 一致执行的规则，是否已经从自然语言上下文中抽离并结构化？

• 分析方法是否与数据口径分开管理，避免把“怎么算”和“怎么分析”同时写进 Skill？

• Agent 是否能够按用户、问题和任务状态动态选择 Context，而不是每轮加载全部企业知识？

• 是否明确建立了“语义层负责事实、Skill 负责方法、Context 负责当前任务、Tool 负责执行”的治理边界？

常见问题（FAQ）

Q1. Context Engineering 可以替代语义层吗？

不能。Context Engineering 可以决定把哪些业务知识送给模型，但并不能天然保证这些知识具有唯一、可执行的数据定义。对于指标口径、维度关系和权限等需要确定性执行的规则，仍然需要语义层或其他结构化系统提供可信来源。

Q2. 所有业务规则都应该进入语义层吗？

不应该。长期稳定并决定数据事实的规则适合进入语义层；分析方法更适合沉淀为 Skill；用户临时要求、当前任务状态、相关知识和历史对话等动态信息，更适合通过 Context Engineering 按需加载。

Q3. Prompt 中还能不能写业务规则？

可以，但应区分规则性质。任务级行为约束、输出格式、当前场景要求可以进入 Prompt；如果某项规则长期决定核心指标如何计算，就不应该只依赖 Prompt，而应尽可能转化为结构化、可执行的语义资产。

Q4. Data Agent 最合理的业务上下文架构是什么？

更合理的模式是由语义层提供可信业务事实，由 Skills 提供分析方法，由 Tools 提供执行能力，由 Memory 和知识库补充历史与非结构化知识，再通过 Context Engineering 根据当前任务动态组织这些信息，最终交给模型进行推理和规划。