最近一年我大部分精力都放在 Agent 的落地项目上从零搭过框架也接手过别人留下的框架还帮团队拆过好几套跑不动的“重型架构”。如果要我说这一年里对效果提升最大的一次改动是什么我的答案很直接把架构删了。做 Agent 的人很容易陷入一个惯性任务一复杂第一反应就是上多层编排、上记忆模块、上多智能体分工。我也不例外。去年上半年我曾经在一个项目上用了一套看起来很完整的架构结果每次改需求都要动五六个模块模型的表现还越来越差。后来我花了差不多两周时间把那套架构一层层拆掉最后只留下一个几乎“没有架构”的最小闭环。效果反而全面变好成功率更高延迟更低Token 消耗更少团队迭代速度也上来了。这篇文章就围绕“删架构”这件事展开。哪些东西可以删、为什么删了反而更好、什么时候又不能乱删以及我在实操中踩过的坑。如果你是刚接触 Agent 的新手这篇文章可以帮你少走一段“过度设计”的弯路如果你已经做了一段时间 Agent正被自己搭的框架搞得头大那这篇文章很可能就是你现在需要的那剂解药。1. 我最初是怎么把 Agent 做“重”的1.1 当时那套架构的完整结构去年年初我做第一个正式交付的 Agent 项目时参考了当时社区里流行的一套设计一共分了五层调度层一个中央协调器负责根据任务类型把请求分发给不同的子智能体。记忆层短期记忆用对话列表存长期记忆挂了向量库还有一层语义缓存。规划层任务进来先拆解成子任务生成执行计划再让执行模块逐一完成。工具层封装了工具注册、参数校验、重试、超时、权限校验这些逻辑。多智能体协同层研究员、写作员、审校员等角色各自独立通过消息队列传递中间结果。那套系统加上配置文件、prompt 模板、数据库表结构代码量大概是五六千行。说实话我当时写的时候是有成就感的毕竟架构图一画出来各层之间职责分明看起来特别“工程化”。1.2 当时为什么选择这种设计现在回头想选择重型架构的原因很现实社区里的最佳实践、框架默认推荐的都是这类复杂编排照着做心里踏实。项目规划阶段要给团队展示“工程化能力”层数越多看起来越专业。大家默认复杂任务必然需要复杂流程单靠提示词怎么能处理长链路任务。第三个隐藏原因是虚荣心架构图画得越复杂越觉得自己在做一件有门槛的事。但项目跑起来之后问题开始一个一个显性化。先是响应变慢然后是 Token 账单吓人再后来是改需求动辄改十几个文件。真正让我下决心删架构的是一次性能评估同一个任务旧架构跑出来的效果竟然不如一个只有三层结构的临时 Demo。那次的冲击非常大。2. 重型架构让效果变差的三个真实原因2.1 每层抽象都在吃 Token模型在给流程“打工”这是一个最基础、也最容易被忽略的问题大模型每走一步都要重新读一遍上下文。任务经过调度层、规划层、多智能体层每个模块都往上下文里塞东西。最后模型看到的上下文里真正和用户任务相关的信息可能只占三成剩下全是流程指令、角色设定、中间结果标记。我举一个真实例子。某文档问答任务用户只是问“这份文档里有没有提到支付流程”在旧架构里会走意图识别、任务规划、检索、答案生成、审校五个环节累计消耗大概 8000 Token响应要 4 到 6 秒。后来我用最直接的方式重写给模型一个搜索工具让它自己翻文档1200 Token、1 秒出头就能返回正确答案。这个问题的本质可以类比成一个组织三个人能干完的活非要配一个分管副总、两个总监和一个项目经理每一级都在写汇报材料。模型就是那个真正干活的员工却被各种流程文档淹没。Token 不只是成本问题也是质量问题。模型注意力是有限的上下文越臃肿模型越容易漏掉关键信息。就像一个员工的工位堆满了无关纸张那份真正重要的合同反而找不到了。2.2 中间信息不落“地”错误层层放大重型架构的第二个坑是错误累积。规划层生成一份计划执行层照着做审校层再做检查。但问题是整个链条里每一层处理后的中间结果都只是内存里的一个对象没有真实的数据校验。一旦规划层对用户任务的理解出现偏差后面所有层都会沿着这个偏差往下走。更麻烦的是审校层往往只是检查“内部一致性”——前面的结论和后面的结论是否自洽而不是去验证“结论是否和真实数据相符”。于是系统会非常自信地输出一个结构完整、逻辑自洽、但根上就错的结果。我印象最深的一次某数据分析 Agent 在旧架构下跑一个数据复盘任务规划层把“近三十天”理解成了“近三个月”后面的检索、计算、报告生成全部基于这个错误的时间范围。审校层把所有结论都复核了一遍愣是没发现问题最后交付了一份完全错误的周报。问题不在模型能力而在链条太长中间没有任何一步去对照原始需求。错误累积的数学很直接假设单步准确率 95%一个五步的链条端到端准确率就掉到 77%如果单步只有 90%五步之后只剩 59%。而一个单步闭环哪怕单步准确率只有 88%它也只需要承担一步的损失。2.3 找 bug 变成“翻框架源码”迭代速度被拖垮重型架构的第三个坑是调试成本。任务出错时第一件事不是看模型输出而是查消息队列有没有丢消息、JSON 解析是不是挂了、重试逻辑是不是触发了、调度器是不是把任务分给了错误的子智能体。有一段时间团队改一个 prompt 都要半小时才能生效因为 prompt 藏在某个子智能体的配置文件里而这个配置文件的加载依赖框架的初始化顺序。我花在“理解框架在干什么”上的时间比花在“让模型把事做对”上的时间还多。这其实是很多 Agent 项目悄悄失败的原因大家以为问题出在模型实际是出在流程本身。过重的架构就像一层毛玻璃你想看清模型真实的行为却被中间那层滤掉了。3. 删完之后我最终留下的最小闭环3.1 核心循环其实只有一条用代码来描述整个循环大概是这个样子def run_agent(user_task, tools, model_fn, max_steps8): messages [{role: system, content: SYSTEM_PROMPT}] messages.append({role: user, content: user_task}) for _ in range(max_steps): response model_fn(messages) messages.append({role: assistant, content: response}) action parse_action(response) # 解析结果只有两种要么调用某个工具要么给出最终答案 if action[type] final: return action[answer] tool_result execute_tool(tools, action[tool], action[args]) # 工具返回统一截断防止上下文被撑爆 messages.append({ role: user, content: f工具[{action[tool]}]返回\n{truncate(tool_result, 2000)} }) return 达到最大步数返回当前结论没有规划器、没有记忆模块、没有多智能体消息总线。模型每轮看的是“系统提示词 历史对话 最新的工具返回”然后自己决定下一步是继续调工具还是给出答案。这个循环为什么有效因为它把决策权完全交给了模型而不是让一整套流程替模型做决策。模型的上下文里只有真正和任务相关的信息不会被各种流程脚手架稀释。这不是我拍脑袋想出来的是拿旧架构和新循环在同一组任务上反复对比之后数据告诉我的结论。3.2 没有“记忆模块”之后我用几条纪律替代它原来有独立的记忆模块后来删了。替代它的不是新模块而是几条非常具体的上下文管理纪律系统提示词控制在 1000 字以内只写角色的工作准则和工具清单不写具体业务细节。每轮工具返回统一截断到 2000 字。超长文档不做全文投递而是先切片再用检索工具去查。历史对话超过一定规模比如累计约 1 万字时先把前面的内容压缩成一段摘要再用摘要替换最旧的部分。摘要的生成也交给同一个模型用一条固定指令触发。如果用户上传大文件先做预处理把文件切成带编号的片段然后给模型一个索引让它自己选择查询哪些片段。这些规则我没有写成类而是直接写在系统提示词里。好处是逻辑清晰、可解释性强想改规则只需要改一段文字不需要改代码、不需要发版。说白了就是把“架构层”的决策降维成“数据层”和“提示词层”的决策。3.3 工具层只保留三个抽象原来的工具层有注册、校验、重试、超时、权限、日志总共六个模块。删到最后我只保留了三个注册表把工具名、工具描述、执行函数登记进一张表。权限开关涉及外部写操作或敏感操作的工具默认要求用户确认不在模型侧直接执行。错误归一化工具抛出的异常统一转成一行人类可读的文本塞回给模型让模型自己尝试解释或换一种调用方式。这三个抽象不是给流程用的是给“模型的输入和输出”用的。它们不参与决策只负责让模型拿到干净、够用、安全的信息。其余的比如重试、超时用简单的装饰器在外层解决不再单独成模块。工具层变薄之后新增一个工具的成本从“改六个文件”变成了“写一个函数 加一行注册”。4. 一场真实的对比某客服分流智能体重构前后4.1 重构前的多智能体方案去年下半年我负责的某客服分流智能体 Demo 进入第二轮迭代。这个项目目标很明确用户发来一段问题系统判断意图决定是直接答复、查订单、还是转人工。第一版我用的是多智能体方案一个意图识别智能体、一个情绪识别智能体、一个分流决策智能体外层再挂一个协调器。每个智能体都有自己的系统提示词协调器负责把用户消息广播给三个子智能体等三份结果都回来再汇总决策。加上重试、超时、日志代码接近六千行。这个方案跑起来之后问题很明显三个智能体看到的是同一份用户消息等于同一份输入被解析了三次协调器必须等最慢的那个返回才能决策而且三个智能体输出格式有小差异协调器经常因为解析其中一个字段失败而整体报错。4.2 重构后的单智能体方案重构时我删掉了三个子智能体和协调器只保留一个智能体给它注册了三个工具查订单工具、查常用答复模板工具、发起转人工指令。系统提示词只写了三件事这个智能体是客服助手、遇到哪些情况用哪个工具、拿不准就转人工。用户消息进来之后不经过任何中间模块直接进入上一节那个最小循环。模型自己会判断这个问题要不要查订单要不要翻模板要不要直接给出答复。只有当它明确判断需要转人工时才调用转人工工具。4.3 重构前后的指标对比指标重构前多智能体重构后单智能体最小闭环意图识别准确率91%94%端到端任务成功率83%95%平均响应时长2.8 秒1.2 秒单请求平均 Token 消耗52002100核心代码量6000 行1200 行新需求从提需求到上线3 天0.5 天注意准确率数据来自内部评估集场景有限不同项目数字会有差异但“成功率上升、Token 下降、迭代变快”这个趋势是稳定的。4.4 为什么差距这么大端到端成功率从 83% 提到 95%不是因为模型底层能力突然变强而是失败面变小了。旧方案里有三个子智能体加一个协调器任何一个环节解析失败、超时、或者子智能体给出的结果被协调器误解都会变成一次失败。删掉之后失败的来源就只剩一个模型在单个环节里判断错了。Token 消耗减半是因为同一个任务不再被三个智能体各读一遍也不再需要协调器在最后把三份结果汇总成一份。响应时长降低是因为少了两轮调度等待。最让我意外的是迭代速度的变化。重构之后要加一类新的用户问题只需要在工具表里加一个工具或者在系统提示词里加一条规则改完立刻可测。而旧架构里加一个新意图往往需要同步改三个子智能体和协调器一次需求改动动辄十几个文件。5. 什么时候别跟风“删架构”5.1 判断该不该删先看三条标准虽然我这一年靠删架构拿到了效果提升但我并不主张无脑删。删之前先自问三个问题第一你有没有可靠的评估集如果没有先建一个。删除架构的理由必须是数据不是感觉。我重构客服分流项目之前先拿三个月的历史对话做了标注数据集用同一套测试集测旧方案和新方案才有底气往下走。第二任务真正需要的操作步数有多少如果典型任务只需要几步工具调用简单循环就够如果任务需要几十步独立操作、每步之间存在必须人工确认的质量节点那还是要保留一定的流程控制。第三任务失败后的代价有多大涉及支付、合规、健康等高风险场景强制节点、审批流、可追溯审计是必要的这些不能因为追求简洁而删掉。5.2 这四类场景仍然需要结构根据我的经验下面四类场景不要轻易把结构全删长周期任务比如一个需要跨越多个时段、每完成一步都要存档的调研任务必须把进度持久化否则模型一旦超时重启前面的工作就全丢了。多步安全审批比如生成对外发布的文案要求“先写草稿、再走审核、审核通过才允许发送”这类强制的状态流转不是流程噪音是合规底线。严格结构化输出如果模型结果要直接喂给下游业务系统且字段有强约束那就需要一个独立的校验层而不是让模型自由发挥。大规模并行子任务比如一次要分析一百份文档单循环逐个跑太慢需要拆分成并行任务并对结果做汇总。5.3 保留结构的正确姿势把流程写进数据和提示词而不是写进框架代码如果确实需要结构我现在的做法是把流程描述成数据。比如一个三步调研工作流我会定义一份 JSON 格式的工作流配置包含每步的任务描述、输入输出字段、允许调用的工具范围。模型不直接面对整个流程它只看当前这一步的指令执行完把结果按约定格式交回由外层一个非常薄的调度器把结果填入下一步的输入。这样做的区别在于流程仍然存在但它不是散落在代码里的逻辑而是可以在评估集上观察、可以随时修改的一份数据。模型永远是“被数据驱动”的而不是“被一堆类和方法驱动”的。我见过很多团队的 Agent 项目死在反向把简单任务塞进重型框架最后连维护框架本身都成了全职工作。6. 实操中容易踩的坑和排查技巧实录6.1 常见问题速查表现象大概率原因处理办法删掉架构后模型频繁漏调用工具工具描述写得太抽象模型不知道何时该用重写工具描述增加“适合使用的场景示例”和“不适合使用的场景示例”多轮对话越聊越偏历史没有裁剪旧信息干扰新决策设置上下文规模阈值触发后做滚动摘要模型在同一个工具上陷入死循环没有最大步数限制或工具返回内容一直没变化加最大步数上限对重复调用去重把“该工具刚用过且结果未变”提示回传简单任务快复杂任务烂前置的“任务复杂度判断”缺失在循环前加一次轻量分类复杂任务走保留的轻量工作流删得太猛完全不可观测日志没有留全删除架构前先加结构化日志至少保留输入、输出、每次工具调用的参数和结果模型自己“脑补”了工具结果工具异常被吞掉没把错误文本回传工具错误统一归一化成文本并回传让模型看到真实错误再决定下一步6.2 我实践下来的删除顺序删架构这事不建议一步到位。我实际操作时按这个顺序走先冻结工具清单。所有模型可能用到的工具先统一成同一套函数接口保证删除过程中模型需要的能力不丢。全量留日志。每一步模型输出、每次工具调用参数、工具返回结果全部落盘。删完之后出现问题可以回放定位。新旧并行跑一周。新方案和旧方案同时接一份影子流量只观察不切换用评估集对比指标。一次只删一层。先删多智能体协同观察三天再删规划层再观察。不要一次性把五层全部拆掉否则出了问题根本不知道是哪一层引起的。留好回滚开关。把新方案做成一个可配置开关出现严重问题时一键切回旧方案。删除过程中产生的“新需求”先记进 backlog。很多时候删了一层之后会觉得“这里是不是还缺个模块”别急着加先记下来等评估数据说话。6.3 我现在的迭代检查清单现在每逢我自己或者团队成员想往一个 Agent 项目里加新模块我都会先过一遍这份清单这个新模块能让模型直接看到更多真实数据吗如果只是一层新的流程封装大概率不必要。它能用评估集证明收益吗不能证明的抽象都是潜在的复杂度负债。如果删掉它最坏情况是什么写下来判断能不能接受。它增加了可观测性还是降低了可观测性一个让调试变困难的东西再漂亮也先不碰。我把这套清单用在自己所有 Agent 项目上之后最大的感受是现在改一个 Agent百分之八十的时间花在调数据、调工具描述、看评估结果上而不是花在理解“系统为什么这样跑”上。我个人这一年的体会比较朴素——大模型的底层能力已经很能打了真正拖后腿的往往不是单步能力而是我们给模型套上的那层壳。删架构不是偷懒也不是否定工程化而是把复杂度放回它该在的地方数据和评估里。如果你手上正有一套跑不动的重型 Agent我建议你先别急着加更复杂的模块试试把架构删掉一层然后让评估集来告诉你答案。