MMetaAware

公共研究预览 · 方法

MetaAware 如何工作——从证据走向承担责任的行动。

MetaAware 把可观察的项目状态和明确政策转化为确定性 finding。AI 帮助人提出问题和理解结果，但不创造治理事实、不静默改变规则，也不授予权威。

运行模型

一套治理循环，七个彼此分离的阶段。

MetaAware 把观察、判断、解释和权威分开，使每一种失败都可以被定位和质疑。

  1. 01 · 提出问题或声明意图

    人或 agent 询问当前状态、请求审计，或声明准备执行的操作。首个 MVP 保持只读：询问下一步应该做什么，并不会执行该操作。

  2. 02 · 取得证据快照

    只读 adapter 检查 Git、项目声明、审阅记录、发布来源，以及在后续集成获得批准时的 CI、安全、基础设施或运行时证据。

  3. 03 · 规范化证据

    证据关联到精确的对象身份、revision、版本、时间戳和来源。观察事实与项目声明、AI 推断保持分离。

  4. 04 · 评估固定版本的政策

    确定性引擎应用具名、版本化的政策包。同一证据和政策版本必须产生相同的语义结果。

  5. 05 · 产生范围明确的 finding

    结果记录观察到了什么、适用哪条规则、为什么重要、认识状态、严重程度、安全下一步、恢复测试，以及证据不能证明什么。

  6. 06 · 解释，但不改变判断

    AI 或人类可读目录可以把结构化 finding 翻译成自然语言、比较选项并讲解底层概念。解释不能压制 finding、改变政策或批准例外。

  7. 07 · 决策、行动与验证

    人类保留对重要行动的权威。状态改变后，MetaAware 再次观察，并验证所声明的恢复条件是否已经满足。

证据契约

四类输入，有意保持分离。

01

观察事实

从 Git、文件、工具输出、provider API 或运行时观察中可复现取得的事实。

02

声明语境

无法安全推断的项目意图：目标发布、分支用途、所需审阅者、已批准制品、业务不变量或已接受例外。

03

导入证据

来自 CI、扫描器、SBOM 系统、基础设施 provider、身份服务或支付测试环境的版本化结果。导入证据始终标明生产者和观察时间。

04

版本化政策

明确规则定义需要哪些证据、如何评估、适用何种严重程度，以及哪项恢复条件可以关闭 finding。

流畅的解释不能取代任何缺失输入。

Finding 契约

Finding 是范围明确的论证，而不是一个分数。

这个概念示例展示用户或其他系统应当能够检查的最小推理链。

FINDINGreview.stale
观察事实
当前 HEAD 不是已记录审阅所指向的 commit。
适用规则
审阅证据必须绑定到准备集成的 revision。
认识状态
观察到的 Git 事实与声明的审阅证据相结合。
为什么重要
后续 commit 不在原审阅覆盖范围内。
安全下一步
审阅差异，并针对当前 HEAD 记录新的审阅。
验证恢复
确认新审阅记录指向当前 revision。

不能证明： 新鲜审阅不能证明代码正确、安全、有价值或已经可以投入生产。

措辞本身不是判断。

这种结构使开发者、审阅者、CI 系统或 agent 能够检查同一项判断，而不必依赖某一次 AI 回答的措辞。

认识状态

不确定性是输出的一部分。

Observed

系统直接复现了事实。

Declared

项目或获授权的人提供了语境。

Inferred

结果包含明确、可质疑的解释。

Conflicting

现有证据支持彼此不兼容的状态。

Unknown

所需证据缺失、无法访问、已经过时或不足。

Unknown 不会自动等于 pass 或 fail。政策可以在证据缺失时保守地阻止某项行动，但系统必须把这种政策响应与“已经证明存在缺陷”的主张区分开。

自然语言边界

自然语言位于确定性核心之上。

人的问题
或意图→自然语言
adapter→稳定 CLI 与
证据查询→确定性引擎
+ 固定政策→结构化
finding→语境化
解释→承担责任的
人类决策

开发者可以问：“为什么这次发布不安全？”或“下一步应该做什么？”Adapter 把问题翻译成范围明确的查询。回答必须始终可以追溯到由此产生的证据和规则。

自然语言改善可访问性，但不会成为治理权威的来源。

职责分离

每个组件只有有限责任。

Adapter 负责观察

它从定义明确的来源取得证据，并报告证据的身份、版本、新鲜度和局限。

确定性引擎负责判断

它只把版本化规则应用于现有证据。缺少必要证据时，它必须返回 unknown。

AI 负责解释

它翻译 finding、检索相关指引、比较恢复选项，并根据用户调整解释深度。

人类负责制定与授权

人类定义政策、批准例外、接受重要风险，并对决策保持责任。

独立证据负责挑战系统

外部结果、独立 oracle、盲测场景、专家审阅和前瞻性使用，检验规则和解释是否真正充分。

治理栈

项目治理只是整个系统的一层。

04

外部现实

事件、用户结果、独立审阅和环境都可能反驳系统。

03

元治理

证据和受治理的修订检验 MetaAware 的规则、解释和边界是否仍然充分。

02

项目治理

版本化政策把范围明确的证据转化为 finding 和恢复条件。

01

开发活动

人和 agent 产生变更、审阅、发布、声明及可观察结果。

领域扩展

证据来源可以变化，核心保持稳定。

通过 adapter 观察

安全工具、云系统、运行时服务、身份提供商和支付 sandbox 继续作为专业证据生产者。

通过政策包判断

版本化规则与项目业务不变量定义现有证据能够支持什么。

保留边界

AI 负责解释，人类负责授权；缺失证据产生 unknown，集成 finding 不会变成认证。

能力改进

MetaAware 通过受治理的修订提高能力。

候选
问题→策展
证据→可复现
场景→独立
预期结果→版本化规则
提案→开发测试 +
负向对照→盲测保留集
评估→前瞻性
只读使用→人类批准晋级
或回滚

一条新规则、更强的 AI 模型或更多警告，本身都不能证明治理能力已经提高。

一项改进主张必须说明过去的失败、新证据、回归场景、盲测结果、误报、漏报和 unknown 的变化，以及仍然存在的局限。

现在时

当前实现边界。

MetaAware 尚未发布治理 CLI。

已批准 MVP 仅限六项只读能力——status、audit、next、why、explain 和 doctor——以及三类规则：分支与工作树安全、审阅新鲜度和发布来源。

Assist 与 enforce 模式、安全政策包、provider 集成、运行时观察、身份治理和支付完整性治理，都是已接受方向或设计可能性，而不是已经实现的能力。

权威来源GOV-PHILOSOPHY / TECHNICAL-DESIGN / ADR-013 / ADR-014 · 运行模型、保证边界与受治理的能力扩展 · 2026-09-13