本地私有化部署大模型 × few-shots 开放题挑战

——本地模型的长任务输出 + Super-agent 的长任务执行：72 小时服务端实证

版本：v1.8（2026-11-02，定稿）
背景：DeepSeek 产品部发表《Super-agent 设计探索：迈向更自主的 Agent 系统》，讲的是这套系统的设计。我们随后在自己的推理系统上实弹跑了一个基于 DeepSeek Harness 的 Super-agent 工作负载，并从服务端做了完整观测：请求体字节级抓包、引擎侧逐笔缓存对账、同栈同模型的对照 agent。设计文档讲它应该是什么样，这篇讲它在线上实际是什么样，顺带回答一个更实际的问题：为什么换了它，本地模型就能跑长任务了。

0. 缘起：私有化部署的最后一公里

先说我们是谁、为什么做这个实验。

oai-mlx 是我们基于 Apple MLX 生态搭的私有化本地部署大模型系统：单机 Mac Studio M3 Ultra 512GB，自研 Rust AI网关 + omlx 引擎多实例。此前的工作重心在 decode 与预填充性能，单流 decode 阶梯、多流分摊、分页 KV 缓存与前缀复用都有基线数据，单会话和短会话场景已经站稳。

但私有化部署说到底是要离线解决复杂问题，复杂任务绕不开长任务输出。眼下的局面是：模型在本地，能力在线，任务却跑不完。长任务至今是私有化部署明显缺着的那一块。

AGI Bar 的 few-shots 开放题挑战正好适合拿来当长任务测试：一组开放研究题，从 11 维 kissing number、Ramsey 数 R(4,6) 到 10 万个点的 Mona Lisa TSP，每道题被压缩成"一个要打败的数"，用 PR 加证书文件做机器验证。题目开放、要多轮工具调用和持续推理、上下文持续增长，是天然的 agent 长任务负载。本地私有化的模型到底能不能解这些题？

长任务跑不跑得成，因素是多方面的。我们在同一套本地栈上先后测过 WorkBuddy、DeepSeek Harness、Reasonix 等多个智能体，失败和中断的居多。这不是印象，是网关台账：过去 72 小时（2026-10-29 23:48 起），这个网关共服务了约 3,500 笔 few-shots 任务请求，估算上下文累计约 1.76 亿 token，各轮首 token 等待时间累计约 113 小时：

* est 为网关估算口径（对真实上下文约低估 2.4 倍），仅用于同一网关内的横向对比；累计 TTFT 为各轮首 token 等待墙钟之和。

最极端的样本是 DeepSeek Harness 常规模式下的一个会话：平均估算上下文 130k（最大 333k），18 小时里累计花了 84.3 小时等首 token（折算平均同时在途约 4.7 笔请求），83% 的轮次首 token 超过 60 秒，最长 1,352 秒——服务端几乎全部时间都在为同一个会话反复重填。换成 DeepSeek 发布的 Super-agent 调同一个本地模型之后，任务跑通率明显上升（任务侧的实测体验，机理见下文）：接手后连续数小时分钟级推进，稳态快循环平均 TTFT 进入个位数秒。

先把目标说清楚。这次实验验证的是长任务的执行能力：私有化本地栈上的 agent，能不能把开放题长任务跑完——活着推进到终点；跑成功——产出经官方验证器确认的合法结果，闭环完整，自评诚实。这个目标已经达成。 突破基线（打败某道题的当前纪录数，并通过 GitHub PR 机器验证）是另一个目标、另一种定位，取决于搜索算法、算力预算、模型能力等多方因素，不在本次实验的证明范围内。官方验证器 check.py 的判定语义：exit 0 = 有效突破、可提交；exit 1 = 达到基线但未破纪录或低于基线；exit 2 = 违规。截稿时的实测状态：

它的自评口径与验证器严格一致：持平不算成绩，复现只是环境校验，差 200 不装成接近。执行层跑成功了，也没把"跑成功"包装成"跑赢"。

这组 exit 1（而不是 exit 2）恰恰证明了"跑成功"：从读题、构建求解器、跑搜索、生成证书到验证器实测与自评，完整闭环真实走通，产出物格式合法。4 道题的差距被量化成了明确的算法问题——p006 需要文献级 long-run 的启发式搜索，p011 需要 SAT 穷举——而不再是跑不完、中断、失忆。台账里的其余 9 个会话，全部倒在离这一步很远的地方。

长任务跑完、跑成功，这次已经证明为能；能不能突破基线，是另一个目标的事。 同样的模型、同样的推理栈、同样的题，只换了 agent，执行结果就从全部淘汰变成跑完且跑成功。差在哪？答案要到线上找。

1. 结论

私有化长任务跑不动，短板常常既不在模型，也不在推理栈，而在 harness 的上下文纪律。Super-agent 补上的正是这一块。在我们这侧的观测里，它的做法可以压成一句话：它从不改写历史。 这一条纪律，同时买到了设计文档承诺的四个特征（连续、高效、主动、持久），在推理服务层也有精确对应：上下文不可变追加，就是 KV 缓存的完美局部性。同栈同模型对照，单轮成本相差 20-50 倍。

2. 实验台与口径

• • 服务端：如上，自建 Rust 网关 + 双 omlx 推理引擎实例，Qwen3.8-Flash-Next（4-bit MoE + 投机解码），启用分页 KV 缓存与前缀复用。
• • 负载：Super-agent 跑 few-shots 开放题挑战，单会话上下文增长到 80k token、累计 242+ 轮请求（截至 2026-11-02 00:00），内含两条并发执行线程。
• • 对照组：同一晚早些时候，同一服务栈、同一模型、同一类任务上跑的 Reasonix（同 harness 家族），区别只在上下文构造策略。
• • 观测手段：网关三态遥测（每轮 usage / 缓存状态 / TTFT）、引擎逐笔缓存恢复日志、请求体全量抓包（做字节级 diff）。
• • 局限：单机、一晚、单一负载。任务侧的最终胜负不在本文口径内（§0 实测表已如实交代），本文度量的是服务侧执行质量：速度、命中率、零弃单。

3. 指纹一：字节级 append-only

设计文档说 Super-agent 要做到跨信道连续。落到抓包里，"连续"长这样。

相邻两笔请求（间隔 6 秒，289,100 字节 vs 290,860 字节）做字节级 diff：

• • B = A + 2 条追加消息，前 172 条历史逐字节相同；
• • 间隔 176 秒的两笔，依然是纯前缀追加关系；
• • 一条独立执行线程内部的相邻请求，也满足"短者是长者的严格前缀"。

还有三处细节值得点名：

1. 1. 时间戳冻结。 历史消息里有 Time sampled while preparing turn 1, step 1: <时刻> 这样的采样标记，冻结在创建时刻，跨请求一字不差。多数 agent 框架每轮都会重注当前时间，等于每轮把历史前缀作废一次；它没有。
2. 2. 工具定义稳定。 31 个工具 schema 跨请求逐字节相同。工具 schema 键序不稳定，是业界公认的前缀杀手。
3. 3. 改写历史的需求被结构消解。 要改变对历史的理解，它选择追加，而不是重排——这是保住前缀稳定的唯一正确姿势。

对照 agent（Reasonix）在逐题阶段的做法正好相反：每道题构造一个新上下文，与已有链只在 2-6k token 处一致（引擎侧三重证据：变体头持续新生、每题仅命中 2048-6144 token、分叉点位置），60k 的任务说明每题都在变。所谓上下文纪律的差异，落到根上就是每轮发给模型的字节不一样。

4. 指纹二：serving 层的 20-50 倍回报

"从不改写历史"，在模型层是记忆完整性，在系统层就是缓存局部性。引擎的账本：

弃单都是个位数，两边在协议层都健康，拉开差距的是每一轮的成本结构：一边为新增的三五百 token 付 2 秒，一边为同一份 60k 任务说明反复付 100 秒。

换 agent 为什么见效，机理在两层：

• • 速度层：同样的任务预算内，它推进的轮数是别人的几十倍。长任务本质上是轮数的比赛。
• • 质量层：模型每轮看到的都是完整且逐字节一致的历史。逐题重建上下文的 agent，模型是在可能不一致的记忆上答题——这比慢更伤成功率。

网关的采样头哈希是同向佐证：同一套采样机制下，Super-agent 242 轮只出现 10 个不同的采样头，对照 agent 256 轮出现 74 个，稳定性差 7 倍。机制很直白：头哈希采样的是上下文头部，append-only 的增长发生在尾部，头部字节稳定，哈希自然稳定；对照 agent 每题重排头部，哈希跟着轮换。不过头哈希终究只是摘要采样，判定上下文纪律还得看字节层——这正是我们做全量抓包的原因。

5. 指纹三：并发与持久

• • Worker 层并发：抓包证实会话内同时存在两条执行线程，一条 5-7 秒节奏的快工具循环，一条 3 分钟节奏的长任务线，各自独立 append-only、互不污染。设计文档里"上下文隔离的 Worker 并发执行"，在请求流上就长这个样子。
• • 持久：同一会话连续推进数百轮，传输失败仅 1 笔。期间服务端做过引擎逐台滚动重启，agent 侧为每条执行线程付一次链冷启动（约一次全量重填），随后自愈回到快循环，全程无需人工介入。

6. 指纹四：它反过来逼着基础设施变好

足够快的 agent，同时也是推理引擎的极限测试仪。

Super-agent 的快循环把两笔请求的间隔压到 5-7 秒，正落在我们引擎一个从未被暴露的窗口里：前一轮请求结束后、KV 存储异步发布完成前的提取期（约 0.7-1.4 秒）。在这个窗口里到达的下一笔请求找不到可等待的存储任务，只能全量重填。毫秒级时间线：存储日志出现于 20:46:58.903，竞态查找发生在 20:46:59.502，只命中 4096/67000 token。

这个竞态存在已久，只是从来没有负载能稳定踩中它。当晚我们据此给引擎打了补丁（存储提取期预注册 + 等待者领养机制，含单测）。上线后，这种形态的全量重填被 28 秒的有界等待替代，快循环稳定在 2-6 秒。

这一晚的收获不止修 bug。这套负载也是我们长任务机制设计的直接输入：逐轮三态遥测（usage / 缓存状态 / 弃单归因）就是被这类负载逼出来的，抽象压测造不出这种真实形态。本地栈让 Super-agent 跑成了长任务，Super-agent 让本地栈长出了长任务能力。

一个"好 agent"的标准之一：它跑过之后，你的基础设施档案里多了一个被修复的真实缺陷。

7. 业界现状：这个空白有多大

截至 2026-11，"本地私有化跑 agent 长任务"在业界是什么状态？

服务器/集群侧：零件成熟，"会话感知"刚起步。vLLM 的 Automatic Prefix Caching（块级、要求 token 序列精确一致）和 SGLang 的 RadixAttention（radix 树匹配，官方口径 6.4× 于无缓存系统）是主流方案；但 agent 长会话保持缓存仍是公开承认的痛点，vLLM 侧的 agentic-api 到 2026 年 4 月还停在 "Session-Aware KV Cache Management" 的 RFC 阶段；有实践记录显示 coding agent 流量会反复击穿缓存分层，工具 schema 序列化不稳可以造成 90-180 秒级的重填——和我们抓包发现的是同一族问题。这一层的路由方案（如 token 感知调度），口径都是数据中心和舰队。

本地/单机侧：基础保持都成问题。Ollama 空闲约 5 分钟即丢 KV，对"等人类输入"的 agent 会话是硬伤；llama.cpp / LM Studio 走隐式缓存，模型切换即全量重算；MLX 官方栈里，mlx-lm 的前缀缓存对混合注意力架构存在缺陷（mlx-lm #980），mlx-vlm 服务端曾被报告每请求清空缓存（mlx-vlm #999）。本地世界最接近的一步，是 LM Studio 给 MLX 引擎做的 KV cache 回卷（面向 agentic 循环的存取/回滚），但止步于单实例，其上是消费应用而不是 serving 层。社区方案（多槽位 KV 服务、KV 落盘续用）还停留在 DIY 教程级。

Agent 侧：纪律知识在传播，但多对着云 API。"前缀工程"实践（时间戳冻结、稳定工具 schema、间隔性压缩）在国内技术社区已经流行，但绝大多数针对云端 API 的 prompt cache 计费优化，落到本地私有化栈上的完整配套很少见。学术界（KV 跨 agent 阶段持久化、agent 执行感知的 KV 管理）还在论文期。

判定：零件存在，组合空白。 单机私有化（尤其 Apple Silicon / MLX 生态）上，把 agent 长任务当一等公民的 serving 层——前缀亲和路由、会话粘滞、跨实例 KV、逐笔缓存可观测、与引擎协同的竞态修复——目前没有现成方案。oai-mlx 这一晚展示的，正是这个空白被补上之后的样子；§3 的字节级证据则说明，另一半（agent 侧纪律）同样不可缺席。

8. 为什么一条纪律买到四个特征

回到设计文档的四个基础特征，它们在 serving 层共用同一个机制：上下文不可变追加。

• • 连续：模型每轮看到完整且一致的历史，记忆是完整的；
• • 高效：前缀缓存近全量命中，每轮只为增量付费；
• • 主动 + 持久：单轮边际成本从"每轮 100 秒全量"降到"每轮 2 秒增量"之后，持续在线观察环境在经济上才成立——主动性的经济学基础在这里；
• • 双层架构（Router / Worker）把这条纪律扩展到并发与跨信道：每条 Worker 线独立保持 append-only，Router 汇总全局。我们在请求流上看到的"双线程各自严格前缀追加"，就是它的落地形态。

私有化场景的特殊性也在这里：本地部署算力有限，没有云端那样的扩容余量，缓存局部性不是锦上添花，是生存条件，而它完全取决于 agent 改不改写历史。我们的 decode / prefill 投资是必要条件，Super-agent 这样的 harness，才是兑现它的充分条件。

9. 给构建者的四条经验

1. 1. 把"不改写历史"当硬约束设计进 harness：时间戳冻结在创建时刻、工具 schema 序列化稳定、需要改变历史理解时追加而不重排（对应 §3 的三个证据）。
2. 2. 选 agent 之前先做一次相邻请求 diff：抓相邻两笔请求体，看第一条差异字节出现在头部还是尾部。一条命令的成本，就能预判这个 agent 在你的推理栈上是"每轮付增量"还是"每轮付全量"。WorkBuddy / Reasonix / Super-agent 在我们栈上的成败差异，这个 diff 全部说中了。
3. 3. 用服务端字节对账评价 agent 的上下文纪律：相邻请求体 diff 加引擎缓存命中账，比任何主观评价都硬。
4. 4. 快 agent 与推理引擎要协同演进：步间隔进入个位数秒后，引擎侧的异步发布窗口、调度竞态都会浮出水面。让 agent 的节奏成为你引擎回归测试的一部分。

10. 结语

回到开头的问题：本地私有化的模型，到底能不能解决 few-shots 这类长任务挑战？

取决于目标定在哪一层。

执行层——长任务能不能跑完、跑成功：能，数据已经证明。模型一直在场，推理栈也早就绪，缺的一直是一个不改写自己历史的 harness；它同时保住记忆完整性和缓存局部性。72 小时里，多种智能体全部倒

在"跑不完"这一关；Super-agent 用同一个本地模型跑通了完整闭环，产出经官方验证器确认的合法结果。突破层——能不能打败这些开放研究题的纪录数：另一个目标、另一种定位，由算法、算力、模型能力共同决定。这次实验至少把差距量化到了具体的算法问题上，执行不再是瓶颈。

"从不改写历史"听起来算不上什么架构创新。难的是在双层架构、事件驱动、跨设备持久化的全部复杂度之下守住它。我们的引擎日志可以为这一切作证。