企业官网建设流程全解析

关键词：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 可以直接使用的上下文。

这里的三个词各有所指：

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 它和已有的东西有什么不同

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

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 缺的那几环

需要说明的是，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 准入原则：一条内容凭什么能进上下文层

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

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

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

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

4.2 应该放的七类内容

A. 语义：词是什么意思

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

B. 规则：必须怎么做

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

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

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

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

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

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

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

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

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

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

4.3 不应该放进去的内容

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 提出过一个三轴框架：

可以落地的指标：

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

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

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

六、落地建议

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

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

总结

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

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

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】