别急着上 AI Agent，先画出真实的业务流程

当根据官方三步 SOP 训练出的 Agent，遇上周二下午白板上的真实工作流。

搭建一个 AI Agent 原型，一下午就够。但要让一套智能体工作流在现有组织内稳定运转，是复杂度完全不同的工程难题。

OpenAI 等机构设立的前线部署工程师（FDE）岗位正说明了这一点：工程师必须深入客户业务现场，搞清楚需求调研、技术边界、系统架构与投产落地。摸清一线到底如何运转，是打造可用系统的先决条件。

许多企业在推行 AI 时，第一个问题就问错了。他们看着既有部门架构发问：“我们流程里的哪几步，能直接甩给 Agent？”

在转向软件工程管理前，我曾在一家跨国电信企业的共享服务中心担任过两年 IT 流程主管。我的工作跨越四个国家，梳理数百人的协同路径，重构从故障响应到软件交付的核心工作流。

观察如今各团队搭建 Agent 工作流的过程，我看到了完全相同的结构性陷阱：你白纸黑字写在文档里的流程，几乎从来不是实际干活的方式。

文档不是流程

团队着手构建 Agent 工作流时，第一反应往往是搜集“权威输入”。他们翻出新人培训 PPT、飞书或 Confluence 知识库，以及标准作业程序（SOP），直接塞进上下文窗口或检索管线，以为 Agent 就会老老实实照章办事。

当年我着手重构多市场的事件管理流程时，也先去翻了官方文档。我找到了三份：一份 2010 年的，一份 2014 年的，还有一份挂在内部 Wiki 上。其中 2014 年版大段照抄通用模板。

没有一份能对得上一线的日常工作。

于是我关掉文档，拉着团队开白板会。我和各国的服务台客服、计费运维、DBA 以及一线支持人员围坐在一起，请他们画出工单在一个班次里到底是怎么流转的——不是画应该怎么走，而是画实际上怎么走。

回到工位后，我把会上收集到的抱怨和卡点逐一写在便利贴上，一共 40 多张，归为八大类。

我原本以为最大的问题是“缺乏流程规范”。但事实并非如此。

工位上堆得最高的便利贴标签是：“流程写在那，但没人照着做。”

无人认领的交接。 专家组解决了技术故障，但因为关闭规则含糊不清，索性把工单挂着，导致工单在多个团队间来回踢皮球。
语义含糊的状态位。 工程师卡壳时会把工单设为 Pending（待处理）。深入访谈发现，这个词有四种不同含义：等客户反馈、等外部供应商、等维护窗口，或者单纯表示“我手头在忙别的事”。
白板上的问号。 数据库团队画出流程后，在旁边批注：(!) 分派规则不明。服务台列出了官方的四种事件分类，但在最后一项后面打满了 ???。
缺失工具权限。 其中一张便利贴单独成组：“部分团队根本没有工单系统的登录权限”。

在制造业流程图里，计划内的生产路线画实线，没人愿意摆上台面的返工和报废路径画虚线。而在服务与研发型组织中，正是那些不合规的“野路子”，撑起了整个系统的运转。

白板上的每一个问号都是排查信号。在尝试自动化之前，必须先厘清规则与权责归属。

如果你完全基于官方 SOP 去搭建 Agent，你服务的目标只是一个存在于幻想中的组织。

单点提速，不等于全局提速

拿到一线反馈后，我打印出原始的事件流转图，把所有摩擦点一一标出。核心痛点根本不在工单录入或初步诊断——而这两处恰恰是大多数流程文档（以及多数 AI 试点项目）最爱使劲的地方。真正的瓶颈在于跨职能升级：当工单从一线支持转交到另一个国家的专家团队时，信息丢失、工单积压与反复扯皮集中爆发。

后来分析集中软件交付部门时，我见到了同样的情况，而且规模更大。一个跨系统需求从提出到上线，需要 12 到 18 周。我复盘过一个集成改造项目：历经初步分流、影响分析、方案宣讲、方案描述以及整整六个版本的 PPT 汇报，光细化设计就磨了九个月。

周期长并不是因为工程师敲代码太慢。而是因为组织内部并存着五种交付节奏，工作在不同部门的交接队列里躺平了好几个星期。

优化单一节点内部的耗时当然有意义，前提是这个节点本身就是全流程瓶颈。但正如 Michael Hammer 在 1990 年《哈佛商业评论》经典名篇《流程再造：消灭任务，而非自动化任务》中所言：企业往往忙于在部门孤岛内实现局部任务自动化，却对孤岛之间支离破碎的交接环节视而不见。

优化单个方框内部 vs 解决方框之间的瓶颈：端到端交付时长消耗在交接队列中时，给单个任务提速收效甚微。

这也是为什么代码或办公助手在任务层级提升了效率，企业整体交付周期却没有明显缩短。优化“节点 4”作用有限，因为大把时间依然烂在“节点 4”和“节点 5”之间的异常死循环里。

语义接缝：四个团队对同一个词有四种理解

即便每个团队本地的工作流都很合理，自动化也会在跨团队边界处彻底崩溃。

在电信公司的第二年，针对某个国家市场开发的功能直接搞挂了另一个市场的服务。事后复盘得出了显而易见的结论：在需求分析阶段，就该识别出跨国影响。

但我没有简单地发一条新规定要求大家“排查全局影响”，而是向 CRM、计费、中间件集成和服务交付四大核心系统的负责人发了一份简短问卷：

在你的系统里，什么叫“全局变更”（Global Change）？
你什么时候会发现某个变更是跨国影响的？
谁来审批？在 Jira 里如何追踪？

我收到了四个南辕北辙的答案。一个团队在系统架构设计完后才评估全局影响；另一个团队在业务分析阶段识别——前提是业务输入足够清晰，否则就拖到研发期；其余两个团队甚至根本没有正式的全局审批机制，全靠架构师开会时“碰巧发现”依赖关系。

每个团队都遵循着自身的局部逻辑，风险全部藏在定义的落差里。

语义接缝：当多个团队（或多个协同 Agent）都在使用“全局”、“就绪”或“完成”等标签，背后对应的局部定义却互不兼容。

审视如今很多团队构建跨部门多 Agent 协作的方式：录入 Agent 将结构化状态传递给分流 Agent 或下游履约流，想当然地认为像 全局、就绪、客户、升级、完成 这类词在所有环节语义一致。实际上并非如此，每个小团队都有一套自己的方言。

在用自动化串联各团队前，必须统一底层语言。当时我们的解决方案是建立一套五级升级阶梯（从录入时的 A 级一直到迭代冲刺中的 E 级），让跨系统团队在面对跨国变更时，享有统一的判定标准与审批路径。

AI Agent 到底应该放哪？

后来，我需要为覆盖七个国家的 15 个跨职能团队设计通用的端到端交付流程。在这个过程中摸索出的分流原则，对构建高效的 Agent 体系同样适用。

“先梳理真实流程”，不是叫你把业务冻结半年去憋一份全能规范，而是选定一个闭环业务，端到端跟踪真实案例，动手开发前先对每个步骤进行严格排查：

第一步，坚决砍掉无明确负责人和输出的环节（TBD 占位符测试）。在我早期的一张流程图正中央，有个写着 TBD（待定）的方框，连接着好几条支线。开会时我问这步是谁负责、能产出什么具体决策或交付物，全场鸦雀无声。它就是一个用来堆积延误的“停滞缓冲区”。我们果断将它剔除，几轮迭代下来，把原本 16 步的分析阶段精简至 12 步。在自动化某个节点前，先确认它到底承载着真实的管控或业务价值，还是纯粹属于历史遗留的交接包袱。

第二步，把简单规则直接分流到确定性快车道。在最早的白板角落有一行小字：“产品配置变更：超出范围”。当时，简单的费率更新全卡在为复杂系统搭建的架构分析流程里。我们把这种特殊情况改造成快车道：标准配置类更新直接绕过架构评审，进需求池排期。在 AI 架构设计中逻辑完全一致：如果分流规则清晰稳定（if/else），直接写代码或走 API 永远比调一次大模型更快、更省钱、更容易排错。

只有裁剪掉冗余节点，并用普通代码收归确定性逻辑之后，你才需要考虑在哪里接入 AI。即便到这一步，也要区分单次大模型调用与自主 Agent。

在非结构化输入与系统规则剧烈碰撞的摩擦边界上——比如将自由文本形式的报错分类并对齐历史工单、校验变更申请是否漏填上下文、汇总多工具日志——嵌套在固定工作流中的单次大模型辅助往往就能搞定。只有当任务需要根据新反馈动态规划排查路径、自主选择工具并持续调整策略时，引入 AI Agent 才有意义。

涉及到跨系统计费修改、安全准入等高风险决策，必须保留明确的人工审批与责任人兜底。

自动化前的分类筛选：先剔除无主环节，用确定性代码搞定稳定规则，再决定哪些地方放单次大模型、哪些地方放自主 Agent、哪些节点设置人工闸门。

底层规则清晰严格，人机交互极简明了

新流程最终上线时，完整的规范文档涵盖 4 个阶段、65 个步骤，记录了约 60 条干系人反馈以及 32 项正式决策。

当你要协调跨国团队——或者要为自主 Agent 体系界定运行边界时，明确的约束是刚需。Agent 可以动态决定如何排查问题或起草方案，但它的权限边界、验证逻辑、升级触发条件和终止动作，必须被死死限定住。

然而，一份多达 65 步的说明书是写给系统架构师和合规团队看的，一线员工在周一早晨根本不可能装进脑子里。

复杂的路由分支与边界控制下沉到系统底层；与人打交道的界面必须收敛到单页看板上。

为了让流程真正走入日常，我们落地了三项法则，这同样适用于当前引入 AI 工作流的场景：

嵌进日常核心系统（System of Record）。 处理突发事故时让人去翻 30 页 PDF，或者要求工程师跳到一个全新且孤立的 Agent 看板上操作，都会造成巨大的采用摩擦。我们将 4 个阶段、65 个底层步骤，映射到团队每天都在用的 13 个 Jira 状态中（如 Draft、Initial Triage、Ready for Analysis、Sprint Ready、Done）。工具改变不了烂流程，但把流程节点嵌进大家每天盯着的工作软件里，能消灭频繁切屏的阻力。
对每个异议给出明确反馈。 事故响应流程上线时，一个区域团队提出，中低优先级工单 24 小时的 SLA 对没有夜班值守的团队不公平。他们说得很对，我们随后修改了规则，对这类工单改按“工作时间”计算。在交付流程评审期间，收集到的约 60 条异议都在共享日志中写明了最终决议。当一线员工看到系统尊重他们的实际约束时，信任才会建立。
把给人的操作视图压缩到一页纸。 在跨团队冲刺开始前，我把 23 步的技术细节压缩成了只关注跨团队协作交接的 9 步精简版。对于每个上线的核心流程，我们都做了一份标准化单页手册（One-Pager）。让底层管线负责执行复杂的逻辑分支，让人看的东西两分钟内必须能扫完。