即刻App年轻人的同好社区
下载
我用 DeepSeek V4 Pro 一次生成的 3D 叙事电影，推荐一看。 这个视频，就如同 3 年前，AI 生成视频领域的威尔史密斯吃面的视频。视频与游戏一体化的时代，在今年年底开始涌现。
01:03
1 10
手机 app 各种分散的能力体系是过去式，我们需要一套统一调用的架构与能力体系。
VION_WILLIAMS: 大家都在做 DeepSeek Harness 的插件，我做了一个安卓原生移植的 DeepSeek Harness ，目标是打通我其他本地 app，实现共享数据与互操作调用，实现一个具有多种业务能力的 AI 助手。例如 AI 会议录制、AI 决策分析 App，智能文档等等。
2 00
大家都在做 DeepSeek Harness 的插件，我做了一个安卓原生移植的 DeepSeek Harness ，目标是打通我其他本地 app，实现共享数据与互操作调用，实现一个具有多种业务能力的 AI 助手。例如 AI 会议录制、AI 决策分析 App，智能文档等等。
2 21
设定一个战略目标，由 AI 来进行主动式推进，这就是企业转型的必然路径，这背后需要涉及一系列的基础设施搭建。最好的 FDE 应该是 CEO 的智能体团队，基于智能经济的基础设施来运行。
1 00
不要让 DeepSeek V4 Pro 做真正复杂的 3D 项目，那确实一团糟。用了一天，DeepSeek V4 Pro 的能力边界大致有些眉目了，做好其能力边界的事情，例如基础产品功能以及业务功能等的研发执行，其次是具备一定良好的决策分析能力，处于勉强能用的水平，可以投入相对保质量的交付。最重要的是，利用好 Dsh，搭建双模型协同的能力体系，这样使用起来是舒服的。但是 harness 层面的开发，还是需要 Codex 5.6 Sol 来做支持。
3 30
四点起床搞了一上午，脑力不够用了🤦♂️ 不过 V4 Pro 这很费钱 ，等涨价就用不起了 。
结论 ：DeepSeek harness 是为 deepseek 下一代模型提前做准备的，自由开放程度非常高，天然适应于那种能够自我持续学习、持续迭代的大模型，所以等下一代模型，它应该就是一个天然的rsi agent harness。那个元框架的论文还没时间看，但那个是核心关键，目前 DeepSeek harness 是下一代 agent harness 的雏形，也是一个探路的实验版，并非是一个成熟产品，也并不是 claude code、 codex 这样的同代产品。
*DeepSeek harness 以下简称为 dsh
dsh 现在定位是开发者预览版，对于 agent 开发者极度友好，但不适合普通用户，需要开发者做二次封装，其实这里就是开发者服务企业用户的机会。所以先不用从普通用户的角度，来看待这个产品。你可以理解为这是一辆在高速公路上可以持续的自我改造的汽车，你唯一不能改的就是这辆汽车的引擎（模型），以及这辆车启动 V4 Pro 模式跑起来时，油费并不便宜。
因为 DSH 过度的开放的自由，导致你有可能把这个他改的越来越冗余，越来越复杂。例如我在开发 agents os 的时候，也因为有太多的想法需求，然后最终使得整个系统变得复杂冗余，然后需要花很多时间去重塑整个架构，重新调整，最后我的做法将原来的系统定位为一个实验版，整个系统采用分布式架构的设计思路，然后建立一个系统中台来了解全局，然后从实验版当中提炼出可用的新版本稳固下来。
所以从这个情况判断的话，dsh 后续应该会演化出很多开发者做的定制化版本，而不仅仅只是做插件。例如 在做记忆系统的创业团队，其实天然可以采用 dsh 来做 agent harness 定制，成为一个具有某种记忆特性的变种版本，UI 界面等完全可以改成自己的。
目前使用起来，我觉得 V 4 PRO不具备多模态确实是一个比较不足的事情，例如在UI界面上，因为它不能识别看图，所以有时出现界面没有内容的时候，它不能精准有效识别这个bug。虽然是可以调用其他多模态的模型来协助其进行界面的检查，例如 你可以调用一个千问的模型来做界面的识别，但是毕竟涉及到模型协作，到底是同一个模型完成这样的任务，还是跨模型协作更好呢？我觉得这个还是取决于deepseek 本身对未来技术路线的判断，但我个人更偏向于多模态集成在一个模型。
目前dsh 处于高速迭代的过程，官网也说了 后续可能会出现破坏性兼容的情况，当前阶段最重要的事情，其实就是打造一个DSH数据管理中心，将全局和工作区的数据进行统一保存与管理，其次就是对自己定制的插件做一个管理区，这个功能管理区用于保留插件设计文档，以便在后续出现破坏性兼容的时候，可以快速的插件复现功能。不过插件应用市场我相信应该可能今天就有了。
不过现在虽然是开发者预览版本，但是我认为还是有明显的一个分类，你是一个基于 dsh 开发插件的开发者，还是你是一个能够对 dsh本身进行系统改造的一个开发者，这是两个不同的发展路线。插件的开发者有点像skill开发者的路线，属于轻量级开发用户，而改造 dsh 本身的属于重量级极客用户，例如在系统架构添加一个针对系统本身的迭代机制，例如，插件本身是通过每日的工作自动化复盘，并给出自动化的提案，然后自动化的设计插件。将整个插件系统改造成一个自动化演化的插件系统，这里可以在每个插这个业务当中植入一些数据买点，然后将其作为一个基因因子，然后通过基因演化算法的方式来生成插件。
目前测试下来，我觉得 V4 PRO没有预期中的那么强，但至少已经是 Opus 4.7～4.8 级别的东西模型了，在综合能力上各有偏差。不过 v4 flash 也是一开始我觉得不咋地，但是后面用对了路径之后就很好用，不排除V4 PRO也会出现这样的一个迭代优化的情况。所以整体上这几天还得继续用，更好的理解这个模型的能力边界。但有一个点在于说V4 PRO整体使用下来都是在每秒100token 左右，我觉得这点相当棒，kimi K3 最大的问题就是成本高，速度慢，导致日常无法进行高频使用的状态，更像是一个远程委托代理的角色。
OK, 暂且先写到这，接下来还要继续测试一下更多的能力边界。然后现在要检验一下在自我改进、自我复盘迭代的循环中，这个模型的能力上限底是什么样的。当然还有就是双盟协同的机制，就是PRO和flash怎么在大型的复杂任务当中长期可持续的实现协同运行与交付。只有把模型的能力边界摸透了，才能比较可靠的明白给市场的交付能到什么样的地步。以及需要哪些其他外部能力的支持，例如UI这块和多模态识别这块，肯定就需要外部模型来支持了。但是DSH的好处就是可以把外部的能力集成到统一运行架构之中，这就是降维打击！
总而言之 新世界的大门已经开启了
结论 ：DeepSeek harness 是为 deepseek 下一代模型提前做准备的，自由开放程度非常高，天然适应于那种能够自我持续学习、持续迭代的大模型，所以等下一代模型，它应该就是一个天然的rsi agent harness。那个元框架的论文还没时间看，但那个是核心关键，目前 DeepSeek harness 是下一代 agent harness 的雏形，也是一个探路的实验版，并非是一个成熟产品，也并不是 claude code、 codex 这样的同代产品。
*DeepSeek harness 以下简称为 dsh
dsh 现在定位是开发者预览版，对于 agent 开发者极度友好，但不适合普通用户，需要开发者做二次封装，其实这里就是开发者服务企业用户的机会。所以先不用从普通用户的角度，来看待这个产品。你可以理解为这是一辆在高速公路上可以持续的自我改造的汽车，你唯一不能改的就是这辆汽车的引擎（模型），以及这辆车启动 V4 Pro 模式跑起来时，油费并不便宜。
因为 DSH 过度的开放的自由，导致你有可能把这个他改的越来越冗余，越来越复杂。例如我在开发 agents os 的时候，也因为有太多的想法需求，然后最终使得整个系统变得复杂冗余，然后需要花很多时间去重塑整个架构，重新调整，最后我的做法将原来的系统定位为一个实验版，整个系统采用分布式架构的设计思路，然后建立一个系统中台来了解全局，然后从实验版当中提炼出可用的新版本稳固下来。
所以从这个情况判断的话，dsh 后续应该会演化出很多开发者做的定制化版本，而不仅仅只是做插件。例如 在做记忆系统的创业团队，其实天然可以采用 dsh 来做 agent harness 定制，成为一个具有某种记忆特性的变种版本，UI 界面等完全可以改成自己的。
目前使用起来，我觉得 V 4 PRO不具备多模态确实是一个比较不足的事情，例如在UI界面上，因为它不能识别看图，所以有时出现界面没有内容的时候，它不能精准有效识别这个bug。虽然是可以调用其他多模态的模型来协助其进行界面的检查，例如 你可以调用一个千问的模型来做界面的识别，但是毕竟涉及到模型协作，到底是同一个模型完成这样的任务，还是跨模型协作更好呢？我觉得这个还是取决于deepseek 本身对未来技术路线的判断，但我个人更偏向于多模态集成在一个模型。
目前dsh 处于高速迭代的过程，官网也说了 后续可能会出现破坏性兼容的情况，当前阶段最重要的事情，其实就是打造一个DSH数据管理中心，将全局和工作区的数据进行统一保存与管理，其次就是对自己定制的插件做一个管理区，这个功能管理区用于保留插件设计文档，以便在后续出现破坏性兼容的时候，可以快速的插件复现功能。不过插件应用市场我相信应该可能今天就有了。
不过现在虽然是开发者预览版本，但是我认为还是有明显的一个分类，你是一个基于 dsh 开发插件的开发者，还是你是一个能够对 dsh本身进行系统改造的一个开发者，这是两个不同的发展路线。插件的开发者有点像skill开发者的路线，属于轻量级开发用户，而改造 dsh 本身的属于重量级极客用户，例如在系统架构添加一个针对系统本身的迭代机制，例如，插件本身是通过每日的工作自动化复盘，并给出自动化的提案，然后自动化的设计插件。将整个插件系统改造成一个自动化演化的插件系统，这里可以在每个插这个业务当中植入一些数据买点，然后将其作为一个基因因子，然后通过基因演化算法的方式来生成插件。
目前测试下来，我觉得 V4 PRO没有预期中的那么强，但至少已经是 Opus 4.7～4.8 级别的东西模型了，在综合能力上各有偏差。不过 v4 flash 也是一开始我觉得不咋地，但是后面用对了路径之后就很好用，不排除V4 PRO也会出现这样的一个迭代优化的情况。所以整体上这几天还得继续用，更好的理解这个模型的能力边界。但有一个点在于说V4 PRO整体使用下来都是在每秒100token 左右，我觉得这点相当棒，kimi K3 最大的问题就是成本高，速度慢，导致日常无法进行高频使用的状态，更像是一个远程委托代理的角色。
OK, 暂且先写到这，接下来还要继续测试一下更多的能力边界。然后现在要检验一下在自我改进、自我复盘迭代的循环中，这个模型的能力上限底是什么样的。当然还有就是双盟协同的机制，就是PRO和flash怎么在大型的复杂任务当中长期可持续的实现协同运行与交付。只有把模型的能力边界摸透了，才能比较可靠的明白给市场的交付能到什么样的地步。以及需要哪些其他外部能力的支持，例如UI这块和多模态识别这块，肯定就需要外部模型来支持了。但是DSH的好处就是可以把外部的能力集成到统一运行架构之中，这就是降维打击！
总而言之 新世界的大门已经开启了
3 00
我建议开发者们全力以赴押注 DeepSeek 生态，DeepSeek Harness 是一个 Meta Harness ，是一个元架构工具，确实只有模型实验室才有条件倒腾这些元架构。
Claude、Codex 本身并没有把真正的开发权限交付给开发者，尤其是 Claude 这种封闭生态极其糟糕，相信 deepseek 会破局成功。
Claude、Codex 本身并没有把真正的开发权限交付给开发者，尤其是 Claude 这种封闭生态极其糟糕，相信 deepseek 会破局成功。
8 00