企业官网建设流程全解析

1. 从一份日报标题说起：Agent 与 LLM 技术圈到底在关注什么

看到“Agent / LLM 技术精选日报”这个标题，很多人第一反应是“又是一个资讯聚合”。但如果你真的在一线做 Agent 和 LLM 应用开发，就会明白这类日报背后其实藏着一张技术雷达图——它反映的是当下开发者社区最真实的痛点和最活跃的探索方向。我从 2023 年开始跟进大模型应用落地，从最早的 Prompt 工程到后来的 RAG 系统搭建，再到如今多 Agent 协作框架的选型，踩过的坑比读过的论文还多。这份日报里出现的每一个热搜词，几乎都能对应到我或身边同行实际项目中遇到的具体问题。

这份内容的核心价值在于：它把散落在知乎、GitHub、技术社区里的碎片信息，按照 Agent 开发、LLM 推理部署、RAG 知识库、Codex 工具链等几个主线做了归类。适合谁看？如果你是刚接触 Agent 开发的新手，它能帮你快速建立技术全景图；如果你已经在做 LLM 应用但卡在某个环节，比如 vLLM 部署显存不够、RAG 检索召回率上不去、Codex 接入本地模型报错，那这份日报里的关键词就是你的排查线索。我下面会把这些热词背后的技术逻辑、实操方案和避坑经验逐一拆开讲，尽量做到你看完就能动手试。

2. Agent 开发的核心命题：从概念到扛并发

2.1 Agent 到底是什么，和普通 LLM 调用有什么区别

很多人第一次听到“Agent”这个词，会觉得玄乎。我用一个生活化的类比来解释：普通 LLM 调用就像你问一个博学的朋友一个问题，他直接给你答案；而 Agent 更像你雇了一个助理，你告诉他目标，他会自己拆解任务、调用工具、查资料、写草稿、自我检查，最后把结果交给你。关键区别在于Agent 有自主决策和工具调用的能力，它不只是“生成文本”，而是“完成任务”。

从技术架构上看，一个典型的 Agent 包含几个核心模块：规划模块（把大目标拆成子任务）、记忆模块（短期对话上下文和长期知识存储）、工具调用模块（搜索、代码执行、API 调用等）、执行循环（观察结果、调整策略、继续执行）。热搜词里出现的“agent框架”“ai agent”“agent项目”“吴恩达 agent 教程”都指向同一个需求：大家想知道怎么把这些模块组装起来，而不是停留在概念层面。

我实测下来，目前主流的 Agent 框架大致分两类。一类是代码优先型，比如 LangChain、LangGraph，灵活度高但学习曲线陡；另一类是配置优先型，比如 Coze、Dify 这类平台，上手快但深度定制受限。选哪个取决于你的场景：如果是做企业内部工具、需要精细控制每一步逻辑，建议代码优先；如果是快速验证想法、做 MVP，配置优先更省时间。

2.2 Agent 怎么扛并发：这是生产环境的生死线

热搜词里有一条特别扎眼：“ai agent 怎么扛并发”。这个问题问到了点子上。Demo 阶段你调一次 API 等几秒没关系，但生产环境可能同时有几百上千个用户请求，每个请求背后是一个多轮 Agent 循环，每轮又要调用 LLM 和工具，这时候并发问题就会集中爆发。

我踩过的坑是这样的：早期用同步方式写 Agent，一个请求走完规划、检索、生成、校验四个步骤，串行执行下来平均 8 到 12 秒。并发量一上来，线程池直接打满，后面的请求全部排队超时。后来改成异步 + 队列的方案，核心思路是把 Agent 的每个步骤拆成独立任务，用消息队列解耦，LLM 调用走异步接口。具体来说：

• 接入层用 FastAPI 或类似框架做异步路由，每个请求生成一个 task_id，立即返回“处理中”状态。
• 任务队列用 Redis 或 RabbitMQ 做缓冲，Agent 的每个步骤作为一个独立消息投递。
• LLM 调用层用 vLLM 或类似推理引擎做批量推理，配合连续批处理（continuous batching）提升吞吐。
• 状态管理用 Redis 存 Agent 的中间状态，支持断点续跑和超时重试。

这里有个关键参数需要算清楚：假设你的 LLM 单次推理延迟是 2 秒，Agent 平均需要 5 轮循环，那么单个请求的纯 LLM 耗时就是 10 秒。如果并发是 100，理论上需要 1000 秒的 GPU 时间。但通过连续批处理，vLLM 可以把多个请求合并成一个 batch 一起推理，实际吞吐能提升 5 到 10 倍。所以并发能力不只取决于你的代码，更取决于推理引擎的批处理效率。

注意：Agent 扛并发时，最大的隐藏杀手是“工具调用”环节。很多外部 API 有速率限制，你的 Agent 并发一高，工具调用先被限流。建议在工具层加令牌桶限流和缓存，对相同参数的调用直接返回缓存结果。

2.3 Harness 和 Agent 的区别：一个容易被混淆的概念

热搜词里有个“harness和agent区别”，这个问题其实很专业。Harness 在软件工程里通常指“测试脚手架”或“运行框架”，在 LLM 语境下，它指的是围绕模型构建的评测和约束层。Agent 是“会做事的智能体”，Harness 是“确保 Agent 做事不出格的护栏”。

举个例子：你让 Agent 去订机票，Agent 可能会调用支付接口。Harness 的作用就是在支付前检查金额是否超限、收款方是否在白名单、操作是否可回滚。没有 Harness 的 Agent 就像没有刹车的车，跑得越快越危险。实际项目中，我建议把 Harness 做成独立的中间件层，所有工具调用都经过它，这样安全策略和业务逻辑解耦，维护起来清爽很多。

3. LLM 推理部署实战：vLLM 为什么成为首选

3.1 vLLM 是什么，它解决了什么核心问题

热搜词里 vLLM 出现的频率极高：“vllm部署deepseek”“vllm部署大模型”“vllm推理”“vllm是什么”“glm5.3 使用vllm哪个版本的镜像”。这说明大量开发者正在从“调 API”转向“自己部署模型”。原因很简单：数据隐私、成本控制、定制化需求，这三条里任意一条都足以让你考虑本地部署。

vLLM 的核心竞争力在于PagedAttention 和连续批处理。我用一个类比解释 PagedAttention：传统推理引擎处理长文本时，KV Cache 需要连续内存空间，就像你停车必须找一整块连续车位，浪费严重。PagedAttention 把 KV Cache 切成固定大小的块，像虚拟内存分页一样按需分配，显存利用率能提升 2 到 4 倍。连续批处理则是让不同请求的动态长度序列在同一个 batch 里并行推理，GPU 利用率大幅提升。

实测数据：同样一张 A100 80G，用 HuggingFace Transformers 原生推理，吞吐大约是每秒 8 到 12 个 token；换成 vLLM 后，吞吐能到每秒 80 到 120 个 token，差距接近 10 倍。这就是为什么 vLLM 几乎成了自部署 LLM 的默认选择。

3.2 vLLM 部署 DeepSeek 和 Qwen 的完整流程

以部署 DeepSeek 系列模型为例，我梳理一遍可复现的步骤。假设你有一台 8 卡 A100 80G 的机器，目标是部署一个 70B 级别的模型。

第一步：环境准备。推荐用 Docker 方式，避免 CUDA 版本和 Python 依赖的冲突。热搜词里提到的docker vllm/vllm-openai:v0.27.1就是一个典型的官方镜像标签。拉取镜像：

docker pull vllm/vllm-openai:v0.27.1

第二步：模型下载。可以用 huggingface-cli 或者 modelscope 下载到本地目录。建议提前下载好，不要用容器内在线拉取，否则启动时间会很长。

huggingface-cli download deepseek-ai/DeepSeek-V2 --local-dir /data/models/deepseek-v2

第三步：启动服务。关键参数包括--tensor-parallel-size（张量并行数，一般等于 GPU 数量）、--gpu-memory-utilization（显存利用率，建议 0.9）、--max-model-len（最大上下文长度）。

docker run --gpus all \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:v0.27.1 \ --model /models/deepseek-v2 \ --tensor-parallel-size 8 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192

第四步：验证服务。用 curl 测试 OpenAI 兼容接口：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "/models/deepseek-v2", "messages": [{"role": "user", "content": "你好"}]}'

这里有个经验：--max-model-len不要一上来就设成模型支持的最大值。比如模型支持 128K 上下文，但你实际业务只需要 8K，那就设 8K。因为 KV Cache 的显存占用和上下文长度成正比，设太大直接导致显存不够启动失败。我见过太多人卡在这一步，报错CUDA out of memory，其实就是这个参数没调好。

3.3 加载 Qwen3-Embedding 的注意事项

热搜词里有一条很具体：“docker vllm/vllm-openai:v0.27.1加载qwen3-embedding-0.6b”。Embedding 模型和生成模型的部署方式略有不同。Qwen3-Embedding 是向量化模型，用于 RAG 的检索环节。用 vLLM 加载时需要注意：

• Embedding 模型不需要--max-model-len设太大，通常 512 到 2048 足够。
• 要确认 vLLM 版本支持该模型的架构，太老的版本可能不识别。
• 启动后调用的是/v1/embeddings接口，不是/v1/chat/completions。

curl http://localhost:8000/v1/embeddings \ -H "Content-Type: application/json" \ -d '{"model": "/models/qwen3-embedding-0.6b", "input": "测试文本"}'

提示：Embedding 模型和生成模型建议分开部署，不要挤在同一组 GPU 上。因为 Embedding 请求通常短而频繁，生成请求长而稀疏，混在一起会导致批处理效率下降。

3.4 推理引擎选型：LM Studio、Ollama、vLLM、SGLang 怎么选

热搜词里出现了“lm studio 、 ollama、vllm/sglang”的对比。这四个工具定位完全不同，我做一个清晰的对照：

我的建议很直接：个人玩模型用 Ollama 或 LM Studio，生产环境用 vLLM 或 SGLang。Ollama 的优势是安装即用，一条命令跑起来，但它的批处理能力有限，并发一高就顶不住。vLLM 的配置复杂一些，但吞吐和稳定性是另一个量级。SGLang 在结构化输出和 RadixAttention 方面有优势，如果你的 Agent 需要大量 JSON 格式输出，可以重点考虑。

4. RAG 知识库：从入门到 Agentic RAG

4.1 RAG 的核心原理：用三个点解释清楚

热搜词里有一条特别有意思：“llm的token三个点key我是谁、query我在找什么、value我能提供什么”。这其实是在用 Attention 机制的 QKV 来类比 RAG 的检索逻辑。我展开说一下：

RAG 的全称是 Retrieval-Augmented Generation，检索增强生成。它的核心流程是：用户提问 → 把问题向量化 → 在知识库中检索最相关的文档片段 → 把文档片段和问题一起塞给 LLM → LLM 基于文档内容生成答案。

用 QKV 类比：Key 是知识库中每个文档片段的“身份标识”（我是谁），Query 是用户问题的“需求描述”（我在找什么），Value 是文档片段的“实际内容”（我能提供什么）。检索的过程就是计算 Query 和所有 Key 的相似度，取出相似度最高的几个 Value。

这个类比之所以流行，是因为它帮初学者理解了 RAG 的本质：它不是让模型变聪明，而是给模型提供它不知道的信息。模型本身的知识是冻结的，RAG 相当于开卷考试，允许模型翻书。

4.2 RAG 知识库能存储图片吗：多模态检索的现实方案

热搜词里有个很实际的问题：“rag知识库能存储图片嘛”。答案是能，但方案和纯文本 RAG 不同。纯文本 RAG 的流程是“文本 → 向量 → 检索”，图片需要先转成可检索的形式。目前主流方案有三种：

方案一：图片转文本描述。用多模态模型（如 GPT-4V、Qwen-VL）给每张图片生成一段文字描述，然后把描述文本存入向量库。检索时匹配的是描述文本，返回的是原图链接。优点是实现简单，缺点是描述可能丢失细节。

方案二：图文联合嵌入。用 CLIP 这类模型把图片和文本映射到同一个向量空间，支持“以文搜图”和“以图搜图”。优点是检索更灵活，缺点是对中文支持参差不齐，且需要额外的模型部署。

方案三：多模态向量库。一些新一代向量数据库开始原生支持图片存储和检索，比如把图片的视觉特征和文本特征分别索引，检索时做混合排序。这是最完整的方案，但工程复杂度最高。

我实际项目中用的是方案一加方案二的混合：先用多模态模型生成图片描述，同时用 CLIP 提取视觉特征，检索时两路召回再做融合排序。实测下来，对于产品手册、技术文档这类场景，召回准确率比纯文本方案提升明显。

4.3 Agentic RAG：让检索本身变成智能体

热搜词里“agentic rag”和“rag瓶颈”放在一起，指向了 RAG 当前最大的痛点：传统 RAG 是“一次检索，一次生成”，但复杂问题往往需要多轮检索和推理。

举个例子：用户问“我们公司去年在华东区的销售额是多少，和前年相比增长了多少”。传统 RAG 可能只检索到一段包含销售额的文档，但无法完成“对比”和“计算”。Agentic RAG 的做法是：Agent 先拆解问题，识别出需要“2025 年华东区销售额”和“2024 年华东区销售额”两个数据点，分别检索，然后调用计算工具做对比，最后生成答案。

实现 Agentic RAG 的关键是把检索工具化。也就是说，检索不再是固定流程，而是 Agent 可以调用的一个工具。Agent 决定什么时候检索、检索什么、检索几次。这需要你的 Agent 框架支持工具调用循环，并且检索工具要返回结构化的结果（比如带来源、带置信度），方便 Agent 判断是否需要二次检索。

注意：Agentic RAG 的 token 消耗会显著高于传统 RAG，因为多轮检索和多轮生成都会增加上下文长度。建议在检索工具里加一个“结果充分性判断”，如果第一次检索的置信度已经很高，就直接生成，不要无谓地多轮循环。

4.4 零基础可复制的本地 RAG 知识库搭建教程

热搜词里有一条“ollama + 简易本地 rag 知识库【零基础可复制教程】”，我顺着这个思路给一个完整可复现的方案。这套方案不需要 GPU 集群，一台带 16G 以上显存的机器就能跑。

第一步：部署 Ollama 和嵌入模型。

# 安装 Ollama 后拉取模型 ollama pull qwen2.5:7b ollama pull nomic-embed-text

第二步：准备知识库文档。把 PDF、Markdown、TXT 等文档放到一个目录下。用 Python 做文档加载和切分：

from langchain_community.document_loaders import DirectoryLoader from langchain.text_splitter import RecursiveCharacterTextSplitter loader = DirectoryLoader('./docs', glob='**/*.md') docs = loader.load() splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) chunks = splitter.split_documents(docs)

第三步：向量化并存入向量库。用 Chroma 做本地向量库：

from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma embeddings = OllamaEmbeddings(model='nomic-embed-text') vectorstore = Chroma.from_documents(chunks, embeddings, persist_directory='./chroma_db')

第四步：构建检索问答链。

from langchain_community.llms import Ollama from langchain.chains import RetrievalQA llm = Ollama(model='qwen2.5:7b') qa = RetrievalQA.from_chain_type(llm=llm, retriever=vectorstore.as_retriever(search_kwargs={'k': 3})) print(qa.invoke('你的问题'))

这套方案的关键参数是chunk_size和k。chunk_size太小会导致上下文碎片化，太大则检索精度下降，500 到 800 是比较稳妥的范围。k是返回的文档片段数量，3 到 5 比较合适，太多会挤占 LLM 的上下文窗口。

5. Codex 工具链：安装、接入与常见报错

5.1 Codex 安装教程与使用场景

热搜词里“codex安装”“codex安装教程”“codex安装包”“codex使用教程”“codex下载”密集出现，说明这个工具正处于用户快速增长期。Codex 本质是一个 AI 编程助手，可以理解代码上下文、生成代码片段、解释报错、重构函数。它的核心价值在于把 LLM 的代码能力封装成开发者日常工具，而不是让你在聊天窗口和 IDE 之间来回切换。

安装方式通常有两种：一种是 IDE 插件形式，直接在 VS Code 或 JetBrains 系列里搜索安装；另一种是命令行工具，通过包管理器安装。我建议优先用 IDE 插件，因为代码补全和上下文感知的体验更流畅。安装完成后，需要在设置里配置模型端点，可以接官方服务，也可以接本地部署的模型。

5.2 Codex 接入 DeepSeek 的配置方法

热搜词里“codex接入deepseek”是一个高频需求。原因很简单：DeepSeek 的代码能力在开源模型里属于第一梯队，而且本地部署成本可控。接入的核心是配置 API 端点。假设你用 vLLM 部署了 DeepSeek 的代码模型，服务地址是http://localhost:8000/v1，那么在 Codex 的配置文件中这样写：

{ "model": "deepseek-coder", "api_base": "http://localhost:8000/v1", "api_key": "your-key-if-needed", "max_tokens": 2048, "temperature": 0.2 }

这里temperature建议设低一些，0.1 到 0.3 之间，因为代码生成需要确定性，太高的温度会导致生成的代码风格飘忽、变量命名不一致。max_tokens根据你的模型上下文窗口来定，不要超过模型支持的最大输出长度。

5.3 常见报错排查：local proxy failed 与 endpoint /responses 问题

热搜词里有一条具体的报错：“cc switch local proxy failed while handling codex endpoint /responses. provi”。这个报错通常出现在代理转发环节。排查思路如下：

第一，检查端点路径是否正确。Codex 默认可能请求/responses路径，但你的本地服务可能只暴露了/v1/chat/completions。需要在配置里显式指定完整的 API 路径，或者在你的服务端加一个路由转发。

第二，检查代理配置。如果用了本地代理工具做请求转发，确认代理规则没有把/responses路径拦截或重写。我遇到过代理工具把 POST 请求转成 GET 的情况，导致服务端返回 405。

第三，检查模型名称匹配。有些客户端会校验返回的模型名称是否和请求的一致，如果不一致会报错。在 vLLM 启动时用--served-model-name参数指定一个固定的模型名，避免客户端困惑。

第四，看日志。这类报错的关键信息通常在服务端的访问日志和客户端的调试日志里。把两边的日志时间对齐，看请求到底有没有到达服务端，到达后返回了什么状态码。

提示：遇到代理类报错，最快的排查方法是绕过代理直连。如果直连正常，问题就在代理层；如果直连也报错，问题在服务端或客户端配置。

6. 技术选型与避坑经验汇总

6.1 LLM 框架选型：LangChain、LangChain4j 与其他

热搜词里“llm框架”“langchain4j easy rag”反映了框架选型的纠结。我的经验是：Python 生态选 LangChain 或 LlamaIndex，Java 生态选 LangChain4j。LangChain 的优势是组件丰富、社区活跃，几乎你能想到的 LLM 相关操作都有现成封装。缺点是抽象层太多，出问题时排查链路长。

LangChain4j 是 Java 开发者的福音，API 设计比 LangChain 更简洁，适合企业级 Java 项目集成。热搜词里的“easy rag”应该是指它提供的简化 RAG 构建方式，确实比手写向量检索要省事很多。

选框架的核心原则是：如果你的团队以 Python 为主，不要为了“性能”强行上 Java 框架；如果团队是 Java 背景，也不要为了“生态”硬啃 Python。框架是工具，团队的生产力才是第一位的。

6.2 LLM as Judge：用模型评估模型的实际操作

“llm as judge”这个热词指的是用 LLM 来评估另一个 LLM 的输出质量。这在 Agent 开发中非常实用，因为 Agent 的输出往往是开放式的，传统指标（如 BLEU、ROUGE）根本没法用。

实操方法是：设计一套评分标准（比如准确性、完整性、格式规范性各占多少分），把用户问题、模型输出、参考答案（如果有）一起塞给 Judge 模型，让它输出评分和理由。关键技巧是给 Judge 模型提供评分示例，也就是 few-shot，这样评分一致性会高很多。

我实测下来，Judge 模型和被评估模型最好不要用同一个，否则会有“自我偏好”偏差。比如用 Qwen 评估 DeepSeek 的输出，比用 DeepSeek 评估自己更客观。

6.3 避坑清单：那些文档里不会写但实际会遇到的坑

最后整理一份速查表，都是我在实际项目中踩过的坑：

这些坑的共同特点是：文档里通常只讲“怎么用”，不讲“怎么坏”。但生产环境和 Demo 环境的差距，恰恰就在这些“坏”的环节上。我的建议是，每引入一个新组件，先花半小时做压力测试和异常测试，比上线后半夜被报警叫醒要划算得多。

6.4 关于榜单和评测：Open LLM Leaderboard 的正确用法

热搜词里出现了“open llm leaderboard 等公开榜单”。这些榜单有价值，但不能迷信。榜单测的是通用能力，你的业务场景是特定能力。一个在榜单上排名靠前的模型，可能在你的垂直领域表现平平。

我的做法是：榜单用来缩小候选范围，最终选型必须用自己的业务数据做 A/B 测试。具体来说，从榜单上挑 3 到 5 个候选模型，用你真实的 100 到 200 条业务问题做评测，看准确率、延迟、成本三个维度的综合表现。这个过程花不了太多时间，但能避免“选了一个榜单高分但业务拉胯的模型”这种尴尬。

榜单的另一个用途是跟踪技术趋势。比如你发现某个新模型在代码任务上突然冲进前三，那可能意味着代码生成领域有新的技术突破，值得关注。但关注归关注，上生产还是要走自己的评测流程。

7. 一些个人体会

做 Agent 和 LLM 应用这两年多，我最大的感受是：这个领域变化太快，但底层逻辑变化很慢。新模型、新框架、新工具层出不穷，但核心问题始终是那几个：怎么让模型理解你的业务、怎么控制成本和延迟、怎么保证输出稳定可靠。把这三个问题想清楚，具体用什么工具反而是次要的。

另外，不要被“日报”和“热词”牵着走。热词反映的是社区关注度，不一定是你项目的优先级。你的项目卡在哪，你的优先级就在哪。看到一个新工具，先问自己：它解决的是我现在的问题吗？如果不是，收藏一下，等需要的时候再翻出来。技术人的时间很宝贵，别让信息焦虑消耗了真正用来写代码的精力。