你的智能体 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。
陷阱三：在搞清楚任务之前就搞评估驱动开发
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- 完整文章，包含未公开存档的部分
- 可落地的工作框架，附带权衡与决策依据
- 新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部