1 篇博文 含有标签「apis」

我认识的一位后端工程师在一个周二的下午盯着一个从未有过波动的 Datadog 图表：其内部日历服务的单用户 429 计数器。投诉的客户并没有改变他们的行为。他们只是开启了助手功能，现在每当用户说“帮我找下周的时间”时，该功能就会针对同一个日历 API 并行启动八个规划线程。速率限制器（Rate Limiter）——每用户每分钟 60 次请求，这个设置非常合理，是多年前针对一个在物理上无法点击得那么快的 UI 编写的——在每次请求的前三秒内就会触发，并悄无声息地破坏了助手一半的响应。

速率限制不是 Bug。契约才是 Bug。那个后端，就像大多数在 2024 年之前编写的内部服务一样，在每一层都植入了一个悄然执行的假设：一个用户意味着一条活动流，其节奏受限于人类的反应时间，拥有一个 cookie 罐、一个 CSRF 令牌和一套在出现问题时可以重新提示的凭据。Agent 一次性粉碎了所有这五个假设，故障表现为一系列看似无关的事件——429 风暴、“最后写入者胜”（last-write-wins）导致的数据损坏、无法取证的审计日志、挂起无头工作线程的重新认证循环——在模式被命名之前，没有人会将它们联系起来。

我一直与平台团队沟通的一个简短总结是：你拥有的每一个后端都与它的调用者有一个未记录的契约，而那个契约是与人类协商达成的。现在 Agent 出现了，要求重新协商。你可以选择在代码审查中主动进行协商，也可以选择在下一次事故期间被动进行。