「这个模型写代码不错」和「这个 Agent 能完成 20 轮工具调用把事办成」是两回事。单轮评测测的是「会不会答」，Agent 评测测的是「会不会把事情办成」——后者涉及状态、工具副作用、长程规划，评测的复杂度直接上了一个数量级。
上一篇LLM 评测工程化讲了单轮文本评测的偏见与校准，这篇聚焦 Agent 场景：评测什么、拿什么当标准答案、怎么写评测骨架、怎么避免评测本身成为成本黑洞。面向已经在跑 Agent 生产流量的后端工程师，不讲科普。
2026 年 8 月，两条看起来不相关的新闻放在一起读，信息量很大：
第一条讲的是"显存为什么不够用"，第二条讲的是"不够用了之后系统该怎么办"。第二条对 AI 推理工程师尤其有参考价值——因为 vLLM 的 CPU offload、llama.cpp 的 mmap、推理服务的显存超卖，本质上是同一个问题：物理显存放不下，被迫把数据换到 PCIe 那头的内存里，系统怎么把损失降到最小。
2026 年 8 月 17 日，Anysphere 宣布 Origin Code Hosting：Cursor 开始直接托管你的代码，面向所有付费计划用户开放 early beta。Hacker News 当天热度 482 分、374 条评论——但讨论的焦点并不全是"又一个 GitHub 替代品"，更多是"Agent 时代代码托管到底应该长什么样"。
这篇文章不重复发布会通稿，而是从工程视角拆三个问题：Origin 在技术上做了什么、它踩中了 AI 工程的哪个痛点、以及它对现有团队（尤其是自托管/合规敏感的团队）意味着什么。
这是「每日一题」专栏的第七篇。每天一道面试题，后端 + AI 混合路线，从原理到代码一次讲清。上一篇讲了分布式 ID 生成器，今天回到 AI/LLM 方向，聊一个让你在长上下文推理时 OOM 的元凶。
很多后端工程师第一次接触 LLM 推理都会困惑：为什么 prefill 快如闪电，decode 却一个字一个字地蹦？为什么 8B 模型的 fp16 权重才 16GB，vLLM 却要求 40GB 以上显存？答案都指向同一个东西：KV Cache。它既是 decode 速度的根基，也是推理服务显存和带宽的最大开销。这篇文章从显存账本算起，讲清楚 KV Cache 为什么是推理性能的隐形瓶颈，PagedAttention 如何用「虚拟内存」的思路解决碎片化，以及 GQA、MLA、量化、prefix caching 各自省掉了什么、代价是什么。文末附一个可运行的 numpy 最小实现和生产环境踩坑清单。
2026 年 8 月 17 日，Wiz Research 公开了一项针对 Snowflake 的安全研究：他们的自主 AI 安全工具「Red Agent」发现并利用了一个 GitHub Actions 脚本注入漏洞，在无人工干预的情况下拿到了 Snowflake 内部 Jira（snowflakecomputing.atlassian.net）的只读访问权限——覆盖工程、安全合规、漏洞赏金项目的数据。漏洞从上线到被攻破只有 5 天，而引入漏洞的 PR 的 co-author 是 "Copilot Autofix powered by AI"。
对做 AI 工程的人来说，这是一次教科书级的「反噬」案例：AI 写代码的能力正在快速商品化，但 AI 生成代码的安全治理才刚刚开始。这篇文章把整个事件拆开：漏洞怎么来的、为什么做了 sed 转义还是被注入、Red Agent 如何从执行报错里自我纠错完成利用、以及工程上到底该加哪些护栏。
前两篇分别聊了向量数据库选型（向量数据库选型对比）和检索链路的分块/重排序（RAG 检索优化深度拆解），但都把 Embedding 模型当成了黑盒——喂进去文本，吐出来一串浮点向量。这篇把盒子拆开，聚焦一个高级后端工程师做规模化 RAG 时迟早会撞上的问题：向量又大又多，存储和检索延迟怎么砍？
先算笔账。一个 100 万 chunk 的语料库，用 1536 维 float32 的 Embedding（比如 text-embedding-3-small），单是向量本体就是：
1,000,000 × 1536 × 4 字节 ≈ 6.1 GB
这还没算 HNSW 图索引的开销（通常再乘 1.2 到 1.5 倍）。规模涨到 1000 万 chunk，向量本体就 61GB，单机内存放不下，得上分布式。但真相是：绝大多数检索场景根本用不到 1536 维的全精度浮点。今天聊的三件事——对比学习怎么训出 Embedding、Matryoshka 怎么一个模型任意维度截断、量化怎么把向量压 8 到 32 倍——就是把这笔账砍下来的三条路。
2026 年 8 月，智谱发布 GLM-5.3，官方把这次更新的关键词定成两个：Coding 和 安全。前者不意外——上一代 GLM-5 的编程能力已经逼近闭源第一梯队；真正值得注意的是后者：模型发布前两周，智谱联合清华、南开及多家企业做了密集红队测试，累计发现漏洞 2404 个（初筛去重后），其中 1088 个中高危，覆盖系统内核、浏览器引擎、开源基础组件、互联网应用与协议等 220 个项目。在 CyberGym 白盒代码审查评测上，GLM-5.3 拿到 84.5%（上一代 5.2 为 77.2%），成为开源阵营里分数最高的安全模型。
为什么一个 Coding 模型要死磕安全？答案很直接：Coding Agent 已经从"给一段代码"进化到"读整个仓库、改文件、跑终端、装依赖、参与部署"，拿到的权限越来越高，一次判断失误的后果被成倍放大。 当 AI 以机器速度写代码、操作系统时，安全必须跟上机器速度。这篇文章以 GLM-5.3 的实测为样本，拆解 Coding Agent 安全能力的三层结构：白盒审计、漏洞推理、证据分级——并讨论这套能力该怎么评测、怎么用。
2026 年 8 月中旬，Qwen 开源了 Qwen3.8-27B：270 亿参数的稠密（Dense）原生多模态模型，Apache 2.0 协议。两个数字让它在一众开源模型里显得特殊——262K 原生上下文（YaRN 可外推到 1M）和量化后 24GB 显存可部署（RTX 3090/4090 级别）。官方 benchmark 里，它在 SWE-bench Pro 上比 Claude Opus 4.6 Max 高出 8.3 分，QwenSWEBench 上领先 15.2 分。
对做工程的人来说，这条新闻的真正信号不是"又一个榜单刷分"，而是：长上下文 + 强 Agent 能力开始向消费级硬件下沉。这背后是架构层面的变化——Qwen3.8-27B 的 64 层里只有 16 层是标准 Attention，其余 48 层换成了 Gated DeltaNet 线性注意力，按"三层线性 + 一层完整 Attention"循环排列。这篇文章拆解这个设计到底解决了什么问题、KV Cache 的账怎么算、以及部署时要注意什么。
全参微调（full fine-tuning）的成本账很吓人：训练时除了权重本身，还要存梯度，以及 Adam 优化器的一阶矩、二阶矩两个状态。一个 7B 模型，权重 bf16 约 14GB，梯度 14GB，Adam 状态约 28GB，再加上激活和中间结果，全参微调 7B 要 60GB 以上显存，70B 直接破 600GB。这不是普通工程师玩得起的。
于是有了参数高效微调（PEFT）三件套：Adapter、Prefix Tuning、LoRA。其中 LoRA（Low-Rank Adaptation，微软 2021）因为"训练省显存、推理时可合并、能热插拔多任务"成为事实标准；QLoRA（2023）进一步把底座量化到 4bit，让 65B 模型在单张 48GB 消费卡上做微调成为可能。本文不重复上一篇多 Agent 编排（多 Agent 协作架构），专注把 LoRA/QLoRA 这条线讲透到能直接上手。