最近团队在做一个客服工单自动处理 Agent最早的写法很直觉把整套处理规范写成一段超长 prompt让大模型按顺序执行。单条测试时效果不错并发一上来问题就开始冒头——有的工单漏掉了必做核验有的在同一个分支里反复重试还有的直接忘记把上一步结论传给下一步。排查时只能翻对话日志找半天都定位不到卡在哪一层。后来我们把处理规范从一段文字描述改成了一张 graph每个操作是一个节点节点之间的流转条件是边整个流程变成了一个可以执行、可以观测、可以单独测试的图结构。这个改变的收益比预期大得多。不是因为画图好看而是因为把“给模型讲一遍流程”变成了“给 Agent 一条明确的运行轨道”。这正是 Graph Engineering 想解决的问题把 Agent 的 SOP 画成 graph它就能自己跑。这句话真正的含义不是“画一张流程图”而是把隐性的、靠提示词维持的流程变成显性的、可执行、可维护的工程结构。1. 先搞清楚 Graph Engineering 解决的是什么问题1.1 文字 SOP 为什么会被 Agent 执行偏SOP 本来是人类之间协作的产物写清楚先做什么、后做什么、什么情况下做什么。把这段文字直接塞给大模型看起来可行实际上每一步都是在让模型重新“理解”流程。问题出在三个地方。第一理解有损耗。不同模型、不同上下文长度、甚至同一模型在不同会话里对“如果金额较大就转人工”这句话的把握都不一样。什么叫“较大”边界不清晰执行就不稳定。第二控制流藏在模型脑袋里。文字 SOP 里“先 A 再 B遇到 C 跳 D”这种逻辑模型读完以后是自己脑补执行的。你无法强制它走到 B 之后一定检查一个条件只能靠提示词去“劝”。可“劝”不等于“保证”。第三出错以后没法定位。文字流程一旦跑偏你看到的是最终输出不对但不知道在哪一步偏了。翻对话日志成本极高改起来更麻烦可能为了修一个问题把整个 prompt 重写一遍。所以文字 SOP 不是不能用而是很难工程化。它适合给人看不适合作为 Agent 的稳定执行规范。1.2 图的本质把“顺序”升级成“路径”图结构带来的变化表面上看是“把流程可视化”实际是把执行控制权从模型手里拿回来一部分控制流不再依赖模型临场发挥而是由图的边和节点决定。模型在每个节点只做局部决策整体路线由图引擎保障。我习惯做这样一张对比维度文字 SOP图化 SOP控制流位置模型内部隐式图结构显式条件判断靠模型语义理解由边的条件和检查节点明确判断执行稳定性依赖提示词质量依赖图结构和节点实现失败定位翻全部对话看节点级日志修改成本改 prompt连带影响不确定改边或改节点局部可控可测试性很难单独测某个环节每个节点可独立验证这张表是我判断一个流程该不该图化的核心依据。如果一段 SOP 的执行结果只能靠整体效果来评估那说明它还停留在文字阶段如果每个环节都能单独验证那它已经具备图化的条件了。2. 把 SOP 画成 graph 时先确定这四类元素2.1 节点不只是任务还有决策、工具、检查点很多人画图时会犯一个习惯性错误每个节点都写成“让大模型做一件事”。比如“提取信息”“判断风险”“生成回复”清一色是模型节点。但真实 SOP 里不是每一步都需要大模型。常见节点至少可以分为几种任务节点调用大模型完成某个子任务比如“从工单里提取客户诉求”。工具节点调用 API、查询数据库、发送消息、写文件。这类节点不经过大模型执行更快、更可控。决策节点根据状态里的字段值选择走哪条边。判断逻辑可以用规则不必每次都用模型。检查节点校验上一步输出是否符合格式要求、是否有缺失字段不合格就重试或转人工。人工节点需要人确认或介入时挂起流程。画图之前先做分类比直接连线重要得多。因为不同节点类型的失败处理方式完全不同工具节点重试策略是超时重连模型节点重试策略是换 prompt 或降低温度检查节点失败则不应该盲目重试而是要暴露给上层。2.2 边回答的不是“下一步”而是“什么时候下一步”边的最大价值在条件。没有条件的边只是顺序有条件的边才是流程逻辑。我一般会在边上写清楚这么几类条件无条件流转执行完 A 就立刻到 B。条件流转状态里的某个字段满足某条件时选择某条路径。超时流转节点执行超过限定时间走降级分支。错误流转节点抛异常时进入补偿节点而不是直接终止。条件一定要写成可验证的表达式而不是再丢给模型判断。比如“金额大于 10000 转人工”这就是一个明确规则用代码判断即可。只有当规则本身无法用代码表达时才考虑引入模型判断而且要在判断节点里写清楚输出格式让后续边能拿到结构化结果。2.3 状态是图能跑起来的关键图是骨架状态是血液。节点之间怎么传数据、传什么数据决定了这张图能不能真正跑起来。我在实践里通常把状态设计成一个共享的 dict 或者结构体每个节点从里面读自己需要的字段写入自己产生的字段。关键原则有两条第一明确输入输出。每个节点在被执行前应该声明自己依赖哪些状态字段、产出哪些字段。这看起来像多写几行配置但排查问题时会省很多时间。某一步没有值一眼就能看出是上游哪个节点没写。第二控制状态体积。不要把整个历史对话都塞进状态更不要在每个节点都把所有字段拼进 prompt。状态里只保留当前流程还需要的数据以及下一节点真正要用的数据。否则图越跑越慢上下文越长效果越差。2.4 把长文本拆进节点上下文而不是一次性塞给大模型这是图化 SOP 最容易被低估的收益。文字 SOP 通常是一大段话包含背景、步骤、规则、例外情况。一次性塞给模型模型要同时记住“流程”和“内容”负担很大。图化之后每个节点可以有自己的 prompt这个节点只需要知道“当前状态里的这几个字段加上一条节点级指令”。比如风险判断节点只需要知道金额、客户类型、历史投诉次数判断规则写在该节点的指令里。其他无关信息完全不用出现。这个做法带来的效果是指令更聚焦模型犯错的概率更低而且每个节点的 prompt 都是独立可调、独立测试的。改风险判断规则时不会影响信息提取节点。3. 从“画图”到“自己跑”一次最小可运行的落地流程3.1 先用配置或代码把图定义出来画图软件只能帮你沟通真正让它跑起来需要把图翻译成配置或代码。下面是一个简化的图定义结构用来示意怎么描述节点、边、条件和状态字段。实际实现取决于你用的框架但抽象是一致的。{ start: extract_info, nodes: { extract_info: { type: task, prompt: 从工单中提取客户诉求输出 JSON字段包括 amount, intent, urgency, output_fields: [amount, intent, urgency], retry: { max_attempts: 2 } }, risk_check: { type: decision, condition: amount 10000 or urgency high, true_next: human_review, false_next: auto_reply }, auto_reply: { type: task, prompt: 根据提取结果生成回复语气保持专业, output_fields: [reply] }, human_review: { type: human, assignee: support_lead, timeout_seconds: 3600 } }, end: [auto_reply, human_review] }这里有个细节值得注意节点的类型不只是“任务”还有“决策”和“人工”。这样做的好处是决策逻辑可以脱离模型独立运行人工节点则把流程挂起等待介入。一张图里混用多种节点类型才能真正对应现实中的 SOP。3.2 执行引擎怎么循环有了图定义执行引擎的循环逻辑其实很固定找到起始节点初始化状态。执行当前节点得到输出并写入状态。根据节点类型和状态值评估出边条件确定下一个节点。如果没有符合条件的边且当前不是终止节点按错误处理。到达终止节点或触发全局终止条件结束本次执行。关键点在于每一步都要留下记录。哪个节点、第几次尝试、读了哪些状态字段、写出了什么、走了哪条边、耗时多少。这些记录不是可选项是图化流程能长期维护的基础。3.3 分支、重试与终止条件分支很容易理解决策节点选边即可。真正要提前定好的是重试和终止策略。我一般会设三类限制节点级重试次数模型节点或工具节点失败时最多重试几次默认 2 到 3 次即可不要太多。全局最大步数防止图出现循环。不管逻辑上是不是死循环超过步数就强制终止并告警。错误兜底分支每个容易失败的节点后面最好预设一条降级路径。比如模型解析失败两次后不再重试而是转人工。终止条件也要写清楚。图结束不是“模型觉得结束了”而是“执行到达了明确的终止节点”。如果一张图里存在多条终局路径就要确保每条路径最后都有一个终止节点或人工节点收尾。3.4 先跑通再批量从一条样例到全量任务我最推荐的落地顺序是先用 5 到 10 条真实历史数据跑一遍逐节点看结果确认信息提取正确、边条件判断正确、终局路径合理。样本跑通之后再加到几十条观察稳定性和失败率。最后才考虑并发和批量。注意不要一上来就把批量数和并发数拉满。图结构能跑通只说明流程没有断批量场景下的限流、超时、状态写入冲突是另一类问题需要单独验证。如果样本阶段就发现某类输入频繁走错分支不要急着改参数先回看边条件和节点 prompt。图化流程里多数“跑偏”问题不是模型能力问题而是规则没写清楚或状态字段没接对。4. Agent 执行图时真正的难点不是图而是节点之间的交接4.1 上下文怎么传、怎么隔离图跑起来的第一个难点是上下文传递。容易出现两种极端一种是什么都不传每个节点各看各的结果下游节点拿不到上游信息另一种是什么都传每次执行把全量历史都带上上下文越来越长。比较好的做法是显式声明每个节点的“输入视野”。节点需要哪些字段就在定义里列出来。执行引擎只透传这些字段其他数据不进 prompt。这样做既控制成本也避免模型被无关信息干扰。同时要注意字段的覆盖问题。多个节点写同一个字段时要明确以哪个为准或者干脆设计成不同字段名。否则流程走到一半某个值被意外覆盖排查时很难发现。4.2 子 Agent 与工具的边界把 subagent 当成另一种 tool多 Agent 设计里经常出现主从模式。一个常见的理解误区是主 Agent 和子 Agent 之间需要对等协作甚至互相聊天。实际上更稳妥的做法是把 subagent 当作一种特殊的工具调用。换句话说当图中某个节点任务过于复杂不适合继续展开成细粒度节点时可以在这个节点内部启动一个子 Agent给它一个明确的输入和输出契约子 Agent 跑完把结果返回。对主图来说这个节点就是一个工具节点输入明确、输出明确、失败策略明确。这样的好处是主图保持稳定不会因为某个子任务复杂而无限膨胀。子 Agent 内部的流程也可以单独维护、单独优化甚至可以先不图化用普通对话式 Agent 实现等它稳定了再决定要不要进一步拆图。4.3 记忆、Skill 和 MCP 与图的关系现在讨论 Agent 经常会提到记忆、Skill、MCP 这些概念容易误以为它们是互相替代的关系。实际落地时它们的定位完全不同图负责编排决定流程走向。记忆负责跨步骤、跨会话的数据积累。Skill负责把某类能力打包成可复用的工具。MCP负责统一工具访问接口让节点能稳定地调用外部能力。图形节点可以决定在什么时候读取记忆、什么时候调用 Skill、通过 MCP 访问哪个外部服务。也就是说图是骨架记忆和工具是血肉。一个训练有素的团队会把图定义、Skill 定义、MCP 接口配置放在不同目录里分别管理而不是混在一起。4.4 日志与可观测性图化之后排查终于有了抓手图化流程和对话式流程最大的区别之一就是可观测性。每跑一次都能得到一条完整的执行轨迹起始节点、每个节点的尝试次数、状态字段变化、边选择结果、耗时、终止状态。我建议至少记录这些字段run_id、node_id、attempt、event_typestart/end/error/edge、input_fields、output_fields、duration_ms、error_message。用结构化日志或表存储。后期分析失败率、定位卡点、评估模型节点质量都依赖这份数据。没有这份日志图化只完成了“能跑”还没完成“能运维”。5. 排查链路图跑得不顺先查哪几层图化流程出问题时最忌讳直接改 prompt 或调参数。我习惯按下面的顺序排查排查层看什么常见问题现象层卡住、循环、无输出、走错分支、结果格式错误确定是哪个节点出的问题输入与状态层节点输入字段是否齐全、值是否符合预期上游节点没写字段、字段被覆盖、状态类型不一致边条件层条件表达式、阈值、比较逻辑条件写错、字段名不匹配、边界值处理遗漏节点实现层模型节点 prompt、工具节点接口、超时配置prompt 指令不聚焦、工具报错、超时设置过短引擎与参数层重试次数、全局步数限制、并发设置、依赖版本死循环、重试过于频繁、并发下状态写入冲突这个顺序的核心逻辑是先确定问题在哪一层再决定修哪里。很多图流程问题看起来像是“模型理解错了”实际是上游字段没传过来或者边条件里字段名写错模型根本拿不到判断依据。有一个经验值得分享所有节点输入输出字段用统一的命名规范比如 snake_case 或 camelCase边条件里不要频繁做类型转换让状态里保存的值从写入到读取保持一致的类型。否则会出现“字符型的 10000”和“数字型的 10000”比较不相等这种低级但难查的问题。注意节点报错不等于模型不行。先看错误类型再看是工具超时、格式解析失败还是模型输出非法 JSON。三种情况的处理方式完全不同。6. 适用边界不是所有 Agent 任务都适合画成图6.1 适合图化的流程稳定、可重复、有明确检查点判断一个 SOP 是否适合图化我用三个标准流程是否稳定同样的输入处理步骤基本一致不会每次需求都变。是否可重复这个流程会被反复执行值得投入成本做工程化。是否有明确检查点每个环节的产出可以被验证或者至少可以被明确判断是否继续。符合这三条的典型如客服工单处理、内容审核、订单异常处理、运维告警响应、常规报表生成。这类流程的收益逻辑是每次执行都能复用同一套编排并逐步积累优化数据。6.2 不适合图化的开放式探索、需求频繁漂移图化本身有成本。画图、定义状态、写边条件、搭日志都需要时间。如果一个任务属于开放式探索比如“帮我想一个营销方案”或者需求每天都在变比如“今天这样明天那样”强行图化反而会拖慢节奏。这类任务更适合让 Agent 以较自由的循环方式执行模型自己规划步骤、自己调用工具、根据结果调整策略。虽然可控性弱一些但灵活性和探索能力更强。还有一个容易被忽略的边界团队规模。如果只有一个人维护任务量也不大用一套轻量的脚本加提示词可能就够。图化是工程手段不是万能手段。它的价值需要一定的任务重复量来摊薄。6.3 从图到工作流资产版本化、测试与复用图化 SOP 带来的长期价值是流程本身变成了一种可版本化的资产。过去的 SOP 是一份文档改一次要重新同步所有人现在的 SOP 是一份配置或代码可以进版本库可以打 tag可以写单元测试。每次修改都有记录每次优化都能对比前后的执行结果。之前那个客服工单流程后来我们把风险判断条件调了三次每次都是改一个边条件跑回归样本验证再灰度上线。如果团队里有多条业务线这套经验还能抽象成公共模板信息提取节点做通用版本人工审核节点做通用版本不同业务线只替换边条件和节点 prompt。这才是 Graph Engineering 真正值得长期投入的地方它把一个岗位的 SOP变成了一台可以每天反复运行、不断改进的机器。回到最开始那句话把 Agent 的 SOP 画成 graph它就能自己跑。这句话的准确理解是把“靠模型临场理解流程”改成“靠图结构保证流程、靠模型完成节点任务”。图是人的业务逻辑模型是节点的执行者日志是迭代的依据。三者各司其职这套流程才真正从“能跑”走向“能长期跑”。如果你手头正有一份靠长 prompt 维护的 SOP我建议下个迭代先别急着调提示词试着把它画成一张图用三条真实数据跑一遍体会一下区别在哪里。