139 篇文章带有标签 “llm”

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] 部分下添加一行

优先使用：豆包 和 Grok

提示词

根据历年财报进行投资分析

基于京东健康上市后历年的财报，从价值投资的角度进行分析。

文件：

• 京东健康 2020 年度报告.pdf
• 京东健康 2021 年度报告.pdf
• 京东健康 2022 年度报告.pdf
• 京东健康 2023 年度报告.pdf
• 京东健康 2024 年度报告.pdf
• 京东健康 2025 中期报告.pdf

评估各模型投资分析能力

下面是我使用提示词：“基于京东健康上市后历年的财报，从价值投资的角度进行分析。”对多个大语言模型进行的分析结果。你作为一个评判专家，请对比各模型的分析内容，给出你的综合评价。

评判结果

Doubao

Grok 4.1

Gemini3

ChatGPT

DeepSeek-Think

混元

Kimi-K2-Think

LeChat

LongCat

MiniMax M2.1

Qwen3-千问

综合AI助手，全面回答工作、学习、生活各类问题

Qwen3-Max

千问系列中最强大的语言模型

各模型投资分析结果

Gemini

Engram 是一种旨在增强大语言模型性能的条件记忆（Conditional Memory）模块。传统的 Transformer 架构在处理静态知识检索时效率较低，往往需要通过复杂的计算来模拟记忆，而 Engram 通过现代化的 N-gram 哈希查找实现了常数级时间复杂度 O(1) 的知识获取。研究者揭示了一种 U 型缩放法则，证明在固定参数预算下，平衡条件计算（MoE）与静态内存（Engram） 能显著提升模型在推理、代码及数学任务中的表现。实验分析表明，Engram 能减轻模型底层对基础模式的重复构建，从而释放更多算力用于处理全球上下文和深度推理。此外，Engram 的确定性寻址特性支持从主机内存预取数据，使其能在不增加硬件负担的情况下实现大规模参数扩张。最终，该技术为构建更高效、具备长文本处理能力的新一代稀疏模型提供了核心原语。

Engram 架构

记忆内存的参数就像是图书馆书架上的一本本百科全书，记录着世界上的事实；而 Engram 模块的参数就像是一位经验丰富的图书管理员。管理员通过训练（学习），能够根据你当前提出的研究课题（隐藏状态），迅速判断哪些百科全书的条目是有用的，哪些是由于名字相似而找错的（哈希冲突），并帮你把这些知识翻译成你研究报告能用的语言（投影整合）。

该模块通过检索静态 N-gram 记忆，并利用上下文感知门控（context-aware gating）将其

内网IP：27.41.19.62

服务	说明	端口	模型	备注
whisperlivekit	实时语音识别服务	8000	Whisper small (默认) large-v3-turbo	带说话人分离
FunASR	实时语音识别服务	8000	语音识别：paraformer-zh 实时语音识别：paraformer-zh-streaming 实时语音端点检测：fsmn-vad 标点恢复：ct-punc 文本逆规范化：fst_itn_zh	实时与非实时一体化协同（2pass）服务模式
llama-server	GGUF 模型推理服务	8080	Qwen3 Qwen3-8B-Q5_K_M.gguf	模型名：qwen3 上下文长度：32K 不思考

系统设置

系统优化

最大功率模式（一次性设置）

sudo nvpmodel -m 0

启动最高频率（每次重启后设置）

sudo jetson_clocks

清理内存

sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

WhisperLiveKit

• WhisperLiveKit - 实时语音识别

部署服务

tmux new -s wlk

默认容器内应用（标点识别有时会失灵 ⚠️）

推理服务

CUDA GPU Compute Capability（计算能力）

计算能力（CC）定义了每种 NVIDIA GPU 架构的硬件特性和支持的指令。在下表中查找您的GPU的计算能力。

vLLM

docker run -it --rm \
  --ipc=host \
  --net=host \
  --runtime=nvidia \
  --name=vllm-test \
  -v /models:/models \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -v ~/.cache/modelscope:/root/.cache/modelscope \
  nvcr.io/nvidia/vllm:25.10-py3 \
  bash

默认情况下，如果模型未指向有效的本地目录，它将从 Hugging Face Hub 下载模型文件。要从 ModelScope 下载模型，请在运行命令之前进行如下设置：

export VLLM_USE_MODELSCOPE=true

vllm serve /models/Qwen/Qwen3-8B \
  --served-model-name qwen3 \
  --chat-template /models/Qwen/Qwen3-8B/qwen3_nonthinking.jinja

SGLang

vLLM V1 引擎通过优化其核心引擎循环，将输入处理并行化，并引入了分段式 CUDA 图，从而实现了更灵活、动态的执行模型，显著降低了在线服务的延迟（TTFT 和 TPOT），同时保持了高吞吐量。其设计目标是确保 GPU 不闲置，通过 API 服务器和 EngineCore 之间的协作来高效调度和执行任务。为了进一步加速大型语言模型推理，vLLM V1 采用了多种优化技术：它通过分离式预填充和分块预填充来优化首个 token 的生成延迟，并结合连续批处理与分页注意力来提高 KV 缓存的内存效率和 GPU 利用率。此外，前缀缓存技术避免了重复计算相同提示的 KV 缓存，而级联推理则是一种内存带宽高效的共享前缀批处理解码技术，通过结合多查询注意力处理共享 KV 和单查询批处理解码处理独特 KV，特别适用于多用户共享长提示的场景，能显著提升性能。其他高级解码方法如推测性解码利用草稿模型加速生成，跳跃解码则适用于结构化输出场景。最后，量化技术是提升性能的关键手段，通过对权重、激活值和 KV 缓存使用低位精度（如 FP8、INT8），它能减少存储和内存占用，加速计算密集型和内存带宽密集型任务，并允许在固定硬件下处理更多 token，从而大幅提升吞吐量，同时保持模型准确性。

V1 Engine 工作流程

推理优化

典型 LLM 推理优化

• Flash Attention 的核心思想是将多个操作融合为一个 GPU 内核（kernel），并充分利用速度极快的片上 SRAM（静态随机存取存储器）。

该文章详细探讨了如何通过优化vLLM框架来提升Qwen3-4B大型语言模型在Tesla T4 GPU上的推理性能。实验中，我评估了不同配置对关键性能指标的影响，包括首次生成Token时间（TTFT）、端到端延迟（E2EL）和请求吞吐量。结果表明，结合前缀缓存（prefix caching）、分块预填充（chunked prefill）以及调整批处理Token数量（max-num-batched-tokens=8192）能显著改善模型性能。尤其在模拟Agent场景下的自定义数据集测试中，这些优化措施成功将TTFT大幅降低约64%，同时提升了请求和输出Token的吞吐量。最终，文章提供了一套推荐的最佳vLLM部署配置，旨在最大化长上下文模型的推理效率和用户体验。

vLLM 工作流程

1. Prefill

Prefill 阶段是指模型在生成任务开始时，将输入 prompt（提示词）全部送入模型，并填充（prefill）KV Cache（键值缓存）。这个阶段通常只在生成的第一个 token 前进行。

• 主要作用：将所有 prompt token 送入模型，建立好 KV Cache，为后续高效 decode 做准备。
• 在 vLLM 里，prefill 可以独立出来（Disaggregated Prefill），甚至由独立的实例来执行，prefill 完成后把 KV Cache 通过网络/进程传给 decode 节点。
• 示例代码见：examples/offline_inference/disaggregated_prefill.py
• 在 chunked prefill 场景下，长文本的 prefill 会被分块（chunk）处理，并与 decode 请求混合批处理，以充分利用算力。

本文档首先比较了 NFS、GlusterFS、Ceph 和 HDFS 四种分布式文件系统的优缺点及适用场景，强调了 GlusterFS 在无元数据服务器、高可用性和横向扩展方面的优势。Gluster 是一个可扩展的分布式文件系统，它将来自多个服务器的磁盘存储资源聚合成一个单一的全局命名空间。文档提供了在多台服务器上准备环境、安装 GlusterFS、配置信任池、创建和启动分布式复制卷的详尽步骤，并指导如何在客户端挂载和测试 GlusterFS 卷。最后，文档通过网络带宽和磁盘读写性能测试，对 GlusterFS 的实际表现进行了评估，指出当前网络带宽可能是性能瓶颈，建议使用更高速的网络接口（25 GbE）以提升性能。

服务器配置

AI 服务器：华为 Atlas 800I A2 推理服务器 X 5

组件	规格
CPU	鲲鹏 920（5250）
NPU	昇腾 910B4（8X32G）
内存	1024GB
硬盘	系统盘：450GB SSDX2 RAID1 数据盘：3.5TB NVME SSDX4
操作系统	openEuler 22.03 LTS

分布式文件系统对比分析：

NFS (Network File System)

NFS 是一种传统的客户端-服务器架构文件共享协议，而不是一个真正的分布式文件系统。它允许客户端通过网络访问远程服务器上的文件，就像访问本地文件一样。