近半年如果你关注 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 其实非常早。当时 PsiACEBub 作者把 Tape 引入 Bub 之后我一直在留意它。我觉得 PsiACE 的实现思路非常有意思。他觉得我们跟大模型探讨的任何东西都应该像一条无休止的纸带一直记录下来。当然在一些关键点位需要有额外的记录。这个跟现在整个 Agent 领域的一些想法很接近就要把完整的用户对话记录尽可能延长下来让 Agent 工作流更持久。用户在做一件事情的时候一般会在一个会话里和 Agent 交流。这个会话里有很多关键点位比如什么时候需要 handoff什么时候要 compact什么时候有 tool use。这些信息记录下来后对后面的 Memory 非常有用。现在 DeepChat 的 Memory 基本上也是依赖 Tape 中的事件记录。它会把所有对话信息、关键点位、工具调用都记下来。这样后面我已经完成了一次完整上下文之后如果往下对话还需要上文的某些内容我就可以通过 Tape 的关键点位找到那个关键点上下的上下文。这是 Tape 真正吸引我的地方。所以v1.0.5 中我做的第一个大工程就是先把 Tape 接进来。而后 v1.0.6Tape 接进来之后开始做 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 meCodex 也有类似功能。模型会帮你 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/deepchatFact model Tapetape.systems/DeepChat 的诞生notes.anya2a.com/posts/deepchat-design-choices-explained全能 AI 工作站 Cherry Studiocherryai.com.cn/写在 DeepChat 停止开发前notes.anya2a.com/posts/roadmap-1-0-0DeepChat 模型配置github.com/ThinkInAIXYZ/PublicProviderConf模型更新 models.devmodels.dev/Computer-Use 基建 Cuagithub.com/trycua/cua数据访问层 OpenDALgithub.com/apache/opendalDeepChat MCP 超级功能channels.weixin.qq.com/finder-preview/pages/sph?idAgA9oHu0yK预置环境注入 Tiny Runtime Injectorgithub.com/zerob13/tiny-runtime-injectorOpenAI 开源沙盒 CLIgithub.com/openai/codex/tree/main/codex-rs/sandboxing/src