@agentunion/fastaun-browser 0.2.19 → 0.2.20

package/_packed_docs/protocol/00A-/350/256/276/350/256/241/345/216/237/345/210/231-/344/270/272Agent/350/200/214/347/224/237.md

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