Morphz
导航
EN

结构化上下文 · Draft

结构化上下文宪法 v1

规范正文 · 与源码同步在 GitHub 查看源码

状态：Draft

标准维护者：新变元（Newvar）

参考实现：Morphz Runtime

规范文本语言：英文

日期：2026-08-21

规范文本：English

翻译说明：本文件是英文规范的中文翻译；如含义冲突，以相同版本的英文文本为准。

1. 目的

本宪法定义一个系统被称为结构化上下文系统所必须保持的身份。它有意比协议规范更 精简、更稳定。不同实现可以采用不同的编程语言、存储系统、部署方式、模型提供商、 用户界面和内部优化，同时仍然遵守这些原则。

Morphz 从以下命题出发：

上下文是一种第一等、可持久化、带版本的认知状态，Agent 可以显式检查和变换它。 它不只是由 Runtime 拼装的 Prompt，也不只是经过自动压缩的对话记录。

2. 规范用语

本文中以全大写形式出现的 MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、MAY 和 OPTIONAL，应按照 BCP 14、RFC 2119 与 RFC 8174 解释，且仅在它们以全大写形式 出现时具有该含义。

3. 宪法原则

第一条：上下文是第一等状态

上下文具有稳定身份、可观察的版本历史和独立于单次模型请求或单个进程的生命周期。 重启 Runtime 或替换模型不得静默创造一个不同的认知身份。

第二条：Agent 拥有认知意义

Agent 决定自己当前相信什么、质疑什么、计划什么、保护什么、修订什么、推导什么或 退役什么。Runtime 不得静默指定语义重要性、制造结论，或用不透明摘要替换 Agent 的 Mind。

Mind 保持轻模式（schema-light）。实现可以提供模板和领域包，但不得把一种通用固定 本体强制作为认知意义本身。

第三条：Runtime 拥有现实边界

Runtime 对身份、权限、事件顺序、直接因果、资源限制、事务结果、工具执行结果和控制 状态转换拥有权威。Agent 可以解释这些事实，但不能把它们改写成仿佛现实曾以另一种 方式发生。

Runtime 的顺序、时间新旧、频率和资源使用建立的是物理事实。它们本身不能建立语义 真理或语义权威。物理版本更新本身不足以支持范围更广的结论。

第四条：历史与认知相互独立

Event History 记录发生过什么；Mind 记录 Agent 当前决定继续携带什么；Kernel 记录 Runtime 的权威运行状态；Inbox 和 Observation 向 Agent 交付有待处理的事实。将某项 内容移出活动注意力不得追溯性地抹除产生该内容的事件。

第五条：认知变更必须显式且事务化

对 Mind 或其注意力状态的修改必须通过显式、可验证的事务发生。事务必须原子提交其 声明的全部变更，或者完整保留先前状态。被拒绝或发生冲突的变更必须对调用者可见。

第六条：来源与因果在变换后仍然存在

推导出的认知必须能够保留指向其声明证据的稳定引用。Runtime 必须保存物理顺序和 直接因果关系；Agent 仍然对自己结论的语义强度负责。

第七条：注意力不等于删除

将信息退役、换出、排除、压缩或以其他方式移出模型请求时，必须具有显式语义。暂时 没有出现在 Prompt 中不得被表示为物理删除。声称可以恢复的信息必须保留通往召回或 恢复的稳定路径。

第八条：Principal、Session、Agent 与 Context 是不同身份

Principal 是经过认证或授权的外部行动者或权威。Session 是交互连接，不是认知身份 本身。多个 Session 可以共享一个 Context；一个 Agent 可以使用多个 Context。实现不得 将“一个对话等于一个心智”作为隐含不变量，也不得用 Principal、Session、Agent 或 Context 中的一种身份静默替代另一种。

实现可以支持 Context 分支或委托。支持时，每个分支或委托都必须具有显式的身份、 来源、授权和生命周期语义。除非后续 Profile 另有规定，分支与委托不是 SC-Core 的 强制要求。

第九条：并发不能削弱真实性

并发工作可以提高吞吐量，但不得静默覆盖已提交的认知、错误路由结果，或让证据越过 其授权的因果范围。冲突检测、隔离栅栏（fencing）和恢复属于 Context 语义，而不是 可选的存储细节。

第十条：可观察语义独立于具体实现

声称兼容的实现必须满足已发布的规范和相应的公开一致性 Profile。实现不必复制 Morphz Runtime 内部结构；它只需要产生规范要求的可观察行为。

第十一条：演进必须显式

对宪法原则、规范性协议行为、兼容 Profile 或一致性声明的变更，必须遵循公开的 Morphz 增强提案流程。新的实现细节不会因为进入代码而自动成为标准的一部分。

第十二条：权威必须可以审计

影响规范语义、兼容性或权威解释的决策，必须留下持久、公开的提案、理由和兼容性 记录。标准维护权意味着承担具有可见记录的最终责任，而不是进行没有文档的私下修改。 组织角色、发布控制和兼容标识由 Governance 文档规定，不在本宪法中规定。

4. 规范权威顺序

规范文档发生冲突时，按以下顺序确定权威：

  1. 当前版本的本宪法；
  2. 声称兼容版本所对应的当前 Final《Morphz 结构化上下文规范》；
  3. 对应的一致性测试套件；测试套件用于验证规范，不得重新定义规范；
  4. 已接受的 Standards Track MEP，但仅限其已被纳入带版本宪法或规范发布的部分；
  5. Morphz Runtime 及其他实现；它们提供证据，但不定义标准；
  6. 解释性文档、示例和非规范实现注释。

Draft 规范与测试套件定义评审目标，不构成已发布的兼容义务。无法追溯到上位规范要求 的测试，不得自行创造规范要求。

5. 宪法边界

本宪法不规定：

  • 特定模型提供商或模型架构；
  • 固定的 Mind Schema 或领域本体；
  • 特定存储引擎、编程语言或传输协议；
  • 用户界面或部署拓扑；
  • Morphz 托管服务的商业条款；
  • 仅仅因为 Runtime 通过一致性验证，就宣称其上 Agent 具有高质量推理能力。

这些事项可以由下层 Profile 规定，而不改变结构化上下文的身份。

6. 修正与首次通过

首版宪法、Governance 文档、MEP 流程、Draft 规范与 Draft 一致性测试套件，可以依据 MEP-0001 的自举规则同时通过。该例外仅用于建立流程，不得用于后续修正。

此后的每次宪法修正都需要单独的 Constitutional MEP。提案必须解释为何普通规范变更 不足以解决问题，提供迁移方案和生态影响分析，并在 Core Maintainers 评审后由 Project Lead 批准。修正只有合入带版本的宪法发布后才正式生效。