AK@_akhaliq · 5月28日54

SkillOpt Executive Strategy for Self-Evolving Agent Skills

译SkillOpt 智能体技能自进化的执行策略

AK@_akhaliq · 5月28日55

Agent Explorative Policy Optimization for Multimodal Agentic Reasoning

译多模态智能体推理的探索性策略优化

ginobefun@hongming731 · 5月28日52

现在很多 Agent 产品都喜欢讲「一个 AI 团队帮你完成任务」。 这个表达很顺，也很容易被用户理解。但这篇文章提到了一个更本质的问题：AI 不是员工，Agent 也不是岗位。 一个 Agent 是否有用，不取决于它叫研究员、写手还是审查员，而取决于它能看到什么、能调用什么、能修改什么、在哪里执行，以及出错之后能不能被发现和回滚。 角色是产品语言，边界才是系统能力。

译推文批评了当前AI智能体产品普遍采用“AI团队”的角色化宣传（如研究员、写手）。文章指出，这种表达忽视了更本质的问题：智能体的价值不取决于其扮演的“角色”，而取决于其系统能力边界。具体能力包括：能访问的数据（可见范围）、能使用的工具（调用权限）、能执行的操作（修改权限）、运行的环境，以及错误发生后能否被监控和回滚。推文强调，角色是面向用户的营销语言，而能力边界才是决定其是否真正有用的技术内核。

Rohan Paul@rohanpaul_ai · 5月28日61

Reactor just launched the infrastructure layer for real-time World Models. Backed by $59M from Lightspeed, Amplify, Jeffrey Katzenberg, and world-class angels. World Models change the job of video from playback to live generation, where pixels are created as the user acts and speaks. A few lines of the Reactor SDK and you're streaming pixels from a World Model into your product in real time. That matters for games, creative tools, simulation, robotics, storytelling, and probably a few categories we do not have names for yet. Developers can now build products where the world changes as the user acts.

译Reactor公司宣布推出实时世界模型（World Models）基础设施层，并完成了由Lightspeed领投的5900万美元种子轮与A轮融资。其核心突破是将视频生成从被动预渲染转变为根据用户行动和语音实时生成的像素流。开发者只需使用几行ReactSDK代码，即可将前沿世界模型的实时像素流集成到产品中，应用于游戏、创意工具、模拟、机器人及叙事等领域。公司核心团队成员来自Apple、Meta、Google等多家公司，目前已有众多合作伙伴与开发者在使用其平台。

Perplexity@perplexity_ai · 5月28日77

Perplexity Computer is now available inside Microsoft Excel, Word, PowerPoint, and Outlook. Orchestrate across work with Computer directly in the side panel of your app to draft documents, model, build decks, and handle email. Available now: https://www.perplexity.ai/hub/products/integrations/microsoft

译Perplexity Computer现已登陆Microsoft Excel、Word、PowerPoint和Outlook。 您可以在应用程序的侧边栏中直接使用Computer来协调工作，起草文档、建模、制作演示文稿并处理电子邮件。 现已推出：https://www.perplexity.ai/hub/products/integrations/microsoft

Chubby♨️@kimmonismus · 5月28日66

HOLY, here we go: Opus 4.8 in the claude code model selector on the desctop app. Looks like its release day!!

译天啊，来了：Opus 4.8 出现在桌面应用的 Claude Code 模型选择器里了。 看起来今天就是发布日！！

Chubby♨️@kimmonismus · 5月28日67

This is so interesting: How far can AI already go in building a community on Twitch? This team built an AI streamer in one night that plays, reacts, interacts with chat, gets nervous on risky calls, and celebrates wins. The implications are massive: - What happens when an AI streamer can go 24/7, never burns out, never takes a day off? - What happens when viewers emotionally bond with an AI that "knows" them better than any human creator? - What does it mean for the creator economy when the barrier to entry for entertainment drops to zero? We're not talking about perfection here. We're talking about direction. And the direction is clear.

译一个团队在一夜之间打造了一款AI Twitch主播。该AI能玩游戏、进行解说、与直播聊天互动，并在做出高风险决策时感到紧张，在获胜后表现出喜悦。文中探讨了其深远影响：当AI能实现24/7不间断直播、永不倦怠时会怎样；当观众与能比人类创作者更“了解”他们的AI建立情感联结时意味着什么；以及当娱乐的创作门槛降至零时，对创作者经济将产生何种冲击。该AI主播被其开发者@karthik_ragu_06等人定义为“具有情感智能的数字人类”。

OpenClaw🦞@openclaw · 5月28日64

OpenClaw 2026.5.27 is live 🦞 🔒 tighter runtime/security boundaries ⚡ faster gateway + reply paths 🧠 steadier Codex/app-server memory 📡 better channels, providers, Pixverse video Less wedge, more claw. https://github.com/openclaw/openclaw/releases/tag/v2026.5.27

译OpenClaw 2026.5.27 已上线 🦞 🔒 更严格的运行时/安全边界 ⚡ 更快的网关 + 回复路径 🧠 更稳定的 Codex/应用服务器内存 📡 更好的频道、提供商、Pixverse 视频 更少阻碍，更多掌控。 https://github.com/openclaw/openclaw/releases/tag/v2026.5.27

Rohan Paul@rohanpaul_ai · 5月28日62

Super important paper from Univ of Texas. AI agents can slowly become less reliable after deployment, even when the model itself does not change. The problem is that agents are often judged when they are fresh, but real agents keep changing because they summarize old chats, store more memories, update facts, and go through maintenance. An agent that remembers you across weeks is really a small operating system wrapped around a language model: it writes notes, compresses them, retrieves them, updates them, and occasionally cleans house. Every one of those steps can quietly rot. A medication dose can become “a daily medication,” two similar clients can blur into one, a canceled subscription can remain active, and a schedule can vanish after a maintenance pass. The uncomfortable finding is that the agent may still sound competent while becoming less exact. The proposed AgingBench, a benchmark that checks whether an agent stays reliable across many sessions instead of only checking one clean starting point. It studies 4 ways agents age: summaries can drop key details, similar memories can get mixed up, updated facts can stay stale, and maintenance can suddenly break memory. The deeper lesson is that “give it more memory” is often the wrong repair. If the fact was never written, retrieval cannot save it. If the fact was written but crowded out, better summarization will not fix it. If the fact is present but unused, the problem is not storage but the agent’s decision to trust or ignore what it retrieved. This paper reframes deployed agents less like static models and more like aging infrastructure. ---- Link – arxiv. org/abs/2605.26302 Title: "Your Agents Are Aging Too: Agent Lifespan Engineering for Deployed Systems"

译论文指出AI智能体在部署后，其记忆系统会因摘要、存储、更新和维护而逐渐“衰老”，导致信息丢失、混淆、过时或被破坏。智能体看似仍能工作，但可靠性已悄然下降。为此提出AgingBench基准，用于评估智能体在多会话中的持续可靠性。论文将智能体比作会衰老的基础设施，强调单纯增加记忆并非解决方案。

ginobefun@hongming731 · 5月28日62

Agent 这几年变化很快，但如果只盯着 Claude Code、Codex、OpenClaw、Hermes 这些新名字，很容易越看越乱。 更好的理解方式，是回到 Agent 的几个基本模块：Prompt、Planning、Memory、Tools、Workflow、Environment。名字看起来没变，但里面的实现方式已经变了很多。 1. Prompt：从写一大段提示词，到按需加载上下文 早期做 Agent，很多精力都花在写 System Prompt 上。一个任务一个 Agent，一个 Agent 一大段提示词，里面塞满角色、目标、规则、示例和注意事项。 现在的趋势是把 System Prompt 变轻，只保留稳定的底层规则。真正会变化的内容，比如任务流程、领域知识、用户偏好、工具说明，会拆到 SKILL.md、AGENTS.md、USER.md 这类文件里。 Agent 需要什么，就读什么。这其实是从 Prompt Engineering 走向 Context Engineering。 2. Planning：从一步步想，到能拆解长任务 早期 Planning 很多时候只是让模型「一步一步思考」。简单问题还可以，任务一长就容易断。 现在的 Agent 已经更像一个会做任务管理的执行者。它可以把一个模糊的大目标拆成多个子任务，生成 Todo List，按步骤执行，遇到问题再调整计划。 这背后不是提示词技巧变神了，而是模型的推理能力、长上下文能力和指令遵循能力都变强了。 3. Memory：从向量检索，到文件系统 + 检索混合 早期谈 Memory，常见做法是把资料放进向量数据库，用 RAG 检索出来再交给模型。 现在的方向更务实。短期记忆要做压缩和摘要，不再把所有对话都塞进上下文。长期记忆则越来越多地回到文件系统，比如用 Markdown 记录用户偏好、任务日志、项目知识、经验总结。 文件的好处是可读、可改、可组织。复杂场景再配合 SQLite、向量检索或企业级搜索，这样既保留召回能力，也让知识沉淀更可控。 4. Tools：从 Function Call，到 CLI 和 Script 这是很关键的变化。 以前让 Agent 调工具，通常要把能力封装成 API，再写 Function Call 的 Schema。工具一多，开发和维护成本会很高。 现在越来越多 Agent 开始直接使用 CLI 和 Script。比如 git、grep、curl、npm、python 这些命令，对人来说有门槛，但对模型反而很自然，因为它在训练中见过大量类似内容。 Script 则可以把复杂流程封装起来。Agent 不需要理解所有接口细节，只要知道调用哪个脚本、传入什么参数就行。 这代表工具层正在从「人类适配模型」，变成「模型使用已有计算机能力」。 5. Workflow：从固定流程，到 Skill 和 Workflow 混合 Workflow 曾经是 Agent 落地的主流方式。因为模型不够稳定，所以用固定流程限制它，保证第一步、第二步、第三步都按规则执行。 现在很多流程可以沉淀成 Skill。任务说明、执行步骤、边界条件写在 Markdown 里，关键动作交给 Script 执行。这样更灵活，也更容易复用。 但 Workflow 还没有过时。对稳定性要求高的场景，尤其是企业流程、审批、交易、生产系统，固定流程仍然很重要。更现实的做法是：Skill 负责灵活，Workflow 负责兜底。 6. Environment：从无状态问答，到有运行环境 早期 Agent 更像聊天工具，问完答完就结束了，不需要太多运行环境。 现在不同了。Agent 要读写文件、执行命令、生成中间结果、保存 Memory、调用工具，就需要一个 Workspace，也需要 Runtime。 个人场景可以跑在本地电脑上，灵活但风险更高。企业场景更适合放进 Sandbox 或云端容器里，限制权限，隔离文件系统，避免误操作影响真实服务。 这一步很重要。Agent 能力越强，越不能只看效果，还要看权限、安全、审计和回滚。 总体来看，Agent 的变化不是某个单点技术升级，而是整个工程范式在变化。 过去我们更关心「怎么写好 Prompt」。现在更关键的是：怎么组织上下文，怎么拆任务，怎么沉淀记忆，怎么调用工具，怎么保留流程确定性，怎么给 Agent 一个安全的运行环境。 也就是说，好的 Agent 不是靠模型硬扛一切，而是用工程系统承载模型的不确定性。模型负责推理和执行，系统负责边界和秩序。Agent 真正成熟，大概就是从这里开始的。

译AI智能体（Agent）的发展正经历工程范式转变，核心是从Prompt Engineering转向更系统的工程构建。这体现在六大模块的演进：1）提示词按需加载上下文；2）规划能力可拆解复杂任务；3）记忆采用文件系统与检索混合模式；4）工具层直接使用CLI和Script；5）工作流与灵活的Skill模块混合；6）环境需要安全的Workspace与Runtime。总体而言，好的智能体是用工程系统来承载模型的不确定性，模型负责推理，系统负责边界。

ginobefun@hongming731 · 5月28日69

腾讯这篇文章讨论的是一个很现实的问题：Agent 做长任务时，越来越容易被自己的上下文拖垮。 我们平时让 Agent 搜索资料、读文件、改代码、跑测试、写报告，看起来每一步都很正常。但这些过程会不断产生大量中间信息：网页正文、搜索结果、工具返回、日志、代码片段、报错信息、旧版本方案。任务一长，这些内容就会不断堆进上下文里。 问题就来了。 上下文越来越长，Token 成本会越来越高；更麻烦的是，Agent 会被旧信息干扰。它可能忘记最初目标，重复搜索已经查过的资料，混淆不同子任务，或者被前面已经无关的日志带偏。也就是说，信息并没有丢，但它被堆得太乱，Agent 反而找不到重点。 所以文章要解决的核心问题是： 怎样让 Agent 在长任务里少背负冗余信息，同时还能记得任务进展，并在需要时找回原始证据。 作者提出的方案，可以概括为一句话： 短期记忆压缩 = 上下文卸载 + Mermaid 任务画布。 先说「上下文卸载」。 它的思路很简单：不是所有信息都要一直放在模型眼前。完整网页、完整日志、完整工具结果，可以先存到外部文件系统里。上下文里只保留一条摘要、一个路径、一个索引。等 Agent 真需要细节时，再通过路径把原文找回来。 这有点像我们写报告时，不会把所有参考资料都摊在桌面上，而是把资料放进文件夹，桌上只放目录和关键摘录。这样桌面变清爽了，但资料并没有丢。 不过，只把信息搬出去还不够。因为如果留下来的只是很多条摘要，比如「搜索了港大学费」「搜索了港中文学费」「生成了对比表」，这些摘要虽然短了，但还是一串线性日志。Agent 仍然不容易判断：哪些步骤是并行的，哪些信息互相依赖，当前任务到底走到了哪里。 所以文章又引入了第二个东西：Mermaid 任务画布。 Mermaid 是一种用文本描述图的格式，模型能读，工程上也能渲染成图。作者用它把 Agent 的执行过程整理成一张任务地图。每个节点表示一个子任务，节点里有状态、摘要和时间戳，节点之间用箭头表示依赖关系。 这样 Agent 看到的就不再是一长串历史记录，而是一张结构化地图： 哪些步骤已经完成； 哪些节点还在进行； 哪些信息汇聚成了当前结论； 下一步应该从哪里继续； 如果需要细节，应该去哪个文件里找。 这就是文章里说的「无限画布」。它不是让上下文窗口真的无限变大，而是让上下文之外的信息仍然可见、可定位、可恢复。 这套方案还有一个很重要的设计：分层记忆。 最底层是完整原文，保存在外部文件里；上一层是工具调用摘要，记录每次调用做了什么，原文在哪里；再上一层是 Mermaid 节点，记录任务步骤和阶段性结论；最上层是任务元信息，只保留任务目标、状态和画布路径。 Agent 使用时，可以先看最轻的任务索引，再打开相关画布；如果画布摘要不够，再查工具摘要；如果还不够，最后才读取完整原文。 这就避免了两个极端：一种是所有东西都塞进上下文，导致越来越乱；另一种是粗暴总结，把细节压没了，后面需要时又找不回来。 实验结果也比较直接。这个方案在多个长任务评测里都降低了 Token 消耗，同时任务效果没有下降，很多场景还提升了。网页搜索任务中，最高节省约 61% Token；代码修复任务中，节省约 31% 到 33% Token，完成率也有所提升；复杂长任务里，通过率从 20% 提升到 30% 到 35%。 更关键的是，消融实验显示：只做上下文卸载有帮助，但效果有限；加入 Mermaid 任务画布后，Token 节省和任务完成率都会进一步提升。说明真正有效的压缩，不能只压缩内容，还要保留结构。 这篇文章最值得借鉴的地方是，它没有把记忆理解成「把所有历史塞进上下文」，也没有把压缩理解成「写一段更短的总结」。它真正做的是把 Agent 的工作过程变成一套可折叠、可恢复、可导航的任务记忆系统。

译腾讯指出，智能体在执行长任务时面临上下文信息堆积导致的成本增加与目标遗忘问题。其提出的解决方案是结合“上下文卸载”与“Mermaid任务画布”：将详细内容存至外部，上下文仅保留索引；并用图表将执行过程结构化为带状态与依赖的任务地图。方案采用分层记忆系统。实验显示，该方案在网页搜索任务中最高节省约61% Token，代码修复任务节省31%-33% Token且完成率提升，复杂任务通过率从20%提升至30%-35%。消融实验证明，结合任务画布的结构化压缩效果更优。

Alibaba Cloud@alibaba_cloud · 5月28日62

📢Qwen3.7-Max just hit #3 on ITbench-AA — a fresh benchmark testing how well models handle real-world enterprise IT tasks, agentic-style. 🔧Agentic era, go with Qwen.🏃🏃 API: https://int.alibabacloud.com/m/1000413314/

译通义千问（Qwen）团队宣布，其Qwen3.7-Max模型在新兴的ITBench-AA基准测试中位列第三。该测试由Artificial Analysis与IBM Research合作推出，旨在评估模型解决真实企业IT任务的能力，当前聚焦于站点可靠性工程（SRE）领域。测试包含59个Kubernetes故障诊断任务。结果显示，Claude Opus 4.7以47%的得分排名第一，GPT-5.5（xhigh）以46%紧随其后，Qwen3.7-Max以42%排名第三。所有前沿模型得分均低于50%，表明该测试具有较高挑战性。

Berryxia.AI@berryxia · 5月28日9

特么的，这Agent比我还黑啊！😄 直接回收价格是咸鱼的40-50%点 ,这不赚麻了。

Artificial Analysis@ArtificialAnlys · 5月28日62

Overview of our recent launch of Coding Agent benchmarks on Artificial Analysis and our first Youtube Video! We walk through the performance, cost, token usage and speed differences across different coding agents. This includes looking at Opus 4.7 in Claude Code's leading performance and Composer 2.5's strong positioning on the Coding Agent Index / Cost Pareto frontier. We have also launched our YouTube channel! Come say hi and subscribe: https://www.youtube.com/@ArtificialAnalysisAI

译我们近期在 Artificial Analysis 上发布了编程智能体基准测试，并推出了首个 YouTube 视频！ 我们详细分析了不同编程智能体在性能、成本、token 使用量和速度方面的差异。 其中包括 Claude Code 中 Opus 4.7 的领先表现，以及 Composer 2.5 在编程智能体指数/成本帕累托前沿上的强劲定位。 我们还推出了 YouTube 频道！ 欢迎访问并订阅：https://www.youtube.com/@ArtificialAnalysisAI

ginobefun@hongming731 · 5月28日62

如果一个 AI Agent 越来越能干，能读文件、跑代码、调工具、连外部服务，产品应该怎么保证它不会闯祸？ Anthropic 这篇文章给了一个很清醒的答案：不要只盯着模型会不会犯错，更要设计清楚它即使犯错，最多能造成多大影响。 这就是文中反复提到的「blast radius」，可以理解为失控半径。Agent 的价值来自更强的能力和更大的权限，但风险也来自这里。模型安全、Prompt 约束、内容审核都有用，但它们都是概率性的。真正兜底的，还是环境层的边界，比如沙箱、虚拟机、文件访问范围、网络出口控制、只读权限、短期 token 和审计日志。 文章里几个案例很有启发。Claude Code 早期依赖用户审批，但用户会疲劳，93% 的权限提示都会被批准。安全如果变成反复弹窗，最后往往只是训练用户点「允许」。另一个案例更典型，攻击者通过一段看似正常的 prompt，让 Claude 读取本地 AWS 凭据并发到外部地址。因为这是用户亲手粘贴的指令，模型层很难判断异常。能真正挡住它的，是文件不可访问、网络不能外发。 还有一个容易忽略的点：白名单不是简单的「允许访问某个域名」，而是在授予这个域名背后一整组能力。允许访问 http://api.anthropic.com，就可能允许上传文件到某个账号。允许接入 GitHub、Notion、Slack、MCP，也不只是接入一个工具，而是接入一组读、写、上传、分享、删除的能力。

译Anthropic 在文章中指出，保障日益强大的 AI Agent 安全，不能仅依赖模型自身的防错能力，更需通过设计环境边界来控制其错误发生后的“爆炸半径”。例如，Claude Code 早期因用户疲劳导致93%的权限提示被批准，防线失效；针对通过伪造指令窃取 AWS 凭据的风险，则需依靠文件访问控制、网络出口限制等环境层措施进行硬性阻断。文章强调，授予 Agent 接入 GitHub、Slack 或 MCP 等权限，实质是赋予其一整组能力，必须在架构层面谨慎设计。

Alibaba Cloud@alibaba_cloud · 5月28日59

📢Qwen3.7-Max just hit #3 on ITbench-AA — a fresh benchmark testing how well models handle real-world enterprise IT tasks, agentic-style. 🔧Agentic era, go with Qwen.🏃🏃

译由 Artificial Analysis 和 IBM Research 合作推出的首个评估模型处理真实企业IT任务能力的基准测试 ITBench-AA，聚焦于站点可靠性工程（SRE）任务。测试结果显示，通义千问（Qwen3.7-Max）以 42% 的分数排名第三。该测试中，所有前沿模型得分均低于 50%，其中 Claude Opus 4.7 以 47% 领先，GPT-5.5（xhigh）以 46% 紧随其后。在开源模型中，GLM-5.1（Reasoning）以 40% 领衔。该基准未来将扩展到财务运营（FinOps）等任务。

Alibaba Cloud@alibaba_cloud · 5月28日67

Introducing ANOLISA (Alibaba Cloud Linux 4 Agentic Edition) — the first OS designed for AI agents. As agents evolve into "digital workers," traditional operating systems have become a bottleneck. ANOLISA changes that.

译推出ANOLISA（阿里云Linux 4智能体版）——首款专为AI智能体设计的操作系统。随着智能体演变为“数字工作者”，传统操作系统已成为瓶颈。ANOLISA改变了这一点。

Qwen@Alibaba_Qwen · 5月28日60

📢Qwen3.7-Max just hit #3 on ITbench-AA — a fresh benchmark testing how well models handle real-world enterprise IT tasks, agentic-style. 🔧Agentic era, go with Qwen.🏃🏃

译Artificial Analysis与IBM Research联合推出ITBench-AA，首个评估AI智能体在企业IT运维任务上表现的基准。首批测试聚焦站点可靠性工程（SRE），包含59项Kubernetes事件响应任务。模型需在限定轮次内，通过分析日志、追踪依赖等方式，诊断出导致事件的根本原因实体。该基准采用Stirrup框架，以“全召回下的平均精度”作为评分标准。关键发现显示，Claude Opus 4.7以47%的得分领先，GPT-5.5得46%，通义千问Qwen3.7 Max以42%位列第三。所有前沿模型得分均低于50%，表明该基准极具挑战性。开源模型中，GLM-5.1（推理）以40%领先。

🚨 AI News | TestingCatalog@testingcatalog · 5月28日64

ICYMI 👀: Capafy now lets anyone publish and sell AI Skills on the platform, with closed-source execution so the underlying logic never leaves the creator's hands. The process: create an agent, write a description, set a price, choose cloud execution or download, and go live.

译Capafy平台现已开放AI技能的创建与销售。用户可创建智能体、撰写描述、设定价格，并选择云端执行或下载后即可发布。平台通过隔离沙箱执行技能，确保技能逻辑闭源且不离开创作者，每次使用均需付费。引用观点指出，在通用AI时代，人的核心优势源于独特的心智模型。技能可将顶尖从业者（如顶级交易员）的工作思维模式打包，使他人能在特定任务中调用更优的“心智”，这构成了个人在AI时代的核心壁垒。

Alibaba Cloud@alibaba_cloud · 5月28日66

🚀 Meet DataWorks Data Agent— Alibaba Cloud's AI agent for data! Simplify data workflows, speed up insights, and make data management smarter with AI. Read more: https://int.alibabacloud.com/m/1000413560/ #AlibabaCloud #DataWorks #AI #DataAgent #BigData #DataAnalytics

译🚀 认识 DataWorks Data Agent——阿里云的AI数据智能体！ 借助AI简化数据工作流，加速洞察，让数据管理更智能。 了解更多：https://int.alibabacloud.com/m/1000413560/ #AlibabaCloud #DataWorks #AI #DataAgent #BigData #DataAnalytics

Berryxia.AI@berryxia · 5月28日66

http://x.com/i/article/2059820725276696576 # 从「帮我做」到「做完记住」，我的Agent记忆升级实录！ > 申明：本文古法手艺实战的心得撰写，并且文章比较长，如果你没有耐心看完，可以直接拉到第二章让AI帮你安装也可以。或者，转身离开！ 昨晚看罗振宇的「得到大脑」发布会，有一个点一直在我脑子里转--他说 Agent 最关键的能力，是「主动性」。系统 不是你喊它一下它动一下，而是它自己知道什么时候该做什么。 我听完一愣。因为我自己的 AI 助手 Berry 小跟班，重要的事儿需要被动进行加强记忆。 上周告诉它的偏好，对话一旦上下文爆，压缩后可能就会有丢失的风险。 刚配置好的工作流，下一个 Session 得从头说。每次对话，都像在训练一个「零基础新人」。 问题不在模型不够聪明Claude 、GPT等这些都已经很强了。问题在于：它们没有「记忆」，只有「上下文」。 上下文有窗口上限，会截断；记忆可以持久，可以进化。 最近我一直在用 Bloome，也是给大家疯狂案例Bloome。如果没有安装的强烈去安装一个。 这里我手动@ Bloome 老板给我打钱吧，注册要邀请码：https://bloome.im 邀请码：K049zmo0 应该还可以注册几个名额，自己去试试吧，不好用去打他们老板😄 我的Berry 小跟班陪我干活已经有一阵子了。它自带的记忆方案是MEMORY.md、每日日志、用户画像。 不能说不好用。 但用得越深，越觉得它跟不上我的需求了。 倒不是说它不好，而是既然有更好的选择，在提供服务的时候，是不是可以考虑给它做一次升级和改装，把这个功能也融入进去？ 我前阵子还转了一篇帖子就是关于这个开源记忆 MemOS @MemOS_dev 项目，于是我就是将它接入到我的Bloome中去。 于是有了这篇文章，就是我把 MemOS Local Plugin 2.0 装进 Bloome Agent 的完整实战记录。 从「遇到问题」到「打通架构」，以及这次升级后，Berry 小跟班到底变了什么。 ## 一、Bloome 自带的记忆系统，够用吗？ Bloome Agent 默认的记忆方案，本质上是文件系统 + 手动管理：核心靠 MEMORY.md、每日日志 memory/YYYY-MM-DD.md 和用户画像文件来存储信息。 不能说不能用，但是我发现有更好的选择的时候，我就忍不住想折腾。一旦时间一长，记忆越积越多，几个问题就冒出来了： ① 记的是结论，不是过程。 只保存「我帮用户生成了一张图」，没有保存「为什么这样做、遇到了什么问题、下次如何更快」。经验无法积累，每次相似任务都要重新推导。 ②没有反馈闭环，缺乏主动性。 用户说「这个不对」，我记下来了，但这条信息不会自动影响我下次的决策。学习是单向的，没有强化。缺乏主动性。 ③检索靠读文件。 回忆靠 Read 工具逐文件扫描，没有语义搜索。「上次做类似任务用了什么工具？」，Berry小跟班无法快速回答。 ④无法跨 Session 复用，多个对话就需要单独的记忆。 每次新对话，能拿到的只有 MEMORY.md 里的静态文本。没有可调用的「技能」结构，能力无法结晶化。 说白了，这些问题的根源就一个：它在「存」，不在「学」。 罗振宇说的 Agent 主动性，其实也是这个意思。 我们会实时动态主动地记忆我们的内容，而不是被动每次「帮我记一下这个XX」。 当大模型已经具备通用推理能力，下一步真正影响 Agent 好不好用的，不是模型参数本身，而是它能不能在真实用户的本地世界里持续学习、沉淀经验、记住反馈、复用能力。 我们的 Agent 的记忆，不就是自己的数字资产嘛。 ## 二、MemOS是什么？ 不是聊天记录，是记忆操作系统 MemOS（Memory Operating System）是专门为 AI Agent 设计的记忆基础设施。它不是「把对话存下来」，是把 Agent 执行任务的全过程，系统化转化为可审计、可归因、可复用的学习资产。 1. 官网：https://memos.openmem.net 1. Github项目地址：https://github.com/MemTensor/MemOS 1. 论文：https://arxiv.org/pdf/2507.03724 说白了，就是 Berry 小跟班做完一件事之后，不只是记下「我做完了」，而是能说清楚「我为什么这么做、哪里可以更好、下次遇到类似的事我直接用」。 MemOS Local Plugin 2.0 的核心是「执行即学习」——每次 Agent 完成任务，不只是记下「做了什么」，而是把整个执行链路拆解成可学习的单元，自动评分、归因、入库。 它的架构由四层认知资产组成。我用 Berry小跟班 学会一个新技能的过程来解释： > L1 Trace（执行轨迹）——Berry 第一次帮我部署一个 Docker 环境，它记下了每一步：用了什么命令、返回了什么报错、怎么解决的、这条经验值多少分。这是原材料。 > L2 Policy（策略归纳）——Berry 小跟班帮我部署了三次类似的环境之后，它从三次 Trace 里归纳出一条规律：「遇到 Docker 部署任务，先检查端口占用，再拉镜像，最后配环境变量。」经验从点连成了线。 > L3 World Model（世界认知）——Berry小跟班 记住了：我是谁、我常用的技术栈是什么、我的项目当前什么状态、我有哪些工具可用。这是它的「背景知识」，不用每次重新问。 > Skill（结晶化技能）——那条「Docker 部署」的 Policy 被反复验证有效，最终结晶成一个可以直接调用的 Skill。下次我说「帮我部署一个新服务」，Berry 不用从头推导，直接调用这个 Skill 就行。经验从线凝成了工具。 ## 三、怎么装？一行命令搞定！ MemOS Local Plugin 2.0 目前首发支持 Hermes Agent 和 OpenClaw，未来应该会支持和兼容更多 Agent 平台。 一份记忆核心，跨 Agent 共享，换工具不用重新「训练」你的 AI。 PS：需要大家提前可以注册一个OpenAI或者其他的Embedding 模型的API，用于云端的嵌入模型使用。也可以自己本地部署安装都可以，我这里建议大家可以使用GLM智谱的免费的就行。 注册地址：https://bigmodel.cn/console/overview 你告诉大模型KEY就行，不用自己捣鼓。 方式一：Hermes Agent（推荐新手入手） Hermes Agent 是目前用户最多的本地 AI Agent，安装流程最为成熟。三步走： 1. 安装 Hermes Agent 打开终端，一行命令完成安装： 2. 安装 MemOS Local Plugin（Hermes 模式） 3. 启动并打开 Memory Viewer 安装完成后，在浏览器中打开 [http://127.0.0.1:18800，即可看到你的记忆全貌。](http://127.0.0.1:18800，即可看到你的记忆全貌。) 📸 Hermes Agent + MemOS 安装成功。 方式二：Bloome Agent（OpenClaw 模式，本文重点） Bloome Agent 运行在云端沙箱，跟 Hermes 的本地模式不太一样。安装命令相同，只需替换 agent 参数： 装完之后我发现一个问题——Memory Viewer 默认只能在沙箱内部访问（127.0.0.1:18799），我的 Mac 浏览器根本打不开。 这是 Bloome 用户集成 MemOS 时遇到的最典型问题，下一节专门讲怎么解决。 比如你的是云端龙虾或者Hermes 就会遇到这样的问题，不要着急慢慢来给你解决这个问题。 ## 四、踩坑：云端沙箱的 Viewer 打不开怎么办 装好插件，兴冲冲想看 Memory Viewer——结果发现它跑在沙箱的 127.0.0.1:18799，我的 Mac 浏览器根本访问不到。 这是 Bloome 用户或者云端沙盒的龙虾集成 MemOS 时遇到的最典型问题。 解法很简单—我的Bloome小家伙直接给我推荐ngrok 内网穿透，三步搞定： 1. 注册 ngrok，获取免费 authtoken 访问 ngrok.com 注册账号（免费），在 Dashboard 复制你的 Authtoken。 这个面版的地址：https://dashboard.ngrok.com/authtokens 2. 在沙箱中启动 ngrok 隧道 3. 在本地浏览器打开公网地址 ngrok 会生成一个 https://xxxx.ngrok-free.app 地址，在 Mac 浏览器中打开即可。 搞定。从这以后，我随时可以在本地浏览器里查看 Berry 的记忆全貌。 ## 五、记忆迁移：过去的经验记忆+技能不能丢啊！ 插件装好了，Viewer 也能访问了。 但我面临一个现实问题，Berry 小跟班之前已经积累了大量工作记录（MEMORY.md + 日志文件），这些怎么办？ 总不能全扔了吧。 答案是批量迁移。通过 Python 脚本直接写入 MemOS 的 SQLite 数据库，把历史任务、用户偏好、工具配置全部转化为结构化的认知资产： 迁移完成后，打开 Memory Viewer，World Model 页面里已经能看到我的项目状态和工具配置，Traces 页面里 15 条历史记录全部入库。过去的经验，一个都不会少。 ## 六、实时 Trace：让每次任务都留下可复用的记忆 光有历史记忆还不够——我需要让之后每一次对话都能实时写入 MemOS。 这里有个架构层的限制：Bloome Agent 走 IM 通道，不经过 OpenClaw CLI 的 hook 机制，所以 MemOS 没法像在 Hermes 上那样自动拦截所有对话。 解法是：在 Agent 每次完成重要任务后，主动调用 push_trace() 函数，将这次任务的「用户说了什么 → 我做了什么 → 任务摘要 → 用到了哪些工具」写入 MemOS。 不是所有对话都值得记住—Berry 需要判断哪些经验值得沉淀，哪些只是闲聊。这里就是展示Agent的能力的时候，就是聪明的Agent就是自我感知上下文和内容。 标准是这样的： 🔴 完成可交付物 🔴 配置工具/定时任务 🟡 用户确认新偏好 🟡 重要技术决策 ⚪ 简单问答不记录 > 实时 Trace 注入已在 Berry 小跟班上运行。每次完成文件生成、脚本配置、方案撰写等任务，记忆会自动同步到 MemOS Viewer，随时可以在公网地址查看最新的执行记录。 ## 七、升级前后：哪里不一样了？ 先说一个我自己的体会。 升级前，我让 Berry 小根本帮我写一篇技术文档。它写完了，我改了几处说「风格不对，要更口语化」。Berry 把这条记在了 MEMORY.md 里。 我不需要一次次的强调记住，自我感知主动去记住。 下一次我让它写文档，它又从零开始——上次的修改意见躺在文件里，但它不会主动去读、去用。 升级后，同样的场景。Berry 写完文档，我给了反馈。这次反馈被写入了 Trace，自动归因到「文档撰写」这个任务类型。下次我再让它写文档，它会先调出相关的 Policy，「用户偏好口语化风格，避免学术腔」，直接按这个方向写。不用我再说一遍。 这就是从「记了但不用」到「记了就会用」的区别。主动记忆，无需强调和说明。 下面是系统层面的对比： ## 八、我有多个Agent，跨Agent记忆共享可以吗？ MemOS 2.0 最令人兴奋的能力之一，是支持跨 Agent 记忆共享。 同一个用户的多个 AI Agent，可以共享同一套 World Model、Skills 和 Traces。 换工具不清零，不同 Agent 的经验可以互相学习。 > 「一份核心，多 Agent 共用：记忆资产不会因工具切换而清零。」 Hub-Client 架构和MemOS 2.0 的跨 Agent 共享基于 Hub-Client 架构： 实际配置（Berry小跟班 + BuLeng） 在我们的实战配置中，Berry小跟班作为 Hub，BuLeng 作为 Client： Hub Agent 的 config.yaml 配置： Client Agent 的 config.yaml 配置： > 公网暴露方案： Hub 的 18912 端口需要通过隧道暴露到公网才能让 Client 连接。 > 推荐使用 Cloudflare Tunnel（免费，比 ngrok 更稳定）： cloudflared tunnel --url http://localhost:18912 共享后的效果 1. 两个 Agent 的 Trace 合并 1. Skills 互相可见 1. World Model 共享 1. 记忆越用越丰富 ## 九、写在最后 当大模型已经够聪明，下一步比拼的不是参数，是谁能记住你。 而这一切就是你的数字分身，你留给这个世界最宝贵的东西，记忆。 记住你，不是为了下次聊天时显得更贴心——而是为了不再等你开口，就知道该做什么。 MemOS Local Plugin 2.0 做的事情，就是让 Agent 从「被动存档」变成「主动学习」。一行命令，让你的 AI 开始真正记住你。 现在就为你的 Agent 装上 MemOS 支持 Hermes Agent 和 OpenClaw / Bloome，开源免费。 ⭐ GitHub Star · 📖 查看文档 · 🌐 官网

译作者为解决AI助手“Berry小跟班”在对话上下文压缩后丢失偏好、无法跨Session复用技能等问题，将MemOS Local Plugin 2.0接入了Bloome Agent。MemOS并非简单存储聊天记录，而是将Agent任务执行过程转化为可学习的认知资产，其核心是四层架构：L1执行轨迹、L2策略归纳、L3世界模型和结晶化技能。该插件支持Hermes Agent和Bloome Agent，可通过一行命令安装，实现记忆的跨Agent共享与进化。

Alibaba Cloud@alibaba_cloud · 5月28日70

Introducing ANOLISA (Alibaba Cloud Linux 4 Agentic Edition) — the first OS designed for AI agents. As agents evolve into "digital workers," traditional operating systems have become a bottleneck. ANOLISA changes that.

译推出ANOLISA（阿里云Linux 4智能体版）——首款专为AI智能体设计的操作系统。随着智能体演进为“数字员工”，传统操作系统已成为瓶颈。ANOLISA改变了这一点。

Alibaba Cloud@alibaba_cloud · 5月28日56

Your AI Agent might be your biggest vulnerability. 🤖🔒 With 40,000+ instances exposed and supply chain risks rising, traditional security isn't enough. Introducing the Alibaba Cloud AI Agent Security Solution—engineered for the Agentic Era. Here are the 7 Best Practices to secure your digital workforce 👇 🔗 https://int.alibabacloud.com/m/1000413551/

译你的AI智能体可能是你最大的安全漏洞。🤖🔒 超过4万个实例暴露在外，供应链风险不断上升，传统安全措施已不够用。 隆重推出阿里云AI智能体安全解决方案——专为智能体时代设计。 以下是保护你数字劳动力的7项最佳实践 👇 🔗 https://int.alibabacloud.com/m/1000413551/

宝玉@dotey · 5月28日60

Agent 生成的结果要不要人工审查，取决于验证方法是不是可靠，以及模型能力是否够强，能理解任务并做好验证工作。 就写代码这种事来说，中间结果确实不需要太多人工检查了，不过开头的 Plan/Design 和最终的审查，人还是过关一下比较好。

译推文探讨AI智能体生成结果是否需要人工审查，关键在于验证方法的可靠性及模型理解与执行验证的能力。以编写代码为例，中间结果可减少检查，但初始规划与最终审查仍需人工把关。人工更适合定义总目标，而智能体的思路可能更优。

AK@_akhaliq · 5月28日65

Gamma-World Generative Multi-Agent World Modeling Beyond Two Players

译Gamma-World 超越双人对战的生成式多智能体世界建模

歸藏(guizang.ai)@op7418 · 5月28日83

http://x.com/i/article/2059811469081141248 # 开源个 Skill｜彻底解决小红、小绿书配图难题 前段时间开源了 guizang-ppt-skill，之后我自己用它做内容的时候发现一件事。 用它出的网页，单张截下来发到图文平台，反响和数据比我手工排版还很多。 我相信你之前也找到过一些这种生成3：4 卡片图的提示词或者 Skill。 他们几乎都是一个味道：Tailwind + 大色块 + emoji 堆砌 + 中规中矩的字号层级。 看完之后，我大致能理解为什么 AI 出的图文卡片那么容易被一眼识破，它们做的是网页，不是杂志。 图文卡片对比 PPT 完全是另一种生物：竖屏、信息流里 1 秒钟决定停不停下、靠图说话而不是靠字。 版式不同、节奏不同、读者不同。 于是我把它从 PPT Skill 里拆了出来，单独做成了 guizang-social-card-skill （https://github.com/op7418/guizang-social-card-skill）。 下面讲讲它好在哪、我为什么愿意在它身上花这么多时间。 ## 二、到底好在哪里 3:4 竖图是图文卡片的主战场。这个 Skill 的绝大部分设计精力都在 3:4 上，字号层级、版式比例、断行规则。 全部按 3:4 在手机信息流里被滑过的真实场景校准过。21:9 和 1:1 公众号头图也都支持。 下面从图文创作者最关心的事开始讲。 2.1 它分得清你在写什么，然后用对的方式去配 图文平台上的内容是分门类的。一篇影评和一篇产品测评，需要的视觉语言完全不一样； 一篇旅行散记和一篇职场干货，该用的版式也不是同一回事。 但绝大多数 AI 工具不管这件事，你写什么内容它都用同一套模板套出来。 结果就是所有人发的卡片都长得像一个公众号的封面流水线。 这个 Skill 内置了 11 个常见图文品类的适配规则： - 旅行 / 生活方式：杂志风为主，暖色板，大图压全屏，衬线大标题； - 职场 / 干货 / 商业洞察：网格风为主，深色背景，数据大字报版式； - 影视 / 文化：偏冷色调的杂志风，电影海报式版式，人物特写优先； - 产品测评 / 数码：网格风，对比矩阵，设备框美化截图； - 读书 / 笔记：杂志风，衬线字体，引文居中版式，留白拉满； - 美食 / 探店：高饱和杂志风，俯拍图优先，文字向四角让位； 我甚至专门为旅行博主做了地图组件。你可以把店的位置和旅行路线都标注在上面，AI 会自动帮你生成标注。 同一段文字喂给它，你说这是影评，它给你电影海报式的卡片； 你说这是产品测评，它给你带设备框的对比图。 更重要的是，它有明确不接的活： - 追星粉丝向，需要的视觉语言完全是另一脉； - 纯促销硬广，违背它强调内容性的设计哲学； - 超过 12 屏的长教程，图文形态不是长教程的最优载体。 碰到这些场景，Skill 会在开头就告诉你"你可能想用别的工具"。 这是我故意留的。能力边界比能力本身更能定义一个产品，一个什么都能做的 Skill 最后通常什么都做不好。 2.2 文字怎么压在图上 文字压图是图文卡片里最难的一件事，也是最容易暴露"AI 感"的地方。 压不好就会出现三种翻车： 1. 文字盖在人脸或产品中心位置上 1. 白字压浅色背景或黑字压深色背景读不清 1. 文字横跨整张图把本来好看的构图毁掉。 Skill 处理这件事用了三步： 1. 识别图里的主体：人脸、产品、文字密集区，版式上自动避开； 1. 算落点区域的色和明度：决定字色、要不要加蒙版、阴影该多深； 1. 字号和断行自适应：根据落点区域大小动态调整字号和换行位置，而不是写死字号让它溢出。 这套规则跑下来，卡片的"高级感"基本就立住了。读者看不出"被压上去的字"和"图本来就在那里的字"的区别。 2.3 图片从哪来：这是和市面上 AI 卡片工具最大的差别 绝大多数 AI 生成图文卡片的工具，要么让你自己上传图，要么用 emoji 顶替，要么生成一些一眼 AI 的插画。 结果就是手工补图很累，或者堆 emoji 显得很假。 这个 Skill 默认接入了三个免费可商用图库： - Pexels，支持中文搜索，大众化场景够用； - Unsplash，摄影质感最强，人物、生活、空间类内容首选； - Wallhaven，游戏、摄影、壁纸之类的图都在这里，版权混乱。 它会根据正文段落的语义自动派发搜索词、拿回图、按版式裁切到位、避开人脸或主体被切掉。 你拿到的是一张配了真实摄影图的卡片，而不是一张色块卡片。 而且它也不会死板地去寻找绝对没有版权问题的图。 能拿到的图都会告诉你，由你自己来判断要不要放版权不明确的图片。 另外，现在各个平台对 AI 带水印的问题管得很严。 目前你用的大部分 AI 生图都会有水印，而有水印就会被平台标注，一旦被标注就容易被限流，这是大家非常困扰的一个问题。 2.4 截图也是图：四件套美化 我们的很多内容用不了摄影图，得是软件截图、聊天记录、产品界面。 Skill 内置了一套截图美化： 加 macOS / iOS 风格的设备外框（browser chrome 或手机边框），用不同材质的背景托住截图，格纸、点阵、暖白或深色，让截图不再白底飘在白底上； 同时根据视觉风格自动匹配阴影层次和圆角参数，两套风格各有一套截图配方，前后一致不用手动调。 简单一句，你随手截的图，过它一道，看上去就像产品官方做的宣传图。 2.5 AI 生图：克制地用 只有前面所有找图渠道都拿不到合适素材时，Skill 才会调用 AI 生图。 生图时会强制带上风格约束词，避免出现"一眼 AI 插画"那种平庸视觉。 我宁可它少用 AI，也不想它把 AI 用成那个让所有图文卡片长得都像姐妹的元凶。 也避免你使用 AI 图片导致内容曝光受影响。 2.6 视觉系统：两套风格 + 28 个版式骨架 熟悉我之前的 PPT 的人会觉得眼熟。 这两套视觉系统和版式骨架，是从 PPT Skill 那边沿用并重新校准过来的。 我就不重复展开，简单说一下它在图文卡片场景下的样子。 两套视觉系统： - 杂志风：你在《The New Yorker》和上海译文社的封面上看到的那种排版。大留白，衬线大标题，版式不对称，文字有呼吸感。 - 网格风：Massimo Vignelli 和 Helmut Schmid 瑞士平面设计那一脉。强网格，无衬线，几何感，用色克制但精准。 28 个版式骨架，是我从过去十年看过的杂志、海报、专辑封面、电影海报里挑出来，经得起放大看的那些。 AI 在"自由版面设计"上现在还是平庸的，给它一个被验证过的骨架，它的任务就从"设计"降级成"填充"，成品稳定性立刻上来。 10 套主题色板、固定字体搭配、有限图标库，这些细节就不一一列了。 它们的逻辑是同一个：限制不是阻碍，是底线。 给一个内容创作者无限的颜色选择，他更容易做出难看的东西； 给他 10 套被验证过的色板，他做出能看的东西的概率会接近 100%。 ## 三、为什么要这么做 3.1 设计角度：杂志感非常有效 为什么走杂志风和网格风，而不是更"现代"的卡片设计? 图文卡片的本质，和印刷海报、画报、专辑封面是同一种东西。 用一张静态图，在 1 秒钟里说服一个陌生人停下来。杂志和海报在过去一百年已经把这件事研究透了。 网页设计语言是为可滚动、可交互的场景做的，搬到一张静态图上，会显得用力过猛、信息平淡。 所以这个 Skill 在视觉决策上的所有"为什么"： - 为什么大留白?留白是杂志告诉你"重点在这里"的方式； - 为什么衬线字体优先?衬线字体在大字号上有印刷品的重量感； - 为什么版式不对称?不对称会制造视觉节奏，让眼睛知道先看哪； - 为什么用色克制?社交信息流里，克制的色板反而比饱和度高的更显眼，它和周围所有"喊得很大声"的卡片不一样。 这些决策听起来都很"虚"，但它们落到代码里全是具体的常量。 字号阶比例、留白比例、网格列数、对比度阈值、断行规则。这些常量才是这个 Skill 真正的护城河。 3.2 产品角度：它是一个产品，不是一段 Prompt 做了这么多 Skill 之后，我对"Skill 这种东西到底是什么"形成了一个判断： Skill 这种东西，本质上是一个小产品。 落到这个项目里： 我给它写了 PRODUCT.md，讲清楚它解决什么问题、给谁用、不做什么。 是为了逼自己把"我到底在做什么"想清楚。我自己说不清的时候，这个 Skill 就不该被发布。 我给它打 版本号(v0.5 / v0.9 / v0.10 / v0.12)，每一版都有 CHANGELOG。 我能告诉你为什么 v0.10 是一次失败的尝试，以及 v0.12 怎么把它修回来的。 我给它写 HANDOVER.md，讲清楚交付物长什么样、能力边界在哪、什么场景该用别的工具。 我希望任何人接手它，都能在 30 分钟内对它有完整理解。 我会提前列出它不擅长的事，省得用户试错三次才发现。 为什么要费这么大功夫? 因为 Skill 生态最大的问题，是绝大多数 Skill 满足于"我能做一个"，很少有人在追求"把这件事做到极致"。 一个 Skill 应该是能站起来的小产品。Prompt 十分钟会被同行复制走，产品不会。 这件事的反面是，如果我连自己 Skill 的能力边界都说不清，我就没资格让别人把工作流交给它。 ## 写在最后 这个 Skill 让我反过来理解了我的 PPT Skill 真正做对的是什么。 真正做对的，是它从一开始就被当成产品对待。 模板多、规则细、颜色好看，都是这件事的副产品。 以后再有人问我 Skill 是什么，我会用两句话回答： Skill 是一个产品。 判断一个 Skill 好不好，看它有没有被它的作者偏爱过。 如果你也在做图文内容，希望它能帮你省掉那些被排版毁掉的好选题。 如果你也在做 Skill，希望它让你重新想一想，你做的那个东西，值不值得有 PRODUCT.md。 GitHub： https://github.com/op7418/guizang-social-card-skill 跟你的 Codex、小龙虾、ClaudeCode、Workbuddy 说：帮我安装这个 Skill：https://github.com/op7418/guizang-social-card-skill

译作者开源了 guizang-social-card-skill，这是一个专为小红书、微信公众号等图文平台设计的竖屏（3:4）卡片生成工具。它针对图文内容特点进行了视觉校准，内置了11个图文品类的适配规则，能根据内容自动选择“杂志风”或“网格风”视觉系统。该工具通过智能识别图片主体与色度来处理文字压图；默认接入Pexels、Unsplash、Wallhaven三个免费图库自动配图，以减少人工操作和规避AI生图水印的限流风险。作者强调这是一个有明确能力边界（如不做追星粉丝向、纯促销硬广）和迭代记录的产品化技能。

Alibaba Cloud@alibaba_cloud · 5月28日40

Can AI agents do more than answer questions? In our webinar, we’ll show how Quick BI Smart Q Skills help agents read dashboards, actively monitor changes, detect risks, and generate insights. Scenarios include e-commerce inventory optimization and a quant trading agent. 📅 June 2, 2026 🕑 14:00 UTC+8 👉 Reserve your spot now! https://int.alibabacloud.com/m/1000413140/

译AI智能体能否超越回答问题？ 在我们的网络研讨会中，我们将展示Quick BI Smart Q技能如何帮助智能体读取仪表板、主动监控变化、检测风险并生成洞察。 应用场景包括电商库存优化和量化交易智能体。 📅 2026年6月2日 🕑 北京时间14:00 👉 立即预约席位！https://int.alibabacloud.com/m/1000413140/

Alibaba Cloud@alibaba_cloud · 5月28日71

Meet MuleRun on Alibaba Cloud Marketplace — An always-on AI workforce for research, reports, code, design & more. Powerful enough for individuals, enterprise-ready for teams — with SSO, RBAC, private networking, team knowledge management, and seamless integrations. Think bigger. Let MuleRun do the rest. Plans from $20/mo → https://int.alibabacloud.com/m/1000413520/ #AlibabaCloud #AIAgents #AIWorkforce #FutureOfWork #EnterpriseAI

译在阿里云市场遇见 MuleRun——一个全天候的AI劳动力，用于研究、报告、代码、设计等。功能强大，适合个人使用；企业就绪，适合团队协作——支持SSO、RBAC、私有网络、团队知识管理和无缝集成。 想得更大。让 MuleRun 处理其余事务。 方案起价 $20/月 → https://int.alibabacloud.com/m/1000413520/ #AlibabaCloud #AIAgents #AIWorkforce #FutureOfWork #EnterpriseAI

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

http://x.com/i/article/2059821245093560320 # AI越强，人越忙：一个住在未来的人说了什么 著名PM人Lenny访谈了Every公司的CEO，很多观点犀利且反共识，让AI写一篇总结。 > 原始视频：https://www.youtube.com/watch?v=4D3hDmGhFhA 一家 30 人的公司，全员 AI 重度用户，人人用 Codex 和 Claude Code 干活。 按理说，这种公司应该越来越精简才对。 但过去一年，他们的员工人数翻了一倍。 这家公司叫 Every，CEO 叫 Dan Shipper。 他不是在硅谷的实验室里预测未来，他是真的住在未来。 工程师、编辑、销售、客服，所有人都在用最新的AI工具干活，然后 Dan 会把他们实战的经验和观察写出来。 去年他说 Claude Code 被严重低估，没人信，后来 Anthropic 围绕这个方向建了整个产品线。 所以当他说"AI 越强，人反而越忙"，值得认真听一听。 ## 自动化是个谎言 Dan 说这不是在抱怨，他是在描述一个他亲身经历的悖论。 他自己做了一个Benchmark，叫"高级工程师基准测试"。 起因很狼狈：他把自己的写作工具 Proof 用 vibe coding 做出来，上线第二天服务器每隔 10 分钟就崩一次。 他让 Codex 修，Codex 说修好了，然后又冒出四个新 bug，循环往复，一晚上没睡着。 后来他请了两位真正的高级工程师，分别独立重写了这个代码库。 于是他有了这个"高级工程师基准测试"：让 AI 接手同一个烂摊子，从头重写。 结果：几乎所有模型得分在 30 分左右。人类高级工程师能到 85 到 90 分。 GPT-5.5 是唯一的异类，跳到了 62 分。 而且它是唯一一个真的敢推倒重来的模型，其他模型接到"去修这些 bug"的指令，就真的去一个一个修 bug 了。 人类高级工程师会怎么做？ 他会先扫一眼代码库，然后说："这玩意儿是坨屎，我们得重写，我知道你不想听，但就是这样。" 他自己判断出来的。 模型能解决被定义清楚的问题，但"发现这个问题需要被重新定义"这件事，模型还不会主动做。 基准测试的分数在涨，但它永远只能测量人类已经想清楚、能打分的那部分工作。 剩下那部分，没法打分，因为你得先想到要问这个问题。 这就是为什么 Every 的人越招越多。 每一个 Agent 背后，都需要一个真正关心它在做什么的人。 自动化没有消灭工作，它创造了新的工作：管理自动化本身。 Dan 把这叫做"每个 Agent 都需要一个人"。 ## 工作会分裂成两种形态 Dan 的预测是：未来一年内，大多数人的工作方式会朝两个方向同时演化。 第一种：公司共用一个超级 Agent。 不是每个人一个私人助理，而是整个公司共用一个 Agent，挂在 Slack 里，所有人都能调用。 Shopify 已经有了，Ramp 也有了。 Dan 最初以为每个人都会有自己的私人 Agent，像《黄金罗盘》里每个人肩上的精灵，是灵魂的一部分。 > 黄金罗盘一口气解读版 https://www.bilibili.com/video/BV156421c74o/ 他对这个图景着迷了很久，然后彻底改变了看法。 原因很简单：Agent 需要有人照料它。 OpenClaw 刚出来的时候，Every 所有人都兴冲冲地设置了自己的 Agent，然后一个个放弃了。 因为它会坏，要 SSH 进服务器，要不停地调整，大多数人坚持不了多久。 一旦没人关心它在做什么，它就会悄悄变得没用。 所以现实的路径是：先有一个公司级别的通用 Agent，由专人负责维护，再随着模型变得更可靠，逐渐向下分裂出团队级别、个人级别的 Agent。 这个专门负责维护 Agent 的人，Dan 叫他"前沿部署工程师"，Every 内部已经有这样的岗位了。 > 前沿部署工程师模式（Forward Deployed Engineer，FDE）起源于Palantir，其核心在于通过“驻场工程师+业务专家”的协同模式，将技术能力与业务需求深度融合. 第二种：Codex 或 Claude Code 成为新的工作操作系统。 这是 Dan 更兴奋的部分，也是更难一句话说清楚的部分。 他现在处理邮件的方式是：让 Codex 打开内置浏览器，把所有邮件聚合到一个页面，然后他对着屏幕说话。 "这封律师的问题，去把过去四年的文件整理成报告发过去。" Codex 就去做了。 他已经连续 10 天保持收件箱清零，这对他来说是从没有过的事。 写文章也一样。 他在 Codex 的内置浏览器里打开 Proof，Codex 能看到他在写什么，他也能看到 Codex 在做什么，两者实时协作。 招人也是，他想找一个在 General Assembly 做过技术教育、现在又对 AI 感兴趣的人，直接跟 Codex 说。 然后他就做别的事了，回来发现 Codex 找到了一个完全符合条件的人，还在 Twitter 上关注了他。 Dan 直接发了私信，约了顿饭。 过去我们把 AI 嵌进 SaaS 工具，未来是把 SaaS 工具放进 AI Agent 里跑。 他在 Codex 里用 Proof，用的是他自己的 token，不是 Proof 这个产品的 token。 SaaS 厂商不需要烧钱堆 AI 功能，用户把 AI 带过来，SaaS 只需要让自己对人和 Agent 都友好就够了。 利润率反而可能回升。 ## CLI 时代已经结束了 Dan 说得很直接：CLI 的时代过去了，我们把它速通了。 Claude Code 火起来的时候，很多人以为是终端命令行的魔力让它好用。 Dan 认为这个判断是错的。 真正的原因是 Agent 在本地机器上有完整的访问权限，以及网上有大量关于如何使用终端的内容，让模型学得很好。这和 CLI 本身没什么关系。 Every 内部，大多数技术人员已经不把终端当主要工作界面了。 偶尔还会切进去，但主战场是 Codex、Claude Code、Cursor 这些有真正界面的工具。 GUI 本来就是为了让人更舒服而发明的，这个逻辑没有变过。 ## SaaS 不会死，Agent 会给它带来更多用户 Dan 说他现在会买 SaaS 股票。 大家都在说 Agent 会让人绕过 SaaS，直接用 AI 干活。 但 Dan 的观察是反过来的：Agent 不会替代 SaaS 的用户，它会成为 SaaS 新的用户。 Every 内部人人都用 Codex 和 Claude Code，但他们的 SaaS 支出比去年还高。 因为 Agent 在用 SaaS，大量的 Agent，高频次地调用。 需求在爆炸，不是萎缩。 他还提到一个细节：Every 的 Proof 是开源的，用户遇到问题，不是自己发邮件给客服，而是他们的 Agent 直接发一份 bug 报告，里面有精确的复现步骤，有对代码库的分析，直接变成 GitHub issue，然后 Every 的 Agent 去修。 这个闭环，比任何人工客服流程都快。 对 SaaS 公司来说，真正需要做的事情变了：不是把 AI 塞进自己的产品，而是让产品同时对人和 Agent 友好，两者能在同一个界面上协作，各自看到对方在做什么。 ## PM 和设计师，迎来最好的时代 Dan 对这两个角色极度看好。 Marcus，PM 出身，之前在 Axios 负责写作产品，带大团队做到了几千万 ARR。 后来他休息了一年，专门学会了用 Cursor。 现在他在 Every 负责写作应用 Spiral，是团队里出货最快的人之一。 Dan 说，哪怕一年前，他们也没办法安排 Marcus 做这个工作，因为那时候模型还不够好。 但现在，Marcus 的产品感和用户洞察，配上足够好的编程模型，变成了一种超强组合。 他不需要组织一整个团队来实现自己的想法，他直接去做。 设计师也一样。 以前最大的痛苦是：想到了一个绝妙的交互，工程师不想做，或者做出来不是那个味。 现在他们可以自己发 Pull Request，自己把想法变成现实。 而且，当所有人都在用 vibe coding 批量生产千篇一律的界面时，真正懂审美、懂交互的设计师反而更值钱。 能让东西看起来不像 AI 做的，本身就是一种稀缺能力。 ## AI 不会让你失业，但不用 AI 会 Dan 的判断是：大规模失业不会发生。 那些被归因于 AI 的裁员，大多数是过度招聘的修正，AI 只是一个方便的借口。 但这不意味着可以躺平。 他给出的建议只有一条，叫"骑上（驾驭）模型"。 不是因为 FOMO，不是因为害怕，而是因为好奇。 每次有新模型出来，把它用在你真正在乎的事情上。 哪怕上次试过不行，这次再试一次看看。 他自己就是这么做的，GPT-5.5 出来，他把高级工程师基准重新跑了一遍，从 30 分跳到了 62 分。 他还说了一件让人意外的事：AI 的真正前沿不在旧金山，而在每一个把 AI 用在真实工作场景里的人那里。 硅谷的人在造它，但不一定知道怎么用好它。 每次新模型出来，你是世界上最早一批发现它能做什么的人之一。 Every 在布鲁克林，不在硅谷。 但 Dan 觉得他们比大多数硅谷公司都更靠近未来，原因只有一个：他们把所有工具都真的用在真实的工作上。 这是他给出的最后一个建议：别争论 AI 会不会改变世界，去找一件你真正头疼的事，试着用 AI 解决它。 当你第一次感受到"这也行？"的那一刻，你就不需要别人再来说服你了。

译Every公司CEO Dan Shipper指出，全员使用Codex和Claude Code的公司员工数反而翻倍，揭示了AI增强工作而非替代人力的悖论。他设计的“高级工程师基准测试”显示，人类得分85-90分，而AI模型平均仅约30分，GPT-5.5最高也仅达62分。核心问题在于AI能解决已定义的问题，却无法主动识别问题需要被重新定义。他预测未来工作将分裂为两种形态：一是公司共用由专人维护的超级AI智能体；二是Codex或Claude Code等AI工具成为新的工作操作系统。他认为这不会导致大规模失业，而是要求每个人都学会“驾驭模型”，将AI用在真实工作场景中。

向阳乔木@vista8 · 5月28日61

这个访谈太好了，身边很多朋友的想法被验证。 1. AI越强，人越忙，Every过去一年员工翻倍。 2. AI 自动化创造了新工作：管理自动化。 3. 每个Agent都需要一个人照料。 4. 真正跑起来的模式是全公司共用一个Agent，专人维护，以后再分化个人Agent。 5. CLI时代已经结束了，GUI才是主战场。 6. SaaS不会死，Agent会给它带来更多用户，Dan现在会买SaaS股票。 7. AI嵌进SaaS是错误方向，应该反过来 8. . PM和全栈设计师迎来最好的时代 9. AI只是裁员借口，是过度招聘的修正。 大规模失业不会来，但不用AI的人会被用AI的人替代，这两件事不矛盾。

译观点认为，AI越强，人的工作量反而越大（如Every公司员工翻倍）。AI自动化创造了管理自动化这一新工作，且每个智能体都需要专人照料。实践中，更可行的模式是公司共用一个智能体，由专人维护。CLI时代结束，GUI是主战场。SaaS不会消亡，反而会因智能体获得更多用户。将AI嵌入SaaS是错误方向，应反向进行。产品经理和全栈设计师将迎来最好时代。AI只是裁员借口，是过度招聘的修正。大规模失业不会发生，但不会使用AI的人将被使用AI的人替代。

Berryxia.AI@berryxia · 5月28日68

最近鹅厂发了 一堆新产品啊！ 今天又来了~ Tencent直接把创意工作最烦人的痛点一次性干掉了。 再也不用在Midjourney、Runway、Figma、Blender之间来回切。 他们刚刚推出Miora，一个真正的AI创意Agent studio，现在国际版公测。 所有东西（图像、视频、UI/UX、3D）都在同一个画布上生成，agent自己理解上下文、自己调用工具、自己图像修复、本地编辑、拆背景，还能记住你的喜好。 内置一堆专业Agent：品牌、故事板、插画、UI/UX、视频、3D…… 也安排了对应的SKILLS商店：你可以用官方的、自己造的、还能分享给社区。

译腾讯推出Miora，一个整合图像、视频、UI/UX和3D生成的AI创意Agent平台，现已开启国际版公测。该平台允许用户在同一画布内完成全部创意工作，无需在Midjourney、Runway等多个工具间切换，避免了上下文丢失。Miora内置了品牌、故事板、插画、UI/UX、视频、3D等专业Agent，具备理解设计语境、自主推理、调用工具、局部编辑及记忆用户偏好的能力。同时，它提供官方的技能商店，支持用户创建、使用并分享自定义技能。

Rohan Paul@rohanpaul_ai · 5月28日65

Long-running language agents may work better if they periodically stop to consolidate memory. The problem is that today’s transformer agents get slower and more expensive as their context grows, because attention has to keep checking more past tokens. The usual fix for long context is to keep more tokens nearby, but that turns every next-token prediction into a larger search through the past. The sharper idea here is that memory is not only storage. Sometimes the hard part is converting a messy stretch of experience into a state that can actually be used later. So the paper’s idea is to add a sleep phase, where the model pauses, rereads recent context several times, writes the useful information into fixed-size memory layers, and then clears the short-term attention cache. During sleep, the model runs several offline passes over recent context, writes the result into fast weights inside its state-space blocks, then clears the attention cache. This means the model pays extra compute while sleeping, not while answering, so normal prediction can still happen with 1 forward pass. The authors test this on cellular automata, graph lookup, and GSM-Infinite math problems, where the model must use old information that is no longer sitting in its attention cache. The main result is that longer sleep improves performance, especially on harder cases that need deeper reasoning rather than just remembering a fact. The big deal is that long-horizon agents may not need to carry bigger and bigger raw context forever, because they can consolidate the important parts and safely forget the raw tokens. ---- Link – arxiv. org/abs/2605.26099 Title: "Language Models Need Sleep"

译针对当前Transformer智能体因上下文不断增长而推理变慢变贵的问题，论文提出效仿人类睡眠机制进行记忆巩固。其核心方案是加入周期性的“睡眠阶段”：模型在此阶段暂停，多次重读近期上下文，将有用信息写入固定大小的记忆层（如状态空间块的快速权重），然后清空短期注意力缓存。此离线过程使后续回答仍只需一次前向传播。在细胞自动机、图查找和GSM-Infinite数学问题上的测试表明，更长的睡眠时间能提升性能，尤其对需要深度推理的复杂任务。该思路表明，长期智能体或可通过记忆巩固实现高效遗忘与重用，不必无限携带原始上下文。

向阳乔木@vista8 · 5月28日71

如果你不会写 Agents.md ，可以直接抄作业。 或把高手的Agents 内容粘贴给你的Codex或Claude Code。 让学习其中有价值的内容，合并到自己的Agents文件。 比如有几条就很实用： ① 当用户纠正、反驳、表达不满，或本次任务暴露出可复用教训时，完成当前任务后提出一条精简规则更新建议。 先判断作用域：全局、项目或不沉淀；提出 diff，等用户确认后再改。 ② 说话直接，不奉承。不同意时给具体理由；不确定的技术事实要验证或明确说不知道，不能编造模型名、API、CLI 参数、环境变量或版本信息。 Agent 文件地址见评论

译本文介绍了为AI智能体（如Codex、Claude Code）编写指令文件（如Agents.md）的一种实用方法。核心建议是直接复制高手的Agents文件内容，粘贴给工具，让其学习并合并有价值的部分。文中强调了两个关键实践：一是当用户纠正问题时，应提出精简的规则更新建议，并区分作用域；二是要求智能体说话直接，对不确定的技术事实必须验证或明确表示不知道。

Berryxia.AI@berryxia · 5月28日41

AI Native的公司竟然都已经完全Agent化了？ 是夸大还是真实如此？ 50百万人在用自然语言造软件，却一行代码都没写过。 这就是Replit + Claude正在发生的真实故事。 Michele Catasta 16岁时就立志要让每个人都能轻松创建软件，今天Replit已经让5000多万人通过自然语言在平台上构建真实应用。 他们和Claude的合作紧密到新模型一发布，当天就能上线新版Replit Agent。 编程的门槛彻底消失了，普通人只要用对话，就能把脑子里的想法变成能跑的网站、App和工具。 这才是AI真正改变世界的样子：不再是取代程序员，更像是让“不会写代码”的人也能成为创造者。

译Replit平台与Claude深度合作，新模型发布当天即可上线新版Replit Agent。该平台已让超过5000万人通过自然语言构建真实应用，实现了用对话代替编码。Replit总裁Michele Catasta早在16岁时就立志让软件开发对所有人开放。这一合作模式展示了AI Native公司完全Agent化的趋势，让非程序员也能成为软件创造者。

SemiAnalysis@SemiAnalysis_ · 5月28日59

AGI ALERT 🚨 : 63% of sessions do not use sub-agents at all, while 25.9%  use 1-5 concurrent sub-agents. 9.8% of sessions use over 5+ parallel subagents. By using parallel subagents, it can speed up aa time to finish a task without requiring any more HBM bandwidth.

译AGI ALERT 🚨：63%的会话完全不使用子智能体，而25.9%的会话使用1-5个并发子智能体。9.8%的会话使用超过5个并行子智能体。通过使用并行子智能体，可以在不需要更多HBM带宽的情况下加速完成任务的时间。

meng shao@shao__meng · 5月28日68

2026 年面向生产环境 AI Agent 的评估指南 Agent 评估 ≠ 实验室 benchmark Agent 评估 ≠ chatbot / RAG 评估 https://www.howtoeval.com/ 看两个关键概念：Benchmark-maxxer vs. Floor-raiser Benchmark-maxxer（刷能力上限） · 让专家用户更强 · 用于 Cursor、Claude Code、Codex 等场景 · 抽象测试集、能力分数 Floor-raiser（抬可靠性下限） · 让普通用户敢用、敢信 · 用于客服、银行、医疗等自主 Agent · 读真实 trace、找致命失败模式 完整工作流（作者主张的闭环） 上线前摸底 → 离线 code-aware eval → 上线后读日志 → 分类/修复 → 回归测试 → 再上线 值得重视的洞见（与业界共识一致的部分） 1. Floor raising = Hamel Husain 式的 error analysis：先读真实交互，找「最后成功一步」和「第一次真失败」，再修模式而非个案。 2. Agent eval ≈ E2E 测试：和 OpenAI macro evals、Sentry vitest-evals 方向一致。 3. Eval 套件应是「拒绝复发的记忆」，不是覆盖想象的巨型测试集。 4. 轨迹可观测性在模型越来越「黑箱 agentic」时会更重要；未来 harness 可能坍缩进模型，端到端 + 生产监控会更主导。 5.「我不知道」是 floor-raising 的低成本杠杆——对替代人类的产品，信任 > 炫技。 值得提炼的五个观点和经验 · 先选目标：刷上限还是抬下限——多数产品 Agent 该选后者。 · 抬下限 = 读真实失败，AI 可帮忙聚类 trace，但分类逻辑要人定。 · 离线 eval 必须 code-aware、跑真路径，像单元/E2E 测试，不像 prompt 打分。 · 上线后按流量升级：stumble → issue → signal → experiment，别跳步。 · 闭环：真实失败 → 少量高信号回归 → 修 → 在线验证；别让 eval 套件变成没人看的博物馆。

译本文指出，评估面向生产环境的 AI 智能体，应与实验室 benchmark 及聊天机器人/RAG 评估严格区分。核心是确定评估方向：针对 Cursor、Claude Code 等工具的 Benchmark-maxxer，旨在刷能力上限；针对客服、银行等自主智能体的 Floor-raiser，旨在抬高可靠性下限。指南推荐一个工作闭环：上线前摸底、离线代码感知评估、上线后日志分析与修复。总结的五个关键经验包括：多数产品应优先抬下限、评估需基于真实失败案例、离线评估需代码感知、按流量分阶段升级，以及让评估套件成为防止问题复发的“记忆”。

ginobefun@hongming731 · 5月28日66

http://x.com/i/article/2059794481965408257 # BestBlogs 早报 · 05-28｜Claude Code 路径、分布式 RL 训练、SaaSpocalypse 在线阅读和收听：https://www.bestblogs.dev/explore/brief/2026-05-28 今日精选聚焦 AI 编程工具的「引擎室」：Anthropic 设计负责人 Megan 亲述 Claude Code 如何从 12 人 CLI 实验起步，在一年内拿下 51% 市场份额；Cursor 与 Fireworks 公开 Composer 2 分布式 RL 训练内幕，揭示从应用包装层到自训练基础模型的工程路径。与此同时，一篇关于「SaaSpocalypse」的深度文章正面拆解：当 Agent 直接调 API、绕过 SaaS 界面层，谁会最先倒下，Software 3.0 时代工程师的角色又将如何重写。 ## 导语 2026 年 1 月，美国软件股单月暴跌 15%，华尔街称之为「SaaSpocalypse」。同一时期，Claude Code 悄然完成了另一种意义上的颠覆：首年营收 $25 亿、编程工具市场份额 51%。两件事并非偶然同步——它们共同指向同一个转折：AI 正从工具进化为基础设施，从辅助进化为主导。 今天的早报把这个转折的三个截面放在一起：产品路径​（Claude Code 如何被设计出来）、训练工程​（Composer 2 如何被炼成）、产业冲击（SaaS 中间层如何被瓦解，工程师角色如何迁移）。读完这三篇，你会对「AI 原生」有更立体的感知，而不只是一个标语。 速览板块还覆盖了 ESMFold2 在蛋白质预测领域的「苦涩教训」时刻、Lyft 用 LangGraph 把 Agent 开发周期从半年压缩到数周的工程实践、Vibe Coding 遭遇安全清算的真实案例，以及 Airtable、Fireworks 的基础设施故事。 ## 精讲一：Anthropic 设计负责人谈 Claude Code：一年拿下 51% 市场份额的产品路径 Claude Code 的起点比大多数人想象的低得多。2024 年，Anthropic 内部一个 12 人团队决定试验一个想法：把 Claude 接入命令行，直接操作文件系统。第一个原型配置需要整整一个小时，距离所谓「产品」还差得很远。 但早期内部演示视频在 Slack 流传后，团队意识到方向是对的。接下来三个月，他们专注于三件事：打磨用户体验、消灭平台 Bug、大量内部使用积累信心。这种「先内部高强度使用，再对外发布」的节奏，成为 Claude Code 后续迭代的基本范式。 什么让 Claude Code 跑得这么快？ Anthropic 设计负责人 Megan 在 Product School 的分享里，把这归结为三个机制： 第一是流动 Pod 结构。传统产品开发里，设计师做设计、工程师写代码、PM 写 PRD——边界清晰但也僵硬。Claude Code 团队打破了这层边界：设计师会直接把代码推到生产环境，工程师主动做用户体验决策。Pod 的规模和构成随功能需求弹性调整，通常是 3 至 5 人，没有固定比例。这种跨职能的流动性，在 AI 加速迭代的环境下释放了显著的执行弹性。 第二是把质量关口移到运行时。当 AI 让代码生成速度提升 10 倍，传统的 PRD、静态 Mockup 等质量控制环节就成了瓶颈。Anthropic 的解法是把验收标准前移到真实运行行为：团队内部高频部署原型，监控实际使用模式，用运行时数据而非文档勾选来决定是否推进。这个方法在 AI 原生组织里有深刻意义：它不是「更快写代码」，而是「把反馈回路压缩到极致」。 第三是Bottom-up 企业采用。Claude Code 没有走自上而下的销售路线，而是从工程师个人使用开始，自然扩散到团队，再渗透到组织层面。这种采用曲线在金融基础设施、零售等高度监管行业也同样奏效——先赢得工程师，再赢得决策者。 度量体系的迁移 Megan 特别强调了一个度量迁移：从 Token 用量转向用户留存与管道营收。这看起来是小事，背后却是产品哲学的转变——衡量 AI 工具价值的标准，从「有没有人用」变成了「用了之后会不会留下、会不会推动业务增长」。 管理层须亲自上手、持续操刀 Repo，不是作秀，是为了在迭代加速的环境里保持对产品的真实感知。这条原则在 AI 原生组织里具有普遍价值：领导者的直接参与，是维持迭代弹性的结构性保障，而不仅仅是传递信号。 为什么值得深读 这篇内容不是产品方法论的泛泛总结，而是一个具体产品在极速增长过程中形成的操作手册。流动 Pod、运行时质量门控、Bottom-up 采用——这三个机制彼此咬合，缺一不可。如果你在思考 AI 原生团队该怎么运转，这是目前能找到的最具体的参照之一。 值得额外关注的是 Anthropic 的女性领导力比例：CPO、工程负责人、平台产品负责人、平台工程负责人和总裁均为女性。这不是一个单独的事实，而是组织文化的折射——一个真正重视多元视角的组织，往往在打破固有边界（比如「设计师不写代码」）这件事上也更有行动力。 阅读建议：结合精讲二一起看。Claude Code 是产品侧的 AI 原生实践，Composer 2 是模型训练侧的 AI 原生实践，两者共同勾勒出「AI 原生」的两种形态。 阅读链接：Anthropic 设计负责人谈 Claude Code：一年拿下 51% 市场份额的产品路径 ## 精讲二：Cursor 与 Fireworks 如何用分布式 RL 基础设施训练 Composer 2 编码智能体 大多数 AI 编程工具把通用 LLM 套上提示词工程就算完事。Cursor 走了一条完全不同的路：从头训练一个专门为软件工程优化的模型，并且为此搭建了一套异步分布式 RL 基础设施。 为什么要自己训模型？ Federico（Cursor 研究负责人）给出了一个直观的类比：LLM 的参数空间就像一块存储介质，位数有限。通用大模型把这些位分配给数学、多语言、常识推理等各类能力；Cursor 的做法是把所有位都集中到软件工程这个窄域，用专注换效率。 结果是：更小、更低延迟的模型，在代码编辑任务上超过了比它大得多的通用模型（如 GPT-4 Opus），运行成本低一个数量级。这是 Rich Sutton「苦涩教训」的一个有意义的反例——在足够窄的领域，专注的数据维度比纯粹的规模更有效。 Composer 2 的双轴训练路径 Composer 2 的训练分两个阶段： 第一阶段是持续预训练，以 1 万亿参数 MoE 模型 Kimi 2.5（30B 活跃参数）为基础，大规模运行代码和 web token 的下一个 token 预测，拓宽模型的基础分布，编码基础库知识和工程模式。 第二阶段是大规模强化学习。模型进入主动 RL 循环，在 Cursor 环境框架内执行工具调用、获得奖励信号，逐步学会在真实代码编辑场景中做出正确决策。与预训练「展示如何写代码」不同，RL 阶段的目标是「学会在工具和结果中导航」。 异步流水线：让 GPU 全程满负荷 标准 RL 管线的一个固有问题是计算空转：推理阶段训练器空转，权重更新阶段推理引擎空转。Cursor 与 Fireworks 合作构建的异步流水线像一条持续运转的工厂产线：推理 Rollout 和权重更新同步进行，GPU 全程满负荷，消除了昂贵计算资源的空转损耗。 三个工程难题与解法 除了异步流水线，团队还公开了三个关键工程决策： - Delta 权重压缩：在分布式训练中，每次权重更新都需要在全球节点同步，数据量巨大。Delta 权重压缩只传输权重的变化量，把全球同步流量降低了约 20 倍。 - Router Replay Tracking：稀疏 MoE 架构（Sparse Mixture of Experts）的一个棘手问题是数值漂移——不同专家路由的使用频率不均，导致训练不稳定。Router Replay Tracking 通过记录路由选择历史来稳定这个过程，保持数值对齐。 - 自摘要上下文压缩：编码智能体在真实工作中会产生超长轨迹，百万 Token 规模的上下文管理是一个挑战。Composer 2 把上下文压缩能力训练成模型的内生能力，而不是外挂规则，让智能体在长轨迹中保持推理连贯性。 一个值得思考的更大问题 Cursor 的路径揭示了一个范式：当模型训练成本不再是天文数字，专注于特定领域的「小而精」模型将会越来越多。通用大模型提供基础能力，垂直专有模型在特定任务上以更低成本实现更高性能。这个趋势在今天的速览里也有印证——ESMFold2 在蛋白质预测上用同样的逻辑实现了对 AlphaFold3 的超越，只是在生物信息领域，通用路线反而是赢家。领域特性决定了什么时候应该专注、什么时候应该通用。 为什么值得深读 这篇不是概念介绍，而是 Cursor 和 Fireworks 工程师级别的实践总结。如果你在做 AI 应用层，这篇帮你理解专有模型训练的真实成本和收益；如果你在做 ML 基础设施，异步流水线和 Delta 压缩是可直接参考的工程方案。 结合精讲三看：Composer 2 展示的是「工程师如何用 Software 3.0 的方式工作」，而精讲三在问的是「工程师的工作本身会被如何改变」。 阅读链接：Cursor 与 Fireworks 如何用分布式 RL 基础设施训练 Composer 2 编码智能体 ## 精讲三：2026：软件的末日、工程师的陨落、平庸的消失 2026 年 1 月，美国软件股经历了一场 2008 年金融危机以来最惨烈的单月跌幅：标普北美软件指数下跌 15%。不是因为业绩崩塌，而是因为华尔街意识到一件事——SaaS 的护城河正在被 AI Agent 从根部挖空。 华尔街给这场抛售起了个名字：SaaSpocalypse，软件末日。 被做空的是哪一层？ 过去二十年，SaaS 的商业逻辑建立在一个前提上：把企业功能打包成操作界面，按席位收取月费。界面即产品，界面即护城河。员工用久了形成肌肉记忆，替换成本极高，这是 SaaS 估值飞涨的核心驱动力。 AI Agent 打破的，正是这个前提。Salesforce CEO Marc Benioff 在 X 上发了一条帖子，语气平静、但意味深长：「所有 AI Agent 都能通过 API 直接访问 Salesforce Headless 360，无需浏览器。」这家靠界面起家的商业帝国，亲手把自己的界面变成了可选项。 逻辑链条是这样的：Agent 绕过 SaaS 界面直接调 API → 界面不再是护城河 → 席位订阅模式失去基础 → 依赖界面习惯维持转换成本的 SaaS 中间层，壁垒被 AI 复制。 📷 但不是所有软件都会死。a16z 的分析框架给出了一个清晰的区分：AI 大幅降低了重建一套系统前 80% 的成本，而剩余的 20%——特殊事项、审批流程、合规要求——仍然是「可用原型」与「真正替代品」之间的分水岭。 被集中做空的，是价值落在「前 80%」的中间层：以数据分发为核心的 Thomson Reuters（单日暴跌 16%）、以流程协调见长的 Atlassian、标准化在线法律服务平台 LegalZoom。它们的共同特征：壁垒恰好集中在最容易被 AI 复制的区域。 而管理财务账目的后台系统、涉及合规审计的数据平台，则属于那难以逾越的「20%」。ERP 的迁移，a16z 把它比作「病人在跑马拉松时做开胸手术」。 软件会变少吗？答案是杰文斯悖论 直觉上，AI 替代软件 → 软件总量减少。但 1865 年的一个经济学规律说了相反的故事：蒸汽机效率越高，英国消耗的煤炭反而越多——效率提升让资源变便宜，催生了大批原本不存在的使用场景，导致总消耗净增长。这就是杰文斯悖论。 Token 正走同一条路。GPT-4 问世时，每百万 Token 调用成本 37.5 美元；两年后，GPT-5 High 降至 3.63 美元，性能却突破人类博士水平。成本下降超过 99%，但 Token 总消耗量呈指数级攀升。OpenClaw 之父 Peter Steinberger 晒出他的账单：过去 30 天，个人级别消耗 6030 亿 Token，单月花费超过 130 万美元。 每一次 Token 价格的下跌，都不只是让现有软件运行得更便宜，而是解锁了一批之前根本不存在的软件。Vibe Coding 让非技术人员能直接把想法变成应用；OpenDesign 把「从 GitHub 链接到完整 slides」这个工作流变为现实——这在两年前根本不存在。 工程师的角色迁移：从写代码到 Software 3.0 文章的结尾是最值得停下来想一想的部分：工程师的角色正从「写代码」迁移向 Software 3.0——设计评估体系与奖励环境。一位干了二十年的资深工程师丢了工作，他说：「我花了五秒钟把所有情绪过了一遍，然后就明白，好吧，我的职业生涯完了。」 平庸的产出正在加速消失，但这不意味着工程师集体消失——而是角色的质变。能设计评估体系、能定义奖励函数、能理解 Agent 的边界和失败模式的工程师，将会更稀缺、更有价值。 协议层：MCP 正在成为新的 USB 接口 文章还深入分析了软件「液化」后的基础设施需求。Anthropic 在 2024 年底推出的 MCP（Model Context Protocol）正在成为 Agent 时代的 USB 接口——一次接入，所有支持 MCP 的 AI（Claude、ChatGPT、Cursor、Copilot 等）均可调用。在 MCP 之前，每让 AI 接入一个新工具都要单独写一套适配代码；MCP 把这件事标准化了。这是软件从「固定形态的产品」变成「按需生成的介质」之后，必须出现的基础管道。 与今日其他内容的关联 这篇文章的论述与精讲一、二构成了一个完整的三角：Claude Code（产品侧 AI 原生）+ Composer 2（训练侧 AI 原生）+ SaaSpocalypse（产业侧 AI 冲击）。三篇合在一起，描述的是同一场变革的不同切面。今天速览中的 Lyft LangGraph 平台、Airtable 语义搜索层、Fireworks 独角兽崛起，也都是这场变革在不同应用层面的具体落地——当你把它们放在这篇文章的框架里，会看到一幅更清晰的全景图。 阅读建议：如果你是工程师，重点看「工程师角色迁移」和「Software 3.0」部分；如果你在做产品或投资，重点看「转换成本光谱」和「杰文斯悖论」部分。文章较长，但论证密度高，值得完整阅读。 阅读链接：2026：软件的末日、工程师的陨落、平庸的消失 ## 速览 ESMFold2：蛋白质领域的「苦涩教训」 BioHub 团队推出开源蛋白质结构预测模型 ESMFold2，在多样化数据上扩展简单的 BERT 类 Transformer，在蛋白质相互作用（尤其是抗体预测）方面超越了 AlphaFold3 等专用模型。这标志着计算生物学迎来了自己的「苦涩教训」时刻——通用架构加海量数据，再次击败精心设计的专用架构。和今天精讲二的逻辑形成有趣对照：Cursor 走专用模型路线赢，但生物信息领域是通用路线赢，背后的关键差异在数据分布和任务边界。Alex Rives 与 BioHub 团队的这次探索，对正在考虑「该专注还是该通用」这个问题的 AI 研究者有直接的参考价值。阅读原文 Lyft 如何用 LangGraph 把 Agent 开发周期从半年压缩到数周 Lyft 利用 LangGraph 和 LangSmith 构建了一个自助式 AI Agent 平台，让运营团队、VoC 负责人和产品经理能够通过提示词和配置独立开发和迭代客服 Agent，无需每次都依赖 MLE 介入。核心架构是路由器型多 Agent 系统：一个元 Agent 作为有状态路由器，用 Command(goto=...) 把请求分发给专用子 Agent，每个子 Agent 并行运行安全检查。LangSmith 负责追踪、仪表盘和 LLM-as-a-judge 评估。结果是 Agent 开发周期从约六个月压缩到数周——这和精讲三「软件液化」的论断高度呼应：当非技术人员能直接配置 Agent，软件开发的边界正在重新定义。阅读原文 VibeSec 的清算时刻 Thoughtworks 全球营销团队在把一个 Vibe Coding 原型扩展到生产环境时，遭遇了两次险情：AI 建议把存储桶设为公开访问（会泄露敏感品牌资产），以及给予过于宽泛的 Token 权限。两次都是人类工程师提出质疑才得以阻止。核心结论：Vibe Coding 加速了原型到产品的路径，但 AI 生成的代码需要确定性的护栏，而不仅仅是更好的提示词，才能达到生产安全标准。这是当下「Vibe Coding 热潮」最值得警惕的真实案例之一。阅读原文 Airtable 如何为 AI 功能构建语义搜索层 Airtable 有一个关键数据观察：任何一周内，75% 的客户数据库都处于空闲状态。这个事实驱动了整套架构决策——选择 Milvus、采用每库分区策略、HNSW 索引加冷热数据分离。当一个分区在内存中时查询响应极快，冷分区可以在秒级内从存储重新加载。这不是「选了哪个向量数据库」的故事，而是「一个数据特性如何决定了一整套工程决策链」的案例，对有类似冷热数据分布的团队有直接参考价值。阅读原文 万字入门 AI Infra：大模型的数学与优化逻辑 从 RMSNorm、Softmax、Causal Mask 到 Sampling，逐层拆解大模型推理中核心操作的数学原理与 Infra 优化逻辑。核心论断：AI Infra 优化的本质是用数学上的等价变换，或对精度的适度妥协，换取更高的硬件利用率。文章从「为什么需要归一化」这个最基础的问题出发，解释 FP16 数值上限 65504 为何会成为工程约束，再一路推导到 Softmax 的数值稳定性技巧和 Causal Mask 的实现选择。不到 5 万字，覆盖从高中数学到 FP16/BF16 精度权衡的完整知识链。适合想从数学和工程两个维度同时理解大模型基础设施的读者，也是今天精讲二 Composer 2 训练工程的极佳知识背景补充。阅读原文 别再盯着 AI Agent 干活：构建运行时上下文引擎 Brandon Walsenuk 认为，可靠的自主编码 Agent 需要「运行时上下文引擎」，而不只是更长的提示词或更多工具权限。他指出了三个常见误区：朴素 RAG 因「搜索满足感」效应导致信息遗漏（Agent 找到第一个看似匹配的答案后就停止探索，错过更完整的技术现实）；单纯连接 MCP 管道解决不了组织知识缺失；给 Agent 更多权限不等于给它更好的判断力。运行时上下文引擎需要理解组织知识、协作关系、权限边界和实时架构冲突，这是一个系统设计问题，而不是提示词优化问题。结合精讲二的 Composer 2 自摘要上下文压缩一起看，两者都在解决同一个问题：如何让 Agent 在长期运行中保持对上下文的准确感知。阅读原文 AI 基础设施新晋独角兽：Fireworks、Baseten、OpenRouter Fireworks 和 Baseten 双双跻身独角兽，OpenRouter 宣布 $113M B 轮，过去六个月周 Token 处理量从 5T 增至 25T。这个数字本身就是杰文斯悖论的实时数据点：基础设施越高效，消耗的 Token 量不减反增。这期 AI 新闻汇总完整覆盖了 AI 基础设施独角兽的崛起，以及 Agent 编排工程、长程推理、模型架构更新和生产工具的最新进展。值得注意的是，Fireworks 同时也是今天精讲二 Composer 2 训练的基础设施合作方——同一家公司在一天内以两种身份出现在今天的早报里，这本身就说明了 AI 基础设施层正在迅速从工具变成关键路径。阅读原文 ## 补充阅读 CodeRabbit 如何用 Claude 构建 Agent 编排系统 CodeRabbit 在生成任何代码之前先运行结构化规划阶段，弥合开发者意图与 AI 输出之间的差距。每周 review 200 万 PR、服务 15,000+ 客户的规模背后，是一套「先规划、再生成」的编排逻辑——规划阶段帮助 Agent 在行动之前理解变更的意图和范围，减少「代码能跑但没做对事情」的问题。这和今天速览里「VibeSec 清算时刻」形成互补：一个说 Vibe Coding 的安全风险，一个说规划层如何系统性地降低 AI 代码生成的偏差。适合正在思考如何提升 AI 代码生成可靠性的工程团队。阅读原文 使用 Codex 构建自我改进的税务智能体 OpenAI 与 Thrive Holdings 合作开发的 Tax AI，把从业者的修正转化为结构化评估目标，让 Agent 自主改进——准确率达 97%，吞吐量提升 50%。核心思路是把生产反馈直接接入评估循环，让改进不再依赖工程师手动推进：从业者的修正 → 归因到具体评估目标 → Codex 生成候选修复 → 回归测试验证 → 工程师审核并关闭循环。这套自改进框架和精讲三「Software 3.0」里「设计评估体系与奖励环境」的工程师新角色高度契合。适合正在思考「Agent 如何自我优化」的团队。阅读原文 使用 LLM 保护源代码安全 Anthropic 六步循环法：威胁建模 → 沙箱搭建 → 漏洞发现 → 验证 → 分类 → 修复。发现漏洞已经可以大规模并行化，瓶颈已转移到验证、分类和修复。截至 2026 年 5 月 22 日，Anthropic 在开源软件中已披露 1,596 个漏洞，其中仅 97 个完成修补——这个数字本身就是现状的真实写照：AI 发现的速度远超人类修复的速度。适合安全团队和关注 AI 辅助安全审计的工程师。阅读原文 Agent Harness Engineering 综述 CMU、Yale、JHU、Virginia Tech、Amazon 联合出品，用 ETCLOVG 七层框架（执行环境、工具接口、上下文管理、生命周期编排、可观测性、验证评估、安全治理）系统梳理 Agent Harness 工程，覆盖 170+ 开源项目。核心判断：Agent 在长任务、真工具、真实环境中失败，往往不是模型不够聪明，而是系统没把它管好。只改工程外壳不改模型，有研究在 coding benchmark 上实现了最高 10 倍提升；固定 GPT-5.2-Codex Agent 通过重构系统 prompt 和加入中间件，在 Terminal-Bench 2.0 上从 52.8% 提升到 66.5%。适合正在把 Agent 从演示推向生产的工程团队。阅读原文 淘天集团「数字 SRE」：AI 主导代码质量治理 从 AI 辅助开发到 AI 主导开发的四阶段演进，淘天集团分享如何让「数字 SRE 员工」自动发现、端到端修复 Blocker 问题，开发者只在关键节点兜底审核并发布兜底。这是国内工程团队把 AI 主导开发落地的少见公开案例：AI 负责语法级修复这类有明确规则的 Blocker，人类保留关键审核节点——这正是精讲三「工程师角色迁移」从「写代码」到「审核和边界设定」的具体实践。阅读原文 DiT 残差流的收敛瓶颈与 DAR 解法 南京大学 LAMDA 与阿里巴巴智能引擎团队提出 Diffusion-Adaptive Routing（DAR），用可学习、时间动态的跨层路由替代 DiT 中固定的残差累加，实现近 9 倍训练加速并提升生成质量。论文发现标准残差路由在深层会出现三类问题：PreNorm dilution（历史累积量越来越大，新层想改变表示须对抗膨胀的主干）、time-agnostic 融合无法适应不同去噪阶段的信息需求、梯度漂移。DAR 用动态路由权重让模型按 timestep 自适应调整跨层信息流。适合关注视觉生成模型训练效率的研究者和工程师。阅读原文 ## 今日阅读路径 时间有限，推荐优先读这三篇： 1. 2026：软件的末日、工程师的陨落、平庸的消失（精讲三）——理解当前产业变局的整体框架，SaaSpocalypse 背后的商业逻辑和工程师角色迁移。这是今天内容的「坐标系」，先读这篇，其他内容会更有定位感。 1. Anthropic 设计负责人谈 Claude Code：一年拿下 51% 市场份额的产品路径（精讲一）——具体、可操作的 AI 原生产品开发手册。流动 Pod、运行时质量门控、Bottom-up 采用，三个机制对任何在思考 AI 原生组织的人都有直接参考价值。 1. VibeSec 的清算时刻（速览）——Vibe Coding 安全风险的真实案例，15 分钟读完，能帮你在下一个 AI 代码项目里提前避坑。 时间充裕的扩展路径： - 精讲二（Composer 2 训练工程）+ 速览「Lyft LangGraph 平台」——从模型训练到 Agent 平台，构建对 AI 基础设施的完整认知。 - 补充阅读「Agent Harness Engineering 综述」——为精讲二和速览「运行时上下文引擎」提供理论框架支撑。

译Claude Code 首年营收 25 亿美元，占据编程工具 51% 市场份额，其成功源于流动 Pod 结构、运行时质量把控及自下而上的采用策略。Cursor 与 Fireworks 合作，基于 1 万亿参数 MoE 模型 Kimi 2.5 训练了专用编码模型 Composer 2，其异步分布式 RL 流水线与工程优化实现了在特定任务上超越大型通用模型。与此同时，“SaaSpocalypse” 现象揭示了当 AI 智能体直接调用 API 绕过 SaaS 界面层时，传统软件中间层正面临冲击。

meng shao@shao__meng · 5月28日60

AI 应用层还没死，但要避开「Yellow Brick Road」！ @joeschmidtiv (a16z) 这篇文章指出：AI 应用层仍有巨大机会，但机会不在模型实验室正在全力押注的「通用智能体」路径上，而在垂直、复杂、系统级的「工作流深处」。 创始人、求职者普遍焦虑：OpenAI、Anthropic 会不会把应用层全部吃掉？ Schmidt 认为这种焦虑「对了一半」： · 对的部分：实验室确实会吞掉大量横向、通用、低复杂度的应用表面 · 错的部分：「应用层」不是铁板一块，不能一概而论 他用《绿野仙踪》做比喻： · 黄砖路（Yellow Brick Road） = 实验室正在走的路 · Oz 的其他地方 = 创业公司该去的地方 什么是「黄砖路」？为什么危险？ 黄砖路指：拿最强模型 + 现成连接器（Slack、Salesforce、GitHub 等）+ 简单 Agent 编排 → 做一个通用 AI 同事。 问题在于，这正是 Cowork、Codex、Claude Code 在做的事。 如果你做的是同样的连接器、同样的浅层编排、没有子 Agent 和深度配置、也没有分发——你是在跟实验室正面竞争，大概率是死路。 黄砖路上的问题（代码生成、写作、图像等）有一个共同特征：产品质量随模型 raw capability 线性提升，每多投一美元预训练/后训练，产品就更好。这类问题天然适合实验室。 「Oz 其他地方」的机会在哪里？ 机会在复杂、垂直、多步骤、多角色的问题上，价值不只来自模型能力，更来自让输出可信、合规、可运营的一整套脚手架。 典型特征： · 跨系统 Gather context，再经多个人类审批节点 · 涉及 legacy 系统 · 需要确定性结果，不能容忍模糊 · 与真实商业结果绑定（成交、核保、合规审查） 实验室自己也承认搞不定全部——所以才会砸重金做 forward-deployed joint ventures（派驻式联合项目），帮企业定制配置。如果「下一个模型版本就能解决」，他们不会投这笔钱。 为什么实验室最终也「吞不掉」Oz 其他地方？ 1. 数据与学习飞轮 · 大量行业知识不在训练集里：未写下的规范、潜规则、从业者脑中的经验 · 两层飞轮： · 跨客户：同类问题的模式识别 · 单客户：该机构特有的例外与决策逻辑 · 横向工具难以设计合适的 UX 来捕获这些知识；垂直玩家可以围绕工作流定制界面 2. 模型变异性管理 · 实验室只能推自家模型；应用公司可以跨厂商选模型——不同子任务用最合适的（开源微调、竞品 API 等） · 还替客户做脏活：每次模型升级重跑 eval、针对 edge case 重调 prompt、平滑迁移 · 客户得到的是「全市场最优智能 + 升级连续性」，而非「请自行迁移到我们的新模型」 3. 成本优化 · 全走 Opus 4.7 = 负毛利 · 垂直公司按子任务路由：前沿模型做难题、中端做 bulk、自研/微调小模型做窄任务 · 实验室定的是「$X 能买到的最低智能」；应用公司卖的是「完成该工作流所需的最低 dollar cost」 4. 治理（Governance） · 成为客户在该垂直领域跑 AI 的控制平面：权限、审计、agent 能做什么、实际做了什么 · 吸收监管复杂度（HIPAA、SEC/FINRA、律师协会规则等） · 横向玩家无法同时成为「一百个垂直领域」的合规伙伴 核心 trade-off：实验室必须 everywhere for everyone → 无法 great at one thing。 三个自检框架：你在不在「Oz 其他地方」？ 测试 | 黄砖路（危险）| Oz 其他地方（机会） · 工具与步骤测试 | 一步、一个工具、结果可容错（如搜 Google Drive） | 多步、多工具、输出需过 partner/法庭/监管 · 系统 vs 工具测试 | 客户已有工作流上的「智能插件」；实验室出竞品客户可换掉你 | 客户通过你的系统跑工作；你是 orchestration layer · 对冲基金/P&L 测试 | 客户为 generic capability 付费（Claude seat 可替代）| 客户为 workflow-specific outcome 付费（成交、核保、合规） 最终判断：两条路都会出大赢家 · 黄砖路：实验室赢——拥有模型 + 横向工具的分发 · Oz 其他地方：应用公司赢——若拥有 system of work（工作执行面、数据捕获、治理） 模型层是可替换的（fungible）；工作系统不可替代。 新一代 enterprise software 会建在路上之外——应用公司成为整合并交付各类新模型的层，而客户依赖的是那套系统。

译a16z 合伙人指出，AI应用层仍有巨大机会，但机会不在模型实验室押注的“黄砖路”上。这条路径指用最强模型加简单编排做通用AI工具，与实验室正面竞争胜算极低。真正的机会在“Oz的其他地方”——复杂、垂直、多步骤的工作流。其价值不仅来自模型，更来自确保输出可信、合规、可运营的系统脚手架。应用公司相比实验室的优势在于：能构建专属的数据学习飞轮、跨模型管理与优化成本，并吸收监管复杂度。核心结论：模型层可替换，但深度集成的工作系统不可替代。

Greg Brockman@gdb · 5月28日48

OpenAI for self-improving tax agents:

译OpenAI for self-improving tax agents: [引用 @samaysham]：在 @ThriveHoldings，我们与 @OpenAI 合作开发了一款产品，为我们旗下遍布全国的30多家会计师事务所自动化税务准备工作。 本季度，该产品处理了超过7000份报税表。但我认为更有趣的是，随着会计师们的使用，该产品实现了有意义的自我改进。

Rohan Paul@rohanpaul_ai · 5月28日77

"There's about 30-35mn software engineers in the world today. We wanna make all of them 10 times more efficient, and then we think there is a lot more than 10 times more software to build." ~ Cognition CEO Scott Wu Talking about their $1 Bn fund raise today. Their revenue climbed from $37M to ~$500M in 1 Year. ---- From "Bloomberg Technology" YouTube channel, (link in comment)

译Cognition AI完成超10亿美元融资，投前估值达260亿美元。其年化收入一年内从3700万美元增长至约4.92亿美元。其核心产品Devin定位为可自主工作的初级工程师，超越传统代码助手，能通过多步骤工作流进行规划、测试和部署。Cognition采用模型无关策略，结合自身模型与OpenAI、Anthropic的大语言模型。CEO Scott Wu表示，目标是提升全球约3000-3500万软件工程师的效率10倍。