让 AI 替你办事之前，先决定哪些事不能交出去

1. 代理的风险来自它能改变外部世界

先把两类事情分开，很多混乱会立刻消失。一类是辅助：AI 归纳会议记录、比较两份文档、为邮件写初稿、从公开资料里整理候选名单。人拿到结果后，仍然决定是否采用，也仍然亲手把结果送入外部系统。另一类是行动委派：AI 在运行中根据已有信息选择工具，读取邮箱、查询数据库、修改工单、创建日程、发送消息或触发付款。后者不只是“生成更多文字”，而是在替某个身份改变系统状态。

Anthropic 对 workflow 与 agent 的区分有一个很实用的提醒：前者通常由预先定义的代码路径编排，后者则让模型在过程中动态决定下一步和工具使用。代理会根据工具返回的结果继续判断和行动；因此，真正需要关注的是它在多大程度上能自己决定路径、接触外部输入并产生写入效果。该文也提醒，更多自治会带来成本和可能累积的错误，需要有检查点和停止条件。^[1]

外部输入需要单独处理。人们容易把“工具返回的内容”想成可信的数据库字段，实际上它也可能是邮件正文、网页、附件、客户留言或第三方系统同步过来的文本。AgentDojo 以 97 个任务和 629 个安全测试案例构造了这类环境，研究对象正是会读取不可信数据并调用工具的代理；其摘要报告，提示注入能够影响这类系统，而当时的先进模型即使没有攻击也会在许多任务上失败。^[2] 这并不证明所有接了工具的 AI 都不安全，更不能把一个基准的结果外推成现实世界的发生率。但它说明了一个工程事实：一条看似只是“读进来”的内容，可能影响随后“做出去”的动作。

因此，评估行动委派时，任务名称没有多少解释力。“帮我处理邮件”可能只是把未读邮件按主题分组，也可能包括扫描附件、草拟回复、代表本人发送、把内容同步到 CRM、为联系人添加标签。前一个动作的错误大多还能在界面里被看见；后几个动作会向外传递信息、改变记录，甚至让别人基于错误信息继续行动。把它们统称为一个任务，会把风险最高的那一步藏在便利的描述里。

更有用的做法，是在接入前画出一条行动链：输入从哪里来；模型能选择哪些工具；每个工具以哪个账户运行；可读取哪些对象；可写入、发送、删除或购买什么；工具返回的数据会不会进入下一轮推理。这个动作不需要一张复杂架构图，哪怕是一页简单的表格，也能迫使团队发现原本没有说清的授权。例如，“起草”与“发送”应当是两个独立能力；“搜索客户”与“导出客户名单”也不应共享默认权限。

这也解释了为什么不必把所有多步骤系统都视作高风险代理。对于定义清楚、路径固定、结果能被程序校验的工作，预定义流程可能比开放式地让模型自行选择下一步更可预测。比如每天从固定格式的公开公告中抽取日期，并在格式校验失败时停止，和让系统自由浏览网页、选择联系人、决定是否发信，不是同一种自治。本文关心的不是给产品贴标签，而是识别哪一个能力真正把决定带到了外部世界。

一旦这样看，标题里的“替你办事”就有了精确含义：不是替你给出建议，而是以你或你的组织的身份，动用权限，让他人、账户、数据或资源处于不同状态。边界应从这里开始画。

2. 委派等级应由后果、权限与可逆性共同决定

任务看起来简单，常常是最容易让人放松警惕的地方。删除一条记录只需一次点击，给一个人增加访问权也许只需选择一个下拉选项，向一个错误地址转发文件只需按一次发送。这些动作在操作层面都很简单，却可能有很高的后果。相反，一个复杂但只读的分析任务即使耗时，也未必比一次不可撤回的写入更适合降低人类控制。

风险管理框架并不把风险等同于“模型会不会犯错”。NIST 在 AI RMF 中把风险放在事件发生的可能性与后果幅度的组合里，并强调可接受的风险取决于具体应用、情境和风险容忍度；当明显的负面影响逼近、严重伤害正在发生或风险不可接受时，系统应能够安全地停止开发或部署。该框架还要求记录预期用途、使用情境、受影响者、潜在影响及应用范围。^{[3] [4]}

这套框架不会替一个个人用户或小团队给出统一的“自动化分数”。它的价值在于逼人先把情境写清楚。本文据此提出一项编辑建议：每次要把一个动作交给 AI 之前，先用四个变量做一次不超过十分钟的检查。它不是合规表格，也不该被压缩成一个看似精确的总分；四项里只要有一项升高，就应降低自治程度，或者把动作拆开。

第一项是后果与不可逆性。这个动作是否会形成承诺、转移资金、改变服务、影响第三方安排，或者留下难以消除的记录？“AI 帮我修改会议标题”与“AI 取消参加者已经接受的会议”差异不在文字质量，而在后果是否会扩散。判断不可逆性时，也不要只问系统有没有撤销按钮。已经送达的邮件、已经披露的信息、已被他人据以安排的承诺，即使数据库字段能改回，也不一定能恢复到原来的关系状态。

第二项是权限范围。它用的是谁的身份，拥有只读、有限写入还是管理员级权限？它能操作一个项目，还是全部客户、全部文件夹和全部账户？权限越广，同一个判断错误能波及的范围越大。很多系统在试用时直接接上主账户，是因为这样最方便；从风险角度看，这相当于先把最难收回的能力交出去，再希望提示词足以约束它。权限应先于提示词被设计。

第三项是数据敏感度。系统为了完成动作，是否会看到身份信息、私人通信、健康资料、财务数据、客户资料、源代码、商业计划或合同内容？它的输出会不会把这些资料交给一个新的接收方？“只读”不等于无害，读取本身就可能构成暴露；“不写数据库”也不等于没有外部后果，如果分析结果被带到不该接触的人面前，伤害已经发生。尤其应区分已获授权的内部处理，与向新的服务、联系人或系统披露资料。

第四项是可观察、可停止、可恢复性。错误能否独立地被发现，而不是只能依靠系统自己说“我做对了”？有没有清楚的暂停点，能在影响扩大前停止？写入前能否预览，写入后能否回滚，出现异常时谁接手？这三件事缺一不可。一个动作即使理论上可撤销，若日志不可读、触发条件不清、管理员几小时后才会看到告警，它在实际运行中仍接近不可控。

用这四项看，同一工作会落在不同等级。低影响、可逆、结果可验证的工作，通常可以较大胆地委派。例如，让系统把公开材料按预先定义的主题分类，或从内部只读工单中生成一份供人审阅的候选清单。这里的关键是输出能被比对、任务可重跑，且错误不会直接改变第三方的权利或资源。

第二类是有边界的外部行动：结果会产生影响，但在执行前能清楚展示对象、范围、金额、数据去向和替代方案。它们适合让 AI 准备到最后一步，再交给有责任的人批准。比如拟好一封对外邮件、生成一笔低于预设额度的采购申请、提出非关键 CRM 字段的修改，或者排好等待确认的日程变更。这里的“批准”应把真正的承诺留在可判断的关口。

第三类则不应由一个通用的“风险分数”悄悄放行。只要动作会形成重大或难以撤回的承诺、动用过宽权限、披露新的敏感资料，或对有争议的利益作实质裁断，它就应进入明确的人类控制范围。AI 可以参与查找材料、归纳证据、检查既定规则、起草多个方案；但不能因为任务名称短、执行步骤少，就让它替人承担最后的责任。

这里要保留一个不舒服但必要的事实：没有一张通用表能替代专业、法律或业务判断。NIST 也提醒，风险测量会受数据、指标和情境限制，某些影响难以被完整量化，指标还可能简化或掩盖重要差异。^[3] 四变量检查的目的不是制造一个“低于 60 分即可自动化”的幻觉，而是让团队在权限被接上之前看见最重要的追问：谁会被影响，错了以后谁来补救，为什么我们认为这个后果可承受。

3. 批准是对可承受承诺的闸门，不是事后的点头

不少产品已经有“请确认”的按钮，但确认并不天然等于控制。有的确认窗口只显示一句“即将执行操作”，没有对象、金额、权限、差异或数据去向；有的把十几个不相干动作塞进一个批量勾选框；有的在用户看不到最终内容时就要求点击同意。这样的批准只是在系统已经做出决定后，向人索取一个难以追责的手势。它既不能帮助人发现错误，也容易在高频使用中变成条件反射。

OWASP 把未经过独立验证和批准的高影响行动列为 excessive autonomy 的典型问题，并建议限制扩展功能和权限、在用户自身上下文中执行、对高影响行动保留人工批准，同时记录和监测扩展及下游系统的活动。^[5] 这是一组安全实践建议，不是一条“加确认弹窗就安全”的证明。恰恰相反，它提示我们：批准只有在批准者能看见足以改变决定的信息时，才有意义。

本文建议把批准设计成一个“批准包”，而不是一个孤立按钮。进入执行队列前，系统至少应把以下内容用普通人能读懂的方式摆出来：这一步将做什么；最终的参数、正文或差异是什么；它将以哪个身份和哪些权限执行；会影响哪些对象、多少金额或多少记录；哪些数据会离开当前系统并到达何处；若行动可撤销，窗口有多长；如果不执行，是否存在更保守的替代方案。对于批量操作，还应明确总量、抽样结果和异常项，而不是只显示“共处理 500 条”。

看似繁琐，其实是在测试系统是否真的知道自己要做什么。假如一个代理无法说明“将向哪三位联系人发送哪一版文本”“会用哪个账户扣除多少金额”“要把哪几项字段改成什么”，它就还不具备让人做有意义批准的条件。此时让人点击确认，不是人类监督，而是把不可见的复杂性转移给一个没有足够信息的人。

适合进入批准队列的动作，有一个共同特征：其后果能在发生前被具体呈现，范围也能被限制。对外邮件是常见例子。AI 可以根据已批准的事实起草回复、列出收件人、标注附件和引用来源；负责人看到最终版本后，再决定是否以组织名义发送。内容发布、低额度付款申请、非关键记录修改也可以采用同样模式。关键不是操作类别，而是批准者能否在执行前理解结果，并有现实的机会修改、拒绝或要求补充信息。

这要求把一个大任务拆成不同动作。以采购为例，AI 可以收集报价、整理需求、检查预算规则、生成订单草稿；它也可以在规则明确时提醒谁还没有批准。但“选择供应商”“改写价格”“同意付款条件”“代表组织发出承诺”不能被藏在“帮我下单”这句话里。前半段可以自动准备，后半段应根据金额、合同条款、关系影响和授权规则设置真正的闸门。

批准的频率也应服务于判断，而不是服务于免责。对高频、低影响、可复核的动作，逐条确认可能会诱发自动点击。更合适的做法可能是金额上限、速率限制、双人复核、先小范围试运行，或者对批量动作做有明确规则的抽样检查。反过来，对一次性但影响重大的动作，即使它很少发生，也不应因为“平时很准”而省略关键确认。系统准确率是背景信息，不是把承诺外包出去的授权书。

还要承认批准的边界。一个负责人无法仅凭页面上的摘要判断医疗建议是否适当，也无法在不了解合同风险时替法律或采购角色做专业判断。批准者必须既有权限，也有足够的事实和能力来承担所批准的内容；否则，正确的动作不是再加一个确认框，而是把事情交给合适的人，或把 AI 的角色退回到准备与解释。

4. 有些决定必须保留人的责任与可申诉空间

“不应委派”并不意味着 AI 在这些领域毫无用处。它可以整理长文件、提取已定义字段、标记材料缺失处、把规则和案例摆在一起、生成可供比较的方案。真正不能被悄悄交出去的，是最终让某个人失去机会、得到权限、承担义务或被贴上某种结论的决定权。因为在这些时刻，需要的不是一个看起来合理的输出，而是一个能够说明理由、被追问、被纠正并承担后果的主体。

NIST 对人机关系的表述比“任何 AI 都必须人工复核”更准确：人机配置可以从全自动到全人工，有些系统需要监督，有些不需要；但在 AI 参与决策和监督的场景里，人的角色和职责应被清楚定义和区分。^[6] NIST 的 AI RMF 还把让用户和受影响群体报告问题、对系统结果提出申诉的反馈机制列入应建立和评估的内容。^[4] 这并不自动得出一张放之四海而皆准的“禁止自动化清单”，但它给出了责任设计的底线：当结果会被合理质疑时，必须知道谁作了决定、依据是什么、如何要求重新审视。

本文建议把下面四类动作视为责任红线。它们不是法律意见，也不声称在每个司法辖区、每种场景下都绝对不能使用自动化；它们的意思是，AI 可以协助，但最终控制和可追责的决定必须由一个被明确指定的人保留。

第一类，是具有约束力的法律、财务、雇佣、医疗或对外承诺。签订或解除合同、同意付款条件、作出雇佣或解约决定、代表个人表达医疗或法律立场，都会把人或组织带入一段难以靠“撤销操作”消除的关系。AI 可以归纳条款差异、检查已有审批是否齐全、起草沟通材料，但不应独自让承诺生效。这里的重点不是模型是否足够聪明，而是出现争议时，谁能解释为什么做出这个承诺，并承担纠正、赔偿、沟通或复议的责任。

第二类，是授予、扩大或撤销访问权。给新员工开通生产系统、把外部协作方加入共享空间、为某账户提升管理员权限、冻结一名用户的访问资格，都会改变别人能看到什么、能做什么，以及能否继续工作。访问控制往往也是其他风险的起点：一次错误授予可能让后续的数据读取、删除或外发都变得可能；一次错误撤销可能使某人无法完成应急工作。AI 可以收集申请材料、对照预先定义的角色矩阵、指出冲突和缺失，但高权限或例外访问的最终授予、扩大和撤销应由有授权责任的人作出。

第三类，是向新的接收方披露身份资料、私密通信、客户资料或商业机密。这里要特别防止一个错觉：系统只是在“帮忙转发”或“找人协作”，所以不算实质决定。事实上，选择收件人、选择外部服务、选择是否附上原始附件，本身就是披露决定。即使内容没有被篡改，披露范围一旦扩大，伤害也可能无法完全回收。AI 可以在已获授权的范围内进行脱敏、分类和准备，并提醒资料等级；是否把具体内容交给新对象，应由理解目的、授权和后果的人决定。

第四类，是会改变他人机会、权利、待遇或声誉的争议性实质判断。招聘筛选、绩效处理、保险或信贷相关建议、客户投诉处置、内容处罚、学业资格判断，都可能包含不完整事实、不同解释和受影响者有理由提出异议的部分。AI 可以提取简历里的明确字段，提示材料缺失，或按公开规则整理候选信息；但若没有能被审查的依据、明确的责任人和可进入的复议路径，就不应让它自行作出淘汰、拒绝、降级或定性结论。

有人会说，人类也会偏见、疲劳、随意判断，保留一个人并不能自动带来公平或准确。这是对的。人类复核不是一种魔法，甚至可能在时间压力下变成对机器建议的机械盖章。本文强调人类责任，并不是因为“人永远更对”，而是因为某些后果需要一个能够理解证据、说明理由、接受质疑、改变决定并承担责任的角色。设计目标不是把所有错误转嫁给一个签字人，而是让系统的判断、证据、权限和救济路径都能被看见和修正。

这也要求把“最终决定由人作出”说得更具体。谁是决定者，谁只是提供意见，谁有权推翻建议，谁接收申诉，处理时限是什么，异常案例去哪里，应该在系统上线前写明，而不是等到有人受影响才临时寻找负责人。涉及受监管行业、劳动关系、医疗或其他专业领域时，还必须遵循适用的法律和专业流程；本文不能代替这些要求。

5. 能撤销的授权、可追踪的行动和可演练的恢复才构成自治条件

即使一个动作已经被判定为可以委派，接入权限也不意味着可以放手运行。真正的自治不是“它能调用工具”，而是“它在有限能力内调用工具，出现意外时仍有人能还原、暂停和接管”。如果团队回答不了三个基础问题：它以哪个身份做了什么，它现在还能做什么，它出错后谁能怎样停下，那么这项自动化还没有达到可以交办的运行条件。

授权设计提供了很具体的材料。OAuth 2.0 将访问令牌描述为经资源所有者批准、带有特定范围、期限和访问属性的凭证；范围用于约束访问请求。^[7] RFC 8707 进一步说明，资源指示符可以让授权服务器把令牌限制在特定资源受众上，越具体的资源 URI 越有助于减少令牌在其他资源上被滥用的机会。^[8] MCP 2025-06-18 版授权规范同样要求服务器验证令牌是否是为自己签发，禁止接受或转运其他令牌，并指出令牌失窃会让攻击者以看似合法的请求访问受保护资源，短期令牌能缩短暴露窗口。^[9]

这些规范说明权限可以被设计得更窄、更短、更贴近具体资源，并不说明任何使用 OAuth 或 MCP 的产品默认安全。一个产品可能把所有权限打包进长期令牌，也可能没有正确验证受众；一个代理即使使用了细粒度令牌，仍可能在被错误输入诱导时做出不恰当但“权限允许”的动作。协议能力不是责任设计的替代品，但它让责任设计有了可实现的抓手。

本文建议，把可自动执行的最低运行条件写成一组可检查的工程条件。第一，使用独立、最小权限、会过期的身份。不要让代理共享管理员账户，也不要为了少一次授权把它接到全公司的主令牌。读工单的身份不应顺便能删文件；能在一个项目创建草稿的身份，不应自动能在所有项目发布。身份应能被单独撤销，过期后需要重新评估，而不是默默永久存在。

第二，工具要窄。比起一个“帮我做任何事”的万能连接器，更可靠的是一组动作明确的工具：读取指定队列、创建草稿、提交等待审批的申请、在限定目录内添加标签。开放式 shell、任意 URL 请求、可跨系统自由组合的高权限连接器，会把原本的一个任务扩大成难以穷举的行动空间。OWASP 对 excessive agency 的缓解建议也包括最小权限、细粒度功能以及日志和监测。^[5]

第三，每一次行动都要能被人读懂地追踪。日志不该只是一串机器错误码，而应至少能关联到触发输入、所用身份、调用的工具、目标对象、最终参数、执行时间和结果。给每个行动一个唯一关联 ID，能让人把“这封邮件为什么发出”“这条记录为什么被改”“这笔请求由谁批准”串回同一条路径。对于敏感写入，预览和延时队列比即时执行更重要：它们为发现错误、撤销任务和等待人工判断留下真实的时间窗口。

第四，恢复不能只存在于产品宣传或事故发生后的愿望清单里。要在投入日常使用前验证：能否撤销当前授权；能否冻结代理的身份；能否停止正在排队的动作；已写入的记录能否按什么边界回滚；不可回滚的外发动作发生后，由谁接管通知、纠正和补救。一次演练会暴露很多平时看不见的问题，比如日志找不到具体对象、回滚会覆盖后续人工修改、暂停开关只能阻止新任务却阻止不了已发出的队列。不能演练的恢复，不应被当作可靠的恢复。

第五，定期从失败中收回或降低自治。每周或每月复盘的重点不该只是“把提示词再写长一点”，而应包括：系统在哪些输入上误解意图，哪些动作被人拒绝，哪些告警来得太晚，哪些权限根本不必存在，哪些异常应该把流程从自动执行退回到只读建议。成熟的系统会把失败当成调整权限、工具和停止条件的证据，而不是把每次事故都解释成偶发的模型波动。

现实中并非每个外部服务都支持细粒度权限、可撤销操作、完整日志或事务性回滚。这个缺口无法靠更强提示词弥补。若服务只能提供全局管理员权限，若外发内容无法撤回，若操作没有可查的记录，保守的答案往往是只允许只读协助、改为人工批准，或者干脆不把该系统接给代理。日志能帮助追责，却不能把已经泄露的信息装回去；撤销令牌能阻止下一次访问，却不能取消已经做出的对外承诺。

最后，边界不应被理解成一张永久不变的“AI 能做”和“AI 不能做”清单。新的工具、新的权限、新的输入来源，都会改变行动链和可承受的后果。每次接入前，先写清它将用哪个身份、能造成什么外部变化、批准发生在哪一步、错误由谁发现、如何停止、如何恢复。让 AI 做得更多之前，先确保人能看见这些行动、暂停这些行动，并为这些行动承担责任。那才是可以逐步扩大委派范围的起点。