在终端里跑一个真正能"动手"的 AI 编码智能体——DeepSeek TUI 完整折腾指南

本文由 莫潇羽@源码七号站（www.fuyuan7.com）撰写，转载请注明出处。

快速摘要

核心结论先说： DeepSeek TUI 是一个完全运行在终端里的开源 AI 编码智能体，用 Rust 写成，核心特点是"零运行时依赖"——不需要 Node.js 或 Python 环境，下载两个二进制文件就能直接跑。它把 DeepSeek V4（deepseek-v4-pro 和 deepseek-v4-flash）的能力原生接入终端，支持读写文件、执行 Shell 命令、管理 Git、搜索网页，以及并行调度子智能体，拥有 100 万 Token 的超长上下文窗口，还能实时展示模型的思维链过程。三种工作模式（Plan / Agent / YOLO）覆盖从安全探索到全自动化的不同场景，内置 side-git 快照机制让你随时可以回滚工作区，不用担心 AI 把代码搞乱。截止写这篇文章，项目开源才两天就斩获了 3500+ Star，势头相当猛。

适合谁看： 喜欢在终端里工作的开发者、想在本地把 AI 能力接入工作流的工程师、对 DeepSeek V4 模型系列感兴趣想上手实操的朋友。

想看完整拆解，往下翻。

一、为什么终端里的 AI 编码智能体有独特价值

现在 AI 编码助手的赛道真的是挤满了人。从 GitHub Copilot 到各种 IDE 插件，从网页版对话框到各类 VSCode 扩展，可以选择的工具已经多到让人眼花缭乱。既然选择这么多，为什么还需要一个"纯终端"方案？

这个问题值得先想清楚，因为它直接决定了 DeepSeek TUI 适不适合你。

首先是工作流集成的问题。对于很多后端工程师、DevOps、系统程序员来说，终端本身就是主要的工作环境。编译、部署、调试、SSH 远程操作，这些任务本来就在终端里完成。如果 AI 助手也在终端里，就不需要在多个界面之间反复切换。上下文不会中断，思路不会被打断，整个工作流是连贯的。这个"不打断"听起来是小事，但在实际开发中，频繁切换窗口对专注度的消耗是真实存在的。很多有经验的程序员为了维持专注状态，宁愿少用一些功能更丰富的图形工具，也要把操作留在同一个环境里。

其次是对工作区的直接访问能力。基于网页的 AI 工具，要让它真正"动手"帮你改文件，通常需要先复制代码，让它生成修改建议，再手动把结果粘回去——这个流程相当割裂。而终端里的智能体可以直接读写你的文件系统，执行 Shell 命令，这种能力在质量上就不是同一个层次的。它不是在给你写"参考代码"，而是在给你改真实的文件，运行真实的命令，看到真实的输出，然后根据输出决定下一步。这个"闭环"是基于网页的 AI 工具在架构上很难做到的事情。

还有一个很实际的点：在远程服务器或者轻量开发环境上，IDE 插件往往跑不起来，或者安装起来很麻烦。但只要能 SSH 上去，一个终端工具就能直接用。这对于需要在服务器端调试或者维护代码的场景来说，非常重要。很多开发者的工作场景是这样的：本地写代码，但真正的运行环境是一台远程 Linux 服务器，出了问题需要登上去查。这时候一个能在纯终端环境运行、不需要任何图形界面的 AI 助手，实用价值就直接体现出来了。

"聊天型"和"智能体型"的本质差距也是绕不过去的话题。很多人用 AI 写代码的方式是：把代码粘进去，让它改，把结果粘回来，看看有没有报错，再粘回去问"为什么报这个错"……这种来回粘贴的模式，本质上是在用一个"聊天工具"模拟一个"智能体"，中间的人工操作成本非常高。真正的编码智能体应该自己去读文件、自己跑命令、自己看错误输出、自己决定下一步——人类只需要在关键决策点上介入或审批。DeepSeek TUI 做的就是这件事。

我自己折腾下来的感受是：终端版 AI 工具和 IDE 插件版的 AI 工具，就像 vim 和图形化编辑器的关系。不是说谁一定比谁好，而是它们适合不同的使用习惯和场景。如果你已经把大部分工作放在终端里完成，那 DeepSeek TUI 这类工具对你的吸引力会远超那些基于图形界面的方案。如果你是一个重度 VSCode 用户，IDE 插件可能更顺手；但如果你每天有大量时间是在终端里度过的，值得试试看能不能把 AI 也留在那个环境里。

当然，这里有一个前提：这个"终端 AI 工具"本身必须足够好用、足够强大，否则再有概念也没有意义。这就是为什么 DeepSeek TUI 值得认真看一眼——它背后接的是 DeepSeek V4，一个在多个基准测试上能和闭源顶级模型掰手腕的开源模型系列。

二、DeepSeek V4 系列背景：你在用什么级别的模型

在深入 DeepSeek TUI 之前，有必要花一点篇幅介绍一下它背后的模型——DeepSeek V4 系列。因为模型的能力天花板，直接决定了这个工具的上限在哪里。

2.1 V4 系列的两个成员

DeepSeek V4 系列目前有两款主力模型：

• DeepSeek-V4-Pro：参数规模 1.6 万亿（总参数），激活参数为 490 亿。这是系列里的旗舰款，定位是高复杂度推理、高质量编码和长时间运行的智能体任务。
• DeepSeek-V4-Flash：参数规模 2840 亿（总参数），激活参数 130 亿。面向高速、高效场景设计，成本更低，推理速度更快，适合作为子任务执行者或者对延迟要求高的应用。

两款模型都原生支持 100 万 Token 的上下文窗口，这个数字在同类开源模型中是顶级水准。

2.2 为什么 100 万 Token 上下文很重要

100 万 Token 是个什么概念？大约能装下 9 本完整的英文长篇小说，或者一个中等规模的完整代码仓库（包括所有源码文件、测试、配置文件），或者几百篇研究论文。

对编码场景来说，这意味着你可以把整个项目的代码都塞进上下文，让模型在全局视角下进行代码审查、重构建议、安全漏洞扫描，而不需要把代码切成小块分批喂给它——后者会导致模型无法感知代码之间的依赖关系，效果大打折扣。

不过这里要解释一个技术细节，否则你可能会觉得"100 万 Token 听起来很美，但成本和性能上能撑住吗"——这个问题 DeepSeek V4 的架构设计上是有针对性回答的。

2.3 混合注意力架构：为什么 100 万 Token 不再那么贵

传统 Transformer 模型在处理长上下文时，计算量和 KV Cache（键值缓存）占用会随 Token 数量平方级增长，这导致超长上下文在工程上要么很慢要么很贵，往往是理论支持、实际跑不起来。

DeepSeek V4 为此设计了一套混合注意力架构（Hybrid Attention Architecture），结合了压缩稀疏注意力（CSA）和重度压缩注意力（HCA）两种机制，对不同距离的 Token 采用不同精度的注意力计算：近期 Token 保持全精度，距离较远的 Token 则使用压缩后的注意力表示。

结果是：在 100 万 Token 的上下文场景下，V4-Pro 相比 DeepSeek-V3.2，只需要约 27% 的单 Token 推理计算量，KV Cache 占用仅为 10%。这不是在说理论，而是在实际推理中就能产生这样的效率差距。

此外，V4 系列还引入了 Muon 优化器（一种针对训练稳定性优化的梯度下降变体）和流形约束超连接（mHC），进一步提升了训练效率和模型表达能力。

2.4 V4-Pro 在编码基准上的表现

从公开的测评数据来看，V4-Pro 在 Agentic Coding（智能体编码）基准上是目前开源模型里的 SOTA（最优水平），在 Math/STEM/Coding 等推理类任务上超过了当前所有开源模型，同时在知识类任务上仅次于 Gemini-3.1-Pro。这对于一个编码智能体来说，意味着它背后的模型基础是扎实的，不是在拿一个勉强能用的模型凑合。

V4-Pro-Max 是 V4-Pro 的最大推理努力模式，在知识能力方面进一步提升，定位为目前最强的开源模型之一，在编码基准上能显著缩小与顶级闭源模型的差距。对于 DeepSeek TUI 用户来说，这意味着在处理最复杂的架构设计或算法推理任务时，可以切到这个推理强度更高的模式来获得更好的结果，代价是推理时间会更长、Token 消耗更多。

另外值得一提的是 V4 系列的开源策略——模型权重在 Hugging Face 上完全公开，意味着有资源的团队可以自己部署推理服务，不依赖任何第三方 API，数据完全在自己手里。对于对数据主权有强烈要求的企业场景，这是一个非常重要的考量因素。结合 DeepSeek TUI 对自托管 SGLang 的支持，完全私有化的 AI 编码助手方案在技术上是可行的。

三、DeepSeek TUI 项目概览

3.1 项目定位

DeepSeek TUI（GitHub 地址：https://github.com/Hmbown/DeepSeek-TUI）是一个用 Rust 实现的终端原生编码智能体。它并不是一个简单的 API 调用包装器，而是一个完整的智能体运行时，内置了任务管理、工具调度、会话状态管理、工作区快照、MCP 客户端等一整套基础设施。

用一句话描述它的架构层次：deepseek（调度器 CLI）→ deepseek-tui（TUI 运行时）→ ratatui 界面 ↔ 异步引擎 ↔ OpenAI 兼容流式客户端。工具调用经过一个类型化注册表（Shell、文件操作、Git、网页、子智能体、MCP、RLM），结果实时流回终端界面。

3.2 Rust 实现的意义

选择 Rust 作为实现语言不只是开发者偏好，对使用者来说有一个直接好处：零运行时依赖。不需要本地装 Node.js，不需要 Python 虚拟环境，不需要任何解释器或运行时。两个二进制文件放到 PATH 里，chmod +x 一下就能跑。这在服务器部署、CI/CD 环境集成、极简系统安装等场景下是很实际的优势。

用过 Aider（Python）的朋友可能有印象，每次在新机器上装的时候，总要处理一堆依赖冲突、Python 版本问题、pip 下载慢等糟心事。Rust 二进制完全避免了这类问题，把"安装成本"降到了最低。特别是在需要快速给一台新服务器配置 AI 编码环境的时候，这个优势格外明显——下载两个文件，放到 PATH，完事。

Rust 本身的内存安全特性也让这类需要频繁操作文件系统和执行外部命令的程序更加可靠。DeepSeek TUI 的架构文档里提到，整个工具调用路径都是强类型化的，这意味着出错时能给出清晰的错误信息，而不是一个不知从哪冒出来的空指针异常。从实际使用体验来说，它的崩溃率和报错质量都比很多同类 Python 工具要好。

目前支持的平台覆盖范围也很广，包括 Linux x64/ARM64（glibc 和 musl）、macOS（Intel 和 Apple Silicon）、Windows x64，以及 FreeBSD、RISC-V64 等 Tier-1 Rust 编译目标。对于有在非主流平台运行需求的场景，这个覆盖面已经非常够用了。

3.3 项目整体完成度

值得特别提一下的是，这个项目的完整性让人有点意外——不只是一个"demo 级"的概念验证，而是带有完整错误处理、配置系统、会话持久化、多平台支持的生产可用工具。从 GitHub 的 CHANGELOG 来看，版本迭代相当频繁，维护者对 bug 修复和新特性的响应速度很快。判断一个开源项目是否值得长期投入使用时，维护活跃度是一个非常重要的指标——从 DeepSeek TUI 目前的表现来看，这方面是加分项。

四、核心能力逐项拆解

4.1 原生 RLM 并行推理

RLM（Reasoning Language Model）是 DeepSeek TUI 里一个颇有意思的设计。简单来说，rlm_query 工具允许主模型（V4-Pro）同时调度 1 到 16 个廉价的 deepseek-v4-flash 子智能体并行工作，每个子智能体可以独立处理一个子任务，最终把结果汇总回来。

这个机制适合什么场景？比如你让它分析一个大型代码库的潜在 Bug，它可以把不同模块拆给不同的 Flash 子智能体同时扫描，而不是让 Pro 模型串行读完整个库。批量分析、任务分解、并行推理——这三类需求都能受益。从效率上来说，16 个子智能体并行扫描 16 个模块，理论上比串行快 16 倍；从成本上来说，Flash 模型的价格比 Pro 低得多，这种"Pro 做调度，Flash 做执行"的分工方式在性价比上也很合理。

v0.8.6 版本之后，RLM 还增加了 rlm_process 工具，把 RLM 的完整执行循环暴露为一个结构化工具，模型自己可以决定什么时候调用它，而不需要用户手动 /rlm 触发。这让并行推理从一个"手动功能"变成了模型自主决策的一部分。在实际使用中，这意味着当你给模型一个大任务时，它会自己判断哪些子任务适合并行化，然后自动调度——用户不需要了解 RLM 的内部机制，只需要描述任务目标就行。

使用 rlm_process 时，可以通过 file_path（工作区相对路径，推荐，避免把大量输入放入上下文）或 content（内联文本，最多 20 万字符）传入任务内容，返回结构化结果，包含迭代次数、耗时、Token 消耗和终止原因。这个返回结构对于需要监控 AI 执行成本的团队来说也很有用，每次大规模并行分析之后都能看到详细的消耗明细。

# settings.toml 里启用相关配置示例
[agent]
default_mode = "agent"  # plan / agent / yolo

4.2 思考模式流式展示

这是 DeepSeek TUI 最有"临场感"的特性之一，也是我个人觉得最值得体验一次的地方。

DeepSeek V4 的思考模式（Think Mode）本质是让模型在给出最终答案之前，先输出一段完整的内部推理过程，也就是"思维链（Chain-of-Thought）"。DeepSeek TUI 把这个过程实时流式渲染到终端里，你可以看着模型一步步拆解你的问题——它先检查了哪个文件、发现了什么、提出了什么假设、又否定了哪个方案……整个决策过程是可见的、可追踪的。

这种透明性有两个实际价值。一是帮你判断模型的推理是否靠谱，在接受它的修改建议之前，你已经"旁观"了它的思考过程，有助于识别明显的错误推断。举个典型的例子：假设模型在思考过程里提到"我认为这个函数只在 A 模块里被调用"，但你知道它其实还被 B 模块引用——这时你就能在它真正动手修改之前叫停，避免一个隐性的破坏性改动。如果没有思维链可见，你只能看到最终结果，等到出了问题才意识到模型的判断是错的，那个时候恢复成本就高多了。

二是纯粹的学习价值。看一个高水平模型如何拆解和分析一个复杂的编码问题，对理解这类问题本身也很有帮助。比如它在分析一个性能瓶颈时，会先建立数据流的心理模型，列出可能的热点，然后逐个排查——这个思维过程本身就是值得学习的解题框架。对于刚入行或者面对不熟悉领域的开发者来说，把 AI 当作一个"思考过程可见的高级同事"来用，是很有意思的学习方式。

V4-Pro 的 Think Max 推理模式官方建议把上下文窗口设到至少 384K Token，这样推理过程才能充分展开，不会被截断。对于普通的编码任务，默认的思考深度已经够用；只有在处理特别复杂的架构决策或者多步骤推理任务时，才需要主动把推理强度调到最高。

4.3 完整工具套件

DeepSeek TUI 内置的工具套件覆盖了日常编码任务的绝大多数场景。这里有一个值得注意的设计理念：工具不是"给人看的功能列表"，而是模型在执行任务时可以自主决策调用的能力集合。模型会根据任务需要，自己判断什么时候应该先读文件、什么时候应该搜索网页、什么时候应该跑测试——用户只需要在审批门槛处决定是否同意执行。

文件操作类：

• read_file / write_file / edit_file — 读取、创建、修改工作区文件
• apply_patch — 应用标准 diff 格式的补丁，精准修改
• list_files / find_files — 目录浏览和文件搜索

Shell 执行：

• shell — 执行任意 Shell 命令，输出实时流回终端，Agent/YOLO 模式下可自动批准，Plan 模式下只读不执行

Git 管理：

• 支持 git status、git diff、git commit、分支操作等常见 Git 工作流，模型可以自主管理代码变更

网页工具：

• web_search — 搜索网页，补充最新技术文档、API 说明
• fetch_url — 抓取指定 URL 的内容（已内置 SSRF 防护，防止恶意重定向）

子智能体：

• agent_spawn — 创建独立子智能体处理特定子任务
• rlm_query / rlm_process — 并行推理与 RLM 循环执行

MCP 工具：

• 通过 Model Context Protocol 接入外部工具，工具审批流程与内置工具完全一致

v0.8.6 版本还新增了 LSP 诊断集成——每次执行 edit_file、apply_patch 或 write_file 后，系统会自动触发 LSP 钩子，收集编辑器级别的错误和警告，并在下一次 API 请求前将诊断信息注入为系统消息。这意味着模型可以"看到"它刚刚写的代码有没有类型错误、未解析的引用、语法问题，并在下一步自动修正。这个特性的价值不容低估——很多情况下，AI 写的代码"看起来对"但实际上有类型问题，没有 LSP 的情况下这类错误要到运行时才能暴露，有了 LSP 集成之后，模型在写完代码的当轮就能感知到问题并修复。目前支持 rust-analyzer、pyright、typescript-language-server、gopls 和 clangd。

# 各语言 LSP 服务需要预先安装，以 TypeScript 为例
npm install -g typescript-language-server typescript

# 以 Python 为例
pip install pyright

工具的权限管理是按模式分层的：Plan 模式下只有只读工具可用；Agent 模式下所有工具可用但需要逐步确认；YOLO 模式下所有工具自动批准。这套分层设计让你可以根据任务的风险级别选择合适的权限粒度，不需要"要么全开要么全关"的二选一。

4.4 100 万 Token 超长上下文

前面在介绍模型背景时已经提过这个特性，这里着重讲一下 DeepSeek TUI 在工程上是怎么处理它的，以及实际使用中有哪些需要注意的地方。

100 万 Token 对编码工作流意味着什么？最直接的好处是：你可以把一个中等规模项目的所有源码一次性塞进上下文，让模型在完整视野下工作。不再需要手动挑选"哪些文件要给它看"，不再需要担心模型因为只看到片段代码而产生误判。实际体验上，模型在有完整上下文的情况下处理跨文件依赖、重构涉及多层调用栈的代码时，准确率有明显提升。

默认情况下，DeepSeek TUI 利用 DeepSeek V4 的 prefix cache（前缀缓存）机制，在会话内尽可能重用 stable message prefix（稳定消息前缀），减少重复计算。这对于在一个长会话里反复修改同一段代码的场景特别有意义——后续 API 调用会命中 cache，大幅降低实际的 Token 消耗和成本。在使用中你会发现，同一个会话的第 5、6 次请求往往比第 1 次便宜很多，就是因为前缀缓存在发挥作用。

当上下文真正快满的时候，系统会显示"crowded"（拥挤）或"refreshing"（刷新中）的状态提示，TUI 底部还有一个"coherence chip"（连贯性指示器），用 healthy、crowded、refreshing、verifying、resetting 等状态来描述当前会话的健康程度，帮你判断什么时候需要干预。可以用 /compact 命令手动触发压缩，或者在 settings.toml 里开启 auto_compact = true 让它自动处理。

需要注意：官方建议谨慎开启 auto_compact，因为它采用的是替换式摘要压缩，会改变消息前缀，破坏前缀缓存，导致后续 API 请求的 cache 命中率下降，成本反而可能升高。如果你对成本比较敏感，手动 /compact 是更好的选择——在一个任务阶段完成后，你自己判断哪些历史上下文已经不需要了再压缩，而不是让系统自动触发。

4.5 三种工作模式

这三种模式覆盖了从"让我先看看再说"到"直接干，全权交给你"的整个光谱，是 DeepSeek TUI 工作流设计里最值得仔细理解的部分。

Plan 模式（只读探索）

模型在 Plan 模式下只能读取文件、搜索信息，不能执行写操作或 Shell 命令。它会在分析完工作区之后，给你一份详细的行动计划：打算修改哪些文件、每个文件改什么、理由是什么。你确认之后再切换到 Agent 模式执行。这个模式特别适合在改动一个陌生代码库之前，先让 AI 帮你梳理清楚再动手。

有一个细节值得注意：Plan 模式下模型的探索行为完全无副作用，但它的分析质量往往出乎意料地好。因为 V4-Pro 有 100 万 Token 的上下文窗口，它可以在分析阶段把整个项目的结构都读进来，形成一个完整的全局理解，而不是只看你指给它的那几个文件。这种"先通读后规划"的做法，比很多人类程序员在接手新项目时的做法还要系统。

Agent 模式（默认交互模式）

Agent 是默认模式，多步工具使用带有审批门槛。也就是说，在模型准备执行某个工具调用（比如写文件、执行命令）之前，会先向你展示它打算做什么，等你按 y 确认才会继续。这给了你在每一步操作上的完整控制权，既能利用 AI 的能力，又不会让它在你不知情的情况下修改任何东西。

在 Agent 模式下，审批提示不只是"确认或拒绝"，你还可以直接在提示里补充说明，修改模型的计划再继续。这个设计很聪明——它把"人机协作"的接入点放在了每一个关键操作上，而不是只在开始和结束时才能插嘴。

YOLO 模式（全自动）

YOLO（You Only Live Once）模式会自动批准所有工具调用，不需要人工确认。这个模式适合你已经非常信任当前任务、想要让 AI 全速跑完整个流程的场景。比如在一个专门的测试分支或临时工作区里，让它完整实现一个功能，不需要你在旁边逐步确认。

YOLO 这个名字起得很妙，既传达了"无拘束"的感觉，也暗示了"风险自负"的意思。用 YOLO 模式之前，最好确认两件事：当前任务的描述足够明确，没有歧义；以及当前工作区是干净的，方便出问题时用快照回滚。

启动时通过 --yolo 标志开启 YOLO 模式：

deepseek --yolo "按照 README 里的说明实现 user auth 模块"

4.6 会话保存与工作区回滚

这是 DeepSeek TUI 里我认为最"工程化"的一个设计，也是用 AI 改代码时最担心的问题的直接解法——万一它改坏了怎么办？

DeepSeek TUI 的解法是：side-git 快照机制。在 Agent 和 YOLO 模式下，每一轮操作前后，系统会在 ~/.deepseek/snapshots/<project_hash>/<worktree_hash>/.git 里做一次工作区快照。重要的是，这个 side-git 和你项目本身的 .git 是完全独立的，不会污染你的提交历史，不会产生乱七八糟的"AI 改动"提交，你的 Git log 依然干净。

这个设计的妙处在于，它把"AI 操作的可回溯性"和"项目 Git 历史的整洁性"这两个通常相互矛盾的需求都满足了。用传统的 Git 提交来追踪 AI 改动（比如 Aider 的做法）确实可以回滚，但会在你的提交历史里留下大量 AI 产生的临时提交，后续 review 和追溯时非常噪杂。side-git 把这部分完全隔离开，你自己的提交历史是你自己的，AI 的操作轨迹存在另一个地方，互不干扰。

回滚操作非常简单：

# 在 TUI 内
/restore 3    # 恢复到第 3 轮操作前的状态

# 或者通过工具（模型自己也可以调用）
# revert_turn 命令将工作区文件状态回滚，但不改变对话历史

注意 /restore 只回滚文件状态，不改变对话历史。这意味着你可以把文件恢复到某个状态，然后继续在原来的对话上下文里给模型说"你上次的做法有个问题，改一下思路"，不需要重新描述整个任务背景。

对于长时间运行的任务，还可以用 --resume 或 Ctrl+R 恢复上次的会话：

deepseek --resume --last    # 恢复最近一次会话
deepseek sessions           # 查看所有已保存会话

断网状态下发送的提示也不会丢失——系统会把它们排队存入 ~/.deepseek/sessions/checkpoints/offline_queue.json，等网络恢复后继续处理。这对于网络不稳定的环境来说是一个很实用的细节。

4.7 Skills 技能系统

这是 v0.8 之后加入的一个比较有趣的扩展机制，也是 DeepSeek TUI 在"可定制化"方向上走得最远的一个设计。简单来说，Skills 让你可以把任何可以用文字描述的"工作流约束"打包成一个可复用的指令包，然后在需要的时候一键激活。

每个技能是一个包含 SKILL.md 文件的目录，里面写的是给智能体的自定义指令。格式有一个简单的 YAML front matter 用来描述名称和触发条件，后面跟着具体的指令内容：

.agents/skills/my-workflow/
└── SKILL.md

---
name: my-workflow
description: 当需要按照公司代码规范提交 PR 时使用这个技能。
---

# 提交规范
- 提交信息必须用 Conventional Commits 格式
- 所有公共函数需要 JSDoc 注释
- 提交前跑 npm run lint:fix

系统会自动从多个目录发现技能，按优先级：工作区 .agents/skills → 工作区 ./skills → 工作区 .opencode/skills → 工作区 .claude/skills → 全局 ~/.deepseek/skills。名称冲突时，工作区本地技能优先。多级目录的设计还有一个好处——它和 .claude/skills 兼容，如果你同时在用 Claude Code，两个工具可以共享同一套技能目录，不需要维护两份配置。

实际使用上，Skills 最适合沉淀下面几类信息：团队的编码规范和风格要求（比"每次都在提示词里说"要可靠得多）；特定项目的架构约定和命名规则；测试覆盖率要求和测试写法规范；提交流程、分支命名、PR 描述格式等工程实践要求。

把这些约束写成 Skills 而不是每次都在对话里提，有两个实际好处。一是稳定性更好，SKILL.md 作为一个明确的文件，内容不会因为上下文压缩而丢失；二是团队协作更方便，把技能目录 commit 到项目仓库里，团队里所有人的 DeepSeek TUI 都会自动加载同一套约束，保证 AI 辅助产生的代码风格是一致的。

还可以从 GitHub 安装社区技能包，不需要任何后端服务，直接从 GitHub 仓库拉取：

/skill install github:<owner>/<repo>

4.8 MCP 协议扩展与 HTTP API

DeepSeek TUI 内置了一个完整的 MCP（Model Context Protocol）客户端，可以通过标准 stdio 或 HTTP 方式接入外部工具服务器。MCP 是一个开放协议，越来越多的工具开始支持它，这意味着 DeepSeek TUI 的工具生态可以随着整个 MCP 生态的成长而扩展。

举几个典型的 MCP 接入场景：接入公司内部的数据库查询服务，让模型可以直接查看真实数据来辅助调试；接入代码审查工具，自动运行静态分析；接入项目管理工具（比如 Jira、Linear），让模型可以读取当前任务描述来辅助实现。这些接入之后，模型会像使用内置工具一样自然地调用它们，审批流程也和内置工具完全一致。

# 列出已配置的 MCP 服务器
deepseek mcp list

# 添加一个本地 MCP 服务器
deepseek mcp add my-db-tool --command "node" --arg "/path/to/mcp-server.js"

# 添加一个 HTTP MCP 服务器
deepseek mcp add my-api --url "http://localhost:3000/mcp"

# 验证所有 MCP 服务器连接状态
deepseek mcp validate

此外，deepseek serve --http 可以把整个智能体运行时暴露为一个 HTTP/SSE API 服务器，支持在无头（headless）工作流中以编程方式驱动 DeepSeek TUI，比如集成进 CI/CD pipeline 或者自己写的自动化脚本里。这个功能对于想把 AI 能力嵌入现有工程工具链的团队来说，打开了很多想象空间。

五、安装与配置全流程

安装一个工具的过程虽然不是最有趣的部分，但往往是新用户流失的第一道门槛。DeepSeek TUI 在这里做得相当用心——提供了多种安装方式满足不同技术背景的用户，同时尽可能把每种方式的门槛降到最低。下面按照从简单到灵活的顺序逐一介绍，你根据自己的环境选择最合适的一种就行。

5.1 选择安装方式

DeepSeek TUI 有四种主要安装方式，根据你的环境选择最合适的一种。

方式一：npm 安装（最简单，推荐大多数用户）

npm install -g deepseek-tui
deepseek --version

npm 的 postinstall 脚本会自动下载和你的平台匹配的两个二进制文件（deepseek 和 deepseek-tui），并校验 SHA-256 哈希，然后把它们放到 PATH 上。整个过程基本是一键完成。

需要注意：必须同时安装 deepseek（调度器）和 deepseek-tui（TUI 运行时）这两个二进制文件，缺少任何一个都会在启动时报 MISSING_COMPANION_BINARY 错误。npm 包会自动处理这个，但通过其他方式安装时需要特别注意。

方式二：Cargo 安装（适合 Rust 开发者）

需要 Rust 1.85 及以上版本。

cargo install deepseek-tui-cli --locked   # 提供 deepseek 命令
cargo install deepseek-tui --locked       # 提供 deepseek-tui 命令
deepseek --version

如果在国内访问 crates.io 下载慢，可以配置 TUNA 镜像：

# ~/.cargo/config.toml
[source.crates-io]
replace-with = "tuna"

[source.tuna]
registry = "sparse+https://mirrors.tuna.tsinghua.edu.cn/crates.io-index/"

方式三：下载预编译二进制（适合不想装 Node/Rust 的场景）

从 GitHub Releases 页面（https://github.com/Hmbown/DeepSeek-TUI/releases）下载对应平台的两个二进制文件，放到同一个目录下（比如 ~/.local/bin/），然后：

chmod +x deepseek deepseek-tui
# 确保该目录在 PATH 里
export PATH="$HOME/.local/bin:$PATH"
deepseek --version

下载完建议用 SHA-256 校验文件完整性：

# Linux
sha256sum -c deepseek-artifacts-sha256.txt
# macOS
shasum -a 256 -c deepseek-artifacts-sha256.txt

目前支持的预编译平台包括：Linux x64（glibc）、Linux ARM64（glibc，v0.8.8 起支持）、macOS x64、macOS ARM64（Apple Silicon）、Windows x64。

方式四：从源码编译（需要 Rust 1.85+）

git clone https://github.com/Hmbown/DeepSeek-TUI.git
cd DeepSeek-TUI

# Linux 需要先装编译依赖（Debian/Ubuntu）
sudo apt-get install -y build-essential pkg-config libdbus-1-dev

cargo install --path crates/cli --locked   # 编译 deepseek
cargo install --path crates/tui --locked   # 编译 deepseek-tui

5.2 配置 API 密钥

安装完成后，第一次启动时会提示输入 DeepSeek API 密钥。可以提前通过以下方式配置：

# 方法一：通过 CLI 保存（推荐，密钥会写入配置文件）
deepseek login --api-key "sk-xxxxxxxxxxxxxxxxxx"

# 方法二：通过环境变量（适合 CI/CD 或临时使用）
export DEEPSEEK_API_KEY="sk-xxxxxxxxxxxxxxxxxx"
deepseek

DeepSeek API 密钥需要在 DeepSeek 官网（platform.deepseek.com）注册后获取。V4 系列提供了按 Token 计费的 API，目前 V4-Pro 还处于预览折扣期（写这篇文章时折扣有效期至 2026 年 5 月 31 日），成本相对较低。

5.3 settings.toml 主要配置项详解

DeepSeek TUI 的核心配置文件是 ~/.deepseek/settings.toml，也可以通过 TUI 内的 /settings 或 /config 命令交互式编辑。第一次用的时候建议用 /config 交互式命令来改，它会显示所有可用选项和当前值，比手动编辑 TOML 文件更直观。

# ~/.deepseek/settings.toml 示例配置

# 默认模型
[model]
default = "deepseek-v4-pro"

# 默认工作模式：plan / agent / yolo
[agent]
default_mode = "agent"

# 上下文压缩（默认 false，建议手动管理）
[context]
auto_compact = false

# 界面语言：auto / en / zh-Hans / ja / pt-BR
[ui]
locale = "zh-Han