企业官网建设流程全解析

1. 从一份日报标题里拆出来的技术地图

看到"Agent / LLM 技术精选日报"这个标题，很多人第一反应是"这不就是个资讯聚合吗"。但如果你真在一线做 AI 应用开发，就会明白这类日报背后其实藏着一张非常清晰的技术栈地图：Agent 编排、LLM 推理、RAG 检索、vLLM 部署、Codex 类编码助手，这五块基本覆盖了当下从原型到生产的完整链路。我平时也会整理类似的技术动态，最大的体会是——日报的价值不在于"今天发生了什么"，而在于帮你判断"哪些东西值得我现在动手试"。

这篇内容适合三类人看：一是刚接触 Agent 和 LLM、想搞清楚这些热词到底指什么的新手；二是已经在做 RAG 或 Agent 项目、但在部署和并发上卡住的开发者；三是想搭建自己技术情报体系、不想被碎片信息淹没的工程师。我会围绕标题里出现的核心关键词，把 Agent、LLM、RAG、vLLM、Codex 这几条线拆开讲透，同时把热搜词里那些高频疑问（比如"RAG 知识库能不能存图片""vLLM 怎么部署 DeepSeek""Codex 安装踩坑"）一并揉进去。

先说清楚一个前提：这类日报的"精选"逻辑，通常是按技术成熟度和社区讨论热度两个维度筛的。成熟度高的（比如 vLLM 推理优化）会反复出现，因为它是生产环境的刚需；热度高的（比如各种 Agent 框架）则更新极快，今天火的框架下个月可能就没人提了。理解这个筛选逻辑，你就能明白为什么日报里有些内容看着"老生常谈"，有些又"眼花缭乱"。

我自己的做法是：把日报当成一个信号源而不是知识源。信号源的作用是告诉你"这个方向有人在密集投入"，至于具体怎么用，还得自己动手跑一遍。下面我就按这个思路，把几个核心方向逐个拆解。

2. Agent 到底是什么：从概念到能跑起来的最小闭环

2.1 Agent 和普通 LLM 调用的本质区别

很多人问"agent 是什么"，网上答案一大堆，但最实用的定义是：Agent 是一个能自己决定"下一步做什么"的 LLM 应用。普通 LLM 调用是"你问一句，它答一句"，一问一答就结束了。Agent 不一样，它拿到目标后会自己拆解、自己选工具、自己判断结果够不够好，不够就再来一轮。

举个具体例子。你让普通 LLM"帮我查一下北京明天天气"，它要么直接编一个，要么告诉你"我无法获取实时信息"。但一个配了工具调用的 Agent，会先判断"这需要调天气 API"，然后发起调用，拿到结果后再组织成自然语言回复你。这个"判断—调用—再判断"的循环，就是 Agent 的核心。

热搜词里有个"harness 和 agent 区别"，这个问得很专业。Harness 通常指测试或评估 Agent 的框架，它负责给 Agent 喂任务、记录行为、打分，本身不参与决策；Agent 是真正做决策的那个主体。你可以把 Harness 理解成考场，Agent 是考生。做 Agent 开发时，Harness 决定了你能不能系统性地发现 Agent 的问题，而不是靠手动试几个 case 就以为没问题了。

2.2 一个最小 Agent 闭环需要哪些组件

想跑通一个能用的 Agent，最少需要四样东西：

• 一个能稳定输出结构化结果的 LLM：注意是"结构化"，因为 Agent 要解析 LLM 的输出决定下一步，如果 LLM 一会儿输出 JSON 一会儿输出散文，解析就崩了。
• 一套工具定义：每个工具要有清晰的名称、参数说明、返回值格式。工具描述写得越清楚，LLM 选错的概率越低。
• 一个循环控制器：负责"调用 LLM → 解析动作 → 执行工具 → 把结果塞回上下文 → 再调用 LLM"这个流程，同时要有最大轮数限制，防止死循环。
• 一个终止条件：什么时候算任务完成？是 LLM 输出特定标记，还是达到某个状态？这个必须提前定义清楚。

我踩过的一个坑是：早期做 Agent 时没设最大轮数，结果 LLM 在两个工具之间反复横跳，一次请求烧掉了几万 token。后来加了硬性轮数上限（一般 5 到 10 轮足够），并且每轮都检查"这一步和上一步是不是在做重复的事"，才把成本控制住。

2.3 Agent 并发扛不住的真实原因

"ai agent 怎么扛并发"是热搜里的高频问题。很多人以为是 LLM 接口慢导致的，其实真正的瓶颈往往在三个地方：

第一是上下文长度爆炸。Agent 每轮都要把历史对话和工具结果塞进上下文，轮数一多，单次请求的 token 量就上去了，推理时间线性增长。第二是工具调用的串行等待。如果 Agent 需要调三个外部 API，默认是串行的，每个等 500ms，加起来就是 1.5 秒。第三是状态管理。多用户并发时，每个用户的 Agent 会话状态要隔离，如果用全局变量存状态，直接就串了。

我的处理经验是：上下文做滑动窗口 + 摘要压缩，超过一定轮数就把早期对话总结成一段话；工具调用能并行的就并行（比如查天气和查日历互不依赖，可以同时发）；状态一律用请求级别的对象存，绝不共享。这三招下来，单机扛几十个并发 Agent 会话是没问题的。

3. RAG 的深水区：从"能检索"到"检索得准"

3.1 RAG 知识库到底能不能存图片

"rag 知识库能存储图片嘛"这个问题，答案要分两层说。原始图片本身当然可以存，但关键在于检索时怎么用。纯文本 RAG 的流程是"文本切块 → 向量化 → 检索 → 塞进 LLM 上下文"，图片没法直接向量化进这个流程。

实际可行的方案有三种。第一种是图片转文字描述，用多模态模型给每张图生成一段描述，把描述存进向量库，检索到描述后再把原图一起返回。第二种是图文混合索引，用支持多模态的嵌入模型（比如 CLIP 类）把图片和文本映射到同一向量空间，这样文字查询也能召回相关图片。第三种是图片只做展示，检索还是靠文本，图片作为文本块的附属资源，命中文本时顺带把图带出来。

我做过一个产品手册的 RAG 项目，最后选的是第一种方案。原因是手册里的图大多是流程图和界面截图，用多模态模型生成的描述质量足够高，而且实现简单、成本可控。纯多模态索引虽然理论上更优雅，但调试起来很痛苦，召回效果不稳定。

3.2 RAG、KG 知识库、结构化知识库的边界

热搜里"kg 知识库、rag 知识库和结构知识库区分以及应用场景"这个问题，值得单独讲。三者的核心差异在于知识的组织方式：

RAG 的瓶颈恰恰在于多跳推理。比如问"张三的导师所在学校的校长是谁"，RAG 检索到的可能是三段互不相关的文本，LLM 很难把它们串起来。这时候 KG 就有优势了，因为"张三—导师—李四—任职—某校—校长—王五"这条路径是显式存储的，查询就是走图。

但 KG 的问题是构建和维护成本极高，尤其是实体对齐和关系抽取，做过的都知道有多痛。所以现在比较务实的做法是RAG 为主、KG 为辅：常规问答走 RAG，遇到需要关系推理的问题再查 KG。热搜里提到的"ontology rag"就是这个思路的延伸，用本体来约束 RAG 的检索范围，减少无关召回。

3.3 RAG 检索不准的排查顺序

RAG 效果不好，很多人第一反应是换嵌入模型，其实应该按这个顺序排查：

1. 先看切块。切块太大，一个块里混了好几个主题，检索出来噪声大；切块太小，上下文不完整，LLM 答不全。我一般先用固定长度加重叠（比如 500 字块、50 字重叠）跑一版，再看效果调。
2. 再看检索数量。top-k 设太小可能漏掉关键信息，设太大又引入噪声。一般从 k=3 开始试，逐步加到 5 或 8，观察效果拐点。
3. 然后看重排。加一个重排模型（rerank）通常能明显提升精度，因为它是在向量召回的基础上做精细排序。
4. 最后才考虑换嵌入模型。嵌入模型的影响其实没有想象中那么大，除非你的领域非常特殊。

这个顺序能帮你省下大量试错时间。我见过太多人一上来就折腾嵌入模型，结果发现真正的问题是切块策略不对。

4. vLLM 部署实战：从装不上到跑得稳

4.1 vLLM 为什么成为推理部署的默认选项

"vllm 推理""vllm 部署大模型"这些词频繁出现，是因为 vLLM 解决了 LLM 推理里最核心的两个问题：显存利用率和吞吐量。它最出名的技术是 PagedAttention，简单说就是把 KV Cache 像操作系统管理内存页一样分块管理，避免了传统实现里大量显存碎片浪费。

打个比方：传统推理像是给每个请求分配一整块连续停车位，车走了位置还占着；vLLM 像是智能停车场，车走了位置立刻回收给下一辆。这个差异在高并发下非常明显，吞吐量能差好几倍。

所以如果你要自部署模型对外提供服务，vLLM 基本是首选。热搜里"lm studio、ollama、vllm/sglang"这几个放一起对比，其实定位不同：LM Studio 和 Ollama 适合本地个人用，开箱即用但并发能力弱；vLLM 和 SGLang 是面向服务的，适合部署给多人用。

4.2 vLLM 部署 DeepSeek 的完整流程

"vllm 部署 deepseek"是高频需求，我把关键步骤和坑点列一下。假设你有一台带 GPU 的机器：

# 1. 创建独立环境，避免依赖冲突 conda create -n vllm python=3.10 -y conda activate vllm # 2. 安装 vLLM，注意 CUDA 版本要匹配 pip install vllm # 3. 启动服务，指定模型和显存利用率 python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/DeepSeek-V2-Lite \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192

几个关键参数解释一下。--tensor-parallel-size是张量并行数，单卡就填 1，多卡填卡数。--gpu-memory-utilization控制 vLLM 能用多少显存，默认 0.9，如果机器上还跑着别的任务就调低。--max-model-len是最大上下文长度，设太大显存吃紧，设太小长文本会报错，要根据模型能力和显存权衡。

启动后 vLLM 会暴露一个兼容 OpenAI 接口的服务，你的应用代码只要把 base_url 指过去就能用，不用改调用逻辑。这是它特别方便的一点。

4.3 CUDA 版本和 Windows 支持的坑

"cuda128 vllm"和"vllm windows 社区版"这两个词说明很多人卡在环境上。vLLM 对 CUDA 版本有要求，装之前一定要先nvcc --version和nvidia-smi看一下驱动和 CUDA 版本，然后对照 vLLM 官方文档选对应的安装方式。版本不匹配的典型症状是装上了但一启动就报 CUDA 相关的错。

Windows 原生支持一直是 vLLM 的弱项，官方主要面向 Linux。Windows 用户有两条路：一是用 WSL2，这是最省心的方案，基本能复现 Linux 下的体验；二是用社区维护的 Windows 版本，但要注意版本可能滞后，新模型支持不及时。我个人的建议是，如果只是本地测试，用 Ollama 更省事；如果要正经部署，直接上 Linux 服务器，别在 Windows 上折腾。

提示：vLLM 启动时如果报显存不足，先别急着换卡，试试调低--gpu-memory-utilization和--max-model-len，很多时候是这两个参数设太大了。

5. Codex 类编码助手：安装、接入与常见故障

5.1 Codex 安装和接入 DeepSeek 的思路

"codex 安装""codex 接入 deepseek"这类需求，本质是想把编码助手接到自己的模型上。Codex 类工具的核心能力是代码补全和对话式编程，它需要一个 LLM 后端。默认后端通常是官方服务，但很多人想换成自己的模型，原因无非是成本、隐私或网络。

接入自定义模型的通用思路是：找到工具的配置入口（通常是配置文件或环境变量），把 API 地址和密钥指向你的服务。如果你用 vLLM 部署了 DeepSeek，它暴露的就是 OpenAI 兼容接口，直接填进去就行。关键是要确认工具支持的接口格式，有些工具只认特定的请求结构，这时候可能需要一个中间层做协议转换。

5.2 "provider rejected the request schema"报错怎么查

热搜里"llm request failed: provider rejected the request schema or tool payload"这个报错很典型。它的意思是你发出去的请求结构，服务端不认。常见原因有三个：

第一是字段名不对。不同服务对同一个概念可能用不同字段名，比如有的叫max_tokens，有的叫max_completion_tokens。第二是工具定义格式不匹配。Agent 场景下工具调用的 schema 各家有差异，服务端可能要求特定结构。第三是多传了服务端不认识的字段，有些严格的服务会直接拒绝而不是忽略。

排查方法很直接：把请求体打印出来，对照服务端的 API 文档逐字段核对。我一般会先用 curl 发一个最小请求，确认基础调用通了，再逐步加上工具定义等复杂字段，这样能快速定位是哪个字段出的问题。

5.3 "cc switch local proxy failed"这类本地代理故障

"cc switch local proxy failed while handling codex endpoint"这个报错，通常出现在用本地代理转发请求的场景。故障点一般在这几处：代理进程没起来、端口被占用、代理配置的上游地址写错、或者代理和目标服务的协议不匹配。

排查顺序建议是：先确认代理进程在跑（ps或任务管理器看一眼），再确认端口监听正常（netstat查一下），然后用 curl 直接打代理端口看返回什么。如果代理本身通了但转发失败，那就是上游配置的问题。这类问题看着吓人，其实按"进程—端口—配置—协议"四步走，基本都能定位。

6. 把日报变成自己的技术雷达

6.1 我筛选技术动态的三条标准

天天看日报容易被信息淹没，我自己的筛选标准是三条：能不能解决我当前的问题、社区有没有可复现的案例、学习成本是否可控。一条动态如果三条都满足，我当天就会动手试；满足两条的记下来，等有空再看；只满足一条的直接跳过。

拿这次的热词举例，"agent 安全""agentpoison"这类属于重要但不紧急，我会记下来关注；"vllm 部署 deepseek"属于能直接解决部署问题且有大量案例，我会立刻试；"spatial llm"这种偏前沿的，先了解概念即可，不急着上手。

6.2 从热词反推技术成熟度

热词本身也能反映技术阶段。像"llm 是什么""agent 是什么"这种基础概念词频繁出现，说明新入场的人还很多，这个领域还在快速扩张期。而"vllm 推理""rag 实战"这种偏实操的词多，说明已经有一批人在做生产落地了，讨论从"是什么"转向了"怎么做好"。

再比如"agentpoison: red-teaming llm agents via poisoning memory"这种安全方向的词出现，说明 Agent 已经从"能跑就行"进入"要考虑被攻击怎么办"的阶段。这个信号对做企业级应用的人特别重要，因为安全合规往往是落地的最后一道门槛。

6.3 建立个人实验清单的习惯

我强烈建议每个做 AI 应用的人都维护一个实验清单：看到值得试的技术，不要只收藏，而是写清楚"要验证什么""预期结果是什么""大概花多久"。比如看到 vLLM 支持新模型，清单上就写"验证 DeepSeek 在 vLLM 上的吞吐，对比 Ollama，预计 2 小时"。

这样做的好处是，你不会被日报的节奏带着跑，而是按自己的项目需求有选择地深入。技术更新再快，你的精力是有限的，把有限的精力投在能直接产生价值的方向上，才是看日报的正确姿势。

最后分享一个我自己的小习惯：每次动手试完一个新技术，不管成功失败，都写三句话总结——它解决了什么问题、我踩了什么坑、下次还会不会用。积累下来，这份笔记比任何日报都值钱，因为它是你自己的、经过验证的技术判断。