VOL.002｜DeepChat：为什么要做一块开源 AI 试验田？

概览

本期邀请 DeepChat 的两位核心维护者，回顾这个开源 AI 客户端从搜索型 Chatbot 转向 Agent 的演进过程。项目最初希望充分利用本地电脑能力，并以更开放的协议和技术栈构建一个可自由扩展的桌面客户端。

对谈重点解释了 Tape、Harness、Memory、Sandbox、MCP 与 ACP 等技术如何进入 DeepChat，以及它在企业二次开发、模型调试、代码审查、自动化运维和科研协作中的实际应用。

嘉宾认为，随着模型能力提升，AI 客户端的价值不会消失，而会更多地体现在连接模型与本地设备、物理世界和各类工程系统。DeepChat 希望成为 AI 前沿技术的开源试验田，为开发者提供可以验证、参考和改造的完整实现。

讨论最后延伸到 AI 时代的开发工作流与开源贡献：重复任务应逐步交给 Agent 自动执行，但贡献者仍需理解自己提交的代码，避免用大量未经验证的 AI 生成 PR 增加维护负担。

分段落总结

[00:06] 为什么从头开发 DeepChat

[事实] DeepChat 最初被定义为一个开源 AI 客户端，希望充分利用本地电脑的能力。

[事实] 团队认为当时已有客户端的协议和技术栈不够友好，成熟项目也较难介入，因此决定从头实现。

[事实] 早期版本主要由几位开发者快速完成，并采用开放方式持续吸收社区贡献。

[01:17] 维护者的开源经历

[事实] 两位核心维护者分别介绍了自己从文档修正、小型组件和实习项目开始参与开源，逐渐进入大型项目维护的经历。

[事实] 辉辉最初甚至直接通过 GitHub 网页提交代码，之后在社区成员指导下学习 Git 和规范的协作流程。

[事实] 嘉宾认为，开源项目可以帮助学生接触真实工程实践、阅读成熟代码，并在社区中完成从学习者到指导者的接力。

[10:18] 从搜索型 Chatbot 演进为 Agent 客户端

[事实] DeepChat 最初围绕低成本模型构建搜索型 Chatbot，通过浏览器获取网页内容，再交给模型整理和总结。

[事实] 项目早期自行实现模型请求、流式输出和 Markdown 渲染，后来逐步采用成熟社区组件，并针对不同模型供应商进行适配。

[事实] 由于模型交互、本地 I/O 与界面渲染从一开始就相对分离，项目只用较短时间便从 Chatbot 迁移到 Agent 客户端架构。

[事实] 团队借鉴社区的 Tape System，将上下文设计为追加式记录，并通过移动窗口组织 Agent 当前可见的信息。

[15:14] Tape、Harness 与自动化任务

[事实] 团队此前已经尝试过追加式上下文、位置指针和压缩机制，但尚未形成统一系统；看到社区的 Tape System 后，才将这些思路组合成完整 Harness。

[事实] DeepChat 已被用于定时聚合数据源、更新公共配置，以及执行其他无需人工持续介入的日常任务。

[事实] 项目会快速集成社区的新能力，包括 Computer Use、远程通道和外部知识系统。

[推测] Tape 的核心价值不仅是保存对话历史，也在于让 Agent 能够在长任务中自行回看记录，减少传统上下文压缩造成的信息丢失。

[17:44] Memory 的价值与边界

[事实] DeepChat 集成了 Memory 功能，用于沉淀对话经验，并让这些经验能够在研究团队或不同任务之间复用。

[事实] 嘉宾认为 Memory 在日常对话、架构设计和多项目管理中较有价值，但在普通编码任务中未必总是必要。

[事实] 在大型架构重构中，项目级记忆可以提醒 Agent 当前目标，避免它持续参考旧代码并重复旧方案。

[事实] 统一记忆还能汇总分散在不同设备和项目中的反馈、待办与审查任务。

[20:33] DeepChat 的实际使用场景

[事实] 企业可以基于 DeepChat 二次开发内部 AI 客户端，限制可用模型供应商，并连接自己的算力与知识库。

[事实] 模型部署人员会使用 Trace 和 Tape 检查器验证 Tool Call、推理内容、多轮对话及模型循环等问题。

[事实] 维护者会利用多个 Agent 并行进行代码审查、翻译和定时任务，并分配不同订阅中的 Token。

[事实] DeepChat 也被用于远程查看并控制 Mac mini，在进程异常时截图、终止进程并重新启动服务。

[24:33] 消息平台接入与 OpenClaw 的启发

[事实] DeepChat 接入 Telegram、飞书等消息渠道的灵感来自 OpenClaw，部分接口也复用了其生态形成的方案。

[事实] 团队早期只支持单向消息投递，在相关生态成熟后才加入双向交互。

[事实] 嘉宾认为，OpenClaw 推动多个平台开放机器人接口，降低了 AI 应用进入既有消息系统的门槛。

[25:20] 与其他 AI 客户端的差异

[事实] 不同客户端采用了不同扩展思路：有的强调“一切皆插件”，有的允许替换 Harness，DeepChat 则同时维护自己的 Tape 与 Harness，并通过 ACP 驱动外部 Agent。

[事实] 插件系统具有较高灵活性，但上游发生破坏性更新时，插件需要持续跟随适配。

[事实] DeepChat 更偏向开发者和 AI 基础设施工程师，会较快集成新技术；其他产品则可能更强调普通用户体验和稳定性。

[事实] 团队将 DeepChat 的重要价值概括为：既是可用客户端，也是社区研究 Tape、ACP、安全审查等实现方式的参考项目。

[31:06] 隐私、本地运行与 Sandbox

[事实] DeepChat 从早期便重视把个人数据保留在本地处理，但随着远程任务和托管需求增加，Sandbox 成为需要考虑的基础设施。

[事实] 当前 Harness 与桌面端集成较深，不像拥有独立核心的工具那样容易直接放入 Sandbox 运行。

[事实] 团队考虑把 Harness 与界面进一步拆分，并可能重写高负载核心，以降低多任务和大量 Subagent 带来的内存及 CPU 压力。

[事实] 嘉宾认为 Sandbox 能隔离风险，却也会限制 Agent 对真实电脑的控制；理想形态需要在人机共同操作、数据访问和防止误删之间取得平衡。

[37:33] 开发计划、MCP 与性能优化

[事实] 团队没有固定 Roadmap，原因是技术迭代很快，许多计划在正式写完前便已实现。

[事实] 近期方向包括补足 MCP 新版本的兼容问题，并探索结合 Code Mode，让模型通过 SDK 和文档按需调用大量 MCP 工具。

[事实] 另一个重点是把 Harness 和最小核心从桌面端剥离，以改善多任务并发时的性能。

[事实] 嘉宾指出，Agent 任务中的高 CPU 工作一旦阻塞 Electron 主进程，就会使整个桌面应用卡顿，因此界面和任务执行需要更彻底地解耦。

[41:11] 模型更强之后，客户端还有什么价值

[事实] 嘉宾认为当前 Agent 仍然很笨，完成一个任务经常需要多轮沟通，但未来这种交互成本会继续下降。

[事实] 即使模型越来越强，它仍需要软件作为连接设备、电脑和物理世界的桥梁。

[事实] DeepChat 希望长期充当开源社区的 AI 技术试验田，让开发者能够直接查看源码、验证新概念并进行二次开发。

[推测] 在这一定位下，DeepChat 的核心竞争力并非单一功能，而是把快速变化的 Agent 工程方法及时转化为可运行的开放实现。

[44:09] 坚持自有 Harness，并用 ACP 连接外部 Agent

[事实] DeepChat 计划继续以自己的 Tape 和 Harness 为主，而不是在产品内部并列维护多套 Harness。

[事实] 对外部 Agent，团队更倾向通过 ACP 协议进行集成，让其他 Harness 也能在 DeepChat 中运行。

[事实] ACP 仍有功能不足和各家扩展不一致的问题，但已被多 Agent 编排、人机交互和虚拟员工类产品采用。

[推测] 团队押注协议层集成，意在避免直接耦合各家 Harness，同时保留更广泛的 Agent 兼容性。

[46:15] 开源项目为何需要明确定位

[事实] DeepChat 最初也希望成为满足所有人需求的大而全产品，但后来发现普通用户使用网页端产品往往已经足够。

[事实] 要求普通用户购买 Key、支付 Token 并完成配置，会带来额外迁移成本。

[事实] 团队因此把重点转向吸收前沿工程实践、验证新概念，并服务开发者和企业 AI 工程师。

[事实] 社区反馈能够带来维护者自己没有想到的应用场景，使软件逐渐适配更多真实需求。

[48:18] 小模型、速度与成本的重新平衡

[事实] 嘉宾认为当前 Coding Agent 普遍消耗大量 Token，未来可以让小型分类模型与大模型协同，减少不必要的调用。

[事实] 如果小模型足够轻量，可以直接内置在客户端中，负责安全判断、任务分类和其他简单工作。

[事实] 对脚本、搜索和常规办公等任务，便宜且快速的模型通常比最强模型更实用。

[事实] 小模型还可用于识别异常请求模式，在不直接人工查看完整提示词的情况下兼顾风控与隐私。

[推测] 对大量企业场景而言，模型能否低成本、快速而稳定地完成常见任务，可能比极限推理能力更重要。

[56:31] AI 开发者的一天

[事实] 辉辉会在晚上向 Agent 布置架构分析与重构任务，第二天早上验收结果，再把学习所得同步到 DeepChat 等开源项目。

[事实] 另一位维护者会在早晨查看夜间任务和自动代码审查结果，再根据用户反馈整理当天的 Bug 与功能任务。

[事实] 其代码审查 Agent 不仅阅读改动，还会在独立机器上运行程序和调用模型验证结果。

[事实] 发布流程中的切分支、等待 CI、上传构建产物等步骤，也会交给 DeepChat 自动完成。

[事实] 一项提示如果重复输入三次，维护者就会考虑把它改造成 Skill、定时任务或由 Webhook 触发的自动流程。

[61:57] 用户沟通与个人影响力

[事实] 嘉宾认为 AI 产品开发者和开源贡献者需要经营个人品牌，让项目能够被潜在用户看见。

[事实] Agent 接管重复劳动后，维护者可以把更多时间投入用户交流、需求澄清和社区运营。

[事实] 付费程度较高的用户往往更愿意深度使用产品、尝试隐藏的新功能，并提交详细问题报告。

[推测] 在 AI 降低开发门槛之后，获得信任、触达用户和建立社区可能会成为产品成功中更加稀缺的能力。

[64:11] 开源维护中的质量与负担

[事实] 大型项目的维护者可能因时间有限而关闭风险较高的 PR，这不一定是在针对贡献者。

[事实] 一个 PR 即使解决了眼前问题，也可能给项目增加长期维护成本。

[事实] DeepChat 使用 Beta 与正式版两个渠道，先让维护者试用新功能，再把较稳定的改动带入正式版本。

[事实] 辉辉也是在使用其他客户端遇到问题后转向 DeepChat，并从主动联系维护者、提交 PR 开始成为核心贡献者。

[67:09] AI 终端、凭据安全与自用驱动

[事实] 嘉宾讨论了带 AI 能力的终端工具，认为较好的设计应保持克制，只在用户忘记命令或需要自动配置时介入。

[事实] Agent 已被用于管理服务器、配置 HTTPS 和 Nginx，但执行危险命令前仍应请求确认。

[事实] 服务器说明可以保存在文档中，而 SSH 密钥则通过密码管理工具的命令行接口调用，避免直接进入模型上下文。

[事实] 嘉宾认为值得参与的开源项目通常也是作者本人长期使用的项目，因为真实使用会持续产生改进动力。

[70:22] AI 时代怎样做有价值的开源贡献

[事实] 嘉宾鼓励更多人参与开源，但强调贡献者必须理解自己正在修改什么。

[事实] 使用多个 Subagent 扫描全部 Issue 并批量生成大量 PR，会给维护者带来额外审查和清理负担。

[事实] 对维护者反馈不作处理、反复提交同一改动，同样不是有效贡献。

[推测] AI 可以显著扩大个人的编码产出，但有价值的开源贡献仍取决于问题理解、验证质量以及对项目长期维护成本的尊重。

播客点评/总结

[事实] 本期的价值在于，它没有只介绍一个产品的功能，而是通过 DeepChat 的实际演进，把 Tape、Harness、Memory、Sandbox、MCP 和 ACP 放进了具体工程场景中讨论。

[推测] 对 Agent 工程师、AI 客户端开发者和开源维护者而言，最有启发性的部分是架构取舍与真实工作流：如何组织长上下文、隔离任务执行、连接外部 Agent，以及让代码审查和发布流程自动化。

[推测] 节目的局限是部分概念、项目名和模型名较多，且讨论节奏跳跃；缺乏相关背景的普通听众可能需要额外查阅资料，才能完全理解技术差异。

[推测] 本期尤其适合希望参与 AI 开源项目、建设企业内部 Agent、改造开发流程，或思考“模型越来越强之后，客户端和工程基础设施还剩下什么价值”的听众。