架构警示：智能体时代，为什么“不友好”的API会成为系统雪崩的放大器？

在传统软件系统中，一个设计得不够理想的 API，往往还能长期存活。它响应慢一点、错误码不够清晰、偶尔返回不完全符合预期的数据，人类开发者通常会选择绕开、缓存、加注释，或者干脆在调用处写一段防御性代码。系统就这样继续运行，看似没有大问题。

但当这个 API 的主要调用者，逐渐从人类工程师变成智能体之后，事情开始发生根本变化。原本“影响有限”的问题，被迅速放大，最终演变为系统级灾难。

这并不是因为 AI 特别“激进”，而是因为我们长期以来对基础设施质量的容忍，是建立在“人会自我约束”这个隐含前提之上的。而智能体，并不会替我们承担这种约束。

一、人类调用 API 时，隐含了大量“非写入代码的判断”

人类开发者在调用 API 时，做了大量不体现在代码中的判断。

例如，当接口文档模糊时，工程师会通过经验猜测“这个字段大概什么时候为空”；当错误码不明确时，会在日志中人工区分“这次失败可能只是偶发”；当接口响应慢时，会在心理上形成一种“不要在高频路径里用它”的共识。

这些判断并不严谨，但它们在无形中限制了问题的扩散范围。一个糟糕的 API，往往正是依靠这种“人类摩擦力”，才得以在系统中长期存在。而智能体不会阅读接口文档时的“潜台词”，也不会形成这种经验性的避让策略。

二、AI调用的本质：忠实、重复、无情绪

智能体调用API的方式，和人类有本质不同。

首先是忠实。只要接口在逻辑上是“可调用的”，智能体就会严格按照既定流程反复尝试。模糊的错误码不会让它“理解”这是不可恢复的失败，反而可能被当作重试信号。

其次是高频和并发。一个人类开发者一天可能只触发几十次的问题路径，而一个智能体，在规划、反思、重试等机制作用下，可能在几秒钟内触发成百上千次调用。

最后是缺乏厌烦机制。人会因为系统不稳定而主动停用某个功能，AI不会。只要目标尚未达成，它就会继续尝试，直到资源耗尽或系统崩溃。

这三点叠加在一起，使得任何原本被“局部容忍