近半年如果你关注 AI 客户端、MCP、Agent Memory、Computer Use 这些关键词，就会发现很多 AI 工具正在从“聊天窗口”变成更完整的 Agent 工作台。
这也是今天要聊的开源项目——DeepChat 演变的路线。一开始它是一个 Chatbot，后来逐步演进成一个 Local First 的 Agent 客户端：对话、文件、记忆、模型配置都尽量放在本地，也支持 MCP、Skills、Computer Use、Agent Memory 等能力。
在本文 DeepChat 的两位作者，会和我们聊了聊这个项目的起点、产品演进、技术实现，以及他们最近在探索的 Agent Memory。
DeepChat 是一款本地优先 Agent 桌面客户端，GitHub ：github.com/ThinkInAIXYZ/deepchat
本次专访嘉宾：
夕阳针：DeepChat 最早的开发者之一，有多年跨端和全栈开发经验，做过移动端、桌面端 App，也接触过前端、后端等不同方向。工作之外，喜欢骑车和拍照。
灰灰：DeepChat 核心贡献者，早期主要负责模型接入，最近主要在 DeepChat 实现 Tape]和 Agent Memory。作为开源爱好者，陆续给 DB-GPT、NewAPI 等项目提交过 PR。平时喜欢折腾 AI 相关项目和网络代理工具。
Tape 是一种将 Agent 的上下文、记忆、运行轨迹（trace）和可观测性统一在同一个“只追加、不可变的事实记录带”上的底层抽象架构。
由于这次专访聊得比较长，如果你想先快速了解，可以先看下面的“懒人版”。
一图胜千言·懒人版
DeepChat 的诞生
DeepChat 是什么
小七：先来和大家介绍下 DeepChat 是什么？你想开发者怎么使用它？
夕阳针：DeepChat 现在定位是一个 Local First 的 Agent 客户端。它原来可能是一个 Chatbot，这样一路发展过来，有一点一直没有变，就是我们坚持本地优先。
不管是更好地支持你本地的模型部署，还是你的数据和交互，我们都尽量往本地客户端放，把数据留在本地，并且做加密。粗浅地说，现在的状态可能就是一个不限制模型和供应商的“ChatGPT + Codex”合起来的形态。
对开发者来说，我更希望他们把 DeepChat 当成一个客制化键盘。你直接拿它当工具当然没有问题，但我更希望你把它拆掉，自己在上面折腾，客制化出一个顺手的 Agent，或者任何你想要的形态。
灰灰：我从重度用户的角度补充一下。对我来说，DeepChat 首先就是针哥刚刚说的，本地优先的 Agent 平台。它没有非常多限制，这点我非常喜欢。所有对话、文件、记忆等等，都是在自己电脑上。
这会带来一个比较长远的思考：当我们越用越多，把内容拼得越来越多的时候，它应该要能越来越懂你。当然，这个“越来越懂你”，DeepChat 现在还处在探索阶段，因为 Memory 没那么好做。这个苗头其实也是从把 Tape 接进来之后，才开始比较明显。
做 DeepChat 的初衷
小七：那你们一开始为什么想做 DeepChat？
夕阳针：这个我之前写过一篇博客「2024 VueConf」，讲过这个事情。
最早是 2025 年 1 月份，那个时候 DeepSeek 开始火了，网页大家都登不上去，于是大家就拿 API 去调。当时我比较喜欢用 Cherry Studio，而且我是 Cherry Studio 的重度用户。
那时候工作上有一个事情：我要调 Prompt。Cherry Studio 当时有个问题，它不支持多个会话一起弄。比如老板让我调三个不同的 Prompt，我必须等一个调完，再发下一条。这就很难受。
我一开始想给他们提个 PR 修这个问题，结果发现它是 React 写的，我又特别不会写 React，折腾半天没搞定。
后来一怒之下，想自己造个轮子。刚好遇到了 Golang 社区的谢孟军，他在做一个新的 AI 社区，说想做一个商业化、比较友好、全新的 Chatbot，问我有没有兴趣一起弄。我觉得这个思路挺好，而且我自己很喜欢写 Vue。我看了一圈，好像没有人用 Vue 写 Chatbot，那我就写一个。
当时 DeepChat 就这么开始了。其实一开始就是一个很“一怒之下”的想法，莫名其妙就开始写了。
灰灰：这个其实我跟针哥有一点点类似。因为我一开始也是 Cherry Studio 的重度用户。它一开始挺稳定，但后来赶上 DeepSeek 那波热潮，Cherry 狠狠火了一把。
但是当时它对 PR 的审核机制，还没有现在这么标准化。它越更新，我发现问题越多。我当时也想过给 Cherry 提 PR，但热度实在太高了，有时候我 idea 刚想出来，别人已经提 PR 上去了。
我就想着，要不我找一下 Cherry Studio 平替吧。其实我找了非常多 Chatbot，基本都那时候市面上的 Chatbot 都逛了一圈。
最后，社区朋友给我推了 DeepChat。我发现这个项目跟我当时用的 Cherry 版本对比，好像更稳定，而且界面风格我也更喜欢，就干脆切过来了。
在使用的过程中，我发现它还有一些小瑕疵。于是，我干脆提 PR 一起把 DeepChat 做得越来越好一点。
一开始我和针哥是通过邮件联系的，从第一个 PR「#636」开始慢慢一起开发。一开始的那一批 PR 都是比较用户视角的东西。哪里不好用，我就修哪里。后面越做投入越多，几乎每天都会看一眼 issue 或 PR，看看还有哪些功能点可以加上去，再跟针哥探讨一下。如果他也觉得没啥问题，我就开始搞。整体大概就是这么一个过程。
Local First 的设计初衷
小七：刚刚夕阳针提到了 Local First。我想问一下，你们为什么把产品设定成 Local First？
夕阳针：这里有几点考虑。
第一个点是我自己本身算是一个隐私爱好者。我希望尽可能把很多东西保护起来。虽然我在社交网络上是一个很透明的人，但我觉得人应该有这样（保护好自己隐私）的权利。
第二个点是，AI 刚出来的时候，我们觉得好的上下文才能得到好的结果。你给它的 context 越贴近你自己，它出来的结果一定越符合你想达到的目标。
我们当时调研了各种平台，觉得个人电脑应该是拥有你最多上下文、也是最准确上下文的地方。尤其是工作类场景和创作类场景，大部分数据都在你的个人电脑上。虽然你可能在云盘有备份，但你最完整的 workspace 一定是在电脑上。
所以我们当时就觉得，不管后面形态怎么迭代，Local First 会很重要。因为它能够接触到你最核心、最懂你的那些数据。
另外，Local First 做隐私和安全相对更好做，也能够打消很多人对 AI 滥用后个人信息泄露的担忧。
小七：好奇问一句，你们接触下来的用户，对隐私这一块在意程度如何？会有人在便利和隐私之间，选择便利吗？
夕阳针：其实还是有不少在意的。
DeepChat 其实有不少海外用户，我们经常会遇到一些欧洲的学校，和未知国籍的程序员，发英文邮件给我们咨询隐私问题。
之前有个学校教授给我们发邮件，说他给学生做 AI 演示和实验的时候用了 DeepChat 项目。由于 DeepChat 有自动更新机制，一旦有新版本就会自动去我们官网请求更新。这个教授发现了这个请求，他有些不理解：这个请求和 AI 模型连接无关，为什么会有存在这样的的连接。所以，保护隐私这块还是很有意义的。
最近，有一个国内用户和我说，你们所有模型的 key 都存在本地，我拿别的 Agent 可以直接去读这些 key，再上传到互联网，刷你的模型额度、用你的 Token。为此，他给我们提了一系列规避 API 被盗刷的技术方案。在他的建议下，DeepChat 做了和系统 Keychain 的结合。
现阶段，DeepChat 应该是现在几个主流 Agent 客户端中比较早做了强数据加密的客户端。它的整个 SQLite 都是加密的。之前还被人开玩笑说，DeepChat 能导入别家的数据，但导不出我们的数据给别的 Agent。自然，这是个玩笑。如果你想把 DeepChat 里的数据导到其他 Agent，其实有一个开关。用户授权后把密钥打开，就能导出 DeepChat 的数据给其他 Agent 用。
不过，确实大部分用户觉得，在便利上可以让渡一些隐私，这是更常见的情况。
DeepChat 的升级之路
从 Chatbot 到 Agent 客户端
小七：DeepChat 从早期版本到现在，有哪些关键性的功能迭代？
夕阳针：最大的一个迭代，应该是在 2025 年下半年到今年初这个阶段。
去年 9 月份的时候，我去拜访了 Cherry Studio 的办公室，和他们当时的团队聊了很多关于 Agent 后续的想法和畅想。也是那个时候，Claude Code 这些 Agent 开始火了。
Cherry Studio 成立公司之后，会开始考虑产品商业化的事情。和 DeepChat 这种纯开源、为爱发电的社区不大一样。他们有很多见解，和他们聊完之后，我觉得很有意思。
回来之后我写了一篇文章写「在 DeepChat 停止开发前」说我要停止开发一下。其实是当时我们决定把整个 DeepChat 从 Chatbot 改成 Agent 客户端。
就是这次，几乎是把原来的 DeepChat，包括模型层、界面，全部推翻重做了。这个过程，大概花了三、四个月的时间。
这是 DeepChat 开发过程中一个非常关键的迭代。DeepChat 从 Chatbot 变成了现在这种有点像 Coding Agent，或者说通用 Agent 的形态。现在回想，当时还是做了一个蛮大的决心，因为很多东西和去年那时候的版本相比，真的全部不一样了。
灰灰：针哥讲的是整个项目的视角，我补一个我的开发视角。
我第一个 PR 是在 2025 年下半年，去年七、八月份那会儿。那是非常疯狂的一个时期，每周都有新模型。GPT-5、GLM-4.5、千问、豆包、Grok，感觉上这些模型几乎每天都在发新版本。
模型发版变频繁之后，就有用户来问：为什么 DeepChat 现在还用不了某个版本的模型？
那两个月我光模型接入提交的 PR，可能就有三、四十个。平均算下来差不多两天一个的频率。其实，接模型不是只接一个名字那么简单。
举个例子，模型要不要开启思考（Thinking）这个功能，各家模型的表达方式都不一样。当时每次千问发模型，我就会喊俊旸哥：快点让你的小伙伴们更新一下 API 接口。Qwen 发版经常是模型发得热火朝天，结果自己的 API 接口没跟上。不过，后面 API 同步更新的速度是慢慢跟上来了。可惜现在俊旸哥走了，没有地方吐槽了。
再后来我跟针哥商量，我们是不是应该把模型配置做成外置化。于是，就做「PublicProviderConf 」这个Repo，针对这些模型单独衍生了一个庞大的数据库。它实际上是通过上游 「models.dev 」的数据，再加上我们对 OpenRouter 等一系列 provider 做全量模型 DB。维护这样一个 DB 会有一个好处，当上游更新不及时的时候，我们可以主动往这个 DB 里加新的模型，调整有问题的参数等，非常方便。同时，我们会把基础参数及能力等都放在这份 DB 中，后续 DeepChat 只需要写一个简易的解析层，就能完成所有的适配工作，而不需要写很多客制化的代码。比如要不要针对 gpt-5.5 多放一个 xhigh 的参数等等。
然后就到了 2025 年底、2026 年初，整个 DeepChat 开始转成 Agent 客户端。最近，我的开发重心就是把 Tape 接进来之后的 Memory 开发。
一个月发版 10+ 在迭代什么
小七：我看了一下，5 月底到现在，DeepChat 发了包括 「v1.0.5」、「v1.0.6」、「v1.0.7」 在内的 10 多个版本。这个发版本速度算是很快了。迭代得这么快，可以简单介绍下这几个版本的重点是什么吗？
夕阳针：先补充一下，其实我们不止这三个版本。DeepChat 的 Beta 版基本上是一到两天发一个。如果有完整功能合进去，我们就会发一个 Beta。
针对这三个大版本，我们其实有自己的规划。v1.0.5 主要是一些用户交互、细节打磨，还有灰灰做的一些东西。v1.0.6 可能是灰灰工作量最重的一版，他加了非常多 Tape System 相关的东西。
我在 v1.0.6 做得主要功能是 Computer Use。我们跟 Codex 差不多同一时间做了 Computer Use。开源社区里有一个项目叫 「Cua」，做得非常好，它把 Computer Use 的基础能力都暴露出来了。我一直在追这个项目的更新，然后把它集成进了 DeepChat。
不过，DeepChat 只集成了 Cua 很小一部分，毕竟 Cua 是一套完整的 Computer Use 解决方案，我只集成了它的驱动部分。然后按照 DeepChat 的实际需求进行修改、适配，看客户端需要哪些 Computer Use 能力。
上个月（六月）中旬左右，Cua 支持了 Windows 和 Linux 的 Computer Use，我又做了一次比较大的集成工作。这是 v1.0.6 中我的主要开发工作。
v1.0.7 当时的规划是把闲聊 Chat 模式加回来。因为很多用户跟我们说，他们还是想要 Chatbot。DeepChat 最后的 Chatbot 版本停留在了 「v0.5.8」，有不少用户 fork v0.5.8 后自己迭代 Chatbot。
所以，在 DeepChat 的 v1.0.7 中单独划了一块区域，让用户可以像之前版本一样当它是个 Chatbot，或者是当个 Agent 用。
灰灰：我从 v1.0.5 开始说吧。
我第一次了解到 Tape 其实非常早。当时 PsiACE（Bub 作者）把 Tape 引入 Bub 之后，我一直在留意它。
我觉得 PsiACE 的实现思路非常有意思。他觉得我们跟大模型探讨的任何东西，都应该像一条无休止的纸带，一直记录下来。当然在一些关键点位，需要有额外的记录。
这个跟现在整个 Agent 领域的一些想法很接近，就要把完整的用户对话记录尽可能延长下来，让 Agent 工作流更持久。
用户在做一件事情的时候，一般会在一个会话里和 Agent 交流。这个会话里有很多关键点位，比如什么时候需要 handoff，什么时候要 compact，什么时候有 tool use。这些信息记录下来后，对后面的 Memory 非常有用。
现在 DeepChat 的 Memory 基本上也是依赖 Tape 中的事件记录。它会把所有对话信息、关键点位、工具调用都记下来。这样，后面我已经完成了一次完整上下文之后，如果往下对话还需要上文的某些内容，我就可以通过 Tape 的关键点位，找到那个关键点上下的上下文。
这是 Tape 真正吸引我的地方。所以，v1.0.5 中我做的第一个大工程，就是先把 Tape 接进来。而后 v1.0.6，Tape 接进来之后开始做 Memory 这块工作。因为，我觉得 Tape 很适合往 Memory 方向转。
后来，DeepChat 社区另一个核心开发者 「zhangmo」，提了一个人格记忆的 「PR#1770」。我虽然 review 了那个 PR，但它合得很快一下进了主分支。这 PR 和我想基于 Tape 做的 Memory 还有一段差距。既然 Memory 这个事情被人提起来了，我就想赶紧把这部分内容完整实现了。
于是，这一、两个月我投入最多时间的工作，就是先把 Tape 这条线补上完整校验和溯源。这有点像给 Agent 执行过程装上一个类似飞机黑匣子的东西。有了它之后，再参考市面上一些 Memory 工具和平台，造一个属于 DeepChat 的 Memory System。
此外，v1.0.6 还集成了 「OpenDAL」（一个数据访问层）。因为之前有用户提过 S3 存储、数据上云这些数据需求。「zhangmo」先实现了一版基于 aws-sdk 实现的同步方案，但我之前「xuanwo」 那刚好看到 OpenDAL 这个项目，只需要写一下简单范式，就能把很多存储接进来项目中，因此就将同步方案改成 OpenDAL 了。
v1.0.7 这个版本主要是把 Memory System 进一步加强。契机是我在推特上转发了针哥的文章，私下去请教了 PsiACE，了解他对 Memory 的看法，以及为什么 Bub 到现在还没把 Memory 放进来。同时 PsiACE 还将 yihong 大哥之前在 Bub 实现的初版 Memory「PR#33」 让我参考。请教过后，自己整合了一部分优点，加到了 DeepChat v1.0.7 里。
现在我有不少研究生朋友，他们整个实验室都在用 DeepChat。他们在读论文、写论文、写实验代码的时候，就会用到记忆功能。我做了 DeepChat 的记忆系统之后，他们就说“为什么你不早点做这个东西？”。
因为很多研究员会有一套相对固定的方式去写论文和实验代码。只要 DeepChat 的 Memory 记住了，后面他们要 Agent 干活就可以快速从记忆中拉出这个方法论去读写论文或者是编写实验代码，甚至他们现在觉得以前写的一些 Skills 都可以删掉了。
这里，还有一个 todo：怎么进行 Memory 的自我更新。在后面的 DeepChat 版本中，我应该会实现这个需求。
DeepChat 中的技术细节
模型接入怎么做抽象
小七：模型接入这块，DeepChat 在架构上是怎么做抽象的？
夕阳针：这个比较有意思。
一开始我们维护了一整套（API）请求。因为 OpenAI、Claude、Gemini 这几个模型的 API 彼此都很不一样，所以 2025 年上半年我们做适配做得很痛苦。不止如此，第三方模型平台会魔改模型 API，往里面加很多奇怪的参数。
我们当时对每个模型供应商都写了一个对应的 provider。比如七牛 provider，会针对七牛模型接口做一系列适配；OpenAI provider 就是接 OpenAI。
我个人很喜欢读文档，会很认真地把各家文档都看完之后，再实现一个接入版本。当时，这些 provider 我维护了很久，也加了很多小的“黑科技”。
比如，DeepChat 从很久之前就能看到一些供应商的账户余额。像国内的硅基流动、PPIO，还有国外的 OpenRouter，你都能在 DeepChat 中看到它们的余额。除了模型 API，我还看了 AI 公司能被 DeepChat 用上的相关 API，再针对这家厂商封装一个小 SDK。
比如 Vercel 出的包括流式渲染、请求在内的一系列 AI SDK，我都第一时间去尝试接入。但 Vercel 有个毛病，他们很喜欢把半成品先扔出来。所以，DeepChat 适配这些就会出很多问题。不过，Vercel 迭代得快，过一段时间这些问题都解决了。现在 DeepChat 最底层，包括 OpenAI、Claude、Gemini 在内的这些模型，全部都换成了 AI SDK 接入。
此外，DeepChat 保留了对每个厂商的二次封装。如果厂商的余额、token 用量、模型参数有自己的配置，DeepChat 就会结合 public provider config 那边配置后给出更准确的版本。
这样设计，provider 配置可以做很多细致的工作。
比如有些厂商是聚合站，既有 Anthropic 接口，也有 OpenAI 接口，而且二者是互通的。你可以用 OpenAI 接口去调 Claude 模型，也可以用 Anthropic 的接口去调 GPT 模型。这时候，如果上下文组织没做好，按 OpenAI 最普通的方式去组织上下文，就会丢失缓存，让模型使用费用变高。
所以，DeepChat 中某些 provider 会做模型路由。因为中转站一般会有前缀，用来区分这个模型来自哪个供应商。这样，我就可以根据供应商分配最适合这个模型的接入端点。用 Claude 模型时，就自动切到 Anthropic API 的 SDK；用 GPT 时，再切回 OpenAI。这样所有 cache、缓存命中，基本能符合预期，不会出现缓存突然飘走的情况。
这就是我们之前手动维护一整套 provider 后得到的经验。虽然现在最底层换成了开源社区都在用的 AI SDK，但上面还是做了一层封装，保障定制化能力、缓存命中率，以及对上下文更好的掌控。
灰灰：我补充模型元数据这一块。
刚刚提到 public provider config，立项初衷就是因为客户端适配来适配去都是这些模型。但模型的上下文长度、是否支持视觉等这些功能都不同，我们决定还是要维护一套属于 DeepChat 的 repo。
有了 public provider config 之后，DeepChat 只要写一个接入层信息，去说明模型有哪些能力，有没有思考能力，DeepChat 这边只需要解析上游给到的配置信息，就能解决这个模型是否展示这个按钮，不需要再有对某些模型去做额外的代码适配工作。
例如 minimax 的模型配置，就可以用这个 json 来表达
{
"id": "MiniMax-M2.7-highspeed",
"name": "MiniMax-M2.7-highspeed",
"family": "minimax",
"display_name": "MiniMax-M2.7-highspeed",
"type": "chat",
"attachment": false,
"reasoning": {
"supported": true,
"default": true
},
"temperature": true,
"tool_call": true,
"structured_output": false,
"release_date": "2026-03-18",
"last_updated": "2026-03-18",
"open_weights": true,
"modalities": {
"input": [
"text"
],
"output": [
"text"
]
},
"cost": {
"input": 0.6,
"output": 2.4,
"cache_read": 0.06,
"cache_write": 0.375
},
"limit": {
"context": 204800,
"output": 131072
},
"metadata": {
"selection": [
"latest",
"fast",
"coding"
],
"lifecycle": "active",
"sourceProvider": "minimax",
"sourceProviderName": "MiniMax",
"sourceDocs": [
"https://platform.minimax.io/docs/guides/models-intro",
"https://platform.minimax.io/docs/api-reference/api-overview",
"https://platform.minimax.io/docs/guides/text-ai-coding-tools"
],
"sourceStatus": "seed",
"apiListed": false,
"source": "public-provider-conf"
},
"vision": false,
"extra_capabilities": {
"reasoning": {
"supported": true,
"interleaved": true,
"summaries": true,
"visibility": "summary",
"continuation": [
"thinking_blocks"
],
"default_enabled": true
}
}
}
这样，就不需要每次有新模型，都要单独为这个模型做个适配，单独处理开关。（补充说明：这里的开关指的是一些特殊设定，比如模型要不要打开视觉支持、是否支持温度等基础参数配置）
夕阳针：我加一个补充点。public provider config 这个项目，目前基本上是 AI 在自主维护了。
我们把结构定义好之后，后面需要增加新东西，可以直接给 Agent 发一下需求。我们有一个 Agent 的打工时间是 7×24 小时，每半个小时就去检测几个大厂有没有发新模型。如果发了新模型，它会自动把配置写进去。
虽然上游的models.dev 是一个很大的项目，有很多人给他们提 PR 但不一定及时被合并。比如 Kimi 今天发新模型，models.dev 不一定几分钟或几个小时内合进去，可能要等第二天早上才会合并 PR 有新的模型配置。
所以，DeepChat 如果有自己的配置机制，可以非常及时地同步模型的更新。一检测到模型厂商发新模型，就立刻把 patch 打进 DeepChat。用户在几分钟内就能拉到这个模型配置，正常使用。这个体验对用户会非常友好。 当然，如果后面上游 models.dev 有了新配置，这边会把自己写的配置删掉，以上游的配置为准。
灰灰：这个体验确实好。我的很多研究生朋友，有时候新模型一出来，就想第一时间用上。早期 DeepChat 没做好配置时，需要我们人肉发版、打包发给用户。现在，用户只要在设置里刷新模型元数据，就能直接用上最新模型。
DeepChat 中的 MCP
小七：MCP 在 DeepChat 里是怎么落地的？
夕阳针：这个是我写的第一个比较让我开心的功能。
DeepChat 的 MCP 最早的版本不是我写的。社区里有一个写 Golang 的小伙伴给 DeepChat 写了一整套 MCP demo。但由于他对 Electron 没那么熟，这个实现有一点小问题，会乱弹进程。虽然有些小 bug，但它跑通了 MCP。
我觉得它很厉害。拿到那个 「PR#121」后，我就基于他的版本去看实现代码，对比 MCP 官方文档去优化。但，说实话当时 MCP 官方文档写得特别差，好像没人维护一样。我就去翻他们 TypeScript SDK 的源码。让我发现他们正在开发一个叫 in-memory 的 MCP 协议。
当时 MCP Server 的连接方式主要是 SSE 和 stdio，大部分应用也是接入了这两种方式。DeepChat 也实现了这两个版本，然后发现 MCP 团队在做 in-memory 协议，可以把当前客户端的能力封装成一个 MCP 暴露出来。这样 tool call 就会变成一个非常好编排的方式。
当时还没有现在这种 Computer Use 的概念。如果把 in-memory MCP 协议做好，再封装一套文件增删查改工具，就可以做出一个很像现在 Computer Use 的东西。
所以，DeepChat 把这个 MCP 协议集成到了内部，调用 DeepChat 的代码去操作本地文件。为此，我还发了一个小视频「DeepChat MCP 超级功能」，展示如何把 DeepChat 开着，让它去帮我整理文件夹：DeepChat 会按照文件类型、后缀名、尺寸大小，帮你整理好文件，在当时看来非常酷炫。
当 DeepChat 的 MCP 功能终于调通之后，又遇到一个新问题：用户本地没有 Node 和 Python 环境的话，用 MCP 就会很麻烦。
我研究了下 Cherry Studio 是如何解决这个问题的。发现他们的做法是写了一篇特别友好的文章，教大家怎么安装 Node.js 和 Python。那篇文章确实写得很好，一开始我也把那篇文章发给用户，说你按这个装就能用 MCP 了。
但后来想了想，丢教程文档不是长久之计。于是，我就开始研究如何更优雅地解决这个问题。这让我发现了一个方案：将 Node.js 和 Python 运行环境内置到应用中，并用 uv 管理依赖，注入到项目。「uv」 是一个很小的工具，可以帮你下载依赖、Python 这些东西。
这样用户装完 DeepChat 之后，本地的开发环境就已经搭好了。他不用去考虑本地 Node.js 配置得对不对，要不要 sudo 权限安装包。MCP 配置里只要发现你填的是 npm、npx 这些命令，DeepChat 就自动转换成内部 Node.js 环境去跑命令。这就相当于集成了一套 Shell 环境到 DeepChat 中。
这个东西做完之后，我觉得特别好用，单独把它抽成了一个叫 「Tiny Runtime Injector」 的库，专门用来给各种 Agent 注入 Binary 环境。后面，它扩展出了 rtk、rg 这些 Agent 时代大家喜欢用的工具。它可以在运行时注入，也可以在打包时注入。
到这里，DeepChat 的 MCP 就相对比较好用了。基本上用户在哪看到一个好的 MCP，复制过来、粘贴进去 DeepChat，就可以直接用。不会再遇到发现“我的 npm 怎么跑不起来了”这种问题了。
再后来，我们给 npm 和 Python 源做了自动镜像选择，会根据当前几个镜像的速度，选择最快的那个，帮用户把包安装好。
所以 MCP 这块，我们是从一个非常简陋的 demo，一直打磨成比较可用的产品。这个事情还是让人很开心的。我以前很少在开源项目里把一个功能做到这么产品化、这么细，当时还是挺自豪的。
接入 ACP Agent 难在哪
小七：DeepChat 在接入 ACP 的时候，技术难点是什么？
夕阳针：ACP 最大的难点，是我们接得太早了。
那个时候 ACP 特别难接，只有一个文档，你只能在 Zed 里面调一下，大概看一下效果。Zed 当时也没有很好的调试窗口。
我当时和 Kimi CLI 那边的朋友聊了这个事。大家最痛苦点都是我都不知道自己实现的 ACP 对不对。
后来，我在 DeepChat 里做了一个 ACP debug panel，方便去调试 ACP 每个协议，看发出去的和收回来的信息对不对。做完之后，再去调 Codex 和 Claude 发现了一个问题：这些 Agent 到现在也不是原生支持 ACP，而是中间设置了一层中转，由 Zed 做的 adapter 把它们的 SDK 转成 ACP 协议。所以，调用 Agent 就更难了。
目前，我本地只装了 Claude 和 Codex。有时候，我发现我的 ACP 实现是对的，但调 Agent 却会失败。奇奇怪怪的问题很多，Kimi 是当时支持 ACP 比较多的项目，所以我很多时候是在 Kimi 上调试，把协议一个一个对齐。
到现在，ACP 还有这个问题，就是协议跟不上 Agent 的迭代。现在 Agent 中的很多功能，ACP 还不支持。比如 DeepChat 就遇到过一个问题：如果你控制 Codex 时不小心触发了它的 Computer Use，它会直接崩掉，告诉你这是不合法访问。因为这个调用链路在 Mac 上存在签名不一致的问题，DeepChat 是 DeepChat 的开发者签名，Codex 里的 Computer Use 是 OpenAI 的开发者签名。
这也是现在比较头疼的问题之一。
目前，ACP 用下来，感觉还是需要有一个比 Zed 更强硬的领头者，去推动协议发展。像 MCP 那样，形成更强的标准，让大家接入。
如果你的 ACP 客户端想面向 Codex 和 Claude 这类多用户的 Agent，那用户体验会比较差。但如果你只是想让 OpenCode 这类 Agent 都能玩，对开发者来说还是挺爽的。
ACP 还是得继续再发展下，现在还不够完善。
Skills、MCP 和 Memory 分别解决什么问题？
小七：下面这个问题比较通用。DeepChat 的 Skills、MCP，还有 Agent Memory，分别解决什么问题？
夕阳针：我来讲下 MCP 和 Skills。
先说 MCP。我们认为 MCP 是一个资源包。通过一个 MCP，可以提供一堆资源，包括工具、prompt，还有一些 resource，比如一张图或者一段代码片段，都可以通过 MCP 这个协议提供给模型。
一个比较有意思的例子是 MiniMax。他们在 Coding Plan 里面提供了一个 MCP 服务。早期 MiniMax 的模型没有视觉能力，它就通过 MCP 里一个 understand image 工具，调用识图能力，给模型补充视觉能力。
所以 MCP 就是一个扩充工具包，让你把原先的能力往外拓一层，让模型能操作更多相对稳定的东西。
Skills 更有意思。它比 MCP 更复杂一点，更主要作用的是说明书。当然，它可能也会带上一些额外产物，比如脚本，但很多时候它就是大模型的说明书。它会告诉你怎么完成一件事，怎么用一个工具，甚至怎么用一个 MCP。
我自己做很多东西时，会用 Skills + MCP 的形式提供能力。比如我用 JS 写一个 MCP Server，里面包含一些工具。然后我再给这个 MCP Server 写一个 Skill，把两个东西打包在一起发出去。
模型拿到 Skill 之后，会自动安装这个 MCP，装完之后就拥有了这个能力，可以跑起来。
DeepChat 里的 Computer Use 就是这样的方案。它背后真正接到电脑上的桥，是通过 Cua 项目提供的驱动来实现的。在它前面有一个 MCP Server，这个 MCP Server 怎么启动、怎么接到 DeepChat、DeepChat 对它有什么要求，其实是通过一个 Skill 来完成的。
所以，当用户在 DeepChat 里启用了 Computer Use 这个插件之后，Agent 会先看一个 Skill，叫 How to use computer use。看完之后，Agent 就明白每个工具应该干什么。
这比在 MCP 上写工具描述要精准得多。工具描述只能告诉你：这个工具是扳手，这个工具是锤子。但 Skills 可以讲清楚：你要完成这个事情，得先用锤子锤钉子，再用扳手拧螺母。这样最后做出来的事情会更可靠。
小七：那灰灰来分享下 Memory？
灰灰：对，我讲一下记忆这边。
以前的 Agent，简单来说可以理解成金鱼记忆，7 秒钟就忘了。每开一个新会话，它都对你一无所知。你最多只能在 system prompt 里写一段人设或规则，而且聊着聊着，随着上下文扩大，有时候还会被冲淡。
我们想要的是它能记住我上周跟它讲过的东西，我的博客用什么框架，我讨厌什么样的代码注释。这样，我再开一个新会话，它还能知道我的偏好。
做 Memory 之前，我调研了一段时间。核心的结论是记忆不等于 RAG。
很多人会理所当然地把外挂知识库当成记忆。但如果只是把聊天记录塞到向量库里再检索，那只是搜索性的日志，意义没那么大。
真正的记忆要走完一个完整闭环：什么时候应该记，什么时候应该巩固，什么时候应该遗忘，需要的时候才召回，最后还要能从一堆事实里长出洞察。检索仅仅只是其中的一个步骤而已。
这个“长出洞察”其实是我目前还没做的内容。我希望后面可以通过一些手段，对以往 Memory 进行总结，长出新的 Skill，或者更新已有 Skill。
这部分我跟 PsiACE 沟通时，感觉意义是最大的。但无法避免的是它会带来越来越多 token 消耗。
回到 DeepChat，现在整个 Memory 架构，用一句话概括就是：Tape 是账本，记忆层是大脑。
Session Tape 是原始事实的流水账。我做什么事情都给它记下来，就像小时候写流水账日记一样。结构化消息、工具调用/结果、运行时事件和关键 anchor 会进入 session tape。
Memory 是从账本里蒸馏出来的耐久结论。它不是把完整上下文都拿下来，而是结论性的东西。
账本是证据，大脑是认知。数据从账本流向大脑。每条记忆都能反查，它到底是从哪几个句子、哪几个片段提炼出来的。
怎么避免它变成杂乱历史记录？这其实是 Memory System 的灵魂问题。
首先入口要收紧。不是所有东西都应该记下来。闲言碎语、聊家常，这些不应该抽取成记忆。即便进来了，也应该快速筛选，只保留稳定偏好、项目事实、任务结局、经验教训这几类信息。
我设计记忆系统的时候，有一个规则：只记住最小的、耐久性的结论，把过程留在 Tape 上。等需要用记忆时，再通过这个结论去找 Tape 里的原始上下文。
接下来是写入时的对质。每条新记忆入库之前，应该先跟库里最相近的 10 条记忆对质一遍。拿一个便宜的小模型来裁决，看是新增、更新旧的、取代旧的，还是重复不记。如果和现有记忆有矛盾冲突，就应该把这条记忆记录下来，不能盲目覆盖。这个过程可能还需要和人互动，这部分的交互我还在思考。
再接下来是遗忘。记忆会有衰减，有半衰期。长期没有用、从来没有被召回的记忆，会被软归档。注意是软归档，不是直接删除。因为未来某一天它可能又有用了，那时可以重新激活。
出口也应该有限制。召回时只取最相关的几条，有严格 token 预算。注入的也是相关记忆，不会把整个 Tape 完整塞进来。
最近我在完善 Memory 可视化，补了健康快照报表。因为一开始设计时，我没有把 Memory 的可视化展示给用户。用户可能感知不到这个黑匣子是真的存在，还是随便乱抽取。
所以我把它变成一个可以量化监控的图表：有多少条记忆从来没有被访问过，有多少条挂着冲突，有多少条没有做向量化处理。这些都可以一目了然。
这就是目前 DeepChat Memory System 的实现闭环。
Agent 安全机制的设计
小七：刚刚也提到安全问题。Agent 会接触各种文件，你们是怎么设计安全机制的？
夕阳针：现在还是比较常规。
一方面，一些函数会尽量遵循项目的 gitignore，以及你设定的 workspace 范围。除非用户特定说去读某个工作区之外的文件，否则默认会在提示词里强调不要乱跑。
但这个只是很小的限制。
第二个是权限系统。我们做了三个权限模式。一个是最标准的，什么都问你。一个是大家也用得很多的“油门踩死”，所有都不问，自动执行。
还有一个新加的叫 Approve for me，Codex 也有类似功能。模型会帮你 review 一下这个工具有没有风险，是不是访问了不该访问的东西。它会判断这个事情要不要做。如果不确定，再来问你。
此外，我还在看另外一个方向。Codex 开源了一套沙盒系统，它的 「CLI 是开源的」，里面那套沙盒系统其实可以拿来用，也可以移植到其他 Agent 里。
但我试过之后发现，这套沙盒系统有个问题：太严格了。如果真的打开，你很可能连自己系统里装的一些全局包都没法正常运行。比如 npm 安装的某个工具，或者 Homebrew 装的工具，因为沙盒限制，执行沙盒之外的命令就不正常。
这块我现在还没想好。引进来之后，对模型限制太大，暂时没有考虑太多。
还有一个我现在也在做、也在推动其他人做的方向：把 Agent 里的敏感信息做加密。不管是数据库，还是 key。
加密不是不让用户访问或导出，而是当其他 Agent 或 AI 来读取你的敏感信息时，你能够感知到，让用户去授权。这一步很重要。
如果每个 Agent 客户端都能保护用户敏感信息，那即便不小心读到，也不会有太大泄露风险。
现在最怕的是：我的 AI 读了一下 secret，或者读了一下某个 key，它不光发给模型服务，还存在本地数据库里。又来了一个 AI，把它再读一遍。每个 AI 的数据库里都存了一份你的密码，最后全世界都知道你的密码了。
这是现在我们做的一些限制。但我觉得还不够好。现在很多做安全或攻击研究的人，已经在用很先进的模型拼命找漏洞。所以我们的防御肯定远远不够。
但如果沿着这个方向继续走，又很可能让 Agent 客户端变成一个限制非常多的东西，模型可能会笨得令人发指。
所以这块我没有想得特别好。我觉得现阶段能做到最基本的围栏，让用户先正常把事情跑下去。后面希望像开头说的客制化键盘一样，有更多安全领域的人，或者有更好想法的人，把这些能力加入到 DeepChat 或其他 Agent 里。
灰灰：Memory 这一边的一些安全机制主要有这些：Agent 隔离，不同 Agent 有不同记忆。像我的研究生朋友可能有好几个不同角色的 Agent，不同 Agent 在专注某件事情时，它们的记忆应该不一样。这也在一定程度上起到了安全隔离。
还有审计日志和事件广播，我都刻意做成没有正文内容，只有编号、动作、数量。这样不会有任何记忆正文泄露。
DeepChat 接下来想做什么
小七：进入尾声了，我们来聊聊未来规划。DeepChat 未来半年想做什么？
夕阳针：我这个规划可能比较“搞笑”。我觉得 DeepChat 未来最想补上的能力，是宣传能力。（划重点，大家可以去用用 「DeepChat」
现在，这个工具本身已经非常好用了。我其实很少用 DeepChat 写代码。更多的时候，是用它做一些稀奇古怪的事情，比如做 Slide、找文件、写邮件、整理各种资料、生图。
但有一些长尾问题、边界问题，我一个人是发现不了的。所以，下一步是借助大家的力量，去挖掘 DeepChat 有哪些问题，更好的使用姿势是什么。
所以，未来半年我这边最想补的是宣传能力。教大家怎么用这个东西。只要有一个敲门砖，把它敲开之后，很多人就会 get 到里面一些设计，可能也能吸引更多人进来，把这个 Agent 变得更加好玩。
灰灰：我的规划更多是在功能上。
既然开了 Memory 这个坑，我就想尽可能把坑填起来。我对它的理念是：越用越懂你。
现在 Memory System 已经能闭环，但还有一些可以完善的地方。比如 Memory 质量。现在虽然它能记住，但我希望未来能更好地从一堆事实里长出真正有质量的 Memory。在未来，它应该自己能总结出“这个用户喜欢小步提交 commit，而不是整个功能实现完才提交”这种提交偏好。
像这种个人偏好，都应该从历史事实里发掘出来，而不是等你一开局就告诉它：“我喜欢分步提交 commit。”如果需要和 Agent 讲一大堆信息，它才懂你，那离真正懂你还差很远。
另一个是记忆可观测性。要让用户对 Memory 有完整的知情权和控制权。现在只做了一小部分，后面还有很多前端上的内容需要实现。
还有一个就是稳定性。稳定性是老生常谈。因为我自己最早就是因为稳定性切到 DeepChat，所以还是想不断完善 DeepChat 的稳定性。
小七：DeepChat 的 Memory 支持管理吗？
灰灰：支持。我今天刚好提交了一个 「PR#1868」。这个 PR 做的是，你在使用过程中，可以看到这一条回复到底引用了哪一个 Memory。如果你看到某条 Memory 是错误的，可以直接删除，不要用这个。那么这条 Memory 就会被软删除。
新手第一次体验 DeepChat，应该从哪里开始
小七：那新手第一次体验 DeepChat，你们建议他从哪个功能开始？
夕阳针：其实就是跟着新手引导走。
我们最近两个版本刚好做了还不错的新手引导。现在有一点比较好：如果你电脑里已经有 CC Switch 这种管理各种 key 的工具，或者有其他 Agent 配置，我们不需要你重新配一遍 key，它可以自动帮你把已有配置导入进来。
所以你会比较快上手。你直接在聊天里先聊起来就可以。用任何功能开始都行。先跟它聊一聊，感受一下整个交互是什么样的，它能做什么事情，比如让它帮你写个文档。之后再慢慢探索插件和其他功能，就很顺理成章。
灰灰：我主动推给朋友之后，他们第一次使用时，因为 DeepChat 会内置一些功能，比如已经装好一些内置 Skill，或者针哥开发的 YoBrowser，也就是 DeepChat 里内置的浏览器。他们只要配完 key，进行第一次对话，就会发现这个工具挺惊艳，然后就会继续用下去。
所以就是先开始。
两个 AI Coding 小技巧
小七：最后一个问题，分享一下你们觉得比较好用的 AI Coding 技能。
夕阳针：我这边是一个很多人可能已经知道的技能：用 ASCII UI 去表达交互和示意图。
我自己也写 TUI 工具，你会发现命令行里就是用 ASCII 字符来表示各种交互，比如选框、动画，都能做出来。
如果你在文档里，比如 DeepChat 是 spike-driven 这样开发的，你在写 spec 文档时，把 UI 交互用 ASCII 字符画成示意图，人也看得懂，模型也看得懂。
而且我们是 Vue 架构。Vue 有 SFC，一个文件里包含模板、逻辑和样式。现在样式可能比较少，因为大家都用 Tailwind，所以一个 SFC 标准形态大概就是一个模板加一段逻辑。
这刚好对应 spec 里的 ASCII UI 和下面的时序图，或者逻辑描述。你讲清楚这个控件要做 A、B、C、D 几件事，上面再用 ASCII UI 把控件画出来，还可以像 Figma 标注一样，告诉你这个按钮点了之后动画飞到哪里。
这样对我作为 reviewer 也非常方便。
我们把这部分直接放到了项目 Skills 里面。每一个在 DeepChat 提代码的人，都会自动使用这个 Skill 来画这样的 spec。每次我看它，就知道它到底在 UI 上改了什么。
开源项目里，你可以在 PR 上写很多要求，比如改 UI 时要截图。但不是所有人都会看。有时候人家提了一个不错的功能，你也不知道他改了什么，只能切到分支跑一下。但你可能正在开发别的东西，不方便切过去。
如果他用 ASCII UI 展示，你就能很清楚地看到：原来它把这个按钮放到了那边，或者改了一些样式。你再看逻辑对不对，最后有空稍微跑一跑，就能很快结束 review。
所以我的小技巧就是，多用 ASCII UI 描述交互和 UI。这是对人和模型都非常友善的桥梁。
灰灰：我最近用得比较多的是 Claude Code 的 Ultracode / workflow 能力**。我非常喜欢用它出 plan**。
它的核心是 dynamic workflow：你抛给它一个较复杂的问题后，它会先围绕当前仓库做代码探查，然后把任务拆成多个子任务，交给不同的 subagent 或 workflow phase 去处理。每个 subagent 在自己的 context 里读代码、分析实现，最后把结论汇总回主 Agent，由主 Agent 形成整体方案。
我自己对比过：不开 Ultracode 的普通 plan，和开 Ultracode / workflow 后出来的 plan，质量差距体感能有 30% 到 40%。如果再对比 Codex 直接写 plan，我个人感觉 Claude Code 的 Ultracode plan 更稳，尤其是在大仓库、跨模块、需要理解现有架构的场景里。
所以我现在的编码流程基本是：先让 Claude Code 用 Ultracode 出 SDD，然后把 Coding 部分下放给 Codex 去执行。最后再做 review。这样组合下来，比单独只用一个工具效果更好。
期间我也跟针哥提了一下，DimAgent 也应该加一下这个功能。前不久他们也做上去了。我感觉这挺厉害的，因为 Ultracode 透露出来的信息并不多，它是闭源的。针哥他们能把这个链路实现起来，其实花了很多功夫。
最后补充一下，我刚刚说的 plan 主要是针对 SDD 而言的。SDD 规范我觉得非常有必要。如果你看 DeepChat 源码，会发现我们大部分 PR 或修改都会配一个 SDD 文档。它其实就是把需求分析、方案设计、实现步骤、风险点和验证方式都结构化下来，相当于完整的 Coding 实现流程。
尾声
到这里，这次和 DeepChat 两位开发者的交流就结束了。
如果你正在关注 AI 客户端、Agent Memory 或 MCP 这类方向，DeepChat 是一个挺值得看看的开源项目。
延伸阅读
DeepChat GitHub ：github.com/ThinkInAIXYZ/deepchat
Fact model Tape：tape.systems/
DeepChat 的诞生：notes.anya2a.com/posts/deepchat-design-choices-explained
全能 AI 工作站 Cherry Studio：cherryai.com.cn/
写在 DeepChat 停止开发前：notes.anya2a.com/posts/roadmap-1-0-0
DeepChat 模型配置：github.com/ThinkInAIXYZ/PublicProviderConf
模型更新 models.dev：models.dev/
Computer-Use 基建 Cua：github.com/trycua/cua
数据访问层 OpenDAL：github.com/apache/opendal
DeepChat MCP 超级功能：channels.weixin.qq.com/finder-preview/pages/sph?id=AgA9oHu0yK
预置环境注入 Tiny Runtime Injector：github.com/zerob13/tiny-runtime-injector
OpenAI 开源沙盒 CLI：github.com/openai/codex/tree/main/codex-rs/sandboxing/src
