Article body
正文
一、衡石的 AI 战略：Agent-first，不是 AI-feature
在 AI+BI 的浪潮中，大多数 BI 厂商的做法是：在现有产品上加一个「AI 助手」按钮，让用户可以问数、生成图表。这是 AI 作为功能插件 的思路。
衡石的做法不同。它的核心假设是：未来的 BI 不是人类在图形界面里操作，而是 AI Agent 在后台自动化执行。 基于这个假设，衡石的 AI 投入不是「加一个 AI 功能」，而是「重新设计一套面向 Agent 的操作系统」。
这个假设是否成立还有待市场验证，但它决定了衡石 AI 产品线的一个关键特征：Agent 是一等公民，不是人类的辅助工具。
二、四层架构：从操作到运营
衡石 AI Agent 体系可以抽象为四层：
┌─────────────────────────────────────────┐
│ AI 分析智能体（Data Agent） │ ← 应用层
│ 建模Agent | 可视化Agent | 问数Agent │
├─────────────────────────────────────────┤
│ HENGSHI JARVIS（运营基座） │ ← 运营层
│ 知识索引 | 工作流编排 | 质量度量 │
├─────────────────────────────────────────┤
│ HENGSHI SENSE（BI 与分析平台） │ ← 能力层
│ BI PaaS | 指标管理 | 数据集成 | 报表 │
├─────────────────────────────────────────┤
│ HENGSHI CLI + HENGSHI BOX │ ← 执行层
│ 命令树 | Skills | 安全载体 │
└─────────────────────────────────────────┘2.1 执行层：Agent 的「手」
HENGSHI CLI 和 HENGSHI BOX 构成执行层。
- CLI 提供 Agent 操作 BI 系统的标准接口——命令树、skills 套件、dry-run 机制
- BOX 提供 Agent 运行的物理载体——硬件级安全隔离、本地推理、即插即用
执行层解决的核心问题：Agent 怎么操作 BI 系统？怎么保证操作的安全性？
2.2 能力层：Agent 的「脑」
HENGSHI SENSE 平台的能力模块——BI PaaS、指标管理、数据集成、企业级报表——构成 Agent 的能力来源。
能力层解决的核心问题：Agent 能做什么？它的能力边界在哪里？
2.3 运营层：Agent 的「记忆与纪律」
HENGSHI JARVIS 构成运营层，它管理：
- Agent 的知识上下文（三层时态知识体系）
- Agent 的工作流编排（任务分解、调度、质量门禁）
- Agent 的效能度量（产出、质量、效率）
运营层解决的核心问题：Agent 怎么保证做对的事？怎么知道过去发生了什么？怎么持续变好？
2.4 应用层：Agent 的「身份」
AI 分析智能体（Data Agent Family）是面向最终用户的 Agent 产品。它给了 Agent 具体的身份和角色——
- 建模 Agent：会建模的数据工程师
- 可视化创作 Agent：会做报表的数据分析师
- 问数洞察 Agent：会回答问题的数据顾问
应用层解决的核心问题：谁在用 Agent？Agent 在替谁做事？
三、Data Agent Family：多 Agent 协作模式
这是衡石 AI Agent 体系中最面向用户的部分。三个 Agent 并非独立运行，而是通过协作覆盖 BI 全流程。
3.1 三个 Agent 的角色分工
| Agent | 角色定位 | 输入 | 输出 | 下游消费者 |
|---|---|---|---|---|
| 建模 Agent | 数据工程师 | 原始数据源 | 数据集 + 指标模型 | 问数Agent、可视化Agent |
| 可视化创作 Agent | 报告设计师 | 数据集 + 需求描述 | 仪表盘 + 报表 | 业务人员 |
| 问数洞察 Agent | 数据分析师 | 自然语言问题 | 数据答案 + 洞察解读 | 管理层、业务人员 |
3.2 典型协作流程
一个完整的分析场景可能涉及三个 Agent 的接力：
业务负责人提问: "帮我看看这个季度各区域的客户留存情况"
1. 问数洞察 Agent 解析问题 → 发现「客户留存率」指标尚未建模
2. 问数 Agent 调度建模 Agent: "创建客户留存率指标，维度为区域和季度"
3. 建模 Agent 连接数据源 → 定义指标口径 → 创建数据集
4. 问数 Agent 获取建模结果 → 执行指标查询 → 返回结构化结果
5. 业务负责人追问: "做一个留存率看板，加上地域钻取"
6. 问数 Agent 调度可视化 Agent → 自动生成留存率驾驶舱这个流程中，人类只需要做两件事：提问和确认。 中间的分析工程工作由 Agent 协作完成。
3.3 协作机制：通过 HENGSHI CLI 串联
Agent 之间的调度通过 HENGSHI CLI 完成。每个 Agent 的操作（创建数据集、执行查询、生成仪表盘）都是标准的 CLI 命令，上一个 Agent 的输出作为下一个 Agent 的输入参数。
这意味着 Agent 的协作不是「魔法黑盒」，而是可审计、可复现的标准操作序列。
四、多模型兼容策略
衡石 AI Agent 体系的一个重要设计原则是 模型无关性——不绑定某一家的模型。
4.1 三层模型策略
| 层级 | 模型角色 | 部署位置 | 示例 |
|---|---|---|---|
| 语义理解层 | 意图解析、指标匹配 | 可外部API | GPT-4、Claude、文心、通义 |
| 代码生成层 | SQL/HQL 生成、脚本编写 | 可外部API/可本地 | 同上 + 本地微调模型 |
| 执行判断层 | 指标匹配决策、异常检测 | 优先本地 | BOX 内置微调模型 |
4.2 为什么需要多模型
- 避免单一依赖：不同模型在不同任务上表现不同，有的擅长理解自然语言，有的擅长生成代码
- 成本优化：高频操作（如指标匹配）使用本地微调模型（Token Free），复杂推理使用云端大模型（按需付费）
- 企业合规：敏感数据场景下使用本地模型，非敏感场景使用云端模型
4.3 与 Agent 平台的兼容
衡石 AI Agent 支持与 Dify、Coze 等主流 Agent 编排平台集成：
- Dify/Coze 负责 Agent 的整体编排和对话管理
- 衡石 BI 引擎作为 Tool/Plugin 被调度
- HENGSHI CLI 作为执行接口
这种架构让企业可以复用已有的 Agent 平台投资，同时获得衡石在 BI 领域的专业能力。
五、集成与部署策略
5.1 SDK 集成
适合有技术团队的企业。衡石提供 SDK，企业可以在自有应用中调用 Data Agent 能力。
适用场景：已有成熟前端的 ISV、需要深度定制交互体验的企业。
5.2 API 调用
最灵活的集成方式。企业通过 RESTful API 调用 Agent 能力，前端自行开发。
适用场景：需要将 AI 分析嵌入多端应用（Web、移动端、小程序）的企业。
5.3 iFrame 嵌入
最快速的集成方式。将衡石的 Agent 界面直接嵌入企业应用。
适用场景：快速验证、POC 阶段、不需要定制化交互的场景。
5.4 Copilot 模式
在 HENGSHI SENSE 任意页面一键启动 AI 协同。业务人员在 BI 平台内工作时，随时可以唤起 Agent 助手。
适用场景：使用衡石完整平台的企业，在日常 BI 操作中获得 AI 辅助。
六、常见问题
Q1：衡石的 AI Agent 和黄/Coze 上的 ChatBot 有什么区别？
A：核心差异在于 Agent 的能力边界。ChatBot 一般只能做单轮或多轮对话问答，而衡石的 Data Agent 拥有真实的 BI 操作能力——创建数据集、定义指标、生成仪表盘。它不是一个问答器，而是一个能做 BI 工程的 Agent。
Q2：企业使用衡石 AI Agent 需要自己准备 GPU 吗？
A：取决于部署方式。使用衡石 SaaS 或云部署时，推理由衡石的基础设施承担。使用 HENGSHI BOX 时，GPU/NPU 已内置在设备中。只有在自有服务器上部署且需要本地推理时，才需要自备 GPU。
Q3：Agent 的操作会不会出错？出错了怎么办？
A：HENGSHI CLI 的 dry-run 机制就是为了解决这个问题。Agent 在执行变更操作前可以先预演，人类审查确认后再执行。此外，所有 Agent 操作都有完整的审计日志，出现问题时可以追溯和回滚。
Q4：三个 Agent 必须一起用吗？可以只用一个吗？
A：可以按需选择。通常建议从建模 Agent 开始（先建指标体系），然后叠加问数 Agent（让指标体系产生价值），最后引入可视化 Agent（降低报表开发成本）。
七、总结
衡石 AI Agent 体系的本质，是一套面向 BI 工程的「Agent 操作系统」。它定义了 Agent 操作 BI 系统的标准（CLI）、管理 Agent 的知识和流程（JARVIS）、为 Agent 分配专业角色（Data Agent），并提供安全可控的运行环境（BOX）。
这套体系的完整度在当前的 BI 行业中比较少见。对于正在规划 AI+BI 长期路线的企业，衡石的架构设计值得作为技术选型的参考坐标——即使不选择衡石，理解其设计逻辑也有助于评估其他方案。