84 篇博文 含有标签「AI」

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 这条线讲透到能直接上手。

单 Agent 的瓶颈很直观：上下文窗口有上限、一次只能专注一件事、越长的对话越容易跑偏。于是大家开始拆多 Agent——一个检索、一个写代码、一个质检、一个做安全审查。但真正上手做过的人会发现，多 Agent 协作的难点从来不是"让 Agent 会聊天"，而是编排（Orchestration）：任务怎么拆、谁先谁后、上下文怎么隔离、结果怎么合并、一个挂了怎么办。

本文不重复上一篇 A2A 协议（A2A 协议深挖），那解决的是"Agent 之间怎么发现和通信"的协议层；这篇解决的是"有了通信之后，你怎么组织它们干活"的工程层。协议是网卡，编排是大脑。

很多人到现在还分不清 MCP 和 A2A 的区别，把它们当成一回事。一句话讲清：MCP 是给 Agent 接外设的 USB 接口，A2A 是给 Agent 联网的网卡。MCP 让一个 Agent 用统一方式调用工具、文件、数据库；A2A 让多个 Agent 之间互相发现、协商、委托任务。上篇拆解了 MCP 2026-07-28 新规范（MCP 规范解读），这篇聊它的姊妹协议 A2A。

先抛一个反直觉的结论：RAG 效果不好的时候，九成问题出在检索，而不是生成。生成模型再强，检索漏掉的 chunk 永远不会出现在 context 里——"垃圾进，垃圾出"在 RAG 里是一条铁律。业界普遍共识是「检索质量决定 RAG 上限」：生成只能在上限之内修修补补，把答案写得通顺，但补不回没检索到的事实。

本文不聊"如何搭一个 hello-world RAG"，而是拆解检索链路里真正决定召回率的三个环节——分块（Chunking）、检索融合（Hybrid Search）、重排序（Re-ranking）——每一环给出可运行代码、性能量级和生产踩坑记录。这是我在多个生产 RAG 系统里反复调过的地方。

先摆一个反差数字：Llama-2-70B 的 FP16 权重约 140 GB，量化到 4-bit 后约 35 GB，压缩 75%，而它在 WikiText2 上的 perplexity 只上升 0.1~0.3。这意味着原本要两台 A100-80G 才装得下的模型，量化后一台就够，decode 速度反而更快——因为权重小到能塞进更大的显存余量里，KV cache 也能放得更长。

为什么「省显存」和「不掉精度」能同时成立？答案藏在 LLM 推理的真实瓶颈里。这篇拆四条主流量化路线（GPTQ / AWQ / GGUF / NF4）的原理、可运行代码和选型，写给要在生产里真刀真枪跑量化的人。

一个 agent 连续跟你工作三周后，突然忘了你的数据库密码格式约定、忘了上周定的接口规范——这不是 bug，是它的记忆系统根本没设计。上下文窗口是「RAM」，断电（会话结束）就没了；真正的记忆系统，是往 RAM 之外再加一层「硬盘 + 索引」。