RFC-0002：Aira Interface 与能力发现协议：安全、评估与接受条件

主文档与完整目录。本分篇与主文档共同构成同一规范，版本、状态与权威以主文档为准；仅拆分阅读结构，条款编号和正文语义不变。

14. 安全与信任

Capability Profile 是数据，不是指令；插件描述中的 prompt injection、URL 或代码片段不得被自动执行。
Search index 只能摄取已注册、已签名和通过 lint/conformance 的 package metadata。
Authorization 在执行端按 capability ID、scope 和 effect 重新判断；不能信任 search result 的 hint。
Read-only、destructive、idempotent、external-side-effect 必须是可强制策略字段，不只用自然语言描述。
默认禁止任意 eval、shell、网络、文件写入、宿主语言 callback 和 raw C++ pointer。
Import/file/image 只通过 content-addressed asset handle；模型不能自行访问任意路径。
Plan/Task Capsule 不应泄露无关项目、用户或组织数据。
Search/description 缓存必须按 tenant、catalog hash、policy 和 grant visibility 隔离。
Capability package 更新必须经过 schema diff、semantic version、签名、测试和 rollout policy。

15. 版本、缓存与重放

一次可重放 AI task 至少保存：

interface protocol version 与 Meta-operation Contract 版本；
Task Protocol hash 与运行时状态迁移序列（含批次归约决策与终态）；
每个 provider 调用轮的 provider projection binding（第 13.2 节）；
base Revision 与 selection snapshot；
Intent Frame hash；
AMIR schema/Operation Catalog/semantic package lock；
discovery catalog hash；
Runtime Capability Snapshot；
Session Grant/policy version（敏感内容可保存不可逆摘要与审计引用）；
search request 与 ordered hits；
selected descriptor handles；
public plan、Patch、diagnostics 和 user approvals；
ExecutionManifest、artifacts 和 certificates。

缓存分类：

Cache	Key 必须包含	可否删除
Search candidates	query normalization、discovery hash、visibility	可以
Applicability	Revision/selection、runtime、grant、policy	可以
Descriptor view	capability/profile version、disclosure level	可以
Task Capsule	intent、Revision、selection、query set、policy	可以
Plan check	canonical plan、全部 snapshot bindings	可以

删除这些缓存不得影响已提交 Revision；重放时如果原 discovery snapshot 不可取得，必须声明 DISCOVERY_SNAPSHOT_UNAVAILABLE，不能用 latest 冒充原过程。

16. 评估体系

16.1 Discovery

Recall@k：gold capability 是否被召回；
Sufficiency@k：top-k 是否覆盖完整可行 plan；
Applicable@k：返回能力在当前状态下可用的比例；
No-tool accuracy：正确判断不需要写操作/工具；
Unknown-capability generalization：新 capability 未经模型训练能否被发现；
Version robustness：deprecation/major upgrade 后能否避免旧调用。

16.2 Planning 与调用

schema-valid call rate；
type/cardinality/unit valid rate；
static plan pass rate；
missing-information detection；
permission/risk violation rate；
first-pass Patch validity；
average search/describe/query turns；
context bytes/tokens 与 latency。

16.3 CAD 结果

execution validity；
geometric/topological assertion pass；
constraint DOF/conflict/fully-constrained rate；
edit reachability 与 constraint preservation；
stable reference resolution after parameter changes；
downstream rebuild success；
function/manufacturing/assembly assurance coverage；
unintended semantic diff 与 affected-scope precision。

16.4 Transaction 与安全

stale plan rejection；
preview/validate/commit binding correctness；
CAS conflict handling；
cancellation/timeout/resource enforcement；
unauthorized call rejection；
replay determinism；
diagnostic-guided repair success 与 regression rate。

不能使用“LLM 自评正确”“截图像”“能导出 STL”作为单一成功指标。

17. 技术验证计划

本节是 Core 接口存在后的验证扩展，不是当前产品实现的前置工程。当前先完成 Aira Core MVP，只用真实接口上的六个 capability 和三个产品回归验证最小闭环；不得先建设大 catalog 或大型 gold corpus 来替代可运行产品。

Phase 0A：Core Interface Smoke（已完成的历史阶段）

范围：六个产品 capability：cap:primitive.box@1、cap:primitive.cylinder@1、 cap:transform.translate@1、cap:boolean.union@1、cap:boolean.subtract@1、 cap:parameter.set@1。它们必须分别映射到 mesh.box、mesh.cylinder、mesh.transform、 mesh.boolean.union、mesh.boolean.difference 和 Patch op parameter.setValue，禁止把 capability ID、Operation ID 与 Patch op 当成同一种标识。

稳定元操作为 interface.manifest、catalog.search、catalog.describe、model.read、 model.proposePatch、model.preview、model.validate、model.commit、model.revert。 model.query 可以在 MVP 中投影为 model.read 的有界 query；SemanticRef 的 resolveAcross 是该稳定元操作下的类型化 query contract，不增加第十个顶层元操作，也不返回可被模型缓存为永久身份的裸 subshape id。plan.check 可以由 model.proposePatch 内部执行，但不得省略其语义检查或绕过 validation binding。

交付：

真实 Aira Core adapter，不使用 mock capability backend；
一个未安装 Skills 的模型调用闭环；
创建实体、参数修改、非法/未验证 Patch 零写入三条回归；
结构化 action、observation、Patch、Candidate、authoritative validation、Revision、 ExecutionManifest、EvaluationBinding、Certificate 与 Diagnostic 记录；
provider-neutral AI gateway；模型凭据只在服务端，浏览器仍负责本地事务、几何与渲染。

Gate：产品原型能够创建、显示、修改、验证、保存、revert 和重放模型；preview token、过期或失配的 validation token 均不能 commit；三条回归通过。未达到该 Gate 时，Phase A–D 不进入当前开发队列。

Phase A：Capability Discovery Harness

前置条件：Phase 0A 已通过，且真实产品 catalog 已经增长到需要系统检索比较的规模。

范围：40–80 个 MVP capability，加 2–3 倍近义/不可用干扰项。

交付：

descriptor/profile schema；
taxonomy + graph；
lexical/semantic/type/state hybrid search；
200–400 个 gold task；
全量 schema、纯 semantic search、hybrid search 三组基线；
retrieval、token、latency、wrong-tool 和 insufficiency 报告。

Gate：hybrid 在不显著增加延迟的条件下，对 Sufficiency@k、applicable result 和 end-to-end task success 有可重复提升；否则重新评估 hierarchy/filter 设计。

Phase B：Typed Plan + Diagnostic Loop

范围：sketch → profile → exact extrude/boolean/fillet → assertions。

交付：

plan schema/checker；
Task Capsule；
compiler/solver/kernel 统一 observation；
one-shot 与 repair-loop 对照；
information-insufficient、selection mismatch、fillet failure、constraint conflict fixtures。

Gate：错误不能绕过静态检查或以 raw exception 驱动；repair 必须产生可见新 Patch。

Phase C：多模态受控输入

范围：受控工程图、单视图零件图片、STEP/mesh 文件，各自定义数据分布。

输出不是“必然正确模型”，而是：

Intent Frame 与不确定项；
一个或多个 editable candidate；
provenance、assumptions、diagnostics；
可执行 acceptance tests/certificates；
无法恢复时的明确拒绝或追问。

Gate：在 holdout complexity、noisy input 和 ambiguous input 上分别报告 success/abstention/error，不得只展示成功案例。

Phase D：领域包与未见能力

引入制造、装配或建筑小型领域包，不修改基础模型 prompt、不安装 Skills，测试新 capability 的 discoverability、schema use、versioning 与 permission isolation。

18. 我们需要创造什么

18.1 必须自研的核心

Aira Capability Ontology：面向 CAD 表示、feature、query、constraint、validation 和 domain package 的最小公共本体。
Capability Descriptor/Profile Schema：语义与 discoverability 分层，自动生成 SDK/tool schema。
State Applicability Engine：对 Revision/selection/runtime/grant 计算可执行性和 unmet conditions。
Hybrid Capability Retriever：层级、文本、类型图、状态和计划 sufficiency 的联合检索。
Task Capsule Builder：从 Document Dependency Graph 和 selection 构造最小充分上下文。
Typed Plan Checker：校验 capability composition、effect scope、权限、预算和 version binding。
Diagnostic/Repair Ontology：把 compiler/solver/kernel/DFM 反馈变成机器可行动的稳定契约。
AI-CAD Capability Benchmark：同时评估发现、调用、几何、编辑、约束、事务和版本泛化。

18.2 应复用的标准/组件

JSON Schema 2020-12：结构 schema；
MCP：AI client transport projection；
OpenAPI/HTTP 或 Connect/gRPC：服务接口描述与传输；
AMIR Operation Catalog：规范操作语义；
OCCT/Manifold/solver adapters：确定性执行；
Three.js：DisplayMesh/RenderPacket 消费；
通用 BM25/vector store/reranker：retrieval building blocks，经 Aira benchmark 校准。

18.3 不应自研或不应作为核心的内容

为了“AI 更懂”而重写 OCCT 或 Manifold；
让模型直接学习几千个 raw kernel methods；
与模型供应商绑定的私有 tool-call 语义；
任意代码作为 committed model；
仅用 embedding 的黑盒 capability router；
只针对 demo prompt 的巨大 system prompt；
把矩阵或坐标变换再包装成独立翻译层。

19. 风险与缓解

风险	后果	缓解
Descriptor 与实现漂移	AI 计划合法但运行失败	schema 单源生成、conformance fixtures、package signing
Retrieval miss	AI 误称系统不会做	sufficiency check、query decomposition、扩大搜索、显式 unknown
纯语义误匹配	Exact/Mesh/Field 路径混淆	type/representation/state filter
Catalog 太细	tool confusion、plan 过长	workflow/macro，但必须可展开审计
Catalog 太粗	隐藏副作用和不可组合	明确 effects、typed ports、原子 Patch ops
Taxonomy 固化	新领域难接入	小核心 + facets + versioned domain packages
Profile prompt injection	插件描述诱导越权	metadata 当数据、签名/lint、权限执行端强制
Dynamic metadata 改变 AI 行为	难以复现	discoveryCatalogHash 与 ordered hits 审计
反馈循环无界	成本和延迟失控	turn/time/compute budget、cancel、明确终止原因
Reward/metric hacking	“通过”但违背设计意图	多维 assertions、参数扰动、人类/工程 review、反例集
Scope creep	AI 改动超出用户意图	Intent Frame scope、impact query、semantic diff、approval

20. 被否决的替代方案

20.1 把全部 capability schema 放入 system prompt

否决原因：上下文随能力数线性增长；相似工具增加误选；新版本难以锁定；研究已表明大规模工具检索本身是独立难题。

第 7.1 节的 small-catalog 内联不推翻本否决：它经 interface.manifest 结构化下发，有 manifest 声明的体积上限、精确版本锁定与 discoveryCatalogHash 绑定；catalog 超限即回到检索路径，不进入 prompt。

20.2 只做向量搜索

否决原因：相似文本不保证 type、state、permission 和完整 solution path 可行；只能作为候选生成器。

20.3 每个 kernel method 都直接变成 MCP tool

否决原因：泄漏 kernel 细节、工具列表无界、缺少 domain transaction、无法保证 AMIR/GUI/AI 对等。

20.4 让 LLM 直接写 Python/C++/TypeScript 控制内核

否决原因：任意副作用、版本漂移、无静态 effect scope、难以审计和 replay。可以用于隔离研究，不进入 production commit path。

20.5 一次性“输入 → 最终模型”生成器作为主架构

否决原因：无法可靠处理信息不足、复杂拓扑、编辑反馈和设计验证；作为候选生成器可以接入，但必须输出 Intent Frame/AMIR candidate 并进入统一闭环。

20.6 新增“矩阵翻译层”

否决原因：矩阵适合表示 Transform3D、坐标系和线性代数，不解决能力发现、类型、状态、约束、权限和事务问题；额外语义层会增加映射和调试成本。

21. 开放问题

v0.1 taxonomy 的稳定核心应有多小，哪些 facets 留给领域包？
Capability Profile 的哪些字段影响 AI 行为到需要长期保留，哪些只做可删除索引？
Applicability predicate 使用 AMIR typed expression、Datalog 还是专用小 DSL？
搜索 result 的 relevance/applicability 如何校准，避免伪概率？
scoped binding 是否真的比 meta-tools + proposePatch 提高 schema-valid rate？
workflow 的抽象粒度怎样避免既隐藏副作用又造成 plan 过长？
如何为未见领域包自动生成高质量正例、反例和 gold retrieval task？
用户长期偏好应进入 project policy、Intent Frame 还是 capability ranking profile？

这些问题均必须通过 benchmark 或独立 ADR 决定，不能由 prompt 习惯替代协议设计。

22. Accepted 条件

本 RFC 可转为 Accepted，当且仅当：

Capability Descriptor/Profile、Manifest、Search、Task Capsule 和 Plan 均有 v0 JSON Schema；
Operation schema 能从 AMIR Catalog 单源生成，Rust/TypeScript 至少两端通过 fixtures；
四层能力模型及 hash/binding 在 transaction audit 中可观察；
40–80 capability 的 discovery harness 完成，并包含全量、semantic-only、hybrid 对照；
至少 200 个任务覆盖 single/multi-tool、state、information-insufficient、version change；
plan.check 能在 kernel 前拒绝类型、单位、基数、权限和明显 precondition 错误；
end-to-end demo 完成 Observe → Discover → Plan → Preview → Validate → Commit/Repair；
MCP projection 不暴露 raw kernel API，且可由另一个 transport 实现同样语义；
capability/plugin metadata 的签名、lint、注入隔离和授权复验完成；
论文调研中的 H1–H6 有可复现结果，失败假设已修改或删除；
Meta-operation Contract v1 的 effectClass 分类、批次归约、修复轮上限与五个显式终态在 scripted/fake-provider fixture 上有 conformance 测试，含 DISCOVERY_REQUIRED 恢复路径与 cannotProceed 弃权路径；
provider projection binding 的机械生成、逐轮 hash 记录与 exact-byte 转发有 gateway/browser 双端 fixture；重复 property name 与 lone surrogate 在两端均于解码前被拒绝；strict profile 未通过接受集合 conformance 前不进入生产路径。

23. 主要依据

Aira Interface 的目标不是让 AI 背下 CAD，而是让 CAD 系统本身变得可发现、可解释、可组合、可拒绝和可验证。只要这个边界稳定，未来模型更换、内核增加、领域扩展和交互变化都不需要重新发明模型真相。