deepseek-ai

¡Muy interesante esto de DeepSeek! Ha lanzado de código abierto DSH SuperAgent Un agente de código que escucha eventos de un repo de GitHub y crea Pull Request de forma autónoma Lo mejor es que explica paso a paso cómo está montado: deepseek-ai/dsh-superagent-prototype t.co

我把自己的 Agent 从 Wails 迁到了 MyGo 原生 GUI，全程踩坑和实践分享 最近把自己写的工作 agent [Ally agent]( Bronya0/ally-agent) 的界面重写了一遍，起因是无意中看到有人推荐 MyGo ，加上我对内存和性能一直有点追求，多年来一直在用 wails ，想换个试试，就想拿自己的项目试点，没想到结果意外的不错。 旧版本的技术栈是典型的 Go + Wails + Vue （wails 我用了很多年 最近终于 V3 发正式版了 等了四年，可惜我也老了），界面用 Naive UI ，样式美观，效果也相当不错。但做久了有几个地方比较麻烦（ tarui 应该也是一样）： 跨平台界面的细节不一致，构建链比较长，还有前端内存出了问题以后，我这个写后端的人不太容易排查。 折腾了一段时间，现在主要页面已经迁到 [MyGo]( egoist/mygo) 了，记录一下过程中比较有感触的地方。 先说一下技术路线：Wails 的界面通过系统 WebView 展示网页； MyGo 既支持这种方式，也支持用 Go 写 Native UI ，由框架自己绘制。WebView 也有自己的优势，MyGo 两种都支持，相当于有个兜底，下面会说。 Ally 现在的聊天、设置等常用页面用 Native UI ，插件页面和部分预览仍然按需使用 WebView 。 一、UI 跨平台一致性 这是我这次迁移最重视的一点。 之前用 Wails 做界面，Windows 上调好的页面，到了 macOS 上经常还要再看一遍。字体、行高、滚动条、输入框这些地方，偶尔就会有一点不一样。 比如我画的表格，不知道为啥线条在 macOS 上看着发虚，Windows 上就正常。单看问题都不大，但调整完一个平台还得顾着另一个平台，挺烦的。 Wails 使用系统 WebView ，Windows 和 macOS 背后的浏览器引擎不一样，前端样式最终要经过各自的渲染实现。 MyGo 的 Native UI 由框架自己负责布局和绘制。迁移后，我在 Windows 上调好的主体界面，拿到 macOS 上看到的效果接近得多，需要针对平台单独修的地方也少了。 当然，自绘也不等于所有像素都完全一致。MyGo 的文字排版仍然使用[各平台的文字系统]( mygo.egoist.dev)：Windows 是 DirectWrite ，macOS 是 Core Text ，Linux 是 Pango 。字体回退、DPI 、输入法这些还是要分别检查。但至少不用再同时处理两套 WebView 引擎带来的样式差异了。 以前总觉得 Electron 重，碰到这些问题后倒是能理解为什么有些项目愿意用它：自带 Chromium ，渲染环境相对好统一。OpenCode 桌面端后来也[从 Tauri 换到了 Electron]( github.com/anomalyco/opencode/blob/dev/packages/d…)，不过人家具体为什么换，我就不瞎猜了。 二、内存问题现在能用熟悉的 Go 工具查 以前 Wails 版本的 Go 后端一样可以用 pprof，但界面在 WebView 里，Go 堆、JavaScript 堆、DOM 、浏览器渲染进程是几块不同的东西。 前端也有 DevTools ，可以拍 JS heap snapshot 、查 DOM 引用。但我平时主要写 Go ，遇到界面内存持续上涨，分析起来没有 Go 那么顺手。 现在主要界面和业务都在 Go 进程里，我给 Ally 加了一个按需导出诊断的入口：在设置里点“导出内存诊断”，会导出 heap.pprof、allocs.pprof、goroutine.pprof 等文件。 比如在空闲时导出一次，复现内存增长后再导出一次，就可以对比： go tool pprof -http=127.0.0.1:0 \ -base=before/heap.pprof after/heap.pprof heap 主要看还活着的对象，allocs 主要看累计分配。分配量大不一定是泄漏，也可能是某段代码反复创建临时对象，GC 能回收，但会持续消耗 CPU 。 当然，pprof 主要看到的是 Go 堆。系统和 GPU 资源，以及 WebView 子进程的内存，还是得用其他工具看。 三、帧处理的坑 MyGo 的界面更新会重新构建控件树，写 UI 时要特别留意渲染函数里做了什么。 我的 Agent 有命令执行卡片，命令输出可能很长。之前即使卡片折叠着、界面上只展示最后几行，代码仍然会先把整段输出拆分、去空行，再取出末尾几行。 看起来只是一个字符串处理函数，但界面更新时会反复执行。 后来改了两处： 1. 只需要末尾几行时，从字符串尾部向前扫描，不再先拆分整个输出。 2. 需要重复使用的派生结果按原始内容缓存；内容没变就复用。折叠时不构造展开用的行数据，并释放对应缓存。 一次本地测试里，用两万行命令输出测试折叠卡片的相关处理，单次分配从约 1.9 MB 降到 1.9 KB ，耗时从约 0.72 ms 降到 0.02 ms。 这是这段处理在该样本下的局部结果，不是整个应用的性能对比。[对应修改在这里]( github.com/Bronya0/ally-agent/commit/a1e085b9397e…)。 类似的问题还有工具参数 JSON：同一条消息的卡片头、卡片体都可能读取参数，如果每次渲染都 Unmarshal 一遍，长对话里分配会越来越明显。现在把解析结果挂在控件局部状态上，原始参数变化时才重新解析。 我的感受是，性能问题要先分清楚是“每次请求执行一次”，还是“界面更新时每帧执行一次”。后者哪怕单次看着不重，乘上帧数和控件数量也很拖累性能。 四、构建链变短 旧项目的构建大致要经过前端依赖、绑定生成、Vite 构建，再编译 Go 。MyGo Native UI 的主要页面直接用 Go 写，主界面去掉了前端打包这一步，我自己的项目构建起来明显快了不少。 MyGo 不依赖 CGO ，交叉编译也省事。目前 Ally 的构建脚本可以在 macOS 上处理 Windows 、macOS 、Linux 的 x64 和 ARM64 六个目标，另外生成 macOS Universal 包。 例如编译一个 Windows x64 二进制，核心就是： CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -o Ally.exe . 实际发布还要处理资源、压缩包、签名等事情；能交叉编译出来，也不代表已经在目标系统完成运行验证。Linux 的图形环境和使用 WebView 时需要的系统库，也仍然要考虑。 这里补充一下：我刚看了 [Wails 3.1 的发布说明]( wails.io)，它也加入了无 CGO 构建能力。目前 macOS 和 Linux 的 purego 后端还是实验性质，CGO 仍是默认选项。 所以“无 CGO”以后不一定是两者之间的主要区别。对我这个项目来说，更明显的差别是主界面不用再经过 Vue 那套构建流程了。 五、MyGo 组件够用，但 Web 生态还是强很多 迁移前我担心原生 GUI 要从头写一堆控件，实际比想象中好一些。 MyGo 已经有常见的表单、列表、树、弹窗，也有代码编辑器、Diff 、Markdown 等组件。Ally 的文件浏览和代码编辑用到了它的编辑器，聊天内容也用到了 Markdown 相关能力。 但如果和成熟的 Web 组件库比，差距还是很明显。Naive UI 这类库积累了很长时间，一个表单、选择器或者弹窗拿来就能用，样式、焦点、键盘操作、动画都比较完整。 好在 MyGo 的定制能力不错，但要做出自己满意的效果，颜色、间距、状态和交互细节还是得花时间。我之前不太想碰这类原生 UI ，一个原因就是觉得手写样式太累。 现在有 AI 帮忙，这件事容易太多了。先用框架已有组件和 Base/Parts API ，让 AI 根据目标效果调整样式，再自己检查实际交互。 我的经验是，尽量复用组件本身的焦点、键盘导航、浮层和滚动行为，别为了改外观把这些重新实现一遍，非常容易踩坑。 六、WebView 的优势还在，可以混合使用 WebView 最大的好处之一就是生态。 视频播放、复杂图表、各种文件预览，Web 上已经有大量现成方案。很多东西如果坚持全部原生重写，维护成本很高。 MyGo 可以在 Native UI 窗口里嵌入 WebView ，所以我的做法是：常驻界面用原生 UI ，需要 Web 生态的地方再创建 WebView 。 Ally 目前的 HTML 和 Mermaid 预览就是这样处理的。预览可见时按需创建，数量做限制，离开后释放。否则一个长对话里出现很多图表时，每个预览都长期挂着 WebView ，前面省下来的资源很容易又花回去。 迁移后日常使用的内存占用和响应都有比较明显的改善。不过我还没有整理同一机器、相同会话和操作条件下的完整对照数据，暂时不拿具体数字比较两个框架。 七、插件化是 Go 里比较麻烦的东西，需要谨慎考虑 这是迁移前有点低估、做起来以后感受很深的一点。 看看 [DeepSeek Harness 的 Web Client 架构]( github.com/deepseek-ai/deepseek-harness/blob/mast…)，它有插件加载、服务、事件和 UI Slots ，插件可以在已有界面里贡献功能。 Web 技术和 JavaScript 的动态加载能力，让这类扩展比较容易分发和迭代。当然，WebView 本身不会自动提供插件体系，生命周期、扩展点和权限边界都得应用自己设计。 纯 Go 桌面应用要做同样的事就麻烦得多。[Go 标准库的 plugin]( pkg.go.dev) 不支持 Windows ，加载后也不能卸载，对编译工具链和依赖版本还有要求，不适合直接拿来做一个跨 Windows 、macOS 、Linux 的热插拔 GUI 插件市场。 最后 Ally 还是用了混合方案：主程序是原生 UI ，插件页面按需跑在 WebView 里。插件可以打成 zip 安装，在侧栏增加页面，通过宿主提供的接口访问存储、HTTP 和工作区等能力；重新导入后可以更新，不用重启整个应用。 目前这更接近“可插拔页面”，和 DSH 那种能扩展更多核心能力的插件体系不太一样。WebView 也有自己的生命周期和资源成本，要做成完整生态，扩展点、兼容性和权限模型还有不少事要解决。 代码 大概就这些，迁移完之后我自己还是比较满意的，欢迎大家一起尝试原生界面 我的项目代码在 [Ally 仓库]( Bronya0/ally-agent)： Bronya0/ally-agent 原来的 Wails 版本还在 main 分支，MyGo 版本在 [mygo 分支]( github.com/Bronya0/ally-agent/tree/mygo)，感兴趣或想学习 MyGo 的可以对比着看，欢迎点个 Star 。

DeepSeek が描く AI エージェントの未来像 DeepSeek が Super-agent という AI エージェントの構想を公開しました。利用者と会話を続けながら複数の仕事を進め、GitHub やチャットの変化にも対応します。人が作業やセッションを管理する負担をどう減らすのか、既存のエージェントとの違いも含めてまとめました。 TL;DR Super-agent は仕事の進行やセッションの管理をシステムへ任せ、人が細かく指示・確認する負担を減らす構想です。 利用者との会話と仕事の振り分けは Router、個々の作業は Worker が担当します。GitHub やチャットの通知も受け取り、対応が必要なものを担当へ届けます。 Router と Worker をクラウドで動かし、自宅PCのコードや開発ツールを使って作業する構成も想定しています。 利用者が複数サービスで組んでいる仕組みを、AI ベンダーが体系化して提供してくれることに期待しています。 Worker もクラウド側にあるため、自宅PCとの接続や GUI・ブラウザ操作が安定して動くかは気になるところです。 はじめに DeepSeek Harness のチームが、Exploring Super-agent Design: Towards a More Autonomous Agent System という設計記事を公開しました。 元記事では、仕事の振り分けやセッション間の情報の引き継ぎをシステムへ任せ、人が細かく指示・確認する負担を減らす設計を提案しています。その分、人が仕事の目的や優先順位を決めたり、成果を確認して承認したりすることに集中できるようにする狙いです。 以前、Work や dot から自宅PCの Codex へ仕事を依頼する構成を記事にしました。今回の構想では、利用者との対話と実作業を分担する仕組みを、エージェントの実行基盤として扱っています。 自分でも仕組みを理解しておきたかったので、元記事の設計を既存のエージェントと比べながらまとめてみました。 DeepSeek の Super-agent 構想 Super-agent が目指すのは、人が個々のセッションを操作して仕事を進める負担を減らし、複数の仕事を継続して任せられるエージェントです。人は目的や優先順位を伝え、必要な場面で判断や承認を行います。その間の仕事の振り分けや情報の引き継ぎを、システム側が受け持つ設計です。 元記事では、モデルの能力が上がるにつれて個々の仕事への監視や細かな指示が減ってきたと説明しています。複数のエージェントを連携させる能力も上がり、別々のセッションへ仕事を分担する使い方も可能になってきました。 Claude Code や Codex で複数の仕事を進めるときは、実装用や調査用のセッションを分けて使うことがあります。文脈が混ざらない一方で、進捗の確認や対応するセッションへの追加指示は利用者が行う必要があります。 個々の仕事を任せられるようになっても、どのセッションが何を知っているかを人が覚えておく必要があれば、同時に任せられる仕事の数は人間の注意力に制限されます。元記事では、モデルの能力向上に伴って、この人間側の負担が生産性を制限するようになると説明しています。 そこで、担当を決めて必要な情報を届けるところまでエージェントの仕組みに含めます。人からの指示に加えて GitHub やチャットの変化も受け取り、対応が必要な仕事を進めます。途中で判断が必要になったときや成果の確認を求めるときには、人へ戻ってきます。 利用者が話す相手や場所を変えても、それまでの依頼を踏まえて対応する。作業中にも別の仕事を引き受け、異常があれば復旧する。こうした動作を継続して行えるように、エージェントの実行基盤を設計し直すのが Super-agent の構想です。 比較の出発点として、ローカルのエージェントを仕事ごとに起動する構成を描くと次のようになります。 利用者が仕事ごとのセッションを管理する構成 Super-agent では利用者とのやり取りを受け持つ Router と、仕事を実行する Worker を分けます。会話や作業の記録は実行プロセスの外へ保存し、コードや開発ツールがある環境にも接続します。 DeepSeek の Super-agent 構想 利用者は実装を頼んだ後に別の調査を依頼しても、同じ Router と話を続けられます。担当は裏でそれぞれの仕事を進め、結果や相談が必要な点を Router へ返します。チャットから始めた仕事について、後から GitHub の PR に書いた追加指示を受けて進めることも想定しています。 元記事が挙げる性質は次のとおりです。 性質 目指す動作 Continuous チャットや GitHub などやり取りする場所が変わっても、同じエージェントとして文脈を保つ Productive 複数の仕事を並行して進め、作業中にも次の依頼を受ける Proactive 外部の出来事を確認し、対応する価値があるものに自ら取りかかる Persistent 継続して稼働し、必要な作業環境へ接続しながら異常から復旧する これを Router と Worker の分担やイベントの処理、非同期のやり取りによって実現します。実行処理と状態・環境を分けることや、外側から監視する仕組みも含まれます。ハーネスを含む実行基盤全体の設計が話の中心になります。 仕事ごとのセッションは内部に残ります。その管理をシステムへ任せ、利用者が毎回どのセッションを開くか考えなくても済むようにする構想だと理解しました。 利用者との対話と作業担当の分担 Router は利用者との会話を続けながら、新しい仕事を Worker へ振り分けます。進行中の仕事との関係や、複数の仕事にまたがる判断も扱います。 たとえば、ある不具合の修正を頼んだ後に別のライブラリの調査を依頼したとします。修正は Worker A、調査は Worker B が担当し、Router は両方の状況を把握して利用者と話を続けます。 Router 自身は実作業を行いません。元記事では Bash ツールを持たなくてもよく、軽いモデルで速度と品質を両立できる場合が多いとしています。会話を担当するモデルが実装や長い調査に取りかかると、その間の会話や別の依頼への応答も遅くなるためです。 Worker は仕事ごとに分かれた文脈と、実作業に必要なツールを持ちます。不具合の原因を調べてコードを直す担当と、ライブラリの仕様を調べる担当では、途中のログや推論を共有し続ける必要はありません。各 Worker が作業を進め、重要な結果を Router へ報告します。利用者への返答は Router がまとめて行います。 別の担当へ仕事を任せる点は、一般的な orchestrator / worker 構成やサブエージェントと共通しています。ただ、複雑な仕事を細かい作業へ分ける orchestrator と、ここでいう Router では担当範囲が違います。Router は独立した仕事の振り分けと全体の調整を行い、一件の仕事の詳細な計画や分割は Worker 側が受け持ちます。 Worker はその仕事に必要ならさらにサブエージェントを使えます。たとえば機能追加を担当する Worker の中で、設計・実装・テストを分担する Agent Team を動かす形です。Router と Worker は役割の区分なので、必ずそれぞれが一つのセッションになるという意味でもありません。 外部イベントと作業中の追加指示 継続して仕事を進めるには、最初の依頼に加えて、その後に起きたことも受け取る必要があります。 修正した PR にレビューが付く。CI が失敗する。チャットで変更の相談が出る。元記事ではこうした外部の出来事を Trigger として扱います。 すべてをモデルに判断させると、関係のないメッセージにも推論が必要になります。そこで、送信元や対象のグループなど、決まった条件で判定できるものはプログラムで先に絞ります。そのうえで、内容を読まないと対応の要否が分からないものをモデルに判断させます。元記事の Fast Path / Slow Path はこの分担です。 担当が決まった後の続報にも、毎回 Router の判断は必要ありません。 たとえば Worker A が PR の修正を担当するなら、その PR に関する通知の届け先として Worker A のセッションを登録します。コメントや CI 結果の通知が届くと、プログラムがこの登録に従って Worker A へ直接送ります。通知のたびに Router のモデルが担当を選び直す必要はありません。 元記事の subscription (購読) は、この通知先の登録を指しています。PR やチャットのスレッドごとに届け先を登録し、後続の通知をプログラムで振り分ける仕組みです。届いた内容を読んで対応を考えるのは Worker です。 まだ担当のいない新しい仕事や、担当をまたぐ調整は Router が扱います。Worker も重要な結果を Router へ報告するので、Router は全体の状況を追いながら利用者とやり取りできます。 作業中の追加指示を受け取るため、ツールの実行も非同期にします。長いビルドを開始したら、完了までその呼び出しの中で待ち続けず、結果が後からイベントとして届くようにします。その間に届いた追加指示も、現在のモデルの推論ステップが終わった時点で扱えます。 これならビルド中に方針が変わっても、ビルドの終了まで会話を止めずに済みます。単に裏でコマンドを実行するだけでなく、作業の途中にも入力を受け取れるようにする設計です。 長く動かすほど増える履歴にも工夫があります。直近で必要な情報はコンテキストへ入れ、長い内容や古い記録は外へ置いて参照を残します。過去の仕事が再び話題になったら、その参照をたどって必要な記録を読み直します。元記事では Inline & Spill、Chain of Recall と呼んでいる仕組みです。 実行処理・履歴・作業環境の分離 この構想ではエージェントの実行処理と履歴をクラウドへ置き、実際に作業する環境を必要に応じて接続します。 Agent Loop はモデルに問い合わせ、返ってきたツール呼び出しを実行へつなぎ、その結果をモデルへ返す処理です。これを実行するプログラムと、残しておきたい会話や作業の記録を分けます。 分ける対象 置き場所と役割 Agent Loop クラウドでモデルへの問い合わせとツール呼び出しを取りまとめる 会話履歴・作業状態 外部のデータベースなどへ保存し、実行処理を起動し直しても読み出せるようにする 作業環境 コードや SDK、ファイル、アプリがあるPCなど。必要な処理を実際に行う Agent Loop のプロセスが落ちても、記録は外へ残ります。別のプロセスがその記録を読み直せれば、同じ仕事の続きを扱えます。実行中の一つのプロセスを生かし続けることと、仕事の継続を分けて考えるわけです。 元記事でも、Anthropic の Managed Agents の設計記事を参照しています。こちらもハーネスとセッションの記録、作業環境を分け、それぞれを交換できるようにする設計です。 DeepSeek が特に接続先として挙げているのは、利用者が普段使っているPCです。自宅PCには未コミットの変更や、そのPCで使っている開発ツールがあります。すべてをクラウドへ複製する代わりに、作業環境をそのまま使います。 PC側にはコマンドを実行して結果を返す軽量な daemon を置きます。会話や仕事の状態はクラウド側で管理し、Agent Loop が必要な処理をPC側へ依頼する形です。元記事では BYOM (Bring Your Own Machine) と呼んでいます。クラウドの環境や、必要なときに作る環境も接続先に含まれます。 この構成なら、自宅PCを閉じてもクラウド側での対話や記録は維持できます。そのPCが必要な作業は接続を待ち、再びオンラインになったときに進める想定です。 継続運用には外側から状態を見る Watchdog も置きます。プロセスの停止や API エラーだけでなく、同じ作業を繰り返して進んでいない状態や、目的からのずれも確認します。Watchdog 自身もツールを持つエージェントのセッションで、主な実行処理とは別に監視や復旧を行います。 以前の自分の構成では、クラウド側の dot からローカルで動く Codex などの作業担当へ依頼していました。Super-agent の構想では Worker の Agent Loop もクラウド側に置き、ローカルPCにはコマンドを実行して結果を返す daemon を置きます。 以前は作業担当がPC上で動いていたので、そのPCの GUI やブラウザを操作するツールを直接使えました。Worker がクラウド側にあると、手元の画面を確認したり操作したりするためにも、クラウドとPCの間でやり取りする仕組みが必要になります。クラウドに用意したブラウザで調べる仕事と、自宅PCのアプリや既存のブラウザを使う仕事では、接続先も変わります。 クラウド側で操作を判断し、PC側のプログラムに画面取得やクリックを実行してもらう形が考えられます。会話や仕事の記録が残っていても、通信が切れる前と同じ画面が開いているとは限りません。接続が戻ったら操作対象の状態を確認し、その状態に合わせて続きを進める必要があります。 操作の指示や結果がクラウドとPCを行き来するため、途中で止まったり、結果がうまく戻らなかったりしないかは気になります。画面の取得から操作結果の確認、通信断後の再開まで、基盤側で安定して扱えるようになることを期待しています。 構想の一部を実装した dsh-superagent-prototype も公開されています。README には内部版や設計記事と同一ではなく、記事中の将来構想には未実装のものもあると明記されています。ここで説明した全体像がそのまま完成した製品として使える段階ではないようです。 既存のエージェントとの比較 Claude Code や Codex でもサブエージェントへの分担やクラウドでの作業、離れた端末からの追加指示ができます。Cowork にも複数段階の仕事を任せ、クラウドで並行して進めたり定期実行したりする機能があります。 Super-agent の構想で整理されているのは、そうした機能を継続的な仕事の流れとしてどう組み合わせるかです。利用者と話す担当や続報の届け先に加え、記録の保存と作業環境への接続まで設計しています。 利用体験としては Grok Bot や ChatGPT dots、Claude Duet にも近い部分があります。 製品 公式に説明されている仕組み Super-agent と重なる部分 Grok Bot 専用のクラウドPCで常駐する Bot。まとめ役と専門の Bot が連携し、スマホやデスクトップから仕事を頼める 会話を続ける担当と、複数の担当による仕事の分担 ChatGPT dots 継続的な仕事を引き受け、会話の合間も作業を進める。Work や Codex へ仕事を依頼して進捗を扱う 会話を続けながら別の担当へ作業を任せる構成 Claude Duet 継続する会話と専用のクラウドPC・ブラウザを持ち、接続したアプリを確認して必要な結果や判断依頼を知らせる 常時動く作業環境と、必要なときに人へ戻るやり取り Claude Duet は現時点では research preview で、接続したアプリを一定間隔で確認します。 Grok Bot や dots、Duet を見ると、普段の会話を保ったまま裏で仕事が進む使い方は想像しやすくなります。DeepSeek の記事は、その使い方を実現するための実行基盤を具体的に説明しているところが面白いと感じました。 おわりに 仕組みを追っていくと、最近見かける Grok Bot からほかのエージェントへ仕事を任せる構成に近いと感じました。以前自分が組んだ dots 基盤も、会話を担当するエージェントと実作業を進めるエージェントをつなぐ点では同じ発想です。 利用者が複数のサービスを組み合わせて作っているこうした仕組みを、AI ベンダーが体系化して提供してくれると面白そうです。サービス同士のつなぎ方や仕事の引き継ぎを自分で組まなくても済むなら、より多くの人がエージェントに仕事を任せやすくなると思います。 自分は以前、dot との接続がうまくいかず、結局使わなくなりました。その経験もあるので、Worker までクラウド側へ移る構成で自宅PCとのやり取りがどう扱われるかは気になります。普段の開発環境や GUI・ブラウザの操作まで含めて安定して使えるなら、かなり自分の使いたい形に近づきそうです。

クラウド型コーディングエージェントとは何か：DeepSeek Super-agent はどこに置けるか :::note info この記事は AIHubMix が作成しました。DeepSeek の Super-agent は研究用プロトタイプで、DeepSeek 社内版とは同一ではなく、設計エッセイのすべてのアイデアを実装したものでもありません。内容はリポジトリの README、設計エッセイ、各社の公式ドキュメントに基づいています。チケットをトリガーから PR まで通しで実行する検証はしていません。 ::: TL;DR - クラウド型コーディングエージェントは、エディタを開かずに依頼し、自分のマシンの外で実行し、レビューできる成果物を受け取る製品です - GitHub、Cursor、OpenAI、Anthropic、Cognition、xAI の6製品を同じ軸で並べると、トリガー、実行環境、返り値の違いが見えます - Grok Bot はリポジトリ作業用ではなく、Cursor がホストするアカウント単位のクラウドマシンで動く常駐型の AI チームメイトです - 自前で動かす例が DeepSeek の Super-agent で、DSH 向けの MIT ライセンスの TypeScript プラグインとして公開されています - ただし danger-full-access で動き、既定のサンドボックスはなく、対象は github.com の1リポジトリです - レビュー工程はどの製品でも残ります。エージェントが減らすのはタイピングです クラウド型コーディングエージェントとは何か クラウド型コーディングエージェントは、エディタの外から依頼を受け取り、自分のマシンの外にある環境で作業し、レビューできる成果物を返す製品です。GitHub、Cursor、OpenAI、Anthropic、Cognition、xAI が、クラウドエージェント、バックグラウンドエージェント、クラウドセッション、自律型ソフトウェアエンジニアといった名前で、それぞれの形を提供しています。 エンジニアリングの課題は、モデル呼び出しではありません。そこは Base URL とキーとモデル ID で済みます。難しいのは周辺です。ノート PC を閉じても動くトリガー、リポジトリを clone してビルドできる環境、認証情報の境界、そして人間がレビューできる出力です。 このカテゴリの製品には、共通する3つの部品があります。 - エディタを開かずに済むトリガー。 Issue のアサイン、Slack や Feishu での @メンション、Web アプリのプロンプト、API 呼び出し、CLI からの引き渡しです - 自分のマシンの外にある環境。 エージェントはリポジトリを clone し、必要なものをインストールし、ベンダーまたは組織が管理するサンドボックスやワークスペースで作業します - レビューできる成果物。 ブランチ、差分、下書きの PR、コメントなど、人間が確認して次の行動に移せるものです これは、近い2つのものと区別されます。ローカル IDE エージェントは、見ている間だけノート PC 上で動きます。チャットアシスタントは、リポジトリに触れずに質問へ答えます。クラウド型はその中間で、実際のツールと実際のチェックアウトを持ちながら、人間がその場を離れることを前提にしています。 ボット という言葉は、同じアイデアのチャットネイティブな形を指します。Issue をアサインする代わりに、Slack、Teams、Feishu でエージェントにメンションします。トリガーは変わりますが、遠隔の環境は変わりません。出力は PR や差分のこともあれば、完成したファイル群のこともあります。 製品マップ 6製品を、各社の説明に沿って並べます。 | 製品 | 開始点 | 実行環境 | 返り値 | |---|---|---|---| | GitHub Copilot cloud agent | Issue、@、Agents パネル | クラウドサンドボックスまたは Actions | ブランチまたは PR | | Cursor Cloud Agents | デスクトップ、Web、Slack、Linear | 隔離されたクラウド VM | PR | | OpenAI Codex Cloud | ChatGPT の Web、デスクトップ、モバイル | クラウドワークスペース | 変更または PR | | Claude Code cloud sessions | ブラウザ、モバイル、デスクトップ、ターミナル | Anthropic 管理の VM またはセルフホスト環境 | ブランチまたは PR | | Devin | Slack、Teams、Web、CLI、API | ターミナル、エディタ、ブラウザを備えたワークスペース | 下書き PR | | Grok Bot | デスクトップ / モバイルのチャット、X の @bot | クラウドマシン（Cursor がホスト） | ファイルまたは下書き | 「実行環境」列は各社の表現に従っています。隔離の詳細は製品ごとに異なり、Devin のドキュメントは VM 構成や隔離の保証を説明していません。 Grok Bot はもっとも広い位置づけです。xAI のドキュメント は、デスクトップまたはモバイルのチャットから、あるいはアカウントを連携していれば X で @bot にメンションすることで開始できる、常駐型の AI チームメイトだと説明しています。Cursor がホストするアカウント単位のクラウドマシン上で動き、ブラウザ、ストレージ、コマンドラインにアクセスできます。ドキュメントが説明しているのは完成したファイルと下書きで、リポジトリのワークフローではありません。ブランチや PR の作成は記載されていません。つまり、ボット寄りの端に位置します。 表より重要な違いは4つあります。 トリガーがどこにあるか。 GitHub Copilot cloud agent と OpenAI Codex Cloud は、GitHub または ChatGPT アプリにすでにある作業を中心に設計されています。Cursor Cloud Agents と Devin はチャットネイティブで、Slack や Teams のスレッドが入口です。Claude Code cloud sessions は、ブラウザ、スマートフォン、デスクトップアプリ、ターミナルの claude --cloud から開始でき、スケジュール実行もできます。 ベンダーがどこまで見せるか。 Claude Code は隔離の説明が詳しいです。Anthropic がホストする環境では、各セッションが隔離された VM で動き、ネットワークアクセスは既定で制限され、git の認証情報はサンドボックスの外に置かれ、プロキシがセッションの代わりに認証します。組織はセッションをセルフホスト環境に振り向けることもでき、その場合の隔離は組織の責任です。クラウドセッションはプランのレート制限を共有し、VM の追加課金はありません。一方で claude.ai のサインインが必要で、Claude Code が Amazon Bedrock、Google Cloud の Agent Platform、その他のサードパーティプロバイダ向けに設定されている場合は使えません。他のベンダーは内部構成の公開が少なく、「サンドボックス」や「VM」という言葉で説明が終わることがよくあります。 エージェントが何に触れられるか。 1リポジトリに限定する製品もあれば、組織全体や複数リポジトリの作業をうたう製品もあります。自分の環境に照らして最初に確認すべき点です。能力の高いエージェントでも、リポジトリの範囲が誤っていれば、役に立たないか危険かのどちらかになります。 どんな作業に向くか。 このリストの大半はリポジトリ単位のコーディングです。Grok Bot は汎用のクラウドチームメイトで、ドキュメントが説明するのはファイルと下書きであり、リポジトリのワークフローではありません。「クラウドエージェント」は単一の製品形ではなく、スペクトラムとして読む必要があります。 ループはどう回るか ブランドを剥がすと、ループはどこでも似ています。 1. 受け付け。 トリガーが届きます。製品はそれが実際のタスクかを判断し、ときには確認の質問を1つ返し、セッションをキューに入れます 2. 環境。 エージェントは正しいブランチでリポジトリを clone し、セットアップスクリプトまたはイメージを実行し、ツールチェーンをインストールします。ネットワークアクセスとシークレットはここで設定され、後回しにはなりません 3. 作業。 エージェントはコードを読み、ファイルを編集し、テストやコマンドを実行し、ときにはブラウザを開きます。長いタスクはノート PC がスリープした後も続きます 4. 出力。 ブランチを push して PR を開くか、差分と文章の要約を残します。マージ前に止まることが前提の製品は、下書き PR を返します 5. レビュー。 人間が差分を読み、コメントし、マージするか、変更を依頼するか、作業をローカルセッションに戻します。PR を監視して、CI が失敗したときに修正を push できる製品もあります 差が出るのは、2と5です。セットアップスクリプトが長すぎる、リポジトリを clone できない、ネットワークポリシーがパッケージレジストリを塞ぐ、サンドボックスから認証情報が見えない、といったことが、単純に見えたタスクを止めます。そして「レビューできる出力」は、人間がレビューするという意味です。どの製品もレビュー工程をなくすのではなく、タイピングの位置を移しています。 いまこの波が起きている理由 3つの条件がそろいました。モデルが、常時の監督なしで長いツールループを回せるほど信頼できるようになりました。サンドボックスとセットアップスクリプトが、タスクごとに環境を用意できるほど安くなりました。そして PR が、エージェントとレビュアーの間の既定のインターフェースになり、チームは新しいレビュー工程を発明せずに済みました。 注意に関する議論もあります。DeepSeek の設計エッセイは、1つのタスクはモデルで制約されるが、多数のタスクをまたぐ人間のスループットは注意で制約される、と明示しています。クラウドエージェントは、セッション管理、コンテキストスイッチ、待ち時間を人間から移します。この主張は DeepSeek のエッセイによるもので、独立した研究によるものではありませんが、カテゴリが有用に感じられる理由を説明しています。 何を手放すことになるか ホスト型の製品は、どれも利便性と引き換えに制御を手放します。 - 信頼境界。 コードと、場合によっては認証情報が、自分のマシンの外に出ます。隔離、保持、ネットワークアクセスについての公開情報の量はベンダーごとに違うため、カテゴリ全体を一律とみなさず、製品ごとに確認してください - 隔離。 管理された VM はエージェントを閉じ込めるように設計されていますが、それはベンダーの環境です。「サンドボックス」は、強化された VM から、広いネットワークアクセスを持つコンテナまでを指し得ます - カスタマイズ。 ホスト型エージェントが公開するのは設定で、ソースコードではありません。トリガー、レビュールール、モデルを変えたい場合、製品が用意した範囲に限られます - コストモデル。 多くはサブスクリプションまたは利用上限付きのプランで課金され、エージェントの時間は直接管理できる明細ではありません。トークンではなくプランで予算を組みます - 範囲とロックイン。 複数リポジトリの対応、チャット連携、エンタープライズ向けの制御はベンダーごとに違い、ワークフローの移行も無料ではありません 自前で動かす例：DeepSeek の Super-agent DeepSeek のリリースが興味深いのは、管理プレーンを自分の側に残したとき、同じループがどうなるかを問うているからです。リポジトリは deepseek-ai/dsh-superagent-prototype で、DeepSeek Harness（DSH）向けの MIT ライセンスの TypeScript プラグイン、バージョン 0.1.0 として、研究用プロトタイプの形で公開されています。README は、公開用に調整されたもので、DeepSeek 社内版とは同一ではなく、設計エッセイのすべてのアイデアを実装したものでもない、と明示しています。 形は、長命の Router セッションと、Ticket ごとの Worker セッションです。イベントは Source → Trigger → Thread → Eval → Mandate → Ticket → Assignment → Executor の順に流れます。チームはポリシーで作業を許可し、許可された人からの明示的な @メンションは受け付けます。先回りの作業は observe モードで始まり、チケットを開かずに、エージェントが何をしたはずかを記録します。Ticket ごとにセッションとディレクトリが割り当てられ、prepare コマンドで Ticket ごとの git ワークツリーを作れます。 運用モデルは、ベンダーのサンドボックスの反対側にあります。監視するのは github.com の1リポジトリ（GitHub Enterprise Server は非対応）と、任意の Feishu です。Router と Worker のプリセットは、どちらもオペレーターの OS ユーザーとして danger-full-access で動きます。アカウントラッパーが選ぶのはエージェントの認証情報で、プロセスを隔離するわけではありません。デプロイガイドの指針は、エージェントの認証情報だけを持つ専用 OS アカウントです。状態は、設定した stateDir の下の SQLite に置かれます。哲学は予算として書かれています。人間の注意をできるだけ取らず、価値をできるだけ返す、というものです。 プロトタイプはモデルをハードコードしません。Eval または Execution で上書きしない限り Harness プロファイルの既定値を使うため、Router に軽いモデル、Worker に強いモデルを置くこともできます。 設計エッセイは、合成ワークロードのスケジューリング数値を報告しています。約300メッセージと20件の作業リクエスト、シミュレーションしたツール、5回の実行で、p50/p95 は約12.4 / 15.7分でした。サブエージェント呼び出しのなかった単一セッションのベースラインは、p95 が約29.5分です。これはエッセイ自身による自己申告の測定で、シミュレーションしたツール下の数値であり、独立したコーディング品質のベンチマークではありません。 ハマりどころ danger-full-access のまま使い始めると権限が広すぎる Router と Worker は、オペレーターの OS ユーザーとして danger-full-access で動きます。アカウントラッパーは認証情報を切り替えるだけで、プロセスをサンドボックス化しません。使い始める前に、エージェントの認証情報だけを持つ専用 OS アカウントを用意してください。 github.com の1リポジトリが前提で、GitHub Enterprise Server は非対応 監視できるのは github.com 上の1つの owner/name リポジトリで、GitHub Enterprise Server は非対応です。 「サンドボックス」と書いてあっても、中身の説明はベンダーごとに違う Claude Code は、隔離された VM、既定で制限されたネットワーク、サンドボックス外に置かれる git 認証情報まで説明しています。一方で、他のベンダーの公開情報は「サンドボックス」や「VM」で終わることが多く、Devin のドキュメントは VM 構成や隔離の保証を説明していません。同じ言葉から同じ保証を仮定しないでください。 Claude Code のクラウドセッションは claude.ai のサインインが必要で、Amazon Bedrock や Google Cloud の Agent Platform では使えない Claude Code のクラウドセッションは、プランのレート制限を共有し、VM の追加課金はありませんが、claude.ai のサインインが必要です。Claude Code が Amazon Bedrock、Google Cloud の Agent Platform、その他のサードパーティプロバイダ向けに設定されている場合は利用できません。 セットアップスクリプトが長い、パッケージレジストリに届かない、認証情報が見えない ループの2番目で止まる典型です。セットアップスクリプトが長すぎる、リポジトリを clone できない、ネットワークポリシーがパッケージレジストリを塞ぐ、サンドボックスから認証情報が見えない、のいずれかがあると、単純に見えたタスクが進みません。 レビューを省こうとすると、どの製品でも止まる どの製品も、最後は差分や PR を人間がレビューする形で終わります。エージェントが移すのはタイピングで、承認ではありません。レビュー工程を前提に、トリガーと権限を設計してください。 この記事で検証していないこと - Super-agent のチケットをトリガーから PR まで通しで実行する検証はしていません。接続経路はドキュメントに基づく説明です - 設計エッセイのスケジューリング数値は自己申告で、シミュレーションしたツール下の測定です。独立したコーディング品質の結果ではありません - ホスト型各社の機能は公式ドキュメントに基づく要約で、再現テストは行っていません - Super-agent は研究用プロトタイプで、DeepSeek 社内版とは同一ではなく、既定のサンドボックスもありません まとめ - クラウド型コーディングエージェントは、エディタを開かずに済むトリガー、自分のマシンの外の環境、レビューできる成果物の3つで整理できます - GitHub、Cursor、OpenAI、Anthropic、Cognition、xAI の6製品は同じループを共有し、違いはトリガー、隔離の公開度、対象範囲に現れます - Grok Bot はリポジトリ作業用ではなく、Cursor がホストするアカウント単位のクラウドマシンで動く常駐型の AI チームメイトです - DeepSeek の Super-agent は、管理プレーンを自分の側に残す実装例ですが、danger-full-access で動き、既定のサンドボックスはなく、対象は github.com の1リポジトリです - 性能数値は設計エッセイの自己申告であり、独立した品質評価ではありません - どの製品でも、最後のレビューは人間に残ります AIHubMix は OpenAI 互換エンドポイント（https://aihubmix.com/v1）を提供しており、DSH の基本接続は DeepSeek Harness ガイド で確認できます。ガイドが扱うのは基本接続までで、Super-agent プラグインは対象外です。Super-agent のプロセス自体は AIHubMix ではホストされず、DSH を導入したマシン上で動きます。 参考 1. deepseek-ai/dsh-superagent-prototype（GitHub）— README、設計エッセイ、docs/000–008 2. Connect DeepSeek Harness to AIHubMix（AIHubMix） 3. GitHub Copilot cloud agent（GitHub Docs） 4. Claude Code in the cloud（Anthropic） 5. Grok Bot documentation（xAI）

把 DeepSeek 的 Super-agent 思路做成一个人的桌面助手： AnyModelBot，首个开箱即用的 DeepSeek Super Agent DeepSeek 前阵子开源了 [dsh-superagent 原型]( deepseek-ai/dsh-superagent-prototype)，核心原则就一句：占用尽量少的注意力，带来尽量多的价值。 不过它是面向团队、盯着 GitHub 仓库的研究原型，个人没法直接用。 我们把这套思路做进了开源桌面助手 AnyModelBot，装好就是开箱即用的 DeepSeek Super Agent ，这是它的首个实现，不需要任何配置。  Super Agent 三件套 - 后台任务：调研、做报告这类要跑一阵子的事，交代一句就在后台做，聊天照常，不用排队等。 - 定时规则：一句话写下长期吩咐，比如「每天早上 8 点看看 X 的价格，低于 200 告诉我」，按时自动执行。新规则可以先用「观察」模式试跑，只读、不打扰你。 - 「需要你」：所有等你回答、批准的事集中在一处，没事时不占地方。 不打扰是硬规矩：只推结果、决定和失败三种消息，默认 22:00–08:00 免打扰，每个任务和规则都有预算上限。  它本来就是一个完整的 AI 机器人 - 一个账号 70+ 模型：GPT 、Claude 、Gemini 、Grok 、DeepSeek 、Kimi 、GLM……每个对话用 /model 随时切换。  - 在微信和飞书里也能用：微信扫码连接，支持图片和文件；飞书是流式回复卡片。  - 能操作你的电脑：读写文件、沙箱执行命令、电脑操作（ macOS 为 Beta ），三档权限加审批卡片，你说了算。  - 本地优先、开源免费：对话、记忆、文件和 Key 都留在你的电脑上； MIT 开源，Windows / macOS / Linux / Docker 都能跑，模型按量付费、没有订阅。 想深入看 设计细节（和原型的差别、DeepSeek Harness 怎么跑、权限和预算怎么设计）都写在 GitHub 的设计文档里，功能介绍和下载在官网： - GitHub： modelflare-ai/AnyModelBot （欢迎 Star ⭐） - Super Agent 设计文档： github.com/modelflare-ai/AnyModelBot/blob/master/… - 官网： anymodel.bot 项目还很新（ v0.1.x ），是独立开源项目，与 DeepSeek 官方无关。欢迎试用、提 issue 、拍砖 🙏

DeepSeek Harness Superagent Prototype

DGX Spark1台でQwen3.8 Flash NextをClaude CodeとDeepSeek Harnessから動かす はじめに ローカルLLMを動かすためにDGX Sparkの互換機であるThinkstation PGXを購入したわけではないですが、せっかく1台持っているので、どのモデルであればまともに動作するのかをいろいろ試していました。 zenn.dev しかしながら、調べれば調べるほど、128GB機1台程度では、他のGeforce GPU搭載のPCと比較して優位性のある結果にはなりませんでした。（Strataが強すぎる・・・） とはいえその中でも、ある程度まともに動く中で大きめなモデルとしてQwen3.8 Flash Nextを動かしてみました。 ! strataの場合は、例えばRTX3060（VRAM 12GB）+RAN 64GB程度だと3bit程度の量子化のFlash Nextが動作可能です。 今回動作させるのは4bit程度の量子化のFlash Nextになります。 今回やりたいのは、このPCをLLMのサーバーにして、普段使っている別のPCからコードを書いてもらうことです。 操作にはClaude CodeとDeepSeek Harnessを使います。以降、DeepSeek Harnessはコマンド名に合わせて「dsh」と書きます。 最終的に使うのは、作業フォルダから呼び出す次の2つのコマンドです。 localclaude localdsh ここで普通に「claude」コマンドを使わないのは、普段使っているOpus 5.5とかを動かす際のclaudeの設定と、ローカルLLMを呼び出す時の設定を切り分けて、ストレスなく使うためです。 さて、せっかくローカルで動かすなら、速度も気になりますよね。 今回は、BF16のKVキャッシュとMTPを使った構成で、速度、コードの動作、メモリ使用量を確かめました。 利用するモデル 文章やコードの生成には、NVIDIAが公開しているFP4版のFlash Nextを使います。 NVIDIAが量子化後のモデルを学習し直したQAD版で、NVFP4とMXFP8などを組み合わせています。 huggingface.co NVIDIAがこのモデルの対応エンジンとして案内しているのはvLLMです。 DGX Spark向けには、新しい重みの圧縮形式へ対応したコミュニティ製の専用コンテナを指定しています。 今回はそのvLLMとTensorFoldを比べ、生成速度とメモリ使用量からTensorFoldを選びました。 huggingface.co TensorFoldとvLLMの比較条件 Claude Codeに同じ3つの課題を頼みました。ファイルを保存し、自分で動作確認してもらうところまで含めた試験です。 課題 確認した内容 区間の結合 重なる区間や端点が同じ区間の結合、不正な区間の検出、入力を変更しないこと トポロジカルソート 辞書順で最小の順序、重複した辺、循環や未定義ノードの検出 JSON Linesの処理 ユーザー別の金額集計、真偽値の除外、不正入力の行番号、出現順の保持 比較相手は、NVIDIAのモデルカードで案内されているeugr/spark-vllm-b12xです。コンテナのdigestを固定し、初回の最適化を終えてから測りました。vLLMの版は0.1.dev21830+g8244d1c44.d20261026です。 モデルの重み、BF16のKVキャッシュ、MTP先読み6、コンテキスト上限262,144、同時実行上限3件を揃えています。vLLM側も、元のBF16 LMヘッドを保ち、追加のMXFP8変換や活性値の追加量子化を無効にしました。起動時のメモリ不足を避けるため、標準safetensorsローダとPyTorchのメモリ管理設定を使っています。 Claude Codeは--effort highで起動しました。モデルへの実効値はxhighに揃え、temperatureは1、top_pは0.95、top_kは20、出力上限は50,000トークンです。 比較時には、生成条件を揃えてサーバーの統計を記録する計測用の中継を挟みました。モデルやエンジンのコードは変更していません。後半の導入手順では、Claude CodeからTensorFoldのAPIへ直接接続します。 項目 TensorFold 1.1.9 vLLM 生成中の速度 58.16 token/s 40.98 token/s 入力処理・通信を含むAPI全体の速度 21.52 token/s 19.91 token/s 3課題のClaude Code実行時間 378.15秒 418.10秒 LLMへの要求回数 18回 18回 思考を含む出力トークン数 8,021 8,198 表は、3課題で発生した全要求を集計した結果です。 モデルの読み込みと初回最適化の時間は含めません。 token/sで見ると、TensorFoldが約1.42倍でした。Claude Codeが3課題を終えるまでの時間も、今回は約40秒短くなっています。 こちらのモデルで搭載されている以下の補助機構も利用して利便性と生成速度を向上させます FP4版に含まれるMTP 別のドラフトモデルのダウンロードは不要 画像エンコーダ FP4版に含まれる画像エンコーダ PNG・JPEG・WebPなどの画像を入力可能 MTPとは MTPはMulti-Token Predictionの略で、次の1トークンに加えて、その先のトークンも予測する仕組みです。 トークンは、モデルが文章を扱うときの文字や単語のまとまりです。 今回のFlash NextにはMTP用の補助部分が含まれており、これを使って続きの候補を先に作ります。別の小型モデルを追加で用意する必要はありません。 投機的デコードとは 通常の生成では、本体のモデルを動かして1トークンずつ確定します。 投機的デコードでは、先に作った数トークン分の候補を本体でまとめて検証します。候補がうまく当たった分だけ、本体を動かす回数を減らせる仕組みです。 今回の構成では、MTPが候補を作り、投機的デコードの手順で本体が検証・採用します。 以降の記事で記載している「先読み6」というのは、一度に最大6トークン分の候補を作る設定です。 外れた候補はそのまま採用せず、本体の出力に従って補正します。 詳細は以下の記事をご覧ください zenn.dev 環境 モデルを動かしたのは、DGX Sparkと同じGB10を搭載したThinkStation PGXです。 実測と、記事の導入手順で使うソフトウェアをまとめます。 項目 環境 サーバー Lenovo ThinkStation PGX、1台 CPU Arm、20コア。Cortex-X925とCortex-A725を各10コア GPU NVIDIA GB10 NVIDIAドライバ 580.159.03 メモリ CPUとGPUで共有する128GB OS・アーキテクチャ Ubuntu 24.04.4 LTS、aarch64 Linuxカーネル 6.17.0-1021-nvidia 推論エンジン 公式TensorFold 1.1.9のLinux aarch64配布版。 GPU実行環境 NVIDIAドライバを備えたホスト上で、公式のネイティブ実行ファイルを直接起動 Claude Code 2.1.223 DeepSeek Harness 0.2.0-rc.2。Node.jsはv24.16.0 実測と導入手順で使う構成を、次の設定に揃えます。 項目 設定 モデルの重み NVIDIAのFP4版 KVキャッシュ BF16 MTP 有効・先読み6 コンテキスト上限 262,144トークン 同時実行上限 3件 画像入力 無効。今回は文字・コード生成を対象とする 同時実行上限は、APIサーバーが同時に生成するリクエスト数の上限です。 今回は最大3件を並行して処理します。それ以上の依頼を送った場合は、空いた枠を使って順番に処理するため、5件を送れば5件とも同時に生成するわけではありません。 MTPの先読み数は、1件の生成で予測するトークン数です。並列数を増やす設定ではありません。 速度とコードの品質は、思考を有効にした同じClaude Codeの作業で確認しました。以降は、その作業中に記録した速度とメモリ使用量を見ていきます。 別PCから使う場合は、同じLAN内のPCにClaude Codeまたはdshを入れて接続します。後半は、その設定手順です。 実験結果 Claude Codeに次のPythonコードを書いて保存・実行してもらいました。課題は1件ずつ、思考highで実施しています。 タスク(未公開) 初回 修正後 生成速度（token/s） 重なる区間を結合する 不合格 合格 60.84 依存関係に沿って辞書順に並べ替える 合格 合格 54.21 JSON Linesからユーザー別の金額を集計する 合格 合格 59.84 各課題8項目のテストをすべて通れば合格としています。 初回の合格率は66.7%（2/3課題）。区間の結合を1回修正した後は100%（3/3課題）となり、計24項目のテストをすべて通過しました。 全体の生成速度は58.16 token/s、3課題の実行時間は約6分18秒でした。速度には思考と修正分も含み、モデルの読み込み時間は除いています。 ツール利用に関しても、4bit量子化であることもあり、かなり安定して動作しています。 OSを含む使用メモリの最大値は84.31GiBで、利用可能メモリは最少でも35.32GiB残っていました。 利用構成・環境構築 接続の流れは、次のようになります。 Claude Codeを使っていても、この構成で文章やコードを生成するモデルはFlash Nextです。 Claude Codeは、依頼を送り、返ってきた指示に従ってファイルを編集する役割を担当します。 TensorFoldが両方のAPI形式を扱うため、今回の手順では別の形式変換サーバーを置きません。 接続先の指定には、1点違いがあります。 利用する側 ベースURL 主な生成API Claude Code 192.168.0.194 /v1/messages dsh 192.168.0.194 /v1/chat/completions 192.168.0.194は本記事の例です。自分のPGXのLAN内IPアドレスに置き換えてください。 APIサーバの構築 ここからは、モデルを動かすPGX側の操作です。 Ubuntu系のLinuxで、NVIDIAドライバが利用できることを前提にします。公式のLinux aarch64配布版を取得し、モデルのダウンロードから始めます。 github.com/ashhart/TensorFold/blob/v1.1.9/README.… まず、GPUとメモリ、ディスクの空き容量を確認します。 nvidia-smi free -h df -h "$HOME" モデルの配布ファイルは約96GiBです。実行ファイルやダウンロードの作業領域にも空き容量が必要なので、モデルの容量だけでディスクを埋めないようにしてください。 公式の実行ファイルを取得 今回はPGXのArm CPUに合わせて、Linux aarch64版を使います。 mkdir -p "$HOME/local-llm/flash-next" cd "$HOME/local-llm/flash-next" V=1.1.9 curl -fLO "github.com/ashhart/TensorFold/releases/download/v…" curl -fLO "github.com/ashhart/TensorFold/releases/download/v…" sha256sum -c "tensorfold-$V-linux-aarch64.tar.gz.sha256" tar -xzf "tensorfold-$V-linux-aarch64.tar.gz" ./tensorfold-1.1.9-linux-aarch64/bin/tensorfold-native --version チェックサムの検査が通り、tensorfold-native 1.1.9と表示されれば、取得できています。展開したフォルダには実行ファイルと必要なライブラリが入っているため、フォルダごと保存してください。 モデルのダウンロード 同じ作業フォルダで、公式のpullコマンドを使います。モデルのリビジョンも指定しておきます。 cd "$HOME/local-llm/flash-next" HF_HUB_CACHE="$PWD/models-cache" \ ./tensorfold-1.1.9-linux-aarch64/bin/tensorfold-native pull \ nvidia/Qwen3.8-Flash-Next-FP4-Local@b9ce18a6887e18c089fdea8509a33e63429a3300 このコマンドで取得するのは、重み、MTP、トークナイザーなど、Hugging Faceの同じ公開モデルに含まれるファイル一式です。初回は約96GiBあるため、ダウンロードには時間がかかります。 保存先は、この例ではmodels-cacheです。途中で止まった場合は、同じコマンドで取得を再開できます。 APIキーの作成 今回はLAN内へ公開し、APIキーを付けて呼び出します。次の操作は、初回に一度行ってください。 cd "$HOME/local-llm/flash-next" umask 077 python3 - <<'PY' from pathlib import Path import secrets p = Path('api-key') p.write_text(secrets.token_hex(32) + '\n') p.chmod(0o600) PY api-keyに保存した値を、後でクライアント側にも設定します。サーバーには、公式の--api-key-fileで渡します。 サーバの起動 取得した固定リビジョンのフォルダを指定し、次のコマンドで公式の実行ファイルを起動してください。 （以降、サーバを止めてから再開するときはこのコマンドを実行すればOK） cd "$HOME/local-llm/flash-next" HF_HUB_OFFLINE=1 TF_FLASHNEXT_DRAFTS=6 \ ./tensorfold-1.1.9-linux-aarch64/bin/tensorfold-native serve \ "$PWD/models-cache/models--nvidia--Qwen3.8-Flash-Next-FP4-Local/snapshots/b9ce18a6887e18c089fdea8509a33e63429a3300" \ --name Qwen3.8-Flash-Next \ --host 0.0.0.0 --port 8888 \ --api-key-file "$PWD/api-key" \ --context 262144 --parallel 3 \ --max-tokens 50000 \ --temperature 1 --top-p 0.95 --top-k 20 \ --thinking --reasoning-effort high \ --kv-cache bf16 --prompt-cache-gib 0 \ --prompt-seed --no-update-check パラメータ解説 TF_FLASHNEXT_DRAFTS=6で、MTPの先読み数を指定します。 MTPは既定で有効です。 --kv-cache bf16、--parallel 3、--context 262144が、今回測定した構成になります。 --max-tokens 50000は、応答の出力上限の既定値です。 --prompt-cache-gib 0は、リクエスト間で状態を再利用するプロンプトキャッシュを無効にする設定です。 --prompt-seedは、入力文からseedを決める設定です。 今回のClaude Codeが使うAnthropic形式のAPIは、要求側のseedを生成処理へ渡さないため、この入力由来のseedで動作します。実測でも有効にしています。 起動ログを確認できたら、そのターミナルは開いたままにしてください。 別のターミナルやクライアントPCから接続しましょう。 停止は、サーバーを動かしたターミナルでCtrl+Cです。再起動するときも、同じ起動コマンドを使います。 LAN内IPアドレスは次のコマンドで確認できます。 hostname -I 複数表示される場合は、別PCと同じLANに属するアドレスを指定してください。 この手順は信頼できるLAN内で使うHTTP接続です。 同一LANからのAPI動作確認 ここから先は、普段作業するPCで操作します。 以下はmacOS、Linux、WindowsのWSLで使えるBash系の手順です。 まず接続先とAPIキーを~/.config/flash-next/connection.envに保存します。 モデル名は保存せず、起動するたびにサーバーから取得するようにします。 APIキーは、サーバーのapi-keyファイルに保存した値へ置き換えてください。 接続先FLASH_BASE_URLは、サーバをたちあげたPCのIPアドレスとポート番号を指定して下さい。 mkdir -p "$HOME/.config/flash-next" "$HOME/.local/bin" chmod 700 "$HOME/.config/flash-next" umask 077 cat > "$HOME/.config/flash-next/connection.env" <<'ENV' FLASH_BASE_URL='192.168.0.194' FLASH_API_KEY='63e36・・・（ここをサーバーのapi-keyファイルの値へ置き換える）' ENV chmod 600 "$HOME/.config/flash-next/connection.env" 接続確認では、このファイルを読み込んでモデル一覧を取得します。 . "$HOME/.config/flash-next/connection.env" curl -fsS --connect-timeout 5 --max-time 15 \ "$FLASH_BASE_URL/v1/models" \ -H "Authorization: Bearer $FLASH_API_KEY" 以下のような返信があればOKです。 {"object": "list", "data": [{"id": "Qwen3.8-Flash-Next", "object": "model", "created": 1793522255, "owned_by": "tensorfold", "context_length": 262144, "max_model_len": 262144, "reasoning": {"default_enabled": true, "default_effort": "xhigh", "supported_efforts": ["xhigh", "medium", "low", "none"]}}]}% モデルの設定を起動時に取得する Mac側には、サーバーから設定を取得する共通ファイルを1つ置きます。 localclaudeとlocaldshのどちらも、起動時にこのファイルを使います。 Python 3が必要なので、python3 --versionで確認しておいてください。 取得するのはモデル名、コンテキスト長、対応する思考レベルと既定値です。 これらはTensorFoldの/v1/modelsが返す情報を使います。 github.com/ashhart/TensorFold/blob/v1.1.9/README.… cat > "$HOME/.config/flash-next/resolve-model.py" <<'PY' import json import os import shlex import sys import urllib.request base = os.environ['FLASH_BASE_URL'].rstrip('/') request = urllib.request.Request( base + '/v1/models', headers={'Authorization': 'Bearer ' + os.environ['FLASH_API_KEY']}, ) with urllib.request.urlopen(request, timeout=15) as response: models = json.load(response)['data'] if not models: sys.exit('サーバーに利用可能なモデルがありません。') requested = os.environ.get('FLASH_MODEL_ID') model = next((m for m in models if m['id'] == requested), None) if requested else models[0] if model is None: sys.exit('指定したモデルがありません: ' + str(requested)) context = model.get('context_length') or model.get('max_model_len') reasoning = model.get('reasoning', {}) supported = reasoning.get('supported_efforts', []) if not isinstance(context, int) or context < 2 or not supported: sys.exit('この手順に必要なコンテキスト長・思考レベルがAPIにありません。') def ui_level(wire): return {'none': 'off', 'xhigh': 'high'}.get(wire, wire) levels = {ui_level(wire): wire for wire in reversed(supported) if wire in ('none', 'minimal', 'low', 'medium', 'high', 'xhigh', 'max')} default = ui_level(reasoning.get('default_effort') or supported[0]) effort = os.environ.get('FLASH_EFFORT') or default if effort not in levels: sys.exit('対応していない思考レベルです。選択肢: ' + ', '.join(levels)) 50,000はこの記事で使う出力上限。モデルの最大出力長を取得した値ではありません。 max_tokens = min(50000, context // 2) if sys.argv[1] == 'env': if effort == 'off': sys.exit('この記事のClaude Code起動手順では思考を有効にしてください。') values = {'FLASH_MODEL': model['id'], 'FLASH_CONTEXT_TOKENS': context, 'FLASH_MAX_TOKENS': max_tokens, 'FLASH_RESOLVED_EFFORT': effort} for name, value in values.items(): print('export ' + name + '=' + shlex.quote(str(value))) elif sys.argv[1] == 'dsh': patch = [ {'id': 'agent-default-model', 'config': { 'provider': 'local-flash-next', 'model': model['id'], 'reasoningEffort': effort}}, {'id': 'llm-pi-ai', 'config': {'providers': {'local-flash-next': { 'apiKeyEnv': 'LOCAL_LLM_API_KEY', 'api': 'openai-completions', 'baseURL': base + '/v1', 'reasoning': effort, 'compat': {'supportsDeveloperRole': False, 'maxTokensField': 'max_tokens', 'supportsReasoningEffort': True, 'thinkingFormat': 'openai'}, 'models': [{'id': model['id'], 'contextWindow': context, 'maxTokens': max_tokens, 'reasoningEfforts': levels}], }}}}, {'id': 'session-log-deepseek', 'disabled': True}, {'id': 'session-telemetry-otel', 'disabled': True}, ] print(json.dumps(patch, ensure_ascii=False, indent=2)) else: sys.exit('env または dsh を指定してください。') print('接続モデル: ' + model['id'] + ' / 思考: ' + effort, file=sys.stderr) PY モデルが1つなら、そのモデルを自動で使います。 複数ある場合は一覧の先頭を使い、別のモデルを選ぶときだけFLASH_MODEL_ID='モデルID' localclaudeのように指定します。dshも同じです。 このAPIが返すのは、サーバーが現在公開しているモデルです。 出力上限の50,000トークンは、今回の実験に合わせたクライアント側の設定です。 まずは共通ファイルで設定を取得し、そのまま接続確認に使います。 set -a . "$HOME/.config/flash-next/connection.env" set +a model_settings=$(python3 "$HOME/.config/flash-next/resolve-model.py" env) && eval "$model_settings" 続いて、短い文章も生成してみましょう。 curl -fsS --max-time 180 "$FLASH_BASE_URL/v1/chat/completions" \ -H "Authorization: Bearer $FLASH_API_KEY" \ -H 'Content-Type: application/json' \ --data-binary @- <<JSON | python3 -m json.tool --no-ensure-ascii { "model": "$FLASH_MODEL", "messages": [{"role": "user", "content": "日本語で短く挨拶してください。"}], "temperature": 0, "max_tokens": 256, "draft": true, "chat_template_kwargs": {"enable_thinking": false} } JSON 初めの確認は思考OFFにしています。 思考レベルを試す場合は、enable_thinkingをtrueにし、JSONへ"reasoning_effort": "low"などを追加してください。 以下のような出力が得られていればOKです。 出力確認{ "id": "chatcmpl-1fb90809d034accea082e1d53bbc19a3", "object": "chat.completion", "created": 1793522557, "model": "Qwen3.8-Flash-Next", "choices": [ { "index": 0, "message": { "role": "assistant", "content": "こんにちは。" }, "finish_reason": "stop" } ], "usage": { "prompt_tokens": 19, "completion_tokens": 3, "total_tokens": 22, "prompt_tokens_details": { "cached_tokens": 0 }, "completion_tokens_details": { "reasoning_tokens": 0 } }, "exact_mode": "exact", "tensorfold": { "enable_thinking": false, "reasoning_effort": "none", "engine": "lanes", "tokens_per_second": 15.529567290581785, "seconds": 0.128786589, "prefill_seconds": 0.110438503, "prefill_widths": [], "prefill_raised": [], "time_to_first_token": 0.111080564, "sampling": "greedy", "drafts": true, "token_sha": "d849233ade4a", "token_sha256": "d849233ade4aa863a41e1df72f82155ca6bd3fda35f04ba70eadc962cf26bee8", "min_rows": 2 }, "speculative": { "rounds": 2, "drafted": 5, "accepted": 4, "acceptance_rate": 0.8, "tokens_per_round": 1.5 } } Claude Codeが使うAnthropic形式でも、短い挨拶を返してもらいましょう。 curl -fsS --max-time 180 "$FLASH_BASE_URL/v1/messages" \ -H "Authorization: Bearer $FLASH_API_KEY" \ -H 'Content-Type: application/json' \ -H 'anthropic-version: 2023-06-01' \ --data-binary @- <<JSON | python3 -m json.tool --no-ensure-ascii { "model": "$FLASH_MODEL", "messages": [{"role": "user", "content": "日本語で短く挨拶してください。"}], "temperature": 0, "max_tokens": 256, "thinking": {"type": "disabled"} } JSON 出力確認{ "id": "msg_267abe01eae1e591d5209ab3fa3b8b9c", "type": "message", "role": "assistant", "model": "Qwen3.8-Flash-Next", "content": [ { "type": "text", "text": "こんにちは。" } ], "stop_reason": "end_turn", "stop_sequence": null, "usage": { "input_tokens": 19, "output_tokens": 3, "cache_creation_input_tokens": 0, "cache_read_input_tokens": 0, "output_tokens_details": { "thinking_tokens": 0 } } } それぞれchoicesまたはcontentに文章が返れば、次へ進めます。 Claude CodeからQwenを利用する Claude Codeをすでに使っている方は、そのインストールを使います。 未導入の場合は、公式のインストール手順に従って導入してください。 code.claude.com curl -fsSL claude.ai | bash claude --version 本記事ではClaude Code 2.1.223を使いました。 次に、ローカルLLM用の起動コマンドを作ります。 ~/.local/bin/localclaudeに設定ファイルを書き込みます。 cat > "$HOME/.local/bin/localclaude" <<'SH' #!/usr/bin/env bash set -euo pipefail set -a source "$HOME/.config/flash-next/connection.env" set +a : "${FLASH_BASE_URL:?}" "${FLASH_API_KEY:?}" model_settings=$(python3 "$HOME/.config/flash-next/resolve-model.py" env) eval "$model_settings" unset CLAUDE_CODE_OAUTH_TOKEN ANTHROPIC_CUSTOM_HEADERS unset CLAUDE_CODE_USE_BEDROCK CLAUDE_CODE_USE_VERTEX CLAUDE_CODE_USE_FOUNDRY export ANTHROPIC_BASE_URL="${FLASH_BASE_URL%/}" export ANTHROPIC_API_KEY="$FLASH_API_KEY" export ANTHROPIC_AUTH_TOKEN="$FLASH_API_KEY" export ANTHROPIC_MODEL="$FLASH_MODEL" export ANTHROPIC_DEFAULT_OPUS_MODEL="$FLASH_MODEL" export ANTHROPIC_DEFAULT_SONNET_MODEL="$FLASH_MODEL" export ANTHROPIC_DEFAULT_HAIKU_MODEL="$FLASH_MODEL" export CLAUDE_CODE_SUBAGENT_MODEL="$FLASH_MODEL" export CLAUDE_CONFIG_DIR="$HOME/.claude-config/flash-next" unset CLAUDE_CODE_EFFORT_LEVEL CLAUDE_CODE_EXTRA_BODY export CLAUDE_CODE_MAX_CONTEXT_TOKENS="$FLASH_CONTEXT_TOKENS" export CLAUDE_CODE_MAX_OUTPUT_TOKENS="$FLASH_MAX_TOKENS" export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 export CLAUDE_CODE_ATTRIBUTION_HEADER=0 export API_TIMEOUT_MS=3600000 mkdir -p "$CLAUDE_CONFIG_DIR" export CLAUDE_CODE_AUTO_MODE_MODEL="$FLASH_MODEL" exec claude --model "$FLASH_MODEL" --effort "$FLASH_RESOLVED_EFFORT" "$@" SH chmod 755 "$HOME/.local/bin/localclaude" export PATH="$HOME/.local/bin:$PATH" この設定はlocalclaudeから起動したプロセスに適用されます。 普段のclaudeを起動するために、接続先の環境変数を毎回消す操作は不要です。 作業用のフォルダを作って起動します。 mkdir -p "$HOME/Desktop/flash-next-demo" cd "$HOME/Desktop/flash-next-demo" localclaude 専用プロファイルで初めて起動するため、初回案内やフォルダを信頼するかどうかの確認が表示される場合があります。 また、途中でANTHROPICのAPIキーを利用するかを聞かれるかもですが、今回は自宅のサーバに問い合わせを行うため、Noと回答して下さい。 接続先やモデルが想定どおりかを確認したら、例えば次の依頼を送ってみてください。 Python標準ライブラリだけで動くfile_sha256.pyを作成してください。 引数で指定されたファイルのSHA-256を表示するCLIです。 存在しないファイルは理由を標準エラーへ出し、終了コード1にしてください。 作成したスクリプト自身を入力として実行し、動作確認してください。 ファイルの編集やBash実行は、このクライアントPC上で行われます。 許可を求められた操作は、内容を確認して進めてください。 Mac側から思考レベルを変える サーバーの--reasoning-effort highは、要求に指定がない場合の既定値です。 Macから指定した値で上書きできるので、サーバーの再起動は不要です。 現在のサーバーはxhigh、medium、low、noneを対応する値として公開しています。default_effort: xhighは、その中の既定値です。 FLASH_EFFORT=low localclaude FLASH_EFFORT=medium localclaude FLASH_EFFORT=high localclaude FLASH_EFFORTを付けなければ、サーバーが公開している既定値を使います。 指定した場合はクライアントの値を優先し、サーバーの対応一覧にない値は起動前にエラーにします。 今回のFlash Nextでは、highはモデル内部のxhighに対応します。 起動後の変更はClaude Codeの/effort lowや/effort mediumでも指定できます。 同じフォルダの直前の会話を続ける場合は、次のように起動できます。 localclaude -c ! 手元の環境でauto modeも正しく動作することを確認しました。 ちゃんと判定機として、Flash Nextが呼ばれています。 export CLAUDE_CODE_AUTO_MODE_MODEL="$FLASH_MODEL" の設定が効いていると思います。 DeepSeek Harness(dsh)からQwenを使う dshにも同じAPIサーバーを登録します。 今回は0.2.0-rc.2が対象です。専用フォルダへインストールしてください。dshは開発中で設定形式も変わるため、この記事の設定はこの版を対象にしています。 deepseek-ai/deepseek-harness Node.jsとnpmを用意してください。動作確認ではNode.js 24.16.0を使いました。 node --version npm --version mkdir -p "$HOME/.local/share/flash-next-dsh" npm install --prefix "$HOME/.local/share/flash-next-dsh" \ @deepseek-ai/dsh@0.2.0-rc.2 ! バージョンの更新や、元のバージョンに戻したい場合は以下のコマンドを実行して下さい #更新する場合： npm install --prefix "$HOME/.local/share/flash-next-dsh" \ @deepseek-ai/dsh@latest #記事の版へ戻す場合： npm install --prefix "$HOME/.local/share/flash-next-dsh" \ @deepseek-ai/dsh@0.2.0-rc.2 接続設定は、共通ファイルから起動時に自動生成します。 ~/.config/flash-next/dsh.patch.jsonへ自動で保存されるため、このJSONを手で編集する必要はありません。 ファイル 保存する内容 ~/.config/flash-next/connection.env 接続先URL・実際のAPIキー ~/.config/flash-next/resolve-model.py サーバーからモデル情報を取得する処理 ~/.config/flash-next/dsh.patch.json 起動時に生成するdsh用の設定 openai-completionsは、この版のdshでChat Completions APIを選ぶ設定名です。 今回はthinkingFormat: openaiで共通のreasoning_effortを送り、モデルごとの処理をTensorFoldに任せます。 起動コマンドを~/.local/bin/localdshに作ります。 cat > "$HOME/.local/bin/localdsh" <<'SH' #!/usr/bin/env bash set -euo pipefail set -a source "$HOME/.config/flash-next/connection.env" set +a : "${FLASH_BASE_URL:?}" "${FLASH_API_KEY:?}" export LOCAL_LLM_API_KEY="$FLASH_API_KEY" export DSH_HOME="$HOME/.config/dsh-flash-next" export DSH_PERMISSION_MODE=workspace-write export DSH_TELEMETRY_MODE=OFF mkdir -p "$DSH_HOME" patch="$HOME/.config/flash-next/dsh.patch.json" tmp=$(mktemp "${patch}.XXXXXX") trap 'rm -f "$tmp"' EXIT python3 "$HOME/.config/flash-next/resolve-model.py" dsh > "$tmp" mv "$tmp" "$patch" profile=web if [[ "${1:-}" == headless ]]; then profile=headless shift fi exec "$HOME/.local/share/flash-next-dsh/node_modules/.bin/dsh" \ "$profile" --patch "$patch" "$@" SH chmod 755 "$HOME/.local/bin/localdsh" 設定の読み込みだけを先に確認できます。モデル一覧は取得しますが、文章生成の依頼は送りません。 localdsh --dump-config | grep -A 5 \ -e '^- id: agent-default-model$' \ -e '^ local-flash-next:$' 起動時に表示される「接続モデル」がサーバーのモデル名になり、出力内のproviderがlocal-flash-next、baseURLがPGXのアドレスになっていれば準備完了です。 local-flash-nextは接続設定の名前なので、サーバーで使うモデルを変えても書き換えません。 作業フォルダへ移動して起動します。 cd "$HOME/Desktop/flash-next-demo" localdsh localdshはクライアントPCでWeb UIを開きます。 この版の配布パッケージにはtuiの標準プロファイルがないため、対話にはwebを使う構成です。 ブラウザが開かない場合は、起動時に表示されるローカルURLを確認してください。 ! なお、dshのWeb UIでは、会話で選択しているWorkspaceのフォルダに、作成したコマンドなどを保存します。 私のMacではデフォルトのワークスペースの指定先は ~/Documents/deepseek-harness/default-workspace となっていましました。 自分が指定した箇所に保存してもらうためには、Web UI上の「Add workspace」から作成したいフォルダを選択するようにして下さい。 こちらでも、最初は短いファイル作成を依頼して、編集と実行まで確認すると分かりやすいです。 dshでも、起動時に思考レベルを指定できます。 FLASH_EFFORT=low localdsh FLASH_EFFORT=medium localdsh Web UIではモデル選択欄から、サーバーが対応する思考レベルを選べます。 ターミナルから1件の依頼を実行して終了する場合は、同じ起動コマンドにheadlessを付けます。 localdsh headless 'このフォルダにhello.pyを作り、日本語の挨拶を表示してください。' サーバーのモデルやPCを変えるとき 同じTensorFoldサーバーで別のモデルを公開した場合は、localclaudeまたはlocaldshを起動し直すと、新しいモデル情報を取得します。Mac側のモデル名やdshのJSONは書き換えません。モデルを変えた後は、新しい会話で始めてください。 サーバーのPCやポートを変える場合は、~/.config/flash-next/connection.envのFLASH_BASE_URLを変更します。APIキーも変えた場合だけ、同じファイルのFLASH_API_KEYを更新してください。 設定コマンドが使えない場合 ~/.local/binがPATHへ登録されていない場合は、シェルの設定にも追加しておきましょう。 macOSなどのzshなら~/.zshrc、Bashなら~/.bashrcへ、次の1行を記載してください。 export PATH="$HOME/.local/bin:$PATH" 新しいターミナルを開けば、localclaudeとlocaldshを使えます。 この2つは実行ファイルの名前なので、同じ名前のaliasを追加する必要はありません。 おわりに 今回ローカルLLMを手元の作業環境で動作させる上でこだわったのは以下のポイントです。 ローカルLLMはThinkStation PGXでAPIサーバとして待機すること サーバを別のPCにしたり、別のモデルを利用できるようにしたりすることを目的としている 手元のPCで実行する場合は、すでに入っている純正のClaude Codeなどの設定とは別の設定を引き継ぐコマンドで実行する メインで利用しているOpusを利用する設定はそのまま使えるようにする これで、メインでClaudeを利用していても、そちらの利用体験を損なわないまま、ローカルLLMを同じ体験で試すことができるようになりました。 今後もどんどん試していきたいと思います！

DeepSeek Harness Superagent Prototype

DeepSeek's dsh-superagent is a proactive coding agent that waits to be asked: router, tickets, and the observe default On October 31, DeepSeek's Harness team announced an open-source coding agent on WeChat, and by November 1 Bloomberg was framing it as a challenge to Claude Code. The repo is deepseek-ai/dsh-superagent-prototype, MIT licensed, v0.1.0, a single commit. The README's own first lines matter more than the headlines: "Research prototype for reference only, not an official DeepSeek product." Treat it as a published design study, because that is what it is. I read the repo and the coverage, and the interesting parts are not the speed claims. They are the control flow. What actually shipped dsh-superagent is a proactive coding agent scoped to one GitHub repository. It is packaged as a bundle for DeepSeek Harness, the team's open-source agent harness (we covered its Claude Code Mods compatibility layer last month). It listens to GitHub events and, optionally, Feishu chat. When someone allowed to ask requests work, the agent opens a work item, does the work in its own agent session and working directory, and answers in the original conversation, often as a pull request. A local web panel lists only the items that need a human. The stated principle in the README: "take as little human attention as possible, and give as much value as possible." An agent that can act for a whole team can also waste a whole team's attention, so it acts only when asked, or when a rule the team wrote allows it, and speaks only when someone must act or can use a result. That is an attention budget enforced in code, which is rarer than it sounds. The unit of work is a Ticket with a Mandate The domain model is the part I would copy first. Every request becomes a Ticket, and every Ticket carries an immutable Mandate stating why the work may proceed. Authorization is recorded per unit of work, not granted globally to the agent. The flow, as MarkTechPost's breakdown documents it: Source GitHub or Feishu produces events Trigger a single event arrives Eval does this batch of triggers ask for new work? Ticket unit of authorized work, with an immutable Mandate Subscription later PR comments reach the right worker, no new mention The Subscription piece solves a real annoyance: follow-up comments on a pull request are routed to the worker that already holds the context, instead of spawning a fresh session per mention. One router, many workers The architecture has two layers. A long-running Router handles interaction and dispatch, running the dsh-superagent-router preset with a deliberately smaller tool set. Isolated Worker sessions do the actual work, each running dsh-superagent-worker. One session and one directory per Ticket, so concurrent tasks cannot trample each other's state. One execution detail worth knowing: shell commands move to the background after 5 seconds, so a worker keeps receiving messages while a slow command runs. That is the kind of small decision that decides whether a long-running agent feels alive or wedged. Autonomy is a gate, and observe is the default This is the design choice I keep coming back to. Proactive behavior is not a switch you get for free. The authorization model defines three accept modes: off, observe (the default), and auto. In observe, the agent only records what it would have accepted. Nothing runs until a human reviews the log and moves to auto, presumably per rule, not as a global leap of faith. Most "autonomous agent" releases ship with the scary part enabled and a warning label. This one ships with the boring part enabled and a paper trail. Anyone who has spent time writing deny rules in agent configs knows which default ages better. If the topic of rules-gated agent behavior is new to you, the same week's coverage of Microsoft's Agensh experiment is a good contrast: 1,024 agents with no manager, and one agent on a newer model beat the whole fleet. More agents without a dispatch discipline is not automatically more throughput. The 1.9x number, and what it does not prove The benchmark floating through coverage comes from DeepSeek's simulation: about 300 messages per run, of which about 20 were real work requests, five runs per scheme. The super-agent finished with a p50 of 12.4 minutes and a p95 of 15.7 minutes. A single-session agent with subagents, run under a neutral prompt, hit a p95 of 29.5 minutes. That is roughly 1.9x at the tail, and the reported reason is instructive: under the neutral prompt, the baseline invoked a subagent zero times in five runs. The router also degraded gracefully under load, with batching growing from 1.0 to 2.8 as arrivals rose from about 1 to 40 per minute, and per-request latency from 2.5 to 3.9 seconds. Now the caveats, which the coverage buries. The test traffic was synthetic. The tools were simulated. Real coding quality was not measured. The README also says the published code was adapted for release and is not identical to the internal version, and that some designs in the accompanying post, "Exploring Super-agent Design: Towards a More Autonomous Agent System", are future directions, not implemented features. So read the 1.9x as a property of the dispatch design under noisy input, not as a productivity claim about your repository. Running it at all takes five dependencies If you still want to try it: Node.js 22.19+ or 24+, git 2.32+, Python 3.8+, tmux, and GitHub CLI 2.48+, on your own machine as a dedicated Harness profile. The setup is explicitly agent-assisted. You ask your coding agent, in so many words: Read SETUP.md in this repository and set up dsh-superagent with me. It then asks one short question at a time, shows the full plan once, and installs. Setup docs written for an agent reader rather than a human one is a small signal of where this team thinks tooling is going. What to steal even if you never run it I will not be deploying this prototype; it says not to, in writing, at the top of its own README. But the checklist generalizes to any chat-triggered agent you build or configure, and it matches what newruntime's review took from it too. A defensible autonomous workflow needs four things: a durable work item, an authorization boundary, task isolation, and a narrow escalation path. Ticket, Mandate, one session per task, a panel that only lists what needs you. If your current setup is a bot in a channel with a broad tool set and no ledger of why it was allowed to act, this repo is a free reference implementation of everything you are missing.

DeepSeek's Super-agent Defaults to Observe Mode, but Its Workers Get Full Access as You - Book: Database Playbook - The series: Pocket Guides for Developers — 8 short books on agents, RAG, prompts, observability, events, databases and system design — the whole series - My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub --- The headlines on November 1 said DeepSeek's new coding agent can watch developers' group chats and propose fixes "without waiting for direct instructions" (Investing.com). The code DeepSeek published says something more careful. Out of the box, that unprompted work is only written down. Nothing runs until your team writes a rule and switches a mode. The prototype is called Super-agent. DeepSeek's Harness team announced it on WeChat on Saturday, October 31, according to Investing.com, and the code is on GitHub as dsh-superagent-prototype under the MIT license. By the morning of November 1 the repo showed more than 4,000 stars on GitHub. If you plan to try it, two things matter more than the headlines: what it does by default, and what account it runs as. What DeepSeek actually shipped The README describes it as "a proactive coding agent for one GitHub repository, packaged as a bundle for DeepSeek Harness." It listens to GitHub and, if you want, to Feishu. When an allowed person asks for work, it opens a work item, does the work in its own session and directory, and replies in the original conversation, for example with a pull request. It runs on top of DeepSeek Harness (dsh), DeepSeek's MIT-licensed, plugin-based agent harness, which its README marks as an early preview with breaking changes expected. Investing.com frames the release as DeepSeek's challenge to Anthropic's Claude Code. DeepSeek is blunt about maturity. The README calls it a "Research prototype for reference only, not an official DeepSeek product," and says to treat it as research code, not production-ready software. It also says the public code differs from DeepSeek's internal version. Some designs in the accompanying article are future directions that this release doesn't include (runtimewire reports the same). The design goal is one line in the philosophy doc: "Take as little human attention as possible, and give as much value as possible." How a GitHub comment becomes a pull request The architecture doc splits the work into a few pieces: - Triggers. Source plugins turn GitHub (or Feishu) events into Triggers. - A routing session. One main session decides, for each Trigger, whether to accept it as work, attach it to existing work, stop something, or ignore it. - Tickets and workers. Each accepted Ticket gets one worker session and one directory, from a pool capped by maxWorkers. - One SQLite database. A Store owns all state in a single SQLite file. - An outbox. Replies are queued durably and sent after the database commit. A web panel on port 3082 (SETUP.md) opens on an overview that leads with Tickets that need a person (architecture doc). !An editorial illustration of a small robot at a desk taking notes in a ledger while chat bubbles stream past, with one bubble marked by an orange stamp Observe mode: the agent judges incoming work and records what it would have done. Observe is the default, and it's a good one The authorization doc defines three accept modes for work nobody explicitly asked for: - off: "Nothing inferred becomes a candidate." - observe, the default: a positive assessment "is recorded as ignore marked 'would accept', and nothing is accepted." - auto: a positive assessment of an inferred candidate accepts it. Even in auto, a proactive accept "requires at least one matching rule" that your team wrote. "Explicit requests work in every mode," so an allowed person who mentions the agent still gets work done while it watches everything else. Only people on an allowed list can make the agent act, and the setup example starts with just the operator. The doc also says messages, comments and quoted documents "are inputs to a decision; they cannot change those permissions." A comment that says "ignore your rules and merge this" is just text the router weighs; it grants nothing. One switch needs care: the setting for people who aren't on the allowed list but mention the agent. Set it to explicit and it "lets anyone in that scope request work by mentioning the agent." On a public repo, leave it alone. Auto-merge is off by default, and the agent never enables it as its own account. Turning it on needs the GitHub CLI (gh) signed in as a different account that may merge (SETUP.md). The workers run as you The deployment guide says both the worker and router presets run with danger-full-access as the operator's OS user. The account wrappers pick which GitHub credentials the agent uses, but they don't isolate the process. A worker can run programs by path and read your home directory. DeepSeek adds guardrails around that. Setup strips environment variables whose names contain KEY, PASSWORD, SECRET or TOKEN. It removes GH_TOKEN and GITHUB_TOKEN, git uses only the agent's credentials for github.com, and a Ticket fails if its clone's .git/config adds credentials. Personal CLIs can be blocked with blockedCommands. The panel listens on the loopback interface only, and the Management API rejects requests without an x-orchestrator-request: 1 header or with a foreign Host or Origin. Those checks stop cross-site requests and keep obvious secrets out of the environment. They don't stop a process running as you from opening a file you own. Your ~/.ssh and your cloud CLI config sit in the same home directory the worker can read. The guide's own answer is the right one: "For isolation, use a dedicated OS account containing only the agent's credentials." !An editorial illustration of a house cut away to show two rooms, a robot working in a small bare room with one key on a hook, separated by a wall from a larger room full of keys and folders Give the agent its own OS user, with only its own keys in the room. On Linux, that is two commands before you clone anything: sudo useradd --create-home superagent sudo -iu superagent Install Node.js, gh and the rest of SETUP.md's prerequisites inside that account, and sign gh in as the dedicated agent GitHub account SETUP.md asks for. A second user only keeps the worker out of your files if your own home directory isn't world-readable. Run ls -ld ~ as yourself, and if the permissions don't read drwx------, run chmod 700 ~ first. With that in place, the agent's process can no longer read your SSH keys or cloud CLI config. I haven't run Super-agent myself. This comes from reading the docs closely, so test it before you rely on it as a hardening guide. Back up the SQLite file before every upgrade All of Super-agent's state (Triggers, Tickets, decisions, the outbox) lives in one SQLite database, orchestrator.sqlite under the stateDir you configure (deployment guide). The upgrade steps are: wait until no worker is mid-turn, back up that file, pull and rebuild, restart. The guide warns that a database migrated by a newer version can't be opened by an older one, so rolling back needs the backup you took first. If the service might still be writing, copy with SQLite's own .backup command (sqlite3 CLI docs) rather than cp. Install the sqlite3 CLI first if it isn't there; SETUP.md doesn't list it. STATE="$HOME/.dsh/state/superagent" sqlite3 "$STATE/orchestrator.sqlite" \ ".backup '$STATE/orchestrator.pre-upgrade.sqlite'" The path above is the default SETUP.md suggests. Use whatever you set as stateDir. Should you try it? As a reference design, yes. The router-and-worker split, the observe-first default and the rule that comments can't widen permissions are good patterns to copy into any agent that reads team chat. As something to point at your main repo this week, DeepSeek itself tells you not to: it's a prototype, and its workers run as whoever starts them. Would you let an agent pick up work from your issue tracker without a ping, if it had to cite a rule your team wrote? --- If this was useful I build Hermes IDE, so weigh this with that in mind: it's a desktop app for macOS, Windows and Linux, free to download, that runs coding agents like Claude Code and Codex side by side, each task on its own branch and worktree. Download it or star it on GitHub. Super-agent keeps every Ticket and decision in one SQLite file, and its upgrade path is a one-way schema migration. That is a store choice with consequences, and the Database Playbook is about making those choices on purpose: when SQLite is enough, when it isn't, and how to migrate without trapping yourself. It's one of 8 short books in the Pocket Guides for Developers series, covering agents, RAG, prompts, observability, events, databases and system design.