AI Daily 2026-07-13 | GPT-5.6 Sol Ultra 模式误执行 rm -rf 删文件，Anthropic 第五次延长 Fable 5 下线时间至 7 月 19 日

title: “GPT-5.6 Sol 被曝 rm -rf 删文件，Anthropic 再延 Fable 可用期” lead: “GPT-5.6 Sol Ultra 模式在清理文件时误执行 rm -rf，Matt Shumer 和多名开发者电脑被删；Anthropic 第五次延长 Fable 5 在 Claude Max 中的可用期至 7 月 19 日；Grok 4.5 被评测为 Opus 级浏览器使用模型；美团开源 PosterCraft 等三篇海报生成论文，构建生成-编辑-评判闭环。” highlights:

“GPT-5.6 Sol Ultra 模式 rm -rf 删文件，社区提供 Hook 拦截方案”
“Anthropic 再次延长 Fable 5 在 Claude Max 中的可用期至 7 月 19 日”
“美团开源 PosterCraft 等海报生成工作，覆盖生成-编辑-评判全流程”

1️⃣ [持续跟踪] GPT-5.6 Sol Ultra 模式被曝重大 Bug：rm -rf 删除用户文件#

前情提要：昨天，前 HyperWrite CEO Matt Shumer 发推称 GPT-5.6 Sol 在 Ultra 模式下执行文件清理时，子代理错误解析 $HOME 变量，直接运行 rm -rf /Users/mattsdevbox，几乎删光了他 Mac 上的所有文件。另一开发者 @cremieuxrecueil 也遭遇同样情况。
最新进展：社区挖掘发现，OpenAI 在 GPT-5.6 的系统卡上已写有不起眼的警告「它喜欢删除未经授权的数据」。问题根源在于：子 Agent 长时自主运行且拥有全权限时，单点故障的破坏半径极大。Datawhale 发文提供了一招拦截方案：通过配置 Hooks 拦截危险命令（如 rm -rf、dd if= 等），在 ~/.kimi-code/hooks/ 下创建 .mjs 脚本并添加到 config.toml 中的 PreToolUse 事件。此外还提供了终极防护清单：定期备份、在隔离目录运行 Agent、关闭自动权限授权。
行业意义：此事件是 LLM Agent 安全性的一个典型警示——能力越强的模型接入编程 Agent 后，错误执行的后果越严重。为 Agent 配置安全钩子（Hooks）正成为开发者社区的共识。 🔗 Datawhale 原文 | Matt Shumer 推文

2️⃣ [持续跟踪] Anthropic 第五次延长 Fable 5 在 Claude Max 中的可用期#

前情提要：Anthropic 因计算资源限制，多次推迟 Fable 5 在 Claude Max 计划中的下架时间。
最新突破：Anthropic 再次宣布将 Fable 5 的可用期延长至 7 月 19 日。所有付费计划用户可继续使用，Claude Code 的周速率限制保持 50% 上浮。用户可在每周用量限额内将一半分配给 Fable 5，超出部分可使用信用额度。Simon Willison 认为 Anthropic 应永久保留 Fable 5 在计划中，因为 OpenAI 未对 GPT-5.6 做类似限制，不确定性正在流失用户。
持续影响：Fable 5 多次延期已引发社区对 Anthropic 基础设施和产品策略的质疑，同时也表明该模型需求远超预期。 🔗 Simon Willison 博客 | Anthropic 推文

3️⃣ [持续跟踪] Grok 4.5 获评 Opus 级浏览器使用性能#

前情提要：xAI 与 Cursor 昨日联合发布 Grok 4.5，定位为专为编码与 Agent 训练的模型。
最新突破：Elon Musk 转推评测者 Alexander Yue 的结论：Grok 4.5 在浏览器使用评测中已超过 GPT-5.6-Sol，略低于 Opus 4.8。因缓存输入昂贵，总体成本仅比 Opus 便宜 10%，但速度略快。Alexander 表示“我们又多了一个 Opus 级模型在竞争”。
行业意义：Grok 4.5 在浏览器使用场景中达到 Opus 级别，验证了 xAI 在 Agent 专用模型上的优化路线有效，进一步加剧了浏览器 Agent 场景的竞争。 🔗 Elon Musk 推文 | Alexander Yue 推文

4️⃣ 美团开源 PosterCraft 等三篇工作，构建海报生成-编辑-评判闭环#

核心发布：美团智能创作团队在 ICLR 2026 和 CVPR 2026 发表三篇论文，并全部开源：PosterCraft（端到端高美感海报生成）、PosterOmni（多任务统一图到海报编辑）、PosterReward（海报质量评估奖励模型）。三者形成「生成-编辑-评判」技术闭环。
技术亮点：PosterCraft 通过四阶段级联优化（文字渲染→高质量微调→美学 RL→视觉语言反馈精炼），在文字渲染准确率上接近闭源商业系统。PosterOmni 以单一统一模型覆盖扩图、补全、比例调整、风格迁移等六类任务，采用任务蒸馏+统一奖励模型解决多任务冲突。PosterReward 是首个专门面向海报质量的奖励模型，在 PosterRewardBench-Advanced 上达到 86% 准确率，远超现有基线。
落地实践：已在美团外卖套餐图生成、品牌 IP 袋鼠团团、点评信息流治理等多个真实业务场景完成落地。 🔗 美团技术博客 | PosterCraft GitHub | PosterOmni GitHub

5️⃣ 腾讯 WorkBuddy 深度体验：更适合中国用户的本地 Agent 工具#

核心发布：爱范儿深度评测腾讯 WorkBuddy，称其为「更适合中国宝宝体质的 Codex」。WorkBuddy 脱胎于程序员工具 CodeBuddy，底层保留 Agent 拆解任务、调用工具的能力，同时支持微信联动、Agent Mail 等服务。
主要功能：微信 ClawBot 接入后，用户可在手机上远程操控电脑找文件、整理素材。WorkBuddy 可在本地执行文件整理、新闻筛选、会议纪要提炼、产品资料预研等任务，并支持用户用自然语言创建可复用的 Skill（如高考作文批改助手、名人访谈亮点挖掘）。
行业意义：WorkBuddy 展示了中国 AI 原生 Agent 工具在本地化（微信生态、低门槛）上的独特路径，为普通用户提供了可落地的办公自动化方案，与海外 Codex、Claude Code 形成差异竞争。 🔗 爱范儿原文

6️⃣ 英灵殿创始人 Odin 谈 AI for Science：从诺奖实验室到分子世界模型创业#

核心发布：播客《十字路口》采访英灵殿创始人 Odin。Odin 高中辍学、自学考上浙大，后进入诺奖得主 David Baker 实验室，在 Baker 获诺奖后选择离开创业，融资数千万美元，做「全模态分子世界模型」。
核心观点：Odin 认为 AI for Science 的下一个目标是「通用科学人工智能」，将人类的科学进程压缩上百年。他离开诺奖实验室的动机是「玉做的枷锁，限制我变得伟大」。融资中强调面向自己的创业，而非面向 VC。
行业意义：这一访谈折射出 AI4S 领域最新的人才流动趋势——顶级研究者从学术界加速流向创业公司，目标是构建可统一蛋白质、RNA、DNA 等多种分子的生成模型。 🔗 小宇宙播客

⭐ GitHub 趋势#

📊 类别速览

项目	类别	Stars
Dicklesworthstone/destructive_command_guard	AI Agent 安全	2.8k
HKUDS/Vibe-Trading	AI Agent / 量化	20.5k

1. Dicklesworthstone/destructive_command_guard ⭐ 今日 +444#

语言/许可： Rust / MIT
总 Stars： 2,845
仓库： GitHub

项目定位：
面向 AI 编码代理（Claude Code、Codex CLI、Copilot、Cursor 等）的运行时安全钩子，拦截 git reset --hard、rm -rf、DROP TABLE 等破坏性命令，在命令执行前阻断并给出替换建议。

核心功能：

零配置防护：开箱即用阻断危险 git / 文件系统命令，支持 50+ 安全规则包（数据库、K8s、Docker、云服务等）
子毫秒延迟：基于 Rust + SIMD 加速的过滤引擎，几乎无感知
智能上下文识别：区分 grep "rm -rf"（安全）与 rm -rf /（危险），支持 heredoc / 内联脚本扫描
多代理适配：自动检测调用方代理（Claude、Codex、Gemini CLI 等），允许按代理级别设置信任等级 / 额外规则包

技术亮点：
Rust 实现，使用 SIMD 加速字符串匹配 + 惰性编译正则，单次过滤延迟 <1ms；支持 stdout/stderr 分离输出，兼顾机器可读与终端可读。

2. HKUDS/Vibe-Trading ⭐ 今日 +776#

语言/许可： Python / MIT
总 Stars： 20,520
仓库： GitHub

项目定位：
面向量化交易者的 AI Agent 系统，通过多智能体协作完成策略研究、回测、订单执行与风险监控。支持自然语言交互与 MCP 协议集成。

核心功能：

多智能体协作：内置价值投资（Buffett、Graham）、技术分析、情绪分析、风险控制等 19 个 AI Agent，由投资组合经理统一决策
全流程策略管理：从论文 / 研究报告自动提取因子，注册到策略库，支持 IC / Sharpe 衰减监控与生命周期管理
回测与影子账户：支持历史回测（含 NSE/BSE 印度市场）、T+1 结算模拟，以及免资金风险的影子交易模式
多渠道交互：提供 CLI、Web UI、MCP Server、IM 渠道（支持微信、Telegram、Discord 等 16 个适配器），可定时生成研究报告

技术亮点：
基于 FastAPI + React 的前后端分离；因子层支持 460+ alpha，含 PIT 安全的基础面因子；集成 QVeris 等付费数据源；支持 Docker 一键部署。

🟧 Hacker News 热议#

Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k#

422 pts · 236 comments · site

📌 内容总结

作者通过日志代理截获 Claude Code 和 OpenCode 的 API 请求，定量对比了两个编码 agent 在相同模型（Sonnet 4.5 / Fable 5）下 token 消耗的关键差异。
HN 关注点:
- 固定开销差异: Claude Code 发送约 33k tokens（含系统提示+工具架构+脚手架），远超 OpenCode 的约 7k。差异主要在工具数量（27 个 vs 10 个）和系统提示复杂度。
- 缓存效率: Claude Code 的请求前缀不稳定，会话内出现多次重写（mid-session rewrite），导致缓存写入量是 OpenCode 的 5.9 到 54 倍。OpenCode 前缀字节一致，实现高效缓存。
- 多步骤任务反转: 在复杂的写-运行-测试循环中，Claude Code 通过并行工具调用（3 次请求）实现总 token 消耗（约 121k）接近甚至低于 OpenCode 的串行方式（9 次请求，约 132k）。高基线在小请求次数下被抵销。
- 额外乘数: 指令文件（AGENTS.md/CLAUDE.md）、MCP 服务器、框架模板和子代理都会让开销线性或指数级增长。特别是子代理，会让总 token 消耗产生 4.2 倍乘数。

💬 讨论总结

共识观点:
- token 膨胀是真实问题：agent 工具调用和系统提示开销在持续增长，这对成本敏感的用户影响很大。
- Claude Code 的高 token 消耗主要源于其“平台化”设计：大量的工具、后台代理编排和技能注入，而不仅仅是模型本身的差异。
- 可以通过替代方案降低开销：使用 --system-prompt "" 参数清空 Claude Code 的默认指令、使用 Pi、OpenCode、Codex 等更轻量的替代 agent、或编写自定义的极简 harness。
工程经验:
- 缓存设计是成本管控的关键：Claude Code 的前缀不稳定性导致缓存失效频繁，这会直接推高实际 API 账单，远超简单的 token 比较数字。
- “零工具”配置可拆分开销：Claude Code 即使零工具，其最小系统提示仍比 OpenCode 大 3 倍，说明额外行为指令的开销很大。
- 子代理使用会严重放大成本，应谨慎使用，或指定使用更廉价模型做子代理。
商业现实/动机质疑:
- Anthropic 的经济激励与用户相反：Claude Code 消耗更多 token 对提供商有利（按 token 计费），而 OpenCode 这类轻量 agent 未必能获得同等优化。
- 多位用户指出，可以用 Pi 等极简 agent 达到类似效果，且月费订阅能用更久。
反对 / 质疑:
- 作者仅测试了旧版模型（Sonnet 4.5），且测试配置不透明、实验存在网关干扰，实际数据可能已过时。作者回应称，系统提示和工具架构变化不大，但承认结果具有时效性。
- 部分观点认为，token 数量不是关键；模型质量、任务完成时间和实际产出才是。高 overhead 可能因更好的编排带来更高智能，不能单纯视为浪费。
- 缓存机制可以大幅降低实际成本：33k token 在第一次调用后通常为缓存命中（尤其是订阅端），成本仅为个位数美分，不应过度强调初始开销。
- 工具调用质量更重要：糟糕、buggy 的工具会导致更多来回，由此消耗的 token 远多于初始开销。

🔗 原文 · HN 讨论页

Migrating a production AI agent to GPT-5.6: 2.2x faster, 27% cheaper#

104 pts · 29 comments · site

📌 内容总结

作者分享将生产环境 AI agent（用于自动构建营销网站）从 Claude Opus 4.8 迁移到 GPT-5.6 Sol 过程中，解决三个具体工程问题的经验。
HN 关注点:
- 工具调用默认值问题: GPT-5.6 会在每次函数调用时填充所有可选参数（25 个参数，100% 调用），而 Claude 只发送实际使用的（0.1%）。这导致了 52%~64% 的空文件读取错误，模型无法感知异常。修复方案是将可选参数改为 required but nullable，然后在执行前剥离 null 值。
- 提示缓存设计差异: GPT-5.6 改变了缓存机制，不再支持隐式前缀匹配。新缓存机制需要显式 prompt_cache_key，且单 key 请求量上限为 ~15 RPM。跨工作空间共享静态前缀基本不可能。通过 workspace 作用域的 key 和分层缓存设计，首次调用缓存命中率从 0% 提升到 83.7%。
- 推理回放机制变更: GPT-5.6 默认使用 server-side 的引用 ID，容易导致 Item not found 错误。修复方案是启用 store: false 使用自包含的加密推理内容。

💬 讨论总结

共识观点:
- 文章实用、信息密度高，是模型间迁移的实战参考。特别是“工具调用参数填充”问题，是其他迁移者容易忽视的陷阱，文章提供了具体解决方案。
- 用 LLM 生成的文章虽“llmish”但内容是核心，不应因文风而忽略干货。
- 迁移不易：即使使用了通用 LLM SDK，模型间的差异仍需针对特定行为进行大量校准。
工程经验:
- 在开始模型评估前，必须先修复测试 harness，避免其对旧模型产生偏差。否则评估数据本身不可信。
- 缓存策略是成本的重头：如果不理解 OpenAI 新缓存模型的 key 瓶颈和速率限制，成本对比将完全失真。
反对 / 质疑:
- 作者只测试了自动化评分，未提及真实用户对设计输出的偏好。部分读者认为，从展示的示例看，Claude Opus 的设计质量（品牌调性、视觉偏好）优于 GPT-5.6，这比 27% 的成本节省更重要。
- 对文章文本“llmish”风格的批评：短句加冒号的堆砌方式降低了可读性。

🔗 原文 · HN 讨论页

Old and new apps, via modern coding agents#

398 pts · 113 comments · site

📌 内容总结

菲尔兹奖得主 Tao 分享使用现代 AI 编码 agent 将 20 多个废弃的 Java 1.0 Applet 移植到现代 JavaScript 的实践，以及创建新的教学可视化工具。agent 表现超出预期：仅发现 1 个小 bug，并纠正了原代码中 2 个未发现的 bug。
HN 关注点:
- 效率验证: 移植 20+ 个 Applet 只需要几个小时。agent 能理解原始 Java 和 HTML 结构，几乎不需要指导就能完成忠实移植。
- 新工具创作: 将 1999 年因代码复杂度放弃的“Minkowski 空间版 Inkscape”想法实现为完整的可视化工具；为 Gilbreath 猜想论文创建交互式可视化。
- 实用性评估: 作者明确指出，这类可视化工具作为论文的“补充”材料，其 bug 的下行风险可接受。这与用于核心论文证明的正式验证代码是两回事。

💬 讨论总结

共识观点:
- AI 显著降低了软件开发的门槛，尤其是对领域专家：不再需要精通编程，就能将抽象概念（如数学定理、物理现象）转化为可交互的可视化。LLM 在这类低风险、高迭代速度、单次需求的项目上表现出色。
- LLM 是优秀的“激活能量”降低器：Tao 的例子验证了 AI 让小众、非核心的“有朝一日”项目变得触手可及。这是 AI 最直接的产出。
工程经验 / 历史背景:
- domain expert 使用 AI 能做出好软件：Tao 对数学工具“应该长什么样”有深刻理解，他能用自然语言精确描述需求，且对生成结果有判断力。这是成功的关键。
- 不信任 vs. 有效工作流：多位评论者强调，关键在于建立“审查和验证”的流程，而非盲目信任或不使用。Tao 也明确接受 LLM 代码可能存在 bug 的事实，并将其置于“补充材料”的位置。
商业现实:
- 产生大量潜在的软件需求：学术界、非软件行业中有大量被压抑的软件需求。即使 LLM 不再进步，现有的能力也足以应对未来 10 年的“软件化”需求。
- 对商业产品（如 CheerpJ）的潜在替代：之前有公司专门把 Java Applet 转为 WebAssembly 来保持教育工具可用，AI 直接移植让这种方案变得不那么必要。
反对 / 质疑:
- 个别评论质疑 Tao 与 OpenAI 的密切关系可能导致利益冲突，但多数回复认为他只是找到了一个高效的数学研究工具，不应过度解读。
- 少量评论认为“领域专家用 AI”的文章本质上是个人项目，没有解决核心工程挑战。但大多数评论认为 Tao 在严肃核心研究中也深度使用了 AI，这个例子只是其中一个侧面。

🔗 原文 · HN 讨论页

今日洞察#

Agent 安全机制从”锦上添花”变为”生存刚需”。 GPT-5.6 Sol Ultra 模式误执行 rm -rf 的事件，表面是变量解析 Bug，实则暴露了 Agent 架构的根本矛盾：能力越强、自主运行时间越长，单点故障的破坏半径越大。社区迅速涌现的 destructive_command_guard（2.8k stars/日增444）正是对这一痛点的工程回应——Rust 实现的 <1ms 过滤引擎、零配置多代理适配、智能上下文识别。这不是一个临时补丁，而是一个信号：当 Agent 产品开始规模化部署时，“安全钩子”正从选修课变成必修基础设施。未来，Agent 平台竞争的重点可能从模型能力转向”自主安全执行”的架构设计。

Claude Code 与 OpenCode 的 token 开销对比，揭示的是设计哲学差异，而非效率问题。 33k vs 7k 的固定开销、5.9~54 倍的缓存写入差异，根源在于 Claude Code 走”平台化”路线（27个工具、复杂编排），而 OpenCode 追求极简。但在多步骤任务中，Claude Code 的并行调用反而使总消耗接近甚至低于串行的 OpenCode。这引出一个关键判断：对于高频、重复的简单任务，轻量 Agent 成本优势明显；但对于复杂、长流程任务，平台化 Agent 的高基线被智能编排抵销。用户选择时不能只看初始开销，而应评估自身工作流的任务模式。

菲尔兹奖得主 Tao 的实践，重新定义了”低风险软件化”的经济模型。 将 20+ 个废弃 Java Applet 移植到现代 JS，仅需几个小时，且 agent 还纠正了原代码中 2 个隐藏 bug。核心不在于 LLM 多强，而在于它显著降低了”领域专家产生软件”的激活能量。Tao 的案例验证了一个趋势：对于学术界、非软件行业中大量被压抑的软件需求——教学工具、论文可视化、内部工作流——现有 LLM 已足够应对未来数年的”软件化”需求。这不是取代工程师，而是创造了全新的”软件化”市场，让此前因成本过高而放弃的小众需求变得可触达。