2026年7月20日 · 来源 aihot.virxact.com · 时间窗:过去 48 小时(24h 内 coding/agent 条目不足,放宽至 48h 补齐)
01

Grok 4.5 登顶 VulcanBench 编程基准:91.3% 得分,5 种语言 23 个真实任务解决 21 个

X:cb_doge (@cb_doge) / Elon Musk (@elonmusk) · 7月20日 03:10 CST

Grok 4.5 在 VulcanBench 新编程基准中得分 91.3%,解决了横跨五种语言的 23 个真实世界软件任务中的 21 个,击败 Claude Fable 5 和 GPT-5.6 Sol,同时占据成本效率前沿。Elon Musk 随后转发推荐用户试用 Grok 4.5。

为什么值得关注
VulcanBench 和 SWE-bench 路线不同——它用五种语言的真实软件任务而非单一 Python 仓库,直接测多语言工程能力。Grok 4.5 在这个维度同时压过 Fable 5 和 GPT-5.6 Sol,加上"成本效率前沿"的标注,意味着它不只是跑分高,单位 token 产出也占优。做 coding agent 选型时,Grok 4.5 从"可选项"变成了需要正面评估的模型。xAI 前一天刚把 Grok 4.5 设为 Grok Build 默认模型,基准成绩和产品落地几乎同步。
https://x.com/cb_doge/status/2078920456682488189 https://x.com/elonmusk/status/2078987522927972695
02

Anthropic 将 Claude Code system prompt 削减 80%:12.8MB 占满 95% 上下文,瘦身后反而更优

X:Thariq (@trq212) / 阿易 AI Notes (@AYi_AInotes) · 7月20日 01:55 CST

Anthropic 团队成员 Thariq 透露,Claude Code 的 system prompt 被削减了 80%。他的解释是:模型越聪明,需要的指令、约束和示例就越少;移除示例反而能让模型更自由发挥。一个极端案例——某用户的 CLAUDE.md 从 12.8MB 占满 95% 上下文窗口,瘦身至 2.1MB 仅占 18% 后,模型专注度与结果均优于此前。Thariq 建议在新模型发布时主动修剪上下文,为最新模型留出更多运行空间。

为什么值得关注
这直接冲击了 harness engineering 的一个默认假设——"prompt 越详细越好"。当模型能力提升到一定水平,过量的示例和约束反而挤占了有效上下文,变成负优化。12.8MB 的 CLAUDE.md 占满 95% 上下文窗口意味着 agent 几乎没有空间处理用户实际任务。瘦身到 18% 后效果更好,说明"少即是多"在强模型上不是审美偏好而是工程事实。对写 CLAUDE.md / 系统提示词的团队,这是一个该立即执行的信号:审计你的 prompt 占了多少上下文,砍掉那些模型已经"默认会做"的指令。
https://x.com/trq212/status/2078901672441790818 https://x.com/AYi_AInotes/status/2078918305973219567
03

Kimi K3 需求远超预期,月之暗面暂停 C 端新订阅,将拆分 Kimi Code Membership 编程会员

IT之家 / X:Testing Catalog (@testingcatalog) · 7月19日 23:08 CST

Kimi K3(2.8T 参数,100 万 Token 上下文)发布后请求量远超预期,GPU 算力逼近极限。月之暗面宣布即日起暂停 C 端新用户订阅,全部算力用于服务已有用户。K3 输入费用为每 100 万 Token 2 元(缓存命中)或 20 元(缓存未命中),输出费用 100 元。

同时,月之暗面计划将会员拆分为两个独立计划:面向 Web/App/Work 的 Kimi Membership,以及面向编程工作流的 Kimi Code Membership——用独立计费通道将编程场景的算力需求与其他场景隔离。

为什么值得关注
拆分 Kimi Code Membership 是一个信号:coding agent 场景的算力消耗模式跟通用对话完全不同——长上下文、多轮工具调用、高并发,混在一个计费池里会互相挤兑。把编程工作流独立出来做会员,本质上是把算力分配问题从"全局限流"变成"按场景隔离"。对使用 Kimi K3 做 coding agent 的开发者,这意味着 coding 通道的资源保障会更稳定,不再和通用聊天用户抢同一池 GPU。更宏观地看,当一家模型公司因为 coding 需求太大而暂停订阅,说明 coding agent 不再是边缘场景——它正在成为前端模型算力消耗的最大变量。

https://www.ithome.com/0/978/808.htm https://x.com/testingcatalog/status/2078934957435797713
04

Anthropic 内部对谈:模型外层的 Harness 正在变薄——从写死的流水线到会挑战术的教练

X:小互 (@xiaohu) · 7月19日 11:34 CST

Anthropic 内部对谈指出,套在模型外层的代码(harness)正在变薄。原因很直接:harness 编码了大量"模型做不到什么"的假设,而这些假设正随模型能力提升而快速过期。旧 harness 像一条写死的流水线——每一步都硬编码了模型的能力边界;新架构更像一个会挑战术的教练,不站在流水线上,而是根据当前局面决定用哪种阵型打。

为什么值得关注
这是来自模型公司内部的 harness engineering 方向判断,不是外部观察者的推测。如果 harness 确实在变薄,那么大量针对当前模型能力短板写的 workaround 代码(格式修复、工具调用纠错、中间结果校验)在未来模型迭代后会变成技术债甚至干扰项。"教练"而非"流水线"的比喻指向一个具体的设计转变:harness 的重心从"控制模型每一步怎么做"转向"决定什么场景用什么策略"。对做 agent 架构的团队,这意味着应该把更多精力花在策略选择和评估机制上,而非堆砌硬编码的纠错逻辑。

https://x.com/xiaohu/status/2078684808067293238
05

宝玉:FDE 是模型公司的阳谋——先帮企业落地 Agent 卖 Token,再把沉淀的 Skills 内化进模型

X:宝玉 (@dotey) · 7月19日 23:47 CST

宝玉分析了 FDE(Field Delivery Engineer,现场交付工程师)在 AI 模型公司中的角色本质。FDE 的工作链条是:帮企业落地 Agent → 消耗 Token → 把企业知识沉淀成 Skills → 将 Skills 内化到模型。每个项目应该为下一个项目打工——沟通记录、方案、修改原因都沉淀为结构化资料,最终形成 Agent 知识库和评估标准。飞轮一旦转起来,公司核心资产不再是明星员工,而是一套不断复利的交付系统。

为什么值得关注
这个分析揭示了一个容易被忽视的商业飞轮:模型公司做 FDE 不只是"卖服务",而是在用交付过程反向收割企业 know-how。你请模型公司帮忙搭 Agent,你的业务逻辑、决策规则、SOP 最终会变成模型能力的一部分——然后模型公司把增强后的模型卖给你的竞争对手。对有自建 agent 能力的企业,这是一个该认真权衡的 trade-off:用模型公司的 FDE 换短期落地速度,还是忍受更长 ramp-up 时间把 Skills 留在自己手里。Skills 沉淀的方向也给出了 skill engineering 的具体抓手:不是写 prompt,而是把"为什么这么改"这类隐性决策结构化。

https://x.com/dotey/status/2078869237796352062
06

Kimi K3 上线 2 天成 OpenRouter 第 10 大模型:日处理 140B token,吞吐量已从 30 降至 13 tok/s

X:Deedy Das (@deedydas) · 7月20日 00:06 CST

Moonshot 的 Kimi K3 上线 2 天即成为 OpenRouter 第 10 大模型,日处理约 140B token。但负载已导致吞吐量从 30 tok/s 降至 13 tok/s,端到端延迟达 72 秒。Deedy Das 估算,服务量化版 K3 需至少 8 块 B300(约 $50 万),推荐 GB300 NVL72 机架则需约 $400 万。他指出前沿模型价格 3 年仅降 4-5 倍,而需求增长超 3 个数量级——算力锁定者将获得巨大价值。

为什么值得关注
这组数字把"开源模型火爆"翻译成了具体的基础设施账单。140B token/天、吞吐量腰斩、72 秒延迟——这是 coding agent 场景下开源大模型的实际负载画像,不是跑分。8 块 B300 ($50 万) 是自托管 K3 的硬件门槛,对想做私有化 coding agent 的中小团队,这个数字直接决定了可行性。更关键的判断是"价格降 4-5 倍但需求涨 3 个数量级"——意味着 token 单价还会降,但总算力支出会持续上升,握有算力的人比握有模型的人更可能赢。
https://x.com/deedydas/status/2078874115910615544
07

OpenAI 将 Codex 上下文窗口从 37.2 万 token 缩减至 27.2 万,同步更新推理摘要与权限元数据

Hacker News 热门 / GitHub PR #33972 · 7月19日 22:49 CST

OpenAI 通过 GitHub PR #33972 将 Codex 模型的上下文窗口从 37.2 万 token 缩减至 27.2 万 token。变更通过 backport 将刷新后的 GPT-5.6 模型指令和上下文窗口元数据同步至 0.144 稳定版客户端。更新还涉及推理摘要、技能、权限和自动审查目录元数据。GPT-5.6 Sol 不包含超快服务层级。

为什么值得关注
上下文窗口缩减 27% 不是小事——对 coding agent 来说,可用的上下文直接决定能处理的代码仓库规模。从 37.2 万到 27.2 万意味着能塞进单次对话的代码行数少了约四分之一。结合 Anthropic 同期在削减 Claude Code system prompt 占比(见第 2 条),两家头部模型公司都在做同一件事:在模型能力提升的前提下,压缩非用户内容、腾出空间给实际任务。如果你的 Codex workflow 依赖大上下文处理整个仓库,这次缩减可能需要调整分块策略。PR 同步更新了推理摘要和权限元数据,说明这不是简单的数值调整,而是配合模型指令刷新的系统性变更。

https://github.com/openai/codex/pull/33972/files
08

Feyn AI 发布 SQRL 文本转 SQL 模型族:查询前先探查数据库 schema,BIRD Dev 70.6% 超越 Claude Opus 4.6

MarkTechPost · 7月20日 06:20 CST

Feyn Labs 发布 SQRL(Text-to-SQL)模型族,核心设计是在生成查询前先用只读探针检查数据库 schema。旗舰版 SQRL-35B-A3B 在 BIRD Dev 基准上达到 70.6% 执行准确率,超越 Claude Opus 4.6。该模型还蒸馏出可自托管的 4B 和 9B 检查点。

为什么值得关注
"查询前先探查数据库"不是 prompt 技巧,而是把 schema 发现做成了模型架构层面的硬步骤——通用大模型生成 SQL 时最大的失败原因就是猜错列名和关系,SQRL 用只读探针在生成前消除这个不确定性。70.6% 执行准确率超越 Claude Opus 4.6 说明在垂直任务上,专用小模型 + 结构化预处理可以超过通用大模型。4B/9B 可自托管检查点对有数据隐私约束的团队是实打实的——数据库 schema 通常包含敏感业务逻辑,走 API 传给第三方模型有合规风险,自托管消除了这个障碍。

https://www.marktechpost.com/2026/07/19/feyn-ai-releases-sqrl-a-text-to-sql-model-family-that-inspects-the-database-before-writing-a-query
09

Codex 重度用户内存优化指南:关闭 XcodeBuildMCP 等 MCP 进程,常态占用从 5.7GB 降至 3.4GB

X:Berry Xia (@berryxia) · 7月19日 23:29 CST

Codex 重度用户日常内存占用约 6GB,常因后台残留 MCP 进程飙高至卡死。官方建议:完全退出重启 Codex,默认关闭高占用的 XcodeBuildMCP(0.84 GB)和 Blender MCP(0.3 GB),保留低占用常用 MCP,同时 active 任务控制在 1-2 个。优化后常态内存可从约 5.7 GB 降至 3.4-4.0 GB。

为什么值得关注
MCP 进程残留是 coding agent 工具链中一个被低估的问题。XcodeBuildMCP 单独吃 0.84 GB,Blender MCP 吃 0.3 GB——这些不是模型推理开销,是工具连接器的内存泄漏/常驻。当 agent 同时挂多个 MCP server 时,内存占用会线性叠加,最终挤占掉系统给模型推理的预算。这个优化指南给出的具体数字(每个 MCP 吃多少 MB)可以作为排查模板:用活动监控器逐个关 MCP 对比内存差值,找到你的工具链里的内存大户。active 任务控制在 1-2 个的建议也值得注意——并发 agent 任务不只是抢 GPU,也在抢客户端内存。

https://x.com/berryxia/status/2078864817574879467
10

Grok Build 0.2.105:Grok 4.5 成为默认模型,新增 /summarize 命令与 Shell 环境变量继承,CLI 重大更新预告

X:Elon Musk (@elonmusk) / Andrew Milich (@milichab) · 7月19日 12:05 CST

xAI 发布 Grok Build 0.2.105 更新:Grok 4.5 成为默认模型,支持高、中、低三档推理努力度。新增 /summarize 命令用于即时会话摘要。本地 Shell 工具现在继承用户的环境变量、别名和函数——这意味着 agent 可以直接使用你 .zshrc / .bashrc 里定义的 alias 和 PATH。此外改进了长会话压缩、全局规则发现以及负载下的滚动流畅度。

同期,xAI 工程师 Andrew Milich 预告下周将发布 Grok CLI 重大更新。

为什么值得关注
Shell 继承用户环境变量这个改动看着小,实际解决了 coding agent 的一个高频痛点:agent 执行 shell 命令时找不到用户已安装的工具(nvm、pyenv、自定义 alias),导致"在我终端能跑但 agent 说不存在"。继承 .zshrc 的 PATH 和 alias 后,agent 的 shell 环境终于和开发者的实际环境对齐了。/summarize 命令和长会话压缩改进指向同一个问题——长 coding session 的上下文管理。三档推理努力度让开发者在简单查询上省 token、在复杂调试上加火力。Grok CLI 重大更新预告则说明 xAI 在终端 coding agent 赛道上还在加速,和 Claude Code、Codex 的竞争会进一步白热化。

https://x.com/elonmusk/status/2078692662345888102 https://x.com/milichab/status/2078543365101216077