微博 AI 观察博客

原文

Cursor 发了一篇工程博客，讲他们怎么持续打磨 Agent 框架。干货很多，适合工程师细读。核心观点：决定 Agent 好不好用，模型只是一部分，框架（harness）同样关键。Cursor 的做法是：拿到新模型的 Early Access 之后，花几周时间专门围绕这个模型的特点调优框架，直到它明显变得更快、更聪明。几个值得记的工程细节：1. 上下文窗口的管理策略在变2024 年底刚做编程 Agent 时，Cursor加了很多护栏：lint 错误主动反馈、限制单轮工具调用次数、预先塞大量静态上下文（文件夹布局、语义相关代码片段）。现在这些大多撤掉了。转向：减少护栏，改成由 Agent 在工作中按需动态拉取上下文。模型变强了，不再需要过多手动辅助。2. 怎么判断框架改好了？两个关键指标1）Keep Rate（代码保留率）：Agent 改完代码之后，用户在固定时间内有多少比例没有动它。不动 = Agent 改得基本对，反复改 = Agent 没做好。2）用语言模型读用户的下一句话，语义判断用户是否满意——用户继续做下一个功能，是完成信号；用户粘贴了 stack trace，是失败信号。3. 工具调用错误的分类管理Cursor把工具调用错误分成两类：预期内错误（InvalidArguments、ProviderError、Timeout 等）和未知错误。未知错误一律当 bug 处理。预期错误按工具 × 模型分别建基线，一旦显著偏离基线就告警。今年上半年集中冲刺一次，把意外工具调用错误降低了一个数量级。4. 不同模型用不同框架配置OpenAI 模型习惯 patch 格式改文件，Anthropic 模型习惯字符串替换——两种都能用，但给错了就多费 token、多出错。所以他们按模型配置不同的工具格式。提示词也按厂商定制：OpenAI 模型偏字面理解，Claude 对模糊指令容忍度更高。还遇到一个有趣问题：某个模型上下文窗口快满时开始拒绝干活，说"这个任务太大了"——他们叫它"上下文焦虑"，后来通过调提示词缓解了。5. 对未来的判断：框架会比模型本身更重要Cursor 认为 AI 编程将走向多 Agent 模式：规划、快速编辑、调试，分别由不同的专业 Agent 负责。怎么调度哪个 Agent、怎么描述任务、怎么整合结果——这些协同编排能力体现在框架里，不在单个 Agent 里。框架工程一直是关键，以后只会更关键。🔗 原文：cursor.com/cn/blog/continually-improving-agent-harness#how i ai# #程序员#

转发者评论

无明显转发评论

原文

Google 为自家开源模型 Gemma 4 发布了 MTP drafter（多 token 预测草稿模型），推理速度最高提升 3 倍，输出质量保持不变。网页链接 Gemma 4 是 Google 几周前发布的开源模型系列，从手机端的 E2B、E4B 一直到工作站的 26B MoE 和 31B Dense，官方称上线几周下载量已经突破 6000 万。MTP drafter 用的是 speculative decoding（推测解码）：让一个轻量级的小模型先“猜”出接下来好几个 token，再让大模型一次性并行验证，验证通过的部分一口气全部输出。这套机制对本地跑模型的场景特别有用。LLM 推理之所以慢，瓶颈往往不在算力，而在内存带宽，处理器大部分时间都在把几十亿参数从显存搬到计算单元，只为了挤出下一个 token。推测解码把闲置算力利用起来，让小模型一次预测多个 token，大模型只做验证，等于把流水线拉满。实际效果上，在 Apple Silicon 跑 26B MoE 模型，批量大小开到 4 到 8 时本地能拿到约 2.2 倍提速。因为最终验证仍由大模型完成，输出和原版逐字一致，没有质量取舍。drafter 沿用 Gemma 4 的 Apache 2.0 协议，权重已经上传到 Hugging Face 和 Kaggle，transformers、MLX、vLLM、SGLang、Ollama 都已支持。官方公告： 网页链接/Drafter 详细解释：网页链接 宝玉xp的微博视频

转发者评论

无明显转发评论

原文

OpenAI 把 ChatGPT 的默认模型升级成了 GPT-5.5 Instant，从今天开始替换原来的 GPT-5.3 Instant，全量推送给所有用户。Instant 是 ChatGPT 里反应最快的日常档，几亿人每天都在用，这次升级针对的也是日常问答场景。【1】幻觉显著减少OpenAI 内部测试的数据：在医疗、法律、金融这类答错代价很高的高风险问题上，GPT-5.5 Instant 编造事实的概率比上一代少 52.5%。在用户实际标记过"这答错了"的对话上，错误率降 37.3%。跑分跟着上来：博士级科学题 GPQA 从 78.5% 升到 85.6%，AIME 2025 数学竞赛从 65.4% 跳到 81.2%，多模态推理 MMMU-Pro 从 69.2% 提到 76%。【2】回答更短，废话更少以前 ChatGPT 经常被吐槽答得太啰嗦，问个简单问题能给你回三屏。新版明显收敛，不必要的反问、过度排版和表情符号都少了。【3】主动用你的过去聊天记录如果你连了 Gmail、上传过文件、之前和它聊过别的事，新版会更主动地把这些内容拿来用。比如问"推荐一家新茶饮店"，它会参考你之前说过常去哪、偏好哪种风格，给出更贴你的答案，而不是泛泛列几家热门店。OpenAI 同时上线了一个叫"记忆来源"（memory sources）的功能，每条用到记忆的回答都可以点开看具体引用了什么，不想被引用的内容随时删掉。【4】发布节奏今天起向所有 ChatGPT 用户推送，免费档也能用。API 里的别名是 chat-latest。付费用户想保留旧版的，GPT-5.3 Instant 在模型设置里还会留三个月。个性化记忆功能先上 Plus 和 Pro 的网页端，移动端随后跟进，Free、Go、Business、Enterprise 之后再逐步开放。官方公告：网页链接 宝玉xp的微博视频

转发者评论

无明显转发评论

• 终于不话痨了，以前的版本实在太喜欢说了 [允悲]

原文

#AI创造营# Addy Osmani 是 Google 的工程师，目前担任 Google Cloud AI director。 他刚写了一篇博客《Agent Skills》来提醒开发者：AI 编码智能体虽然能快速生成代码，但默认会跳过高级工程师重视的“隐形工作”，比如写规格、拆任务、先测试、做评审、控制改动范围、留下验证证据。本文中Addy Osmani 试图把多年在 Google 级工程体系中沉淀出的工程纪律，迁移到 AI agent 时代，让模型不只是更快地产出代码，而是在规格、测试、评审、验证和发布约束下产出更可信的软件。文章配套有开源项目 addyosmani/agent-skills ，把里面这些高级工程实践封装成了 skills 。 下面是全文翻译，makedown排版，适合web端阅读，原文在：addyosmani.com/blog/agent-skills/# Agent Skills**2026 年 5 月 3 日**高级工程师的工作，大多是那些不会出现在 diff 里的部分：规格说明、测试、评审、范围控制、拒绝发布无法验证的东西。AI 编码智能体默认会跳过这些部分。**Agent Skills** 是我试图让这些环节不再变成“可选项”的尝试。任何 AI 编码智能体的默认行为，都是走向“完成”的最短路径。你要求它做一个功能，它就写这个功能。它不会问你是否有规格说明，不会在实现前先写测试，不会考虑这个改动是否跨越了信任边界，也不会检查这个 PR 在评审者眼中会是什么样子。它产出代码，宣布胜利，然后继续往前。这正是每个高级工程师在职业生涯中都在学习避免的失败模式。任何任务的高级版本，都包含那些不会出现在 diff 里的工作：揭示假设、撰写规格、把工作拆成可评审的小块、选择朴素可靠的设计、留下结果正确的证据、控制改动大小，让人类真的能够评审它。这些步骤，正是能在规模化场景下交付可靠软件的工程师，与那些提交会破坏系统的代码的人之间的主要区别。智能体跳过这些步骤，原因和初级工程师一样：这些步骤是不可见的。奖励信号指向的是“任务完成”，而不是“任务完成，并且设计文档也存在”。所以我们必须把高级工程师的脚手架重新加回去。**Agent Skills** 就是我对这种脚手架的尝试。它刚刚超过了 2.6 万颗星，所以显然不只我一个人想要这个东西。这篇文章讲的是 README 没有完全覆盖的部分：为什么每个设计选择存在，它如何映射到标准 SDLC 和 Google 公开的工程实践，以及即使你永远不安装任何一个 skill，也应该从这个项目里借鉴什么。---## “Skill”到底是什么在 Claude Code / Anthropic 的语境里，“skill”这个词承载了很多含义，所以有必要说精确一点。一个 skill 是一个带 frontmatter 的…

转发者评论

无明显转发评论

原文

用 Claude Code 的人应该都有这个痛点：每次开新会话，之前聊过的背景、做过的决策全都丢了，得重新交代一遍。Obsidian 里倒是存了几百条笔记，但它们就静静躺在那里，跟 Claude Code 之间完全是两个世界。最近在 GitHub 上发现了一个项目叫 obsidian-second-brain，思路很有意思。它把你的 Obsidian 仓库变成 Claude Code 的一个 Skill，让笔记库变成一个会自我重写的 AI 第二大脑。这个项目的灵感来自 Karpathy 的 LLM Wiki，但做得更深。新内容进来之后不是简单地追加到末尾，而是直接改写已有笔记，把新旧信息融合在一起。如果发现笔记之间有矛盾，它会自动调和；如果发现跨笔记的隐藏规律，它会整理成新的页面。功能上提供了 31 个斜杠命令，覆盖面很广：保存对话、摄入资料、写日报、做周复盘、可视化整个仓库结构，还能调用 X、Perplexity、YouTube 这些外部源拉取资料并自动归档。我觉得最有意思的是它的 4 个定时 Agent。你可以设置它们在夜里自动跑一轮：关闭今日任务，调和笔记间的矛盾，综合提炼规律，修复孤立笔记，重建索引。第二天早上醒来，整个仓库已经被悄悄整理过一遍了。它还支持四种预设角色：executive、builder、creator、researcher，每种角色会生成对应的目录结构和看板模板。基础命令装上就能用，涉及外部研究的命令需要自己配 API Key。如果你长期用 Claude Code，同时又重度依赖 Obsidian 做知识管理，这个项目值得试试。核心价值就一句话：让你的笔记从静态的档案变成动态的、持续生长的资产。传送门：网页链接#How I AI##科技先锋官#

转发者评论

无明显转发评论

原文

Claude Code 的创造者 Boris Cherny 最近在红杉的 AI Ascent 2026 上做了一场访谈，信息量很大，值得聊聊。最炸裂的一个事实是：Boris 整个2026年没有亲手写过一行代码。他现在每天从手机上提交几十个 PR，最夸张的一天提了150个。他的工作方式是同时跑五到十个 Claude Code 会话，背后挂着几百个 Agent，晚上睡觉的时候还有几千个在跑更深层的任务。对他来说，编程这件事已经被解决了。他特别推崇一个叫 Loop 的功能。原理很简单，就是让 Claude 用 cron 定时执行重复任务。他自己跑着几十个 Loop，有的在自动修 CI、有的在自动 rebase PR、有的每30分钟从 Twitter 上抓用户反馈然后聚类整理发给他。他觉得 Loop 就是未来，因为它让 Agent 从「你问一句它答一句」变成了持续运转的自动化系统。关于团队的未来，他的判断是：跨学科通才会越来越多。Claude Code 团队里每个人都写代码，包括产品经理、设计师、数据科学家、甚至财务。未来最有价值的人才是那种同时懂产品、设计和工程的人，因为 AI 把编码的门槛拉平了，真正稀缺的是对业务和用户的深度理解。他用了一个很有意思的类比：15世纪的印刷术。印刷术发明之前，欧洲只有10%的人识字。印刷术出现后50年里出版的书比之前一千年还多，书的价格降了100倍，几百年后全球识字率到了70%。他认为软件开发正在经历同样的事情，而且速度会快得多。以后写会计软件最好的人可能是一个优秀的会计师，因为领域知识才是真正的壁垒，写代码本身已经不是了。关于商业护城河，他引用了《七种权力》的框架。他认为 AI 会削弱两类护城河：转换成本（因为模型可以帮你迁移数据和系统）和流程优势（因为 4.7 模型可以自动爬坡优化任何流程）。但网络效应、规模经济、稀缺资源这些护城河依然坚固。他预测未来十年创业公司的数量会增长十倍，因为小团队现在能用 AI 做出跟大公司一样有价值的产品，而大公司要改流程、要内部推动变革，阻力比小团队大得多。最后一个很有意思的点：他说 Anthropic 的领先优势不在于用了更好的模型，他们内部用的和外部开放的是同一套东西。真正的领先在于他们把整个组织流程都围绕 AI 重新设计了。他们的 Agent 之间会通过 Slack 互相沟通协调，公司里已经没有任何手写的代码或 SQL。这种组织层面的变革，才是大多数公司还没追上的地方，也恰恰是创业公司天然的优势所在。#How I AI##科技先锋官#

转发者评论

无明显转发评论

原文

【电脑硬盘莫名缩水？Chrome 偷偷藏了个 4GB 大文件】快速阅读：Google Chrome 正在未经用户许可的情况下，向设备静默推送约 4GB 的 Gemini Nano 模型权重文件。这不仅引发了关于用户知情权与存储空间的隐私争议，更因其在全球数十亿设备规模下的带宽与能源消耗，带来了巨大的环境成本。你有没有发现，电脑的硬盘空间正以一种诡异的速度缩水？最近有个发现很有意思：Google Chrome 正在像个不请自来的房客，在没打任何招呼的情况下，往你的磁盘里塞进一个 4GB 的大块头——Gemini Nano 的模型权重文件。它藏在 `OptGuideOnDeviceModel` 文件夹里，名字叫 `weights.bin`。最让人无语的是，如果你尝试手动删掉它，Chrome 只要一运行，就会立刻重新下载。这种行为不像是在更新软件，倒更像是在进行某种“强制占领”。有网友提到，这就像是你买了一套家具，结果搬进家后发现，厂家不仅没问你就偷偷在客厅塞了一台巨大的、你根本不需要的工业级打印机，而且你还没法把它扔出去。这事儿不仅仅是占用了几 GB 空间的问题。如果把视角拉高到全球规模，这简直是一场生态灾难。有人算了一笔账：如果 Chrome 将这个 4GB 的模型推送到 10 亿台设备上，仅数据传输过程产生的碳排放，就可能高达 6 万吨二氧化碳当量。这不仅是带宽的浪费，更是对全球网络基础设施和能源的无端消耗。对于那些使用计费流量或带宽极其有限的用户来说，这 4GB 简直是“劫掠”。更有意思的矛盾点在于，Chrome 的界面上虽然显眼地挂着“AI Mode”的标签，但用户以为是在用本地模型保护隐私，实际上很多查询依然会被发往云端。这种“本地模型”更像是一个放在用户设备上的“预置资源”，让 Google 可以随时调用，而成本却由用户承担。这让我想起一个问题：当软件不再是工具，而变成了某种“自动扩张的生命体”时，我们对设备的控制权还剩下多少？thatprivacyguy.com/blog/chrome-silent-nano-install/

转发者评论

无明显转发评论

• [并不简单] 关键还费流量

原文

【Google 杀招 MTP 架构！Gemma 4 推理速度飙升 3 倍】快速阅读：Google 通过引入 MTP（多 Token 预测）架构，为 Gemma 4 系列配备了专门的“助手”模型，利用投机采样技术在不损失质量的前提下，将推理速度提升了最高 3 倍。现在的 LLM 推理本质上是在玩一场带宽与计算的博弈。大多数时候，处理器并不是在“思考”，而是在苦等数据从显存搬运到计算单元。这就像是在用拨号上网时代的速率，去跑一个需要实时交互的智能体。Google 的策略很有意思。他们没有一味追求参数规模的堆叠，而是把重心放在了计算效率上。Gemma 4 引入的 MTP 架构，逻辑很像 CPU 里的分支预测。它让一个极小的“助手”模型先去“猜”后面几个 Token，主模型再并行校验。如果猜对了，就像是一次性完成了多次指令流水线；如果猜错了，也就只是丢弃掉错误的预测，重新执行而已。有网友提到，这种做法让 Gemma 在某些任务上表现得极其轻快。比如在对比测试中，虽然 Qwen 在某些基准上略胜一筹，但 Gemma 仅用 4 分钟就完成了任务，而对手可能要跑 22 分钟。这种“性价比”在本地部署时尤为重要，它意味着你可以在消费级显卡上，获得接近生产力工具的响应速度。当然，这种策略也有代价。有观点认为，Google 似乎在通过这种方式，试图在有限的算力资源下，通过优化效率来对抗其他厂商的规模扩张。这更像是一种“降维打击”：当大家都在卷参数规模时，Google 在卷如何让模型跑得更省、更快。不过，这种“投机”策略在工具调用（Tool Calling）上偶尔也会显得有些笨拙。如何让这种高速的预测，在复杂的逻辑链路中保持稳定，依然是个悬而未决的问题。blog.google/innovation-and-ai/technology/developers-tools/multi-token-prediction-gemma-4/

转发者评论

无明显转发评论

原文

Google 刚刚发布了 Gemma 4系列模型的草稿专用模型! 31B Dense 搭配草稿模型速度竟然能提升3倍! 付出的代价仅仅是多花 1G 显存!另外 Gemma4-26B 也能提升1.5x 速度, Gemma4-E4B 更是能提升3.1x 速度. 我之前给大家做过 Gemma 4 推测性解码的教程, 当时官方还没有专用草稿模型, 所以我给大家演示的是 gemma-4-31B-it-UD-Q4_K_XL 作为主模型, 然后使用 gemma-4-E2B-it-UD-Q4_K_XL 作为草稿模型, 速度可以提升 1.23x, 草稿接受率在62% 左右.这次直接翻三倍原因很简单, 因为之前用的 gemma-4-E2B-it-UD-Q4_K_XL 即使已经是量化模型了, 大小也有3GB左右, 而这次的 gemma-4-31B-it-assistant 即使是原始精度也只有 939 MB! 而且是专门为了推测性解码优化的! 接受率也会高. 所以提速自然就明显了.而代价也仅仅是显存中再多加载这个模型就可以了(大概1GB显存开销).现在压力来到了 Qwen 这边, 建议 Qwen 赶紧推出 Qwen3.6-27B-assistant, 再不推出我的显卡可是要红温了, 我天天cue你们嗷!#HOW I AI##gemma4##qwen##gemma4assistant##推测性解码##投机解码#

转发者评论

无明显转发评论

原文

🌟 Gemma 4：Drafter 详解Google Gemma 团队刚发的文章，介绍了Gemma 4 为提升推理速度而引入的 drafter 草稿模型机制。该技术不再完全依赖大型目标模型一个 token 一个 token 地生成内容，而是让一个更小更快的草稿模型先提前预测多个 token，再由目标模型并行验证这些预测，从而显著减少推理时的计算开销。下面是文章翻译。原文在Google Gemma的推上。------------------------为了提升 Gemma 4 模型的推理速度，Gemma 4 主系列模型之外还发布了一组新的自回归 “drafter” 模型。这里的主模型被称为 “target model”，也就是目标模型；而 drafter 草稿模型可以在目标模型处理一个 token 的时间里，提前预测多个 token。这种技术也被称为推测解码，即 speculative decoding。在 drafter 预测出多个草稿 token 之后，目标模型只需要验证这些被建议的草稿 token。验证过程可以并行完成，因此能显著加快推理速度。它减少了目标模型为了生成每个 token 所需要执行的前向传播次数。由于 drafter 会生成一串 token 供目标模型验证，所以我们也把它称为 Multi-Token Prediction，MTP，多 token 预测头。Gemma 4 系列发布的草稿模型体积较小，并引入了若干增强设计，以提高草稿 token 的质量，并进一步加速推理。例如，它会利用目标模型的激活值和 KV cache 来获得更好的预测结果。这些增强带来了显著的解码加速，同时仍然能保证相近的生成质量。因此，这些 checkpoint 非常适合低延迟和端侧应用场景。[ 图1 ]这里面有很多内容需要拆解。下面我们依次讲解推测解码、MTP，以及 drafter 的设计。🌟 什么是推测解码？Gemma 4 模型以自回归方式生成文本，也就是一次生成一个 token。无论某个 token 是容易预测还是难以预测，每生成一个 token 大致都需要相同的计算量。因此，当某些 token 很容易预测时，这个过程就可能显得不必要地缓慢。假设一个较大的模型正在生成文本，并且已经生成了 “Actions speak”。熟悉英语谚语的人会知道，这句话常见的完整表达是 “Actions speak louder than words.”，意思是“事实胜于雄辩”。由于这句话非常常见，小模型很可能生成与大模型完全相同的后续内容，也就是 “louder than words”。在这种情况下，让大模型一个 token 一个 token 地预测 “louder than words” 就会浪费时间和计算资源。通过推测解码，我们可以使用一个更小的草稿模型提前预测多个 tok…

转发者评论

无明显转发评论