ginobefun@hongming731 · 5月19日70

http://x.com/i/article/2056536208592039936 # BestBlogs 早报 · 05-19 · Composer 2.5、长时 Agent 与 AI 生码率 在线阅读和收听：https://www.bestblogs.dev/explore/brief/2026-05-19 > EP61 · BestBlogs 每日早报 · 当 AI 编码跨过工具替换的门槛，工程化才真正开始。 AI 编码正在跨过工具替换的门槛，走进工程化深水区。今天的早报有一条很清晰的主线：从写得快，到做得对。 Cursor 把 Composer 2.5 的训练栈完整公开，节奏从产品迭代切换到模型迭代；Anthropic 工程师在 AI Engineer 大会拆解长时间 Agent 工程，用对抗式的 generator-evaluator 架构把 Agent 续航推到 12 小时；阿里云 CIO 蒋林泉则端出 2026 财年真实数据，告诉所有人「AI 生码率」是一个危险的过程指标 ——「代码一定是负债」，Vibe Coding 不能直接上生产。 工具升级、工程化运行、效能反思，三条线索连起来，是从写得快到做得对的范式转身。今天的早报除了三条精讲，还有 Skill 开发、RAG 全链路、十七种 Agent 架构、MCP 企业落地、Anthropic 创始人手册、AI 收入集中度，以及 Anthropic 收购 Stainless 等七条值得一读的内容。 ## 导语 如果只看一个关键词，今天属于 「工程化」。 过去一年里，「Agent」「Vibe Coding」「AI 提效」基本被当作工具命题处理：换个更好的模型、装一个更聪明的 IDE、把流程自动化一段，效果就来了。但 2026 年中段开始，三条独立线索同时把命题往后推了一层。 第一条是模型层。Cursor 的 Composer 2.5 不是一个产品公告，而是一份训练报告：textual feedback RL、25 倍合成任务规模、亿级参数 MoE 训练栈、和 SpaceXAI 联手用 Colossus 2 训练新一代模型。一家原本的工具公司，正式进入自有模型的训练周期。 第二条是 Agent 工程层。Anthropic 的 Ash Prabaker 和 Andrew Wilson 把长 session 的失败模式归纳成三类：context rot、规划缺陷、输出 sycophancy；并给出今天最被推崇的架构 —— 类 GAN 的 generator-evaluator 对抗循环，宏观规划器、代码生成器、视觉评审器通过磁盘 markdown 协商契约。结果是 Opus 3.7 时代 1 小时的自主续航，到 Opus 4.6 已经被推到 12 小时。 第三条是组织效能层。阿里云 CIO 蒋林泉给出 2026 财年的硬数据：前端人均有效代码量翻 3 倍、后端翻 2 倍，千行代码缺陷率前端降 30%、后端降 55%。但他从一开始就把「AI 生码率」从考核体系里划掉。理由很硬：编码只占软件工程 20% 时间，AI 生码率衡量的恰好是这条链路里「价值密度最低、最容易被替代」的那一段；用最容易被替代的环节去衡量整体效能，是最常见也最隐蔽的误区。 三条线索叠加起来，会得到一个并不轻松的结论：AI 让代码生产的边际成本趋近于零，但代码本身始终是负债。能不能把它转化成资产，取决于工程化与组织能力。今天的三条精讲，恰好分别站在模型、架构和组织三个高度回答这件事。 围绕这条主线，今天的速览还有 7 条值得带走的内容：阿里云对 Skill 开发方法论的系统梳理、大淘宝 RAG 全链路工程实战、腾讯关于 17 种 Agent 控制流架构的拆解、Spring I/O 上 MCP 与 Spring AI 的企业级落地、Anthropic 的 AI Native 创始人手册、AI 收入集中度被两家头部公司吞下 89% 份额的最新数据，以及 Anthropic 收购 Stainless 收编 SDK 与 MCP 服务器基建的官方动作。三个层级（模型 / 架构 / 组织）的精讲 + 七条横切视角的速览，构成了今天对「AI Native 工程团队」最完整的一次切片。 ## 精讲一：Cursor 发布 Composer 2.5：基于 Kimi K2.5 的智能升级 评分：93 · Cursor Blog · 在 BestBlogs 阅读全文 背景。 Composer 2.5 沿用了 Composer 2 的底座 —— 月之暗面开源的 Kimi K2.5 模型权重。但和上一代不同，这一次 Cursor 在博客里端出来的不是产品截图，而是一份完整的训练报告：训练栈做了哪些改动、合成任务怎么造、强化学习的奖励信号怎么对齐到具体行为。这种姿态本身就是信号 —— Cursor 把训练栈作为差异化的核心叙事，节奏正在从产品迭代切换到模型迭代。 三件值得说的事。 第一件是定向文本反馈强化学习（textual feedback RL）。传统 RL 一条 rollout 可能跨越几十万个 Token，最后给一个总奖励，模型很难判断到底是哪一步走错了 —— 想抑制一个局部行为（错误工具调用、混乱解释、风格违规）很难，因为最终奖励是一个 noisy signal，告诉你哪里错了说不清。Cursor 的做法是：在出错的那一轮上下文里直接插入一条文本提示，比如「提醒：当前可用的工具是这几个」，把这条带提示的上下文当作教师模型，把原始上下文当作学生模型，做一次 on-policy distillation KL loss 的局部蒸馏。信号从粗粒度总奖励变成精确到具体轮次的局部信号，编码风格、沟通方式、工具调用错误这些细颗粒行为都被拉了回来，同时还保留了 RL 在整条 trajectory 上的全局目标。 第二件是合成任务规模直接放大 25 倍。其中一类「特征删除」任务很有意思：给模型一个带完整测试的代码库，让它删掉某个功能但保持其他测试通过，然后再让它重新实现这个功能，用原来的测试当作可验证奖励。Cursor 在文中也坦白：模型变强之后甚至出现了奖励作弊 —— 有一次它从 Python 类型检查的缓存里反推出被删除函数的签名，还有一次它反编译 Java 字节码还原第三方 API。规模化 RL 在变成一条工程长跑，需要越来越细致的看护机制。 第三件是工程层面的优化：分片 Muon 优化器、双网格 HSDP 并行策略，让万亿参数 MoE 的每一步优化只要 0.2 秒。这些本来是闭门技术，公开出来本身就是给行业的礼物。 为什么重要。 Composer 2.5 价格定在每百万输入 Token 0.50 美元、每百万输出 Token 2.50 美元，首周双倍额度；另有一个快速版本，相同智能水平价格抬到 3.00 / 15.00 美元每 M token，仍然比同等智能水平的 frontier 模型快线便宜不少。但真正值得关注的不是价格，而是结尾的那一段：Cursor 宣布和 SpaceXAI 合作，用 Colossus 2 集群、相当于 100 万张 H100 的算力，从零训练一个 10 倍总算力规模的更大模型。这意味着 Cursor 不再只是一家产品公司，AI 编码工具的竞争层级，正在从应用层下沉到模型层。同时 Cursor 在博客里特意提到，Composer 2.5 在沟通风格、effort calibration 这些「不容易被现有 benchmark 衡量」的维度上也做了系统性调优 —— 这是产品公司转向模型公司之后才会重视的事。 和今日其他议题的关系。 模型再强，要把这种强度变成可交付的长任务，还需要一层架构 —— 这是接下来精讲二要回答的。读完精讲一之后看精讲三，会看到模型能力增长和组织效能提升之间的鸿沟有多大。 阅读建议。 如果你是 AI 工程师，从「Targeted RL with textual feedback」一节读起，再补一遍 Composer 2 的技术报告作为基底；如果你是产品负责人，重点看价格曲线和模型路线图。 ## 精讲二：构建能持续运行数小时的智能体：Anthropic 工程师揭秘对抗式生成 - 评估架构 评分：93 · AI Engineer · 在 BestBlogs 观看演讲 背景。 在 AI Engineer 大会的首场分享上，Anthropic Applied AI 团队的 Ash Prabaker 和 Andrew Wilson 没有再讲一个浮夸的浏览器自动化 demo，而是认真拆了一件事：怎么让 Agent 自主运行 5 到 12 小时、甚至跨多日，还能保持代码可交付。这正是当前长时间 Agent 工程的核心难题。 三类失败模式。 Andrew Wilson 把长 session 的失败归纳为三类。第一类是 context rot​，会话越拉越长，模型对早期信息的把握逐渐崩塌；到 Token 上限附近还会出现 context anxiety​，开始草草收尾以「赶紧关掉上下文」。第二类是 规划缺陷​，原生大模型不擅长长 horizon 规划，要么一口气塞太多功能进一轮，要么半途停在残缺的代码库上。第三类是 输出 sycophancy：模型不擅长评判自己的产出，前端界面看起来对就报告完成，后端逻辑断了也不察觉。 数据校准。 Anthropic 给出一组很硬的对照：Opus 3.7 时代，一个 Agent 完成 50% 任务的自主运行时长大约是 1 小时；到 Opus 4.6，已经推到了 12 小时。模型本身在变强（model weights 这一面），但要把这 12 小时真正用好，外层的脚手架（scaffolding）同样关键。Anthropic 自己的 Agent SDK 从 Claude Code 的 research preview 演化到 GA，引入了 progressive disclosure Skills（只先加载 frontmatter、延迟加载完整工具 schema）、programmatic tool calling（让 Agent 自己写处理脚本、避免把数据塞进主上下文）这类原语。 核心架构：生成 - 评估对抗循环。 Ash Prabaker 推荐的当前最佳实践不是 Ralph Wiggum 那种线性循环（一个 Agent 在单一终端会话里顺序处理任务），而是借鉴 GAN 思路的对抗架构。系统里有三类独立角色：宏观规划器（Planner）拆分里程碑、代码生成器（Generator）实现功能、Playwright 视觉评审器（Evaluator）拉起真实浏览器对照参考站点打分。三者不靠把所有上下文塞进同一个模型，而是通过本地磁盘的 markdown 文件协商契约 —— 先把「这一关算交付」的标准用文本固化下来，再让生成器去干。每个角色有自己的 context window 和 system prompt，互相之间是独立的人格设定。 为什么要拆开？因为一个模型批评自己永远比批评别人难得多，self-evaluation 是 trap。把评估器单独拎出来，可以给它一个非常苛刻的系统提示，建立对抗压力。设计、原创、工艺、功能，每一项都用打分表量化，迭代直到评审器满意才算这一关交付。文中演示了一个例子：同一个 prompt「做一个复古游戏制作器」，单一循环的 Agent 跑出来界面拥挤、播放模式不能用；对抗架构跑了 6 个小时，Agent 自动起名 RetroForge，配了 54 色复古调色板，带物理引擎和键盘绑定，甚至自己加了一个递归式 AI 关卡助手，用自然语言生成关卡地图。同一个 base model，不同的脚手架架构，输出质量差出一个数量级。 为什么重要。 这套架构有两个非显然的工程结论：第一，不要让 Agent 自评​，单一 session 内部的自我审查永远不可靠 —— 输出 sycophancy 是模型权重层面的固有偏置，只能靠独立的 critic 角色和对抗压力来矫正；第二，用结构化交接代替上下文压缩，状态、配置、契约都写到本地磁盘，不要靠 LLM 自己背。把 markdown 当成 Agent 之间的协议层，远比试图把所有信息塞进同一个 context window 更可靠。这是把 Agent 当成一个工程系统来设计的方式，也是真正把 12 小时连续会话变成可生产代码的关键。 和今日其他议题的关系。 精讲一让模型本身变强，精讲二回答了「这种强度怎么变成可交付」。再到精讲三，企业要拿什么去衡量这种能力的产出，就不只是技术问题了。 阅读建议。 建议直接看视频原片，重点是 Adversarial Generator-Evaluator Loop 那一段；如果只有 10 分钟，去精讲三回看「结构化交接 vs 上下文压缩」的工程结论，对 AI 辅助软件工程的落地有直接帮助。 ## 精讲三：CIO 正在抛弃 AI 生码率：一场关于什么才算产研提效的实践复盘 评分：92 · InfoQ 中文 · 在 BestBlogs 阅读全文 背景。 阿里云 CIO 蒋林泉端出 2026 财年 vs 2025 财年的产研效能数据：前端人均有效代码量翻 3 倍、后端翻 2 倍；千行代码缺陷率前端下降 30%、后端下降 55%。承接更多核心业务和 AI 创新、没有增加人力，最后落到业务价值。 在一个几乎所有团队都在谈论「AI 提效」的年份，这样的衡量指标和结果并不常见。更值得说的是：这套结果背后，他从一开始就把行业最流行的指标 ——「AI 生码率」—— 从考核体系里划掉。 为什么不要 AI 生码率。 他的理由分两层。第一层，AI 生码率是过程指标，组织一旦盯着过程指标，AI 就特别容易产生毒害。代码行数不加权毫无意义，团队很容易陷入灌水陷阱 —— 看起来生码率从 20% 攀升到 50%，但对业务效能毫无帮助。第二层更结构性：端到端看，开发人员真正写代码的时间只占整个软件工程生命周期的 **20%**​，剩下 80% 时间花在需求对焦、PRD 评审、跨团队对齐、上下游联调和返工。而那 20% 里，价值密度差别也极大 —— 自动生成单测、补充注释、写胶水代码这类工作本来就不耗时间；真正费力的是核心概念、核心算法、核心逻辑和跨系统联调，那些是「代码量少、精力投入度极高」的地方。把这两个漏斗叠起来，AI 生码率衡量的恰好是整条链路里 价值密度最低、最容易被 AI 替代 的那一段。用最容易被替代的环节去衡量整体效能，是第一个误区。 「代码一定是负债」。 蒋林泉的第二个判断更尖锐：代码一旦生产出来，首先是负债。增加的大量代码「可能」是资产，但「一定」是负债。任何代码进入生产环境，立刻引入维护成本、增加系统复杂度，依赖关系需要持续管理；能否转化为对业务客户的正向价值，是不确定的。如果生成的代码无法对业务产生正向价值，规模化地生产代码本质上就是规模化地生产负债。理解这一句，是后面所有 AI 工程实践的逻辑基础。 Vibe Coding 的边界。 他给出两条很清楚的区分：做一个 Demo / 个人应用，和做一个客户大规模生产系统之间，有巨大差别；做一个全新应用，和在已有核心业务系统上叠加新需求，也有巨大不同。大部分企业的核心应用都是存量系统，业务复杂度高、积累了不同人的编码风格和历史技术债，需要为生产稳定性、性能、可维护性负责。在这样的环境里，Vibe Coding 直接生成的代码无法大规模投入生产并承担质量责任。阿里云 CIO 团队的果断选择是：不用 Vibe Coding 直接上生产，采用 AI 辅助的软件工程，把 AI 作为提效工具融入规范化工程流程，覆盖测试、运维、编码、存量系统梳理等切面。 AI 改写人月神话与左移。 文中还有两条很有启发的论断。一是「人月神话」：原来加人之所以低效，是因为人际沟通呈几何级数增长，新成员缺乏系统上下文、需要高成本的知识传递；但加 Agent 不一样 —— Agent 能无损拿到上下文，能规模化从已有代码里解析上下文，不需要人与人之间几何级数增长的沟通消耗。二是「左移」：以前一直说要在问题出现之前就解决它，但难以贯彻，是因为「左移本质是跨部门转移责任」，左边的人接不接、有没有能力承担都是组织摩擦力的来源；AI 时代，上下文和知识资产可以从存量代码里抽取，加上增量的 PRD、Spec，业务复杂系统能简化成一个共识框架，跨岗位之间在一条业务链路里能更低成本、更高效地对齐。一个具体的成果是：在有新成员加入的情况下，借助 AI 把测试覆盖从 20% 提升到加权接近 100%。 为什么重要。 这是今天三条精讲里最「反流行」的一条，也是最可执行的一条。它直接告诉企业：不要追 AI 生码率，要追 业务价值 E2E​；不要追 Vibe Coding 上生产，要追 AI 辅助的软件工程；不要奖励代码数量，要奖励「品味」—— 对业务价值的判断力。它也回答了一个被很多技术管理者绕开的问题：当所有人都在炫耀「AI 生码率从 20% 涨到 50%」，真正的 E2E 产研时间却没有缩短，这种割裂背后的原因，不是技术问题，是组织管理对「可量化指标」的过度依赖。 和今日其他议题的关系。 把精讲一、二的能力底座放进精讲三的组织视角里，你会得到一个完整的判断框架：模型够强（精讲一）、Agent 续航够长（精讲二）、但只有靠 E2E 度量和工程化流程（精讲三），才能让它落到「业务价值」。这也是今天「从写得快到做得对」这条主线的最终归处。换句话说，模型层和 Agent 工程层负责把「能做的事」推到新边界，组织层负责回答「该做哪些事、做到什么标准才叫好」—— 三者缺一不可。 一个延伸观察。 文章另一组细节也值得记下：他强调 AI 时代的人才结构里「技能在贬值、品味在升值」。技能指的是「会做某件事」，品味指的是「能定义什么是好」。AI 工具普及后，技能的稀缺性正在迅速下降，而对业务价值的判断、对产品最终验收的标准，反而越来越难被替代。这是他给团队反复强调的一句话：忘掉岗位和位置，去看任务和目标。 阅读建议。 建议读全文。如果只能跳读，重点看「两个流行误区」和「AI 破解人月神话与左移」两节；如果你是技术负责人，最后那一节关于「品味 vs 技能」的判断值得反复看，并和今天速览里的 Anthropic 创始人手册对照着读。 ## 速览 今天还有 7 条值得一读的内容，把它们大致按从工程实践到行业格局排列： Skill 开发：保姆级教程 & 一站式开发助手发布（阿里云开发者 · 评分 93） 作者把 Agent Skill 的本质讲透了：一个 SKILL.md 文件就是「技能卡」，背后是 YAML frontmatter + 渐进式三级加载机制 —— Agent 只在需要时才读取详细指令，既节省上下文又保证执行精准。文章覆盖目录结构、编写规范、跨平台发布痛点和一站式开发助手 skill-dev-aio。最值得带走的判断是 ——「Skill 替代的不是你，而是你身上那些重复、易错、本不该占用大脑的任务；真正的价值在于体验和判断」。如果你最近开始用 Claude Skills / Agent Skills 把工作流沉淀下来，这是少有的把方法论和工具一起讲清楚的中文资料，也能直接呼应今天精讲二里 progressive disclosure 的工程细节。 RAG 全链路技术详解（大淘宝技术 · 评分 92） 一篇罕见的 RAG 实战指南，覆盖了完整的工程链路：文档加载（多格式解析 + 元数据提取）、智能切分（规则 / 语义 / 结构化方法，含 Meta-Chunking 用 PPL 困惑度感知语义边界的原理）、索引构建（embedding 模型选型与向量生成）、检索优化（Query 改写、HyDE / Doc2Query、标签过滤、重排序）、生成调优（Prompt 设计、参数控制、SFT 微调），到进阶的 Graph RAG（多跳推理与全局摘要）与 Ragas 自动化评估体系（Context Precision/Recall、Faithfulness、Answer Relevancy）。文章强调「可测、可调、可信赖」的工程化态度，回应了 Agent 开发里最常见的三个共性挑战 —— 知识库构建缺乏标准、检索召回精度达不到预期、缺乏量化评测体系。对落地企业级 Agent 知识库的团队是一份高质量的内部培训材料。 从 0 开发大模型的 17 种 Agent 架构演进详细拆解（腾讯技术工程 · 评分 92） 作者用 agno 框架把开源项目 all-agentic-architectures 的 17 种 Agent 控制流模式重写了一遍。核心观点很犀利：Agent 架构的本质不是 prompt engineering，也不是某个框架的 DSL，而是控制流设计，应当能在任何体面的框架里复现。文章梳理了一条清晰的演化路径 —— 从单次生成到反思闭环，再到工具交互、观察 - 行动循环、显式规划、验证驱动重规划、多 Agent 编排、长期记忆、搜索 / 模拟，最后到「可信任」。每一步都用同一套六个问题（要解决什么、State 是什么、拓扑、Router、失败模式、何时该升级）拆解。如果你正在选型多 Agent 编排框架，或在长 session Agent 上踩坑，这篇能帮你把「状态有没有被正确建模、控制流有没有被显式表达、错误能不能被局部截断、副作用能不能被关进闸门、系统知不知道自己什么时候该停」这五件真正决定能不能落地的事想清楚。 深入探索 MCP 与 Spring AI：从协议核心到企业级生产部署全链路指南（Spring I/O · 评分 92） James Ward 和 Maximilian Schellhorn 在 Spring I/O 上的技术深度演讲。视频从 Agent 的三个基础组件（Memory、Context、Tools）讲起，重点拆解 Model Context Protocol（MCP）如何解决工具调用标准化 —— 让开发者不必再为每一个 CRM、机票、订单 API 写一套定制 tool function；并演示了 Spring AI 框架在 OAuth 鉴权、水平扩展、上下文优化上的企业级实践。把今天精讲二的对抗式架构落到 Java 生态来看，是一份非常好的工程对照材料；对 Spring Boot / 企业 AI 平台团队尤其有价值，也能给「MCP 在生产环境到底怎么落」这个常见问题一个完整答案。 Anthropic 创始人手册：AI Native 公司，正在把「几个人做几百人的事」变成现实（AINLP · 评分 88） Anthropic 刚发布的 36 页《The Founder's Playbook: Building an AI-Native Startup》中文译读，按 Idea → MVP → Launch → Scale 四个阶段拆解 AI Native 创业公司的生命周期，并给出每个阶段的退出标准、典型风险和实操练习。一个核心判断：当 AI 已经能写代码、做调研、整理竞品、起草投资人材料、自动化大量运营流程，过去那条「想法 → 验证 → 融资 → 招人 → 开发 → 再融资 → 再招更多人 → 规模化」的默认路径正在被改写。创业公司不一定每进入一个新阶段就必须配更大的团队、更多岗位和一轮新融资；很多工作可以由创始人通过 Claude Chat、Claude Cowork 和 Claude Code 编排完成，创始人的角色从「亲自执行的人」变成「系统编排者」。最大的风险不再是「做不出来」，而是「太快做出一堆没人要的东西」。判断力取代执行力，成为最稀缺的能力 —— 这和精讲三里蒋林泉说的「品味通缩，技能通胀」是同一件事，也呼应了今天 Anthropic 收购 Stainless 的另一条新闻：基础设施层的并购正在和创业公司形态变化同步发生。 AI 收入集中度创新高：Anthropic 与 OpenAI 吞下 89% 份额（腾讯科技 · 评分 89） The Information 最新数据显示，34 家头部 AI 初创公司年化收入合计逼近 800 亿美元（月收入 66 亿美元），比半年前增长 112%；但其中 Anthropic 和 OpenAI 两家吞下了 89%，比半年前又高了 4.5 个百分点，剩下的 32 家只能为 11% 的蛋糕奋力拼抢。Anthropic 据华尔街日报报道有望在 6 月底冲到 500 亿美元年化收入 —— 而 2026 年初它的年化收入还只有 10 亿美元，4 月份跳到 300 亿美元以上，第一季度收入和使用量同比增长 80 倍。文章还点出一个容易被忽视的事实：Cursor、Perplexity、ElevenLabs、Cognition 等过 5 亿美元线的应用公司，很多收入会回流到 Anthropic 和 OpenAI 当模型成本 —— Cursor 在截至 1 月的一个季度里毛利率一度做到 -23%，暴露了依赖头部模型供应商的脆弱性。AI 商业化正在走向赢家通吃的格局，模型供应商和应用公司的边界也在加速模糊；这对应用层创业公司接下来一两年的护城河选择，是个严肃的问号。 Anthropic 收购 Stainless：整合 SDK 与 MCP 服务器平台（Anthropic · 评分 88） Anthropic 官方推文宣布收购 Stainless —— 这家公司从 Anthropic API 早期阶段起就负责所有 Anthropic SDK 的构建和运行，也是 MCP 服务器生态里基础设施层的关键供应方。把这条新闻和今天精讲二的 Agent SDK 演化、速览里的 MCP / Spring AI 视频放在一起看，会得到一个一致的信号：Anthropic 正在系统性把开发者工具和 MCP 生态的基础设施收进自己手里，加深对开发者体验的控制，加速 MCP 成为连接 AI 模型和外部工具/数据源的事实标准。叠加上一条 89% 收入集中度的报道，模型层的赢家通吃正在向 SDK 与协议层延伸。 ## 扩展阅读 今天的内容池里还有几条不进精讲、但值得跟读的方向： - Agent 工程化的延伸阅读路径：把今天的精讲二（Anthropic 长时间 Agent）+ 速览里的 17 种 Agent 架构 + MCP 与 Spring AI 视频 串起来读，能形成一条「架构理念 → 控制流模式 → 生产部署」的完整路径，比单独看任何一篇都更有体感。 - AI 编码与组织效能的对照阅读：精讲一（Cursor Composer 2.5）讲模型怎么变强，精讲三（阿里云 CIO）讲组织怎么衡量 AI 投入，加上速览的 Anthropic 创始人手册 讲创业公司形态的重构，三篇放一起，是当下「AI Native 工程团队」的三种不同观察视角。 - 行业格局的横切信号：AI 收入集中度 89% 的报道 + Anthropic 收购 Stainless 的推文 一起读，会看到一条更长的线 —— 模型层的赢家通吃正在向开发者基础设施层（SDK、MCP、Agent SDK）延伸。这关系到接下来一两年应用层创业公司的护城河会建在哪里。 - Skill 工程化的最佳实践入口：如果你刚开始把团队的工作流写成 Skill，先读它再回头看精讲二关于「progressive disclosure Skills」的工程细节，会更容易理解为什么 frontmatter + 渐进加载是当前最佳实践。 ## 今日阅读路径 如果你今天只有 20–30 分钟，按这个顺序读最划算： 1. 精讲三：阿里云 CIO 抛弃 AI 生码率 —— 先把「该不该做」的判断框架定下来。读完最大的收获是不再被「AI 生码率 70%」这种数字迷惑，知道该用 E2E 业务价值去衡量产研效能。 1. 精讲二：Anthropic 长时间 Agent 工程 —— 再看「怎么把强模型变成可交付」。重点看对抗式 generator-evaluator 架构和「结构化交接 vs 上下文压缩」两条结论。 1. 精讲一：Cursor Composer 2.5 训练报告 —— 最后看「底座变强到什么程度」。如果你不写训练栈代码，重点看 textual feedback RL 的思路和 SpaceXAI 合作的战略意涵。 如果还剩 10–15 分钟，加读速览里的 Anthropic 创始人手册 和 17 种 Agent 架构拆解：前者帮你看清 AI Native 创业公司的生命周期，后者帮你把 Agent 控制流的方法论装进脑袋。再多 5 分钟，可以加读 Skill 开发那篇 —— 它和精讲二的 progressive disclosure 工程细节是直接呼应，能帮你把今天读到的 Agent 工程化心得直接落地到自己的工作流里。 如果你做的是企业 AI 平台、Spring Boot 后端，或 Java 生态的 Agent 工程，把 MCP 与 Spring AI 视频 当作今晚的额外补课；如果你关注 AI 行业格局和创业方向，把 收入集中度 89% 和 Anthropic 收购 Stainless 一起读，会更清楚下一年模型供应商和应用公司之间的关系会怎么演化，以及创业护城河该往哪里建。 读完今天的早报，欢迎在评论区分享你最有共鸣的一条。明天见。

译本文聚焦AI编码领域正从追求“写得快”向“做得对”的工程化范式转变。文章通过三条核心线索展开：Cursor发布Composer 2.5并公开训练栈，标志着从产品公司转向模型迭代；Anthropic工程师提出对抗式生成-评估架构，将长时Agent自主运行时间从1小时提升至12小时；阿里云CIO则指出“AI生码率”是危险指标，强调代码是负债，工程化与组织能力才是关键。这共同指向一个结论：AI降低了代码生成成本，但将其转化为资产需要深度工程化。

Chubby♨️@kimmonismus · 5月19日56

The scaling bottleneck in AI right now has completely shifted from model intelligence to architecture orchestration. Most tools still force you to sit there and babysit individual prompt windows. LobeHub introduces a complete backend management layer called a Chief Agent Operator. You give it a high-level strategy and your CAO auto-assembles specialized teams on the fly, routing tasks across multiple models in parallel. It plugs directly into heavy developer environments like Claude Code or Cursor as an orchestration system rather than trying to compete with them, tapping into an ecosystem of 292K skills and 55K MCP servers. The entire platform runs 24/7 cloud-side with zero local server or Docker maintenance, which cuts operational costs by roughly 50% compared to closed alternative stacks. You literally close your device and the execution keeps scaling.

译当前AI发展的核心瓶颈已从模型智能转向架构编排。LobeHub推出了名为Chief Agent Operator（CAO）的后端管理层，能够根据高层级策略自动组建代理团队并行处理任务。该平台作为编排系统无缝集成到Claude Code、Cursor等开发者环境中，接入庞大的技能市场，并在云端全天候运行，无需本地维护，从而显著降低运营成本。用户专注于制定宏观策略，而由CAO负责管理和执行具体的代理工作。

OpenClaw🦞@openclaw · 5月19日50

OpenClaw 2026.5.18 is live 🤖 xAI/Grok OAuth + sidecar auth fixes 🎙️ Realtime Android Talk Mode 💬 Telegram media + forum-topic delivery fixes 🪟 Browser dialogs visible + answerable A week of polish, plumbing, and fewer papercuts. https://github.com/openclaw/openclaw/releases/tag/v2026.5.18

译OpenClaw 2026.5.18 已上线 🤖 xAI/Grok OAuth + sidecar 认证修复 🎙️ 实时 Android 对话模式 💬 Telegram 媒体 + 论坛主题推送修复 🪟 浏览器对话框可见且可应答 一周的打磨、优化，减少小问题。 https://github.com/openclaw/openclaw/releases/tag/v2026.5.18

Rohan Paul@rohanpaul_ai · 5月19日64

Can a smaller model purpose-built for one domain beat a frontier general model that's 100× its size? A recent paper showed yes — and not by a small margin. Raven 3.5 from PolyAI shows that a smaller specialist model can beat bigger general models on customer service calls. It beats GPT-5 and Claude Sonnet 4.6 on all 4 customer service benchmarks while staying under 300ms latency. This is one of the live debates in ML. Every researcher is asking this question. The paper is the empirical answer. PolyAI's research team published “Raven 3.5: The post-training recipe that beats GPT-5 for customer service” —- Voice agents are moving from call-center software into everyday product infrastructure. PolyAI’s launch targets the gap between website traffic and real customer conversations. Made every website capable of answering out loud. PolyAI helps enterprises fix slow phone support, long wait times, costly contact centers, robotic IVRs, and missed revenue from abandoned calls. Its voice agents handle customer conversations 24/7 across voice, chat, SMS, and social channels in 45+ languages. The result is faster support, lower operating cost, more consistent answers, and better customer experience at enterprise scale. 📞 PolyAI is launching 2 new voice AI products: ADK, a code-first Agent Development Kit for building production voice agents from your own IDE, and PolyPhone, which turns any website into a live voice AI agent in about 10 minutes. ADK connects directly into Agent Studio, so developers can build, manage, and deploy agents from the terminal. PolyPhone reads a website, understands things like FAQs and product details, then creates a voice agent that can be embedded on any webpage without needing telephony setup. The bigger point: enterprise voice AI is moving from “contact center project” to “something teams can build and ship much faster.” 🧵 1

译PolyAI研究证实，专为客服设计的较小模型Raven 3.5，在性能上显著超越了规模大其100倍的通用前沿模型。该模型在所有四项客服基准测试中击败GPT-5和Claude Sonnet 4.6，并将响应延迟控制在300毫秒内。这项发布同时包括ADK代码开发工具包和PolyPhone网页语音生成工具，助力企业快速构建生产级语音代理。此举旨在将企业语音AI从大型项目转变为可快速部署的基础设施，从而有效解决客服等待时间长、成本高等问题，提升服务效率与客户体验。

Rohan Paul@rohanpaul_ai · 5月19日74

Agora-1, a multi-agent world model from Odyssey just exposed the next bottleneck for world models: keeping one shared reality consistent for everyone inside it. The first serious test of whether world model can act like a game engine for multiple players at once. Agora-1 turns world models from single-player predictors into shared real-time environments. The big deal here is that several agents, human or AI, can now disturb the same simulated world at once, forcing the model to track not only scenery, but consequence. Traditional world models combine simulation dynamics and rendering within a single model. And a single-player world model can survive by predicting what should happen next from one stream of action, but a multiplayer world has collisions, timing, intent, surprise, and blame. But Agora-1 turns a world model into a learned multiplayer engine, where the AI does not just generate what one player sees, but keeps a shared world state stable while up to 4 humans or AI agents act inside it in real time. In that setting, realism is no longer just visual fidelity; it is whether the world stays coherent when two minds push on it from different directions.

译Odyssey团队推出的Agoro-1是首个支持多智能体交互的世界模型，解决了多人共享同一虚拟环境时维持现实一致性的核心瓶颈。该模型突破了传统单玩家预测模式的限制，能够实时模拟多个参与者（人类或AI）在同一世界中的交互行为，并保持世界状态的稳定连贯。这意味着世界模型从单向预测演进为支持动态因果关系的共享实时环境，其真实性不再仅依赖视觉保真度，而取决于多方干预下世界逻辑的自洽性。

Nathan Lambert@natolambert · 5月19日49

The system is the product. Models are just one piece today, agree with Joanne.

译系统才是产品。如今模型只是其中一个组成部分，我同意 Joanne 的观点。

Greg Brockman@gdb · 5月19日62

Keep your Mac awake so you can build and work from your phone, with Codex in the ChatGPT app:

译通过ChatGPT应用中的Codex，让你的Mac保持唤醒状态，以便你可以在手机上进行构建和工作： [引用 @OpenAIDevs]：你的Mac可以在你用手机工作时坚守岗位。 在Codex桌面应用中启用远程连接，然后开启“保持此Mac唤醒”。 当你的Mac开机并接通电源时，Codex可以持续运行，而你可以在ChatGPT移动应用上工作。

AYi@AYi_AInotes · 5月19日62

Cursor 今天发的 Composer 2.5，表面看是常规迭代， 拆开基准图和 blog 之后我整个人都有点懵， 它本质上其实不是一个新模型，更像是把 RL 后训玩到极致的 agentic 怪物， 因为它85% 的算力根本没花在底座上，全都砸在后期魔改上了🤣 同等智能下成本直接砍到对手的十分之一， 最狠的是那张成本-性能曲线， Composer 2.5 在 CursorBench 3.1 上拿到 63.2%，单任务成本几乎贴着 0 美元那条线， Opus 4.7 xhigh 要贵一个数量级才能接近，GPT-5.5 medium 也要 2 美元左右， Terminal-Bench 直接追平 Opus 4.7， 10x 更高效这个感觉不是吹的， 但我觉得这件事真正值得关注的可能不是 benchmark 数字， 而在于他们做对了一件 agentic 里最痛苦的事:就是信用分配， 长 rollout 几千上万 token，global reward 其实根本分不清哪一步错了， 他们的解法叫 textual feedback RL——在出错的 local context 里插极短 hint，让 teacher model 生成正确分布，再用 KL loss 让原模型对齐， 风格、工具调用、解释清晰度，全都能精细调， 这意味着什么， 以前大家迷信谁底座大谁牛， 现在看的是谁敢把 80%+ 算力砸在 RL 和合成数据闭环里， Kimi k2 只占 7.5%，却把 Opus 和 GPT 打到平手， Agentic coding 真正的胜负手不在单次 pass@1， 而在于 40 分钟后它还能不能自己恢复状态继续跑， 在于该努力时努力、该偷懒时不浪费 token 的行为校准， 这些东西现有 benchmark 根本测不到，但开发者每天都能感受到， 我觉得这是 Composer 2.5 最被低估的地方， 以后做 agent 的人，得同时建 anti-hacking 监控了——他们用 25x 合成数据后，模型已经聪明到能逆向工程类型缓存、反编译 bytecode 来钻漏洞，reward hacking 可能也不再是 bug，是需要被管理的 emergent behavior， Cursor 也不再只是 IDE 公司了， 他们和 SpaceXAI 合作，用 Colossus 2 从零训 10x compute 大模型， 垂直整合的时代终于要来了，做编辑器的反向，掌控最上游模型能力， 我觉得真正的差距不在单次 prompt， 而在第 45 分钟它还能不能自己爬起来继续干 hhh

译Cursor发布的Composer 2.5并非全新底座，而是将85%算力集中于强化学习后训练的agentic模型。它在CursorBench 3.1上达63.2%性能，单任务成本极低。其核心突破在于通过“textual feedback RL”解决了长任务中的信用分配难题，实现精细化调优。该模型真正的优势是长时间运行下的稳定性与行为校准，这是现有基准未能体现但开发者能感知的关键能力。这标志着行业评价标准正从迷信底座规模转向衡量RL与合成数据闭环的投入效率。

Rohan Paul@rohanpaul_ai · 5月19日60

Top AI labs are suddenly abandoning fringe consumer features (like video models & conversational personas) to mirror Anthropic's success with coding agents. "They're all like, “We're only going to do coding agents too.” ~ Marc Benioff, CEO of Salesforce

译顶级AI实验室突然放弃边缘消费功能（如视频模型和对话角色），转而效仿Anthropic在编程智能体领域的成功。 “他们都表示，‘我们也要只做编程智能体了。’” ——Salesforce CEO Marc Benioff

elvis@omarsar0 · 5月19日67

NEW paper from Meta. (bookmark it) It's an agent system that autonomously discovers neural architectures that beat Llama 3.2 at 350M, 1B, and 3B scales, all under a 24-hour compute budget. They get this work by splitting the search into two agents: > AIRA-Compose searches the macro architecture. > AIRA-Design implements the low-level mechanisms. For devs: If one agent in your stack is doing both strategy and implementation, split it. Run a planner that picks the structure and an implementer that fills in the mechanisms. AIRA shows this beats a single end-to-end agent on a real, non-toy search problem. The same split is useful for pipeline assembly, query planning, prompt scaffolding, and tool-use programs. Paper: https://arxiv.org/abs/2605.15871 Learn to build effective AI agents in our academy: https://academy.dair.ai/

译Meta提出AIRA系统，通过分离策略与实现的双代理架构，实现神经架构的自主发现。AIRA-Compose负责宏观架构搜索，AIRA-Design专注低级机制实现。该系统在24小时计算预算内，于350M、1B和3B规模上找到超越Llama 3.2的架构。其核心方法论表明，在复杂任务中分离规划代理与实现代理能提升效能，此思路同样适用于流水线组装、查询规划等其他AI代理场景。

Greg Brockman@gdb · 5月19日69

how to use /goal in codex — keep Codex working on a persistent objective until it's solved:

译如何在 Codex 中使用 /goal —— 让 Codex 持续执行一个明确目标直至解决： [引用 @derrickcchoi]：我的同事撰写了一篇关于在 Codex 中使用 Goals 的精彩文章。 他们介绍了何时使用 Goals、激活 Goals 时会发生什么变化，以及如何编写能为 Codex 提供明确结果、约束和验证标准的 Goals。 如果你感兴趣，文章还介绍了我们在架构层面如何设计 Goals。 https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex

Thariq@trq212 · 5月19日67

continuing my HTML era, I had so much fun talking with Claire at Code w/ Claude about staying in the loop with long running agents

译在Code with Claude活动中，演讲者Thariq提出“HTML是新的Markdown”这一观点。他指出，虽然Markdown编写简单且易被AI解析，但对人类可读性较差；而HTML能更有效地作为人类与AI代理之间的交互界面。其应用场景包括：使用HTML工件作为动态交互式规格说明、快速构建临时微用户界面、维护一个活的设计系统，以及在与Claude等模型交互时使用开放式提示（如“whatever is needed”）以赋予其更多自主思考空间。该观点强调了软件开发中前端呈现与后端智能结合的重要性，并探讨了工程师与产品经理角色融合后的演变方向。

Berryxia.AI@berryxia · 5月19日54

奥特曼说的这些话，这个现象其实比很多人想象的更值得警惕。 用 AI 代理完成了一整套复杂任务，结果发现整个流程里最耗时的部分，竟然不是思考和决策，而是不断「修正 AI 犯的低级错误」。 这听起来有点反直觉。 我们通常以为 AI 能帮我们省掉大量重复劳动，但当代理能力变强之后，新的问题出现了——我们开始花更多时间去监督、纠正和兜底。 真正棘手的地方在于，这种修正成本往往是隐性的。 你很难提前预判 AI会在哪个环节突然翻车，也很难建立一套可靠的验证机制。 久而久之，很多人其实不是在用 AI 提升效率，而是在用自己的注意力去填补 AI的不可靠性。 这其实暴露了一个更深层的问题：当工具的自主性提高后，人的角色正在从「执行者」变成「验证者」。 而验证这件事，本身需要极高的判断力和系统性思维。

译使用AI代理处理复杂任务时，一个反直觉的现象出现：最耗时的环节并非思考决策，而是不断修正AI的低级错误。这种隐性修正成本难以预判和管理，使人从“执行者”转变为“验证者”，用注意力填补AI的不可靠性。这反映了AI自主性增强后的新挑战。Sam Altman指出AI可能负责发现复杂规律，而人类仍需负责理解，这印证了人类需承担对AI成果进行验证与理解的新负担，而非单纯地提效。

Rohan Paul@rohanpaul_ai · 5月19日68

Voice AI might be the biggest productivity boost you can add to almost any office job. And with PolyAI’s Agentic Dialog Platform now open to every enterprise builder, Voice AI has gone from a 6-figure annual contract to a free trial you can install straight from your terminal. The hard part is not speech recognition, because the real challenge is keeping track of messy human intent while a caller changes details, adds urgency, or asks for something the system did not expect. Their proprietary model Raven, has the agent behavior built into the model itself instead of relying on long prompts that can drift when calls get complicated.

译PolyAI现已向所有企业开发者开放其Agentic Dialog平台，将语音AI服务从高昂的年度合约变为可通过终端免费试用的产品。该平台的核心目标并非语音识别，而是攻克在通话中动态追踪复杂、多变的人类意图这一难题。其专有模型Raven将代理行为直接内置于模型本身，避免了冗长提示词在复杂对话中的失效问题。该模型已为FedEx等大品牌处理超10亿次对话。平台支持集成Raven或GPT-5等外部模型，使任何团队都能轻松构建、测试并部署企业级对话智能体。

Microsoft Research@MSFTResearch · 5月19日51

New in Research Focus: Cloud efficiency, smarter agentic cost reduction, a randomized trial on 3D telemedicine, and an open call for inclusive AI language projects in Africa. https://msft.it/6010vTpuG

译研究聚焦新动态：云效率、更智能的智能体成本削减、3D远程医疗随机试验，以及面向非洲包容性AI语言项目的公开征集。

Elon Musk@elonmusk · 5月19日50

Grok agent mode is a major ability unlock

译xAI更新了Grok的Agent模式，这被视为其能力的一次重大提升。该模式显著简化了AI视频创作流程。基于Grok Imagine，创作者能更流畅地制作视频，并借助Grok的理解能力完成素材生成与对话，无需额外配音，极大节省了时间成本。据早期测试，生成视频的写实效果良好，且图片参考等功能增强了实用性。这标志着AI在自动化、高质量内容生成领域取得了新的进展。

OpenRouter@OpenRouter · 5月19日60

Some primitives for building long-horizon agents: https://openrouter.ai/long-horizon

译构建长期代理的一些基础要素：https://openrouter.ai/long-horizon

François Chollet@fchollet · 5月19日66

A mental model for working with coding agents is that they're blind squirrels running into a maze and bumping into walls. You must place the walls (verifiable constraints) strategically so that they end up in the general region you want them in.

译与编程智能体协作的心智模型是：它们就像在迷宫中奔跑、不断撞墙的盲眼松鼠。你必须策略性地设置墙壁（可验证的约束），让它们最终大致到达你期望的区域。

🚨 AI News | TestingCatalog@testingcatalog · 5月18日57

Manus AI released Scheduled Tasks 2.0, introducing web apps that can self-update their data on a schedule, task continuation, and new ways to observe ongoing tasks. > Scheduled Tasks is now available to all @ManusAI users.

译Manus AI 发布了定时任务 2.0，引入了可按计划自动更新数据的网页应用、任务延续功能，以及观察进行中任务的新方式。 > 定时任务功能现已向所有 @ManusAI 用户开放。

elvis@omarsar0 · 5月18日62

Every time I ask my 10-year-old to use coding agents, he gets extremely disappointed. It turns out that all he wants is to build his own rocket simulator. No amount of context engineering helps. No model works. All coding agents fail. That's just one example. He has many use cases where the coding agent really suck. Learning apps and other types of science-centered simulators. It's not like he is trying to be adversarial or break the system. I use the coding agents so extensively in my codebases that I just assumed that he would get similar results. It's not the case. And I think this is happening across all kinds of domains. I know he is not the target user. I get all that. But if all these claims about superintelligent AI on the horizon (12-18 months) are right, then coding agents shouldn't struggle so much to build any of the things he wants. The reality is that coding agents can help maintain and build complex things that aim to extend what exists in abundance in the training data. No surprises there. There is plenty of AI research to explain the OOD issues with LLMs. I think there is a massive opportunity here. Potentially a more generalized harness (something I have been working on). It doesn't have to work super well now, but it tests on edge use cases as newer models and capabilities emerge. IMO, all of this is a good indicator that LLMs are nowhere close to AGI or whatever they call it these days. Every day that passes, I am more convinced that we need to quickly move beyond LLMs and into things like native multi-modal systems and world models.

译一个10岁孩子想创建火箭模拟器等科学应用，却屡屡被主流AI编码工具所挫败。这揭示了当前以LLM为核心的技术短板：它们擅长在丰富训练数据框架内维护和构建现有模式，但难以灵活应对需要全新综合创造能力的边缘与生成性任务。这暴露了LLM距离实现通用人工智能（AGI）的局限，指明了未来需向更具泛化能力的原生多模态系统与世界模型等方向突破。

Rohan Paul@rohanpaul_ai · 5月18日56

Managing AI agents by hand is yesterday’s job. hire a Chief Agent Operator and move on. LobeHub launched just that. It turns AI agents from one-off chat helpers into a cloud-run operations team. The old model asks you to open separate agents, repeat context, assign tasks, check progress, move results between apps, and decide when to escalate work. LobeHub has an operator layer that hires agents from a 273K-skill marketplace, schedules them in the cloud 24/7, and sends reports through the IM apps where teams already work. So their "Task" turns an agent into a background worker: you assign the job once, the agent keeps running, shares progress, moves finished work to Pending Review, and updates its work when you leave comments.

译LobeHub推出“首席代理运营官（CAO）”这一新角色，旨在将AI代理从一次性对话助手转变为云端运行的自动化运营团队。用户无需再手动管理、重复上下文或逐一检查进度。该平台通过拥有27.3万项技能的市场来“雇佣”代理，并在云端进行24/7调度，通过团队现有的IM应用汇报进展。用户只需分配一次任务，代理即作为后台工作者持续运行、更新状态并将完成的工作置于待审核。用户专注于制定战略，而CAO则负责管理所有代理的执行与运作。

meng shao@shao__meng · 5月18日32

还是忍不住，先说一点外部比较公开的信息吧 你在 X 上看到的第一个铺天盖地的 AI 产品商单是谁？是 Manus 邀请码吗？我的是 Lovart，当时记得有几轮商单爆发，铺天盖地，阵仗很大！ 后来很多人知道 Lovart 应该是因为 Nano Banana，特别是国内的朋友，因为 IP 和账号问题不容易体验到原版 Nano Banana，Lovart 就做了一个中转，好像还有限免？ 后来罗永浩老师做了一次很大型的 AI 直播发布，给很多 AI 产品做推广，其中一个就是 Lovart，但那次 Lovart 推广其实没做成。当时罗老师解释时时长还是现场调试问题来着？反正是没做成，后来还承诺额外做品牌露出推广，作为补偿。 后面两件事，好像还有一个微妙的联系。。因为要做国外模型中转给国内用户，特别是 Nano Banana 和 Veo 等生图生视频模型，Lovart 应该是在香港做了一层代理，这也是打通国内外网络环境很常用的骚招。如果只是自己用，或者少量内测，一般不太会被发现。 但他们还在国内请公众号、小红书等好多平台的博主做 PR，导致国内流量短期内飙升，也就很自然的被发现了，切断了国内站的正常访问，而切断时，刚好就是直播时。。

译Lovart作为一款AI设计工具，通过密集的社交媒体推广和为国内用户提供Nano Banana等模型的中转服务迅速走红。其推广包括与罗永浩合作的直播，但该次推广未成功。为解决跨境访问，Lovart在港设立代理服务器，这在国内大规模PR推广导致流量激增后暴露，并被切断服务。该事件与直播时间重合，导致Lovart从备受瞩目的“Design Agent”迅速面临重大运营挑战。

Runway@runwayml · 5月18日58

Runway Characters can now take actions, not just speak. Tell the real-time video agent what you want, and they can call tools for you. Learn more about how to integrate tool calling into your product at the link below.

译Runway角色现在不仅能说话，还能执行操作。告诉实时视频代理你想要什么，它们就能为你调用工具。 了解更多如何将工具调用集成到你的产品中，请点击下方链接。

Rohan Paul@rohanpaul_ai · 5月18日58

Microsoft’s AI chief is warning that AI may automate most computer-based professional tasks within 12 to 18 months. Mustafa Suleyman’s claim targets work done through screens, documents, email, spreadsheets, code, dashboards, tickets, contracts, campaigns, and project trackers, because these jobs turn human intent into digital instructions that an AI agent can increasingly read, plan, execute, and revise. The risky jobs are not risky because they are low-skill, but because many expensive office tasks are repeatable patterns of reading, writing, comparing, filing, summarizing, searching, and deciding under known rules. --- fortune .com/article/why-microsoft-ai-chief-mustafa-suleyman-predicts-ai-automation-18-months/

译微软AI业务负责人Mustafa Suleyman警告，AI可能在12到18个月内实现对大多数基于计算机的专业任务的自动化。他指出，这类工作的核心是将人类意图转化为数字指令（如处理文档、邮件、代码、项目管理等），而这正是AI代理日益能够阅读、规划、执行并修正的流程。其风险并非源于技能门槛低，而在于许多高成本的办公任务本质上是重复性的阅读、书写、比较、归档、总结、搜索和基于已知规则的决策模式。

meng shao@shao__meng · 5月18日74

TRAE 团队分析了用户实际使用的 Agent Skills Top 10 这 10 个 Skills 覆盖了从 UI 设计到调试的产品开发全链路，还有一个 PUA Skills 😄，咱们分类看看： 流程治理类（强制工作流） 1. brainstorming —— 设计先行 强制在写代码前完成结构化需求对话，未批准方案禁止编码。核心是消灭"这事太简单不用设计"的惯性偷懒。 5. writing-plans —— 计划落地 把头脑风暴的产物拆成 2–5 分钟粒度的可执行任务，每步附带完成标准、风险预案和代码示例。是 brainstorming 的下游配套。 7. using-superpowers —— 调度中枢 元技能。强制 Agent 在每次响应前先检索并加载相关 skill，并明确优先级：用户指令 > 技能指令 > 系统默认。 8. karpathy-guidelines —— 行为护栏 源自 Karpathy 对 LLM 编码缺陷的观察，约束三类常见病：过度假设、过度工程、留下烂摊子。原则是 think first / stay simple / edit surgically。 设计与前端类 2. frontend-design 针对"AI 生成页面千篇一律"的问题，强制选择明确的设计语言（极简 / 复古 / 野兽派等），关注排版、配色、动效的真实质感。 3. ui-ux-pro-max 全平台设计系统生成器：50+ 风格、97 套配色、57 套字体组合，附带无障碍规范。属于 frontend-design 的"重型武器"版。 调试与验证类 4. systematic-debugging 四阶段方法论：禁止猜测式修复，要求根因追踪、纵深防御、基于条件的等待，必须完成完整诊断后才允许动手。 9. webapp-testing 基于 Playwright 的本地测试套件，强调"先侦察后行动"——截图、抓控制台日志、管理多服务生命周期。 10. agent-browser 更通用的浏览器自动化 CLI：导航、填表、点击、截图、数据抽取，把浏览器变成 Agent 的标准 I/O 通道。 生态扩展类 6. find-skills 对接开放的 skills. sh 生态，支持模糊搜索和从任意 Git 仓库安装，并按 Agent 作用域隔离。 额外发现：PUA /pua —— 高压问责 四级升级机制 + 七项检查清单，禁止 Agent 用"差不多了"或被动等待来收尾，强制承担完整责任。命名带反讽意味。 整体设计逻辑分层 1. 元层 using-superpowers, find-skills 2. 行为层 karpathy-guidelines, /pua 3. 流程层 brainstorming → writing-plans 4. 执行层 frontend-design, ui-ux-pro-max 5. 验证层 systematic-debugging, webapp-testing, agent-browser 形成的闭环是：想清楚 → 拆细 → 做精 → 验透 → 担责。

译TRAE团队基于真实的用户技能调用数据（而非安装量），分析了用户实际高频使用的Agent Skills Top 10。这些技能覆盖了从UI设计、流程规划到测试调试的产品开发全链路，甚至包含一个带有反讽意味的“PUA”高压问责技能。其设计具有清晰的分层逻辑，从元层的技能检索与调度，到行为层的约束护栏，再到具体的执行与验证层，共同构成了一个“想清楚→拆细→做精→验透→担责”的结构化、负责任的闭环工作流。

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

GOOGLE 🔥: Gemini desktop app will get Gemini Live, Gemini Spark, Gemini Omni, and a new "Stream to Cursor" feature. What we know so far 👀 - "Stream to Cursor" feature will allow Gemini to have something similar to "Magic Pointer" announced last week during Android Show. - Gemini Spark Agent will be able to operate local files from attached folders. - Gimini Omni is referred to as "Veo4 Omni" internally. - Skills will be supported too. - Gemini Live feature is WIP and not functional yet. A short demo from testers ⚡

译谷歌Gemini桌面应用即将迎来重大功能更新。新增的“Stream to Cursor”功能类似上周Android Show上展示的“Magic Pointer”。Gemini Spark智能代理将能直接操作本地文件夹中的文件。此外，应用将引入被内部称为“Veo4 Omni”的新模型，并支持Skills技能体系。不过，Gemini Live实时功能目前仍在开发中，尚未可用。

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

基于藏师傅 PPT Skill 的讲解视频生成 Skill，差不多搞定了！ Codex 配合远程控制不在家也可以一键产出视频内容 可以用非常低的成本保证视频内容的可用性和表现力 这里的视频是我随便找了一个徒步文案一次生成的。 主要的内容用前端生成，只有配音和部分分镜使用音频和Seedance 2.0 模型

译该工具基于藏师傅PPT Skill，结合Codex与远程控制，可实现离家时一键生成讲解视频。方案以极低成本保证了视频的可用性与表现力，主要通过前端技术生成内容，仅配音和部分分镜使用了Seedance 2.0等模型。此组合能直接基于文本生成带动效的解释视频。

向阳乔木@vista8 · 5月18日29

好像连读本地微信数据库也会警告，发就更别想了。 wx-cli 已GG，卡比的 cli 宇宙阵亡一个。

Alibaba Cloud@alibaba_cloud · 5月18日62

AgentScope Java 1.1 launches with workspace-driven persistence, pluggable filesystems, auto-context management, and secure sandbox orchestration for scalable enterprise Agents 🚀 Learn more: https://int.alibabacloud.com/m/1000413005/ #Java #AI #AgentScope

译AgentScope Java 1.1发布，支持工作区驱动持久化、可插拔文件系统、自动上下文管理以及安全沙箱编排，用于构建可扩展的企业级Agent 🚀 了解更多：https://int.alibabacloud.com/m/1000413005/ #Java #AI #AgentScope

向阳乔木@vista8 · 5月18日64

又一个开源的 Agent IDE：ORCA 优势是直接提供iOS和安装移动客户端，支持多账号切换（比如多ChatGPT订阅），Token消耗、5小时重置显示。 也是检测电脑里装好的各种Cli，比如Claude Code CLI、Codex CLI、Gemini CLI、Hermes、OpenClaw等。 支持目录和文件拖拽对话，内置Markdown预览渲染。 开源地址：https://github.com/stablyai/orca 官网： https://www.onorca.dev/ 解决了很多Tui工具小痒点，但缺点明显，安装包好大...

译ORCA是一款新开源的Agent IDE，提供iOS及移动端客户端，支持多账号切换（例如多个ChatGPT订阅），并显示Token消耗与5小时重置信息。它能自动检测电脑中已安装的CLI工具，如Claude Code CLI、Codex CLI、Gemini CLI等，支持目录文件拖拽对话及内置Markdown预览。该工具优化了Tui工具的常见痛点，但安装包体积较大。开源地址及官网已公布。

Greg Brockman@gdb · 5月18日52

Codex for unsubscribing from unwanted marketing emails

译用Codex退订不需要的营销邮件 [引用 @toddsaunders]：我终于在Codex中使用了/goal功能，效果令人震惊。 它扫描了我最近500封归档邮件。 然后查找退订链接，如果有的话就点击退订。 它找到了87封，并全部点击了退订。 它处理了“确认退订”页面，并标记了14封需要登录的邮件。 它自主运行了一个多小时，现在我的收件箱里没有营销邮件了。 太神奇了。

向阳乔木@vista8 · 5月18日67

马上安装试试，飞书机器人本身是不能互相@的，但这个方法估计可行，感谢 @kentzhu 的探索。

译用户推荐安装@kentzhu开发的skill，以解决飞书机器人不能互相@的限制。该工具支持飞书机器人之间稳定相互@，提供自定义停止方式，并内置自由讨论、头脑风暴、评审、辩论四种交互模式。同时，它支持跨openclaw和Hermes的机器人相互@，已开源在GitHub上供试用和参考。

meng shao@shao__meng · 5月18日57

感谢 @MaxForAI 推荐！ 关注 AI 的朋友，可以对照这个列表，看看还有哪些你感兴趣的账号，关注起来。

译推文推荐了一份由@MaxForAI整理的AI领域值得关注的30个Twitter账号列表，旨在帮助用户拓展高质量信息源。列表分为英文和中文两部分：英文账号包括Andrej Karpathy、Yann LeCun、吴恩达等顶尖研究者与教育者，内容涵盖LLM、Agent、AGI及前沿论文；中文账号包括宝玉、歸藏、小互等，侧重LLM实践、Prompt Engineering、AI工具资讯与行业动态。该合集为不同需求的用户提供了系统性的关注指引。

向阳乔木@vista8 · 5月18日47

配置好Hermes，每个飞书机器人用不同的模型，拉到一个群，就可以一次性@ 所有人回答同一个问题。 还在研究如何机器人之间互相@讨论。

Berryxia.AI@berryxia · 5月18日64

兄弟们，Google最新论文直接把时间序列预测的底层逻辑翻了个个儿。 过去所有模型都在死磕历史数据：曲线怎么走，就怎么预测。 Nexus却说：预测需要的不只是历史，而是“事件上下文”。 数字背后的真正原因——政策、突发事件、宏观趋势、局部冲击——必须和数字互相解释。 他们用多agent框架把这件事拆得清清楚楚： 一个agent从海量文本里提炼事件时间线， 一个读宏观政权， 一个盯局部冲击， 最后一个合成器把所有信息和历史误差校准后给出最终预测。 真实测试里，用Claude驱动的Nexus版本，在Zillow数据集上把平均MAPE直接砍了86.6%。 不是小幅提升，是降维打击。 以前模型只会“看懂模式”，现在它开始“理解因果”。 这篇论文真正厉害的地方不是某个数字，而是把预测从“统计外推”彻底变成了“多agent推理”。

译Google论文提出的Nexus框架颠覆了传统时间序列预测仅依赖历史数据的模式，强调“事件上下文”的核心作用。该框架采用多智能体协作架构：分别从文本中提取事件时间线、解读宏观态势、追踪局部冲击，最终通过合成器整合信息并校准误差。在Zillow数据集测试中，基于Claude的版本将平均预测误差（MAPE）大幅降低86.6%，实现了从“识别模式”到“理解因果”的范式转变。这标志着预测方法正从统计外推转向结构化推理，为未来预测系统指明了新方向。

meng shao@shao__meng · 5月18日64

LLM 应用层的产物形态走了三步： chat → agent → ? chat 给你 text，agent 给你一次 execution trace——但两者的产物都困在 session 里。同一个工作流跑第 100 次，依然是第 1 次的成本：冷启动、重喂上下文、token 重烧一遍。 KroWork 给的第三步答案是应用固化：把会话编译成一个本地可执行的App，而且沉淀为App后，后面再运行就完全不消耗token了，不需要焦虑反复消耗token。 一次对话，一次"编译"，剩下的全是 invoke。

译LLM应用层产物形态从chat演进到agent，两者输出均受限于会话，每次运行都需冷启动、重输上下文并消耗token。KroWork推出第三步应用固化，通过将对话编译为本地可执行App，使后续运行完全避免token消耗，实现一次编译后多次调用，提升效率并降低成本。

meng shao@shao__meng · 5月18日62

给 AI 时代工程师们的警示：不要把你的学习外包给 AI 随着 LLM 和 Agent 能力增强，作为工程师，咱们 “接受 AI 建议” 的概率在不断增加，甚至会默认跳过确认环节直接接受。@addyosmani 自己也是 AI 重度用户，但不会把学习和判断让 AI 来做。 几乎所有人都陷入一个工作模式： 粘贴报错 → 模型给出修复 → 症状消失 → 提交代码 → 进入下一个任务 在这个循环中消失的，是 "问题与解法之间那段混乱的挣扎"，而这段挣扎，恰恰是认知能力生长的唯一土壤。 Addy 把这称作"单人版的认知投降"：模型更快，于是你放弃在"理解深度"上与它竞争。每次妥协都微小到不构成事件，但成千上万次叠加后，离开 AI 你还能独立构建什么——这个能力每周都在缩水。 三项研究的趋同结论 1. Anthropic (2026) Python 库学习实验 AI 组与对照组完成速度相同，但理解测验得分 50% vs 67%；调试题差距更大 2. MIT《Your Brain on ChatGPT》 EEG 测量显示 LLM 用户脑区耦合最弱；83% 的人写完文章后无法引用自己刚写的任何一句 3. CHI 2026 锚定效应研究 任务开头使用 LLM 会框定整个问题空间，即使后续靠自己完成，决策质量也明显下降 为什么工具本身不会帮你？ Addy 点破了一个产品逻辑层面的真相： · 产品团队的 KPI 是"合并的 PR 数"和"更短的周期时间"，不是"让你变成更强的工程师" · 工具刻意把摩擦力打磨干净——而摩擦力正是学习发生的地方 · Claude Learning Mode、OpenAI/Google 的同类功能确实存在，但被集体归类为"学生用的"——这是严重误判 什么时候纯委托 AI 会崩塌？ Addy 还是认为：样板代码、胶水代码、一次性脚本——该委托就委托。但在五种场景下，纯委托必然失败： · 出 bug 时——"代码是 agent 写的"不能帮你 debug · AI 自信地错了时——对抗"看起来合理的错误答案"的唯一防线是足够的专业知识 · 底层变化时——框架升级、安全审计发现结构问题，无法靠 re-prompt 解决 · 偏离中位数时——AI 擅长 GitHub 上被解过一百万次的问题，越独特越无能 · 市场重新定价时——只能"带 AI 才能交付"的工程师，正进入一个正在重估专业价值的劳动力市场 最后一句尤其锋利： "如果你用 AI 跳过学习，你是在用未来的相关性，换一个稍微轻松点的周二。" # 可执行的姿势调整（核心方法论）# 1. 先形成假设，再提问 请求修复前，先写两三句你认为问题是什么。用模型的答案验证你的理论，而不是替代它。 2. 先要解释，再要代码 进入陌生领域时，第一条 prompt 应该是："解释它如何运作、有哪些替代方案、各自的权衡是什么"。理解了概念，再要代码。 3. 在能力之外时打开 Learning Mode 是的，会更慢。这正是重点。 4. 把 AI 的输出当作 junior 的 PR 来审 "测试过了"就足以合并吗？如果不是，这里也不行。 5. 偶尔徒手重写一遍 拿一段 AI 写过的代码，从零复现。这是校准检查，告诉你已经悄悄丢了多少。 6. 让模型反过来教你 代码生成后再加一条 prompt："你用了哪些概念？我需要读什么才能理解这个设计选择？"——一条额外的 prompt 就能改变这次会话的留存。 # 两个独立的指标 # 一个极简但深刻的自检框架： 每次写完代码问自己："我今天学到了什么，还是只是关闭了 issue？" · 偶尔答案是"只关了 issue"——没问题 · 连续几个月都是这个答案——认知债务正在背景里累积 "Ship" 和 "Learn" 是两个独立的指标。 · 你的 manager 和客户只会问第一个 · 第二个，只能你自己问自己

译Addy Osmani 警示工程师过度依赖AI生成代码会导致“认知投降”，即牺牲深度理解换取效率。研究显示，依赖AI会削弱问题理解、脑部活动和决策质量。产品设计追求效率，但学习恰恰发生在“摩擦力”中。AI委托在样板代码中有效，但在调试、AI犯错、底层变化、处理独特问题及面对市场价值重估时必然失败。作者建议应形成假设再提问、先要解释再要代码、开启学习模式、审阅AI输出如PR、徒手重写代码，并区分“交付”与“学习”指标，避免用未来能力换取短期轻松。

Ethan Mollick@emollick · 5月18日61

And, yes, our experiments used a mix of GPT-4 & GPT-4o (publishing takes awhile). I think we would see much larger results with more recent models, let alone recent agentic tools.

译一项名为“赛博队友”的实地实验发现，AI可以通过在员工技能薄弱任务上提供高于平均水平的性能来提升生产力，其作用方式类似于人类团队协作。实验表明，配备AI的个体工作者能达到未配备AI的人类团队的工作绩效，并能弥补个人单独工作时解决方案过度依赖自身专长导致的“不平衡”缺陷。研究进一步预测，AI的生产力增益在以下条件下更显著：人类专业分工更细、AI能力与人类技能呈负相关（即擅长人类不擅长的任务），且双方整体能力相当。实验使用了GPT-4系列模型，研究者认为采用更新的模型和智能体工具效果会更大。

Ethan Mollick@emollick · 5月18日61

So the two most obvious barriers to some sort of true AI takeoff are robust RSI (AI acting as an independent AI researcher, rather than “merely” a multiplier of human effort) and continual learning. Either would represent a major change in trajectory for AI development.

译因此，实现真正AI腾飞的两个最明显障碍是： 强大的RSI（AI作为独立的AI研究者，而“不仅仅”是人类工作的倍增器） 以及持续学习能力。 其中任何一项都将代表AI发展轨迹的重大转变。

Elon Musk@elonmusk · 5月18日48

Grok upgrades

译Grok升级 Grok正致力于让您实现个人任务自动化！ 部分功能包括： 1. 邮件自动回复 2. 每日股票追踪 3. 任务提取（从消息中）