幂等键防得住重复退款,防不住错误退款

Idempotency Keys Stop Duplicate Refunds, Not Wrong Ones — Where the Distributed Systems Analogy for AI Agents Breaks Down

TikTok 的 SRE Salman Munaf 最近有一场演讲,开场问题问得很漂亮:

你的 AI Agent 调用退款接口,网络超时了。那退款到底成功没有?

他的答案是:超时从来不意味着失败,而意味着「未知」。Agent 遇到失败的第一反应是重试,没有请求 ID、幂等键和状态查询,这个本能就会把一笔退款退成两笔。整场演讲的论点一句话概括:模型一旦开始调用外部服务,问题就从模型问题变成了分布式系统问题——几十年前命名过的故障模式全部回归,SRE 工具箱必须整体搬进 Agent 架构。

我同意。但我想在他的问题后面再问一句:

就算退款成功了——那笔退款,退得对吗?

这两个问题之间的距离,就是这篇文章要讲的东西。

Idempotency Keys Stop Duplicate Refunds, Not Wrong Ones — Where the Distributed Systems Analogy for AI Agents Breaks Down

[Read More]

当 10 万个定时任务同时敲门:MaaS 平台调度优化实战

从整点风暴到分布式调度——平台视角的六个关键策略

上周五下午 3 点,告警群炸了:MaaS 层的 GPU 推理集群 QPS 在 60 秒内从 1200 飙到 18000,p99 延迟从 800ms 打到 45 秒,大量请求 429。

排查发现原因很"朴素"——大约 3 万个 OpenClaw 实例的定时任务都跑在整点。每个实例可能只有 1-3 个 cron job(数据摘要、定时巡检、报表生成),但所有人的 cron 都写着 0 * * * * 或 0 0 * * *。三万乘以三,就是整点瞬间涌来的近十万个 LLM 推理请求。

这不是应用层的 bug,而是平台设计的缺陷。当你的平台承载成千上万个租户的定时任务时,“整点风暴"不是意外——它是必然。问题是:作为平台设计者,你该怎么办?

[Read More]