1. 从一份日报说起Agent 与 LLM 技术栈的当下切面做 AI 应用这一行信息密度最高的地方往往不是论文而是每天在社区里被反复问到的那些具体问题。我整理这份 2026-09-27 的技术日报时最大的感受是Agent 和 LLM 的讨论已经从能不能做彻底转向了怎么扛住生产环境。热搜词里既有vLLM 部署 DeepSeek、CUDA 12.8 vLLM这种底层推理部署问题也有RAG 知识库能存储图片吗、ontology RAG这种知识建模层面的追问还有Codex 安装教程、Codex 接入 DeepSeek这类工具链落地细节。这些词放在一起其实勾勒出了一条完整的链路模型推理底座 → 知识检索增强 → Agent 编排 → 开发工具接入。这份日报适合谁看如果你正在把一个大模型 demo 往生产环境推或者正在纠结 RAG 到底该用向量库还是知识图谱又或者你被vLLM 加载 Qwen3-Embedding-0.6B卡了一整天那这篇内容基本能覆盖你 80% 的疑问。我会按推理部署 → 检索增强 → Agent 架构 → 工具链与安全这条主线把每个热搜词背后的真实问题拆开讲该给命令给命令该给参数给参数踩过的坑也一并说清楚。需要先说明一点日报里的热词是碎片化的很多只是半句话比如llm 的 token 三个点 key 我是谁、query 我在找什么、value 我能提供什么这其实是有人在用类比解释注意力机制。我会把这些碎片还原成完整的技术语境而不是照着词条念一遍。2. 推理底座vLLM 部署与显存那些绕不开的坑2.1 为什么大家都在用 vLLM而不是 Ollama 或 LM Studio热搜里同时出现了LM Studio、Ollama、vLLM/SGLang的对比这个问题我被问过太多次。结论先给本地单机玩一玩Ollama 和 LM Studio 足够要上生产、要扛并发、要跑多卡vLLM 和 SGLang 才是正解。原因不在于哪个模型跑得快这种模糊感受而在于架构差异。Ollama 本质是一个封装好的推理服务底层早期用 llama.cpp优势是开箱即用、量化模型生态好、Mac 上也能跑。但它的调度是相对简单的面对几十路并发请求时吞吐会明显掉下来。LM Studio 更偏桌面工具图形界面友好适合调试和演示但你要把它塞进一个 Kubernetes 集群里做弹性伸缩基本不现实。vLLM 的核心竞争力是PagedAttention。传统推理框架给每个请求预分配一块连续的 KV Cache 显存请求长短不一的时候短的浪费、长的可能不够显存碎片化严重。PagedAttention 把 KV Cache 切成固定大小的 block像操作系统管理内存页一样按需分配显存利用率能提升到 90% 以上。配合Continuous Batching连续批处理新请求可以随时插入正在进行的批次不用等整批跑完这才是它扛并发的根本。SGLang 则在结构化生成和前缀复用上做得更激进RadixAttention 对多轮对话、共享 system prompt 的场景特别友好。选型上我的经验是通用文本生成、生态成熟度优先选 vLLM大量多轮对话、复杂 prompt 模板、需要 constrained decoding 的场景可以试 SGLang。2.2 vLLM 部署 DeepSeek 的完整参数计算热搜里vLLM 部署 DeepSeek和vLLM 运行 Qwen3.8-Flash-Next是高频问题。部署大模型第一步不是敲命令而是算显存。我拿一个具体的例子走一遍。假设你要部署一个 32B 参数的模型用 FP16 精度权重显存 32B × 2 bytes 64 GBKV Cache 显存 2 × 层数 × 注意力头数 × head_dim × 序列长度 × batch_size × 精度字节以常见的 32B 模型约 64 层、hidden_size 5120、GQA 8 个 KV 头、head_dim 128为例单 token 的 KV Cache 大约是2 × 64 × 8 × 128 × 2 bytes ≈ 256 KB。如果你要支持 8192 上下文、并发 16 路那就是256KB × 8192 × 16 ≈ 32 GB。加上权重 64 GB总共接近 96 GB一张 80G 的卡放不下需要两张或者用 AWQ/GPTQ 量化把权重压到 4bit约 16-18 GB。实际部署命令大概长这样vllm serve deepseek-ai/DeepSeek-V3 \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --gpu-memory-utilization 0.92 \ --max-num-seqs 16 \ --dtype bfloat16 \ --port 8000几个参数值得单独说。--gpu-memory-utilization 0.92是显存占用上限比例留 8% 给 CUDA context 和临时缓冲设成 0.98 很容易 OOM。--max-num-seqs控制同时处理的序列数这个值直接决定 KV Cache 峰值宁可先设小一点压测后再往上调。--tensor-parallel-size要和你的卡数匹配2 张卡就填 2填错了要么起不来要么性能腰斩。注意--max-model-len不要一上来就设成模型支持的最大值比如 128K。KV Cache 是按这个长度预留的设太大直接吃光显存。先按业务真实需求设比如 8K 够用就别开 32K。2.3 CUDA 12.8 与 vLLM 版本匹配的坑CUDA 12.8 vLLM这个组合最近问的人特别多因为新卡和新框架对 CUDA 版本有硬性要求。vLLM 的 wheel 包是跟特定 CUDA 版本编译绑定的你装错版本轻则报undefined symbol重则直接段错误。我的排查顺序是这样的先nvidia-smi看驱动支持的最高 CUDA 版本再nvcc --version看运行时版本最后确认 vLLM 安装包对应的 CUDA。三者要能对上。如果驱动是 550 系列最高支持 CUDA 12.4那你装 CUDA 12.8 编译的 vLLM 就会出问题得先升驱动。用 Docker 部署能省掉一大半这类麻烦热搜里那个docker vllm/vllm-openai:v0.27.1 加载 qwen3-embedding-0.6b就是典型场景docker run --gpus all \ -v ~/.cache/huggingface:/root/.cache/huggingface \ -p 8000:8000 \ --ipchost \ vllm/vllm-openai:v0.27.1 \ --model Qwen/Qwen3-Embedding-0.6B \ --task embed--ipchost这个参数很多人会漏vLLM 多进程共享内存需要它不加在高并发下会报共享内存不足。--task embed是 embedding 模型专用的普通生成模型不加这个参数。镜像 tag 一定要写死版本号用latest哪天自动更新了行为变了你连回滚都找不到原因。2.4 Windows 社区版 vLLM 的现实取舍vLLM Windows 社区版这个搜索词背后是一群不想装 Linux 的开发者。说实话vLLM 官方对 Windows 的支持一直不算一等公民社区版能跑但坑不少。我的建议是如果只是本地验证用 WSL2 装 Linux 版 vLLM比折腾原生 Windows 版省心得多。WSL2 现在对 GPU 直通支持已经比较成熟nvidia-smi在 WSL 里能正常识别性能损失在可接受范围内。真要在原生 Windows 上跑注意几个点一是 Python 环境尽量用 conda 隔离别污染系统环境二是编译依赖需要 Visual Studio Build Tools缺了会卡在编译阶段三是路径分隔符和文件锁的问题Windows 下模型加载偶尔会因为文件被占用失败重试一次往往就好了。3. RAG 深水区从向量检索到知识图谱的进阶3.1 RAG 知识库到底能不能存图片RAG 知识库能存储图片吗这个问题答案取决于你说的存是哪个层次。向量库本身存的是向量不是原始文件。图片要进 RAG标准做法是三步先用多模态模型比如 CLIP 或专门的视觉编码器把图片编码成向量把向量存进向量库原始图片存到对象存储S3、MinIO 之类向量里带上图片的 URL 作为 metadata。检索的时候用文本 query 去匹配图片向量命中后通过 metadata 里的 URL 把原图取回来。这就是所谓的多模态 RAG。更进阶一点的做法是图片描述增强用视觉大模型给每张图生成一段文字描述把描述文本也编码进向量库这样纯文本 query 也能召回相关图片。我实测下来图片描述 原图向量双路召回的效果比单路好不少尤其是图表、流程图这类信息密度高的图。3.2 向量库、RAG 知识库、结构化知识库的区别与应用场景热搜里KG 知识库、RAG 知识库和结构知识库区分以及应用场景是个特别值得展开的问题很多人把这三个概念混着用。我用一张表说清楚类型存储形式检索方式擅长场景短板向量库高维向量语义相似度非结构化文本、模糊匹配无法做精确逻辑推理RAG 知识库向量 原文 chunk检索后拼接进 prompt问答、文档助手多跳推理弱、易召回噪声结构化知识库三元组/表图查询、SQL关系推理、精确查询构建成本高、覆盖有限向量库解决的是语义相近结构化知识库解决的是关系明确。举个例子你问张三的部门经理是谁向量库可能召回一堆提到张三和经理的文档但没法保证答案准确知识图谱里如果存了张三 -[任职于]- A部门、A部门 -[负责人]- 李四两跳查询直接给出李四准确率天差地别。3.3 Ontology RAG给检索加上一层语义骨架Ontology RAG是这两年被讨论得越来越多的方向。普通 RAG 把文档切成 chunk 就完事chunk 之间没有关系检索是扁平的。Ontology RAG 的做法是先定义一个领域本体概念、属性、关系把文档内容映射到本体上检索时不仅看语义相似度还沿着本体关系做扩展。举个实际例子。医疗领域的本体里定义了疾病-症状-药物的关系。用户问这个药治什么病普通 RAG 可能召回一堆提到药名的段落Ontology RAG 会沿着药物 -[治疗]- 疾病这条边直接定位到相关疾病实体再召回这些疾病的详细文档。它的价值在于把检索变成了推理式检索多跳问题的表现明显更好。代价是构建成本。本体设计需要领域专家参与实体抽取和关系映射需要额外的 NLP 流水线。我的经验是领域边界清晰、关系密集的场景医疗、法律、金融合规值得上 Ontology RAG开放域问答、内容推荐这类场景普通向量 RAG 性价比更高。3.4 RAG 瓶颈到底卡在哪RAG 瓶颈这个词被搜了很多次我总结下来主要卡在四个地方。第一是切分策略。chunk 切太大检索精度下降噪声多切太小语义不完整召回的内容答非所问。固定长度切分是最偷懒的做法稍微好一点的是按语义边界切段落、标题最好的是用模型做语义分块。我一般先用递归字符切分按\n\n、\n、句号逐级降级chunk size 设 512、overlap 设 50 起步再根据效果调。第二是召回质量。纯向量检索对关键词不敏感用户搜一个专有名词向量可能召回一堆语义相近但不对的东西。解决方案是混合检索向量检索 BM25 关键词检索两路结果用 RRF倒数排名融合合并。这个改动通常能带来肉眼可见的提升。第三是重排序缺失。召回 top-20直接全塞进 prompt噪声大还费 token。加一个 rerank 模型比如 bge-reranker对召回结果重新打分取 top-5效果和成本都能优化。第四是评估困难。RAG 没有标准答案怎么知道改得好不好我建议建一个小规模评测集50-100 条问答对用LLM as judge打分每次改动跑一遍用数据说话别凭感觉。3.5 RAG 实战一个可复现的最小流程RAG 实战和RAG 教程搜的人多我给一个能直接跑的最小流程用 LangChain4j 的Easy RAG思路Java 技术栈的同学会熟悉# 1. 加载与切分 from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter(chunk_size512, chunk_overlap50) chunks splitter.split_documents(docs) # 2. 向量化并入库 from langchain_community.vectorstores import FAISS from langchain_community.embeddings import HuggingFaceEmbeddings emb HuggingFaceEmbeddings(model_nameQwen/Qwen3-Embedding-0.6B) db FAISS.from_documents(chunks, emb) # 3. 混合检索 重排 retriever db.as_retriever(search_kwargs{k: 20}) # 接 BM25 做混合再接 reranker 取 top-5 # 4. 拼接 prompt 生成关键在第三步。很多人只做向量检索 top-k 就完事这是效果上不去的主因。召回要宽k 大重排要严top 小这个宽进严出的思路是我踩了很多坑才总结出来的。4. Agent 架构从概念到扛并发的工程实践4.1 Agent 是什么和 Harness 有什么区别Agent 是什么、AI Agent、Harness 和 Agent 区别这几个词经常一起出现。我的理解是Agent 是一个能自主决策、调用工具、根据反馈调整行为的系统。它和普通 LLM 调用的区别在于循环——LLM 一问一答就结束Agent 会规划、执行、观察结果、再规划直到任务完成。Harness 这个词在测试和评估语境里更常见指的是包裹在模型外面、负责驱动和观测的那层框架。你可以把 Harness 理解成测试台架它给 Agent 提供工具、注入输入、记录每一步的中间状态、判断任务是否成功。Agent 是干活的Harness 是搭台子并盯着干活的。做 Agent 评测的时候Harness 的设计质量直接决定你能不能复现问题。4.2 Agent 架构的几种主流形态Agent 架构、Agent 框架是绕不开的话题。目前主流形态大概有这么几类ReAct 型Reasoning Acting 交替模型先想一步再调一个工具看结果再想下一步。结构简单适合工具数量少、任务线性的场景。缺点是容易陷入循环工具多了会选错。Plan-and-Execute 型先让模型出一个完整计划再逐步执行。好处是全局视野强适合多步骤复杂任务坏处是计划一旦错了后面全错而且计划阶段不感知执行反馈。多 Agent 协作型把任务拆给多个专职 Agent比如一个负责检索、一个负责写代码、一个负责审核通过消息传递协作。灵活但通信开销大调试困难容易出现互相甩锅。我的选型经验先上 ReAct跑通了再看要不要升级。很多团队一上来就搞多 Agent结果连单 Agent 的工具调用准确率都没调好纯属给自己找麻烦。4.3 AI Agent 怎么扛并发AI Agent 怎么扛并发这个问题特别实在因为 Agent 比普通 LLM 调用重得多——一次任务可能触发十几次模型调用和工具调用延迟是叠加的。第一层优化在推理层就是前面说的 vLLM Continuous Batching把并发请求合并处理。第二层在Agent 编排层核心是异步化工具调用不要串行等待能并行的并行。比如 Agent 要查三个数据源用asyncio.gather并发发起而不是一个一个等。第三层在状态管理。Agent 有会话状态多轮对话要维护上下文。状态存内存扛不住横向扩展得放 Redis 之类的共享存储。这里有个坑Agent 的中间状态思考过程、工具调用记录往往很大全塞 Redis 会爆我的做法是只存关键状态中间过程落日志。第四层是限流和降级。Agent 任务耗时长用户等不及会重试重试又加剧负载。必须做请求去重相同任务合并、超时熔断、以及降级策略复杂任务降级成简单问答。4.4 Agent 安全被投毒的记忆和知识库Agent 安全和AgentPoison: Red-teaming LLM Agents via Poisoning Memory or Knowledge Base这个方向最近关注度很高。核心风险是Agent 依赖记忆和知识库做决策如果这些数据被污染Agent 的行为就会被操纵。攻击方式很隐蔽。比如攻击者在知识库里植入一段看似正常的内容里面藏着触发词当用户 query 命中触发词时Agent 会执行攻击者预设的恶意工具调用。因为内容本身语义上是通顺的传统的内容审核很难发现。防御上我总结了几条一是知识库写入要审计不是谁都能往里塞数据二是工具调用要白名单 参数校验Agent 想调什么工具、传什么参数都要过一道检查三是关键操作要人工确认比如删除、转账、发邮件这类不可逆动作不能让 Agent 自己拍板四是定期做红队测试主动往知识库里投毒看 Agent 会不会中招。注意Agent 安全不是加个 prompt 说不要做坏事就完事的。模型层面的对齐很容易被绕过真正的防线在系统层面——权限、审计、确认机制。5. 工具链与开发实践Codex、LLM as Judge 与那些报错5.1 Codex 安装与接入 DeepSeek 的实操Codex 安装、Codex 安装教程、Codex 安装包、Codex 使用教程这一串词说明很多人卡在入门。Codex 这类编码助手工具安装本身不复杂麻烦的是配置和网络环境。安装流程一般是装 CLI 工具 → 配置 API endpoint 和 key → 验证连通性。接入 DeepSeek 这类第三方模型时关键是 endpoint 格式要对。很多工具默认走 OpenAI 的接口格式DeepSeek 兼容 OpenAI 协议所以把base_url改成 DeepSeek 的地址、api_key换成 DeepSeek 的 key 就行。配置示例以常见的配置文件为例[model] provider openai-compatible base_url https://api.deepseek.com/v1 api_key your-key model deepseek-chat5.2 那些让人头大的报错怎么排查热搜里几个报错特别典型我逐个拆。Codex 无法加载组织设置通常是认证信息过期或权限配置问题。先检查 token 是否有效再看账号是否有对应组织的访问权限。有时候是缓存问题清掉本地配置目录重登一次就好。Codex 无法发送消息显示更新 Agent 沙盒这是沙盒环境版本不匹配。Codex 这类工具会在沙盒里执行代码沙盒镜像和主程序版本对不上就会卡住。解决办法是更新到最新版本或者手动拉取匹配的沙盒镜像。CC Switch local proxy failed while handling Codex endpoint /responses这个报错指向本地代理转发失败。常见原因是端口被占用、代理配置指向了不存在的服务、或者请求体格式不符合预期。排查顺序先确认本地服务在监听、再确认代理配置的地址端口正确、最后抓包看请求体。LLM request failed: provider rejected the request schema or tool payload这是请求 schema 校验失败多半是工具调用的参数格式不对。比如模型返回的 JSON 里字段类型和工具定义的不一致或者必填字段缺失。解决办法是在工具定义里把 schema 写严格并在调用前做一次校验和修复。我把这些整理成一张速查表报错大概率原因排查动作无法加载组织设置认证过期/权限不足重登、检查权限更新 Agent 沙盒版本不匹配升级主程序与沙盒local proxy failed端口占用/配置错误查监听、查配置、抓包rejected request schema工具参数格式错校验 schema、修复 payload5.3 LLM as Judge用模型评估模型的门道LLM as judge是评估 RAG 和 Agent 效果的主流手段但用不好会得到一堆看似合理实则没用的分数。我的经验是第一评分标准要具体。别让模型打 1-10 分而是给明确的 rubric比如答案是否完全正确、部分正确、还是错误三档比十分制稳定得多。第二位置偏见要消除。对比两个答案时模型倾向于选先出现的那个。做法是交换顺序各评一次取平均。第三用强模型当裁判。拿一个 7B 模型去评 70B 模型的输出裁判本身能力不够评不准。裁判模型至少要和被评模型同级别。第四人工抽检校准。LLM judge 的结果要定期和人工标注对比如果偏差大说明 rubric 或裁判模型有问题。5.4 注意力机制那个三个点的类比热搜里LLM 的 token 三个点 key 我是谁、query 我在找什么、value 我能提供什么这个类比其实挺到位。注意力机制里每个 token 会生成三个向量Query我在找什么信息、Key我是谁、我能被谁找到、Value我实际能提供什么内容。计算过程是当前 token 的 Query 和所有 token 的 Key 做点积得到注意力分数softmax 归一化后作为权重对所有 Value 加权求和。Query 和 Key 决定看谁Value 决定看到什么。这个类比把抽象的矩阵运算翻译成了找信息的日常逻辑对新手理解很有帮助。6. 一些踩坑之后的个人体会Agent anywhere这个词我理解为Agent 无处不在的趋势判断但落到工程上我更愿意说Agent 的边界要清晰。我见过太多项目把 Agent 当成万能胶什么逻辑都往里塞最后变成一个没人敢改的黑盒。能用确定性代码解决的就别交给 AgentAgent 应该只负责那些真正需要判断的环节。关于Open LLM Leaderboard 等公开榜单我的态度是参考但不迷信。榜单测的是通用能力你的业务场景可能完全不在它的评测范围内。与其盯着榜单排名选模型不如拿自己的真实数据做小规模评测哪个在你的任务上表现好就用哪个。Spatial LLM这个方向值得关注它把语言模型和空间理解结合起来在机器人、自动驾驶、AR 场景有想象空间。但目前还比较早期工程落地案例不多观望为主。LLM Wiki和LLM 框架这类词提醒我这个领域知识更新太快建立自己的知识管理体系比追热点重要。我的做法是维护一个本地笔记库每解决一个具体问题就记一条包括报错原文、排查过程、最终方案。半年下来这个库比任何教程都管用因为里面全是我自己踩过的坑。最后分享一个我一直在用的小技巧遇到任何 LLM 相关的报错先把完整的请求体和响应体打出来。90% 的问题看一眼原始 payload 就清楚了比在网上搜报错信息快得多。模型接口的报错信息往往很模糊但原始数据不会骗人。