《WAO Protocol 最小实现规范(MVP 工程版)》下面是可直接交付工程团队、可写入 README / RFC / MVP 任务
WAO Protocol 最小实现规范(MVP 工程版)
《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(关键认知)
| Demo | WAO MVP |
|---|---|
| 展示能力 | 强制约束 |
| 多输出 | 多拒绝 |
| 流畅 | 可追责 |
| 用户爽 | 文明稳 |
6. 一句话工程总结(给 CTO)
WAO MVP 不是在“生成得更好”, 而是在工程上第一次让“不该生成的东西跑不出来”。
7. 下一步自然演进(不在 MVP 内)
- 自动化语义状态学习
- 多人治理与异议机制
- DAO / 法律 / 合规模块
- 与 LLM 的深度对接(但永不信任)
Comments (0)
No comments