AI 中的第二系统效应：为什么你的智能体 v2 重写大概率会失败

你的智能体 v1 能用。它很丑，靠提示词胶带勉强维持，每次打开代码都让你皱眉。但它能处理 90% 的情况，用户很满意，每天都在创造价值。于是你自然而然地决定：从头重写。

六个月后，重写版本仍未上线。你迁移了两次框架，为一个根本不需要的问题搭建了多智能体编排层，评估套件测试的全是那些从不出错的地方，真正容易崩溃的地方一个没测。与此同时，v1 依然在跑——依然很丑，依然好用。

这就是第二系统效应，它在我们大多数人出生之前就已经摧毁了无数软件项目。

一个与软件同龄的规律

1975 年，Fred Brooks 描述了他在 IBM 观察到的一个现象：当一位架构师设计他的第二个系统时，它会成为他一生中最危险的系统。第一个系统之所以"简洁干净"，是因为设计者谨慎、尚在学习、被不确定性所约束。第二个系统则吸收了第一个系统中所有被推迟的功能、所有曾经显得过早的优化，以及所有"最好加上"的泛化。结果就是：臃肿、延期，而且往往比它所取代的东西更差。

Brooks 描述的是 IBM 从相对简单的 700/7000 系列操作系统向野心勃勃的 OS/360 的灾难性过渡。这一规律在此后计算机的每个时代中反复重演。而现在，它正在 AI 智能体生态系统中大规模重演。

各方面条件几乎完美地契合：智能体 v1 始终是一个出乎所有人意料地能用的原型。团队积累了一长串想要修复的妥协之处。某个新框架承诺能解决他们遇到的问题。然后，通常是最资深的工程师，说出了那句魔咒："这次我们应该彻底重写，好好做一遍。"

三种过度工程化陷阱

智能体重写的失败，不是因为团队能力不足，而是因为一些可预见的过度工程化模式——这些模式在当下看起来像是正确的工程决策。

陷阱一：过早引入多智能体架构

当前智能体生态中最昂贵的错误，就是在还没穷尽单智能体能力之前就急着上多智能体编排。对 47 个生产 AI 部署的分析发现，68% 的案例用架构良好的单智能体系统本可以达到同等甚至更好的结果。

成本差异毫不微妙。以一个每月处理 290 万次查询的客服系统为例，多智能体架构每月花费 47,000 美元，而单智能体方案只需 22,700 美元——准确率的提升仅有 2.1 个百分点。多智能体系统的 token 放大倍数高达 4.6 倍，其中大部分成本来自纯粹的协调开销。

调试惩罚更为严重。单智能体故障的平均解决时间是 18 分钟，多智能体故障则跳升至 67 分钟——增加了 3.7 倍。单智能体出错，你调试一个组件；多智能体工作流出错，你要跨智能体、跨协调逻辑、跨共享状态追踪交互链路。

团队选择多智能体，是因为它在架构上听起来很高级。但对于每月查询量低于 10,000、工作流线性的场景，单智能体系统 90% 的时间都能赢。只有月查询量超过 50,000、工作流具备真正并行性的情况下，多智能体的经济账才算得过来。

陷阱二：通过迁移陷入框架锁定

智能体框架的历史是一部昂贵迁移的墓志铭集。团队在某个框架上花三到六个月，触到天花板，然后面临 50–80% 的代码重写才能迁到另一个框架。有文献记录的案例中，一次三周的重写导致 60% 的代码库发生变化，并引入了两个生产故障。

第二系统效应的本能让这一切雪上加霜。重写时，你不只是搬运逻辑——你要"修复"一切。你完全采用新框架的惯用法，重构工具定义、状态管理、错误处理。每一项改动单独看都合理，但合在一起意味着：你在测试一个全新的系统，却期待旧系统那样的可靠性。

从经历过多次迁移的从业者那里得到的反直觉建议是：即便感觉杀鸡用牛刀，也要从一开始就选择上限高的框架。在框架中成长，远比从框架中迁出容易得多。LangGraph 的学习曲线需要 40–60 小时，CrewAI 需要 20–30 小时。但一个八人工程团队做迁移的第一年框架切换成本约为 11,600 美元——这还只是学习成本，不包括 bug。

陷阱三：在搞清楚任务之前就搞评估驱动开发

评估（eval）对于生产智能体至关重要。但在重写期间——在重写版本证明其基础架构可行之前——就构建一套全面的评估套件，是一种 Brooks 一眼就能认出来的过早优化。

团队迟迟不敢上线重写版本，因为评估不断暴露失败。但这些失败不在新系统的逻辑里，而在评估套件对系统应该做什么的假设上。团队最终花在维护评估工具上的时间，比基于评估结果采取行动的时间还要多。

务实的做法：从真实生产故障中提取 20–50 个简单测试用例作为起点。早期智能体系统的每一次改动都会产生清晰可见的影响。你不需要数百个任务来验证重写版本是否处理了真正重要的情况。先验证架构，再建全面的评估套件，而不是把评估套件当作前提条件。

为什么渐进式重构优于净室式重写

证据强烈支持渐进式改进，而非整体替换。遵循分阶段重构策略的生产 AI 系统能够在维持业务连续性的同时降低风险。持续迭代能将技术债从指数级问题变成下降曲线。

多步骤智能体工作流背后的数学让这一点更加具体。每步准确率为 85% 时，五步工作流的端到端成功率只有 44%，十步工作流降至 20%。一个增加编排复杂性的重写版本——更多步骤、更多协调、更多状态管理——即便每个单独组件都更好，也可能导致整体可靠性下降。

渐进式重构之所以有效，是因为它保留了重写唯一会丢掉的东西：经过生产验证的行为。你的 v1 智能体已经被数千次真实交互塑造。每一个丑陋的条件判断、每一个特殊情况的提示词，都是因为某个真实用户触发了真实的边界情况。从头重写，你会失去所有这些制度知识，只能通过生产故障重新发现它们。

绞杀榕模式——逐步替换运行中系统的各个组件，而非整体切换——天然契合智能体架构。先替换检索层，再改进工具定义，再重构提示词结构。每一步改动都可以独立地针对生产流量进行验证。

何时重写真正有必要

不是每次重写都是第二系统陷阱。有时基础架构确实无法支撑你需要构建的东西。决策框架归结为三个问题。

问题本身是否发生了根本性变化？ 如果你的智能体最初是一个问答机器人，现在需要执行有副作用的多步骤工作流，原有架构可能缺乏正确的基础能力。这是重建的正当理由——但重建的是架构，不是功能。把现有的提示词、工具和边界情况处理移植到新结构中。

你遇到的是框架级限制，还是应用级限制？ 如果框架不支持你需要的持久化、流式处理或状态管理，迁移可能是正当的。但如果你的问题出在提示词、工具定义或检索质量上，换个框架解决不了。团队经常把实际上是应用层的问题归咎于框架。

你能说清楚具体哪里会不同吗？ "更好的架构"和"更干净的代码"不够具体。如果你列不出重写能带来而渐进式重构无法实现的具体能力，你的动机大概是挫败感而非必要性。挫败感是合理的情绪，但是糟糕的工程需求说明。

克制的修炼

Brooks 应对第二系统效应的预防策略很简单：抵制功能装饰、让小功能的资源成本可见、确保有经验的架构领导力。翻译到智能体开发中：

• 抵制功能装饰。 你的重写版本应该做 v1 完全相同的事，只是做得更好。新能力在达到功能同等之后再加，而不是在重写过程中加。每一个"顺带加上"的功能都是进度风险和调试面。

• 让成本可见。 追踪每个架构决策的 token 用量、延迟和错误率。每次查询增加 4.8 秒延迟的多智能体协调是可量化的成本，不是抽象概念。

• 需要有经验的领导力。 Brooks 指出，最安全的设计者是构建过三个或更多系统的人，而不是两个。在智能体开发中，这意味着需要有人真正把多个智能体送上过生产——而不是只读过智能体架构相关文章的人。

工程中最难的部分是知道什么时候不该构建。你的 v1 智能体之所以丑，是因为它在真实世界中运作，而真实世界就是很丑。一个让代码变漂亮却失去实战伤疤的重写，不是进步，而是披着净室外衣的退步。

在你启动那次重写之前，问问自己：我是在解决真实的架构限制，还是只是对那些看起来像是在压力下写出来的代码感到不舒服？因为它就是在压力下写出来的。这就是生产代码的样子。六个月之后，当现实发表了它的意见，下一个版本也将是同样的面貌。