最近，百度智能云和 SGLang 社区办了一场以“Agent 时代的推理基础设施”为主题的 Meetup，我也在现场，讲了一段 7 分钟的闪电演讲，题目叫《生产级 Agent 的上下文内核：工程实践与验收》。我的另一个身份，是一套销售订单加仓库履约系统的项目负责人。这套系统的开发、调试、权限处理，整体交给 Agent 推进，模型调用跑在百度百舸的在线推理服务上。
活动主视觉
负载的变化，开场致辞里有一组对比说得很直白：去年办上一届的时候，大家聊的还是 ChatBot 时代怎么撑住大模型推理，典型负载是输入 4K、输出 1K；现在百度内部平均上下文已经到 60K，还在往 100K、500K 走。负载涨到这个量级，压力不光压在推理基础设施那一层，也压到我们应用这一层头上。
先说清项目。这套销售订单加仓库履约系统，开发、调试、权限处理整体交给 Agent，测试也基本全部由它自己跑。从目前推进的情况看，90% 以上的动作它能完成，剩下不到 10% 还得人来。
活儿交出去，省心了吗？没有。项目往前推，我们实际在还三笔账。
一笔是迭代。底层的模型、框架、芯片一直在变，我们怕的不是换，而是每换一次就要重新配环境、查兼容、跑迁移验证，应用自己的节奏全被拖住。
一笔是成本。工程任务一轮接一轮，每轮输入都带着项目上下文，还夹着工具调用的中间结果。大量内容已经算过一遍，每一轮都从头算，账单压不住。
一笔是稳定。一条任务链要跑几个小时，中途服务一抖、实例一挂，前面的时间和资源一起搭进去。对话式应用失败了用户可以再问一次，生产里的任务链没有这个余地。
这三笔账，模型自己管不了，得有人替我们管。先说平台那一半——在百度百舸，它被逐项接住了。
三笔账｜迭代、成本、稳定
先说迭代这笔账。我们的模型调用都跑在百舸在线推理服务上，走标准化接口，没有为哪一款芯片写过特殊代码。这不是偷懒，是刻意保持的姿势。底层怎么换，应用层的工程能力都不用返工。活动前一天，SGLang-Kunlun 正式开源到百度百舸的开源仓库，插件机制让国产芯片的后端与 SGLang 主社区的上百万行代码解耦、独立演进，不用跟着社区版本反复 rebase。对我们这类团队，“换底层”这件事，正从一次工程冒险变成一次配置变更。
再说成本这笔账。SGLang 核心贡献者在会上引了一份第三方评测。Agentic 流量的输入长度中位数 88K，输出只有 413 个 token，比例是 213 比 1。每轮新增的就几百个 token，却要把几万、几十K的历史原样带一遍。我们的多轮调用正是这样。百舸在线推理服务默认的 SGLang 引擎按匹配前缀复用计算，相似上下文不重算；显存放不下的，分层缓存能扩展到主机内存和远端存储，现场公布的口径里命中率能做到 80% 以上。这套平台机制和我们的纪律正好是两面。应用侧“下一轮必须重新检索”保证依据是对的，框架侧前缀复用保证算过的不再算。两边对上，重复的钱才真正省下来。
多轮推理的代价，百舸怎么解
最后是稳定这笔账。会上有个数把这种风险量化得很直白。命中率常态 90% 的服务，一次流量波动把它打到 40%，算力需求瞬间放大 3 到 5 倍。服务波动不是慢一点，是整个容量盘被掀翻。这笔账百舸在平台层给了对应的解法：流量突增，弹性扩缩容让容量跟着负载走；版本更新，滚动发布加健康检查，升级不停服；实例故障，平台自动恢复，官方口径里万卡任务的故障恢复提速到了 1 分钟。分工很清楚：数据不丢、顺序不乱，是我们四项机制的事；服务一直可用，是平台的事。
应用管依据的准，平台管运行的稳，各管一层，互不替代。
调用链与验收
平台那一半有人兜底，应用这一层的依据就得自己管好。开发这套系统时，我们撞上过一个职责问题，快递单记录到底由谁创建。
早期取快递运单号的流程里，我们加过一步“新增快递单记录”。后来再核对，最新流程已经把这一步去掉了，创建职责由业务表自动化统一承接。
人看一眼新流程，这事就翻篇了。Agent 不行。它干活的依据是我们交给它的资料，流程改了、依据不跟着改，它下一轮还按旧理解往前走，可能把已经删掉的步骤又补回来，快递单就重复建了。
撞上这么一回，我们想明白一件事。模型不缺聪明，缺的是一份对的依据。
创建快递单，到底由谁负责
为了治这个，我们在上下文工具里实现了四项单机机制。状态上，先确认新记录再替代旧项，更正过程可追溯。并发上，共用一把锁，读取、修改、保存按顺序提交。持久化上，完整写入并同步后再整体替换，换个进程也能读回。权限追溯上，校验资料读取范围，保留来源与位置，按文件变化识别需要重新核对的资料。
上下文内核的四项机制
机制落地后，我们把这次职责更正放进单机环境做回放验证。更正前，默认检索返回旧规则；确认新规则并重新检索后，拿到的就是“业务表统一创建，取号流程不再新增”。9 月 13 日的隔离检查里，4 类临时样例全部通过，两进程各 10 次状态转换，20 条状态、20 条历史完整保留。
更正以后，下一轮拿到什么
这里有个最容易漏的地方。光改记录没用，下一轮必须重新检索。拿着更正前的输入继续干，改了等于白改。
这四条管的是应用层的依据。加上平台那一层接住的迭代、成本和稳定，这套系统才敢一直在生产里跑。
下午开场是闪电演讲，这也是这次 Meetup 的创新升级环节，一共邀请了包括我在内的三位演讲者。前面聊了那么多基础设施，这一环节讲的是离应用更近的故事，另外两位嘉宾的分享也让我印象很深。
闪电演讲｜我在台上演讲
闪电演讲环节，第一位登台的嘉宾是SGLang核心贡献者张晓雨。他讲的是用 Agent 做模型 Kernel 调优：DeepSeek V4.1 Flash 在 day0 支持时就跑到每秒 800 多个 token。模型优化这件事本身，也在被 Agent 重做一遍。
闪电演讲｜SGLang 核心贡献者张晓雨
第二位是元神智算 CEO 蓝衣剑客，他讲的是自己一个人写了一年的知更鸟业务系统。他说的“恢复决定任务能不能完成”我印象很深，和我们琢磨的“下一轮依据什么”，是同一件事的两面。
闪电演讲｜元神智算 CEO 蓝衣剑客
台下聊起来，发现大家踩的坑高度相似，解法也都落在上下文和基础设施这两层。这个信号比任何一场分享都让我确定，应用侧的上下文工程，值得当成一门正经学问做下去。
聊完同台的三位，把视线收回来，回到我们自己那张快递单。它的教训是，交给 Agent 的依据错了，它会把错的执行到底；依据对了，下一轮检索也对了，它才接得上。而让“下一轮”一直成立，靠的是平台把迭代、成本、稳定这三笔账逐项接住。
去年同一批人还在聊 ChatBot 时代的推理，今年全场讲的是 Agent 的几十轮会话和几百 K 上下文。模型能力的下一次跳跃还没有时间表，但把今天的模型在生产里跑稳、跑省、跑得久，百度百舸已经替应用团队蹚出来了。我们要做的，是把自己这一层的依据做对。
应用管依据的准，平台管运行的稳
