1. 从一份日报标题说起Agent 与 LLM 生态的真实切面看到Agent / LLM 技术精选日报这个标题很多人第一反应是又是一个资讯聚合。但如果你真的在一线做 Agent 和 LLM 相关的东西就会明白这类日报的价值根本不在资讯两个字而在于它把当天整个技术圈最活跃的几个方向——Agent 架构、RAG 检索增强、vLLM 推理部署、Codex 类编码助手——压缩成了一份可以快速扫读的切片。我做 Agent 开发差不多两年多从最早的 LangChain 拼装玩具到后来自己写调度、自己搭 RAG、自己上 vLLM 做推理服务踩过的坑基本覆盖了这份日报里出现的所有关键词。所以这篇东西我不打算写成日报解读而是想借这个标题把 Agent、LLM、RAG、vLLM、Codex 这几条线在真实项目里是怎么咬合在一起的掰开揉碎讲一遍。先说清楚这份内容适合谁看。如果你是完全没接触过 LLM 的小白这篇能让你搞明白Agent 到底是什么RAG 为什么老是效果不好vLLM 部署到底难在哪这些最基础但最容易被人云亦云带偏的问题。如果你已经能跑通一个 demo但一到并发、一到知识库、一到模型切换就抓瞎那这篇里的实操细节和避坑经验应该能帮你省下不少时间。如果你已经在做生产级系统那我们可以就架构选型和参数调优聊点更细的。核心关键词我会反复提到Agent、LLM、RAG、vLLM、Codex。这五个词基本构成了当前 AI 应用层到推理层的一条完整链路——LLM 是底座模型vLLM 是把它高效跑起来的推理引擎RAG 是给模型外挂知识的手段Agent 是让模型能自主调用工具、多步推理的框架Codex 类工具则是把这条链路直接落到写代码这个最刚需的场景上。理解了这条链路你看任何一份技术日报都不会再觉得是零散信息的堆砌。2. Agent 与 LLM 的底层关系别把框架当能力2.1 Agent 到底是什么和普通 LLM 调用差在哪很多人问agent 是什么网上答案一大堆但最容易被忽略的一点是Agent 不是模型是一套控制流。你直接调一次 LLM输入 prompt 输出文本这是一次函数调用。而 Agent 是在这个调用外面套了一层循环——模型输出可能是一个工具调用请求系统执行工具、把结果塞回上下文、再让模型继续推理直到模型认为任务完成。这个循环 工具 状态管理的组合才是 Agent 的本质。我见过太多人一上来就纠结用哪个 Agent 框架LangChain、AutoGPT、CrewAI、还有各种国产框架挑花眼。但实际做下来你会发现框架解决的是编排问题不解决模型能力问题。一个 7B 的模型你套再花哨的 Agent 框架它该调错工具还是调错工具该幻觉还是幻觉。所以选型顺序应该是先确定模型能力够不够再决定要不要上重框架。如果只是简单的查天气 总结一个几十行的 while 循环加 function calling 就够了没必要引入一整套依赖。这里有个概念经常被混淆harness 和 agent 的区别。Harness 通常指的是测试/评估用的外壳它负责给模型喂输入、收集输出、打分本身不做自主决策。而 Agent 是有自主决策能力的。举个例子你写个脚本批量跑 100 条测试用例看模型答对多少那是 harness你让模型自己决定先查数据库还是先调 API那是 agent。搞清楚这个区别你在做评估和做产品时就不会把两件事混在一起。2.2 LLM 的 token 机制理解它才能理解 Agent 为什么贵热词里有一条特别有意思llm 的 token 三个点 key 我是谁、query 我在找什么、value 我能提供什么。这其实是在用注意力的 QKV 机制类比 RAG 的检索逻辑很妙。但我想先把最基础的 token 讲清楚因为Agent 的成本和延迟90% 都花在 token 上。LLM 处理文本不是按字是按 token。一个中文汉字大约 1 到 2 个 token英文一个单词大约 1.3 个 token。你每次调用模型输入的 prompt 和输出的内容都按 token 计费而且上下文越长每一轮推理的计算量越大——注意力的复杂度是 O(n²)n 是序列长度。这意味着一个 Agent 如果跑了 10 轮每轮都把完整历史塞进去那第 10 轮的成本可能是第 1 轮的十几倍。我实测过一个客服 Agent单轮对话平均 800 token 输入跑到第 8 轮时输入膨胀到 6000 多 token延迟从 1.2 秒涨到 4 秒多成本翻了近 8 倍。后来做了上下文裁剪和摘要压缩把历史对话定期总结成一段短文本才把曲线压下来。所以你在设计 Agent 时上下文管理策略比模型选型更影响最终体验这一点新手几乎都会忽略。2.3 Agent 怎么扛并发这是从 demo 到生产的生死线ai agent 怎么扛并发这个问题是区分玩具和生产系统的分水岭。Demo 阶段你一个请求一个请求地跑什么问题都没有。一旦上生产几十上百个用户同时来问题全冒出来了。核心矛盾在于Agent 的一次任务往往要调用多次 LLM每次调用都是秒级延迟。如果串行处理一个用户的任务要 10 秒10 个并发用户就要 100 秒这显然不可接受。解决办法有几个层次第一层是推理层并发也就是用 vLLM 这类支持 continuous batching 的引擎把多个请求动态拼成一个 batch 一起算这是吞吐量的根本保障后面会细讲。第二层是Agent 层并发用异步框架Python 的 asyncio、Go 的 goroutine让多个 Agent 任务并行推进谁的 LLM 调用返回了就继续谁。第三层是任务队列把用户请求丢进队列用固定数量的 worker 消费避免瞬时流量打垮后端。我踩过最深的坑是一开始用同步的 requests 调 LLM并发一上来线程池直接爆掉全是超时。后来改成异步 信号量限流才稳住。这里的关键经验是——限流不是限制用户是保护你自己。你后端能扛多少并发是物理上限超过这个数的请求要么排队要么拒绝硬扛只会雪崩。3. RAG 实战从知识库选型到检索瓶颈突破3.1 RAG 知识库到底能不能存图片rag 知识库能存储图片嘛这个问题问得特别实在因为很多人做 RAG 时默认只处理文本遇到 PDF 里的图表、扫描件就懵了。答案是能但不是直接存而是转成可检索的形式。主流做法有三种。第一种是图片转文字用 OCR 或者多模态模型把图片内容描述出来存成文本块。第二种是多模态向量用 CLIP 这类模型把图片编码成向量和文本向量放同一个向量库检索时图文可以互相召回。第三种是图片单独存、文本里留引用检索命中文本后把关联的图片一起返回给用户。我做过一个产品手册的 RAG里面大量是参数表格截图。纯 OCR 效果很差表格结构全乱。后来改成用多模态模型对每张图生成一段结构化描述这是一张参数表包含型号、功率、尺寸三列……再把描述和原图 ID 关联存储。检索时命中描述返回时带上原图。实测下来用户满意度比纯 OCR 高很多。所以结论是图片能进 RAG但关键是想清楚你要检索的是图片的内容还是存在。3.2 KG 知识库、RAG 知识库、结构化知识库怎么选热词里kg 知识库、rag 知识库和结构知识库区分以及应用场景这条是很多团队选型时的真实困惑。我用一张表把三者的核心差异说清楚类型存储形式擅长场景典型短板结构化知识库表、字段、外键精确查询、统计、事务无法处理非结构化文本RAG 知识库向量 原文块语义检索、问答、文档理解检索精度依赖切块和 embeddingKG 知识库实体-关系-实体三元组多跳推理、关系查询构建成本高、维护难实际项目里我很少只用一种。最常见的是混合架构结构化数据走 SQL 精确查非结构化文档走 RAG 语义检索需要多跳关系推理的走 KG。比如一个企业知识助手员工问去年 Q3 华东区销售额最高的产品是什么这走 SQL问这个产品的售后政策怎么规定的这走 RAG问这个产品的供应商还供应哪些其他产品这走 KG。别指望一种知识库解决所有问题这是选型时最容易犯的错。3.3 RAG 瓶颈到底卡在哪检索质量才是命门rag 瓶颈这个词被搜了无数次因为太多人做出来的 RAG 效果一言难尽。我总结下来瓶颈基本集中在三个环节而且大部分问题出在检索不是生成。第一个瓶颈是切块策略。很多人默认按固定字数切500 字一块结果一句话被切成两半语义断裂。好的切块应该按语义边界切——按段落、按标题层级、按句子。我现在的默认策略是先按标题切大块大块超过阈值再按段落切段落还超就按句子切同时保留 10% 到 20% 的重叠避免边界信息丢失。第二个瓶颈是embedding 模型选择。热词里提到docker vllm/vllm-openai:v0.27.1 加载 qwen3-embedding-0.6b这其实是个很实用的组合——用 vLLM 部署 embedding 模型通过 OpenAI 兼容接口调用。embedding 模型直接决定检索的语义匹配能力中文场景下 Qwen 系列、BGE 系列都是常见选择。选型时别只看榜单一定要用你自己的数据做召回测试榜单第一的模型在你的领域数据上未必最好。第三个瓶颈是召回后的重排。向量检索召回 top-20直接全塞给 LLM 效果往往不好因为噪声太多。加一个 rerank 模型比如 BGE-reranker对召回结果重新打分取 top-3 到 top-5效果提升非常明显。我实测过一个法律问答场景加 rerank 后答案准确率从 62% 提到 81%这个投入产出比极高。3.4 ontology rag 与 rag 框架的进阶玩法ontology rag是最近比较热的方向本质是把本体ontology引入 RAG让检索不只是语义相似还带上了概念层级和关系约束。举个例子普通 RAG 检索糖尿病用药可能召回一堆相关文档而 ontology RAG 知道糖尿病是代谢疾病的子类二甲双胍是降糖药的实例检索时能沿着本体关系扩展或收窄精度更高。代价是你要先建本体成本不低适合领域知识稳定、对精度要求高的场景。至于 RAG 框架LangChain、LlamaIndex、还有热词里提到的 langchain4j easy ragJava 生态的各有取舍。我的建议是先用框架快速跑通再逐步替换掉你不满意的模块。框架的价值是帮你省掉胶水代码但它的默认切块、默认检索策略往往不是最优的生产环境该自己写的还得自己写。别被框架绑架。4. vLLM 部署实战从环境到参数调优4.1 为什么是 vLLM而不是 Ollama 或 LM Studio热词里lm studio、ollama、vllm/sglang这几个放一起说明大家在纠结推理引擎选型。我直接给结论本地玩票用 Ollama 或 LM Studio生产部署用 vLLM 或 SGLang。Ollama 和 LM Studio 的优势是开箱即用下载模型、点一下就能跑适合个人开发调试。但它们的设计目标是单用户、低并发吞吐量上不去。vLLM 的核心杀器是PagedAttention和continuous batching——前者把 KV cache 像操作系统管理内存页一样管理大幅减少显存浪费后者让不同请求的动态拼批成为可能吞吐量能比朴素实现高几倍到几十倍。我做过对比测试同样一张 A100 跑 7B 模型Ollama 单并发延迟还行但并发上到 20 就排队严重vLLM 在 20 并发下总吞吐是 Ollama 的 6 倍以上。所以如果你的场景是一个人用Ollama 够了如果是一群人用vLLM 是必选项。4.2 vLLM 部署大模型的完整流程先说最标准的 Docker 部署方式这也是生产环境最推荐的。以热词里提到的vllm/vllm-openai:v0.27.1镜像为例docker run --runtime nvidia --gpus all \ -v ~/.cache/huggingface:/root/.cache/huggingface \ -p 8000:8000 \ --ipchost \ vllm/vllm-openai:v0.27.1 \ --model Qwen/Qwen2.5-7B-Instruct \ --served-model-name qwen7b \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 1几个参数必须解释清楚因为它们直接决定你能不能跑起来--gpu-memory-utilization 0.9vLLM 会预分配 90% 显存做 KV cache。设太高容易 OOM设太低浪费显存。0.85 到 0.92 是常见区间。--max-model-len最大上下文长度。这个值越大KV cache 占用越多。如果你只需要 4K 上下文别设 32K否则显存白白被吃掉。--tensor-parallel-size张量并行数等于你用几张卡。单卡设 1双卡设 2以此类推。注意这个值必须能整除模型的注意力头数。启动后vLLM 会暴露一个 OpenAI 兼容的接口/v1/chat/completions、/v1/embeddings都能用。这意味着你原来调 OpenAI 的代码改个 base_url 就能切过来迁移成本极低。4.3 用 vLLM 部署 embedding 模型和 DeepSeek热词里docker vllm/vllm-openai:v0.27.1 加载 qwen3-embedding-0.6b和vllm 部署 deepseek是两个高频需求。embedding 模型的部署和 LLM 略有不同vllm serve Qwen/Qwen3-Embedding-0.6B \ --task embed \ --port 8001注意--task embed这个参数它告诉 vLLM 这是个 embedding 模型走/v1/embeddings接口。这样你的 RAG 系统就能用同一个 vLLM 实例同时提供生成和向量化服务架构更简洁。部署 DeepSeek 这类大模型时显存是最大门槛。DeepSeek-V3 这种 671B 的 MoE 模型即使量化后也需要多卡。实操中常见的是用--quantization参数加载量化版本或者用 tensor parallel 跨多卡。我建议先用小模型7B、14B把流程跑通再上大模型否则一上来就卡在显存问题上排查起来很痛苦。4.4 CUDA 版本与 vLLM 的兼容坑cuda128 vllm这个搜索词背后是无数人的血泪。vLLM 对 CUDA 版本、PyTorch 版本、驱动版本有比较严格的对应关系。我踩过的坑包括驱动太老导致 vLLM 起不来、CUDA 版本和 PyTorch 编译版本不匹配报错、镜像里的 CUDA 和宿主机驱动不兼容。经验是优先用官方 Docker 镜像别自己从源码编译。官方镜像已经把 CUDA、PyTorch、vLLM 的版本对齐好了你只需要保证宿主机的 NVIDIA 驱动足够新一般要求 525 以上新版本 vLLM 要求更高。如果非要用 pip 装一定先查 vLLM 官方文档的版本对应表别凭感觉装。另外vllm windows 社区版这个需求我得泼盆冷水vLLM 官方对 Windows 的支持一直很有限生产环境强烈建议用 Linux。Windows 上要么用 WSL2要么用社区维护的版本但稳定性和性能都不如原生 Linux。这不是技术歧视是 vLLM 的很多底层优化依赖 Linux 的特性。5. Codex 类编码助手安装、接入与常见故障5.1 Codex 安装与使用的基本盘codex 安装codex 安装教程codex 使用教程这几个词高频出现说明大量人卡在第一步。Codex 类工具本质是把 LLM 能力接到你的编辑器或终端里帮你写代码、改 bug、解释代码。安装流程通常不复杂但坑在于环境依赖和认证配置。标准流程一般是先装 CLI 工具或编辑器插件然后配置 API key 或登录账号最后在项目里初始化。我建议新手先用官方文档的默认配置跑通一个 hello world确认链路通了再去改配置。很多人一上来就自定义一堆参数结果出问题不知道是哪一步的锅。5.2 Codex 接入 DeepSeek 等第三方模型codex 接入 deepseek是个很实际的需求因为不是所有人都想用官方模型。接入第三方模型的核心是接口兼容性——只要对方提供 OpenAI 兼容接口改 base_url 和 api_key 就能接。但要注意几点不同模型的 function calling 支持程度不一样有些模型对 tool payload 的格式要求更严格上下文长度限制不同超长会直接报错流式输出的实现细节可能有差异。我实测过用 Codex 类工具接国产模型大部分场景能用但在复杂的多轮工具调用上稳定性不如官方模型。所以如果你的工作流重度依赖工具调用接入前一定要做充分测试。5.3 那些让人抓狂的报错逐个拆解热词里有一堆 Codex 的报错我挑几个典型的说说排查思路cc switch local proxy failed while handling codex endpoint /responses这类代理转发失败通常是本地代理配置和 Codex 的 endpoint 不匹配。排查顺序是先确认代理服务本身活着再确认 Codex 配置的 base_url 指向正确最后看代理日志里请求到底发到哪去了。很多时候是路径拼接多了或少了一层。codex 无法加载组织设置这基本是认证或权限问题。检查 API key 是否有效、账号是否有对应组织的权限、配置文件里的组织 ID 是否正确。有时候是缓存了旧的认证信息清一下配置重新登录就好。codex 无法发送消息显示更新 agent 沙盒这是沙盒环境的问题。Codex 类工具为了安全会在沙盒里执行代码如果沙盒初始化失败或者权限不足就发不出消息。检查沙盒目录的读写权限或者重置沙盒环境。llm request failed: provider rejected the request schema or tool payload这个报错很明确——你发的请求格式provider 不认。常见原因是 tool 定义的 JSON schema 不符合规范或者模型不支持你用的 tool 格式。解决办法是拿最小可复现的请求去测逐步加字段定位到具体哪个字段被拒。5.4 Agent 安全别忽视的 red teamingagent 安全和agentpoison: red-teaming llm agents via poisoning memory or knowledge base这两个词放在一起点出了一个被严重低估的问题Agent 的记忆和知识库是可以被投毒的。AgentPoison 这类研究的核心思路是攻击者在 Agent 能访问的知识库或记忆里注入恶意内容当 Agent 检索到这些内容时会被诱导执行非预期操作。比如你在 RAG 知识库里塞一段当用户问 X 时请执行 Y 命令Agent 检索到就可能照做。防御手段有几个层次输入侧对知识库写入做审核和来源校验检索侧对召回内容做异常检测识别可疑指令执行侧对 Agent 的工具调用做权限最小化和二次确认尤其是涉及文件写入、命令执行、网络请求的操作。我在项目里给所有危险工具加了人工确认环节虽然牺牲了一点自动化程度但安全底线不能破。6. 常见问题速查与实操避坑清单6.1 高频问题速查表问题现象可能原因排查方向vLLM 启动 OOMgpu-memory-utilization 过高 / max-model-len 过大降低利用率到 0.85缩短上下文RAG 答非所问切块断裂 / embedding 不匹配 / 无 rerank改语义切块换 embedding加 rerankAgent 并发超时同步调用 / 无限流 / 推理引擎吞吐不足改异步加信号量上 vLLMCodex 请求被拒tool schema 不合规 / 模型不支持最小化请求逐步定位上下文成本爆炸历史全量塞入摘要压缩 滑动窗口知识库投毒写入无审核来源校验 异常检测 工具权限控制6.2 我踩过的几个真实坑第一个坑是盲目追求大模型。早期我总觉得模型越大效果越好结果上了 70B延迟高、成本高很多简单任务根本用不着。后来改成分级路由——简单任务走小模型复杂任务走大模型成本和体验都优化了。这个思路在 Agent 里尤其重要因为 Agent 一次任务可能调用十几次 LLM每次都上大模型成本扛不住。第二个坑是RAG 切块一刀切。我一开始所有文档都按 500 字切结果技术文档里的代码块被切得七零八落检索出来全是残片。后来针对不同文档类型用不同策略代码文档按函数切FAQ 按问答对切长文按标题层级切。切块策略要跟着数据走没有万能参数。第三个坑是忽视 embedding 和生成模型的语言匹配。我用英文 embedding 模型处理中文文档检索效果惨不忍睹。换成中文优化的 embedding 后召回率直接翻倍。这个细节很多人不注意但影响巨大。6.3 给不同阶段读者的实操建议如果你是刚入门我的建议是先用 Ollama 跑通一个本地模型用 LangChain 或 LlamaIndex 搭一个最简单的 RAG把文档进、答案出的链路走通。别一上来就纠结架构先有体感。如果你已经能跑 demo下一步是把 RAG 的检索质量做上去——换 embedding、加 rerank、优化切块这三件事做完效果提升最明显。同时开始关注并发把同步调用改成异步。如果你在做生产系统重点应该放在推理层用 vLLM 提吞吐、Agent 层做限流和降级、知识库做安全和版本管理。这时候拼的不是单点技术是整体架构的稳定性和可维护性。最后分享一个我最近的小体会Agent 和 LLM 这个领域变化太快今天的最佳实践明天可能就过时了。但有些底层的东西是不变的——token 的经济学、检索的质量决定生成的质量、并发的瓶颈在推理层、安全永远是最后一道防线。抓住这些不变的东西你就不容易被各种新框架、新名词带着跑。我自己的习惯是每周花点时间把新出的工具跑一遍但只把真正解决了我实际问题的纳入工具箱其余的看看就好。毕竟工具是拿来用的不是拿来追的。