#Agent 执行真实操作前为什么必须有人类确认

Agent 最吸引人的地方，是它可以替用户完成任务。

它可以查资料、读文档、规划步骤、调用工具、填写表单、发送邮件、修改数据，甚至跨多个系统连续执行。也正因为如此，Agent 的风险不再只是“回答错了”，而是“做错了”。

只要一个动作会影响真实世界、真实账户、真实客户或真实数据，就不能让模型直接执行到底。执行前必须有人类确认，至少在高风险动作上必须如此。

人类确认不是对 AI 能力的不信任，而是对责任边界的设计。模型可以建议，系统可以校验，人类负责授权，工具负责执行，审计负责追踪。

#什么叫真实操作

真实操作不是指“很复杂的操作”，而是指会产生外部影响或持久变化的操作。

典型例子包括：

• 发送邮件、短信、站内信或通知。
• 删除、修改、移动文件。
• 创建、取消或修改订单。
• 提交表单、工单、报销或审批。
• 修改用户权限、团队成员或安全配置。
• 调用生产 API。
• 发布文章、评论、代码或配置。
• 发起支付、退款、转账或采购。
• 把数据导出到外部系统。

这些动作一旦发生，影响可能已经离开 AI 应用本身。即使模型后来说“我理解错了”，邮件已经发出，权限已经改动，客户已经收到通知，账务系统已经生成记录。

所以 Agent 的执行边界必须比普通聊天严格得多。

#为什么模型不能直接代表用户授权

模型没有真正的授权能力。

用户说“帮我处理一下”，不等于授权 Agent 可以删除文件、发送邮件或修改生产数据。用户说“可以”，也要看是在什么界面、针对什么动作、确认了哪些参数。

自然语言授权有三个问题。

第一，范围不清。
“帮我清理一下文档”可能是归档，也可能是删除。模型对范围的理解不一定等于用户真实意图。

第二，参数不透明。
用户可能同意“给客户发邮件”，但并没有看过收件人、正文、附件和抄送列表。

第三，责任不可审计。
如果系统只保存一段聊天记录，很难证明用户确认的是哪个结构化动作。

因此，确认必须发生在产品交互层。用户确认的对象应该是工具调用计划和关键参数，而不是模型的一句“我准备好了”。

#人类确认在架构中的位置

人类确认应该位于模型建议和工具执行之间。

这个流程里，Agent 只生成 proposal。Policy Engine 决定是否允许进入确认。用户确认后，Tool Executor 才真正执行。

确认不是一个弹窗形式问题，而是一个状态机问题。系统应该能表达“等待确认”“已批准”“已拒绝”“已过期”“已取消”“已执行”“执行失败”这些状态。

#哪些动作必须确认

不是所有 Agent 动作都需要确认。读取天气、搜索公开网页、总结当前用户上传的文件，通常可以自动执行。

但以下动作应该默认需要确认：

工程上可以把工具分成风险等级：

type ToolRiskLevel =
  | 'read_only'
  | 'draft'
  | 'write_internal'
  | 'external_effect'
  | 'financial'
  | 'permission_change'
  | 'irreversible';

read_only 可以自动执行。draft 可以生成草稿但不发送。write_internal 视业务要求确认。external_effect 以上通常必须确认。

#确认界面应该展示什么

确认界面最重要的原则是：展示结构化事实，而不是展示模型劝说。

用户需要确认的是：

• 将要执行的动作。
• 使用的工具或系统。
• 目标资源。
• 关键参数。
• 影响范围。
• 是否可撤回。
• 执行账号或身份。
• 风险提示。
• Agent 给出的理由和证据。

例如邮件发送确认：

确认按钮旁边应该有取消或返回修改。对高风险操作，还可以要求二次输入、管理员审批或 MFA。

不要只展示：

AI 将为你发送一封合适的邮件，是否继续？

这不是确认，只是把用户推向相信模型。

#确认要绑定结构化计划

一个可靠的确认机制，必须把确认绑定到具体 action proposal。

type ActionProposal = {
  id: string;
  runId: string;
  toolName: string;
  args: Record<string, unknown>;
  riskLevel: ToolRiskLevel;
  resourceIds: string[];
  summary: string;
  createdBy: 'agent';
  createdAt: string;
  expiresAt: string;
  status: 'pending' | 'approved' | 'rejected' | 'expired' | 'executed';
};

type ApprovalRecord = {
  id: string;
  proposalId: string;
  approvedBy: string;
  decision: 'approved' | 'rejected';
  visibleSummaryHash: string;
  decidedAt: string;
};

这里有一个容易被忽视的细节：用户确认后，执行时不能让 Agent 临时改参数。

如果用户确认的是给 lin@example.com 发邮件，执行时就不能变成给另一个地址发送。确认记录应该绑定 proposal id、参数快照和可见摘要。执行器只执行已批准的参数。

#人类确认不是唯一防线

确认很重要，但不能把所有安全责任都推给用户。

用户不应该承担识别每个权限错误、注入攻击和危险参数的责任。确认前，系统仍然必须完成权限校验和风险判断。

正确顺序应该是：

1. Agent 生成动作计划。
2. 系统校验工具名和参数 schema。
3. 系统校验用户、租户和资源权限。
4. 系统判断风险等级。
5. 高风险动作进入确认。
6. 用户确认结构化参数。
7. 执行器用受限凭证执行。
8. 系统写入审计日志。

确认是责任边界，不是替代权限系统的借口。

#合规视角：确认记录是一种证据

在企业应用里，确认记录不仅是产品体验，也是合规证据。

当用户投诉、客户审计、内部安全复盘或监管检查发生时，系统需要回答：

• 谁发起了 Agent run？
• Agent 建议执行什么动作？
• 当时用户看到了哪些关键参数？
• 谁在什么时候批准？
• 实际执行参数是否和批准参数一致？
• 执行结果是什么？
• 是否可以撤回或补救？

如果没有结构化确认记录，只能回放聊天记录，责任很难说清楚。

对于敏感行业，确认还可能需要更严格的控制：

• 四眼原则：一个人发起，另一个人批准。
• 分级审批：金额越大，审批级别越高。
• MFA：高风险操作确认时重新验证身份。
• 数据导出水印：记录导出人和用途。
• 保留期限：确认记录按审计要求保留。

这些都不是模型能力问题，而是应用治理问题。

#如何降低确认带来的打扰

有人担心确认会降低 Agent 的自动化价值。这个担心合理，但解决办法不是取消确认，而是设计风险分级。

可以采用三种策略。

第一，自动执行低风险读操作。
例如搜索、读取当前用户有权访问的文档、生成草稿、计算摘要。

第二，把写操作拆成草稿和提交。
Agent 可以自动生成邮件草稿、表单草稿、配置 diff，但提交前确认。

第三，对重复低风险动作使用受限授权。
例如用户可以授权“未来 24 小时内，允许自动把符合条件的会议纪要保存到当前项目文件夹”。这种授权必须有范围、期限和撤销入口。

这样既保留自动化效率，也不牺牲责任边界。

#常见坑

第一个坑是把聊天里的“好的”当确认。用户在自然语言中说“可以”不等于确认了具体工具、参数和影响范围。

第二个坑是确认后仍让 Agent 改参数。用户确认的是参数快照，执行器必须执行同一个快照，否则确认失去意义。

第三个坑是确认界面只显示模型总结。模型总结可以辅助理解，但必须展示真实结构化参数，尤其是收件人、金额、资源 ID、权限变化和是否可撤回。

第四个坑是所有动作都确认。这样会制造确认疲劳，用户最后会机械点击。应该按风险分级，让低风险动作自动化，高风险动作严肃确认。

第五个坑是没有过期机制。Agent 生成的 proposal 不应该永久有效，特别是价格、库存、权限和外部状态可能变化的场景。

第六个坑是用管理员凭证执行所有工具。即使用户确认了，也应该用最小权限、可追踪的执行身份，而不是共享超级 token。

第七个坑是缺少拒绝和修改路径。用户不批准时，Agent 应该能理解是取消、改参数、生成草稿还是请求更多信息。

第八个坑是没有审计可见性。确认记录、执行结果和失败原因应该能被用户、管理员或安全团队按权限查看。

#小结

Agent 的价值在于能行动，但行动必须有边界。

模型可以计划，不能独自授权。系统可以校验，不能替用户承担所有意图判断。用户可以确认，但确认必须基于结构化参数和清晰风险。执行器可以调用工具，但必须使用受限权限并留下审计记录。

人类确认不是让 Agent 变笨，而是让 Agent 进入真实业务系统前具备责任链路。没有确认的 Agent，适合 Demo；有权限、确认、审计和恢复机制的 Agent，才有机会进入生产环境。