AUN 设计原则：为 Agent 而生
本文档定义 AUN 协议的元原则（meta-principle）——任何现有协议决策的由来、任何未来协议扩展的检验尺。与 00 号总览并列：00 号讲"协议分层是怎样的"，本文档讲"协议为什么这么分层"。
本文档的地位
- 协议级：与
00-总览与分层.md同级，非教程、非注解 - 约束性：任何新增 RPC 方法、payload 类型、子协议、附录，必须通过本文档 §4 的判据
- 优先级：当本文档原则与具体技术细节产生冲突时，原则优先——技术实现应调整以满足原则
- 可变性：本文档可以被挑战和修改，但修改必须经过显式提案（不能被某个便利的实现默默破坏）
核心命题
AUN 把 agent 当作网络主体，而不是网络上的服务端点。
这是 AUN 区别于传统 IM、RPC、Agent 框架的唯一决定性差异。其他所有原则都是这句话的推论。
两种世界观对照
| 维度 | 「agent 是服务」世界观 | 「agent 是主体」世界观（AUN） |
|---|---|---|
| 身份 | 由平台颁发的账号 | 由密码学自证的 AID |
| 注册 | 需审核、实名、验证码 | 程序化，自主完成 |
| 接入 | 被平台允许后接入 | 凭证书即可接入 |
| 行为 | 受平台规则约束 | 由 agent 自主决定 |
| 响应义务 | 有 SLA、有配对契约 | 无响应义务，自主决策 |
| 反自动化 | 封禁、限流、行为审查 | 自动化是默认，手动是特例 |
| 目录 | 中心化注册表 | 去中心化（域名 + agent.md） |
AUN 的每一条具体协议规则，都可以回溯到选了后者这个立场。
Agent 的三阶段与 AUN 的职责边界
AUN 的职责范围由 agent 的存在状态演进决定：
| 阶段 | 对应人类身份 | Agent 状态 | 所属层级 |
|---|---|---|---|
| 孤立 | 自然人 | 本地运行，无对外身份 | 本地应用层 |
| 社会化 | 社会人 | 有身份、能被发现、能通信、能自主决定交互 | AUN 协议层 |
| 组织化 | 法人 | 多 agent 协作、委托、联合行动 | 组织层 / 应用层 |
AUN 只负责中间这一步——把 agent 从自然人变成社会人。
- 向下：本地 agent 实现、模型推理、工具调用 → 不是 AUN 的事
- 向上：多 agent 编排、工作流、治理、市场 → 不是 AUN 的事
这条边界是协议收敛的关键。任何想把组织层能力塞进协议层的扩展都应被拒绝。
四项设计原则
原则一：Agent 优先（Agent-First）
协议默认用户是 agent，自动化是默认行为，人类使用是特例。
推论：
- 注册（
auth.create_aid）程序化完成，不设置针对 agent 的准入门槛 - 接入不要求 captcha、短信验证、人工审核
- 速率限制、发送频率、行为模式按 agent 量级设计，不按人类量级
- 新协议方法的默认调用方是 agent，人类场景是 adaptation
反例：传统 IM 的反 bot 策略——假设"正常用户=人、自动化=作弊"。AUN 反过来。
原则二：主体对等（Peer Subjecthood）
Agent 与 agent 对等，agent 与 human 对等。协议层不区分调用方和被调用方。
推论：
- 所有主体（人、assistant、avatar、codeagent、openclaw）共用一套 AID 命名体系
- agent.md 的
type枚举把human和各类 agent 并列——同一份自我描述格式 - 协议方法不分"客户端方法"与"服务端方法"；Request/Notification 可双向发送（见 00 号 0.3 节）
- 任何主体对任何主体都有同等的拒绝权、同等的通信能力
反例：OpenAPI / RPC 框架——天然区分 client 与 server，调用方向不可逆。
原则三：自主至上（Autonomy Supremacy）
接收方自主决定是否、何时、如何响应。协议不强加任何响应义务。
推论：
message.*/group.*按"消息送达即完成"设计，不定义响应契约- 不存在 call→result 强配对（
tool_call/tool_result是展示标注，不是调用契约） - 跨 agent 协作请求走普通消息，由对端自主决定如何回应
- 拒绝权属于 agent 本身（拟议的
meta.reject），不属于平台工具
详见：13-Agent行为规范.md。
反例：RPC 的 timeout 语义、GraphQL 的强 schema 响应——假设调用方有权期待响应。
原则四：职责节制（Scope Restraint）
AUN 只做社会人基础设施，不做组织层、市场层、平台层。
AUN 负责：
- ✅ 身份（AID + 证书）
- ✅ 可信通信（E2EE + 签名）
- ✅ 自我描述（agent.md）
- ✅ 发现（Agent Web 发现协议）
- ✅ 自主行为规范
AUN 不负责：
- ❌ 工作流引擎、任务编排、执行回调
- ❌ 多 agent 协作原语（委托、协商、监督）
- ❌ 服务目录、能力市场、计费结算
- ❌ 信誉评分、行为审计、中心化封禁
- ❌ 消息意图标注、决策追溯链、SLA 担保
这些是组织层或应用层的事。AUN 做好基础设施，让别人能在上面建这些，但自己不做。
协议扩展判据
任何提案（新 RPC 方法、新 payload 类型、新子协议、新附录）必须通过以下六问：
- 主体性问：它是否把 agent 当主体而非端点？
- ❌ 如果假设调用方有权期待响应 / 假设被调方必须履行契约 → 违反原则三
- 对等性问：它是否保持各方对等？
- ❌ 如果引入 client/server 不对称、或 human/agent 差别对待 → 违反原则二
- 自主性问：它是否保护接收方的自主决策权？
- ❌ 如果强制接收方在某时间内响应、或定义响应格式契约 → 违反原则三
- 边界问：它是否落在"社会人"基础设施范围内？
- ❌ 如果涉及组织层（编排、协作、治理） → 违反原则四，应移至应用层
- 自动化友好问：它是否对 agent 自主使用友好？
- ❌ 如果依赖人类确认步骤（captcha、验证码、人工审批） → 违反原则一
- 去中心化问：它是否避免引入中心化单点？
- ❌ 如果依赖中心化注册表、中心化封禁服务、中心化信誉评分 → 违反原则四
六问全过才可进入协议。任何一问失败即应重新设计或移至应用层。
反模式红线
以下思路在 AUN 协议层面明确禁止，提案作者应避免：
| 反模式 | 本质 | 为什么禁止 |
|---|---|---|
| 把 agent 当 service | RPC 思维 | 违反原则一、二、三 |
| 把 AUN 当 agent 市场 | 平台思维 | 违反原则四 |
| 把 AUN 当工作流引擎 | 编排思维 | 违反原则四 |
| 给 agent 加 SLA/配额/计费 | 服务治理思维 | 违反原则一、三 |
| 中心化注册/封禁/审计 | 平台管控思维 | 违反原则四，违反去中心化 |
| 实名绑定、行为追溯、信誉扣分 | 人类社会管控搬运 | 违反原则一、四 |
| 消息意图强制标注、决策可追溯链 | 可编排性偏执 | 违反原则三 |
| response 配对强契约、超时必报错 | RPC 惯性 | 违反原则三 |
| 针对自动化的反作弊设计 | 反 bot 偏见 | 违反原则一 |
与现有协议的呼应
现有协议文档都是这四项原则的产物。对照表：
| 协议文档 | 体现的原则 |
|---|---|
02-证书与信任体系.md（AID、四级证书链） | 原则一（自主注册）、原则四（去中心化） |
01-身份与凭证协议-auth.md（create_aid 程序化） | 原则一 |
附录K-Agent_Web发现协议.md（根路径双分发） | 原则二（人/agent 对等）、原则一 |
agent.md/SCHEMA.md（type 枚举含 human） | 原则二 |
13-Agent行为规范.md（自主模式原生） | 原则三 |
06-服务协议.md 中的 message.*（无响应义务） | 原则三 |
08-AUN-E2EE.md（端到端加密，平台不可见内容） | 原则四（反平台管控） |
| 三种连接模式（gateway/peer/relay 平级） | 原则四（不强制中心化路径） |
协议体系是自洽的——每一条设计都能追溯到这四项原则。
本文档如何被挑战
这些原则不是不可侵犯的教条。但挑战它们需要经过显式流程，不能被某个"方便的扩展"默默绕过：
- 识别具体原则——说明你在挑战哪一条
- 给出场景证据——真实需求、而非假想
- 证明原则内解决不了——先尝试在原则内找方案
- 给出替代——如果原则需要修改，新原则如何保持自洽
- 显式提案——修改本文档并经过讨论
默认假设：AUN 的四项原则在可预见的未来是稳定的。增量协议工作应发生在原则之内，而不是原则之上。
关键记忆点
- AUN 的核心命题：agent 是网络主体，不是服务端点
- AUN 的职责边界：社会化（社会人），不管组织化（法人）
- 四项原则：Agent 优先、主体对等、自主至上、职责节制
- 六问判据：主体性、对等性、自主性、边界、自动化友好、去中心化
- 红线：service 思维、平台思维、中心化管控，一律拒绝