AI Agent 接手正式工作后，人和组织怎样重新分工？
定义什么叫一段可交付、可验收的正式工作，再通过渐进授权扩大 Agent 的责任，并把人的能力迁移到客户、产品、创新和增长。
讨论 AI Agent 时，最容易陷入两个极端：一种只谈“能省多少人”，另一种只说“AI 永远只是辅助”。这两种说法都跳过了真正需要设计的部分——一段工作怎样被定义、移交、验收，并逐步扩大 Agent 的责任。
重复、规则明确的任务通常是当前最容易进入生产的起点，但不是长期终点。随着知识、工具、权限和治理成熟，Agent 可以从完成一个动作，逐步走到独立完成一段边界清楚的正式工作。企业真正要验证的，不只是省了多少时间，而是响应速度、交付质量、服务容量和客户体验有没有变成竞争优势。
什么才算一段“正式工作”
这里的正式工作不是岗位名称，也不是一句“让 Agent 自己做”。它至少需要同时具备五项定义：
- 触发与输入明确： 什么事件启动工作，最少需要哪些信息。
- 输出可以验收： 交付物是什么，怎样判断完成或不合格。
- 质量与时效有标准： 不只看模型输出，还看端到端周期、错误等级和服务承诺。
- 权限与责任清楚： Agent 可以读取、判断和执行到哪一步，谁对业务结果负责。
- 异常可以接管： 超出边界时能暂停、留痕、交接和恢复，而不是静默失败。
缺少这些条件，Agent 仍然只是一个功能；具备这些条件，才有可能对一段工作结果承担可验证的责任。
AI Agent 的责任归属：执行可以交给系统，问责不能消失
“Agent 对结果负责”不等于企业可以取消人类责任主体。更准确的设计，是把执行责任和最终问责拆开：
| 角色 | 主要责任 | 不能外包给 Agent 的决定 |
|---|---|---|
| 业务 owner | 定义业务目标和结果取舍 | 是否接受风险、是否扩大投入 |
| 流程 owner | 维护流程、规则和例外 | 哪条规则生效、何时调整边界 |
| 系统 owner | 管理权限、可靠性和审计 | 谁能访问、写回或触发外部动作 |
| 异常 owner | 接收边界外任务并推动恢复 | 冲突、重大错误和不可逆动作怎样处理 |
Agent 可以在这些角色设定的范围内承担任务执行、证据记录和正常情况交付。出现规则冲突、低置信度、高风险或不可逆动作时，责任必须回到已经指定的人类 owner。这样做不是削弱自动化，而是让责任边界可以随着证据逐步扩大。
用 RACI 把“谁负责”写成可以执行的决定
四类 owner 不是四个人平均负责所有事情。对每一种关键决定，只保留一个最终拍板者（A）；其他角色分别承担执行（R）、协商（C）或知会（I）。下面是一张可直接改写的起始表：
| 决定或动作 | 业务 owner | 流程 owner | 系统 owner | 异常 owner | Agent |
|---|---|---|---|---|---|
| 定义业务结果与验收门槛 | A | R | C | C | I |
| 发布规则版本与处理例外 | C | A/R | C | C | I |
| 授予、扩大或收回权限 | C | C | A/R | I | I |
| 执行正常、边界内任务 | I | A | C | I | R |
| 处理越界任务并恢复流程 | I | C | C | A/R | I |
| 决定试点是否扩大 | A | R | C | C | I |
这里的 A 是最终问责，R 是实际执行。一个人可以兼任多个角色，但同一项决定不应该同时出现两个 A。如果业务 owner 要求提速、系统 owner 判断权限越界，Agent 不应自己选择支持哪一方。
Owner 发生冲突时怎样处理
先在上线前写好优先级，而不是等事故发生再讨论：
- 法律、安全和不可逆风险高于速度或产量目标；
- 已批准的权限边界高于临时业务指令；
- 当前有效的规则版本高于聊天中的口头要求；
- 无法确定版本、权限或最终拍板者时，停止执行并交给异常 owner；
- 人工决定必须带理由回写，决定是否更新规则、权限或只是处理一次例外。
这种冲突处理顺序让 Agent 的停止行为可以预测，也避免“人说了算”变成任何人临时发一句话都能越过控制。
如果当前问题不是理解责任结构，而是要真正确定由谁担任流程 owner，可以继续使用为 AI Agent 指定 human owner 的七步方法与 RACI 模板。
从助手到正式工作：五级成熟度
| 级别 | Agent 承担什么 | 人承担什么 | 升级条件 |
|---|---|---|---|
| L0 助手 | 检索、摘要、建议 | 完成全部动作并承担结果 | 输出可用但尚无执行权限 |
| L1 任务执行者 | 完成一个边界明确的动作 | 逐项检查并写回 | 同类任务有稳定验收数据 |
| L2 工作流执行者 | 串联多个任务 | 关键节点批准、处理异常 | 状态、重试和交接可追踪 |
| L3 工作单元负责人 | 独立完成正常任务并满足 SLA | 管理例外、规则与质量 | 结果不低于人工基线，严重风险受控 |
| L4 流程协作者 | 与其他 Agent/员工完成端到端流程 | 负责目标、治理和经营结果 | 客户与业务指标持续改善 |
成熟度不是按模型版本升级，而是按证据、权限和业务责任升级。首月最可信的目标不是“替代一个岗位”，而是让 Agent 从 L0/L1 走向一段有边界的 L2 或 L3 工作。
任务仍然要拆，但它只是第一步
我会先把任务按两个维度拆开：重复程度和判断密度。
| 任务类型 | Agent 的角色 | 人的角色 | 常见例子 |
|---|---|---|---|
| 高频重复、低判断 | 在权限范围内自动执行 | 设定规则、抽查结果 | 字段整理、固定检查、状态同步 |
| 高频重复、中高判断 | 准备上下文和候选结果 | 做最终判断并承担责任 | 异常分流、规则冲突、方案比较 |
| 低频、高关系密度 | 提供资料和提醒 | 主导沟通与关系维护 | 关键客户沟通、跨团队协商 |
| 高风险、不可逆 | 只读、模拟或生成草稿 | 审批、执行和复盘 | 外部承诺、付款、合同动作 |
这个分类避免了两个误区：既不把完整岗位当成第一阶段目标，也不把 Agent 永远锁在低价值动作上。更稳妥的路径是先稳定接手一组可验收动作，再逐步扩大到工作单元和端到端流程。
工作移交与组织重分配的五步
1. 写出任务，而不是岗位名称
不要只写“客服”“商务”或“运营”。需要继续拆成每天真正发生的动作：接收消息、提取字段、查找规则、追问信息、生成草稿、确认例外、维护客户关系。
2. 建立人工基线
至少记录任务频次、人工分钟、等待时间、返工原因和错误影响。没有基线，无法判断 Agent 是减少了工作，还是把工作变成了更多复核和救火。
3. 同时写 Agent 动作和人工动作
每项任务都应回答：Agent 做到哪里停下？人为什么必须介入？介入时收到什么上下文？处理后怎样回到流程？
4. 逐步扩大 Agent 的责任
权限从只读、生成草稿、批准后执行，到低风险自动执行和正常任务独立完成。每次升级都要绑定任务成功率、严重错误、可撤销性、接管质量和客户影响，而不是因为模型宣传变强就直接放权。
5. 指定人力能力的下一用途
不要只写“节省 2 小时”。要写清这 2 小时准备投入哪项具体工作，例如：
- 深入客户关系，识别尚未被满足的需求；
- 改进产品、服务方案与业务规则；
- 做复杂判断、跨团队协同和风险决策；
- 进入获客、转化、留存、创新等增长事项。
如果岗位目标、能力和激励没有同步变化，自动化很可能只让团队以更高速度接收更多低价值任务，释放出来的时间也不会自动变成利润。
一个合成示例：询价入口的人机分工
下面是为了说明方法编写的合成示例，不对应真实公司、客户或交易。
原流程里，员工需要从消息中复制字段、检查缺失信息、寻找规则、整理待确认材料，再决定是否需要进一步沟通。Agent 上岗后，可以先接手留痕、字段抽取、完整性检查、规则检索和固定格式回写。
人不再反复搬运信息，而是集中处理三类工作：判断规则冲突、理解客户的非标准要求、决定新例外是否要更新到 SOP。随着 Agent 在已定义范围内表现稳定，它可以继续接手追问、匹配、回写和状态跟进；人的目标则转向客户成功、服务设计和新增业务机会。这里的价值不是只把人从一个动作里移开，而是重新设计企业的服务能力。
怎样确认企业能力真的升级
建议沿着四层证据链记录：
- 工作接手： 独立完成率、人工批准率、成功写回率、异常接管率。
- 流程结果： 端到端周期、P50/P95 响应、一次通过、返工和严重错误。
- 客户结果： 等待时间、重复联系、解决率、满意度、转化或留存。
- 经营结果： 可承接需求量、有效机会、收入、毛利和人均产出。
成本和人工分钟仍然要记录，但它们是约束和结果之一。只有工作边界扩大、客户指标改善，并在足够长的窗口里进入经营结果，才能说技术真正变成了企业竞争力。
下载 AI Agent 正式工作与组织重分配矩阵（CSV）。
证据与适用边界
- 当前状态：工作方法与匿名小范围实验框架，不是行业标准。
- 样本来源：真实工作观察经过匿名抽象；本文例子为合成示例。
- 已验证：任务可以按重复程度、判断密度和风险重新分配；正式工作可以用结果、权限、责任和接管机制定义。
- 正在验证：Agent 的责任边界能否持续扩大，流程改善能否进入客户和经营结果。
- 不适用：高风险、不可逆、强关系或责任主体不清的任务，不应直接自动执行。