spec 1.0 · 规范性
检索规范：打开单页版，然后用浏览器的查找功能。
Leji 规范
Leji 是一份面向 AI 原生团队共享上下文层的开放规范。它定义团队如何存储、治理、加载和维护归属于代码仓库的上下文；人和 AI 智能体执行每项任务时，都会读取这份上下文。
| 规范版本 | 1.0.0 |
| 状态 | 已 GA，在 v1.3.0 参考工具发布时冻结。破坏性变更需要新的主版本。 |
| 编辑 | Vuong Nguyen |
| 单页版 | 整份规范汇于一页 |
原则（非规范性）#
- 意图重于指令。 Leji 记录持久的意图（事物意味着什么、必须满足哪些约束、为何如此），而不是针对特定厂商的命令式指令。人和智能体结合已声明的意图与任务上下文来推导行动。
- 是圆环，不是层级。人对人、人对 AI、人对 AI 再对人，这三种流动围绕同一个共享上下文层，都是一等公民。平等的是访问权，而不是决定权：凡能访问某个上下文层的人都读取它的全部内容，任何参与者都可以提议，由人来批准。参与身份基于角色而非工具：一位从不直接使用 git 的参与者，在这个圆环中同样是一等参与者。访问权本身由版本控制系统授予，而不是由 Leji 授予；圆环的范围就是一个上下文层的受众。
- 机制重于善意。共享上下文会自然失效：现实不断变化，文档却不会自行更新，wiki 也没有机制确保内容始终最新。Leji 依靠机制而非善意来强制维护：变更与代码经过同一道评审关卡，工具在检测到机械性漂移时报错，复核期限标记已经过时的内容，而过期上下文绝不会被悄悄当作当前有效（规范性表述见 governance.md 的“时效性”一节）。
本规范其余部分，都是这三条原则的规范性推论。
一致性用语#
本规范中的关键词 MUST、MUST NOT、REQUIRED、SHOULD、SHOULD NOT、RECOMMENDED、MAY 和 OPTIONAL，按 RFC 2119 的描述解释。
本译文正文中的必须、不得、应当、不应、可以、推荐，依次对应上述 MUST、MUST NOT、SHOULD、SHOULD NOT、MAY、RECOMMENDED，强度相同；REQUIRED 与 MUST 同强度，OPTIONAL 与 MAY 同强度。这些中文词只是英文关键词的对照说明，规范性效力始终以英文原文为准。
引用本规范（非规范性）#
引用某一章节时，写明章节标题与规范版本，并附上指向该章节锚点的永久链接。在规范站点上，每个标题在悬停时都会显示自己的锚点。
- 格式： Leji 1.0, §Section：
https://leji.org/spec/<document>/#<anchor> - 示例： Leji 1.0, §The circle, normatively：
https://leji.org/spec/governance/#the-circle-normatively
务必写上版本号（Leji 1.0）：破坏性变更以新的主版本发布，因此锁定版本的引用在规范演进之后依然准确。
词汇表#
以下术语在所有规范性文档中的用法保持一致：
| 术语 | 含义 |
|---|---|
| context layer（上下文层） | 本规范所治理的产物：一组归属于代码仓库、纳入版本管理的人类可读文档与机器可读产物，编码了一个团队持久的运作上下文。“Leji context layer”是消除歧义的完整写法。始终写“context layer”；单独的“layer”仅保留用于指称联邦中可数的层实例（同级层、宿主层、已挂载层、受限层、伴随层或不可访问的上下文层）。 |
| agent（智能体） | 会行动的 AI 系统：它加载仓库上下文，执行或协助工作，并且可以提议变更。这是规范中的行动者名词。 |
| person / people（人） | 人类参与者。批准权归人所有。 |
| participant（参与者） | 一个人或一个智能体。 |
| audience（受众） | 依据仓库权限，以及任何暴露该工作副本的文件系统或共享盘权限，被准许读取某个上下文层的人与智能体。“所有人都读取”的范围就是一个上下文层的受众；不同受众由彼此独立的上下文层服务，绝不通过在同一个层内部设限来实现。 |
| agent host（智能体宿主） | 智能体运行所依托的产品或运行时（例如 Claude Code、Codex、Cursor）。厂商适配器配置的就是智能体宿主。 |
| tool（工具） | 智能体可调用的能力（shell、搜索、某个 MCP 服务器）。绝不是产品名。 |
| vendor adapter（厂商适配器） | 智能体宿主的入口文件，它重定向到引导配置，本身绝不承载权威内容。有些适配器可在多个宿主间通用（AGENTS.md），有些只服务单一宿主（CLAUDE.md、.cursor/rules）。两者规则相同；区别只体现在工具默认生成什么。 |
| boot profile（引导配置） | 上下文层中与智能体无关的入口，同时面向人和智能体。 |
| agent profile（智能体配置） | 面向智能体、按角色划分的加载与行为姿态文档。 |
| AI | 用作形容词（AI 原生），并出现在流动的名称中：人对人、人对 AI、人对 AI 再对人。在这些流动名称里，“AI”指的是通过智能体宿主运行的智能体。 |
| model（模型） | 智能体所运行的预测引擎。读取上下文层的是智能体，不是模型。这个词只在必须把引擎与行动者区分开时出现（例如模型选择这类宿主专有的机制）。 |
这套层级关系可以概括为：模型驱动智能体；智能体通过智能体宿主运行并调用工具；上下文层面向智能体与宿主，而不直接面向模型。本规范对技术栈中的每一层都保持中立：任何模型都可以驱动任何智能体，通过任何宿主运行，并读取同一个上下文层。“LLM”有意不纳入这套词汇，因为它只代表模型中的一类，而本规范按同一原则对所有模型保持中立。
范围边界。 Leji 1.0 治理的是智能体，以及加载仓库上下文的智能体宿主。非智能体形态的 AI（自动补全、行内建议、不带仓库上下文的聊天）不在规范范围内，除非它作为某个加载上下文层的智能体宿主的一部分运行。
规范性文档#
按阅读顺序：
| 文档 | 定义内容 |
|---|---|
| context-layer.md | 上下文层、清单、上下文根目录、厂商适配器规则 |
| content-categories.md | 五个逻辑内容类别，以及索引文件如何把内容映射到类别 |
| boot-profile.md | 每个智能体宿主都会加载的、与智能体无关的入口 |
| machine-readable-surface.md | 清单、索引、变更日志、配置文档、决策记录 |
| decisions.md | 决策记录 |
| governance.md | 提议与批准、归属、纳入与移除、时效性 |
| distribution.md | 单体仓库、多仓库子模块、联邦 |
| conformance.md | 四个一致性级别与检查清单 |
| versioning.md | 规范与 schema 的版本管理 |
../schemas/ 中的 JSON Schema 对机器可读产物具有规范性。../rationale/ 与 ../adoption/ 中的文档是非规范性的。
1.0 的范围#
范围之内：提供上下文、设定约束、记录决策、评审变更、沉淀可复用的模式；与智能体无关的接线方式与厂商适配器（浅度覆盖）；归属与延续性语义（浅度覆盖）。
扩展边界。 Leji 1.0 规定的是权威的共享上下文层：团队上下文如何被书写、归属、纳入版本、提议、批准、索引与读取。它刻意不规定围绕该上下文层运转的执行协议：任务信封、通用化的证据协议、智能体之间的交接、工具权限协议以及编排。这些是扩展协议，而非前提：一个符合 1.0 的上下文层在没有它们时必须依然可用，实现也不得要求具备它们才能读取、提议、评审、批准或校验上下文层。它们会在实践证明其价值时补全这门语言；它们不会被凭空发明出来。
Leji 不是编程语言、DSL、运行时，也不是 SaaS。它由 markdown 约定、精简的 JSON Schema 和治理语义构成。