最近这两年被问得最多的一个技术方向就是Agent但聊得越深越发现很多人对Agent的理解其实还停留在“让模型自己跑”的层面。真正到了生产环境纯Agent方案很容易翻车——模型突然开始自由发挥、流程跑到一半失去上下文、该校验的数据没有校验最后得到一个“看上去很聪明但根本不敢上线”的系统。我自己的体会是能把Agent用好的核心恰恰不在于Agent本身而在于怎么把它和Workflow融合起来。这两者本质上是同一个问题的两面Agent负责不确定性Workflow负责确定性把它们编排成一个整体才是真正意义上的Agentic系统。这篇文章我会从一个实际项目出发把我自己搭过、上线过、踩过坑的这套融合方案完整拆开讲清楚。1. Agent与Workflow到底差在哪里一个被说烂了但没人讲透的话题1.1 先扔掉那些包装词用“实习生”和“SOP”理解Agent很多人一听到Agent就想到自主决策、自我进化、多智能体协作这类看起来很酷的东西但落到工程上你想要的其实就是一个能做判断、能调用工具、能完成不确定任务的程序模块。我把Agent理解成一位能力很强但需要盯着的实习生他理解任务快遇到没见过的状况能自己想办法但你没法保证他每次都严格按照你的规范走完流程。他会突然发挥创造力那对写文案来说是好事对扣款、发通知、改配置这种场景就是灾难。Workflow正好相反它是一套写死的SOP每一步做什么、做完到哪一步、不合格怎么办全部提前定好。好的一面是稳定、可控、能审计坏的一面是太僵硬一旦输入稍微偏离预期整个流程就卡死或者给出错误结果。1.2 纯Agent和纯Workflow各自的“死穴”先看纯Agent。它的最大问题不是能力不够而是不可预测。我用过一个早期版本的系统让Agent全权处理一个数据分析任务结果它在某个分支里反复调用同一个查询工具把自己绕进了死循环最后还是靠人肉干预才停下来。另一个常见问题是模型幻觉它会在没有数据支撑的情况下一本正经地“脑补”出一个执行结果而且看起来没有任何破绽。再来看纯Workflow。只要输入格式是固定的、规则是明确的它跑一万次都不会出问题。但一旦遇到需要语义理解、需要权衡取舍的场景它就彻底抓瞎。比如判断一封售后邮件属于“退款纠纷”还是“恶意投诉”光靠关键词匹配根本做不准这种问题只有模型能解决。1.3 融合的本质把自由裁量权关进笼子里所以这两者不是替代关系而是互补。融合的核心思路是把整个业务流程拆分成一个个明确的步骤绝大部分步骤继续用确定性代码执行只在真正需要模型判断的环节才把控制权交出来。打个比方Agent就像开车的人Workflow就是导航路线和交通规则。你可以让司机在某些路段自己选择变道时机但不能让他决定“今天不走高速改走国道”。一个成熟的Agentic系统应该是在严密的轨道约束下给模型留出有限的、可控的决策空间。2. 架构设计的心法什么时候用Workflow什么时候交给Agent2.1 任务拆解先把流程里“确定”和“不确定”的部分切开这是我做任何Agentic系统的第一步把任务描述写下来然后逐行标注它是“固定的”还是“需要判断的”。固定步骤归Workflow需要判断的节点才是Agent的候选位置。以一个智能工单系统为例。一张工单进来先要做身份校验这是固定的然后判断工单内容属于哪个类别这是需要语义理解的接下来根据类别走不同处理分支分支本身是固定的但如果某个分支里知识库匹配置信度太低又要由模型决定是转人工还是继续追问用户。拆完之后你会发现真正需要Agent的节点其实很少通常只占整个流程的20%左右。其他80%都是确定性逻辑完全不需要模型参与。2.2 一个判断标准三秒内决定用谁我平时给团队定的标准很简单一条规则就够如果这个步骤的输入和输出都是结构化数据、逻辑可以由正则表达式或代码描述那就用Workflow如果输入是非结构化的自然语言、输出是弹性结果比如分类、摘要、决策理由那就用Agent。更直接一点说Agent节点访问的是“语义空间”Workflow节点访问的是“逻辑空间”。你在设计的时候只需要问一个问题这一步需要“理解”还是需要“执行”理解用Agent执行用Workflow。2.3 边界条件处理模型负责开脑洞代码负责兜底还有一个容易被忽略的设计原则Agent可以做决策但不能决定流程边界。流程中最大的节点是什么、总共可以走多少步、哪些操作禁止执行这些必须写死在代码里。我习惯把Agent节点的输出规范成严格的结构化JSON如意图、参数、置信度、备选方案。代码拿到这个JSON后只做两件事判断是否合法然后路由到对应分支。模型永远不直接触碰真实系统它只负责输出“我想怎么做”真正操作系统的还是原有那一层稳定代码。3. 核心实现从零搭一个Agent-Workflow融合引擎骨架3.1 抽象层设计节点、状态、路由动手写代码之前先定三个核心抽象节点Node、状态State、路由Router。节点是流程里的一个执行单元状态是一个贯穿整个流程的数据载体包含当前步骤、已收集的信息、执行结果路由决定当前节点执行完毕后下一步去哪。这个思路和状态机的本质是一样的只不过每个节点内部允许调用模型。下面这段Python代码展示了最基础的抽象定义from dataclasses import dataclass, field from typing import Any, Callable, Optional dataclass class State: data: dict field(default_factorydict) current_node: str history: list field(default_factorylist) class Node: def __init__(self, name: str, handler: Callable[[State], dict]): self.name name self.handler handler self.next_nodes [] # 允许配置多个出口 def run(self, state: State) - str: # 每个节点执行后返回下一个节点的名称 result self.handler(state) state.history.append(self.name) # 从 result 中解析出目标和要写入 state 的数据 target result.get(next, END) updates result.get(data, {}) state.data.update(updates) return target这个框架极其简单但它已经能支撑起整套融合逻辑。每个节点只做一件事处理当前的State返回下一步要去哪、有什么数据要写回。Agent节点和非Agent节点在这个抽象下没有任何区别模型只是节点内部的一种特殊处理器。3.2 Workflow引擎用一张有向图串起所有步骤节点定义好了之后还需要一个能够把它们串起来执行的引擎。执行逻辑本身不复杂从START节点进入拿到节点返回的目标跳转到对应节点直到碰到END或者超过最大步数。class WorkflowEngine: def __init__(self, nodes: dict[str, Node]): self.nodes nodes def run(self, start_state: State, max_steps: int 50) - State: state start_state steps 0 while state.current_node ! END and steps max_steps: if state.current_node not in self.nodes: raise ValueError(f未找到节点: {state.current_node}) node self.nodes[state.current_node] next_node node.run(state) state.current_node next_node steps 1 return state这里面的max_steps参数特别关键它是我踩坑之后加进来的。早期版本没有这个限制结果Agent节点在极端情况下会反复跳转直接把流程跑挂。现在所有线上系统都强制配置最大步数超过后直接抛给重试机制处理。引擎本身不关心某个节点是模型还是纯代码这个设计让整个系统保持简单新加一个功能只需要注册新节点。3.3 Agent节点让模型在“划好的跑道”里做判断接下来是最核心的部分怎么把Agent塞进这个框架里。我的做法是写一个通用的模型决策节点它的输入是当前State的全部关键信息输出是一个固定结构的JSON相当于“在划好的跑道里做判断”。下面是一个工单分类节点的实现示例def classify_ticket(state: State) - dict: ticket_text state.data[ticket_content] prompt f 你是一个工单分类器。 请从以下类别中选择一个技术咨询、账号问题、投诉退款、建议反馈。 严格要求只输出JSON格式如下 {{intent: 类别, confidence: 0.0-1.0, reason: 判断理由}} 工单内容{ticket_text} response call_llm(prompt, max_tokens100) parsed json.loads(response) confidence parsed.get(confidence, 0.0) if confidence 0.6: # 置信度过低转人工而不是硬着头皮分类 return {next: HUMAN_REVIEW, data: {low_confidence: True}} if parsed[intent] 投诉退款: return {next: REFUND_BRANCH, data: {intent: parsed[intent]}} # 其他情况继续走常规分支 return {next: STANDARD_BRANCH, data: {intent: parsed[intent]}}这个节点的关键点是模型只负责输出意图和置信度代码负责判断置信度够不够、往哪个分支走。遇到低置信度的情况宁可转人工也不让模型继续硬猜这个兜底逻辑比模型本身的能力更值钱。3.4 状态的可视化追踪观测量是这套系统的生命线因为整个执行过程被拆成了多个节点查问题的时候必须能完整还原每一步发生了什么。我在State里加了一个history字段每次节点运行都会记录节点名、输入、输出、耗时最后落到日志里。一段节选的日志输出大致长这样time2024-05-20 10:23:01 nodeRECEIVE_TICKET evententer time2024-05-20 10:23:02 nodeRECEIVE_TICKET eventexit nextCLASSIFY_TICKET time2024-05-20 10:23:05 nodeCLASSIFY_TICKET eventllm_call cost0.012 time2024-05-20 10:23:06 nodeCLASSIFY_TICKET eventexit nextREFUND_BRANCH运行完一个工单就能清楚看到模型在哪一步被调用、花了多少钱、做了什么决策。这个能力在排障时比任何文档都有用。4. 完整实战一个智能工单系统的Agentic改造全过程4.1 原始流程的痛点为什么固定流程跑不通我接手这个工单改造项目时原系统用的是一套纯规则流程。身份校验后直接按关键词分类“退款”出现就是退款“发票”出现就是发票然后走对应处理分支。听起来很合理实际上体验很差。因为自然语言表达千变万化用户写的是“这笔钱怎么还没到我账上”没有“退款”这个关键词系统就会把工单分到“其他”类然后永远没人处理。还有一类是“我要骂你们客服这个产品坏了三次”系统只匹配到“投诉”就自动触发道歉模板但用户真正的诉求是换货。规则系统处理不了这种“话里有话”的场景。改造的目标很简单保留原本所有稳定的链路逻辑只把“分类”和“异常判断”这两个环节替换成Agent节点。4.2 改造后的流程图固定步骤还是固定步骤关键节点变了改造后的流程依然是标准的分步结构接收工单 - 身份校验 - 意图识别 - 路由分支 - 分支内处理 - 质检 - 归档。变化只发生在这三个位置意图识别节点从关键词匹配换成模型分类输出结构化意图和置信度。分支内处理时如果遇到“退货申请但理由复杂”这种需要综合判断的情况由Agent决定是自动审批还是转人工。质检节点让模型通读整条处理链路判断结果是否符合规范输出通过或不通过。其他所有步骤比如身份校验、权限判断、数据更新、通知发送全部保持原有代码没有为“智能”而改造。4.3 注册节点组装完整工作流节点写好后组装成一个可运行的Workflow只需要把节点注册进引擎。下面是工单系统关键部分的组装代码engine WorkflowEngine(nodes{ RECEIVE_TICKET: Node(RECEIVE_TICKET, receive_ticket), VERIFY_USER: Node(VERIFY_USER, verify_user), CLASSIFY_TICKET: Node(CLASSIFY_TICKET, classify_ticket), STANDARD_BRANCH: Node(STANDARD_BRANCH, standard_branch_handler), REFUND_BRANCH: Node(REFUND_BRANCH, refund_branch_handler), HUMAN_REVIEW: Node(HUMAN_REVIEW, human_review_handler), QUALITY_CHECK: Node(QUALITY_CHECK, quality_check), ARCHIVE: Node(ARCHIVE, archive_ticket), }) state State(data{ticket_content: 我买了三天就坏了能不能直接换一个新的}) state.current_node RECEIVE_TICKET final_state engine.run(state, max_steps20)整个系统改造完原先那些分错类的工单明显减少了。更重要的是当某个工单被模型判断为低置信度时它会自动进入HUMAN_REVIEW节点由人工接手而不是被规则系统强行处理到底。4.4 这个过程中必须守住的三个设计底线第一个底线模型永远不能直接改数据库。所有Agent输出都会被解析成操作请求请求再经过代码校验后才真正执行。哪怕模型判断出错最多是路由走偏不会造成实质性的数据破坏。第二个底线必须有低置信度逃生通道。我做每个Agent节点都会配一个兜底分支只要你做的分类置信度低于阈值就默认走人工或者走保守策略。永远不要在关键路径上让模型“不得不做决定”。第三个底线所有Agent调用都要有成本开关。每调一次模型都是真金白银所以线上系统里我只在语义理解必需的节点上启用Agent那些能用规则解决的绝不浪费一次调用。5. 融合系统的可靠性治理让你的Agent从“能跑”到“敢上线”5.1 超时、重试和熔断为模型节点加上“熔断器”模型接口的响应时间天然不稳定高峰期可能从几百毫秒飙到几十秒。生产系统里不可能一直傻等所以我把每个Agent节点的超时时间设为15秒超过后触发重试重试两次仍然失败就熔断到兜底规则分支。这个兜底分支可能不够智能但它至少保证系统不会因为模型接口挂了就整体瘫痪。见过不少团队把Agent封装成同步调用模型上游一抖整个业务链路跟着抖这属于典型的架构设计失误。5.2 可观测性是调试Agent的唯一救命稻草传统系统出了问题可以靠日志堆栈快速定位Agent系统因为引入了不可控的模型输出问题排查难度翻倍。一个工单没有正确分类你根本不知道是模型理解错了还是路由节点匹配错了又或者是上游状态传丢了。所以State的history字段不只是记录节点顺序还要记录进入节点时的完整上下文快照。我在每个Agent节点调用前会把相关的状态字段、模型输入的prompt、原始返回结果全部落盘。排查时直接回放现场一步不差。5.3 成本控制把大模型调用当成“按次付费的API账单”来管每个Agent节点吞掉的token都是成本如果流程设计不当一个工单处理下来光调用模型可能就要花掉几十次。我处理这个问题有四个笨办法能用小模型完成的分类绝不用大模型。相同输入的判断结果做缓存比如用户ID加上工单分类组合键。模型调用全部走异步批处理能合并的请求合并发。每个Agent节点设置单日调用上限超过直接转人工。这些做法看着简单但能把成本压到一个可接受的范围。很多Agent项目到最后不是效果不行而是账单先撑不住了。5.4 安全边界Agent可以聪明但不能越权模型本身没有安全意识它对工具的调用逻辑完全依赖prompt约束所以安全不能指望模型的自觉。我把Agent的能力边界做了一次严格的收口模型只能输出结构化意图实际能操作的对象极窄比如某个工单的状态、某条备注的内容无法访问其他用户的私有数据无法执行管理接口。这话说起来像老生常谈但真实系统里模型其实只该做“嘴”不该做“手”。所有真正执行的动作都必须回到受控的、有权限校验的代码层。6. 常见问题排查与避坑速查表我把实际调试过程中遇到过的高频问题整理成了一个速查表方便遇到同类情况直接对照排查。现象可能原因排查方法与解法Agent流程进入了死循环反复执行同一个节点路由逻辑在低置信度分支上形成了闭环检查所有节点出口是否覆盖了全部情形强制开启max_steps限制模型输出JSON解析经常失败prompt约束不严格模型自行发挥在prompt中给出完整JSON示例并把解析失败重试次数设置为2某个分支永远走不到前置节点输出格式和路由节点期望不匹配打印State历史确认数据流经过的每个节点是否更新了预期的键线上成本忽然暴涨缓存没生效重复调用了模型核查缓存key设计确认是否混入了用户ID等不可复用参数系统一上线就出现幻觉数据入库Agent节点输出直接被业务代码信任强制模型输出经过一层校验代码所有写入动作必须显式映射为白名单字段并发场景下State数据混乱同一个State对象被多个请求共享确认每个流程实例都创建了独立的State禁止全局复用转人工的工单占比过高置信度阈值设得太保守下调阈值同时分析被判定低置信度的样本确认是否存在prompt表达不清的情况这里面最值得重视的是死循环和幻觉数据两个问题。死循环直接拖垮性能幻觉数据则是悄无声息地污染业务数据两者都是在生产环境才暴露且定位难度极大。我最开始做那套系统的时候两条坑都踩遍了后来才总结出上面这张表。7. 从这套系统里悟到的三个额外经验第一不要一上来就做多智能体协作。很多团队看到Agent火了直接设计四五个Agent互相聊天的系统最后整个系统的行为变成一个黑盒。我建议先从单个Agent节点加工作流开始跑通之后再考虑扩展。第二模型的能力边界要提前摸底。同样一个分类任务有的模型输出稳定有的模型一直都在“创作”。我在接入前会准备至少500条历史数据做一次离线评测看它在真实分布上的准确率和失败模式再决定把它放在什么位置、配多大阈值。第三这个架构的扩展性远比想象中好。那套工单引擎后来被复用到好几个不同场景每次只改节点实现和一些分支条件就行引擎本身和状态管理半年没动过。这让我更确信把流程编排和模型能力解耦才是Agentic系统能长期演进的关键。最后分享一个习惯每新增一个Agent节点前我会先写一个极其详细的prompt草稿然后把它“降级”成规则逻辑看看能不能用代码硬写出来。如果硬写可以就不需要Agent。这个看似反效率的习惯帮我砍掉了至少一半毫无必要的模型调用。
最近这两年被问得最多的一个技术方向就是Agent但聊得越深越发现很多人对Agent的理解其实还停留在“让模型自己跑”的层面。真正到了生产环境纯Agent方案很容易翻车——模型突然开始自由发挥、流程跑到一半失去上下文、该校验的数据没有校验最后得到一个“看上去很聪明但根本不敢上线”的系统。我自己的体会是能把Agent用好的核心恰恰不在于Agent本身而在于怎么把它和Workflow融合起来。这两者本质上是同一个问题的两面Agent负责不确定性Workflow负责确定性把它们编排成一个整体才是真正意义上的Agentic系统。这篇文章我会从一个实际项目出发把我自己搭过、上线过、踩过坑的这套融合方案完整拆开讲清楚。1. Agent与Workflow到底差在哪里一个被说烂了但没人讲透的话题1.1 先扔掉那些包装词用“实习生”和“SOP”理解Agent很多人一听到Agent就想到自主决策、自我进化、多智能体协作这类看起来很酷的东西但落到工程上你想要的其实就是一个能做判断、能调用工具、能完成不确定任务的程序模块。我把Agent理解成一位能力很强但需要盯着的实习生他理解任务快遇到没见过的状况能自己想办法但你没法保证他每次都严格按照你的规范走完流程。他会突然发挥创造力那对写文案来说是好事对扣款、发通知、改配置这种场景就是灾难。Workflow正好相反它是一套写死的SOP每一步做什么、做完到哪一步、不合格怎么办全部提前定好。好的一面是稳定、可控、能审计坏的一面是太僵硬一旦输入稍微偏离预期整个流程就卡死或者给出错误结果。1.2 纯Agent和纯Workflow各自的“死穴”先看纯Agent。它的最大问题不是能力不够而是不可预测。我用过一个早期版本的系统让Agent全权处理一个数据分析任务结果它在某个分支里反复调用同一个查询工具把自己绕进了死循环最后还是靠人肉干预才停下来。另一个常见问题是模型幻觉它会在没有数据支撑的情况下一本正经地“脑补”出一个执行结果而且看起来没有任何破绽。再来看纯Workflow。只要输入格式是固定的、规则是明确的它跑一万次都不会出问题。但一旦遇到需要语义理解、需要权衡取舍的场景它就彻底抓瞎。比如判断一封售后邮件属于“退款纠纷”还是“恶意投诉”光靠关键词匹配根本做不准这种问题只有模型能解决。1.3 融合的本质把自由裁量权关进笼子里所以这两者不是替代关系而是互补。融合的核心思路是把整个业务流程拆分成一个个明确的步骤绝大部分步骤继续用确定性代码执行只在真正需要模型判断的环节才把控制权交出来。打个比方Agent就像开车的人Workflow就是导航路线和交通规则。你可以让司机在某些路段自己选择变道时机但不能让他决定“今天不走高速改走国道”。一个成熟的Agentic系统应该是在严密的轨道约束下给模型留出有限的、可控的决策空间。2. 架构设计的心法什么时候用Workflow什么时候交给Agent2.1 任务拆解先把流程里“确定”和“不确定”的部分切开这是我做任何Agentic系统的第一步把任务描述写下来然后逐行标注它是“固定的”还是“需要判断的”。固定步骤归Workflow需要判断的节点才是Agent的候选位置。以一个智能工单系统为例。一张工单进来先要做身份校验这是固定的然后判断工单内容属于哪个类别这是需要语义理解的接下来根据类别走不同处理分支分支本身是固定的但如果某个分支里知识库匹配置信度太低又要由模型决定是转人工还是继续追问用户。拆完之后你会发现真正需要Agent的节点其实很少通常只占整个流程的20%左右。其他80%都是确定性逻辑完全不需要模型参与。2.2 一个判断标准三秒内决定用谁我平时给团队定的标准很简单一条规则就够如果这个步骤的输入和输出都是结构化数据、逻辑可以由正则表达式或代码描述那就用Workflow如果输入是非结构化的自然语言、输出是弹性结果比如分类、摘要、决策理由那就用Agent。更直接一点说Agent节点访问的是“语义空间”Workflow节点访问的是“逻辑空间”。你在设计的时候只需要问一个问题这一步需要“理解”还是需要“执行”理解用Agent执行用Workflow。2.3 边界条件处理模型负责开脑洞代码负责兜底还有一个容易被忽略的设计原则Agent可以做决策但不能决定流程边界。流程中最大的节点是什么、总共可以走多少步、哪些操作禁止执行这些必须写死在代码里。我习惯把Agent节点的输出规范成严格的结构化JSON如意图、参数、置信度、备选方案。代码拿到这个JSON后只做两件事判断是否合法然后路由到对应分支。模型永远不直接触碰真实系统它只负责输出“我想怎么做”真正操作系统的还是原有那一层稳定代码。3. 核心实现从零搭一个Agent-Workflow融合引擎骨架3.1 抽象层设计节点、状态、路由动手写代码之前先定三个核心抽象节点Node、状态State、路由Router。节点是流程里的一个执行单元状态是一个贯穿整个流程的数据载体包含当前步骤、已收集的信息、执行结果路由决定当前节点执行完毕后下一步去哪。这个思路和状态机的本质是一样的只不过每个节点内部允许调用模型。下面这段Python代码展示了最基础的抽象定义from dataclasses import dataclass, field from typing import Any, Callable, Optional dataclass class State: data: dict field(default_factorydict) current_node: str history: list field(default_factorylist) class Node: def __init__(self, name: str, handler: Callable[[State], dict]): self.name name self.handler handler self.next_nodes [] # 允许配置多个出口 def run(self, state: State) - str: # 每个节点执行后返回下一个节点的名称 result self.handler(state) state.history.append(self.name) # 从 result 中解析出目标和要写入 state 的数据 target result.get(next, END) updates result.get(data, {}) state.data.update(updates) return target这个框架极其简单但它已经能支撑起整套融合逻辑。每个节点只做一件事处理当前的State返回下一步要去哪、有什么数据要写回。Agent节点和非Agent节点在这个抽象下没有任何区别模型只是节点内部的一种特殊处理器。3.2 Workflow引擎用一张有向图串起所有步骤节点定义好了之后还需要一个能够把它们串起来执行的引擎。执行逻辑本身不复杂从START节点进入拿到节点返回的目标跳转到对应节点直到碰到END或者超过最大步数。class WorkflowEngine: def __init__(self, nodes: dict[str, Node]): self.nodes nodes def run(self, start_state: State, max_steps: int 50) - State: state start_state steps 0 while state.current_node ! END and steps max_steps: if state.current_node not in self.nodes: raise ValueError(f未找到节点: {state.current_node}) node self.nodes[state.current_node] next_node node.run(state) state.current_node next_node steps 1 return state这里面的max_steps参数特别关键它是我踩坑之后加进来的。早期版本没有这个限制结果Agent节点在极端情况下会反复跳转直接把流程跑挂。现在所有线上系统都强制配置最大步数超过后直接抛给重试机制处理。引擎本身不关心某个节点是模型还是纯代码这个设计让整个系统保持简单新加一个功能只需要注册新节点。3.3 Agent节点让模型在“划好的跑道”里做判断接下来是最核心的部分怎么把Agent塞进这个框架里。我的做法是写一个通用的模型决策节点它的输入是当前State的全部关键信息输出是一个固定结构的JSON相当于“在划好的跑道里做判断”。下面是一个工单分类节点的实现示例def classify_ticket(state: State) - dict: ticket_text state.data[ticket_content] prompt f 你是一个工单分类器。 请从以下类别中选择一个技术咨询、账号问题、投诉退款、建议反馈。 严格要求只输出JSON格式如下 {{intent: 类别, confidence: 0.0-1.0, reason: 判断理由}} 工单内容{ticket_text} response call_llm(prompt, max_tokens100) parsed json.loads(response) confidence parsed.get(confidence, 0.0) if confidence 0.6: # 置信度过低转人工而不是硬着头皮分类 return {next: HUMAN_REVIEW, data: {low_confidence: True}} if parsed[intent] 投诉退款: return {next: REFUND_BRANCH, data: {intent: parsed[intent]}} # 其他情况继续走常规分支 return {next: STANDARD_BRANCH, data: {intent: parsed[intent]}}这个节点的关键点是模型只负责输出意图和置信度代码负责判断置信度够不够、往哪个分支走。遇到低置信度的情况宁可转人工也不让模型继续硬猜这个兜底逻辑比模型本身的能力更值钱。3.4 状态的可视化追踪观测量是这套系统的生命线因为整个执行过程被拆成了多个节点查问题的时候必须能完整还原每一步发生了什么。我在State里加了一个history字段每次节点运行都会记录节点名、输入、输出、耗时最后落到日志里。一段节选的日志输出大致长这样time2024-05-20 10:23:01 nodeRECEIVE_TICKET evententer time2024-05-20 10:23:02 nodeRECEIVE_TICKET eventexit nextCLASSIFY_TICKET time2024-05-20 10:23:05 nodeCLASSIFY_TICKET eventllm_call cost0.012 time2024-05-20 10:23:06 nodeCLASSIFY_TICKET eventexit nextREFUND_BRANCH运行完一个工单就能清楚看到模型在哪一步被调用、花了多少钱、做了什么决策。这个能力在排障时比任何文档都有用。4. 完整实战一个智能工单系统的Agentic改造全过程4.1 原始流程的痛点为什么固定流程跑不通我接手这个工单改造项目时原系统用的是一套纯规则流程。身份校验后直接按关键词分类“退款”出现就是退款“发票”出现就是发票然后走对应处理分支。听起来很合理实际上体验很差。因为自然语言表达千变万化用户写的是“这笔钱怎么还没到我账上”没有“退款”这个关键词系统就会把工单分到“其他”类然后永远没人处理。还有一类是“我要骂你们客服这个产品坏了三次”系统只匹配到“投诉”就自动触发道歉模板但用户真正的诉求是换货。规则系统处理不了这种“话里有话”的场景。改造的目标很简单保留原本所有稳定的链路逻辑只把“分类”和“异常判断”这两个环节替换成Agent节点。4.2 改造后的流程图固定步骤还是固定步骤关键节点变了改造后的流程依然是标准的分步结构接收工单 - 身份校验 - 意图识别 - 路由分支 - 分支内处理 - 质检 - 归档。变化只发生在这三个位置意图识别节点从关键词匹配换成模型分类输出结构化意图和置信度。分支内处理时如果遇到“退货申请但理由复杂”这种需要综合判断的情况由Agent决定是自动审批还是转人工。质检节点让模型通读整条处理链路判断结果是否符合规范输出通过或不通过。其他所有步骤比如身份校验、权限判断、数据更新、通知发送全部保持原有代码没有为“智能”而改造。4.3 注册节点组装完整工作流节点写好后组装成一个可运行的Workflow只需要把节点注册进引擎。下面是工单系统关键部分的组装代码engine WorkflowEngine(nodes{ RECEIVE_TICKET: Node(RECEIVE_TICKET, receive_ticket), VERIFY_USER: Node(VERIFY_USER, verify_user), CLASSIFY_TICKET: Node(CLASSIFY_TICKET, classify_ticket), STANDARD_BRANCH: Node(STANDARD_BRANCH, standard_branch_handler), REFUND_BRANCH: Node(REFUND_BRANCH, refund_branch_handler), HUMAN_REVIEW: Node(HUMAN_REVIEW, human_review_handler), QUALITY_CHECK: Node(QUALITY_CHECK, quality_check), ARCHIVE: Node(ARCHIVE, archive_ticket), }) state State(data{ticket_content: 我买了三天就坏了能不能直接换一个新的}) state.current_node RECEIVE_TICKET final_state engine.run(state, max_steps20)整个系统改造完原先那些分错类的工单明显减少了。更重要的是当某个工单被模型判断为低置信度时它会自动进入HUMAN_REVIEW节点由人工接手而不是被规则系统强行处理到底。4.4 这个过程中必须守住的三个设计底线第一个底线模型永远不能直接改数据库。所有Agent输出都会被解析成操作请求请求再经过代码校验后才真正执行。哪怕模型判断出错最多是路由走偏不会造成实质性的数据破坏。第二个底线必须有低置信度逃生通道。我做每个Agent节点都会配一个兜底分支只要你做的分类置信度低于阈值就默认走人工或者走保守策略。永远不要在关键路径上让模型“不得不做决定”。第三个底线所有Agent调用都要有成本开关。每调一次模型都是真金白银所以线上系统里我只在语义理解必需的节点上启用Agent那些能用规则解决的绝不浪费一次调用。5. 融合系统的可靠性治理让你的Agent从“能跑”到“敢上线”5.1 超时、重试和熔断为模型节点加上“熔断器”模型接口的响应时间天然不稳定高峰期可能从几百毫秒飙到几十秒。生产系统里不可能一直傻等所以我把每个Agent节点的超时时间设为15秒超过后触发重试重试两次仍然失败就熔断到兜底规则分支。这个兜底分支可能不够智能但它至少保证系统不会因为模型接口挂了就整体瘫痪。见过不少团队把Agent封装成同步调用模型上游一抖整个业务链路跟着抖这属于典型的架构设计失误。5.2 可观测性是调试Agent的唯一救命稻草传统系统出了问题可以靠日志堆栈快速定位Agent系统因为引入了不可控的模型输出问题排查难度翻倍。一个工单没有正确分类你根本不知道是模型理解错了还是路由节点匹配错了又或者是上游状态传丢了。所以State的history字段不只是记录节点顺序还要记录进入节点时的完整上下文快照。我在每个Agent节点调用前会把相关的状态字段、模型输入的prompt、原始返回结果全部落盘。排查时直接回放现场一步不差。5.3 成本控制把大模型调用当成“按次付费的API账单”来管每个Agent节点吞掉的token都是成本如果流程设计不当一个工单处理下来光调用模型可能就要花掉几十次。我处理这个问题有四个笨办法能用小模型完成的分类绝不用大模型。相同输入的判断结果做缓存比如用户ID加上工单分类组合键。模型调用全部走异步批处理能合并的请求合并发。每个Agent节点设置单日调用上限超过直接转人工。这些做法看着简单但能把成本压到一个可接受的范围。很多Agent项目到最后不是效果不行而是账单先撑不住了。5.4 安全边界Agent可以聪明但不能越权模型本身没有安全意识它对工具的调用逻辑完全依赖prompt约束所以安全不能指望模型的自觉。我把Agent的能力边界做了一次严格的收口模型只能输出结构化意图实际能操作的对象极窄比如某个工单的状态、某条备注的内容无法访问其他用户的私有数据无法执行管理接口。这话说起来像老生常谈但真实系统里模型其实只该做“嘴”不该做“手”。所有真正执行的动作都必须回到受控的、有权限校验的代码层。6. 常见问题排查与避坑速查表我把实际调试过程中遇到过的高频问题整理成了一个速查表方便遇到同类情况直接对照排查。现象可能原因排查方法与解法Agent流程进入了死循环反复执行同一个节点路由逻辑在低置信度分支上形成了闭环检查所有节点出口是否覆盖了全部情形强制开启max_steps限制模型输出JSON解析经常失败prompt约束不严格模型自行发挥在prompt中给出完整JSON示例并把解析失败重试次数设置为2某个分支永远走不到前置节点输出格式和路由节点期望不匹配打印State历史确认数据流经过的每个节点是否更新了预期的键线上成本忽然暴涨缓存没生效重复调用了模型核查缓存key设计确认是否混入了用户ID等不可复用参数系统一上线就出现幻觉数据入库Agent节点输出直接被业务代码信任强制模型输出经过一层校验代码所有写入动作必须显式映射为白名单字段并发场景下State数据混乱同一个State对象被多个请求共享确认每个流程实例都创建了独立的State禁止全局复用转人工的工单占比过高置信度阈值设得太保守下调阈值同时分析被判定低置信度的样本确认是否存在prompt表达不清的情况这里面最值得重视的是死循环和幻觉数据两个问题。死循环直接拖垮性能幻觉数据则是悄无声息地污染业务数据两者都是在生产环境才暴露且定位难度极大。我最开始做那套系统的时候两条坑都踩遍了后来才总结出上面这张表。7. 从这套系统里悟到的三个额外经验第一不要一上来就做多智能体协作。很多团队看到Agent火了直接设计四五个Agent互相聊天的系统最后整个系统的行为变成一个黑盒。我建议先从单个Agent节点加工作流开始跑通之后再考虑扩展。第二模型的能力边界要提前摸底。同样一个分类任务有的模型输出稳定有的模型一直都在“创作”。我在接入前会准备至少500条历史数据做一次离线评测看它在真实分布上的准确率和失败模式再决定把它放在什么位置、配多大阈值。第三这个架构的扩展性远比想象中好。那套工单引擎后来被复用到好几个不同场景每次只改节点实现和一些分支条件就行引擎本身和状态管理半年没动过。这让我更确信把流程编排和模型能力解耦才是Agentic系统能长期演进的关键。最后分享一个习惯每新增一个Agent节点前我会先写一个极其详细的prompt草稿然后把它“降级”成规则逻辑看看能不能用代码硬写出来。如果硬写可以就不需要Agent。这个看似反效率的习惯帮我砍掉了至少一半毫无必要的模型调用。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
