DoneHub

背景

每天打开手机，十几个 APP 轮番刷一遍，微博热搜、知乎热榜、抖音热点、今日头条……刷完一圈下来，两个小时过去了，真正有用的信息可能就三五条。剩下的是什么？震惊体标题党、营销软文、明星八卦、各种算法硬塞给你的”你可能感兴趣”。

更气人的是，明明只想看看科技圈今天发生了什么，却被”某明星离婚”霸占了热搜第一。平台算法绑架了我们的注意力，想看的内容找不到，不想看的铺天盖地。

有没有一种工具，能帮你从”被动接收”变成”主动获取”？TrendRadar 就是这么一个开源项目——聚合全网热点，按你的关键词筛选，定时推送到你的手机。更重要的是，它还能让 AI 帮你分析这些热点背后的趋势和情绪。

TrendRadar 是什么

一句话概括：TrendRadar 是一个开源的热点新闻聚合分析工具。

它的核心思路很简单——把全网 50+ 个平台的热榜抓过来，按你设定的关键词过滤，把真正关心的内容推给你。推送渠道也很丰富：飞书、钉钉、企业微信、Telegram、邮件、Bark（iOS）、Slack，甚至自定义 Webhook。

更厉害的是，它内置了 AI 分析功能。不仅是聚合热点，还能让 AI 帮你：

• 分析热点趋势走向
• 判断舆论情绪（正面/负面/争议）
• 跨平台关联分析
• 生成洞察报告

这就像雇了一个私人新闻助理，每天帮你从海量信息中提炼出真正有价值的干货。

数据是怎么来的

TrendRadar 的数据来源是另一个开源项目 NewsNow。这个项目聚合了全网 50+ 个平台的热榜数据，包括：

NewsNow 通过调用各平台的官方 API 或爬取页面来获取热榜数据，然后统一输出成标准格式。TrendRadar 直接调用 NewsNow 的公开 API：

1

https://newsnow.busiyi.world/api/s?id=zhihu&latest

返回的数据格式是这样的：

1
2
3
4
5
6
7
8
9
10
11
12
13

{
  "status": "success",
  "items": [
    {
      "title": "如何评价DeepSeek新模型?",
      "url": "https://zhuanlan.zhihu.com/p/xxx",
      "extra": {
        "info": "1234万热度",
        "hover": "摘要描述..."
      }
    }
  ]
}

所以 TrendRadar 不需要自己去啃各平台的反爬机制，数据源维护这个苦活儿由 NewsNow 项目负责。万一某个平台接口变了，NewsNow 更一下就行，TrendRadar 用户完全不用操心。

核心功能一览

热榜聚合

默认支持 11 个主流平台：知乎、微博、百度热搜、抖音、今日头条、B站热搜、华尔街见闻、财联社、澎湃新闻、凤凰网、贴吧。想加更多平台？直接在配置文件里加就行。

关键词筛选

这是核心功能。你在 frequency_words.txt 里写上关心的关键词，系统就只推送包含这些词的新闻。语法很灵活：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

# 最简单的：直接写关键词
华为

# 多个关键词归为一组（空行分隔）
华为
鸿蒙
任正非

# 给词组起个名字
[科技巨头]
华为
腾讯
字节

# 正则匹配（精确匹配英文单词，避免误匹配）
/\bAI\b/ => AI相关
人工智能

# 排除不想看的
[苹果公司]
苹果
!水果        # 排除"水果"相关的

# 限制显示条数
特斯拉
@10          # 最多显示10条

# 必须同时包含多个词
+发布会
+新品        # 必须同时出现"发布会"和"新品"

AI 智能筛选（新功能）

如果你不想自己写关键词，可以用 自然语言描述 你关注的方向。在 ai_interests.txt 里写：

1
2
3
4
5
6
7
8
9
10
11

下面是我要关注的内容：

1. 中国科技与互联网公司：重点关注 DeepSeek、华为、腾讯...
2. 大模型与 AI 产品：关注 OpenAI、Claude、ChatGPT...
3. AI 基础设施与云算力：关注英伟达、AMD...
4. 芯片与半导体制造：关注芯片、光刻机...
...

# 标题质量要求
- 不要标题党/震惊体
- 不要营销软文

AI 会自动理解你的兴趣，给每条新闻打分，只推送高相关度的内容。这个功能需要配置 AI API（支持 DeepSeek、OpenAI、Gemini 等）。

三种推送模式

举个例子：你监控”特斯拉”，每小时执行一次。如果选择 incremental 模式，只有第一次出现的新闻才会推送给你，后续重复出现的就不打扰了。适合高频监控场景。

调度系统（时间线）

你可以精细控制”什么时间做什么事”。比如：

• 工作日：早上9点速览、中午看热点、晚上7点汇总
• 周末：睡到自然醒，10点开始推送，有新增就推

预设了 5 种模板：always_on（全天候）、morning_evening（早晚汇总）、office_hours（办公时间）、night_owl（夜猫子）、custom（完全自定义）。

AI 分析推送

开启后，每次推送都会附带一份 AI 生成的洞察报告，包含：

• 核心热点态势
• 舆论风向争议
• 异动与弱信号
• 研判策略建议

AI 还能分析每条新闻的排名变化轨迹、热度持续时间、跨平台表现。比如某条新闻在微博排第3，知乎排第5，抖音排第8——AI 能告诉你这个话题的”全网热度分布”。

AI 多语言翻译

如果你订阅了海外 RSS（如 Hacker News），AI 可以帮你把英文标题翻译成中文。反过来，如果你想用英文读国内热点，也可以翻译成英文。

MCP 智能分析（进阶功能）

这是给深度用户准备的。TrendRadar 实现了 MCP (Model Context Protocol) 协议，可以接入 Claude Desktop、Cherry Studio、Cursor 等 AI 客户端。

你可以用自然语言跟新闻数据”对话”：

1
2
3
4

"分析过去一周 DeepSeek 的热度变化"
"对比知乎和微博今天的热点差异"
"生成一份今天的科技热点摘要，推送到飞书"
"搜索特斯拉相关新闻，分析情感倾向"

AI 会自动调用 TrendRadar 的 21 个分析工具，帮你做深度数据挖掘。

部署方式

GitHub Actions（零服务器）

适合没有服务器的用户。流程是：

1. Fork TrendRadar 仓库到自己的 GitHub
2. 配置 GitHub Secrets（填推送渠道的 webhook URL）
3. GitHub Actions 定时运行，自动抓取并推送

缺点是每次运行完环境就销毁，数据没法本地存。需要配置云存储（如 Cloudflare R2）来持久化数据。

Docker（推荐）

适合有服务器、NAS 或长期运行电脑的用户。数据本地存储，更稳定。

1
2
3
4
5
6
7
8
9
10

# 克隆项目
git clone https://github.com/sansan0/TrendRadar.git
cd TrendRadar

# 配置
cp config/config.yaml.example config/config.yaml
# 编辑 config.yaml 和 frequency_words.txt

# 启动
docker compose up -d

Docker 部署还有个好处：可以同时跑两个容器——一个做新闻推送，一个做 MCP AI 分析服务。

本地运行

Windows/Mac/Linux 直接跑：

1
2
3
4
5
6
7
8

# Windows
setup-windows.bat

# Mac/Linux
./setup-mac.sh

# 运行
python main.py

配置要点

config.yaml 主配置

这是核心配置文件，结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

app:
  timezone: "Asia/Shanghai"        # 时区

schedule:
  enabled: true
  preset: "morning_evening"        # 调度模板

platforms:
  enabled: true
  sources:                         # 监控平台列表
    - id: "zhihu"
      name: "知乎"
    - id: "weibo"
      name: "微博"

report:
  mode: "incremental"              # 推送模式
  display_mode: "keyword"          # 显示方式

filter:
  method: "keyword"                # keyword | ai

notification:
  enabled: true
  channels:
    feishu:
      webhook_url: ""
    telegram:
      bot_token: ""
      chat_id: ""

ai:
  model: "deepseek/deepseek-chat"  # AI 模型
  api_key: ""                      # API Key

ai_analysis:
  enabled: true                    # 开启 AI 分析
  max_news_for_analysis: 50        # 分析数量上限

ai_translation:
  enabled: true
  language: "中文"

frequency_words.txt 关键词配置

前面已经介绍过语法，这里补充几个实用技巧：

技巧1：从宽到严，逐步调整

刚开始可以写宽泛的关键词，观察几天后再加过滤词：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 第一版：先测试
AI
ChatGPT

# 第二版：发现太多广告，加过滤
AI
ChatGPT
!培训
!课程
!广告

# 第三版：只想看技术相关，加必须词
AI
ChatGPT
+技术

技巧2：正则表达式精确匹配英文

英文容易误匹配，比如 ai 会匹配到 training 里的 ai。用正则解决：

1
2
3
4
5
6

# 精确匹配独立单词
/\bAI\b/i => AI相关

# 匹配开头或结尾
/^breaking/     # 只匹配开头是 breaking 的
/发布$/         # 只匹配结尾是"发布"的

不会写正则？直接问 ChatGPT：”帮我写一个正则表达式，精确匹配英文单词 AI，不匹配 training 里的 ai，格式是 /正则/ => 别名”

技巧3：全局过滤不想看的

有些内容不管什么关键词都不想看，用 [GLOBAL_FILTER]：

1
2
3
4
5
6
7
8
9

[GLOBAL_FILTER]
震惊
刚刚
竟然
广告
推广

[WORD_GROUPS]
你的关键词配置...

推送渠道配置

企业微信（最简单）：

1. 打开企业微信，进入目标群聊
2. 点击右上角”…”，选择”群机器人”
3. 添加机器人，复制 Webhook URL
4. 填入配置或 GitHub Secrets

飞书：

1. 访问 https://botbuilder.feishu.cn/home/my-command
2. 新建机器人指令
3. 选择”Webhook 触发”，复制 URL
4. 配置参数模板：

   1 2 3 4

   { "message_type": "text", "content": { "text": "{{内容}}" } }

Telegram：

需要两个配置：bot_token 和 chat_id。

1. 在 Telegram 搜索 @BotFather，发送 /newbot 创建机器人
2. 获取 Bot Token
3. 向你的机器人发一条消息
4. 访问 https://api.telegram.org/bot<Token>/getUpdates
5. 从返回 JSON 找到 chat.id

邮件：

支持 Gmail、QQ邮箱、163、Outlook 等。QQ邮箱需要用授权码（不是密码），在邮箱设置里开启 SMTP 服务后生成。

实际使用体验

我部署了一套配置，关键词设为：AI、DeepSeek、华为、特斯拉、芯片、大模型。推送模式选 incremental，调度选 morning_evening。

效果是这样的：

早上 9 点：收到推送，包含昨晚到今早新出现的 15 条相关热点。AI 分析报告附在最后，告诉我”AI 领域今天舆论偏正面，DeepSeek 新模型发布引发热议，华为鸿蒙讨论度上升”。

晚上 8 点：收到当日汇总，包含全天所有匹配新闻（去重后约 30 条）。AI 给了一份更完整的趋势分析，包括”哪些话题持续在榜”、”哪些是新爆发点”。

好处：

1. 不用刷 APP 了。之前每天刷微博知乎抖音至少两小时，现在 5 分钟看完推送就行。
2. 信息密度高。一条推送包含 11 个平台的热点，跨平台对比一目了然。
3. AI 分析有价值。不是简单的汇总，而是告诉你趋势、情绪、关联。比如”特斯拉降价”这个话题，AI 能分析出”微博讨论偏负面（吐槽割韭菜），知乎讨论偏中性（分析影响），抖音讨论偏正面（喊降价真香）”。

注意点：

1. 关键词不要太多。我刚开始写了 30 多个关键词，结果每次推送 100 多条，信息过载。后来精简到 6 个核心关键词，效果好多了。
2. AI 分析有成本。默认模型是 DeepSeek，很便宜。按官方估算，每小时推送一次，每天约 0.1 元。如果想省钱，可以把 max_news_for_analysis 从 150 降到 50。
3. GitHub Actions 有延迟。定时任务触发时间不稳定，可能有 ±15 分钟偏差。如果需要精准推送，建议用 Docker 部署到自己的服务器。

MCP 功能进阶用法

如果你想深度挖掘新闻数据，MCP 功能很有价值。

配置 MCP 客户端

以 Cherry Studio 为例（推荐，有 GUI）：

1. 运行 TrendRadar 的 MCP 服务：

   1 2 3 4 5

   # Windows start-http.bat # Mac/Linux ./start-http.sh

2. 在 Cherry Studio 设置里添加 MCP 服务器：

   • 类型：streamableHttp
   • URL：http://127.0.0.1:3333/mcp

3. 开始对话。

MCP 可以做什么

趋势分析：

1

"分析最近 7 天 DeepSeek 的热度变化"

AI 会调用 analyze_topic_trend 工具，返回：

• 首次出现时间、持续时间
• 排名变化曲线（第3→第1→第5）
• 热度峰值、爆火判断
• 趋势预测

平台对比：

1

"对比知乎和微博今天关于 AI 的讨论差异"

AI 会对比两个平台的热点分布、情绪倾向、讨论角度差异。

情感分析：

1

"分析特斯拉最近新闻的情感倾向"

返回正面/负面/中性分布，以及典型情感关键词。

生成报告并推送：

1

"写一份今天的科技热点摘要，推送到飞书"

AI 会调用 generate_summary_report 生成报告，然后调用 send_notification 推送。自动处理格式转换（Markdown → 飞书格式）。

MCP 工具列表

总共 21 个工具，覆盖了从查询到分析到推送的全流程。

数据存储

TrendRadar 的数据存储在 SQLite 数据库，按日期分库：

1
2
3
4
5
6
7
8

output/
├── news/
│   ├── 2025-05-16.db    # 当天热榜数据
│   ├── 2025-05-15.db    # 历史数据
├── rss/
│   ├── 2025-05-16.db    # RSS 数据
└── html/
    └── 当日汇总.html     # HTML 报告

数据库表结构设计得很好：

• news_items：存储新闻条目（标题、URL、排名）
• rank_history：记录排名变化历史（每次抓取的排名）
• crawl_records：记录抓取时间和数量

这样设计的好处是可以追踪热度变化轨迹。比如某条新闻早上排第 5，中午排第 3，晚上掉到第 10——这些变化都会被记录下来，供 AI 分析。

与其他工具对比

TrendRadar 的优势在于：聚合 + 筛选 + 分析 + 推送 一条龙。RSS 阅读器适合订阅特定博客，热榜网站适合快速浏览，但都没有 AI 分析和自动推送。

项目地址和资源

• GitHub：https://github.com/sansan0/TrendRadar
• 可视化配置编辑器：https://sansan0.github.io/TrendRadar/
• NewsNow 数据源：https://github.com/ourongxing/newsnow

项目维护得很活跃，版本迭代快（从 v1.0 到 v6.7），文档也很详细。有问题可以去 GitHub Issues 提，作者回复很及时。

总结

TrendRadar 解决的问题是：如何从信息洪流中高效获取有价值的内容。

它不是简单的热榜聚合，而是：

• 用关键词/AI筛选过滤噪音
• 用多渠道推送直达手机
• 用AI分析提供深度洞察
• 用MCP协议支持自定义数据挖掘

如果你每天花大量时间刷 APP 看热点，却总觉得信息过载、抓不住重点——试试 TrendRadar。部署一次，配置好关键词，之后就等着推送敲门，看完推送就完事。

从”被动接收算法推荐”变成”主动获取关心内容”，这才是高效的信息消费方式。

背景

2026年，AI浪潮席卷全球，最近都被这些新闻刷频了：

“三星市值突破新高，HBM订单排到明年”
“海力士股价暴涨，成英伟达最大HBM供应商”
“美光宣布HBM3e量产，AI存储竞争白热化”
“长鑫存储融资成功，中国DRAM再获突破”

作为科技爱好者，你可能会有很多困惑：

• 内存条、固态硬盘、HBM… 到底都是什么？
• 为什么AI训练需要HBM，而不是普通内存条？
• 三星、海力士、美光、长鑫、长江存储… 各家到底做什么？

这篇文章，用两个视角帮你彻底理清：DRAM和NAND Flash——存储芯片世界的两大支柱。

第一视角：DRAM

一、DRAM是什么？

DRAM = Dynamic Random Access Memory，中文叫”动态随机存取存储器”。

通俗理解：DRAM就是你电脑上的”临时工作台”。

1
2
3
4
5
6

你在用Word写文档：
硬盘（SSD）── 长期保存文件，断电后还在
     ↓ 打开文件时加载
内存条（DRAM）── 临时存放正在编辑的内容，断电就没了
     ↓ CPU随时读取
CPU ── 处理文字、格式、排版

忘记保存就断电？文件没了。因为DRAM里的数据瞬间清空。

二、为什么叫”动态”？

这是DRAM与其他内存技术最大的区别：数据需要不断”刷新”才能保持。

1
2
3
4
5
6
7
8
9
10

DRAM的存储单元 = 1个电容 + 1个晶体管

电容充电 = 存储"1"
电容放电 = 存储"0"

问题：电容会自然漏电，电荷慢慢流失
      几毫秒后，数据就没了

解决：每隔几毫秒"刷新"一次
      把电荷补回去，数据才能保持

这就是”动态”的含义：数据不是静态保存的，需要动态、持续地刷新。

对比一下SRAM（静态随机存取存储器）：

一句话：DRAM性价比高，适合做大容量内存；SRAM性能好但贵，只做CPU内部的小缓存。

三、DRAM的核心特点

四、DRAM产品家族

都属于DRAM技术，但针对不同场景优化：

五、重点解读：HBM为什么是AI的命门

普通内存条有个致命瓶颈：带宽不够。

1
2

普通内存条：单通道带宽约 25GB/s（DDR5-6400）
AI训练需求：几百 GB/s 甚至 TB/s 级别

GPU（如英伟达H100）算力极强，但数据喂不进去——传统内存条成了瓶颈。

HBM的解决方案：垂直堆叠

1
2
3
4
5
6
7
8
9
10
11
12
13

传统内存条：
┌───┐
│芯片│ ← 平铺在PCB上，信号要走很远
└───┘

HBM：
┌─────┐
│芯片8│ ↑
├─────┤ │ 垂直堆叠8-12层
│芯片7│ │ 通过TSV（硅通孔）连接
│ ... │ │ 路径极短，速度极快
└──┬──┘ ↓
   └── GPU芯片（紧邻封装）

核心技术：

性能对比：

这就是为什么英伟达H100价格3万美元起步——HBM成本占了很大比例。

六、DRAM厂商格局

全球市场份额（2025年Q1）：

三巨头控制93%+市场

2025年关键变化：

• 海力士份额上升：HBM业务驱动，成英伟达最大HBM供应商
• 长鑫份额上升：从3-5%提升到5-6%，国产替代加速
• 三星份额略降：战略转向高利润HBM，减少低端产能

技术能力矩阵：

中国现状：长鑫存储是中国大陆唯一的DRAM厂商，2016年成立，填补了国内空白。目前主攻DDR4/DDR5、LPDDR4/LPDDR5，HBM仍在研发阶段。

日本现状：日本已无DRAM厂商。曾经的霸主尔必达2012年破产被海力士收购，日本DRAM产业终结。

第二视角：NAND Flash

一、NAND Flash是什么？

NAND Flash，中文叫”NAND闪存”，是一种非易失性存储器。

通俗理解：NAND Flash就是你电脑的”永久仓库”。

1
2
3
4
5
6
7

你的手机：
RAM（DRAM）8GB ── 运行APP时临时用，断电清空
存储（NAND）128GB ── 保存照片、APP、文件，断电后还在

你的电脑：
内存条（DRAM）16GB ── 正在运行的程序
固态硬盘（NAND）512GB ── 系统、软件、所有文件

核心特点：断电后数据不会丢失，可以长期保存。

二、为什么叫”NAND”和”闪存”

NAND是逻辑门电路的名字（Not AND），用这种结构的晶体管阵列存储数据，所以叫NAND Flash。

“闪存”的由来：

1
2
3
4

传统EEPROM：擦除需要几秒
NAND Flash：擦除只需几毫秒

像"闪光"一样快 → Flash Memory（闪存）

三、工作原理

1
2
3
4
5
6
7
8
9
10
11

NAND存储单元 = 浮栅晶体管

┌─────────────────┐
│ 浮栅            │ ← 电子被困在这里
│  有电子 = 存储"0"│    不会跑掉
│  无电子 = 存储"1"│
└─────────────────┘

写入：把电子注入浮栅（高压）
擦除：把电子从浮栅拉出来（更高电压）
读取：检测浮栅是否有电子

关键点：电子被困在浮栅里，没有电源也能长期保存——这就是”非易失性”的原因。

四、NAND Flash的核心特点

五、NAND分类（按每单元存储位数）

1
2
3
4

简单理解：
SLC = 每格只放1个东西，空间利用率低，但耐用快速
TLC = 每格塞3个东西，空间利用率高，但慢一些
QLC = 每格塞4个东西，最便宜，但寿命最短

六、3D NAND：垂直堆叠技术

传统NAND是平铺的，容量有限。现代技术把存储单元垂直堆叠：

1
2
3
4
5
6
7
8
9

传统2D NAND：
┌──┐ ┌──┐ ┌──┐ ┌──┐ ← 平铺在一层

3D NAND：
┌──┐
│232│ ↑ 垂直堆叠
├──┤ │ 像盖楼房一样
│...│ │ 同样面积，容量翻倍
└──┘ ↓

主流3D NAND层数：

七、长江存储的独创技术：Xtacking

1
2
3
4
5
6
7
8
9
10
11

传统3D NAND：
┌─────────────────┐
│ 存储单元+外围电路 │ ← 同一片晶圆上制造
│    叠在一起      │    层数增加会互相干扰
└─────────────────┘

Xtacking架构：
┌──────────┐   ┌──────────┐
│ 存储单元  │ ←→ │ 外围电路  │ ← 两片晶圆分别制造
│（垂直堆叠）│   │（高速逻辑）│   再键合在一起
└──────────┘   └──────────┘

优势：存储密度更高、I/O速度更快、制造效率更高。

八、NAND Flash产品家族

九、NAND Flash厂商格局

全球市场份额（2025年）：

三星+凯侠+西数+海力士控制80%+市场

2025年关键变化：

• 凯侠完成IPO：2024年底上市，获得资金扩张
• 西部数据拆分：计划将SanDisk业务独立分拆
• 长江存储受限：美国制裁持续，全球份额增长受阻，但国内市场稳步发展

中国现状：长江存储是中国最大的NAND Flash厂商，技术水平与国际差距较小，232层Xtacking技术已接近第一梯队。

日本现状：凯侠（原东芝存储）专注NAND Flash，是日本唯一的存储芯片厂商。日本已无DRAM厂商。

两视角对比：DRAM vs NAND Flash

核心区别

用一个场景理解

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

你打开一个大型游戏：
┌─────────────────────────────────────┐
│ 固态硬盘（NAND）                     │
│ 存着游戏的所有文件（50GB）           │
│ 断电后还在                           │
└─────────────────────────────────────┘
         ↓ 启动游戏时加载
┌─────────────────────────────────────┐
│ 内存条（DRAM）                       │
│ 临时存放正在运行的游戏数据（8GB）     │
│ 断电就没了                           │
└─────────────────────────────────────┘
         ↓ GPU随时读取渲染
┌─────────────────────────────────────┐
│ GPU + HBM                            │
│ AI时代：GPU算力强，HBM喂得快          │
│ 传统内存条喂不饱GPU                  │
└─────────────────────────────────────┘

中国存储产业现状

两家企业，两条路线

为什么差距不同？

DRAM差距较大：

• 三星、海力士、美光有40年技术积累
• DRAM工艺极其复杂，专利壁垒高
• 设备（光刻机、刻蚀机）受国外限制

NAND差距较小：

• NAND技术路线相对灵活
• 长江存储Xtacking架构实现”弯道超车”
• 层数堆叠更多依赖工艺创新，而非单纯制程

总结

DRAM：三巨头（三星+海力士+美光）控制90%市场，长鑫是中国唯一希望，日本已无厂商。

NAND Flash：六强格局（三星/海力士/凯侠/西数/美光/长江存储），长江存储技术水平接近一流。

“任务越复杂越该用多Agent”——听起来好像没毛病，但这句话背后藏着一个巨大的陷阱。很多人一拍脑袋就上多Agent，结果延迟爆表、成本失控、日志一团浆糊，最后发现单Agent加个工具调用就能搞定。上一篇我们聊了 Multi-Agent 系统的设计原理，今天换个角度：什么时候该用多Agent？用完之后，怎么评判这套设计到底好不好？

一、先破一个误区：复杂度不是决策标准

很多人一听到”多Agent”，脑子里的画面是这样的：一个主控 Agent 坐镇中央，下面挂着写代码的、做测试的、写文档的，各司其职，特别壮观。

但壮观不等于好用。

复杂度从来不是选择多Agent的理由。 真正的决策标准只有两个维度：并发收益和上下文约束。

用一张表说清楚：

但这张表太粗了，真实决策远比这复杂。下面我们拆开来讲。

二、决策框架：四把尺子量出答案

2.1 第一把尺子：任务依赖图是线性的还是扇出的？

这是最核心的判断依据。

线性依赖是指任务之间有严格的先后顺序：A 的输出是 B 的输入，B 的输出是 C 的输入。比如用户问”我的退款到哪一步了”——先识别意图，再查订单库，最后组织回复。这三步必须串行，中间插不进任何并行操作。

扇出依赖是指一个任务可以拆成多个互不相关的子任务同时执行。比如”帮我审查这个代码仓库的安全性”——注入漏洞扫描、内存泄漏检测、代码风格检查，这三件事之间没有任何数据依赖，完全可以同时开工。

画成图就是这样的区别：

1
2
3
4
5
6
7
8

线性依赖（单Agent）：
意图识别 → 查数据库 → 组织回复
  A    →    B     →    C

扇出依赖（多Agent）：
            ┌→ 安全检测 ──┐
主控规划 ──→├→ 性能分析 ──├→ 汇总合并
            └→ 规范检查 ──┘

判断标准：如果你的任务依赖图画出来是一条直线，用单Agent。如果画出来像一把扇子，考虑多Agent。

2.2 第二把尺子：上下文窗口是不是硬瓶颈？

有些任务看起来是线性的，但数据量大到单个模型根本吃不下。这时候即使任务是串行的，你也得想办法切分。

举个例子：给你一个 50 万行的代码仓库，要求生成完整的 API 文档。这不是并行任务——你需要理解全局架构才能写好文档。但问题是，50 万行代码塞不进任何模型的上下文窗口。

这时候多Agent的价值不是并行加速，而是上下文切片：

1
2
3
4

Agent-1：扫描 controller 层，提取接口定义
Agent-2：扫描 service 层，提取业务逻辑
Agent-3：扫描 entity 层，提取数据模型
主控 Agent：拿到三份切片报告，合并生成文档

每个 Agent 只需要处理自己那一层的代码，上下文压力骤降。最后主控 Agent 拿到的是三份精炼过的报告，而不是几十万行原始代码。

判断标准：估算一下任务需要的上下文 token 量。如果超过模型窗口的 60%，就要考虑切分了。留 40% 的余量给系统 Prompt、工具调用和中间推理。

2.3 第三把尺子：延迟预算够不够？

这是最容易被忽略的一把尺子。

多Agent系统的延迟公式非常残酷：

1

总延迟 = max(各子Agent延迟) + 主控规划延迟 + 主控汇总延迟 + 通信开销

注意这里用的是 max 不是 sum——因为子 Agent 是并行的，总延迟取决于最慢的那个。听起来不错对吧？但别忘了后面还有三项固定开销。

在真实的线上环境里，大模型的一次调用延迟通常在 2-8 秒。一个三层架构的多Agent系统，光是规划和汇总就要各调一次模型，加上子 Agent 的执行时间，端到端延迟很容易突破 15 秒。

对比一下单Agent方案：

1
2

单Agent：意图识别(2s) → 工具调用(1s) → 总结回复(2s) = 5s
多Agent：规划(3s) + max(子Agent×3)(4s) + 汇总(3s) + 通信(1s) = 11s

判断标准：如果你的场景是面向用户的实时交互（聊天机器人、客服系统），延迟预算通常在 5 秒以内。这种场景下多Agent几乎一定会超时，单Agent + 工具调用是更务实的选择。如果是后台批处理任务（代码审计、报告生成），延迟预算宽松，多Agent才有发挥空间。

2.4 第四把尺子：Token 预算能不能扛得住？

多Agent系统的 Token 消耗不是线性增长，而是阶梯式跳涨。

每一次 Agent 调用，你都要支付：

• 系统 Prompt（每次都一样，但每次都要算钱）
• 上下文注入（任务描述、历史信息）
• 模型推理（输出 token）

假设你有一个主控 Agent + 5 个子 Agent，每个 Agent 的系统 Prompt 是 2000 token，任务描述平均 1000 token，输出平均 1500 token。那么一轮完整执行的 Token 消耗大约是：

1
2
3
4

主控：2000 + 1000 + 1500 = 4500
子Agent×5：(2000 + 1000 + 1500) × 5 = 22500
汇总：2000 + 3000(子Agent结果) + 2000 = 7000
总计：约 34000 token

而单Agent完成同样任务，可能只需要 5000-8000 token。

判断标准：如果你的系统要处理高并发请求（比如每秒几百个），Token 成本的差异会被放大几百倍。在做架构选型时，先算一笔账：多Agent方案的 Token 成本是单Agent的几倍？这个倍数你的预算扛不扛得住？

三、四个典型场景的决策推演

光讲理论不过瘾，我们拿四个真实场景来跑一遍决策流程。

3.1 场景一：智能客服（结论：单Agent）

用户问：”我的订单 #12345 退款到哪一步了？”

依赖图分析：识别意图 → 查订单 → 回复。严格线性，没有并行空间。

上下文分析：一次对话的上下文很小，远不到窗口极限。

延迟分析：用户在等回复，延迟预算 3 秒。

Token 分析：高并发场景（成千上万用户同时咨询），成本敏感。

四把尺子量完，全部指向单Agent。上多Agent就是过度设计。

3.2 场景二：企业级代码安全审计（结论：多Agent）

需求：扫描一个 10 万行代码仓库，输出安全漏洞报告。

依赖图分析：注入扫描、内存泄漏检测、依赖漏洞检查、代码规范审查——四个子任务完全独立。

上下文分析：10 万行代码远超单模型窗口，必须切片。

延迟分析：后台批处理，用户可以等几分钟，延迟预算宽松。

Token 分析：低并发（一天可能就跑几次），成本可控。

四把尺子量完，全部指向多Agent。

3.3 场景三：长文档摘要生成（结论：伪多Agent / 单Agent + 分段策略）

需求：把一份 200 页的技术文档浓缩成 5 页摘要。

乍一看，200 页文档肯定塞不进上下文，应该用多Agent切分对吧？

但仔细想想：文档摘要是有全局连贯性要求的。你不能让 Agent-A 总结第 1-50 页、Agent-B 总结第 51-100 页，然后拼在一起——这样出来的摘要会有大量重复、遗漏和逻辑断裂。

更好的方案是单Agent + 分段迭代策略：

1
2
3
4

第一轮：单Agent处理第1-50页，产出中间摘要A
第二轮：单Agent带着摘要A处理第51-100页，产出中间摘要B
第三轮：单Agent带着摘要B处理第101-150页，产出中间摘要C
第四轮：单Agent带着摘要C处理第151-200页，产出最终摘要

每一轮都保留了前序上下文的精华，保证了连贯性。这比多Agent并行切分效果好得多。

教训：上下文超限不等于必须上多Agent。有时候串行分段 + 状态传递比并行切分更适合有连贯性要求的任务。

3.4 场景四：多语言翻译流水线（结论：看情况）

需求：把一份技术文档翻译成英、日、韩三种语言。

表面分析：三种语言互不依赖，可以并行——看起来应该用多Agent。

深层分析：翻译的前置步骤（术语提取、风格统一）是共享的。如果三个 Agent 各自提取术语，出来的译文风格会不一致。

最优方案：混合架构。

1
2
3

阶段一（单Agent）：提取术语表 + 定义翻译风格指南
阶段二（多Agent并行）：三个Agent分别翻译三种语言，共享术语表
阶段三（单Agent）：审校三份译文的一致性

教训：很多任务不是纯粹的”该用”或”不该用”多Agent，而是在流水线的某些阶段用、某些阶段不用。混合架构才是最常见的生产形态。

四、怎么评估一个多Agent系统设计得好不好？

选对了场景只是第一步。就算你决策正确，多Agent系统仍然可能设计得很烂。下面是一套评估框架，从五个维度给系统打分。

4.1 评估维度一：任务分解的合理性

这是最基础也最关键的维度。分解不合理，后面的一切都是空中楼阁。

好的分解有三个特征：

快速检验法：拿一张纸，把每个子Agent的任务写下来。如果你发现两个子Agent的任务描述有超过 30% 的重叠，分解就有问题。

4.2 评估维度二：通信开销占比

多Agent系统的总成本 = 计算成本 + 通信成本。

通信成本包括：

• 主控 Agent 向子 Agent 传递任务描述的 Token
• 子 Agent 向主控 Agent 返回结果的 Token
• 主控 Agent 汇总所有结果的 Token
• 如果子 Agent 之间需要通信（不推荐），还有交叉通信的 Token

健康的系统：通信开销占总 Token 消耗的 20% 以内。

有问题的系统：通信开销超过 40%。这意味着你在花大量 Token 让 Agent 之间”传纸条”，而不是干实事。

计算公式：

1

通信开销占比 = (任务传递Token + 结果回传Token + 汇总Token) / 总Token消耗 × 100%

如果你算出来这个比例很高，说明要么子任务拆得太碎（太多小Agent在传话），要么结果压缩做得不好（子Agent带回来的信息太冗余）。

4.3 评估维度三：并行效率

多Agent的核心价值是并行。如果并行效率低，用多Agent就没有意义。

并行效率的定义：

1

并行效率 = 单Agent串行完成时间 / 多Agent并行完成时间

理论上，N 个 Agent 并行，效率应该接近 N。但实际上很难达到，因为：

• 子 Agent 的任务量不均衡（最慢的那个决定了总时间）
• 主控 Agent 的规划和汇总有固定延迟
• 通信有网络开销

提升并行效率的关键：让每个子 Agent 的工作量尽量均衡。如果一个子 Agent 1 秒就跑完了，另一个要跑 10 秒，那你的并行效率就被拖后腿了。

4.4 评估维度四：容错与可观测性

这是工程落地时最容易翻车的维度。

容错能力评估清单：

• 一个子 Agent 超时或失败了，系统会怎样？是直接整体失败，还是能降级处理？
• 子 Agent 返回了错误结果（幻觉），主控 Agent 能不能识别出来？
• 有没有设置最大重试次数？重试的 Token 成本有没有上限？

可观测性评估清单：

• 出了问题，你能在日志里定位到是哪个 Agent 在哪个环节出错的吗？
• 每个 Agent 的输入输出有没有完整记录？
• 你能不能回放一次完整的执行过程来做 Debug？

一个残酷的现实：大部分多Agent系统的日志都是一团浆糊。主控 Agent 调了 5 个子 Agent，每个子 Agent 又调了若干工具，出了问题你只能看到一个笼统的”执行失败”，根本不知道是哪一步在胡说八道。

好的设计：给每个 Agent 执行分配一个唯一的 trace ID，所有日志都带上这个 ID，方便链路追踪。

4.5 评估维度五：边际收益递减点

这是最需要工程直觉的一个维度。

多Agent系统的子 Agent 数量不是越多越好。存在一个边际收益递减点——超过这个点，增加 Agent 带来的并行收益小于增加的通信开销和协调成本。

1
2
3
4
5
6
7
8
9
10

    收益
     ↑
     │        ╭───────── 收益曲线
     │      ╱
     │    ╱
     │  ╱
     │╱
     ├──────────────────→ Agent数量
     ↑
边际收益递减点

经验值：在大部分场景下，子 Agent 数量控制在 3-8 个是比较合理的区间。超过 10 个，协调成本会急剧上升。

怎么找到这个点？ 最靠谱的方法是跑基准测试：

1. 从 2 个子 Agent 开始，记录执行时间和 Token 消耗
2. 逐步增加到 3、4、5… 个
3. 画出”Agent数量 vs 端到端延迟”和”Agent数量 vs Token成本”两条曲线
4. 找到延迟不再显著下降、但 Token 成本还在上升的那个拐点

那个拐点就是你的最优 Agent 数量。

五、一个完整的评估 Checklist

把上面五个维度浓缩成一份可执行的检查清单。拿到任何一套多Agent系统设计方案，对照这张表打分：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

任务分解合理性                          □ 通过  □ 不通过
├─ 子任务之间是否低耦合？               □ 是    □ 否
├─ 粒度是否适中？                       □ 是    □ 否
└─ 边界是否清晰？                       □ 是    □ 否

通信开销占比                            □ 通过  □ 不通过
├─ 通信Token占比 < 20%？               □ 是    □ 否
└─ 子Agent结果是否经过压缩？            □ 是    □ 否

并行效率                                □ 通过  □ 不通过
├─ 并行加速比 > 1.5x？                 □ 是    □ 否
└─ 子Agent工作量是否均衡？              □ 是    □ 否

容错与可观测性                          □ 通过  □ 不通过
├─ 子Agent失败是否可降级？              □ 是    □ 否
├─ 每个Agent是否有trace ID？            □ 是    □ 否
└─ 能否回放完整执行过程？               □ 是    □ 否

边际收益                                □ 通过  □ 不通过
├─ 子Agent数量是否在合理区间(3-8)？     □ 是    □ 否
└─ 是否做过基准测试找最优解？           □ 是    □ 否

5 个维度全部通过，这是一套合格的多Agent系统设计。有 1-2 个不通过，需要针对性优化。3 个以上不通过——回去重新考虑一下，这个场景是不是真的需要多Agent。

六、总结

回到文章开头的问题：什么场景下用多Agent系统？

答案不是”任务越复杂越好”，而是当你同时撞上了两个天花板时：

1. 单一模型的上下文天花板——数据量大到一个模型吃不下
2. 串行执行的延迟天花板——子任务之间没有依赖，串行跑太慢

只撞上第一个天花板，用单Agent + 分段策略就能解决。只撞上第二个天花板，用单Agent + 异步并发工具调用也能凑合。两个同时撞上，才是多Agent真正不可替代的场景。

而在评估一套多Agent系统设计时，不要只看架构图好不好看，要拿数据说话：通信开销占比多少？并行效率多少？边际收益递减点在哪？

用工程的刚性去约束架构的浪漫，这才是做系统设计的正确姿势。

如果你在构建 Agent，一定想过这个问题：怎么让 Agent 跨会话记住用户的偏好、项目的背景、之前犯过的错误？大部分人的做法是搞一个文件，把所有「需要记住的东西」往里塞。文件越来越大，token 成本越来越高，而且大部分内容跟当前对话根本没关系。Claude Code 的记忆系统给出了一个反直觉的设计原则：工程量最大的部分不是「怎么存」，也不是「怎么取」，而是「什么该存、什么不该存」。

一、核心哲学：记忆是代码的补集

这套记忆系统的设计哲学可以用一句话概括：

记忆是代码的补集。

听起来简单，但这是整个设计里最有启发性的原则。具体来说：

该存的：全部是「关于人和上下文」的信息——人的偏好、纠正、动机、外部资源指针。这些藏在代码之外，不查记忆就无从得知。

不该存的：全部是「关于代码和项目状态」的信息——代码是实时的、可查的、权威的。代码能回答的问题，不要让记忆来回答。

这个分界线一旦清晰，你会发现很多之前觉得「应该记住」的东西，其实根本不该存。

二、四种该存的记忆

2.1 用户记忆：记用户是谁

用户记忆记录的是用户的角色、技术背景、工作习惯、知识水平。

好的例子：

「这个用户是数据科学家，目前在做日志系统的调研。」

「这个用户写了十年 Go，但第一次碰 React。」

这类记忆的设计意图是让 Agent 能调整沟通方式和工作策略。面对一个资深后端工程师，Agent 不需要解释基础概念，可以直接用技术术语；面对一个初学者，Agent 需要更耐心地铺垫背景。

关键约束：记忆的目的是「怎么更好地帮这个人」，不是「给这个人画像」。不要记录对用户的负面评价，也不要记录跟工作无关的个人信息。

1
2
3

❌ 不要记：「这个用户脾气不好，经常发火」
❌ 不要记：「这个用户喜欢喝咖啡」
✅ 要记：「这个用户偏好简洁回复，不需要末尾总结」

2.2 反馈记忆：记纠正和肯定

这是四种记忆里设计最精细的一种。源码里对它有三个关键要求。

要求一：规则 + 原因 + 适用场景

每条反馈记忆必须包含三个部分：

1

规则是什么 → Why → 什么时候该应用

举个实际例子。用户说：

「测试不要 mock 数据库，上个季度我们就是因为 mock 测试通过了但生产环境迁移失败才出的事故。」

如果只记「不要 mock 数据库」，Agent 在所有测试里都不敢 mock，包括那些跟数据库迁移完全无关的单元测试。

但如果它知道原因是「mock 和生产环境行为不一致导致迁移失败」，它就能判断：集成测试不该 mock，但纯逻辑的单元测试 mock 是没问题的。

记原因，是为了让 Agent 能在新场景下做判断，而不是机械地执行规则。

要求二：不要只记纠正，也要记肯定

源码注释里说得很直白：

如果你只记录用户说「不要这样做」的时刻，它只知道什么是错的，不知道什么是对的。时间长了，它会回避一切不确定的做法，变得畏手畏脚。

但肯定信号比纠正信号更难捕捉。用户说「不要这样做」很明显，但用户说「对，就是这样」或者默默接受了一个不寻常的方案，需要主动注意这些肯定信号。

例子：

用户说：「对，这次用一个大 PR 是对的，拆开反而是无意义的工作量。」

这条记忆的价值是：下次遇到类似的重构场景，Agent 知道这个用户倾向于合并提交，而不是拆成很多小 PR。这不是纠正，是一个被验证过的判断。

要求三：区分个人偏好和项目规范

「不要在回复末尾加总结」→ 个人偏好，只对这个用户有效

「集成测试必须用真实数据库」→ 项目规范，对所有协作者有效

源码里用 scope 来区分这两种。个人偏好存在私有目录，项目规范存在团队共享目录。

2.3 项目记忆：记正在发生什么

项目记忆记录的是当前项目里正在发生的事：谁在做什么、为什么要做、截止日期是什么。

例子：

「本周四之后冻结所有非关键合并，移动端团队要切发布分支。」

「正在重写认证中间件，原因是法务团队指出旧的 token 存储方式不符合合规要求，所以做决策的时候要优先考虑合规性而不是技术优雅。」

关键规则：相对日期必须转换成绝对日期

用户说「周四冻结」，记忆里存的是具体的年月日，比如「2026-03-07」。

为什么？因为记忆是跨会话的。如果存「周四」，下周再看这条记忆就不知道是哪个周四了。

另一个特点：衰减得很快

一个月前的项目状态大概率已经过时了。所以源码要求项目记忆必须记录「为什么」。即使事实过时了，背后的动机仍然有参考价值。

1
2

事实过时：「正在重写认证中间件」→ 可能已经写完了
动机仍有效：「合规要求优先于技术优雅」→ 这个决策原则长期有效

2.4 引用记忆：记外部资源在哪里

引用记忆记录的是外部资源的位置：bug 在哪个系统里追踪、监控面板的地址是什么、设计文档在哪个平台。

例子：

「流水线相关的 bug 都在 Linear 的 INGEST 项目里追踪。」

「API 延迟的监控面板在 grafana.internal/d/api-latency，值班的时候看这个。」

这是四种里最简单的，但也是最实用的。它本质上是一个「去哪里找信息」的索引。

三、五种不该存的东西

这部分才是整个设计里最有启发性的。很多人做记忆系统的第一件事，就是把不该存的东西全存了。

3.1 代码模式、架构、文件路径、项目结构

这是最反直觉的。很多人觉得 Agent 应该记住「项目用了什么框架、目录怎么组织、哪个文件负责什么」。

Claude Code 说：不要存这些。

为什么？因为这些信息可以直接从代码里读出来。Agent 随时可以通过读代码和搜索来获取当前的项目结构。

把这些存进记忆有两个问题：

1
2
3
4
5

问题一：浪费空间
每次对话都要加载一堆本来可以实时查的信息

问题二：过时风险
代码改了但记忆没更新 → Agent 基于过时信息决策 → 很难发现

背后的原则：如果一个信息可以从当前项目状态推导出来，就不要存进记忆。记忆只存那些「看代码看不出来」的东西。

3.2 版本管理历史

谁改了什么、最近的提交记录——这些用版本管理工具查就行了。

Git 是实时的、权威的，不需要记忆来存一份可能过时的副本。

3.3 调试方案和修复方法

修复已经在代码里了，提交信息里有上下文。存「怎么修的」没有意义，因为代码本身就是最好的参考。

3.4 配置文件里已经写过的东西

如果你的项目里有 CLAUDE.md 或其他配置文件已经定义了编码规范，记忆系统不需要再存一份。

重复存储不仅浪费空间，还会在两份内容不一致的时候制造混乱。

1
2
3

配置文件说：「使用 pnpm」
记忆文件说：「使用 npm」
→ Agent 该听谁的？

3.5 临时性的任务细节

当前正在做什么、对话里的中间状态——这些是短期的，属于当前会话的上下文，不该进入长期记忆。

四、一条特别重要的规则

即使用户明确要求你记住某些东西，如果它属于上面五类，也不该记。

例子：

用户：「记住这周的 PR 列表」

Agent 不应该直接存 PR 列表，而应该反问：

「这些 PR 里有什么让你意外的或者不明显的？那个部分才值得记。」

活动日志不是记忆，从活动中提炼出的洞察才是。

用户要求存不该存的内容时，正确的做法是提炼价值点。PR 列表本身不该存，但如果某个 PR 的处理方式让用户觉得「这样做是对的」，那个判断才值得存成反馈记忆。

五、信息来源决策树

把上面的原则整理成一个判断流程：

1
2
3
4
5
6
7
8
9
10

这条信息能从代码/工具实时获取吗？
         │
         ├── 能 → 不存，实时查
         │
         └── 不能 → 属于哪种类型？
                         │
                         ├── 用户特征 → 用户记忆
                         ├── 纠正/肯定 → 反馈记忆
                         ├── 项目动态 → 项目记忆
                         └── 外部资源 → 引用记忆

六、实践中的常见错误

错误一：把记忆当成项目文档

1
2

❌ 存储：「src/auth 目录负责认证逻辑，包含 middleware.ts 和 token.ts」
✅ 实时查：Glob + Read 工具

错误二：把记忆当成聊天记录

1
2

❌ 存储：「用户昨天问怎么配置 Redis，我回答了...」
✅ 不存：这是会话上下文，不是长期记忆

错误三：记了规则但没记原因

1
2
3

❌ 存储：「不要用 forEach」
✅ 存储：「避免在 async 函数里用 forEach，原因是 forEach 不等待 Promise 完成，
         曾导致批量写入只执行了一半，适用场景是异步批量操作」

错误四：只记纠正不记肯定

1
2

❌ 只存：「不要在回复末尾加总结」
✅ 也要存：「用户确认：重构时用一个大PR是对的，拆开反而增加工作量」

七、记忆系统的质量检验清单

在写入一条记忆之前，问自己这些问题：

1
2
3
4
5
6

□ 是否存了代码可查的内容？→ 删除或反问用户
□ 是否包含「为什么」？→ 补充动机
□ 是否指定适用范围？→ 补充项目/模块边界
□ 相对时间是否转绝对时间？→ 如「明天」→「2026-03-16」
□ 是否存在相似记忆？→ 合并去重
□ 敏感信息是否过滤？→ 拒绝存储密码、密钥、PII

八、总结

Claude Code 记忆系统的核心设计可以概括为一句话：少而精。

记忆的价值不在于数量，而在于每条记忆都能在关键时刻减少认知负担。

如果你在给自己的 Agent 做记忆系统，这个分类框架可以直接拿来用：

四种该存：

• 用户是谁（角色、背景、习惯）
• 用户纠正和肯定过什么（含规则、原因、适用场景）
• 项目背后的动机和时间线（相对日期→绝对日期）
• 外部资源在哪里（索引而非内容）

五种不该存：

• 代码能告诉你的一切
• 版本历史能告诉你的一切
• 提交记录能告诉你的一切
• 配置文件已经说过的一切
• 临时性的中间状态

这样做的好处是：你的记忆文件会非常精简，每一条都是高价值的、代码里找不到的信息。模型每次加载记忆的时候，看到的全是有用的东西，没有噪声。

相关文章：

• Memory 系统：跨会话持久化知识库 — Claude Code 记忆系统的技术实现细节
• Claude Code 源码深度解析系列 — 更多 Claude Code 架构分析

背景

2026年4月24日，DeepSeek 正式发布了 V4 系列模型。这不是一次普通的版本迭代——它解决了一个困扰 AI 行业多年的根本问题：长上下文的效率瓶颈。

本文将深入解读 DeepSeek V4 的核心技术创新，帮助你理解这次发布为何值得关注。

一、模型规格：更大但不更贵

DeepSeek V4 发布了两个版本：

对比上一代 V3.2（671B 总参数，37B 激活），V4-Pro 参数量翻了 2.4 倍，但激活参数仅增加 32%。更重要的是，两者都原生支持 100万 token 上下文——这是之前任何开源模型都做不到的。

为什么”更大但不更贵”？

得益于 MoE（Mixture-of-Experts）架构，每次推理只激活一小部分参数。V4-Pro 的激活率仅为 3%（49B/1.6T），这意味着：

• 推理成本接近一个 50B 参数的稠密模型
• 但拥有 1.6T 参数的知识容量和表达能力

这是 DeepSeek 从 V2 开始就坚持的技术路线，V4 把这个策略推向了新高度。

二、核心架构创新：打破 O(n²) 的魔咒

Transformer 的标准注意力机制计算复杂度是 O(n²)——序列长度翻倍，计算量翻四倍。当上下文达到百万级别时，这变成了不可承受之重。

DeepSeek V4 用混合注意力架构彻底解决了这个问题。

2.1 CSA（Compressed Sparse Attention）

CSA 的核心思路是：压缩 + 稀疏选择。

1
2
3
4
5

原始序列：n 个 token
     ↓ 压缩（每 m 个 token 合成一个 KV entry）
压缩序列：n/m 个 compressed KV entry
     ↓ 稀疏选择（Lightning Indexer 选 top-k）
参与计算的：k 个 compressed KV entry

具体流程：

1. KV Cache 压缩：将每 m 个 token 的 KV entry 通过加权聚合压缩成一个条目，序列长度降到 1/m
2. Lightning Indexer：为每个 query token 生成 indexer queries，与压缩后的 KV 偂相似度计算，选出 top-k 个最相关的压缩块
3. Core Attention：只在选出的 k 个压缩块上做完整的 attention 计算

关键参数（V4-Pro）：

• 压缩率 m = 4（每 4 个 token 压缩成 1 个）
• Indexer head 数 = 64，head 维度 = 128
• Top-k = 1024（每个 query 只关注 1024 个压缩块）

2.2 HCA（Heavily Compressed Attention）

HCA 是更激进的压缩策略，用于处理”不需要精细关注的历史信息”：

1
2
3

压缩率 m' = 128（每 128 个 token 合成一个 KV entry）
     ↓
直接对压缩后的 KV 做完整 attention（不做稀疏选择）

HCA 的哲学是：远处的信息可以”模糊处理”，近处的信息才需要精细关注。

2.3 混合架构设计

V4 不是全用 CSA 或全用 HCA，而是交替使用：

• 前 2 层：纯滑动窗口 attention（保留近期信息的精细度）
• 后续层：CSA 和 HCA 交替，形成”粗细结合”的信息处理

这种设计让模型既能高效处理长上下文，又能保持对关键信息的精确检索能力。

2.4 效率提升有多夸张？

官方给出了硬核数据（100万 token 上下文场景）：

这意味着：以前跑不起的百万级上下文任务，现在可以在单卡上跑了。

三、mHC：残差连接的”数学升级版”

残差连接 x + F(x) 是 Transformer 的基石，但深层堆叠时会遇到问题：

• 信号可能逐层放大 → 数值爆炸
• 信号可能逐层衰减 →梯度消失

DeepSeek V4 引入了 Manifold-Constrained Hyper-Connections (mHC)，用数学约束解决这个问题。

核心思路

传统残差连接：

1

X_next = X + F(X)  // 简单加法

mHC：

1
2
3

X_next = B·X + C·F(A·X)  // A、B、C 是线性映射矩阵
         ↑
      B 约束在双随机矩阵流形上（行和=1，列和=1，元素≥0）

关键约束：B 的谱范数 ≤ 1，这意味着信号传播是”非膨胀的”，不会爆炸。

为什么叫”流形约束”？

双随机矩阵构成的空间是一个流形（Manifold）——Birkhoff Polytope。mHC 通过 Sinkhorn-Knopp 算法，把矩阵 B 投影到这个流形上：

1
2
3

1. 对 B 取 exponential（保证正元素）
2. 迭代做行归一化、列归一化
3. 收敛到一个双随机矩阵

这套数学确保了深层堆叠时的稳定性，同时保留了模型的表达能力。

四、Muon 优化器：万亿参数训练的新配方

训练万亿参数模型，AdamW 已经不够稳了。V4 引入了 Muon 优化器。

核心算法

1
2
3
4
5

G = gradient
M = momentum_buffer
M = μ·M + G  // 动量累积
O = HybridNewtonSchulz(μ·M + G)  // Nesterov trick + 正交化
W = W·(1 - ηλ) - η·O  // weight decay + update

关键步骤是 Hybrid Newton-Schulz 迭代，把梯度矩阵正交化：

1
2
3
4
5
6

# 10 步迭代，分两阶段
# Stage 1（前 8 步）：快速收敛
M_k = 3.4445·M_{k-1} - 4.7750·(M·M^T)·M + 2.0315·(M·M^T)^2·M

# Stage 2（后 2 步）：精确定位到正交矩阵
M_k = 2·M_{k-1} - 1.5·(M·M^T)·M + 0.5·(M·M^T)^2·M

正交化的好处：

• 避免”跑偏”——梯度方向更明确
• 避免”数值爆炸”——矩阵谱范数被约束
• 收敛更快——不需要 Adam 的二阶矩估计

配合稳定性技术

V4 还用了两招来防止 loss spike：

1. Anticipatory Routing：路由决策用”历史参数”而非”当前参数”，打破 MoE 路由的恶性循环
2. SwiGLU Clamping：把 SwiGLU 的线性分量 clamp 到 [-10, 10]，直接压制异常值

五、FP4 量化感知训练：天生适应低精度

以往的量化是”训练后补救”——模型在高精度下训练，推理时强行降精度，性能必然下降。

V4 的创新：训练时就让模型适应 FP4。

应用范围

• MoE 专家权重：占模型大部分参数，FP4 压缩节省大量显存
• QK 路径（Lightning Indexer 的 indexer 部分）：长上下文检索的核心计算，FP4 加速

关键技术点

FP4 → FP8 的无损反量化：

1
2
3
4

FP4 (E2M1) → FP8 (E4M3)
          ↑
FP8 多 2 个 exponent bit，动态范围更大
只要 block 内的 scale factor 差异不超过阈值，信息完全保留

这意味着：

• 训练时用 FP8 做计算（模拟 FP4）
• 推理时直接用 FP4 权重，零性能损失
• 整个 pipeline 可以复用现有的 FP8 训练框架

六、训练基础设施：工程硬核

V4 的基础设施投入展现了”长期主义”的工程思维。

6.1 TileLang：Kernel 开发的 DSL

传统 CUDA Kernel 开发效率低、难迭代。V4 用 TileLang 这个 DSL：

• 用声明式语法描述 Kernel 逻辑
• Z3 SMT Solver 做形式化分析（证明正确性）
• 自动生成高性能 CUDA 代码

开发效率 + 运行效率，两者兼得。

6.2 确定性训练

V4 的 Kernel 全程批不变（Batch-Invariant）：

• 同一 token 无论在 batch 哪个位置，输出 bitwise 一致
• 用特殊设计避免了原子加法带来的不确定性
• 训练过程可复现，调试有据可查

这对大规模训练调试、定位问题至关重要。

6.3 MoE EP 的细粒度重叠

Expert Parallelism 的通信开销大。V4 把 MoE 层拆成 4 个阶段：

1

Dispatch (通信) → Linear-1 (计算) → Activation → Linear-2 (计算) → Combine (通信)

关键洞察：计算时间 > 通信时间，所以通信可以被计算掩盖。

V4 把专家分成”wave”，每个 wave 的通信和计算流水线化，实现 1.5-1.96× 加速。

七、性能基准：开源模型的新标杆

知识任务

V4-Pro-Max 在知识任务上领先开源对手 20+ 百分点，但距离 Gemini 3.1 Pro 还有一段差距。

Agent 能力：开源最佳

这是 V4 最重要的能力跃升之一。官方披露：

• Agentic Coding：V4-Pro 达到当前开源模型最佳水平
• 内部实测：已成为 DeepSeek 公司内部员工使用的 Agentic Coding 首选模型
• 体验对比：优于 Claude Sonnet 4.5，交付质量接近 Claude Opus 4.6 非思考模式

V4 针对 Claude Code、OpenClaw、OpenCode、CodeBuddy 等主流 Agent 产品进行了专项适配优化，在代码任务、文档生成等场景表现显著提升。

推理与代码

这是开源模型首次在代码竞赛上追平闭源模型。V4-Pro-Max 在 Codeforces 排名第 23 位（人类选手中）。

长上下文

V4-Pro 在真实场景的 CorpusQA 上超越 Gemini 3.1 Pro，在 MRCR 上接近 Claude Opus 4.6。

八、V4-Flash：经济高效的选择

V4-Flash 是一个重要的补充版本，让不同需求的用户都能找到合适的方案。

与 V4-Pro 的对比

适用场景：

• V4-Flash：日常对话、简单代码任务、成本敏感场景
• V4-Pro：复杂 Agent 任务、深度推理、高质量输出需求

九、三种推理模式：灵活的推理成本

V4 支持三种推理模式，让用户按需求选择成本：

Think Max 模式会在系统 prompt 里注入特殊指令：

1
2

Reasoning Effort: Absolute maximum with no shortcuts permitted.
You MUST be very thorough in your thinking...

这让模型”把推理推到极限”，在 HLE、IMO 等高难度任务上表现最优。

十、API 使用指南

模型调用

DeepSeek API 已同步上线 V4-Pro 与 V4-Flash，支持 OpenAI ChatCompletions 接口与 Anthropic 接口：

1
2
3
4
5
6
7
8
9
10
11
12

# OpenAI 格式
from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://api.deepseek.com"
)

response = client.chat.completions.create(
    model="deepseek-v4-pro",  # 或 deepseek-v4-flash
    messages=[{"role": "user", "content": "你好"}]
)

关键参数

思考模式

对于复杂的 Agent 场景，建议使用思考模式并设置强度为 max：

1
2
3
4
5

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[{"role": "user", "content": "复杂任务..."}],
    reasoning_effort="max"  # 极限推理
)

⚠️ 重要提示

旧 API 模型名 deepseek-chat 和 deepseek-reasoner 将于 2026年7月24日 停止使用：

• 当前阶段 deepseek-chat → 指向 V4-Flash 非思考模式
• 当前阶段 deepseek-reasoner → 指向 V4-Flash 思考模式

请尽快迁移到新的模型名称。

十一、开源与本地部署

权重下载

本地部署建议

由于 V4-Pro 参数量达 1.6T，本地部署需要：

• 多卡推理：至少 8× A100 80GB 或同等显存
• 量化推理：FP4 量化后可显著降低显存需求
• V4-Flash：单卡 A100 80GB 可运行

技术报告

完整技术细节请参考官方技术报告：

• DeepSeek V4 技术报告（PDF）

十二、行业启示：V4 带来的新范式

12.1 长上下文不再是奢侈品

以前，百万级上下文是”理论上可行但经济上不行”。V4 把成本降到 原来的 10-30%，让以下场景变得可行：

• Test-time Scaling：推理阶段可以长时间思考，不受上下文限制
• 长 horizon Agent：复杂多轮任务（如软件工程流水线）有足够”记忆空间”
• 在线学习：持续吸收新信息，无需全量重训练

12.2 开源 vs 闭源的格局变化

V4 是一个信号：开源模型不仅追上了能力，还追上了效率性价比。

• V4-Flash 用 13B 激活参数，就能达到接近 GPT-5.2 的推理水平
• 在代码任务上，开源首次追平闭源

这意味着闭源模型的”护城河”正在缩小。

12.3 架构创新的长期价值

V4 的创新不是”刷榜技巧”，而是架构层面的根本改进：

• CSA/HCA 解决了 Transformer 的 O(n²) 瓶颈
• mHC 让残差连接更稳定、可堆叠更深
• Muon 优化器可能成为万亿参数训练的新标配

这些创新会启发更多研究，推动整个行业向前。

十三、局限与展望

官方坦承了几个局限：

1. 架构相对复杂：为了降低风险，保留了 V3 的很多验证过的组件，未来会精简
2. 训练稳定性原理未完全理解：Anticipatory Routing 和 SwiGLU Clamping 有效，但数学原理还在探索
3. 多模态尚未集成：未来版本会加入视觉能力

展望方向：

• 进一步的稀疏化探索（如稀疏 embedding）
• 低延迟架构优化（让长上下文交互更流畅）
• 长 horizon Agent 的深度优化

总结

DeepSeek V4 的意义不在于某个具体指标的提升，而在于它解决了长上下文效率这个根本问题。

通过 CSA/HCA 混合注意力、mHC 残差升级、Muon 优化器、FP4 量化训练等一系列创新，V4 让百万级上下文从”理论上可行”变成”经济上可行”。

这为 AI 的下一阶段——更深的 test-time scaling、更长的 Agent 任务、更灵活的在线学习——铺好了基础设施。

开源模型第一次在效率和能力的综合维度上，追上了闭源前沿。这是整个行业值得关注的里程碑。

参考资源：

• DeepSeek V4 技术报告（PDF）
• 模型权重（HuggingFace）

阿里云百炼 Coding Plan 官方宣称”仅限编程工具使用”，但实际上其 endpoint 基于 OpenAI 兼容协议，Java/Python 应用完全可以调用。本文分享如何用 LangChain4j 和 OpenAI SDK 突破这一限制，直接消耗 Coding Plan 额度。

一、背景：一个被”误解”的服务

阿里云百炼的 Coding Plan 是一项面向 AI 编程助手的服务套餐，提供专门的模型调用额度。官方客服的说法是：

“Coding Plan 的专属 API Key（格式为 sk-sp-xxxxx）仅限在支持的编程工具（如 Claude Code、OpenClaw 等）中使用，不能用于 Java 应用直接调用大模型。若您的 Java 应用需要调用百炼大模型，请使用百炼通用 API Key（格式为 sk-xxxxx），该 Key 支持调用包括 Coding 模型在内的所有百炼模型，并按量计费。”

这意味着如果你想在 Java 应用中使用百炼大模型，需要：

1. 额外开通百炼通用 API Key（格式为 sk-xxxxx）
2. 按量付费，产生额外费用

但实际上，Coding Plan 的额度完全可以在 Java/Python 应用中使用！ 本文将分享这个”奇技淫巧”。

二、问题发现：为什么 Coding Plan Key 在 Java 中”失效”？

2.1 错误的调用方式

很多开发者（包括我）最初使用阿里云官方的 dashscope-sdk-java 调用百炼：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// pom.xml
<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>dashscope-sdk-java</artifactId>
    <version>2.22.15</version>
</dependency>

// Java 代码
Generation gen = new Generation();
GenerationParam param = GenerationParam.builder()
    .apiKey("sk-sp-xxxxx")  // Coding Plan API Key
    .model("qwen-plus")
    .messages(messages)
    .build();
GenerationResult result = gen.call(param);

结果：API 返回 InvalidApiKey 错误，或者即使调通了，消耗的是通用额度而非 Coding Plan 额度！

2.2 根本原因分析

Coding Plan 的 API Key 使用的是 OpenAI 兼容协议，endpoint 地址不同于通用百炼服务：

官方的 dashscope-sdk-java 只支持通用百炼 endpoint，无法连接 Coding Plan 的 endpoint！

三、解决方案：使用 OpenAI 兼容模式

3.1 技术原理

Coding Plan 的 endpoint 基于 OpenAI API 兼容协议，任何支持 OpenAI API 的客户端都可以调用：

1. Python: 使用 openai SDK
2. Java: 使用 LangChain4j 的 langchain4j-open-ai 模块

只要将 base_url 指向 Coding Plan 的 endpoint，API Key 就能正常工作！

四、Java 实现：LangChain4j + Coding Plan

4.1 添加依赖

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<!-- pom.xml -->
<properties>
    <langchain4j.version>0.35.0</langchain4j.version>
</properties>

<dependencies>
    <!-- LangChain4j OpenAI 兼容模块 -->
    <dependency>
        <groupId>dev.langchain4j</groupId>
        <artifactId>langchain4j</artifactId>
        <version>${langchain4j.version}</version>
    </dependency>
    <dependency>
        <groupId>dev.langchain4j</groupId>
        <artifactId>langchain4j-open-ai</artifactId>
        <version>${langchain4j.version}</version>
    </dependency>
</dependencies>

4.2 配置文件

1
2
3
4
5
6

# application.properties - Coding Plan 配置
langchain4j.open-ai.chat-model.base-url=https://coding.dashscope.aliyuncs.com/v1
langchain4j.open-ai.chat-model.api-key=sk-sp-xxxxx
langchain4j.open-ai.chat-model.model-name=kimi-k2.5
langchain4j.open-ai.chat-model.temperature=0.3
langchain4j.open-ai.chat-model.max-tokens=4096

关键点：base-url 必须是 coding.dashscope.aliyuncs.com/v1，不是通用的 dashscope.aliyuncs.com！

4.3 Java 代码实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

import dev.langchain4j.data.message.AiMessage;
import dev.langchain4j.data.message.ChatMessage;
import dev.langchain4j.data.message.SystemMessage;
import dev.langchain4j.data.message.UserMessage;
import dev.langchain4j.model.chat.ChatLanguageModel;
import dev.langchain4j.model.openai.OpenAiChatModel;
import dev.langchain4j.model.output.Response;

import java.time.Duration;
import java.util.Arrays;
import java.util.List;

public class CodingPlanExample {

    private final ChatLanguageModel chatModel;

    public CodingPlanExample(String baseUrl, String apiKey, String modelName) {
        // 使用 OpenAI 兼容模式构建 ChatModel
        this.chatModel = OpenAiChatModel.builder()
                .baseUrl(baseUrl)  // Coding Plan endpoint
                .apiKey(apiKey)    // Coding Plan API Key
                .modelName(modelName)
                .temperature(0.3)
                .maxTokens(4096)
                .timeout(Duration.ofSeconds(60))
                .build();
    }

    public String chat(String systemPrompt, String userMessage) {
        List<ChatMessage> messages = Arrays.asList(
                SystemMessage.from(systemPrompt),
                UserMessage.from(userMessage)
        );

        Response<AiMessage> response = chatModel.generate(messages);

        if (response == null || response.content() == null) {
            throw new RuntimeException("模型返回结果为空");
        }

        return response.content().text();
    }

    public static void main(String[] args) {
        CodingPlanExample example = new CodingPlanExample(
                "https://coding.dashscope.aliyuncs.com/v1",
                "sk-sp-xxxxx",
                "kimi-k2.5"
        );

        String result = example.chat(
                "你是一位专业的翻译助手",
                "将以下内容翻译为英文：你好世界"
        );

        System.out.println(result);
    }
}

4.4 Spring Boot 集成示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

@Configuration
public class LangChain4jConfig {

    @Value("${langchain4j.open-ai.chat-model.base-url}")
    private String baseUrl;

    @Value("${langchain4j.open-ai.chat-model.api-key}")
    private String apiKey;

    @Value("${langchain4j.open-ai.chat-model.model-name}")
    private String modelName;

    @Bean
    public ChatLanguageModel chatLanguageModel() {
        return OpenAiChatModel.builder()
                .baseUrl(baseUrl)
                .apiKey(apiKey)
                .modelName(modelName)
                .timeout(Duration.ofSeconds(60))
                .build();
    }
}

@Service
public class TranslationService {

    private final ChatLanguageModel chatModel;

    public TranslationService(ChatLanguageModel chatModel) {
        this.chatModel = chatModel;
    }

    public String translate(String content, String sourceLang, String targetLang) {
        String systemPrompt = String.format(
                "你是翻译专家，将内容从%s翻译为%s，直接输出结果",
                sourceLang, targetLang
        );

        List<ChatMessage> messages = Arrays.asList(
                SystemMessage.from(systemPrompt),
                UserMessage.from(content)
        );

        return chatModel.generate(messages).content().text();
    }
}

五、Python 实现：OpenAI SDK + Coding Plan

5.1 安装依赖

1

pip install openai

5.2 Python 代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

from openai import OpenAI

# 使用 Coding Plan endpoint
client = OpenAI(
    base_url="https://coding.dashscope.aliyuncs.com/v1",
    api_key="sk-sp-xxxxx"
)

response = client.chat.completions.create(
    model="kimi-k2.5",
    messages=[
        {"role": "system", "content": "你是一位专业的翻译助手"},
        {"role": "user", "content": "将以下内容翻译为英文：你好世界"}
    ],
    temperature=0.3,
    max_tokens=4096
)

print(response.choices[0].message.content)

5.3 异步调用示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

from openai import AsyncOpenAI
import asyncio

async_client = AsyncOpenAI(
    base_url="https://coding.dashscope.aliyuncs.com/v1",
    api_key="sk-sp-xxxxx"
)

async def translate_async(content: str) -> str:
    response = await async_client.chat.completions.create(
        model="kimi-k2.5",
        messages=[
            {"role": "system", "content": "你是翻译专家"},
            {"role": "user", "content": content}
        ]
    )
    return response.choices[0].message.content

# 批量翻译
async def batch_translate(contents: list[str]) -> list[str]:
    tasks = [translate_async(c) for c in contents]
    return await asyncio.gather(*tasks)

# 运行示例
async def main():
    results = await batch_translate(["你好世界", "人工智能"])
    print(results)

asyncio.run(main())

六、实际应用场景

6.1 职位内容翻译

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

@Service
public class JobTranslationService {

    private final ChatLanguageModel chatModel;

    public String translateJobDescription(String content, String sourceLang, String targetLang) {
        String systemPrompt = buildTranslationPrompt(sourceLang, targetLang);

        List<ChatMessage> messages = Arrays.asList(
                SystemMessage.from(systemPrompt),
                UserMessage.from(content)
        );

        return chatModel.generate(messages).content().text();
    }

    private String buildTranslationPrompt(String sourceLang, String targetLang) {
        return String.format("""
            你是一位专业的职位内容翻译专家。
            请将用户输入的职位描述从%s翻译为%s。

            翻译要求：
            1. 保持原文的段落结构和格式
            2. 专业术语使用行业标准翻译
            3. 直接输出翻译结果
            """, sourceLang, targetLang);
    }
}

6.2 文档内容生成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public String generateDocumentOutline(String topic) {
    String prompt = """
        根据以下主题，生成一份技术文档大纲：
        主题：%s

        要求：
        1. 结构清晰，层次分明
        2. 每个章节要有简要说明
        3. 使用 Markdown 格式输出
        """.formatted(topic);

    List<ChatMessage> messages = Arrays.asList(
        SystemMessage.from("你是技术文档撰写专家"),
        UserMessage.from(prompt)
    );

    return chatModel.generate(messages).content().text();
}

6.3 智能客服对话

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

@Service
public class CustomerServiceBot {

    private final ChatLanguageModel chatModel;

    public String handleUserMessage(String userMessage, List<String> history) {
        List<ChatMessage> messages = new ArrayList<>();

        // 系统提示词
        messages.add(SystemMessage.from("""
            你是专业的客服助手，帮助用户解答产品相关问题。
            回答要求：
            1. 语气友好专业
            2. 回答简洁明了
            3. 如果无法回答，引导用户联系人工客服
            """));

        // 添加历史对话
        for (String h : history) {
            messages.add(UserMessage.from(h));
        }

        // 当前消息
        messages.add(UserMessage.from(userMessage));

        return chatModel.generate(messages).content().text();
    }
}

七、关键注意事项

7.1 Endpoint 不要混用

混用会导致 InvalidApiKey 错误或消耗错误的额度！

7.2 模型名称差异

Coding Plan 支持的模型可能与通用百炼不同：

• Coding Plan: kimi-k2.5 等
• 通用百炼: qwen-plus, qwen-max, qwen-turbo

请根据实际账号支持的模型选择。

7.3 Token 消耗监控

虽然使用了 Coding Plan 额度，但仍需关注：

• 单次调用 Token 数量
• Coding Plan 额度剩余
• 设置合理的 max_tokens 防止超限

7.4 超时设置

Coding Plan 响应时间可能与通用服务不同，建议设置较长超时：

1

.timeout(Duration.ofSeconds(60))  // 或更长

八、总结

8.1 官方说法 vs 实际实践

8.2 核心原理

Coding Plan 的 endpoint 基于 OpenAI API 兼容协议，这是业界通用的 LLM API 标准。任何支持 OpenAI 协议的客户端都可以调用，不受编程工具限制。

8.3 适用场景

• ✅ Java 后端服务调用 LLM
• ✅ Python 应用调用 LLM
• ✅ Spring Boot / LangChain4j 集成
• ✅ 翻译、生成、对话等各类 NLP 任务
• ❌ 直接使用 dashscope-sdk-java（不支持 Coding Plan endpoint）

九、参考资料

• LangChain4j 官方文档
• OpenAI API 兼容协议
• 阿里百炼 Coding Plan

如果你最近关注 AI Agent 领域，可能会注意到一个新名字——Hermes Agent。它来自 Nous Research，在短短两个月内从一个小型内部项目成长为功能完备的 AI Agent 平台。这篇文章聊聊它到底有什么不一样，以及为什么值得你花时间了解。

一、Hermes Agent 是什么？

简单说，它是一个可以自我进化的 AI Agent 框架。

市面上大多数 Agent 工具，你用完一次，下次还要重新教它。你说”帮我整理今天的 Git 提交记录”，它执行了。第二天你再说同样的话，它又从头开始理解。对话结束后，一切归零。

Hermes Agent 不一样。它有个叫”技能系统”的东西。第一次你教它做某件事，完成后它会问自己：这件事我以后是不是经常要做？如果答案是肯定的，它会把整个过程打包成一个技能。下次你只需要说”整理提交”，它就能直接调用这个技能。

这不是预设好的模板，是 Agent 自己判断、自己创建、自己优化的。用久了，它会越来越懂你的工作习惯。

二、为什么突然火了？

翻一下 Hermes Agent 的版本历史，你会发现一个有意思的时间线：

从2月底到4月中旬，不到两个月，发布了10个大版本。平均每三四天一个版本。这不是营销驱动的节奏，是真实需求驱动的迭代速度。

看看 v0.2.0 的发布说明：”In just over two weeks, Hermes Agent went from a small internal project to a full-featured AI agent platform — thanks to an explosion of community contributions.”

这句话翻译过来：两个星期，从内部小项目变成完整平台，原因是社区贡献爆发。

为什么爆发？因为 Hermes Agent 解决了一个长期痛点——Agent 的记忆和学习能力。之前大家做 Agent，要么接受”每次对话归零”的现实，要么自己写一套复杂的持久化逻辑。Hermes Agent 把这套逻辑内置了，而且是真正意义上的”学习”，不只是”存储”。

三、核心特质

3.1 闭环学习，不是单次执行

这点前面说了，展开讲一下细节。

Hermes Agent 的学习机制包含几个层次：

技能自动创建：完成复杂任务后，Agent 会分析这个任务是否有重复价值。有，就创建技能。技能里包含了执行步骤、需要的工具、注意事项。

技能自我改进：你用某个技能的时候如果给了反馈，比如”这次格式不对”或”下次加上这个字段”，Agent 会把这些反馈写进技能描述里。下一次执行会自动应用。

定期提醒：Agent 有个机制叫”periodic nudges”，会周期性地提醒自己把重要信息持久化。不是被动等待你要求，是主动思考”这个信息值得记住吗”。

跨会话搜索：你问”上次我们讨论的那个方案是什么”，它会搜索历史对话，用 LLM 做摘要，然后告诉你。这不是简单的关键词搜索，是语义层面的召回。

3.2 Honcho 用户建模

Hermes Agent 内置了一个叫 Honcho 的用户建模系统。这个名字来自 plastic-labs 的 Honcho 项目，是一个专门做”AI 理解用户”的框架。

它的作用是：Agent 会持续观察你的偏好、习惯、工作方式，然后建立一个用户模型。你喜欢简洁回复，它记住；你讨厌某种操作方式，它记住；你对某个项目有特殊约定，它跨会话保持。

这不是简单的”记住你说过的话”，是”理解你是什么样的人”。

3.3 多平台统一接入

这点对实际使用很重要。

你可以在 Telegram、Discord、Slack、WhatsApp、Signal 这些平台跟 Hermes Agent 对话，也可以在终端用 CLI。同一个 Agent，不同入口，记忆和技能是共享的。

这意味着你早上在公司电脑用 CLI 让它整理日报，晚上回家用 Telegram 继续讨论，它记得你白天说了什么。

3.4 定时任务，原生支持

大多数 Agent 框架没有内置的定时任务系统。你想让 Agent 每天早上自动发日报，要么写外部脚本触发，要么依赖某个外部调度器。

Hermes Agent 内置了 cron 调度。你用自然语言描述：”每天早上9点，汇总昨天的 Git 提交并发到 Telegram”，它会自动解析、创建任务、按时执行。

这对于”Agent 作为助手”的场景很重要。真正的助手不只是你叫它才动，是会主动做事情。

3.5 云端部署，不是本地绑定

这点是 Hermes Agent 相比很多同类产品的优势。

它支持六种终端后端：本地、Docker、SSH、Daytona、Singularity、Modal。其中 Modal 和 Daytona 是”无服务器”模式——你的 Agent 环境在云端，空闲时几乎不花钱，有请求时自动唤醒。

这意味着你可以把 Hermes Agent 部署到云端，然后从 Telegram 发消息触发。不在电脑前的时候，Agent 依然在工作。这对于”随时随地操作”的需求很关键。

3.6 多模型，随时切换

Hermes Agent 支持大量 LLM 提供商：

• Nous Portal（官方订阅服务）
• OpenRouter（200+模型）
• Anthropic（Claude 系列）
• OpenAI（GPT 系列）
• Google AI Studio（Gemini）
• 阿里云百炼（DashScope）
• 智谱 AI（GLM）
• Moonshot（Kimi）
• MiniMax
• 小米 MiMo
• NVIDIA NIM
• DeepSeek
• xAI（Grok）
• Hugging Face
• AWS Bedrock
• 还有更多…

切换模型用一个命令：hermes model。不需要改代码，不需要重新部署，运行时切换。

这对于实际使用很重要。不同的任务适合不同的模型，你可能写代码用 Claude，快速问答用 GPT-mini，中文内容用 Qwen。Hermes Agent 让这种切换变得零成本。

四、对 OpenClaw 用户的意义

如果你正在用 OpenClaw，听到 Hermes Agent 可能会想：又一个类似的工具，有必要换吗？

这里有个事实你可能不知道：Hermes Agent 是 OpenClaw 的官方进化版本。

翻 Hermes Agent 的文档，你会发现专门的迁移章节：

1
2
3

## Migrating from OpenClaw

If you're coming from OpenClaw, Hermes can automatically import your settings, memories, skills, and API keys.

迁移命令很简单：

1
2

hermes claw migrate --dry-run    # 先预览会迁移什么
hermes claw migrate              # 执行迁移

迁移内容包括：

• SOUL.md（人格设定）
• 已有技能
• 命令白名单
• 消息平台配置
• API 密钥（Telegram、OpenRouter、OpenAI、Anthropic 等）
• 工作空间说明（AGENTS.md）

这说明 Hermes Agent 的开发团队明确知道 OpenClaw 用户群体，并且专门做了兼容路径。

那为什么要从 OpenClaw 换到 Hermes Agent？几个实际理由：

如果你需要定时任务、云端部署、Agent 学习能力，Hermes Agent 提供了这些 OpenClaw 没有的东西。

五、安装和使用指南

5.1 Mac 用户

Mac 上安装最简单，一行命令：

1

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

安装完成后：

1
2

source ~/.zshrc   # 或者 source ~/.bashrc
hermes            # 启动

首次运行会引导你配置。按照提示选择 LLM 提供商、设置 API Key 就可以开始使用。

5.2 Windows 用户

Windows 原生不支持，需要通过 WSL2。

先安装 WSL2：

1

wsl --install

然后进入 WSL2 的 Linux 环境，运行和 Mac 一样的安装命令。

这步对不熟悉 Linux 的用户可能有点门槛，但设置好后使用体验和 Mac 一样。

5.3 常用命令

1
2
3
4
5
6
7

hermes              # 启动交互式 CLI
hermes model        # 选择模型提供商和具体模型
hermes tools        # 配置启用的工具
hermes gateway      # 启动消息平台网关（Telegram、Discord 等）
hermes setup        # 完整设置向导
hermes doctor       # 检查配置是否有问题
hermes update       # 更新到最新版本

在对话中使用的斜杠命令：

1
2
3
4
5
6
7

/new              # 开始新对话
/model            # 切换模型
/skills           # 浏览可用技能
/retry            # 重试上一轮
/undo             #撤销上一轮
/compress         # 压缩上下文
/usage            # 查看用量

5.4 配置阿里云百炼

如果你之前用 OpenClaw 配了阿里云百炼的 Coding Plan，在 Hermes Agent 里可以直接用：

1
2
3
4
5

# 设置环境变量
export DASHSCOPE_API_KEY=你的API密钥

# 如果用国内版，额外设置
export DASHSCOPE_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1

或者在 ~/.hermes/.env 文件里写：

1

DASHSCOPE_API_KEY=sk-xxxxxxxx

然后用命令切换提供商：

1
2

hermes model alibaba
hermes model qwen3-coder-plus

六、OpenClaw 用户迁移指南

如果你已经有 OpenClaw 的配置，迁移步骤：

1. 安装 Hermes Agent

1
2

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
source ~/.zshrc

2. 运行迁移命令

1

hermes setup

Setup 向导会自动检测 ~/.openclaw 目录，提示你是否迁移。

或者任何时候手动运行：

1
2

hermes claw migrate --dry-run    # 预览会迁移什么
hermes claw migrate              # 执行迁移

3. 检查迁移结果

1

hermes doctor    # 检查配置是否正确

4. 开始使用

1

hermes    # 启动 CLI

迁移后，你的 SOUL.md（人格设定）、已有技能、命令白名单、消息平台配置都会保留。API 密钥会自动迁移到 ~/.hermes/.env。

注意：OpenClaw 支持 Telegram、飞书等平台，这些配置会直接迁移。

七、适合什么人用？

如果你的需求是：

• 写代码为主 → 继续用 Claude Code，它在代码理解上更强
• 操作电脑、整理文件 → Hermes Agent 或 OpenClaw 都能胜任
• 重复性任务多 → Hermes Agent，技能系统会帮你省时间
• 需要定时自动化 → Hermes Agent，内置 cron
• 离开电脑时也想用 → Hermes Agent，云端部署 + Telegram
• 飞书/Telegram 是核心场景 → Hermes Agent 或 OpenClaw 都能胜任

如果你已经在用 OpenClaw，不需要立即换。两个工具核心功能重叠约 70%，Hermes Agent 新增的是学习能力、定时任务和云端部署。这些对你有没有价值，看你的实际需求。

但如果你想尝试 Hermes Agent，迁移成本很低。一条命令就能把 OpenClaw 的配置全部导过去，不存在”从头设置”的问题。

八、总结

Hermes Agent 的价值不在”功能更多”，在”设计思路不同”。

大多数 Agent 工具的设计假设是：用户发起对话 → Agent 执行 → 结束。下一次对话从零开始。

Hermes Agent 的设计假设是：Agent 和用户是长期关系，Agent 应该越来越懂用户，而不是每次都从陌生人开始。

这个假设的差异，导致了功能设计的差异：技能自动创建、技能自我改进、Honcho 用户建模、跨会话搜索、定期提醒持久化。

这些功能单独看都不复杂，组合起来形成一个闭环：Agent 做事 → Agent 学习 → Agent 下次做得更好。

这个闭环是 Hermes Agent 和其他 Agent 工具的本质区别。

如果你对”Agent 可以学习和进化”这个概念感兴趣，值得花半小时安装试试。不需要完全替换你现有的工具，先体验一下它的学习机制，看看是否符合你的预期。

九、相关资源

• Hermes Agent GitHub：https://github.com/NousResearch/hermes-agent
• 官方文档：https://hermes-agent.nousresearch.com/docs/
• Skills Hub：https://agentskills.io
• Nous Research Discord：https://discord.gg/NousResearch
• HermesClaw（微信桥接）：https://github.com/AaronWong1999/hermesclaw

LangChain 和 LangGraph 是当下最流行的 Agent 开发框架，但 Anthropic 的 Claude Code 却完全不用它们。这不是傲慢，而是基于技术本质、产品体验、API 特性和工程可控性的四重考量。本文从多个层面剖析 Claude Code 的自研架构选择，以及它用什么技术替代了 LangChain/LangGraph 的能力。

一、先说结论

Claude Code 不用 LangChain/LangGraph，原因有四个：

一句话概括：LangChain/LangGraph 是”通用框架”，Claude Code 是”专用系统”。通用框架追求易用，专用系统追求极致体验。

二、架构层面：为什么放弃 ReAct

2.1 ReAct 模式的根本缺陷

LangChain 和 LangGraph 的核心都是 ReAct 模式（Reasoning + Acting）：

1

思考(Thought) → 行动(Action) → 观察(Observation) → 思考 → ...

这个模式直观易懂，但存在三个根本缺陷：

缺陷一：串行瓶颈

1
2
3
4
5
6
7
8
9
10
11

┌─────────────────────────────────────────────────────────────┐
│                    ReAct 串行流程                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  用户输入 → 等待完整响应 → 解析工具调用 → 执行工具 → 等待 →  │
│            └───────────────────────────────────┘            │
│                        用户感知到的延迟                       │
│                                                             │
│  问题：用户要等模型生成完整响应后才能看到工具执行             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

在 CLI 交互场景中，这种延迟是致命的——用户盯着屏幕等待，不知道发生了什么。

缺陷二：无法利用流式传输

现代 LLM API 都支持流式输出（SSE），但 ReAct 模式下流式的价值被大大削弱：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# LangChain 的 Agent 执行
agent.run("帮我分析这个项目")

# 内部流程：
# 1. LLM 生成完整响应（即使流式，也要等 action 完整）
# 2. OutputParser 解析响应文本
# 3. 提取工具名称和参数
# 4. 执行工具
# 5. 工具结果返回给 LLM
# 6. 重复...

# 流式输出的价值：实时看到模型"在想什么"
# 但工具执行：必须等完整响应后才能开始
# 两者冲突，流式体验被割裂

缺陷三：状态恢复困难

ReAct 模式没有统一的状态表示，每一步都是独立的：

1
2
3
4
5
6
7
8

Step 1: Thought → Action → Observation  (无状态记忆)
Step 2: Thought → Action → Observation  (重新开始)
Step 3: ...

当 API 超时、Token 溢出时：
- LangChain：抛出异常，用户需手动处理
- LangGraph：需要显式定义 checkpoint，复杂度高
- Claude Code：State 对象统一承载，自动恢复

2.2 Claude Code 的替代方案：Async Generator 状态机

Claude Code 用一个 while(true) 循环 + State 赋值 替代 ReAct：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// src/query.ts 核心（简化版）
export async function* query(params: QueryParams): AsyncGenerator<QueryUpdate> {
  let state: State = {
    messages: [...],
    toolUseContext: {...},
    turnCount: 0,
    transition: undefined,
  }

  while (true) {
    // 阶段1: 消息压缩（自动处理 Token 溢出）
    // 阶段2: 流式 API 调用（工具即时执行）
    // 阶段3: 决策点（继续还是结束）
    // 阶段4: 工具编排（并行只读，串行写入）
    // 阶段5: 状态更新
    
    state = next  // 通过赋值驱动循环
    continue
  }
}

核心优势对比：

2.3 流式即时执行：StreamingToolExecutor

Claude Code 的关键创新是 工具在模型生成过程中就开始执行：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

┌─────────────────────────────────────────────────────────────┐
│                 Claude Code 流式执行流程                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  模型流式输出：                                              │
│    "我来帮你分析这个项目..."                                 │
│    "首先读取 README..."                                     │
│    [生成 tool_use 块: Read { path: "README.md" }]           │
│                                                             │
│                    ↓ 立即执行                                │
│                                                             │
│  StreamingToolExecutor:                                     │
│    检测到 tool_use → 立即调用 Read 工具                     │
│    工具结果实时返回                                          │
│                                                             │
│  用户感知：                                                  │
│    实时看到模型思考                                          │
│    实时看到工具执行                                          │
│    无需等待完整响应                                          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

对比 LangChain：

1
2
3
4
5
6
7

LangChain 流程：
  用户输入 → 等待(模型完整响应) → 解析 → 执行工具 → 等待 → ...
  总延迟 = 模型生成时间 + 解析时间 + 工具执行时间

Claude Code 流程：
  用户输入 → 流式生成(工具即时执行) → 流式输出 → ...
  总延迟 = max(模型生成时间, 工具执行时间)

三、API 层面：原生特性的充分利用

3.1 LangChain 的”框架税”

LangChain 作为通用框架，需要在多种模型 API 之间保持一致性。这意味着：

1
2
3

Anthropic API 特性          → LangChain 抽象层 → 用户代码
                                    ↓
                          被抹平或延迟支持

Anthropic 独有的 API 特性：

3.2 Claude Code 的原生集成

Claude Code 直接使用 Anthropic SDK，充分利用所有原生特性：

示例：Prompt Caching 的利用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

// Claude Code 的提示词组装（src/constants/prompts.ts）

// 静态可缓存区域（scope: 'global'）
const systemPrompt = {
  type: 'text',
  text: `
    ## 角色定义
    Claude Code 是一个...
    
    ## 系统规则
    你必须遵守...
    
    ## 工具说明
    以下工具可用...
  `,
  cache_control: { type: 'ephemeral' }  // 缓存标记
}

// 动态不可缓存区域（scope: 'ephemeral'）
const dynamicPrompt = {
  type: 'text',
  text: `
    ## 当前环境
    工作目录: ${cwd}
    
    ## 用户记忆
    ${claudeMdContent}
  `,
  cache_control: { type: 'ephemeral' }  // 独立缓存
}

缓存效果：

• 第一次调用：完整 token 计费
• 后续调用：静态部分缓存命中，降本约 90%

LangChain 也支持 Prompt Caching，但需要用户手动配置，且无法像 Claude Code 这样精细划分缓存边界。

示例：原生 tool_use 块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// Anthropic API 响应格式
{
  content: [
    { type: 'text', text: '我来帮你...' },
    {
      type: 'tool_use',
      id: 'toolu_01...',
      name: 'Read',
      input: { file_path: '/path/to/file' }
    }
  ]
}

// Claude Code 直接处理
for (const block of response.content) {
  if (block.type === 'tool_use') {
    // 立即执行，无需解析文本
    await executeTool(block.name, block.input)
  }
}

对比 LangChain：

1
2
3
4
5
6
7
8
9
10
11

# LangChain 的工具调用
response = llm.invoke(prompt)

# OutputParser 解析文本
parsed = output_parser.parse(response.content)
# 解析可能失败，格式不固定

if parsed['action']:
    tool_name = parsed['action']['tool']
    tool_input = parsed['action']['input']
    result = tools[tool_name].run(tool_input)

LangChain 需要 OutputParser 解析模型输出的文本，这是脆弱的——模型格式不固定时解析会失败。

四、性能层面：零抽象的流式优先

4.1 LangChain 的抽象层堆叠

LangChain 的抽象层结构：

1
2
3
4
5
6
7
8

用户代码
  → Chain
    → AgentExecutor
      → LLM
        → Memory
          → Tools
            → OutputParser
              → 实际 API 调用

每一层都增加处理开销。对于 Web 应用，这些开销可以忽略；但对于 CLI 交互工具，延迟是致命的。

4.2 Claude Code 的零抽象设计

Claude Code 的结构：

1
2
3
4

用户输入
  → query() AsyncGenerator
    → Anthropic SDK（直接调用）
      → 工具执行（流式即时）

没有中间抽象层，API 响应直接流式传递给用户。

4.3 工具编排的性能优化

Claude Code 的工具编排策略：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

工具调用列表
  │
  ├─ 分类：只读 vs 写入
  │
  ├─ 只读工具 ──→ 并行执行（最多 10 个并发）
  │   ├─ Read      ──→ 同时开始
  │   ├─ Grep      ──→ 同时开始
  │   ├─ Glob      ──→ 同时开始
  │   └─ WebFetch  ──→ 同时开始
  │
  └─ 写入工具 ──→ 串行执行（保证顺序）
      ├─ FileEdit  ──→ 等待上一个完成
      ├─ Write     ──→ 等待上一个完成
      └─ Bash      ──→ 等待上一个完成

LangChain 的工具执行：

1
2
3

# LangChain Agent 默认串行执行
for tool_call in parsed_tool_calls:
    result = tool.run(tool_call.input)  # 一个一个执行