Agent on KnightLi的博客

CLI-Anything：把软件变成 Agent 可用的命令行

Mon, 25 May 2026 00:24:36 +0800

CLI-Anything 是 HKUDS 开源的 Agent 工具化项目，目标是把原本面向人类 GUI 操作的软件，转成 AI Agent 更容易调用的命令行接口。它不是重新实现一个简化版软件，而是围绕现有代码库和真实后端生成 CLI harness，让 Agent 可以通过稳定命令、状态会话和结构化输出来完成任务。

这个方向解决的是 Agent 使用软件时最常见的断层：GUI 自动化依赖截图、点击和坐标，容易受界面变化影响；单个 API 又经常覆盖不完整，Agent 需要自己拼接大量上下文。CLI-Anything 选择把软件能力收敛成命令行，因为命令天然适合被模型读取、组合、验证，也便于接入脚本和自动化流程。

它怎么工作

官方仓库把 CLI-Anything 描述为一套自动生成 CLI 的流水线。给它一个本地软件源码路径或 GitHub 仓库地址后，流程会分析代码结构、识别后端和数据模型，设计命令分组，再实现 CLI、测试和文档。

生成出来的 CLI 通常包含两种使用方式：一种是面向连续工作的 REPL，会保留项目状态；另一种是子命令模式，适合脚本和流水线。命令还会提供 JSON 输出，方便 Agent 直接解析结果，同时保留人类可读的格式用于调试。

官方示例里，Claude Code 插件可以这样使用：

1
2
3

/plugin marketplace add HKUDS/CLI-Anything
/plugin install cli-anything
/cli-anything <software-path-or-repo>

如果已经生成某个软件的 harness，后续使用方式会更接近普通 Python CLI：

cd <software>/agent-harness
pip install -e .
cli-anything-<software> --help
cli-anything-<software>
cli-anything-<software> --json <command>

适合什么场景

CLI-Anything 更适合那些“能力在真实软件里，但 Agent 不好稳定操作”的场景。例如图像、视频、音频、办公文档、3D 建模、数据分析或 AI/ML 工具链，只要项目有可分析的代码库、可调用的后端或清晰的数据模型，就有机会被包装成 Agent 可用的命令集。

它的价值不只是在命令行里多一层封装，而是把软件的关键操作变成可发现、可组合、可测试的接口。Agent 可以先通过 --help 理解能力，再用 JSON 输出接收结果，并把多个命令串成工作流。对于需要批处理、自动验证和持续迭代的任务，这比临时让 Agent 点击界面更可控。

需要注意的边界

CLI-Anything 并不等于任何软件都能立刻无成本接入。它依赖目标软件的源码、后端能力、文件格式和可测试性；如果一个软件高度封闭、关键逻辑只存在于 GUI 层，生成高质量 CLI 的难度会明显上升。

官方方法论也强调真实后端和测试验证，这意味着生成 harness 不是只写几个命令包装脚本就结束。要让它用于严肃工作，还需要确认命令覆盖范围、输出格式、依赖安装、真实软件调用和端到端测试是否可靠。更现实的用法，是先为一个明确工作流生成 CLI，再通过 refine、test、validate 等命令逐步补齐能力。

小结

CLI-Anything 的思路很直接：不要让 Agent 去适应脆弱的人类界面，而是为现有软件补上一层稳定、结构化、可测试的命令行入口。它适合想把专业软件纳入 Agent 工作流的人，也适合研究“Agent 原生软件”形态的开发者。真正落地时，重点不在于一句命令生成了多少代码，而在于生成的 CLI 是否能调用真实能力、保持状态、输出结构化结果，并经得起测试。

Token Efficiency 是什么？从 DeepSeek V4 看大模型规划、小模型执行

Fri, 15 May 2026 08:59:33 +0800

AI 编程接下来真正重要的指标，可能不是“谁的模型最强”，而是谁能用更少的 token、更低的成本、更稳定的流程，完成更多可验收的工作。

这就是 Token Efficiency 的价值。

很多人理解 Token Efficiency，只会想到模型便宜、上下文变长、缓存命中更低价。但这些只是底层条件。真正能把它变成生产力的，是模型分工、任务编排、上下文预算和评估体系。

换句话说，Token Efficiency 不是省钱技巧，而是一套把 token 转换成产出的工程方法。

DeepSeek V4 的定位：把大小模型分工产品化

这篇文章最应该先补上的背景，是 DeepSeek V4 的定位。

DeepSeek V4 不是单纯发布一个更强模型，而是把 Token Efficiency 需要的两层能力直接拆成了 V4 Pro 和 V4 Flash：Pro 更适合做规划、推理、架构判断和关键审查，Flash 更适合做高频执行、批量改写、代码补全、资料整理和 agent 循环里的普通节点。

这正好对应 AI 编程里的两个角色：

V4 Pro：当作 planner / consultant，用在需求拆解、技术方案、复杂 bug 根因、架构审查和最终验收。
V4 Flash：当作 executor，用在文件扫描、简单实现、测试补齐、文档整理、候选方案生成和重复性任务。

DeepSeek 官方 API 文档显示，V4 Flash 和 V4 Pro 都支持 1M 上下文、JSON Output、Tool Calls、Chat Prefix Completion 和 FIM Completion；价格页也把缓存命中输入单独计价，并说明全模型 input cache hit 价格已降到发布价的十分之一。这几个点组合起来，才是它和 Token Efficiency 关系最密的地方。

1M 上下文解决的是复杂 agent 任务容易被压缩的问题；低缓存命中价格解决的是长系统 prompt、项目文档、代码片段和历史状态反复进入上下文的成本问题；Flash / Pro 双模型形态解决的是“每一步都用旗舰模型太贵、每一步都用小模型又不稳”的分工问题。

所以 DeepSeek V4 的优势不应该只写成“便宜”或“上下文长”，而应该理解成三件事：

执行层便宜：大量 agent 节点可以交给 V4 Flash，让 token 消耗落在低成本模型上。
判断层可用：关键步骤仍然可以调用 V4 Pro，避免为了省钱牺牲复杂推理质量。
长链路友好：1M 上下文和缓存价格让代码库、文档、工具调用历史更容易留在可用窗口里。

这就是为什么 DeepSeek V4 对 AI 编程的意义，不只是又多了一个模型选项，而是给“顾问模型 + 执行模型 + harness 编排”的模式提供了更现实的成本结构。

不要让最强模型干所有活

过去使用 AI，常见做法是找一个最聪明的模型，让它从需求分析、代码实现、测试、总结一路干到底。

这个方式简单，但不一定高效。因为很多任务并不需要最高级别的推理能力。真正贵的模型，应该更像顾问、架构师或规划员：只在关键决策点介入。

更合理的结构是：

大模型负责拆问题、定方向、做关键判断。
小模型负责执行、批量处理、重复修改。
工具和 harness 负责流程、状态、上下文和验证。
人负责定义产品、验收结果和决定取舍。

这样做的好处是，前沿推理能力不会被浪费在机械执行上。大部分 token 消耗可以落到便宜模型和缓存输入里，贵模型只处理真正需要“脑力”的部分。

上下文不是越大越好

长上下文很重要，尤其是 coding agent。代码、文档、历史对话、测试输出、错误日志都会吃掉上下文。上下文一旦接近上限，模型就容易触发压缩、遗忘或误判。

但长上下文不等于可以无限塞资料。

Token Efficiency 的关键，是让每个任务都能在一个清晰、可控的上下文窗口内完成。最理想的状态不是“把整个仓库塞进去”，而是：

当前任务只带必要文件。
背景文档只带决策相关部分。
历史信息只保留当前阶段需要的状态。
每个节点有明确输入和输出。
完成后把结果压缩成结构化摘要，交给下一个节点。

上下文越便宜，越要警惕浪费。便宜 token 会诱导人把无关信息全塞进去，最后模型不是更聪明，而是更容易被噪声拖慢。

Harness 比单个模型更重要

如果只是把 Claude Code、Codex 或其他 coding agent 接到便宜模型上，效果未必好。小模型容易在长链路任务里跑偏，需要更强的流程控制。

真正让小模型发挥价值的，是 harness。

这里的 harness 可以理解为一套调度系统：它知道任务怎么拆、节点怎么跑、模型怎么选、结果怎么验收、失败怎么重试、上下文怎么传递。

一个可用的编排系统，至少要回答几个问题：

哪些任务需要规划？
哪些任务可以直接执行？
哪些节点可以并行？
哪些节点必须串行？
哪个节点用大模型，哪个节点用小模型？
每个节点最多允许多少上下文？
每个节点完成后输出什么结构？
谁来 review，谁来决定是否继续？

没有这层软件，小模型只是便宜；有了这层软件，小模型才可能变成杠杆。

用 DAG 拆任务

一个有效的思路，是把复杂任务拆成有向无环图，也就是 DAG。

比如一个功能开发任务，可以拆成：

需求澄清
方案设计
任务拆分
编码实现
测试补齐
Code Review
修复问题
提交 PR

每个节点都可以是一个独立 agent。它们运行在独立环境里，有自己的角色、prompt、工具权限和输出格式。节点之间不靠长篇聊天传递信息，而是靠预先定义好的结构化结果。

这会带来两个直接收益。

第一，单个节点更短。任务越小，越容易被小模型完成，也越不容易撑爆上下文。

第二，流程更可测。你可以单独观察“编码节点失败率高”还是“review 节点漏问题多”，然后针对性优化。

任务可以跑多个副本

当 token 足够便宜时，一个有趣的变化会出现：同一个任务不一定只跑一次。

你可以让同一个任务用不同模型、不同 prompt、不同编排跑多个副本，再从结果里选最好的，或者把多个结果合并。这个思路有点像“抽卡式任务解决”，但前提是必须有评估和验收。

适合多副本的任务包括：

方案设计
文案生成
测试用例补全
Bug 根因假设
重构方案比较
Code Review

不适合盲目多副本的任务，是那些会直接修改共享状态、会产生外部副作用、或者验收标准不清楚的任务。

多跑几次不是为了碰运气，而是为了获得可比较样本。样本越多，越能反过来优化编排、模型选择和节点技能。

必须建立评估体系

Token Efficiency 不能只看价格。便宜但失败率高，最后会吞掉人的时间，反而更贵。

所以每个团队都应该逐步建立自己的评估体系。它不需要一开始就很复杂，但要能量化。

可以先记录这些指标：

任务完成率
人工介入次数
工具调用失败率
测试通过率
Review 发现的问题数量
单任务 token 成本
单任务耗时
返工次数
不同模型组合的差异

有了这些数据，才能知道哪些任务适合小模型，哪些任务必须上大模型，哪些任务应该交给人判断。

真正的优化不是“所有地方都换便宜模型”，而是把每类任务放到最合适的模型和流程里。

业务流程要原子化

普通用户不一定要自己写完整 harness。未来这类工具会越来越多，也会越来越成熟。

但现在就可以做一件事：把自己的业务流程拆成原子节点。

比如内容生产可以拆成：

选题
资料收集
提纲
初稿
事实核查
风格改写
SEO 标题
多语言翻译
发布检查

软件开发可以拆成：

需求确认
技术方案
数据结构
接口变更
单元测试
实现
迁移脚本
文档
Review

每个节点都要尽量做到输入明确、输出明确、验收明确、上下文可控。这样等 harness 工具成熟时，你的业务流程可以直接接进去。

硬件不是第一优先级

很多人聊 Token Efficiency，很快就会聊到本地部署和显卡。但对大多数人来说，第一选择仍然应该是 API。

原因很简单：在没有跑通经济模型之前，本地硬件只是成本前置。你还不知道 token 怎么转化成收入或生产力，就先买昂贵设备，很容易变成玩具。

更稳的顺序是：

先用 API 跑通业务流程。
建立任务评估和成本统计。
找到稳定高频的执行节点。
再考虑哪些节点值得本地化。
最后再计算硬件、电费、维护和折旧。

如果只是个人提效，API 往往已经够用。如果是创业团队，要验证模型边界和推理框架，本地 CUDA 平台才更有学习价值。如果已经有明确生产场景和经济模型，多卡部署才有讨论空间。

小结

Token Efficiency 的本质，不是“用便宜模型替代贵模型”，而是重新设计 AI 工作流。

大模型负责关键判断，小模型负责批量执行，harness 负责调度和验证，人负责定义目标和验收结果。只有这四层配合起来，token 才能稳定变成生产力。

接下来真正有价值的能力，不只是会用最新模型，而是能把任务拆小、把上下文控住、把结果量化、把流程编排起来。

模型会继续降价，上下文会继续变长，小模型会继续变强。越是这样，越应该早点理解 Token Efficiency。因为未来的差距，很可能不在谁调用了最强模型，而在谁能用同样的 token 撬动更多真实产出。

Superpowers：把 Coding Agent 拉回工程流程的技能框架

Fri, 15 May 2026 08:53:17 +0800

obra/superpowers 是一个给 coding agent 使用的技能框架，也是一套软件开发方法论。它的目标不是再写一个“让 AI 更听话”的万能 prompt，而是把 agent 的工作流程固定下来：先澄清目标，再产出设计，再拆计划，再按测试驱动开发推进，最后做 review 和收尾。

项目地址：https://github.com/obra/superpowers

截至写作时，GitHub API 显示这个仓库已有超过 19 万 star，许可证为 MIT，最近仍在更新。README 对它的描述很直接：An agentic skills framework & software development methodology that works.

它想解决什么问题

现在很多 AI 编程工具的问题，不是“不够会写代码”，而是太容易直接写代码。

用户刚说一个模糊需求，agent 就开始改文件；改完以后看似完成，其实边界没对齐、测试没补、架构没想清楚。短任务可能没事，复杂项目里就会变成返工、回滚和技术债。

Superpowers 的思路是：让 agent 在动手前先进入流程。

README 里描述的核心路径大致是：

发现用户要做东西时，不立刻写代码，而是先追问目标。
从对话中整理出规格说明，并分段给用户确认。
设计通过后，生成足够清楚的实施计划。
用户说 “go” 之后，再进入实现流程。
实现时强调 TDD、YAGNI、DRY，并通过 review 检查结果。

这套流程听起来不新，但放到 coding agent 里很关键。AI 的执行速度越快，前置澄清和中途验证越重要。

支持哪些工具

Superpowers 不是只面向一个 agent。README 里列出的安装入口包括：

Claude Code
Codex CLI
Codex App
Factory Droid
Gemini CLI
OpenCode
Cursor
GitHub Copilot CLI

其中 Codex CLI 和 Codex App 都可以通过官方 Codex plugin marketplace 安装。Claude Code 也可以通过官方插件市场或 Superpowers 自己的 marketplace 安装。

这说明它的定位更像“跨 harness 的工作流层”，而不是绑定某一家模型或某一个命令行工具。

基础工作流

Superpowers 的基础工作流分成几个阶段。

第一步是 brainstorming。它会在写代码前触发，通过问题把粗糙想法整理成可执行设计。它不是让 agent 自嗨式补全需求，而是把设计分段拿给用户确认。

第二步是 using-git-worktrees。设计确认后，它会创建隔离的工作区和新分支，先确认项目能正常安装、测试基线是干净的。这一步能减少多个任务互相污染工作区的问题。

第三步是 writing-plans。它会把设计拆成短小任务，每个任务要求有明确文件路径、代码范围和验证步骤。README 里甚至把计划写给“没有上下文、品味可疑、不爱测试的热情初级工程师”也能执行，当作清晰度标准。

第四步是实现。它可以用 subagent-driven-development 派发子任务，也可以用 executing-plans 分批执行。重点不是并发本身，而是每个任务都要能检查、能 review、能继续推进。

第五步是 test-driven-development。Superpowers 强调真正的 RED-GREEN-REFACTOR：先写失败测试，确认失败，再写最小实现，确认通过，然后重构。它甚至要求删除测试前写出来的实现代码，避免“先实现后补测试”的假 TDD。

第六步是 requesting-code-review。任务之间做 review，按严重程度报告问题。Critical 问题会阻塞继续推进。

最后是 finishing-a-development-branch。任务结束后，验证测试，给出合并、发 PR、保留或丢弃 worktree 的选择。

Skills Library 里有什么

Superpowers 的技能库可以分成几类。

测试类主要是 test-driven-development，围绕红绿重构循环，并包含测试反模式参考。

调试类包括 systematic-debugging 和 verification-before-completion。前者要求按复现、最小化、假设、验证、修复的过程找根因；后者强调不要在没有验证前宣布完成。

协作类更丰富，包括：

brainstorming
writing-plans
executing-plans
dispatching-parallel-agents
requesting-code-review
receiving-code-review
using-git-worktrees
finishing-a-development-branch
subagent-driven-development

元技能包括 writing-skills 和 using-superpowers。前者用于创建新技能，后者用于理解技能系统本身。

这些技能组合起来，像是给 agent 装了一套工程习惯：什么时候该问，什么时候该计划，什么时候该测试，什么时候该停下来 review。

和普通 prompt 最大的区别

普通 prompt 往往把规则堆在一段 system prompt 里：不要乱改、先思考、要测试、要解释、要简洁。问题是规则越堆越多，模型越容易在复杂任务里选择性遗忘。

Superpowers 更像把规则拆成可触发的流程模块。不同任务阶段使用不同技能，每个技能只负责一段工作。这样做有几个好处：

规则更短，目标更集中。
agent 更容易知道当前阶段该做什么。
复杂流程可以被拆成可检查的步骤。
技能可以跨工具复用。
团队可以把自己的工程习惯沉淀成技能。

这也是它最值得参考的地方：不要只追求“更聪明的模型”，还要给模型一套可重复的工作方式。

适合谁用

Superpowers 更适合已经在认真使用 coding agent 的开发者，尤其是这些场景：

任务不只是单文件改动。
希望 agent 先设计再实现。
项目需要 TDD 或至少需要验证步骤。
经常并行做多个功能分支。
希望用 subagent 分摊实现、检查和 review。
想把团队流程写成可复用技能。

如果只是让 AI 改一行配置、生成一个脚本，它可能显得偏重。但一旦任务涉及多文件、多阶段、多轮确认，它的流程约束就会变得有价值。

使用时要注意什么

第一，不要把它理解成自动驾驶。Superpowers 能让 agent 更有流程感，但设计取舍、需求边界和最终验收仍然需要人负责。

第二，TDD 和 review 会增加前期成本。小任务可能会变慢，但复杂任务通常能减少返工。

第三，子代理并发不是越多越好。并发适合边界清楚、写入范围不重叠的任务；如果需求还没想清楚，先并发只会把混乱放大。

第四，团队要维护自己的技能质量。技能不是写完就万事大吉，过时的流程、模糊的指令和互相冲突的规则，也会拖累 agent。

小结

Superpowers 的价值，不在于某个单独技能多神奇，而在于它把 coding agent 从“接到需求就写代码”拉回了软件工程流程。

它提醒我们：AI 编程真正缺的往往不是生成速度，而是澄清、计划、验证、review 和收尾。模型越强，这些流程越不能省。否则 AI 只是更快地制造未验证的代码。

如果你已经在用 Codex、Claude Code、Cursor 或 Gemini CLI 做真实项目，Superpowers 值得看一眼。即使不直接安装，它的技能拆分方式也很适合拿来改造自己的 agent 工作流。

DeepSeek V4 Flash 做 Godot 游戏 Demo：几毛钱能跑通到什么程度？

Wed, 06 May 2026 09:22:18 +0800

DeepSeek V4 Flash 用来开发 Godot 游戏 Demo，到底能不能打？

重点很直接：它能不能做出一个可运行、可观察、带物理效果的 Godot 小 Demo。

结论先说：可以跑通，效果不算商业级，但已经足够作为玩法原型和物理交互 Demo 使用。更重要的是，成本非常低，适合快速验证想法。

Demo 表现

这个 Demo 的重点是物理交互。

几个比较直观的效果包括：

绳子可以被切断。
箱子会掉到地上。
调大质量后，箱子碰撞会更猛烈。
绳子表现出比较明显的弹性。
调整摩擦力和弹性后，箱子会出现明显的滑动和反弹。

从呈现效果看，它已经不是“只生成几段 Godot 脚本”那么简单，而是一个能运行、能观察物理表现的小型原型。

可用程度

这个 Demo 的价值在于“能跑、能看、能改”。它不是完整游戏，也不是可以直接商业化的工程，但已经能说明几个问题：

DeepSeek V4 Flash 能理解 Godot Demo 的基本目标。
AI Agent 可以把需求转成可运行工程。
Godot 物理交互这种非网页类任务，已经可以进入低成本原型阶段。
对个人开发者来说，它能把“想法”快速变成“能看的东西”。

如果目标是做一个正式游戏，它当然还不够；但如果目标是验证“这个玩法有没有意思”“物理效果大概能不能做出来”，这个 Demo 已经可用。

成本意义

最值得关注的不是画面有多精致，而是成本。

如果一个 Godot 物理 Demo 只需要几毛钱级别的模型成本，就能得到一个可运行版本，那么它的意义就不是替代专业游戏开发，而是大幅降低原型试错成本。

以前想验证一个小游戏想法，至少需要自己熟悉 Godot、写脚本、调场景、调物理参数。现在可以先让 AI Agent 生成一个可运行版本，再由人判断方向对不对。

对独立开发者来说，这类低成本试错很有用：

快速验证玩法概念。
生成临时 Demo 给别人看。
探索 Godot API 和物理系统。
把想法转成能跑的初版工程。
在不确定方向前减少手写代码成本。

DeepSeek V4 Flash 的表现

比较值得注意的是，使用的是 DeepSeek V4 Flash，而不是更贵、更重的旗舰模型。

它在“低成本原型”这个定位上表现不错。它不是最强、最稳、最适合交付生产工程的模型，但在预算敏感、想快速试一下方向的场景里，很有吸引力。

适合什么场景

DeepSeek V4 Flash + Agent + Godot 更适合下面这些任务：

小型玩法原型。
物理效果 Demo。
UI 或交互概念验证。
教学示例。
辅助理解 Godot 项目结构。
生成第一版可运行工程。

不太适合直接承担这些任务：

大型游戏架构。
复杂角色控制器。
网络同步。
商业项目核心代码。
高精度物理模拟。
不经过人工测试的自动提交。

换句话说，它适合做“第一稿”和“试验场”，不适合当生产工程负责人。

这说明了什么

这说明，AI 编程正在从网页、脚本、后端接口，继续向游戏开发和交互原型扩展。

过去游戏开发的门槛很高，尤其是引擎、脚本、资源管理和物理系统混在一起时，新手很容易卡住。现在模型加 Agent 工具，可以先把工程搭起来，让开发者把注意力放在玩法判断和效果调优上。

它带来的变化可能有三点：

第一，游戏原型会更便宜。很多想法不用等到完整开发阶段才验证，可以先得到可运行 Demo。

第二，独立开发者会更敢尝试。不会 Godot 的人，也可以借助 AI 先摸到项目结构和基本流程。

第三，模型稳定性会变得更重要。游戏开发不是只要代码能跑，还要效果合理、手感正常、参数可控。未来谁能更好地结合实际画面和运行状态，谁就更适合做这类任务。

小结

DeepSeek V4 Flash 做 Godot Demo，可以概括成一句话：效果不完美，但足够便宜、足够快，也足够适合做原型。

它离商业游戏还很远，但如果目标是用极低成本验证一个小游戏想法，它已经很有价值。

对个人开发者来说，最现实的用法不是把游戏全交给 AI，而是让 AI 先给出能跑的工程，再由人负责判断、取舍和打磨。这样用，DeepSeek V4 Flash 这类低成本模型反而会很香。

DeepSeek-V4 Preview 发布：1M 上下文、双模型与 API 切换提醒

Fri, 24 Apr 2026 22:39:46 +0800

DeepSeek 在 2026-04-24 发布了 DeepSeek V4 Preview Release。从官方新闻页来看，这次更新的重点非常集中：1M context、V4-Pro 与 V4-Flash 双模型、对 Agent 场景的专门优化，以及 API 侧的模型切换。

如果只看一句话，这次发布的核心信号是：DeepSeek 不只是继续做更强的模型，而是在把超长上下文和 Agent 能力一起往“可直接上线使用”的方向推进。

1. 这次一共发布了什么

官方页面里，DeepSeek-V4 Preview 主要包含两条产品线：

DeepSeek-V4-Pro
DeepSeek-V4-Flash

对应的官方描述也很直接：

DeepSeek-V4-Pro：1.6T total / 49B active params
DeepSeek-V4-Flash：284B total / 13B active params

从命名就能看出来，这次不是单模型升级，而是把高性能版本和更高性价比版本同时推了出来。

其中 V4-Pro 更强调上限，官方说它的表现已经可以和全球顶级闭源模型竞争；V4-Flash 则更强调速度、效率和成本，更适合对响应速度和 API 成本更敏感的场景。

2. `1M context` 是这次最突出的卖点

官方页面最醒目的表述之一，就是：“Welcome to the era of cost-effective 1M context length.”

DeepSeek 这次不只是说“支持长上下文”，而是明确把 1M context 当成这代模型的默认能力来讲。页面里也写得很清楚：

1M context 已经成为官方 DeepSeek 服务的默认标准
V4-Pro 和 V4-Flash 都支持 1M context

这件事的意义不只是“能塞更多 token”。它更直接影响下面这些任务：

长代码仓库理解
长文档问答和资料整合
多轮 Agent 工作流
跨多文件、多工具、多阶段的复杂任务

如果上下文窗口足够大，模型就更不容易因为中途丢上下文而反复回读材料，这对 Agent 编码和复杂知识工作会特别重要。

3. `V4-Pro` 主要在强调什么

从官方页的措辞看，DeepSeek-V4-Pro 重点强调三件事：

Agentic Coding 能力
世界知识
推理能力

页面里提到，V4-Pro 在 Agentic Coding benchmark 上达到开源 SOTA；在世界知识方面领先当前开源模型，仅落后于 Gemini-3.1-Pro；在数学、STEM 和编码能力上超过当前开源模型，并且可以和顶级闭源模型竞争。

换句话说，V4-Pro 的定位并不是单纯回答问题，而是更偏向高难度推理、复杂编码和长任务执行。

4. `V4-Flash` 并不是简单的缩水版

另一个值得注意的点是，官方没有把 V4-Flash 包装成“低配模型”，而是强调它在很多实际任务里已经足够强。

按照新闻页给出的说法，V4-Flash：

推理能力已经很接近 V4-Pro
在简单 Agent 任务上与 V4-Pro 表现相当
参数规模更小，响应更快，API 定价更便宜

这意味着 DeepSeek 这次给出的并不是“一个旗舰、一个入门”的非常割裂的组合，而更像是：

V4-Pro：追求更高性能和更强上限
V4-Flash：追求更低延迟和更好成本效率

对于开发者来说，这样的组合会更实用，因为很多线上任务真正需要的不是“理论最强”，而是“够强、够快、够省”。

5. 官方特别强调了 Agent 优化

这次发布页里还有一个很明确的方向：DeepSeek 在主动把 V4 往 Agent 场景上推。

官方页面提到，DeepSeek-V4 已经和一些主流 AI Agent 深度集成，包括：

Claude Code
OpenClaw
OpenCode

同时 DeepSeek 也提到，V4 已经在内部 agentic coding 场景中使用。

这说明它想覆盖的，不再只是聊天或普通补全，而是更长链路的工作方式：读代码、理解结构、调用工具、生成结果，再把整条流程串起来。

如果你最近正好在关注 coding agent，这个信号值得留意。因为它意味着模型厂商已经不再只拼 benchmark，而是在拼“能不能真正接进工作流”。

6. 底层结构创新在为长上下文服务

在技术描述上，官方页把这次的结构创新总结为：

token-wise compression
DSA (DeepSeek Sparse Attention)

页面给出的方向非常明确：目标是把长上下文做得更便宜、更高效，尽量降低计算和显存成本。

虽然新闻页没有展开完整技术细节，但这至少说明 DeepSeek 这次不是单纯靠“更大算力硬堆更长窗口”，而是在结构层面针对长上下文效率做了专门优化。

对实际使用者来说，这通常比单纯“窗口数字变大”更重要，因为真正决定可用性的，不只是能不能开到 1M，还包括：

速度是否还能接受
成本是否还能接受
长上下文任务是否真的稳定

7. API 已经可用，但要注意模型切换

官方页面明确写到，这次 API 当天就已经可用。

接入方式也比较简单：

base_url 保持不变
把模型名切换为 deepseek-v4-pro 或 deepseek-v4-flash

同时页面说明，这两个模型都支持：

1M context
Thinking / Non-Thinking 双模式
OpenAI ChatCompletions
Anthropic APIs

这意味着如果你原本已经接了 DeepSeek API，升级门槛并不高，主要是模型名切换和能力验证。

8. 旧模型的退役时间也写得很明确

对开发者来说，这次新闻页里最不能忽略的信息之一，其实是旧模型退役提醒。

官方写明：

deepseek-chat
deepseek-reasoner

会在 2026 年 7 月 24 日 15:59（UTC） 后完全退役并不可访问。

页面还说明，当前这两个模型实际上已经路由到 deepseek-v4-flash 的非思考 / 思考模式。

这意味着如果你的项目里还直接写着 deepseek-chat 或 deepseek-reasoner，现在就应该开始安排迁移，而不要拖到正式下线前再处理。

9. 这次发布值得怎么理解

如果把这次更新浓缩成几个重点，大概可以这样看：

DeepSeek 开始把 1M context 从“高配能力”变成默认标准
双模型路线更清晰：一个冲性能上限，一个冲速度和性价比
Agent 能力已经被放到很核心的位置
API 升级路径相对直接，但旧模型退役时间需要尽快关注

对普通使用者来说，最直观的变化可能是：长文档、长代码、长流程任务会更容易放进一次上下文里。
对开发者来说，更重要的是：如果你已经在做 Agent、代码助手、资料整理、复杂工作流，这一代模型显然就是朝这些场景设计的。

DeepSeek 这次发布，不只是一次常规模型更新，更像是在明确它下一阶段的产品方向：超长上下文 + Agent 优化 + 更实际的 API 可用性。

AI 名词解释：用大白话讲清楚 Agent、MCP、RAG 和 Token

Thu, 23 Apr 2026 13:13:40 +0800

刚开始接触 AI，最容易劝退人的通常不是模型本身，而是讨论里那些一串串名词。Agent、MCP、RAG、AIGC、Token 看起来都很常见，但如果没人先用人话讲一遍，很多人其实只是在“眼熟”，并没有真正听懂。

这篇就顺着一组常见入门解释的思路，把 10 个高频 AI 名词压缩成一套更容易记住的解释。目标不是讲得多学术，而是先帮你建立一个能跟上日常讨论的基础框架。

10 个常见 AI 名词，分别是什么意思

1. Agent：不只会聊天的执行型 AI

Agent 可以先理解成“会干活的 AI 助手”。

普通聊天机器人更像是你问一句、它答一句；Agent 则更进一步，它会把任务拆开、安排步骤、调用工具，再把结果交回来。比如你让它帮你整理资料、查信息、生成文档，它不只是给建议，而是可能直接把这些动作串起来做完。

所以 Agent 的关键，不在“会不会说”，而在“能不能做”。

2. OpenClaw：驻留在电脑里的 AI 助手

视频里把 OpenClaw 形容成一种“住在电脑里的 AI 管家”。

你可以把这类工具理解成更贴近桌面操作的 AI 助手：它不只是接收文字，还可能直接观察界面、调用本地工具、按流程执行任务。和普通网页聊天相比，这类工具更强调实际操作能力。

如果说 Agent 是抽象层面的“执行型 AI”，那这类桌面型助手更像是它在个人电脑上的一种具体落地形式。

3. Skills：给 Agent 装上的能力包

Skills 可以理解成 Agent 的功能模块或操作说明。

同一个 Agent，装上不同的 Skills，就能表现出不同的专长。比如有的偏文案生成，有的偏数据整理，有的偏代码处理。它们有点像手机里的 App，也有点像一套套可复用的工作流程。

所以很多时候，不是模型突然“变聪明”了，而是它背后多了一组明确的规则、工具和步骤。

4. MCP：AI 连接外部工具的统一接口

MCP 全称是 Model Context Protocol。

如果用生活里的比喻，它有点像 AI 世界里的 Type-C 接口。以前模型想接不同工具，往往要一套一套单独对接；有了统一协议之后，接入方式会更标准，也更容易复用。

对普通用户来说，最值得记住的一点是：MCP 解决的不是“模型会不会回答”，而是“模型怎么安全、稳定地连上外部工具和资源”。

5. 抽卡：AI 生成结果带有随机性

“抽卡”这个说法常见于 AI 绘图、视频生成和内容创作场景。

意思很简单：同样的提示词、同样的大方向，每次生成出来的结果也可能不一样。有时候效果惊艳，有时候明显翻车，所以很多人会把反复尝试生成结果这件事，形容成像游戏里抽卡。

它提醒我们的其实是同一件事：AI 生成不是固定公式，而是带概率和波动的过程。

6. API：应用和模型之间的连接方式

API 全称是 Application Programming Interface，也就是应用程序接口。

它可以理解成程序之间沟通的标准入口。你在自己的应用、脚本或编辑器里调用模型服务，本质上就是通过 API 发请求、拿结果。

如果把模型服务比作一家餐厅，那么：

菜单像 API 文档
点菜像发起 API 请求
后厨出餐像模型返回结果

所以很多工具表面上看起来不一样，底层其实都是在调用某种 API。

7. 多模态：AI 不只处理文字

“多模态”说的是 AI 不再只会读写文本，而是可以同时处理多种信息形态。

比如它可以看图、听语音、理解视频、生成图片，甚至做实时语音和视频交互。和早期只会处理文字的模型相比，多模态模型更像是在同时拥有“看、听、说、写”的能力。

这也是为什么现在很多 AI 产品的交互方式，已经不再局限于一个输入框。

8. RAG：先检索资料，再组织答案

RAG 是 Retrieval-Augmented Generation，通常译作检索增强生成。

它适合解决一个很现实的问题：模型本身的训练数据有时间边界，也不知道你企业内部的新文档、客服记录和业务规则。RAG 的思路就是，先从指定资料里把相关内容找出来，再结合这些资料生成回答。

它的价值通常体现在三点：

答案更容易贴近真实资料
可以追溯回答依据来自哪里
新文档加入后，知识可随时更新

所以很多企业知识库、智能客服和内部问答系统，底层都会用到 RAG。

9. AIGC：AI 生成内容的总称

AIGC 是 AI Generated Content 的缩写。

它不是某一个单独工具，而是一个总称，泛指 AI 生成出来的内容，包括文本、图片、音频、视频等各种形式。你看到的 AI 写稿、AI 制图、AI 做短视频、AI 配音，都可以放进 AIGC 这个大框里理解。

这个词真正重要的地方在于，它描述的是一种内容生产方式，而不是某个具体模型。

10. Token：模型处理内容时的计量单位

Token 可以理解成模型处理文本时使用的基础计量单位。

它不完全等于“一个字”或者“一个单词”，但在使用层面上，你可以先把它当成模型计算和计费时的通用单位。你的输入会消耗 Token，模型的输出会消耗 Token，上下文里保留的历史内容同样会占用 Token。

所以为什么很多模型服务都在强调上下文长度、成本控制和压缩提示词，本质上都和 Token 有关。

Claude Code 多 Agent 协作：Subagents 和 Agent Teams 怎么选

Wed, 22 Apr 2026 21:35:52 +0800

Claude Code 里和多 Agent 协作相关的能力，最容易混淆的就是 Subagents 和 Agent Teams。它们看起来都像“多开几个 Agent 一起做事”，但定位并不一样。简单说，前者更适合把独立任务分出去做，后者更适合让多个 Agent 围绕同一件事持续协作、互相验证。

如果你之前用过 Skill，也可以先这样理解：

Skill 负责定义流程和规则
Subagent 或 Agent teammate 负责实际执行任务

所以问题不在于“哪个更高级”，而在于你要解决的是哪一类协作。

Subagents：把支线任务分出去

Subagents 更像是在当前会话里临时派出去的分身。每个分身都有自己的上下文窗口，做完之后只把结果摘要带回来，主对话不会被大量中间输出塞满。

这类能力的优势很直接：

主线对话更干净，不容易被测试日志、搜索结果或长输出污染
可以把相互独立的研究或执行任务并行化
适合“给我结果就行”的任务，不需要持续讨论

原文提到，Claude Code 内置了三类 Subagent：

Explore：只读、适合快速搜索代码库
Plan：只读、适合在 plan mode 下后台收集信息
General-purpose：可读可写，适合同时探索和修改的任务

自定义 Subagent

如果内置能力不够，可以自己定义一个 Subagent。方式也不复杂，本质上就是写一个 Markdown 文件：

.claude/agents/：只对当前项目生效
~/.claude/agents/：对所有项目生效

文件格式类似这样：

---
name: code-reviewer
description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code.
tools: Read, Grep, Glob, Bash
model: inherit
---
You are a senior code reviewer ensuring high standards of code quality and security.

When invoked:

1. Run git diff to see recent changes
2. Focus on modified files
3. Begin review immediately

Review checklist:

- Code is clear and readable
- Functions and variables are well-named
- No duplicated code
- Proper error handling
- No exposed secrets or API keys
- Input validation implemented
- Good test coverage
- Performance considerations addressed
Provide feedback organized by priority:

- Critical issues (must fix)
- Warnings (should fix)
- Suggestions (consider improving)

Include specific examples of how to fix issues.

这里最关键的是 description。Claude 会根据这段描述判断什么时候应该调用这个 Subagent，所以写得越清楚，触发越准。

另外几个常见配置项也很实用：

tools：限制它能用哪些工具
model：决定使用 sonnet、opus、haiku 或 inherit
permissionMode：控制编辑权限和权限提示行为
memory：给 Subagent 配跨对话记忆目录

如果只是临时用一次，也可以直接通过 CLI 注入：

claude --agents '{
  "code-reviewer": {
    "description": "Expert code reviewer. Use proactively after code changes.",
    "prompt": "You are a senior code reviewer. Focus on code quality, security, and best practices.",
    "tools": ["Read", "Grep", "Glob", "Bash"],
    "model": "sonnet"
  }
}'

Subagents 适合什么场景

最适合 Subagents 的，通常是这些任务：

跑测试并返回失败摘要，而不是把几千行日志全塞回主会话
并行调查几个互不依赖的模块
把“检查问题”和“修问题”拆成两步流水线

例如：

`1`	`Research the authentication, database, and API modules in parallel using separate subagents`

`1`	`Use the code-reviewer subagent to find performance issues, then use the optimizer subagent to fix them`

但如果任务需要频繁来回修正、多个阶段共享大量上下文，或者改动高度集中在少数几个文件里，那么直接在主对话里做，往往比派 Subagent 更省事。

Agent Teams：多个独立会话一起协作

Agent Teams 是另一个层级的能力。它不是在一个会话里派出分身，而是启动多个彼此独立的 Claude Code 实例，让它们围绕共享任务列表协作，还可以互相发消息。

这意味着它更像一个真正的小团队，而不只是“分出去做个支线”。

原文提到，这项能力目前还是实验功能，需要先开启：

{
    "env": {
        "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
    }
}

把它加到 settings.json 后，就可以让 Claude 按你的要求组织一个 team。比如：

1
2
3

I'm designing a CLI tool that helps developers track TODO comments across
their codebase. Create an agent team to explore this from different angles: one
teammate on UX, one on technical architecture, one playing devil's advocate.

Agent Teams 的组成

一个 Agent Team 主要由三部分组成：

Team lead：你当前正在使用的主会话，负责组队、分派和汇总
Teammates：多个独立的 Claude Code 实例
Task list 和 Mailbox：共享任务列表与消息通道

和 Subagents 最大的不同在于，teammates 之间可以直接沟通，不需要每次都经过 lead 中转。任务状态通常会在 pending、in progress、completed 之间流转，成员完成一个任务后，还可以继续认领下一个任务。

Agent Teams 适合什么场景

当任务需要多角度讨论、互相挑战结论、或者拆成多个模块并行推进时，Agent Teams 会更合适。

原文给了几个很典型的场景：

多人并行审查同一个 PR，但每个人关注不同维度
围绕同一个 bug 提出不同假设，并互相反驳
前端、后端、测试分别推进不同模块

比如并行代码审查：

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

再比如竞争假说式调试：

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk to
each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.

这类任务的共性是：不是只要一个结果，而是需要不同 Agent 之间不断交换判断、修正方向，最后再形成比较可靠的结论。

两者怎么选

如果要快速区分，可以直接记这条：

做完给结果，用 Subagents
需要讨论和相互验证，用 Agent Teams

再展开一点，区别主要在这几个维度：

通信方式：Subagents 主要把结果回传给主对话；Agent Teams 的成员之间可以直接通信
协调模式：Subagents 更依赖主会话统一调度；Agent Teams 有共享任务列表，成员可以自己认领任务
Token 成本：Subagents 更省；Agent Teams 成本更高，因为每个 teammate 都是独立实例
适合任务：Subagents 更适合独立、结果导向的任务；Agent Teams 更适合需要讨论、交叉验证的任务

使用时要注意什么

Agent Teams 虽然更强，但并不意味着任何任务都值得开 team。原文特别提醒了几个现实问题：

token 消耗明显更高
同时让多个 teammate 改同一个文件，很容易互相覆盖
teammate 太多会增加协调成本，收益未必继续增长

因此，比较稳妥的做法通常是：

3 到 5 个 teammate 作为起点
按模块或文件拆任务，避免写入冲突
如果 lead 过早接手了 teammate 的任务，要明确告诉它先等队友完成

另外，当前实验能力还有一些限制，例如：

不支持 /resume 和 /rewind 恢复 in-process teammates
任务状态偶尔会滞后，需要人工提醒更新
一个 lead 一次只能管理一个 team
teammate 不能再继续派子 team

简单结论

这两个能力并不是替代关系，而是分别解决两类协作问题。

如果你的需求是“把支线任务并行做掉，别污染主上下文”，优先用 Subagents。如果你的需求是“让几个 Agent 像一个小团队一样协作、讨论、交叉验证”，再考虑 Agent Teams。

先用一个真实场景试一次，通常很快就能体会到差别：一个强调上下文隔离和结果回收，另一个强调多视角协同和持续互动。

Agent on KnightLi的博客

CLI-Anything：把软件变成 Agent 可用的命令行

它怎么工作

适合什么场景

需要注意的边界

小结

Token Efficiency 是什么？从 DeepSeek V4 看大模型规划、小模型执行

DeepSeek V4 的定位：把大小模型分工产品化

不要让最强模型干所有活

上下文不是越大越好

Harness 比单个模型更重要

用 DAG 拆任务

任务可以跑多个副本

必须建立评估体系

业务流程要原子化

硬件不是第一优先级

小结

Superpowers：把 Coding Agent 拉回工程流程的技能框架

它想解决什么问题

支持哪些工具

基础工作流

Skills Library 里有什么

和普通 prompt 最大的区别

适合谁用

使用时要注意什么

小结

DeepSeek V4 Flash 做 Godot 游戏 Demo：几毛钱能跑通到什么程度？

Demo 表现

可用程度

成本意义

DeepSeek V4 Flash 的表现

适合什么场景

这说明了什么

小结

DeepSeek-V4 Preview 发布：1M 上下文、双模型与 API 切换提醒

1. 这次一共发布了什么

2. 1M context 是这次最突出的卖点

3. V4-Pro 主要在强调什么

4. V4-Flash 并不是简单的缩水版

5. 官方特别强调了 Agent 优化

6. 底层结构创新在为长上下文服务

7. API 已经可用，但要注意模型切换

8. 旧模型的退役时间也写得很明确

9. 这次发布值得怎么理解

相关链接

AI 名词解释：用大白话讲清楚 Agent、MCP、RAG 和 Token

10 个常见 AI 名词，分别是什么意思

1. Agent：不只会聊天的执行型 AI

2. OpenClaw：驻留在电脑里的 AI 助手

3. Skills：给 Agent 装上的能力包

4. MCP：AI 连接外部工具的统一接口

5. 抽卡：AI 生成结果带有随机性

6. API：应用和模型之间的连接方式

7. 多模态：AI 不只处理文字

8. RAG：先检索资料，再组织答案

9. AIGC：AI 生成内容的总称

10. Token：模型处理内容时的计量单位

Claude Code 多 Agent 协作：Subagents 和 Agent Teams 怎么选

Subagents：把支线任务分出去

自定义 Subagent

Subagents 适合什么场景

Agent Teams：多个独立会话一起协作

Agent Teams 的组成

Agent Teams 适合什么场景

两者怎么选

使用时要注意什么

简单结论

相关链接

2. `1M context` 是这次最突出的卖点

3. `V4-Pro` 主要在强调什么

4. `V4-Flash` 并不是简单的缩水版