Agent-first 流程设计：把人肉流程重画成"Agent 干活、人把关"

有个常见的误区，害了很多团队在 AI 落地上绕了大弯：他们以为重造业务流程，就是把原来流程里每一步都配上一个 AI 工具。

旧流程是：人收邮件 → 人整理需求 → 人写方案 → 人走审批 → 人发出去。"AI 赋能"后变成：人+AI 收邮件 → 人+AI 整理需求 → 人+AI 写方案 → 人走审批 → 人+AI 发出去。

这不是重造，这是在旧马路上铺了一层柏油。流程的结构没变，人还在每一步等着、盯着，只不过每步都多了一个"助手"。人的工作量可能下降了 20%，但流程的速度、吞吐量、容错性都没有本质变化。

真正的 Agent-first 流程设计，是重新画一张图——不是在旧流程的每个方框里加个 AI 图标，而是重新思考：哪些步骤可以串成一条 Agent 自动跑的链路，哪些节点人必须亲自站着。两张图在结构上完全不同。

---

什么是 Agent-first 流程

一句话定义：以 Agent 为主力执行者，人只在关键节点出现的流程架构。

"Agent-first"不是"无人值守"，也不是"全自动"。它的核心逻辑是：

• Agent 负责执行：信息收集、判断路由、初稿生成、格式转换、系统写入、状态跟踪——凡是有规则可循、可以被描述成"如果X就Y"的动作，都交给 Agent。
• 人负责把关：在流程里真正需要判断力、授权、或承担责任的节点，人出现一次，做一个决定，然后放行。

这和任务三分法里讲的三档分类直接对应——fully agent-driven 的任务串成 Agent 网络，human-led 的任务人亲自做，agent-assisted 的任务人做主、Agent 辅助。Agent-first 流程设计，就是把这三类任务重新排布在流程图里的具体操作。

---

四步重画路径

第一步：画出现有流程的每一步

不要凭印象，找一个真实流程，把每一步逐条写下来。每步记录三件事：

步骤	谁在做	干的是什么	大概耗时
① 收到客户需求	销售	邮件/微信接收，粘贴进内部文档	10 分钟
② 需求分类	销售	判断是标准品还是定制需求	5 分钟
③ 转交产品	销售 → 产品	发消息或开会交接	30 分钟（含等待）
④ 产品出初步方案	产品	写方案文档	2—4 小时
⑤ 内部评审	产品 + 管理层	会议讨论，拍板	1 小时
⑥ 回复客户	销售	整理方案，发给客户	30 分钟

这一步的目的不是"分析"，而是让流程变得可视。很多团队在这里就已经发现问题了——步骤③"转交"耗时 30 分钟，里面一半是等另一个人上线。

第二步：判断每步该归谁

对每一步，打一个归属标签：人主导（H）/ Agent 辅助（A）/ 完全交给 Agent（F）。

判断标准直接借用任务三分法：

• 完全交给 Agent（F）：信息搬运、格式转换、规则判断、状态写入——有标准答案或可验证输出的。
• Agent 辅助（A）：人做决定，但 Agent 可以先跑一遍给出草稿、分析或建议，人来确认。
• 人主导（H）：需要判断力、价值权衡、对外承诺、或涉及高风险的决策——人必须亲自做，Agent 不该替代。

套回上面的例子：

步骤	原来谁做	归属标签	理由
① 收到需求并整理	销售	F	信息提取 + 格式化，规则明确
② 需求分类	销售	F	标准品 vs 定制品有规则可判断
③ 转交产品	销售	F	路由分配，Agent 自动触发
④ 出初步方案	产品	A	Agent 出草稿，产品经理审核修改
⑤ 内部评审	产品+管理层	H	拍板决策，涉及资源分配和对客承诺
⑥ 回复客户	销售	A	Agent 整理方案格式，销售确认后发出

重点：打标签不是一次性的，第一遍打完要问：我打这个标签，有没有低估 Agent 的能力？也没有过度信任 Agent？

第三步：把 F 和 A 的步骤连成 Agent 网络

把所有"完全交给 Agent"的步骤，用触发关系串起来——上一步的输出是下一步的输入。这条链就是你的 Agent 网络骨干。

"Agent 辅助"的步骤，变成"Agent 跑完 → 等待人确认 → 人放行后继续"的节点。

五种编排模式里的链式、路由、并行，都是这个连接过程的具体选项——比如步骤①②③可以链式串联，未来如果分类结果要同时通知多个下游（产品+库存），可以改成并行。

这一步不需要会写代码，但需要画清楚每个节点：

• 输入是什么（上游传什么过来）
• Agent 执行什么动作
• 输出是什么（传给谁）
• 异常怎么处理（路由到人工 or 重试 or 报错）

第四步：人只留在关键节点

把所有标记"H"的步骤，明确地标出来：这里需要人出现，做一个决定，然后流程继续。

人在流程里的角色从"每步都在"变成"定点守关"。关键节点的特征在下面单独讲。

---

重画示例：客户投诉处理流程

这是一家 SaaS 公司真实存在的情况（细节做了脱敏）。

旧流程（人肉版）

客户发邮件投诉
  → 客服专员登录邮箱看到
  → 手动填写工单（复制粘贴到系统）
  → 判断投诉类型（功能 bug / 账单 / 使用问题 / 情绪宣泄）
  → 发给对应部门（技术/财务/产品支持）
  → 对应部门回复客服
  → 客服整理回复话术
  → 回复客户邮件
  → 关闭工单

平均处理时长：4—8 小时（大部分时间是等人、找人、等回复）。客服专员每天 60% 时间在做信息搬运。

新流程（Agent-first 版）

客户发邮件投诉
  → [Agent] 自动读取邮件，提取：客户ID / 投诉要点 / 情绪程度 / 所涉功能
  → [Agent] 自动创建工单，填写分类标签
  → [Agent] 路由：
       - 功能 bug → 自动关联已知 bug 库，生成"已知问题+预计修复时间"回复草稿
       - 账单问题 → 自动拉取账单记录，生成情况说明草稿
       - 情绪强烈 / 涉及退款 → 路由到[人工节点①]客服主管介入
  → [Agent] 向对应部门发起异步协作请求（不是"等人上线"，而是系统通知+截止时间）
  → [Agent] 收到部门回复后，自动整合回复话术草稿
  → [人工节点②] 客服确认草稿（30 秒—2 分钟）
  → [Agent] 发出邮件，关闭工单，归档

平均处理时长：30—90 分钟（大部分情况下客服不需要介入，只在节点②点一下确认）。

两个人工节点的定义：

• 节点①：情绪强烈或涉及退款——对外承诺的金额和口径需要有权限的人拍板，Agent 不能替代。
• 节点②：回复草稿确认——不是"必须改"，而是"必须有人看一眼再发出去"，防止 Agent 跑偏。

对比两张流程图，结构完全不同：旧流程是人串联起来的链条，每个人都是一个等待节点；新流程是 Agent 串联起来的网络，人只在两个关键位置出现。

---

怎么定义"人在环上"的关键节点

并不是所有步骤都该设人工节点。设多了，流程变慢，和旧流程没区别；设少了，风险点无人把关。

以下四类场景，人必须在流程里出现：

① 对外承诺类：流程结果会直接变成给客户/合作方/监管机构的承诺。合同条款、退款金额、交付时间、合规声明——这些内容一旦出去就有法律或商业约束，Agent 的输出必须有人确认再发出。

② 高风险决策类：决策一旦错了，代价大且难以撤销。删除数据、发起大额支付、触发合同终止条款、公开发布涉及品牌声誉的内容——即使 Agent 的判断看起来合理，人也必须出现。

③ 异常路由类：流程碰到 Agent 无法处理的情况——超出规则范围的边界案例、罕见的组合条件、情绪激烈的对话——自动路由到人，而不是让 Agent 硬跑一个大概率错的结果。

④ 责任归属类：流程结果需要一个具名的人负责。不是"系统处理的"，而是"谁批准了"。内部审批、预算拍板、人事决定——这类节点人不能缺位，不是因为 Agent 做不到，而是因为责任不能落在 Agent 身上。

一个实用的检查问题："如果这一步出错了，谁负责？" 如果答案是"没有人，是系统自动处理的"——这一步大概率需要加人工节点。

---

反面教训：贴工具不是重造

这是最常见的陷阱，值得单独说清楚。

表现：把原来的流程文档拿出来，在每个步骤下面补一行"AI 工具：XXX"。流程图里每个方框都加了一个小机器人图标。PPT 里写着"全面拥抱 AI"。

问题：流程的结构没变。步骤数量没变，依赖关系没变，等待节点没变，人在每一步的介入方式没变。AI 工具变成了每个人手里多了一个"更快的笔"，但流程本身的瓶颈——等待、交接、重复传递——一个都没有消除。

怎么识别自己是不是在贴工具：问一个问题——"这个流程里，如果把所有 AI 工具去掉，流程还是原来那个流程吗？" 如果答案是"是"——你做的是工具配置，不是流程重造。

真正的 Agent-first 重造，去掉 Agent 之后流程就跑不了，因为整个执行路径依赖 Agent 的调度和传递。这才是结构性的变化。

还有一种更隐蔽的贴工具：按原有岗位边界设计 Agent。旧流程里销售做 A、产品做 B、客服做 C，Agent-first 版本里变成"销售的 Agent"做 A、"产品的 Agent"做 B、"客服的 Agent"做 C。岗位边界成了 Agent 的边界，原来的交接点都保留了下来——但这些交接点本来就是流程最慢的地方。重造的价值就消失了。

Agent-first 流程设计的出发点是任务和数据流，不是组织架构。先问"这件事该怎么流"，再问"哪个 Agent 或哪个人负责这一段"。

---

常见问题

我们的业务流程非常复杂，不知道从哪里开始重画。

从最痛的那条流程开始，不要选全局。找一条满足这三个条件的：① 每周都在跑；② 有明确的起点和终点；③ 你能说清楚"这条流程当前最慢的地方在哪里"。典型候选：客户需求响应、内容发布审批、合同流转、周报汇总。选一条，走完四步重画，出一个最小可用版本，跑两周，再扩。不要第一次就想重画整个公司的流程。

第二步打标签时，怎么判断某一步到底是 F 还是 A？

有一个简单测试：把这一步的输入描述给一个陌生人听，然后问他：你能给我一个"对/错"或者"1/2/3"这样的明确答案吗？如果能，这一步大概率可以给 Agent（F）。如果他需要追问"这要看情况"，或者答案因人而异，这一步需要人参与（A 或 H）。另一个信号：如果这一步的错误"安静地传导"到下游不会被发现——说明它需要人工确认节点。

设了人工节点，但人还是觉得每一步都要看，最后流程还是慢。

这是习惯问题，不是流程问题。人工节点的设计要明确：这里人需要做什么决定，预计花多长时间，不做决定会发生什么（比如 30 分钟内无操作默认放行，或自动升级）。如果节点设计不清晰，人会本能地把它当成"我需要重新审视整件事"的机会，时间就耗在这里。把节点的决策范围缩小到最小——"这个草稿可以发吗，是/否"——人的介入时间会自然降低到 1 分钟以内。

Agent 跑错了怎么办？流程里怎么处理错误？

每个 Agent 节点设计的时候，同步定义三件事：① 什么情况算"跑错了"（验证规则）；② 跑错了之后路由到哪里（重试/人工/报错）；③ 错误会不会影响后续步骤（隔离范围）。错误处理不是事后补救，是流程设计的一部分。第三步连 Agent 网络的时候，每条边不只是"正常流"，也要画出"异常流"的去向。

---

小结 · 你现在该做什么

• 明白了"贴工具"和"流程重造"的本质区别：结构没变就不是重造
• 拿到了四步重画路径：画现状 → 判断每步归属（H/A/F）→ 连成 Agent 网络 → 人留关键节点
• 看完了客户投诉处理的前后对比：两张图结构完全不同
• 知道了四类必须有人在的关键节点：对外承诺、高风险决策、异常路由、责任归属

下一步：流程重画出来之后，你会发现有些流程天然适合某种编排模式——链式、路由、并行。五种编排模式（管理者版）能帮你把重画的结果落实成具体的 Agent 架构选型。还没做任务分类的，先看任务三分法把现有工作盘一遍，再来重画流程。

👉 看看 AI 时代的组织与管理 专栏，或了解 AI 时代管理者认知课。需要定制落地与陪跑，欢迎聊 企业服务。