歸藏(guizang.ai)@op7418 · 5月13日70

Skills 已经更新了这个带地图的版式和地图组件 大家让自己的 AI 更新这个 Skills 就行。 地图支持放大缩小和拖动，以及 AI 可以在地图上做任意的标记。

译Skills功能已更新，新增了带地图的版式和地图组件。用户可让各自的AI更新此技能。更新后的地图支持缩放、拖动等基本交互操作，并且AI能够在地图上进行任意标记。这增强了AI在空间信息处理和可视化方面的能力。

Peter Steinberger 🦞@steipete · 5月13日48

Codex was debugging a Telegram issue and needed a new token, so it used Peekaboo to open the Telegram Mac app, talked to botfather and just did it. Computer Use is amazing. https://peekaboo.sh

译Codex在调试Telegram问题时需要新令牌，于是使用Peekaboo打开Telegram Mac应用，联系botfather并完成了操作。 计算机应用令人惊叹。https://peekaboo.sh

Berryxia.AI@berryxia · 5月13日76

最近我鼓吹苹果的端侧模型和统一内存的优势！ 前有MLX ，现在不断拓展的格式都出来比如之前也分享过的oMLX又有更新！ Apple Silicon上的本地AI已经把云端大模型的很多优势直接干掉了。 oMLX 0.3.9.dev2直接把Gemma 4的MTP视觉路径、DFlash引擎、ParoQuant全塞了进来，图文解码速度大幅提升； 还新增了omlx launch copilot，一键接入Claude / Codex / OpenClaw等顶级工具； oQ自动建proxy解决显存不够的问题； 管理界面也加了重启服务器按钮。 以前本地AI总觉得“差点意思”，现在它在速度、集成度、易用性上越来越离谱地强。 这才是真正把AI从云端拉回你自己电脑的节奏。 项目地址：https://github.com/jundot/omlx

译oMLX项目更新至0.3.9.dev2版本，集成了Gemma 4的MTP视觉路径、DFlash引擎和ParoQuant技术，显著提升了图文处理速度。新增一键启动copilot功能，可便捷接入Claude等工具，并通过oQ自动代理解决显存瓶颈。这些改进大幅增强了本地AI在速度、集成与易用性上的表现，正推动AI能力从云端向个人电脑回归。

宝玉@dotey · 5月13日57

1. Skills 是技能，领域知识，工作流等等，相当于怎么干好一件事的说明书。 比如 https://github.com/anthropics/claude-for-legal 仓库里有个 skill 叫 nda-review，在 commercial-legal/skills/ 文件夹里。里面是一份 SKILL.md，写清楚：审 NDA 时先比对哪些条款、按团队 playbook 打绿黄红三档、什么情况要升级、输出格式是 Word 修订模式。 它就是一份给 Claude 看的工作手册，本身不干活。 2. Agent 是真正执行任务的主题，除了主要执行的 Agent，通常自定义的 Agent 分两种：Subagent 和 Scheduled agent 2.1 Subagent 是单独派出去干一摊子活的“分身” 举个仓库里的例子：corporate-legal:tabular-review 这个 skill 要对一个数据室里几百份合同做表格化尽调。如果让主对话一份份读，上下文很快爆掉。所以它派 subagent，一个 subagent 负责一份文档，并行跑，最后把结果汇总回主对话。 主 Agent 看到的只是最终表格，中间几百次读取的信息被隔离在外。 2.2 Scheduled agent 是定时自己跑的后台任务 renewal-watcher 这个就是。每周自动扫一遍合同库，把 90 天内到期的合同列出来，发到指定 Slack 频道。你不用记日子，它替你盯。 docket-watcher（盯法院案件动态）、reg-feed-watcher（盯监管新规）都是这种。 3. MCP connector 是把外面的数据接进来的连接器 Skill 写得再好，也得有合同可审。仓库里配了 Ironclad（合同库）、DocuSign（已签合同）、iManage（文档管理）几个 MCP connector。 Agent 通过这些 MCP connector 去读公司真实的合同库，而不是让你手动复制粘贴。 类似地，诉讼那个 plugin 接的是 Everlaw（电子取证）、CourtListener（联邦法院判决数据库）、Trellis（州法院数据库）。换个执业方向，换一套数据连接器。 4. Plugin 是把上面这些打包到一起的容器 commercial-legal 这个 plugin 文件夹里装着： - 一堆 skill（nda-review、vendor-agreement-review、escalation-flagger……） - 几个 scheduled agent（renewal-watcher、deal-debrief） - 一份 .mcp.json，告诉 Claude 要连哪些外部系统 - 一份 CLAUDE.md 模板，用来记你团队的 playbook 你装上这一个 plugin，整套企业合同审查的能力就一次性配齐了。

译Claude通过四大组件实现自动化任务：Skill是领域工作流指南（如nda-review），指导操作但不执行；Agent是执行主体，Subagent用于并行处理子任务，Scheduled agent则定时自动运行（如合同到期监控）；MCP connector连接外部数据源（如合同库），使Agent能访问真实数据；Plugin将上述组件打包，提供完整功能集（如commercial-legal plugin实现企业合同审查）。这些组件共同协作，使Claude能高效处理复杂工作流。

ginobefun@hongming731 · 5月13日76

Codex 的 computer use 演示视频：OpenAI 展示新的 AI 队友能力 OpenAI 为 Codex 引入了 Computer Use 能力，让这个 Agent 从操作代码文件，扩展到操作本地 GUI 应用。这个挺值得关注的：AI Agent 的行动空间，延伸到了开发者日常使用的所有桌面软件。 这次演示最突出的一个设计决策，是 Codex 拥有自己的独立光标。它在后台运行，不会接管用户的鼠标或键盘，用户可以继续自己的工作，同时 Codex 在旁边完成配置虚拟机、播放 Spotify、添加日历提醒等任务。过去的 GUI 自动化工具通常会独占整个显示器，这个设计让 AI 助手真正成为并行工作的「队友」而不是「接手者」。 技术架构采用了两种模态的混合方案。视觉模态通过截图让模型「看见」界面，以坐标为单位点击；无障碍框架则通过系统 API 提取 UI 元素的文字描述，包括当前滚动出屏幕的内容。对速度敏感的任务，Spark 模型只依赖无障碍数据而不做图像处理，可以达到「超人速度」完成消息发送或调试操作。 安全层面，Codex 采用了逐应用的权限授权机制。在用户明确允许之前，Codex 对任何应用都完全不可见，无法访问、无法操作。这个设计让敏感数据的隐私得到了结构性保护。 目前 Computer Use for Codex 已在 Mac 上可用，Windows 支持即将推出。 https://youtu.be/D_FCYsshMI4

译OpenAI为Codex引入Computer Use能力，使其从操作代码扩展到本地GUI应用。Codex拥有独立光标，不接管用户输入，允许用户并行工作。技术架构混合视觉模态截图和无障碍框架API，Spark模型依赖无障碍数据加速任务执行。安全层面采用逐应用权限授权，在用户允许前无法访问任何应用，保护隐私。目前该功能已在Mac上可用，Windows支持即将推出。

ginobefun@hongming731 · 5月13日57

http://x.com/i/article/2054356653437562880 # AI Agent 落地三问：代码本质、长流程状态、GUI 操控 · BestBlogs 每日早报 05.13 在线阅读和收听早报：https://www.bestblogs.dev/explore/brief EP55 · 2026 年 5 月 13 日 > 从演示 Agent 到生产 Agent，最难的一步是解决空闲等待。今日精读聚焦 AI Agent 落地的三个层面：Google ADK 教程用持久化状态机替代对话历史、事件驱动替代轮询，让长流程 Agent 永不丢失上下文；小红书 QCon 实战还原 GUI Agent 测试的真实瓶颈，发现执行自动化只解决一半问题，业务理解才是核心；PingCAP 黄东旭复盘 TiDB 为 Kimi K2.6 数千万站点提供 Agent 数据库支撑的细节，说明 Scale 数量才是 Infra 真正的考题。 ## 导语 今天是 5 月 13 日，星期三。欢迎收听 BestBlogs 每日早报第 55 期。 LLM 让生成代码这件事变得廉价，但真正让工程师有价值的能力——对问题域的深度建模——并没有被替代。今天三篇精读，分别从「代码的本质」、「长流程 Agent 架构」和「GUI 操作 Agent」三个维度，探讨 AI Agent 从 Demo 走向生产的关键挑战。 精讲一来自 Martin Fowler 博客，Thoughtworks 首席工程师 Unmesh Joshi 追问：代码究竟是什么？他的答案直指 LLM 时代开发者的核心竞争力。当 LLM 把「打字生成代码」这件事商品化之后，真正稀缺的变成了什么？这个问题比大多数人想象的更深。 精讲二来自 Google Developers Blog，用一个「新员工入职协调 Agent」的完整实现，展示了三项让 Agent 从 Demo 走向生产的关键架构转变——持久化状态机、事件驱动休眠门控、多 Agent 委托。这是目前最完整的开源参考实现之一。 精讲三来自 OpenAI，演示了 Codex 的 computer use 功能——AI Agent 正式迈入「操控本地 GUI」的新阶段。用独立光标、不接管用户电脑，在后台并行处理多个桌面任务。 速览部分，我们还关注了：小红书 GUI Agent 测试工程实战（执行自动化解决一半，业务理解才是另一半）、PingCAP TiDB 为 Kimi K2.6 提供虚拟数据库支持、Anthropic CLUE 威胁检测平台、Claude 法律行业版 20+ MCP 连接器、吴恩达对 AI 就业影响的系统性分析、Agent Skill 规范与五种设计模式，以及当前最紧迫的供应链安全事件——Mini Shai-Hulud 蠕虫侵入 172 个 npm/PyPI 包，删包后仍存活。 ## 精讲一：什么是代码？ 代码是什么？表面上看，答案显而易见——代码就是程序员写的、告诉机器做什么的指令。但 Thoughtworks 首席工程师、《Patterns of Distributed Systems》作者 Unmesh Joshi 在 Martin Fowler 博客上的这篇文章里，对这个问题给出了一个更深刻、也更有预见性的答案。 代码承载两个使命，正在被分别对待 Joshi 认为，代码始终同时服务于两个目的： 第一，给机器的指令——让计算机执行操作、移动数据、协调计算。这部分，正在被 LLM 商品化。你不再需要逐字敲出每一行代码，高层次的描述就能生成大量可运行的代码。LLM 在这个维度上的能力提升速度，比大多数人预期的快得多。 第二，问题域的概念模型——这是代码的「设计」维度。一个优秀的代码库，不只包含机器能执行的指令，还包含人和工具能用来推理的概念。类名、方法名、模块边界——这些构成了一套共享的词汇表，让团队能够用同一种语言思考和沟通。这个维度，目前还没有被 LLM 真正替代。 词汇表是核心，领域知识是护城河 Joshi 举了一个零售域的例子：当我们为零售业写代码，代码里出现的是「顾客」、「商品」、「订单」、「发货」、「支付」。当我们为这个域做 Web 开发时，代码里还有「资源」、「GET/POST/DELETE 语义」这套 Web 词汇的映射。 一个不懂这两套词汇体系的人，写出来的代码架构会有根本缺陷——即使机器能正确运行，也无法经受需求变化的冲击，也无法让团队在未来高效地在上面继续工作。 这套词汇体系，就是领域驱动设计（DDD）里的「通用语言」（Ubiquitous Language）。它不是凭空生成的，而是在与领域专家深度合作、在无数次设计决策中逐渐形成的。LLM 可以模仿词汇，但无法替代构建词汇体系的过程——因为那个过程本质上是对业务现实的深度理解和提炼。 AI 时代，稀缺技能正在转移 当「打字生成代码」变得廉价，真正稀缺的技能是： - 为问题域构建精准的概念模型——什么是核心实体？它们之间的关系是什么？ - 设计清晰的词汇体系和有界上下文——在哪里「顾客」和「用户」应该是同一个概念，在哪里它们必须分开？ - 在人与 LLM 的协作中保持概念的一致性——如何确保 LLM 生成的代码使用了正确的领域词汇，而不是创造了新的混乱？ Joshi 的结论很简洁：在 AI 时代，工程师应该主动提升的是建模能力，而不是打字速度。 与今日其他精读的关联 这个视角与今天精讲二、三形成了一个有趣的呼应：精讲二的 ADK 长流程 Agent，核心挑战就是为工作流建立精确的状态模型（把「入职流程」建模为六个明确节点）；精讲三的 Codex computer use，需要 AI 对 GUI 界面的功能语义有正确理解（通过 Accessibility 框架提取 UI 元素的文字描述）。无论是人写代码还是 Agent 编排任务，「准确的概念模型」都是核心约束。 这篇文章不长，但它在 LLM 渗透开发工作流的当下，给了开发者一个非常清醒的定位框架。如果你正在思考「AI 会取代程序员吗」，或者想理解自己在 AI 时代应该投资什么能力，这是最值得认真读的一篇。 阅读原文：什么是代码？ ## 精讲二：构建支持暂停、恢复且永不丢失上下文的长时间运行 AI 智能体（基于 ADK） 大多数 Agent 教程都止步于一个无状态聊天机器人——对话结束、容器重启，什么都忘了。但真实的企业工作流不是这样的。 HR 入职流程跨越两周，发票争议需要等待供应商回复好几天，销售跟进序列可能延续一个月。这些流程的主角，是漫长的「空闲等待」——Agent 需要在等待人类签字、物流确认、审批通过的过程中静静休眠，然后准确地从中断点继续。一个无状态聊天机器人根本无法应对这种挑战。 Google Developers Blog 上的这篇教程，用一个「新员工入职协调 Agent」展示了三项将 Agent 从 Demo 推向生产的关键架构转变。 无状态 Agent 为何在真实工作流中崩溃 当前主流的无状态模式，是把每条用户消息和模型回复追加到不断增长的对话历史里，然后把整个历史塞给下一次 LLM 调用。这对五分钟的问答没问题，但在跨天、跨周的工作流里会以三种方式失败： - 上下文污染：经过数百轮对话，历史里充满了过时的工具输出和无关闲聊，模型开始搞混自己在哪个步骤。 - Token 成本爆炸：把两周的对话历史在每次推理时完整重放，Token 消耗极高，一次入职流程可能产生数千轮对话，大多数对当前决策不再相关。 - 空闲期后的幻觉：Agent 在等待签字期间休眠三天后，带着大量历史上下文重启，频繁「记起」从未发生过的步骤，或跳过它以为已完成的环节。 解决方案不是更大的上下文窗口，而是一种根本不同的架构——让 Agent 的状态变得显式、持久、并与原始对话历史解耦。 三项关键架构转变 转变一：持久化状态机替代对话历史 教程把入职流程建模为六个明确的节点： 1. 发送欢迎包和文件链接 1. 等待 — 员工签署文件（空闲等待） 1. IT 配置企业邮箱和 Slack 账号 1. 等待 — 笔记本电脑发货（空闲等待） 1. 发送个性化第一天日程 每个节点对应一个明确的状态，Agent 任何时候重启，都能从状态机精确定位自己在哪里，完全不依赖对话历史。状态是持久化的，存储在可靠的后端（本地是 SQLite，云端是托管存储），不随进程生死而消失。 转变二：事件驱动休眠门控 「等待签字」不再是让 Agent 主动轮询「文件签好了吗？」，而是设置一个事件门控——文件签署事件到达时，Agent 自动唤醒并从正确节点继续。休眠期间零资源占用，没有 Token 消耗，也没有定期唤醒导致的幻觉风险。这与传统的 Webhook/异步任务队列的思路一致，但被系统性地集成进了 ADK 的 Agent 生命周期管理中。 转变三：多 Agent 委托 IT 账号配置这类子任务，委托给专门的 IT 子 Agent 独立完成，主 Agent 只负责协调，不负责执行细节。子 Agent 可以独立运行、独立失败、独立重试，不会拖累整个主流程。这让整个系统更易于维护、测试和扩展——每个 Agent 的职责边界清晰，与微服务的设计理念一脉相承。 核心洞察：Context 与 State 解耦 这篇教程的核心洞察是：把 Context（对话历史，给 LLM 理解当前对话语境用）与 State（工作流状态机，给系统定位当前流程节点用）解耦，是 Agent 从 Demo 走向生产的关键一步。这两个东西长期被混为一谈，导致无状态 Agent 在长流程场景下的失败。 完整代码已开源于 GitHub，涵盖 ADK 状态机、事件门控和多 Agent 委托的完整实现，可以直接参考用于自己的生产 Agent。 如果你正在构建任何需要跨小时、跨天运行的 Agent——审批流、数据处理管道、自动化调研任务——这篇教程的架构思路是目前最完整的开源参考之一。 阅读原文：构建支持暂停、恢复且永不丢失上下文的长时间运行 AI 智能体（基于 ADK） ## 精讲三：Codex 的 computer use：OpenAI 展示新的 AI 队友能力 OpenAI 演示的 Codex computer use，标志着 AI Agent 从「生成文本」走向「操作本地 GUI」的重要一步。这次演示由 Ari 和 Roma 共同呈现，核心卖点不是「AI 帮你用电脑」，而是「AI 在后台替你干活，同时你继续干自己的事」。 不接管你的电脑，拥有自己的独立光标 Codex computer use 最大的设计突破，是它拥有独立光标，在后台运行，不会接管用户的 Mac。这一点直接解决了此前 computer use 场景的最大痛点——用户必须放弃电脑使用权，眼睁睁看着 AI 控制屏幕。 在演示中，Codex 同时在做： - 在 UTM 里设置虚拟机 - 在 Spotify 上播放音乐 - 在日历里添加提醒 而演示者继续在前台正常使用电脑。多任务并行，互不干扰——这才是真正意义上的「AI 队友」，而不是「AI 替代你」。 技术架构：视觉 + Accessibility 框架双轨 Codex 准确导航 GUI 的能力来自两套机制的混合： - 多模态视觉（Multimodal Vision）：通过截图「看到」界面，按坐标点击。能处理任意 GUI，但速度受限于图像处理延迟。 - OS Accessibility 框架：通过系统可访问性数据，提取 UI 元素的文字描述——理解每个按钮的角色、标签和功能，甚至能看到当前滚出屏幕外的内容。这套机制让 Codex 对 UI 的理解超越了「像素位置」，达到「语义理解」。 对于速度敏感的任务，可以启用 Spark 模型——因为它主要依赖 Accessibility 框架而非图像处理，可以达到「超人速度」，完成消息发送、日历操作或简单调试任务比人工操作还快。 逐应用权限授权：安全边界由用户掌控 安全层面，OpenAI 实现了逐应用权限授权机制：Codex 无法看到或操作任何未经用户显式授权的应用。这意味着： - 未授权应用里的敏感信息对 Codex 完全不可见 - 用户可以精确控制 Codex 能操作哪些工具，不能碰哪些 - 即使 Codex 被输入了恶意指令，影响范围也被限制在已授权应用范围内 这套权限模型比「给 AI Root 权限然后用沙箱隔离」要更细粒度、更符合用户直觉。 可用范围与展望 目前 Mac 用户可以立即体验 Codex computer use，Windows 支持正在路上。OpenAI 的目标，是让 AI 驱动的计算机操作成为日常工作不可或缺的一部分。 结合今天精讲一（代码作为概念模型）和精讲二（长流程状态管理）来看，Codex computer use 代表的是 AI Agent 能力扩展的第三个维度：从处理文本和代码，延伸到直接操控用户界面、完成端到端的计算机任务。三篇精读共同描绘了一个 Agent 能力版图——知识建模、长流程可靠性、GUI 操控——这三个维度正在逐步覆盖真实工作场景的完整闭环。 阅读原文：Codex 的 computer use：OpenAI 展示新的 AI 队友能力 ## 速览 QCon 北京 2026 | 把自动化测试当 AI Coding 来做：小红书 GUI Agent 实战回顾 来源：小红书技术 REDtech 小红书质效研发部在 QCon 北京 2026 分享了其自研 GUI Agent 智能化测试系统的完整工程实践。春节大促期间，106 种设备 × 128 个测试场景全部由 Agent 自动跑，累计执行 4.3 万 + 次，AI 用例生成采纳率达 82%，单用例执行成本 $1，固化脚本回归 Token 消耗趋近 0。核心架构是「分层 + 双 Agent 协作 + Code-as-Action」：探索 Agent 自主执行并生成用例，执行 Agent 负责 CI 回归，执行通过后整段交互自动固化为可重复使用的测试脚本。但文章最值得关注的洞察是：就算把执行 100% 自动化，也只解决了一半问题。测试方案设计占工时 25%，执行占 60%，业务理解、知识积累这些上游工作不解决，「自动化只是把同一台戏台扛在更累的肩膀上」。正在构建 AI 测试系统的团队必读。 Agent Infra 实践复盘：Kimi 如何搭建 Agent 背后的 Database 服务 来源：Founder Park PingCAP CTO 黄东旭复盘了 TiDB Cloud 为 Kimi K2.6 Agent 建站服务提供数据库支持的细节。核心挑战不是代码生成，而是 hosting 成本：Kimi 的建站服务中，用户每创建一个网站就需要一个独立的数据库实例，随着用户量增长，这意味着同时维护数千万个数据库实例。TiDB 的解法是虚拟数据库界面——不分配真实数据库实例，底层所有数据共享大型分布式 KV 存储，通过 DB Session Gateway 在逻辑层面「假装」每个 Agent 拥有独立数据库。这个架构让数量 Scale 成为可能，而传统的 Supabase/Neon 式「每用户一个真实实例」在这个量级下成本完全失控。黄东旭的核心判断：Scale 数量才是 Agent Infra 真正的考题。关注 Agent 基础设施的工程师和创业者值得深读。 Anthropic 网络安全团队如何用 Claude Code 构建威胁检测平台 来源：Claude Blog Anthropic 安全工程师 Jackie Bow 用 Claude Code 构建了威胁检测平台 CLUE，实现告警自动分类、自然语言日志查询和安全调查自动化，显著节省安全工程师时间并减少误报。这是一个典型的「AI 让工程师终于能构建一直想要的工具」的故事——安全领域的数据孤岛（多平台多查询语言）和上下文切换长期折磨着安全工程师，Claude Code 让个人工程师也能快速跨系统构建定制化自动化工具。关注 AI 在内部安全工具和企业场景落地的读者值得一读。 Claude 法律行业版 来源：Claude Blog Anthropic 为 Claude 发布 20+ 个新的 MCP 连接器和 12 个法律行业实践插件，接入法律行业核心技术栈（合同生命周期系统、研究平台、文件管理、电子取证、数据房间等），并在 Microsoft Word、Outlook、Excel、PowerPoint 中原生工作，跨应用保持完整上下文。同时宣布与 Free Law Project、Justice Technology Association 合作推动法律援助普及化。法律专业人士已成为 Claude Cowork 用户中参与度最高的群体，这次扩展标志着 Claude 在垂直行业的深度集成进入加速阶段。关注 AI 行业垂直化落地的读者适合跟进。 吴恩达：AI 不会带来"失业末日"，而是"就业狂欢" 来源：Andrew Ng (@AndrewYNg) 吴恩达系统性地驳斥了 AI 将导致大规模失业的说法，援引尽管编码 Agent 发展迅猛、软件工程师招聘依然强劲的真实数据，并分析了「失业末日」叙事盛行的三个结构性原因：前沿 AI 实验室有动机夸大能力（引起关注）；AI 公司通过锚定员工薪资来收取更高服务费；企业利用 AI 叙事掩盖疫情后过度招聘的裁员。他类比了历史上的社会性恐慌（核能安全、人口爆炸、膳食脂肪），指出这类恐慌往往导致错误决策。他最终预测将迎来一场「AI 就业狂欢」，但强调劳动力技能升级的迫切性。与今天精讲一的视角互补——一篇谈开发者如何定位能力，一篇谈整体就业趋势。 Agent Skill 规范、构建与设计模式 来源：阿里云开发者 系统梳理 Agent Skill 的规范标准（name/description/compatibility 等 YAML frontmatter 字段）、三层渐进式加载机制（元数据常驻 / SKILL.md 正文触发时加载 / references 按需加载）、模型驱动触发逻辑，并深入解析 Skill-Creator 和 Writing-Skills 两种工程化开发范式及五种设计模式。Skill 规范 2025 年 12 月由 Anthropic 作为开放标准发布，目前已被 33+ 个 Agent 产品采纳，包括 Claude Code、OpenAI Codex、GitHub Copilot、VS Code、Cursor、Gemini CLI、Kiro 等。对想了解这个开放标准完整体系的开发者，这是难得的中文系统综述。 立即保护您的企业：针对 Shai-Hulud 蠕虫与 npm 漏洞的 6 个可执行步骤 来源：VentureBeat 深度分析 Mini Shai-Hulud 蠕虫攻击——通过有效来源证明（Proof of Provenance）入侵了 172 个 npm 和 PyPI 包（5 月 11 日起），可窃取 AWS Key、SSH 私钥、npm Token、GitHub PAT、HashiCorp Vault Token、Kubernetes 服务账号、Docker 配置，以及 Claude Code 和 Kiro 的 AI Agent 配置（含 MCP Server 认证令牌）。首次在 TeamPCP 攻击中针对 1Password 和 Bitwarden 密码管理器。最危险的特性：删除包之后蠕虫仍然存活——它在 .claude/settings.json 和 VS Code .vscode/tasks.json 中安装持久化机制，在 macOS 安装 LaunchAgent、在 Linux 安装 systemd 守护进程，重启后依然运行。如果在隔离机器前先撤销 Token，Wiz 发现恶意守护进程会擦除整个 home 目录。文章提供了 6 步可执行的企业审计计划，任何使用 npm 的开发团队需要立即检查。 ## 扩展阅读 OpenAI 翁家翌："启发式学习"的强化学习新范式 OpenAI 研究员翁家翌提出「启发式学习（Heuristic Learning）」新范式：让 coding agent 持续迭代手写规则和程序策略（heuristic），通过看失败、改代码、加测试、看回放的循环，在不训练神经网络、不更新权重的情况下，在 Atari Breakout 等多个强化学习基准任务上达到或超越 Deep RL 的性能。这个范式的核心洞察是：过去 heuristic 不是没用，而是没人养得起；coding agent 改变的是维护成本曲线，让长期拥有可演化规则库成为可能。对强化学习、Agent 自主演化和 Continual Learning 感兴趣的读者值得深读。 Code w/ Claude SF 2026：在 AI 指数级增长之上构建 Anthropic 旧金山开发者大会 Code w/ Claude 2026 的官方回顾：Claude Code 速率限制翻倍、Claude Managed Agents 推出新功能（Dreaming 异步任务、多 Agent 编排、Outcomes 结果跟踪、Webhooks）。核心信息：从想法到生产软件的距离正在缩短，获得最大杠杆的团队是在为 AI 指数级增长做设计，而不是在被动追赶。适合关注 Claude Code 和 Managed Agents 生态动态的开发者和工程团队。 暴跌漩涡中，软件选择主动被大模型"吞噬" 深度分析软件行业正在发生的入口重构：从「用户打开应用」转向「Agent 调用能力」。2026 年 4 月，Notion 发布官方 MCP Server，Adobe 把旗下所有产品重新打包为 Agent Skills 和 MCP 端点，合作伙伴包括 Anthropic、Google Cloud、Microsoft、OpenAI 和 AWS。文章探讨了 Skill、Plugin、MCP 等封装形态的商业逻辑——MCP 是基础设施管道，Skill/Plugin 才是真正体现专业价值的应用层，「更像 AI 时代的 App」。软件股的「SaaSpocalypse」暴跌背景下，这篇提供了一个关于软件行业主动转型逻辑的宏观视角。 AI 时代到底该怎么管一个工程团队 Claude Code 和 Cowork 两条产品线的工程与产品负责人 Fiona Fung 在 Code w/ Claude 2026 大会上分享的工程管理实践。核心判断：过去所有工程流程都基于「写代码很贵」这个假设设计，这个假设现在已经失效，流程必须全面重构。实战细节：技术辩论不再靠白板，而是让 Claude 直接搓出三个 PR 对着代码讨论；所有 PR 都有 Claude 参与，「这段代码是谁写的」这个问题开始失去意义。宝玉翻译整理，内容扎实，适合工程管理者和 AI 原生团队建设者。 ## 今日阅读路径 时间有限？推荐从这三篇开始： 第一优先：构建支持暂停、恢复且永不丢失上下文的长时间运行 AI 智能体（基于 ADK） 今天实用性最强的一篇。持久化状态机 + 事件驱动休眠门控 + 多 Agent 委托，这三个架构模式是生产级 Agent 的必要基础。完整代码开源，可以直接参考实现。适合任何正在构建需要跨小时或跨天运行的 Agent 的工程师。 第二优先：什么是代码？ 今天认知框架最清晰的一篇。在 LLM 让代码生成变得廉价的当下，明确「代码的概念模型价值」才是开发者定位自己核心竞争力的关键。文章不长，但值得认真读完，不同阶段的工程师都会有不同层次的共鸣。 第三优先：立即保护您的企业：针对 Shai-Hulud 蠕虫与 npm 漏洞的 6 个可执行步骤 今天最紧迫的一篇。如果你的团队在 5 月 11 日之后安装或导入过任何 npm/PyPI 包，需要立即执行文中的审计步骤。删包后蠕虫仍然存活这一特性，让这次攻击的严重性远超普通供应链事件。 如果还有时间：Codex computer use 的演示值得亲眼看看（精讲三），感受一下 AI 操控 GUI 的当前状态；吴恩达的推文提供了一个关于 AI 就业影响的清醒视角，适合饭后思考；小红书的 GUI Agent 测试实战（速览第一条）则是今天最接地气的工程案例，真实数据完整，对测试工程团队有直接参考价值。 BestBlogs Pro 早鸟内测开放：你可以自定义订阅源、配置兴趣标签，每天获得一份属于自己的头条早报。欢迎抢先体验，并把反馈发回给我们：https://bestblogs.dev

译本期探讨AI Agent从演示走向生产环境的核心挑战。首先，在LLM时代，工程师的核心竞争力转向为问题域构建精准的概念模型与通用语言。其次，构建可靠的长流程Agent需进行关键架构转变：用持久化状态机替代对话历史来管理状态，采用事件驱动机制处理空闲等待，并通过多Agent委托实现职责分离。最后，GUI操控Agent的实践表明，执行自动化仅解决一半问题，对业务逻辑的深度理解才是关键。此外，基础设施需应对大规模并发访问的挑战。

Berryxia.AI@berryxia · 5月13日61

这不得个榨干CC的最后一滴血啊！ 何让 Claude 持续工作直到任务完成？ Claude Code 通过几种方式帮助实现这一点，包括最近推出的一个功能：/goal。 一行命令即可让它把所有活干完，都不需要别的指令！

译Claude Code推出/goal功能，允许用户通过一行命令让Claude持续工作直至任务完成，无需额外指令。该功能旨在实现开发任务的自动化，减少人工干预，提高工作效率。

宝玉@dotey · 5月13日65

Anthropic 今天正式上线了一个叫做「Claude for Legal」的仓库，一口气放出了 12 个针对具体法律岗位的插件，以及超过 20 个连接行业常用软件的 MCP 连接器。 无论你是公司法务、打并购战的律所、专注隐私和 AI 治理的法律顾问，还是每天苦熬到半夜的诉讼律师，甚至是法学院里摸爬滚打的学生，这个仓库都给你准备好了对应的 AI 工具，直接在 GitHub 上开源了：http://github.com/anthropics/claude-for-legal。 这些插件用之前不是即插即用，你得花 10 到 20 分钟，带着 Claude 做个简单的“冷启动访谈”，把你团队的 playbook、模板和风格习惯都塞进一个叫 CLAUDE.md 的本地文件。这样，以后每个插件干活儿的时候，都自动按照你自家的风格和标准来。 Anthropic 这么搞，是为了彻底解决 AI 法律工具最常见的槽点：输出内容太通用，看起来不像哪家律所自己的东西。 Anthropic 还是挺懂律所的痛点的。 比如 Vendor Agreement Reviewer 插件，它能自动对照你家合同模板改供应商协议，还贴心地输出一份 redline 备忘录； 又比如 NDA Triager，帮你自动把涌进来的 NDA 文件按绿黄红分级，绿灯放行、红灯直接推律师处理； Claim Chart Builder 插件可以一键生成专利侵权对比表； Privilege Log Reviewer 自动帮你跑第一轮特权日志审查； 而 Docket Watcher 插件则不知疲倦地盯着法院动静，帮你把最新动态实时扫进来。 简单讲，就是把律所里最烦、最机械、最浪费人力的活，变成了一个个简单的 slash command。 如果说插件解决的是律所内部效率问题，那么对行业系统的深度接入才真正体现 Anthropic 的野心。 现在，Thomson Reuters 的 CoCounsel、Harvey，还有 iManage、NetDocuments、Ironclad、DocuSign、Everlaw、Relativity、Box、Datasite 等几乎所有你能叫得上名字的平台，全都接入了官方 MCP 连接器。日常办公的 Word、Excel、Outlook、PPT 也全线打通。合同改完后，Claude 甚至会直接输出成 Word 修订模式，律师一条条接受或拒绝就行。 Anthropic 不只是把目光停留在高端律所。他们还特意做了些更「接地气」的事儿，联合 Free Law Project 和 Justice Technology Association，给法律援助机构、公设辩护人、非营利法律组织推出特别折扣，连给普通当事人设计的 Courtroom5 工具也接进来了。这点挺让人感触的，因为美国大约八成民事诉讼里的原被告，根本请不起律师。 Claude for Legal 背后的大脑是刚升级的 Claude Opus 4.7 模型。Anthropic 很谨慎地强调：所有插件输出都是“仅供律师审阅的草稿”，绝对不能替代律师的专业判断。 README 文件里反复提醒：引用必须追踪来源，涉及特权和主观法律判断时，要默认保守处理。毕竟法律这件事，AI 还是不能完全代替专业律师。 官方博客：https://claude.com/blog/claude-for-the-legal-industry

译Anthropic正式开源“Claude for Legal”项目，针对法律行业推出12个具体岗位的AI插件和超过20个连接行业常用软件的MCP连接器。用户通过简短的“冷启动访谈”定制本地CLAUDE.md文件，使插件能遵循团队特定的风格与标准，解决AI法律工具输出内容过于通用的问题。插件功能覆盖合同审阅、NDA分级、专利侵权对比表生成等重复性工作，并深度集成Thomson Reuters CoCounsel、iManage、DocuSign等主流平台。项目基于Claude Opus 4.7模型，但强调所有输出仅为律师审阅的草稿，不能替代专业法律判断。

Elon Musk@elonmusk · 5月13日39

Grok now has skills

译Grok现已具备技能 [引用 @techdevnotes]：在Grok Web中可通过输入/使用技能

OpenAI Developers@OpenAIDevs · 5月13日70

Computer use lets Codex work across your apps without taking over your Mac. @AriX talks with @romainhuet about what changes when agents can click, type, and keep working in the background.

译计算机使用让Codex能在你的应用间工作而不占用你的Mac。 @AriX与@romainhuet探讨当代理程序能点击、输入并在后台持续工作时将带来哪些改变。

凡人小北@frxiaobei · 5月13日68

AI 时代每个人的工作方式都可以长这样，开完会不用整理、消息不用一条条看、重复的事 Agent 替你跑、只做真正需要你决策的事。 分享下官方 100+ 能力清单和一些使用案例，有需要的可以折腾起来 https://bytedance.larkoffice.com/wiki/CLNjwBozvi11IjkeChOcltHinye 不管你是带团队的还是单打独斗的，飞书 CLI 过去一个月悄悄更新了 100+ 能力，Bot@Bot、画板、妙记、审批、知识库全部可以被 Agent 编排，个人和团队都能用。

译飞书CLI近期悄然更新了100多项能力，允许用户通过AI Agent自动化编排飞书内的多项功能，如Bot、画板、妙记、审批和知识库。这旨在将AI能力从开发层延伸至日常协作层，解决工作碎片化问题。引用推文指出，管理者可为下属配置专属Agent，实现Agent间的自动化沟通与任务处理，从而让人专注于核心决策，提升个人与团队效率。官方提供了能力清单和使用案例以供参考。

Xiaomi MiMo@XiaomiMiMo · 5月12日58

Heads up, agent users！ If you're using Xiaomi MiMo with thinking mode: When thinking mode is enabled in a multi-turn agent session and the conversation history contains a tool call, any assistant message with tool calls passed back in subsequent user turns must preserve its full reasoning_content field — otherwise the API will return a 400 error. Without it, the model's context is incomplete, which can lead to weaker instruction-following, more hallucinations, and a visibly degraded user experience. Missing reasoning = incomplete context = degraded reasoning quality. Affected frameworks include TRAE, Cursor, Roo Code, Codex, GitHub Copilot CLI, Zed, AutoGen. We're actively working with the maintainers to push compatibility updates. Affected models: MiMo-V2.5-Pro, MiMo-V2.5, MiMo-V2-Pro, MiMo-V2-Omni, MiMo-V2-Flash. See docs(https://platform.xiaomimimo.com/docs/en-US/usage-guide/passing-back-reasoning_content )for more details.

译当在多轮代理会话中启用小米MiMo思考模式，且对话历史包含工具调用时，后续用户回合中传回的助手消息必须保留完整的reasoning_content字段，否则API将返回400错误。缺失该字段会导致模型上下文不完整，进而削弱指令跟随能力、增加幻觉并显著降低用户体验。受影响的框架包括TRAE、Cursor、Roo Code等，受影响模型涵盖MiMo-V2.5-Pro、MiMo-V2.5等多个系列。开发团队正与相关维护者合作推送兼容性更新以解决此问题。更多详情请参阅官方文档。

向阳乔木@vista8 · 5月12日72

如何让Claude Code中调用Codex，可安装OpenAI提供的官方插件。 在Claude Code中依次执行： 1. 添加库 /plugin marketplace add openai/codex-plugin-cc 2. 安装插件 /plugin install codex@openai-codex 3. 重新加载插件 /reload-plugins 4. 登录配置（已安装登录Codex cli，这步不用） /codex:setup

译本文介绍了在Claude Code中通过插件市场安装OpenAI官方Codex插件的具体步骤：添加库、安装插件、重新加载及配置。其核心实践动机源于HeavySkill论文提出的“重思考”方法，即让多个AI模型并行独立推理，再由一个模型（如Codex）作为主持人综合思路以提升回答质量。作者正依此构建由Claude Code推理、Codex主持的Skill。

凡人小北@frxiaobei · 5月12日62

我给每个下属都配了一个专属 Agent，跑在飞书上。现在是他们的 Agent 在跟我的 Agent 对话，我在旁边看着。 带团队这些年，我最大的感受不是累，是碎。 各种项目要跟，各种进展要盯，各种需求要确认。AI 让每个程序员的产出翻了好几倍，活多了，事也多了，人还是那几个。 有一天我看着 Claude Code 自己把一个功能从需求写到上线，然后转头看了眼飞书群，纪要要人整理，进展要人跟，审批堆着等人看。开发层已经 AI 化了，协作层还是原始人。 正好发现飞书 CLI 过去一个月悄悄更新了 100 多条能力，很多上个月还不存在的东西，现在已经可以用了。我就开始动手改。

译一位团队管理者表示，AI极大提升了程序员个体产出，导致工作量与事务激增，但团队规模未变。其核心矛盾在于开发层已实现AI化，而项目跟进、纪要整理、审批等协作层工作仍依赖人工，效率低下。为此，他利用飞书CLI近期密集更新的能力，为每位下属配置了专属Agent。现在，下属的Agent与他的Agent直接对话处理事务，他本人则转为旁观协调，以此应对管理事务过于“碎片化”的挑战。

向阳乔木@vista8 · 5月12日62

AI Agent 没有好的Skill，潜力发挥不出来。 另一个痛点是，全网上百万Skill，哪个最匹配我当前的任务？能不能运行？安不安全？ Vercel的find skill 能搜索安装Skill，但只收录了9万Skill，分散到垂直领域，都没啥安装量，不知道好坏。 最近看到一个Skill 叫 SkillsVote，来自@MemOS_dev，有点强！ 据说花了20万美元用GPT5.4 整理了Github的大概有160万+ skill，筛选出79万+ skill。 每个Skill都提取了功能描述，环境要求，运行权限等信息。 一方面Skill推荐更精准，另一方面会记录Skill执行步骤，回传反馈，后续用于Skill优化和推荐。 最棒的是，还能根据搜到的Skill，给出工作流组合建议！让Skill发挥出更大的价值。 Vercel Skill 只有发现安装，而这个Skill 把 "发现→适配→归因→迭代" 都做了。 ① 找到了能不能跑、要什么权限、依赖什么包，一眼看清。 ② 跑完成功还是失败、是 Skill 写得烂还是环境不兼容，系统都能归因记录 ③ 基于 Skill 生成评测任务，看到底符不符合描述。 ④ 积累多了，同样的坑不会踩第二次。 官网：https://skills.vote/ GitHub：https://github.com/MemTensor/skills-vote 这个Skill支持Codex、Claude Code、小龙虾等Agent客户端，这是给AI Agent做的基建，建议安装试试。

译AI Agent面临技能发现难、匹配不准及运行安全等挑战。SkillsVote利用GPT-5.4分析了Github上超160万个技能，筛选出79万多个，并提取功能、环境及权限等关键信息。它不仅提供精准推荐，还能记录执行步骤、反馈结果以优化技能，并生成工作流组合建议，提升技能价值。相比Vercel仅支持发现安装，SkillsVote覆盖了从发现、适配、归因到迭代的全流程，支持多种Agent客户端，是AI Agent的重要基础设施工具。

meng shao@shao__meng · 5月12日71

Codex 发布 OpenAI Developers 插件 OpenAI Developers 插件，把分散在 OpenAI 平台上的多条开发链路（API Key、Agents SDK、Apps SDK / ChatGPT Apps）打包进 Codex，让 Codex 能在一个会话里完成「拿到密钥 → 写应用 / Agent → 排查 API 错误 → 准备 ChatGPT Apps 提审」的闭环。 插件包括：1 个 App + 5 个 Skill 1 App：OpenAI Platform 5 Skill：OpenAI API Key Setup、OpenAI API Troubleshooting、Agents SDK、Build ChatGPT App、ChatGPT App Submission 插件适用场景三个动词：build / create / diagnose · build —— 让 Codex 用 OpenAI API 直接产出一个可运行的应用、Agent 或 ChatGPT App，而不是只给一段 snippet。 · create —— 在 Codex 里直接生成 API Key 并完成本地配线，省掉来回切 Dashboard、复制粘贴 .env 的步骤。 · diagnose —— 看到报错时把"错误码 → 含义 → 该改哪行代码"一次性给齐，避免漫无目的地搜索社区。

译OpenAI 为 Codex 推出 OpenAI Developers 插件，将 API 密钥管理、Agents SDK、Apps SDK 及 ChatGPT Apps 开发等分散流程整合至单一会话环境。该插件包含一个 OpenAI Platform 应用和五项核心技能，支持开发者直接构建完整应用、创建并配置 API 密钥，以及诊断 API 错误。其核心目标是帮助开发者更高效地利用 OpenAI API 构建 AI 应用和智能体，实现从开发到提审的闭环工作流，提升开发效率。

ginobefun@hongming731 · 5月12日71

Claude Code 推出智能体视图 用过 Claude Code 跑多任务的人，大概都经历过这个阶段：一个窗口在写测试，另一个在 review PR，第三个在排查 bug，脑子里还要记着每个任务跑到哪里了、哪个在等回复。随着并发任务增多，这个认知负担线性增长，最终把人逼回单任务模式。 Anthropic 今天发布了 Claude Code 的智能体视图（Agent View），把这个问题正面解决掉了。 核心设计思路很直接：把所有并行会话集中显示在一块面板里，只在关键决策节点介入，其余时间让会话自己跑。在任意会话里按左箭头，或在终端执行 claude agents，就能打开这个界面。每一行显示一个会话的状态、最近的响应内容和上次交互时间。 最有用的是 Peek 功能：你可以快速预览某个会话的最后一轮，如果需要决策，直接在预览界面回复，会话自动继续，不需要切进完整对话。长期运行的任务可以用 /bg 推到后台，或启动时用 claude --bg [task] 跳过前台。 官方整理了几个早期用户的使用模式。最常见的是批量下发任务：把多个想法同时分配给多个 Claude 会话，每个绑定不同的 skill，等一批 PR 就绪再集中审查，把串行开发流程改成并行流水线。另一个是管理 PR 守卫、Dashboard 更新器这类长期运行的 Agent，直接在面板里看到下一次运行时间。还有在进行主任务时快速开一个子任务，答案就绪会直接出现在 Peek 里。 这次更新很有意义，以往多 Agent 协作的组织成本，完全压在开发者身上。智能体视图把这部分认知负担转移给了工具本身。当并发工作的摩擦大幅下降，开发者自然会跑更多任务，这会改变 Claude Code 的实际使用方式。 目前以研究预览形式上线，Pro、Max、Team、Enterprise 和 API 计划均可使用。 https://youtu.be/-INveHwbRz4

译Anthropic为Claude Code发布智能体视图功能，旨在解决开发者管理多任务时的认知负担。该功能将所有并行会话集中显示在一个面板中，用户主要在关键决策点介入，其余时间会话可自动运行。其核心亮点包括Peek功能，支持快速预览会话最新进展并直接回复，以及使用/bg命令将任务推至后台。该视图支持批量下发任务、管理长期运行Agent及快速处理子任务，从而将多任务协作的组织成本从开发者转移至工具本身，有望显著改变开发工作流。该功能目前以研究预览形式向Pro、Max、Team、Enterprise及API用户开放。

Chubby♨️@kimmonismus · 5月12日34

Nice release. But looks like now it's just about releasing *something* every day.

译发布不错。但现在看来，似乎只是为了每天发布*点东西*。

宝玉@dotey · 5月12日80

Claude Code 今天上线了一个新功能：agent view，让开发者可以在一个界面里统管所有正在运行的 AI 编程会话。 过去用 Claude Code 同时跑多个任务，只能靠一堆终端标签页和 tmux 分屏拼凑，脑子里还得记着每个任务跑到哪了。现在不用这么折腾了。 在任意会话里按左箭头，或者直接在终端跑 claude agents，就能打开 agent view 的总览界面。每一行显示一个会话的状态：在等你回复、还在跑、还是已经完成，一眼能看清。 最实用的一点是不用切换上下文就能回复。选中某个会话可以先"偷看"最新进展，如果它在等你做决定，直接在那里打回复，它就接着跑。不用打开完整会话窗口，不打断你手头在做的事。 想把某个会话扔到后台？在会话内输入 /bg。想直接起一个后台任务？claude --bg [任务描述]，连前台都不用经过。 目前 agent view 以“研究预览”状态上线，Pro、Max、Team、Enterprise 和 API 用户今天就可以用，直接跑 claude agents 即可激活。

译Claude Code 上线新功能 Agent View，允许开发者在单一界面集中管理所有正在运行的 AI 编程会话，解决了以往依赖多个终端标签页或 tmux 分屏、需手动记忆进度的繁琐问题。用户可通过按左箭头或运行 claude agents 命令进入总览界面，直观查看每个会话的状态（如等待回复、运行中或已完成）。其核心便利在于无需切换上下文即可直接回复特定会话，并能“偷看”进展后输入指令，不中断当前工作。此外，支持通过 /bg 命令将会话置于后台，或直接用 claude --bg 启动后台任务。该功能目前以研究预览形式向 Pro、Max、Team、Enterprise 及 API 用户开放。

宝玉@dotey · 5月12日66

Codex 的野心，MCP 和 Skill 的下一步 这段时间我在密集使用 Codex App、Cursor 等 Agent 应用，有件事越来越觉得有意思。 去年大家争的是谁家模型更强，今年争的好像变成了谁家窗口右侧更好用。 Codex、Claude 桌面版、Cursor 3.0、TRAE SOLO，这几家最顶尖的 Agent，在完全没有协商的情况下，几乎同时收敛到了同一个界面布局：左侧是项目和会话列表，中间是和 Agent 的对话，右侧是工作区，放着文件浏览、网页预览、文件变更审查这些功能。 肯定不是相互之间的抄袭，更像是当前 Agent 交互的最优解。 【1】为什么是三栏 传统 Chatbot 只需要两栏，左边会话历史，右边对话窗口，你问它答，用完走人。 到了 Agent 时代，Agent 能自己写代码、改文件、调工具了。它做完之后，你得看看有没有做对——右侧工作区就是为这件事出现的。 但这只是第一阶段。 随着用户越来越多时间是在指挥 Agent，打开 VSCode 这类专业工具的时间自然越来越少。那个问题迟早会冒出来：Agent 帮你写完代码、做完 PPT，你想微调几个字，还要专门切出去打开另一个软件？ 没有人愿意这样。用户的自然期待是：能不能直接在 Agent 里改？这也是目前 Codex App 呼声最高的功能之一（另一个呼声高的是手机版，马上要出了）。 于是各家开始悄悄升级右侧工作区，让它从只能看文件编辑记录，变成了一个多功能区。Codex 在 4 月 16 日的大版本更新里，右侧工作区的改动幅度是所有功能里最大的。 交互细节上各家略有差异。Codex 和 Cursor 用 Tab 切换，Claude 用浮动面板。我自己用下来觉得 Codex 最顺手，Claude 的浮动面板方案设计感有余、实用性不足，迟早要改。 【2】Codex 的真正野心 但如果只把这个变化读成“设计界面进化”，就低估 Codex 了。 Codex 4 月大版本发布时的口号是“Codex for (almost) everything”——几乎任何任务都能做。你可以把它理解成一句广告口号，但更像是一个产品方向的声明。 要兑现这句话，Codex 不能只是个擅长写代码的 Agent，它必须能处理各种文件格式，支持各领域的专业工作流，还要让用户能在它里面完成全程闭环，包括最后的人工微调。 目前 Codex 还做不到最后一步：生成之后无法编辑，代码、Markdown、PPTX 都不行。这可能是产品上有意为之的克制，可能是技术上还没跑通，也可能是在等一个统一的解决方案出现。 我猜是第三种。 【3】MCP 和 Skill 都只解决了一半 要理解 Codex 在等什么，得先想清楚 Agent 能力拼图里现在差哪一块。 MCP 解决了“连接”问题：Agent 通过统一规范接入各种工具，数据库、日历、代码仓库，都能打通。 Agent Skills 解决了“怎么做”的问题：Agent 学会了它没训练过的领域知识和最佳实践，比如怎么写特定风格的文章，怎么处理某类复杂任务。 这两件事做得都还不错。但有一块缺口始终没补上：用户的二次编辑。 你让 AI 写完一篇文章，最后还是要自己打开编辑器改几处，毕竟很多时候最后那 5% 的精准度，只有自己动手才能到位。就算将来 AI 再聪明，它也做不到百分百的懂你，还是少不了要手动去做修改。 于是最近 Markdown 编辑器又火了，各种 Vibe Coding 出来的 Markdown 产品满天飞。 但 Codex 不会自己做一个 Markdown 编辑器，因为每个人的偏好都不一样，做出来永远有人不满意；更何况它也不可能把每个垂直领域的专业编辑器都集成进来。 最合理的路，是插件机制。 【4】下一步：Agent 版 App Store 把 Agent 做成平台，让社区来贡献插件，就像 VSCode 和 Chrome 那样。 Codex 只需要聚焦在 Agent 调度这一层，把文件预览、二次编辑、垂直领域的专业能力都交给插件来扩展。用户按需安装，做设计的装设计插件，写作者装写作插件。 插件机制还能顺手解决一个长期没有答案的问题：Skill 没办法商业化。 我自己的 baoyu-skills 快 2 万 Star 了，但从中赚到的钱是 $0。Skill 这东西几乎是透明的，对 Agent 透明，对人也透明，复刻成本极低，不管你写得再好，护城河都很浅。 插件不一样。App Store 和 Chrome 插件市场已经跑通了一套收费和版权保护机制，把它移植到 Agent 插件市场完全可行。好插件可以收费，开发者才有持续打磨的动力，生态才真正能转起来。 Codex 现在已经有了一个非常原始的插件市场。从这里到成熟的收费插件生态，还有很长的路，但方向是对的。 想做这件事的不止 Codex 一家。Cursor 我能看到类似的影子。唯独 Claude Code 和 Cowork，目前没看到这个方向的产品迹象——也许他们不屑于做，也许只是还没走到这一步。 【5】留给中小团队的窗口 如果 Codex 真的跑通了插件生态，对中小团队意味着什么？ 除了自己做一个垂直 Agent，还有另一条路：在 Codex 这样的平台上做插件。不用自己搭 Agent 调度层，不用解决 Token 接入，用户分发也靠平台。你只需要专注在那个“最后一公里”——帮用户把 Agent 生成的结果处理好、编辑好、用得顺手。 这个窗口不会开太久。先进去的能拿到冷启动红利，晚进去的只剩存量竞争。 时间点不会太远，也许就在这几个月。 Codex 的野心摆在那里，“几乎任何任务”这个口号要真正兑现，插件机制是绕不过去的一步。如果 OpenAI 在这件事上继续犹豫，那才是真的失误。 你觉得这个插件生态最后会是哪家先跑通？或者说你觉得有更适合 Agent 的产品表现形式？欢迎留言分享！

译Codex、Claude等顶尖Agent应用均采用三栏界面，反映其从问答转向任务执行与审查的演进。Codex野心是成为“处理一切任务”的平台，但用户需二次编辑AI生成内容。目前MCP解决工具连接，Skill解决执行方法，仍缺编辑闭环。作者认为，建立类似VSCode的插件生态是合理路径，将文件预览、专业编辑等能力开放给社区开发，实现商业化，从而为中小团队提供开发垂直插件的机遇。

🚨 AI News | TestingCatalog@testingcatalog · 5月12日56

Sigma browser now supports Hermes Agent inside its Private Mode! Hermes Agent can work on top of available local models to execute your browser tasks. Users can select between OpenClaw and Hermes options inside the Settings menu. Team Hermes or team OpenClaw? 👀

译Sigma浏览器现已在隐私模式中支持Hermes智能体！ Hermes智能体可基于现有本地模型执行浏览器任务。用户可在设置菜单中选择OpenClaw或Hermes选项。 选择Hermes团队还是OpenClaw团队？👀

Google AI Developers@googleaidevs · 5月12日60

Build production-ready solutions with @GoogleDeepMind’s Gemini for Developers course. Registration opens today for this specialization series from @coursera that teaches you how to: - Reason & Act: Build AI apps that don't just generate text, but reason through complex tasks - Connect & Automate: Use function calling to connect Gemini with real-world tools - Scale with Confidence: Build, test, and deploy scalable AI systems Start building with Gemini today ↓ https://www.coursera.org/specializations/gemini-for-developers?utm_source=tw&utm_medium=social&utm_campaign=launch_gemini_s12n_04292026

译谷歌DeepMind与Coursera合作推出的“Gemini for Developers”专项课程现已开放注册。该课程旨在指导开发者利用Gemini模型构建可用于生产环境的AI解决方案。其核心涵盖三大模块：“推理与行动”使AI应用能推理并执行复杂任务；“连接与自动化”通过函数调用将Gemini与现实世界工具集成；“规模化与信心”则专注于构建、测试和部署可扩展的AI系统。课程强调超越单纯文本生成，实现实际任务的自动化与系统集成，助力开发者快速上手。

凡人小北@frxiaobei · 5月12日85

Anthropic：“我正在金融街”。 走自己的路，让别人无路可走。

译Anthropic在GitHub开源了金融服务行业AI解决方案完整模板库，包含10个端到端智能体、7个垂直行业插件及11家主流金融数据商的MCP连接器，覆盖投研、投行、风控等核心工作流。该库提供了从个人插件到企业API的部署方式，支持集成至Microsoft 365及私有云。此举为金融AI落地提供了开箱即用的标准作业程序，与OpenAI的消费级路线形成鲜明对比，凸显了其深耕企业场景、通过开源构建行业生态的战略意图。

Peter Steinberger 🦞@steipete · 5月11日48

Trimmy now has support for Claude Code prompt trimming. I mean, even better if you type that prompt into Codex, but ya know, let's be inclusive. Oh and since I realize I'm taking over the Menu Bar, you can now hide that icon completely. https://trimmy.app

译Trimmy现已支持Claude代码提示优化功能。当然，如果你把提示词输入Codex效果会更佳，但我们要兼容并包嘛。 对了，考虑到我意识到自己正在占据菜单栏，你现在可以完全隐藏那个图标了。 https://trimmy.app

凡人小北@frxiaobei · 5月11日61

花了些时间研究 Google Health API，说几点感受。 我前段时间基于 OpenClaw 搭了套主动式的个人健康管 Agent，目前数据源靠 Apple Health 打通，然后自己上传了一些体检、病历之类的材料，体验下来能用，但数据层面的可控性一般，需要花时间构建的也不少，并且生态也有点封闭。 Google 这个 API 的颗粒度和开放程度明显不在一个量级，31 个数据点、Webhook 推送、精细权限控制，这才是开发者应该有的样子。 打算认真做一次融合：直接把它接进来当数据端，本地做一层轻备份，省掉不少造轮子的事儿。数据层的问题解决了，上面结合 Gemini 的能力，有意思的东西应该不少。 这件事让我更坚定了一个判断，以后要刻意多买接入这套生态的海外健康终端。数据主权这件事，终端选择很重要。 至于国内……开放性嘛，懂的都懂。

译作者在体验Apple Health后，认为其数据可控性与生态开放性不足。新推出的Google Health API提供了31种健康数据点、Webhook实时推送和精细权限控制，在数据颗粒度与开放程度上优势显著，为开发者构建健康AI Agent或自动化工作流奠定了强大基础。作者计划将其接入现有系统作为核心数据源，并强调未来将优先选择接入此生态的海外健康终端以掌握数据主权，同时暗示国内生态在开放性上存在差距。

Berryxia.AI@berryxia · 5月11日73

小块有大智慧？这下真成真了！ 7B小模型现在直接当上了GPT-5、Claude Sonnet 4、Gemini 2.5 Pro这些顶级大模型的老板。 一篇最新论文里，一个用强化学习训练的7B模型学会了写自然语言子任务、分配给不同大模型、精确指定上下文，最后在GPQA Diamond、LiveCodeBench、AIME25等硬核基准上全面超过单个前沿模型，而且平均每个问题只调用三次大模型，比手动设计的多代理系统还高效。 最狠的是：它证明了目前商业AI产品里那些靠人工手调的prompt engineering和pipeline设计，完全可以通过奖励信号端到端学会。 以前大家觉得智能拼的是模型大小，现在看来，真正拉开差距的是“谁更会指挥”。 这才是AI下一阶段最被低估的真相。

译一项新研究证明，一个通过强化学习训练的7B语言模型能够有效指挥GPT-5、Claude Sonnet 4和Gemini 2.5 Pro等前沿大模型。该模型通过编写自然语言子任务、分配给不同大模型执行，并精确指定上下文信息，在GPQA Diamond、LiveCodeBench和AIME25等硬核基准测试中，其性能全面超越了单个前沿模型。该系统平均每个问题仅需调用约三次大模型，比手动设计的多代理流程更高效。该工作提供了关键证据，表明目前商业AI产品中依赖人工的提示工程和流程设计，完全可以仅通过奖励信号进行端到端学习。这揭示了AI发展的新方向：智能的差距可能不在于模型规模，而在于协调与指挥的能力。

Peter Steinberger 🦞@steipete · 5月11日25

challenged codex to e2e test improvements to the OpenClaw chat completion endpoint WITH openclaw. Used /side to ask more question while it works.

译使用OpenClaw对OpenClaw聊天完成端点的端到端测试改进发起挑战。 在它工作时使用/side功能提出更多问题。

阿绎 AYi@AYi_AInotes · 5月11日62

说个暴论，AI 行业的天，今天真的要变了， 前几天刚写了几篇推文分析过孙哥和特朗普家族为啥下场做AI 中转站，底层逻辑是中转站本质是AI水电煤的生意。 结果今天就看到央视新闻，中国移动上线了AI中转站！ 各大社区里很多人都以为中国移动发的 MoMA， 又是一个凑数的模型平台，其实根本不是一回事， 这是 AI 国家队正式跑步进场了， 而且直接把中转站做成了国家级得AI基础设施。 它现在已经接入了 300 + 主流模型， DeepSeek、通义千问、豆包、Kimi、GLM 全在里面， 不知道实际效果和体验咋样，了解的宝子可以评论区分享交流下。 为什么国家队这么快就下场了？ 我觉得本质还是中转站就是 未来AGI 时代的智能电网， 谁掌握电网，谁就掌握定价权， 谁掌握电网，谁就掌握未来。 #AI #中国移动 MoMA

译中国移动正式上线AI模型中转平台MoMA，标志着“AI国家队”入场，并将其定位为国家级的AI基础设施。该平台已接入包括DeepSeek、通义千问、豆包、Kimi、GLM在内的300多个主流模型。其核心逻辑在于，AI中转站被视为未来AGI时代的“智能电网”，是关乎定价权与行业未来的关键基础设施。此举呼应了此前关于AI中转站本质是“AI水电煤”生意的分析，预示着基础设施层面的竞争格局变化。

阿绎 AYi@AYi_AInotes · 5月11日58

MCP协议真的要成为AI时代的HTTP了，现在所有的本地AI工具都在往MCP靠，未来的Agent和工具都能无缝互联了吧🤔 YC CEO亲自下场打磨的GBrain，今天发布了v0.31.1版本。 这不是一个小补丁，属意真正的架构级升级： 一个家庭服务器跑中央大脑，所有电脑、手机、所有AI Agent，全部通过MCP协议远程连接。 体验和本地运行一模一样，再也没有同步问题，再也没有记忆割裂。 之前最蠢的bug终于被彻底修好了： 以前的瘦客户端就是个半成品，你连了远程服务器， 它还偷偷在本地开个空的PGLite数据库，跑38次迁移之后告诉你“没有找到任何结果”。 现在v0.31.1强制所有读写全部走远程，10万页的知识库，搜什么都能精准命中。 最有意思的是，这个bug是Garry自己的个人Agent Neuromancer在生产环境踩的。 更新日志里直接写了“Hermes/Neuromancer hit this in production”。 AI自己在生产环境发现了基础设施的bug，然后被写进了官方更新日志。 这可能是人类历史上第一次。 这才是真正的大招，以前我们跑本地AI，是每个设备自己养一个大脑。 电脑上一个，手机上一个，每个Agent又各有一个。 同步慢，不一致，浪费资源，永远拼不成一个完整的你。 现在反过来了： 一个大脑，养所有设备和所有Agent。 你家的旧电脑或者树莓派加个GPU，就能跑一个10万页的私人知识库。 你的Claude Code、OpenClaw、Neuromancer，全部连同一个大脑。 你在电脑上读的论文，手机上记的笔记，Agent做的研究，全部存在同一个地方。 所有AI共享你的全部记忆，再也不会问你“你刚才说什么来着”。 Garry Tan作为YC的掌门人，不去投那些估值几十亿的大模型公司，反而天天熬夜写一个开源的个人记忆工具。 这个信号已经不能更明显了： 下一波AI的最大机会，根本不在云端的大模型。 在本地，在你自己的电脑里，在完全属于你自己的、可控的、永久的个人智能基础设施。 个人AI正在走和企业软件一模一样的路。 从单机版，到客户端-服务器架构。 今天GBrain跨出了这一步，个人Jarvis就真的从玩具变成了基础设施。

译YC CEO主导的GBrain发布v0.31.1版本，实现从本地单机到客户端-服务器架构的关键升级。通过MCP协议，用户可部署中央家庭服务器，让所有设备与AI Agent远程连接、共享记忆，解决了同步不一致与资源浪费问题。此次更新修复了瘦客户端在本地错误创建数据库的关键bug，该bug由CEO的个人AI在生产环境发现并记录，凸显AI参与调试的新范式。这标志着个人AI正从玩具转向可控、永久的本地智能基础设施。

宝玉@dotey · 5月11日57

http://x.com/i/article/2053591256110940160 # 深度拆解：AI Agent Harness 的构造【译】 本文将深入探讨 Anthropic、OpenAI、Perplexity 和 LangChain 究竟在开发什么。我们将聊聊编排循环、工具、记忆、上下文管理，以及那些将“无状态”的大语言模型（LLM）转变为全能智能体（Agent）的底层机制。 你可能已经开发过聊天机器人，甚至可能用一些工具搭建了一个 ReAct 循环 （ReAct：Reason + Act，一种让模型在行动前先进行推理的模式）。跑 Demo 的时候看着挺好，但一旦投入生产环境，系统就会开始掉链子：模型会忘记三步前做了什么，工具调用悄悄报错，上下文窗口（Context Window）里塞满了毫无意义的垃圾信息。 问题其实并不在模型本身，而在模型外围的基础设施。 LangChain 证明了这一点：他们仅仅通过改变包裹大语言模型的底层架构——模型没变，参数没变——就让系统在 TerminalBench 2.0 （一个衡量 AI 智能体处理命令行任务能力的权威基准测试） 上的排名从 30 名开外飙升到了第 5 名。另一项研究则通过让大语言模型自己去优化这套架构，实现了 76.4% 的通过率，甚至超过了人类精心设计的系统。 现在，这套基础设施有了一个正式的名字：AI Agent Harness。 虽然这个术语在 2026 年初才正式确立，但其核心理念早已存在。Harness是包裹在大语言模型之外的完整软件架构：它包括编排循环、工具、记忆、上下文管理、状态持久化、错误处理和护栏（Guardrails）。Anthropic 在其 Claude Code 文档中直截了当地指出：SDK（软件开发工具包）就是“驱动 Claude Code 的 Agent Harness”。OpenAI 的 Codex 团队也使用了同样的说法，明确将“智能体”和“Harness”等同，指代那些让大语言模型真正发挥作用的非模型架构。 我非常喜欢 LangChain 的 Vivek Trivedy 给出的定义公式：“如果你不是模型本身，那你就是 Harness。” 这里有一个经常让人搞混的区别：“AI 智能体”（Agent）是用户感知到的行为体现，它是一个有目标、会用工具、能自我纠错的实体；而**“Harness”**则是产生这种行为的背后机器。当有人说“我开发了一个智能体”时，他真正的意思是“我开发了一套 Harness，并把它接入了模型”。 Beren Millidge 在其 2023 年的博文中做了一个精准的类比：原生大语言模型就像一个没有内存、没有硬盘、也没有输入输出设备的 CPU。此时，上下文窗口充当了内存（快但容量有限），外部数据库扮演了硬盘（大但速度慢），工具集成则是设备驱动程序。而Harness，就是那个操作系统。正如 Millidge 所写：“我们重新发明了冯·诺依曼架构（Von Neumann architecture）”，因为这是任何计算系统最自然的抽象方式。 围绕模型，工程化可以分为三个同心圆层次： - 提示词工程 (Prompt engineering)：精心设计模型接收到的指令。 - 上下文工程 (Context engineering)：管理模型在什么时间点能看到什么内容。 - Harness 工程 (Harness engineering)：涵盖了上述两者，再加上整个应用架构：包括工具编排、状态持久化、错误恢复、验证循环、安全执行以及生命周期管理。 Harness 不仅仅是一个包裹提示词的套壳（AI Wrapper），它是让智能体能够自主行动的完整系统。 综合 Anthropic、OpenAI、LangChain 以及广大从业者的实践经验，一个生产级的 Agent Harness 由 12 个不同的组件构成。让我们逐一拆解。 ## 1. 编排循环 (The Orchestration Loop) 这是系统的“心脏”。它实现了“思考 - 行动 - 观察”（Thought-Action-Observation，简称 TAO）循环，也被称为 ReAct 循环。这个循环不停运转：整合提示词 -> 调用大语言模型 -> 解析输出 -> 执行工具调用 -> 反馈结果 -> 重复，直到任务完成。 从技术实现上看，它通常只是一个 while 循环。但复杂的地方不在于循环本身，而在于循环所要处理的各种状态和逻辑。Anthropic 将他们的运行时描述为一个“笨循环”，所有的智慧都存在于模型之中，Harness 只负责管理回合的切换。 ## 2. 工具 (Tools) 工具是智能体的“双手”。它们被定义为某种结构化模式（名称、描述、参数类型），并注入到模型的上下文中，让模型知道哪些工具可用。工具层负责注册、格式校验、参数提取、在**沙箱（Sandbox）**环境执行、结果捕获，并最终将结果格式化为模型可读的“观察结果”。 Claude Code 提供了六大类工具：文件操作、搜索、执行、网页访问、代码分析和子智能体创建。OpenAI 的 Agents SDK 则支持函数工具（通过 @function_tool 定义）、托管工具（如网页搜索、代码解释器、文件搜索）以及 MCP （Model Context Protocol，一种开放的工具接入标准） 服务器工具。 ## 3. 记忆 (Memory) 记忆在不同的时间尺度上运作。短期记忆是单次会话中的对话历史。长期记忆则跨越多个会话持久存在：Anthropic 使用项目文件和自动生成的 memory.md 文件；LangGraph 使用按命名空间组织的 JSON 存储；OpenAI 则支持由 SQLite 或 Redis 驱动的会话存储。 Claude Code 实现了三层记忆架构：一个轻量级索引（每条约 150 字符，始终加载）、按需调用的详细主题文件，以及仅通过搜索访问的原始对话记录。一个核心设计原则是：智能体将自己的记忆视为一种“提示”，在行动前必须根据实际状态进行验证。 ## 4. 上下文管理 (Context Management) 这是许多智能体容易暗中翻车的地方。核心问题在于上下文腐烂：当关键信息处于窗口中间位置时，模型表现会下降 30% 以上（这就是斯坦福大学发现的“迷失在中间”现象）。即便是支持百万级 Token （Token：模型处理文本的最小单位，大致相当于单词或汉字的部分） 的窗口，随着上下文的增长，指令遵循能力也会退化。 生产环境的应对策略包括： - 压缩 (Compaction)：在接近限制时总结对话历史（Claude Code 会保留架构决策和未修复的 Bug，同时丢弃冗余的工具输出）。 - 观察掩码 (Observation masking)：隐藏旧的工具输出，但保留工具调用的记录。 - 即时检索 (Just-in-time retrieval)：只保留轻量级标识符，动态加载数据（Claude Code 倾向于使用 grep 或 head 命令，而不是加载整个文件）。 - 子智能体委托：让每个子智能体进行深度探索，但仅返回 1000 到 2000 Token 的浓缩摘要。 Anthropic 的上下文工程指南指出，目标是：找到能最大化达成目标概率的、信号最强的最小 Token 集合。 ## 5. 提示词构建 (Prompt Construction) 这决定了模型在每一步具体能看到什么。它是层级化的：系统提示词、工具定义、记忆文件、对话历史，以及当前的用户消息。 OpenAI 的 Codex 使用严格的优先级栈：服务器控制的系统消息（最高优先级）、工具定义、开发者指令、用户指令，最后才是对话历史。 ## 6. 输出解析 (Output Parsing) 现代 Harness 依赖于原生工具调用，即模型返回结构化的 tool_calls 对象，而不是需要费力解析的自由文本。Harness 会检查：是否有工具调用？如果有，执行并继续循环；如果没有，那当前的输出就是最终答案。 对于结构化输出，OpenAI 和 LangChain 都支持通过 Pydantic 模型 （Python 中用于数据校验和格式化的库） 进行模式约束。 ## 7. 状态管理 (State Management) LangGraph 将状态模拟为在图形节点中流动的类型化字典。系统会在关键步骤进行“存档”（Checkpointing），这样即使中断也能恢复，甚至可以进行“时间旅行”式的调试。OpenAI 则提供了四种策略：应用内存、SDK 会话、服务器端 API 或轻量级的响应 ID 链。Claude Code 采用了不同的思路：将 Git 提交作为存档点，将进度文件作为结构化的草稿纸。 ## 8. 错误处理 (Error Handling) 为什么这很重要？一个包含 10 个步骤的过程，即使每一步的成功率高达 99%，最终全流程的成功率也只有约 90.4%。错误是会滚雪球的。 LangGraph 将错误分为四类：临时性的（带延迟的重试）、模型可恢复的（将错误作为工具消息返回，让模型自己调整）、用户可修复的（暂停等待人类干预）以及意外错误（上报调试）。 ## 9. 护栏与安全 (Guardrails and Safety) OpenAI 的 SDK 实现了三个层级：输入护栏（在第一个智能体运行时检查）、输出护栏（检查最终结果）以及工具护栏（每次调用工具前检查）。一旦触发“绊网”（Tripwire）机制，智能体将立即停止。 Anthropic 在架构上将“权限执行”与“模型推理”分离。模型决定想做什么，但 Harness 决定允许做什么。 ## 10. 验证循环 (Verification Loops) 这是区分“玩具演示”和“生产级智能体”的关键。Anthropic 推荐三种方法：基于规则的反馈（测试、代码检查）、视觉反馈（通过 Playwright 截取 UI 截图）以及以大语言模型为裁判 (LLM-as-judge)（由另一个子智能体评估输出）。 Claude Code 的创造者 Boris Cherny 指出，让模型能够验证自己的工作，能让产出质量提升 2 到 3 倍。 ## 11. 子智能体编排 (Subagent Orchestration) Claude Code 支持三种模式：克隆 (Fork)（复制父级上下文）、队友 (Teammate)（通过文件邮箱通信的独立窗口）和 工作树 (Worktree)（独立的 Git 分支）。OpenAI 则支持将智能体作为工具（专家处理特定子任务）或移交（专家接管后续控制权）。 既然了解了组件，让我们看看它们在一次循环中是如何协同工作的。 1. 第一步（提示词组装）：Harness 构建完整的输入信息。 1. 第二步（模型推理）：组装好的内容发送给模型 API，模型生成 Token：可能是文本，也可能是工具调用请求。 1. 第三步（输出分类）：如果没有工具调用，循环结束；如果有，进入执行阶段。 1. 第四步（工具执行）：Harness 校验参数、检查权限，在沙箱中运行并捕获结果。 1. 第五步（结果打包）：将结果格式化为模型可读的消息，捕获错误以便模型自愈。 1. 第六步（上下文更新）：将结果追加到历史记录，必要时触发压缩。 1. 第七步（循环）：返回第一步，直到满足退出条件。 - Anthropic (Claude Agent SDK)：通过一个简单的 query() 函数暴露 Harness，运行时是一个“笨循环”，智慧全在模型里。 - OpenAI (Agents SDK)：采用“代码优先”策略，工作流逻辑直接用 Python 表达，而不是复杂的图形语言。 - LangGraph：将 Harness 建模为显式的状态图，强调对流程的精细控制。 - CrewAI：实现了基于角色的多智能体协作，由“流程层”管理确定性的骨干逻辑。 - AutoGen：由微软开发，支持多种编排模式，如顺序执行、群聊、移交和动态任务管理。 “脚手架”这个比喻并非装饰，而是极其精准的。建筑脚手架是临时性的基础设施，让工人们能触及原本够不到的高度。脚手架本身不盖房子，但没有它，工人就上不去高层。 关键洞察在于：房子盖好后，脚手架是要拆除的。 随着模型能力的提升，Harness 的复杂程度应该逐渐降低。 这就是协同进化原则：现在的模型在训练时，就已经考虑了 Harness 的存在。如果你的 Harness 设计得好，当模型升级时，你不需要增加复杂度，性能就会自动提升。 每个 Harness 的架构师都面临这七个选择： 1. 单智能体 vs. 多智能体：官方建议：先充分挖掘单智能体的潜力。多智能体会带来额外的开销和信息损耗。 1. ReAct vs. 先规划后执行：ReAct 灵活但成本高；“先规划后执行”速度更快。 1. 上下文管理策略：是总结对话，还是动态加载？ 1. 验证循环设计：是用硬性的代码测试，还是用另一个 LLM 来打分？ 1. 权限与安全架构：是追求速度自动批准，还是追求安全步步确认？ 1. 工具范围管理：工具不是越多越好。暴露当前步骤所需的最小工具集往往效果最佳。 1. Harness 的厚度：多少逻辑写死在系统里，多少逻辑留给模型发挥？ 两个使用完全相同模型的智能体，性能可能天差地别，原因就在于 Harness 的设计。TerminalBench 的证据已经非常明确：仅仅改变 Harness，就能让排名变动 20 多位。 Harness 不是一个已经解决的问题，也不是一个通用的商品层。它是硬核工程能力的体现：如何将上下文视为稀缺资源进行管理？如何设计验证循环以防止错误累积？如何构建不产生幻觉的记忆系统？ 随着模型越来越强，Harness 会变薄，但它永远不会消失。即便最强大的模型，也需要系统来管理窗口、执行代码、保存状态并验证工作。 下次当你的智能体表现不佳时，别光顾着抱怨模型，去检查一下你的Harness吧。 如果你喜欢这些内容： 关注我 → https://x.com/@akshay_pachaar ✔️ 每天我都会分享关于 AI、机器学习和凭感觉编程 (Vibe Coding) 最佳实践的教程与见解。

译文章指出，将大语言模型转化为可靠智能体的关键在于其外围基础设施，即“AI Agent Harness”。它被定义为产生智能体行为的完整软件架构，包括编排循环、工具、记忆、上下文管理等核心组件。这如同操作系统之于CPU，是智能体得以自主运行的“机器”。Harness工程超越了提示词工程，涵盖了完整的应用架构，是解决智能体在生产环境中表现不稳定的根本方案。

elvis@omarsar0 · 5月11日66

This is just mindblowing stuff! I couldn't resist replicating this workflow to generate 3D biological structures. In a few minutes, I designed an artifact specifically built to generate these for any topic. Stack: - HTML Artifact to view diagrams - Gemini Nano Pro for concept generation - Tripo for generative 3D - Codex for assembling everything AI will exponentially accelerate learning and democratize high-quality education. Stay tuned! We have a few releases on this front.

译作者受启发复现了一个利用AI工具栈快速生成3D生物结构的工作流。该流程整合了Gemini Nano Pro生成概念、Tripo进行3D生成、Codex组装代码，并通过HTML构件实现交互式查看。作者认为，此类AI应用将指数级加速学习过程，并推动高质量教育的民主化。其灵感来源于@DilumSanjaya展示的利用GPT生成UI、Gemini编写代码来创建交互式科学探索应用的概念。

elvis@omarsar0 · 5月11日65

Cool paper from Apple. Most evaluation of tool-calling agents happens after the trajectory is over. By then the wrong call has already shipped. This new paper moves evaluation into the execution loop. A specialized reviewer agent inspects each provisional tool call before it executes. If something is off, it injects feedback and the primary agent revises. To quantify the tradeoff between corrections and new mistakes, they introduce Helpfulness-Harmfulness metrics. Helpfulness measures the percentage of base errors fixed; harmfulness measures correct calls degraded by the reviewer. Results on BFCL: +5.5% on irrelevance detection (84.9% to 90.4%), +1.6% on relevance, all with no retraining of the base agent. On τ²-Bench multi-turn: +7.1% (48.7% to 55.8%). Reasoning-model reviewers get a 3:1 benefit-to-risk ratio vs. 2.1:1 for GPT-4o. Adding GEPA prompt optimization stacks another +1.5–2.8%. Why does it matter? You can keep the base tool-calling agent frozen and still ship measurable accuracy gains by improving only the reviewer. Model selection and prompt optimization on the reviewer become real, separable production levers. Paper: https://arxiv.org/abs/2604.27233 Learn to build effective AI agents in our academy: https://academy.dair.ai/

译苹果公司提出一种新型AI代理评估方法，将评估环节从事后分析移至执行循环内部。该方法部署一个专门的审查代理，在主代理执行每个工具调用前进行检查，若发现问题则注入反馈令其修正。研究引入了“帮助性-危害性”指标来权衡修正效果与新错误产生。在BFCL基准测试中，无关性检测准确率从84.9%提升至90.4%；在τ²-Bench多轮对话测试中，准确率从48.7%提升至55.8%。此方法的核心优势在于无需重新训练基础代理，仅通过优化审查代理的模型与提示工程即可实现显著性能提升，为生产部署提供了独立的优化杠杆。

Thariq@trq212 · 5月11日65

Jarred tried rewriting Bun in Rust and it passes 99.8% of the existing test suite we're not being ambitious enough

译Jarred 尝试用 Rust 重写 Bun，新版本已通过现有测试套件 99.8% 的测试。这是一次涉及 96 万行代码的重写，代码在 Linux 上已实际运行并通过测试，其他平台也将跟进。整个过程并非简单地指令 AI 完成，未来将有博客文章详细阐述其对 Bun 性能、内存使用、可维护性的影响，以及具体的重写过程。

阿绎 AYi@AYi_AInotes · 5月11日62

Damn，刷到这个帖子我瞬间愣了，AI迭代速度已经疯了，有点跟不上节奏了🤯 我一开始以为这又是一个生成视频的新工具，点进去发现根本不是一回事。 Higgsfield昨天刚发的Virality Predictor，直接把脑科学塞进了内容创作流程。 上传一段15秒以内的视频， 几秒就能给你出完整的人脑反应报告。 整体病毒潜力， 前3秒钩子得分， 全程注意力保持曲线， 还有彩色的脑区激活热图， 告诉你观众的大脑哪部分被点亮了。 最狠的是它和Claude的打通， 可以一句话生成500个产品视频变体， 然后全部丢进预测器自动筛掉垃圾， 只放大高分版本直接投流， 从0到已验证高潜力广告，全程自动化。 它不是看你视频过去像不像爆款。 而是用AI模拟700多个人、500多小时fMRI数据训练出来的人脑，预测你看到这段视频时的真实神经反应。 我们以前做电商短视频， 拍，剪，烧钱测，看数据，迭代， 测试成本是真金白银的广告费。 现在做电商短视频， 生成，预测，只投高分， 测试成本只是一点token费。 最牛逼的地方在于 大脑亮不等于一定爆， 一些高认知负荷的内容会让大脑很活跃，但普通人刷到就会直接滑走。 真正的病毒性，只看前3秒钩子得分和视觉拉力。 和你有没有深度，有没有道理，一点关系都没有。 也就是说以前爆款靠灵感， 现在爆款靠系统。 所以当别人还在熬夜想创意的时候， 你已经用AI筛完了500个版本， 知道哪10个能爆。 而且工具越强，越考验人的判断， 它能帮你砍掉80%的无效创意， 但选什么方向，解读什么结果， 永远是人说了算。 我感觉2026年的电商短视频战场， 已经不是比谁创意好， 而是比谁能用AI先把非爆款干掉， 所有还在靠感觉做内容的人可真的要跟不上了。 #AI工具 #短视频创业

译Higgsfield发布Virality Predictor工具，利用基于700多人fMRI数据训练的AI模型，直接预测视频引发的人脑神经反应。它能分析15秒视频的整体病毒潜力、前3秒钩子得分及注意力曲线，并生成脑区激活热图。该工具可与Claude等AI结合，实现批量生成视频变体并自动筛选高分版本，使内容测试成本从高昂广告费降至极低token费。这标志着爆款创作从依赖灵感和人工测试，转向依靠系统化预测与高效淘汰机制，核心竞争力变为利用AI快速筛除非爆款的能力。

Chubby♨️@kimmonismus · 5月10日18

The problem when you're sick in bed and have too many ideas

译当你卧病在床却有太多想法时的问题

meng shao@shao__meng · 5月10日60

Claude Code、Cursor、Codex、Aider、Cline 部分底层模型可能完全相同，但 Agent 表现却不一样，为什么？ @addyosmani 认为：是因为模型之上的那层“外壳” —— Harness，它包括「提示词、工具、上下文策略、钩子、沙箱、子智能体、反馈回路、恢复路径」等。 Agent = Model + Harness 重新系统看看什么是 Harness？ 凡是"不是模型本身"的部分都属于外壳： · 指令层：System prompt、CLAUDE.md、AGENTS.md、skill 文件、子 agent 指令 · 能力层：工具、skills、MCP servers 及其描述 · 基础设施：文件系统、沙箱、无头浏览器 · 编排层：子 agent 派发、任务交接、模型路由 · 执行控制：hooks、中间件（lint、上下文压缩等确定性逻辑） · 可观测性：日志、trace、成本与延迟监控 裸模型不是 agent。只有当外壳为它提供了状态、工具执行、反馈回路和强制约束，它才成为 agent。 思维范式的切换：不是"模型问题"，是"配置问题" 行业默认反应是：agent 出错 → 等下一代模型。 Harness Engineering 拒绝这个默认。 每一类失败都是可定位的工程信号： · 忽略代码规范：写进 AGENTS.md · 执行破坏性命令：加 hook 阻止 · 长任务中途失焦：拆分为 planner + executor · 写出无法编译的代码：把 type-check 作为反压信号注入回路 同一个模型，放在精调过的外壳里，性能可以远高于跑在通用框架上。当前模型理论能力与你实际看到的能力之间的差距，主要是 harness gap。 最关键的工作方法：棘轮（The Ratchet） 每一次失误都变成一条永久规则。 · 一次"提交了被注释掉的测试"的事故 → AGENTS.md 增加"绝不注释测试"，pre-commit hook 检测 .skip(，reviewer 子 agent 拦截。 · 约束只在观察到真实失败时加入，只在更强模型让它冗余时才移除。 · 系统提示词里每一行都应能追溯到一次具体的历史失败。 推论：没有通用最优 harness。 一个 harness 是一个代码库的"失败史"塑造出来的，是工程纪律而非框架。 设计方法：从行为反推组件 1. 文件系统 + Git —— 持久化状态 模型只能操作进入上下文窗口的内容。文件系统是工作区、暂存区、多 agent 协调面。Git 提供免费版本控制、分支实验、回滚。 2. Bash + 代码执行 —— 通用工具 ReAct 循环（reason → act → observe → repeat）。与其为每个动作预建工具，不如让 agent 用 bash 现场组装。Agent 在 shell 上表现普遍很强。 3. 沙箱 + 默认工具链 Bash 必须安全运行。好沙箱预装运行时、测试 CLI、无头浏览器，让 agent 能"自我验证"。 4. 记忆 + 搜索 —— 持续学习 模型不知道训练之后的世界。AGENTS.md 在每次会话注入领域知识；web search 和 MCP 工具补足实时信息。 5. 对抗 Context Rot 上下文越满，推理越退化。三种主要手法： · Compaction：智能压缩与卸载旧上下文 · Tool-call offloading：长输出（如 2000 行日志）落盘，只在上下文里保留头尾 · Progressive disclosure：按需披露指令和工具，而不是启动时全量加载 6. 长程执行 应对"过早停止"和"分解失败"： · Loops：拦截模型的退出意图，在新上下文窗口里强制继续推进完成目标 · Planning：强制写出步骤计划文件，每步后用 self-verification hook 检查 · Splits：生成与评估拆给不同 agent，规避模型自评的正向偏差 7. Hooks —— 强制层 连接"请求行为"和"强制行为"。生命周期挂载点：工具调用前、文件编辑后、提交前。 成功应当沉默，失败应当冗长。typecheck 通过则无声；失败则把错误直接注入回路供自纠。 8. 规则手册和工具选择 · AGENTS.md 仍是仓库根部最高杠杆的配置点。但要把它当飞行员检查清单，不是风格指南——简短，每条都有失败史背书。 · 十个高度聚焦的工具，永远胜过五十个互相重叠的工具。 · 工具描述会进入 prompt，所以未审计的 MCP server 等同于 prompt 注入风险面。 生产中的样子 把对 Claude Code 架构的推测性拆解作为成熟外壳的参照 · 上下文注入 = 知识层 · 循环状态 = memory store + worktree 隔离器 · 破坏性动作 hook = 权限闸 · 子 agent 上下文防火墙 = 多 agent 层 · 工具 dispatch registry = MCP 与 bash 的统一插槽 外壳不会消失，只会迁移 模型变强不会让外壳消失，而是让它位移： · 老一代模型催生的"上下文焦虑缓解层"已经被新模型大幅淘汰 · 但能力上限抬高的同时，新的失败模式也随之出现 · 外壳里每一块脚手架都编码了"模型当前不能独立做到什么"——模型变强，过时的拆掉，新的搭起来去够下一条地平线 训练循环的反馈 模型 post-training 时通常会带特定 harness 入环 → 模型对这些 harness 偏向的动作（文件系统操作、bash、子 agent 派发）格外擅长 → 形成一定程度的过拟合。 最佳 harness 是为你具体任务和工作流定制的那个。 Harness-as-a-Service 行业从"在 LLM API（提供 completion）上构建"转向"在 Harness API（提供 runtime）上构建"。SDK 直接交付循环、工具、上下文管理、hooks、沙箱。 新默认范式：选一个 harness 框架 → 配置其核心支柱 → 只专注于领域特定的 prompt 与工具设计。 这让排错变成"调一个良好分层的配置面"，而不是"重造整个 agent 架构"。 未来方向 · 顶尖编码 agent 之间的相似度，已经高于它们底层模型之间的相似度——外壳模式在收敛 · 开放问题正在越过"单 agent"：多 agent 并行编排、agent 分析自身 trace 修复 harness 级故障、按需即时组装工具的环境 · 下一阶段：harness 不再是静态配置文件，而越来越像编译器。

译智能体表现差异的核心在于模型之上的“外壳”，它包括提示词、工具、上下文策略等工程组件。外壳为裸模型提供状态和执行能力，使其成为智能体。行业常将智能体失败归咎于模型，但实为可定位的配置问题。通过“棘轮”方法，每次失误都可转化为优化外壳的永久规则。没有通用的最优外壳，最佳外壳是为具体任务定制的。未来，行业焦点将从构建LLM API转向构建提供运行时环境的Harness API。

Chubby♨️@kimmonismus · 5月10日49

I'd somehow completely forgotten that Karpathy introduced the wikiLLM a while back (obsidian + Claude code/codex). I'm sick in bed and set it up because I have nothing else to do. I love it. I have a second brain now. Amazing.

译我居然完全忘了Karpathy之前介绍过wikiLLM（obsidian + Claude code/codex）。 我卧病在床，因为无事可做就搭建了一个。 太喜欢了。我现在有了第二个大脑。真不可思议。

小互@xiaohu · 5月10日49

「HTML 比Markdown让人更容易读懂 Agent 的工作 更适合人机协作交互」 让Codex 用HyperFrames 制作个解说视频 除了解说文案有一点AI味，效果其实还不错的 嘿嘿

译推文提出，在Agent工作流和人机协作交互场景中，HTML格式比Markdown更易于人类阅读和理解。作者建议让Codex使用HyperFrames来制作解说视频，并指出虽然生成的解说文案带有明显的AI风格，但整体效果不错。引用的推文提供了关于HyperFrames技术或相关演示的背景支持，强调了HTML在提升人机交互清晰度方面的优势。

Artificial Analysis@ArtificialAnlys · 5月10日67

Exciting launch by OpenRouter that uses Artificial Analysis benchmarks

译OpenRouter推出令人兴奋的新功能，采用Artificial Analysis基准测试 设置请求中的`min_coding_score`参数，即可根据@ArtificialAnlys的排名，自动路由至符合要求且成本最低的编码模型。 实时查看帕累托前沿的变化👇

Berryxia.AI@berryxia · 5月10日72

Google 把 Fitbit Air 的全新 Google Health API 直接开放了！ 昨天 Fitbit Air 刚刚发布，但更重磅的是它自带了全新的 @googlehealth API，开发者现在可以直接在上面构建 AI Agent、MCP Server 或者 CLI，利用自己的睡眠、心率、运动等健康数据玩出花来。 核心能力非常全面： - 31 种不同数据点，涵盖从运动、睡眠、心率到 SpO2 等全维度健康指标； - 支持 Webhooks 实时推送，当健康数据发生变化时立刻通知； - 读写权限精细控制，你只需要申请实际用到的权限即可； - 支持按时间范围查询、自动汇总每日数据、结果分页等灵活操作。 作者自己是 Whoop 重度用户，但他也直言这波更新值得认真探索。 完整入门 codelab 已经放出（包含第一步 API 调用教学）：https://developers.google.com/health/codelabs/make-your-first-api-call 对想做健康 Agent、个人数据工具、实时监控系统或者 MCP 相关项目的开发者来说，这等于把真实可穿戴设备的结构化健康数据彻底打开了，结合现在的 Agent 框架，能直接做出非常实用的个人健康自动化工作流。 值得立刻去试试！

译Google 随新款 Fitbit Air 发布了全新的 Health API 并向开发者开放。该 API 提供了涵盖运动、睡眠、心率、血氧等维度的 31 种健康数据点，支持 Webhooks 实时数据推送、精细的读写权限控制以及按时间范围查询和汇总数据。开发者可利用该 API 基于个人真实健康数据构建 AI Agent、MCP Server、CLI 或实时监控系统等应用，从而创建实用的个人健康自动化工作流。官方已发布包含首次调用教学的入门指南。