一句话定义：Agent Context Layer（智能体上下文层）是介于原始内容与智能体之间的那一层——把文档、数据库、权限、关系整理成智能体可以直接读取和操作的结构，而不是每次任务来了再临时拼一段 prompt。
先看没有它会怎样
假设你让智能体回答“上个季度华东区的续约情况”。最常见的做法是：先做一轮检索，把提到“续约”的段落捞出来，塞进 prompt，再让模型总结。这就是 RAG（Retrieval-Augmented Generation，AI 词典：检索增强生成">检索增强生成）的典型用法。
问题在于，捞出来的是一堆飘在空中的文字片段。模型不知道“续约率”其实是一个数据库里的数值字段，不知道那批数据属于“销售”库，不知道自己以谁的身份在看，也不知道两个同名表格哪个才是最新的。于是它只能猜，或者看起来很自信地编。
打个比方：这就像一个没有编目的书库，每次有人提问，管理员都冲进去随手抽几本书、抄几段递过去。RAG 优化的是“抽得准不准”，但书架本身始终是乱的。
上下文层要做的是另一件事：先把书架编好目。每本书有稳定编号、有分类、有借阅权限、有“这套书属于同一系列”的关系记录。智能体拿到的不是几段摘抄，而是一张能被程序读取的地图。
这一层通常包含什么
- 稳定的对象与标识：页面、文档、数据库条目各有唯一 ID，可被引用、可被回写
- 结构化属性：数据库的字段、类型、状态、标签，而不是藏在正文里的自然语言
- 关系：父子页面、条目之间的关联、跨库引用
- 权限：谁能看什么，智能体以谁的身份运行、能写还是只能读
- 变更信息：谁在什么时候改了什么
Notion 这类产品天然占了这个位置：文档、数据库、层级和权限本来就在一套模型里。把它们整理成智能体能消费的形态——统一的读取接口、明确的字段语义、随身份收敛的可见范围——就是在建上下文层。具体支持哪些能力、怎么接入，各家实现不同，以官方页面为准。
和相邻概念的区别
| 概念 | 主要解决 | 典型短板 |
|---|---|---|
| Prompt Engineering | 一次对话怎么措辞 | 换个问题就得重写 |
| RAG | 找到相关片段 | 片段脱离结构与权限 |
| Memory（记忆） | 跨会话记住偏好和事实 | 多是个人的，不是组织级的 |
| Agent Context Layer | 组织知识怎么被结构化消费 | 需要前期治理投入 |
对不同人的意义
对从业者：工作的重心从“调 prompt”转向“治理上下文”——定义字段语义、划清权限边界、维护标识稳定。这些东西做得好，智能体的表现会稳定一截；做得差，再精巧的 prompt 也只是在补窟窿。
对普通职场人：文档的元数据不再只是给人看的装饰，而是给模型的路标。一篇没有标题、没有属性、堆在根目录下的文档，对人勉强能读，对智能体基本等于不存在。而权限设计也第一次有了“机器读者”这个新约束——你的智能体能读到什么，取决于你给它开了多大的门。