DoneHub

过去 50 年，人机交互经历了 CLI → GUI → Web 的演进。今天，一个名为 Flipbook 的实验性产品正在悄悄开启第四个时代——AI 生成界面（AGI，AI-Generated Interface）。每”页”都是一张 AI 实时生成的图片，没有 HTML，没有 CSS，没有 JavaScript。你看到的一切，都是像素。

一、什么是 Flipbook？

最近刷到 Shopify CEO Tobi Lütke 转发了一条动态，引起了我的注意。一个叫 flipbook.page 的平台，被描述为：

“An infinite visual browser generated entirely on demand in real time.”
（一个完全按需实时生成的无限视觉浏览器）

用一句话概括：

你在 Flipbook 里看到的每一”页”，都是一张 AI 实时生成的图片。点击图中的任何元素，就会生成一张新图片，带你深入探索那个方向。

听起来有点科幻？但它已经上线了。

二、它长什么样？

传统浏览器的渲染链路是这样的：

1

用户点击链接 → 服务器返回 HTML → 浏览器解析 DOM → CSS 渲染 → JS 执行 → 显示页面

Flipbook 的链路则完全不同：

1

用户点击图片某处 → AI 理解意图 → 实时生成一张新图片 → 显示为"下一页"

具体来说：

• 你打开 flipbook.page，输入一个你想探索的主题
• AI 生成一张精美的信息图——包含文字、图标、图表、插图
• 所有文字都是图片像素，不是 HTML 文本覆盖层
• 你点击图中的某个元素（比如一张图表中的某个数据点）
• AI 理解你点击的内容，实时生成一张更深入的图
• 如此往复，没有终点

这就像在探索一张无限展开的知识地图，而不是在浏览一个个独立的网页。

三、核心技术架构

3.1 两个模型的协同

Flipbook 背后有两套 AI 系统在协作：

用户开启”视频流”模式后，两系统合并为连续 1080p 视频流，页面切换不再是跳变，而是平滑的镜头运动。

3.2 知识从哪来？

这不是一个”纯幻觉”的生成器。Flipbook 的内容来源有两个：

1. 代理式网络搜索（agentic web search）—— 实时从互联网获取真实数据
2. 图像模型自身的知识库 —— 模型训练时学到的世界知识

官方自己也说：“事实准确性大致等同于 ChatGPT/Gemini/Claude 的水平。”

3.3 文字也是像素

有一个细节很有意思：官方专门解释了文字渲染问题。

“All text on the screen is rendered as pixels by the image model. There are no text overlays applied to the images.”

这意味着图中的每一个字、每一行标题、每一个数字标注，都是图像模型”画”出来的。偶尔会出现文字不够清晰、位置偏移的问题——但这会随着模型迭代而改善。

换句话说，文字在这个系统中不再是可复制的文本节点，而是视觉元素的一部分。

四、谁在做这件事？

Flipbook 的创始团队背景很有意思：

算力由 Modal 赞助，投资方是 South Park Commons（这家机构还投了 Notion、Figma 等知名产品）。

一个前 OpenAI 研究员 + 两个顶尖产品设计师的组合，解释了为什么这个项目既有技术深度，又有极强的交互直觉。

五、为什么这件事值得兴奋？

5.1 它打破了一个根深蒂固的假设

过去 30 年，我们默认了一个前提：人机交互的界面是由工程师编写代码构建的。

无论是早期的 HTML 页面、Flash 动画，还是现在的 React 组件，本质上都是：工程师定义结构 → 浏览器渲染 → 用户交互。

Flipbook 打破了这个假设：

界面不再是”建造”出来的，而是”生成”出来的。

就像从”手工绘制每一帧动画”进化到”实时渲染引擎”——只不过这里的渲染引擎不是 GPU，而是大模型。

5.2 信息表达的维度被彻底打开

官方有一段话很打动我：

“一张图片价值千言万语，但我们的屏幕上却大多只是文字和彩色方块。”

在传统 Web 上，如果你想解释一个复杂概念，你只有几种选择：

• 写文字（读者需要理解）
• 放图片（需要设计师提前制作）
• 做动图/视频（成本高，不够灵活）

在 Flipbook 里，如果最有效的表达方式是一个词，你会看到一个词；如果是一幅插图，你会看到一幅插图；如果是一个数据可视化，你会看到一个数据可视化——AI 会自动选择最适合当前语境的形式。

这不是在”展示信息”，而是在”选择最佳的信息传达方式”。

5.3 灵感来自 HyperCard

Flipbook 被描述为 “AI 完全实现的 HyperCard”。

HyperCard 是 Apple 在 1987 年推出的一个软件，允许用户以卡片式的方式组织知识和导航。它的核心理念是：知识应该以空间方式探索，而不是线性搜索。

这个理念在当时太超前了，最终被万维网（WWW）取代。但 37 年后，AI 让”空间化知识探索”重新有了可能——而且这次不再需要用户手动制作卡片。

六、未来的惊艳方向

官方明确表示，Flipbook 目前是一个实验。但它规划的演进方向，每一条都足够让人兴奋。

6.1 一站式交易闭环

官方原话举例：

“现在你用 Flipbook 研究旅行计划，但预订要去别的地方。未来整个过程都可以在 Flipbook 内完成。”

想象一下：

• 搜索”巴厘岛数字游民生活” → 生成精美信息图（签证、成本、社区）
• 点击”Co-working Space” → 生成实时价格表，包含可预订的空间
• 点击”预订” → 在图内完成支付和确认
• 不需要跳转到 Airbnb、Agoda 或任何第三方 App

从”信息探索”到”行动执行”的闭环。

6.2 实时数据流嵌入

当前页面是”快照式”的图片。但未来可能实现：

• 股票价格、汇率、天气 实时渲染在图中，每帧都在更新
• 航班状态、快递追踪、赛事比分无需刷新，实时流动
• Flipbook 从”信息探索工具”变成 “实时动态仪表盘”

6.3 真正的交互能力

官方提到了 “more interactive” 和 “take actions and store their own data”：

• 表单输入：直接在生成的图片上打字、选择、拖拽
• 状态存储：Flipbook 拥有自己的”记忆”——购物车、收藏夹、项目草稿
• 复杂操作：在图中直接编辑文档、调整设计

这意味着交互能力将内嵌到像素生成的过程中，不再是 HTML 元素的专利。

6.4 跨 App 的统一入口（操作系统的替代品）

这是最大胆的方向。官方说：

“我们想象一个世界，你使用的所有工具都像我们生活的世界一样丰富和可视化。”

翻译成大白话：Flipbook 可能成为所有 App 的”元界面”。

所有功能都通过自然语言 + 视觉界面调度，不需要打开任何独立 App。

这不就是 AI 一直在说的”无 App 的未来”吗？

6.5 个性化实时生成

当前生成的是通用信息图。未来结合个人数据后：

• 你的健康数据 + 运动目标 → 专属于你的健身计划图
• 你的消费习惯 + 预算 → 为你量身定制的理财建议图
• 你的学习进度 + 知识盲区 → 针对你的薄弱点的教学图

每个人看到的内容完全不同，而且是当下即时生成的。

6.6 多人协作探索

• 你探索到一张有价值的信息图 → 生成链接 → 朋友打开后从同一节点继续探索
• 多人同时在同一个”视觉空间”中探索，各自走不同路径
• 类似”多人版维基百科”，但导航是视觉空间式的而非链接式的

七、技术挑战

当然，Flipbook 要走的路还很长。以下是当前的核心瓶颈：

八、个人感受

说实话，第一次看到 Flipbook 的演示时，我的第一反应是：这东西真的能用吗？

但仔细思考后，我发现它触及了一个本质问题——我们为什么需要浏览器？

浏览器的核心功能是”获取信息并交互”。传统 Web 用 HTML/CSS/JS 实现了这个功能，但这只是一种实现方式，不是唯一的方式。

Flipbook 用 AI 重新定义了”获取信息”的界面形态：不再是工程师预先写好的页面，而是根据你的意图即时生成的视觉表达。

这就像从”预先录制的电视节目”进化到”实时互动的直播”——内容不再是固定的，而是随观众需求变化的。

九、总结

Flipbook 目前可能只是一个实验性产品，但它代表了一个可能改变行业走向的信号：

界面，正在从”被构建”走向”被生成”。

如果说 HTML 定义了 Web 1.0 的界面范式，React 定义了 Web 2.0 的界面范式，那么 Flipbook 可能正在定义 Web 3.0 的界面范式——AI 生成的实时视觉界面。

这不是在取代 Web，而是在 Web 之上叠加了一层新的交互维度。

正如官方所说：

“We wanted a computing experience full of rich beautiful visuals made just for us, generated just in time.”

一、背景

之前研究 Chrome DevTools MCP 的时候，解决的核心问题是让 AI 能操控浏览器。但那个方案有天然的局限性：必须配置 MCP Server、依赖 Chrome 调试端口、每个平台要单独写适配器。

OpenCLI 把这件事重新做了一遍，而且做得更彻底——它不只是让 AI 能操控浏览器，而是把任何网站变成标准化的命令行工具。GitHub 上 22K+ Stars，不是偶然。

这篇文章的目标很明确：讲清楚 OpenCLI 是什么、架构怎么设计的、以及最核心的部分——如何在 Claude Code 等 Code Agent 里用它。

二、OpenCLI 是什么

一句话定义：OpenCLI 是一个 AI 原生的 CLI 运行时框架，把任意网站、浏览器会话、Electron 应用统一变成标准化的命令行接口。

打个比方理解它的定位：

核心区别在于：传统做法每次都要手动操作网页，OpenCLI 把这些操作封装成确定性 CLI 命令，而且零 LLM 运行成本。

三、架构深度拆解

3.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
29
30
31
32
33
34

┌──────────────────────────────────────────────────────┐
│                   用户 / AI Agent                     │
│              (Claude Code / Cursor 等)                │
└──────────────────────┬───────────────────────────────┘
                       │ CLI 命令
                       ▼
┌──────────────────────────────────────────────────────┐
│                   OpenCLI CLI 层                      │
│  ┌─────────────┐  ┌──────────────┐  ┌─────────────┐  │
│  │  Plugin     │  │  Adapter     │  │  Session    │  │
│  │  Loader     │  │  Resolver    │  │  Manager    │  │
│  └─────────────┘  └──────────────┘  └─────────────┘  │
└──────────────────────┬───────────────────────────────┘
                       │
          ┌────────────┴────────────┐
          ▼                         ▼
┌────────────────────┐   ┌────────────────────────┐
│  YAML Adapter 引擎  │   │  CDP 通信层             │
│  (编译期智能)       │   │  Chrome DevTools        │
│  生成确定性命令     │   │  Protocol 注入          │
└────────────────────┘   └────────────┬───────────┘
                                      │
                                      ▼
                          ┌───────────────────────┐
                          │  Chrome Extension     │
                          │  (Playwright MCP      │
                          │   Bridge)             │
                          └───────────┬───────────┘
                                      │
                                      ▼
                          ┌───────────────────────┐
                          │  已登录的 Chrome 浏览器 │
                          │  (你的真实用户会话)     │
                          └───────────────────────┘

这个架构有几个关键设计点，值得拆开细说。

3.2 核心理念：编译期智能 vs 运行期智能

这是 OpenCLI 架构里最重要的一个设计选择。

运行期智能的意思是：每次执行命令时都让 LLM 实时理解页面结构、决定操作步骤。这种方式灵活，但每次都要消耗 token，而且结果不稳定。

编译期智能是 OpenCLI 的选择：Adapter 在生成阶段只解析一次页面结构，产出一个确定性的 YAML 定义。后续所有 CLI 调用都走这个 YAML，零 LLM 成本，结果可预测。

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

# 一个 Adapter 示例：获取 B站视频播放量
name: bilibili-stats
target: https://member.bilibili.com/platform/home
steps:
  - action: navigate
    url: "https://member.bilibili.com/platform/home"
  - action: extract
    selector: ".data-overview .total-views"
    output: total_views
  - action: extract
    selector: ".data-overview .total-fans"
    output: total_fans

这段 YAML 定义好之后，每次执行都是确定的 DOM 选择器匹配，不需要 LLM 参与。只有在 Adapter 开发阶段才需要一次智能解析。

3.3 CDP 驱动层：为什么不走 Selenium/Playwright 路线

OpenCLI 选择基于 Chrome DevTools Protocol (CDP) 而不是传统的 Selenium 或 Playwright，原因很实际：

关键点在于复用登录态。你在浏览器里已经登录了知乎、B站、小红书，OpenCLI 直接通过 CDP 连上这个正在运行的实例，不需要重新登录、不需要 API Key、不需要存密码。

3.4 浏览器扩展：Playwright MCP Bridge

CDP 本身只能从外部控制 Chrome，但 OpenCLI 需要双向通信——既要控制页面，也要把页面结构回传给 CLI。这个桥梁由一个 Chrome 扩展承担：

Playwright MCP Bridge 扩展负责：

1. 接收 OpenCLI CLI 的指令（点击、输入、导航）
2. 在页面中执行对应操作
3. 返回结构化 DOM 快照（不是截图，是带语义的 DOM 树）
4. 维护 Session 状态（bind/unbind 标签页）

这个扩展是轻量级的 micro-daemon 模式，启动 OpenCLI 时自动加载。

3.5 Session 管理：bind 机制

Session 是 OpenCLI 连接 CLI 命令和具体浏览器标签页的桥梁：

1
2
3
4
5
6
7
8

# 把当前浏览器某个已登录的标签页绑定到 session
opencli browser my-blog bind

# 查看已绑定的 session
opencli browser list

# 解绑
opencli browser my-blog unbind

绑定之后，所有针对该平台的 CLI 命令都会在这个已登录的标签页里执行。

四、安装与快速上手

4.1 环境要求

• Node.js >= 20.0.0
• Chrome / Chromium / Brave / Edge 浏览器

4.2 安装步骤

1
2
3
4
5

# 全局安装 OpenCLI
npm install -g @jackwener/opencli

# 自动配置（检测 Chrome 实例、安装扩展）
opencli setup

opencli setup 会做这几件事：

1. 检测本地 Chrome 调试端口
2. 下载并加载 Playwright MCP Bridge 扩展
3. 验证 CLI 与浏览器的连通性
4. 初始化 ~/.opencli 配置目录

4.3 运行第一个命令

1
2
3
4
5

# 查看内置适配器列表
opencli list

# 运行一个平台命令（以 B站 为例）
opencli bilibili stats

五、在 Code Agent 中的使用（重点）

这部分是整篇文章的核心。OpenCLI 的真正威力不在于手动敲命令，而在于让 AI Code Agent 通过它操控任意网站。

5.1 为什么 Code Agent 需要 OpenCLI

Claude Code、Cursor 这类 Code Agent 原生能力很强：能写代码、能读文件、能跑测试、能用 git。但有一个明确的边界——它们不能操作网页。

这个边界在实际工作中很要命。举个例子：

你要把一篇技术博客同步到知乎、公众号、小红书三个平台。用 Claude Code 写文章很快，但发布环节只能手动操作三个平台的后台。OpenCLI 把这个边界打通了。

5.2 在 Claude Code 中集成 OpenCLI

方式一：直接作为 CLI 工具调用

Claude Code 本身就能执行 shell 命令，最直接的方式就是在对话中让它执行 opencli 命令：

1
2

你: 帮我查看 B站最近的视频数据
Claude Code: 执行 opencli bilibili stats，返回结果...

这种方式不需要额外配置，只要本机装了 OpenCLI 就行。

方式二：安装 OpenCLI Skill

OpenCLI 提供了适配 AI Agent 的 Skill 定义，安装后 Agent 能更准确地理解和使用 OpenCLI：

1
2

# 在 Claude Code 中安装 OpenCLI skill
npx skills add jackwener/opencli

安装之后，Claude Code 会在执行浏览器相关任务时自动识别 OpenCLI 的可用命令，而不是每次都让你手动指定。

方式三：在 .claude/commands 中自定义命令

结合 Claude Code 的自定义命令系统，可以把常用的 OpenCLI 操作封装成斜杠命令：

1
2
3
4
5
6
7
8
9

# .claude/commands/publish-blog.md
---
description: 发布博客到多平台
---

执行以下命令发布博客：
1. opencli zhihu publish --title "{{title}}" --content "{{content}}"
2. opencli weixin publish --title "{{title}}" --content "{{content}}"
3. opencli xiaohongshu publish --title "{{title}}" --content "{{content}}"

之后在 Claude Code 中只需输入 /publish-blog 就能一键发布。

5.3 实际工作流示例

场景：AI 驱动的博客同步工作流

1
2
3
4
5
6
7
8
9
10

你: 把 source/_posts/opencli-deep-analysis.md 这篇文章发到知乎、小红书、B站

Claude Code 的执行流程:
1. 读取 Markdown 文件内容
2. 根据各平台特点调整格式（知乎支持 Markdown，
   小红书需要短文案+图片，B站专栏有特定结构）
3. 执行 opencli zhihu publish --title "..." --content "..."
4. 执行 opencli xiaohongshu publish --title "..." --content "..."
5. 执行 opencli bilibili publish --title "..." --content "..."
6. 返回各平台的发布结果

整个过程不需要你打开任何一个浏览器页面。

场景：数据监控面板

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

你: 帮我看看各平台最近一周的数据

Claude Code:
> opencli bilibili stats --period 7d
> opencli zhihu stats --period 7d
> opencli xiaohongshu stats --period 7d

汇总输出:
| 平台   | 阅读量  | 点赞 | 评论 |
|--------|--------|------|------|
| B站    | 12,340 | 456  | 89   |
| 知乎   | 8,920  | 312  | 56   |
| 小红书 | 15,600 | 890  | 123  |

场景：社区运营自动化

对于数字游民社区的运营工作，OpenCLI 能大幅减少重复劳动：

1
2
3
4
5
6
7
8
9
10
11

你: 检查一下社区后台有没有待审核的帖子

Claude Code:
> opencli nomad-community pending-reviews

返回 3 条待审核内容，逐条展示...

你: 全部通过

Claude Code:
> opencli nomad-community approve --all

5.4 Agent 操作浏览器的技术细节

理解 Claude Code 通过 OpenCLI 操作浏览器的底层流程，有助于你排查问题和编写自定义插件。

完整的调用链路：

1
2
3
4
5
6
7
8

Claude Code 发起对话
  → OpenCLI CLI 解析命令
    → 查找对应 Adapter 定义（YAML/TS）
      → 通过 CDP 连接 Chrome 实例
        → 扩展在页面中执行操作
          → 返回结构化 DOM 快照
            → Adapter 解析快照提取数据
              → CLI 返回结果给 Claude Code

结构化 DOM 快照 是理解这一切的关键。OpenCLI 不是截图给 AI 看，而是把页面转成一个带语义的结构化文本：

1
2
3
4

[button] "发布文章" (clickable, enabled)
[textbox] "标题" value="OpenCLI 深度解析" (editable)
[textarea] "正文内容" (editable, placeholder="输入正文...")
[link] "预览" href="/preview"

这种格式对 LLM 极其友好：token 消耗远低于截图，信息密度更高，而且可以直接定位到可交互元素。

六、插件开发实战

内置适配器覆盖了主流平台，但你自己的网站或者小众平台需要写自定义插件。

6.1 插件目录结构

1
2
3
4
5
6
7
8

~/.opencli/plugins/
└── my-custom-plugin/
    ├── plugin.yaml        # 插件元信息
    ├── adapters/
    │   ├── list.yaml      # 列表命令
    │   ├── publish.yaml   # 发布命令
    │   └── stats.yaml     # 统计命令
    └── README.md

6.2 编写一个完整的 Adapter

以”从某个网站后台提取文章列表”为例：

1
2
3
4
5

# plugin.yaml
name: my-blog-admin
version: 1.0.0
description: 个人博客后台管理 CLI
base_url: https://myblog.com/admin

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

# adapters/list.yaml
name: articles
description: 列出所有文章
target: "https://myblog.com/admin/articles"
steps:
  - action: navigate
    url: "https://myblog.com/admin/articles"
  - action: wait
    selector: ".article-table tbody tr"
  - action: extract
    selector: ".article-table tbody tr"
    fields:
      - name: title
        selector: ".article-title"
      - name: status
        selector: ".article-status"
      - name: published_at
        selector: ".published-date"
    output: articles
  - action: format
    template: "{{title}} | {{status}} | {{published_at}}"
    output: articles

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

# adapters/publish.yaml
name: publish
description: 发布新文章
target: "https://myblog.com/admin/articles/new"
inputs:
  - name: title
    type: string
    required: true
  - name: content
    type: string
    required: true
steps:
  - action: navigate
    url: "https://myblog.com/admin/articles/new"
  - action: input
    selector: "#article-title"
    value: "{{title}}"
  - action: input
    selector: "#article-content"
    value: "{{content}}"
  - action: click
    selector: "#publish-button"
  - action: wait
    selector: ".publish-success"
  - action: extract
    selector: ".success-message"
    output: result

写好之后，通过 symlink 链接到 OpenCLI 插件目录：

1
2
3
4
5

# Linux/Mac
ln -s /path/to/my-custom-plugin ~/.opencli/plugins/my-blog-admin

# Windows (PowerShell)
New-Item -ItemType Junction -Path "$env:USERPROFILE\.opencli\plugins\my-blog-admin" -Target "D:\path\to\my-custom-plugin"

之后就能直接使用：

1
2
3
4
5

# 列出文章
opencli my-blog-admin articles

# 发布文章
opencli my-blog-admin publish --title "OpenCLI 深度解析" --content "..."

6.3 在 Claude Code 中使用自定义插件

自定义插件写好后，Claude Code 同样能调用。你可以在 Claude 的对话中直接说：

1
2
3
4
5
6
7
8

你: 用 my-blog-admin 插件列出所有已发布的文章
Claude Code: 执行 opencli my-blog-admin articles，返回...

你: 帮我把标题为 "xxx" 的文章同步到知乎
Claude Code:
1. 执行 opencli my-blog-admin articles 获取文章内容
2. 提取目标文章内容
3. 执行 opencli zhihu publish 发布到知乎

七、OpenCLI vs 其他方案对比

市面上让 AI 操作网页的方案不少，简单对比一下：

OpenCLI 的 sweet spot 很明确：当你需要一个确定性的、零运行成本的、能复用浏览器登录态的网站操作方案时，它是最优选择。

八、注意事项与限制

任何工具都有边界，OpenCLI 也不例外。

8.1 不适合的场景

• 高频交易或实时性要求极高的操作：CDP 通信有延迟，不如直接调 API
• 需要无头浏览器批量爬取的场景：OpenCLI 依赖真实 Chrome 实例，不适合大规模并发
• 对稳定性要求 100% 的生产环境：网站改版后 Adapter 需要更新选择器

8.2 安全考量

OpenCLI 复用浏览器登录态，意味着它能操作你已登录的任何网站。建议：

• 只在受信任的 AI Agent（如本地 Claude Code）中使用
• 不要在云端或共享环境中使用
• 发布类操作可以先让 Agent 生成预览，人工确认后再执行

8.3 平台反爬

部分平台会检测自动化行为。OpenCLI 走的是真实浏览器实例，比无头浏览器好一些，但如果操作频率过高仍可能触发风控。控制节奏、避免短时间大量操作。

九、总结

OpenCLI 把”让 AI 操作网页”这件事从实验阶段拉到了生产可用阶段。它的核心价值可以概括为三点：

1. 统一接口：任何网站变成 CLI，不用管底层是网页、Electron 还是本地工具
2. 零运行成本：Adapter 编译后确定性执行，不消耗 LLM token
3. 安全复用登录态：不存密码、不要 API Key、走真实浏览器

对于写博客、运营社区、管理多平台的创作者来说，配合 Claude Code 这样的 Code Agent，OpenCLI 能省掉大量重复的浏览器操作。对于开发者来说，YAML 声明式的插件开发门槛远低于写完整的自动化脚本。

一、背景

每天打开手机，十几个 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 不要混用