146 篇文章带有标签 “llm”

下面是 CLAUDE.md 文件的内容，用于改善 Claude Code 的行为，源自 Andrej Karpathy 的观察 关于 LLM 编码陷阱的总结。

CLAUDE.md

旨在减少大语言模型常见编码错误的行为准则。可根据项目特定说明按需合并。

权衡： 本准则偏向谨慎而非速度。对于琐碎任务，请自行判断。

1. 编码前先思考

不要假设。不要掩饰困惑。要呈现权衡。

实施之前：

• 明确陈述你的假设。如果不确定，就提问。
• 若存在多种解读，请呈现出来——不要默默选择一种。
• 若有更简单的做法，请说出来。在必要时坚持己见。
• 若某事不清楚，就停下来。指出困惑所在。提问。

2. 简单至上

用最少的代码解决问题。不添加任何推测性内容。

• 不添加需求以外的功能。
• 不为一次性代码创建抽象。
• 不提供未要求的“灵活性”或“可配置性”。
• 不对不可能发生的场景进行错误处理。
• 如果你写了 200 行，而本可以 50 行完成，那就重写。

问问自己：“一位资深工程师会认为这过于复杂吗？” 如果会，就简化它。

3. 外科手术式的修改

只碰你必须改的。只清理你自己弄乱的。

编辑现有代码时：

• 不要“改进”相邻的代码、注释或格式。
• 不要重构没有坏的东西。
• 即使你有不同做法，也要遵循现有风格。
• 若注意到无关的无效代码，提出来——但不要删除。

当你的修改造成孤立代码时： 删除由你的修改导致的未使用的导入/变量/函数。

一、技术方案

1.1 总体架构

采用 “公众号前端 + 智能客服中台 + 知识库底座” 三层架构：

层级	功能	技术选型建议
接入层	公众号对话入口，支持文字、图片、视频等多模态输入	微信公众号开发接口
智能客服中台	意图识别、知识检索、问答生成、智能路由（AI/人工分流）	RAG架构 + 大模型API（通义千问/Qwen、文心一言等）
知识库底座	产品手册、FAQ、历史工单、维修案例的结构化存储与向量检索	向量数据库 + 结构化知识库

1.2 核心功能模块

1. 智能问答：基于RAG（检索增强生成）架构，系统从知识库中检索相关文档，再由大模型生成精准答案。方案匹配准确率可达92%以上。

2. 多模态故障识别：支持客户上传故障图片/视频，利用多模态大模型进行图像识别与故障推理，自动推送处理建议。

3. 智能路由与转人工：AI首轮处理常规问题，疑难问题自动转接人工客服，实现“AI首轮服务＋人工兜底”的协同模式。

4. 知识自进化：系统在问答过程中持续学习，客户采纳的答案自动整理为问答对，不断优化知识库。

1.3 实施路径（建议分三期）

在大语言模型（LLM）的生产落地中，自回归生成的 $O(N)$ 延迟始终是制约用户体验与系统吞吐的瓶颈。投机采样（Speculative Decoding）通过引入轻量级的“草稿模型（Draft Model）”先行生成候选 Token，再由大模型（Verification Model）进行并行校验，成为了当前最主流的加速方案。

本文将针对当前业界前沿的三种草稿模型方案——DFlash（纯并行）、DSpark（半自回归） 与 Eagle3（纯自回归） 进行深度架构剖析、技术指标对比及选型建议。

一、 核心架构与生成机制对比

三种方案的本质区别在于“生成速度（并行度）”与“草稿质量（接受率）”的权衡。以下图表直观展示了它们在计算模式上的根本差异：

本文基于 DeepSpec 开源代码，以 Qwen3-4B + DSpark 为具体实例，从算法思想、模型架构、训练数据流、推理流程四个维度，逐行拆解代码，帮助你完整理解 DSpark 草稿模型的训练与推理工作原理。

DeepSpec 核心工作原理

DeepSpec 训练草稿模型的本质是：在目标模型的 backbone 架构上，构建一个更小的 draft 网络，使用目标模型预计算的 hidden states 作为监督信号进行训练。

因此，适配新模型的核心工作量是让 draft 模型能够"理解"目标模型的内部表示——这包括：

• 复用目标模型的 tokenizer、embedding、归一化层、旋转位置编码等组件
• 从目标模型的特定层抽取 hidden states 作为 draft 模型的输入
• 保持注意力机制、MLP 结构与目标模型一致

一、DSpark 是什么：核心思想

DSpark 是一种面向推测解码（Speculative Decoding）的草稿模型训练方法。它的核心洞察可以总结为一句话：

"让草稿模型在训练时就学会——给定目标模型某几层的 hidden states，一次性猜出接下来的 N 个 token 是什么。"

传统训练语言模型是自回归的：输入 t0, t1, t2，预测 t3。

• DSpark 论文

北京大学　DeepSeek-AI

摘要

推测解码（Speculative Decoding）通过将草稿生成与目标验证解耦来加速大语言模型（LLM）推理。尽管最近的并行 drafter 能够在单次前向传播中高效 Proposed 长令牌序列，但由于缺乏令牌间依赖关系，它们面临着接受率快速衰减的问题。此外，不加区分地验证这些扩展块会浪费关键的批次容量在具有高拒绝风险的令牌上，严重降低了高并发服务系统中的吞吐量。

我们提出了 DSpark，这是一个推测解码框架，统一了高吞吐量的并行生成与自适应的、负载感知的验证。为了保持草稿质量，DSpark 利用半自回归架构——将并行主干与轻量级顺序模块耦合——引入块内依赖建模并缓解后缀衰减。为了优化系统效率，DSpark 采用置信度调度验证，根据估计的前缀存活概率和引擎特定的吞吐量配置文件，动态地为每个请求定制验证长度。

在跨多个领域的离线基准测试中，DSpark 在已接受长度方面显著优于最先进的自回归和并行 drafter。当部署在 DeepSeek-V4 服务系统中并处理实时用户流量时，DSpark 成功缓解了验证浪费。与已确立的生产基线（MTP-1）相比，DSpark 在匹配的吞吐量水平上加速了每用户生成速度 60%–85%。

结合 DSpark 论文与代码实现，全面剖析 DeepSpec 的工作原理与核心组件。

项目地址：https://github.com/deepseek-ai/DeepSpec DSpark 论文：https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf

DSpark 是 DeepSeek 提出的一套无损加速大模型推理的“看人下菜碟”机制。 传统加速手段（推测解码）通常是让小模型一次性盲目盲猜一大串后续 Token，再让大模型统一验证。但这存在两个痛点：小模型猜得越往后越不准（多模态冲突导致“后缀衰减”）；高并发时，大模型花大力气去验证那些猜得不准的 Token，会严重压垮系统吞吐。

DSpark 的核心突破就在于两点：

1. 猜得更准（半自回归）： 它在原有的单次并行生成网络后，拼了一个极轻量的小尾巴（顺序头），在几乎不增加延迟的情况下，让后面的 Token 能根据前面猜出的 Token 进行自适应修正，大幅提升长序列的猜测准确度。
2. 动态裁剪（置信度调度）： 它能实时感知系统的硬件负载与并发压力。如果并发高、大模型很忙，或者发现后面小模型猜的置信度太低，它就会果断把不靠谱的后缀砍掉，只送靠谱的前缀给大模型验证。

通过这种“高质量猜测”与“负载感知动态裁剪”的结合，DSpark 在保障大模型输出质量完全无损的前提下，成功

Pi 是一个模块化的 AI 编码智能体 Monorepo，使用 TypeScript 构建。它提供统一的 LLM 抽象层、通用的智能体运行时、丰富的终端 UI 框架，以及完全可扩展的编码智能体命令行工具。

1. 项目概览

Pi（@earendil-works/pi-mono）是由 Mario Zechner 开发的 AI 编码智能体 Monorepo，设计理念是模块化、可扩展、供应商无关。它将多个 LLM 供应商的复杂性抽象为统一 API，提供强大的智能体运行时和工具执行能力，并附带生产就绪的终端 UI。

核心能力

能力	说明
统一 LLM API	9 种 API 协议和 30+ 供应商品牌的单一接口。只需修改一个字符串即可切换供应商。
智能体运行时	完整的智能体循环，支持并行工具执行、消息注入队列和上下文压缩。
丰富的终端 UI	独立的终端 UI 框架，支持差异化渲染、文本编辑器、图片显示和浮层系统。
扩展系统	80+ 扩展示例、20+ 生命周期钩子。可注册工具、命令、快捷键和供应商。
Web 组件	基于 Lit 的聊天 UI，支持沙箱化 Artifact 渲染（HTML、SVG、PDF、DOCX 等）。
多运行模式	交互式终端、管道友好的打印模式，以及用于 IDE 集成的 JSONL RPC 模式。

包依赖关系图

DeepSeek-V4

简介

我们在此发布 DeepSeek-V4 系列的预览版本，包括两个强大的混合专家（MoE）语言模型 —— 总参数量 1.6T（激活 49B）的 DeepSeek-V4-Pro，以及总参数量 284B（激活 13B）的 DeepSeek-V4-Flash，两者均支持长达 一百万 token 的上下文。

DeepSeek-V4 系列在架构与优化方面引入了多项关键升级：

1. 混合注意力架构：我们设计了一种结合压缩稀疏注意力（CSA）与重度压缩注意力（HCA）的混合注意力机制，大幅提升长上下文处理效率。在 1M token 上下文设定下，DeepSeek-V4-Pro 的单 token 推理 FLOPs 仅为 DeepSeek-V3.2 的 27%，KV 缓存仅占其 10%。
2. 流形约束超连接（mHC）：我们引入 mHC 来增强传统的残差连接，在保留模型表达能力的同时，提升信号跨层传播的稳定性。
3. Muon 优化器：我们采用 Muon 优化器以实现更快的收敛速度和更高的训练稳定性。

两款模型均在大于 32T 的多样化高质量 token 上进行了预训练，并随后执行了全面的后训练流程。后训练采用两阶段范式：首先独立培养领域专属专家（通过 SFT 与基于 GRPO 的强化学习），随后通过 on-policy 蒸馏将不同领域的专长整合至单一模型中。

DeepSeek-V4-Pro-Max 作

编码智能体的核心组件——编码智能体如何借助工具、记忆与仓库上下文，让大语言模型在实际应用中更高效

Sebastian Raschka 博士 2026年4月4日

本文将讲解编码智能体与智能体框架的整体设计：它们是什么、如何工作，以及各模块在实际中如何协同。读过我《从零构建大语言模型》《从零构建推理模型》两本书的读者经常问到智能体相关问题，因此我整理了这份可直接参考的说明。

总体而言，智能体之所以成为重要议题，是因为当下大语言模型实用系统的进步，不只在于模型本身更强，更在于我们如何使用模型。在许多真实场景中，模型外围的系统——如工具调用、上下文管理、记忆机制——与模型本身同等重要。这也解释了为何 Claude Code、Codex 这类系统，会比在普通聊天界面中使用同款模型显得能力强得多。

本文将拆解编码智能体的六大核心组件。

Claude Code、Codex CLI 与其他编码智能体

你大概率熟悉 Claude Code 或 Codex CLI，简单来说，它们本质是智能体式编码工具：在大语言模型外层封装一层应用层（即智能体框架），让编码任务更便捷、性能更优。

编码智能体专为软件工程场景设计，其关键不只在于模型选择，更在于外围系统：仓库上下文、工具设计、提示词缓存稳定性、记忆能力、长会话连续性。

这个区分很重要，因为人们谈论大语言模型的编码能力时，常把模型、推理行为、智能体产品混为一谈。

Harness 工程：给 AI 智能体一个"可靠的家"

想象一下，你有一个非常聪明但有点冲动的助手——它知识渊博、能说会道，但有时候会：

• 忘记五分钟前你们讨论的事情
• 直接执行危险操作而不问你
• 在复杂任务中迷路，绕来绕去
• 做错了事，但你不知道为什么

这就是没有 Harness 的 LLM 智能体。

什么是 Harness？

Harness 这个词在英文里有"马具"、"安全带"的意思。在 AI 智能体的世界里，它就是那个让智能体既能够发挥能力，又不会失控的"安全脚手架"。

这个隐喻是有意的：

• 马是 AI 模型——强大、快速，但它自己不知道去哪里
• Harness是基础设施——约束、护栏、反馈循环，以富有成效地引导模型的力量
• 骑手是人类工程师——提供方向，而不是亲自奔跑

用一个更贴近生活的比喻：Harness 就像是智能体的"驾驶舱 + 安全带 + 导航系统 + 黑匣子"的组合体。

根据 Harness Engineering 将原始模型能力转化为可靠 Agent 行为的脚手架。实用的 Agent 最好被理解为在 Harness 内部运行的模型，而不是带有外围能力的模型。

真实故事：Harness 工程的威力

在我们深入技术细节之前，让我们看看几个真实的例子，了解为什么 Harness 工程如此重要：

WikiLLM

利用 LLM 构建个人知识库的系统。WikiLLM 将原始素材"编译"成结构化、交叉链接的高质量中文 Wiki，可在 Obsidian 中查看。

本项目基于 Andrej Karpathy 提出的理念构建。详见：LLM Knowledge Bases

项目概述

WikiLLM 的工作流包括：

1. 数据摄入：源文档（文章、论文、代码库、数据集、图像）被索引到 raw/ 目录
2. Wiki 编译：LLM 增量地"编译"原始数据成 markdown 文件的 wiki，包含摘要、反向链接、分类概念和相互链接的文章
3. IDE：Obsidian 用作前端查看原始数据、编译后的 wiki 和可视化
4. 问答：LLM 可以通过研究相关数据来回答针对 wiki 的复杂问题
5. 输出：结果渲染为 markdown 文件、Marp 幻灯片或 matplotlib 图像，可在 Obsidian 中查看
6. Linting：LLM"健康检查"发现不一致、填补缺失数据、建议新文章候选
7. 额外工具：诸如 wiki 上的朴素搜索引擎等额外工具

核心原则

• LLM 编写和维护所有 wiki 数据；手动编辑很少见
• 用户探索和查询被归档回 wiki 以增强它
• 系统专注于 markdown 文件和 Obsidian 兼容格式
• 图像被下载到本地 以便 LLM 轻松引用

目录结构

• LLM Knowledge Bases

最近我发现一个非常实用的方法：利用大语言模型（LLM）为各类感兴趣的研究方向搭建个人知识库。这样一来，我近期消耗的模型令牌中，用于处理代码的占比大幅减少，更多被用于处理知识（以 Markdown 文件和图片形式存储）。最新的大语言模型在这方面表现十分出色。具体做法如下：

数据导入

我先将各类源文件（文章、论文、代码仓库、数据集、图片等）归档到 raw/ 目录下，再通过大语言模型逐步“编译”生成一份知识库，这份知识库本质就是按目录结构组织的一系列 .md 文件。 知识库会包含 raw/ 目录下所有数据的摘要、反向链接，还会将数据按概念分类、撰写对应词条并完成相互关联。 为把网页文章转为 .md 文件，我习惯使用 Obsidian 网页剪藏插件，同时通过快捷键将相关图片批量下载到本地，方便大语言模型直接调用。

集成开发环境

我把 Obsidian 当作前端 IDE，既能查看原始数据、编译后的知识库，也能查看衍生的可视化内容。 需要重点说明的是：整个知识库的内容撰写与维护均由大语言模型完成，我几乎不直接手动修改。我还试用过多款 Obsidian 插件，以其他形式渲染和查看数据（比如用 Marp 制作幻灯片）。

问答交互 真正有意思的是，当知识库规模足够大时（比如我近期的研究知识库已有约 100 篇词条、40 万字），就可以向大语言模型智能体提出各类复杂问题

关于标准化使用 /llms.txt 文件以提供信息，帮助大语言模型（LLM）在推理阶段使用网站内容的提案。

Jeremy Howard 2024-09-03

背景

大型语言模型（LLM）越来越依赖网站信息，但面临一个关键限制：上下文窗口（Context Windows）太小，无法处理大多数完整的网站内容。将包含导航、广告和 JavaScript 的复杂 HTML 页面转换为 LLM 友好的纯文本内容既困难又不精确。

虽然网站同时服务于人类读者和 LLM，但 LLM 受益于在单一可访问位置收集的更简洁、专业级别的信息。这在开发环境等用例中尤为重要，LLM 需要快速访问编程文档和 API。

提案

我们建议在网站上添加一个 /llms.txt Markdown 文件，以提供 LLM 友好的内容。该文件提供简要的背景信息、指导和指向详细 Markdown 文件的链接。

llms.txt Markdown 既可以被人类阅读，也可以被 LLM 读取，同时具有精确的格式，允许使用固定的处理方法（即经典的编程技术，如解析器和正则表达式）。

我们进一步建议，网站上可能对 LLM 有价值的信息页面应提供该页面的干净 Markdown 版本，URL 与原始页面相同，但附加 .md 扩展名。（没有文件名的 URL 应附加 index.html.md 代替。）

Andrej Karpathy：氛围编程（vibe coding）

我称之为“氛围编程”（vibe coding）——这是一种全新的编程方式：你完全沉浸在感觉中，拥抱指数级的效率提升，甚至忘掉代码本身的存在。

这之所以成为可能，是因为大语言模型（比如配合 Sonnet 使用的 Cursor Composer）正变得过于强大。而且，我直接通过 SuperWhisper 和 Composer 语音对话，几乎连键盘都不碰。我会提一些极度偷懒的要求，比如“把侧边栏的间距缩减一半”，因为我根本懒得去代码里找位置。我永远点“全部接受”（Accept All），再也不看代码比对（diffs）了。遇到报错信息，我直接原样粘贴回去，一句话都不解释，通常这样就能修好。

代码库的增长速度超出了我以往的理解能力，如果真要搞懂，我得花好长一段时间去通读。有时大模型修不好某个 Bug，我就绕过去，或者要求进行随机改动，直到 Bug 消失。对于那些周末折腾的练手项目来说，这种方式还算凑合，但也确实挺离谱的。

我正在开发一个项目或 Web 应用，但这感觉并不像在编程——我只是观察、动嘴、运行、粘贴，然后它居然大部分时间都能跑通。

Andrej Karpathy：智能体工程（agentic engineering）

很多人转发这条推文，以此纪念“氛围编程”（vibe coding）诞生一周年。简单回顾一下：

当用户在whatsapp, discord 等消息软件中发送了消息后，网关是如何获得的，再到回复，整个流程是如何运转的？

OpenClaw 消息处理完整流程

1. 消息接入 → 2. 路由决策 → 3. AI 处理 → 4. 回复发送

核心文件位置

模块	文件位置	功能
渠道实现	extensions/*/src/channel.ts	WhatsApp/Discord/Telegram 等渠道插件
渠道监听	extensions/discord/src/monitor/listeners.ts	监听渠道消息事件
消息分发	src/auto-reply/dispatch.ts	协调预处理、路由、回复
路由解析	src/routing/resolve-route.ts	根据 bindings 配置决定由哪个 agent 处理
网关服务	src/gateway/server.impl.ts	网关服务器主实现
Agent 执行	src/agents/pi-embedded-runner/	运行 AI agent
消息发送	src/infra/outbound/deliver.ts	统一发送逻辑

详细流程示例（以 Discord 为例）

感觉 Kimi K2.5 在国内被低估了，让子弹飞一会儿 🚀🚀🚀

基准测试（Benchmarks）

Agent Swarm 基准测试

为了严格评估智能体集群（Agent Swarm）框架的有效性，选择了三个具有代表性的基准测试，它们共同涵盖了深度推理、大规模检索以及真实世界的复杂性：

• BrowseComp：一项具有挑战性的深度研究基准，需要多步推理和复杂的信息综合。
• WideSearch：旨在评估在不同来源中进行广泛、多步信息寻求和推理能力的基准。
• In-house Swarm Bench：一项内部开发的集群基准，旨在评估智能体集群在真实世界、高复杂度条件下的性能。 它涵盖了四个领域：
  • WildSearch（开放网络上不受约束的真实世界信息检索）；
  • Batch Download（大规模获取多样化资源）；
  • WideRead（涉及 100 多个输入文档的大规模文档理解）；
  • Long-Form Writing（连贯生成超过 10 万字的海量内容）。 该基准整合了极端规模的场景，旨在压力测试基于智能体系统的编排（Orchestration）、可扩展性（Scalability）和协作能力。

主要基准测试

Kimi K2.5 评估涵盖了多个领域的基准测试，下面是按能力维度分类的各基准测试说明：

推理与通用能力 (Reasoning & General) Humanity’s Last Exam

LongCat-Flash-Thinking-2601 创新性地开启了全栈式的智能体推理（Agentic Reasoning）训练体系与架构优化。首先，提出了自动化的环境扩展流水线，构建了覆盖 20 多个领域的高质量、可执行且可验证的智能体环境，有效解决了真实世界中复杂智能体交互数据匮乏的难题。其次，针对现实任务的不确定性，创新性地引入了鲁棒性智能体训练流程，通过系统性分析现实噪声模式并采用课程强化学习（Curriculum RL）将噪声整合进训练，显著增强了模型在非理想环境下的泛化与生存能力。在底层支撑上，扩展了异步强化学习框架 DORA 以支持高达 32,000 个环境的大规模并发训练，并引入了 Heavy Thinking（深思考）模式，通过在推理阶段同时扩展思考的深度与广度（Test-time Scaling），进一步突破了复杂任务的性能边界。此外，还设计了 Zigzag Attention 稀疏注意力机制，使模型能以极低开销实现高达 100 万 token 的长上下文扩展，为长程智能体任务提供了坚实的架构基础。

重思考模式架构

“重思考模式”（Heavy Thinking Mode）是 LongCat-Flash-Thinking-2601 模型为了突破现有推理能力极限而引入的一种推理时扩展（Test-Time Scaling）架构。

📌 DSL

Dify

1. 克隆代码仓库

git clone https://github.com/langgenius/dify

2. Docker 部署

Dify 提供了 Docker 部署方式，您可以通过以下步骤快速部署：

cd dify
cd docker
cp .env.example .env
docker compose up -d

运行后，可以在浏览器上访问 http://localhost/install 进入 Dify 控制台并开始初始化安装操作。

vLLM

vllm serve /data/models/llm/deepseek/DeepSeek-R1-Distill-Qwen-32B-AWQ/ \
    --served-model-name gpt-4o-mini \
    --tensor-parallel-size 4 \
    --max-model-len 102400 \
    --dtype half \
    --port 8111

Ollama

1. 安装 Ollama 服务。

curl -fsSL https://ollama.com/install.sh | sh

2. 编辑 systemd 服务，调用 systemctl edit ollama.service。这将打开一个编辑器。

sudo systemctl edit ollama.service

对于每个环境变量，在 [Service] 部分下添加一行