每次都 MasterControl Seventeen

TL;DR 治理式企业分析：LLM 只解析意图，由确定性策略执行预先批准的分析程序并返回结果与证据；在 440 次运行中，策略执行 110/110 达标，而运行时规划智能体 0/330 达标。

问题

问题背景：企业级数据分析正从人工写 SQL 转向以语言模型为核心的问答。业界关注点已从“能否生成一个答案数字”转移到“这个数字是否代表明确、可审计的统计口径”——即人口、时间区间、度量定义、支持记录等语义治理。

现有方法局限：当前主流的运行时规划 Agent（例如让 8B 模型直接决定如何查询数据、选择工具并生成 SQL）存在根本性不稳定。它们在每次回答时即时发明测量方法：可能忽略预定义的数据版本，错用比较或窗口逻辑，且输出的 SQL 过程难以保证附带完整证据。具体表现：在 330 个运行时规划实例中，没有一个最终程序在开发快照和四个留出变体上完整匹配“答案+证据”契约。这种局限不是参数规模问题，而是在缺少固定语义和策略约束时，模型自由组合操作步骤的固有风险。

为什么难/重要：核心矛盾是表达力与治理可控性之间的权衡。要解决这个问题，不能简单禁止模型生成代码，而是要设计一个受限但有完备性的分析代数。论文中的构造性翻译从有限关系和 first-order satisfaction 出发，加入聚合、比较、窗口、排名、版本化相似度，从而证明在定义好的分析类内，每个规范都有精确的有限程序。同时可重放性要求固定治理意义、策略、数据、kernel 状态、数值规则和输出契约，这在企业中意味着相同问题必须得到相同结果和证据。

行业类比：这与 LLM 辅助金融合规审查类似：模型可以理解用户意图，但最终执行必须由通过审计的规则引擎完成，而非每次自由生成计算过程。

核心洞察

• - **意图与方法分离是治理式分析的核心控制点**: 论文将语言模型限制为意图解释，由确定性策略执行预批准分析程序，对比当前流行的 runtime tool planning agent。其独特性在于放弃提升模型推理能力，转而通过架构约束缩小自由裁量空间，从而保证可复现与可审计。330 次运行时规划无一满足完整 answer-and-evidence 契约，而策略执行 110/110 匹配，说明在合规敏感场景中，减少运行时决策风险比单纯增强模型能力更有效。
• - **“回答+证据”契约应作为分析系统的验收标准**: 多数 agent 评估只关注最终答案或任务成功率，该工作则要求程序同时返回结果与证据（查询逻辑、数据快照等）。运行时规划即便偶尔得到数值，也无法稳定提供完整证据链；策略执行则保证证据可重放。其视角差异在于将可验证性前置，而非事后审计。工程启示是，生产级分析 API 应输出方法来源与支撑记录，而不只是一个数字，以支撑合规与复盘。

方法

输入 → 关键模块 → 输出

输入为自然语言问题、受治理的数据快照以及预定义策略库。系统不直接处理自由文本到查询，而是先由 意图解释器（本文使用 Qwen3-8B）将问题解析为结构化的意图表示，包括分析对象、时间窗口、指标定义与所需证据范围。该解释器只负责“用户想问什么”，不生成 SQL 或选择工具。

随后，确定性策略引擎 根据意图映射到预先批准的分析程序。这些程序用一个小型 类型化分析代数 表达：以有限关系和一阶满足为核心，扩展聚合、比较、窗口、排名和版本化相似度。每个操作都有明确类型签名和数据血缘，因此可证明在该代数范围内存在精确的有限程序（范围完备性）。执行时，分析内核按固定数值规则和数据版本重放，生成结果与证据清单。

输出是一个完整契约：结果（数值或表格）+ 证据（数据切分、定义、版本、支撑记录）。策略确保同一意图始终选择同一程序，从而保证可复现性。

与运行时工具规划（模型动态决定查询路径、生成 SQL、调用工具）不同，本方法将方法选择从推理阶段剥离，交给治理策略静态固化，以牺牲部分灵活性换取结果与证据的确定性和审计完整。

实验

实验设计

论文设计了一项受控对比，共 440 次运行，比较两种回答相同分析问题的机制：

• Runtime-planning agents：三个独立的 8B 开源模型在运行时决定如何查询数据、选择工具并生成 SQL 过程。共产生 330 个 episodes。
• Policy-executed analyzer：Qwen3-8B 仅解释用户意图，随后确定性策略选择并执行预先批准的分析程序。共产生 110 个 episodes。

测试覆盖一个开发快照和四个保留变体。评估标准是完整匹配 answer-and-evidence contract，即返回的结果和证据同时正确。

关键发现

• 在 330 个 runtime-planning episodes 中，没有最终过程匹配完整契约（0/330）。
• Policy-executed analyzer 在 110 个 episodes 中全部匹配（110/110）。

作者谨慎指出，这是 configuration-specific 结果，并非证明 runtime agents 在其他设计下不能成功。论文的核心主张是：通过限制为预批准程序，可以在保留分析表达力（覆盖聚合、比较、窗口、排名、相似度）的同时获得可重放性。

与基线对比的深度解读

Runtime-planning 的失败可能源于 LLM 在生成 SQL 和选择工具时难以一致地维持语义约束与证据链接；而 policy-executed 将“方法选择”从推理中剥离，用确定性策略保证可预期性。但对比并非完全对称：runtime 方使用三个未指明模型，policy 方仅用 Qwen3-8B 做意图解释，任务更简单。该结果提示：对于需要严格审计和复现的企业分析，将“意图识别”与“程序执行”解耦是可行的治理架构，但需预构建覆盖足够的政策目录。

行业影响

落地场景

在 可审计性 要求高的行业，如 金融合规、医疗临床统计、企业财务分析，可使用这一受控分析框架。典型 use case：

• 电商平台 的商家经营分析助手：用户提问“上季度退货率最高的品类有哪些？”，Qwen3-8B 仅解析意图，策略引擎选择预批准的 SQL 分析程序，返回结果与退货明细证据。
• 金融服务 的反洗钱调查：分析师询问“某客户近 30 天跨境交易金额统计”，系统按固定计算路径给出结果和证据列表，满足监管留痕要求。

商业价值

• 降低合规风险：避免 LLM 运行时生成错误 SQL 导致的指标失真，减少监管处罚概率。
• 减少人工审核成本：预批准程序保证结果可复现，无需逐次核对计算逻辑，节省数据团队人力。
• 提升决策可信度：附带证据让业务用户快速验证，加速从数据到决策的闭环。

论文对照实验显示，运行时规划 agent 在 330 次任务中无一完全符合“答案+证据”契约，而政策执行分析器在 110 次任务中全部符合，为受控场景提供了强可靠性论据。

与现有产品/工作流接口

可作为 受控分析网关 嵌入现有 BI 栈：在 LLM 与数据库之间加入策略引擎，下游连接数据仓库或指标层。与 指标平台（如 dbt 语义层）集成时，将预定义指标程序注册到策略目录，LLM 将自然语言映射到指标，策略选定程序执行。部署为独立微服务，不需要替换现有数据仓库，适合渐进式引入。

局限

• **表达范围受限**：论文定义的 analytical algebra 仅覆盖关系操作、聚合、比较、窗口、排名和版本化相似度，并非通用编程系统。预批准程序目录无法覆盖所有可能问题，需要持续人工扩展。对于超出现有分析类别的新问题，系统需重新设计程序并批准，扩展成本高。
• **实验规模与模型代表性有限**：对比仅使用三个开源 8B 模型（未列名）和 Qwen3-8B，总运行次数 440 次。更大参数模型或专有模型可能具备更强的运行时规划能力，论文也明确声明结果是 configuration-specific，不能泛化为所有 agent 设计均失败。
• **治理假设依赖固定语义**：replay 保证基于固定的治理含义、策略、数据、核状态和数值规则，这要求严格版本管理和前期定义。对于快速变化的业务指标、非结构化数据或需要动态语义的场景，该方法适用性下降，预批准程序库的维护成本可能超过运行时动态规划的灵活性。