AI 原生转型 · 运营模式 · 人机协作工作流
AI 原生运营模式：从组织架构到工作图谱
Nick Zhu 用于重新设计人、Agent 与系统如何围绕业务结果协作的工作框架，涵盖工作图谱、角色配置、决定权、证据、例外与学习回路。
作者：Nick Zhu
AI 原生运营模式，并不是在组织架构里增加几个 Agent。它需要有意识地设计：业务结果、决策、任务、上下文、行动、证据、例外与责任，如何在人、Agent 与系统之间流动。
我使用工作图谱让这种设计变得可以检查。它补充组织架构，但不取代法人结构、汇报关系、管理责任或人的最终责任。这是我的工作框架，不是行业标准、人员缩减模型、强制技术架构，也不主张每条工作流都应该使用 Agent。
组织架构仍然有价值。它告诉我们正式权限位于哪里、团队如何划分，以及谁向谁汇报。但当工作跨越职能、系统、队列与能力不断增强的软件时，组织架构往往无法完整回答另一个问题：一项业务结果究竟是怎样被生产出来的？
这个问题很重要，因为即使组织架构中的每个岗位都配置正确，工作流仍可能失效。上下文可能来得太晚；一项决策可能没有明确负责人；Agent 也许能够行动，却不知道何时应该升级；证据可能已经产生，却没有回到能够改进工作的人手中。缺口未必在组织结构本身，也可能存在于组织方框之间的运营设计。
两张地图，回答两个不同的问题
组织架构描述正式结构，工作图谱描述工作如何流动。
这不是新旧两种模型之间的竞争。企业仍然需要法律责任、管理责任、团队与汇报关系。工作图谱只是增加第二个视角：正在追求什么结果、哪些决策影响结果、哪些任务与系统参与其中、需要什么上下文、行动在哪里发生、什么证据会返回，以及由谁处理例外。
两张互补的地图
正式结构与工作流动
组织架构
谁向谁汇报？
- 正式权限
- 团队与角色
- 管理责任
工作图谱
一项结果如何被生产？
- 决策与任务
- 上下文与行动
- 证据与例外
工作图谱补充组织架构，但不取代法人结构、汇报关系、管理责任或人的最终责任。
工作图谱从业务结果开始，而不是从自动化目标开始
我把工作图谱定义为：用于描述产生一项有界业务结果所需元素及其关系的可检查模型。起点不是“哪里可以放一个 Agent”，而是“我们希望为谁产生什么结果，以及边界在哪里”。
从这项结果出发，图谱可以展开七个相互连接的元素：
- 结果： 工作流准备产生的有界结果。
- 决策： 会改变方向、承诺、风险或验收的判断。
- 任务： 用于准备、转换、检查或交付某项内容的工作单元。
- 上下文： 负责任地完成工作所需的政策、知识、记录、权限与当前状态。
- 行动： 对文档、系统、沟通或外部世界作出的改变。
- 证据与例外： 用于判断工作是否保持在边界内的观察，以及落在预期路径之外的情况。
- 学习： 观察到的证据如何改变工作流、上下文、Agent、评估或下一项运营决策。
这个顺序是一条阅读路径，不是通用软件架构。真实工作可能分支、循环、并行或停止。工作图谱的价值，不是把工作画成一条直线，而是让缺失的关系更容易被发现。
工作图谱的构成
围绕一项结果的七个相连元素
- 01结果有界产出
- 02决策方向与承诺
- 03任务工作单元
- 04上下文知识、政策与权限
- 05行动作出的改变
- 06证据与例外观察质量与边缘情况
- 07学习下一步改变什么
这是一条用于检查的阅读路径，不是强制顺序、系统架构、成熟度模型，也不主张真实工作必然线性进行。
在人、Agent 与系统之间分配工作
“人机协作”本身太模糊，无法直接运营。一条可以运行的工作流，需要更明确地分配工作。
人通常更适合持有意图、高重要性判断、运营边界、批准权、例外处理与最终责任。Agent 可以在具备必要上下文与权限时，执行准备、转换、搜索、综合、起草、测试、工具协调或有边界的行动。事实记录系统则保存权威状态、权限、交易与证据。
这些只是本框架中的设计倾向，并不是通用角色定义。某项任务可能更适合确定性服务，而不是 Agent；低频或高后果步骤可能仍由人直接完成；Agent 可以承担大量工作，但不因此成为业务结果的负责人。
实用的检查方法是：每个重要节点是否都有明确执行者、清晰边界、预期输出和恢复路径。如果一项任务只被描述为“交给 AI 处理”，图谱还不够具体。
角色分配
三类参与者，不同的运营责任
人
- 设定意图
- 持有边界
- 判断例外
- 承担最终责任
Agent
- 准备与转换
- 搜索与综合
- 使用获准工具
- 执行有界工作
事实记录系统
- 保存权威状态
- 执行权限规则
- 记录交易
- 保留证据
这些是设计倾向，不是通用分配。合适的执行者取决于工作、后果、证据、权限与恢复要求。
选择运营配置，但不要把它变成阶梯
同一条工作流可以在不同节点采用不同配置。我使用三种并列的配置：
人使用 AI 辅助
人执行工作，并使用 AI 改善一项有界任务。人直接控制过程，始终接近输出。
人与 Agent 协作
人和 Agent 分担相互连接的工作。工作流需要明确交接、共享上下文、审核标准与例外路径。
人主导的有界委派
人设定意图与运营边界，Agent 在获准权限内执行较长或多步骤任务。设计需要可观察的进度、证据、停止条件与升级路径。
这些是运营配置，不是组织成熟度等级。更多委派不代表更加 AI 原生。高后果决策可以继续由人操作，同时把后果较低的研究或准备路径委派给 Agent。一条工作流也可以同时组合三种配置。
并列配置
三种工作配置方式
- 01人使用 AI 辅助
人控制过程，AI 支持一项有界任务。
- 02人与 Agent 协作
人和 Agent 通过明确交接分担相互连接的工作。
- 03人主导的有界委派
人设定意图与边界，Agent 在权限与停止条件内执行。
这是三种并列配置，不是阶段、成熟度等级、强制旅程，也不证明更多委派更好。
在扩大自主性之前，先设计决定权
自主性并不是一个开关。一条工作流包含多种可以分别分配的权利。
谁可以发起工作？Agent 可以访问哪些上下文？它可以采取哪些行动？谁批准高重要性输出？谁能够中断或覆盖当前路径？谁验收结果，并继续对业务结果负责？
我使用六项决定权让这条边界可以被检查：发起、访问、行动、批准、覆盖与验收。并不是每项权利都必须由人执行，但每条工作流都应该明确答案；高重要性决策、运营边界、批准权与最终责任，应继续归属于可识别的人类负责人。
最后一句是我的规范性立场，不是法律规定、行业共识、合同分配，也不要求人手工执行每一个步骤。它是一条设计纪律：当执行工作被更多委派时，责任仍然保持清晰。
决定权地图
需要明确分配的六项权利
- 01发起谁可以开始工作？
- 02访问可以使用哪些上下文与系统？
- 03行动可以作出哪些改变？
- 04批准谁授权高重要性输出？
- 05覆盖谁能中断或改变方向？
- 06验收谁对结果负责？
让高重要性决策、运营边界、批准权与最终责任继续归属于可识别的人类负责人。
具体分配取决于情境。本框架不要求人执行每一步，也不定义法律、合同或责任归属。
让证据与例外成为运营模式的一部分
一条工作流不会因为正常路径实现自动化，就自动成为 AI 原生。运营模式还需要解释：上下文缺失、证据冲突、置信不足、工具失效、没有权限，或情况落在预期边界之外时，应该发生什么。
例外不仅是运营噪音，也可能暴露工作图谱中的定义缺口。一个例外可能指向缺失的上下文、不清晰的决定权、不现实的质量标准、脆弱的交接，或者一项原本就不应该被委派的任务。
因此，证据需要返回到能够改变设计的人手中。他们可以更新工作流、上下文、权限、工具、Agent 指令、评估，或者委派范围；也可以决定继续保持有界或停止。学习并不会自动把工作升级为更高自主性。
有界学习回路
证据返回到人的运营决策
- 01运行有界工作
- 02记录证据
- 03暴露例外
- 04人的运营决策改变、保持、收窄或停止
- 05更新设计工作流、上下文、权限、工具、Agent 或评估
如果人类负责人决定继续，更新后的设计将返回下一次有界运行。
这是一种可能的学习回路，不证明持续改进、自动扩张，也不要求增加委派程度。
先重构一条工作流，再谈重构整个组织
工作图谱最适合应用在一项真实结果上，而不是一开始就画成抽象的全公司转型地图。先从能够约束价值、责任与证据的地方开始。
建立一份 Work Graph Record
选择一条工作流，用一页记录以下内容：
- 有界结果： 工作流准备为谁产生什么结果，边界在哪里？
- 决策与人类负责人： 哪些判断会改变方向、承诺、风险或验收？由谁负责？
- 任务与执行者： 哪些工作由人、Agent、确定性工具或事实记录系统完成？
- 所需上下文与权限： 每项重要行动开始前，必须知道什么或能够访问什么？
- 行动与事实记录系统： 将作出什么改变？记录在哪里？哪个状态具有权威性？
- 证据与例外路径： 什么能够证明工作保持在边界内？什么情况需要升级？
- 运营配置： 哪些节点采用辅助、协作或有界委派？
- 下一项学习决策： 什么证据可能支持改变、保持、收窄或停止当前设计？
这份记录不是人员计划、自动化评分、成熟度评估或架构认证。它的目的，是让围绕一项业务结果的运营假设变得足够可见，从而可以被质疑。
AI 原生转型：从局部提效到业务重构 帮助判断围绕一项有界业务任务应该选择多大的变更范围；什么让一家企业成为 AI 原生？ 提供更广泛的业务设计背景。工作图谱则再向下推进一层：所选择的工作究竟应该如何运行？
如果团队内部仍无法解决运营模式，FDE Delta 运营合作可以作为工作流边界明确后的克制下一步。这不意味着认证、保证路线图、人员缩减方案或结果承诺。
关于这一视角
我的视角来自企业系统、转型、0→1 业务构建、商业化与当前 AI 原生实践。我使用工作图谱组织自己对运营模式的检查方式，不把它描述成通用方法论，也不把它当作客户结果的证据。
目标不是让组织架构消失，而是让组织方框之间的工作变得可见：业务结果、决策、上下文、行动、证据、例外与人的最终责任，如何让人、Agent 与系统作为一个有边界的业务系统共同运行。