审批（Approval）
先用一句话说清楚
审批（Approval）是在高风险动作执行前，由用户、管理员或人工审核者确认是否允许继续的控制机制。
实战知识卡
| 维度 | 要点 |
|---|---|
| 项目里看什么 | 看哪些动作必须人工确认，审批结果是否进入状态和审计记录。 |
| 新手最该记住 | 审批（Approval）不是拖慢系统，而是把高风险责任交还给人。 |
| 作品集证据 | 展示一个“模型建议执行，但等待人工确认”的任务状态。 |
| 面试回答公式 | 先区分只读、草稿、写入和高风险动作，再说明审批超时、拒绝和通过怎么处理。 |
| 常见扣分点 | 把 Prompt（提示词）当成审批机制。 |
新手通俗解释
AI Agent（人工智能体）可以建议“创建退款申请”，但不应该自己直接退款。它可以生成合同审查意见，但不应该自动发正式法律通知。审批（Approval）就是在这些动作前加一道人工或规则确认。
审批（Approval）不是拖慢系统，而是把责任边界说清楚：模型负责建议，系统负责校验，人负责确认高风险动作。
为什么岗位会问它
企业项目里，模型错误可能造成真实损失。面试官问审批（Approval），是在看你是否知道哪些动作不能全自动。
| 场景 | 是否需要审批 |
|---|---|
| 查询公开政策 | 通常不需要 |
| 查询个人订单 | 需要身份和权限校验 |
| 创建普通工单 | 可能需要用户确认 |
| 退款、改价、取消订单 | 需要人工审批 |
| 合同、财务、人事结论 | 需要人工复核 |
它在项目里怎么用
Tool Calling（工具调用）平台里，审批（Approval）通常和风险等级绑定：
| 风险等级 | 处理方式 |
|---|---|
| 低风险 | 自动执行，记录日志 |
| 中风险 | 用户确认后执行 |
| 高风险 | 人工审批后执行 |
| 不允许 | 拒绝执行并说明原因 |
审批记录应该进入审计（Audit），包含审批人、审批时间、审批结果、关联 Trace ID（追踪编号）和操作摘要。
和用户确认的区别
用户确认通常是“你确定要提交这个工单吗”；审批（Approval）更强调权限和责任，可能需要主管、管理员或业务负责人确认。高风险动作不能只靠模型和普通用户确认。
常见误解
| 误解 | 为什么不对 | 正确理解 |
|---|---|---|
| 审批（Approval）会让系统不智能 | 高风险动作本来就不能随意自动化 | 智能是把风险分级处理 |
| 用户点确认就够了 | 用户可能没有权限 | 审批要看角色和责任 |
| 只要 Prompt（提示词）写清楚就不用审批 | 模型不能承担业务责任 | 系统必须有硬边界 |
| 作品集不用做审批 | 面试一定会追问高风险动作 | 至少要展示审批设计 |
面试官可能怎么追问
1. 哪些工具调用必须审批？
考察点： 是否能区分风险。
参考回答： 涉及写入、金钱、客户权益、合同、财务、人事、删除数据、发送正式通知的工具调用都要审批或人工确认。只读查询也要做权限校验，但不一定要审批。
容易扣分： 所有工具都自动执行。
2. 审批失败或超时怎么办？
考察点： 是否有流程闭环。
参考回答： 审批拒绝时任务应终止或改为草稿，不继续执行；审批超时要提醒、转交或标记待处理；所有状态变化都要进入审计（Audit）记录，避免用户误以为已经完成。
容易扣分： 审批没结果时继续执行。
作品集里怎么展示它
- 在工具清单中标注风险等级和审批要求。
- 展示一次高风险工具调用进入待审批状态。
- 展示审批通过、拒绝、超时三种状态。
- 展示审批记录如何进入审计（Audit）。