Microsoft Research@MSFTResearch · 5月15日51

New tools, models, repos, and papers out of Microsoft Research are here. Use AI and agents? It's worth watching: • MagenticLite from MSR AI Frontiers • Agentic GitHub workflows • Verification‑first agents • Meaning‑matching fine‑tuning • AI transition + the economy

译微软研究院的新工具、模型、代码库和论文现已发布。 使用AI和智能体？值得关注： • MSR AI Frontiers的MagenticLite • 智能体化GitHub工作流 • 验证优先型智能体 • 意义匹配微调 • AI转型与经济发展

小互@xiaohu · 5月15日74

你敢把 Opus 和 GPT 接入到小龙虾里跑吗？ 反正我是不敢，跑不起... 但是不接入这些顶级模型，有些复杂任务，国产模型真的搞不定。 发现一个以前不知道的团队做的开源项目 @OpenSquilla 脑洞很大的用 Python 重写了一个【智能省钱+智能安全】小龙虾 更省钱还更安全... 用一个本地路由器，把简单任务丢给便宜模型，复杂任务才上 Opus 4.7 同一套测试跑下来分数和 OpenClaw 几乎一样（0.9251 vs 0.9255），但成本从 6 美元降到 6 毛8，差快十倍。 四层记忆：模仿人脑分四层存东西。手头正在干的、过去干过的、知识和规则、原始日志，分开放。还会「做梦」，定期把零碎记忆整理成系统知识 按需加技能：自带 16 个工具（写 PPT、查 GitHub、跑定时任务等等），用哪个加哪个，不一股脑全塞进去 三档沙箱：跑代码的时候关进小黑屋，分三个安全等级。要是连续被拦下来好几次，Agent 自己就停了，不让它继续乱搞 一个入口管所有：网页、命令行、Slack、飞书、钉钉、Discord、Telegram、QQ 全都连进同一套后端，行为一致 20 多家模型随便挑：OpenAI、Claude、Gemini、DeepSeek、Qwen、Kimi、智谱、火山，国内外主流的都接了，挂一个用另一个

译开源项目OpenSquilla通过智能路由架构，在保持与OpenClaw相近性能（0.9251分）的同时，将复杂AI任务处理成本从6美元大幅降至0.68美元。其核心是将简单任务分配给廉价模型，仅复杂任务调用Opus等顶级模型。系统具备四层记忆结构模拟人脑认知，支持按需加载16种工具，并设有三档代码沙箱安全防护。项目提供统一后端，支持网页、命令行及Slack、飞书等平台接入，兼容OpenAI、Claude、Gemini、DeepSeek等20余家主流模型。

Greg Brockman@gdb · 5月15日69

codex for finding local businesses who may need help building a website:

译开发者发布了一款开源的Codex技能，旨在将本地搜索转化为潜在客户线索。该工具能自动搜索附近的各类本地商户，并分析其是否拥有独立网站或仅依赖社交媒体页面，以此判断其建站需求。核心功能包括潜在客户挖掘、网站与纯社交媒体状态检查、线索评分、提取联系方式，并支持聊天或CSV格式输出。用户可通过一条命令快速安装使用。

Baidu Inc.@Baidu_Inc · 5月15日39

The rise of the agent era is bringing new questions into focus: how value should be measured, how agents and people evolve together, and what infrastructure is needed to support agents at scale. At Baidu Create 2026, Robin Li explored Daily Active Agents (DAA) as a new defining metric, "AI evolution theory" across agents, individuals, and organizations, and our full-stack infrastructure built for the agent era. Taken together, they offer a broader view of how this shift is beginning to unfold. Watch the recap ↓

译在Baidu Create 2026上，李彦宏阐述了智能体时代的关键议题。他提出了“日活跃智能体”（DAA）作为衡量价值的新核心指标，并探讨了“AI进化理论”，该理论涵盖智能体、个人与组织三个层面的协同演进。同时，百度展示了为大规模支持智能体而构建的全栈基础设施。这些观点共同勾勒出智能体时代发展初期的基本框架与方向。

Berryxia.AI@berryxia · 5月15日55

Google刚刚泄露了Gemini Spark的最新内部截图。 新模型同时支持Agent模式和Chat模式，重点放在了高级工具使用和Skills创建流程上。 我把截图仔细看完后，发现两个关键限制目前很明显： Skills只能通过复制粘贴MD文件的方式创建，没有直接导入选项。 目前也没有任何Browser或Computer Use的痕迹，也就是说还无法直接控制用户的电脑。 这波更新把Gemini的工具能力又往前推了一步，但也暴露了Google在落地Agent时的谨慎节奏。 以前大家觉得Google会在工具使用上直接一步到位，现在看起来他们选择先把核心流程打磨扎实，再逐步开放更激进的功能。`

译泄露的Gemini Spark内部截图显示，新模型整合了Agent与Chat模式，重点提升高级工具使用和Skills创建流程。然而，当前Skills仅支持复制粘贴MD文件创建，缺乏直接导入选项，且未见Browser或Computer Use功能。这表明Google在推进AI工具能力时采取了渐进策略，优先打磨核心流程，而非一步到位开放激进功能。

AYi@AYi_AInotes · 5月15日76

刚刚花三分钟装了飞书官方那个 CLI 工具， 跑了一句话，建群、建文档、发通知，一次性全做完了， 我盯着终端看了几秒钟， 才反应过来这玩意儿真的能让 AI 直接操作飞书。 装的过程没啥可说的， 一行 npx @larksuite/cli@latest install， 三分钟搞定， 我试的场景挺日常，让 AI 帮我处理这么一件事， 明天上午十点和算法团队拉个会， 建一个会前准备文档， 把上周遗留的几个 issue 写进去， 然后在群里 @ 所有人通知时间， 终端里它一步步在 print 自己要做什么， 建群、建文档、写入内容、发消息， 每一步都能用 --dry-run 先预览一遍再真的执行， 我作为人类全程能看清 AI 在干嘛， 这跟我之前接 MCP 那种 AI 在云里自己执行你看不到的体感，完全不是一个东西， 跑完我才回头去看 GitHub， 飞书这个 lark-cli 今天 star 数刚好破 1 万， 开源到现在 45 天， 平均每天 219 颗星， GitHub 的 star 跟微博点赞不一样， 每一颗都挂在一个真实开发者的账号上， 是国内办公套件里第一个、也是目前唯一一个破万星的开源项目， 但真正让我对这条新闻改观的， 是另一个被很多人划过去的数字， 国内三家办公套件都开了 CLI，飞书、钉钉、企业微信， 只有飞书的主干里有 10 位真实外部开发者的代码被合进来，包括一个河南科大的实习生和一个土耳其的电商工程师，另两家是 0 和 0， 星是路过给的， PR 是动手写的， 这两个指标的含金量差了一个量级。 Notion 和 Figma 走的是 MCP 路线， 飞书选了 CLI，跑过一遍以后我有点理解这个选择了， AI 在 CLI 里执行任务， 每一步是可见的、可预览的、可审查的， 这个对开发者来说不是 fancy， 是真正能放心交给 Agent 去做事的前提， 以后让 AI 帮我从拉会到归档跑完一个完整项目流， 可能真就是一句话的事啊。

译飞书开源命令行工具lark-cli在45天内获得超过1万GitHub star，成为国内首个破万星的办公套件开源项目。该工具允许AI通过命令行直接操作飞书，执行建群、建文档等任务，且每一步操作都可预览、可审查，与云端不可见的MCP模式形成对比。其主干代码已合并10位外部开发者的贡献，而同类产品钉钉和企业微信则为零。这种可见、可控的特性被视为开发者放心将任务交给AI Agent的前提，预示着一句话指令驱动完整项目流程成为可能。

Chubby♨️@kimmonismus · 5月15日45

"Locked use" for Codex incoming. Probably explains OpenAI's image yesterday. "Let Codex use your Mac while it's locked"

译Codex 的“锁定使用”即将到来。 可能解释了 OpenAI 昨天的图片。 “让 Codex 在你的 Mac 锁定时使用它”

meng shao@shao__meng · 5月15日30

最近跟几位朋友沟通中多次提及 Lovart，真的很好奇，Lovart 过去的一年发生了 tm 的什么？ 好像从那个横空出世的 Design Agent，变成了...

译最近跟几位朋友沟通中多次提及 Lovart，真的很好奇，Lovart 过去的一年发生了特么的什么？ 好像从那个横空出世的 Design Agent，变成了...

🚨 AI News | TestingCatalog@testingcatalog · 5月15日34

OpenAI is working on a dedicated setting for Codex to allow users to enable "Locked use." > Let Codex use your Mac while it's locked No more need to carry a half-open laptop around?

译OpenAI正在为Codex开发专用设置，允许用户启用“锁定使用”。 > 让Codex在Mac锁定时继续使用 无需再随身携带半开状态的笔记本电脑？

MiniMax (official)@MiniMax_AI · 5月15日42

Livestream with @zocomputer in Singapore! Check how we demo Zo with MiniMax models❤️‍🔥

译与@zocomputer在新加坡直播！看看我们如何用MiniMax模型演示Zo❤️‍🔥

🚨 AI News | TestingCatalog@testingcatalog · 5月15日66

GOOGLE 🔥: New Gemini Spark screenshots featuring advanced tool use and Skills creation flow. It seems like there won't be an option to import SKILL MD files besides copeing and pasting. There is also no evidence of Browser or Computer Use atm.

译GOOGLE 🔥：Gemini Spark新截图展示高级工具使用和技能创建流程。 目前看来除了复制粘贴外，似乎没有导入SKILL MD文件的选项。目前也没有浏览器或计算机使用功能的迹象。

向阳乔木@vista8 · 5月15日63

哪个模型最牛逼？arena榜都被刷烂了。 要看就看 Vercel的最新报告。 20万个项目，7个月十万亿个 token的消耗分析，有些结论有意思： 1. 按费用消耗 Anthropic 占 61% 居首，按 token 量排名 Google 占 38% 居首。 2. Claude Opus 贵但好用，用在重要任务。Gemini Flash 便宜量大。 3. B2B 只产生 29.7% 的 token 量，却占了 40.7% 的费用。 5. 场景越关键 Anthropic 份额越高，比如后台业务 Anthropic 占 87% ，近乎垄断，消费场景三家平分。 6. Agent 请求 6 个月翻近一倍，从 31.6% 涨到 58.9%，一次 Agent 请求消耗的 token 是普通聊天的 2.6 倍。 7. 大规模团队平均使用 35 个模型。 原文见评论

译Vercel基于十万亿token消耗的分析显示，Anthropic在费用上占61%居首，而Google以38%的token量领先。Claude Opus用于关键任务，Gemini Flash则以低成本大用量见长。B2B业务贡献40.7%的费用却仅产生29.7%的token。Agent请求占比激增至58.9%，其token消耗是普通聊天的2.6倍。

ginobefun@hongming731 · 5月15日64

http://x.com/i/article/2055195078931709952 # BestBlogs 周刊 | 第 95 期：Agent 工程化的全面落地 在线阅读：https://www.bestblogs.dev/newsletter/issue95 > 🎧 本期也有播客版本：时长 18:15 · 在线收听 ## 导语 最近这一周，我有一个特别明显的感受：AI 这件事在头部厂商和国内厂商眼里，讨论重点已经从模型能力，转向如何把 Agent 真正推向生产。本周没有任何顶级模型发布，但 Anthropic、OpenAI、阿里、腾讯、淘宝、Kimi 这一堆团队同时在做一件事，就是把 Agent 真正推向生产。Claude Code 和 Codex 一起走出 IDE 跑到整个计算机里、Computer Use 的工程化最佳实践、Windows 上从零做沙箱、Agent Skill 成为开放标准、还有国内三连发的 Multi-Agent Harness 实战。我整理这期内容的时候忍不住给本期起了一个名字，就叫 Agent 工程化的全面落地周。 本期 20 篇内容里有 13 篇直接跟 Agent 工程化相关，剩下 7 篇是行业人物对这件事的不同视角回响。 在开始正文之前，也想用一段说说 BestBlogs 自己的几个变化。我们的新版三步引导这周正式上线，从「先选兴趣」反转成「先选公共信源、再加你自己的 RSS、最后选兴趣方向」，每一步都立刻保存，完成引导直接送 7 天 Pro 试用。同时文章、播客、视频、推文四类详情页对所有人开放，访客不登录也能读全文。还有一件事是邀请功能正式重启，每邀请 1 位新朋友双方都能各得 7 天 Pro，单人累计上限 28 天。如果你是 5 月 9 号之前注册的老用户，5 月 15 日到 5 月 31 日还有一次性 14 天 Pro 限时赠送，到 bestblogs.dev/promo 一键领取就行。希望大家多体验，也欢迎把 BestBlogs 推荐给身边热爱阅读的朋友。 ## 一、Coding 工具走出编辑器：Anthropic 与 OpenAI 的同步答卷 第一条主线，也是这周最清晰的趋势：Coding 工具正在走出编辑器，走向整个计算机。 Anthropic 这周一口气发了三篇关于 Claude Code 的文章，三篇都是工程化实践，没有一篇是模型层的事。 第一篇讲 Claude Code 在大型代码库里到底是怎么用的。这里说的大型代码库，指的是百万行的 monorepo、十年遗留系统、几十个微服务跨仓，百行千行规模不在讨论范围内。Anthropic 的核心结论挺反直觉的，他们直接说，放弃 RAG 嵌入式索引，改走 Agentic Search 路线，让 Claude 像工程师一样用 grep 跨引用导航。原因是嵌入式索引在大团队里很容易滞后。你两周前重命名的一个函数，索引可能还在返回老名字。Agentic Search 不依赖索引，每次都从最新的代码状态出发。 不过 Anthropic 自己也明确承认：Agentic Search 也有边界。「如果你让它在十亿行代码库里寻找一个模糊模式的所有实例，你会在工作开始之前就撞上上下文窗口的上限」。代码库本身的可导航性才是 Claude Code 性能的天花板，所以 Anthropic 把「Harness 和模型一样重要」放在文章最关键的位置。这套 Harness 由五个扩展点组成： - CLAUDE.md：Claude 每次会话自动读取的上下文文件，根目录放整体架构，子目录放局部约定。因为每次都加载，CLAUDE.md 必须「窄而聚焦」，过于宽泛反而拖累性能 - Hooks：大多数团队把 hooks 当成「防止 Claude 干坏事」的脚本，但 Anthropic 强调它最有价值的用法是自我改进。一个 stop hook 可以在会话结束时回顾整段交互、自动提议 CLAUDE.md 更新；start hook 则可以根据开发者当前所在模块动态加载团队上下文 - Skills：通过渐进式加载机制，把专业领域知识做成「按需触发」的能力包，避免每个会话都被无关 expertise 撑满 - Plugins & MCP servers：接入外部工具和数据 - LSP integrations + Subagents：锦上添花的两块拼图 文章给出了三条关键模式：第一是分层的 CLAUDE.md 文件，第二是接入 LSP 拿到准确的引用关系，第三是明确的团队所有权。第三点我特别认同：AI 工具在大组织里能不能用起来，技术问题只占一半，另一半是谁负责维护这套规约。如果 CLAUDE.md 没人 own，3 个月后就会变成一份谁也不敢动、也没人相信的文件。这套思路其实就是 Agent Engineering 最具体的样子。Anthropic 在自己产品的官方博客上正式给出了答案。 → 阅读原文：https://www.bestblogs.dev/article/243d2340 同期发的第二篇是 Claude Code Agent View，简单说就是把多会话并行管理这件事终于做成了产品。以前你同时跑几个 Claude Code 会话，需要开几个终端窗口、或者用 tmux 切分屏，再加上你自己脑子里那张哪个还在等输入、哪个已经跑完的表。现在 Agent View 在命令行里就给你一个统一面板，谁需要你回话、谁还在干活、谁已经把 PR 提了，一眼看清楚。你甚至可以直接用 claude --bg [task]，把任务直接丢到后台，左箭头返回总览。我自己最近在跑很多并行 Agent，这个东西出来之后确实顺手很多。 → 阅读原文：https://www.bestblogs.dev/article/e8c4364d 第三篇是 Claude 团队整理的 Computer Use 和 Browser Use 完整最佳实践。重点其实是一个特别容易被忽略的细节：截图分辨率。Claude 4.6 系列有 1568 像素长边上限，Opus 4.7 提到了 2576 像素。如果你给模型送的截图超过这个限制，API 内部会自动降采样，但你的代码还在用原图的坐标系，结果模型基于一个失真的图判断点击位置，整条工作流直接塌。这种坑你不踩一次基本不会知道。文章还讲了努力度参数怎么选、提示注入怎么防御、上下文怎么管理（缓存断点、滚动缓冲区、LLM 压缩三件套）这套组合拳，是真正能拿来打底的工程清单。 → 阅读原文：https://www.bestblogs.dev/article/94694e50 然后是 OpenAI 这边的 Codex 三连发，跟 Anthropic 的节奏几乎是对称的。 第一篇是 Codex 的 Computer Use 上线，特点是 Codex 在你电脑里有一个自己的独立光标，不抢用户的控制权。Codex 可以一边在 UTM 里开虚拟机给你测环境，一边你自己继续在 Mac 上写东西，互不打扰。底层是多模态视觉加上系统辅助功能框架的混合：视觉负责定位坐标，辅助功能框架负责拿到每个 UI 元素的文本描述，甚至屏幕外的内容也能看见。他们专门提了一个叫 Spark 的模型，可以完全跳过视觉直接走辅助功能框架，跑出他们说的「超人速度」。隐私这块用每应用权限隔离，没授权的应用 Codex 完全看不见。Mac 已经可用，Windows 即将跟上。 → 阅读原文：https://www.bestblogs.dev/video/cc94ab1 跟 Windows 这件事强相关的，是同周发的另一篇技术博客，专门讲怎么在 Windows 上为 Codex 做沙箱。这篇文章特别工程，作者直接说：Windows 长期没有像 macOS 那样的原生沙箱接口，给 Codex 上线时只剩两个糟糕选项：每条命令都问用户，或者干脆完全放行。他们的解决方案是从一个非提权的原型迭代到一个带防火墙的提权方案，用专用的用户账户隔离 Codex 进程，再叠加防火墙规则封住网络出口。这套方案不损失开发体验，安全性又接近 macOS 沙箱。我读完最大的感受是，安全这件事在 Agent 时代会变得越来越像系统级工程，不是写几个 Prompt 防御就完事。 → 阅读原文：https://www.bestblogs.dev/article/36e502e0 第三篇是 Codex 负责人 Tibo Sio 在 OpenAI Forum 上的一段访谈，这个我建议大家有时间真去听一下，因为他直接讲了 Codex 下一步要去哪儿。他的判断是，Codex 已经不再是开发者工具，而是一个本地长周期的 Agent，能跑数小时甚至数天的自主任务。最有意思的演示是他用一句语音 prompt 让 Codex 给自己生成了一个定制电子表格，还有一张按价格和质量过滤的旧金山面包房地图。他给这种东西起了一个名字叫 「家常软件」，意思是非技术用户也可以为自己做工具。然后他预告了两个能力：Slash Goal，让你说一句高层意图 Agent 就执行；Auto Review，让一个次级 AI 在主 Agent 干活的时候充当裁判审计它的行为。我觉得这两个东西如果都做出来，Coding Agent 这个范式就真的可以让位给通用 AI 队友了。 → 阅读原文：https://www.bestblogs.dev/video/e310426 这六篇放在一起看，整个 Coding 工具的工程化底座就清晰了：模型层暂时没大动，但围绕模型怎么用、怎么管、怎么让它接管真实计算机，这一周一次性给了一份相对完整的答案。 ## 二、把 Agent 推到生产必须先过的两道关：评估与长时运行 第二条主线，是把 Agent 真正推到真实工作流必须先过的两道关：评估和长时运行，以及它们共同的协议层 Agent Skill 标准。 先说评估。Towards Data Science 这周发的一篇文章，标题就说基于 100 多次企业部署沉淀出 12 项指标框架。作者一开头讲了一个故事：他们给一个医疗 AI 客户做了三个月的项目，眼看就要上线，客户的合规官问他们一句：「你怎么知道你的 Agent 没在编造病人症状？」这个团队当时哑口无言。然后他们花了六周补完了一套 12 项评估指标，项目才上线。 这套指标分三个层面，作者还额外加了一组生产侧指标： - 检索层（Retrieval，4 项）：Context Relevance > 0.85、Context Recall > 0.90、Context Precision > 0.80、Retrieval Latency < 200ms p95 - 生成层（Generation，3 项）：Answer Faithfulness > 0.95、Answer Relevance > 0.90、Hallucination Rate < 2% - Agent 行为层（Agent，3 项）：Tool Selection Accuracy > 0.92、Tool Execution Success、Task Completion - 生产侧（Production，2 项）：成本、P99 Latency < 3s 作者还把「为什么大多数团队跳过评估」拆成了三种典型反模式：「先 MVP 再加评估」（结果回填要 4-6 周，损失不可逆）、「准确率够了就行」（基准 95% 的 RAG 在真实流量上 30% 在幻觉）、「人工抽检就够」（每天 100 条还行，10000 条直接崩）。他给的结论非常硬：评估基础设施绕不过去，它直接决定项目能不能上线。检索质量不行，下游再多 prompt 工程都救不回来，这是我看完后印象最深的一句。 如果你正准备把 Agent 推到真实场景，这是开工前应该先打印出来贴在墙上的清单。 → 阅读原文：https://www.bestblogs.dev/article/ed72fe59 跟评估并列的另一道关是长时运行。Google ADK 团队这周发了一个非常具体的教程，主角是一个新员工入职流程的协调 Agent。他们一上来就说：真实企业工作流主要由「空闲时间」构成，HR 入职跨两周，发票纠纷拖几天，销售跟进延绵一个月。一个无状态的 chatbot 容器一重启就忘光了所有上下文，根本撑不住这种节奏。 他们用一个完整的代码示例，演示了三处架构跃迁： - 结构化的记忆 schema：替代往向量数据库里扔 JSON 这种粗暴做法 - 事件驱动的休眠门：替代轮询或者阻塞线程，让 Agent 在等待签字的时候真的休眠 - 多智能体委派：替代一个巨型 Prompt 包打天下 完整源码在 GitHub 上，这是把 Agent 真正搬进企业流水线之前必须先看的一篇。 → 阅读原文：https://www.bestblogs.dev/article/7be5372c 然后是 Agent Skill 这件事。Anthropic 去年 12 月把 Agent Skill 作为开放标准发布，半年时间过去了，已经有 33+ 个 Agent 产品接入：Claude Code、Codex、GitHub Copilot、VS Code、Cursor、Gemini CLI、Kiro，全部都在用同一个叫 SKILL.md 的协议。阿里云开发者这周发了一篇深度解析，把规范字段、三层渐进式加载机制、模型驱动触发逻辑讲得特别透。 我最喜欢里面那句总结：Skill 围绕任务、工具、流程和输出边界做结构化行为设计，比单纯堆 Prompt 更靠谱。他还提到了一个非常实操的判断：description 字段的质量直接决定 Skill 能不能被正确触发。你以为 description 只是给人看的，其实模型先读这个字段决定要不要打开 Skill。我觉得 Agent Skill 是这一波最有可能成为长期基础设施的标准之一，因为它已经跨厂商了。 → 阅读原文：https://www.bestblogs.dev/article/ad38855c ## 三、国内厂商的多智能体 Harness 三连发 第三条主线，国内厂商的 Multi-Agent Harness 实战集中爆发。这周一口气来了三篇，分别从数据库、运行时和 Java 生态三个角度切入。 第一篇来自 PingCAP 的联合创始人黄东旭，他复盘了 TiDB Cloud 怎么成为 Kimi K2.6 Agent 的数据库后端。这件事的背景很有意思：Kimi K2.6 让普通用户用一句话就能造出一个端到端的在线应用，挑战根本不在代码生成那一段，而在后面的 hosting 成本。 你算一笔账：如果每个用户的 Agent 应用都给它配一个 Supabase 实例，百万级动态创建小站直接成本爆炸。如果用一个大 PG 实例多 schema 隔离，单实例到了大约一万租户就崩了。TiDB Cloud 的做法是给每个租户提供一个虚拟数据库界面，下面跑统一的存储和计算资源，把单租户成本压到订阅模式还能算账的水平。 黄东旭还给出了 Kimi × TiDB 这套合作能跑通的三个核心战略决策，每一条都很有借鉴价值： - 最小化 Agent 使用 Infra 工具时的摩擦：每个任务和站点独立隔离，由 Agent 创建。Agent 一秒拿到一个 fully prepared 的数据库实例（TiDB Warm Pool + Scale-to-zero）。如果 provisioning 要花几分钟，Agent 就得自己写 retry / poll / wait，那是 Agent 不该扛的负担 - 技术栈尽可能统一：人类工程师觉得「方便」，对 LLM 就是直接决定代码生成成功率的因素。少跨一个系统就少一类 bug，Skill 里跑过的脚手架比每次抽卡更稳 - 极致的低成本：放弃 Supabase 那种「每个用户一个真实实例」的分配模式，TiDB 引入虚拟数据库界面层。「事实上没有请求的事情，是不需要真实分配数据库实例的」。平台只需要一个常驻 DB Session Gateway 服务维持连接，其他都是弹性的 黄东旭对这一波的判断非常清晰：「以前一个产品扛亿级用户，一个 app 扛亿级会话。现在一个用户身边可能有 10 个甚至 100 个 Agent 在跑，每个都需要自己的状态和数据。」很多 AI Agent 团队的架构正在收敛到同一个范式：one agent, one sandbox, one storage, one database。 这是 Agent Native 时代数据基础设施竞争的第一个真案例。以前我们讨论数据库的扩展性更多是单点性能，现在的问题变成了：几百万个独立租户里每一个都很小，怎么把单位成本做下去。 → 阅读原文：https://www.bestblogs.dev/article/70ea435c 第二篇来自腾讯云开发者，这是一篇真正意义上的长文，把生产级 Multi-Agent Harness 的全景图画出来了。作者一上来就指出一个关键的误区：很多团队以为多智能体系统能不能落地，取决于模型够不够强，或者 Prompt 够不够精妙。真正决定落地的，往往是常被忽略的 Harness。Harness 这个词翻译过来叫挽具，但在 Agent 领域它就是 Agent 的操作系统。 他给出的生产级原则只有一句话：Agent 负责局部智能，Harness 负责全局控制。然后他详细说了 Orchestrator 必须独占的五项决策权： - 任务生命周期 - 执行计划的裁决 - Agent 路由 - 失败处理 - 硬终止条件 每一条他都讲了具体怎么做，配了 PlantUML 图。国内能把多智能体工程化讲得这么完整的文章并不多见，建议有相关项目的朋友收藏。 → 阅读原文：https://www.bestblogs.dev/article/878057b5 第三篇是阿里发布的 AgentScope Java 1.1，把他们前几个月开源的 OpenClaw 那套 Harness Engineering 范式正式带到了 Java 生态里。这是国内首个 Java Harness Framework，对企业级开发意义很大，因为大量传统行业的服务还是跑在 Spring 上的，Python 那套 Agent 框架没法直接搬。 Java 1.1 给了四项核心能力： - 工作区驱动的运行时：把 Agent 的人格、知识、技能、记忆、子 Agent 规格全部沉淀在一个结构化工作区里 - 可插拔的抽象文件系统：本地磁盘、远端共享存储、隔离沙箱用同一套接口操作，同一份 Agent 逻辑不用改代码就能从个人开发环境搬到企业分布式部署 - 内置的上下文管理：对话压缩、双层记忆沉淀和全文检索 - 子 Agent 编排和隔离执行：支持多租户场景的会话和用户维度隔离 如果你公司主要技术栈是 Java，这个框架值得认真试一下。 → 阅读原文：https://www.bestblogs.dev/article/321aed16 跟这三篇可以放在一起读的，还有大淘宝技术团队发的 AI-Generated UI 技术深度解析。这篇文章把 v0.dev、Bolt.new、Cursor、Windsurf 这一批产品背后的全栈技术梳了一遍：从 SSE 协议、fetch + ReadableStream 这些基础设施，到 Vercel AI SDK、WebContainers 这些开源核心，再到流式代码、流式 Markdown、流式 JSON 三大增量解析挑战。如果你想做出 v0 那样的 AI 生成 UI 体验，这是补全技术地图最干净的起点。 → 阅读原文：https://www.bestblogs.dev/article/42f8648f 这周国内厂商一次性给了多智能体工程化的四块拼图：数据库、运行时全景、Java 落地、流式 UI 渲染。这种密度，未来一年都不一定再见到。 ## 四、AI Native 时代的组织、商业模式与三场访谈 第四条主线，把视角从工程化往后退一步，去看组织、商业模式、以及一线人物对这件事的不同回响。 先说阿里技术发的那篇《AI Native 时代研发组织何去何从》，这一篇建议大家直接收藏起来反复读。他们对内部深度使用 AI 的工程师做了访谈，结果是这样的： - 写代码占比从过去的 30% 降到 5% - 跟 Agent 对话的占比从 5% 升到 60% - 端到端需求交付效率提升了 2-3 倍 作者紧接着提出了一个判断，让我读了之后愣了好一会儿：AI 是一种新的协作主体。所有过去以人形约束为前提设计的组织规则，比如康威定律、管理跨度、年度评价制，前提开始失效了。他观察到正在做 AI Native 的团队（包括 Anthropic 和阿里内部的一些先锋小组），都出现了一种共同形态：两层结构。下面是高度结构化的 Harness 层，上面是高度松散的 Hive Mind 层，两层的运作逻辑甚至是相反的。 这篇文章里有几段我想专门展开。 关于「人既是瓶颈也是兜底」。作者在访谈里写道：「之前的模式一个工作需要拉入很多人来做模块划分，功能上需要相互协议和对齐目标，消除理解的不一致性。」过去几十年我们抱怨的「会议太多、对齐成本高、信息上下传递失真」，所有矛头都指向人。但与此同时，一份不完整的需求、一段没注释的代码、一个不一致的 API 约定、一段口头传达的潜规则，这些缺陷之所以系统能正常运转，是因为人在用自己的灵活性、推理能力、社会沟通能力悄悄把缺口补上。「开个会问一下、走过去问老王、凭经验猜一下」，这些动作发生得太自然，自然到我们不再把它看作「工作」。但它们就是工作。当 AI 接管执行之后，这一面就翻过来了。AI 没有「猜」和「问老王」的能力，它需要的是结构化、可查询、可执行、确定性的信息。新瓶颈落在系统的信息形态上。 关于 Execution Graph 替代 Org Chart。作者给出了一个具体的、可衡量的判断：传统 reorg 周期常常是 6 到 12 个月（计划几个月、执行几个月、重建信任又几个月），因为旧组织的最小单元是「人 + 长期关系网」，粘性极高。Execution Graph 把组织最小单元从「人 + 关系网」换成「任务 + 上下文 + 权限 + 工具」，里面大部分依赖是机器可读的 artifact，所以重组成本可以从季度级压到 week 级，这是数量级的跃迁。从公司层面看，这可能是 AI Native 转型最被低估的红利：适应性速度本身的升级，远比「组织能更高效」更值钱。 关于 Architect 这个新角色。文章用 CREAO 的 CTO Peter Pang 做案例：他自己两个月前还有 60% 时间在管人，现在不到 10%。但作者强调，管理在塌缩，也在重新选择它的位置。新出现的最关键角色叫 Architect，设计教 AI 怎么工作的人：他不写代码，不堆功能，为整个 Execution Graph 设计架构、定义系统能力的边界、设计 SOP、建立测试基础设施、定义「什么叫好」。 这三段读完，我觉得这是本周最值得反复读的一篇。它把整个组织视角的思考做实了。 → 阅读原文：https://www.bestblogs.dev/article/8c2c877a 跟这个组织议题完美对仗的，是 Eric Ries 在 Lenny's Podcast 上聊他的新书 Incorruptible。Eric Ries 是精益创业的作者，这次他要解决的问题是：成功的公司为什么会逐渐被拖向平庸。他指出的症结，是一种他叫**「财务引力」**的东西，是公司治理结构的天然产物。 他用了一个特别好的比喻：公司治理需要「不锈钢螺栓」，就是结构上防腐蚀的东西。他列了三类： - 公共利益公司（PBC）：将使命写入章程 - 信托治理：Anthropic 的独立受托人模式，监督关乎使命的关键决策 - 基础所有权：Novo Nordisk 由非营利基金会控股的模式 如果你也在思考你的公司怎么长期不被外部财务力量吃掉，这是一篇稀缺的具体路径讨论。 → 阅读原文：https://www.bestblogs.dev/video/2efe03f 然后是三场关键访谈，让本期内容立体起来。 第一场：Stripe 的 AI Boom 系列采访 Manus AI 的张涛。Manus 这个产品很多人听过：八个月做到 1 亿美元 ARR，几乎全部是有机增长。他们的核心架构叫「大脑与手」：大模型是大脑，Agent 需要一只手，他们就给每个 Agent 配一个虚拟机沙箱让它自己浏览、写代码、跑命令，更侧重输出完成任务，文本只是中间产物。张涛分享的最有意思的产品决策，是把 Agent 内部的过程做成「会话回放」给用户看。本以为透明会让用户怀疑，结果反而换来了信任。他对未来的判断：AI 之后，人的瓶颈从「解决问题」转向「定义问题」。 → 阅读原文：https://www.bestblogs.dev/video/cf1fb78 第二场：Sequoia 访谈 Suno CEO Mikey Shulman。Suno 这个公司你即便不做音乐也值得听听他们的思路。他们的技术路线不走 12 平均律和 MIDI 那套西方音乐理论，把音乐建模成 48 kHz 采样的连续声波，相当于第一性原理重做音乐生成。这种做法让一些原本不存在的形态自然涌现，比如「带西塔琴的 trap」，比如微分音音乐。但他给的最反直觉的发现是：Suno 用户里有 90% 每天都在创作，消费占少数。AI 一边把「地板」抬高了（人人能做音乐），一边也把「天花板」抬高了（专业音乐人拿到了新工具）。 → 阅读原文：https://www.bestblogs.dev/video/c6a585f 第三场：张小珺 4 小时对话姚顺宇。姚顺宇前后在 Anthropic 和 Google DeepMind 出任过研究科学家，参与过 Claude 3.7、4.5、Gemini 3 的训练。这场访谈直白到罕见，姚顺宇本人在物理学（非厄米系统、量子物理、高能物理）深耕九年后毅然转行 AI，自言「总想挑战一些自己不太会的事」。访谈里他几句话特别戳人： > 「AI 个人英雄主义的时代已经过去了，所以也没有什么英雄，有时候甚至觉得旧时代英雄有点蠢。」 「现在大家都是冲浪的人，本质上是那个浪，冲浪的人反而没那么重要。」 「AI 这个事，本来也不太需要脑子。真的不太需要脑子。这个行业最重要的特质，就是靠谱，就是做事细，对自己做的事情负责任。」 「你不用太担心因为自己的观点而惹到什么人。只要你的观点是自洽的，不是说随便喷人，你是有一套自己的理解。最终你在这个领域做的怎样，是有客观评价标准的。大家是会尊重你的。」 4 小时的内容覆盖两个 Shunyu Yao（清华同一届的姚顺雨和姚顺宇）、Pre-train 没到头、Coding 爆发、字节豆包、机器人技术预测、AI 个人英雄主义的终结、集体主义胜利。在描述自己的研究时，姚顺宇又异常审慎：「我自己对那个事没那么重要，更多的是我很幸运，有机会在那个时候加入了一个重要的项目，做了一些事」。 我看完最大的感触是：新一代 AI 工程师的工作伦理变了，集体主义、靠谱、做事细正在取代个人天才主义。这场访谈是少数能从一线训练者口中拿到的真正内幕。 → 阅读原文：https://www.bestblogs.dev/podcast/a4391a3 最后一个亮点，是 AI 在真实产业现场的两种姿态。 一种是李想这边的宏大愿景。罗永浩这周对话李想，理想汽车带来了全新旗舰 SUV L9 Livis。这车搭载理想自研的马赫 M100 芯片，算力达到 2560 TOPS，配的是全球首个完全体全线控底盘，还有 800V 主动悬架。这场访谈三个小时，李想本人完成了从汽车公司创始人到「AI + 具身智能公司」创始人的角色切换。 → 阅读原文：https://www.bestblogs.dev/podcast/177bfb5 另一种姿态是 flomo 的少楠在腾讯研究院 AI 跃迁者调研里给出的真实困境。少楠是 11 年没写过代码的产品经理，现在每天用 Claude Code 在真实数据库里跑 3 个小时的需求验证，他公司 70-80% 代码已经由 AI 贡献，开发周期从按月变成按小时。但他给出了一个反直觉的观察：效率上去了，用户价值没跟上。 他的原话是：「以前工程师烦死产品经理觉得需求太多，现在是产品经理不好意思提需求了。」他还说了一句让我特别有共鸣的话：只有原来优秀的人变得更优秀了，因为 AI 无法回答一句话：『我不知道』。16 人团队的协作重构，比工具升级难得多。 → 阅读原文：https://www.bestblogs.dev/article/6af09fd5 李想那条线是宏大愿景，flomo 这条线是真实困境，把这两条放在一起，可能比任何技术分析都更接近 AI 这一年的真实样子。 ## 本周关键词 如果非要给本周挑几个关键词的话，我会选这几个： - Agent 工程化的全面落地 - Coding 工具走出 IDE - 国内多智能体 Harness 三连发 - AI Native 组织 - 真实产业现场的两种姿态 这周没有什么模型发布，但跟模型相关的工程化、组织化、产品化的答案，一次性给得特别多。下周我会重点关注国内厂商在 Agent 工程化的后续动作，看看这周的密度能不能延续。 20 篇文章的完整链接都在上方各章节里，如果哪一篇特别戳到你，建议直接读原文。 我们下周见。 ## 关于 BestBlogs BestBlogs.dev 是 AI 驱动的个性化高质量阅读工作流，**「我的早报」**会基于你关注的源、阅读行为与兴趣画像，每天为你生成一份真正属于你的精选 brief，让你以最少的时间触达本周最值得读的内容。 完成新用户三步引导即送 7 天 Pro 试用；现有 Pro 用户每邀请 1 位朋友双方各得 7 天 Pro（单人上限 28 天）；5 月 9 日之前注册的老用户别错过 5 月 15 日至 5 月 31 日的 14 天 Pro 限时赠送，到 bestblogs.dev/promo 一键领取。 让高质量内容找到对的人。欢迎来体验，也欢迎推荐给身边热爱阅读的朋友。

译近期AI领域焦点从模型能力转向Agent工程化落地。Anthropic发布Claude Code实践，强调放弃RAG索引，采用Agentic Search导航大型代码库，并推出管理并行会话的Agent View及Computer Use最佳实践。OpenAI的Codex推出独立光标的Computer Use功能，解决了Windows平台沙箱安全问题，其负责人指出Codex正演变为可执行长期自主任务的本地Agent。国内厂商如阿里、腾讯等也在同步推进Multi-Agent实战，标志着AI Agent进入全面工程化应用阶段。

ginobefun@hongming731 · 5月15日56

本周没有新模型发布，却是 Agent 工程化信息密度极高的一周。Anthropic 与 OpenAI 同步把 Claude Code、Codex 推出 IDE，Computer Use、Windows 沙箱、截图分辨率等落地细节一次讲透；另有 12 项 Agent 评估指标、Agent Skill 开放标准，以及国内 TiDB、腾讯云 Harness、AgentScope Java 三连发。想把 Agent 真正推进生产，这期内容值得阅读和收藏。

译本周科技领域聚焦Agent工程化落地。Anthropic与OpenAI分别将Claude Code和Codex集成至IDE，并详细披露了Computer Use、Windows沙箱等关键实施细节。行业同时推出了包含12项指标的Agent评估体系及开放的Agent Skill标准。国内TiDB、腾讯云Harness、AgentScope Java也相继发布相关产品，共同推动Agent技术进入实际生产环境。

Peter Steinberger 🦞@steipete · 5月15日62

built a new feature into discrawl (store media), codex said it's done, then I used my codex review skill... https://github.com/steipete/agent-scripts/blob/main/skills/codex-review/SKILL.md

译为discrawl（存储媒体）构建了一个新功能， codex说它已完成， 然后我使用了我的codex审查技能... https://github.com/steipete/agent-scripts/blob/main/skills/codex-review/SKILL.md

Chubby♨️@kimmonismus · 5月15日56

Dario reiterates in his latest article: Powerful AI ("AGI") is coming in 2028. As a reminder, here's what he said about it in Machines of Loving Grace: "Powerful AI" describes a system that is not just better than humans at individual tasks, but smarter than top experts across most important domains, able to reason, create, code, research, and act autonomously through digital interfaces. and "A country of geniuses in a datacenter" means that millions of these highly capable AI agents could run in parallel, working faster than humans and collaborating like an entire nation of Nobel-level experts compressed into computing infrastructure. In the latest blogpost they write: "When US frontier labs release new models in 2028 that achieve step-function advances in capabilities (similar to the relative impact of Mythos Preview in April 2026)"

译Dario在其最新文章中重申，强大的AI（或称AGI）将在2028年到来。他定义的“强大AI”并非仅在单一任务上超越人类，而是在大多数重要领域比顶尖专家更聪明，具备自主推理、创造、编码、研究和通过数字界面行动的能力。他进一步用“数据中心里的天才国度”来比喻，即数百万个这样的高能力AI代理可以并行运行，其工作速度远超人类，并能像压缩在计算基础设施中的整个诺贝尔奖专家群体一样协作。其最新博文预测，到2028年，美国前沿实验室将发布能力实现阶跃式提升的新模型。

歸藏(guizang.ai)@op7418 · 5月15日71

刚才阿真提醒才发现， GPT 的 Codex 远程控制可以链接多个设备 只需要在你另一个设备的 Codex 上点击那个“设置 Codex 移动版就行”

译GPT的Codex功能现已支持通过手机ChatGPT进行远程控制。用户可将移动设备与桌面端Codex绑定，实现对话自动同步，并可直接从手机发送指令、审批权限及监控进度。设置需在Mac版Codex客户端启用“设置Codex移动版”，过程中建议使用Google Authenticator完成多重因素验证，而非短信。目前该功能仅支持Mac，Windows版本仍在开发中。

MiniMax (official)@MiniMax_AI · 5月15日57

Excited to see MiniMax in action inside open-multi-agent! 🔥 It automatically breaks goals into DAG tasks &amp; runs them in parallel

译MiniMax AI已作为原生适配器集成至open-multi-agent框架，旨在解决多智能体系统在生产环境部署的核心成本难题。该框架能自动将目标分解为DAG任务并并行执行，但传统多智能体方案的token成本会随智能体数量、交互轮次和工具调用次数快速复合增长，这常导致实际生产部署受阻。此次集成使得由目标驱动的智能体团队不仅能高效运行，更能保持可负担的生产成本，从而推动其从演示场景走向实际应用。

Alibaba Cloud@alibaba_cloud · 5月15日50

A K-POP MV, mostly directed by AI agents? 🎤✨ Built SPECTRA using Wan2.7 & HappyHorse. Agents handled generation, iteration, and editing — Shun Fujiyoshi @GhostyAIpp, Alibaba Cloud MVP, oversees quality gating and handles retakes. Not zero-touch yet. But close. 🎞️ Watch the MV: https://youtu.be/CwDxsTWy1Ak 📖 Full dev blog: https://int.alibabacloud.com/m/1000412982/ 🚀 20% OFF HappyHorse: https://int.alibabacloud.com/m/1000412936/

译一支主要由AI代理执导的K-POP MV？🎤✨ 使用Wan2.7和HappyHorse构建SPECTRA。代理负责生成、迭代和剪辑——由阿里巴巴云MVP Shun Fujiyoshi @GhostyAIpp监督质量把控并处理重制。 尚未实现零接触。但已非常接近。 🎞️ 观看MV：https://youtu.be/CwDxsTWy1Ak 📖 完整开发博客：https://int.alibabacloud.com/m/1000412982/ 🚀 HappyHorse八折优惠：https://int.alibabacloud.com/m/1000412936/

Peter Steinberger 🦞@steipete · 5月15日79

This is a game changer. With codex autoreview and crabbox I can now go from issue to fix almost fully automated. (yes it does burn lots of tokens)

译这改变了游戏规则。通过codex自动审查和crabbox，我现在几乎可以全自动化地从问题定位到修复。（是的，这会消耗大量token） [引用 @steipete]：编写了一个循环运行codex/review的技能，直到不再出现错误为止。 注意事项：它不会为你修复系统架构，所以你仍然需要以BRAIN作为主模型。https://github.com/steipete/agent-scripts/blob/main/skills/codex-review/SKILL.md

歸藏(guizang.ai)@op7418 · 5月15日65

飞书 CLI 牛皮啊，发布一个月多点就达到 10000 Star 了！ 说明用户和市场相当认可这个动作 最近我们可以发现，越来越多的传统办公产品开始发布 CLI 和 Agent。 AI 时代的 SaaS 软件可能得换个做法了：UI 只是最基本的，接下来还要竞争对 Agent 的适配程度以及覆盖率。在这块，我觉得飞书走得相当靠前。 作为一个 IM 软件，飞书在 AI 时代去做这种开放自己所有能力的 CLI 工具，其实是一种非常不传统互联网的尝试。 这对于之前的互联网产品逻辑和经验来说，是一个非常不应该做的决定。 因为他们这个 CLI 几乎可以控制飞书的所有能力：你可以完全不跟飞书的传统 UI 去交互。只跟 CLI 交互，也可以完成飞书上所有的工作。 传统的 IM 办公软件通常非常复杂，入门门槛相对较高。无论从产品逻辑、UI 设计还是交互设计的角度来看，都没有办法太好地消解这种复杂性。 但是 CLI 工具交付给 Agent 以后，就可以快速消解这种复杂性。用户只需要进行对话，这是非常本能的行为，不需要在繁杂的层级列表 UI 里去寻找功能入口。 我拉了一下数据，他们迭代效率也非常恐怖，它们是 3 月 28 号开源的，一个多月发了 32 个版本、385 个提交。 这说明飞书对这块是非常重视的，投入的人力和精力也非常大。 他们在 CLI 本身的设计上也考虑得非常多，下了很多功夫。主要分为三层： 面向日常任务的快捷命令、开放平台对应的标准 API、兜底的 API 调用。 因为人和 Agent 都不喜欢从 2500 个 API 里去寻找参数，但又需要把这些能力暴露出来，所以他们采用了这种分层的形式。 即使做了分层设计，CLI 本身的内容和 API 依然非常多。所以他们把 CLI 作为工具本身，同时做了很多 Skills 用来充当 CLI 的说明书。 Agent 可以分层、分类型地了解应该如何调用这些 CLI 及其命令。 此外，他们在对 Agent 友好的命令包装上做了很多工作，例如： (a) 内置了 Dry Run (b) 结构化输出 (c) 身份选择、权限检查与风险等级评估 (d) 允许 Agent 在发消息前预览请求 (e) 建立了输出格式的“契约”：将成功或失败的结果、原因以及风险提示都放在结构化数据里。 这样如果出错了，AI 可以非常清楚地进行调试和修改，而不是盲目猜测。 其实现在你如果要创业或者做自己的 Agent，就不需要非得写一个界面。 飞书 CLI 加上 Agent 框架可以完成所有的 Agent 产品常见的操作： 你的聊天界面就是你的 Agent 聊天界面； 你的数据库就是飞书多维表格和文档； 你的用户就是把你拉到组织里的群成员；

译飞书CLI工具发布一个多月即获10000 Star，显示市场对其方向的认可。在AI时代，SaaS软件的竞争正从传统UI转向对Agent的适配。飞书通过开放全部能力的CLI，允许用户和Agent完全绕过复杂UI进行操作，大幅降低了使用门槛。其CLI设计采用分层结构，并配套大量Skills作为“说明书”，便于Agent调用。同时，CLI在命令包装上注重对Agent友好，内置Dry Run、结构化输出等功能，方便AI调试。这为创业或构建Agent提供了新路径，可依托飞书CLI和Agent框架，直接利用其聊天界面、多维表格及组织成员作为基础设施。

AYi@AYi_AInotes · 5月15日67

Google下周要发布的Gemini Spark，应该是 AI Agent 时代真正到来的信号了🙂 我理解它既不是ChatGPT的直接竞品，也不是又一次模型参数的升级， 更像一个Google正式把AI从你叫它才干活的工具，变成了24/7替你运行的个人操作系统级Agent， 它不会再等你发prompt，会主动自己帮你筛选邮件，预约会议，跟进在线任务，甚至代你上网点按钮填表格， 我觉得最核心的突破是它终于有了持久化的记忆和上下文， 以前的AI每次对话都是全新的，用完就忘， 现在它会持续从你的每一次操作里学习，越用越懂你， 别人做代理还在拼谁的工具调用更全，Google直接掏出了别人永远复制不了的杀手锏， 你的搜索历史，你的位置信息，你的日历邮件，你的所有Google服务数据，这些加起来就是一张关于你的完整全息图， 我觉得这才是真正的护城河， 当然风险也真实存在，它会保存你的登录凭证，会在必要时分享你的信息，甚至可能未经确认就直接购物， Google把这些警告都给你写的明明白白， 但我想大多数人最终还是会选择便利，毕竟历史上每一次数据换便利的博弈，结果从来都没有变过， 真正聪明的人不会全盘拒绝，也不会全盘接受， 他们会把控制权握在自己手里，只开放必要的权限，定期清理数据， 对重度依赖Google生态的人来说，这可能不是百分之十几的效率提升， 可能是整个工作和生活流程的彻底重构， 你睡觉的时候它在帮你处理邮件， 你吃饭的时候它在帮你跟进项目， 这才是AI Agent真正该有的样子， 5月19号的Google I/O，很可能会成为2026年Agentic AI真正的分水岭时刻，一起期待吧 #Gemini #AI代理 #GoogleIO

译Google即将发布的Gemini Spark标志着AI Agent时代的实质性进展。它并非单纯的聊天机器人或模型升级，而是演变为一个能24/7持续运行、拥有持久化记忆的个人操作系统级代理。其核心在于能主动处理邮件、预约会议、跟进任务，并持续从用户操作中学习。Google的独特优势在于整合了用户的搜索历史、位置、日历、邮件等全生态数据，构成了强大的护城河。尽管存在数据与隐私风险，但该产品有望彻底重构重度Google用户的工作与生活流程，使5月的Google I/O成为Agentic AI发展的关键节点。

歸藏(guizang.ai)@op7418 · 5月15日37

Codepilot 新版预览，即将支持 Codex 作为 Agent 引擎

歸藏(guizang.ai)@op7418 · 5月15日69

也可以直接在 ChatGPT 里边用控制 claude code 或其他的软件。 让 codex 调用 computer use 控制就行。 这样的话，如果你是 codex 和 cloud code 的协作开发，就可以让就可以都在 ChatGPT 里边进行控制。 你如果你开的是自动审查权限的话，就不太好控制，开那个完整权限才行。 不然自动审查会拒绝他读取终端 claude code 里的内容

译Codex现已支持通过手机上的ChatGPT应用远程控制绑定的桌面设备。该功能可实现对话自动同步，并允许用户直接发送指令、审批权限及监控进度。设置需在桌面端Codex客户端内启动，并建议使用Google Authenticator完成多重因素验证。绑定后，手机ChatGPT应用将出现Codex侧边栏，用于访问和控制桌面端对话。目前该功能仅支持Mac版Codex，Windows版本仍在开发中。

Berryxia.AI@berryxia · 5月15日70

兄弟们，国内大模型现在彻底”大乱斗“了！ 群雄共舞啊，用户可以有更多的选择了！ 来自Ant Group AGI团队直接把Ring-2.6-1T这个1万亿参数的旗舰思考模型开源了。 这不是又一个聊天玩具，它专为真实世界的复杂任务而生：Agent工作流、代码工程、长时序执行、深度研究、企业自动化。 它能理解上下文、规划步骤、调用工具，在漫长任务链里保持稳定。支持两种reasoning模式——high用于高效生产，xhigh用于极致思考。底层IcePop异步强化学习算法，把万亿规模的长时序训练彻底稳住了。 最关键的一点，它完全开源。 这意味着什么？ 兄弟们现在可以直接把这个顶级模型拉到本地服务器或者端侧环境跑，企业所有数据完全不出域，隐私安全和合规问题直接解决。 以前很多金融、政务、医疗、大型企业，因为数据敏感性，只能眼巴巴看着云端闭源模型干瞪眼。现在Ring-2.6-1T直接把执行级思考能力放在了自己手里。 本地部署门槛也已经大幅降低，结合MoE架构和优化后，很多中大型企业完全可以把最强Agent能力跑在自家机房。 模型已在以下地址上线： Hugging Face：https://huggingface.co/inclusionAI/Ring-2.6-1T ModelScope：https://modelscope.ai/models/inclusionAI/Ring-2.6-1T 如果你在做企业Agent、内部自动化或者对数据安全要求极高，这波开源值得立刻去试。

译蚂蚁集团AGI团队开源了万亿参数旗舰思考模型Ring-2.6-1T。该模型专为处理Agent工作流、代码工程、长时序执行等复杂任务设计，具备上下文理解、规划与工具调用能力，并提供高效与极致两种推理模式。其采用IcePop算法稳定训练，并借助MoE架构降低部署门槛。完全开源允许企业将模型部署于本地或端侧，确保数据不出域，有效解决了金融、政务等敏感领域对数据安全与合规的迫切需求。模型已在Hugging Face和ModelScope平台发布。

宝玉@dotey · 5月15日63

看卡兹克提到飞书 CLI 的 star 数过万了，意料之中，飞书确实是目前国内 Agent 最友好平台，我自己也常用飞书 cli 抓去飞书文档为 markdown 和下载文档图片 通常我看一个开源项目是否靠谱，或者是不是 KPI 驱动的开源项目，通常看几个方面： 1. Star 数量，这个虽然也有做假可能，但大多数时候还是能客观反应项目热度 2. Commit 历史，是否活跃提交，很多项目你一看提交时间在几个月前，甚至几年前，那这个项目多半没人维护了，要慎用 3. Issues 数量和关闭速度，一个热门项目是不愁 Issues 的，有人用才有 Issues，但如果只有新 Issue，没有 Issues 被关闭也不好，说明没人认真处理 4. PR（Pull Request）被合并的记录，开源项目不只是说简单的把源代码放出来，社区参与也很重要，如果你发现很多社区的 PR 都没有处理响应，那说明官方不重视社区的参与 拿这几个标准去看大多数项目，你就可以知道这项目是不是靠谱，这几点飞书 cli 都是做的不错的了。 https://github.com/larksuite/cli

译飞书CLI在GitHub上的star数已过万，作者认为这印证了飞书是国内对Agent最友好的平台。作者提出评估开源项目是否靠谱的四项关键标准：star数量反映项目热度；活跃的commit历史表明项目持续维护；issues的数量与关闭速度体现用户活跃度和问题处理效率；社区PR被合并的记录则显示项目对社区参与的重视。飞书CLI在这些方面均表现良好。

宝玉@dotey · 5月15日79

不知道你们有没有用过微信聊天总结 Skill 里面的“毒舌版”，Claude 写的话有时候还挺“毒”的。 提示词是这样的： Roast 版基于普通版的话题骨架和素材，用毒舌、尖锐、挑衅的风格重写。整体结构与普通版相同（统计区块、开头概览、群友画像、正文分类、结尾），但风格完全不同。痛点部分省略。标题加 "毒舌版" 后缀。 风格要求： - 你是一位以尖锐和挑衅风格著称的专业评论员 - 对每个群友的行为、言论进行犀利点评，不怕让人尴尬 - 发言排行旁给每个人加一句毒舌备注（括号内） - 群友画像改为「不留情面版」，放大每个人的槽点和矛盾之处 - 开头概览用更戏谑的口吻，突出荒诞和讽刺 - 正文话题标题可以改得更损 - 引用原话时配上辛辣点评 - 结尾改为：本简报由一个没有感情的 AI 自动生成，如有冒犯，概不负责 注意：毒舌但不恶毒，调侃但不人身攻击。目标是让群友看了会笑，而不是生气。具体红线： - 只嘲讽群里的公开行为，不碰外貌、体重、健康、家庭、私人关系 - 不用时间戳推断作息或时区（服务器时间不等于本地时间） - 不做医学/心理诊断类玩笑（「这位需要看医生」「典型 ADHD」） - 不揣测对方未主动公开的身份属性（性取向、宗教、政治立场） - 嘲讽观点本身，不嘲讽发言的权利（「这个观点错得离谱」可以，「连这都不懂还敢发言」不行） - 如果某人本期没有槽点（3+ 条但都很中性），给一句温和调侃即可，不要硬凑 写作顺序：先放开写最狠的版本，写完再回头检查红线。不要边写边自我审查，那样只会写出温吞水。

译该提示词要求Claude基于普通版总结骨架，以毒舌、尖锐但不恶毒的风格重写微信群聊总结。具体包括扮演专业评论员，为发言排行添加毒舌备注、将群友画像改为“不留情面版”，并用戏谑口吻撰写概览。同时设定了创作红线，如不涉及人身攻击、私人信息或医学诊断，仅针对群内公开行为进行调侃。技术实现依赖于wx-cli，推荐使用Claude Code和Claude Opus 4.6模型以达到最佳效果。

Elon Musk@elonmusk · 5月15日62

Go in with expectations that Grok Build is still beta, but improving almost every day

译Grok Build早期测试版已向SuperGrok Heavy用户开放，初期开发者反馈极为积极。用户认为它感觉比其他编码智能体领先十倍，能原生处理完整智能体工作流、并行运行多个智能体、进行实时代码重构，并拥有支持vim模式和鼠标的精致终端界面。该工具速度快，可清晰管理大上下文，让用户体验类似与自主编码伙伴协作，而非仅获取建议。若测试版保持此发展势头，Grok Build有望成为高级用户的强大工具。

ChatGPT@ChatGPTapp · 5月15日69

Touch grass and leave your laptop—Codex is now on your phone. Now in preview on the ChatGPT mobile app.

译放下电脑接触自然——Codex现已登陆手机。 现已在ChatGPT移动应用开启预览。

Orange AI@oran_ge · 5月15日61

开源一个月的时间，飞书 CLI 在 Github 破万星了。 相比同期的一些 CLI，飞书这个确实是群里口碑最好的。 为 Agent 做软件这件事，飞书践行得很好。

歸藏(guizang.ai)@op7418 · 5月15日55

藏师傅的 PPT Skills，感觉 GitHub star 马上就要破万了呀！ 没点 star 的朋友点点 star 吧，谢谢了。 顺便让 Codex 分析了一下安装的数据，还挺有意思的。

歸藏(guizang.ai)@op7418 · 5月15日56

Codex CLI 设置 Chatgpt 远程控制

歸藏(guizang.ai)@op7418 · 5月15日69

Codex 终于支持手机上的 ChatGPT 远程控制了！ 可以自动同步你绑定的 Codex 设备上的所有对话，而且可以直接发送指令、审批权限、监控进度。 我写一下设置的教程： 1. 点击桌面端 Codex 客户端左侧的“设置 Codex 移动版”，点击后系统会引导你开始设置。 2. 如果你的 ChatGPT 没有设置多重因素验证（MFA），系统会弹出网页要求你设置。这里推荐使用 Google Authenticator（谷歌身份验证器）App，不要用手机短信。 3. 系统会要求你使用手机 ChatGPT 客户端扫码。如果你直接打开手机端 App，它通常会弹出授权请求，直接点击允许即可，不扫码也是可以的。 4. 绑定完成后即可开始使用。你会在手机 ChatGPT 上看到一个 Codex 侧边栏，进去后能看到当前绑定的桌面端设备的所有 Codex 对话。你可以点击进入任意对话并发送命令让它执行。 注意：目前仅支持 Mac 版 Codex，Windows 版本还在开发中。 OpenAI 在封号上没有 Anthropic 那么激进和傻逼，所以你可以放心用。

译Codex现已支持通过手机上的ChatGPT应用进行远程控制，实现了跨设备对话同步与指令操作。用户需在桌面端Codex客户端内启动设置，并完成多重因素验证（推荐使用Google Authenticator）。绑定后，手机ChatGPT App将出现Codex侧边栏，可查看并控制已绑定桌面设备的所有对话，直接发送命令。目前该功能仅支持Mac版Codex，Windows版本仍在开发中。

AYi@AYi_AInotes · 5月15日77

Damn，xAI今天发布的Grok Build， 可能是今年到目前为止最重要的AI产品， 我看很多人还在吐槽它没有漂亮的网页界面，吐槽它贵得离谱， 但就是没人看懂这是代理时代真正到来的第一个明确信号， 铁铁们，这可不是又一个帮你补代码的助手之类的产品， 它能让你指挥一整支AI工程军团的指挥中心， 没有做花里胡哨的GUI， 反而选择了最老派的纯终端界面， 很多人觉得这是偷懒， 我觉得现在这个其实才是最聪明的战略选择， 因为CLI天生支持脚本化， 支持版本控制， 能和所有现有开发工具链无缝对接， GUI反而会成为代理执行的最大瓶颈， 其中最核心的突破是并行子代理机制， 以前的AI编码工具是一个人帮你干活，你得一步步教它， 现在是一个主代理统筹全局， 同时派出研究，写代码，审逻辑，做设计的多个子代理并行推进， 这简直就是结构化的效率革命啊， 所以我觉得那个99美元每月的高价订阅也不是为了赚钱， 相当于给你一个精准的高质量数据过滤器， xAI不需要海量玩票用户的低质反馈， 它要的是重度开发者在真实项目里产生的深度训练信号， 用高价把噪声全部筛掉，留下的每一个用户都是帮它打磨产品的免费工程师， 很多人以为这样AI会让终端彻底消失， 实际上AI正在给这个诞生了半个多世纪的老工具注入全新的灵魂， 未来最值钱的技能可能不再是自己敲代码， 而是如何指挥一群AI代理高效协作完成复杂项目， 初级开发者的工作会被大量替代， 但高级开发者会变成真正的代理军团指挥官， xAI没有等模型在编码上做到完美就把产品扔了出来， 因为它知道真实世界的使用才是最好的训练数据， 边打边练，以战养战， 这才是xAI最可怕的地方， 四年后当所有人都在用AI代理构建产品的时候， 今天所有吐槽它贵，吐槽它难用的人， 都会明白这步棋的真正分量，让们拭目以待咯 #xAI #Grok #AIAgent

译xAI推出Grok Build早期beta版，这是一个面向SuperGrok Heavy订阅者的代理CLI工具。其核心突破在于并行子代理机制，主代理可指挥多个子代理协同执行编码、研究等任务，实现结构化效率革命。战略上选择CLI界面，以支持脚本化、版本控制及与开发现有工具链集成。高价订阅旨在筛选重度开发者，获取真实项目中的高质量训练数据，加速产品迭代。此举标志着AI代理时代正式开启，未来开发者角色将向指挥AI代理军团协作转变。

meng shao@shao__meng · 5月15日66

Codex 进入 ChatGPT mobile App，这回终于能开心的移动办公，随时随地指挥 Codex 工作了（Windows 端还未推出） https://openai.com/index/work-with-codex-from-anywhere/ 新版 ChatGPT mobile App 做了一个完整的 Codex 移动工作面： · 接入用户任意一台运行 Codex 的机器（笔记本、Mac mini、远程开发环境）； · 实时同步所有线程、审批、插件、项目上下文； · 实时回传截图、终端输出、diff、测试结果、审批请求； · 文件、凭证、权限、本地配置始终留在原机器上，不上云。 技术架构：安全中继层 Codex 通过一个安全中继层让可信机器跨设备可达，而不直接暴露到公网；同时把活跃会话状态在所有登录 ChatGPT 的设备间保持同步。 OpenAI 在产品形态上选择了"云端中继 + 本地执行"的混合模型——既保留本地开发环境的安全边界与凭证隔离，又通过云中继获得跨设备的实时同步体验。这是企业级 AI 编程工具一个相对成熟的架构取舍。 OpenAI 演示的四个使用场景 1. 排队买咖啡：启动 bug 调查，Codex 复现、跑测试，需要授权时手机批准 2. 通勤途中：收到 Codex 的方案分叉决策请求，手机上选择路径，任务继续推进 3. 会议间隙：让 Codex 跨 Slack/邮件/文档汇总客户问题，准备 brief 4. 散步、午餐：灵感即时投递到新线程或现有任务，回到工位前已有初步进展

译OpenAI 在 ChatGPT 移动应用中推出 Codex 预览功能，用户可远程连接运行 Codex 的本地机器（如笔记本或 Mac mini）。通过安全中继层架构，系统能实时同步工作线程、审批请求与项目上下文，并回传截图、终端输出等结果，而所有文件与凭证均保留在本地，不上传云端。用户可在移动中启动任务、审阅输出或决策分叉，实现“云端中继+本地执行”的混合办公模式。目前该功能暂未支持 Windows 端。

Berryxia.AI@berryxia · 5月15日74

牛逼！Yetone 佬。

译开发者Yetone将一篇关于桌面应用开发“最佳实践”的文章转化为一个名为“native-feel-skill”的Agent Skill。该Skill旨在帮助开发者利用Coding Agent，轻松地重构或开发跨平台桌面应用，并使其获得极其接近Native原生应用的性能体验。项目代码已开源在GitHub上。

Berryxia.AI@berryxia · 5月15日69

Prime Intellect 最近把 AI 研究自动化推到了一个新阶段。 他们让 Claude Code（Opus 4.7）和 Codex（GPT 5.5）完全自主运行在 nanoGPT speedrun 的 optimizer track 上，使用闲置算力完成了约 1 万次实验，总计消耗 1.4 万 H200 小时。 最终结果：Claude Code 把记录推到 2930 steps，超过了人类基准的 2990 steps。 整个过程完全无人值守。 我看完他们的完整 thread 后，最有启发的部分是 agents 的实际表现： 它们在 optimizer 搜索、超参数扫描和方法 stacking 上非常高效，几乎把社区所有主流 PR 的思路（Contra-Muon、MuonEq、NorMuon、SOAP 等）都系统性组合了一遍。 但在 novelty（真正创新）上遇到明显瓶颈，当强制要求每个 idea 必须通过 novelty check 时，两个 agents 都没能超越 baseline。 Prime Intellect 把所有 scratchpad、运行日志、配置和生成的 idea 全部开源了，包括两个 agents 的完整实验记录。 这波操作把“AI 研究能不能自己跑”从概念变成了可复现的现实。 完整实验和代码在这里：https://github.com/PrimeIntellect-ai/experiments-autonomous-speedrunning

译Prime Intellect 近期在AI研究自动化领域取得重要进展。他们让Claude Code与Codex智能体完全自主运行于nanoGPT速度挑战的优化器赛道，利用闲置算力完成了近万次实验，消耗约1.4万H200小时。最终，Claude Code将记录提升至2930步，超越了2990步的人类基准。实验显示，智能体在系统整合社区主流优化方法、进行超参数扫描和策略组合方面效率极高，但在要求真正创新的“新颖性检查”环节未能突破基线。该项目将所有实验记录、日志和代码开源，使得AI自主研究从概念转化为可复现的现实。

meng shao@shao__meng · 5月15日67

xAI 发布 Grok Build CLI (beta) 面向编码、应用构建与工作流自动化的 Agentic CLI。现在仅向 SuperGrok Heavy 订阅用户开放，xAI 明确表示发布目的是借用户反馈迭代模型与产品本身。 产品地址：http://x.ai/cli 一行 curl 安装 产品定位与关键能力 · Fast & flicker-free CLI — 强调终端渲染性能，针对长会话与并行任务做了优化。 · Plan（计划视图） — 提供可视化的多步计划面板，便于在执行前审阅和调整复杂任务。 · Subagents（子智能体） — 支持并行派生研究、构建、审查角色，最多可同时跑 8 个智能体。 · Skills（技能） — 可装载的工作流偏好与领域知识，让 Agent 适配团队规范。 · Plugins / Marketplaces — 团队间共享能力的市场机制，意在形成生态。 · Q&A 主动澄清 — Agent 会在动手前主动追问细节，而非直接生成。 底层模型为 grok-code-fast-1，公开数据为 SWE-Bench Verified 70.8%，上下文窗口 256K。

译xAI 面向 SuperGrok Heavy 订阅用户推出了 Grok Build CLI 测试版，这是一个用于编码、应用构建与工作流自动化的智能体命令行工具。其发布旨在通过用户反馈迭代产品。该工具核心特性包括优化的终端渲染性能、用于审阅复杂任务的可视化计划视图、支持并行执行最多8个角色的子智能体系统、可装载团队规范与知识的技能模块，以及支持团队共享的插件市场。其底层模型 grok-code-fast-1 在 SWE-Bench Verified 基准测试中成绩为70.8%，上下文窗口为256K。

🚨 AI News | TestingCatalog@testingcatalog · 5月15日61

Manus 🤝 Similarweb Manus users can now access richer data from Similarweb to analyze their traffic and growth drivers.

译Manus 🤝 Similarweb Manus用户现可获取Similarweb更丰富的数据，用于分析流量与增长驱动力。 通过更多指标深入分析： • 关键词需求、难度、CPC及意图 • 品牌与非品牌搜索流量 • 引入+外链来源 • 自然与付费着陆页 • 任意域名下访问量最高的页面 随后利用Manus将研究转化为简报、仪表板、报告与演示文稿

ginobefun@hongming731 · 5月15日60

http://x.com/i/article/2055063165621374976 # BestBlogs 早报 05.15 · Claude Code 最佳实践 / GPT-Realtime-2 · AI 工具到 AI 体系的跃迁 在线阅读和收听：https://www.bestblogs.dev/explore/brief/2026-05-15 BestBlogs 新手注册和老用户领取 Pro 会员福利活动进行中，欢迎参与并定制自己的早报。 https://www.bestblogs.dev/pro EP57 · BestBlogs 每日早报 · 2026 年 5 月 15 日 今天这期早报的主线是：从工具到体系。Claude Code 官方公布了大型代码库最佳实践，Harness 的配置比模型分数更决定实际表现，新兴职能「Agent Manager」正在大型组织中落地。OpenAI 通过 Build Hour 深入解析 GPT-Realtime-2 的语音 Agent 架构，对话框正在跃升为自主「语音→行动」工作流。这期还有一个值得关注的真实困境：当 AI 把开发周期从月压到小时后，效率溢出带来的反而是协作方式的重构难题。 ## 导语 AI 编程工具进入大规模落地阶段后，一个关键认知正在浮现：模型能力只是起点，围绕模型搭建的整套工程体系才是决定上限的变量。 Anthropic 这次发布的大型代码库最佳实践指南，直接点破了一个常见误区——团队往往把精力集中在比较不同模型的 benchmark 分数，却忽视了 CLAUDE.md 配置、Hooks、Skills、MCP 等「Harness」层面的工程投入才是实际体验差距的真正来源。这不是一个理论观察，而是来自真实部署在百万行级 monorepo、数十个微服务 repo 上的经验总结。 语音交互领域同样如此。OpenAI 的 GPT-Realtime-2 带来了 GPT-5 级推理和 128k 上下文，但更值得关注的是它背后的架构演进：语音 Agent 已经从「聊天机器人」跨越到了「语音→行动」自主工作流，Sierra 实测延迟降低 30%–200%，这种量级的提升意味着企业语音服务的基础设施需要重新评估。会议场景、客服中心、实时翻译——这些场景的成本结构和体验边界都将随之改变。 flomo 联合创始人少楠的案例则提供了一个反直觉的视角：16 人团队 70%–80% 的代码由 AI 贡献，开发周期从「按月」压缩到「按小时」之后，真正的瓶颈不是工程效率，而是协作方式的重构。产品经理因为能直接验证想法反而提交的需求变少了，优秀的人变得更优秀，能力鸿沟反而在拉大。当效率不再是瓶颈，考验的是另一套能力：判断什么值得做，以及如何在没有传统约束的情况下保持组织协作的凝聚力。 三篇精讲从不同维度指向同一个问题：AI 带来的效率红利，最终会被组织结构和协作惯性消耗掉多少？ 今天速览还有明略科技吴明辉聊 AI 如何颠覆 SaaS、OpenAI 前 CTO Murati 对「永远在场」AI 的探索、阿里云 Skill Factory 的工程实践、OpenAI 13.1 万 GPU 网络的反直觉设计，以及 Codex 登陆 ChatGPT 移动端的最新动态。 ## 精讲一：Claude Code 在大型代码库中的运作方式：最佳实践与入门指南 | Claude Anthropic 官方这篇指南针对的是真实企业场景：百万行级 monorepo、跨越十余年的 legacy 系统、分布在数十个 repo 的微服务群。这类代码库的挑战不是规模本身，而是规模带来的上下文爆炸——如何让 Claude Code 在茫茫代码中准确定位、精准修改，而不是在 context window 里原地踏步。 Harness 和模型同等重要 指南最核心的观点可以用一句话概括：「影响 Claude Code 实际表现的，Harness 配置和模型能力同等重要。」这个论点打破了一种常见预设——很多团队在选型时把大量时间花在比较不同模型的 benchmark 分数上，实际上，两个使用相同模型但 Harness 配置差异显著的团队，体验可能判若云泥。 这里的 Harness 由五个扩展点构成，指南给出了清晰的优先级顺序： - CLAUDE.md 文件 — 每次会话自动加载的上下文文件，根目录放全局约定，子目录放局部规范。这是整套体系的基础，所有其他层都依赖它的质量。内容越聚焦、越准确，Claude 的定位速度越快。 - Hooks — 在 Claude 执行前后注入自定义逻辑，比如格式检查、lint 验证、自动提交、安全审查。它让 Claude 的行为与团队工程规范对齐，而不是每次依赖 prompt 提醒。 - Skills — 可复用的任务模板，把常见工作流封装成结构化指令。类似「为新增 API 端点生成测试用例」这类重复任务，Skills 比每次重写 prompt 更稳定。 - Plugins — 扩展 Claude Code 的底层能力边界，比如接入自定义的代码分析工具或内部知识库。 - MCP Servers — 连接外部工具和数据源，让 Claude 能访问数据库、调用 API、读取实时数据。这是 Claude Code 与企业既有工具链整合的关键接口。 指南特别强调这五个扩展点的顺序很重要：每一层都建立在前一层的基础上。在 CLAUDE.md 还不完善的情况下就去精心配置 MCP，效果会大打折扣。 LSP 与子智能体：两个容易被忽视的加速器 除了五大扩展点，指南还着重强调了两项附加能力： LSP（Language Server Protocol）集成实现符号级导航。传统的 grep 搜索在大型代码库中精度有限——它找到的是文本匹配，不是语义匹配。LSP 能让 Claude 精确跳转到函数定义、查找所有引用、理解类型层次，显著提升在陌生代码区域的探索效率。在 C、C++、Java 这类类型系统复杂的语言中，LSP 集成的收益尤为显著。 **子智能体（Subagents）**解耦探索与编辑。核心思想是：一个子智能体负责探索代码结构、收集上下文，另一个负责实际修改。这种分工避免了单个 Agent 在探索过程中把 context window 消耗殆尽——等到真正要写代码时，已经没有足够空间容纳准确完整的修改了。子智能体完成任务后只把最终结果返回给父 Agent，中间过程的 token 消耗不会传递。 为什么 RAG 在大型代码库中失效 指南对 RAG（检索增强生成）在代码场景局限性的分析值得特别关注。很多团队在引入 AI 编程工具时会考虑「把整个代码库向量化」的方案，Anthropic 明确指出了这条路在大型团队中的天花板。 问题核心是索引的时效性。向量索引需要预先构建，当工程团队在高速迭代时，索引的更新速度根本跟不上代码变更速度。Claude 检索到的可能是两周前已被重命名的函数、上个 sprint 已经删除的模块，而且检索结果本身不会告知你这个信息是否已经过期。在一个有几千名工程师并行提交的 monorepo 里，这个问题会被急剧放大。 Agentic 搜索（即 Claude 直接在 live 代码库中 grep、读文件、跟引用）规避了这个问题——没有索引需要维护，每个开发者的实例都在最新代码上工作。代价是需要足够的起始上下文，也就是说 CLAUDE.md 的质量直接决定 Claude 能否快速定位到正确的代码区域。指南建议：如果 Claude 需要在十亿行代码库里寻找一个模糊的模式，你会在工作开始之前就碰到 context window 限制。精确的起点比广泛的搜索更有价值。 「Agent Manager」这一新兴职能 在大型组织的落地案例中，指南观察到一个新角色正在涌现：Agent Manager。这个职能介于传统技术 Lead 和 AI 工程师之间，具体职责包括：维护 CLAUDE.md 的规范质量、审查和迭代 Hooks 配置、评估 Skills 的覆盖率和准确性、协调不同团队的 MCP 接入标准，以及管理多个 AI Agent 之间的协作边界。 这个职能的出现反映了一个现实：AI 工具的「基础设施」工作需要有人专门负责，否则很容易变成「每个人都在各自配置，没有人在系统性优化」的局面。指南特别提醒，每 3–6 个月应随模型迭代主动更新 Harness 配置——旧有的「规则」可能会约束新模型本已具备的能力，形成不必要的限制。随着 Claude 的能力持续演进，过度保守的 Hooks 和过时的 CLAUDE.md 有时候反而是性能瓶颈。 这篇指南对任何在团队中推广 Claude Code 的工程师或技术 Lead 都有直接参考价值。完整内容见 Claude Code 大型代码库最佳实践。 ## 精讲二：Build Hour 深解 GPT-Realtime-2：语音 Agent 如何从聊天迈向「语音→行动」 OpenAI 的这次 Build Hour 围绕 GPT-Realtime-2 展开，但内容远不止一个新模型发布——它实际上是在描绘语音 AI 应用架构的下一代形态。从「用语音问 AI 一个问题，AI 用语音回答」，到「用语音指挥 AI 执行一系列操作，AI 实时改变应用状态」，这是两个完全不同量级的产品体验 三款音频模型协同工作 OpenAI 这次推出的不是单一模型，而是面向不同场景的三款模型组合，每款都有明确的定位： - Real-time Translate：支持 70+ 语言输入、13 种语言输出，主打低延迟流式翻译。适合实时多语言会议、跨语言客服等场景，不需要最强的推理能力，但对延迟极度敏感。 - Real-time Whisper：延迟可调，最低可达 200ms，支持 80 种输入语言。这是对语音识别精度和速度的双重优化，适合需要快速响应但对下游推理要求不高的场景。 - GPT-Realtime-2：旗舰推理模型，带来 GPT-5 级推理能力，具备高质量工具调用性能，是真正实现「语音→行动」的核心模型。在 Big Bench Audio 上比前代提高了 15.2%。 这三款模型的组合设计思路值得关注：OpenAI 没有试图用一个模型覆盖所有场景，而是根据延迟需求、语言支持广度和推理深度做了明确分层，让开发者根据具体场景选择合适的「档位」。 三项关键技术提升 GPT-Realtime-2 相比前代有几项对开发者直接有用的改进： 首先是 128k 上下文窗口，是上一代的 4 倍。这意味着近一小时的完整对话可以保留在上下文中，不需要截断，长会话中的指令遵循也更稳定。对于需要记住复杂用户偏好、维护多轮任务状态的场景，这是实质性的提升而不是数字上的增量。 其次是前导语（Preambles）机制。当用户提问后，模型需要调用工具或进行多步推理时，可以先输出「让我查一下……」或「好的，我来看看……」这类过渡语，填补思考间隔。这个设计让语音对话的节奏更接近真实人际对话，避免了用户提问后遭遇令人不安的长时间沉默。 第三是逐轮 VAD 控制。VAD（Voice Activity Detection，语音活动检测）负责判断用户是否说完话、何时该模型开始回应。新版本允许开发者在特定对话轮次禁用 VAD，防止模型在输出关键内容（比如法律声明、合同条款、医疗建议）时被意外打断。这对企业合规场景来说是刚需。 Sierra 的企业实测数据 Build Hour 邀请了企业 AI 公司 Sierra 的工程师 Ken Murphy 和 Soham 分享实战经验。他们在企业客服场景下将 GPT-Realtime-2 与传统级联语音系统进行了系统对比。传统方案是「语音识别→文本处理→语音合成」三段式架构，每段都引入延迟，且各段的误差会叠加。 实测延迟降低幅度在 30% 到 200% 之间。区间跨度大的原因是不同业务场景的原始延迟基线差异很大，但即便是最保守的 30% 改善，对用户感知体验也已经是质的提升——语音交互对延迟的敏感度远超文本交互，因为人类对话中的节奏期望是内化的。 Sierra 同时强调了一个务实的观点：模型能力再强，生产环境中的稳健性仍然依赖「Agent Harness」——处理背景噪音、口音、中途打断、连接抖动等真实世界干扰的工程层。这与精讲一关于 Claude Code Harness 的核心论点形成了有趣的呼应：无论是编程助手还是语音助手，「Harness 和模型同等重要」这一判断都成立。 语音 Agent 的下一步 从这次 Build Hour 的演示来看，OpenAI 展示的电商场景（语音管理购物清单，按预算过滤商品，实时更新 UI 状态）和产品分析仪表盘（语音指令诊断移动端 bug，Agent 自主筛选复杂数据集）已经超出了「对话助手」的范畴，进入了真正的自主工作流领域。 用户说「帮我把购物车里超过 500 元的东西移出去」，Agent 不是返回一份建议清单，而是直接操作。这是「语音→文本→建议→用户确认→操作」到「语音→操作」的路径压缩。对于产品设计者来说，这意味着 UI 交互范式需要重新思考：哪些操作应该完全自主执行，哪些需要保留确认环节。 完整技术解析见 GPT-Realtime-2 Build Hour。 ## 精讲三：AI 让生产效率不再是瓶颈，然后呢？｜AI 跃迁者调研 02-flomo 少楠 如果说前两篇精讲是在讲「如何把 AI 工具用好」，少楠的这篇访谈则在追问一个更难回答的问题：当 AI 工具真的把效率拉满之后，真正的障碍是什么？ 少楠是 flomo 浮墨笔记和幕布的联合创始人，做了 11 年产品。这次访谈他分享了一个 16 人团队在 AI 让效率暴涨之后遇到的真实困境，以及 flomo 两个从「代码上下文里长出来」的新功能背后的设计过程。 转折点：命令行比 IDE 更适合产品经理 少楠从 GPT-3.5 时代就开始使用 AI，但长期卡在两个瓶颈：API 成本太高无法集成进产品，Cursor 的 IDE 界面对不写代码的产品经理来说过于复杂——「不小心关掉右边聊天窗口就找不到了，干脆放弃。」 真正的转折来自 Claude Code 的命令行界面。「没有复杂的 IDE，直接给口头指令。」他用它写了一个浏览器插件，能跑，额度从 20 美元充到了 200 美元。同期 DeepSeek V3 把 API 价格打下来，产品内终于也敢大规模用了。从今年开始，他们团队的 AI 渗透率才真正大幅提升：16 人团队，70%–80% 的代码由 AI 贡献，开发周期从「按月」缩短到「按小时」。 这个细节值得注意：对于不写代码的产品经理来说，「简洁的命令行界面」比「功能丰富的 IDE」更低的认知门槛，反而成了 AI 编程工具的入口优势。工具的易用性不是对所有人都意味着相同的东西。 一个反直觉的悖论：产品经理反而更少提需求了 少楠对所有产品经理提了一个新要求：提需求之前，必须先拿到代码库权限，在自己的分支上用代码把需求跑通，在真实数据库里拿到结果，再写 PRD 交给工程师上线。 这带来了一个意外效果。工程师效率提升了——把任务交出去，能开一堆 Agent 并行处理。但产品经理效率反而下降了——「你证伪自己想法的效率变高了，但最终交付产出的数量变低了。以前工程师烦死产品经理了，觉得需求太多；现在是产品经理不好意思提需求了。」 他举了一个典型案例：有用户说 flomo 应该做画板功能，可以拖拽连线。以前少楠直接 Pass，觉得需求太重不敢想。现在他吃晚饭前把想法丢给 AI，吃完饭回来一上手用，发现这是个伪需求——用户需要的是「看到笔记之间有联系」的感觉，而不是自己手动连线这个操作本身。以前只能靠逻辑推演，现在是亲自做出来之后发现不靠谱。验证速度提升了，最终交出去的需求质量也提升了——只是数量少了很多。 工程师那侧也在变化。Web 端做完一个功能，移动端工程师直接去代码库级别参考实现，不需要重新写 PRD，数据埋点有专门的 Skill 技能指令自动化完成。开发周期从「按周」计算变成了「按小时」计算。 AI 没有带来能力平权 少楠给自己团队打了 5 分（满分 10 分），理由直接：「速度上去了，但用户价值的挖掘没有同步提升。」他心目中的满分状态是从「上下游关系」变成「Peer 搭档关系」，像特战小组——四个人的小组能调动远程火炮，有非常清晰的职能分工，同时互相补位，而不是冗长的瀑布流。 更值得警惕的是他的一个核心判断：​「只有原来优秀的人，变得更优秀了。AI 没有带来能力平权，反而把鸿沟拉得更大。」 最会用 AI 的人往往最累，因为能力边界扩张后，优秀的人会自发承担更多。而不擅长使用 AI 的人，和擅长使用 AI 的人之间的效率差距不是在收窄，而是在急剧拉大。 协作方式的重构是最大的难点，不是工具本身。具体问题包括：谁来做 Code Review？怎么 debug 一段 AI 生成的代码？产品经理和工程师的协同边界到底变成什么样？职能边界在溶解——有的产品经理开始兼顾交互设计，有的设计师想直接 vibe coding 出效果，这些探索性的实验会抵消一部分执行效率。少楠自己也在和 vibe coding 的诱惑搏斗：「你的能力变强之后，天然地会想做更多的东西，跟抽烟一样，抽了一口就想抽第二口，两三个小时就没了。」 从代码上下文里「长出来」的功能 flomo 最近上线的两个 AI 功能很有意思——它们都不是从传统 PRD 流程来的，而是少楠在 Claude Code 里写着写着「碰出来的」： 认知地图：少楠想把 flomo 笔记的高维向量（1000 多维）压缩到二维平面看聚类效果。在和 AI 基于代码上下文讨论「这些小点点还能做什么」时，AI 提到了等高线。他一试，发现刚好契合脑子里「个人知识库是一张地图」的想象——等高线对应认知密度的起伏，还能以月为单位播放时间轴，看到自己哪个月在攀登哪个「认知山峰」。「想了很多年的一个东西，就这样上线了。」 AI 记忆：系统把用户所有 flomo 笔记按偏好、事实、事件三大类压缩提炼，生成一份「记忆文档」。把这份文档丢给 Claude 或 GPT，回答质量和个性化程度完全不同——因为 AI 知道你最近在关注什么、你的历史判断、你的角色。这是 flomo 最重要的大更新：长期主动记录积累的私有数据被彻底盘活了。目前只对 Max 会员开放，因为把用户所有笔记压缩两遍的算力成本「是非常惊人的」。 这两个功能的共同点是：它们不是从「用户访谈→需求文档→设计稿→开发」的传统流程来的，而是从「产品经理直接用 AI 工具探索代码实现」的过程中意外发现的。这本身就是少楠所说的「工作流变化」最具体的体现。 完整访谈见 flomo 少楠：AI 跃迁者调研 02。 ## 速览 当 AI「杀死」SaaS：多 Agent 网络与软件业转型 晚点聊 LateTalk 第 164 期邀请了明略科技创始人吴明辉，深度探讨 AI Agent 如何颠覆 SaaS 商业模式。核心论点是「闭源软件价值消失，从 Token 和模型上赚钱」。明略正在开源发布多 Agent 协同网络「章鱼」，通过集体学习机制实现指数级增长。吴明辉提出了「龙虾哲学」——用工程化的义务约束来代替无法约束大模型的道德框架。有 5 年前 AI 尝试失败经验的他，这次对 AI 转型的判断更为审慎和结构化。这期时长超过两小时，想深入了解 AI 对企业软件架构影响的同学值得完整听完。 OpenAI 前 CTO 带来的「永远在场」AI 原型 腾讯科技这篇论文解读深入分析了 Thinking Machines 发布的 Interaction Model。文章从传播学的三条件出发（共在性 Copresence、共时性 Contemporality、并发性 Simultaneity），诊断了当前 AI 交互系统的根本缺陷：AI 只在你主动输入时才「存在」，在你不说话时你的世界对它不存在。Thinking Machines 的方案是通过 200ms 微轮次心跳和统一多模态架构打破这一局限，实现真正「在场」的下一代交互。这篇文章与精讲二关于 GPT-Realtime-2 的内容形成有益互补，两篇放在一起读能更完整地理解「真正的实时 AI」意味着什么。 Skill Factory：三天搭一条技能生产流水线 阿里云开发者这篇实践分享介绍了基于测试驱动开发（TDD）理念构建的 Skill Factory。系统通过多路并行生成（同时调用 3 种不同策略的 Creator，相当于「买三张不同号码的彩票」）、自动化测试回归和生态适配，实现了标准化的技能生产流水线。多路并行的逻辑是：只要其中一路生成了高质量 Skill，整个任务就算成功，这极大提高了首次生成成功率。文章对正在规模化部署 AI Skill 生态的团队有直接参考价值，配合精讲一的 Harness 概念来读效果更好。 OpenAI 13.1 万 GPU 训练网络的反直觉设计 这篇 Towards Data Science 文章深入解析了 OpenAI 发布的 MRC（Multipath Reliable Connection）协议。这套协议颠覆了 30 年的网络惯例：禁用所有路由协议、主动接受丢包、将每次传输随机分散到数百条路径上。结果是在 13.1 万块 GPU 上实现了可预测的尾部延迟，以支持同步训练。文章最值得关注的发现是：MRC 实际上「消灭」了数据中心网络的整个第三层控制平面，没有 OSPF，没有 BGP，没有 IS-IS，交换机维护零动态转发状态。这在任何已公开的生产 AI 训练网络中都是前所未有的。对大规模分布式系统和网络架构感兴趣的工程师必读。 用 Evals 与五段式 Rubric 打造可靠 AI Agent 这个 AI Engineer 工作坊视频由 Arize AI 的 Laurie Voss 主讲，系统介绍了如何从「感觉对」走向「可测量」。核心框架是三层评估体系：代码 Evals（确定性检查，快速且便宜）、LLM-as-a-Judge（用更强模型评估语义质量，适合代码无法捕捉的质量维度）、人工评估（生成黄金数据集，是自动化评估器的「校准基准」）。五段式 Rubric 设计和 Meta-Evaluation（评估你的评估器本身是否靠谱）是两个关键实操技巧。想让 Agent 从实验阶段走向生产的团队必看。 只加两行代码，为什么要两天？ 腾讯云开发者这篇文章深入剖析业务系统复杂性的根本来源：功能间隐秘增加的耦合和不可避免的代码腐化。文章指出，随着系统功能增多，实现每个新功能不会越来越容易，而是越来越难——这与理想中「可复用性会降低边际成本」的预期完全相反。实际的 functionalities-cost 曲线是指数级上升的，不是线性的。文章对于理解 AI 辅助开发在复杂遗留系统中的真实效率边界很有帮助，和精讲三少楠案例中「协作方式的重构才是最大难点」的观点形成互补。 Codex 正式登陆 ChatGPT 移动应用 OpenAI 官方宣布，AI 编程智能体 Codex 现已在 ChatGPT 移动应用中开启预览。开发者可以通过手机启动新任务、审查输出结果、引导执行流程并批准后续步骤，而 Codex 会继续在笔记本或开发机上运行。这意味着开发者可以随时随地通过口袋设备管理正在进行中的编程任务，项目上下文和文件访问权限保持不变。这是一个典型的「分离关注点」的产品设计——执行仍在算力充足的设备上，监控和审批可以在移动端完成。 ## 扩展阅读 OpenAI Codex 负责人 Tibo Sio：Codex 如何进化为通用 Agent OpenAI Forum 的演讲视频，Codex 负责人 Tibo Sio 介绍 Codex 从云端开发者工具转型为本地运行的通用知识工作助手的路径：随着 GPT-5 的发布，Codex 将关注点从简单代码补全转向「长时任务」，即需要数小时乃至数天自主工作的复杂项目。视频中预告了面向长时任务的 Slash Goal 模式和安全护航的 Auto Review Agent。对关注 OpenAI Agent 产品演进方向的人值得看。配合速览中 Codex 登陆移动端的动态一起理解效果更好。 解锁连续批处理中的异步性 Hugging Face Blog 的 LLM 推理系列第二篇，讲解如何通过 CUDA 流和事件将 CPU 批次准备与 GPU 计算解耦，实现真正的并行执行，实测获得 22% 的推理加速。技术深度较高，适合需要优化 LLM 推理服务成本、尤其是在 H200 等高端 GPU 上跑生产推理的工程师。是对第一篇连续批处理文章的延伸，建议按顺序阅读。 GitHub Issues 导航性能现代化改造 GitHub 工程团队如何通过客户端缓存、预热（Preheating）和 Service Worker，将 Issues 页面导航延迟从「网络受限」变为「接近即时」。文章特别有价值的是方法论层面：先做流量分布测量（发现 57.6% 是 hard navigation），再针对主导路径优化，而不是只优化已经较快的 React soft navigation。HPC 百分位指标的改善数据具体详实。适合做前端性能优化或关注产品感知速度提升的工程师参考。 在 Zoox 加速 LLM 驱动的开发者生产力 Zoox AI 负责人分享通过构建企业 AI 平台 Cortex 系统化提升开发者效率的路径，涵盖安全 LLM 访问、RAG、智能体 API 和采纳率管理。从「新员工入职查文档靠猜」到「AI 无处不在，缺 AI 才感觉奇怪」的转变过程，有不少关于 AI 采纳率培育的实操细节。适合正在规划企业 AI 基础设施、需要参考大型工程团队实战案例的管理者和架构师。 ## 今日阅读路径 时间有限时，建议优先按以下顺序阅读： 第一优先：Claude Code 大型代码库最佳实践 如果你的团队正在推广或评估 Claude Code，这篇 Anthropic 官方指南有直接的实操价值。理解「Harness 和模型同等重要」这一核心论点，能避免在工具选型时只看 benchmark 分数而忽视工程配置的误区。五大扩展点的优先级顺序、LSP 集成的时机、子智能体的使用场景——这些都是容易踩坑的决策点。预计阅读时间 25–35 分钟。 第二优先：flomo 少楠：AI 跃迁者调研 02 这篇访谈提供的不是技术方案，而是一个真实团队在 AI 效率提升后遇到的组织挑战的第一手记录。「AI 没有带来能力平权，反而把鸿沟拉大」和「协作方式的重构是最大难点，不是工具」这两个判断，对任何在团队中推动 AI 落地的人都有很高参考价值。尤其推荐和 flomo 同量级的中小团队创始人和产品经理阅读。预计阅读时间 30–40 分钟。 第三优先：GPT-Realtime-2 Build Hour 如果你的产品涉及语音交互或实时通信，这个 Build Hour 值得完整看完。三款音频模型的定位差异、128k 上下文的实际意义、前导语机制和逐轮 VAD 控制的产品含义、Sierra 的企业实测数据——这些细节在正式文档中很难找到这么集中的呈现。预计视频时长 45–60 分钟，可以 1.5 倍速观看不影响理解。 BestBlogs 每日早报 · EP57 · 2026 年 5 月 15 日 · bestblogs.dev

译Anthropic发布Claude Code大型代码库实践指南，强调Harness配置（如CLAUDE.md、Hooks）与模型能力同等重要，是决定实际体验的关键，并指出RAG在高速迭代代码库中存在时效性局限。同时，OpenAI通过Build Hour解析GPT-Realtime-2，展示语音Agent正从聊天机器人演进为“语音→行动”的自主工作流。此外，当AI将开发周期从月压缩到小时，效率提升正引发协作方式与组织结构的重构难题。