2026-08-16 23:55:00
零 API key、零依赖、零模型账单——用你自己的浏览器给 DSH 提供搜索能力。 #dsh-plugin
如果你在用 DSH（DeepSeek Harness），可能没注意到一件事：模型每调用一次 web_search 工具，后台就是一次 deepseek-v4-flash 的完整计费请求。
这是 DSH 自带搜索路由的实现方式——DeepSeek 没有独立的搜索端点，DSH 的做法是发起一次携带 web_search 服务器工具的完整模型调用。问题在于：
今天推荐的开源插件 dsh-web-search-ddg，就是来解决这件事的：它把搜索提供方换成你本地的浏览器——用机器上已经装好的 Chrome/Edge 以 headless 模式访问 DuckDuckGo，解析出结果链接返回给模型。
三个”零”：
全自动安装：直接把文末github地址扔给DeepSeek Harness。
手动安装：
第一步，在你的 DSH profile 目录下（通常是 ~/.dsh/profiles/web）安装：
ounter(linepnpm add dsh-web-search-ddg
第二步，编辑 cordis.patch.yml，加两段：
ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line# 把默认搜索提供方切到本地浏览器- id: webconfig:searchProvider: ddg-browser# 挂载插件- insert:- id: web-search-ddgname: dsh-web-search-ddg
重启 dsh web，生效。之后模型的每次 web_search 都走本地浏览器，DeepSeek 账单里再也不会出现搜索产生的扣费。
验证配置是否正确（不用启动宿主）：
ounter(linedsh --profile web --dump-config | grep -A2 searchProvider
自带的 DeepSeek 搜索提供方始终保持注册，切回来只是把 searchProvider 改回 deepseek-official。
这里有个设计细节值得说一下：DSH 的提供方选择是单一显式 ID，不是优先级链，没有静默降级。所以如果哪天 DuckDuckGo 反爬收紧，插件会明确报错、告诉你原因和怎么切回——而不是悄悄换个通道，让你以为一切正常结果搜索质量悄悄变差。对账单敏感的场景，这种”笨拙的诚实”其实很宝贵。
插件本体只有一个约 250 行的 index.js，流程很直白：
web_search 工具和结果卡片无需任何改动，体验一致。几个工程上的处理：headless 浏览器的 UA 会被覆盖成普通桌面 Chrome（否则会被反爬识别拦截）；每次搜索有超时兜底和两次尝试；临时浏览器配置用完即删。
全部可选，不配也能跑：
| 配置键 | 默认值 | 说明 |
|---|---|---|
chromePath |
自动探测 | 浏览器可执行文件路径。macOS 的 Chrome/Edge/Chromium 和 Linux 常见路径会自动识别 |
timeoutMs |
20000 |
单次尝试的超时预算，每次搜索共两次尝试 |
virtualTimeBudgetMs |
8000 |
页面沉寂多久后 dump DOM |
浏览器探测覆盖：macOS（Chrome、Edge、Chromium）与 Linux（/usr/bin/chromium、/usr/bin/google-chrome），找不到时用 chromePath 指定即可。
开源工具先说清限制，你再决定要不要用：
一句话总结适用人群：主力模型不在 DeepSeek 家、或者单纯不想让搜索产生模型账单的 DSH 用户，延迟不敏感的话，这就是当前最省心的方案。
README 有中英双语文档、完整的安装和故障排查说明。觉得有用欢迎 star，遇到问题直接提 issue。
在 macOS + DSH 0.1.0-rc.6 环境下实测通过。如果你也在DSH同时使用多家模型，欢迎聊聊你的账单优化心得。
2026-06-14 00:07:29
今年到5月下旬才确定好中国大陆地区版权依然由CCTV买下，转售给了咪咕和小红书、电视渠道转售给了五星体育和广东体育。
FIFA官方app：每场比赛拥有一个ig story形式的highlights，可以查看各地区的持权转播商。
FIFA官方小程序：中国大陆用户专属
央视频，CCTV5直播及每场比赛集锦，直播信号相比电视信号延迟有半分钟
小红书，直播延迟约10秒，提供多视角信号可切换
FotMob app，开启全量比赛实时活动，赛前赛中会直接显示在iPhone锁屏
一张赛程图的公众号推文，星标挂在微信中，随时展开即可查询赛程
其它：
Apple Sports App
worldcup2026ai.vercel.app
2026-06-10 00:07:00
2026 年 6 月，距离腾讯内部启动微信 AI 智能体项目整整一年。
2026 年 6 月 2 日，有媒体报道：腾讯正在测试一款内嵌于微信的 AI 智能体原型，最快当月启动合规审批流程，之后将对小范围用户灰度测试，随后逐步全量上线。
根据此前其他媒体的报道，微信 AI 智能体项目是腾讯内部最高优先级的绝密项目，从 2025 年上半年启动至今刚好一年。
2025 年 1 月 13 日，腾讯召开 2024 年度员工大会。Pony 首次透露微信将推出 AI 智能体。
再到今年年初的2025年度员工大会，他的表态依然谨慎而克制。
针对微信生态的智能化，马化腾明确表示：“AI 全家桶未必是大家都喜欢的”。他强调，微信将继续坚持”去中心化”原则，以兼顾用户需求和隐私安全的方式来规划微信的智能化。
与此同时，他也释放了一个关键信号——微信 AI 正在开发中了。
微信 AI 智能体的交互设计极简——在微信主界面右滑，即可唤出一个对话界面。
没有新增的 Tab，没有臃肿的设置页，不需要学习新操作。就是一个简单的滑动动作，你就进入了微信 AI。
在这个对话界面里，你可以用自然语言输入指令。比如：
“帮我找到附近人均 100 以内的川菜店，订两人位。”
“推荐几个适合周末去玩的周边目的地。”
“帮我叫一辆车去浦东机场。”
你不需要打开某个小程序，不需要在小程序里搜索，不需要一步步筛选。你的指令会被智能体理解，然后由它自动调度微信生态内对应的小程序来完成整个服务链路——从搜索、比价到下单、支付，全程无需人工干预。
这就是微信 AI 的核心形态：聊天。
但不同于你日常的聊天，这个聊天窗口连接的是微信内数百万个小程序。
马化腾在员工大会上的表态，看似矛盾，实则指向同一条路线。
“全家桶未必喜欢”，意味着微信不会像一些竞争对手那样，把 AI 功能粗暴地塞进每一个模块——不在搜索里加 AI 摘要，不在通讯录里加 AI 推荐，不在朋友圈里加 AI 滤镜。微信的智能化，选择了一个集中的、非侵入的方式：一个右滑，一个对话窗口。
这种方式既尊重了去中心化理念————AI 只是一个可选的入口，用户不需要它时完全可以不用——又避免了功能碎片化。
元宝 或者 微信Clawdbot 已经在微信里以”好友”的身份存在了一段时间，可以解析文章、解读文档、分析图片。但微信 AI 智能体是另一回事——它不是聊天机器人，它是服务编排者。
两者的关系，更像是”大脑”和”手脚”：元宝负责理解和分析，智能体负责调用和服务。或者说，微信 AI 智能体，可能是腾讯元宝能力在微信生态内的终极形态。
产品故事讲完了，我们再看另一面：供给侧。
6月8日，微信开发者公众号发布了一则面向开发者的公告——《关于开发者接入微信AI生态的指引》。这意味着，数百万小程序正被正式邀请成为微信AI的”手脚”。也意味着，之前都属于传言的微信AI，正式被官方平台官宣落地。
开发者可以在「小程序管理后台-AI能力」中主动授权接入，平台提供了两种模式：
自动模式几乎是零门槛——授权平台在提审时读取小程序源码，无需额外开发，平台将自动分析你的业务功能并生成可供AI调用的接口。对大多数小程序来说，这几乎是”开一下就行”。
开发模式则面向有定制化需求的团队。开发者基于自家小程序的业务特性，将功能抽象为原子接口和原子组件，封装成SKILL供微信AI调用。原子接口是最小的执行单元，封装单一业务功能；原子组件是界面元素；SKILL则是三者的有机组合。
两种模式并不互斥，可以同时开启。自动模式让小白开发者也能一键接入，开发模式让美团、京东这样的巨头可以保持自己的服务逻辑和体验差异化。
目前已经看到京东、美团、携程、滴滴、猫眼率先宣布接入。
微信AI生态的推出，将是微信自视频号推出6年来最大的交互变革。
回顾微信的发展，每一次重大升级都改变了一个行业：公众号改变了信息分发，小程序改变了 APP 生态，视频号改变了短视频格局。而 AI生态，也会是很大的一次。
这大概就是”超级智能助手”的终极形态：不需要记住它叫什么，它就在你手里，随时可用。
正好Apple的Siri AI今天也正式亮相，但国内用户暂时还用不了，对我们来说更接近的可能还是微信AI生态。
10年前，微信小程序开始内测的时候，我写了这篇文章https://mp.weixin.qq.com/s/2LDko87D5h9mMtcfQXGT6w 现在回头看，当时的判断基本都对了。
期待微信AI生态给我们带来更多生活上便利，让现在需要点击很多步的操作，都变成一个个自然语言输入，几秒内完成。
2026-06-09 22:44:40
今天凌晨的WWDC26算是近年来最让人期待的一届了。原因很简单————苹果终于把Apple Intelligence画了两年多的”大饼”端上了桌，而主角就是全新升级的 Siri AI。
不过看完整个主题演讲，我最大的感受是：这是一场”AI大于设计”的发布会。
如果说去年 iOS 26 是苹果自 iOS 7 以来最大的一次视觉革新（Liquid Glass 液态玻璃），那 iOS 27 就是在这块基石上的精细化打磨。
整体来看，iOS 27 并没有带来设计语言上的重大变化。Liquid Glass 的核心视觉风格——半透明、动态反射、光影自适应——基本保持不变。但这次苹果加入了一个非常实用的新特性：全局透明度滑块。
以前 Liquid Glass 的磨砂透明效果是”一刀切”的，喜欢通透感的用户和偏好传统 UI 的用户没法两全。iOS 27 在设置里提供了一个滑动条，用户可以自由调节各 App 中 Liquid Glass 材质的通透程度。从几乎不透明到高度半透明，完全取决于个人审美。
除此之外，iOS 27 还带来了一些细节优化：
这些改进让 Liquid Glass 从”尝鲜”走向”可用”，但确实不再是一个颠覆性的设计变革。设计的天花板已经在 iOS 26 封顶了，iOS 27 是在做减法而不是加法。
如果说 Liquid Glass 是”锦上添花”，那 Siri AI 就是 WWDC26 绝对的”C 位”。
这次 Siri 发生了颠覆性的蜕变：它不再只是一个悬浮在屏幕上的”语音弹窗”，而是被重塑为一个独立的、全天候在线的 AI 聊天应用。
全新的 Siri 拥有独立的聊天机器人界面——聊天气泡、文字输入框、语音/文字自由切换、历史会话回溯、对话置顶搜索。唤醒 Siri 后，灵动岛会实时显示交互状态。你可以像使用 ChatGPT 一样跟它进行多轮连续对话，它会记住上下文并做关联推理。
Siri AI 的核心引擎是苹果与谷歌合作定制的 Gemini 模型，这直接拉高了 Siri 的认知上限。发布会上演示的核心能力可以归纳为五大方向：
| 能力 | 说明 |
|---|---|
| 个人上下文理解 | 能调用你的邮件、信息、日历、行程等个人数据来回答问题 |
| 屏幕感知 | 能”看懂”当前屏幕上的内容，并基于此执行任务 |
| 跨 App 操作 | 能跨越多个应用自主执行任务 |
| 图像理解 | 分析图片内容、解读照片中的场景和文字 |
| 广泛世界知识 | 联网搜索、生成图片/邮件/笔记等 |
这是我最期待的功能。新版 Siri 能够主动读取并理解你的邮件、短信、日历、文件等个人数据。比如你问”朋友推荐的餐厅叫什么？”，Siri 能直接从你的聊天记录里找到答案。这种深度整合 Apple 生态的能力，是其他 AI 助手目前很难做到的。
Siri 现在能识别当前屏幕上正在显示的内容。比如你在地图上看到一个地址，Siri 可以直接帮你保存到通讯录；或者识别照片中的具体地点，并结合朋友发来的地址信息规划路线。
发布会上，Siri 可以一句话触发多个 App 的连续操作：找餐厅 → 查地图位置 → 设日历提醒 → 发消息通知朋友。这种”一句话跑通多步流程”的能力，就是所谓的代理式（Agent）操作。
但说实话，目前的跨 App 操作还比较有限。演示中的场景都是精心设计的”理想情况”，在真实使用中，能否像豆包手机或一些安卓 AI 助手那样真正实现自由的代理操作，还有待观察。苹果这次迈出了第一步，但距离”完全体”还有距离。
除了 Siri 本身的升级，WWDC26 还有一个重大消息：iOS 27 引入了”Extensions”机制，允许第三方 AI 模型接入系统级 Siri。
用户可以选择安装 Claude、Gemini、ChatGPT 等主流 AI 聊天机器人扩展作为 Siri 的 AI 引擎。这意味着苹果终于意识到，单靠自家模型打天下是不够的，开放生态才是未来。
这也是苹果首次在系统层面拥抱第三方 AI 模型，战略意义不言而喻。
这是整场发布会最大的”意难平”。
苹果在发布会上明确宣布：在中国大陆，Siri AI 和其他 Apple Intelligence 新功能因需配合监管要求，暂不提供。
这意味着：
Craig Federighi 在发布会尾声专门对此作了说明，但难掩遗憾。
说实话，从技术角度看，Siri AI 确实是 Apple Intelligence 发布以来最彻底的一次兑现。但对国内用户来说，这波 AI 翻身似乎又一次和自己无关。希望与国内 AI 公司的合作尽快落地吧。
| 维度 | iOS 27 Siri AI | 安卓 AI 助手（豆包等） |
|---|---|---|
| 独立 App |
 首次推出 |
已有 |
| 多轮对话 |
支持 |
支持 |
| 屏幕感知 |
支持 |
已实现 |
| 跨 App 操作 |
支持（有限场景） |
已实现 |
| 第三方 AI 接入 |
Claude/Gemini/ChatGPT |
开放生态 |
| 中文原生优化 |
 Gemini 打底 |
豆包等国产模型 |
| 国内生态整合 |
国行不可用 |
微信/小程序等 |
客观来说，国内 AI 助手在中文场景和生态整合上有优势，但 Siri AI 在 Apple 生态的深度整合、多模态能力和全球 AI 模型的前沿性上，确实有了质的飞跃。
iOS 27 的设计层面属于小修小补，Liquid Glass 更加成熟但不再颠覆。真正的重头戏是 Siri AI ——从”语音助手”到”AI 智能体”，从”弹窗工具”到”独立应用”，这十五年来 Siri 经历的最大一次重构。
虽然目前的 AI 能力（个人数据上下文 + 屏幕感知 + 有限跨 App 操作）还远未达到”完全体”，离豆包手机那种深度代理操作仍有差距，但这已经足够让人期待未来了。
至于国行用户？别急，再等等吧。
2026-05-10 22:02:00
时间进入到 2026 年 5 月，软件工程领域已经全面引入 Coding Agent，目前一线生产力用得最多的是 Claude Code、Codex、OpenCode。我之前也介绍过我自己现在在本地编程的场景是通过 VS Code 使用 Claude Code 和 Codex。
我到底用了多少 token？花了多少钱？(虽然基本都是Coding Plan，但如果按原价看，会感觉赚了)
我还经常想知道「某个项目到底吃了多少 token」。但三个 Agent 各自存数据，散落在硬盘的不同角落。写个脚本统计？能用，但太折腾了。每次想看数据都得重新跑。
TokenScope 是一个 macOS 原生应用。SwiftUI 写的，零外部依赖。
核心思路就一句话：把常用的 Coding Agent 的用量数据拉到一起，统一展示。
它目前支持三个数据源：Claude Code、Codex、OpenCode。原理也不复杂——这些工具在本地都会留下 session 日志，TokenScope 直接读这些日志，解析 token 用量，然后汇总。
不需要 API key，装上就能用。基本功能也不需要联网。
打开 App 第一个看到的就是 Dashboard。
最上面是几个关键数字：总会话数、总 token 数、输入 token、输出 token、费用估算（美元）。
下面按来源拆开。Claude Code 用了多少，Codex 用了多少，OpenCode 用了多少。点一下就能筛选。
再往下是柱状图。按天展示 token 消耗，不同颜色代表不同模型。鼠标悬停能看到每天的详细拆解：用了哪些模型，每个模型花了多少钱。
还可以按月展开，看到每个月的总 token、费用、消息数。点开就是每一天的数据。
筛选器很灵活。按日期、来源、模型、token 类型，想怎么看就怎么看。
我每次打开 App 第一件事就是看这个柱状图。哪天用得多，哪天用得少，一眼就能看出来。
这是我自己用得最多的功能。
Claude Code、Codex、Z.ai 三个来源的配额和使用量，实时展示。进度条直接告诉你还剩多少。重置倒计时也有。
以前用着用着突然到 limit，或者就是隔一会儿去刷一下各家的 Usage 页面看看剩余额度。现在随时在 TokenScope 看一眼进度条就心里有数了。
还有费用统计。今天花了多少，最近 30 天花了多少。
如果你有多个 Codex 账号——比如工作账号和个人账号分开——TokenScope 支持多账号切换。OAuth 登录，直接在 App 里搞定。
所有 Coding Agent 的会话都在一个列表里。按时间、来源、项目、消息数、token 数、费用，想怎么排就怎么排。
搜索也方便。想找某个项目的会话，搜项目名就行。
双击一个会话，能看到完整的对话记录。每条消息的 token 拆解都在：输入多少、输出多少、缓存读取多少、缓存创建多少、消耗多少费用。
能看到哪些对话特别费 token。有时候一个复杂任务，Agent 反复尝试，token 就蹭蹭涨。看到具体数字之后，我会更有意识地控制对话长度和 prompt 质量。
我在 TokenScope 内置了 20 多个模型的定价数据。Anthropic 全系、OpenAI 全系、GLM 全系都有。
所以每个视图都带费用估算。从 Dashboard 到会话详情，token 数旁边永远跟着一个美元数字。
觉得内置价格不准？可以自己覆盖，改成你使用的 API 的实际价格。
数据存在本地。第一次打开会扫描所有日志文件，之后有缓存，秒开。后台自动刷新新数据。
API key 存在 macOS Keychain 里。这点我很在意，密码类的东西不应该明文存在配置文件里。
纯 Swift 实现，零外部依赖。最低支持 macOS 14。
下载地址：https://github.com/aooyoo/TokenScope/releases
目前仅支持 M 芯片的 Mac 电脑
这个项目还在持续开发中。感兴趣的话，或者有什么功能建议，欢迎告诉我。
2026-04-28 20:56:00
本文首发于公众号：未来科技
DeepSeek 团队近期发布的 DeepSeek-V4 系列（包括 1.6T 参数的 Pro 版与 284B 参数的 Flash 版）将开源大模型的能力边界推向了百万 token 上下文时代。这份技术报告中最值得深入探讨的，一是其在模型架构层面对长上下文效率瓶颈的系统性突破，二是其在后训练阶段为 Coding Agent 场景所做的针对性优化。本文围绕这两条主线展开。
DeepSeek-V4 在保留 DeepSeek-V3 的 MoE 框架与 MTP（Multi-Token Prediction）的基础上，引入了三项关键的架构升级：混合注意力机制（CSA + HCA）、流形约束超连接（mHC）以及 Muon 优化器。这三者共同构成了 V4 系列在效率与稳定性上的护城河。
长上下文场景下，注意力机制的二次复杂度是绕不开的瓶颈。V4 没有选择单一路线，而是设计了两种压缩注意力机制并以交错方式部署。
Compressed Sparse Attention（CSA） 走的是”先压缩、再稀疏”的路线。它首先用一个 token 级压缩器将每 个 token 的 KV 缓存合并为一条 entry（V4 中 ），随后通过一个轻量级的 Lightning Indexer 计算压缩 KV 块与 query 的相关性分数，并通过 top-k 选择器（Pro 版选 1024 条）保留最相关的压缩块进行核心注意力计算。值得注意的是，CSA 使用的是 Multi-Query Attention 形式，且 query 的 latent 向量在 indexer 与主注意力之间共享，进一步压缩了计算量。此外，由于 query 的输出维度 较大，V4 还引入了 grouped output projection——先将 个头分成 组，每组先投影到中间维度 ，再合并为最终输出，避免了出口投影成为新的瓶颈。
Heavily Compressed Attention（HCA） 则走极致压缩路线，将每 个 token 合并为一条 entry，但放弃稀疏选择，对所有压缩后的 entry 执行 dense attention。由于压缩比足够大，dense 形式的开销也已被摊薄。
CSA 与 HCA 在 Transformer 层之间交错部署：CSA 保留了局部精细度但有 top-k 上限，HCA 提供了全局视野但分辨率较粗，两者形成互补。再叠加几个工程细节——RoPE 仅作用于最后 64 维并对核心注意力输出施加 位置的逆向 RoPE 以恢复相对位置关系；额外的滑动窗口分支（）补偿压缩带来的局部信息损失；可学习的 attention sink logit 允许查询头将总注意力分数压低至接近 0。
效率收益是惊人的。在 1M token 上下文下，V4-Pro 的单 token 推理 FLOPs 仅为 V3.2 的 27%、KV 缓存仅为 10%；V4-Flash 更进一步降至 10% 与 7%。配合 RoPE 维度用 BF16、其余维度用 FP8 的混合存储格式，以及 Lightning Indexer 内部的 FP4 计算，V4 的 KV 缓存在 1M 场景下被压到了 BF16 GQA8 基线的约 2%。
残差连接是 Transformer 信号传递的”高速公路”。Hyper-Connections（HC）通过将残差流的宽度从 扩展到 （V4 中 ）提供了一个独立于 hidden size 的扩展轴，但实测中堆叠多层 HC 会出现数值不稳定。
V4 提出的 mHC 的核心思想是将残差变换矩阵 约束在双随机矩阵流形（Birkhoff polytope）上，即满足行和列之和均为 1 且元素非负。这一约束保证了 ，使残差变换是非扩张的（non-expansive），前向与反向传播的数值稳定性都得到加强；同时双随机矩阵集合在乘法下封闭，深层堆叠依然稳定。具体实现上，未约束的原始矩阵 先经过指数变换确保正性，然后用 Sinkhorn-Knopp 算法做 20 次行列交替归一化收敛到流形上；输入与输出映射 、 则用 Sigmoid 限制非负有界。
这种约束同时解决了 HC 的稳定性问题，又保留了它独立于 hidden size 提供额外容量的优势。
V4 在大部分模块上将 AdamW 替换为 Muon——这是 Muon 第一次被用在万亿参数 MoE 模型的全规模训练上。Muon 的关键步骤是对动量矩阵做近似正交化（通过 Newton-Schulz 迭代），其更新方向接近 的形式，相当于把奇异值都拉到 1 附近。V4 采用了两阶段混合 Newton-Schulz 迭代：前 8 步用激进系数 快速逼近，后 2 步用稳健系数 精确收敛到 1。AdamW 仅保留给 embedding、prediction head、RMSNorm 权重以及 mHC 的静态偏置和门控因子。
Muon 与 ZeRO 的兼容性是工程难点——ZeRO 假设元素级优化器允许参数矩阵切片更新，而 Muon 需要完整梯度矩阵做正交化。V4 的解法是 dense 参数用背包算法做矩阵级分桶分配，MoE 参数则按专家粒度展平、跨 rank 均匀分配；MoE 梯度同步还用了随机舍入到 BF16 + 两阶段 all-to-all + 本地 FP32 求和的方案，把通信量减半的同时维持了数值稳健性。
万亿参数 MoE 训练的不稳定性几乎是普遍现象。V4 报告了两个有效但理论尚未完全清晰的技巧：
V4 的后训练流水线整体采用”专家培养 → 统一蒸馏”两阶段范式：先针对数学、代码、agent、指令跟随等不同领域分别训练专家模型（SFT + GRPO 强化学习），再通过多教师 On-Policy Distillation（OPD）将能力合并到统一模型中。这一节聚焦其中与 Coding Agent 直接相关的优化。
V4 同时提供 Non-think、Think High、Think Max 三种推理模式，每种模式在 RL 训练时使用不同的长度惩罚和上下文窗口，使得同一模型可以根据任务难度选择”思考预算”。对于 coding agent 这种本质上需要长链路推理与多步工具调用的场景，Think Max 模式额外注入一段系统提示，明确要求模型穷尽推理、压力测试逻辑、显式记录所有中间步骤与被否定的假设。从评测结果看，Terminal Bench 2.0 上从 None 模式的 59.1 提升到 Max 模式的 67.9，说明这种推理预算的弹性对 agent 任务有显著收益。
V4 用一套基于 <|DSML|> 特殊 token 的 XML 风格调用格式替代了传统的 JSON 调用约定。文中明确指出，XML 格式可以有效缓解转义失败、减少工具调用错误——这在长链路 coding agent 中尤其关键，因为单一调用错误会让整条轨迹失败。
更重要的是 Interleaved Thinking 的管理策略升级。V3.2 在每个新用户回合到来时会丢弃之前所有的思考链，每次都要从头重建上下文。V4 利用百万 token 上下文窗口，在 Tool-Calling 场景下完整保留所有回合（包括跨用户消息的）思考内容，让模型在长 horizon 的 agentic 任务中维持累积的、连贯的推理脉络；只在不涉及工具的纯对话场景沿用旧的丢弃策略。对 coding agent 来说，这意味着模型在调试一个长达数十个步骤的修复流程时，不必每次重新理解项目结构与已尝试的方案。
OPD 的目标是让学生模型 在自己生成的轨迹上学习多个教师专家（包括 coding 专家）的输出分布，目标函数是加权反向 KL：
以往工作通常将这个 KL 退化为 token 级估计并塞进 RL 框架，但这会带来高方差和训练不稳定。V4 坚持全词表 logit 蒸馏——保留完整 logit 分布做反向 KL，梯度估计更稳，教师知识保留更忠实。
这背后的工程支撑相当扎实：超过十个万亿级教师模型的权重被 offload 到分布式存储按需 ZeRO 式加载；为避免 词表的 logit 物化爆显存，V4 只缓存教师最后一层 hidden state 到中央 buffer，训练时按需通过 prediction head 重建 logits；训练样本按教师索引排序，保证每个 mini-batch 至多一个 prediction head 驻留 GPU。最终 KL 散度由专门的 TileLang kernel 计算。
对 coding agent 而言，这意味着代码专家通过强化学习获得的细粒度能力（错误处理、API 调用习惯、重构判断）能够以接近无损的形式融合进统一模型，而不是被 token 级近似稀释掉。
Coding agent 的训练 rollout 经常涉及 50 万 token 以上的长轨迹，且单次 rollout 可能需要数百次工具调用。V4 在基础设施上做了几项关键优化：
FP4 量化集成到 rollout：rollout 与所有 inference-only 前向（包括教师与参考模型）直接使用原生 FP4 权重，而训练步骤用 FP4→FP8 无损反量化模拟，复用现有 FP8 mixed-precision 框架。这显著降低了 rollout 阶段的显存占用与采样延迟。
Token 粒度 Write-Ahead Log 容错：每生成一个 token 立即追加到该请求的 WAL。被抢占时暂停推理引擎、保存 KV 缓存；恢复时基于持久化的 WAL 与 KV 缓存继续解码；即使硬件错误也能通过 WAL 重建 KV 缓存继续。从头重生成会引入长度偏差（短响应更容易在中断中存活，导致模型偏向短输出），WAL 机制从数学上保证了正确性。
DSec 沙箱平台：为 coding agent 的执行环境提供了四种执行底座（Function Call、Container、microVM、fullVM）的统一接口。Container 用 EROFS 按需加载基础镜像，microVM 用 overlaybd 实现快照链，单集群可管理数十万并发沙箱实例。轨迹日志支持抢占恢复时的客户端快进——已完成的命令直接重放缓存结果，避免非幂等操作的重复执行（这在涉及文件系统、网络请求的 coding agent 中至关重要）。
V4-Pro 在 Codeforces 上拿到 3206 Elo（人类排名约第 23 位），LiveCodeBench Pass@1 达 93.5，是首个在编程竞赛上对标 GPT-5.4 的开源模型。SWE Verified 80.6、SWE Multilingual 76.2、Terminal Bench 2.0 67.9（其 Verified 子集约 72.0），与 K2.6、GLM-5.1 处于同一梯队。
但更值得关注的是 DeepSeek 团队自建的 R&D Coding Benchmark——从 50+ 内部工程师收集 200 个真实任务，覆盖 PyTorch、CUDA、Rust、C++ 跨技术栈的功能开发、bug 修复、重构、诊断，经过质量筛选保留 30 个评测任务。在这个更接近真实工程的基准上：
| 模型 | Pass Rate |
|---|---|
| Haiku 4.5 | 13% |
| Sonnet 4.5 | 47% |
| DeepSeek-V4-Pro-Max | 67% |
| Opus 4.5 | 70% |
| Opus 4.5 Thinking | 73% |
| Opus 4.6 Thinking | 80% |
V4-Pro 显著超越 Sonnet 4.5、接近 Opus 4.5。在对 85 名 DeepSeek 内部研究员与工程师的调研中，52% 表示 V4-Pro 已可作为日常默认编码模型，39% 倾向于是，反对者不到 9%。被反复提及的不足是偶发的低级错误、对模糊指令的误解与过度思考——这恰好指向后续迭代的方向。
DeepSeek-V4 的架构创新可以概括为用结构化压缩换取长上下文效率，用流形约束换取深层稳定性，用矩阵级优化换取收敛速度。CSA + HCA 的混合注意力是当前开源社区在百万 token 上下文方向最系统的工程化方案；mHC 用 Birkhoff polytope 这一漂亮的数学工具解决了 Hyper-Connections 的实战痛点；Muon 在万亿参数规模的成功部署也为后续模型提供了重要参考。
后训练侧，V4 并没有押注单一的 RL 算法奇迹，而是用专家培养 + 全词表 OPD 的两阶段范式，配合 XML 工具调用、跨回合思维保留、token 级 WAL、DSec 沙箱等组合拳，把 Coding Agent 这一长链路、强工程依赖的能力做扎实。R&D 内部基准 67% 通过率与开发者 91% 的正向反馈，比任何公开 benchmark 都更能说明问题。
对从业者而言，V4 给出的最大启示或许是：长上下文与 agent 能力不是独立追求的两件事——只有当注意力效率足够高、推理状态能够持续保留、训练基础设施能容忍长 rollout 与频繁抢占时，agentic AI 才真正具备规模化训练的可能。V4 把这条路径完整地走通了一次。
