架构设计这事很多团队第一步就绕错了。不少朋友跟我聊Agent系统时开口就是“我该用哪个框架”“LangChain还是自研”其实框架只是表面问题真正决定系统上限的是你把Agent工作流编排成什么形状。今天这篇我把Agent工作流里三种最核心的架构模式掰开揉碎讲一遍——增强型、链式、路由式从设计思路到落地的关键细节再到我实操中踩过的一系列坑全部摊开说。先泼一盆冷水如果你把Agent当成一个“万能黑盒节点”所有任务一股脑塞进去让它自由发挥那你大概率会在交付前夜被不稳定的输出折腾到崩溃。Agent本身是模型模型天然带随机性工作流设计的第一价值就是用结构去约束随机性。三种架构不是谁替代谁的关系而是像积木一样可以组合嵌套的关系。搞懂它们各自解决什么问题、擅长什么场景、有哪些致命缺陷你才能像搭积木一样搭出稳定可控的系统。这篇文章适合正在做Agent应用落地的开发者、技术负责人也适合刚接触LLM应用架构、想建立全局认知的同学。1. 三种Agent工作流架构到底在解决什么问题1.1 单节点Agent的失控与低效先聊一个最常见的原始形态一个Prompt一个Agent自动决定做什么、用什么工具、输出什么。听起来很美好但现实中这种“自由Agent”很容易变成“失控Agent”原因有三个层面。一是输出不稳定。模型每次推理都有概率偏差同一种语义的表达方式可能完全不同直接导致下游解析程序没法稳定工作。二是上下文失管。自由Agent调用工具时每轮工具结果都往上下文里塞多轮下来上下文膨胀模型开始遗忘早期关键信息幻觉率直线上升。三是效率低下。一个复杂任务比如“查一个客户的历史订单并生成售后处理建议”如果让单个Agent从零自由发挥它可能花大量tokens在自我对话上编排步骤不固定响应时间和成本双双失控。这里有个很好的生活类比把整个餐厅后厨交给一个大厨让他一个人决定配菜、炒菜、摆盘、上菜顺序。遇到熟客家常菜没问题但一到高峰期菜品一多这个大厨就开始手忙脚乱出品质量大打折扣。工作流架构本质上就是给后厨划分工位切配归切配热炒归热炒传菜归传菜——用明确的职责边界去替代“一个人扛所有事”的不确定性。1.2 三种架构的定义与选型边界增强型架构Augmented Workflow核心是“让单个Agent变强”。在Agent外层包裹上下文检索、记忆管理、工具注册、结果校验等一系列机制。模型还是那个模型但外围设备让它不裸奔。典型形态像RAG应用Agent在回答前会先检索知识库把相关内容作为上下文注入再让模型生成答案。增强型的价值在于就近解决“单点能力不足”实施成本相对低对现有系统改造小。链式架构Sequential Chaining / Pipeline核心是“把一个大任务拆成多个子Agent接力”。上一个Agent的输出解析、过滤后作为下一个Agent的输入。典型场景是信息提取流水线原始文档先交给Agent A做要素抽取抽出的结构化数据交给Agent B做分类打标签再交给Agent C生成摘要报告。每级只做一件事输入输出有明确接口约束问题定位起来非常方便。路由式架构Routing Workflow核心是“先分类、再分派”。一个入口路由Agent接收用户请求判断任务类型把请求转发给不同的下游Agent或固定流程。典型形态是智能客服系统的主入口用户问“我的订单怎么还没到”——路由到订单查询流程用户骂“你们产品质量有问题”——路由到售后维权流程。路由式架构擅长处理意图分支明确的场景能把不同类型的任务隔离到各自的处理流程中避免“一个Agent干所有活”带来的指令冲突。选型边界其实挺清晰的我归纳成一张表架构类型核心目标适合场景落地复杂度典型风险增强型提升单Agent能力问答、代码辅助、知识密集型任务低上下文成本高、检索质量不稳链式稳定流水线、可定位信息提取、内容生成、多步处理中错误传播、前级输出影响后级路由式意图分流、任务隔离多业务入口、客服、门户型系统中高分类错误、边界模糊导致分发失败1.3 为什么选型比写代码更重要我在一些项目里见过一句话式的技术决策“先跑通再说后面优化”。这句话在MVP阶段没问题但到了Agent系统这里很容易变成灾难。因为Agent工作流的改型成本不是改一段代码而是整个链路的数据形态、上下文策略、运维观测体系全部推倒重来。举个例子某团队一开始做了个增强型Agent所有任务都在一个大Agent里完成。后来业务方提出要支持“先提取用户意图再分流到不同处理流程”团队被迫在现有大Agent外面套路由层但原来大Agent里塞满了各种业务prompt互相干扰最后不得不拆成多个小Agent重新编排。估算下来重构工时是当初“先跑通”版本的3倍不止。所以我有个习惯动工前先花半天把“任务类型清单”列出来。数一数系统到底有多少种不同的用户意图、多少种上游输入、多少种下游输出。如果不超过两种类型增强型就够了如果超过五种且有明确的分支条件路由式不可避免如果任务本身是一条明确的生产线比如“解析、分类、摘要、入库”链式才是正确选择。选型错了后面每一步都是在还债。2. 架构设计的核心细节与关键参数2.1 协议先行三种架构共同的基础聊任何架构细节之前必须先说“协议”。这个词听起来硬核实际含义就是你系统里传递的数据长什么样必须提前定死。很多Agent系统崩就崩在这里——Agent A输出的字段叫“summary”Agent B期待的字段叫“result”两边对不上链式架构直接断链路由式架构直接分错类。我在实操中会把每个Agent之间的消息体统一成三层结构第一层meta放消息ID、产生时间、来源Agent标识、链路追踪ID。这层负责运维观测排查问题全靠它。第二层payload放业务主数据。比如工单标题、用户描述、历史订单列表。第三层context放链路内的临时状态。比如处理进度、已执行步骤、路由决策依据。再来一个版本号字段描述这套结构的schema版本。这样后面要加字段老的处理节点看到版本不匹配可以走降级逻辑而不是直接解析报错。整体结构类似这样{ version: 1.2, meta: { message_id: msg_8f3a..., created_at: 2024-05-12T10:30:00Z, source_node: router, trace_id: trace_0f2e... }, payload: { ticket_id: TKT-20240512-001, user_message: 我的订单三天没更新物流了, user_id: U-10086, order_ids: [ORD-20240501-A] }, context: { route_decision: logistics_query, route_confidence: 0.87, attempts: 0 } }这个契约一旦确定三种架构的拼装就变得非常顺滑。路由式看context.route_decision链式处理payload里的业务数据增强型Agent只用关心payload和检索回来的辅助上下文。所有架构差异都被隔离在“数据处理逻辑”之外。2.2 增强型架构的设计重点上下文、记忆与工具增强型架构的设计重点不是模型选型而是“在模型之外围了些什么”。我排一下优先级。上下文工程是排第一位的。一个常见误区是“把能搜到的全塞给模型”。实际情况是模型输入越长注意力分配越稀疏关键信息反而容易被淹没。我实测过一组数据上下文从2k tokens涨到8k tokens时召回率明显下降的case不在少数。正确做法是做“压缩-排序-匹配”三步压缩指把检索回来的长文档截断成与问题相关的段落排序指按语义相似度从高到低排列匹配指从压缩后的语料里挑出Top-K条注入K值的黄金区间通常在3到5条之间。记忆管理排在第二位。短期记忆可以理解为对话窗口里的消息历史这个直接控制——超过一定轮次就做摘要压缩不然全量塞进去必然爆上下文。长期记忆用向量库存储但要注意写入时机不是每轮都写而是等一个任务单元结束后把关键结论抽取出来持久化。否则你库里塞的全是中间状态检索时噪声极大。工具注册与失效降级排在第三位。每个工具都该有四个元信息名称、描述、入参schema、调用地址。描述写得好不好直接决定模型调用工具的准确率——描述模糊模型就会张冠李戴。实测下来描述越具体越带范例调用准确率越高比如“查询订单物流状态参数为订单号形如ORD-20240501-A”就比“订单查询”好很多。工具还得配降级策略。工具临时不可用时不能直接把错误抛给用户要设计“降级链”主工具挂了按顺序尝试备选工具最后兜底返回预设话术。关键是要在响应里带上“工具异常”标记方便后续补单处理。2.3 链式架构的衔接时机与失败传播链式架构的核心不在“怎么调用下一个Agent”而在“怎么保证上一个Agent的输出可靠地成为下一个Agent的输入”。有四个细节必须抠。第一单一职责。每个环节只做一件事而且这件事必须能被“一句话说清”。比如“把原始工单文本里的地址抽取出来”是一个职责“抽取地址并判断该地址是否在配送范围并给出运费预估”就串了三个职责任何一步出错你都定位不到是哪一步出的错。第二中间产物持久化。链条上一环的结果不能只存在内存里必须在每一步完成后落盘数据库或对象存储。这既是数据审计的需要也是失败恢复的抓手——很多时候不是重跑整条链而是从失败节点恢复重新执行。第三幂等设计。链式系统里同一环节被重复执行的情况非常常见比如网络超时后客户端自动重试。如果这个环节是“写库”或“调对外接口”重复执行就会产生脏数据或重复扣费。所以每个环节的入参里必须带唯一事件ID处理前先查重做不了幂等的环节至少要做到可对账。第四失败传播策略得提前定。链式里有三种失败方式——前级输出为空、解析失败、模型超时。我的做法是每个环节都配置一个“失败出口”要么终止整链并通知上游要么走一个降级子流程要么把异常信息追加到消息体里继续往后传。注意没有兜底策略的链式架构等于没有安全气囊的汽车。2.4 路由式的分类质量与兜底策略路由式架构的门面是入口核心是决策质量。如果你的入口分类不准后面的流程再精妙也没用。分类实现有两种路线。一种是用LLM做语义分类比如让Agent判断“这个请求属于订单查询、售后投诉、建议反馈中的哪一类”。一种是用Embedding相似度匹配把用户请求向量化跟预置的各类别样本向量比相似度。各有各的问题我给出的建议是混合使用先用相似度匹配拿到Top-2候选再用LLM在候选里做最终判定。这样既避免LLM在太多类别里犯选择困难又能弥补相似度匹配对语义深层理解不足的缺陷。路由置信度阈值也是个关键参数。阈值太高很多请求会掉进“无法分类”的兜底流程里阈值太低各种不相干的请求被硬塞进某个流程后患无穷。我的经验是从0.7起步根据线上日志动态调整如果A类任务被误分到B类的比例高于5%就该上调B类阈值同时补A类样本。设计兜底流程时有个容易踩的坑。不少人觉得兜底就是“找不到就道歉抱歉”但实际兜底应该做成“澄清-重试-转人工”三级。第一级告诉用户“我没太理解您是想要XX还是YY”给出选项引导用户重新表述第二级用另一种分类策略重新判一次比如换Embedding模型或者换Prompt第三级转到人工或预设的通用FAQ流程。三级的兜底结构能极大降低路由系统的不可用率。3. 实操过程从一个具体项目看三种架构落地3.1 场景设定某智能客服工单系统的改造理论讲了一堆下面用一个模拟项目把三种架构串起来。场景是“某电商平台的智能客服工单系统”业务背景是每天收到几千条用户消息需要自动分类、提取关键信息、生成处理摘要、派发到对应业务组。原系统是一个巨大的增强型Agent一条Prompt包打天下。结果就是客服团队天天抱怨有时候把抱怨当成了咨询有时候把退换货请求当成了物流查询处理摘要格式不统一业务组接单后还要重看原始消息才能理解上下文。于是我们做了架构改造整体设计成“路由式入口 增强型处理Agent 链式子流程”的混合架构。改造后的整体流程是这样的用户消息先进入路由层判定为“物流咨询”“退换货请求”“建议反馈”“无法识别”四个大类。其中“物流咨询”走一个增强型Agent查订单系统、查物流接口OR备选查询方案生成答复建议。“退换货请求”走链式流程先做信息抽取把订单号、商品ID、问题描述抽出来再做退款计算最后生成售后处理摘要输出给业务组。“建议反馈”则直接入库存留定期汇总。“无法识别”进入兜底流程先澄清再转人工。3.2 第一步把需求拆成可路由的意图树动手前我们做的第一件事是把所有客服会话历史翻出来统计高频意图。这里有个很核心的经验意图树不是拍脑袋定的是拿真实数据喂出来的。我们拉了一个月的工单数据按人工客服的归类方式做聚类最终收敛出四级意图树。注意不需要无限细分只要分到“能对应到不同处理流程”这个粒度就够了。比如“退换货请求”下级还拆了“仅退款”“退货退款”“换货同款”但这三个走的是同一套链式流程只是参数不同所以路由层只分到“退换货请求”这一层。每个意图路由目标都预置了“样本示例”比如“物流咨询”的示例有“我的快递不发怎么办”“都三天了还没更新物流”“能帮我催一下快递吗”等等。每个意图至少预置了十条示例样本数量直接影响Embedding匹配的准确度太少根本匹配不准。3.3 第二步实现路由层与增强型单Agent路由层的实现我们选了“Embedding召回 LLM判定”的混合策略。具体来说用户消息先转化为向量在所有意图样本里取相似度Top-2。然后构造一个精简Prompt让模型在这两个候选中选一个并输出置信度全程使用较低温度保证稳定性温度参数我通常设在0.1以下。这里有个实际参数Embedding召回的相似度阈值是0.55低于这个值直接判定为“无法识别”不再进LLM二次判定。LLM的置信度阈值是0.75低于0.75也归入“无法识别”。两个阈值配合使用最终“无法识别”的比例大约在8%左右这个比例是可接受的因为还有三级兜底在撑。物流咨询子流程的增强型Agent我们做了三个增强点。一是接入了订单信息检索接口先把用户关联的订单信息查回来做上下文。二是接了物流查询工具并设计了备用方案A方案调物流平台APIB方案调缓存中最近一次物流快照。三是建了一个“客服安全边界”规则库比如遇到“要求补偿”“要求加急”时Agent只能记录不能承诺这个规则以指令形式注入系统提示词。3.4 第三步在子流程中用链式串联多个子Agent退换货请求的链式流程是这个项目里最复杂的部分。链路总共四段信息抽取、条件校验、动作决策、摘要生成。信息抽取段Agent把用户原始消息转为结构化数据包括用户ID、订单号、商品ID、问题类型、诉求描述。这里用到了严格模式输出要求模型只输出JSON任何多余文字都被视作失败。条件校验段这里不是模型处理的是传统代码在处理。拿到结构化数据后查订单系统核对订单是否真实存在、是否在售后期内、是否已发起过售后。这块用传统代码的原因是规则是刚性的不需要模型做模糊判断用代码更稳定。动作决策段根据校验结果决定“自动退款”“转人工审核”“拒绝并说明原因”三类动作。这里也用了增强型Agent来写“拒绝并说明原因”的话术因为这种场景需要模型生成语气合适的解释文案同时保持信息准确。摘要生成段把前面的结构化数据和处理动作摘要成一段自然语言描述推给业务组。摘要格式有严格的字段要求包括处理结果、建议、风险标记等确保业务组能直接看摘要干活不用返回原文。3.5 第四步观测与迭代整个系统上线前我们还做了几件观测层面的准备。第一是给每个消息都生成了完整的链路追踪ID从入口路由到最后摘要生成每个节点的耗时、token消耗、状态码都记录成结构化日志。第二是搭了一个“评估集”机制每个工作日抽样50条历史消息人工标注路由分类是否正确、链式各段输出是否达标算出一个“架构健康分”。这个分数直接反映系统在真实分布上的表现比看几个演示案例靠谱得多。在迭代节奏上有一个反直觉的经验不要每天调Prompt。Prompt调整一次你至少要给它一周的线上数据来验证效果否则很容易被噪声样本带偏。我们现在的节奏是每两周做一次集中调优平时只修明显的case级错误。4. 常见问题排查与避坑实录4.1 典型故障路由误判、链路中断、上下文污染、工具超时做这套系统以来遇到最多的问题集中在四个地方。路由误判的典型案例用户说“你们这个洗衣液是不是有问题用了之后手上起红疹”系统分成了“产品效果咨询”而不是“投诉维权”。原因是我们预设的投诉样本太偏向“情绪化表达”了忽略了很多理性陈述的投诉。解决方法是去真实投诉工单里补充样本而不是拍脑袋写示例。链路中断的典型案例信息抽取段全部字段都成功解析但条件校验段发现订单号格式不对导致链路断裂。查日志发现用户消息里写的订单号是“OR D2024”这种带空格的Embedding检索没问题但严格正则匹配挂了。这类问题的核心不是正则写不好而是链式架构缺少“数据清洗前置节点”。上下文污染的典型案例增强型Agent在处理物流咨询时把前一个用户的历史投诉记录也检索进来当作上下文导致回答风格突然变得非常防御性。这个问题说明了“检索范围隔离”的重要性——业务A的工单记录不能让处理业务B的Agent随意检索。工具超时的典型案例物流平台API晚间高峰期响应要5秒以上Agent等待期间整个链路超时。解决方式其实很简单给工具调用设独立较短超时指标超时就走降级缓存方案不让模型干等。这个优化之后整个系统的P95响应时间下降明显。4.2 常见问题速查表现象可能原因解决方案路由分类结果跳来跳去温度过高、样本相似度接近将分类温度降到0.1以下给相似样本差异化描述链式下一环节经常解析失败上一环节输出格式不稳定使用严格结构化输出范式并加一轮格式校验重试多个会话互相干扰全局上下文混用为每轮会话建立独立隔离的上下文存储区工具调用频繁报错工具描述与实际参数不符在描述里加入参数示例预置参数校验环节Agent重复执行相同操作网络超时导致客户端重试为操作节点设置唯一事件ID实现幂等控制增强检索结果质量差检索范围过大、噪声多增加元数据过滤缩小检索范围提高相似度阈值输出内容出现冲突信息上下文里新旧信息矛盾在注入上下文前做时间戳筛选过期信息降权系统成本突然飙升链式环节无节制的全量重跑为每个重试场景设置最大次数上限失败走降级流程4.3 我踩过的坑与经验心得最后分享几条可能是文档里永远找不到的实操经验。第一路由目标宁少勿多。同一个系统路由目标从4个扩到9个之后分类准确率没有提升反而下降。原因是目标越多样本边界越难划清相邻意图互相污染。如果需要很细的分类试着把它们拆到路由之后的子流程里去判断而不是全部押在路由层一次搞定。第二链式架构里的“中间人”要克制。有些环节看着可以“顺便”做点别的比如信息抽取环节顺便生成个标题、顺便做个情绪判断。但一旦加了“顺便”这个节点的输出就不能被其他环节稳定预期了排查问题的难度直线上升。第三增强型架构最怕过度增强。一开始我们往Agent里塞了超长系统指令、历史对话摘要、知识库Top-5、工具描述十几条结果模型输出变得犹豫、话痨、频繁自我纠正。后来做减法把系统指令压到一屏以内删除低价值工具上下文清清爽爽输出质量反而上来了。第四架构是动态演进的。我们的系统上线时是“路由 增强型”运营一个月后才发现退换货场景需要稳定流水线才补上了链式子流程。所以不用指望一次选型终身正确关键是让系统具备“演进能力”——消息契约先行、各节点解耦、观测体系完整这三点做到位从一种架构演进到另一种架构的成本就会小很多。做Agent工作流架构这件事我最大的体会是它的本质不是“把模型接进来”而是“把不可控的模型关进可控的笼子里”。三种架构是三种笼子——增强型是把笼子加固链式是给笼子隔间路由式是把不同的鸟分到不同的笼子。理解这一点很多设计决策都不用纠结了。
架构设计这事很多团队第一步就绕错了。不少朋友跟我聊Agent系统时开口就是“我该用哪个框架”“LangChain还是自研”其实框架只是表面问题真正决定系统上限的是你把Agent工作流编排成什么形状。今天这篇我把Agent工作流里三种最核心的架构模式掰开揉碎讲一遍——增强型、链式、路由式从设计思路到落地的关键细节再到我实操中踩过的一系列坑全部摊开说。先泼一盆冷水如果你把Agent当成一个“万能黑盒节点”所有任务一股脑塞进去让它自由发挥那你大概率会在交付前夜被不稳定的输出折腾到崩溃。Agent本身是模型模型天然带随机性工作流设计的第一价值就是用结构去约束随机性。三种架构不是谁替代谁的关系而是像积木一样可以组合嵌套的关系。搞懂它们各自解决什么问题、擅长什么场景、有哪些致命缺陷你才能像搭积木一样搭出稳定可控的系统。这篇文章适合正在做Agent应用落地的开发者、技术负责人也适合刚接触LLM应用架构、想建立全局认知的同学。1. 三种Agent工作流架构到底在解决什么问题1.1 单节点Agent的失控与低效先聊一个最常见的原始形态一个Prompt一个Agent自动决定做什么、用什么工具、输出什么。听起来很美好但现实中这种“自由Agent”很容易变成“失控Agent”原因有三个层面。一是输出不稳定。模型每次推理都有概率偏差同一种语义的表达方式可能完全不同直接导致下游解析程序没法稳定工作。二是上下文失管。自由Agent调用工具时每轮工具结果都往上下文里塞多轮下来上下文膨胀模型开始遗忘早期关键信息幻觉率直线上升。三是效率低下。一个复杂任务比如“查一个客户的历史订单并生成售后处理建议”如果让单个Agent从零自由发挥它可能花大量tokens在自我对话上编排步骤不固定响应时间和成本双双失控。这里有个很好的生活类比把整个餐厅后厨交给一个大厨让他一个人决定配菜、炒菜、摆盘、上菜顺序。遇到熟客家常菜没问题但一到高峰期菜品一多这个大厨就开始手忙脚乱出品质量大打折扣。工作流架构本质上就是给后厨划分工位切配归切配热炒归热炒传菜归传菜——用明确的职责边界去替代“一个人扛所有事”的不确定性。1.2 三种架构的定义与选型边界增强型架构Augmented Workflow核心是“让单个Agent变强”。在Agent外层包裹上下文检索、记忆管理、工具注册、结果校验等一系列机制。模型还是那个模型但外围设备让它不裸奔。典型形态像RAG应用Agent在回答前会先检索知识库把相关内容作为上下文注入再让模型生成答案。增强型的价值在于就近解决“单点能力不足”实施成本相对低对现有系统改造小。链式架构Sequential Chaining / Pipeline核心是“把一个大任务拆成多个子Agent接力”。上一个Agent的输出解析、过滤后作为下一个Agent的输入。典型场景是信息提取流水线原始文档先交给Agent A做要素抽取抽出的结构化数据交给Agent B做分类打标签再交给Agent C生成摘要报告。每级只做一件事输入输出有明确接口约束问题定位起来非常方便。路由式架构Routing Workflow核心是“先分类、再分派”。一个入口路由Agent接收用户请求判断任务类型把请求转发给不同的下游Agent或固定流程。典型形态是智能客服系统的主入口用户问“我的订单怎么还没到”——路由到订单查询流程用户骂“你们产品质量有问题”——路由到售后维权流程。路由式架构擅长处理意图分支明确的场景能把不同类型的任务隔离到各自的处理流程中避免“一个Agent干所有活”带来的指令冲突。选型边界其实挺清晰的我归纳成一张表架构类型核心目标适合场景落地复杂度典型风险增强型提升单Agent能力问答、代码辅助、知识密集型任务低上下文成本高、检索质量不稳链式稳定流水线、可定位信息提取、内容生成、多步处理中错误传播、前级输出影响后级路由式意图分流、任务隔离多业务入口、客服、门户型系统中高分类错误、边界模糊导致分发失败1.3 为什么选型比写代码更重要我在一些项目里见过一句话式的技术决策“先跑通再说后面优化”。这句话在MVP阶段没问题但到了Agent系统这里很容易变成灾难。因为Agent工作流的改型成本不是改一段代码而是整个链路的数据形态、上下文策略、运维观测体系全部推倒重来。举个例子某团队一开始做了个增强型Agent所有任务都在一个大Agent里完成。后来业务方提出要支持“先提取用户意图再分流到不同处理流程”团队被迫在现有大Agent外面套路由层但原来大Agent里塞满了各种业务prompt互相干扰最后不得不拆成多个小Agent重新编排。估算下来重构工时是当初“先跑通”版本的3倍不止。所以我有个习惯动工前先花半天把“任务类型清单”列出来。数一数系统到底有多少种不同的用户意图、多少种上游输入、多少种下游输出。如果不超过两种类型增强型就够了如果超过五种且有明确的分支条件路由式不可避免如果任务本身是一条明确的生产线比如“解析、分类、摘要、入库”链式才是正确选择。选型错了后面每一步都是在还债。2. 架构设计的核心细节与关键参数2.1 协议先行三种架构共同的基础聊任何架构细节之前必须先说“协议”。这个词听起来硬核实际含义就是你系统里传递的数据长什么样必须提前定死。很多Agent系统崩就崩在这里——Agent A输出的字段叫“summary”Agent B期待的字段叫“result”两边对不上链式架构直接断链路由式架构直接分错类。我在实操中会把每个Agent之间的消息体统一成三层结构第一层meta放消息ID、产生时间、来源Agent标识、链路追踪ID。这层负责运维观测排查问题全靠它。第二层payload放业务主数据。比如工单标题、用户描述、历史订单列表。第三层context放链路内的临时状态。比如处理进度、已执行步骤、路由决策依据。再来一个版本号字段描述这套结构的schema版本。这样后面要加字段老的处理节点看到版本不匹配可以走降级逻辑而不是直接解析报错。整体结构类似这样{ version: 1.2, meta: { message_id: msg_8f3a..., created_at: 2024-05-12T10:30:00Z, source_node: router, trace_id: trace_0f2e... }, payload: { ticket_id: TKT-20240512-001, user_message: 我的订单三天没更新物流了, user_id: U-10086, order_ids: [ORD-20240501-A] }, context: { route_decision: logistics_query, route_confidence: 0.87, attempts: 0 } }这个契约一旦确定三种架构的拼装就变得非常顺滑。路由式看context.route_decision链式处理payload里的业务数据增强型Agent只用关心payload和检索回来的辅助上下文。所有架构差异都被隔离在“数据处理逻辑”之外。2.2 增强型架构的设计重点上下文、记忆与工具增强型架构的设计重点不是模型选型而是“在模型之外围了些什么”。我排一下优先级。上下文工程是排第一位的。一个常见误区是“把能搜到的全塞给模型”。实际情况是模型输入越长注意力分配越稀疏关键信息反而容易被淹没。我实测过一组数据上下文从2k tokens涨到8k tokens时召回率明显下降的case不在少数。正确做法是做“压缩-排序-匹配”三步压缩指把检索回来的长文档截断成与问题相关的段落排序指按语义相似度从高到低排列匹配指从压缩后的语料里挑出Top-K条注入K值的黄金区间通常在3到5条之间。记忆管理排在第二位。短期记忆可以理解为对话窗口里的消息历史这个直接控制——超过一定轮次就做摘要压缩不然全量塞进去必然爆上下文。长期记忆用向量库存储但要注意写入时机不是每轮都写而是等一个任务单元结束后把关键结论抽取出来持久化。否则你库里塞的全是中间状态检索时噪声极大。工具注册与失效降级排在第三位。每个工具都该有四个元信息名称、描述、入参schema、调用地址。描述写得好不好直接决定模型调用工具的准确率——描述模糊模型就会张冠李戴。实测下来描述越具体越带范例调用准确率越高比如“查询订单物流状态参数为订单号形如ORD-20240501-A”就比“订单查询”好很多。工具还得配降级策略。工具临时不可用时不能直接把错误抛给用户要设计“降级链”主工具挂了按顺序尝试备选工具最后兜底返回预设话术。关键是要在响应里带上“工具异常”标记方便后续补单处理。2.3 链式架构的衔接时机与失败传播链式架构的核心不在“怎么调用下一个Agent”而在“怎么保证上一个Agent的输出可靠地成为下一个Agent的输入”。有四个细节必须抠。第一单一职责。每个环节只做一件事而且这件事必须能被“一句话说清”。比如“把原始工单文本里的地址抽取出来”是一个职责“抽取地址并判断该地址是否在配送范围并给出运费预估”就串了三个职责任何一步出错你都定位不到是哪一步出的错。第二中间产物持久化。链条上一环的结果不能只存在内存里必须在每一步完成后落盘数据库或对象存储。这既是数据审计的需要也是失败恢复的抓手——很多时候不是重跑整条链而是从失败节点恢复重新执行。第三幂等设计。链式系统里同一环节被重复执行的情况非常常见比如网络超时后客户端自动重试。如果这个环节是“写库”或“调对外接口”重复执行就会产生脏数据或重复扣费。所以每个环节的入参里必须带唯一事件ID处理前先查重做不了幂等的环节至少要做到可对账。第四失败传播策略得提前定。链式里有三种失败方式——前级输出为空、解析失败、模型超时。我的做法是每个环节都配置一个“失败出口”要么终止整链并通知上游要么走一个降级子流程要么把异常信息追加到消息体里继续往后传。注意没有兜底策略的链式架构等于没有安全气囊的汽车。2.4 路由式的分类质量与兜底策略路由式架构的门面是入口核心是决策质量。如果你的入口分类不准后面的流程再精妙也没用。分类实现有两种路线。一种是用LLM做语义分类比如让Agent判断“这个请求属于订单查询、售后投诉、建议反馈中的哪一类”。一种是用Embedding相似度匹配把用户请求向量化跟预置的各类别样本向量比相似度。各有各的问题我给出的建议是混合使用先用相似度匹配拿到Top-2候选再用LLM在候选里做最终判定。这样既避免LLM在太多类别里犯选择困难又能弥补相似度匹配对语义深层理解不足的缺陷。路由置信度阈值也是个关键参数。阈值太高很多请求会掉进“无法分类”的兜底流程里阈值太低各种不相干的请求被硬塞进某个流程后患无穷。我的经验是从0.7起步根据线上日志动态调整如果A类任务被误分到B类的比例高于5%就该上调B类阈值同时补A类样本。设计兜底流程时有个容易踩的坑。不少人觉得兜底就是“找不到就道歉抱歉”但实际兜底应该做成“澄清-重试-转人工”三级。第一级告诉用户“我没太理解您是想要XX还是YY”给出选项引导用户重新表述第二级用另一种分类策略重新判一次比如换Embedding模型或者换Prompt第三级转到人工或预设的通用FAQ流程。三级的兜底结构能极大降低路由系统的不可用率。3. 实操过程从一个具体项目看三种架构落地3.1 场景设定某智能客服工单系统的改造理论讲了一堆下面用一个模拟项目把三种架构串起来。场景是“某电商平台的智能客服工单系统”业务背景是每天收到几千条用户消息需要自动分类、提取关键信息、生成处理摘要、派发到对应业务组。原系统是一个巨大的增强型Agent一条Prompt包打天下。结果就是客服团队天天抱怨有时候把抱怨当成了咨询有时候把退换货请求当成了物流查询处理摘要格式不统一业务组接单后还要重看原始消息才能理解上下文。于是我们做了架构改造整体设计成“路由式入口 增强型处理Agent 链式子流程”的混合架构。改造后的整体流程是这样的用户消息先进入路由层判定为“物流咨询”“退换货请求”“建议反馈”“无法识别”四个大类。其中“物流咨询”走一个增强型Agent查订单系统、查物流接口OR备选查询方案生成答复建议。“退换货请求”走链式流程先做信息抽取把订单号、商品ID、问题描述抽出来再做退款计算最后生成售后处理摘要输出给业务组。“建议反馈”则直接入库存留定期汇总。“无法识别”进入兜底流程先澄清再转人工。3.2 第一步把需求拆成可路由的意图树动手前我们做的第一件事是把所有客服会话历史翻出来统计高频意图。这里有个很核心的经验意图树不是拍脑袋定的是拿真实数据喂出来的。我们拉了一个月的工单数据按人工客服的归类方式做聚类最终收敛出四级意图树。注意不需要无限细分只要分到“能对应到不同处理流程”这个粒度就够了。比如“退换货请求”下级还拆了“仅退款”“退货退款”“换货同款”但这三个走的是同一套链式流程只是参数不同所以路由层只分到“退换货请求”这一层。每个意图路由目标都预置了“样本示例”比如“物流咨询”的示例有“我的快递不发怎么办”“都三天了还没更新物流”“能帮我催一下快递吗”等等。每个意图至少预置了十条示例样本数量直接影响Embedding匹配的准确度太少根本匹配不准。3.3 第二步实现路由层与增强型单Agent路由层的实现我们选了“Embedding召回 LLM判定”的混合策略。具体来说用户消息先转化为向量在所有意图样本里取相似度Top-2。然后构造一个精简Prompt让模型在这两个候选中选一个并输出置信度全程使用较低温度保证稳定性温度参数我通常设在0.1以下。这里有个实际参数Embedding召回的相似度阈值是0.55低于这个值直接判定为“无法识别”不再进LLM二次判定。LLM的置信度阈值是0.75低于0.75也归入“无法识别”。两个阈值配合使用最终“无法识别”的比例大约在8%左右这个比例是可接受的因为还有三级兜底在撑。物流咨询子流程的增强型Agent我们做了三个增强点。一是接入了订单信息检索接口先把用户关联的订单信息查回来做上下文。二是接了物流查询工具并设计了备用方案A方案调物流平台APIB方案调缓存中最近一次物流快照。三是建了一个“客服安全边界”规则库比如遇到“要求补偿”“要求加急”时Agent只能记录不能承诺这个规则以指令形式注入系统提示词。3.4 第三步在子流程中用链式串联多个子Agent退换货请求的链式流程是这个项目里最复杂的部分。链路总共四段信息抽取、条件校验、动作决策、摘要生成。信息抽取段Agent把用户原始消息转为结构化数据包括用户ID、订单号、商品ID、问题类型、诉求描述。这里用到了严格模式输出要求模型只输出JSON任何多余文字都被视作失败。条件校验段这里不是模型处理的是传统代码在处理。拿到结构化数据后查订单系统核对订单是否真实存在、是否在售后期内、是否已发起过售后。这块用传统代码的原因是规则是刚性的不需要模型做模糊判断用代码更稳定。动作决策段根据校验结果决定“自动退款”“转人工审核”“拒绝并说明原因”三类动作。这里也用了增强型Agent来写“拒绝并说明原因”的话术因为这种场景需要模型生成语气合适的解释文案同时保持信息准确。摘要生成段把前面的结构化数据和处理动作摘要成一段自然语言描述推给业务组。摘要格式有严格的字段要求包括处理结果、建议、风险标记等确保业务组能直接看摘要干活不用返回原文。3.5 第四步观测与迭代整个系统上线前我们还做了几件观测层面的准备。第一是给每个消息都生成了完整的链路追踪ID从入口路由到最后摘要生成每个节点的耗时、token消耗、状态码都记录成结构化日志。第二是搭了一个“评估集”机制每个工作日抽样50条历史消息人工标注路由分类是否正确、链式各段输出是否达标算出一个“架构健康分”。这个分数直接反映系统在真实分布上的表现比看几个演示案例靠谱得多。在迭代节奏上有一个反直觉的经验不要每天调Prompt。Prompt调整一次你至少要给它一周的线上数据来验证效果否则很容易被噪声样本带偏。我们现在的节奏是每两周做一次集中调优平时只修明显的case级错误。4. 常见问题排查与避坑实录4.1 典型故障路由误判、链路中断、上下文污染、工具超时做这套系统以来遇到最多的问题集中在四个地方。路由误判的典型案例用户说“你们这个洗衣液是不是有问题用了之后手上起红疹”系统分成了“产品效果咨询”而不是“投诉维权”。原因是我们预设的投诉样本太偏向“情绪化表达”了忽略了很多理性陈述的投诉。解决方法是去真实投诉工单里补充样本而不是拍脑袋写示例。链路中断的典型案例信息抽取段全部字段都成功解析但条件校验段发现订单号格式不对导致链路断裂。查日志发现用户消息里写的订单号是“OR D2024”这种带空格的Embedding检索没问题但严格正则匹配挂了。这类问题的核心不是正则写不好而是链式架构缺少“数据清洗前置节点”。上下文污染的典型案例增强型Agent在处理物流咨询时把前一个用户的历史投诉记录也检索进来当作上下文导致回答风格突然变得非常防御性。这个问题说明了“检索范围隔离”的重要性——业务A的工单记录不能让处理业务B的Agent随意检索。工具超时的典型案例物流平台API晚间高峰期响应要5秒以上Agent等待期间整个链路超时。解决方式其实很简单给工具调用设独立较短超时指标超时就走降级缓存方案不让模型干等。这个优化之后整个系统的P95响应时间下降明显。4.2 常见问题速查表现象可能原因解决方案路由分类结果跳来跳去温度过高、样本相似度接近将分类温度降到0.1以下给相似样本差异化描述链式下一环节经常解析失败上一环节输出格式不稳定使用严格结构化输出范式并加一轮格式校验重试多个会话互相干扰全局上下文混用为每轮会话建立独立隔离的上下文存储区工具调用频繁报错工具描述与实际参数不符在描述里加入参数示例预置参数校验环节Agent重复执行相同操作网络超时导致客户端重试为操作节点设置唯一事件ID实现幂等控制增强检索结果质量差检索范围过大、噪声多增加元数据过滤缩小检索范围提高相似度阈值输出内容出现冲突信息上下文里新旧信息矛盾在注入上下文前做时间戳筛选过期信息降权系统成本突然飙升链式环节无节制的全量重跑为每个重试场景设置最大次数上限失败走降级流程4.3 我踩过的坑与经验心得最后分享几条可能是文档里永远找不到的实操经验。第一路由目标宁少勿多。同一个系统路由目标从4个扩到9个之后分类准确率没有提升反而下降。原因是目标越多样本边界越难划清相邻意图互相污染。如果需要很细的分类试着把它们拆到路由之后的子流程里去判断而不是全部押在路由层一次搞定。第二链式架构里的“中间人”要克制。有些环节看着可以“顺便”做点别的比如信息抽取环节顺便生成个标题、顺便做个情绪判断。但一旦加了“顺便”这个节点的输出就不能被其他环节稳定预期了排查问题的难度直线上升。第三增强型架构最怕过度增强。一开始我们往Agent里塞了超长系统指令、历史对话摘要、知识库Top-5、工具描述十几条结果模型输出变得犹豫、话痨、频繁自我纠正。后来做减法把系统指令压到一屏以内删除低价值工具上下文清清爽爽输出质量反而上来了。第四架构是动态演进的。我们的系统上线时是“路由 增强型”运营一个月后才发现退换货场景需要稳定流水线才补上了链式子流程。所以不用指望一次选型终身正确关键是让系统具备“演进能力”——消息契约先行、各节点解耦、观测体系完整这三点做到位从一种架构演进到另一种架构的成本就会小很多。做Agent工作流架构这件事我最大的体会是它的本质不是“把模型接进来”而是“把不可控的模型关进可控的笼子里”。三种架构是三种笼子——增强型是把笼子加固链式是给笼子隔间路由式是把不同的鸟分到不同的笼子。理解这一点很多设计决策都不用纠结了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
