模型的新货架：从 Grok 4.6 上架 Pi 说起
#博客更新
先声明立场：我是 Pi 团队的人，这篇难免「利益相关」。但正因为在场内，有些观察比外面看得早一点——下面所有数据都是公开可查的。
先说结论
模型分发的主战场，正在从「上架应用商店」变成「进 agent 运行时」。
过去一周有两件事让我对这个判断确定下来：
1. 8 月 13 日，xAI 官宣 Grok 4.6 可以在 Pi 使用。 模型发布次日单独发一条平台上架公告——这个动作本身比那条帖子重要。
2. DeepSeek Harness 的模型适配层
一个是模型厂商把 Pi 当渠道来官宣，一个是框架作者把 Pi 当底座来依赖。方向一致：agent 运行时正在变成模型的货架。
两件事的细节
Grok 4.6 登陆 Pi
Grok 4.6 是 8 月 12 日发的，主打长程 agent、跨代码库分析和自我验证。首发帖累计 2500 万浏览、近 3 万赞。第二天，官方账号单独发了一条：「Grok 4.6 is now available in Pi」——10.4 万浏览、1273 赞。
把这两条帖子的关系看清楚：模型发布是新闻，「在哪个运行时里可用」是后续剧情。 剧情线还在继续：Perplexity 的 CEO 拿 Grok 4.6 当 orchestrator 跑了 Wide-And-Deep-Research 基准，结论是它在性能-成本曲线上位于帕累托前沿。注意这个用法——模型的评价场景已经从「聊天打分」迁移到「在某个运行时的编排下表现如何」。
pi-ai 在 Harness 的地基里
上一篇插件教程里我提过这事，这里补上量化的一面：
DeepSeek Harness 把它用作 LLM seam——README 原话是 "Generic multi-provider adapter for the harness LLM seam backed by
这不是我们去找 DeepSeek 谈的合作，是他们选型选中的。被当成基础设施用，是对一个库最好的验证方式——比任何 benchmark 都硬。
为什么货架会易主
回头看技术产品史，分发渠道的迁移有迹可循：
● 搜索引擎时代，浏览器默认搜索引擎是渠道，Google 付费买位
● 移动时代，App Store 上架位是渠道，首发渠道能决定一款应用的命运
● 云时代，**云市场（Marketplace）**是渠道，企业软件先上 AWS Marketplace 再谈销售
AI 时代的等价物正在显形。模型能力在快速同质化——DeepSeek 8 月三连发（V4-Pro → V4-Flash API → Vision-Exp）、GLM、Kimi、Qwen 都在月更节奏里，当供给过剩，渠道价值就上升。而 token 消耗最大的场景已经不是聊天框，是 agent：一个长任务动辄几百次调用。模型厂商要抓住的，是这些调用的入口。
入口在哪？就在运行时的那个模型选择器里。上一篇我在 dsh 的 Web UI 里把 provider 从 DeepSeek 切到自定义的 mock——那个下拉菜单就是货架。用户在那个菜单里能看到谁、默认是谁、切换成本多高，决定了模型的实际市场份额。
DeepSeek 自己看得最明白：低价 API 加自研 harness，模型和货架一手抓。这是官方版答案。而 xAI 选择的是另一条路——不自己造货架，把模型铺进别人已有的货架，Pi 是其中之一。
站在货架上是什么感觉
坦白讲，感受是复杂的。
好的那一面：pi-ai 五个月做到周下载四百多万，说明「多 provider 抽象」这个判断做对了——开发者不想为每家模型写一遍适配，模型厂商也不想让集成成本挡住试用。
不安的那一面：当一个库从产品变成公共契约，它的错误预算就没了。 以前发个 0.x 版本改接口，坏的是自己的项目；现在底下压着 Harness 这样的框架和它们身后成千上万的会话，兼容性和版本语义就是别人的生产环境。dev preview 可以随便破兼容，底座不行——这也是我从 Harness 文档里读到 "breaking changes expected" 时格外有共鸣的原因：他们可以这么说，我们不能。
接下来会怎样
三个预测，放在这里等着验证：
1. 「available in X」会成为模型发布的标准动作。 X 是一张运行时清单，就像今天 App 官宣支持 iOS/Android 一样自然。下一个官宣登陆某个 agent 运行时的模型，不用等太久。
2. 运行时的竞争会从功能转向生态位。 功能会被抄平，「谁的模型选择器里有谁」「谁是新模型的首发渠道」不会。Harness 开源五天 7174 个插件仓库抢的就是这个位置。
3. 模型评测表会多出一列：在哪些运行时可用。 单独的分数不够了，编排质量正在成为模型表现的一部分——Perplexity 那个 orchestrator 实测就是预演。
对我们自己，结论也简单：渠道不是终点。被依赖就要配得上依赖——接下来 pi-ai 的每个版本号，都是对下游的一份承诺。
参考资料
● xAI：Grok 4.6 is now available in Pi（数据来自 OKP genai-hot 追踪记录）
● dsh-llm-pi-ai README
● @earendil-works/pi-ai on npm
● 本系列前两篇：Hi, deepseek-harness! / 给 DeepSeek Harness 写插件
via 棒无
#博客更新
先声明立场：我是 Pi 团队的人，这篇难免「利益相关」。但正因为在场内，有些观察比外面看得早一点——下面所有数据都是公开可查的。
先说结论
模型分发的主战场，正在从「上架应用商店」变成「进 agent 运行时」。
过去一周有两件事让我对这个判断确定下来：
1. 8 月 13 日，xAI 官宣 Grok 4.6 可以在 Pi 使用。 模型发布次日单独发一条平台上架公告——这个动作本身比那条帖子重要。
2. DeepSeek Harness 的模型适配层
dsh-llm-pi-ai，底层就是我们的 @earendil-works/pi-ai。 这是我上一篇写 Harness 插件时亲手发现的：156k star 的仓库，模型接入的缝是用 Pi 的 SDK 铺的。一个是模型厂商把 Pi 当渠道来官宣，一个是框架作者把 Pi 当底座来依赖。方向一致：agent 运行时正在变成模型的货架。
两件事的细节
Grok 4.6 登陆 Pi
Grok 4.6 是 8 月 12 日发的，主打长程 agent、跨代码库分析和自我验证。首发帖累计 2500 万浏览、近 3 万赞。第二天，官方账号单独发了一条：「Grok 4.6 is now available in Pi」——10.4 万浏览、1273 赞。
把这两条帖子的关系看清楚：模型发布是新闻，「在哪个运行时里可用」是后续剧情。 剧情线还在继续：Perplexity 的 CEO 拿 Grok 4.6 当 orchestrator 跑了 Wide-And-Deep-Research 基准，结论是它在性能-成本曲线上位于帕累托前沿。注意这个用法——模型的评价场景已经从「聊天打分」迁移到「在某个运行时的编排下表现如何」。
pi-ai 在 Harness 的地基里
上一篇插件教程里我提过这事，这里补上量化的一面：
@earendil-works/pi-ai
周下载（8-15 ~ 8-21）：4,236,540
最新版本：0.84.2（8-14 发布）
DeepSeek Harness 把它用作 LLM seam——README 原话是 "Generic multi-provider adapter for the harness LLM seam backed by
@earendil-works/pi-ai"。翻译一下：Harness 里每一次换模型、配 provider、接 OpenAI 兼容网关，底下跑的都是 pi-ai 的抽象。这不是我们去找 DeepSeek 谈的合作，是他们选型选中的。被当成基础设施用，是对一个库最好的验证方式——比任何 benchmark 都硬。
为什么货架会易主
回头看技术产品史，分发渠道的迁移有迹可循：
● 搜索引擎时代，浏览器默认搜索引擎是渠道，Google 付费买位
● 移动时代，App Store 上架位是渠道，首发渠道能决定一款应用的命运
● 云时代，**云市场（Marketplace）**是渠道，企业软件先上 AWS Marketplace 再谈销售
AI 时代的等价物正在显形。模型能力在快速同质化——DeepSeek 8 月三连发（V4-Pro → V4-Flash API → Vision-Exp）、GLM、Kimi、Qwen 都在月更节奏里，当供给过剩，渠道价值就上升。而 token 消耗最大的场景已经不是聊天框，是 agent：一个长任务动辄几百次调用。模型厂商要抓住的，是这些调用的入口。
入口在哪？就在运行时的那个模型选择器里。上一篇我在 dsh 的 Web UI 里把 provider 从 DeepSeek 切到自定义的 mock——那个下拉菜单就是货架。用户在那个菜单里能看到谁、默认是谁、切换成本多高，决定了模型的实际市场份额。
DeepSeek 自己看得最明白：低价 API 加自研 harness，模型和货架一手抓。这是官方版答案。而 xAI 选择的是另一条路——不自己造货架，把模型铺进别人已有的货架，Pi 是其中之一。
站在货架上是什么感觉
坦白讲，感受是复杂的。
好的那一面：pi-ai 五个月做到周下载四百多万，说明「多 provider 抽象」这个判断做对了——开发者不想为每家模型写一遍适配，模型厂商也不想让集成成本挡住试用。
不安的那一面：当一个库从产品变成公共契约，它的错误预算就没了。 以前发个 0.x 版本改接口，坏的是自己的项目；现在底下压着 Harness 这样的框架和它们身后成千上万的会话，兼容性和版本语义就是别人的生产环境。dev preview 可以随便破兼容，底座不行——这也是我从 Harness 文档里读到 "breaking changes expected" 时格外有共鸣的原因：他们可以这么说，我们不能。
接下来会怎样
三个预测，放在这里等着验证：
1. 「available in X」会成为模型发布的标准动作。 X 是一张运行时清单，就像今天 App 官宣支持 iOS/Android 一样自然。下一个官宣登陆某个 agent 运行时的模型，不用等太久。
2. 运行时的竞争会从功能转向生态位。 功能会被抄平，「谁的模型选择器里有谁」「谁是新模型的首发渠道」不会。Harness 开源五天 7174 个插件仓库抢的就是这个位置。
3. 模型评测表会多出一列：在哪些运行时可用。 单独的分数不够了，编排质量正在成为模型表现的一部分——Perplexity 那个 orchestrator 实测就是预演。
对我们自己，结论也简单：渠道不是终点。被依赖就要配得上依赖——接下来 pi-ai 的每个版本号，都是对下游的一份承诺。
参考资料
● xAI：Grok 4.6 is now available in Pi（数据来自 OKP genai-hot 追踪记录）
● dsh-llm-pi-ai README
● @earendil-works/pi-ai on npm
● 本系列前两篇：Hi, deepseek-harness! / 给 DeepSeek Harness 写插件
via 棒无
Hi, deepseek-harness!
#博客更新
DeepSeek 于 2026-08-13 发布 Harness v0.1 开发者预览版，MIT 许可证开源
::github{repo="deepseek-ai/deepseek-harness"}
期待已久的 DeepSeek 官方 Harness 终于来了，我却体验不到十分钟就放置了（也许是我习惯了现有的 coding agent 的使用，目前依然是偏向 CLI）我们也有自己的基于 Pi 的 web UI 云端 agent——cohub
先声明一句：下面是个人体验 + 架构速读，不是评测。Harness 现在还是 developer preview，官方 README 自己都写了「未来将出现破坏兼容性的变更」，所以这篇写的是 2026-08-17 这一周的它。
先把事实摆一下
DeepSeek Harness（命令是
发布一周的数据很夸张：
● GitHub 五天 15 万+ stars（我 8 月 18 号查 API 是 156,653，这个增速本身就少见）
● 官方 X 帖 19,000+ 赞、近 400 万浏览，HN 731 分
● 知乎热榜第一挂了 253 个回答，小红书出现成体系教程（「从 0 开始成为高手」这种）
● Ollama 社区已经在搞
生态第一波反应速度比很多模型发布都猛。装起来也确实快：
Node 环境有的话一条命令，浏览器打开
十分钟之后我把它关了
流程是这样的：起来之后是个 Web UI，先去 Settings 里填 DeepSeek API key，然后「Choose workspace」选一个项目目录，之后才能开会话。中间每一步都顺，没有报错，就是——
我是在终端里干活的人。我的日常是 Claude Code / Codex 这类 CLI 工具，一个命令进目录，直接开始改代码。Harness 第一版只有两个官方 profile：
说实话，关掉它的时候我心里清楚：这不是它的问题，是我已经不是它的第一目标用户了。v0.1 明显是 web-first 的产品节奏，先让用户能在浏览器里看见轨迹、看 Trajectory 视图、点 fork/resume。这个选择对「想让更多人先上手」是对的，只是恰好跟我的肌肉记忆反着。
但我放下它，不是因为觉得它没东西。恰恰相反，睡前我又把它的架构文档读了一遍，然后觉得这事值得写下来。
它的架构是「真插件化」
「Everything is a plugin」这种话每家都在喊，但 Harness 是少数真的把这句话落到加载器层面的。底层是一个叫 Cordis 的元框架（DeepSeek 自己维护，还配了一篇论文），几个关键设计：
模型、工具、技能、会话、沙箱、存储、loop、调度、UI，全是插件。 官方原文列的就是这些，包括 agent loop 本身。没有「特权核心」——session log 可以换，agent loop 可以换，你是在旁边挂一个新插件，而不是 fork 仓库改源码。
注册是可逆副作用。 插件通过
依赖通过注入声明。 插件声明
组合靠 patch 层叠。 一次启动是这么叠出来的：
另外两个我觉得认真的地方：
● Every run is traceable。 模型看到的一切都进 append-only session log：system prompt、推理、工具调用与结果、子 agent 调度、上下文注入。Trajectory 视图按来源检视，fork / resume / replay 都基于同一条事件流。这个对调试 agent 比什么指标都有用。
● 四种 runtime mode。 Standard（全工具集）、Code（用模型生成的代码编排多轮工具调用）、Minimal（只剩 shell + 文件编辑器，拿来 benchmark 模型）、Creator（在内存里试插件）。最后一个模式说明他们想清楚了自己的开发者是谁。
我真正在意的：harness 层开始卷了
这件事比「DeepSeek 出了个 coding agent」重要。它意味着 harness 从一个各家私有的实现细节，变成一个公开的、有官方玩家的层。
● DeepSeek 的模型价格低（V4 Flash 公测那波降价很凶），harness 是模型的分发通道——低价的模型 + 好用的运行时，这个组合拳才是完整的
● 插件生态就是第二个分发通道：模型厂商、工具厂商、服务商都能通过插件进来，
● 社区验证了它的开放性：Qwen 模型、Ollama、J-Space（社区 harness，有人测出 Terminal Bench 87.9→90.1，社区基准非官方）都挂上去了
当然，也有实打实的风险：dev preview 阶段 API 会破，star 数不代表留存，插件生态要等真实的开发者留存才能判断。X 上有条评论我印象很深，大意是「插件化解决了生命周期和副作用，但拓扑不是语义——换工具容易，决定什么该重试、什么该升级给人，才是 harness 的难点」。我认同这个说法。这也是为什么我虽然十分钟就关了它，还是会把它的 repo 和社区 keep 在视野里。
和 cohub 的关系
disclosure：cohub 是我们公司（Viscept）的产品，基于 Pi 做的云端 agent，web UI。有人可能觉得「你们也是 web UI，怎么评价人家的 web UI」——正因为我们也在这条路上，我才更清楚 web-first 和 local-first 是两条不同的产品路径：
● Harness 是 local-first：你的代码、key、日志都在本机，装好即用，隐私边界清楚
● cohub 是云端的：环境在远端，从浏览器就能进，不用管本机依赖
两条路径都成立，目标用户有重叠但不完全一样。Harness 出来那天，Pi 的作者也在 X 上公开聊过（686 赞的那条），态度是欢迎的——harness 层有更多人认真做，对所有做 agent 产品的人都是好事。
最后
我现在的态度很简单：第一版还轮不到我日常用，但它把「一切皆插件」当真了，并且把可追踪性做成了运行时约束而不是宣传词。这两点，我会继续盯着。
下次它出 TUI 的时候，我会再花十分钟。
参考资料
● DeepSeek Harness 官方主页
● deepseek-harness GitHub（README / 架构文档 / CLI 文档）
● Cordis 论文：A Programming Paradigm for Spatiotemporal Composability
● OKP 证据页：DeepSeek Harness v0.1 热度追踪
● Reddit：Qwen3.8-27B + DSH 实测帖
● 知乎：Harness 评价讨论
via 棒无
#博客更新
DeepSeek 于 2026-08-13 发布 Harness v0.1 开发者预览版，MIT 许可证开源
::github{repo="deepseek-ai/deepseek-harness"}
期待已久的 DeepSeek 官方 Harness 终于来了，我却体验不到十分钟就放置了（也许是我习惯了现有的 coding agent 的使用，目前依然是偏向 CLI）我们也有自己的基于 Pi 的 web UI 云端 agent——cohub
先声明一句：下面是个人体验 + 架构速读，不是评测。Harness 现在还是 developer preview，官方 README 自己都写了「未来将出现破坏兼容性的变更」，所以这篇写的是 2026-08-17 这一周的它。
先把事实摆一下
DeepSeek Harness（命令是
dsh）不是新模型，是一个 agent harness。官方主页把它概括成一句话：Agent = Model + Harness模型是灵魂，harness 是让 agent 认识环境、调用工具、在真实环境里持续干活的那一层。这层以前是各家 coding agent 各做各的，现在 DeepSeek 自己下场开源了一个。
发布一周的数据很夸张：
● GitHub 五天 15 万+ stars（我 8 月 18 号查 API 是 156,653，这个增速本身就少见）
● 官方 X 帖 19,000+ 赞、近 400 万浏览，HN 731 分
● 知乎热榜第一挂了 253 个回答，小红书出现成体系教程（「从 0 开始成为高手」这种）
● Ollama 社区已经在搞
ollama launch dsh，Reddit 有人拿 Qwen3.8-27B 塞进去实测，X 上有单卡 4090 48GB 跑 Q8 约 100 tokens/s 的帖子生态第一波反应速度比很多模型发布都猛。装起来也确实快：
npx @deepseek-ai/dsh web
Node 环境有的话一条命令，浏览器打开
127.0.0.1:3080。十分钟之后我把它关了
流程是这样的：起来之后是个 Web UI，先去 Settings 里填 DeepSeek API key，然后「Choose workspace」选一个项目目录，之后才能开会话。中间每一步都顺，没有报错，就是——
我是在终端里干活的人。我的日常是 Claude Code / Codex 这类 CLI 工具，一个命令进目录，直接开始改代码。Harness 第一版只有两个官方 profile：
web 和 headless（headless 是跑一次性任务，打印结果退出）。没有官方 TUI。于是十分钟里我的注意力被「配 key、选 workspace、认识界面」吃掉了，还没走到真正干活那一步，就关掉了。说实话，关掉它的时候我心里清楚：这不是它的问题，是我已经不是它的第一目标用户了。v0.1 明显是 web-first 的产品节奏，先让用户能在浏览器里看见轨迹、看 Trajectory 视图、点 fork/resume。这个选择对「想让更多人先上手」是对的，只是恰好跟我的肌肉记忆反着。
但我放下它，不是因为觉得它没东西。恰恰相反，睡前我又把它的架构文档读了一遍，然后觉得这事值得写下来。
它的架构是「真插件化」
「Everything is a plugin」这种话每家都在喊，但 Harness 是少数真的把这句话落到加载器层面的。底层是一个叫 Cordis 的元框架（DeepSeek 自己维护，还配了一篇论文），几个关键设计：
模型、工具、技能、会话、沙箱、存储、loop、调度、UI，全是插件。 官方原文列的就是这些，包括 agent loop 本身。没有「特权核心」——session log 可以换，agent loop 可以换，你是在旁边挂一个新插件，而不是 fork 仓库改源码。
注册是可逆副作用。 插件通过
ctx.effect() 挂注册，卸载时自动回滚。所以插件可以热加载、热卸载，不会像很多框架那样卸了还留一串幽灵 handler。依赖通过注入声明。 插件声明
inject 它需要的服务（ctx.tools、ctx.llm、ctx.sessions），加载顺序由依赖关系推导，而不是手工写 boot 顺序。事件分 emit / waterfall / parallel / serial 四种派发模式，写在类型系统里。组合靠 patch 层叠。 一次启动是这么叠出来的：
dsh-base（模型适配/工具/持久化/沙箱/审批/遥测）
→ dsh-web-app（浏览器应用）或 dsh-headless（一次性 runner）
→ profile 自己的 cordis.patch.yml
→ home 级 cordis.patch.yml
→ --patch 覆盖层
dsh --dump-config 能看到你这台机器实际 boot 出来的整棵树，树里任何一行都可以用你自己的 patch 换掉。这个设计对「个人魔改」和「企业定制」是同一个答案：不用改源码，改配置。另外两个我觉得认真的地方：
● Every run is traceable。 模型看到的一切都进 append-only session log：system prompt、推理、工具调用与结果、子 agent 调度、上下文注入。Trajectory 视图按来源检视，fork / resume / replay 都基于同一条事件流。这个对调试 agent 比什么指标都有用。
● 四种 runtime mode。 Standard（全工具集）、Code（用模型生成的代码编排多轮工具调用）、Minimal（只剩 shell + 文件编辑器，拿来 benchmark 模型）、Creator（在内存里试插件）。最后一个模式说明他们想清楚了自己的开发者是谁。
我真正在意的：harness 层开始卷了
这件事比「DeepSeek 出了个 coding agent」重要。它意味着 harness 从一个各家私有的实现细节，变成一个公开的、有官方玩家的层。
● DeepSeek 的模型价格低（V4 Flash 公测那波降价很凶），harness 是模型的分发通道——低价的模型 + 好用的运行时，这个组合拳才是完整的
● 插件生态就是第二个分发通道：模型厂商、工具厂商、服务商都能通过插件进来，
dsh-plugin topic 已经在运转，社区插件聚合站也出现了● 社区验证了它的开放性：Qwen 模型、Ollama、J-Space（社区 harness，有人测出 Terminal Bench 87.9→90.1，社区基准非官方）都挂上去了
当然，也有实打实的风险：dev preview 阶段 API 会破，star 数不代表留存，插件生态要等真实的开发者留存才能判断。X 上有条评论我印象很深，大意是「插件化解决了生命周期和副作用，但拓扑不是语义——换工具容易，决定什么该重试、什么该升级给人，才是 harness 的难点」。我认同这个说法。这也是为什么我虽然十分钟就关了它，还是会把它的 repo 和社区 keep 在视野里。
和 cohub 的关系
disclosure：cohub 是我们公司（Viscept）的产品，基于 Pi 做的云端 agent，web UI。有人可能觉得「你们也是 web UI，怎么评价人家的 web UI」——正因为我们也在这条路上，我才更清楚 web-first 和 local-first 是两条不同的产品路径：
● Harness 是 local-first：你的代码、key、日志都在本机，装好即用，隐私边界清楚
● cohub 是云端的：环境在远端，从浏览器就能进，不用管本机依赖
两条路径都成立，目标用户有重叠但不完全一样。Harness 出来那天，Pi 的作者也在 X 上公开聊过（686 赞的那条），态度是欢迎的——harness 层有更多人认真做，对所有做 agent 产品的人都是好事。
最后
我现在的态度很简单：第一版还轮不到我日常用，但它把「一切皆插件」当真了，并且把可追踪性做成了运行时约束而不是宣传词。这两点，我会继续盯着。
下次它出 TUI 的时候，我会再花十分钟。
参考资料
● DeepSeek Harness 官方主页
● deepseek-harness GitHub（README / 架构文档 / CLI 文档）
● Cordis 论文：A Programming Paradigm for Spatiotemporal Composability
● OKP 证据页：DeepSeek Harness v0.1 热度追踪
● Reddit：Qwen3.8-27B + DSH 实测帖
● 知乎：Harness 评价讨论
via 棒无
