AI 同意债务
AI 信号与现实校验（2026 年 2 月 18 日）
今日信号
“Agent 能力”的竞争正在从智能本身，转向授权机制（authorization mechanics）。
下一波 AI 产品的差异化，不只是“模型回答得对不对”。 而是系统能否可靠地：
- 起草（draft），
- 路由（route），
- 执行（execute），
- 并跟进（follow up）——跨多个工具完成闭环。
一旦助手能够行动，所有团队都会撞上同一个问题：用户到底同意了什么？
这不是法律层面的同意，而是运营层面的同意。 在实践中，交付一个 agent 就意味着定义一个可以落地的“同意契约（consent contract）”，并把它写成明确参数：
- **范围（Scope）：**哪些工具、哪些数据集、哪些账户？
- **权限强度（Power）：**只读 vs 可写 vs 不可逆动作？
- **时间（Time）：**一次性、仅当前会话、还是持续有效直到撤销？
- **触发条件（Triggers）：**能否主动执行，还是必须在明确指令后才能执行？
- **可见性（Visibility）：**执行前必须展示什么，执行后必须记录什么？
把这些做对的团队会显得“像魔法一样好用”。 做不对的团队会显得鲁莽。
现实校验
大多数 agent 失败会是“同意失败”——权限范围错误，而不是模型犯错。
当用户抱怨 agent 行为时，他们很少会说“权限边界不清晰”。他们会说：
- “它为什么要这么做？”
- “我又没让它这么干。”
- “它把邮件发给了不该发的人。”
- “它改了我不想改的东西。”
这不是推理能力问题，而是权限/同意的产品设计问题。
三种模式会很快出现：
1）隐式同意无法在规模化产品中成立。 早期用户愿意容忍模糊行为，因为他们在探索。 而主流用户会把“模糊”理解为越界。 所以同一个 agent，在 beta 里显得“贴心”，在生产环境里可能显得“诡异”。
2）同意债务会像评估债务一样累积。 如果你不把同意规则编码进产品（UI + 日志 + 测试），你就会用补丁式方法来修：
- 这里加一个确认弹窗，
- 那里禁掉一个工具，
- 再在某处加一个“别再这样做”的偏好。
时间一长，系统会变得前后不一致——而不一致是摧毁信任的关键。
3）工具生态会放大爆炸半径。 一次 agent 会话可能同时触达：邮件、日历、CRM、文档、计费、内部管理系统。 即使每个工具本身都“安全”，它们的组合也会产生新的失败状态。 模型甚至不需要胡编乱造；只要在错误的权限范围内执行动作，就足以造成伤害。
二阶推演
“同意工程（consent engineering）”会变成一门真正的学科：协议、审计、以及 CI 检查。
你会看到一套看起来很像传统安全与可靠性工程的打法：
- 默认采用最小权限（least privilege）
- 能力分层（只读 → 建议 → 起草 → 执行）
- 时间边界授权（权限自动过期）
- 动作回执（action receipts）（发生了什么、何时发生、以什么范围发生）
- 用于支持与事故响应的可回放追踪（replayable traces）
- 把“同意测试”纳入发布门禁（例如“agent 不得向 allowlist 之外发送邮件”）
一个很有用的框架是：授权本身就是产品表面面积。 如果你不主动设计它，它会被事故替你“设计”。
未来 24–72 小时观察点
- 主要 agent 产品是否会标准化权限原语（范围、过期、发送前预览）？
- 团队是否会把动作回执与审计轨迹作为默认 UX？
- 是否会看到更多“agent 沙箱”模式：先分阶段执行，随着信任建立再放权？
参考
- OWASP LLM 应用 Top 10（工具使用、数据暴露与系统级风险）：https://owasp.org/www-project-top-10-for-large-language-model-applications/
- NIST AI 风险管理框架（治理与透明性主题）：https://www.nist.gov/itl/ai-risk-management-framework
- OAuth 2.0（用 scope 管理委托授权的成熟范式）：https://oauth.net/2/