难的不是两万 QPS，是断点那一刀

这道新时代八股题听着吓人，两万 QPS、单任务跑几十分钟，真难点却不在并发上。 引帖先把题面摆开。企业级 AI agent 的调用与计费平台，入口峰值两万 QPS，任务最长几十分钟，要解长任务、额度扣减、计费准确和高可用。链路走快进快出。网关鉴权限流，缓存预扣额度，丢进消息队列立刻返回任务号，同步请求只接单不执行。 扣款分两段。入口按模型档位冻结上限，跑完按实际用量真扣，多冻的释放、失败的也释放。冻结防超额，结算才是真扣，两件事分开。用量是多维的，token、工具调用、时长、档位分别上报，冻结和结算用同一套算法。调度器挂掉那问是杀招，任务状态必须持久化，重启后能从断点恢复。 点评那半句是全场重心，真痛点在流式输出和状态恢复，不在高并发输入输出上。session 的状态机因此格外复杂。最痛苦的场景是一轮对话中间断掉，还得有原子性并正确恢复。这跟前面那张按下重置的按钮接得上，断了之后能不能体面地续，才是这套系统成色的分界。 分层解耦的观察也扎实。推理层和编排层分开，编排层做组合上下文和数据库访问，异步输入输出多，计算反而少。云 agent 其实和聊天软件一回事。只是要跑在沙箱里、禁一堆系统调用、再设预算。计费也归推理层，编排层只管把账单拼起来。 我留的疑问是断点恢复的粒度没给，中途断的那一轮到底回滚还是续跑，两边各有一套说法。 拿自己项目里最长的那个任务试一次，跑到一半掐网再接回，看状态机停在哪一步。