Agent 产品的软件腐化:一种新型技术债

引子

最近和 AI 讨论了一个有意思的话题:在 AI Native 时代,Agent 产品存在一种独特的”软件腐化”——它不是传统意义上的代码腐化,而是发生在智能层面的劣化。

传统软件腐化讲的是代码层面:重复、耦合、复杂度上升。Agent 腐化是另一种东西——系统逐渐变得更蠢、更僵化、更难迭代,而且这种劣化在常规指标上往往不可见。

一个典型场景

产品经理说:”用户一提到数据库,就推荐我们的数据库产品,这样能提升功能渗透率。”

技术团队加上了这条规则。渗透率确实上去了。

然后产品经理又说:”用户提到性能问题,就推荐我们的监控方案。”

又加了一条规则。

一年后,Agent 里有 50 条这样的规则。产品经理拿着一个”纯净版”Agent 对比说:”为什么我们的 Agent 比这个蠢这么多?技术团队要提高智能水平。”

技术团队:”……”

腐化的几种形态

1. 规则堆积 (Rule Accumulation)

每条规则单独看都合理,加起来就是:

• Prompt 越来越长,优先级冲突难以调试
• 模型的自主判断空间被不断压缩
• 改一个地方,另一个地方出 bug

最讽刺的是:你花钱买了 GPT-4 的智能,然后用 if-else 覆盖了它的判断。

2. 上下文膨胀 (Context Bloat)

为了让 Agent “更懂用户”,不断往 context 里塞东西:用户历史、产品信息、各种 metadata。

结果:上下文窗口被低价值信息填满,真正重要的信号被稀释,模型”注意力”被分散。

3. 工具蔓延 (Tool Sprawl)

一开始 5 个工具,边界清晰。后来 50 个工具,功能重叠,Agent 自己都不知道该调哪个。

工具选择错误率上升,维护成本爆炸。

4. 评估漂移 (Evaluation Drift)

早期评估 Agent 真正的智能水平。后来评估变成”有没有触发这个规则””有没有推荐这个产品”。

指标和智能脱钩,团队在优化错误的东西,智能下降但指标上升,问题被掩盖。

5. 人设分裂 (Persona Fragmentation)

产品说要”专业可靠”,运营说要”活泼有趣能带货”,客服说要”严谨不能出错”。

同一个 Agent 被拉向不同方向,最后人格分裂,用户感知”这个 AI 很奇怪”。

温水煮青蛙

这种腐化最危险的地方在于:它是渐进的。

每条规则单独看都”有效”——短期数据确实在涨:

• 功能渗透率:↑
• 转化率:持平或略升
• 结论:”有效,继续加”

但债务在暗处累积。用户体验不是一下子变差,是慢慢变得”不那么聪明”。用户说不出哪里不对,但就是不想用了。留存慢慢掉,归因不到任何单一功能。

等你意识到问题的时候,系统已经改不动了。

根源在哪

1. 短期指标驱动:每个决策都优化局部指标,没人为 Agent 整体智能负责。

2. 技术缺乏话语权:技术知道加规则有问题,但产品数据说”有效”,技术说了不算。

3. 因果被切断:产品加规则拿到渗透率功劳,智能下降技术背锅。制造债务的人不承担后果。

4. 没有”智能债务”概念:传统技术债有行业共识,Agent 智能债没有度量、没有意识。

如何对抗

借鉴软件工程的经验

在传统软件工程中,架构师的职责是保持一致性、做对的抽象、防止腐化,辅以及时重构。

Agent 产品需要类似的角色:智能架构师。

智能架构师的职责

1. 定义 Agent 的”宪法”:核心行为准则,所有规则都要服从它。

2. 守护 Prompt 的一致性:不是谁都能往里加东西。

3. 把控工具边界:新工具要审核,工具粒度要合理。

4. 拥有否决权:产品要加破坏智能的规则,可以说不。

5. 维护纯净 baseline:始终有一个无业务污染的版本作为参照。

建立”智能债务”指标

• 硬编码规则数量
• Prompt 复杂度
• 模型自主决策比例 vs 规则覆盖比例
• 纯净版 vs 当前版的智能评分差距

让债务可见,而不是只看功能渗透率。

流程机制

• 偿还计划:每条规则要有下线条件和时间,不是加了就永远在。
• 定期清理:每季度 review 所有硬编码逻辑。
• 决策权和后果绑定:谁加的规则,谁对智能指标负责。

组织架构

Product (What/Why) ←→ Agent Architect (守护智能) ←→ Engineering (How)
                              ↓
                      Evaluation/QA (度量智能)

关键:Agent Architect 要独立,有独立 KPI,可以 challenge 产品和工程双方。

AI Native 时代的特殊性

这里有一个更深的问题:在 Agent 产品中,技术团队的角色发生了变化。

传统软件:PM 定义 What/Why,工程定义 How。

但 Agent 不一样:

• 能力边界不清晰:能不能做到、做到什么程度,取决于技术实现。
• How 决定了 What 的可能性:用什么模型、怎么做 tool calling、怎么处理上下文——这些不是实现细节,是产品形态的根本约束。
• 体验是涌现的:Agent 的体验取决于它”怎么思考”,这完全是技术层面的事。

所以,Agent 产品中的技术团队,不只是 How,而是要参与 Why:

• Why this approach works
• What’s actually possible
• Where the real value is

这不是越界,是 Agent 产品的本质要求。

写在最后

Google DORA 2025 报告有一句话说得很好:

AI doesn’t fix a team; it amplifies what’s already there.

Agent 腐化本质上是技术债 + 组织债的结合体。每个人都在优化自己的局部指标,没人看整体——这和 LLM “优先保证局部功能正确,而不是全局架构一致性”是同一个问题。

只解决技术层面不够,需要组织层面的改变。

如果你也在做 Agent 产品,希望这篇文章能让你在下次加规则之前,多问一句:这条规则的智能债务是什么?谁来偿还?