1. 删架构之前的真实现场一个Agent项目是怎么被拖垮的做了一年多的Agent这时间不算长但足够把各种主流范式都试一遍。先直接说结论这一年里让我最肉疼、但收益最大的一次改动就是把一个团队搭了两个多月的“完整架构”删掉了。现在回头看那不是我删掉的第几版方案而是主动放弃了一种“看起来很专业”的建设方式。整个过程不是拍脑袋是数据一步步逼出来的。我当时接手的业务场景是智能客服Agent负责售前咨询、订单查询、售后流转三类任务。听起来不复杂但一接过来我就发现代码库里的设计远比业务本身复杂。系统里跑着Planner规划器、Executor执行器、Verifier验证器三层同时还挂着主管Agent、反思Agent甚至还有一个专门用于“争议裁定”的Agent。记忆体系也分短期、长期、摘要、向量检索四套。工具层更不用提统一网关、权限校验、重试策略、路由配置应有尽有。演示效果确实好。演示环境里Agent回答连贯、逻辑清晰、能解释自己的步骤看起来非常有“智能感”。但真实用户流量一进来问题立刻暴露一个普通的订单查询用户在输入框敲了一句话等回复要七八秒稍微复杂一点的售后问题Agent内部要来回调用好几轮LLM中间偶尔还会出现反思Agent给出一个“貌似合理”的修改建议主Agent采纳后答案反而跑偏。最折磨人的是排查。线上用户反馈“回答不对”我打开日志发现一条请求背后有五六次模型调用分布在不同的Agent模块里很难判断是哪一层出了问题。是规划错了是反思改坏了还是记忆摘要污染了每条链路都有可能。我花在“猜”上的时间比写新功能的时间还多。那个阶段我经常跟同事说一句话这个系统不是不聪明是不稳定。它稳定地浪费着算力稳定地变慢稳定地在某些输入上翻车。而所有这些问题都指向同一个根源——我们给一个本该轻量的问题装了一副过于沉重的骨架。后来我和团队坐下来复盘问了一个很朴素的问题这些架构组件到底哪个在真实场景里产生了正收益没人能给出量化答案。我们只有一堆流程图、概念图和一些“理论上应该更好”的信心。那时候我就隐约意识到这个方向大概率错了。真正动手去删是在想清楚以下三个机制之后。2. 重架构拖垮Agent的三个机制Token、错误传播与无法定位先说Token。很多人以为多几次LLM调用只是“慢一点”但实际代价远比想象中大。我们当时给每个Agent都写了人设规划Agent要有“战略思维”节奏反思Agent要“批判性审视”裁定Agent要“客观中立”。每个Agent的System Prompt动辄几千字业务知识还要反复塞进上下文。一次用户请求内部多次调用每次调用都带着一大段冗余文本输入Token很快破万。这不仅让单次请求的延迟暴涨还直接把成本推高了一个量级。更隐蔽的是上下文污染。某次反思Agent在分析用户问题时随手生成了一段“用户可能对物流不满”的猜测被写入记忆摘要。后续主Agent读取摘要后完全跟着这个错误假设走把原本简单的地址修改问题误判成物流投诉来回兜圈子。这类问题在重架构里几乎无法根治因为你不知道哪一次中间调用会往共享上下文里写脏数据。再说错误传播。LLM本质是概率模型任何一次调用都有失败概率。把多个概率模型串成一条流水线整体成功率会相乘递减。假设主Agent的单步准确率是85%反思Agent“正确修正”的概率是80%验证器“正确判断结果可用”的概率是85%三层叠加后的整体成功率只有58%左右。57.8%的成功率意味着接近一半的用户请求得不到可用结果。而如果直接用单次模型调用只要模型本身能力够成功率就是那一次调用的水平明显更高。这也是“多Agent协作”最容易被高估的地方理论上各司其职实际上错误在层与层之间传递而且每一层都在消耗时间和Token。很多人没有意识到多Agent之间的对话并非免费的“智慧碰撞”它们是在用真金白银和用户耐心做代价。最后是无法定位。重架构下一条请求会分裂成多条日志Planner输出一个计划Executor逐条执行Verifier给出判定。如果最终结果错了你必须同时检查计划是否合理、工具执行是否成功、反思是否把对的改成错的。这种排查成本在开发阶段还能忍一旦线上用户量大起来就完全不可接受。我统计过当时排查一个中等复杂度问题平均要花二十分钟其中大部分时间在“对照多个Agent的输出日志猜是哪一步的锅”。这三个机制叠加在一起解释了我当时看到的全部现象慢、贵、不稳、难查。而它们恰恰是架构复杂度带来的直接代价。所以当团队里有人提出“我们能不能不搞这么多层次”的时候我没有像之前那样反驳而是决定做一次严格对照实验用数据来判断到底该删谁。3. 动手删架构前我先把“谁有用”做成了可以量化的对照实验很多文章会教你直接删但我想强调盲删和盲堆一样危险。我当时做了一个为期两周的对照实验思路很简单但有效。先把线上流量复制一份维护A、B两条评估链路。A链路保持原架构不变B链路则用我最想验证的极简方案一个核心Agent 原生工具调用 精简后的提示词不搞多Agent不搞状态机。两组用同一批测试集跑测试集包含三百条真实用户问题覆盖售前、售后、订单异常和多轮追问。第一批结果就让我有点坐不住。B链路的任务完整解决率是87%A链路只有74%。注意B链路没有任何额外优化只是删掉了架构结果反而高了十三个点。我第一反应是测试集有偏差于是人工抽检了三十条差异案例发现A链路的大量失败来自“中间某个Agent把正确结果改错”或“验证器错误拦截了本来可用的回答”而不是模型能力不足。这说明复杂编排确实在添乱。更讽刺的是反思Agent。我单独做了一个剥离测试把反思层关闭只保留PlannerExecutor。结果在简单任务上成功率不降反升追问类任务基本持平。反思步骤在多数场景下根本没有“反思”到位只是在消耗一次额外的模型调用和几秒钟延迟。真正有价值的反思极少——大概只有5%左右的复杂请求确实需要二次修正而这部分完全可以用另一条策略处理而不是全局无差别加一层。实验做到这里该删什么已经不言自明。我按顺序做了清理先删掉主管Agent、反思Agent和裁定Agent它们属于典型的“协作幻觉”再删掉状态机和固化流程编排改成轻量的关键字段判断最后把四套记忆体系压缩成“最近5轮上下文 业务关键信息”的简单结构。向量检索暂时下线因为业务场景里的知识召回需求远没有想象中频繁。这次“删”不是一刀切。机制上保留了三个东西工具封装层、输出校验、以及少量经过验证的few-shot示例和常见问题预案。工具封装是有实际价值的因为真实业务必须对接订单系统、库存系统、售后工单系统这些接口不能让模型自己裸调输出校验能防止模型吐出不合法结构预案代码则像一个兜底网处理模型明显超出边界的情况。至于那些纯“架构感”的东西一律不留。4. 删除之后的形态所谓“无架构”到底长什么样删完之后整个Agent的核心逻辑变得非常朴素看起来甚至有点简陋。核心循环就一个import json from typing import List def run_agent(user_input: str, user_info: dict): messages build_messages(user_input, user_info) tools get_available_tools() for _ in range(MAX_TURNS): # 一般限制3轮 response llm.chat(messagesmessages, toolstools) if response.tool_calls: messages.append(response.message) for call in response.tool_calls: result execute_tool(call) messages.append({ role: tool, tool_call_id: call.id, content: json.dumps(result, ensure_asciiFalse) }) continue return validate_response(response.text) return fallback_response()就这些。没有Planner没有状态机没有反思层。模型根据工具列表自己决定调用哪些工具、按什么顺序调用、什么时候给出最终答案。这个设计能跑起来依赖的是当前模型已经具备的原生工具调用function calling能力——模型内部已经有“规划”的能力代码层再包一层Planner属于重复发明轮子。但如果你以为这个方案什么都不用管那就大错特错了。真正的工作量其实转移到了三个不那么显眼的地方。第一是工具列表的精简。我特意把工具数量控制在八个以内每个工具的docstring都写得极其详细参数类型、单位、返回结构、可能的异常输出、典型失败场景。比如订单查询工具的docstring里会写明“当订单状态为PAY_PENDING时用户的问题应该转向支付相关问题不要尝试售后流程”。模型会认真读这些描述来做决策工具描述写得越清晰模型用得越准。第二是提示词的结构。我放弃了长篇大论的任务说明只保留四块一句话身份、任务边界、动态工具说明、明确的兜底规则。其中兜底规则最重要比如“如果查询接口返回空结果必须向用户说明暂时无法获取信息禁止编造订单状态”。这一类硬约束是替代Verifier的关键。第三是输出结构校验。模型返回的最终回答必须符合预定义的JSON结构包含“回复文本”“是否需要人工介入”“命中的知识范围”三个字段。我会在代码里做一次校验不合格就把整段回复丢弃走兜底流程。这个校验不贵却能拦住很多幻觉输出。这套方案跑通后我才真正理解了那句话好的架构不是被“写”出来的是“生长”出来的。极简并不等于不做工程化而是把工程化用到刀刃上——代码管流程模型管判断。在这个形态下新增一个业务功能只需要加一个工具、改一段提示词不需要再跑到调度层加节点。5. 删除前后的量化对比一次完整评估删架构不是情怀得有实打实的数字支撑。我整理了同一批测试集、同一时段线上日志的关键指标这里列出来给大家参考。需要说明的是这些数字来自我实际经手的某个特定业务场景不保证普适但趋势很有代表性。指标删除前删除后变化任务完整解决率74%92%18%平均响应时长单次请求6.8秒2.4秒-65%单请求平均消耗Token约9.2k约4.1k-55%无效工具调用占比31%12%-19%新增一个知识范围的平均开发周期2.5天0.5天-80%人工介入率19%8%-11%其中响应时长的变化最直观。删除前用户问完一句话系统内部要对多个Agent进行串行调用删除后大部分请求一次模型调用就能完成最多再追加一两次工具调用。我做了一个小实验模拟用户感知同样的问题旧架构下等出答案的时间够我读完三行代码新架构下基本是“刚点完发送就看到回复”。这种体验差异对留存的影响比任何架构图都更有说服力。Token成本的下降也不难解释。多Agent架构意味着同一个用户问题会被不同的角色模型重复阅读每个角色都带着独立的长提示词。删掉这些冗余后单请求Token输入量直接腰斩。我算过一笔账如果一个月有十万次请求新架构能省下约五倍的Token费用这部分省下来的钱完全可以投入到更优质的模型选型上。但我也要泼一盆冷水这些数据不能简单归结为“删架构的功劳”。那一年模型本身也在快速变强B链路使用的模型版本就比A链路晚了两代功能调用能力、指令遵循能力都有明显提升。所以准确的说法是模型能力变强是前提删除冗余架构是放大器。如果你手里拿到的是当前最新一代模型却还在跑两年前那套多Agent重型框架那大概率是在给模型拖后腿。另外评估里最难量化但实际收益最大的一项是“调试时间”。删除前定位一个线上问题需要十几分钟删除后因为整体链路只有一条打开日志看工具调用序列和模型输出就能直接判断通常一两分钟就能定位。对于小团队来说这可太重要了。它直接决定了你一天能做多少事也决定了团队敢不敢频繁迭代。6. 架构删完之后踩的坑没有架构不等于可以不设防如果你以为删完架构就一马平川那就太天真了。新方案上线后我确实追了一段时间的问题但踩出来的坑完全不一样了。第一波问题基本集中在“模型自由度过大”上。以前有Verifier兜着模型就算想胡来后面还有一个检查环节。现在没有这一层了模型偶尔会胆子变大最典型的就是用户问了一个不在业务范围内的问题模型会尝试编造一个答案而不是承认自己不知道。我处理的办法是把“不得超出工具结果范围”写进提示词并在代码里做强制校验如果模型的回答引用了某个工具的结果而这个工具实际没有被调用过就判定为无效回答走兜底话术。这相当于把验证从“事后检查内容质量”改成“事前卡住引用来源”成本更低效果也更直接。第二个坑是工具门禁。删除向上编排后工具执行层成了整个系统的命门。如果订单查询接口超时模型会试图重试如果连续重试都失败它可能会编一个“系统繁忙”之外的模糊解释。我后来加了一个简单的规则单轮最多允许模型调用同一个工具两次超过就主动终止执行返回预设话术并标记人工介入。这个规则很死板但它把失败模式收敛成少数几种方便我持续优化。第三个坑更隐蔽是工具本身的“吸引力”。新Agent架构下模型是逐字阅读工具描述来决定行为的。如果某一天我加了一个功能强大但描述模糊的工具模型会倾向于频繁使用它哪怕这个工具跟用户问题根本不相关。我观察过一次离谱行为知识检索工具描述里写着“支持查询常见问题”结果用户问“退款多久到账”模型不去查售后工具反而去检索知识库拿回一段泛泛而谈的说明。后来我把工具描述改得非常精确强调“此工具用于查询政策文档不包含用户订单和售后处理信息”这种错配才明显减少。所以我的体会是删掉架构后你要盯的指标不是“有没有架构文档”而是“模型在哪些工具上浪费了次数”“哪句话术让用户重复追问”“哪个异常分支没有兜底”。工程化的工作量并没有消失只是从编排层转移到了提示词、工具设计和异常处理上。换句话说极简方案依然需要大量精细化工作只不过它的重心更靠近模型和工具本身远离了一堆空转的中间层。7. 复盘什么场景下“删架构”是蠢的什么场景下它是必要的写了这么多我必须把边界条件讲清楚否则这篇总结会误导不少人。这一个改动在我当时的业务里是正确的但它并不具备普适性。至少有三类场景下代码化编排和多Agent协作确实有用删了反而是灾难。第一类是强合规、强流程约束的场景。比如退款审批、理赔处理、工单派发这类任务的子步骤有严格顺序且每一步都需要留痕。如果一个Agent在理赔流程里“自由发挥”先给用户放款再走风控业务上绝对不可接受。这种场景必须用代码状态机把流程钉死LLM只能充当某个节点上的判断器不能拥有全局调度权。我后来在另一个偏风控的项目里就老老实实保留了大量代码化约束绝不套用极简方案。第二类是高并发下的任务分拆场景。当一个任务需要并行查询多个独立数据源或者需要在多个子任务间做优先级调度时一个简单的单循环就明显不够了。这时候需要队列、任务派发和合并层。你要是硬拿单Agent去扛模型会变成瓶颈而且工具并发也不好控制。这类场景的重点已经从“模型智能”变成了“并发工程”删架构属于自残。第三类是子步骤之间存在强依赖且错误代价极高的场景。虽然当前模型规划能力强了很多但在某些专业领域错误规划一次的成本可能是几十万。这时候用代码把依赖顺序固定下来比让模型自由决定更稳妥。判断标准很简单错误的代价越高越应该用代码兜底而不是信任模型临场发挥。我个人的判断原则就一条任何架构组件从Planner到多Agent协作从反思层到向量记忆都必须能回答一个问题——它到底解决了哪个具体问题去掉它之后哪个指标会变差。如果指标说不出来这个组件大概率就是负资产。你不需要一步到位的全面极简但最好每半年审视一次整个系统把那些无法量化价值的层删掉让架构保持与业务复杂度匹配的状态。说真的删掉那套架构之后我做Agent最大的感受是所谓智能本来就应该尽量减少代码层面的“自以为聪明”。代码擅长的是流程、校验、并发、异常处理而判断、规划、语言表达这些应该更多地交给模型自己。把两者边界划清楚比维护一个华丽的分层架构重要得多。