《WAO Protocol 最小实现规范（MVP 工程版）》

下面是可直接交付工程团队、可写入 README / RFC / MVP 任务清单的版本。

目标非常明确：不用“想象中的 AGI”，也不用大模型改造，今天就能落地一个“不可绕过”的 WAO 最小实现。

WAO Protocol 最小实现规范（MVP 工程版）

WAO Protocol · Minimum Viable Implementation Spec

0. MVP 的严格定义（先说清楚）

WAO MVP 不是：

• 一个新模型
• 一个更聪明的推理系统
• 一个价值判断引擎

WAO MVP 是：

一个强制绑定“语义状态 × 责任 × 可审计性”的输出过滤与治理层（Governance Layer）

📌 核心目标只有一句话：

让“无状态、无责任、不可追溯”的输出，在工程上“跑不起来”。

1. MVP 总体架构（最小闭环）

[ Input ]
   ↓
[ Semantic State Resolver ]
   ↓
[ State-Bound Output Gate ]
   ↓
[ Accountability Binder ]
   ↓
[ Audit Logger ]
   ↓
[ Output / Reject ]

⚠️ 所有模块都是 Hard Gate 任一模块失败 = 输出被拒绝

2. 必须实现的 6 个最小模块（不可删）

M1｜语义状态注册表

Semantic State Registry（SSR）

作用

定义：系统“现在在什么语义状态中”

最小实现

• 一个不可随意修改的状态表（JSON / YAML / DB）
• 每个状态包含：

{
  "state_id": "S-QUERY-FACT",
  "description": "事实性查询",
  "allowed_transitions": ["S-FACT-ANSWER", "S-UNCERTAIN"],
  "risk_level": "low"
}

硬性要求

• ❌ 不允许隐式状态
• ❌ 不允许“系统自己猜状态”

M2｜语义状态解析器

Semantic State Resolver

作用

将输入强制归类到一个明确语义状态

最小实现方式（任选其一）

• 规则匹配（regex / keyword map）
• 人工标注（MVP 初期可手动）
• 简单分类器（非必要）

输出格式（必须）

{
  "input_id": "req-001",
  "resolved_state": "S-QUERY-FACT",
  "confidence": 0.82
}

拒绝条件

• 无法确定状态
• 低于最小置信阈值

➡️ 直接 Reject，不生成内容

M3｜状态绑定输出门

State-Bound Output Gate

作用

禁止“裸输出”

所有输出必须包含：

{
  "state_before": "S-QUERY-FACT",
  "state_after": "S-FACT-ANSWER",
  "transition_rule_id": "T-FACT-01",
  "content": "..."
}

硬性要求

• ❌ 不允许纯文本输出
• ❌ 不允许“先输出，后补状态”

M4｜责任绑定模块

Accountability Binder

作用

回答文明三问：

谁触发？ 谁解释？ 谁负责？

最小字段

{
  "triggered_by": "user:123",
  "explained_by": "system:wao-mvp",
  "responsible_entity": "org:demo"
}

拒绝条件

• 任一字段为空
• 使用“anonymous / system-only”逃避责任

M5｜幻觉标记与拒绝机制

Hallucination Flagging Module

MVP 判定标准（简单即可）

• 引用不存在来源
• 事实自相矛盾
• 超出状态允许的确定性（如猜测当事实）

处理方式（必须）

{
  "hallucination_flag": true,
  "action": "reject",
  "reason": "Unverifiable factual claim"
}

📌 MVP 不要求“检测得很准” 只要求：一旦检测，就绝不放行

M6｜审计日志模块

Audit Logger（不可关闭）

所有请求必须写入

{
  "input_id": "req-001",
  "state_path": ["S-QUERY-FACT", "S-FACT-ANSWER"],
  "responsibility": {...},
  "timestamp": "...",
  "final_status": "rejected | accepted"
}

硬性要求

• ❌ 不允许“调试模式关闭日志”
• ❌ 不允许批量删除

3. MVP 的三条“不能做”红线（工程版）

❌ 禁止 1｜无状态输出

任何未绑定 state_before / after 的输出 = 非法

❌ 禁止 2｜模型即责任

“模型生成的”不是责任主体

❌ 禁止 3｜结果正确即可

结构不合法 → 结果无效

4. MVP 成功标准（不是性能）

✅ MVP 被认为“成功”当且仅当：

• 系统经常拒绝输出
• 工程师会抱怨： “这玩意太严格了”
• 用户必须学会把问题问清楚
• 日志比内容更重要

5. MVP ≠ Demo（关键认知）

6. 一句话工程总结（给 CTO）

WAO MVP 不是在“生成得更好”， 而是在工程上第一次让“不该生成的东西跑不出来”。

7. 下一步自然演进（不在 MVP 内）

• 自动化语义状态学习
• 多人治理与异议机制
• DAO / 法律 / 合规模块
• 与 LLM 的深度对接（但永不信任）