今年年中我给一个内部工具做了次重构起因很直接Agent 调用链越来越长调试的时候根本分不清是哪一步在胡说八道。团队一开始想上完整的可视化 Workflow 引擎被我拦下来了。以我的经验面向 Agent 的流程设计绝大多数情况下不需要重型编排框架越轻越容易看清楚问题在哪。这也是这篇内容想聊的主题——不依赖重框架怎么把一个多步骤的 Agent 任务拆成可维护、可观测、能兜底的轻量 Workflow。这里说的轻量不是少写几行代码而是指运行时逻辑足够直白每一条路径都看得见、每一种分支都说得清、每一次失败都有明确退路。适合正在做 Agent 应用、被复杂的流程状态搞得头疼或者准备从单轮 Prompt 走向多步骤自动化场景的开发者参考。我会从场景判断、最小运行时设计、路由循环取舍、可观测性、稳定性兜底几个层面展开最后给一点可复用的配置经验。1. 先分清Agent 工作流和Agent 自由行动是两条路很多团队一听到Agent就往全自主方向想——给模型一个目标让它自己规划、自己调用工具、自己决定什么时候结束。听起来很酷落地的时候却常常被现实抽耳光模型会把简单事情复杂化会捏造中间结果会在无限循环里打转。面向 Agent 的轻量 Workflow本质上是把自由行动收敛成有边界的选择这不是妥协而是工程理性。1.1 低置信度任务才值得让模型全权自主先抛一个我常用的判断标准某个环节的结果可验证程度决定了它适不适合被模型全权接管。如果任务的每一步产出都能低成本校验比如代码能跑、接口能调通、数值能比对那模型多做一些开放性探索问题不大但如果产出只能靠人眼判断或者产出错了会导致连锁损失那每一步都应该被 Workflow 约束住。我见过最典型的反面案例是让 Agent 直接操作数据库完成数据订正任务。模型选字段选错、拼错查询条件、影响行数估算离谱一系列问题接踵而至。后来改成 Workflow模型只负责解析用户意图和输出结构化指令真正的增删改操作由代码节点用白名单方式执行执行前还强制要求做一次影响行数预估确认。问题减少了八成。可见低置信度场景可以开放高申请场景一定要加控制。1.2 高确定性流程要的是把人的判断前置针对内部业务系统的自动化流程大多数步骤其实是高确定性的查库存、算价格、填单据、发通知。这些步骤里冠冕堂皇套一个大模型不但慢而且不稳定。正确做法是把模型放在两个位置入口解析和分支决策其余步骤交给确定性代码。举个例子一个客服工单自动分派流程需要从用户长句里提取用户类型、问题类别、紧急级别这一步用模型很合适但提取完成后该转给哪个组、等多久、要不要升级处理这些规则完全可以用代码写死。这样整个 Workflow 是模型负责理解代码负责执行模型出错的边界被压得很小。人要做的事情在设计阶段就前置介入定好路由规则、定好兜底策略而不是等线上出错了再人肉救火。1.3 轻量 Workflow 的本质把不可控的推理压缩到最小边界如果给面向 Agent 的轻量 Workflow 下一个定义我认为是一种将大模型推理能力嵌入到确定性流程中的编排方式保留必要弹性消灭不必要随机性。它跟纯 Agent 的最大区别是控制粒度。纯 Agent 在每次模型调用之间自己决定下一步做什么而轻量 Workflow 在设计期就把可枚举的路径画出来了模型只能在画好的路口做选择。这么做换来的三个好处可复现——同一输入跑十次流程路径基本稳定可测试——每个节点都能单独构造输入验证可审计——每一步为什么走这条分支有明确记录。代价是灵活性下降但我觉得对绝大多数商业化场景这个代价值得付。没人希望上线第二天系统自己发明了一条流程开发人员都没见过的逻辑路径。2. 我的最小运行时设计串行框架加三种分支机制有了前面的判断到了实现层面。我通常不用现成的重型流程引擎而是基于代码写一个极简的运行时。核心思路一句话流程是代码节点是函数状态挂在上下文对象上。这听起来有点像状态机 函数调用实际上就是。复杂度控制得好的话整个运行时核心只有几百行代码却足够承载大部分业务。2.1 为什么不用流程图引擎而用代码即流程很多人喜欢拖拽式的可视化流程设计器看上去很美但项目一旦进入维护期痛点全暴露复杂分支在画布上挤成一团版本 diff 难以阅读想加一个条件判断得改配置文件。而代码即流程的方式每次改动都能走代码评审每一步逻辑都允许写注释安全和质量问题有迹可循。以我的实践为例我常定义一种极简语法step()执行单个节点自动记录开始结束时间route()根据结构化条件选择后继节点foreach()对批量数据循环执行子流程try_until()带重试上限的循环适合模型自我修正场景。这套 DSL 来自不超过两百行的实现团队里新同学看半小时就能上手比学一个图形引擎的节点 API 快得多。业务逻辑是代码那调试、测试、版本管理全部复用工程体系这类收益在长期维护里会无限放大。2.2 节点基类与状态机的最小实现节点设计上我不建议把节点写成大胃王——一个节点里既调模型又查数据库又发通知那样就失去了拆分的意义。我一般定义两类节点智能节点和普通节点。智能节点内部包含一次 LLM 调用输入输出都要带 schema普通节点则是纯函数只要幂等和快。两者的公共接口一致接收上下文处理完后把结果写回上下文并返回节点状态success / fail / retry。运行时的状态机也很朴素大致是INIT - RUNNING - {SUCCESS, FAILED, NEED_HUMAN}这么一条线。不需要引入复杂的 Petri 网概念因为实际业务里我们不需要并发分叉太多。绝大多数流程都是串行加少数并行串行结构对心智负担和日志排查都友好得多。2.3 全局上下文哪些数据必须共享哪些必须隔离轻量 Workflow 最容易翻车的点是上下文对象变成一个大杂烩。所有节点往同一个字典塞数据到最后谁也不知道某个 key 是谁写的、格式是什么、能不能放心用。我的建议是一个约定上下文分层。request层只存用户原始输入和初始参数只读work层存各节点产出的中间结果按节点 ID 建命名空间避免 key 冲突meta层存 token 消耗、cost、节点耗时、重试次数用于观测。在 Python 里我用一个简单的Context类内部三个字典分别暴露只读和读写接口。这样做之后写新节点的人很清楚自己应该读写哪个区域排查问题时定位数据来源也快得多。这个习惯看着不起眼但对维护多节点的 Agent 流程帮助巨大。3. 路由、条件与循环低成本实现关键决策轻量不等于简陋路由与循环恰恰是 Workflow 的灵魂。模型在什么路口做选择、选错了怎么回头、循环迭代几次该停下来这些设计得好不好直接决定系统的可靠程度。我从三个角度分享一下思路。3.1 用结构化输出而不是提示词判断做路由早期做 Agent 路由我习惯把路由条件写在提示词里如果你是技术问题输出 tech如果是账单问题输出 billing。这种方式在大模型幻觉面前不堪一击。最离谱的一次模型把billing拼成billling导致流程走到了 unknown 分支。后来所有路由决策改成结构化输出模型不许自由输出文本必须返回一个符合 JSON Schema 的对象例如{intent: billing, confidence: 0.96, extracted_params: {...}}。代码节点再做两件事第一校验 intent 是否在预设枚举里第二判断 confidence 是否超过阈值低于阈值直接走人工确认分支。这样路由的准确率从大概八成提升到接近九成五路由错误率大幅下降。3.2 循环设计让模型只在局部迭代有些任务确实需要模型迭代比如根据报错信息反复修代码、根据用户反馈反复润色文案。但这个迭代范围必须被严控。我见过最差的设计是把整个流程包在一个大循环里模型每次发现结果不理想就从头再跑。最后不是超时就是 token 烧到人崩溃。我的做法是局部循环 全局线性。流程框架始终是有一条主线的只有某个特定节点内部允许try_until自循环。比如代码生成节点内部可以重试最多三次每次把上一次的报错信息反馈给模型但代码生成节点不会跳出到流程开头重新规划。这么设计后循环的可控性显著提升重试次数设上限超过上限便触发降级或转人工。3.3 让模型自己选择工具链的轻量策略完全由模型动态选工具风险较高把所有工具都写死又失去弹性。折中方案是预定义好策略模板模型只做模板选择。例如流程针对数据分析需求绑定了三个模板模板 A 是查库 - 聚合 - 生成图表模板 B 是查接口 - 清洗 - 对比基线 - 生成报告模板 C 是直接推理不调用外部工具。模型的任务是根据用户意图从模板列表里选一个并填充模板参数。这一层可以比作不是让厨师自由发挥做什么菜而是让厨师点菜——菜谱是固定的选哪个菜和加什么佐料由厨师定。它依然保留了适用性但不会出现模型凭空发明工具调用顺序的情况。4. 别省可观测性轻量流程的跟踪与调试很多人觉得轻量流程不复杂日志随便记一记就够了。真上线跑过就知道Agent 流程最大的坑是**非线性错误**同样的输入不同时间的输出完全不一样有时候是模型抽风有时候是上游数据结构变了。没有一套可观测体系排查一次线上故障可能耗掉一整天。轻量系统的可观测性不需要上重型 APM但要覆盖到关键信息。4.1 日志要记什么LLM调用、节点状态、上下文快照至少三类信息必须落日志LLM 调用日志模型名、请求 token、响应 token、温度、耗时、prompt 摘要、response 摘要。如果要审计合规还要把完整请求响应落存储。注意摘要可以只记前若干字符避免日志膨胀。节点执行日志节点 ID、节点类型、入参包、出参包、状态、耗时、异常堆栈。这里的关键是把每个节点的输入输出分别记录方便判断是上游传错还是本节点算错。上下文快照在关键路由节点之后把当前 work 层的关键字段快照一下。这样回溯的时候能看到分支决策那一刻系统认为的事实是什么比看一万行日志都管用。4.2 用事件流而非嵌套堆栈做追踪代码即流程的好处是天然有函数调用栈靠堆栈也能定位问题但一旦出现循环和重试堆栈里全是重复帧可读性很差。我更推荐用事件流记录执行轨迹每次节点开始、结束、失败、重试都往一个集中的事件列表追加一条事件。每个事件包含event_id, parent_event_id, node_id, event_type, timestamp, payload。这里可以让多个节点共享同一个trace_id然后靠parent_event_id表达父子关系。好处是它没有真正的层级堆栈那么刻板查问题可以平铺展开尤其适合循环场景。你可以把整个 Workflow 的执行历史当成一份时序账本来看模型某次调用温度是多少、当时上下文是什么一清二楚。4.3 十分钟搭一个不重样的链路追踪不想引入大型分布式追踪系统的话可以自己做一个迷你版本成本很低。我的做法是在流程入口生成trace_id用一个全局的collector对象接收所有事件异步刷到轻量的日志存储里。线上排查时只要拿到trace_id就能拉出整条执行链路。再做一个简单的print_trace(trace_id)调试工具把事件流按树形格式化输出开发阶段单测直接可用。这套东西我大概花了一晚上写完但它救了无数次线上排障的命。所以别觉得轻量 Workflow 就可以不做观测恰恰相反因为流程执行路径多更需要一个低成本但完整的事件日志机制。5. 稳定性和兜底轻量但绝不能裸奔说句实话面向 Agent 的流程模型调用天然不稳定如果不做分层兜底上线就是给自己找麻烦。稳定性设计应该成为 Workflow 基础设施的一部分而不是事后补救。我常把稳定性拆成三层输入输出校验、调用层保障、人工救治。5.1 Schema 校验与失败回退每个智能节点的输出必须过 Schema。做法很简单模型一返回先用校验库验证字段、类型、枚举值、必填项。一旦校验失败通常有两个处理方向格式修复或者重试一次。格式修复是把这个节点的原始输出和校验错误一并回传给模型让它自行修正如果修正后仍失败就判定节点失败走回退逻辑。回退逻辑需要提前定义好有些节点失败后整个流程终止有些可以跳过一个并不核心的步骤仅告警还有一些需要用默认值代替。一个常见场景用户意图识别节点失败你的回退策略可能是让流程进入FAQ 转人工节点而不是直接抛出 500 异常。把回退写进流程而不是靠外层 try-catch才是面向状态编排的思维。5.2 超时、重试、模型降级的三层保障模型服务的延时漂移通常巨大。哪怕同一个模型早上 200ms、下午 8 秒都算常见。轻量 Workflow 必须给每次 LLM 调用施加超时超时采用快超时 慢重试策略第一调用超时设短比如 10 秒失败后立刻重试一次带更长超时比如 30 秒第二次也失败直接转单调的确定性策略比如用关键词匹配顶替模型能力或转人工。这么一个小策略能把核心流程可用性从 90% 拉到 95% 以上。模型降级更多指的是主模型不可用时切到备用模型或降低模型规格。我的建议是只有在快速响应比效果更重要的节点才做规格降级在诊断类节点不要轻易降级因为效果差异可能导致后续节点连锁出错。降级的开关要能远程动态调整不是改代码重新发布否则运维成本很高。5.3 人工介入与版本灰度总有些场景模型搞不定比如用户要求必须退款、提供法律合同变更、问题内容极其模糊。设计 Workflow 时我会把转人工待办当作一种正常的终止节点而不是异常。它和 fail 有本质区别转人工代表流程知道自己能力边界主动移交给人类fail 代表系统不知所措。前者在企业场景里很加分后者只能换来看出问题时的焦虑感。版本灰度同样重要。流程即代码的好处是天然能用分支和发布系统控制灰度范围。我的习惯是每个 Workflow 版本带version字段运行时会记录在 meta 层灰度时把新版本流量切到 10%跑到指定调用量后观察成功率确认无异常再全量。这样即使新版路由规则或提示词有偏差影响面也被严格限定。6. 几个实际使用经验与推荐参数最后分享几个零散但实用的参数与经验全部来自实际项目踩过的坑和试出来的配置。这些数值不一定是普适最优值但作为起点能少走很多弯路按你的场景微调即可。6.1 超时与重试参数参考场景首轮超时重试次数第二轮超时熔断阈值在线意图识别10s125s连续 5 次失败文档信息抽取30s160s连续 3 次失败批量离线标签60s2120s失败率超 20%熔断触发后我的做法是直接停掉后续调用进入降级队列或人工流程。注意一点第一次调用失败未必是模型问题也许是上游参数格式变了所以重试前最好也检查一次输入数据是否完整。6.2 路由节点的温度参数设置路由节点的温度要低我一直用 0 到 0.1。温度接近 0模型输出稳定性更高虽然看似减少了灵活性但路由节点不负责创造只负责归类低温度是正确选择。生成类节点可以稍微高一点比如 0.7 到 0.9不过一旦生成内容后面还要接校验节点温度最好也降一点免得生成出格式五花八门的文本。你还可以让路由节点在低置信度时输出拒绝路由并把它当正常分支处理这比强行从两个不相关的意图里选一个更合理。这个设计看着简单却显著降低了错误路由带来的下游污染。6.3 资源占用与并发目标既然是轻量设计资源占用也要有预期。一个纯 CPU 的流式节点只做字符串处理和接口调用线程池并发 50 时单个 Worker 的内存占用控制在几十到一百多 MB 很合理。如果引入本地向量检索或本地小模型资源占用会上去但依然比你跑一个完整的重型微服务省得多。我曾把一个多步工具流程从重型服务拆成轻量编排后单机从 4C8G 降到 2C4GQPS 反而翻倍原因是减少了框架层开销和序列化损耗。这种资源收益本质上来自对该做的用加法对不该做的用减法——推理只留给真正需要的节点其他全部用确定性代码系统自然轻快。这个思路可以用一句话总结让模型做只有模型能做的事让代码做所有代码能做的事。我自己的体会是做 Agent 相关项目与其一开始就追求宏伟的自主体不如先静下心来画一画流程边界。能明确的路径分叉用 Workflow 兜住不能明确的才放开给模型系统稳定性和维护成本都会好得超出预期。愿你设计的流程跑得又稳又省电。