知识库简报 · Jay · 2026-08-01 15:05（晚间高频推送）
主题：MCP 2.0 重大规范更新 · KV-Cache 系统工程 · 推理引擎基准 · arXiv 新论文 · Substack 技术洞察
检索范围
- MCP 2.0 规范（2026-07-28）
- arXiv: KV-cache offloading, inference systems, 2026
- Substack: Lilian Weng Harness Engineering, ByteByteGo OpenAI Agent Loop, Import AI MirrorCode
- Hugging Face: Kimi-K3, LFM2.5-Encoder
- 基准: vLLM vs SGLang vs TensorRT-LLM H100 benchmarks
- 检索时间窗口：今日新发现 + 近一周高价值条目精筛
一、Database / 向量数据库 & 存储系统
D1 · KV Cache Transform Coding：ICLR 2026 紧凑存储新方法 ⭐⭐⭐⭐
arXiv: https://arxiv.org/abs/2511.01815
会议： ICLR 2026（已接收）
标签： #KV-Cache #Compression #ICLR2026 #LLM-Serving
可信度： 高（顶会接收）
工程价值： ⭐⭐⭐⭐
核心贡献： KV-cache 是 LLM 推理中显存占用的大头（128K 上下文单用户约需 40GB BF16）。本工作提出 Transform Coding 方法对 KV-cache 做紧凑压缩存储，减少显存占用的同时保持精度。
工程关联： - 与 DUAL-BLADE（本期 D2）形成"压缩+卸载"两条路线互补 - 可与 vLLM PagedAttention 集成，减少 GPU 显存压力 - 与 KVQuant（10M context LLM inference）路线对比
建议： 关注 transform coding 相对量化（KVQuant）的精度损失曲线，评估生产可用性
D2 · DUAL-BLADE：边缘 LLM 推理的 NVMe-direct KV-Cache 卸载 ⭐⭐⭐⭐
arXiv: https://arxiv.org/abs/2604.26557
会议： ICDCS 2026（已接受）
作者： Bodon Jeong et al.（具体机构待确认）
标签： #KV-Cache-Offloading #Edge-LLM #ICDCS2026 #NVMe #System
可信度： 高（IEEE ICDCS 2026 论文）
工程价值： ⭐⭐⭐⭐
核心数据： - Prefill 延迟降低：最高 33.1% - Decode 延迟降低：最高 42.4% - SSD 利用率提升：最高 2.2×
关键技术： 1. 双路径 KV 常驻（Dual-Path KV Residency）： 动态选择 page-cache 路径或 NVMe-direct 路径 2. NVMe-direct I/O： 绕过文件系统，将 KV tensor 直接映射到连续 LBA（Logical Block Address）区域 3. 自适应流水线并行（Adaptive Pipeline Parallelism）： 存储 I/O 与推理计算重叠
解决的问题： - 2-7GB 范围内，写入停顿（write stalls）问题 - Decode 阶段 page-cache thrashing 问题
工程关联：
- 与 LMCache（vLLM/SGLang/NVIDIA Dynamo 的 KV-cache 持久化存储 backend）路线互补
- 适用于边缘推理（AGPU/NVIDIA Jetson 等内存受限场景）
- 与 vLLM --swap-space 参数的工程意义对比：更系统化的 KV 卸载方案
建议： 作为边缘 LLM 部署的 KV 卸载架构参考；关注 LMCache 与 DUAL-BLADE 的集成可行性
D3 · Shadow in the Cache：KV-cache 的隐私安全风险（NDSS 2026）⭐⭐⭐⭐
arXiv: https://arxiv.org/abs/2508.09442
会议： NDSS 2026（网络与分布式系统安全研讨会）
标签： #KV-Cache #Security #Privacy #NDSS2026 #LLM-Serving
可信度： 高（安全四大顶会之一）
工程价值： ⭐⭐⭐⭐
核心问题： KV-cache 在 LLM 推理服务中存储了完整上下文（包括用户 prompt、tool call 结果、文档内容等），这些数据在 GPU 显存中以明文形式存在，存在隐私泄露风险。
主要发现： - KV-cache 可被利用进行侧信道攻击，恢复敏感信息 - 多租户场景下，共享 GPU 的不同用户可能通过 KV-cache 窃取其他用户数据 - 提出缓解方案
工程关联： - 对 vLLM/SGLang 生产部署有直接安全参考价值 - KV-cache 加密或隔离方案是 2026 年 LLM serving 安全的重要议题 - 与 MCP 2.0 的 authorization hardening（本期 backend 部分）结合理解
二、Backend / 推理引擎 & 系统架构
B1 · MCP 2.0（2026-07-28）：无状态协议核心 + 安全加固 ⭐⭐⭐⭐⭐
官方博客： https://blog.modelcontextprotocol.io/posts/2026-07-28
规范： 2026-07-28
SDK： TypeScript / Python / Go / C# 均已更新
标签： #MCP #Agent-Protocol #Stateless #Security #A2A
可信度： 极高（MCP 官方维护团队）
工程价值： ⭐⭐⭐⭐⭐
核心变更：
1. 无状态协议核心（Stateless Protocol Core）
最大变化： MCP 从双向有状态协议变为请求/响应无状态协议。
- 废除
initialize/initialized握手 - 废除
Mcp-Session-Idheader - 每个请求独立携带协议版本、客户端身份、客户端能力（放在
_meta中） - 可选
server/discoverRPC（但非必需） - 任何请求可以路由到任何服务器实例，支持普通 round-robin 负载均衡
"无状态协议仍然允许你管理状态——只是需要显式地通过 handle 来传递，而不是隐藏在 transport 层的 session 中。"
2. Multi Round-Trip Requests（MRTR）
- 替代原有的 server-initiated elicitation/create、sampling/createMessage、roots/list
- 不再需要持续开放的双向流
- 服务器返回
resultType: "input_required"，客户端在重试时附加inputResponses
3. HTTP Header 路由
- Streamable HTTP 现在强制要求
Mcp-Method和Mcp-Nameheader - 网关/WAF/Rate-limiter 可以在不解析 JSON 的情况下路由和限速
4. List 结果可缓存
tools/list、prompts/list、resources/list、resources/read现在携带ttlMs和cacheScope- 客户端可缓存工具目录，减少不必要的重复请求
5. 授权加固
- RFC 9207 issuer 验证
- 从 Dynamic Client Registration（DCR）迁移到 Client Metadata Documents（CIMD）
- Enterprise Managed Authorization（EMA）扩展框架
6. 攻击面变化（Backslash Security）
新架构引入三类新攻击面： | 攻击类型 | 说明 | |----------|------| | Handle Hijacking | 原 session hijacking 需要访问 session store；新架构下 handle 只是模型可见的字符串，模型可以 echo 和传递 | | Stateless ≠ Stateless App | 协议层无状态，但应用层状态管理方式变化 | | 权限边界消失 | server-to-client 请求不再依赖持久连接，原有边界机制不再存在 |
工程行动项：
- 现有 MCP 服务器需升级 SDK 到 2026-07-28 版本
- 检查网关是否传递新增的 Mcp-Method/Mcp-Name header
- 审查基于 session 的状态管理是否需要迁移到 handle 模式
- 12 个月最低弃用窗口期可用
B2 · 推理引擎 H100 基准：vLLM vs SGLang vs TensorRT-LLM 2026 综合对比 ⭐⭐⭐⭐⭐
来源： Spheron Blog、Lyceum Technology、InferenceEngineering.tech、Swfte AI 等综合
标签： #vLLM #SGLang #TensorRT-LLM #H100 #Benchmark #2026
可信度： 高（多方独立验证）
工程价值： ⭐⭐⭐⭐⭐
H100 并发吞吐对比（Spheron，2026）：
| Concurrency | vLLM | TensorRT-LLM | SGLang |
|---|---|---|---|
| 1 req | 120 tok/s | 130 tok/s | 125 tok/s |
| 10 req | 650 tok/s | 710 tok/s | 680 tok/s |
| 50 req | 1,850 tok/s | 2,100 tok/s | 1,920 tok/s |
| 100 req | 2,400 tok/s | 2,780 tok/s | 2,460 tok/s |
综合评估： | 维度 | vLLM | SGLang | TensorRT-LLM | |------|------|--------|--------------| | 生态广度 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | | H100 吞吐（高并发）| ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | | DeepSeek V3 优化 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐（3.1x） | ⭐⭐ | | 结构化输出 | ⭐⭐⭐（Outlines，-15-30% throughput）| ⭐⭐⭐⭐⭐（原生 grammar engine）| ⭐⭐⭐（自定义 logits processor） | | 前缀共享工作流 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐（RadixAttention）| ⭐⭐ | | 跨框架配置 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | | 模型覆盖 | NVIDIA + AMD + Intel + TPU + Trainium | NVIDIA（主）+ AMD | NVIDIA（仅）|
选型建议： - 通用生产服务，多样化工作负载 → vLLM（生态最广，动态负载处理稳健） - DeepSeek 系列 / 前缀共享场景（RAG、Agent、代码助手） → SGLang（RadixAttention + MLA 优化） - 极致单任务吞吐，NVIDIA 标准化环境 → TensorRT-LLM（编译后性能最强） - 结构化输出（JSON/函数调用）密集 → SGLang（原生 grammar engine，无 throughput 惩罚）
B3 · Lilian Weng：Harness Engineering for Self-Improvement ⭐⭐⭐⭐⭐
URL： https://lilianweng.github.io/posts/2026-07-04-harness/
来源： Lil'Log（Lilian Weng，OpenAI 前安全工程负责人）
时间： 2026-07-04
标签： #Harness #RSI #Agent-Architecture #Self-Improvement #Framework
可信度： 极高（顶级 engineer 技术博客）
工程价值： ⭐⭐⭐⭐⭐
核心定义：
Harness = LLM + Memory + Tools + Planning + Action + Workflow Design + Eval + Permission Controls + Persistent State
Harness 是 LLM 部署系统（harness）层与模型原始智能（core intelligence）层的边界，是 AI 产品工程的核心差异所在。
三大设计模式：
Pattern 1: Workflow Automation - Goal-oriented loop: plan → execute → observe/test → improve → loop - Karpathy autoresearch（github.com/karpathy/autoresearch）为参考实现 - 关键：工作流图强调模型分析自身轨迹和失败案例，通过"agent runtime"而非静态 prompt 模板进行迭代
Pattern 2: File System as Persistent Memory - 长期 agent 任务中，artifacts（实验日志、代码 diff、论文摘要、错误 trace）远大于 context window - 解决方案：用文件系统做持久化，而非全部塞入 context - 优势：利用模型读写文件的能力，随模型能力提升自动受益
Pattern 3: Sub-agent and Backend Jobs - Harness 可并行生成多个 sub-agent，监控 backend jobs - 父 agent 需要小型 process manager：启动 jobs、检查日志、取消失败运行、合并结果 - 关键设计选择：并行性必须显式且可检查（文件/日志/状态记录 > 瞬态聊天上下文）
Coding Agent Harness 工具集（参考 Claude Code / Codex）：
| 工具组 | 工具示例 |
|---|---|
| 文件系统 | glob, grep, ls, read, read_many, write, edit, multi_edit, apply_patch |
| Shell 执行 | bash, PowerShell |
| IO | LSP, git_status, git_diff, git_commit |
| 外部上下文 | MCP tools, Skills |
| Web | web_search, web_fetch, browser tools |
| Artifacts | Read docs, images; generate HTML, images |
| Backend 进程 | CronCreate, CronDelete, CronList |
| Agent 委托 | spawn_agent, resume_agent, wait_agent, list_agents, interrupt_agent |
工程关联： - 与 ByteByteGo 的 OpenAI Agent Loop 架构（本期 B4）直接对应 - 为 Agent 系统架构设计提供理论基础 - 与 MCP 2.0 的无状态设计哲学互为补充
B4 · ByteByteGo：ChatGPT 如何优化 Agent Loop（Harness → API → Inference）⭐⭐⭐⭐⭐
URL： https://blog.bytebytego.com/p/how-chatg优化s-its-agent-loop
来源： ByteByteGo（OpenAI 工程师直接受访）
时间： 2026-08-01（RSS，今日新）
标签： #Agent-Harness #OpenAI #Inference-Optimization #Codex #Architecture
可信度： 极高（一手受访）
工程价值： ⭐⭐⭐⭐⭐
三层架构：Harness → API → Inference
Harness 层技术： - Persistent WebSockets：减少连接建立开销 - Stable prompt prefixes：缓存不变 prompt 前缀，避免重复 tokenize - Deferred tool discovery：按需加载工具 - Code Mode：专用代码执行模式
API 层技术： - Tokenize only delta：仅对增量变化做 tokenize - Parallel safety checks：安全检查与推理并行化（race 机制）
Inference 层技术： - Cache-aware routing：根据 KV-cache 热度路由 - KV cache lifecycle management - Speculative decoding - Prefill/decode separation
关键洞察：
"AI 应用 ≠ LLM。LLM 只是其中一层。真实产品中，用户请求在到达 LLM 之前已经过了 harness 层和 API 层的多次处理。"
三、Cloud-Native / 云原生 & 基础设施
C1 · MCP 2.0 无状态协议对云原生 Agent 部署的影响 ⭐⭐⭐⭐
分析基础： MCP 2.0 官方博客 + Backslash Security 安全分析
标签： #MCP #Cloud-Native #Stateless #Security #Kubernetes
工程价值： ⭐⭐⭐⭐
云原生利好：
1. 水平扩展简化： 任何请求可路由到任意服务器实例，支持原生 round-robin / least-connections 负载均衡，不再需要 sticky session 或共享 session store
2. 故障恢复简化： 连接中断后重试成本降低，客户端可简单重发请求
3. gRPC/HTTP 基础设施复用： Mcp-Method/Mcp-Name header 使网关可做标准路由和限速
云原生挑战：
1. Gateway 升级要求： Streamable HTTP 强制要求传递新增 header，现有 WAF/网关必须升级
2. 安全边界重新设计： 原有 session-based 权限边界消失，handle hijacking 风险需要新的防护机制
3. MRTR 的状态管理： 多轮交互需要客户端显式管理 handle 和 inputResponses
四、CSDN / 工程实践
CS1 · 企业级 Agent 工程化落地：RAG + 幻觉防御 + 状态管理 ⭐⭐⭐⭐
来源： 火山引擎开发者社区（Volcengine）
URL： https://developer.volcengine.com/articles/7667122323107315753
标签： #Agent #RAG #幻觉防御 #状态管理 #企业落地
可信度： 高（工程实践，含具体场景数据）
工程价值： ⭐⭐⭐⭐
核心工程原则： 1. 召回优先于生成，引用优先于推理： RAG 型 Agent 必须深入引用召回率和幻觉检测工程层面 2. 多路召回 + 小模型关键词抽取/实体识别： 索引结构化元数据 3. 强制引用溯源： 无信源支撑则触发"拒答"或"澄清引导" 4. 分层适配层设计： 连接层（DB驱动/HTTP API/文件轮询/RPA）→ 语义层（原子接口聚合成"技能"）
关键教训： - 直接在 Agent 提示中暴露过多原子工具函数会显著降低 LLM 抉择准确率并增加 Token 消耗 - 收缩工具选择空间是关键优化手段
CS2 · vLLM 投机解码源码解析（CSDN）⭐⭐⭐⭐
来源： CSDN · jx232515
URL： https://blog.csdn.net/jx232515/article/details/161521192
标签： #vLLM #投机解码 #源码分析 #CUDA #推理优化
可信度： 高（CSDN 源码级分析）
工程价值： ⭐⭐⭐⭐⭐
覆盖模块： - 调度器、Worker、Model Runner - PagedAttention、CUDA Graph - 自定义扩展、KV Transfer
备注： 页面访问不稳定，建议直接从 vLLM 仓库源码 + 注释入手
五、Reproduction / 可复现 & 基准
R1 · MirrorCode Benchmark：AI 系统完成人类数周编程任务的能力 ⭐⭐⭐⭐⭐
来源： Import AI（Jack Clark）+ METR/Epoch AI
仓库： github.com/epoch-research/MirrorCode
标签： #Coding-Agent #Benchmark #METR #Epoch #Long-horizon-Tasks
可信度： 极高（METR + Epoch AI 联合发布）
工程价值： ⭐⭐⭐⭐⭐
Benchmark 设计（真实可复现）： - 25 个目标程序：pkl（Apple PLC，61k LOC）、gotree（系统发育树解析，16k LOC）、qsv_select（CSV 处理，87k LOC）、ruff（Python linter/formatter） - 仅通过 CLI 访问目标程序（无源码、无 web 访问），需完整重新实现
关键数据：
| 模型 | 推理成本 | 完成时间 | 正确率 |
|---|---|---|---|
| Opus 4.7 | $251 | 14 小时 | 17/25 达 100%；4/25 达 >99% |
| GPT-5.5 | — | — | 对比基线 |
| 1 年前领先模型 | — | — | ~30%（仅能完成 calendar utility 等简单程序） |
工程意义：
"AI 系统能从零通过黑盒 I/O 构建对标原程序的自研实现，这意味着高度智能的 Agent 可能具有从真实世界 bootstrapping 工业文明形态的能力。"
R2 · X Tech Radar（2026-08-01 早间）高价值技术线索 ⭐⭐⭐⭐
来源： X（Twitter）硬核干货雷达，近 7 天（2026-07-25 ~ 2026-08-01）
R2a · LLM 作为机器人"大脑"：物理机器人 16.7% → 97.3%（4× SOTA）⭐⭐⭐⭐⭐ - 来源：@tri_dao，链接：https://x.com/tri_dao/status/2082175796710658210 - 实现路径：纯 LLM 连接视觉-动作策略，无额外训练 - 物理机器人任务：16.7% → 97.3% - 仿真 LIBERO-PRO：12.8% → 53.3% - 工程价值：机器人 agent 方向可直接参考
R2b · LFM2.5-Encoder：CPU 长文本编码器，8K tokens 仅 28 秒 ⭐⭐⭐⭐ - 来源：@maximelabonne，链接：https://x.com/liquidai/status/2081305857479736577 - 仓库：huggingface.co/LiquidAI/LFM2.5-Encoder-230M - 双向混合 SSM+注意力架构，230M 参数 - 对比 ModernBERT：3.7× faster（28s vs 90s+） - 边缘部署性价比极高
R2c · LlamaParse 智能路由：PDF 解析成本降低 50-90% ⭐⭐⭐⭐ - 来源：@jerryjliu0，链接：https://x.com/jerryjliu0/status/2081069940099141951 - 核心：自动判别页面复杂度（文本页走廉价 OCR，表格/图表页才上 VLM） - vs Opus 5 自解析：节省 50-90% token 成本，精度更高 - 具体数字：agentic 模式 $0.0125/页 vs Opus 5 端到端 $0.08-$0.33/页
分类标签总览
| 类别 | 条目数 | 最高价值 |
|---|---|---|
| Database | 3 | D2 DUAL-BLADE（ICDCS 2026） |
| Backend | 4 | B1 MCP 2.0 / B3 Lilian Weng Harness / B4 ByteByteGo Agent Loop |
| Cloud-Native | 1 | C1 MCP 2.0 云原生影响 |
| CSDN | 2 | CS1 企业 Agent 工程化 |
| Reproduction | 2 | R1 MirrorCode / R2 X Tech Radar |
建议写入路径
按主题分别建议：
- MCP 2.0 / Agent Protocol 相关 → 2026-08-01-mcp2-agent-protocol-arxiv-harness.md
- KV-Cache 系统工程（offloading/compression/security） → 2026-08-01-kvcache-systems-arxiv-icdcs-ndss.md
- 推理引擎基准综合对比 → 2026-08-01-inference-engine-benchmark-h100-2026.md
- Coding Agent Benchmark / X Tech Radar 线索 → 2026-08-01-coding-agent-benchmark-mirrorcode-techradar.md
精读/审稿/主题页更新建议
| 优先级 | 操作 | 原因 |
|---|---|---|
| ⭐⭐⭐⭐⭐ 精读 | MCP 2.0 官方博客全文 | 协议层重大变更，生产环境必须跟进 |
| ⭐⭐⭐⭐⭐ 精读 | DUAL-BLADE arXiv 原文 | ICDCS 2026，边缘推理 KV 卸载完整方案 |
| ⭐⭐⭐⭐⭐ 精读 | Lilian Weng Harness Engineering 全文 | Agent 架构理论基础，需配合 ByteByteGo 文章对照 |
| ⭐⭐⭐⭐ 精读 | Shadow in the Cache (NDSS 2026) | KV-cache 安全风险，生产部署安全评估必备 |
| ⭐⭐⭐⭐ 审稿 | MirrorCode Benchmark 代码仓库 | 可复现的长期任务 agent 评测基准 |
| ⭐⭐⭐⭐ 审稿 | KV Cache Transform Coding (ICLR 2026) | 与 DUAL-BLADE 互补的 KV-cache 压缩路线 |
| ⭐⭐⭐ 审稿 | ByteByteGo OpenAI Agent Loop 全文 | 原文 8000 char 截断，需补全 harness 层细节 |
元信息
- 本次简报生成时间：2026-08-01 15:05（Asia/Shanghai）
- 本次简报覆盖时间窗口：今日新发现 + 近一周高价值条目
- 已有对应简报：午间 arXiv 推理系统简报（13:35）、晨间五类简报（11:05）
- 建议：MCP 2.0 和 DUAL-BLADE 可合并入下一轮知识库主题页更新