当 AI 开始替你工作，改变的是判断、权限与责任边界

1. 任务自动化和工作流委托不是一回事

让模型把一篇会议记录整理成三条要点，是任务自动化。它的输入和输出相对清楚：给它文字，拿到文字。即使结果需要修改，错误通常停留在文档里。把会议记录交给一个能够读取日历、查找项目文档、判断哪些事项需要跟进、创建任务并通知责任人的系统，就变成了工作流委托。系统需要记住上下文，选择工具，遇到缺失信息时决定是追问、跳过还是升级，还要对外产生影响。

Anthropic 在讨论 agentic systems 时，刻意区分了两种架构：workflows 是由预先写好的代码路径编排模型和工具，agents 则由模型动态决定过程和工具使用。^[3] 这个区分很实用，因为“代理”这个词经常把不同程度的自动化混在一起。一个固定顺序的“提取—校验—写入”程序，和一个可以自行选择搜索范围、调用接口、重试并改写计划的系统，虽然都能调用工具，风险结构却完全不同。

区别不在界面上有没有一个聊天框，而在工作对象有没有从“一个动作”变成“一个带状态的过程”。流程委托至少包含三种变化。

第一，系统要处理状态。客服助手要知道订单是否已经退款、客户是否在过去三十天内用过一次例外政策，否则它可能把同一笔钱退两次。第二，系统要处理分支。库存不足时，补货、换货和退款的路径不一样；模型需要把事实和政策对应起来，而不是只生成一段听起来合理的说明。第三，系统要产生副作用。写回 CRM、发送邮件、关闭工单、更新权限，都是可被别人依赖的动作。文字写错可以重写，付款写错却要追索。

这也是为什么局部速度很容易制造错觉。Copilot 实验的参与者完成了一个界定清楚的编程任务，研究摘要报告处理组比对照组快 55.8%；它能说明在那个任务和工具版本下，代码产出加速了，不能说明测试、审查、上线和维护也按同样比例加速。^[2] NBER 的客服研究同样是在一个既有业务系统里观察到生产率变化，而不是把一个代理放进完全开放的组织环境。^[1]

长流程的问题还会放大每个小错误。METR 在长软件任务评测中，以人类完成任务所需时长预测模型成功率，并观察到模型在较长任务上的成功率更低。^[4] 这项结果没有直接解释失败机制，但对组织有一个工程上的提醒：流程变长后，团队不能用单步演示替代端到端验证。一个流程有八个步骤，每一步看起来都“差不多能做”，并不等于最后能可靠交付。模型多走一次搜索、误读一个字段、把旧政策当成新政策，都会把后续步骤带偏。人类员工也会犯错，但组织通常知道谁做的、依据什么做的；代理如果没有记录，错误会像一串没有署名的点击一样难以复盘。

所以，第一步应画出真实工作流：输入来自哪里，哪些动作改变外部状态，哪一个判断不可逆，异常时要找谁。流程固定、错误可逆、数据敏感度低的地方，普通自动化或模板化工作流就够了。只有在规则难以穷举、需要动态取证的环节，才适合考虑让模型参与规划。把任务自动化误称为流程委托，会让组织在没有准备证据链之前先放大权限。

2. 当 AI 接手执行，判断的位置必须被主动设计

过去使用助手，人的主要动作是提出问题、阅读答案、决定要不要采纳。流程代理改变了这个顺序：它可能先判断哪一封邮件优先、哪条政策适用、哪个客户需要升级，再把一个已经经过若干步骤的结论递给人。人如果只在最后点击“批准”，就很难知道此前有哪些选项已被过滤，哪些判断已由系统作出。

这并不意味着人的判断会自然上移，也不意味着判断一定会消失。更准确的说法是：AI 接手更多执行步骤之后，组织必须决定判断留在哪里。本文建议至少把三类判断明确写进流程：由人定义目标，由人设定委托边界，由明确的责任人处理例外。目标不只是“把工单关掉”，还包括保持客户信任、遵守合同和保留可解释的证据。边界不只是字数和格式，而是哪些数据可以读取、哪些动作可以自动执行、什么情况下必须让客户知道使用了 AI。例外则是政策没有写全的地方：客户提供了新证据、订单涉及未成年人、系统发现账户可能被盗，任何一个条件都可能让“最常见的路径”变成错误的路径。

ILO 对生成式 AI 职业影响的研究预测，这类技术的主要影响更可能是增强职业，而不是自动化整个职业。^[5] 这个结论为讨论划出了一条边界：岗位并不因为某几项动作加速就必然整体消失。但这份摘要没有证明实际组织里的判断权会向上移动，也没有替任何团队决定哪些动作应由人批准。一个岗位可以保留原来的名称，内部的决定权却可能因界面、默认值和权限设置而改变；这是组织需要检查的设计问题，不是 ILO 研究已经观察到的普遍结果。

设想一个使用模型整理简历的招聘流程。模型可以从简历中提取技能、按岗位要求整理候选人，甚至草拟面试邀请。招聘团队仍要决定岗位要求是否公平，哪些信息不应进入排序，候选人如何申诉，模型的推荐是否复制了过去的偏见。如果人只检查排名最前的三个人，审核就可能从独立判断缩成盖章。相反，团队可以规定“模型只做信息整理，不得决定淘汰；每次淘汰必须有可读理由；出现缺失资料时不得用猜测补齐”。这不是任何原则文件已经验证的最佳流程，而是把“人保留什么判断”落实成可检查规则的一种做法。

OECD AI Principles 把以人为本与公平、透明与可解释、稳健安全以及问责放在同一组原则中，并提出对 AI 系统进行持续风险管理的方向。^[6] 这些是规范性原则，不是判断权如何变化的现场研究。它们落到日常工作里，可以转化为几个治理问题：当模型的建议改变了客户待遇，负责人能否说明建议依据了什么；当系统资料过期，谁会发现；当员工不同意模型排序，是否有不依赖模型的复核渠道。具体答案仍需要组织自己作出。

如果组织不主动设计，判断还可能被界面和默认项隐性下放给系统。界面把“接受”放在最醒目的位置，把“查看原始证据”藏在第二层，最后的点击即使由人完成，也不等于人完整检查了前面的推理。自动填入的理由、默认勾选的动作、只展示一个候选方案，都会缩窄审核者实际看到的选择。形式上的最终批准权仍在人手里，实质上的取舍却可能已经发生在模型输出和产品设计中。

NBER 的结果显示，AI 对新手和低技能员工的平均帮助更大，对资深和高技能员工的影响很小。^[1] 这项研究说明特定客服环境中的收益存在异质性，也提出优秀员工的做法可能被传播给新手；它没有直接测量新手是否把建议当成判断，更没有证明组织中的决定权移到了哪里。本文据此提出的是一个需要核查的问题：员工是否能够查看依据、提出反例并拒绝建议，而不是只比较点击批准的速度。

一种可供组织检验的分工，是把“模型可以提出什么”和“模型可以决定什么”分开。模型可以提出候选人排序，但不能独自决定淘汰；可以根据已批准的退款规则生成建议，但不能在金额超过阈值时自动付款；可以把故障日志归类，但不能未经确认修改生产配置。人需要练习的也不只是提示词，而是如何确认前提、寻找缺失证据和解释取舍。这样的安排不会由部署模型自动出现，必须通过政策、权限和界面刻意建立。

3. 行动权限和证据链决定风险的形状

让 AI 从“建议”跨到“执行”，技术上可能只需要多一个 API 权限。治理上却是一次质变。读取公开知识库和读取客户的健康记录不是同一种动作；草拟一封邮件和代替公司发送邮件也不是同一种动作。权限一旦开通，模型的错误就不再只是内容错误，而会变成数据泄露、合同承诺、错误付款或无法撤销的记录。

因此，代理的工具清单必须和责任清单一起写。每个动作至少要回答五个问题：它读取什么数据，写入什么系统，代表谁作出改变，改变能否撤销，事后留下什么证据。把所有工具放在同一个“管理员”账户下最省事；如果同时缺少独立调用标识和应用层日志，共用高权限账户会让审计很难区分是模型、员工还是脚本做了这件事。更合理的做法是最小权限：代理只看到完成当前步骤所需的字段，只能调用限定的接口，只能在低风险条件下执行，超过阈值就交给明确的责任人。

欧盟《人工智能法案》把这些问题写进了高风险系统的制度要求。Article 12 要求记录日志，Article 13 要求向部署者提供足够透明的信息，Article 14 规定人类监督，Article 26 规定部署者在使用和监控方面的义务。^[7] 这些条款并不意味着每个内部聊天机器人都自动属于高风险系统，但它们清楚地指出：一个能够影响人的系统，不能只交付一个模型文件，还要交付日志、说明、监督和使用责任。

假设一个财务代理负责处理供应商发票。它可以从邮件中提取金额，与采购订单比对，把低于一千元且完全匹配的发票放进待付款队列；金额不匹配、账户第一次出现或合同条款缺失时，只能创建待办，不得付款。每次执行都要保存原始附件的哈希、使用的政策版本、模型输出、调用的接口、批准人的身份和最终结果。月底发现异常时，财务人员不必猜“模型当时为什么这么做”，而可以沿着证据链回到具体字段。

NIST 的 AI RMF 1.0 将风险工作组织为 Govern、Map、Measure、Manage，并明确框架用于帮助组织在设计、开发、使用和评估 AI 系统时纳入可信性考量。^[8] 把这四个词翻译成工作语言，就是先规定谁负责，再弄清系统处在哪个业务环境，测量实际表现和偏差，最后根据结果调整或停止。它的价值不在于提供一个万能表格，而在于提醒团队：风险不是上线前的一次评审，而是随着数据、模型和流程变化的持续活动。

英国政府的 AI 监管白皮书提出五项跨部门原则：安全、安保与稳健性，适当的透明与可解释，公平，问责与治理，以及可质疑与补救，并强调由现有监管机构结合具体场景落实。^[9] 这种做法对组织也有启发：不要给 AI 设一套与采购、信息安全、客服投诉完全割裂的新流程。代理的权限、日志和停用条件，应当嵌入原有的审批、审计和事故响应体系。

当然，所有动作都要求人工点一次确认也不是答案。低风险、可逆的格式转换如果每一步都弹窗，员工会很快形成“无脑同意”的习惯，或者转向没人看得见的个人工具。权限应该按影响、可逆性、数据敏感度和外部承诺分级。一个公开网页的摘要可以自动发布草稿；一封涉及赔偿的邮件需要人审；改变生产数据、付款或法律立场则需要更高等级的批准和双人复核。目标是让高影响动作不会在没有证据和责任人的情况下发生。

4. 技能形成是待监测的风险，责任归属是组织选择

当重复动作被交给 AI，组织需要监测一种风险情景：如果初级客服不再处理简单工单，初级工程师不再亲手修小缺陷，运营新人只看到系统筛选后的邮件，他们形成独立判断所需的练习机会可能减少。这里的“可能”不能省略。现有 NBER 客服研究和 Copilot 实验都没有直接测量多年后的技能形成，也没有证明长期去技能化已经发生。本文把它列为风险，是因为委托会改变新人接触完整流程的机会；是否真的变慢，要由组织用后续数据验证。

NBER 的客服研究发现，工具对新手和低技能员工的帮助明显高于资深员工，并提出 AI 可能传播更有经验员工的做法、帮助新人沿着经验曲线前进。^[1] 这是一个积极结果，也提醒我们不要预设 AI 一定削弱技能。但这项研究没有回答两个长期问题：新人是否理解了建议背后的条件，以及在没有工具或遇到新例外时能否独立判断。组织不能从短期产出改善直接推导出能力已经形成，也不能反过来把技能衰退当成既成事实。

Copilot 的实验同样只划定了局部边界。研究者让开发者尽快实现一个 JavaScript HTTP server，处理组比对照组快 55.8%。^[2] 它没有覆盖需求澄清、架构取舍、代码审查、上线监控和事故修复，也没有追踪参与者日后的学习速度。因此，这个实验既不能证明整个软件工程流程会按同样幅度加速，也不能证明使用者会失去调试或设计能力。它真正留下的问题是：当局部产出变快时，团队是否仍在观察验证能力和处理异常的能力。

责任归属是组织必须作出的选择。一份报告可能由模型检索资料、由运营选择提示、由工程团队配置权限、由经理点击发布；这条链路不会自动生成唯一负责人。组织可以选择在流程开始时指定结果负责人，并授予他查看证据、暂停系统和恢复人工流程的权力；也可以为不同影响等级设置不同的批准者。无论采用哪种方式，都应把选择写进流程，而不是在出错后让参与者互相指向“系统建议”。这是本文的治理主张，不是前述生产率实验直接得出的结论。

这也不支持“AI 会替代所有人”的结论。ILO 的研究预测，生成式 AI 的主要影响更可能是增强职业，而不是自动化整个职业。^[5] 一位产品经理可能少写几页需求，却要花更多时间验证用户反馈是否被模型误读；一位律师可能少做检索，却要更仔细地确认引用、利益冲突和客户授权。这些是用于说明“岗位保留不等于工作内容不变”的情景，不是 ILO 摘要逐项验证的职业预测。具体岗位会如何变化，仍取决于任务、工具和组织安排。

技能监测还要考虑模型和成本会变化。Stanford HAI 的 2025 AI Index 将模型能力、推理成本、责任实践和劳动力趋势放在同一份年度综述中。^[10] 这类年度变化说明，一次基准成绩不能当成永久能力证明。模型更新、工具接口变化、数据分布变化，都可能改变原先的检查点。组织如果只记录“代理现在比人快”，没有记录“代理在哪些输入上会失灵”，以后就很难判断应该保留哪些人工能力。

如果团队要验证练习机会是否真的减少，可以把它当成与速度并列的试点指标：新人能否在没有模型建议时处理一小批案例，员工发现错误需要多久，异常升级是否找到了合适的人，复核者是否能说清原始证据。无 AI 演练、完整流程轮换和反向复盘，都是本文建议的监测办法，不是唯一方案，也没有被上述研究共同验证。它们的价值在于把“我们担心员工能力变薄”改写成可观察的问题。结果也可能证明另一种情况：AI 减少机械劳动后，新人反而更早接触复杂问题。组织需要让数据回答，而不是先把乐观或悲观的叙事当成结论。

5. 本文的五步方案：从一张责任表开始

下面的五步框架，是本文根据前述实证边界、法规例子和治理原则提出的编辑性组织设计方案。它不是唯一方法，也不是 NBER、ILO、NIST、OECD 或其他来源共同实证验证的“最佳实践”。不同规模、行业和风险环境需要调整步骤、阈值与责任人。为了把方法写具体，本文用一个三十天、低风险、可逆、边界清楚的试点作为示例；三十天只是便于执行的周期，不是经过研究证明的统一期限。试点可以选择内部知识库的工单分类或已批准模板的邮件草拟，先验证结果、异常、证据、学习和停用机制，再决定是否扩大权限。

第一步应定义结果，再选择模型。把“处理得快”改写成可以核对的目标：字段正确率达到多少，客户等待时间不能增加，所有外部发送都保留批准记录，任何敏感数据不能流出指定系统。没有结果定义，团队容易把演示时的顺滑误认为上线后的成功，也无法判断什么时候应暂停。

第二步是把流程拆成动作，并给动作分级。可以把动作分成四层：只读和整理，生成供人修改的草稿，执行可撤销的内部变更，执行不可逆或对外承诺的动作。每一层对应不同的数据范围、工具权限和人工检查。分类错误可以自动回退；删除记录、付款、发送法律承诺则必须升级。分级是为了让“自动化到哪里”为人所知。

第三步是建立权限和证据表。表格至少有动作、输入数据、调用工具、允许账户、批准人、日志字段、回滚方式和保留期限。代理用服务账户运行，不借用某位员工的超级权限。模型每次作出的关键判断都要能指向原始资料、政策版本和时间戳；没有来源的猜测不能直接变成外部事实。若供应商更换模型或默认设置，变更也应触发一次重新评估。

第四步是把人放在真正有意义的检查点。检查应回答具体问题：依据的事实是否仍然有效，是否遗漏了反例，动作是否在授权范围内，客户是否需要被告知。界面应让审核者看到原始证据、模型的工具调用和可撤销选项，而不是只有一个巨大的“接受”按钮。对低风险动作可以抽样复核，对高影响动作要逐项复核；抽样比例应根据历史错误和用户影响调整。

第五步是用事故和学习指标复盘。速度、节省工时可以记录，但还要记录返工率、错误被发现的时间、异常升级是否找到了合适的人、用户申诉、权限拒绝、证据缺失和员工独立解决问题的能力。METR 的长软件任务评测显示，模型在较长任务上的成功率更低。^[4] 这项研究没有直接验证本文的五步框架；它在这里提供的只是一个边界提醒：连续工作能否完成和单步演示是否漂亮是两件事。团队可以每周拿几条真实日志做“如果当时没有人拦住它会怎样”的演练，检查自己设定的阈值是否有效。

流程一旦跨过部门，责任表还要写清“交接”而不只是“执行”。市场代理生成活动名单，销售系统发出邀约，财务系统计算优惠，法务规则检查承诺，这四个环节可能由四个团队维护。最后一封邮件出错时，不能只看发送系统，也要知道名单怎样产生、优惠依据哪个版本、哪条规则放行了文本。每个环节都应交付结构化状态和证据，而不是给下一个代理一段含糊的自然语言摘要。上游资料缺失时，下游必须能够拒绝继续执行；责任人也要能看见拒绝发生在哪里。

团队还可以给代理设“失败预算”。这不是容忍高影响错误，而是预先定义在什么范围内可以通过观察继续试验：例如内部分类的误差可由抽样发现并回退，错误发送客户邮件则立即暂停自动发送。失败预算把风险承受度变成可执行阈值，也防止试点在一次小错后被草率取消，或在连续异常后仍因沉没成本继续运行。达到暂停条件时，系统应自动收回写权限、保留现场日志，并把未完成事项交回人工队列。恢复运行需要新的责任人签字，而不是代理自行重试到看似成功。

这套方案也允许组织承认失败。试点发现代理经常把过期政策当成最新版本，就缩小资料范围、增加版本校验或暂时停用；发现员工全部点击批准，就改造界面和培训，而不是把责任推给“人没有认真审核”；发现代理只能在最常见的案例上可靠，就把它定位成分流和草拟工具，不再追求假想的全自动。NIST 的风险框架把治理、映射、测量和管理视为循环，而不是一次上线清单。^[8] 本文借用的是持续治理的方向，具体的五步顺序仍是为这篇文章组织出来的实践建议。

效率仍然重要。更快的响应可以减少等待，更低的重复劳动可以让人把精力用在客户、产品和判断上。但当组织同时交出连续流程和行动权限时，效率应当是受边界约束的结果，而不是放开权限的理由。组织需要知道代理完成了什么、没有完成什么、依据什么完成，以及谁有权在下一次运行前改变规则。

当 AI 开始替你工作，重要的动作是把被委托的工作重新画一遍：哪一步属于执行，哪一步需要人的判断；哪一个权限可以交出，哪一个必须保留；哪一条证据能让责任人解释决定，哪一种失败会触发停用。并非每个组织都会走到这一步，也没有一套框架能够保证相同结果。但只要 AI 被允许连续行动，这些选择就不会因模型更快而自行解决。真正改变工作的，是组织选择把判断放在哪里、把权限交到哪里、让谁承担后果，以及是否继续为人的能力形成留下可见的路径。