DeepSeek开源编码代理框架深度实测：插件化架构如何重新定义AI编程

又一个编码代理框架，但这次路线完全不同

编码代理领域从不缺少新面孔，但DeepSeek悄然开源的这个编码代理框架，短短一周便在GitHub上斩获16.5万颗星——这个数字本身就说明了开发者社区对它的热烈期待。

不过需要先泼一盆冷水：这个框架目前还相当粗糙，实际使用中会遇到不少小故障。但它真正吸引人的地方，在于它与Claude Code、Codex这类主流编码代理走的是完全相反的路线。

使用Claude Code或Codex时，你被锁定在特定的模型集合上，无法触及代理的内部机制去做任何深度定制。而DeepSeek框架恰恰相反——它把"可定制"和"可扩展"做到了极致。有一件事几乎可以确定：AI编码的未来，属于那些能让开发者尽可能轻松地构建和定制的框架。

与Pi相似的理念，但走得更远

与DeepSeek框架最相似的产品是Pi（PY）——一个广受好评的编码代理。Pi最初的口号是："外面有很多编码代理，但这个是我的。"它的核心理念是打造一个极度简约的基础，让开发者能轻松在其上扩展，实现"可自我扩展的编码代理"。

DeepSeek的框架继承了相似的哲学，但走得更远：**构成整个框架界面的所有组件，以及底层框架本身，全部由插件组成。**插件是底层的可组合单元，拼接在一起构成了整个系统。你可以随意开关这些插件，可以去官方插件市场安装第三方工具，也可以轻松创建自己的专属插件。

插件化架构：一切皆可组合的设计哲学

这套框架最核心的设计理念，就是把"插件"作为驱动一切的基本单元。这么做的目的，是让在框架之上构建变得异常简单——因为随着编码代理能力越来越强大，开发者越来越倾向于构建自己的专属解决方案，而不是只依赖Codex、Claude那样开箱即用的产品。

开箱即用固然省心，所有能力都摆在那里。但像DeepSeek框架这样，你可以拿一个精简的基础，在其上构建、定制到适配自己的工作流程，最终会带你走得更远。

自我进化的编码代理已成现实

一个值得深思的观点是：我们已经到了"自我进化软件"在很多方面相当现实的阶段。既然现在的编码代理能够高度自主地构建软件，那么反过来，一个能够自我进化的编码代理同样是完全可行的。

这正是"可自我扩展编码代理"概念的核心，也是Pi早些时候爆火的原因。但为了让编码代理尽可能高效地优化自身，它需要某种底层框架来提供指导和标准：如何添加新功能组件、如何禁用模块，就像它在测试自己、改变自己的代理循环，以优化到你的工作流程和代码库。

DeepSeek构建的正是这样的底层框架。它的插件系统做到了尽可能细粒度，让每一个功能组件、每一条系统指导、乃至框架本身的内部机制，都成为可以被替换和优化的插件。

Creator Mode：让框架自我构建

最酷的是，你不必自己手写这些插件。框架内置了一个叫做Creator Mode的模式，引导你用自然语言为任何想要的功能创建插件。换句话说，自我构建的能力已经作为开源产品的核心功能内置其中。

上手体验：本地运行与多模式切换

让DeepSeek编码代理框架跑起来非常简单，你可以通过npm安装或从源码运行。一个更取巧的方式是：直接把GitHub仓库的URL丢给Claude Code，让它去安装并把WebUI跑起来。

整个系统在本地运行——不依赖任何远程服务，所有编码代理都在自己电脑上工作。在模型配置标签页，你可以添加DeepSeek或OpenRouter的API密钥来访问默认模型，当然也可以添加任何你想要的模型提供商。不像其他编码代理那样被锁定在特定模型上，这是它最大的优势之一。

配置完成后，界面提供了几种不同的工作模式：

• 标准模式：进入常规编码代理界面，可配置权限级别，或直接进入YOLO模式
• Creator模式：用自然语言构建自定义插件，让框架自我改进
• 编排器模式（Orchestrator）：调用Claude Code、Codex等其他编码代理作为子代理协同工作

轨迹视图：前所未见的代理可观测性

框架中一个让人眼前一亮的功能是轨迹视图（Trace View）。这是在编码代理中极为少见的功能，它看起来更像LangFuse、LangSmith这类AI可观测性平台才会有的东西。

你能看到代理执行的每一个动作，以及它具体来自哪里。比如点击某个上下文注入动作，可以追溯到它来自"DSH系统提示插件"；查看某个工具调用，可以发现它被委托给了Claude Code。这种可审计性，让开发者能够真正深入代理的内部机制——这是Claude Code、Codex甚至Pi都无法提供的精细度。

子代理委托与插件市场生态

借助编排能力，你可以把某些工作委托给Claude Code或Codex。比如直接说"我想用Claude Code代理"，框架就会通过工具调用进行委托，拿回结果后继续对话；同样也可以让Codex去写一个Python函数。

这一点非常实用：DeepSeek虽然是个不错的模型，框架本身也能胜任很多任务，但有时你确实想借助其他编码代理开箱即用的强大能力。而这些子代理能力，本质上也只是框架里的一个个插件——搜索"Codex"就能找到"子代理Codex"插件，Claude Code同理。

用插件弥补模型能力短板

插件系统还能优雅地弥补模型本身的能力缺陷。DeepSeek本身无法处理图像，如果对话中需要处理PNG、JPEG，就需要一个工具调用去联系其他能处理图像的模型。插件市场里就有一个叫ModelLens的插件，充当"纯文本模型的视觉桥梁"。

通过Creator Mode还能快速构建自定义插件。比如只需说一句"给我构建一个能获取开源仓库星标数的插件"，框架就会询问澄清问题、和你一起构建，然后自动安装到系统中。

从简约基础出发，值得吗？

这里有一个绕不开的问题：从如此简约的基础出发，任何需要的东西都得作为插件构建，这种方式真的值得投入吗？

答案是肯定的，理由有二：其一，构建这些组件正变得越来越容易，尤其是有Creator Mode的辅助；其二，我们拥有了一个能理解自身结构的框架，它真正做到了可自我扩展。

当然痛点也真实存在。相信很多开发者在使用Claude Code或Codex时，每天大约会遇到一次令人沮丧的对话——模型太啰嗦、子代理工作流出小故障、或者走了个奇怪的弯路。那一刻你会想"我真希望能修复它"，但你无法修复Claude Code或Codex，只能用规则去引导，永远无法真正做到完美。

而使用DeepSeek框架，你确实可以做到——修改或创建插件，甚至改变框架本身的内部代理循环。这需要更多的前期时间投入，但长期来看会带来丰厚回报：让你的编码代理和开发团队像一台运转良好的机器一样高效协同。

现在该迁移到DeepSeek框架吗？

一个务实的建议：**现在还不必立刻从Claude Code、Codex或Pi跳到DeepSeek框架。**如果你只想要开箱即用的编码代理，Claude Code依然是稳妥的选择；如果你想要更精细地构建，Pi也是不错的方案。

但这个框架值得持续关注。它目前确实不够精细——对话中能看到不少工具调用和插件的小故障，甚至连开源内置的插件也不例外。但它16.5万颗星的社区热度不是偶然。

核心判断是：在未来一两年内，"尽可能可定制"将会是编码代理演进的最优方向。也许最终胜出的不一定是DeepSeek的这个框架，但一定会是承载类似理念的产品。这正是为什么我们现在就值得去理解这类插件化系统如何运作，以及"代理可自我扩展"究竟意味着什么。