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

月之暗面开源 Kimi K3:2.8T MoE、104B 激活参数、1M 上下文,每单位算力智能提升 2.5 倍

X:Kimi.ai (@Kimi_Moonshot) / The Decoder:AI News / IT之家 · 7月27日

月之暗面正式开源 Kimi K3,2.8T 总参数、104B 激活参数的 MoE 架构,原生视觉理解,100 万 token 上下文窗口。新架构采用 Kimi Delta Attention(KDA)、NoPE、跨深度注意力残差和 896 专家 MoE 设计,官方称每单位算力的智能密度提升 2.5 倍,长上下文解码速度提升 6 倍。模型权重、技术报告及配套高性能注意力内核 FlashKDA、MoE 通信库已在 HuggingFace 和 GitHub 开源。

The Decoder 报道称,K3 在基准测试中接近 Fable 5 和 GPT-5.6 Sol 等西方前沿模型,但英国网络研究所的独立测试显示其网络能力和数学技能仍落后于前沿模型。Artificial Analysis Intelligence Index 上以 57 分成为领先的开源权重模型。许可证方面,年收入超 2000 万美元需商业授权。

为什么值得关注
2.8T 参数开源模型直接把开源模型的能力门槛抬到闭源旗舰水平——57 分的 Intelligence Index 意味着 K3 和 Fable 5(60 分)、GPT-5.6 Sol(59 分)的差距在个位数以内。104B 激活参数意味着推理时只需要激活 3.7% 的总参数,这是 MoE 架构的成本优势所在。KDA(Kimi Delta Attention)是新架构设计,不是简单堆 Transformer 层——69 层 KDA 线性注意力与 24 层 MLA 交错的混合架构说明月之暗面在注意力机制上做了原创设计。许可证的 2000 万美元收入门槛对绝大多数创业公司和个人开发者不构成障碍。对需要本地部署或微调的团队,K3 提供了一个不依赖 OpenAI/Anthropic 的开源前沿选项——但英国实验室的独立测试提醒你,基准分数和实际能力之间仍有差距,需要在自己的任务上实测。
https://x.com/Kimi_Moonshot/status/2081760186235289764 https://the-decoder.com/moonshot-ai-releases-kimi-k3-open-weights...
02

SGLang 和 Miles 为 Kimi K3 提供 Day 0 推理支持:单卡 113 tok/s,推测解码 423 tok/s

LMSYS:Blog(Chatbot Arena 团队) · 7月27日

SGLang 负责推理、Miles 负责 RL 训练,为 Kimi K3 提供发布当日支持。K3 采用 69 层 KDA(Kimi Delta Attention)线性注意力与 24 层 MLA 交错的混合架构,在 SGLang 上单卡 batch-1 解码速度约 113 tok/s。结合 DSpark 推测解码可达约 423 tok/s。

KDA 架构迫使推理栈重新设计状态缓存与推测解码逻辑——这不是在现有 Transformer 推理框架上改参数就能跑的,需要对注意力内核做定制化适配。

为什么值得关注
423 tok/s 的推测解码速度是落地部署的硬指标——这个速度意味着 K3 可以用于实时交互的 coding agent 场景,不需要等几秒才出第一个 token。KDA+MLA 混合架构对推理引擎的影响在于:SGLang 必须为 KDA 写专门的注意力内核和 KV cache 管理逻辑,FlashKDA 内核也随模型一起开源。如果你用 vLLM 或 TensorRT-LLM 而非 SGLang,需要等社区适配或自己写内核。Day 0 支持的意义是:模型发布当天就有可用的推理方案,不需要等几周才有部署路径——这缩短了从模型发布到生产可用的时间差。

https://www.lmsys.org/blog/2026-07-27-kimi-k3-day0-support
03

Kimi K3 开源 AgentENV:基于 Firecracker 微虚拟机的分布式智能体环境,快照恢复低于 50ms,MIT 许可

X:Kimi.ai (@Kimi_Moonshot) / MarkTechPost · 7月27日

月之暗面与 kvcache-ai 合作开源 AgentENV(AENV),一个用于大规模运行智能体环境的分布式系统。该系统为 Kimi K3 的智能体强化学习训练提供支持,基于 Firecracker 微虚拟机实现快速快照、恢复和分支功能——快照启动和恢复时间低于 50 毫秒,支持将运行中的沙箱分叉出最多 16 个独立子沙箱。代码采用 MIT 许可证,已在 GitHub 发布。

为什么值得关注
AgentENV 解决的是 agent 强化学习训练的基础设施问题:agent 在环境中执行动作后需要快照环境状态,用于回滚和分支探索。50ms 的快照恢复速度意味着可以在训练中高频地保存和恢复环境状态,不会成为训练瓶颈。16 个子沙箱的分叉能力让同一训练节点可以并行探索 16 条不同轨迹——这是 agent RL 训练中 tree search 的基础设施需求。Firecracker 微虚拟机(AWS 开源的轻量级 VM)的选择说明隔离性和启动速度的平衡点在微虚拟机而非容器——agent 可能执行任意 shell 命令,容器隔离不够。MIT 许可证意味着可以直接商用。对做 agent RL 训练或需要大规模并行 agent 环境的团队,这是一套可直接复用的开源基础设施。
https://x.com/Kimi_Moonshot/status/2081762978391843020 https://www.marktechpost.com/2026/07/27/kimi-ai-and-kvcache-ai-open-sources-agentenv
04

Kimi K3 Max 在 Agent Arena 排名第三,Frontend Code Arena 总榜第一,5/7 领域登顶

X:Rohan Paul (@rohanpaul_ai) · 7月27日

Kimi K3(Max)在 Agent Arena 中以 +9.75% 净提升分领跑所有开源模型,在全部 42 个模型中排名第三,仅次于 Claude Fable 5(High)和 GPT-5.6 Sol(xHigh)。在 Frontend Code Arena 中同样位列开源及总体第一,并在 7 个领域中的 5 个拿下榜首。另在 3D 物理碰撞模拟测试中,本地部署的 K3(8×B300)生成的 HTML 场景效果优于 GPT 5.6、Grok 4.5 和 GLM 5.2,三个场景全部胜出,本地运行成本为零。

为什么值得关注
Agent Arena 第三 + Frontend Code Arena 总榜第一——这两个基准直接对应 coding agent 的核心能力:agent 任务编排和前端代码生成。+9.75% 的净提升分意味着 K3 Max 在 agent 场景下不只是"可用",而是和闭源旗舰拉开了可测量的差距。8×B300 本地部署击败 GPT 5.6 的 3D 物理模拟测试更具体——模型需要独立创建包含几何、质量、碰撞和持续损伤的完整场景,这考验的不只是代码生成,还有物理建模和场景理解能力。零成本本地运行意味着对隐私敏感或预算有限的项目,K3 是一个不需要 API 费用就能跑的前沿选项。但 B300 不是消费级硬件——8 卡 B300 的硬件成本仍然不低,"零成本"指的是推理 API 费用为零而非硬件投入为零。
https://x.com/rohanpaul_ai/status/2081845487628599717 https://x.com/rohanpaul_ai/status/2081860853666869295
05

GitHub Copilot 发布"Harness"工作流:8 步法用单一工具完成原型→规划→实现→审查,提到 Matt Pocock 的 grill-me skill

GitHub Blog · 7月27日

GitHub Copilot 官方博客发布"Harness"工作流,核心论点是"The harness is all you need—mostly"——不需要追逐每个新 AI 工具,用 Copilot 一个工具就能跑通完整开发流程。8 步法:选工具(推荐从 Copilot CLI 入手)→ 开启 YOLO 模式(/allow-all,配合 Codespaces 沙箱)→ 原型(生成多个方案对比,用中型模型如 GPT 5.6 Terra,不中途切换模型以利用 prompt 缓存)→ 规划(/plan 命令,推荐安装 Matt Pocock 的 grill-me skill 让模型更激进地提问)→ Autopilot 实现(内置循环,自动用子 Agent 编排大小模型)→ 人工审查迭代 → Rubber Duck 审查(让不同模型家族交叉审查,如 Claude Sonnet 审查 GPT 输出)→ 提交或开新会话。

Rubber Duck 审查可以和 Autopilot 组合成循环:/autopilot rubber duck,直到双方模型都认为只剩边际改进空间。文章以构建日期选择器 Web Component 为贯穿案例。

为什么值得关注
GitHub 官方把这套工作流叫"Harness"——直接用了 harness engineering 的概念,说明这个词已经从社区讨论进入了主流工具厂商的官方叙事。几个具体细节值得拿走用:①一个功能周期内不切换模型以利用 prompt caching 省 token,这是实操层面的成本优化;②grill-me skill(Matt Pocock 出品)让模型在 plan 阶段更激进地提问,这和上周晨报里 MSCE 论文的"策略需要触发条件和边界"思路一致——都是让 agent 在动手前把边界情况挖透;③Rubber Duck 跨模型交叉审查是 codex-bridge(Claude Code 调 Codex 交叉审计)的轻量版,用 Copilot 内置功能就能实现,不需要额外工具。官方自己也承认"没人真正搞懂了 AI 的最佳实践",今天的魔法 prompt 明天可能就是反模式。
https://github.blog/ai-and-ml/github-copilot/the-harness-is-all-you-need-mostly
06

GitHub Copilot app 升级多 Agent 会话工作区:/create-canvas 预览 UI、Agent Merge 自动处理 PR 审查与合并冲突

GitHub Blog · 7月27日

GitHub Copilot app 将 AI 编码工具升级为多 Agent 会话工作区,支持同时管理多个任务线程而不丢失进度。每个会话可绑定项目上下文。通过 /create-canvas 命令在浏览器 Canvas 中预览 UI 并直接点选修改。Agent Merge 功能可自动处理 PR 审查反馈和合并冲突。

为什么值得关注
多会话并行解决的是 coding agent 的上下文切换问题——之前用 Claude Code 或 Copilot 时,开一个新任务意味着丢失当前上下文,现在可以在多个会话间切换而不丢进度。/create-canvas 的点选修改意味着 UI 迭代不再依赖文字描述("把按钮往左移一点"),可以直接在渲染结果上点选元素修改——这对前端开发的交互效率提升是结构性的。Agent Merge 自动处理 PR 审查反馈是把 agent 从"写代码"延伸到"处理 code review"——之前 agent 写完 PR 就停了,现在它可以继续处理 reviewer 的评论和合并冲突,真正覆盖到 PR 合并前的最后一步。
https://github.blog/ai-and-ml/github-copilot/github-copilot-app-for-beginners-getting-started
07

Claude Cowork 存在 VM 沙箱逃逸漏洞:攻击者可读写 Mac 任意文件,影响约 50 万 macOS 用户

IT之家 · 7月27日

Anthropic 的 Claude Cowork AI 智能体存在安全漏洞,攻击者可利用 Linux 内核漏洞从虚拟机沙箱逃逸,读写 Mac 任意位置文件并获取在线服务登录凭据。该漏洞影响约 50 万运行本地 Cowork 会话的 macOS 用户。Anthropic 未发布直接修复,后续版本默认在云端执行以绕过本地逃逸路径。

为什么值得关注
这是 agent 安全问题的具体化——不是理论上的提示注入风险,而是 VM 沙箱被实际逃逸的漏洞。Linux 内核漏洞 + VM 沙箱逃逸意味着 agent 的执行环境隔离不够:agent 在 VM 里执行 shell 命令时,攻击者可以利用内核漏洞突破 VM 边界访问宿主文件系统。50 万用户的规模说明这不是个例。Anthropic 的"修复"方式值得注意:不是修补 VM 沙箱,而是把执行默认放到云端——等于承认本地沙箱的隔离强度不够,用云端隔离替代。对在本地跑 agent 的团队(OpenWorker、OpenMinis 等),这个漏洞是警示:你的本地沙箱可能也有类似的逃逸路径。如果 agent 能执行任意 shell 命令,VM 沙箱的内核版本和安全配置就是你的安全边界。
https://www.ithome.com/0/982/277.htm
08

浪费 20 亿 Token 后开源 Leader.skill:帮 Agent 定义目标的技能,提出"目标七问"方法论

公众号:数字生命卡兹克 · 7月27日

作者因目标定义不清导致 Agent 沿错误方向狂奔一整天,浪费 20 亿 token 后开发了 Leader.skill 并开源。该 Skill 将人类模糊需求转化为 Agent 可独立执行数小时的目标任务书,核心是"目标七问"方法论:①目的(Why,为什么做)②完成态(Done,什么算完成,具体到靠岸就能判断)③证据(Proof,谁来验证、怎么算数)④反作弊(Anti,最偷懒的达标路径是什么,全堵死)⑤边界(Bounds,哪些路不许走、资源用完怎么办)⑥取舍(Trade,冲突时保哪个)⑦未知(Unknown,遇到空白区绕过还是硬闯)。

作者认为"Harness 比 Goal 本身更重要"——Goal 告诉 Agent 往哪走,Harness 告诉它哪些路不许走。灵感来自军事概念的"指挥官意图"(告诉部队"为什么打"和"打完战场该是什么样",让部队自己决定怎么打)和芒格的"我只想知道自己会死在哪里,这样我就永远不去那里"。推荐多模型组合:用 Fable 5 或 K3 做规划出目标任务书,交给 GPT-5.6 Sol 或 GLM-5.2 做长程执行。Skill 已开源。

为什么值得关注
20 亿 token 的代价给出了一个量化锚点:目标定义不清的代价不是"多聊几轮",而是 agent 在错误方向上自主跑一整天的 token 消耗。"目标七问"的价值在于它不是泛泛的"写好 prompt"建议,而是具体的检查清单——尤其第④问"反作弊"和第⑤问"边界"直击 agent 的核心失效模式:agent 永远会找到你没想到的捷径。"Harness 比 Goal 更重要"的判断和上周晨报中 Harness Handbook 论文(静态分析提升规划成功率 10-19pp)方向一致——都在说 agent 的约束层比目标层更关键。多模型组合的实操建议(Fable 5 规划 + GPT-5.6 Sol 执行)也值得参考:规划用强推理模型、执行用强编码模型,两个模型各发挥所长。Skill 开源意味着可以直接装到 Claude Code 或 Codex 里试。
https://mp.weixin.qq.com/s/AwOk3di8m6eVeIUjzNftgg https://github.com/KKKKhazix/khazix-skills/tree/main/leader
09

用 Claude + Python 构建技能驱动金融分析智能体:解析 SKILL.md 构建可搜索技能注册表,迭代工具调用循环

MarkTechPost · 7月27日

本教程基于 Anthropic 的 financial-services 仓库,用纯 Python 复现其技能驱动架构。核心步骤:解析 SKILL.md 文件构建可搜索技能注册表,创建可复用 SkillAgent,将金融分析剧本注入 Anthropic Messages API,支持迭代工具调用循环。通过 MCP Connectors 连接外部数据源,实现自动化交付物生成(报告、图表、数据表)。

为什么值得关注
这个教程的价值在于它把 Anthropic 的 Skills 机制从概念落到了可运行的 Python 代码。"解析 SKILL.md 构建技能注册表"——这和上周晨报中 Claude Skills 的调用机制(所有 skill 元信息预加载在上下文中,一次推理完成判断和调用)是同一套设计,但用纯 Python 实现意味着你可以脱离 Claude Code 独立搭建 skill-driven agent。迭代工具调用循环是 agent 的核心执行模式:模型调用工具→获取结果→基于结果继续推理→调用下一个工具,直到完成任务。金融分析场景的选择也说明 skill-driven 架构不限于编码——任何需要多步骤、多工具协作的专业工作都可以用这套模式。对想自建 agent harness 的团队,这个教程提供了一个从 SKILL.md 到工具调用的完整代码参考。
https://www.marktechpost.com/2026/07/27/designing-skill-driven-financial...
10

开源模型 + 租用 GPU 将 AI 月费从 120 万降至 10 万:Polsia 案例的 8.3 倍成本压缩

X:Kim (@kimmonismus) · 7月27日

Ben Cera 通过租用 GPU 并转向开源权重模型,将 Polsia 的月度 AI 账单从 120 万美元降至约 10 万美元。此前四个月使用前沿模型 API 期间,用户从 500 增长至 5000 付费用户;随后约两个月配置租用 GPU 后,6 月成本降至约 10 万。关键原因:大部分用户只需处理简单代码库的简单任务,不需要最昂贵的模型。

为什么值得关注
120 万到 10 万是 12 倍降幅,具体到月费就是每月省 110 万美元。这个案例的核心洞察不是"开源模型便宜"——大家都知道——而是"大部分用户只需要便宜模型的能力"。500 到 5000 付费用户的增长发生在用前沿模型 API 的阶段,说明前沿模型在产品冷启动时确实有能力优势(能处理复杂 case、用户体验好)。但用户规模上来后,长尾用户的需求分布决定了成本结构:如果 80% 的请求是简单任务,用 GPT-5.6 Sol 处理就是浪费。这个案例和 7/24 晨报中微软的"可替换性"原则、Cursor Router(成本降 60%)方向一致——都是在说:能力验证阶段用最强模型,规模化阶段用路由器或开源模型降成本。租用 GPU 的方案意味着你不需要买卡,按需租用即可——但需要自己管推理基础设施,运维成本要算进去。这个数字是否适用于你的场景,取决于你的任务分布中有多少比例是"简单任务"。
https://x.com/kimmonismus/status/2081791395077988655