AK@_akhaliq · 6月12日62

CHORUS Decentralized Multi-Embodiment Collaboration with One VLA Policy

译CHORUS 去中心化多本体协作，基于单一VLA策略。

向阳乔木@vista8 · 6月12日76

Fable 5 开发在线Photoshop，就是用这个生成需求文档。 P0需求点的开发效果。

译Vista 编写了 AI 专用 PRD 文档生成 Prompt，先用它生成文档再交给 AI 开发，以提升功能完整度。Fable 5 项目开发在线 Photoshop 正是使用此方法。安装指令：`npx skills add joeseesun/qiaomu-ai-prd`，开源地址和 Prompt 见评论。

向阳乔木@vista8 · 6月12日44

AI First原则就是，一切都要先试试AI能不能帮搞定。 正在试着用Codex 的Computer Use帮填写 Word 合同。

向阳乔木@vista8 · 6月12日75

现在都是 AI Agent做开发，人喜欢的 PRD 和 AI 喜欢的是不一样的。 为了精准高效开发，写了个专门服务于 AI 的PRD文档生成Prompt。 先有这个文档，再给AI开发，功能完整度和丰富性会远远比自己想的全面、好用。 Skill开发好了，安装指令： npx skills add joeseesun/qiaomu-ai-prd 开源地址和Prompt见评论

译推文提出AI Agent开发中人类与AI对PRD的需求不同，为此发布了一个专门服务于AI的PRD文档生成Prompt（命名为qiaomu-ai-prd）。开发者先使用该Prompt生成文档，再交给AI开发，可显著提升功能完整度和丰富性。安装指令为：`npx skills add joeseesun/qiaomu-ai-prd`，开源地址及Prompt见评论区。

歸藏(guizang.ai)@op7418 · 6月12日68

万字长文：做了些爆款 Skills 以后，我对 Skills 的看法 最近做了几个传播还不错的 Skills后，我对 Skills 的理解也有些变化。 这篇文章算是我目前对 Skills 最系统的一次复盘。 我写了为什么 Agent 不是聊天框，为什么 Agent 会放大人的能力差距，为什么 Skill 可能是普通用户真正用好 Agent 的关键中间层； 也写了一个好 Skill 应该怎么设计、怎么维护、怎么分发，为什么 Skill 生态不能只做成仓库列表，以及内容、产品、案例、反馈之间如何形成一个持续迭代的飞轮。 这不是一篇概念科普，也不是对别人观点的转述，更多是我自己做了一批真实案例之后沉淀下来的判断。 如果你正在做 Agent、AI 工具、插件生态、内容产品，或者想把自己的专业经验变成可复用的能力，这篇文章应该会有一些参考价值。

译@op7418 万字长文复盘爆款 Skills 经验，核心观点：Agent 不是聊天框，会放大能力差距；Skill 是普通用户用好 Agent 的关键中间层。好 Skill 需设计、维护与分发；生态不能只做仓库列表，需要内容、产品、案例、反馈形成迭代飞轮。基于真实案例。

Berryxia.AI@berryxia · 6月12日45

非常认同的观点：Agent 不是简单抹平能力差距，而是在放大能力差距。" 头部用户已经在搭系统（文档、规则、memory、loop、MCP、CLI、工具调用、权限、安全沙箱），普通用户还在问聊天框。 目标清晰、品味强的人被 Agent 放大。 目标混乱、没有文档的人被 Agent 放大混乱。 之前我和朋友分享的观点就是AI时代不一定是完全平权的时代，而是会将“善于使用AI工具”的人能力放大数万倍，原本没有AI Agent的时代你和他的差距可能只是几倍而已。 但，如今可能真的差距就会变成数百倍不止。 好文，值得大家阅读~

译Berry Xia 赞同观点：Agent 不会缩小用户能力差距，反而会放大差距。头部用户已搭建文档、规则、memory、MCP、CLI、工具调用、权限、安全沙箱等系统，普通用户仍停留在聊天框。目标清晰、品味强的人被 Agent 放大优势；目标混乱、缺乏文档的人被放大混乱。作者认为 AI 时代并非完全平权，善于使用 AI 工具的能力可被放大数万倍，原本几倍的差距现在可能扩大到数百倍。

meng shao@shao__meng · 6月12日46

Re-Ink：再保险合约智能提取与审核参考实现 @LandingAI 金融 AI Hackathon 冠军之一，针对再保险承保流程中耗时严重的文档处理痛点，构建从 PDF/DOCX 条约文档到可审核合同记录的端到端自动化方案。 行业痛点量化 再保险承保人约 40% 时间用于行政工作，主要为手动将条约数据（日期、保费、留存限额、参与方名称等）重新录入合同管理系统。Accenture P&C Underwriting Survey 数据显示： · 实际承保工作仅占 30%； · 行政任务占 40%； · 谈判与销售支持占 30%。 手动提取存在系统性风险：日期格式多变、参与方名称不一致、金融术语表述差异大，即使在规范环境下错误率仍超 6%（Reisch et al., 2024）。保险公司运营预算中约 14% 用于修复此类手动错误。 Re-Ink 核心方案 Re-Ink 使用 LandingAI 的 Agentic Document Extraction (ADE) 作为文档智能核心，结合 FastAPI + React + PostgreSQL + LangGraph 栈，实现： 1. 上传与结构解析：ADE 自动识别 PDF/DOCX 的章节、表格、标题、段落及嵌入数据。 2. 字段提取：基于预定义 schema（合同标识、日期、金融条款、覆盖细节、参与方信息）进行上下文感知提取，无需正则、模板或格式特定逻辑。 · 优势：能处理“Net Retention”“Ceding Company Retention”等不同表述，或嵌入段落中的留存金额。 · Hackathon 测试（SEC EDGAR 文件）显示，在提取 cedent（分出公司）和 reinsurer（再保险公司）名称时特别可靠，即使出现在叙述性文本中。 关键设计：人机协同闭环 · 提取后人工审核：所有数据在 reviewer 确认前不持久化。ReviewForm 展示提取字段，支持编辑、补充或拒绝。 · 事务保障：审批后以单事务创建 Contract 和 Party 记录，任何校验失败均回滚。 · 业务理由：再保险合同涉及数百万美元义务，监管要求人工基于业务上下文验证原文档，AI 输出不可作为合规唯一依据。 · 反馈优化： reviewer 反复修正的模式可指导 schema 或 prompt 迭代。 Agent 层增强 Re-Ink 使用两个 LangGraph Agent（均不负责提取，仅封装业务逻辑）： · 入库前引导 Agent：检查缺失必填字段、日期逻辑矛盾等，并生成建议审核 payload。 · 审批后分析 Agent：StateGraph 包含 validate（完整性检查）和 analyse（LLM 风险与合规标记）节点。 两者均支持 offline 模式（确定性 mock），便于端到端自动化测试。

译Re-Ink 是 @LandingAI 金融 AI Hackathon 冠军项目，针对再保险承保中约 40% 时间消耗的行政文档录入痛点，构建端到端自动化方案。核心使用 LandingAI 的 Agentic Document Extraction (ADE) 实现 PDF/DOCX 条约的结构解析与上下文感知字段提取（合同标识、日期、金融条款、参与方等），无需正则或模板。关键设计为人机协同闭环：提取数据经人工审核后以单事务持久化，校验失败即回滚。Agent 层用两个 LangGraph Agent 封装入库前引导与审批后分析逻辑。Academy 调查显示手动提取错误率超 6%，运营预算约 14% 用于修复此类错误。

歸藏(guizang.ai)@op7418 · 6月12日68

http://x.com/i/article/2065096982310567936 # 万字长文：做了些爆款 Skills 以后，我对 Skills 的看法 如果看不完的话，可以先帮忙点个赞，收藏一下以后看，感谢。 我最近几次聊 Skills，有一个越来越明确的判断： 大家现在都在说 Agent，但大多数人其实还没有真正理解 Agent。 大众理解里的 Agent，往往还是一个聊天框。 你输入一句话，它回答一段文字；你再输入一句，它继续回答。 这个视角下，AI 好像天然会带来一种平权：以前不会写代码的人可以写代码，不会做 PPT 的人可以做 PPT，不会剪视频的人可以剪视频。 只要模型足够强，大家的能力差距就会被抹平。 但我越来越觉得，这个判断是错的。Agent 不是简单抹平能力差距，而是在放大能力差距。 头部用户已经默认理解 Agent 的组成： 文档、规则、memory、loop、MCP、CLI、工具调用、权限、安全沙箱、上下文工程、定时任务、心跳、文件系统、代码执行和 Skill。 但普通用户只知道“Agent 能写代码”“Agent 可以调用 Skill”，并不知道 Agent 的上限从哪里来，也不知道自己应该如何组织目标、资料和流程，才能让 Agent 真正工作。 > Agent：这里指的不只是聊天机器人，而是能理解目标、规划步骤、调用工具并持续执行任务的 AI 系统。 > Memory：Agent 用来保存长期偏好、项目状态和历史决策的外部记忆，不等同于模型训练记忆。 > Loop：Agent 反复“思考、调工具、观察结果、再决定下一步”的执行循环。 这里就出现了一个很大的认知割裂：头部用户已经在搭系统，普通用户还在问聊天框。 目标清晰、上下文好、品味和判断强的人，会被 Agent 放大； 目标混乱、没有文档、没有判断的人，也会被 Agent 放大混乱。 所以用户会出现 K 型分化。去年还可以靠产品设计、交互设计和用户教育降低一些门槛，今年我觉得已经很难靠简单 UX 弥合这个差距。 Skill 则可以弥合 Agent 使用能力差距。 ## Skill 是能力商品，不只是提示词 我现在对 Skill 的一句话定义是： Skill 是把专家经验、工作流、品味和工具调用封装成可分发、可复用、可迭代的 Agent 能力单元。 > Skill：把提示词、流程、工具调用、模板、脚本、边界和经验打包起来的可复用能力单元。 它不是单纯的提示词，也不是传统意义上的 App。 它更像 Agent 时代的“能力商品”。用户不需要理解底层的 MCP、CLI、workflow、memory、loop、模型选择、代码执行和上下文工程，只需要知道： 它解决什么问题，产出什么结果，怎么使用，别人用得怎么样。 提示词本身很难成为产品。它容易被复制，难以分发，没有版本管理，也缺少安装和调用语义。 Skill 把提示词、规则、示例、工具调用、文件结构、脚本、依赖和使用说明打包起来，让它变成一个可以安装、调用、迭代和传播的能力包。 所以 Skill 和 Prompt 本质上并非完全不同，但 Skill 的调用效率更高，分发和理解成本更低，也能承载更多工程化内容。 更重要的是，很多任务并不是一句提示词能解决的。 它们是一组稳定流程：读取材料，分析需求，选择模板，调用工具，生成产物，验证结果，修复问题，导出文件。 Skill 把这套流程从一次性对话中抽出来，变成可以反复调用的工作流。 比如 PPT Skill 的流程不是“生成 PPT”这么简单。 它要读取文章或大纲，询问主题、页数和配图，选择主题、颜色和版式，生成 HTML PPT，自动后验检查常见问题，再修正缺属性、未居中、溢出、图片裁切、节奏重复等问题，必要时还要调用图像模型生成配图，最后输出可演示、可分享的文件。 这背后真正有价值的，是 Skill 把人的演示经验被外化了。 ## Skill 的核心，是把人的经验外化 我做的设计类 Skill 很能说明这一点。 真正有价值的部分是把人的审美、版式判断、设计系统经验、模板选择、图片裁切规则、明暗遮罩规则、字体和颜色规则固化进去。 这要求创作者同时懂三件事：传统专业知识，AI 的上下限，以及产品化思维。 传统专业知识决定你知道什么结果算好。比如设计、剪辑、写作、健身、法律、商业化投放，每个行业都有大量隐性判断。AI 的上下限决定你知道模型什么能做、什么做不稳、什么必须工程化兜底。 产品化思维决定你知道用户场景、使用门槛、反馈路径和稳定性要求。 这也是我做几个 Skill 时最深的体会。 PPT Skill 最开始不是为了“做一个 Skill”，是因为我真的要做一场分享。 第一版基本成型后，我通过五六轮对话调整间距、字号、字体、颜色、配图、重复内容、WebGL 背景等问题。 讲完之后发现大家最关心的不是分享本身，而是 PPT 怎么做，于是才把这套模板和流程沉淀成 Skill。 社交媒体卡片 Skill 也不是凭空抽象出来的。它来自非常具体的内容分发需求： 3:4 竖版图文卡片，适配小红书、公众号、Twitter 等不同场景。它要处理 11 类内容，两套视觉系统，28 个版式骨架，真实图片 + Coding 排版，还要规避 AI 图限流、文字不锐利、平台风格不匹配等问题。 Logo Generator Skill 也是同一逻辑。它没有直接让图像模型一把梭生成 Logo，因为图片模型的文字、结构和可编辑性不稳定。 它选择先生成 SVG Logo 变体，再生成展示图和 WebGL 背景，把 Logo 本体、展示场景和交互背景拆成不同层，分别用最适合的技术处理。 AI Desk Card 则说明 Skill 的边界可以扩展到物理环境。 它让 Agent 接管屏幕边缘的物理信息位：固件烧录、Wi-Fi 配置、信息推送、定时任务、memory、todo、日历、GitHub 展示、墨水屏刷新，都可以被封装成一套 Skill。 这些案例共同说明：Skill 和核心是“人把什么经验变成了可调用的能力”。 ## 用户不关心概念，用户关心结果 对普通用户来说，Skill、MCP、CLI、Plugin 叫什么并不重要。 他们关心的是：这个功能能解决什么问题，适合什么场景，我点一下能不能用，需要输入什么材料，结果长什么样，别人用得怎么样。 > MCP：Model Context Protocol，可以理解为让 AI 以统一方式连接外部工具、数据源和服务的协议。 > CLI：Command Line Interface，命令行工具；对 Agent 来说，它常常是比图形界面更稳定、更容易自动化的操作入口。 因此，面向用户的产品层不应该堆术语。Codex 把很多东西统一叫插件，我觉得就是一个正确方向：弱化概念，强调功能。 底层可以是 Skill、MCP、CLI 或原生 Plugin；用户只需要知道它能干什么。 但对产品和创作者来说，这些底层形态的区别又很重要。 Skill 适合承载相对垂直、可描述、可复用的工作，比如 PPT、社交媒体卡片、文章配图、写作润色、视频包装、简历优化、数据可视化、某个行业 SOP。 MCP 更适合 Agent 架构中的原子服务和上下文连接，比如地图、浏览器、网盘、设计稿、数据库、企业 API。 CLI 则是目前很现实的通用 Plugin 形态：命令行、代码、Skill 都可以封装进去，也不绑定单一 Agent 平台。 飞书 CLI 就是一个很好的例子。用户不用理解 200 多条命令，也不用知道背后是哪个 API。 他只需要说“帮我把今天的智能纪要拉到笔记里”，Agent 背后可以搜索云文档、读取妙记、下载逐句转写、写入本地 Markdown、建立反向链接。 用户看到的是结果，Agent 用的是工具，Skill 封装的是流程。 这也是为什么 Skill、CLI 和 MCP 的关系不能只从技术概念上理解。 它们最终都要落到一个问题：怎么让普通用户用上头部用户已经验证过的能力。 ## 好 Skill 的架构：中心短，辐射厚 很多人会把 Skill 理解成一个 SKILL.md 文件，这只说对了一半。 > SKILL.md：很多 Skill 的入口说明文件，用来告诉 Agent 什么时候加载这个能力、按什么流程执行、哪些坑不能踩。 好的 Skill 往往是一个目录。SKILL.md 只是入口，旁边还可以有 scripts/、references/、assets/、模板、schema、配置文件、子 Skill 和特殊案例。 复杂 Skill 不怕有复杂内容，怕的是把复杂内容一次性塞给模型。文件系统本身就是一种上下文工程。 > 上下文窗口：AI 一次能“看见”和处理的信息范围，文档、代码、聊天记录和工具说明都会占用它。 好 Skill 的信息架构应该是“中心短，辐射厚”。 SKILL.md 只放高信号流程和判断；references/ 放重文档和领域材料，按条件读取；scripts/ 放确定性逻辑，让 Agent 调用而不是重写；assets/ 放模板、schema、示例、字体、主题和版式骨架；配置文件或稳定数据目录放首次配置、偏好和历史记录。 这里有个很关键的点：Skill 的 description 不是宣传语，也不是功能摘要，是路由触发器。 好的 description 应该描述用户什么时候需要它，最好来自真实用户表达；坏的 description 只是解释“这个 Skill 做什么”。 比如一个 PPT Skill，不应该写“这个 Skill 可以生成漂亮 PPT”。 它应该写“当用户需要把文章、大纲或演讲内容转成可演示 HTML PPT 时加载”。前者是广告，后者是 Agent 的判断条件。 这能解释为什么“把所有能力塞进一个大 Agent”不是好方向。 大而全的 harness 会把工具定义、协议细节和长文档塞满上下文，带来更高延迟、更高 token 成本和更多误用。 反过来，薄 harness 只提供最小运行环境，Skill 作为按需加载的能力包，才能让系统长期复利。 > Harness：运行 Agent 的外层程序，负责模型循环、文件读写、上下文管理和安全边界。 更稳的架构是 Thin Harness, Fat Skills：harness 保持薄，负责跑模型循环、读写文件、管理上下文、执行权限和安全边界； Skill 变厚，承载流程、判断、领域知识、模板、脚本、资产、gotchas 和 eval； 确定性工具下沉给 CLI、scripts 或 API；模型留在理解、判断、综合、取舍和表达这些更适合它的部分。 > Thin Harness, Fat Skills：让 Agent 底层运行环境保持轻，把具体流程、领域知识、模板、脚本和失败经验放进按需加载的 Skill 里。 ## Skill 质量要像代码质量一样维护 好 Skill 不是一次写完。它需要维护，而且要像代码质量一样维护。 一个比较可靠的生命周期是： 1. 先用无 Skill 的 Agent 跑真实任务，找到它会错在哪里； 1. 基于真实 query 写 eval，包括正例、反例和 forbidden load； 1. 先调 description，确保该加载时加载，不该加载时不加载； 1. 写主体时删除显而易见的内容，只保留会改变模型行为的判断； 1. 把失败案例追加到 gotchas，而不是不断加长主流程；改 description 或路由边界时补 eval； 1. 再做跨模型测试，看不同编排模型对 Skill 触发和执行的差异。 > Eval：用一组真实或模拟任务测试 Skill 是否按预期触发、执行和交付结果。 > Gotchas：从真实失败里总结出来的“别这么做”清单，往往比正向说明更能提升 Skill 稳定性。 这里有一个很重要的原则：每个 Skill 都是一种税。 它进入索引后，每个会话、每个用户都在为它的 name 和 description 付上下文成本； 它被加载后，后续对话都在为主体内容付成本。 所以每一句都要问：没有这句，Agent 会不会做错？如果不会，就删。 gotchas 是最高价值内容，因为它们来自真实失败。 正向原则往往模型已经知道，负面边界才是专家经验。 设计 Skill 中“不要纯白纯黑”“连续三页相同节奏是 P0 错误”“文字不能压脸”“AI 图只在无合适真实图时使用”，都属于 gotchas 或强约束。 这也解释了为什么完全自动生成 Skill 只能做初稿。 模型可以帮你起草结构，但它无法凭空拥有你的失败样本、审美判断、行业边界和用户反馈。 真正有价值的是人把经验注入进去，再通过 eval 和 gotchas 让它持续变厚。 ## 设计 Skill 的本质：把品味变成约束 设计类 Skill 不是简单的“AI 会画图”。 它需要解决模型不稳定、图像限流、文字不锐利、排版不可控、风格一致性难判断等问题。 我现在越来越觉得，设计 Skill 的核心是把专业品味变成模型可执行的限制。 模型默认会收敛到一些平庸模式： Tailwind 大色块、紫色渐变、emoji 堆砌、Inter 字体、发光、过度圆角、无意义动效、信息密度失控。这不是模型没有审美素材，而是没有稳定的取舍原则。 所以设计 Skill 里最有价值的是主观但明确的约束： - 不使用纯白和纯黑，降低刺眼和廉价感； - 不让用户任意输入 hex，只提供经过验证的主题色板； - 不用紫色多彩渐变、发光和大面积 blur 作为主视觉捷径； - 动画只在必要时使用，且只动 transform 和 opacity； - 图文卡片优先真实摄影和截图美化，AI 生图只是兜底； - 版式骨架先被人工验证，AI 负责填充、组合和微调；文 - 字必须根据图像主体、明度和可读区域自适应落点、字色、遮罩和断行。 这些规则看起来限制自由，实际是在保护输出下限。 设计类 Skill 的质量来自“替用户排除绝大多数会变丑的选项”。 这也是我几篇 Skill 文章里反复出现的经验： 好看不是玄学，而是可拆解、可编码、可检查的行业常识。 Skill 的价值，就是把这些常识压进 SKILL.md、模板、checklist、主题变量和后验检查里。 PPT Skill 和社交媒体卡片 Skill 的一个共同方法，是把 AI 的任务从“自由设计”降级成“在高质量骨架里填充”。 PPT Skill 里，10 种页面布局、5 套主题色、字体三级分工、7:5 / 6:6 / 8:4 网格、hero 与 non-hero 的节奏交替，构成了一个稳定的演示系统。AI 不需要从零发明版式，只需要根据内容选择合适页面类型并填进去。 社交媒体卡片 Skill 进一步把场景校准到手机信息流： 3:4 是主战场，1 秒决定停不停下。它不是把 PPT 截图成竖图，而是重新定义了图文品类、版式比例、断行规则和素材优先级。 11 个内容品类、两套视觉系统、28 个版式骨架、截图美化、地图组件、真实图库和克制 AI 生图，共同构成了“内容平台视觉 Skill”。 Logo Generator Skill 也是同一逻辑： 不直接让图像模型一把梭生成 Logo，因为图片模型的文字、结构和可编辑性不稳定； 他是先生成 SVG 变体，再做展示图和 WebGL 背景。这里把 Logo 本体、展示场景、交互背景拆成不同层，分别用最适合的技术处理。 所以设计 Skill 的通用公式是： 人工沉淀审美系统，模型理解内容和语义，代码负责稳定排版和导出，图像模型只处理适合它的视觉部分。 这比单纯“让 AI 画一张图”更慢一点，但可控、可改、可复用，也更适合内容创作者长期使用。 ## Skill 生态不能做成仓库列表 如果一个 Skill 能被图文、案例、评价、使用数据、作者、应用场景反向链接起来，它就不只是一个工具，而是一个社区节点。 > 反向链接：从使用案例、文章、图文或项目页面反过来链接到某个 Skill，让人能看到它被谁用、怎么用、效果如何。 当前很多 Skill 展示的问题是： 列表很长，像 GitHub 仓库名；图标都一样；没有结果展示；没有评价指标； 多模态 Skill 也只用文本展示；用户不知道哪个适合自己。 推荐 10 个或 20 个精选 Skill，并讲清楚怎么用，远好过给用户几千个列表。 每个 Skill 都应该像一个软件功能页。页面应该说明： 它解决什么问题，适合什么场景，需要输入什么，输出长什么样，典型提示词是什么，生成结果截图或视频，谁用过、怎么评价，有哪些常见失败情况，如何安装和修改。 这本质上需要强运营。 不是把名字列出来，而是一个一个挑、一个一个写介绍、展示结果，最好还有视频讲解。 GitHub 是代码型 Skill 的天然托管地，因为 Skill 往往包含代码，需要版本管理； GitHub 有生态位、版权声明和分发基础；AI 也熟悉 Git 和 GitHub 操作；开源还能覆盖所有 Agent 平台，不绑定单一产品。 但小红书适合做视觉内容和使用案例分发。 小红书的优势是内容感知、视觉展示、用户审美和评论体系。 PPT Skill 和社交媒体卡片 Skill 都已经在小红书之外的人群中传播，比如咖啡馆主理人、数码测评、活动策划、餐厅、三线城市分享场景。这说明 Skill 能跨出 AI 圈。 应用商店式 Skill 分发也有潜力：更精准推荐、更低使用门槛、可能给创作者分成。 但对创作者来说，如果只在一个平台上架，就等于押注这个平台能做好产品、生态、分发和市场占领。 更稳的策略可能是：GitHub 做基础分发和跨平台覆盖，平台 Skillhub / 应用商店做体验优化、运营推荐和商业转化。 未来的 Skill 平台，本质上会同时是 App Store、GitHub、社区种草页、评价系统和 Agent 工具层。 ## 普通用户真正卡在哪里 AI 圈外的人并非不能用 Skill。 实际观察中，咖啡馆主理人、数码测评、活动策划、健身教练等都能用出好结果。 真正卡点是交互心智。 很多人仍然用传统软件思维，以为一次生成就该完成： 不习惯通过 chat 连续调整；不知道可以要求 AI 改颜色、改字、修溢出、换图；不知道如何提供上下文和素材；也不知道如何从自己的工作流中抽 Skill。 因此，Skill 产品不仅要提供安装，还要提供使用教育。 行业 Skill 会是一个很重要的方向。很多行业有非常好的经验和客户洞察： 健身、法律、餐饮、活动策划、教育、商业化投放等。但行业专家不一定知道如何做 Skill，也担心分享后被盗。 这里的关键不是把 Skill 作为服务添加项。 健身教练可以用 Agent 维护会员饮食、训练、有氧、提醒和反馈，提高客户粘性和服务效率。 法律从业者可以把琐碎文本处理、条文审查、格式检查做成辅助 Skill，但核心判断仍由人完成。 餐饮和活动行业可以用图文 Skill 把真实图片和故事包装成可传播内容。 AI 不能替代线下履约，但可以提高获客、沟通、维护和复用效率。 这类行业用户只需要基础启蒙：带他做一次需求分析，落地成一个 Skill，他就知道边界在哪里。 每个行业都有先锋用户：有创造力、有好奇心、想用 AI 获得竞争优势。先服务这些人。 ## 内容 Skill：文章、产品和案例互相喂养 从我已有文章看，我正在形成一条很清晰的内容 Skill 路线： 不是为某个抽象 AI 概念写文章，是先做出一个能用的 Skill，再把制作过程、设计判断和使用场景写成传播内容。 这类内容有几个特点。 PPT Skill 最初来自一次 AI 和组织分享，观众问得最多的是 PPT 怎么做，于是从一次交付沉淀成开源 Skill。这是副产品变主产品。 文章本身像说明书，但不是 README。 它要讲清楚为什么这样设计、适合谁、边界在哪、真实效果如何，降低用户理解门槛。 产品演示本身就是内容资产。PPT 截图、图文卡片、Logo 展示图、Desk Card 场景图，都可以成为传播素材。 Skill 反过来也提升写作效率。社交卡片 Skill 可以把文章段落直接转成更适合小红书、公众号或 Twitter 的视觉卡片。 每篇文章都在扩展 Skill 的语义边界。 PPT 是演示，Social Card 是内容分发，Logo 是项目品牌资产，Desk Card 是硬件和环境 UI，夜巡录则指向游戏 demo 工作流。 这说明 Skill 不只是“工具产品”，也是内容创作者的表达基础设施。 过去文章和产品是分开的：先做产品，再写推广。现在 Skill、文章、案例、开源仓库、社交反馈会互相喂养。 一个成熟路径可能是：用 Agent 完成一次真实任务，把过程沉淀成 Skill，用 Skill 产出的可视化结果写文章，文章带来用户和反馈，反馈补成 gotchas、模板和下一版 Skill，新版 Skill 再产生下一轮内容。 这就是个人产品在 Agent 时代的复利飞轮。 ## Skill 的边界会继续扩大 过去“插件”通常意味着软件里的一个按钮。现在 Skill 的边界可以明显更大。 浏览器 Skill 会是消费者入口。Tabbit Browser 一类产品说明，Skills 可以进入浏览器场景，变成普通用户在网页、资料、脚本和自动化之间的入口。 浏览器是大众最熟悉的工作环境，如果 Skill 能以“现成脚本 / 使用案例 / 一键执行”的方式出现，会比裸露 CLI 或 GitHub 仓库更容易被理解。 硬件 Skill 则说明 AI 可以接管环境 UI。 AI Desk Card 的价值在于它把 Agent 的能力延伸到了物理环境： 安装固件、配置 Wi-Fi、写 cron、读取 Memory、选择 widget、刷新墨水屏，全流程由 AI 引导。用户不再面对 App 设置页，AI 本身就是设置页。 游戏 Skill 代表更长链路的创作流程。 夜巡录开发手记里提到的“独立游戏 demo Skill”，从玩法母题、原型、素材采集、绿幕抠图、contact sheet、视频生成、音乐、Electron 打包、GitHub Actions 到 Release。 封装是一套跨程序员、美术、动画、作曲和运维的生产流水线。它的价值是把“做个原型”和“独立交付完整作品”之间的墙变薄。 这些案例共同说明： Skill 的未来不只会局限在聊天框里，它会扩展到浏览器、桌面、本地文件、硬件、内容平台、游戏引擎和真实工作环境。 ## Skill 与 Gene：手写经验和自动进化的边界 还有一个值得保留但需要谨慎使用的对比：Agent Skill 与 GEP Gene。 Skill 更像人类预先沉淀的能力包：有明确创建者、明确边界、明确流程和版本。 Gene / Capsule 这类概念强调运行中从成功经验里自动长出能力：带成功率、变异历史、适用上下文和自动修复机制。 > Gene / Capsule：这里指从 Agent 反复执行中的成功路径里沉淀出的可复用经验单元，强调自动演化而不是人工手写。 这两者不是简单替代关系，是不同的层级。 Skill 适合承载人的专家经验、审美、行业 SOP、工具不变式和明确交付标准； Gene 适合从重复执行中捕捉成功路径，把临时试错变成可复用经验；Capsule 类似把多个 Gene 组合成更长工作流。 从当前产品现实看，Skill 仍是更可落地的单位，因为它能被写、被审、被发布、被解释、被传播。 但长期看，自动沉淀 Skill / Gene 化经验会成为方向：Agent 先用通用工具试错，成功后把路径写回 Skill 或生成新的子能力。 这也回应了“自动沉淀 Skill”的讨论。系统可以自动发现重复流程，但是否值得沉淀、如何命名、边界在哪里、哪些失败要写进 gotchas，仍然需要人的判断。 真正理想的形态不是完全自动，也不是完全手写，而是人定义品味和边界，Agent 负责收集证据、提出改动、补充 eval 和维护长尾经验。 ## 盗用不是靠藏，防御方式是持续分发 Skill 很难靠闭源防盗。即便不开源，只要看到产出结果，试用几次，也可能被复刻。 所以防御方式不是“藏起来”，而是开源覆盖更多平台，用影响力威慑过分盗用者，做自媒体让用户知道源头是谁，用持续迭代建立领先，用社区案例和评价体系形成品牌资产。 在产品壁垒降低的时代，个人产品如果没有渠道、资源和营销，就必须自己做宣发。以前自媒体是可选项，现在是基础设施。 ## 平台真正该做什么 如果要做 Skill 平台，不能只押 Skill。用户下载独立端的理由，首先是 Agent 基础体验足够好： 漂亮好用的客户端，多模型支持，尤其国产模型；文件、项目、memory、CLI、MCP、Skill 管理； 权限和安全沙箱；长程任务和状态延续；多设备流转，手机控制桌面，桌面反向控制手机；官方高质量插件开箱即用。 Workbody 的启发是，它没有做特别独特的东西，只是把该有的基础体验做齐了。很多国内产品连这一点还没做好。 一些高频、必须、常见的能力应该内置并打磨好，不要让用户自己折腾安装。 官方插件强，会形成壁垒。多设备、云端和本地互控，也会形成壁垒。 Skill 与本地环境强相关时，移动端需要遥控 PC。 Skill 可跨端通用，但依赖本地文件、脚本、浏览器、CLI 的 Skill 在移动端很难直接跑。 移动端适合轻量级从 0 到 1 创作；桌面端适合重任务和本地环境调用。 自动沉淀 Skill 是长期方向，但好 Skill 仍需要人。Dumate 等产品提出“自动沉淀 Skill”：从用户重复工作中自动总结流程。 这个方向成立，但好 Skill 仍需要业务 SOP、品味、测试和迭代。自动生成可以做初版，真正能稳定交付的 Skill 需要打磨。 ## 一个完整 Skill 生命周期 如果把前面的判断收束成一条路径，一个完整 Skill 生命周期大概是这样的。 先发现真实需求，从自己或行业用户的重复工作开始。 再做一次高质量产物，不要先抽象，先用 Agent 解决真实任务。 然后抽象流程，识别可复用步骤、输入、输出、约束和工具。 接着工程化模板，把审美、版式、调用、验证和修复机制固化。 再做跨模型测试，好模型看上限，差模型保下限。 之后才是封装发布，GitHub 托管，配 README、示例和安装方式。 再做内容分发，用小红书、Twitter、公众号、视频展示结果。然后收集反馈，从 issue、评论区、用户案例和平台数据里找真实问题。 反馈还要筛选，只吸收能提升泛化和稳定性的部分。 这条路看起来长，但它的本质很简单： 每一次真实任务，都不只是在完成任务，而是在积累下一次能调用的能力资产。 Agent 时代最稀缺的是可复用的能力组织方式。 Skill 之所以重要，是因为它第一次让人的经验、工作流和品味，有机会变成一种可以分发、调用、评价和持续迭代的商品。 这可能才是 Agent 生态里真正的大机会。 好，今天的内容就到这里。如果你觉得有帮助，欢迎帮我点个赞，或者转发给你需要的朋友。

译作者认为Agent并非抹平能力差距，而是放大K型分化，Skill可弥合鸿沟。Skill是把专家经验、工作流、品味、工具调用封装成可分发复用的Agent能力单元，如PPT Skill、社交媒体卡片等。好Skill的信息架构应为“中心短，辐射厚”：SKILL.md只放高信号流程，其余依赖文件系统分层管理，以高效利用上下文窗口。

ginobefun@hongming731 · 6月12日58

http://x.com/i/article/2065232915970371585 # BestBlogs 早报 · 06-12｜智能体解耦、Harness 工程化、脚手架被吞 在线阅读本期早报 ## 导语 智能体工程化正在从两端同时收紧。一端是 Anthropic：用 Claude Managed Agents 把推理与执行彻底解耦，靠可恢复的事件日志和独立 Vault 撑起企业级落地，首字延迟中位数已经大幅下降，Notion、Sentry、Rakuten 等公司的生产环境已经跑通。另一端是一位阿里工程师：用三层加载架构、dispatcher 状态机和 G1-G8 门禁，治好了 CLAUDE.md「规则越堆越多、AI 越读越懵」的老毛病，给出了一套「用结构约束 AI，而不是用更多字约束 AI」的可复用模式。再往远看，Sequoia Capital 对 Google AI Studio 与 Gemini API 负责人的一场访谈提了一个更让人不安的趋势：模型正在把外层脚手架一口口吃掉——路由、执行环境这类原本要靠工程团队搭的能力，正逐渐被基础模型自己吸收，留给独立创业公司的窗口正在变窄。 今天的速览部分同样值得关注：从"决策-执行-交付三明治"模型看 AI 为什么不会取代软件工程师，到阿里云用声明式 CRD 把多智能体协作模型化的 AgentTeams 实践，再到端侧大模型靠 Arm SME2 指令集实现 Prefill 提速 80% 的工程细节，以及一位 4 人团队靠 Agent 协作平台冲上 GitHub Trending 的真实运转记录——这些案例和今天的三篇精讲互为印证：工程化的红利正在向「会搭框架、会用工具」的团队和个人集中。 ## 精讲一：智能体交互界面的演进：使用 Claude Managed Agents 进行构建 | Claude 背景：从「一问一答」到「全程托管」 2023 年 Anthropic 开放 Claude API 的时候，接口设计非常朴素：token 进、token 出，一次请求对应一次模型轮次，剩下的事全部交给开发者自己处理。这套契约支撑了文档摘要、工单分类、文本改写这类「单轮搞定」的工作，但很快就不够用了——用户希望 Claude 能把一个任务从头跟到尾：去查一些东西、基于结果采取行动、观察发生了什么变化、再决定下一步做什么，而且要能直接在代码库、内部 Wiki、工单系统这些「真实战场」里操作。 要把 Claude 变成这样的智能体，开发者过去必须自己搭一套循环：问模型该做什么、执行工具调用、把结果喂回去、再循环一遍。Anthropic 在 2025 年推出的 Claude Code 内置了这样一套经过打磨的 harness（智能体执行框架），随后开放成 Claude Agent SDK，让开发者可以在同一套机器之上构建自己的智能体，而不必维护一套自研循环。 关键事实：把「大脑」和「双手」彻底拆开 即便有了 SDK，把智能体真正推向生产环境依然困难重重：智能体的代码要在哪里跑、会话历史和进度存在哪里、运行中断后能不能干净地恢复、出了问题的「爆炸半径」有多大、凭证怎么给而不暴露给生成的代码、自主运行一小时之后能不能复盘每一步。这些问题的根源往往是同一个架构选择——智能体的 harness 和它操作的文件系统跑在同一个容器里：容器要先启动才能让 Claude 开始思考（付出启动成本），代码执行紧贴着凭证，容器一旦挂掉整次运行就跟着没了。 Claude Managed Agents 的解法是把「调用 Claude 的 harness」和「代码真正执行的沙箱」彻底拆开，中间用一份可追加的事件日志（session）连接两端——记录每一次模型调用、工具调用和结果。这意味着 Claude 可以在沙箱还没创建出来之前就开始推理，沙箱本身离凭证很远，而整次运行随时都可以从事件日志中重建出来。围绕这套架构，Managed Agents 由三类资源组成：agent（模型 + 提示词 + 工具 + 护栏的配置）、environment（沙箱容器、网络规则和预装包，可以跑在 Anthropic 云上也可以跑在企业自己的基础设施上）、session（每次运行，把一个 agent 和一个 environment 配对，拥有自己独立的沙箱实例）。 凭证管理是另一处关键设计：MCP、CLI、GitHub 仓库等工具的 token 统一存进独立的 Vault，用信封加密保护，检索时需要一份经签名验证的请求 token，代码本身永远拿不到这些凭证——即便 prompt injection 想诱导模型读取自己的运行环境，也读不到任何敏感信息。在性能层面，由于 Claude 可以在环境并行启动的同时立即开始推理，从不调用工具的会话甚至可以完全跳过容器，实测下来首字延迟中位数（p50）降低了约六成，最慢的长尾情况（p95）降低超过九成。 为什么重要：基础设施差异正在被「抹平」 这篇文章最值得关注的一点，是它把「智能体工程」里最耗时的部分——安全、状态管理、权限、harness 调优——明确定义为「不构成产品差异化」的通用基础设施。当 harness 没能跟上模型智能的进化，智能体就会出问题：在 Claude Sonnet 4.5 上，模型会在上下文快用完时匆忙收尾、提前打住工作，团队为此专门给 harness 加了「上下文重置」机制；但到了 Claude Opus 4.5，这个行为消失了，之前加的重置反而变成了纯粹的开销。这说明 harness 调优本身是一种会随着模型迭代而过期的「沉没成本」，与其反复自己调，不如把这部分托管出去，把精力放在「上下文管理和领域专长」这些真正能拉开差距的地方。 与今日其他报道的关系 这篇文章和今天另外两篇精讲构成了一个完整的叙事闭环：Anthropic 用 Managed Agents 把通用 harness 能力产品化、托管化，恰好对应阿里工程师在精讲二里复盘的「自建 harness」的另一种路径——一个是把基础设施外包给平台，一个是自己动手搭三层加载架构；而 Logan Kilpatrick 在精讲三里提出的「模型吞掉脚手架」趋势，则提示无论是托管方案还是自建框架，都需要持续关注哪些能力会被模型本身吸收。Notion、Sentry、Rakuten 等公司的落地案例，也呼应了速览中阿里云 AgentTeams 把多智能体「组织化」的思路——基础设施成熟之后，下一个竞争点是「怎么把 Agent 团队真正用起来」。 阅读建议 如果你正在评估是否要自建智能体 harness，这篇文章值得通读全文，重点看「凭证管理」和「会话持久化」两部分的具体设计——这两点往往是自建方案里最容易留坑的地方。完整内容见 BestBlogs 阅读原文。 ## 精讲二：AI 不缺智商缺纪律：一场 Harness 工程化实践 背景：CLAUDE.md 越写越厚，AI 反而越读越懵 一位阿里工程师分享了他过去两个月用 AI 编码时踩过的一个典型坑：一开始他用一个不断膨胀的 CLAUDE.md 解决 AI「不守纪律」的问题——先写单测、部署前评审、提交前合并主分支，所有规矩都往里堆。这套做法管用了三天，然后问题以更严重的形式回来了：规则多到把上下文「撑爆」，模型读完所有规则之后已经没有「脑容量」去读代码，于是开始遗忘、串味、自我矛盾。他由此得出一个核心判断：对付 AI 的不确定性，堆 prompt 是负债，搭框架（harness）才是资产。 关键事实：三层加载架构 + dispatcher 状态机 + G1-G8 门禁 文章的核心是一套三层加载模型，设计思想可以浓缩成一句话：把上下文当预算管理，而不是当免费的草稿纸。常驻入口层（CLAUDE.md + CLAUDE.local.md）只放角色定义、代码偏好、流程触发规则和门禁速查表，把主会话的常驻上下文压到 8K 以内；原子规则层（rules/）每条规则单一职责，本质是把踩过的坑固化成强制约束——「每条规则都是一次事故的墓志铭」；按需上下文层（context/）存放完整流程详情、Pre-Mortem 模板、TDD/ATDD 指南等深度内容，只在进入对应阶段时才被读取，用完即释放。 更关键的是角色 Agent 层：一个 dispatcher 读取 state.json 和 workflow.yaml，决定下一步该调用哪个 agent，自己只管路由不管业务；orchestrator 负责合成三角色（业务、技术、质量）评审的观点并向用户确认；developer、verifier、deployer、tester 各管一段，从方案到验收一步一岗。主会话被刻意「降级」成一个只听 dispatcher 指令的纯执行器——这个设计反直觉，因为我们本能地想让主模型更全能，但全能恰恰是污染之源。贯穿全文的还有一条 19 节点的标准研发链路，按 intent（意图）× risk（风险）动态裁剪——一次简单的 BUG_FIX/LOW 任务只需要检查 5 个节点，而 FEATURE/HIGH 任务要走满 19 个节点，外加一条硬规则：只要检测到真实业务代码改动，部署预发和接口测试自动成为必需节点，堵死「改了代码、没验证就收工」的漏洞。 为了回答「改完 harness 到底是变好还是变坏」这个问题，作者还搭了一套确定性评分平台：100% Python 逻辑、零 LLM 调用、3 次跑分 hash 完全一致，从 7 个维度（参考了 SWE-bench、AgentBench、Anthropic Eval Guide、CMMI 等方法论）给每次执行打分，权重最高的两个维度是流程完整性（22%）和代码正确性（22%）——前者靠「产物文件在不在」而不是「模型说做了」来判断，后者用真编译、真单测来防止 AI 自我汇报和实际结果之间出现「诚实度差距」。 为什么重要：从「堆 prompt」到「做框架」的范式转移 这篇文章给出的核心论点，是 AI Coding 的瓶颈正从「模型能力」转移到「流程工程」——模型已经足够聪明，但不稳定，而稳定性必须由外部框架供给。文章引用了多项研究支撑这个判断：Stanford 的「Lost in the Middle」研究表明 LLM 注意力呈 U 型分布，中部信息准确率显著下降；另一项研究（arxiv 2605.29682）发现原始 token 消耗和工具调用只能解释 agent 成功率方差的 R²=0.33~0.42，而验证反馈质量能达到 R²=0.94~0.99——也就是说，决定 AI 干活靠不靠谱的不是「给它多少预算」，而是「检查做得多好」。这也是为什么作者坚持用确定性评分而非 LLM 评委：宁要可复现的「粗糙分」，不要会漂移的「精准分」。 与今日其他报道的关系 这篇文章和精讲一形成了有趣的对照：Anthropic 把 harness 能力做成了托管产品，而这位工程师选择自己动手，用 dispatcher + 文件交接的方式搭了一套轻量级的「控制平面」。两者殊途同归的地方在于：都把「流程纪律」从模型推理中外置成确定性的基础设施——一个靠平台层的事件日志和 Vault，一个靠文件系统的状态持久化和 G1-G8 门禁。文章里提到的「fail-closed（默认拒绝，只放行显式允许的操作）」原则，也是精讲三里 Logan Kilpatrick 讨论的「脚手架」最终会沉淀成什么形态的一种答案：当模型还不能自我保证流程纪律时，这类外置约束就是当下最稳的解法。 阅读建议 如果你正在用 AI 做长周期、跨多个阶段的开发任务，这篇文章里的三层加载架构和 19 节点裁剪规则可以直接拿来参考；如果你更关心「怎么验证一次 harness 改动到底有没有用」，重点看第四部分的 7 维评分体系设计。完整内容见 BestBlogs 阅读原文。 ## 精讲三：Google DeepMind 的 Logan Kilpatrick：为什么模型会吞掉智能体脚手架 背景：Google 智能体生态的「重新打地基」 在 Sequoia Capital 主持的这场访谈中，Google AI Studio 和 Gemini API 负责人 Logan Kilpatrick 谈到了 Google 产品生态正在经历的一次范式转变。过去 Google 旗下的各类产品之间缺乏统一的主线，Gemini API 的出现提供了一层共享的基础智能层，而当前的演进则聚焦于通过一套被称为 anti-gravity agent harness 的智能体框架进行深度架构整合——这套框架横跨核心 IDE 功能、Web 界面、CLI 和 SDK 能力，把消费级和开发者工具统一改造成能够自主执行长周期任务的智能体原生环境。 关键事实：Gemini 3.5 Flash 的提升全部来自后训练，模型在「吃」周边脚手架 Logan 特别提到，智能体执行最强的落脚点是软件工程领域。在讨论模型训练路径时，他强调 Gemini 3.5 Flash 在编程任务上观察到的性能跃升完全来自后训练增益——这让一个体量更小的模型在编程任务上反超了此前的 Pro 版本。同时，Google 内部的深度「自用」（dogfooding）也大幅压缩了产品迭代周期，让工程团队能比传统开发流程更快地构建和上线复杂的桌面与移动端原生工具。 更值得关注的是「世界模型」架构的演进——以 Omni 这样的系统为代表，行业正从「文本、音频、图像、视频分别建一条独立流水线」转向「统一的单一模型结构」，能够同时解释多模态序列，并在编辑操作中展现出对场景的整体理解：调整环境的同时保持历史上下文和核心主体的一致性。Logan 给出的一个核心趋势是：应用层的一个普遍现象是基础模型在系统性地「吞掉」周边基础设施——曾经作为外部平台脚手架搭建的工程能力（比如路由机制、执行环境封装），正逐渐被上移并整合进模型自身的核心逻辑中。 为什么重要：独立公司的生存空间在收窄 对于独立创业公司和软件初创团队而言，Logan 给出的结论并不轻松：长期生存将高度依赖于在特定垂直领域内的深度专精，只有这种独特的市场聚焦才能在某些场景下跑赢通用化的消费级系统。换句话说，「在模型外面搭一层路由 / 编排 / 执行环境」这件事本身的护城河正在变薄——基础模型每完成一次后训练迭代，就可能把昨天还需要专门团队维护的脚手架变成今天的「免费午餐」。 与今日其他报道的关系 这篇访谈给今天的另外两篇精讲提供了一个更长远的视角。精讲一里 Claude Managed Agents 把 harness 做成托管基础设施、精讲二里那位工程师辛苦搭出的三层加载架构和 G1-G8 门禁——这些工程投入的价值会随着模型本身「吃掉脚手架」的速度而发生变化。但这并不意味着这些投入是徒劳的：恰恰相反，越是「过程可观测、可固化成规则」的工程能力，越有可能被模型吸收为原生能力，而那些依赖深度领域知识、无法简单规则化的部分，反而会成为 Logan 所说的「垂直专精」的真正壁垒。这也是为什么精讲二的作者特别强调「这套模式的价值会随模型进化而衰减，当模型强到能自我保证流程纪律的那天，harness 就该功成身退」——两篇文章在不同立场上得出了相似的判断。 阅读建议 如果你在思考公司或团队的技术护城河，这段访谈值得完整看一遍，尤其是关于「世界模型」架构演进和「脚手架被吞」的部分，能帮你判断当前投入的工程能力哪些更容易被模型吸收、哪些更值得长期押注。完整内容见 BestBlogs 阅读原文。 ## 速览 为什么 AI 还没有取代软件工程师，而且也不会 这篇文章用「决策-执行-交付三明治」模型来解释一个反直觉的现象：尽管 AI 编程能力的进步速度和落地速度都远超其他行业，软件工程师的整体岗位需求并未出现大规模裁员。文章把知识工作拆成三层——决策（decide）、执行（execute）、交付（deliver），AI 主要压缩的是中间的「执行」层，但两端的「决策」和「交付」（包括对结果负责）依然高度依赖人类判断，不会因为模型能力的单纯提升而被自动化吞掉。文章还引用了一项基于真实 AI 编程会话日志的研究（SWE-chat），数据显示只有 44% 的 agent 生成代码最终进入了用户的正式提交。文章作者来自专注于 AI 评估的研究团队，本文是系列文章的第一篇，后续会讨论个体工程师的职业路径为何仍可能颠簸。阅读原文：BestBlogs。 云原生 - AI Native 多智能体数字人架构实践 阿里云开发者团队分享了他们基于商业化产品 AgentTeams 落地「数字员工小分队」的实践：通过声明式 CRD（自定义资源定义）把组织结构和协作策略模型化，让多个 Agent 像一个真实团队一样分工协作，而不是各自为政、互相抢活。文章用一个凌晨三点的告警场景开场——以前需要值班同学被叫醒、登录跳板机、翻日志、判断根因、必要时拉群升级，整套流程下来 MTTR（平均故障恢复时间）轻则一两个小时；而在 AI Native 的流程里，告警进来 30 秒内就有 Agent 数字人贴出第一轮诊断结论并 @ 另一个 Agent 进一步定位，90 秒后根因定位完成并给出可执行修复脚本，留给人的只是「是否在生产环境直接执行修复」这一个判断。 文章还梳理了从 RPA 到大模型再到多 Agent 协同的演进逻辑：RPA 是「录屏式」自动化，规则固定但不理解业务，界面一变就要返工；大模型带来了「理解」能力，Agent 不再是录屏脚本，而是能听懂模糊指令、查文档、调工具、做判断；但单 Agent 有天花板——上下文窗口有限，遇到需要多角色协作的真实业务场景（产品提需求、研发写代码、测试跑回归、文档同步发布）就会力不从心，于是自然演化到多 Agent 协同。文章特别强调「让多个 Agent 跑起来」和「让它们像一个团队一样工作」是两件完全不同的事：没有组织结构就没有稳定的分派关系，没有通信策略就没有可控可审计的消息边界，没有共享状态和统一网关就没法把 LLM 和工具（MCP）安全接入。AgentTeams 正是为解决这一整套组织化问题而生，文章给出了网络架构图和研发、值班、开源维护等场景的具体落地步骤。阅读原文：BestBlogs。 端侧 AI 提速 80%？如何让 Qwen3-VL 在手机起飞 通义实验室团队手把手演示了如何利用 Arm 第二代可伸缩矩阵扩展（SME2）指令集与 MNN 推理引擎，在支持 SME2 的旗舰手机（如 vivo X300）上部署 Qwen3-VL-4B 这样的多模态模型，实现 Prefill 阶段提速超过 80%。文章解释了 SME2 的核心突破——引入 ZA 矩阵累加器寄存器和流式模式，让 FMOPA 等指令可以一条指令完成一个矩阵 tile 的外积累加，相比传统 Neon 需要手工拆分向量乘再累加效率大幅提升。MNN 对 SME2 的支持采用「编译时内建 + 运行时自动检测」设计：编译时通过 MNN_SME2 开关（默认开启）控制是否编译优化内核，运行时自动检测硬件支持情况，不支持则平滑回退到 i8mm → Neon，不会崩溃；同时覆盖 FP32、FP16、INT8/INT4 三种精度，并集成了 Arm 官方 KleidiAI 加速库。文章给出了从引擎编译、模型部署到 APP 构建的完整实战流程。阅读原文：BestBlogs。 人是最慢的节点，还怎么管 AI Agent？｜AI 跃迁者调研 腾讯研究院「AI 跃迁者调研」系列第四期，深度访谈了开源 Agent 协作与编排平台 Multica 的创始人张佳圆。Multica 连续霸榜 GitHub Trending，一周涨 1.2 万 Star，访谈时已收获 2.75 万 Star，平台上每 10 秒就触发一个 Agent 任务——而做出这一切的团队只有 4 个人，这 4 个人本身也是 Multica 最极端的用户，构成了一个「4 人 + 几十个 Agent」的超级小团队。 访谈中提出了几个值得玩味的观点：整个组织的产出效率瓶颈如今已经是「人」而非 AI 或 Agent；建太多管理层级是对人类低效组织的拙劣模仿；快速做一个错误决策，比缓慢做一个正确决策更好，因为错误决策可以修正，但犹豫不决会让整个组织在某个环节卡死；只要活得足够久，本身可能就是一种很大的壁垒；而人的思考在 AI 时代是被低估的——AI 给出的东西可能只是一个「中位数」水平的答案。产品定位上，Multica 做的不是 Agent 本身，而是一个模型和平台中立的协作层，处理多个 Agent 怎么分工、怎么传递任务、怎么合并上下文。产品的三个核心概念分别是：运行时（Agent 运行的机器，可以是本地 MacBook、Mac Mini 或服务器，统一注册到 workspace）、智能体（相当于 AI 员工，可分配任务、设置角色）、Agent Team（多个 Agent 组成的小队，有自己的工作流程）。日常使用模式是创建任务、分配给对应的 Agent 或 Agent Team，人只需做最终 review，需要介入时会出现在 inbox 里。阅读原文：BestBlogs。 Fable AI 实现 1770% 性能提升并发现关键 Bug：我的个人奇点时刻 知名开发者 Taelin（@VictorTaelin）报告了一次他称之为「个人奇点时刻」的体验：Anthropic 的 Fable AI 在代码优化任务上，以数量级优势超越了他本人、Opus 4.8 以及一整群 GPT-5.5 智能体，实现了高达 1770% 的性能提升，并且在优化过程中还顺带发现了他自己代码里一个相当微妙的 Bug。这条推文引发了广泛讨论，因为它把「AI 代码优化能力超过资深开发者本人」这件事变得非常具体——不是某个 benchmark 上的分数对比，而是一次真实的、可验证的优化任务。阅读原文：BestBlogs。 CFO 的自白：为什么你的加薪变成了 GPU Peter Girnus（@gothburz）分享了一段来自某 CFO 的「自白」，揭示了一个企业用 AI 投资取代员工加薪决定背后的会计逻辑：花在人身上的每一块钱是当期费用（expense），会直接拉低利润率、受到市场审视；而花在 GPU 上的每一块钱则可以记为资本资产（capital asset），不会以同样的方式冲击利润表，也因此能规避市场对人力成本上涨的审视。这条推文用一种近乎赤裸的方式解释了为什么很多公司在「降本增效」叙事下，会优先把预算投向算力而不是涨薪——这并非单纯的技术判断，而是财务报表结构带来的激励扭曲，也是很多团队感受到「公司有钱买卡、没钱涨薪」的真实原因。阅读原文：BestBlogs。 "无招" 没变，但 AI 改变了公司和人才的权力关系 晚点 LatePost 以钉钉 CEO 陈航（花名"无招"）因高压管理风格被阿里合伙人委员会直接换掉为切入点，分析了 AI 时代大公司与顶尖人才之间权力关系的根本性转变。陈航以"高压"管理风格闻名，曾要求团队早 9 点打卡、深夜巡楼查岗，甚至要求员工动员亲友注册钉钉、完成"族谱上钉"的考核任务。这些管理方式过去虽屡受争议，但阿里内部一直没有针对性动作；这一次，一篇 7.5 万字的员工离职长文迅速传播后，阿里合伙人委员会在 6 天内罕见回应，直指钉钉的管理方式"不是阿里文化该有的样子"，不到 24 小时后陈航卸任 CEO。文章借此事件展开，探讨为什么在 AI 重塑生产力的当下，顶尖人才和公司之间的议价权正在发生结构性变化。阅读原文：BestBlogs。 ## 补充阅读 今天的候选内容里还有不少值得一看的角度，限于篇幅未能逐一展开，这里简单提一下： - 多智能体编排和协作平台是今天的一条隐藏主线——从 Claude Managed Agents 的托管编排，到阿里云 AgentTeams 的声明式协作模型，再到 Multica 的「4 人 + 几十个 Agent」实践，三者分别代表了「平台托管」「企业内部落地」「创业团队自建」三种不同的路径，适合关注智能体编排方向的读者对照阅读。 - 端侧推理优化（如 Qwen3-VL 的 SME2 提速）和云端智能体托管基础设施（如 Claude Managed Agents）看似是两个方向，但都指向同一个趋势：把"跑得动 AI"这件事的门槛持续往下压，无论是手机端还是企业基础设施。 - 关于 AI 对就业市场的影响，"决策-执行-交付三明治"模型和"CFO 的自白"可以放在一起读——前者从岗位需求结构的角度论证 AI 不会带来大规模裁员，后者从企业财务激励的角度解释了为什么算力投入比涨薪更"划算"，两者从不同角度解释了同一个现象的两面。 - 钉钉"无招"事件本质上是一个组织管理案例，但放在 AI 重塑权力关系的背景下读会更有意思——尤其是和 Multica 里"人是最慢的节点"的判断对照，能看到大公司和小团队在同一个趋势下走向了截然不同的应对方式：一边是用考勤和层级管理人，一边是用 Agent 团队去掉中间层、让 4 个人端到端做完所有事。 - 如果你既关心工程框架又关心组织设计，可以把今天的内容串成一条线读：harness 解决的是「AI 怎么干活才靠谱」，AgentTeams 和 Multica 解决的是「一群 Agent 怎么像团队一样协作」，而钉钉和 CFO 的两篇则提醒你，工程能力之外，组织和激励结构同样会决定 AI 红利最终流向谁。 ## 今日阅读路径 如果今天时间有限，建议按以下顺序读： 1. 精讲二《AI 不缺智商缺纪律：一场 Harness 工程化实践》——这是今天信息密度最高、最具操作性的一篇，三层加载架构和 19 节点裁剪规则可以直接套用到自己的 AI 工作流里，读完能立刻上手改造。 1. 精讲一《智能体交互界面的演进：使用 Claude Managed Agents 进行构建》——和精讲二形成互补视角，了解平台层提供了哪些「托管基础设施」，帮你判断哪些事该自己搭、哪些事该交给平台。 1. 精讲三《Google DeepMind 的 Logan Kilpatrick：为什么模型会吞掉智能体脚手架》——作为前两篇的「远景校准」，提醒你在投入工程化建设时，留意哪些能力可能很快被模型本身吸收。 如果还有余力，再读一下「人是最慢的节点，还怎么管 AI Agent？」——它把今天所有关于工程化、协作平台的讨论，落回到「人在这个体系里到底该做什么」这个最终问题上。 BestBlogs 是 AI 驱动的私人阅读助手，帮助你建立稳定、可信、个性化的高质量信息输入。它帮你判断什么值得读、协助你读懂，并逐渐理解你关注什么。

译本期精讲聚焦智能体工程化：Anthropic推出Claude Managed Agents，将推理与执行解耦，独立Vault管理凭证，事件日志支持运行恢复，首字延迟p50降约六成、p95降超九成。阿里工程师分享三层加载架构（常驻入口层压至8K上下文）、dispatcher状态机及G1-G8门禁，用结构约束替代堆prompt。Sequoia访谈指出模型正逐步吸收路由、执行环境等外层脚手架，独立创业公司窗口收窄。

ginobefun@hongming731 · 6月12日63

BestBlogs 早报 · 06-12 # Claude Managed Agents / Harness 工程化 / 模型吞脚手架 / Logan Kilpatrick / Gemini 3.5 Flash [1] ★ 精讲｜智能体交互界面的演进：使用 Claude Managed Agents 进行构建 | Claude Anthropic 推出 Claude Managed Agents，把智能体的「大脑」（推理循环）和「双手」（代码执行沙箱）彻底解耦，靠可恢复的事件日志连接两端：凭证统一存进独立的 Vault，绝不暴露给生成的代码，自托管沙箱还能让代码留在企业内网，首字延迟中位数降低六成、长尾降低九成以上，Notion、Sentry、Rakuten 等都已在生产环境跑通。 来源：Claude Blog https://www.bestblogs.dev/article/8e6ddfdf [2] ★ 精讲｜AI 不缺智商缺纪律：一场 Harness 工程化实践 一位阿里工程师复盘两个月的 AI Harness 演进：从把所有规则堆进 CLAUDE.md 导致「读完规则没脑容量读代码」，到三层加载架构 + dispatcher 状态机 + 文件交接 + G1-G8 门禁，再用 7 维确定性评分给每次改动打分，结论是「用更好的结构约束 AI，而不是用更多的字」。 来源：阿里技术 https://www.bestblogs.dev/article/07b28cbc [3] ★ 精讲｜Google DeepMind 的 Logan Kilpatrick：为什么模型会吞掉智能体脚手架 [视频] Google DeepMind 的 Logan Kilpatrick 在 Sequoia 访谈中提出「模型吞掉脚手架」：路由、执行环境这类原本搭在外层的工程能力正被模型本身逐步吸收，Gemini 3.5 Flash 的编程能力提升完全来自后训练；他认为随着基础模型不断「吃掉」周边脚手架，独立创业公司的出路只剩垂直领域的深度专精。 来源：Sequoia Capital https://www.bestblogs.dev/video/568d29c [4] 为什么 AI 还没有取代软件工程师，而且也不会 本文通过“决策-执行-交付三明治”模型论证 AI 不会取代软件工程师，解释了人类在决策和问责中的角色为何仍然至关重要。 来源：AI as Normal Technology https://www.bestblogs.dev/article/28a90882 [5] 云原生 - AI Native 多智能体数字人架构实践 本文介绍了阿里云基于云原生理念打造的 AI Native 多智能体数字人协作平台 AgentTeams，通过声明式 CRD 将组织结构与协作策略模型化，实现多 Agent 像团队一样协同工作，并分享了在研发、值班、开源维护等场景的落地实践。 来源：阿里云开发者 https://www.bestblogs.dev/article/cb8e134b [6] 端侧 AI 提速 80%？如何让 Qwen3-VL 在手机起飞 本文手把手演示如何利用 Arm SME2 指令集与 MNN 推理引擎，在支持 SME2 的旗舰手机上实现 Qwen3-VL-4B 多模态模型的高效部署，Prefill 阶段提速超 80%。 来源：通义实验室 https://www.bestblogs.dev/article/2e22b643 [7] 人是最慢的节点，还怎么管 AI Agent？｜AI 跃迁者调研 本文深度访谈 Multica 创始人张佳圆，揭示了一个 4 人团队如何通过 Agent 协作平台实现组织效率革命，并探讨了人在 AI 时代的新角色与思考边界。 来源：腾讯研究院 https://www.bestblogs.dev/article/7bf0f7d2 [8] Fable AI 实现 1770% 性能提升并发现关键 Bug：我的个人奇点时刻 Taelin 报告称，Anthropic 的 Fable AI 在代码优化方面以数量级优势超越了他本人、Opus 4.8 以及一群 GPT-5.5 智能体，甚至还发现了他自己代码中的一个微妙 Bug。 来源：Taelin(@VictorTaelin) https://www.bestblogs.dev/status/2064448425936994742 [9] CFO 的自白：为什么你的加薪变成了 GPU 一位 CFO 解释称，用 AI 投资取代员工加薪的决定纯粹是会计把戏：花在人身上的每一块钱是费用，而花在 GPU 上的每一块钱则是一项可以规避市场审视的资本资产。 来源：Peter Girnus 🦅(@gothburz) https://www.bestblogs.dev/status/2064800166272512122 [10] “无招” 没变，但 AI 改变了公司和人才的权力关系 本文以钉钉 CEO 陈航（无招）因高压管理被阿里合伙人委员会直接换掉为引子，深入分析了 AI 时代大公司与顶尖人才之间权力关系的根本性转变。 来源：晚点 LatePost https://www.bestblogs.dev/article/959001dd --- http://BestBlogs.dev · 发现真正适合你的高质量内容 BestBlogs 是 AI 驱动的私人阅读助手，帮助你建立稳定、可信、个性化的高质量信息输入。 关注你感兴趣的来源和主题，每天生成一份更适合自己的「我的早报」。 在线阅读：https://www.bestblogs.dev/explore/brief/2026-06-12

译Anthropic推出Claude Managed Agents，将推理循环与代码执行沙箱解耦，凭证存入独立Vault，自托管沙箱支持内网，首字延迟中位数降低六成、长尾降低九成。阿里工程师复盘Harness工程化，提出三层加载架构与G1-G8门禁。Google DeepMind的Logan Kilpatrick称模型正“吞掉”脚手架，Gemini 3.5 Flash编程能力完全来自后训练。另，Qwen3-VL-4B在支持SME2的旗舰手机上Prefill提速超80%；Fable AI实现1770%性能提升并发现关键Bug；此外涉及AI取代工程师、多智能体数字人、CFO用GPU替代加薪等讨论。

凡人小北@frxiaobei · 6月12日77

AI 上云

译OpenAI已达成协议收购Ona。其安全云执行技术将帮助Codex在笔记本电脑合盖后继续处理长时间运行的工作，并帮助更多组织在生产环境中安全部署AI智能体。交易完成后，Ona将加入OpenAI Codex团队。主推文：「AI 上云」。

meng shao@shao__meng · 6月12日74

Claude Fable 5 首发一天后的 playbook：8 条共识、3 个陷阱，以及互联网怎么说 @mvanhorn 用 /last30days 扫了 865 条跨平台讨论、再结合自己实测后写下的首日实践总结。整理出社区在 24 小时内已经收敛出一套可复用的用法，以及一堆代价与陷阱。 核心判断 Claude Fable 5 是一个高自主、高成本、偏规划编排的模型。首日共识很一致： · 给更难的目标，少给步骤 · 让它当指挥，不当苦力 · 免费窗口内把经验固化成 Skill，窗口关闭后靠便宜模型执行 把它当 “更听话的 GPT” 用，大概率又贵又慢，还容易踩安全回退。 # 八条实践，逐条展开 1. 任务要更难，提示要更短 官方口径是 aim higher：少说“第一步、第二步”，多讲终点。过度拆解的旧 prompt 反而会拉低质量。 隐含能力变化：模型自主规划变强了，微管理变成负资产。同时别让它复述内部推理——容易触发拒绝。 社区讽刺很到位：人人被教育要“瞄准神话级”，人人还是在做 Todo 和贪吃蛇——说明认知升级滞后于能力升级。 2. 设目标，不设路径；但必须设刹车 /goal 代表工作流从任务清单 → 持续对齐高层目标。Claude Code 团队自己也这么用。 代价：它会一直干，直到你叫停。长任务必须写清：预算上限、时间上限、或明确的“完成条件”。否则不是智能，是失控。 /goal make 1 million dollars 是社区对这条逻辑的幽默推演。 3. 编排者，不是执行者 · 规划 / 拆任务：Fable · 实现：Sonnet · 测试 / 验证：Haiku 验证用新上下文的 agent，通过才提交——这是首日最务实的工程模式。 Stripe 50M 行 Ruby 一天迁移，是官方背书的上限案例；无 spend limit 跑 subagent 则是下限警示。能力真，账单也真。 4. Effort 旋钮：Medium 可能最适合 · Medium 的 Fable 有时能打过 High/Max 的 Opus，且 token 更少 · 严肃 agent 工作可钉在 xhigh；ultracode 极耗额度 · 付费计划里 Fable 按双倍用量计费 结论：不是越强越好，而是匹配任务复杂度。 用 Fable 做常规活，像请外科医生修指甲。 BridgeMind 一天 7 亿 token、三套 Max 订阅打穿月限额——能力认可与成本恐惧并存。 5. 两条隐形降级线 安全回退：触发分类器会静默切到 Opus 4.8，输出质量突然变差时，先怀疑路由而非模型变笨。误杀案例（hello、cancer、发酵食品）说明假阳性是实操问题，不是段子。 可引导性弱：Arena 数据——任务成功 #1，可引导性 #17。能做的事很强；不想做时很难拧。约束要写得像承重墙，不能当建议。 系统提示泄露与越狱同日出现，说明防护与能力赛跑，用户侧不能假设“官方护栏 = 你的护栏”。 6. 视觉输入是首日被低估的杠杆 截图 → 可运行应用，比文字描述 UI 有效得多。像素优于形容词。 同时反差也好笑：神话级算力用来清邮箱——说明真实刚需往往是枯燥自动化，不是 demo 炫技。 7. 喂业务上下文，别追 demo 高杠杆用法就一段 prompt：讲清业务（卖什么、客户、栈、团队、瓶颈、上季度数字），让它列 8 件本月最高杠杆工作 并立刻推进第一件所需的数据/权限。 Demo（贪吃蛇、克隆 Notion）传播广；业务诊断式 prompt 更可能产生可重复价值。 8. 免费期是“蒸馏窗口”，不是无限狂欢 Pro/Max/Team 免费到 6 月 22 日，之后约 $10/M 输入、$50/M 输出（约为 Opus 两倍）。 最佳策略：正常工作中遇到 Fable 的巧解，让它写成 Agent Skill 留存——两周免费换长期能力资产。 企业侧：微软因 30 天数据保留 从内网 Copilot 下架 Fable——能力与合规张力，首日已显现。 Claude Fable 5 Playbook · 说清结果，删掉保姆步骤 · /goal + 硬性停止条件 · Fable 规划 → Sonnet 写 → Haiku 验 · 先试 medium effort · 质量骤降先查是否被 safety 路由 · 截图优先 · 跑一次业务 prompt · 6/22 前把解法蒸馏成 Skill

译社区基于865条讨论与实测总结：Claude Fable 5高自主、高成本、偏规划编排。核心共识：给更难目标、少给步骤；用Fable规划→Sonnet实现→Haiku验证；免费窗口（截至6月22日）内将经验固化为Skill。Effort旋钮Medium最省token且效果接近High；付费计划下输出价约$50/M token。安全回退静默切至Opus 4.8；视觉输入（截图→应用）比文字更有效。最佳策略：跑一次业务prompt诊断，把解法蒸馏成Skill留存。

meng shao@shao__meng · 6月12日75

Spec 驱动开发 (SDD) 需要这三个 Skills：覆盖 Spec -> Implement -> Verify 闭环 Agent 出错往往是需求理解偏差。解决办法是把规格当作 PR 的一部分，让队友和 Agent 都能对照同一份文档。 规格分两层： 1. 产品规格：PRODUCT.md 做什么，用户视角、用户故事、可验证的产品不变量 2. 技术规格：TECH.md 怎么做，架构、代码位置、实现策略 都放在 specs/<issue>/ 目录，随实现 PR 一起提交、一起 Review。 # SDD 五步流程（包含三个 Skills） 1. 写产品规格（/write-product-spec） 从用户行为出发，写用户故事和详细的不变量（invariants）——即「无论什么情况都必须成立」的规则。可附 Figma、截图等。这些不变量后续可被代码检查，甚至用计算机操作（computer use）验证。 2. 写技术规格（/write-tech-spec） 在同一目录生成 TECH.md，说明架构思路、改哪些文件、实现时要注意什么。这是给 Agent 的「施工图纸」。 3. 让 Agent 按规格实现 理论上任何 Agent、包括推理能力较弱的模型，只要有清晰规格，实现质量都会更稳定。 4. 规格一致性校验（/validate-changes-match-specs） 实现后不能默认「做完了就对」。用 Skill 让 Agent 对照 PRODUCT.md 和 TECH.md 自查，列出与规格不一致之处，再由人决定如何处理。这是规格驱动开发里容易被忽略、但很关键的一步。 5. 用计算机操作做端到端验证 Warp 内部用 Oz 做 UX 验证：在云端沙箱里给 Agent 鼠标键盘权限，模拟真实用户操作。对他们这种 Rust 原生桌面应用尤其必要——单元测试覆盖不了完整交互链路。 # 为什么用这三个 Skills 编码流程 Skills 把「怎么写产品规格」「怎么写技术规格」「怎么校验」固化成可复用指令，不绑定 Warp，流程可移植。 @warpdotdev 开源仓库：warpdotdev/common-skills 安装：npx skills add warpdotdev/common-skills 本质是把人的工程习惯（先 PRD、再设计、再实现、再验收）变成 Agent 可执行的流水线。

译邵猛分享 Spec 驱动开发（SDD）方法，用三个 Skills（/write-product-spec、/write-tech-spec、/validate-changes-match-specs）覆盖 Spec→Implement→Verify 闭环。规格分两层：PRODUCT.md（用户故事、不变量）和 TECH.md（架构、实现策略），均放在 specs/<issue>/ 目录，随 PR 提交。五步流程：写产品规格、写技术规格、Agent 按规格实现、一致性校验、计算机操作端到端验证。Skills 可移植，不绑定 Warp。开源仓库 warpdotdev/common-skills，安装：npx skills add warpdotdev/common-skills。

Tibo@thsottiaux · 6月12日71

Codex 🤟Ona Beyond excited to work with Johannes and team to build the future.

译OpenAI宣布已达成协议收购Ona，其安全的云执行技术将帮助Codex处理更长期的任务（即使笔记本电脑关闭也能运行），并让更多组织安全地部署智能体。收购完成后，Ona将加入OpenAI的Codex团队。Tibo对此表示“无比兴奋，期待与Johannes及团队共同构建未来”。

Replit ⠕@Replit · 6月12日72

How to prompt like a pro with Replit 🤖 Vague prompts just mean more rewrites. Here's how to get Agent to build the right thing the first time. 🧵 Open thread ↓

译如何像专家一样使用 Replit 进行提示 🤖 模糊的提示词只会导致更多重写。以下是如何让 Agent 第一次就构建出正确的东西。 🧵 展开线程 ↓

Rohan Paul@rohanpaul_ai · 6月12日62

This paper shows an AI improving itself better when it rewrites its setup and updates its model. The problem is that most AI progress still depends on people changing prompts, tools, code, training data, and model weights by hand. The paper’s idea is SIA, a loop where one AI watches how a task agent performs, then either changes the agent’s outer setup or trains the model itself. The outer setup means things like prompts, tools, retry rules, and output parsing, while weight updates mean changing the model’s learned behavior through task feedback. The loop works like this: the task agent tries many answers or programs, the verifier scores them, and those scores become training feedback. Then the system updates a small add-on set of weights called LoRA weights, which changes the model’s behavior without retraining the whole model. So the base model stays mostly the same, but the LoRA adapter learns, “outputs like this got high reward, outputs like that failed.” The authors tested this on 3 very different tasks: Chinese legal charge classification, GPU kernel speed tuning, and single-cell RNA denoising. The combined version beat setup-only improvement on all 3 tasks, reaching 70.1% on LawBench, faster GPU code than the prior best, and 0.289 on denoising. The main lesson is that better scaffolding helps the agent act better, but weight updates help it learn task patterns that prompts and tools alone did not find. ---- Link – arxiv. org/abs/2605.27276 Title: "SIA: Self Improving AI with Harness & Weight Updates"

译该论文提出SIA框架，让AI自动循环改进：一个观察者AI监控任务代理的表现，然后修改其外部设置（提示词、工具、重试规则、输出解析）或通过LoRA权重更新训练模型本身，模型主体不变，仅适配器从任务反馈中学习。在三个任务上测试：中文法律罪名分类（LawBench达70.1%）、GPU内核速度调优（生成代码优于此前最佳）、单细胞RNA降噪（得分0.289）。综合版本在所有任务上超越仅修改设置的方案，表明权重更新能帮助模型学到提示和工具无法发现的模式。

Rohan Paul@rohanpaul_ai · 6月12日83

Jeff Bezos on CNBC explains revealed what Prometheus is building. Today his new company Prometheus announced a $12B funding round at a valuation of $41B . Prometheus trying to build an artificial general engineer that can help design and manufacture physical products like engines, medical devices, and electronics. So the target areas are hard physical products like jet engines, chips, bridges, medical devices, consumer electronics, aerospace systems, vehicles, and drug design, where design cycles can take years because every idea has to survive physics, materials, cost, testing, and factory limits. Bezos’ jet-engine example explains it well: asking for the same engine with 10% more thrust can become a 10-year engineering program, and Prometheus wants to shrink that “dream-build” cycle by 10x or more. The $6.2B launch funding gave Prometheus a massive starting base, and the new raise says the company likely needs far more compute, talent, and industrial data before it can prove the product. Their $41B valuation shows that frontier AI is becoming less a software race than a compute procurement race. A company with no broadly shipped product can raise $12 billion at a $41 billion valuation because investors are not only funding a model, they are prepaying for the machines that might make the model possible. The scarce asset is no longer just talent or algorithms, but clustered GPUs, power contracts, cooling, networking, and the operational skill to keep expensive silicon busy. They are proof that demand is arriving faster than infrastructure can be built, and that every frontier funding round quietly turns into a future claim on power, racks, GPUs, and uptime.

译Jeff Bezos 在 CNBC 披露其新公司 Prometheus 的愿景：构建人工通用工程师，设计制造喷气发动机、芯片、医疗设备等硬物理产品，将传统数年设计周期缩短 10 倍以上。公司宣布完成 120 亿美元融资，估值 410 亿美元。初始启动资金 62 亿美元，新一轮融资表明公司需要更多算力、人才和工业数据才能验证产品。410 亿美元估值表明，前沿 AI 已从软件竞赛变为计算采购竞赛——投资者实质在为可能实现模型所需的机器预付费。

swyx@swyx · 6月12日61

congrats to our friends @ona_hq on joining @openai! see their talk here for alpha on what’s next for Codex 👀

译swyx 祝贺 ONA 团队加入 OpenAI，并引用其演讲透露 Codex 的下一步方向。同时引述 @aiDotEngineer 观点：运行 Agent 集群需要三层——Runtime 与编排触发器已解决，但协调层（Agent 间任务交接、验证阶段、继续执行）仍未解决。Stripe 和 RAMP 各自自建了内部方案 Minions 和 Inspect。@loujaybee 指出 GitHub 作为协调层很差——噪音大、仅为人类设计，不适合数百个并行 PR。他提出的修复方案是构建一个 CLI 网关，供本地编码 Agent 调用以检查当前 SDLC 阶段是否已通过、能否继续。

Rohan Paul@rohanpaul_ai · 6月12日67

OpenAI is buying Ona to give Codex agents a secure cloud desk that stays open after humans leave. Codex already has 5M weekly users, up 400%, but harder work breaks the old chat pattern because agents need tools, files, credentials, logs, and time. Ona adds persistent cloud workspaces, meaning an agent gets a controlled place to run commands, inspect systems, preserve context, and resume work without depending on one device. The enterprise angle is the real acquisition target: companies want agents inside their own cloud boundary, with scoped credentials, review trails, access limits, and auditable activity. This makes Codexmore like a managed execution layer for tests, bug fixes, refactors, vulnerability work, migrations, and multi-step knowledge tasks.

译OpenAI 宣布收购 Ona，其安全云端执行技术可为 Codex 智能体创建持久云端工作空间——用户离开后，智能体仍可持续运行命令、检查系统、保留上下文并跨设备恢复任务。目前 Codex 周活用户达 500 万（增长 400%）。收购旨在强化企业级部署：智能体可在企业云边界内运行，具备作用域凭证、审核追踪、访问限制和可审计活动，适用于测试、漏洞修复、重构、迁移等多步骤任务。收购完成后，Ona 团队将加入 OpenAI Codex 团队。

宝玉@dotey · 6月12日73

我用 /goal，长任务很稳定，就不用继续了

译宝玉表示使用 /goal 指令后，长任务运行稳定，不再需要像许多用户那样在AI意外停止时输入“继续”。引用推文指出，不少AI新手不知道AI意外停止时只要发一句“继续”即可恢复任务。宝玉的实践表明，/goal 指令能有效减少此类中断需求。

xAI@xai · 6月12日73

Install the @sentry plugin and ask your agent to find and fix errors, analyze stack traces, and triage alerts

译Grok Build 插件市场现已进入公测阶段。你可以在终端中使用 MongoDB、Vercel、Sentry、Cloudflare 和 Chrome DevTools 等插件进行开发。详情：https://x.ai/news/grok-plugin-marketplace

Greg Brockman@gdb · 6月12日69

welcome @ona_hq to the team, to help organizations deploy agents securely in production!

译欢迎 @ona_hq 加入团队，帮助组织在生产环境中安全部署智能体！

Replit ⠕@Replit · 6月12日65

AI agents are powerful, but they don’t remember your preferences. So you end up repeating instructions- How you structure projects. Your brand guidelines. You can now teach Replit Agent your conventions with Custom Instructions and Skills. It'll take them into account for every project automatically.

译AI 智能体很强大，但它们不记得你的偏好。 所以你总是重复指令——如何组织项目、你的品牌指南。 现在你可以通过自定义指令和技能让 Replit Agent 学会你的惯例。 它会在每个项目中自动将这些考虑进去。

🚨 AI News | TestingCatalog@testingcatalog · 6月12日68

Perplexity Deep Research is now available on Perplexity Computer as a native skill. > Computer breaks the hardest questions into subtasks, routes them across 20+ frontier models, and returns work-ready reports, decks, and dashboards. > Available now to Pro and Max subscribers. Even Deep Research is a Computer 👀

译Perplexity Deep Research 现以原生技能形式集成至 Perplexity Computer 平台。Computer 负责将复杂问题分解为子任务，路由至20多个前沿模型，并返回报告、演示文稿和仪表板。Deep Research 基于 Search as Code 架构构建，模型编写代码自行组装搜索，并行执行数千次检索步骤，在所有基准测试上均超越旧版 Deep Research。该功能已面向 Pro 和 Max 订阅用户开放。

Perplexity@perplexity_ai · 6月12日77

We're integrating Deep Research as a native skill inside Computer. It now connects to the agent harness that powers Computer, with access to search as code generation, long running sandboxes, connectors, tools, and licensed data. Available now to Pro and Max subscribers.

译我们正在将 Deep Research 作为原生技能集成到 Computer 中。 它现在连接到驱动 Computer 的智能体框架，可访问搜索即代码生成、长运行沙箱、连接器、工具和授权数据。 Pro 和 Max 订阅者现已可用。

向阳乔木@vista8 · 6月12日46

发现Claude Fable 5强的地方之一，可能是模型思考推理的时间足够长。 刚提了个想法，它思考15分钟才开始行动，牛逼。

AK@_akhaliq · 6月12日60

Toward Generalist Autonomous Research via Hypothesis-Tree Refinement

译通过假设树精炼迈向通用自主研究

Berryxia.AI@berryxia · 6月12日60

Agent 几件套是必不可少的就是“记忆层”！ Grok 终于 可以记住你了！ Grok终于能记住你了，而且你还能随时翻出来看、改、删，这才是真正把AI从“每次聊天都重头来过”的工具，变成了陪你一起成长的伙伴。 以前每次打开Grok都得重新解释你的项目、偏好、目标，聊着聊着上下文就断了。现在它会主动把有用的细节留下来，下次直接接上，继续帮你推进。 更狠的是你完全掌控：想让它忘掉什么就删，觉得哪里不对就编辑，透明到不能再透明。隐私和个性化同时拉满。 如何开启？ 打开Grok -设置按钮- 选择 记忆 - 然后开启记忆按钮。 可以查看记忆，编辑记忆等。

译Grok 推出“记忆”层，能记录用户之前的对话细节（项目、偏好、目标等），避免每次聊天从头开始。用户完全掌控：可查看 Grok 记住了什么、随时编辑或删除不需要的记忆。启用方式：打开 Grok 设置 → 记忆 → 开启。该功能旨在让 AI 越来越了解用户，提供更个性化的辅助体验。

🚨 AI News | TestingCatalog@testingcatalog · 6月12日71

OpenAI ❤️ Ona OpenAI acquired Ona, a cloud execution platform for AI agents. > Its secure cloud execution technology will help Codex take on longer-running work, even when laptops are closed, and help more organizations deploy agents securely in production. Managed OpenAI Agents soon?

译OpenAI 已达成协议收购云执行平台 Ona，其安全云执行技术将帮助 Codex 处理更长时任务（即使笔记本关闭也能继续运行），并让更多组织在生产环境中安全部署智能体。收购完成后，Ona 团队将加入 OpenAI 的 Codex 部门，此举或预示着托管 OpenAI 智能体服务的到来。

AYi@AYi_AInotes · 6月11日71

Fable 5是真的厉害真的好用， 但也真的贵啊， 今天直接干掉$1000+😭

译用户分享 Claude Fable 5 体验：仅靠一句指令“给你自己做个落地页，自由发挥，要2026最新设计趋势，要彩蛋”，Fable 5 在几分钟内自动生成完整单文件 HTML，无需任何修改。它主动搜索 2026 设计趋势、调整配色和动效，并偷偷藏了 3 个彩蛋。用户惊叹其代码质量和文笔，但当天因使用 Fable 5 耗费超过 $1000，称“真的贵”。

向阳乔木@vista8 · 6月11日75

很多朋友问，如何给Codex写一个好的Goal指令？ 睡觉前执行，模型自动开发，第二天“收菜”。 发过4w字文档，但多数人懒的看，所以我写了个Skill。 把一句话需求变成目标，复制就能用。 安装指令： npx skills add joeseesun/qiaomu-goal-meta-skill 源码免费开源，见评论区

译针对如何给Codex写Goal指令的问题，作者发布了一个Skill，可将一句话需求自动转化为目标，实现“睡前写指令、模型自动开发、第二天收菜”。安装命令：`npx skills add joeseesun/qiaomu-goal-meta-skill`。源码免费开源（见评论区），旨在简化4w字文档的阅读负担。

Rohan Paul@rohanpaul_ai · 6月11日52

The cold open in this Parloa video is every dev’s API stress list. docs, middleware, auth, error handling, retries, data mapping.... There has to be a better way. Parloa just launched Agent Skills, an MCP-based layer to replace brittle API glue with self-healing agent workflows. Their success numbers: first integration a day, the second an hour, every use case after that is config — and a top-10 travel co cut average handle time by over a minute.

译Parloa 发布 Agent Skills，基于 Model Context Protocol (MCP) 构建，旨在替代脆弱的 API 胶水代码。业务团队可在 AI Agent 管理平台 (AMP) 上零代码配置完整集成链，集成时间从 4-8 周缩短至数小时。关键特性包括：工具调用逻辑一致且能自愈、可定义成功条件追踪真实结果、执行链可审计可重试。早期数据：平均处理时间减少 67 秒，通话转接中客户沟通提升 39%，多工具路由可靠性提高 20%。首个集成一天完成，第二个仅一小时，后续用例只需配置。一家 Top-10 旅游公司平均处理时长缩短超一分钟。

elvis@omarsar0 · 6月11日51

Increasingly, how I'm effectively leveraging agents: Routing - routing different tasks to the right agent Looping - instructions + skills + dynamic workflows + automations It's how you get more control over costs and performance, and how you better prepare for changes ahead.

译越来越多地，我有效利用智能体的方式： 路由——将不同任务路由到正确的智能体 循环——指令 + 技能 + 动态工作流 + 自动化 这就是你如何更好地控制成本和性能，以及更好地为未来的变化做准备。

Lee Robinson@leerob · 6月11日56

We're training the next version of Composer... with Composer! The model is always learning from itself. This kind of "recursive self-improvement" might sound new, but it's been happening for many months! For example, training big models requires creating *lots* of data for RL - essentially games the model plays to improve at any task you can grade. The newest models can configure their own environments to make those games playable (auto-installing dependencies, fixing broken setups). Composer 2 was *dramatically* better at this than version 1. So the better the model gets, the better it gets at creating the conditions to train its successor. Each generation unlocks capabilities the previous one didn't have! So cool. https://x.com/cursor_ai/status/2052116064474161556

译Cursor 正用当前版 Composer 训练下一代 Composer，形成递归自我改进循环。训练大型模型需要大量 RL 数据（模型通过“游戏”提升能力），新模型能自动配置开发环境（如自动安装依赖、修复故障）。Composer 2 在环境配置能力上显著优于版本 1，模型越强，越擅长创造训练其继任者的条件。Cursor 的 autoinstall 系统让前代 Composer 设置 RL 训练环境，使下一代专注于解决更难题，每一代都解锁先前版本不具备的能力。

Rohan Paul@rohanpaul_ai · 6月11日61

AI agents may turn software from fixed code into systems that can plan and build on demand. This paper argues that code may stop being the central artifact. For decades, software meant frozen intent: a human anticipated a situation, translated judgment into rules, and shipped those rules into the world. Agents disturb that bargain because they can turn intent into action at runtime, generating code as a disposable tool rather than treating it as the product. The real shift is not from human coding to AI coding; it is from predesigned behavior to negotiated behavior, where the system keeps interpreting the goal as conditions change. That sounds powerful, but it is also where the danger lives. A static program fails inside boundaries we can often inspect, while an agent can fail through drift, overconfidence, bad memory, or a plausible chain of steps that quietly compounds an early mistake. So the paper is not saying coding tools will get better, but that software itself may become a living agent system where humans guide intent and audit outcomes. So the future engineer is not just a prompt writer, and not merely a supervisor of digital interns. The valuable person becomes someone who can define intent, constrain autonomy, design evaluation, inspect reasoning traces, and know when the machine’s fluent answer is not the same as a reliable system. ---- Link – arxiv. org/abs/2606.05608 Title: "Agentic Software: How AI Agents Are Restructuring the Software Paradigm"

译该论文认为，AI智能体可能使软件从固定代码转变为按需规划和构建的系统，代码不再是核心产物。传统软件预先固化规则，而智能体在运行时将意图转化为行动，把代码视为一次性工具。真正转变是从“预设计行为”到“协商式行为”，系统随条件变化不断解读目标。但这也带来新风险：静态程序在可检查边界内失效，智能体可能因漂移、过度自信、记忆错误或逐步放大早期错误而失败。未来工程师的关键能力是定义意图、约束自主性、设计评估、检查推理痕迹，并辨别流利回复与可靠系统的区别。

Google DeepMind@GoogleDeepMind · 6月11日62

When millions of AI agents interact with each other, new collective behaviors can emerge. 🌐 Together with @schmidtsciences, @coop_ai, @ARIA_research and supported by @GoogleOrg, we’re launching a $10M research fund to help understand how AI systems behave as a group. → https://goo.gle/3Si6rCl

译当数百万个AI智能体相互交互时，新的集体行为可能涌现。🌐 与 @schmidtsciences、@coop_ai、@ARIA_research 合作，并由 @GoogleOrg 支持，我们正在启动一个1000万美元的研究基金，以帮助理解AI系统在群体中的行为。→ https://goo.gle/3Si6rCl

SiliconFlow@SiliconFlowAI · 6月11日71

@NousResearch has shipped Hermes Agent Desktop — and it's now even easier to use frontier open-source models through @SiliconFlowAI 🔥 → One click to switch models anytime — DeepSeek-V4, GLM-5.1, Kimi-K2.6, MiniMax-M3, and more, all on SiliconFlow ... ... Full guide to start your Hermes trip with SiliconFlow 👇🧵

译@NousResearch 发布了 Hermes Agent Desktop——现在通过 @硅基流动 SiliconFlow 使用前沿开源模型更加便捷 🔥 → 一键随时切换模型——DeepSeek-V4、GLM-5.1、Kimi-K2.6、MiniMax-M3 等，均在硅基流动上 ... ... 通过硅基流动开启你的 Hermes 之旅的完整指南 👇🧵

Berryxia.AI@berryxia · 6月11日76

对了 直接限时免费！！ 所以大家可以用起来啊～ https://mimo.xiaomi.com/zh/mimocode

译小米开源MiMo-Code，为终端原生AI coding助手，fork自OpenCode。新增SQLite持久记忆实现跨会话永久记忆，配备build/plan/compose三类子代理、自动checkpoint、智能上下文预算，及/dream自我提炼知识与/distill打包技能进化机制。零配置支持任何OpenAI兼容模型，一键curl安装，MIT协议。此前MiMo 2.5模型已接入Bloome作为Agent使用，且MiMo-Code限时免费。

Peter Steinberger 🦞@steipete · 6月11日78

Here's a simple loop: Tell codex to maintain your repos, wake up every 5 minutes and direct work to threads. That makes it easy to parallelize+steer work as needed. I use a orchestrator skill combined with my triage+autoreview+computer use skills, so some work can land autonomously. https://github.com/steipete/agent-scripts/blob/main/skills/maintainer-orchestrator/SKILL.md https://github.com/steipete/agent-scripts/blob/main/skills/github-project-triage/SKILL.md

译一个简单的循环：告诉 Codex 维护你的仓库，每5分钟唤醒一次，将工作直接分配到线程。这样可以轻松按需并行化和导向工作。 我使用一个编排器技能，结合我的分类+自动审查+计算机使用技能，因此部分工作可以自主落地。

Alibaba Cloud@alibaba_cloud · 6月11日42

🎙 Alibaba Cloud ClawTalks EP6 | Data + Agent = Your AI Workforce: Launch of Alibaba Cloud AI-native Database Service 📅 June 24, 2026 | 10:00 AM (UTC+8) | 30 min 🔗 Register now → https://int.alibabacloud.com/m/1000414360/ Your database shouldn't just store data—it should work for you. Introducing ApsaraDB Enterprise Agents: AI-native agents that live inside your database, think with context, and act autonomously. What you'll see in 30 minutes: ✅ Autonomous ops — analytics, governance, data prep, zero hand-holding ✅ Enterprise-grade security — granular access, data masking, token controls ✅ Self-improving — agents that learn and adapt on the job #AlibabaCloud #ClawTalks #ApsaraDB #AIAgents #DataIntelligence

译阿里云宣布推出ApsaraDB Enterprise Agents，即内置于数据库中的AI原生智能体，可自主执行分析、治理、数据准备等运维任务，无需人工干预；具备企业级安全能力（细粒度访问控制、数据脱敏、token管控），并能自我学习适应。相关活动将于2026年6月24日10:00（UTC+8）线上举办，时长30分钟。