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 五个核心指标的完整数据低配版赢在哪输在哪结果如下表分数为三名评审的平均值评估指标完整架构版5模块低配版检索单轮生成差距信息完整性3.94.40.5事实准确性3.24.31.1结构化程度4.13.8-0.3去重合理性3.54.10.6整体满意度3.44.20.8完整版唯一赢的是结构化程度但优势极微弱。事实准确性差了 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 删除后的最终线上数据延迟、成本、人工介入率全面改善删完架构之后我在生产环境跑了整整三个月和之前两个多月的复杂架构期做了完整对比指标复杂架构期简化架构期平均生成延迟约 9.5 秒约 3.2 秒单次请求平均 Token 消耗约 25K Token约 12K Token用户有效反馈率无投诉无退回约 68%约 87%人工介入修正比例约 22%约 10%代码模块数量18 个模块9 个模块延迟和 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 项目从“看架构很好”到“效果始终不对”的迷茫期我的建议只有一句话先做减法再做加法。你真正需要的不一定是下一个更强的模型也不一定是下一个更智能的模块而是先把挡住模型发挥的东西清走。删掉那层多余架构之后模型在里面舒舒服服地呼吸效果自然就上来了。我这一年最大的体会就是删代码的时候心最疼删完之后项目跑得最顺。
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 五个核心指标的完整数据低配版赢在哪输在哪结果如下表分数为三名评审的平均值评估指标完整架构版5模块低配版检索单轮生成差距信息完整性3.94.40.5事实准确性3.24.31.1结构化程度4.13.8-0.3去重合理性3.54.10.6整体满意度3.44.20.8完整版唯一赢的是结构化程度但优势极微弱。事实准确性差了 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 删除后的最终线上数据延迟、成本、人工介入率全面改善删完架构之后我在生产环境跑了整整三个月和之前两个多月的复杂架构期做了完整对比指标复杂架构期简化架构期平均生成延迟约 9.5 秒约 3.2 秒单次请求平均 Token 消耗约 25K Token约 12K Token用户有效反馈率无投诉无退回约 68%约 87%人工介入修正比例约 22%约 10%代码模块数量18 个模块9 个模块延迟和 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 项目从“看架构很好”到“效果始终不对”的迷茫期我的建议只有一句话先做减法再做加法。你真正需要的不一定是下一个更强的模型也不一定是下一个更智能的模块而是先把挡住模型发挥的东西清走。删掉那层多余架构之后模型在里面舒舒服服地呼吸效果自然就上来了。我这一年最大的体会就是删代码的时候心最疼删完之后项目跑得最顺。
