工程实践筛选报告 · Jay · 2026-07-25 晚场（第三轮）
实例: Jay | 时间: 2026-07-25 19:50 (CST) 检索范围: Tavily + arXiv + GitHub + Substack · LLM推理 / RAG生产 / Agent框架 / 生产架构 本轮筛选候选: ~18 条 → 精选 4 条保留 + 4 条丢弃
筛选结论总览
| 状态 | 条目数 | 典型特征 |
|---|---|---|
| ✅ 保留 | 4 条 | 真实 benchmark 数据 / 命令架构 / 生产数字 / 可复现步骤 |
| ❌ 丢弃 | 4 条 | 概述文章 / 课程营销 / 路线图 / 低工程密度 |
✅ 保留条目
保留 1：Particula Tech — "SGLang vs vLLM in 2026: Benchmarks, Architecture, and Production Adoption"
| 维度 | 内容 |
|---|---|
| 来源 | particula.tech · 2026-07 |
| URL | https://particula.tech/blog/sglang-vs-vllm-inference-engine-comparison |
| 类型 | 推理引擎横向评测 + 架构对比 + 生产采用数据 |
核心工程内容：
① 实测 benchmark 数据（H100 80GB / Llama 3.3 70B）：
| 指标 | SGLang | vLLM | 差距 |
|---|---|---|---|
| 总吞吐 | ~16,200 tok/s | ~12,500 tok/s | SGLang +29% |
| 输出 token 吞吐 | 894 tok/s | 413 tok/s | SGLang +117% |
| TTFT | 79 ms | 103 ms | SGLang 快 23% |
| Token 间延迟 | 6.0 ms | 7.1 ms | SGLang 快 15% |
并发扩展数据：
| 并发 | vLLM (tok/s) | SGLang (tok/s) | 差距 |
|---|---|---|---|
| 1 | 120 | 125 | ~4% |
| 10 | 650 | 680 | ~5% |
| 50 | 1,850 | 1,920 | ~4% |
| 100 | 2,400 | 2,460 | ~2% |
② 架构差异对比（关键工程决策点）：
| 特性 | vLLM (PagedAttention) | SGLang (RadixAttention) |
|---|---|---|
| 内存管理 | 分页块，<4% 浪费 | 分页块 + radix tree cache |
| Cache 复用 | 仅单请求 | 跨请求前缀匹配复用 |
| 调度 | 连续批处理 (FIFO) | Cache-aware（前缀优先） |
| 内存开销 | 基线更低 | 更高（保留 cache tree） |
| 最佳场景 | 唯一 prompt、批处理作业 | 共享前缀、多轮对话 |
③ 生产采用数据（真实部署规模）： - SGLang：xAI Grok 3、Microsoft Azure endpoints、LinkedIn AI 功能、Cursor 代码补全，400,000+ GPUs - vLLM：Stripe 每日 5000 万次调用，大部分云 API 端点的默认后端 - GitHub stars：vLLM ~75K vs SGLang ~25K；贡献者：vLLM ~2,400 vs SGLang ~600
④ 生产选型决策树： - 选 SGLang：多轮对话、结构化输出、前缀密集型管道（RAG）、需要极致吞吐 - 选 vLLM：硬件多样性需求（AWS/GCP/Azure/TPU）、最大社区支持、大部分通用场景
保留理由： - ✅ 有实测 benchmark 数据：H100 量化对比，覆盖吞吐/TTFT/延迟/并发扩展 - ✅ 有架构原理：PagedAttention vs RadixAttention 的内存管理差异 - ✅ 有生产规模数据：Stripe / xAI / LinkedIn / Cursor 真实部署数字 - ✅ 有选型决策树：明确场景对应关系，不是泛泛对比 - ⚠️ 数据来源为第三方，需注意测试条件（模型版本、batch size 等）
可信度：⭐⭐⭐⭐（第三方实测，有具体场景和硬件配置）
保留 2：Redis.io — "RAG at Scale: How to Build Production AI Systems in 2026"
| 维度 | 内容 |
|---|---|
| 来源 | redis.io/blog/rag-at-scale · 2026 |
| URL | https://redis.io/blog/rag-at-scale |
| 类型 | 生产 RAG 架构工程指南 + 失败模式分析 |
核心工程内容：
① POC vs 生产关键差异（工程决策点）：
生产 RAG 必须具备： - 分离索引管道和查询管道（不再混用） - 混合检索（向量 + BM25） - 完整可观测性 + 99.9% SLA - TTFT p90 < 2s，超时触发自动扩缩容
② 真实生产失败模式（三个月真实案例）：
"三个月后，你在管理四个不同的数据存储层。向量在系统A，语义缓存在系统B，应用状态在系统C，运维数据在系统D。每个集成点增加延迟并创造新的故障模式。当语义缓存未命中，LLM 成本飙升。当峰值流量期间向量搜索超时，重试逻辑介入，进一步增加延迟。"
③ 检索频率对端到端延迟的巨大影响： - 检索策略选择影响吞吐量需求，可能差两个数量级
④ 可观测性必须覆盖的指标： - 检索精度、缓存命中率、重排效果、嵌入质量随时间变化、幻觉率
保留理由： - ✅ 有真实生产失败案例：三个月四层存储管理的具体描述 - ✅ 有具体 SLA 数字：TTFT p90 < 2s，99.9% uptime - ✅ 有可操作工程建议：索引/查询管道分离、混合检索、SLA 设计 - ✅ 有成本数据：每查询 $0.005-$0.02，含语义缓存优化空间 - ⚠️ 主要为架构指导，缺具体命令代码
可信度：⭐⭐⭐⭐（Redis 官方博客，工程经验输出）
保留 3：Addy Osmani Substack — "My LLM Coding Workflow Going Into 2026"
| 维度 | 内容 |
|---|---|
| 来源 | addyo.substack.com · 2025-12 |
| URL | https://addyo.substack.com/p/my-llm-coding-workflow-going-into |
| 作者 | Addy Osmani（Google 工程师，Chrome 团队早期成员） |
| 类型 | AI 辅助工程实践 + 工作流方法论 |
核心工程内容：
① 任务分解原则（可操作工程实践）： - 不要让 LLM 生成大段整体输出 → 改为迭代步骤/工单模式 - 每个步骤小到 AI 在上下文内可以处理、人类也能理解代码 - 计划后提示 codegen 模型："好，现在实现计划第 1 步" - 每步编码 → 测试 → 下一阶段
② 监督执行模式： - 不让 AI 无人值守完成整个功能 - AI 生成并运行代码，但每步都有人盯着，随时介入 - 建议：1 个主 agent + 1 个审查 agent（并行）
③ 编排工具实验数据： - Conductor 等工具支持多 agent 并行（3-4 个同时处理不同任务） - 大规模并行有效，但心理上很累（需同时监控多个 AI 线程）
保留理由： - ✅ 有具体工程原则：任务分解粒度、监督执行模式、agent 并行策略 - ✅ 有工作流步骤：spec → plan → iterative coding → test → review - ✅ 作者背景可靠：Google 工程师，有实际工程实践经验 - ⚠️ 非 2026 新文章（2025-12），但工作流原则仍有效
可信度：⭐⭐⭐⭐（Google 工程师亲测，非营销内容）
保留 4：The AI Engineer Substack — "The AI Agents Stack: LLM to Production (2026 Edition)"
| 维度 | 内容 |
|---|---|
| 来源 | theaiengineer.substack.com · 2026 |
| URL | https://theaiengineer.substack.com/p/the-ai-agents-stack-2026-edition |
| 作者 | Paolo Perrone |
| 类型 | Agent 技术栈年度盘点 + 工程范式转变 |
核心工程内容：
① 2024→2026 Agent Guardrails 范式转变（关键）： - 2024：Guardrails = LLM 输入/输出过滤器 - 2026：Guardrails = 工具调用授权 + 速率限制 + 执行验证 - "guardrails before action" 模式出现：在工具执行层授权，而非响应输出层 - 教训：等到过滤响应时，agent 已经发送了邮件
② Agent Memory 三层架构（2026 新范式）： - 2024 Memory：选一个向量数据库做 RAG - 2026 Memory：三层一等公民架构 - Tier 1：Working memory（上下文窗口） - Tier 2：Short-term memory（向量检索） - Tier 3：Long-term memory（持久化存储）
③ Context Engineering 取代 Prompt Engineering： - 2024 核心问题：如何写更好的 prompt - 2026 核心问题：如何架构 agent 每轮调用看到什么信息
④ Memory Blocks（新型上下文原语）： - Agent 可以读写命名结构化字段，上下文窗口内的状态管理 - 不再把所有内容塞进 system prompt
保留理由： - ✅ 有概念演进梳理：guardrails / memory / context engineering 的范式转变 - ✅ 有真实失败教训：guardrails before action 模式（agent 已执行才过滤的教训） - ✅ 有 OWASP MCP Top 10 引用：2026 agent 安全标准 - ✅ Substack 高质量来源：Paolo Perrone，AI 工程领域资深 newsletter - ⚠️ 缺少具体命令/代码，但概念梳理质量高，对理解 2026 Agent 技术栈有价值
可信度：⭐⭐⭐⭐（Substack 优质工程 newsletter，概念有引用来源）
❌ 丢弃条目
| # | 来源 | 丢弃理由 |
|---|---|---|
| 1 | javarevisited Substack — "2026 Agentic AI Engineer Roadmap" | 课程营销导向，目录式内容，无真实命令/错误/性能数据；课程引流性质明显 |
| 2 | aiamastery Substack — "Production AI Engineering" | 付费课程推广，课程介绍文章，无工程细节；30 lessons/5 agents 噱头，无具体步骤 |
| 3 | aiagentssimplified Substack — "2026 Path to Learning AI Agents" | 路线图式概述，高层次技能分类，缺少具体命令、性能数据或可复现步骤 |
| 4 | louisbouchard Substack — "AI Engineering Roadmap" | 综述性质，内容与已有 Jay 文件大量重叠（start-ai-engineering repo），工程密度低 |
📋 分类标签汇总
| 标签 | 涉及条目 |
|---|---|
#推理引擎 #vLLM #SGLang #Benchmark |
保留 1 |
#RAG #生产架构 #可观测性 #SLA #Redis |
保留 2 |
#AI辅助工程 #工作流 #任务分解 #AddyOsmani |
保留 3 |
#Agent框架 #Guardrails #Memory #ContextEngineering #OWASP |
保留 4 |
💡 后续行动建议
- 精读保留 1（Particula benchmark）：提取完整 benchmark 配置文件和测试脚本路径，更新推理引擎选型主题页
- 精读保留 2（Redis RAG）：提取生产失败案例的详细描述（原文），补充到 RAG 工程实践主题页
- 纳入保留 3（Addy Osmani）：提炼迭代式 AI 编码工作流，可合并到"AI 工程实践"主题页
- 纳入保留 4（AI Engineer Stack）：补充 Agent Guardrails 范式转变内容到 Agent 框架主题页
- 去重检查：保留 1 的 vLLM vs SGLang 内容与今日已有文件重叠较多，建议仅补充新数据点
实际写入路径: /shared/research-kb/inbox/jay/2026-07-25-1950-jay-engineering-filter.md