★ FEATURED ARTICLE 从生产事故聊起Agent复杂到一定程度就得先定架构上周有位同行在技术群里发了一段很长的抱怨同一个Agent在本地Demo里跑得神采奕奕一旦接进生产环境就开始乱说话、乱调工具、上下文经常断用户问一句它绕三圈。他十份怀疑是模型选型不对换了好几个模型也无济于事。我回了他一句大概率不是模型的问题是工作流的架构问题。很多人在搭Agent的时候脑子里只有一个概念——让大模型自己规划、自己调用工具。模型确实有这个能力但你把它当作唯一的编排核心等于把一条流水线的所有质检岗位都交给一个特别聪明但偶尔走神的人。生产环境需要的是稳定AI Agent也是同样的道理。所以我在实际项目中会先根据任务复杂度把Agent工作流架构分成三类来设计增强型架构、链式架构、路由式架构。这篇文章不打算讲抽象概念我会用生产视角拆一遍每种架构解决什么问题、怎么搭、什么时候选它、以及搭完之后最容易翻车的点在哪里。无论你是刚接触Agent开发还是已经被生产环境折磨过几轮这套分类方法应该能帮你把混乱的编排思路慢慢理清楚。1. 两个反直觉的结论为什么什么都让模型做会翻车1.1 Demo可以随意生产不行先讲一个我反复踩过的坑。早期做某制造业企业的设备告警Agent时需求非常简单把设备上报的异常信息汇总成一段结构化描述附带处理建议。我在本地用单Agent加Prompt的方式做效果非常惊艳——模型自己知道要整理时间、设备编号、异常类型、影响程度还会主动标记哪些需要人工介入。结果一接生产就出问题了。真实告警数据的格式五花八门有些字段缺失有些编号对不上模型偶尔会脑补它认为正确但实际上不存在的设备信息。出一次错就是一次事故。那时候我才真正意识到一件事大模型的自由发挥是能力也是风险生产级Agent必须用架构约束它的自由度。所谓的增强型、链式、路由式架构本质上是三种不同力度的约束策略增强型架构不拆流程但给单个Agent配齐工具、记忆和知识来源让它把一件事做到极致。链式架构把一个大任务拆成一串有先后顺序的小步骤每一步的输出是下一步的输入中间可以校验、可以干预。路由式架构一个入口进来根据用户意图或任务类型分发到不同的处理分支每个分支各做各的事。1.2 架构的价值在于兜底我会把架构理解为生产系统的安全带。模型的推理能力决定上限架构决定可靠性的下限。某种架构是否值得选不在于它听起来多高级而在于当模型出错时它能不能尽早拦截、兜底、或者把错误控制在局部。比如增强型架构里工具本身的参数校验就是兜底链式架构里每步之间的格式检查是兜底路由式架构里低置信度时转人工或者回退到默认分支是兜底。没有兜底的Agent不管多智能都只是一颗定时炸弹。这三个架构不是互相替代的关系而是不同复杂度场景下的不同解法。下面我逐一展开。2. 增强型架构先把单个Agent的能力做到极致2.1 增强型到底在增强什么先说最容易混淆的点增强型架构不是把多个Agent串在一起而是让一个Agent具备更多外部能力。典型的手段包括工具调用Function Calling让Agent能执行API、查询数据库、操作文件系统等实际动作而不是只输出一堆建议文本。知识库检索RAG把私有文档、产品手册、历史工单等内容向量化在回答时先检索相关片段再生成减少幻觉。记忆管理短期记忆维护当前对话上下文长期记忆保存用户偏好、历史决策让Agent的行为有连续性。这就像给一个人配了一整套工具箱而不是拉来一整支施工队。任务边界清晰、输入输出比较单一、中间不需要多人协作的场景很适合走增强型。我做过一个简历初筛Agent就是典型的增强型架构。输入是候选人简历输出是评分和建议。给Agent配了三个工具文档解析工具PDF、Word转结构化文本、岗位需求库检索工具、评分规则执行工具。整个流程没有拆分成多步Agent拿到简历后自行决定先做什么、再做什么。2.2 增强型架构的搭建要点增强型架构的搭建核心不是把工具挂上去就完事而是让Agent能正确理解工具的边界。我一般按这四步来做列工具清单写出Agent可能需要完成的所有动作比如解析文档、查库、发消息、生成表格。给每个工具写清晰的功能描述描述里要写明什么时候用这个工具输入参数是什么格式可能返回什么。模型是根据功能描述来选工具的描述模糊等于让模型瞎猜。设定触发前提如果一个工具只在特定条件下可用要写清楚。比如仅当用户明确要求导出Excel时才调用导出工具否则只生成预览表格。留出空转出口模型拿不定主意时必须知道怎么处理是追问用户还是输出默认结果。这一步不能省。我自己写过一份工具描述模板大概长这样工具名称query_candidate_score 功能根据候选人ID查询简历综合评分以及各项能力维度的细分得分。 使用时机需要候选人评分、对比多个候选人分数时使用。 输入参数candidate_id字符串。 返回结果JSON对象包含 total_score、dimension_scores、update_time 三个字段。 注意如果候选人不存在返回 error_code404不要尝试用其他工具替代本工具。这个描述看起来琐碎但它决定了模型能不能在正确时机触发正确的工具。实测下来工具描述里少了注意那一句模型偶尔会绕去搜文件目录输出质量立刻下降。2.3 增强型架构最容易翻车的地方增强型架构最大的隐患是工具数量膨胀。工具挂得越多模型选择工具的准确率越低。我见过一个项目挂了四十多个工具测试期经常发生A需求调用B工具的情况后来不得不把工具合并、精简到十来个准确率才明显回升。另一个容易被忽略的问题是上下文膨胀。工具返回的结果通常是一大段原始数据如果不做截断或摘要Agent的上下文很快会被工具结果占满导致它忘记用户最初的需求。现在我处理工具返回时只要超过一定体量就先用一个轻量摘要模型把关键信息提取出来再交给主Agent。假如你的任务只需要一个Agent、一把好用的工具、一份够准的知识库就能搞定那就不要强行上多步骤流程。增强型架构是性价比最高的起点。3. 链式架构拿流水线的确定性对抗大模型的随机性3.1 核心逻辑上一步的输出就是下一步的输入当你发现单个Agent要做的事情太多上下文装不下或者某一步的输出经常污染下一步时就该考虑链式架构了。链式架构的思想不复杂把任务拆成若干有序步骤步骤之间单向流转每步的输出经过校验后作为下一步的输入。典型例子是内容生成大纲生成、初稿撰写、事实核查、风格润色、排版输出——每一步单独用一个Agent或者一次Prompt完成。我刚做链式架构时觉得这跟多次调用模型没区别后来才发现关键差异在于中间状态的显式定义。盲目的多次调用只是跑代码链式架构要求你为每个中间状态设计清晰的Schema让每一步的产出是可校验、可追溯、可重做的。拿Markdown转Word格式化报告这个场景来说很多人的做法是丢给模型一句帮我把这篇Markdown转成Word样式。结果经常是半路断章、列表层级混淆、图片丢失。用链式架构重新设计后我会拆成四个明确的环节第1步结构解析——把Markdown按标题层级拆成章节树识别段落、表格、代码块、图片引用。第2步样式映射——把Markdown元素映射到Word样式模板标题1对应一级标题表格加上边框和表头底色。第3步内容生成——由模型按模板生成每个章节的Word结构化内容处理表格宽高、换页逻辑。第4步质量校验——检查生成结果里的章节完整性、表格结构、图片路径有异常就打回对应步骤重跑。四步之间有明确的输入输出接口哪一步出错就重跑哪一步而不是从头再来。这种细粒度控制在纯单Agent方案里几乎做不到。3.2 链与链之间的接口协议链式架构里最考验经验的不是每一环本身而是环节之间的接口协议。我之前处理一个数据清洗类Agent时第2步生成的数据字典字段名总是变来变去第3步直接崩溃。排查了大半天发现问题出在第2步的Prompt没有强约束输出字段名。后来我把接口字段写死并且加了一步JSON Schema校验问题才彻底消失。以下是现在项目里常用的一种接口约束写法# 设定链式流程中每一步的输入输出结构 step2_output_schema { type: object, required: [section_id, field_name, field_type, description], properties: { section_id: {type: string}, field_name: {type: string}, field_type: {type: string, enum: [string, int, float, bool]}, description: {type: string} } } def validate_step2_output(raw_output): # 如果模型输出不是合法JSON或缺字段这里直接拦截 import json try: data json.loads(raw_output) except json.JSONDecodeError: return False, 输出不是合法JSON if not all(k in data for k in step2_output_schema[required]): return False, f缺少必需字段 return True, data有人觉得这样很死板认为让模型自由发挥更好。但在多步骤流程里自由发挥等于把错误的雪球越滚越大。前一步的自由发挥会让后一步在错误的输入上做更多错误决策。接口越严格流程越稳。3.3 链式架构要注意的误差累积链式架构有两个常见的踩坑点我分别说一下。第一是误差累积。链子越长误差被放大的概率越高。解决办法是每一环除了正常处理之外要加一层质量检查逻辑发现异常就触发回滚或重试。宁可一步慢一点也别把坏数据送进下一环。第二是每环的独立性。如果某一环依赖前一环的私有状态链式架构的好处就大打折扣了。理想的链式流程每一环只依赖上一环的显式输出不依赖全局变量。这样你才能方便地替换、调试、重跑任意环节。如果你发现任务已经可以拆成明确的顺序步骤并且每一步都有独立的目标那就果断走链式架构。它牺牲了一些模型自由度换来了对整个流程的掌控力。4. 路由式架构入口只有一个出口却要各奔前程4.1 先把路由这件事讲清楚路由式架构简单说就是一个入口多个出口。用户请求先进来由路由器判断这是什么类型的任务然后分发到对应的处理分支。懂一点Web服务的人对这个模式应该很熟悉——类似于Nginx里根据路径前缀把请求分发到不同后端服务也类似于企业内部呼叫中心先让你按1、按2、按3选择不同业务线。区别是Agent路由的分类器可以是大模型也可以是一段规则。我的经验是只要业务存在两类以上差异明显的任务而且处理流程完全不同就该引入路由式架构。比如一个智能客服Agent用户可能问退款、查物流、咨询技术参数、发起投诉。如果全部塞进同一个Agent它需要掌握的上下文太多工具列表也没法精简。拆成路由分发后每个分支可以轻装上阵。之前在某平台做过一个订单异常处理Agent入口进来只做一件事识别用户意图。代码思路大概是这样的def route_request(user_message): # 1. 让模型输出意图分类结果和置信度 intent_result model.classify( user_message, candidates[refund, logistics, technical, complaint] ) # 2. 置信度低于阈值转人工兜底 if intent_result.confidence 0.85: return manual_fallback # 3. 高置信度则进入对应业务链 return intent_result.intent只要分类器够准路由式架构能把大而全的Agent拆成小而精的分支每个分支内部再决定是走增强型还是链式。这也是路由式架构真正厉害的地方它不与其他架构互斥反而经常是组合的起点。4.2 路由分类器的设计规则、模型、混合路由分类器有三种实现方式按复杂度从小到大排列纯规则匹配——关键词、正则、模板。适合意图表达严格、词汇有限的场景。简单可靠但覆盖不全。模型分类——用小模型或蒸馏模型做文本分类。适合语义多样、需要理解语气的场景。灵活性高但需要维护训练数据。混合模式——先规则快筛模型兜底或者反着来。大多数生产项目最终都会走向这种。我现在偏爱的模式是规则优先、模型兜底先跑一套关键词规则命中率高的直接分流规则未命中时再让模型判断模型的低置信度结果一律转入人工或默认流程。这样做的好处是核心场景有确定性边缘场景又有灵活性。有一次Agent把售后问题分到了技术咨询分支用户问了三遍才被转回正确通道。查原因发现是某个泛化词触发了错误关键词。从那以后我把高冲突的关键词从规则表里删掉改为让模型决定。准确率反而上来了。4.3 路由之后不能“裸奔”很多人以为路由完就万事大吉其实路由只是第一步。真正决定体验的是每个分支里的兜底策略。我在路由分支里通常都会加一个“低置信度手动兜底”策略模型置信度高于0.9直接自动处理。置信度在0.7到0.9之间处理完后给用户一个我理解你的需求是X对吗的确认环节。置信度低于0.7不尝试自动处理直接转人工队列。这个策略救了很多次场。因为你永远不知道用户会用多奇怪的措辞来描述需求。路由式架构有时候解决的问题不是准确分流而是知道什么时候不该自作主张。5. 别急着站队三种架构的选型判断与组合玩法5.1 用一张表看懂三种架构差异我习惯用下面这张表来对比三种架构帮助团队在项目启动时快速对齐对比维度增强型链式路由式核心思路单Agent多能力多步骤串行流水线多分支按意图分发解决的问题单任务上下文扩展复杂任务拆解、误差定位多类任务混合、资源隔离实现成本低入门首选中需要设计接口高依赖分类准确率交付延迟最低随链长线性增长取决于分支内部流程可解释性中依赖Agent自我说明高每步有显式输出中路由原因可记录翻车点工具膨胀、上下文泄露接口不稳定、误差累积误路由、兜底缺失最适场景简历筛选、单文档处理报告生成、数据加工客服分流、多业务入口这张表不是拿来背的是拿来在评审会上吵架用的。团队成员各执己见时把任务当前的复杂度、可控性、资源投入拿上来一比往往结论就清晰了。5.2 复杂度是选型的第一依据我的选型判断其实很简单从最简方案出发只有当前架构解决不了问题时才升级架构。任务输入输出结构固定、内容量不大——先用增强型挂几个工具就够。当你发现输出质量不稳、或者上下文装不下时就拆成链式。当你发现入口进来的请求五花八门、内部已经有好几条业务线时再考虑路由式。这也是我常用的复杂度阶梯思路第1阶梯单Prompt随便玩玩第2阶梯增强型工具、记忆、RAG第3阶梯链式多个步骤、每步可控第4阶梯路由式多入口分流整合底下多套链式一上来就搞路由式很容易把重心放在分类器准不准上反而忽略了底层每个分支本身的质量。先把每个分支做扎实再加路由才有意义。5.3 组合才是常态一次生产级Agent的长什么样成熟的Agent系统里三种架构往往混在一起。我最近在做一个面向内部员工的知识问答与工单系统整体结构是路由式开头内部再套多个链式分支每个链式分支的某些节点又用了增强型能力。实际流程大致是这样用户提问 - 路由层意图识别 - 知识问答分支链式检索 - 引用确认 - 生成回答 - 工单创建分支链式信息抽取 - 表单生成 - 重复检查 - 人工转接分支增强型实时对话 历史工单检索这个结构里路由层决定了用户的请求流向哪里知识问答分支内部是链式的检索结果先经过验证才生成回答工单创建分支里的信息抽取节点又用了一个带工具的增强型Agent来自动查询用户所属部门和历史权限。组合设计的好处是每一条链路都可以独立优化、独立测试、独立扩容。路由层出了问题不需要改动下层分支某个分支改了工具也不会影响路由逻辑。这就是架构设计在生产环境中的真实价值。6. 几个真实项目的复盘哪些地方最容易翻车6.1 案例复盘一盲目升级链式架构结果越改越慢某内容生产团队原本用增强型做活动文案生成效果不错唯一问题是长文案偶尔前后风格不一致。产品经理坚持要拆成标题生成、正文生成、摘要生成、润色四条链式流程。结果拆完之后每一步都要重新整理上下文总耗时增加了一倍多风格不一致的问题并没有完全解决。复盘时发现真正的问题是模型对全文语境感知不足而不是步骤不够细。后来我们把链路缩短为两步——正文生成和整体润色——问题才算解决。链式架构不是搭积木拆得越细越好拆得过多反而增加冗余和延迟。现在我的原则是只有当某个步骤需要独立校验、独立工具、独立处理错误时才把它拆成单独一环。可拆可不拆的一律不拆。6.2 案例复盘二路由置信度阈值拍脑袋回流率飙升另一个项目里路由层阈值被定成了0.9结果大量本来能自动处理的请求因为置信度不够高直接转人工人工工作量立刻爆表。后来我们把阈值降到了0.75同时对0.75到0.9之间的请求增加了确认环节效果平衡了很多。阈值不是拍脑袋定的要根据拦截率、人工处理成本、用户容忍度一起权衡。我现在的习惯是先在线上用小流量跑几天记录置信度分布再看0.7、0.8、0.9三个档位分别对应多少转人工率最终选择一个让自动处理率和误判率都相对合理的值。6.3 案例复盘三接口字段没锁死链路下游全线崩溃最后这个教训最惨重。某数据报表Agent里上游输出日期字段时是2025-06-01偶尔会变成2025年6月1日。下游做日期解析时没做容错整条链路直接崩了。从那之后我在每个链式接口的Schema里都增加了一个格式化要求字段同时在下游入口增加自动纠错逻辑。不要相信模型会稳定输出同一种格式必须在接口层做强制校验和兜底标准化。我也养成了习惯每次上游Prompt调整后都要跑一遍全链路的回归用例确保格式没变。这个动作看似繁琐省掉的事故远大于成本。最后再分享一点个人心得如果让我给三类架构各贴一个关键词增强型是能力链式是秩序路由式是分流。搭过太多Agent项目之后我越来越觉得架构设计不是炫技而是在为不确定性做预案。我现在接手一个新项目时会先花小半天列出任务的所有输入来源、输出要求、失败模式和可接受成本把复杂度摸清后再决定采用哪套架构。大多数团队的Agent项目翻车不是模型不够聪明而是一开始就没想清楚该用哪种结构去约束它。动手之前多问自己三句话这件事凭一个Agent能干完吗干不完的话能不能拆成有接口的步骤入口进来的请求是不是可以明显分成几类答案清楚了架构自然就浮出水面了。
阅读完成 · 觉得有帮助？
