AI Agent Autonomy：委派架构
Agent autonomy 不是模型智能程度的刻度，而是组织把行动权委派给 AI 系统的方式。真正需要设计的不是“让 Agent 更自动”，而是回答：什么任务可以被委派、谁授权、能访问哪些数据、能调用哪些工具、能写入哪些状态、什么时候必须升级给人、如何撤销、如何证明它按边界行动。
AI Agent Autonomy / Delegation Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_AGENT_AUTONOMY_DELEGATION_ARCHITECTURE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织自主 agent 风险（AI RMF 1.0 发布 2023-01） |
| EU AI Act, Regulation (EU) 2024/1689 | https://eur-lex.europa.eu/eli/reg/2024/1689/oj | 参考 high-risk AI、human oversight、transparency 和 risk management（OJ 正式公布 2024-07；时间线已被 2026 Omnibus 修订，见文末 SOTA 检查） |
| OECD AI Principles | https://oecd.ai/en/ai-principles | 参考 human-centred values、transparency、robustness、accountability（访问日期: 2026-07-01） |
| ISO/IEC 42001 | https://www.iso.org/standard/81230.html | 用 AI management system 管理责任、运行控制和持续改进（标准发布 2023-12） |
| OWASP LLM Top 10 | https://owasp.org/www-project-top-10-for-large-language-model-applications/ | 参考 excessive agency、tool misuse、prompt injection 等 agent security 风险（v2025 版发布 2024-11；agentic 专用版见文末 SOTA 检查） |
核心导读
Agent autonomy 不是模型智能程度的刻度，而是组织把行动权委派给 AI 系统的方式。真正需要设计的不是“让 Agent 更自动”，而是回答：什么任务可以被委派、谁授权、能访问哪些数据、能调用哪些工具、能写入哪些状态、什么时候必须升级给人、如何撤销、如何证明它按边界行动。
在金融零售场景中，AI 从 assistant 到 copilot 再到 agent 的跃迁，本质是从“生成信息”变成“影响客户、账户、流程和风险状态”。因此 autonomy 必须被设计成可授权、可限制、可观察、可撤销、可降级的 delegation architecture。
1. 问题定义：自主权是被委派的行动权
许多 AI 产品会自然演进为三类能力：
assistant answers
-> copilot suggests
-> agent acts
这三个阶段的风险性质不同：
| 阶段 | AI 输出 | 主要风险 |
|---|---|---|
| Assistant | 解释、总结、草稿 | hallucination、过时信息、不安全建议 |
| Copilot | 推荐操作、生成工单、预填字段 | automation bias、弱复核、隐藏假设 |
| Agent | 调 API、改状态、发通知、触发流程 | unauthorized action、客户/财务损害、责任断裂 |
所以 autonomy 不应该被表达成一个模糊需求，例如“自动处理客户问题”。更准确的表达应当是：Agent 可以在某些任务上读取数据、推荐动作、生成草稿或执行低风险动作，但不得越过客户承诺、财务结果、法律结论、监管通知等高影响边界。
一个可上线的 autonomous agent 至少要定义以下问题：
| 设计问题 | 架构含义 |
|---|---|
| 做什么 | task boundary，而不是开放式目标 |
| 代表谁 | delegated authority 的来源 |
| 读什么 | data boundary 与 purpose limitation |
| 调什么工具 | tool allowlist 与最小权限 |
| 写什么状态 | write authority、可逆性和影响面 |
| 何时停下 | escalation、confidence gate、policy gate |
| 如何撤销 | token/session/tool/workflow kill switch |
| 如何复盘 | trace、evidence、approval、decision record |
2. 架构模型：从能力等级到委派合约
2.1 Autonomy level taxonomy
Autonomy level 的价值不是给产品贴标签，而是把“AI 可以影响系统到什么程度”转成可评审的架构边界。
| Level | 名称 | Agent 权限 | 适用场景 | 关键控制 |
|---|---|---|---|---|
| L0 | Human-only | AI 不参与 | 法律决定、最终信贷审批 | 无 AI action |
| L1 | Answer-only | 只能解释和总结 | 政策问答、知识检索 | citation、refusal、source freshness |
| L2 | Draft-only | 生成草稿，人类提交 | 客服回复、SAR narrative 初稿 | reviewer approval、diff view |
| L3 | Recommend-action | 推荐动作，人类点击执行 | case routing、next-best-action | confidence threshold、reason code |
| L4 | Bounded-execute | 自动执行低风险、可回滚动作 | 创建内部 task、更新非关键字段 | allowlist、rollback、rate limit |
| L5 | Conditional-autonomy | 满足策略条件时自动执行，异常升级 | 标准退款、KYC 文档追踪 | policy gate、exception queue |
| L6 | Supervised-multi-step | 多步计划和工具调用，过程受监控 | AML case triage、贷款服务流程 | supervisor、trace、checkpoint |
| L7 | Restricted-domain autonomy | 领域内高自治，但有硬边界 | 内部运营优化、库存/排班建议 | kill switch、KRI、periodic validation |
| L8 | Enterprise autonomy | 跨域行动 | 金融零售高影响场景通常不应默认开放 | board-level risk acceptance |
同一个产品通常不是单一等级。一个客服 Agent 可以在 L1 查询政策、在 L2 草拟回复、在 L3 推荐分类、在 L4 创建内部任务，但不得在 L5/L6 自动承诺赔付或关闭投诉。
2.2 Delegation contract
Delegation contract 是 autonomy 的核心架构对象。它把“AI 可以做什么”拆成任务、权限、证据和责任边界。
| 维度 | 要回答的问题 | 示例 |
|---|---|---|
| Delegator | 谁委派 Agent 行动 | customer service manager、AML operations lead |
| Agent role | Agent 代表哪个业务角色工作 | complaint triage agent |
| Task boundary | 可以完成哪些任务 | classify complaint、create case、draft response |
| Prohibited tasks | 明确禁止哪些任务 | deny claim、waive fee above threshold |
| Data boundary | 可以访问哪些数据 | customer profile、complaint history、product policy |
| Tool boundary | 可以调用哪些工具 | CRM read、case create、policy search |
| Write authority | 可以写入哪些状态 | case note、task assignment |
| Budget/time | 资源与时间边界 | max model calls、max execution time |
| Confidence gate | 低置信度如何处理 | source support threshold、schema validation |
| Escalation | 哪些情况必须升级给人 | vulnerable customer、legal threat、low confidence |
| Revocation | 如何停止授权 | disable tool scope、revoke session token |
| Evidence | 如何证明执行过程 | trace id、tool call log、reviewer decision |
没有 delegation contract 的 Agent，本质上是一个无法解释授权来源、行动边界和责任归属的影子执行者。
2.3 Reference architecture
business use case
-> risk tiering
-> delegation contract
-> agent runtime
-> tool gateway
-> policy / approval gates
-> downstream systems
-> evidence plane
-> monitoring / revocation / continuous validation
这套架构把 autonomy 从 prompt 设计提升为生产控制面：Agent runtime 负责推理和规划，tool gateway 负责动作边界，policy gate 负责决策约束，approval gate 负责人类控制，evidence plane 负责证明和复盘。
3. 关键机制与生命周期
3.1 Delegation lifecycle
Agent autonomy 的生命周期应按授权闭环设计：
| 阶段 | 设计重点 |
|---|---|
| Define | 明确 use case、客户影响、风险等级和禁止事项 |
| Delegate | 建立 delegation contract，绑定业务 owner 与授权范围 |
| Grant | 通过 purpose-bound token、scope、tool allowlist 授权 |
| Execute | 运行时执行 policy gate、confidence gate、tool validation |
| Escalate | 低置信度、高影响、异常输入、越权企图进入人工队列 |
| Observe | 收集 trace、tool call、human decision、output 和 incident signal |
| Revoke | 支持按 agent、tool、workflow、domain 分层停用或降级 |
| Revalidate | 根据 drift、incident、法规、业务变化重新验证边界 |
3.2 Approval-before-action
Approval-before-action 适用于客户可见、财务影响、法律/监管敏感或不可逆动作。AI 可以检索、解释、草拟和推荐，但最终提交必须由人类完成。
关键设计点包括：
| 控制点 | 设计要求 |
|---|---|
| Review surface | 人类能看到原始证据、AI 理由、动作影响和替代选择 |
| Decision capture | 审批、拒绝、编辑和 rationale 都进入 evidence trail |
| Diff view | 显示 AI 草稿与最终提交内容差异 |
| Accountability | 下游系统记录 human actor、agent actor、approval id |
3.3 Bounded execution
Bounded execution 适用于低风险、可回滚、内部可见、可监控的动作，例如创建 follow-up task、添加非最终 case note、把客户问题分类到队列。
边界必须清楚：
| 允许 | 禁止 |
|---|---|
| allowlisted tools | 任意 API 调用 |
| reversible / compensable actions | 不可逆客户承诺 |
| internal workflow updates | 直接改变账户、合同、贷款或监管状态 |
| rate limit and budget | 无限制循环执行 |
3.4 Supervisor、checkpoint 与 kill switch
Supervisor agent 不能只是另一个没有边界的 LLM。它应结合 policy engine、规则、trace、threshold 和风险状态，检查 worker agent 的计划、权限、证据和异常。对高影响动作，supervisor 只能作为前置检查，不能替代 human gate。
Kill switch 也不是事故后手工删代码，而是可运营的产品能力：
| 层级 | 操作 |
|---|---|
| Tool scope | 禁用特定工具或写入权限 |
| Agent role | 停用某个 agent 角色 |
| Workflow class | 停止某类流程自动化 |
| Domain | 某业务域全部降级到 draft-only |
| Global | 全局切断 agentic execution，仅保留只读或人工流程 |
4. 证据与控制
Autonomy 控制不能只停留在上线评审。运行时必须持续证明 Agent 在授权边界内行动。
| 风险 | 典型表现 | 控制 |
|---|---|---|
| Excessive agency | Agent 可以调用超出任务所需的工具 | least privilege tool scope、tool gateway |
| Unauthorized action | AI 替人提交高影响决定 | approval-before-action、step-up approval |
| Silent escalation failure | 应升级的 case 没升级 | escalation rules、queue monitoring、miss detection |
| Automation bias | 人类无实质复核 | reviewer UX、override tracking、sampling QA |
| Accountability gap | 说不清谁批准了什么 | delegation contract、actor chain、trace |
| Prompt injection | 外部内容诱导 tool call | instruction hierarchy、content isolation、policy gate |
| Model/vendor drift | 同样任务行为变化 | release impact assessment、canary、revalidation |
| Weak revocation | 出事后不能快速停用 | kill switch hierarchy、token/session revocation |
Evidence 应覆盖：
| Evidence | 用途 |
|---|---|
| run id / trace id | 串起一次 Agent 执行 |
| agent id / version | 识别行为来自哪个 Agent 配置 |
| prompt / policy profile version | 复盘模型行为上下文 |
| tool call log | 证明调用了什么、参数摘要、返回结果摘要 |
| policy decision | 说明 allow、deny、escalate 的依据 |
| human approval | 记录审批人、决定、理由和时间 |
| output / action result | 追踪客户或系统状态影响 |
| incident linkage | 把投诉、返工、损失、合规事件回连到 run |
5. 金融零售与 AI 产品场景
5.1 Customer service copilot
合理边界是分层的：L1 查询政策和解释术语，L2 草拟回复，L3 推荐 case category，L4 自动创建内部 follow-up task。禁止边界包括自动承诺赔付、修改合同、关闭投诉、发送监管敏感通知。
这个场景的关键不是“客服效率”，而是把客户可见承诺和内部运营动作分离。内部任务可以 bounded execution，客户承诺必须 approval-before-action。
5.2 AML investigation assistant
AML 场景可以让 Agent 总结交易、检索 typology、草拟 case narrative、推荐下一步调查，并自动拉取只读证据。自动提交 SAR、解除客户风险标记或关闭高风险 alert 必须禁止或进入强审批。
这里的核心控制是 evidence completeness：每一段 narrative 应能追溯到交易、政策、红旗规则和 analyst 修改。
5.3 Lending policy assistant
贷款政策助手可以检索政策、解释条件、草拟 rationale、识别缺失材料、推荐人工复核点。它不应自动批准/拒绝贷款、改变 risk grade、触发 adverse action。
贷款场景的边界必须关注 fair lending、adverse action、模型解释和人工最终责任。即使 Agent 只是“解释政策”，也要防止它把政策解释变成事实上的信贷决定。
5.4 Wealth advisory assistant
财富顾问助手可以做教育性解释、meeting note、资料整理和 advisor review item 推荐。未经授权的个人化投资建议、自动下单、自动调仓、诱导性推荐都属于高影响动作。
这个场景的关键是区分 education、preparation、recommendation 和 execution。不同动作对应不同 autonomy level 和证据要求。
6. 反模式
| 反模式 | 问题 |
|---|---|
| 用“自动处理”描述需求 | 隐藏了读、写、承诺、审批、升级等完全不同的风险 |
| 一个 Agent 绑定宽泛工具权限 | prompt injection 或任务漂移会直接变成系统级事故 |
| 只靠 prompt 要求 Agent 谨慎 | 没有 tool gateway、policy gate 和 runtime evidence，无法执行控制 |
| Supervisor 也是无边界 LLM | 表面上有监督，实际上扩大了不可解释决策链 |
| 人类审批 UI 只显示 AI 建议 | 审批者看不到证据、影响和替代选择，容易形成 automation bias |
| Kill switch 只能全局关停 | 过粗的停用能力会在事故中造成业务中断或无法精准止血 |
| 只在上线前评估 autonomy | 模型、数据、政策、工具和业务流程变化后，原边界会失效 |
7. 最终心智模型
Autonomous Agent 的治理核心不是“模型是否足够聪明”，而是“组织是否清楚地委派了什么行动权，并能在运行时持续执行边界”。在金融零售 AI 中，Agent architecture 应以 delegation contract 为中心，把 autonomy level、tool authority、human oversight、runtime evidence、revocation 和 continuous validation 连接成一个闭环。
可以用一个判断式来压缩理解：
No delegated authority without boundary.
No boundary without enforcement.
No enforcement without evidence.
No evidence without accountability.
SOTA 检查 (2026-07-01)
- Agent 安全基线已从 LLM Top 10 升级为专用框架：OWASP 于 Black Hat Europe 2025 期间发布 OWASP Top 10 for Agentic Applications 2026 版（2025-12），与 LLM Top 10 v2025（2024-11）并行作为 agentic 系统专用基线。它把本篇的 excessive agency 叙事细化为 "Least Agency"（自治权是需要被赢得的特性而非默认设置），并新增 uncontrolled autonomy、delegated identity abuse、cross-agent prompt injection 等 agentic 专属风险类别——写新的 agent 安全评审时应引用该框架而非仅 LLM Top 10。
- EU AI Act 时间线已被修订，本篇引用时需注意：经 Digital Omnibus（2026-05-07 达成临时政治协议，欧洲议会 2026-06-16 表决通过、理事会 2026-06-29 最终批准），Annex III 独立高风险系统义务推迟至 2027-12-02（Annex I 嵌入受监管产品的 AI 推迟至 2028-08-02）；但 Article 50 透明度义务基本维持原时间表（2026-08-02）。本篇对 human oversight / risk management 的架构要求仍成立，只是合规期限锚点要用新日期。
- 监管方开始直接标准化 agentic autonomy：Singapore IMDA 于 2026-01 发布全球首个专门针对 agentic AI 的 Model AI Governance Framework，引入 Agent Identity Cards（标准化披露 agent 的能力、限制、授权行动域和升级协议）——与本篇 §2.2 delegation contract 几乎一一对应；NIST 于 2026-02 启动自主 AI agent 标准专项。本篇的 delegation contract 设计从"最佳实践"正在变为"监管预期"。
- 不随版本过时的框架性结论：autonomy = 被委派的行动权（而非模型智能刻度）、delegation contract 作为核心架构对象、approval-before-action vs bounded execution 的二分、分层 kill switch、evidence plane——这些是与具体模型/平台版本无关的判断框架，2026 年的 agentic 治理框架（OWASP Agentic Top 10 的 Least Agency、IMDA 的 Agent Identity Card）都在收敛到同一结构。
- 库内配套实现笔记：运行时侧的渐进授权（progressive authorization）实现见
docs/aipa/day81-progressive-authorization.md（2026-06），agent 运行时权限与 hook 边界见docs/aipa/day59-claude-agent-sdk.md（2026-06）；操作手册版仍是docs/AI_AGENT_AUTONOMY_DELEGATION_ARCHITECTURE_PLAYBOOK.md。