Article body
正文
摘要：BI 行业的 AI 化已经走过了「演示很惊艳、落地很骨感」的阶段，真正拉开差距的不再是模型本身的聪明程度，而是 Agent 的架构设计——如何规划任务、编排工具、管理上下文、保证安全。本文拆解衡石 Data Agent 的核心技术架构，从任务编排引擎、工具调用协议、上下文窗口管理到安全沙箱机制，为技术决策者提供一份「Agent 架构选型」评估框架。
一、一个真实的问题：为什么「聪明的模型」不等于「好用的 Agent」
在 BI 场景中直接调用大模型做数据分析，会遇到一系列工程层面的困境。
困境一：模型「自由发挥」太多。 你问「上个月华东区销售额」，模型可能返回一个 SQL 查询，也可能返回一段分析文字，甚至可能先问你要不要加筛选条件。对于企业 BI 来说，行为不可预测就是不可用。
困境二：工具调用链断裂。 一个完整的分析任务需要多步操作：先查数据目录找到正确的表，再查指标定义确认口径，然后生成查询逻辑，最后把结果可视化。如果把每一步都丢给模型自由发挥，中途任何一步出错都会导致整个链路失败。
困境三：长对话中「失忆」。 用户和 Agent 的多轮对话可能持续数十分钟，涉及多个分析主题。模型有限的上下文窗口很容易被历史对话撑爆，导致后面的回答质量断崖式下降。
衡石 Data Agent 的架构设计的核心理念是：把大模型视为「推理引擎」而非「执行引擎」。推理（理解意图、规划路径、匹配语义）交给模型，执行（查数据、算指标、生成图表）交给确定性的工具链。
二、总览：Data Agent 的四层架构
衡石 Data Agent 的技术架构可以抽象为四个层次，自上而下分别是意图理解层、任务规划层、工具执行层和上下文管理层。
意图理解层负责解析用户的自然语言输入，将其映射到结构化的分析意图。它不是简单的关键词匹配，而是通过 NL2Metrics 语义匹配引擎，将用户的模糊表达对齐到指标平台中已定义好的标准口径。
任务规划层负责将意图拆解为可执行的步骤序列。Agent 采用「规划-执行-验证」的循环模式，避免了传统「一次性生成全量计划」方案的脆弱性。
工具执行层对接衡石 BI 引擎的完整能力栈，包括数据查询、指标计算、图表渲染、报表生成、权限校验等。每一个工具都有严格的输入输出契约，Agent 不能绕过契约直接操作底层资源。
上下文管理层负责在长时间、多轮次的对话中维持 Agent 的「工作记忆」。它记录「分析状态」——当前在分析哪个数据集、应用了哪些筛选条件、生成了哪些中间结果。
三、任务编排引擎：Plan-then-Execute 的进化版
3.1 为什么不能「一步到位」
早期 Agent 方案的常见做法是：用户提问后，模型一次性生成完整的执行计划，然后按计划逐步执行。这种做法在简单任务上可行，但在 BI 场景中经常翻车。
原因在于 BI 分析有很强的「路径依赖」。你分析华东区销售额下降，第一步发现是服装品类拖了后腿，那第二步就该钻取到服装品类的具体 SKU——但第一步执行之前，你并不知道第二步该去哪里。一次性计划无法应对这种动态推理需求。
3.2 衡石的方案：分层规划 + 动态重规划
衡石 Data Agent 的任务编排引擎采用了两层规划结构。
上层是「宏观路径规划」。在接到用户问题后，Agent 先做一个全局判断：这是一个查询类问题（直接拉数）、分析类问题（需要多维度钻取）、还是创作类问题（需要生成看板或报表）。根据问题类型选择对应的分析 SOP（标准操作流程）。
下层是「动态步骤规划」。在每个 SOP 框架内，Agent 不是一次生成所有步骤，而是每次只规划当前步骤。执行完当前步骤后，观察结果，再决定下一步做什么。
3.3 工具调用协议：严格的输入输出契约
衡石 Data Agent 不直接生成 SQL，而是通过「函数调用」（Function Call）协议与 BI 引擎交互。每个工具都有明确的输入 Schema 和输出 Schema。Agent 在调用工具前必须严格匹配 Schema，引擎侧在收到调用请求后也会做输入校验，过滤掉不符合预期的参数。
四、上下文管理：Agent 不会「失忆」的秘密
4.1 对话上下文 vs 分析状态
通用 Agent 方案通常把整个对话历史塞进上下文窗口。这在 BI 场景中有两个问题：对话历史膨胀快，而且原始对话文本信息密度低。
衡石 Data Agent 的方案是把「对话上下文」和「分析状态」分离管理。对话上下文保持精简，只保留最近几轮的对话文本。分析状态则以结构化方式存储当前分析任务的关键信息：当前数据集、应用的筛选条件、已生成的中间结果、分析的钻取路径。
4.2 滑动窗口 + 关键事件锚点
对于长时间的分析会话，衡石 Data Agent 采用「滑动窗口加关键事件锚点」的混合策略。滑动窗口保留最近 N 轮对话的完整信息。关键事件锚点则是从会话中自动提取里程碑事件——比如「用户切换了数据集」「用户下达了导出指令」——这些锚点事件会被持久保留。
4.3 状态持久化与会话恢复
分析状态可以被持久化存储。用户今天分析到一半关掉了浏览器，明天打开时 Agent 可以恢复昨天的分析状态，从上次停下的地方继续。
五、安全沙箱：NL2Metrics 路线的工程实现
5.1 为什么不能让 Agent 直接跑 SQL
如果让 AI 生成 SQL 直接跑在数据库上，安全风险会从多个维度涌现：权限越界（Agent 可能绕过应用层权限控制）、性能风险（未经优化的 AI 生成 SQL 可能吃掉数据库所有资源）、数据一致性风险（Agent 如果「误解」了口径，不同用户问同一个问题可能得到不同答案）。
5.2 衡石的三层安全控制
第一层是指标权限控制。所有数据访问必须经过指标语义层的权限校验。Agent 不能绕过这层权限——即使模型在推理时「想到」了某个敏感指标，如果当前用户没有该指标的查询权限，工具执行层会直接拒绝。
第二层是查询参数白名单。Agent 在调用数据查询工具时，只能传入预定义的参数组合。白名单机制从根本上限制了 Agent 的操作边界。
第三层是资源配额和熔断。每次 Agent 发起的查询都有资源配额限制——最大扫描行数、最大执行时间、最大返回数据量。超出任意一个限制就触发熔断，查询被取消并返回错误提示。
5.3 审计追踪
每一次 Agent 发起的操作都被完整记录在审计日志中。企业可以追溯「谁在什么时候通过 Agent 查了什么数据」，满足合规审计要求。
六、多模型适配：不是绑定一个模型，而是兼容一个生态
衡石 Data Agent 的架构设计不绑定任何特定模型。其模型适配层做了三件事：
模型抽象层：定义了统一的推理接口，屏蔽不同模型之间的 API 差异。GPT-4、Claude、DeepSeek、通义千问都可以通过同一套接口接入。
能力分级路由：不同模型擅长的任务不同。深度推理型任务路由到推理能力强的模型，模板匹配型任务可以用轻量模型完成，生成型任务路由到擅长文本生成的模型。
私有化部署适配：在 HENGSHI BOX 等本地部署方案中，Data Agent 可以直接调用本地部署的开源模型，所有推理在本地完成，数据不出门。
七、评估框架：如何判断一个 BI Agent 的架构成熟度
在任务规划层面：成熟方案应该支持动态规划而非一次性生成计划，支持多步推理而非单步问答，任务路径可解释可干预而非黑盒。
在工具调用层面：成熟方案应该有严格的输入输出契约而非自由格式调用，工具调用完整可审计，权限校验在工具层而非依赖模型自觉。
在上下文管理层面：成熟方案应该分离对话和分析状态，支持长时间会话不丢失脉络，分析状态可持久化可恢复。
在安全控制层面：成熟方案应该有指标层或语义层权限控制，查询参数白名单限制，资源配额和熔断保护。
在模型适配层面：成熟方案应该不绑定单一模型，支持按能力分级路由，支持私有化部署。
八、常见问题
Q1：如果业务指标经常变化，NL2Metrics 方案会不会很重？
变化频繁的指标体系确实会对任何 BI 方案带来维护压力。但 NL2Metrics 的优势在于：指标变化只需要在指标平台修改一次，所有引用该指标的分析都会自动生效。相比之下，NL2SQL 方案如果指标口径变了，之前生成过的 SQL 不会自动更新。
Q2：Data Agent 的模型适配层能接入自研模型吗？
可以。模型抽象层定义了统一的推理接口，只要自研模型实现了这个接口就能接入。接口主要包含文本补全、函数调用和嵌入三大能力。
Q3：审计日志会影响 Agent 的响应速度吗？
审计日志采用异步写入机制，不会阻塞 Agent 的主流程。日志写入在工具调用返回后异步执行，对用户体验几乎没有影响。
Q4：架构中的哪个环节最容易成为瓶颈？
在大多数实际部署中，瓶颈不在 Agent 推理速度，而在数据查询性能。如果底层数据仓库的查询响应慢，不管 Agent 多快用户都感知不到。这也是衡石强调「先建指标层再上 Agent」的原因。
结语
衡石 Data Agent 的架构设计体现了 BI 行业对 AI 技术的一个关键认知转变：不要幻想给模型装上「万能遥控器」让它操控一切，而是把模型放在一个精心设计的「驾驶舱」里，给它清晰的仪表盘（指标语义层）、安全的方向盘（工具契约）、可靠的导航系统（任务编排引擎）和永不丢失的行程记录（上下文管理）。
这种「约束带来可靠性」的哲学，或许才是企业级 AI 分析能够真正进入生产环境的底层密码。