Agent架构越复杂效果越差？A/B测试揭示删掉一半后反而更好

1. 先说结论：那次 A/B 测试的赢家，是被我删掉一半的“半成品”

去年年中，我手头有一个已经跑了大半年的 Agent 项目，内部代号就叫“群聊管家”。它做的事情不复杂：把用户群里零散的问题收集起来，按主题分组、去重、补充背景，再生成一份可直接用的工作纪要。听起来简单，但用户群里有销售、有技术、有运营，同一个问题在不同人嘴里完全不是一个问法，而且有些问题需要翻一周前的聊天记录才能回答。于是我像大多数做 Agent 的人一样，叠了一套很有“仪式感”的架构：意图识别、任务路由、多智能体协作、反思修正、长短期记忆，层层封装，每个模块都觉得自己很必要。

转折点是一次被逼无奈的 A/B 测试。当时为了验证新加的记忆模块到底有没有用，我把整套系统对半砍：一半走完整架构，另一半只保留“检索+单轮生成”的最简链路，连上下文整理层都去掉了。本来只是想给完整版提供一个“低配对照组”，结果跑了一周混合真实流量，几乎每一个关键指标上都打输了。

用一句最直白的话总结这一年：效果提升最大的一次改动，不是加了什么，而是我把精心设计的架构删了。

下面我会把当时的完整思考链路、测试数据、以及删完之后我拿什么替代这些“架构能力”的过程写清楚，全程基于真实项目复盘。如果你也在做 Agent，正被各种编排框架、Agent 框架、多层规划弄得头大，这篇应该能给你一个完全不同的思路。

2. 我原来那套“豪华架构”到底长什么样，以及为什么当初非搭不可

2.1 从需求到上线，我经历的三个架构阶段

最开始这个项目只有一个 Prompt，模型直接读取七天关键词和对话摘要，然后输出纪要。准确率大概 60% 出头，典型的问题是：问“报价单发了吗”这种简短问题时，模型因为没有上下文，会自由发挥编出一个人名。于是第一个月我做了检索增强：把全员聊天记录灌进向量库，回答问题前先按语义召回最近三天相关内容，再注入提示词。这一步把准确率提到了 72% 左右，算是真正能用了。

但到了第二个月，用户提出了新的要求：希望纪要能按部门归类、自动标记待办事项、并且把同一个问题的多个回复给去重合并。单模型单检索已经明显带不动了，因为同一个 Prompt 里既要承担判断、又要承担总结、还要承担分类，指令冲突很严重。这就是我决定上完整架构的直接原因：不是跟风，而是当时单链路口径下确实出现了能力瓶颈。

2.2 五个模块的完整架构，以及每层落地时的“当时正当理由”

当时设计的架构是这样的，每个模块都有一套我认为无懈可击的设计逻辑：

• 意图识别与路由层：先用一个轻量模型判断用户请求属于哪一类（查资料、做总结、安排日程、回答具体问题），然后把不同请求转到不同的处理链路。理由：单一 Prompt 不擅长处理不同类型的任务，分类后再处理可以降低指令冲突。
• 任务规划层：负责拆解请求。比如“这周有哪些重要事项需要跟进”，会被拆成“提取本周聊天记录-筛选重要内容-匹配项目名称-生成待办”。规划器自己写了任务清单和执行顺序，理由是让 Agent 具备复杂的多步推理能力。
• 子 Agent 执行层：底下一堆专门的子 Agent，每个只干一类事，比如“纪要撰写 Agent”“待办提取 Agent”“上下文检索 Agent”。理由是专业分工、互不干扰。
• 记忆模块：短期记忆存当前会话的上下文，长期记忆存跨会话的用户偏好和历史决策。理由是不用每次把全部记录塞进模型，节省 Token 并提升个性化。
• 反思与修正层：每次生成完最终答案，再用一个独立的“反思 Agent”去检查输出有没有遗漏、有没有幻觉、格式对不对，发现问题就自动重写一版。理由是提高输出质量，降低模型幻觉概率。

从纸上流程来看，这几乎是一个接近企业级标准的 Agent 架构，每一层都有它“应该有用”的理由，每一层的设计我都能找到对应的论文或开源项目作为参考。当时我甚至觉得架构还不够完整，还在考虑要不要加一个评估器模块，给生成内容自动打分。

2.3 为什么当时完全没意识到复杂度本身是负担

事后复盘，我觉得最根本的原因是：那段时间我衡量系统好坏的方式变了。我不再看用户反馈和实际效果好不好，而开始看架构本身“像不像一个成熟产品”。每次跑通一个模块，都会有一种“系统更强大了”的错觉，因为模块数量多了、流程复杂了、日志好看了。这种心态非常危险——它让你把中间过程的复杂度误认为最终效果。让我意识到这个问题的，不是自我反思，而是那段被逼着做的 A/B 测试。

3. A/B 测试的意外结果：低配版把我精心设计的架构打回了原形

3.1 测试设计：我如何控制变量、构建评估集，以及打分的细节

当时测试做得很仓促，现在看反而歪打正着。我把系统接进了企业微信的一个真实工作群，随机分流真实用户请求：50% 走“完整版”，50% 走“低配版”，连续跑 5 个工作日。评估维度不是简单地看好不好，而是五个人工指标，每个维度 1 到 5 分，由三个评审人员独立打分再取平均：

• 信息完整性：纪要是否覆盖了用户请求涉及的所有关键点
• 事实准确性：引用的人名、时间、链接、项目名是否真实存在
• 结构化程度：待办、负责人、截止时间是否清晰可分
• 去重合理性：多个回复是否被合理合并，有没有漏合并或误合并
• 整体满意度：如果这是别人交到你手上的纪要，你愿不愿意直接转发

评估集一共 37 条真实请求，覆盖四种类型：查资料、总结讨论、生成待办、多轮追问。每条请求都会补齐真实聊天背景。我没有用模型评测打分，因为当时项目没有预算做复杂的 LLM-as-Judge，而且以我后来的经验，人工虽然慢，但结果最可靠。

3.2 五个核心指标的完整数据：低配版赢在哪，输在哪

结果如下表，分数为三名评审的平均值：

完整版唯一赢的是结构化程度，但优势极微弱。事实准确性差了 1.1 分，这个数字在人工打分里已经算巨大差异。我一开始不信，觉得肯定是评估集里有偏差，于是打开低配版的输出人工看了一遍，结果发现它甚至比完整版更简洁：直接把检索到的内容按时间线列出，在开头加了一句话“以下内容基于 6 月 3 日至 6 月 5 日群聊记录整理”，没有多余修饰，反而显得很可信。

完整版的问题集中在两个点：一是意图路由层偶尔把“查资料”的请求误判成“生成待办”，导致整个链路跑偏；二是反思 Agent 在重写时常常把原文中的准确信息改成了模棱两可的表述，比如把“周三下午三点”改成“本周中下午”。看完整版生成结果的时候，我最大的感受是：它看起来很有条理，但每条条理里都藏着一点不确定性。

3.3 第二轮验证：用另一个项目验证，确认这不是个例

为了排除偶然因素，我又用另一个内部工具类 Agent 项目做了一轮同样的对照。那个项目是做合同要点提取的，原本同样带着子 Agent 分工和反思修正。这次我没有像上次那样同时跑两套，而是直接把反思层停掉，并且把路由层换成了一个硬编码的 if 规则。跑了两周，用户反馈我收到的几乎是正向评价：“生成费眼睛的问题少了”“提取的要点比以前的版本直接”。合同的条款数量和原文一致性都有小幅上升，尤其是不再出现“模型自己加了半句话”的幻觉情况。

到这里，我已经不得不承认一件事：我当时精心设计的复杂架构，对效果不仅没有正贡献，反而是负贡献。

4. 拆解根因：为什么架构越复杂，Agent 效果反而越差

4.1 三层“中间过程”稀释了上下文预算，需求信息层层打折

最直观的问题出在 Token 预算上。我当时完整版架构的处理流程是：意图识别层读一遍完整上下文（约 8K Token），把压缩后的用户意图传给规划层；规划层再读一遍意图和部分上下文（约 4K Token），输出任务清单；执行层每个子 Agent 又读一遍各自需要的部分。每一个环节看似都拿到了“经过处理”的信息，但实际上压缩过程就在持续丢信息。

举例说明：用户问“合同那个事到底定了没”，意图识别层判断这是“查进度”，于是把上下文里的合同讨论细节压缩成一句话“用户询问合同进度”；规划层拿到这句话后，又把任务拆成“检索合同相关消息-确认当前状态-输出结论”；等到执行层真正去检索时，它已经不知道该检索“合同条款里的付款条件”还是“合同签订进度”。模型不是没有能力回答，而是喂给它的原材料在每一层都被压缩了一遍，轮子还没转完，关键信息早丢了。

低配版的做法恰恰不同：直接把一周内的群聊消息全部塞进 Prompt，只做简单的时间过滤，模型自己决定关注哪部分。完整的原始上下文和明确的任务目标放在同一个窗口里，信息没有中间层损耗，准确率自然上去了。

4.2 分层引入的立场固化：每一层都在把模型往错误方向上推

这个点是我认为最核心的机制性问题。单模型生成时，模型看到的是“原始信息+任务指令”，它只能基于内容本身给出判断；而多层架构下，每一层都在给后一层“预设立场”。

举个例子，原始信息本来是“张三说合同周四发，李四说希望周三前拿到”，如果把这个原始信息直接给模型，模型能产出“双方存在时间冲突，建议确认优先级”这种合理判断。但完整架构下，意图识别层可能先判断“这是待办整理”，然后规划层再预设立场“目标是生成待办清单”，等到执行层看到的内容已经被压缩成“张三周四发合同，李四周三要”，执行层只会机械地把它拆成两条待办，完全看不到其中的矛盾点。

更严重的是反思层：反思 Agent 的任务是“挑错并重写”，为了完成任务，它天然倾向于对原文做修改，甚至修改那些本来就正确的内容。模型没有“不该改的不要动”这种天然的保守性，它会在重写过程中把模糊不清的表述替换成它自己认为更合理的表述，哪怕原文其实更精确。我在复盘中发现，完整版出现的误写案例里，有一大半是反思层“多此一举”造成的。

4.3 评估失焦：我们在优化架构指标，而不是最终用户体验

还有一点必须讲清楚：不是所有复杂架构都一定差，但复杂架构会悄悄改变你的优化目标。单模型系统里，你只能优化“最终回答质量”，因为中间没有东西可供你把控；而多层架构下，你可以优化的东西突然多了一大堆：路由准确率、规划成功率、子任务完成率、记忆命中率、反思修改率。每一个看起来都是合理的优化对象，但它们全部偏离了最终目标。

当我知道“意图识别准确率已经达到 93%”时，我会默认整套系统会更可靠；但事实上，路由准确率再高，只要剩下 7% 的路由错误，后果就是整个链路错误。低配版不需要路由，也就没有路由错误这个概念。架构越复杂，任何一个中间环节的失误都会被放大到最终结果里，而你完全无法通过优化中间环节来挽回最终结果。我手上的数据也印证了这一点：完整版的端到端错误率并不等于各个子模块错误率之和，而是明显更高。

4.4 代码可维护性和调试成本，比模型效果下降更致命

这个属于是被测试数据淹没的隐藏问题。完整版架构上线后的调试灾难，现在想起来还会头皮发麻：每次用户投诉一个输出不好，我得花半个小时沿着日志从上到下翻，判断是意图识别误判了、规划器漏拆了、子 Agent 检索没覆盖到、还是反思层又乱改？整整五个排查点，任何一个都可能是问题源头。

更有意思的是，多层架构修 bug 也会互相牵连。我曾经为了提高“结构化程度”，修改了任务规划层的 Prompt，结果直接导致意图识别层的判断逻辑也跟着变了，一周内出现了一批以前不会有的路由误判。到后来我修一个 bug 要跑三遍回归测试，代码不敢乱动，整个项目变成了一个碰哪哪碎的大型瓷器。删掉架构之后，所有问题都收敛到了“检索环节和生成环节”两处，排查代码行数直接少了一半。

5. 删完之后，我拿什么接住了原来的“架构能力”

5.1 放弃“模型牌”路由和规划：用确定性的规则与流程来兜底

把多层架构删掉之后，有一个现实问题必须解决：原来意图识别层和规划层的功能怎么办？难道直接退回到一个什么都不会的裸模型？我的方案是：把本该由模型承担的分类、路由、规划逻辑，全部改成硬编码规则和外部流程，让模型回到它最擅长的事情。

具体做法分三层：

第一层，用一套关键词规则做初筛。比如用户请求里含有“定”“没”“呢”“什么情况”这些词，优先走“进度查询”链路；含有“总结”“纪要”“整理”则走“纪要生成”链路；含有“待办”“安排”“跟进”则走“任务提取”链路。这套规则在真实数据上命中率能到 80% 以上，剩下 20% 命中不了的，不硬判，直接丢给模型让它自己结合上下文判断，而不是让路由层强行给它指派一个错误方向。

第二层，把“规划”内置到 Prompt 的固定指令里。原来的规划层是动态生成任务清单，现在我只用一个固定模板：“先检索最近 X 天群聊记录，再按时间顺序整理关键主张，再判断当前状态，最后列出待办和负责人”，把流程写死在提示词里。模型只需要执行，不需要自己决定先做什么后做什么。

第三层，把明显的依赖关系变成外部脚本。比如需要去重时，先用一个简单的哈希算法把相似消息聚类，再把聚类结果喂给模型；需要提取时间时，用一个正则表达式先做第一步筛选，模型只需处理规则筛不掉的情况。通过这一通操作，原来“规划层”要做的 90% 的工作，都用确定性代码替代了，模型只需要做它唯一擅长的事情：理解上下文语义并生成自然的文字。

5.2 把复杂度转移到了“工具”和“提示词”上，而不是“系统流程”上

很多人会问：这么多规则，不也是一种复杂度吗？是的，物理复杂度总量并没有减少，但它完成了一次转移：从“运行时的模型决策复杂度”转移到“开发时的一次性编码复杂度”。这是天壤之别：开发时一次性编码哪怕多写 200 行代码，程序跑起来稳定、可预测；而运行时模型决策，每一次都可能产生不同的结果，飘忽不定。

转移到工具侧的例子：我用了一个封装了检索、去重、时间提取三个函数的工具库，模型只需调用一个接口，接口返回什么它就整理什么，不再需要模型自己写检索规划。转移到提示词侧的例子：通过一次性的长文 Prompt 编写，把领域知识直接写进去，比如“本系统服务于销售运营群，用户常提及‘定价表’‘报价单’‘试用申请’等，这些词必须原样保留”，这比让模型在运行时通过反思去学会保留术语靠谱得多。

5.3 删除后的最终线上数据：延迟、成本、人工介入率全面改善

删完架构之后，我在生产环境跑了整整三个月，和之前两个多月的复杂架构期做了完整对比：

延迟和 Token 消耗的下降是自然的，因为少了多层往返调用。让我更意外的是人工介入率从 22% 降到 10%：这意味着代理商自己处理的请求明显增多，系统真正“能自己干”的比例提高了。而代码模块减半，直接带来的影响就是维护压力变小，我再也不用每天盯着日志看是哪个中间环节出了问题。这些数据加在一起，才让我彻底下定决心：之前那套复杂架构不叫“架构”，叫“负担”。

6. 怎么判断你的 Agent 架构中哪些“该删”，哪些“该留”

6.1 三把尺子：从效果、调试难度、A/B 验证三个角度做判据

如果你的项目也正处在一个“架构越来越复杂”的阶段，我建议你用下面三把尺子逐一审视当前架构中的每一个模块，凡是三把尺子都不过关的，立刻删掉。

第一把尺子：它是否直接改善最终答案？看这个模块被去掉之后，最终输出是变好、变差、还是不变。只要是“不变”甚至“变差”，就说明它只是给你提供安心感，实际没有任何价值。我在测试记忆模块时就发现：去掉短期记忆模块之后，最终回答质量几乎没有变化，因为当下的上下文已经完全足够支撑生成。而事实上，短期记忆模块还为每次运行额外增加了约 3K Token 的消耗和一次额外的模型调用，纯属负资产。

第二把尺子：它是否降低了调试难度？模块有没有让“出现问题”变得更容易定位？如果引入一个模块后，你需要额外花费两倍时间排查问题，那不管它理论上能带来多大提升，都要考虑砍掉或重写。完整的链路追踪机制如果不到位，任何形式的复杂架构都会变成黑洞。

第三把尺子：它是否能通过最小改动方式的 A/B 验证？给每个模块单独做一次对照实验：打开它跑一周，关掉它跑一周，对比最终指标。如果结果没有显著差异，直接删。注意，实验的时间要足够长，至少覆盖一个完整的业务周期，否则容易被随机性欺骗。

我用这三把尺子重新审视遗留的系统时，发现需要保留的模块只剩下两类：一类是提升信息输入的（检索增强模块），一类是约束输出格式的（结构化输出模块）。其余的全部删除。这也对应了一个规律：在 Agent 项目里，真正有价值的是“输入端的准确”和“输出端的可控”，而中间环节越多，越容易变成噪音源。

6.2 从“架构优先”转向“最小架构优先”：像做特征工程一样做 Agent 编排

这句话是我这一年最大的认知转变。大部分人做 Agent 的思路是先设计一个完整架构，再往里填功能；但正确顺序应该反过来：先用最少的代码跑通一条完整链路，再根据实际数据，一个一个地把缺失的能力加回去。每一次加东西，都必须有数据支撑，而不是“感觉需要”。

这和机器学习里的特征工程非常像：一个优秀的机器学习工程师不会一开始就跟风加几百个特征，而是先跑一个最简单的 baseline，然后逐一验证特征的增量贡献。做过特征工程的人都深有体会：大多数花大功夫构造的特征，对模型效果的提升远小于预期，有时候甚至会把模型带偏。Agent 的“功能模块”和特征没有本质区别。

我现在做任何 Agent 项目，初始阶段只用三样东西：一个检索函数、一个 Prompt、一个格式化输出函数。跑通之后，再逐步加记忆、加工具、加人工评估流程。当你发现某个环节真的不够用，再去增加架构模块，这种增量式增加的架构，每一层都会经过实际场景验证，保留了确定能提升效果的部分。

6.3 什么时候“复杂架构”是必要的？以及什么样的复杂度值得保留

当然，我并不是说 Agent 的复杂架构一无是处。在两种情况下，复杂架构是必要的信任基石：一种是涉及多种独立数据源、需要严格权限隔离或审计追踪的企业级应用，流程本身需要结构化；另一种是有大量并行子任务、子任务之间有明确的静态依赖关系，人为编排比模型自由发挥更可靠。

即使是这两种情况，架构也应该由“确定的流程图”来承担，而不是靠“模型的动态规划能力”。也就是说，可以复杂，但要复杂在规则、脚本和可视化流程图里，不要复杂在“运行时让模型自己决定下一步”的自由度上。我的最终经验是：模型适合做局部的语义理解和文字生成，复杂的流程编排永远应该沉淀在确定性的系统代码里。当你想给 Agent 加一个新能力时，先问问自己：能不能用 20 行代码实现？能，就先把代码写了，把环节固定在流程中，别急着加一个模型角色。因为每加一个模型角色，你都不只是在加功能，而是在给系统增加一个不可控的自由参数。

7. 最后补几个细节：删的时候容易踩的坑，以及我当时的具体操作顺序

很多人看到这里可能会想：那我把架构全删了是不是就行了？没那么简单。删除也有删除的讲究，顺序不对可能造成项目断档几天无法运行。

我的建议操作顺序是这样的：第一步，保留检索模块和输出格式化模块，先把其他模块的服务拆掉；第二步，把路由层替换成硬编码规则时，不要一次到位，先用规则和模型并联跑一周，记录两者差异；第三步，关掉反思模块时，要接受前三天输出质量的暂时波动，因为模型需要适应没有外部挑错者的状态，其实适应之后会稳定下来；第四步，最后删记忆模块，因为你得先确认短期上下文和检索长文本能否完全覆盖业务场景，确定不行时，先用外部缓存，不要一开始就用记忆模型那种重方式。

如果你也在经历一个 Agent 项目从“看架构很好”到“效果始终不对”的迷茫期，我的建议只有一句话：先做减法，再做加法。你真正需要的，不一定是下一个更强的模型，也不一定是下一个更智能的模块，而是先把挡住模型发挥的东西清走。删掉那层多余架构之后，模型在里面舒舒服服地呼吸，效果自然就上来了。

我这一年最大的体会就是：删代码的时候心最疼，删完之后项目跑得最顺。