> ## Documentation Index
> Fetch the complete documentation index at: https://ahvn.top/llms.txt
> Use this file to discover all available pages before exploring further.
# 什么是 HeavenBase？
> HeavenBase 概览：面向 agent 的多后端统一引擎，用于结构化数据管理。
*你的数据，agent 可读可讲。*
*一个模型。多种后端。面向每一个 agent。*
## 1. 数据可观测性：数据孤岛困境
现代企业已拥有支撑智能 agent 系统所需的信息。挑战在于，这些知识分散在碎片化的基础设施中（即数据孤岛）：事务型数据库、搜索引擎、向量库、文件系统等。
对人类操作者而言，这种碎片化带来运维复杂性。对 agent 而言，则意味着**失明**。
三种模式反复出现：agent 不知道某孤岛存在、对数据源的认知已过时，或误读团队实际使用的业务词汇。以下场景为虚构，但这些失效模式在企业部署中十分常见。
孤岛与接口越多，agent 就越难发现并访问所需数据。LLM 的推理、检索与学习能力虽在持续进步，但它们无法*推断从未被展示过的数据的存在*。
采购团队让 agent 查找「本月到期的全部供应商合同」。agent 可访问五个系统：两个涵盖**交易与订单**，三个涵盖代码与文档。
它查询交易与订单来源——多数有效合同所在之处——并返回**73 条结果**，附带一份自信满满的摘要。
但还有**43 份合同**仅以扫描 PDF 修正案的形式存在于法务团队的**文档库**中。
该文档库已编入企业搜索索引，但法务团队从未将其注册为合同数据源。
从 agent 视角，列表是完整的——它检查了与交易和订单相关的所有来源。
从业务视角，43 笔续签在供应商发票到来之前完全不可见。
> **要点**：agent 无法查询它不知道存在或与任务无关的孤岛。
客服 agent 起步时有一份清晰的数据地图：Salesforce 中的客户上下文、NetSuite 中的账单、Confluence 中的产品 FAQ。
**六个月后**，产品团队将现场服务报告中的**兼容性说明**加载到新的向量数据库。**agent 的数据源目录从未更新。**
客户询问其 2019 款控制器是否兼容最新固件。agent 查询 Confluence 和 Salesforce，自信地引导客户完成升级路径。
向量索引显示该组合不受支持。客户预约了一次本可完全避免的服务上门。
> **要点**：一旦数据版图发生变化而 agent 的地图未随之更新，数据可观测性就会衰减。
财务分析 agent 配备了一份详尽且最新的手册：每种场景该查什么、去哪查。
随后财务团队一个常规请求使其失灵：「生成 Q3 的区域 **DFA** 报告。」
「DFA」？agent 完全不知道那是什么意思。
按手册，区域指标存放在 `regional_performance` 表中，于是 agent 查询该表——一无所获。
原来 DFA 代表 **Double-Factor Analysis（双因子分析）**——财务团队沿用多年的电子表格方法论。
报告存放在文件驱动器上，文件名形如 `FY25/Q2/Regional_DFA_v3.xlsx`。手册从未解释该术语；它默认人人都已知晓。
> **要点**：即便数据源地图精确，当领域词汇未纳入可观测层时仍会失败。
深度研究 agent 可对专业文献、公司知识与数据本体进行向量搜索。
任务要求总结时间序列预测领域所有近期论文的趋势。
它使用**向量搜索**找到相关论文，然后总结**排名前 20** 的结果。
它做后续检查以查找遗漏论文，又找到**20 篇**，修订摘要后自信地提交报告。
但 20 只是向量搜索的**默认 top-k**。索引中实际有 100 多篇相关论文。
> **要点**：知道查「什么」和「哪里」还不够——「多少」同样重要。
某 agent 正在制作 margin 报告。它准确找到了自认为需要的所有内容：收入数据、成本数据及其他相关数字。
计算 margin 时，它用收入减去成本——足够直接。
缺失的一环是**税**：还必须从收入中扣除税，且各州税率不同。
agent 从未建立关联，因为「tax」从未出现在其搜索路径中——它查询了「margin」「revenue」「cost」，无一指向 tax。
还有一份单独的「tax computation」手册，其中有一段关于 margin 报告期间税项计算的说明。agent 找到了该手册，但断定与 margin 报告无关，未阅读便继续。
> **要点**：找到正确数据只是工作的一半——找到正确手册与操作指南同样重要。
***
agent 在真实场景中失败，首要原因往往并非不够智能，而是缺少**数据可观测性**。
认识到这一点后，许多企业试图通过数据仓库、数据湖或带重度 ETL 的新型数据库，将数据孤岛整合到单一系统中。这一路径常导致性能次优、运维复杂度上升，最重要的是迁移成本高昂。
agent 系统不需要新的数据源，而需要一种**直观、统一**的方式访问既有数据源。
这正是 HeavenBase 的切入点。
## 2. HeavenBase 方案：面向 Agent 的多后端引擎
HeavenBase 位于 agent 与数据之间；它不取代你的数据库、搜索引擎或向量库——而是连接它们。
HeavenBase 提供**统一数据接口**，抽象不同后端的复杂性，原生面向 agent，使其能在各孤岛间发现、查询、操作与组织数据，而无需知道数据实际存放位置或如何查询。
开始使用 HeavenBase 时，只需创建工作区，告知可用的数据后端，然后连接数据源并注入业务知识。技术上，HeavenBase 采用直观的*面向对象数据模型*来管理知识与数据。你可以在同一个逻辑工作区中处理数据与业务知识，用同一接口编排 agent、管理工作流。与此同时，HeavenBase 承担物理存储、查询规划与跨后端执行的复杂性，让你与 agent 专注于推理与决策。
当所有数据与决策流经同一逻辑工作区时，**数据洞察**便会浮现。
例如，客服 agent 可通过一个 HeavenBase 工作区，同时访问订单记录、产品政策、历史对话与内部备注，回答客户问题。
源数据、元数据、领域知识、agent 轨迹、工具、Prompt、用户偏好与统计，都在 HeavenBase 工作区中以同一逻辑数据模型统一呈现，因此可由 **meta-agent** 一致管理。这使你可以*主动*或*按需*将洞察反馈给 worker agent，确保它们始终把握全局，并在正确时机访问正确信息。
## 3. HeavenBase 提供什么
作为**个人用户**，你可以将 HeavenBase 用作 agent 的*记忆层*，作为 agent 记录思路、任务、你的偏好及其他服务所需信息的笔记本。HeavenBase 还提供*即插即用的 MCP 服务器与 Skills*，供 agent 使用。
作为**企业用户**，你可以立即让 agent 与数据对话，并*持续从数据中学习*，获得有价值洞察、改进决策。你可以选择以最顺手的形式暴露接口：Python ORM 表达式、MongoDB 风格 JSON 查询、SQL、Python 程序或自然语言指令，HeavenBase 会帮助 agent 将其翻译为跨合适数据存储的高效物理查询。
作为**开发者**，你可以使用 HeavenBase CLI 与 Python SDK，更快构建 agent 与应用：创建工作区、定义实体、连接后端，然后专注业务逻辑与 agent 工作流，数据管道与管理交给 HeavenBase。
作为**管理者或平台负责人**，你可以将 HeavenBase 用作 agent 系统的数据平面，监控交互、整合业务知识，并持续改进数据版图。
TODO: HeavenBase GUI for catalog and observability; data governance and lineage features
## 进一步探索
**相关资源：**
* [设计哲学](/zh/introduction/philosophy) - 设计价值与取舍
* [架构](/zh/introduction/architecture) - 系统结构
* [快速开始](/zh/quickstart/installation) - 几分钟内跑起来