84 篇博文 含有标签「AI」

AI 生成代码的比例正在快速攀升，但绝大多数团队的评审流程还停留在「AI 写完 → 人看一眼 diff → 合入」。这条链路在 2026 年 8 月被 Wiz Research 的 Snowflake 案例打穿了：一个由 Copilot Autofix 参与合入的 GitHub Actions 变更，引入了一个脚本注入漏洞，5 天后就被自主安全 Agent 攻破，拿到了内部 Jira 的只读权限——而 AI 辅助评审（Copilot 作为 co-author）当时判定 all-clear。

这不是孤例。HN 上「How do you review and validate LLM generated code?」的讨论里，一线工程师的共识很朴素：AI 写代码的节奏变了，但「验证代码」的严谨度不能跟着降级，反而要升级。本文把 AI 时代的代码验证拆成四层，讲清每一层做什么、在哪一层容易翻车。

系统提示词（system prompt）正在成为 LLM 推理成本里最容易被忽略的部分。一个正经的 Agent 通常要背几十条指令、工具 schema、few-shot 示例和安全约束，动辄几千 token。每次请求都要编码这些 token，decode 时每个生成 token 又要对它们做 attention——长度是线性成本，而吞吐是用户的账单。

2026 年 8 月 19 日，Shopify Engineering 公开了他们在生产环境落地的一项技术：gisting。他们把自己的 GraphQL Agent 系统提示词从约 6000 token 压到约 1500 个 gist token（4:1 压缩），在预测质量不掉的前提下，把 350 RPM 流量下的 TTFT 从 438ms 降到 354ms（-19%）、端到端延迟从 6.8s 降到 4.2s（-38%）、吞吐从 20.2 QPS 提到 23.4 QPS（+16%），最终少用了 14% 的 GPU。这篇文章拆解它背后的原理、训练细节和部署方式。

流式输出（streaming）已经是 LLM 应用的默认形态——用户等不了非流式的 TTFB，ChatGPT 系的打字机效果也成了产品预期。但对后端工程师来说，SSE 协议本身只有半小时的学习成本，真正的工程难点在异步管道的生命周期管理：客户端慢了怎么办？上游断了怎么办？用户关页面了，上游还在生成、还在烧钱，怎么办？这篇文章聊的就是这些。

语音 Agent 和文本 Agent 的体验差距，往往不在模型智商，而在延迟和打断。文本场景用户等 3 秒没问题；语音场景超过 800ms 不说话，用户就会开始重复提问。而「打断」——用户中途插话——是语音交互里最高频、也最容易做砸的环节。

这篇讲语音 Agent 工程化：端到端延迟预算怎么拆、流式 ASR 的架构选择、打断（barge-in）与全双工设计。面向要自建语音链路而不是只调云 API 的工程师。上一篇多模态 VLM 工程指南讲了视觉侧，这篇补上听觉侧。

推理集群的利用率为什么普遍只有 30%-50%？大多数时候不是模型不够强，而是调度层把 GPU 当成了「特别大号的 CPU」。这张卡该不该给、给多少、和谁共享、抢占了谁——每一步都决定你是多跑一倍任务，还是天天看着显存碎片和排队干瞪眼。

上一篇Linux VRAM overcommit 与显存超卖讲了单机层面的显存管理，这篇往上一层：K8s 集群里 GPU 是怎么被调度、切分和排队的。面向要搭推理集群的 SRE / 平台工程师，从 Device Plugin 讲到 Kueue、Volcano，附可直接抄的 YAML。

「这个模型写代码不错」和「这个 Agent 能完成 20 轮工具调用把事办成」是两回事。单轮评测测的是「会不会答」，Agent 评测测的是「会不会把事情办成」——后者涉及状态、工具副作用、长程规划，评测的复杂度直接上了一个数量级。

上一篇LLM 评测工程化讲了单轮文本评测的偏见与校准，这篇聚焦 Agent 场景：评测什么、拿什么当标准答案、怎么写评测骨架、怎么避免评测本身成为成本黑洞。面向已经在跑 Agent 生产流量的后端工程师，不讲科普。

2026 年 8 月，两条看起来不相关的新闻放在一起读，信息量很大：

1. Tom's Hardware 报道 DRAM 价格 12 个月涨了约 500%，HBM/GDDR 的供应紧张让"显存"成了整个 AI 产业链最贵的消耗品；
2. 一位 Linux 图形栈开发者（pixelcluster.dev）多年打磨的 VRAM 管理补丁合入主线、随 Linux 7.3 发布：当 GPU 显存被"超卖"（overcommit）时，系统不再随机崩溃，而是尽量优雅地降速。

第一条讲的是"显存为什么不够用"，第二条讲的是"不够用了之后系统该怎么办"。第二条对 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 最小实现和生产环境踩坑清单。