关键词：Context Layer、上下文层、RAG、企业知识库、AI Agent、MCP、知识治理

本文主要参考 Atlan 官网公开的 Context Layer 系列资料（链接见文末），结合企业知识问答场景整理而成。文中涉及的厂商统计数据均为厂商自述，引用时已注明出处。

---

写在前面

做过企业 RAG 项目的同学，大概都经历过这样的阶段：

• Demo 阶段效果很好，领域专家一问就露馅；
• 召回率调到很高了，答案还是"看起来对、其实错"；
• 同一个问题，换个问法、换个人问，得到不同的答案；
• 制度更新了，AI 还在引用旧版本。

这些问题大多不是模型能力的问题，也不是向量检索调参能解决的问题。它们有一个共同的根源：AI 拿到的是"文本"，而不是"经过确认的企业知识"。

Context Layer（上下文层）就是为解决这个问题而提出的一层架构。本文尝试讲清楚四件事：

1. 什么是 Context Layer；
2. 为什么需要它；
3. 它为什么能提升 RAG 的准确性（附 6 个例子）；
4. 哪些内容应该放进去，哪些不应该。

---

一、什么是 Context Layer

1.1 一句话定义

Atlan 对 Context Layer 的定义是：

“A context layer for AI is the system that turns your company’s knowledge, expertise, and norms into machine-usable context for AI agents.”

上下文层是一个系统，它把企业的知识、经验和规范转化为 AI Agent 可以直接使用的上下文。

这里的三个词各有所指：

维度	含义	例子
知识 Knowledge	可信的数据资产、定义及其来源	"A 级客户"是什么意思、出自哪份制度
经验 Expertise	成文的流程与做法	月结怎么做、异常订单怎么排查
规范 Norms	权限与必需的审批	谁能看薪资口径、超 5000 元报销需总监批

1.2 它在架构中的位置

Context Layer 是位于"底层数据/文档系统"和"上层 AI 应用"之间的一层：

┌──────────────────────────────────────────────────────────┐
│  AI 应用：问答助手 / Copilot / Agent / BI 助手               │
└───────────────────────────▲──────────────────────────────┘
                            │  MCP / API / SQL
                            │  按提问人权限裁剪、带引用
┌───────────────────────────┴──────────────────────────────┐
│  Context Layer（上下文层）                                   │
│  术语定义 · 指标口径 · 业务规则 · 出处与血缘 · 权限策略 · 决策记录 │
│  —— 每一条都有负责人、版本、有效期、认证状态 ——                  │
└───────────────────────────▲──────────────────────────────┘
                            │  抽取 · 起草 · 人工确认
┌───────────────────────────┴──────────────────────────────┐
│  数据与文档：数据仓库 · 业务系统 · 制度文档 · Wiki · 工单 · 代码库 │
└──────────────────────────────────────────────────────────┘

有两条重要的设计原则：

“The context layer guides reasoning; it does not store the data.”
上下文层负责引导推理，本身不存储业务数据。

“Context doesn’t come from a prompt. It comes from a pipeline.”
上下文不来自提示词，而来自一条流水线。

第一条说的是边界：订单、客户、薪资这类业务数据仍在业务系统里，上下文层只存"关于这些数据的知识"。第二条说的是方法：靠在 Prompt 里多写几句说明解决不了问题，需要一条能持续生产、校验、更新上下文的工程流水线。

1.3 它和已有的东西有什么不同

很多人第一反应是："这不就是知识库 / 数据目录 / 语义层 / 知识图谱吗？"区别在于服务对象和交付时机：

	数据目录	语义层	知识图谱	RAG 知识库	Context Layer
回答的问题	我们有什么数据？	BI 里这个指标是什么意思？	什么和什么相连？	哪段文字和问题最像？	AI 在推理时应该怎么理解这些内容？
服务对象	人	BI 报表	实体关系查询	LLM	AI Agent
推理时交付	否	仅指标定义	仅结构	文本片段	定义、出处、策略、决策历史
按提问人执行权限	否	否	否	通常否	是
内容是否经过认证	部分	是（仅指标）	视情况	否	是

Atlan 有两句话概括得很到位：

“The catalog tells you a column exists. The context layer tells the agent what it means and whether the requester is authorized.”
目录告诉你某一列存在；上下文层告诉 Agent 它是什么意思，以及提问人有没有权限。

“The knowledge graph shows you the wiring; the context layer shows whether the wire is live, who certified it, and where it’s authorized to flow.”
知识图谱展示接线；上下文层展示这根线是否通电、谁认证的、允许流向哪里。

---

二、为什么需要 Context Layer

2.1 企业 AI 的落地困境

Atlan 在其官网引用了几组行业数据：

• 95% 的生成式 AI 试点项目未能进入生产（MIT，State of AI 2025）；
• 到 2026 年，60% 的 AI 项目会因数据准备不足面临被放弃的风险（Gartner，2025 年 2 月）；
• 在投产前放弃 AI 项目的企业比例，一年内从 17% 上升到 42%。

缺乏可靠上下文的 AI 会出现三类典型失效：幻觉、相互矛盾（不同 Agent 对同一问题给出不同答案）、基于过期或越权的信息作答。

2.2 更大的上下文窗口不是答案

一个常见的想法是：模型窗口越来越大，把文档都塞进去不就行了？

“A million-token window of raw documents is still a million unverified tokens.”
塞满原始文档的百万 token 窗口，仍然只是一百万个未经验证的 token。

窗口大小解决的是"能看多少"，解决不了下面这些问题：

• 看到的两份文档互相矛盾时，该信哪一份？
• 这份文档是不是已经作废了？
• 这条规则适不适用于当前提问的人？
• 当前提问的人有没有权限看到这段内容？

而且内容越多不一定越好。Atlan 在 How Much Context Is Enough 一文中引用的研究指出，在复杂任务上，模型的有效上下文可能比标称窗口小得多（“up to 99% lower”）。无关内容越多，干扰越大。

2.3 规模化时的三堵墙

Atlan 把企业规模化部署 Agent 时遇到的问题概括为三堵墙：

1. 起草墙：“Building the agent takes five minutes. Giving it business context takes five months.” 搭一个 Agent 只要五分钟，给它补齐业务上下文要五个月。
2. 测试墙：业务不信任答案，大量上线的 Agent 在几周内就被弃用。
3. 扩展墙：没有共享的上下文，每个新 Agent 都要重新做一遍，工作量随 Agent 数量线性增长。

Context Layer 的价值就在于：上下文做一次、认证一次，所有 Agent 共用。

---

三、为什么能提升 RAG 的准确性：6 个例子

先看传统 RAG 的流程：

用户问题 ──▶ 向量化 ──▶ 相似度检索 Top-K 切块 ──▶ 拼进 Prompt ──▶ LLM 生成答案

它隐含了一个假设：**“和问题相似的文本"就是"回答问题需要的知识”。**在企业场景里，这个假设经常不成立。

加入 Context Layer 之后，流程变成：

用户问题
  │
  ├─①─▶ 术语解析：问题里的业务词对应哪个经过认证的定义？
  ├─②─▶ 状态过滤：只保留已认证、在有效期内、适用于当前提问人的条目
  ├─③─▶ 权限裁剪：按提问人角色去掉无权查看的内容
  ├─④─▶ 装配上下文：结构化定义 + 规则 + 出处（可再补充 RAG 检索的原文作为证据）
  └─⑤─▶ LLM 生成答案，并引用用到的条目及版本

下面用一个虚构的企业内部问答助手来举例。

例 1：同义词与缩写——“问法不同，答案不同”

问题：“KA 客户这季度的复购率是多少？”

传统 RAG：知识库里的制度文档写的是"战略客户"和"A 级客户"，没有"KA"这个词。向量检索召回了一篇讲"KA 渠道铺货"的市场部文档，LLM 基于它给出了一个完全不相关的回答。

有 Context Layer：术语表里维护了同义关系：

term: A级客户
aliases: [KA, 大客户, 战略客户, 顶级客户]
definition: 年采购额 ≥ 100 万元的客户
source: 《客户分级管理办法 v3》§2.1

系统先把"KA 客户"解析为"A 级客户"，再去找它的复购率口径。问法不同，落到的是同一个定义。

失效根因：**向量相似 ≠ 语义等价。**企业内部的缩写、黑话、历史叫法，通用 Embedding 模型并不知道。

例 2：口径冲突——“两份文档都对，但只能用一个”

问题：“上季度营收是多少？”

传统 RAG：召回了两段内容。财务手册说"营收 = 确认收入，扣除退款"；销售周报说"营收 = 签约合同额"。两个数字差了 30%，LLM 要么随便挑一个，要么把两个混在一起算。

有 Context Layer：两个定义各自属于不同的业务域，并记录了冲突的裁决结果：

- name: 营收
  domain: finance
  definition: 确认收入，扣除退款，税后
  owner: 财务数据组
- name: 营收
  domain: sales
  definition: 当期签约合同额
  owner: 销售运营组
conflict_resolution: >
  财务类问题默认使用 finance 口径；
  回答时须注明口径，跨域比较时须同时列出两种口径。
decided_by: CFO 办公室

根据提问人所在部门和问题所属的域选对口径，并在答案里说明用的是哪个口径。

失效根因：**RAG 能找到"相关"的内容，但不能判断"哪个是权威"。**这里的"唯一定义"是域内唯一：财务的营收和销售的营收可以都正确，前提是边界清楚、差异写明。

例 3：过期版本——“引用的是去年的制度”

问题：“出差报销超过多少需要总监审批？”

传统 RAG：知识库里同时有《差旅报销制度》v2（阈值 3000 元）和 v3（阈值 5000 元）。两份文档内容几乎一样，向量相似度也几乎一样。召回了 v2，LLM 回答"3000 元"。

有 Context Layer：每条规则带有状态和有效期：

rule: 差旅报销审批阈值
value: 超过 5000 元需总监审批
version: 3
status: VERIFIED
valid_from: 2026-01-01
supersedes: 差旅报销审批阈值@2   # v2 已标记为 DEPRECATED
source: 《差旅报销制度 v3》§4.2

已废弃的版本不会被交付给模型，但仍保留在历史中，以便回答"去年的标准是多少"这类问题。

失效根因：**向量检索没有"时间"的概念。**新旧版本在向量空间里几乎重合。

例 4：适用范围——“这条规则不适用于你”

问题（华北区员工提问）：“新员工试用期是多久？”

传统 RAG：召回了"试用期为 6 个月"。但这条规定只适用于华东区研发岗，华北区是 3 个月。

有 Context Layer：规则带有适用范围，装配上下文时按提问人的属性过滤：

rule: 试用期时长
value: 6 个月
scope:
  region: [华东]
  job_family: [研发]

华北区员工提问时，这条规则根本不会进入上下文。

失效根因：适用范围如果只是写在正文里的一句话，模型很容易忽略。范围应该是过滤条件，而不是注释。

例 5：权限——“答案是对的，但你不该看到”

问题（普通员工提问）：“销售总监的绩效奖金是怎么算的？”

传统 RAG：知识库里有薪酬委员会的内部文件，被召回并据此回答。答案准确，但属于严重的数据泄露。

有 Context Layer：条目带有敏感分级，访问策略在装配上下文时执行，同一个问题不同的人拿到的上下文不同：

entry: 销售管理层绩效奖金计算规则
sensitivity: CONFIDENTIAL
access_policy: 仅 HR 薪酬组与薪酬委员会可见

普通员工得到的回答是"该信息仅对授权人员开放，请联系 HR"。

失效根因：权限要在"给模型看之前"执行，而不是指望模型"不说出来"。

例 6：决策先例——“规则说不行，但以前批过”

问题（销售提问）：“客户要求续约打 8 折，能批吗？”

传统 RAG：召回了定价政策"续约折扣上限 10%“，回答"不能超过 9 折”。

有 Context Layer：除了规则，还保存了过去的决策轨迹：

decision_id: DEC-2026-0342
type: 续约折扣例外
subject: 客户 X（战略客户）
inputs: [客户健康分下降, 竞品报价]
policy_applied: 定价政策@v5（上限 10%）
outcome: 批准 20% 折扣（例外）
approved_by: 销售 VP
precedents: [DEC-2026-0117, DEC-2026-0201]

回答变成：“标准政策上限为 9 折。过去对健康分下降的战略客户，曾经在销售 VP 批准下给过例外折扣（参见 DEC-2026-0342）。如需申请，请走例外审批流程。”

失效根因：**企业里大量知识不在制度里，而在"以前是怎么处理的"里。**Atlan 把这类内容称为 Decision Traces，并强调它和审计日志的区别：审计日志记录"发生了什么"，决策轨迹记录"为什么这么决定、参考了什么先例"。

小结：Context Layer 补的是 RAG 缺的那几环

失效类型	传统 RAG 的问题	Context Layer 的解法
同义词、缩写	向量相似 ≠ 语义等价	术语表 + 别名解析
口径冲突	能找到相关内容，判断不了权威	按域划边界 + 冲突裁决 + 负责人
过期版本	检索没有时间概念	版本、状态、有效期
适用范围	范围写在正文里被忽略	范围作为结构化过滤条件
权限	检索不区分提问人	装配前按人执行访问策略
经验与例外	只有规则，没有先例	决策轨迹
无法追溯	不知道答案依据哪一条	每条有稳定 ID 和版本，答案带引用

需要说明的是，Context Layer 并不取代 RAG。原始文档仍然需要检索，只是它们的角色从"事实本身"变成了"证据"。模型先拿到经过认证的结构化上下文，再用检索到的原文作为补充和引用。

一个简化的实现示意

下面用伪代码说明上下文装配的核心逻辑：

def assemble_context(question: str, user: User) -> Context:
    # 1. 术语解析：把问题里的业务词映射到认证过的定义（含别名）
    terms = glossary.resolve(question)

    # 2. 取出相关的规则、指标口径和决策先例
    candidates = context_store.related(terms)

    # 3. 准入过滤：只保留可交付的条目
    today = date.today()
    entries = [
        e for e in candidates
        if e.status == "VERIFIED"                      # 已认证
        and e.valid_from <= today <= e.valid_to        # 在有效期内
        and e.scope.matches(user)                      # 适用于当前提问人
        and policy.can_read(user, e)                   # 有权限查看
    ]

    # 4. 同一术语跨域冲突时，按提问人所属的域选口径
    entries = resolve_domain_conflicts(entries, user.domain)

    # 5. 用 RAG 补充原文证据（同样经过权限过滤）
    evidence = rag.search(question, filter=policy.filter_for(user))

    # 6. 返回结构化上下文，每条带 id 和 version，用于答案引用
    return Context(entries=entries, evidence=evidence)

真正的系统还要处理置信度、新鲜度排序、审计记录等，但核心思路就是这几步：先解析、再过滤、后装配、全程可追溯。

---

四、哪些内容应该存入 Context Layer

4.1 准入原则：一条内容凭什么能进上下文层

在讨论"放什么"之前，先确定"凭什么能放"。以下五条原则需要同时满足：

#	原则	说明
1	只放含义，不放数据	上下文层回答"这是什么意思、从哪来、谁能用"；具体数值在推理时从业务系统读取
2	达到认证门槛才交付	状态流转：草稿 DRAFT → 已认证 VERIFIED → 已废弃 DEPRECATED
3	有负责人、出处、有效期	否则内容一旦过期，就会变成"权威的错误答案"
4	按域唯一，而非全局唯一	同一业务域内一个术语只有一个权威定义；跨域同名要写明差异
5	可验证	每条有稳定 ID 和版本，能从答案回溯到用到的条目

关于第 2 条，有一个常见误解："认证"是不是意味着每条内容都要人工审核？Atlan 的做法是按置信度分流：

“High-confidence outputs auto-apply. Lower-confidence outputs route to humans.”
高置信的输出自动生效，低置信的输出交给人工处理。

也就是说，AI 负责批量起草，人负责抽检、裁决冲突、认证高风险内容。一般来说，规则、指标口径、访问策略这类高风险内容必须人工认证；资产描述这类低风险内容，置信度达标即可自动生效。

4.2 应该放的七类内容

A. 语义：词是什么意思

内容	例子
业务术语 + 定义	A 级客户：年采购额 ≥ 100 万元
同义词、缩写	KA = 大客户 = A 级客户
分类层级	财务 → 营收指标 → 净营收
术语之间的关系	净营收 依赖 退款口径
指标口径（结构化）	复购率 = 90 天内下单 ≥ 2 次的客户数 / 总客户数，按自然月统计
业务对象本体	客户、合同、工单各有哪些属性，相互如何关联
描述与使用指南	某份文档或数据集是什么、主要谁在用、常见误用

指标口径建议写成结构化字段，而不是一段文字：公式、时间窗口、过滤条件、粒度、单位、适用域。Atlan 在评测失败归因里提到，最常见的缺口就是"模型不知道的关系、解析不了的同义词、该加却没加的过滤条件"。写成纯文字描述时，这三类信息最容易丢。

B. 规则：必须怎么做

内容	例子
政策、制度、SOP	年假需提前 3 个工作日申请
阈值与审批链	报销超过 5000 元需总监审批
适用范围	仅适用于华东区、销售部、2026 年后入职员工
标准答案	高频问题的权威回答
例外与优先级	两份制度冲突时以哪份为准

C. 溯源：这个说法从哪里来

内容	例子
出处	出自《销售部 SOP v3.2》§2.1
依赖链	源文档 → 抽出的术语 → 引用它的规则 → 使用它的回答
版本历史	每次修改留存快照，可比较、可回退
时间点回溯	查询"2026 年 3 月 1 日时这条规则是怎么写的"
影响分析	某份文档下线后，哪些术语和规则会失去依据

D. 治理：谁负责、谁能看

内容	例子
负责人	对准确性负责的人或团队
认证状态	草稿 / 已认证 / 已废弃
有效期与复审周期	生效日、失效日、每 180 天复审一次
访问策略	薪酬相关内容仅 HR 薪酬组可见
敏感分级	个人隐私、机密、受监管
审计记录	谁在何时读取、修改了哪条内容

注意，策略必须是系统能直接执行的结构化数据，而不是一份写着"敏感信息请勿外泄"的说明文档。

E. 运行状态：大家实际怎么用

内容	用途
使用情况：引用次数、主要使用方	排序，发现"没人用"的条目
质量分：完整性、准确性、新鲜度	排序和准入门槛
覆盖缺口：没有命中任何条目的问题	驱动补齐内容

这一类对应 Gartner 提出的上下文层三组件之一 Operational State（运行状态）。另外两个组件是 Semantics（语义）和 Provenance（溯源）。

F. 决策轨迹：当时为什么这么决定

例 6 中已经展示过。最小字段包括：决策 ID 与类型、决策对象、使用的输入、适用的规则及版本、决策人与时间、结果、先例链接。

需要注意，单条决策轨迹不等于规则。它先作为证据保存；同类决策积累出稳定模式、并由负责人确认后，才升级为正式规则或标准答案。

G. 评测资产：怎么证明内容是对的

内容	说明
认证问答集	按业务域维护的"问题 + 标准答案"，作为回归测试
用户纠错	用户标"错"时生成建议的内容更新；标"对"时变成一条新的测试用例
推理记录	每次交互的"问题 + 用到的条目及版本 + 回答"

这一类不会注入给模型，但要和上下文条目一起做版本管理。上下文改了，就要重跑评测。

4.3 不应该放进去的内容

内容	应该放在哪里	原因
业务数据（订单、客户信息、薪资明细）	业务系统	上下文层不存数据；数值在推理时实时查询
原始文档全文与切块	向量库（RAG）	未经认证，只能作为证据，不能当作事实
未审核的 AI 草稿	待审区	未经认证就交付，等于把幻觉包装成权威
对话流水	会话存储	有价值的部分提炼为纠错、覆盖缺口或决策轨迹
系统提示词、回答模板	应用配置	这是"怎么回答"，不是"业务事实"
用户、角色、组织架构	IAM 系统	上下文层只引用它们来做权限判断
密钥、凭证	密钥管理系统	不能出现在任何可被模型查询的地方
与当前用例无关的内容	不装配	内容越多，干扰越大

4.4 一条上下文长什么样

把前面的要求合在一起，一条合格的上下文条目大致如下（YAML 只是示意，也可以存在数据库里）：

id: metric.sales.repurchase_rate
type: metric
domain: sales
version: 2.1.0
status: VERIFIED
owner: 销售运营组
definition: 90 天内下单 ≥ 2 次的客户数 / 同期下单客户总数
window: 90 天滚动，按自然月出数
filters:
  - 剔除测试账户
  - 剔除全额退款订单
grain: 客户
unit: 百分比，保留 1 位小数
aliases: [回购率, 复购比例]
source:
  document: 《销售指标口径手册 v4》
  section: §3.5
valid_from: 2026-01-01
review_cycle: 180d
last_verified_at: 2026-08-15
verified_by: 张三
sensitivity: INTERNAL
conflicts_with:
  - ref: metric.marketing.repurchase_rate@1.0.0
    note: 市场部口径为 180 天窗口，跨部门比较时须注明

Atlan 把这类按业务域划定边界、做版本管理的上下文集合称为 Context Repo，并把它类比为软件工程里的 Git 仓库：

“Context Repos are to enterprise AI what Git repos are to software.”

---

五、如何衡量效果

上下文层做得好不好，不能只看"条目数量"。Atlan 提出过一个三轴框架：

维度	含义
针对性 Specificity	按用例划定范围，而不是做全局大杂烩
新鲜度 Freshness	最近验证过，足以被信任
可验证性 Verifiability	能从答案回溯到驱动它的上下文

可以落地的指标：

指标	说明
准确率	Agent 答案与认证答案一致的比例。Atlan 建议的首个门槛是 70%–80%
覆盖率	重点业务域中，定义、指标、规则已被收录的比例
复用度	同一份上下文支撑多少个 Agent。Atlan 建议至少 3 个
一致性	同一问题多次运行，结果在可接受的波动内
人工纠错率	应随时间下降

还有一个容易被忽略的点：

“Eval tells you whether the agent was right today. But what about next quarter, when the context it’s reading has changed?”
评测只能告诉你 Agent 今天是对的；下个季度上下文变了，它还对吗？

所以评测集要和上下文一起做版本管理、持续回归，而不是只在上线前验收一次。

---

六、落地建议

如果你正准备在自己的 RAG 系统上加一层上下文层，可以按以下顺序推进：

1. 选一个业务域起步。不要一上来就做全公司，选一个问题集中、口径争议多的域，比如财务指标或 HR 制度。
2. 先建评测集。收集 50 到 100 个真实问题，请领域专家给出标准答案。这是后面所有改进的基准线。
3. 从术语和指标口径开始。前 20% 的上下文就能覆盖大部分明显的错误（Atlan 原话：“The first 20% of context enrichment covers most of the obvious failure modes.”）。
4. 让 AI 起草，让人认证。用 LLM 从现有文档中抽取候选术语、规则，按置信度分流；专家只处理冲突和高风险内容。
5. 给每条内容加上负责人、出处、有效期。这一步最容易被跳过，也是日后最容易出问题的地方。
6. 在检索前做过滤。状态、有效期、适用范围、权限，都在交给模型之前执行。
7. 答案带引用，建立反馈闭环。用户的"对/错"反馈回流为内容更新和新的测试用例。

---

总结

• Context Layer 是什么：一层把企业的知识、经验和规范转化为 AI 可用上下文的基础设施。它引导推理，不存业务数据。
• 为什么需要：更大的上下文窗口和更好的检索，解决不了"哪个是权威、是否过期、是否适用、是否有权限"这些问题。
• 为什么能提升 RAG 准确性：它补上了 RAG 缺失的几环，包括同义词解析、口径裁决、版本与有效期、适用范围过滤、按人授权、决策先例和可追溯引用。原始文档的角色从"事实"变成"证据"。
• 该放什么：语义、规则、溯源、治理、运行状态、决策轨迹、评测资产七类内容。每一条都要满足五条准入原则：只放含义、达到认证门槛、有负责人与出处与有效期、按域唯一、可验证。

一句话概括：RAG 解决的是"找得到"，Context Layer 解决的是"找得对、用得对、说得清依据"。

---

参考资料

• Atlan: The Context Layer for AI — https://atlan.com/context-layer/
• Atlan: Context Layer for AI — https://atlan.com/know/context-layer-for-ai/
• Atlan: Enterprise Context Layer — https://atlan.com/know/enterprise-context-layer/
• Atlan: Seven Core Components of a Context Layer — https://atlan.com/know/core-components-context-layer/
• Atlan: Decision Traces for AI Agents — https://atlan.com/know/what-are-decision-traces-for-ai-agents/
• Atlan: Context Graph vs Knowledge Graph — https://atlan.com/know/context-graph-vs-knowledge-graph/
• Atlan: How Much Context Is Enough — https://atlan.com/know/how-much-context-is-enough/
• Atlan: Context Agents — https://atlan.com/context-agents/
• Atlan: Context Engineering Studio — https://atlan.com/context-engineering-studio/
• Atlan: Context Layer Glossary — https://atlan.com/context-layer/glossary/

本文例子均为虚构场景，用于说明原理。文中引用的统计数据来自 Atlan 官网，属于厂商自述，仅供参考。