第 13 章 人机协同与组织生产方式：从对话辅助到目标受托
前面的章节讨论了如何把 Prompt 沉淀为 Skill、工作流和受控 Agent，也讨论了员工怎样使用 AI、组织怎样治理用例。本章进一步回答一个更长期的问题：当 AI 不再只生成一次回答，而能够在有边界的环境中检索资料、调用工具、执行多步骤任务并依据反馈迭代时，企业的生产方式会怎样变化？
答案不应被简化为“人被替代”或“所有工作都会变成 Agent”。更接近现实的变化是：工作单元、人的职责、组织知识和反馈机制正在被重新组合。 人类仍然定义业务目的、提供不可替代的情境判断、承担授权与责任；AI 则可在明确边界内承担更多信息处理、初步实现、验证、协调和执行工作。企业的关键能力将不再只是采购模型，而是把这种协作设计成可复核、可维护、可暂停的系统。
本章是一张协作形态地图，不是技术发展史、组织重组方案或岗位替代预测。 同一企业、同一部门甚至同一流程中的不同子任务，都可能长期采用不同形态。复杂度只有在带来经验证的业务增益时才值得增加。
一、从“使用工具”到“重新组织工作单元”
早期的生成式 AI 使用，常以一次问答、初稿或资料整理为单位。用户输入问题，模型给出结果，用户自行修改或放弃。Prompt 工程使个人经验开始显性化；Skill 使可重复的程序性知识、示例、脚本和资源得以共享；工作流将稳定的步骤、验证和回退固定下来；受控 Agent 则在目标、权限和停止条件明确时，承担路径无法预先完全写死的多步骤任务。
变化的重点不是把所有工作都交给 AI，而是把“完成一项工作”拆成更清晰的单元：谁定义目标，谁提供上下文，谁执行可验证步骤，谁审核例外，谁记录反馈，谁对结果负责。OpenAI 的公开工程文章将这种转变概括为：随着 Agent 承担更多执行，工程师的高价值工作转向设计环境、表达意图、建立反馈循环和编码质量约束。1 这一观察适用于工程之外的很多场景，但不应被误读为所有岗位都采用同样的节奏或自动化比例。
| 过去常见的工作方式 | 正在出现的协作方式 | 企业需要补齐的能力 |
|---|---|---|
| 个人向工具提问，靠经验判断结果 | 人将任务、边界和验收标准交给可复用的协作单元 | 任务契约、示例、Rubric 与个人自检 |
| 知识分散在聊天记录、邮件和人员记忆中 | 知识被整理为可发现、可定位、可更新的上下文与 Skill | 知识 Owner、来源/版本、渐进披露与变更机制 |
| 专家亲自处理每个实施步骤 | Agent 在批准工具和环境中承担准备、实现、测试或整理 | 工具说明、权限、日志、异常处理与人工接管 |
| 问题通过临时沟通解决 | 失败、评审意见和例外被转化为测试、规则、文档或 Skill 改进 | 反馈闭环、回归评测、复盘与资产维护 |
| 经理管理投入的人数和任务量 | 经理同时管理目标、容量、质量、风险、上下文资产和人机分工 | 阶段闸门、价值证据、RACI 与组合治理 |
因此，企业应把注意力从“谁在使用哪个工具”转向“哪个工作单元已具备可委托、可复核和可恢复的条件”。这也是本手册始终强调用例、证据和运行控制，而不以模型名或调用量作为成果的原因。
二、六种可以并存的人机协作形态
以下六种形态不是线性成熟度等级。企业不必从左到右升级；某些任务应永久停留在对话辅助、共同创作或固定工作流。是否升级，取决于任务结构、风险、数据、验证能力和组织准备度。
| 协作形态 | 主要工作单元 | 人的主要贡献 | 应沉淀的资产 | 适合升级的信号 | 不应升级的信号 |
|---|---|---|---|---|---|
| 对话辅助 | 一次问题、初稿或资料整理 | 提问、核验、修改与采用判断 | Prompt、参考材料、检查清单 | 同类任务反复出现 | 每次任务高度独特，且没有复用价值 |
| 共同创作 | 可迭代的文档、分析或设计 | 设定方向、比较方案、给出反馈 | 示例、Rubric、版本记录 | 反馈模式稳定，质量可讨论 | 事实无法核验，或业务责任不清 |
| 可复用 Skill | 重复出现的子任务 | 提炼程序性知识、维护适用边界 | Skill 卡、指令、脚本、资源与评测 | 可跨人员、跨任务复用 | 规则不稳定、Owner 缺失或数据不具备 |
| 受控工作流 | 预定义的多步骤流程 | 设计输入输出、例外和回退 | 工作流合约、测试、Runbook 与发布记录 | 步骤稳定、验证可程序化 | 异常路径无法说明，或回退不可行 |
| 目标受托 Agent | 开放但有边界的多步骤任务 | 定义目标、授权、验收、升级 | 目标契约、上下文包、状态、工具与证据 | 路径难预先穷尽，但结果可验证 | 权限、停止条件、人工 Owner 或回退不清 |
| Agent 协作网络 | 可并行的高价值探索或生产任务 | 设计分工、努力预算、冲突处理与整合 | 编排规则、上下文隔离/共享、追踪与恢复 | 任务可并行，价值足以覆盖协调成本 | 任务强依赖、低价值，或团队无法观察协调过程 |
Anthropic 对 Agentic 系统的公开说明也区分了预定义代码路径的工作流与由模型动态决定步骤和工具的 Agent，并建议从最简单、可验证的方案开始，只在复杂性确有收益时增加自主性。2 这与第 4 章和第 9 章的原则一致：能力强并不是扩大自主性的充分理由。
三、人的工作从“亲自执行”转向“委托、复核与拥有”
当 AI 能承担更多实现和执行时，人类并没有退出流程，而是更集中地承担三类不可空缺的责任：委托（Delegate）、复核（Review）与拥有（Own）。 OpenAI 在其面向 AI 原生工程团队的公开指南中，使用了类似的划分：Agent 可完成有边界的初步分析、实现、测试或文档；团队复核准确性、完整性和适配性；组织仍拥有优先级、长期取舍和最终发布责任。3
| 责任层 | 人应负责什么 | AI 可在受控范围内承担什么 | 不应混淆的边界 |
|---|---|---|---|
| 委托 | 明确问题、目标、范围、约束、可用资料和验收方式 | 拆解已授权任务、提出计划、准备候选方案 | AI 提出计划不等于已获得执行授权 |
| 复核 | 核验事实、判断例外、评估风险、确认质量与影响 | 执行规则检查、测试、交叉比对、整理证据 | 自动通过不等于业务、法律或安全批准 |
| 拥有 | 决定优先级、资源、权限、对外承诺、停止与恢复 | 提供选项、模拟影响、汇总运行信号 | AI 不能成为业务 Owner、审批人或责任主体 |
这种分工会改变不同角色的日常工作。员工需要更擅长描述问题、识别可用上下文、判断依据和停止条件；专业人员需要将经验转化为可验证的规则、示例和例外路径；管理者需要同时管理业务目标、容量、质量、风险和共享资产；技术团队则需要让知识、工具、日志、测试和环境对 Agent 可理解、可使用且可限制。
这并不意味着每个人都要成为程序员。Anthropic 公开的跨团队使用案例显示，设计、数据、营销、法务和工程团队都可将 Agent 用于理解、原型、测试、文档或自动化；其共同前提是由人定义问题、提供反馈并复核结果。4 对企业而言，真正需要普及的不是某个产品界面，而是目标表达、上下文判断、质量评估、例外升级和反馈沉淀等协作能力。
四、目标契约：让 Agent 为目标工作，而不是自行决定目标
“Agent Goal”容易被误解为让 AI 自主选择组织目标。企业需要的不是目标自治，而是目标契约：由具有业务授权的人，将可委托任务的目标、边界、证据和停止条件明确下来，再允许 Agent 在契约内规划与执行。
目标受托不等于目标自治。 Agent 可以决定下一步如何在授权工具中完成任务；改变业务目标、扩大范围、连接新系统、提高权限、接受不可逆后果或对外作出承诺，必须由有权的人决定。
| 目标契约字段 | 必须回答的问题 | 与既有资产的连接 |
|---|---|---|
| 业务目标与成功证据 | 要改善什么业务结果，怎样证明完成？ | 用例立项卡、价值评估与阶段闸门 |
| 范围与非目标 | 处理哪些对象、时段和问题，明确不处理什么？ | 工作流/Agent 运行合约 |
| 最小必要上下文 | 可以依据哪些来源、版本、范围和实时状态？ | 上下文包、知识责任与动态事实卡 |
| 工具与权限 | 可以读取、查询、修改或发送什么；哪些动作必须批准？ | 工具/MCP/连接器控制卡与最小权限设计 |
| 时间、成本与并发预算 | 最多允许运行多久、调用多少工具、消耗多少资源？ | 运行合约、健康卡与成本记录 |
| 验证与审批点 | 哪些结果可自动检查，哪些必须由人判断或确认？ | Golden Set、Rubric、发布登记与审批矩阵 |
| 停止、升级与回退 | 出现什么信号必须停止、转人工、回退或升级？ | Runbook、人工备用与事件分级 |
| 人工 Owner 与记录 | 谁拥有目标，谁维护上下文/工具，哪些证据需要保留？ | RACI、审计证据索引与移交资产 |
目标契约不是新增的一套繁重表格。低风险的内部试点可以用简短卡片记录；涉及对外沟通、敏感数据、写入操作、权限扩大或高影响决定时，则必须与第 9、14、15 章和附录 A 的运行、风险与安全资产一起使用。
五、公开实践观察窗：可以借鉴的机制，而不是可复制的组织蓝图
前沿 AI 公司公开的工程文章和产品资料，为理解协作方向提供了有价值的观察窗。但这些材料反映的是特定团队、模型、基础设施、人员能力和产品目标下的实践，不能被转写为其他企业的效率承诺或组织模板。
1. 让工作环境对 Agent 可理解
OpenAI 的“Agent-first 工程”公开文章描述了一种做法：使用短而稳定的入口文件引导 Agent，再由版本化、结构化的仓库知识库提供更深层的上下文；通过测试、结构约束、日志、指标和持续清理，让 Agent 能够找到信息、验证结果并将反馈转化为下一轮改进。1
这个案例的可借鉴点不是“让 Agent 写所有代码”，而是将组织知识从分散的聊天、个人记忆和临时文档，转化为可发现、可定位、可更新和可验证的工作资产。 第 5 章的最小上下文包、附录 A 的 Skill 卡和第 12 章的知识 Owner 机制，正是企业版的基础做法。
不可外推之处在于：该公开实践依赖特定仓库、工具链、可观察性和工程团队投入。普通企业不应因看到其吞吐或自主性描述，而跳过自身的上下文治理、测试、权限和发布控制。
2. 将“委托—复核—拥有”嵌入生命周期
OpenAI 的 AI 原生工程团队指南按计划、设计、构建、测试、审查、文档、部署和维护拆解协作，并在每个阶段区分可交给 Agent 的工作、需要团队复核的工作以及人必须拥有的责任。3
这提示企业：人机协同不应只出现在“生成内容”这一个节点，而应设计在完整的业务生命周期中。例如，客服团队可以让 AI 整理证据和起草回复，由员工核验适用规则并批准发送；运营团队可以让 Agent 汇总异常、准备处置选项和运行记录，由 Owner 决定优先级、授权动作并评估后果；工程团队可以让 Coding Agent 准备实现、测试和文档，由工程师拥有架构、迁移和上线责任。
3. 将成功做法封装为可共享的 Skill
Anthropic 将 Agent Skills 描述为包含指令、脚本和资源的可发现文件夹，并强调渐进披露：Agent 先看到何时可用的元信息，再按任务需要加载详细指令或运行确定性脚本。其建议从评测中发现能力缺口，在真实使用中观察 Agent 如何读取和使用资产，再逐步改进。5
对企业而言，Skill 的价值不在于某种文件格式，而在于把“某位同事会做”的经验转化为可共享的程序性知识包。每个 Skill 都应有任务范围、输入输出、来源、脚本/工具、验证、Owner、变更和退役条件。知识一旦更新、实例一旦失败、规则一旦发现歧义，就应回写到对应资产中，而不是只在个别聊天窗口里修正。
4. 多 Agent 只在分工清楚、价值足够时使用
Anthropic 对其研究系统的公开说明采用编排者—工作者模式：主 Agent 规划并分配任务，子 Agent 在相对独立的上下文中检索和分析，结果再被整合、引用和评测。文章同时说明，多 Agent 会增加协调复杂度、工具调用和成本；任务高度依赖、难以并行或价值不足时，并不适合采用这种结构。6
因此，多 Agent 的企业问题不是“能否创建更多 Agent”，而是：哪些子任务真正独立？各自能看见什么？谁定义分工和努力预算？如何避免重复、冲突和信息污染？谁在异常时停止、恢复或转人工？如果无法回答这些问题，固定工作流、单 Agent 或人工协作往往是更可靠的选择。
六、组织如何开始：先重构一个工作单元，而不是重画组织架构
组织生产方式的变化通常从一个真实工作单元开始，而非从新的部门名称、岗位调整或全员工具推广开始。建议按以下路径推进。
- 选择一个高频、可验证且人工备用可行的工作单元。 例如整理工单证据、准备技术变更说明、编写内部知识摘要或定位重复异常。避免一开始选择高影响决策、跨系统写入或责任边界模糊的任务。
- 画出当前的人机分工。 明确哪些步骤由人定义、哪些可由 AI 协助、哪些必须复核、哪些动作只能由有权角色批准。不要以“是否使用 AI”替代流程设计。
- 建立最小目标契约与上下文资产。 先定义目标、完成证据、范围、来源、权限、停止条件和 Owner；再建立必要的 Prompt、Skill、工作流或 Agent 合约，而不是把所有背景一次性塞进系统提示词。
- 用真实结果更新协作系统。 将失败、评审意见、工具异常和高质量样本转化为 Golden Set、Skill 更新、工具说明、测试、Runbook 或培训材料。只有反馈能持续回写，局部提效才会成为组织能力。
管理者应特别避免以调用量、Prompt 数量、Agent 数量或自动化率作为主要绩效。更值得奖励的是可验证的业务改进、知识更新、质量提升、风险信号被及时拦截，以及能被其他团队安全复用的协作资产。
七、三种常见误读
误读一：把公开公司实践当作通用蓝图。 公开文章能说明当事团队采用了什么机制，却无法说明其他企业应使用同一模型、架构、人员比例或自主性。企业必须先用自身任务、数据、风险和证据验证。
误读二：把多步骤执行等同于业务自主。 Agent 能够规划、调用工具并完成一段任务，不等于它能确定组织优先级、解释价值冲突、承担法律责任或接受不可逆后果。目标契约、审批、回退和 Owner 不能被省略。
误读三：把更多 Agent、更多上下文或更多工具等同于更高生产率。 更长的运行链路会带来成本、协调、权限、状态和错误传播问题。只有当复杂性在内部评测和实际运行中带来可验证增益时，才应扩大。
八、本章行动清单
- [ ] 选择一个可在两周内观察到端到端结果的人机协作工作单元。
- [ ] 用“委托—复核—拥有”标出每个关键步骤的人类责任与可委托边界。
- [ ] 为该工作单元填写最小目标契约，并关联现有用例立项卡、上下文包和工作流/Agent 合约。
- [ ] 识别一项应从个人经验沉淀为 Skill、示例、脚本、Rubric 或 Runbook 的做法，并指定 Owner。
- [ ] 为一次异常、错误或高质量反馈设计回写路径，确认它会进入评测、知识、工具或培训资产之一。
- [ ] 在扩大到更多人员、工具或自主性前，复核业务价值、质量、权限、人工接管、运行证据和恢复能力。
本章小结
AI 时代的人机协同不取决于是否拥有最强模型，而取决于组织能否把目标、上下文、程序性知识、工具、反馈、权限和责任组织成可运行的协作系统。对话辅助、共同创作、Skill、工作流和 Agent 会长期共存；正确的选择是与任务和控制条件相称的选择。
人的角色并没有被取消，而是在更多场景中转向定义目的、判断边界、复核结果、承担责任和把反馈沉淀为资产。企业应先让一个工作单元变得可描述、可验证、可回退，再逐步扩大协作范围。下一章将讨论当组织对模型、上下文、工具和自动化形成更深依赖后，如何保持韧性与运营准备度。