Jay 工程文章筛选报告 · 2026-08-11 14:50 (第三次)

筛选主题

推理引擎横评 · Agent 评测框架 · RAG 评估体系 · 生产排障

检索范围

• GitHub（benchmark 仓库、awesome 列表、源码分析）
• arXiv（Agent harness 评测、推理系统）
• Substack（The AI Engineer、Agent 开发实践）
• 工程博客（Kubenatives vLLM OOM runbook）

一、今日已有内容确认（需去重）

二、候选条目筛选结果

✅ 保留 — 高价值工程条目

1. GitHub: srawlin/vllm-vs-sglang-performance-benchmark

URL: https://github.com/srawlin/vllm-vs-sglang-performance-benchmark
类型: 可复现 Benchmark 仓库

保留理由： - 真实测试数据集：5 类 JSON 文件（short_chat.json 32token、medium_chat.json 512token、long_rag.json 2048token、xl_rag.json 8192token、cache_reuse.json 前缀缓存） - 可执行 Benchmark 命令：python benchmark.py --server-url --api-key --model-name --test short_chat 实际脚本逻辑 - Troubleshooting 章节：SSL 证书错误、Timeout 错误（--timeout 600）、Memory 错误（降低并发 --concurrency） - 硬件规格说明：H100 双卡实测环境 - 与已有内容区分：已有报告侧重生产选型，此仓库提供可本地复现的 benchmark 脚本 + 数据集路径，对工程团队有直接复现价值

可信度: 高（开源可复现）
建议行动: 写入草稿，链接可作为知识库「推理引擎 benchmark」章节的复现材料

2. Kubenatives: Production Runbook: vLLM OOM Debugging

URL: https://www.kubenatives.com/p/production-runbook-vllm-oom-debugging
类型: 生产排障 runbook（Substack 受阻，需付费查看完整版）

保留理由： - 真实错误信息：torch.cuda.OutOfMemoryError: CUDA out of memory 和 RuntimeError: NCCL error: out of memory（已在 snippet 中提取） - kubectl 诊断命令：kubectl get pod <name> -o jsonpath='{.spec.containers.resources}' - 内存估算规则： 8B model: memory limit = 16-24 Gi 13B model: memory limit = 24-32 Gi 70B model: memory limit = 48-64 Gi - 关键工程洞察：vLLM Pod 禁止设置 CPU limits——会导致 request throttling，只设 requests 不设 limits - 完整 resources YAML 示例：含 requests、limits、nvidia.com/gpu: "2" 的生产配置 - 与已有内容区分：今日简报覆盖了「vLLM OOM」问题但未给出 kubectl 诊断命令和内存规则，此条目是唯一含具体命令和错误日志的来源

可信度: 高（生产运维经验，有具体错误 + 命令）
注意: 完整内容需付费，snippet 已提取关键诊断路径和 YAML 示例，足够记录精华

3. arXiv: Stop Comparing LLM Agents Without Disclosing the Harness (2605.23950)

URL: https://arxiv.org/html/2605.23950v1
类型: 学术论文（方法论）

保留理由： - 核心观点：Harness（评测框架）对 Agent 性能影响巨大，不同 harness 下同一模型排名可能完全不同 - 实验设计：GPT-5.4、Kimi K2.6、GLM-5.1 在 3 种 harness 配置 {H1, H2, H3} × SWE-bench Verified 100 题变体上的结果 - 工程意义：评测结果 ≠ 模型能力，评测时应强制披露 harness 配置；这是 Agent 工程化的方法论里程碑 - 与已有内容区分：今日晨间简报提及了「Agent 评测」但未覆盖 harness variance 的量化证据

可信度: 高（arXiv 2026，实验设计严谨）
建议行动: 写入草稿，核心结论值得进入知识库「Agent 评测方法论」条目

4. arXiv: Harness-Bench: Measuring Harness Effects across Models (2605.27922)

URL: https://arxiv.org/html/2605.27922v1
类型: 学术论文

保留理由： - 核心贡献：提出 Harness-Bench，通过变换 harness 而非模型来测量 harness 效应；支持对 completion、tool use、state management、permission handling、robustness、token cost 的分析 - 与已有内容互补：2605.23950 是「发现问题」，本文是「提出系统性测量方法」，两者构成「问题 → 方法」关系 - 工程价值：为 Agent 框架选型提供了可量化的评测框架参考

可信度: 高（arXiv 2026）
建议行动: 与条目 3 合并写入「Agent Harness 评测方法论」草稿

5. arXiv: LoopsBench: From Harness Engineering to Loop Engineering (2608.00267)

URL: https://arxiv.org/html/2608.00267v1
类型: 学术论文

保留理由： - 核心贡献：指出 SWE-bench 等现有 benchmark 只测「最终 artifact」，而非「产生 artifact 的 loop 质量」；提出 Loop Engineering 作为新研究方向 - 与 SWE-bench 的区别：不测「patch 对不对」，而测「loop 的状态管理、回归压力、执行连续性」 - 工程意义：对长期运行的多步 Agent 系统（代码生成、自动化工作流）的评测设计有直接指导意义

可信度: 高（arXiv 2026，ACL/FSE 相关）
建议行动: 单独写入「Agent Loop 评测新兴研究方向」草稿，或并入条目 3/4 的 harness 评测体系

6. GitHub: ai-boost/awesome-harness-engineering

URL: https://github.com/ai-boost/awesome-harness-engineering
类型: Awesome 列表（工程实践汇编）

保留理由： - 实证基础：基于 375 个真实 GitHub issues 挖掘（AutoGen、CrewAI、OpenAI Agents SDK、LangChain、CAMEL、DB-GPT） - Fault Taxonomy（原创价值）：Agent 特异性故障分类——初始化失败、角色偏离、内存/状态缺陷、编排失败、工具集成错误 - MCP 部署现场报告：协议层 3 个生产断裂点（身份传播缺失、自适应工具预算缺失、非结构化错误语义）+ JWT 丰富工具调用等缓解模式 - Stripe Agent SDK 研究：主动引导（hard steering signals）vs 被动文档的效果差异；核心原则：「若 guidance 未在 loaded context 中，则等于不存在」

可信度: 高（实证 + 原创分类）
建议行动: 写入「Agent 工程故障分类学 + MCP 生产实践」草稿

⚠️ 有条件保留 — 需核实是否已覆盖

7. The AI Engineer (Substack): vLLM vs Ollama vs SGLang vs TensorRT-LLM

URL: https://theaiengineer.substack.com/p/vllm-vs-ollama-vs-sglang-vs-tensorrt
Screening note: 晨简已覆盖 Ollama/vLLM/SGLang/TensorRT 横向对比。此 Substack 差异点在于「AI Engineer」品牌视角 + 社区讨论（Reddit/CI 反馈）。建议：读完全文后判断是否有新 benchmark 数字或生产经验再决定是否写入。

8. The AI Engineer (Substack): The AI Agents Stack: 2026 Edition

URL: https://theaiengineer.substack.com/p/the-ai-agents-stack-2026-edition
Screening note: 晨简已覆盖 Agent Stack 2026 格局。本文新增内容（估算）：记忆架构（Memory-first）、Agent Guardrails 与 LLM Guardrails 的区别（2024→2026 演进）、Eval-driven CI/CD。建议：有条件写入「Agent 工程实践 2026」补充条目，重点提取 Agent Guardrails 演进和 Eval 实践。

❌ 丢弃条目

三、分类标签汇总

#LLM-Serving #vLLM #SGLang #TensorRT-LLM #OOM-Debugging #K8s
#Agent-Evaluation #Harness-Engineering #SWE-bench #LoopsBench
#Agentic-RAG #Memory-Architecture #Eval-Driven-CI #MCP
#Production-Observability #Benchmark-Reproducibility

四、建议写入路径

五、是否需要精读/审稿/主题页更新

六、Substack 专项检查

根据 2026-06-10 启用规则，本轮 Substack 来源检查：

七、关键洞察（本次筛选新增）

1. Harness 效应已量化：3 篇新 arXiv 共同指向「Agent 性能 = f(模型, Harness)」而非单纯模型能力，Agent 评测方法论正在经历范式转变。

2. vLLM OOM 存在工程共识：CPU limits 禁止设置（会导致 throttling）已是生产经验共识，配合 kubectl 诊断和内存规则可形成可操作排障 SOP。

3. awesome-harness-engineering 的故障分类：来自 375 个真实 GitHub issues 的实证分类，比直觉性总结更可信，建议作为知识库「Agent 工程故障诊断」的分类框架参考。

报告生成时间: 2026-08-11 14:50 CST
筛选人: Jay
本轮写入: 是（4 个草稿，见「建议写入路径」）