Alibaba Cloud@alibaba_cloud · 5月19日56

AI inference tasks are long and unpredictable—traditional MQ throttling just doesn't cut it. 📉 Apache RocketMQ 5.x introduces LiteTopic for fine-grained, millisecond-level traffic governance. Master your AI traffic today! 🔗 https://int.alibabacloud.com/m/1000413081/ #RocketMQ #AI

译AI推理任务耗时长且不可预测——传统消息队列限流已力不从心。📉 Apache RocketMQ 5.x 引入 LiteTopic，实现细粒度、毫秒级流量治理。 立即掌握您的AI流量！🔗 https://int.alibabacloud.com/m/1000413081/ #RocketMQ #AI

Claude@claudeai · 5月19日72

Live from Code with Claude London: we're launching self-hosted sandboxes (public beta) and MCP tunnels (research preview) in Claude Managed Agents. Run agents inside your own perimeter, with your security controls applied by default.

译来自Code with Claude伦敦现场：我们正在Claude Managed Agents中推出自托管沙箱（公测版）和MCP隧道（研究预览版）。 在您自己的安全边界内运行代理，默认应用您的安全控制。

歸藏(guizang.ai)@op7418 · 5月19日57

英伟达开始交付自己设计的通用 CPU NVIDIA Vera了。 重点优化的是长期高并发和高吞吐的场景，专门用来做Agent 编排和工具调用的中枢。 模型可以在 GPU 上进行推理，但所有的调度编排和调用工具都放在这个 CPU 上。 这种密集 Agent、密集常驻的强 IO、内存和调度压力的工作，其实都是 CPU 的工作，所以他们专门做了一个 CPU。 这次交付由英伟达自己上门，将这个 CPU 送到了：Anthropic、OpenAI、xAI、OCI，其中 xAI 是由老马亲自接待的。

译英伟达正式开始交付其首款自研通用CPU——NVIDIA Vera。该芯片专门针对AI Agent时代高并发、高吞吐的长期运行场景进行优化，核心功能是作为Agent编排与工具调用的调度中枢。它旨在将原本由GPU承担的密集调度与I/O任务分离，由CPU专门处理，从而构建更高效的AI系统。首批Vera CPU由英伟达高管亲自送至Anthropic、OpenAI、xAI及甲骨文云（OCI），其中xAI由马斯克亲自接待。此举标志着英伟达正从GPU主导的推理市场，深入布局为AI Agent时代定制计算基础设施的新赛道。

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

Chubby♨️@kimmonismus · 5月19日62

Intelligence too cheap to meter. This is the real deal. Composer 2.5 is an efficiency-beast

译智能成本低到难以计量。这是真正的突破。Composer 2.5是效率怪兽。

Anthropic@AnthropicAI · 5月19日71

Anthropic is acquiring @stainlessapi, an SDK and MCP server platform that has powered every Anthropic SDK since the earliest days of our API. Read more: https://www.anthropic.com/news/anthropic-acquires-stainless

译Anthropic正在收购@stainlessapi，这是一个SDK和MCP服务器平台，自我们API早期以来就为所有Anthropic SDK提供支持。 阅读更多：https://www.anthropic.com/news/anthropic-acquires-stainless

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语言项目的公开征集。

ClaudeDevs@ClaudeDevs · 5月19日73

What are best practices for running Claude Code at scale? New blog post on what we've learned from teams running it across multi-million-line monorepos, decades-old legacy systems, and distributed microservices: https://claude.com/blog/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start

译在大规模运行Claude Code有哪些最佳实践？ 关于我们从团队在数百万行单体仓库、数十年历史的遗留系统和分布式微服务中运行的经验总结，新博客文章已发布： https://claude.com/blog/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start

向阳乔木@vista8 · 5月19日39

小火箭Shadowrocket的规则有点复杂，安装 Tailscale 后更是乱套。 关掉火箭就能用远程桌面，打开就连不上。 最后，掏出Codex，它自己做网络联通测试，完成本地规则数据库修改，终于修复了。 经验：电脑的网络问题也都可以交给AI，以后都用写Shadowrocket 配置规则。

译用户在使用Shadowrocket时发现，安装Tailscale后网络连接出现异常：关闭Shadowrocket时可正常进行远程桌面连接，但开启后便无法连接。最终通过AI工具Codex自动执行网络联通测试，并修改本地规则数据库成功修复问题。此案例表明，复杂网络配置问题可由AI高效解决，未来或可广泛应用于自动化编写Shadowrocket等工具的配置规则。

AYi@AYi_AInotes · 5月18日68

跑了三个最实用的HTML工具， 大家浏览器打开就能用， 但先给铁汁们一个更值钱的东西， 怎么判断AI产出该用HTML还是Markdown， 记住这一句话够了， 这个东西生成完之后， 是被读，还是被用， 如果是被读，就用Markdown， 如果是被用，那就用HTML， 听起来好像很简单是吧， 但实际上咱们80%的活其实卡在这个中间， 就是说你以为是应该被读的，但它实际上是被用的， 比如项目计划，大多数人交付的时候会写成MD文档，对面的老哥可能看了三天就忘了， 但同样的信息如果做成可点击的项目页，对面老哥可能就愿意反复回来看， 我实测了最好用的场景，都是打开浏览器就能跑的: 1️⃣项目计划页:时间线+风险表+流程图，改完直接分享链接就行 2️⃣数据看板:把CSV或API结果丢给AI，生成带排序筛选的交互表格 3️⃣临时小工具:Prompt调参器、正则测试器、文件格式转换器等 大家可以把你的下一个项目计划或报告，让AI输出成HTML试试， 你会发现自己以前用Markdown交付，浪费了多少回头率 👇

译推文提出了一个核心判断标准：根据AI产出内容的最终用途来选择格式——如果是为了“阅读”，就用Markdown；如果是为了“使用”，则用HTML。推文指出，许多内容（如项目计划）本质上属于“使用”范畴，但常被错误地用Markdown交付，导致效果不佳。为此，作者推荐了三种适合用HTML生成的实用场景：项目计划页（含时间线与交互图表）、数据看板（支持排序筛选的交互表格），以及各类临时小工具。

OpenRouter@OpenRouter · 5月18日58

New: an easier-to-use playground sidebar that adapts to the type of model you're trying See @Kling_ai Video v3 in action:

译新功能：一个更易使用的 playground 侧边栏，可适配您正在尝试的模型类型 查看 @Kling_ai Video v3 的实际效果：

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

不得不说，哪怕在大模型这么厉害的今天。 DeepL的翻译质量还是很优秀。 淘宝上几块钱买个 API，配置到Bob翻译里，用了一年多了。。。

Yuchen Jin@Yuchenj_UW · 5月18日48

GPU shortage is worse than ever. H100s cost more today than they did 3 years ago, and you cannot get them on-demand. The big AI labs have locked up most of the supply for years. I’m worried university researchers and individual developers simply won’t be able to get GPUs.

译GPU短缺比以往任何时候都更严重。 H100现在的价格比三年前更高，而且无法按需获取。 大型AI实验室已锁定了未来数年的绝大部分供应。我担心大学研究人员和独立开发者将根本无法获得GPU。

Berryxia.AI@berryxia · 5月18日73

前几天大家一起聊中转站的“暴利”、“捡钱”、“掺水”、“造假”等等 但是，有个核心问题，我给小菜鸟如何判断呢？ 这不巧了韭二（以下简称92）把他搞了个项目，还特么开源了。 他最近把2026年中文市场涌现的三个AI API中转站安全检测工具全部跑了一遍。 他发现一个让人大跌眼镜的事儿：你花钱买的“直连”Claude或GPT，很可能早已被安静地动手脚。 92对比了三款工具的核心检测能力、方法论和透明度后，发现差距极大。 开源工具api-relay-audit走的是双论文锚定路线，把AC-1工具调用改写、AC-2错误响应泄漏、上下文截断等常见攻击全部拆成可验证步骤，每一步都给出clean/anomaly/inconclusive三态判定，还自带透明日志。 hvoy. ai更适合小白用户，cctest. ai则主打一键黑盒检测，但完全闭源。 92认为，最靠谱的还是api-relay-audit的透明度和可审计性，安全工具本身必须可被审计。 他把完整对比、方法论、短板和功能速查表写成一篇长文，并把自己的工具完全开源。 感兴趣的可以安装，地址评论区。 记得给给他一颗Star～

译针对AI API中转站可能存在的“掺水”、“造假”等安全风险，开源项目api-relay-audit通过双论文锚定路线，对AC-1工具调用改写、AC-2错误响应泄漏、上下文截断等常见攻击进行可验证的三态判定，并提供透明日志。对比hvoy.ai和cctest.ai等工具，其透明度和可审计性更为可靠。项目作者已将完整方法论、对比结果和功能速查表公开，并开源了该检测工具。

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消耗，实现一次编译后多次调用，提升效率并降低成本。

Chubby♨️@kimmonismus · 5月17日57

Energy, not compute, may become the real bottleneck for AI. The proposed Stratos data center in Utah could consume up to 9 GW of power at full buildout, making it one of the largest data center projects in the world. That is roughly comparable to New York City’s average electricity demand - or the output of about nine nuclear power plants - for a single data center.

译能源而非算力，可能成为人工智能的真正瓶颈。 犹他州拟建的Stratos数据中心在完全建成后，耗电量可能高达9吉瓦，使其成为全球最大的数据中心项目之一。 这大致相当于纽约市的平均电力需求——或约九座核电站的发电量——仅用于一个数据中心。

Rohan Paul@rohanpaul_ai · 5月17日27

ASML is the invisible backbone of AI and semiconductor revolution. Without ASML: 🚫 No NVIDIA H100 🚫 No AI supercomputers 🚫 No GPT-3/4/5, or Claude 🚫 No scalable data centers They make this $400M machines that basically sit behind all advanced chips

译ASML是人工智能和半导体革命的无形支柱。 没有ASML： 🚫 就没有英伟达H100 🚫 就没有AI超级计算机 🚫 就没有GPT-3/4/5或Claude 🚫 就没有可扩展的数据中心 他们制造这些价值4亿美元的机器，基本上支撑着所有先进芯片的生产。

AYi@AYi_AInotes · 5月17日67

说个所有AI创业者都不愿意承认的事实： 现在做一个AI工具的门槛已经降到了地板， 普通人做一个AI工具都只需要一天， 但学会用它干成一件事，却至少得一个月， 感觉像是AI时代的一个悖论😅 5.7M 阅读 23 万点赞的这条推，表面看是游戏圈在自嘲， 视频展示的是一颗树莓 237 万个高斯点，做一筐扔进游戏直接 2 FPS， 但如果把游戏开发四个字去掉，你会发现这是 2026 年所有 AI 工具用户的共同故事。 我先先把这个梗讲透： 原推作者 @DanyBittel 用 90 组焦点堆栈、每组 68 张照片，重建出来这颗树莓，总共 237 万个高斯点， 这是一种叫 3D Gaussian Splatting 的新型 AI 重建技术，简称 3DGS， 视觉效果有多吓人呢？ 每一颗小果粒的绒毛、表面光泽、半透明的果肉质感全都纤毫毕现，在 RTX 3060 Ti 这种中端显卡上还能跑 100+ FPS，前提是只有这一颗🙃 @nazbowling102 的笑点在这里，老哥迫不及待想看哪个独立游戏开发者一激动，把一整筐这种树莓当道具扔进游戏里，然后纳闷为啥游戏跑 2 FPS🤣 我觉得这个吐槽之所以 5.7M 阅读，是因为它戳中了游戏圈的集体回忆—— Monster Hunter Wilds 一颗八角茴香用了 2048 乘 4096 的纹理直接卡帧，Cities Skylines 2 给行人建了高精度牙齿模型，全都是一个小道具毁全局的真实事故。 但这条推真正让我深入研究的还不是游戏开发的事，虽然我是个游戏爱好者，但对于游戏开发是个小白。 ayi干货输出开始！ 咱们把游戏开发四个字去掉，这个故事正在所有 AI 工具领域都能同步上演， AI 生成的图，单张精美绝伦，但批量做长素材时质量瞬间崩溃， AI 生成的视频，10 秒钟惊艳，1 小时长片的管线一团乱， AI 生成的代码，单个函数完美，扔进项目跑起来一堆隐藏依赖， 共性是同一条规律： 新工具让做出来这件事的门槛降了 100 倍， 但用得动、跑得稳、能交付这件事的门槛反而升高了 10 倍。 过去做不出来是因为没人能做，现在做出来是因为工具太好用， 但优化、压缩、整合、降本的脏活累活没人帮你干，AI 工具时代真正稀缺的不再是创造力，而是生产工程能力。 所以我觉得这条树莓推真正的价值，不是教育游戏开发者怎么做 LOD， 是给所有正在被新工具喂得满嘴流油的人一个提醒： demo 级和生产级永远隔着一条河， AI 让前者变得免费， 后者还是要你自己游过去的！

译一条关于游戏开发的推文引发广泛共鸣：利用3D Gaussian Splatting技术生成的单颗树莓模型精度极高且运行流畅，但若将一整筐此类高精度模型放入游戏，帧率会骤降至2 FPS。这现象揭示了AI工具领域的普遍困境：生成单张图像、短视频或代码片段时效果出色，一旦进行批量生产或系统集成，就会出现质量崩溃、性能低下或依赖混乱等问题。其核心在于，新工具极大降低了创意demo的制作门槛，但将其转化为稳定、可交付的生产级应用，所需的工程优化与整合能力反而变得更加稀缺和关键。AI让创意唾手可得，但跨越demo到生产的鸿沟，仍需扎实的工程能力。

SemiAnalysis@SemiAnalysis_ · 5月17日41

MLSys 2026 is next week! MLSys is the conference that showcases the most important system problems AI researchers are tackling, and SemiAnalysis will be there. Here are some research that we found interesting 🧵

译MLSys 2026下周开幕！ MLSys是展示AI研究者正在攻克的最重要系统问题的会议，SemiAnalysis将亲临现场。 以下是我们发现的一些有趣研究 🧵

向阳乔木@vista8 · 5月17日65

跟小龙虾（OpenClaw）比，Hermes代码质量和稳定性都好很多！ 搭个Hermes硅基飞书群，每个机器人用独立模型和网关，远程协同工作。 1. 终端中执行 hermes profile create [机器人名字] 比如创建了西游记团队，tangseng、sunwukong等。 2. 给每个机器人配置模型和IM连接方式，指令 [机器人名字] setup 比如给孙悟空用OpenAI Codex GPT 5.5 ，给唐僧用GLM 5.1 turbo，给猪八戒用 Kimi 2.6 ，给沙僧用DeepSeek v4 Flash等。 3. 绑定飞书（支持多个）或微信机器人（只能绑一个） setup流程中会有提示，空格选中，回车配置，飞书或微信的话扫二维码就行，配置比之前太容易了。 4. 重启网关 [机器人名字] gateway restart

译Hermes框架在代码质量和稳定性方面显著优于OpenClaw。用户可通过命令行快速创建多个独立机器人角色，并为每个角色分别配置不同的AI模型（如OpenAI GPT、GLM、Kimi等）和即时通讯平台（如飞书、微信）连接。配置过程通过引导式指令和扫码完成，简化了网关设置，实现了多机器人的远程协同工作流。

SemiAnalysis@SemiAnalysis_ · 5月17日60

SERIOUS & COOL: AIPerf -- a sub-repo of the Nvidia Dynamo project focused on benchmarking LLM workloads -- just accepted an upstream contribution from AMD! As far as we know, this is one of the first contributions from AMD accepted into an Nvidia repository. This is an awesome moment for the open-source community as it allows high quality vendor agnostic code for all to use. We hope to see more contributions in the future such as upstreaming parts of RIXL into NIXL, instead of maintaining as a separate fork.

译NVIDIA的AI性能基准测试项目AIPerf接受了来自AMD的上游代码贡献，这被认为是AMD代码首次被纳入NVIDIA官方仓库。此举被视为开源社区的重要时刻，意味着高质量的、不依赖特定厂商的代码将能供所有人使用。社区期待未来能有更多此类合作，例如将AMD的RIXL部分代码整合进NVIDIA的NIXL，而非维持独立分支。

Peter Steinberger 🦞@steipete · 5月17日43

BlackBar 0.2.0 is live for @useblacksmith 📈 24h vCPU + workflow graphs 🔔 opt-in status/job notifications 🧰 richer Blacksmith job rows 🟢 compact status badge Tiny menu bar, less CI guesswork. https://black.bar

译BlackBar 0.2.0 已为 @useblacksmith 上线 📈 24小时vCPU与工作流图表 🔔 可选状态/任务通知 🧰 更丰富的Blacksmith任务行 🟢 紧凑状态徽标 小巧菜单栏，减少CI猜测。 https://black.bar

Chubby♨️@kimmonismus · 5月16日38

This is what you’re competing with. 1.3 million tokens in 30 days. Burn more tokens or you’re not gonna make it.

译这就是你要面对的竞争。 30天130万token。 燃烧更多token，否则你将无法成功。 [引用 @steipete]：The latest CodexBar update renders API costs wayyyy nicer. https://codex.bar

Berryxia.AI@berryxia · 5月16日61

长上下文LLM的军备竞赛已经转向：长上下文LLM竞争已转向：从堆token转向精细的架构优化。 Sebastian Raschka（《Build a Large Language Model From Scratch》作者、前统计学教授. 刚发布《Recent Developments in LLM Architectures》，用可视化方式拆解Gemma 4到DeepSeek V4的硬核优化。 这些不是纸上谈兵，全是已在生产环境落地的真实方案。 关键转变：长上下文的瓶颈不再是「能否支持更多token」，而是「如何聪明分配计算」。 以前大家卷上下文长度，现在真正拉开差距的，是这些精细的架构选择。 正在做长上下文模型、Agent或RAG的团队，这篇文章的视觉图和效率对比特别值得细读。 阅读全文见评论区~

译长上下文大型语言模型的竞争焦点已从单纯增加上下文长度，转向通过精细的架构优化来提升计算效率。Sebastian Raschka的新文章通过可视化方式，解析了从Gemma 4到DeepSeek V4等模型在生产环境中应用的关键效率优化技术，如KV缓存共享、分层嵌入和压缩注意力等。这些技术旨在更智能地分配计算资源，已成为决定模型性能差异的关键。对于从事长上下文模型、智能体或RAG开发的团队而言，文章中的视觉图解与效率对比具有重要的参考价值。

Peter Steinberger 🦞@steipete · 5月16日57

Lossless is a really interesting concept for OpenClaw to have an "infinite" context window/memory. It compacts conversations in blocks that the model can refer to, building a tree to look up past messages.

译Lossless为OpenClaw引入了一个实现“无限”上下文窗口或记忆的有趣概念。其核心机制是将对话内容压缩成可引用的数据块，并构建树状结构以检索历史信息。最新发布的lossless-claw 0.10.0版本旨在确保长对话的持久性，关键改进包括：采用全局压缩替代增量压缩以减少缓存抖动，保护高频提示缓存，修复启动与重启时的转录异常，并简化了新安装的配置流程。

meng shao@shao__meng · 5月16日56

当管理者被要求"hands-on/亲自动手"时，到底该做什么？ 过去十年，硅谷主流观点是 "manager 就是 manager，IC 就是 IC"，分工清晰。 @joulee 发现最近硅谷资深管理者在两场晚宴上无一例外地说自己被期待 hands-on，风向好像变了： · AI 把动手成本压到极低：以前一个 feature 要排期、对齐、调资源；现在一个人一个周末就能 ship。 · 高层不再容忍"纯协调者"：如果管理者不亲自感受 AI 工具，就无法判断团队效率、技术方向和人才水平。 · 但管理者的时间没有变多：所以"做什么"成了真正的难题。 Julie 找到了四类合适的 IC 工作： 1. 优化团队系统 - 内部效率工具：让团队跑得更快的内部杠杆（沟通工具、知识库、技能培训） 2. 维护产品品味 - 生活质量改进：你一直觉得别扭、但排不上优先级的小问题 3. 讲述团队故事 - 庆祝物料：总结团队成果的视频、图文叙事 4. 指明前进方向 - 愿景作品：展示"团队未来能去哪"的酷炫 demo 贯穿四类的共同特征： · 非关键路径——做砸了不影响交付 · 杠杆型——要么放大团队、要么对外表达 · 管理者视角独有——别人做不了或不会做 关键禁忌：不要碰关键路径 · 关键路径任务有 deadline、有依赖、有不可预测的复杂度 · 管理者的日程被会议、1:1、决策切碎 · 一旦你成为瓶颈，要么交付崩，要么管理崩，通常两者都崩

译硅谷资深管理者普遍被要求亲自动手使用AI工具，以判断团队效率与技术方向。管理者应选择非关键路径、高杠杆且视角独有的工作，具体包括优化团队内部效率工具、改进产品生活质量、制作庆祝团队成果的物料以及创建展示未来愿景的演示。核心禁忌是介入有关键截止日期和依赖关系的核心产品任务，以免因日程碎片化成为瓶颈，导致交付或管理失败。

SemiAnalysis@SemiAnalysis_ · 5月16日57

As we've come to expect from a DeepSeek release, DeepSeek V4 comes with more flashy ML systems optimizations. This time? MegaMoE, a 1400 line fused CUDA kernel that computes the entire MoE forward pass. Let's see how it works (1/4) 🧵

译正如我们对DeepSeek发布的期待，DeepSeek V4带来了更多炫目的ML系统优化。 这次是MegaMoE，一个1400行融合CUDA内核，可计算整个MoE前向传播。 让我们看看它是如何工作的（1/4）🧵

宝玉@dotey · 5月15日71

http://x.com/i/article/2055299017211248640 # Forward Deployed Engineer：AI 时代的新宠岗位，到底干什么？ ## 一场 AI 岗位的“军备竞赛” 先看看最近 AI 圈的一个关于新职位 Forward Deployed Engineer（FDE）的新闻。 Google 正在 FDE 岗位上加倍投入，并且大幅简化了面试流程。Google Cloud 的 CEO 托马斯·库里安（Thomas Kurian）宣布，他们在市场营销（Go-To-Market）团队下成立了一个全新的、以 AI 为核心的部门，并且正在为此疯狂招募 FDE。 听说，他们的面试流程已经被大幅压缩，从过去长达数周、多达 4-6 轮的面试，缩短到了仅仅两天内的两轮面试。看来 Google 对填补这些空缺不仅是渴望，简直可以说是迫不及待了。 就在周一（5 月 11 日），OpenAI 宣布成立了“OpenAI 部署公司”（The OpenAI Deployment Company）。这是一家由私募股权基金投资 40 亿美元成立的独立实体，估值高达 140 亿美元，投资方包括 TPG、Advent 等。看起来 OpenAI 本身并不是直接的投资方，而是扮演着合作伙伴的角色。 公告特别提到了 FDE，并表示他们的职责是“与业务领导者、运营人员和一线团队紧密合作，精准定位 AI 能产生最大价值的领域，并围绕 AI 重新设计组织的基础设施和关键工作流程，最终将这些收益转化为持久稳定的系统”。 由此可见，FDE 将在 OpenAI 的企业销售业务中扮演极其关键的角色，他们的任务就是确保公司的 AI 系统能在客户的真实业务中跑通，并实实在在地创造价值。将这块业务外包给新成立的“部署公司”，也能让 OpenAI 腾出手来，专心研发更强大的 AI 模型；而面对客户的那些繁琐对接，就交给合作伙伴和他们的 FDE 去搞定吧。 与此相关的一个动态是，OpenAI 收购了 Tomoro。这是一家总部位于英国、成立于 2023 年的 AI 公司，在英国、亚洲和澳大利亚拥有 150 名 FDE。这也是“OpenAI 部署公司”成立以来的第一笔收购。 Anthropic 也在如法炮制，创建属于自己的独立 FDE 咨询公司。上周一（5 月 4 日），Anthropic 发布了一份极其含糊的公告，宣布了这项新业务，但连名字都没透露，投资细节也寥寥无几。 已知的投资方包括 Anthropic 本身、黑石（Blackstone）、Hellman & Friedman 以及高盛（Goldman Sachs）。这家新公司的使命是与“各行各业的中型企业合作，将大语言模型（LLM）Claude 引入他们最重要的业务运营中”。 Anthropic 的算盘似乎和 OpenAI 打得一模一样：拉外资建个独立公司，让里面的 FDE 帮企业把 Claude 整合进系统。可以预见，这么一来，这些企业购买的 Claude Token 数量绝对会创下历史新高。 ## 用大白话给你讲清楚 FDE 到底是啥 那么 FDE 到底是啥？全称是 Forward Deployed Engineer，简称 FDE。这个名字直译过来是“前线部署工程师”，但光看名字很难理解它到底干什么。 > 一句话版：驻扎在客户公司现场写代码的工程师。 详细点说，这个岗位介于软件工程师、方案架构师和咨询顾问之间，但更实操。他们直接坐在客户公司里，用自家 AI 技术帮客户搞定实际问题。 你可能会问，这不就是咨询顾问？还真不太一样。顾问通常给你 PPT，告诉你“怎么做最好”，FDE 直接给你代码，帮你做到最好。方案架构师一般画架构图、写技术方案，FDE 除了这些，还得上手敲代码、调接口、现场 debug。 如果要给具体的比例，大概是：25% 写代码，50% 集成和调试，25% 开会和沟通。实际上，真正安静写代码的时间可能更少。 ## 其实，Palantir 才是鼻祖 说起 FDE，这其实不是 AI 时代新冒出来的，而是 Palantir 在 2010 年代就玩熟的招数。 Palantir 做数据分析平台，早期服务的全是美军和情报部门，客户需求都是机密，根本不能用常规方法沟通。于是 Palantir 干脆把工程师派到客户那里常驻，近距离观察客户需求，现场快速迭代。 这些驻场工程师（Palantir 叫他们 Delta）干得不仅仅是交付项目，还有更重要的任务：在客户端提炼出通用需求，反馈回产品团队做成标准化功能。 到 2016 年，Palantir 的 FDE 已经比普通工程师还多了，真正定义了这个岗位。 ## 同样押注 FDE，三家公司走了三条不同的路 **OpenAI 最猛。**成立 OpenAI Deployment Company，TPG、麦肯锡、贝恩、凯捷全来了，连估值都搞到 140 亿美元，直接买了一家英国公司，150 名 FDE 到位即用。承诺 17.5% 的最低回报率，更像在投基建。 **Anthropic 稳一些。**找了黑石、高盛、Apollo 等华尔街巨头成立合资公司，先期投入 15 亿美元，主攻中型企业市场。这些投资方手里一大堆企业，天然就是 Claude 模型最好的用户池。 **Google 最传统。**自己雇人，FDE 岗位分布全球，薪资还不低——在美国高阶的总包能到 40 万美元以上。但最大的区别是，Google 的 FDE 拿的是 Google 股票，OpenAI 和 Anthropic 的 FDE 则在独立公司，跟母公司利益没直接关系。 ## 给你翻译一下 Google FDE 招聘启事背后的“人话” 企业招聘启事这种东西，经常让人看不懂，咱们翻译一下： 原文 翻译 - “你是客户环境中的嵌入式建设者” - “你要去客户公司里坐着写代码。” - “不同于传统咨询，你是创新者兼建设者” - “活确实很像咨询，但我们想让你多写点代码。” - “你得有创始人心态” - “没人写需求文档，需求变了、项目拖了，都是你的锅。” - “高能动性” - “别指望额外资源，啥都得靠自己。” - “白手套级复杂 AI 系统部署” - “客户怎么要求你都得接着，哪怕要求很离谱。” - “把真实世界的洞察反馈给产品路线图” - “你提的工单，产品经理可能会偶尔瞄一眼。” 虽然听起来有点吐槽，但实际上每家公司的 JD 都类似。有个心理准备，才更清楚自己适不适合。 ## 灵魂拷问：FDE 到底还是不是咨询？ 看三个维度。 1. 一是组织归属。Palantir 的 FDE 归产品团队，跟母公司同进退。但 OpenAI、Anthropic 的 FDE 属于独立公司，信息流通、身份认同和发展路径都会打折。 1. 二是反馈环。FDE 最大的价值是发现客户需求后反哺给产品。但独立公司和母公司间隔着一道组织鸿沟，这个反馈通道可能会受阻，FDE 就容易沦为纯“写代码的咨询”。 1. 三是利益绑定。Google 的 FDE 拿母公司股票，利益一致。OpenAI、Anthropic 的 FDE 就拿独立公司的收益了，跟母公司估值涨到天上去也没你份。 结论就是，OpenAI 和 Anthropic 的 FDE 已经更接近咨询，Google 则更接近传统的 FDE 模式。 ## 谁该关注 FDE？ 分三类人看： - 新毕业生：绝佳机会，大厂的软件岗越来越少，但 FDE 大量招人，你能快速接触到企业级 AI 项目，成长更快。 - 资深工程师：可能会觉得“降级”，客户换得勤，缺乏长期归属感；但如果你正想创业或者更接近业务，FDE 是个深入企业需求的绝佳窗口。 - 非技术背景：门槛仍然挺高，不是学几个月 Python 就能搞定的事。 ## AI 行业的竞赛，已经悄然转向 过去三年，AI 行业一直拼的是模型大小、跑分高低。现在问题变了——大多数企业不缺模型，缺的是有人帮他们把模型接进业务。 OpenAI 一出手就是 40 亿美元，Anthropic 也拿了 15 亿，Google 招聘流程压到两天。这些巨额投入表明：AI 公司的赚钱方式变了，从卖模型到卖落地。 往大了说，每花 1 块钱训练模型，就可能得再花 1 块钱让模型真正跑起来。 FDE，恰好就站在这个转折点的最前沿。

译Forward Deployed Engineer（FDE）是AI落地应用的关键角色，负责在客户现场部署和集成AI系统。近期，OpenAI成立独立部署公司，Anthropic与华尔街巨头合作，Google也简化流程大力招聘，显示行业重心正从模型竞赛转向商业落地。FDE工作介于工程师与顾问之间，需写代码、调试并深度理解业务。此岗位为毕业生提供了接触企业级项目的机会，也帮助资深工程师贴近业务需求，成为推动AI创造实际价值的重要力量。

OpenRouter@OpenRouter · 5月15日74

Three big upgrades to BYOK on OpenRouter 🔑 1/ Add multiple keys for the same provider in one workspace and set the order they're tried in. Useful for rotating across rate limits, separating dev and prod credentials, or distributing usage across team accounts!

译OpenRouter BYOK 三项重大升级 🔑 1/ 可在同一工作空间为同一服务商添加多个密钥，并设置调用顺序。 便于在速率限制间轮换、区分开发与生产凭证，或在团队账户间分配使用量！

OpenClaw🦞@openclaw · 5月15日60

The latest OpenClaw release is ~3.5x faster 🦞 We run end-to-end RTT tests against every published npm release, every 6 hours, over real message channels (here: Telegram, using the brand new bot-to-bot communication). No more silent regressions. Runners are all running on @useblacksmith CI. Catching slowdowns before you do.

译最新版OpenClaw速度提升约3.5倍 🦞 我们每6小时通过真实消息渠道（此处使用Telegram，采用全新的机器人间通信）对所有已发布的npm版本进行端到端RTT测试。不再有静默回归。 所有运行器均在@useblacksmith CI上运行。 在您察觉之前捕捉减速问题。

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进入全面工程化应用阶段。

Orange AI@oran_ge · 5月15日61

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

歸藏(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版本仍在开发中。

SemiAnalysis@SemiAnalysis_ · 5月15日58

Cerebras IPO today had a 90% gain, the team had some pre-launch insights - but first Jordan discusses the Drone Police squad chasing Fox News reporters during Trump’s China visit.

译Cerebras今日IPO涨幅达90%，团队早有预判——但乔丹首先讨论了特朗普访华期间无人机警察小队追访福克斯新闻记者的事件。

Epoch AI@EpochAIResearch · 5月15日61

Servers account for 60% of the total cost of owning a 1 GW AI data center. A typical 1 GW AI data center costs about $38B in up-front capital and $0.9B/year to operate. Annualizing the capital expenses over equipment lifespans, that equates to $8.5B/year, with $5B for servers.

译服务器占有一座1吉瓦AI数据中心总持有成本的60%。 典型的1吉瓦AI数据中心前期资本投入约为380亿美元，年运营成本为9亿美元。将资本支出按设备寿命折算为年度成本，相当于每年85亿美元，其中50亿美元用于服务器。

AYi@AYi_AInotes · 5月15日69

做LLM生产落地的开发老哥们，可以看Andrew Ng刚出的这门课，免费版可以看所有视频和基础代码。 这个课程不是又一遍Attention is All You Need的数学推导， 也不是又一套调prompt的玄学技巧， 更不是又一个从零写Transformer的玩具项目，它直接把LLM的黑箱给你拆开了。 会让你亲手玩自回归循环， 看着模型一个token一个token生成，看着某一步概率采样走偏， 看着幻觉是怎么一步步从无到有长出来的。 甚至会让你拖动滑块调整temperature，实时看到输出多样性的变化， 看到不同的采样策略到底在改变什么。 以及让你点开每一层每一个注意力头， 看到哪个头在管语法， 哪个头在管事实， 哪个头在管逻辑推理。 最狠的是推理优化部分， 这是所有生产工程师每天都在踩的坑，慢推理，OOM，成本爆炸。 以前所有人都告诉你要换更大的GPU。要加更多的机器。 这门课告诉你， 70%以上的延迟根本不是参数量的问题，是内存带宽的问题，是注意力计算的问题。 量化，KV Cache，Flash Attention，投机解码， 每一个技巧都能让你的模型速度翻2到5倍，精度损失几乎可以忽略。 而且这次是和AMD深度合作，由AMD工程副总裁亲自主讲。 终于有一门课不是只讲CUDA了，终于有人开始讲硬件感知的优化了。 虽然会调用API的人已经满大街都是了，但能看穿模型内部。能诊断问题。能优化成本的人，才是未来三年最稀缺的。 我觉得这门课最大的价值，是它终于把Transformer从一个学术概念，变成了一个你可以摸得到，可以调试，可以优化的工程工具。

译吴恩达与AMD合作推出新课《Transformers in Practice》，旨在将Transformer从学术概念转化为可调试的工程工具。课程提供交互式可视化，让开发者深入模型内部，观察自回归生成、注意力头分工及幻觉产生过程。核心聚焦生产中的推理优化难题，指出大部分延迟源于内存带宽与注意力计算，而非参数量。课程将系统讲解量化、KV Cache、Flash Attention、投机解码等关键技术，以实现数倍速度提升且精度损失极小。其最大价值在于培养能诊断问题、优化成本的稀缺人才，弥补了仅关注CUDA而缺乏硬件感知优化的市场空白。

SemiAnalysis@SemiAnalysis_ · 5月15日60

During their last Google Cloud Next conference in Las Vegas, Google unveiled their new inference-focused TPU, featuring a novel network topology called "Broadfly". By leveraging a high-radix design, Google can scale up to 1,152 TPUs in a single pod. Compared to Ironwood, this enables a 4.5x larger pod size while reducing network diameter and with a maximum of just 7 hops between any two chips. (1/3) 🧵

译在拉斯维加斯举行的最近一次Google Cloud Next大会上，谷歌发布了专注于推理的新型TPU，其采用名为"Broadfly"的新型网络拓扑结构。 通过采用高基数设计，谷歌可在单个集群中扩展至1,152个TPU。 与Ironwood相比，这使集群规模扩大4.5倍，同时减少网络直径，任意两芯片间最多仅需7次跳转。(1/3) 🧵

Berryxia.AI@berryxia · 5月15日69

我刚听完 Patrick OShaughnessy 最新一期播客，直接让人坐不住了！ 嘉宾是 Anthropic 的 CFO Krishna Rao，这是他第一次公开长谈。 两年前他加入时，公司年化营收 run-rate 只有 2.5 亿美元。 今天已经暴涨到 300 亿美元。 中间他还主导募集了近 750 亿美元资金。 但真正让我头皮发麻的，是他手里握着的真正权力： Anthropic 所有算力的采购、分配和动态调度。 Trainium、TPUs、GPUs 该怎么切、优先给训练还是推理、今天这批资源先给哪个项目，全由他最终拍板。 他已经签下超过 1000 亿美元的 AI 算力采购承诺。 我突然意识到一个最残酷的核心暴论： 在 2026 年最顶尖的 AI 公司里，真正坐在驾驶舱掌控全局的人，可能根本不是首席科学家。 而是这位 CFO。 因为模型能力正在快速趋同，算力才是真正的命门和稀缺资源。 谁能拿到更多算力、谁能把算力用得更狠，谁就赢。 这期播客全程高能，从「Cone of Uncertainty」的不确定性决策，到前沿智能回报为什么越来越高，再到 Anthropic 内部如何用 Claude 写代码，干货多到离谱。 想真正看懂 AI 公司内部到底是怎么打仗的，这期必须完整听完。 你觉得下一阶段，决定 AI 公司生死的最大变量，到底是模型能力，还是算力获取和分配能力？ `

译Anthropic首席财务官Krishna Rao在首次深度访谈中透露，其加入公司两年来，年化营收从2.5亿美元激增至300亿美元，并主导筹集近750亿美元资金。他手握超过1000亿美元的AI算力采购承诺，全权负责Trainium、TPUs和GPUs等资源在训练与推理间的动态分配。访谈核心指出，随着模型能力趋同，算力获取与调配能力已成为顶尖AI公司的决胜关键，CFO可能取代首席科学家成为战略掌控者。节目还深入探讨了不确定性决策、前沿智能回报递增等议题。

Baidu Inc.@Baidu_Inc · 5月14日61

As agent applications move into larger-scale deployment, the cloud stack behind them has to scale with them. At Baidu Create, our EVP and President of Baidu AI Cloud, Dou Shen, announced a new full-stack AI cloud purpose-built for large-scale agent applications, with upgrades spanning Agent Infra and AI Infra. A dedicated cluster powered by our proprietary Kunlunxin AI chip has already supported the training of a key model in the ERNIE 5.1 series.

译随着智能体应用迈向更大规模部署，其背后的云技术栈也需同步扩展。 在百度Create大会上，百度集团执行副总裁、百度智能云事业群总裁沈抖宣布推出专为大规模智能体应用打造的全新全栈AI云，其升级涵盖智能体基础设施与AI基础设施。 基于我们自研的昆仑芯AI芯片构建的专用集群，已支持ERNIE 5.1系列中一个关键模型的训练。

Baidu Inc.@Baidu_Inc · 5月14日57

As agent applications move into larger-scale deployment, the cloud stack behind them has to scale with them. At Baidu Create, our EVP and President of Baidu AI Cloud, Dou Shen, announced a new full-stack AI cloud purpose-built for large-scale agent applications, with upgrades spanning Agent Infra and AI Infra. A dedicated cluster powered by our proprietary Kunlunxin AI chip has already supported the training of a key model in the ERNIE 5.1 series.

译随着智能体应用迈向更大规模部署，其背后的云技术栈也必须随之扩展。 在百度Create大会上，百度集团执行副总裁、百度智能云事业群总裁沈抖宣布推出全新的全栈AI云，专为大规模智能体应用构建，其升级涵盖智能体基础设施和AI基础设施。 基于我们自研的昆仑芯AI芯片的专用集群，已经支持了ERNIE 5.1系列中一个关键模型的训练。