精选归档 · 第 15 页

281300 条 · 共 403

5月15日5月15日周五

星期五 · 6 条
20:42
AYi@AYi_AInotes精选
AI 评分 76/100
飞书开源CLI工具45天获万星,AI操作可见可控引关注刚刚花三分钟装了飞书官方那个 CLI 工具, 跑了一句话,建群、建文档、发通知,一次性全做完了,我盯着终端看了几秒钟, 才反应过来这玩意儿真的能让 AI 直接操作飞书。装的过程没啥可说的, 一行 npx @larksuite/cli@latest install, 三分钟搞定,我试的场景挺日常,让 AI 帮我处理这么一件事, 明天上午十点和算法团队拉个会, 建一个会前准备文档, 把上周遗留的几个 issue 写进去, 然后在群里 @ 所有人通知时间,终端里它一步步在 print 自己要做什么, 建群、建文档、写入内容、发消息, 每一步都能用 --dry-run 先预览一遍再真的执行, 我作为人类全程能看清 AI 在干嘛,这跟我之前接 MCP 那种 AI 在云里自己执行你看不到的体感,完全不是一个东西,跑完我才回头去看 GitHub, 飞书这个 lark-cli 今天 star 数刚好破 1 万, 开源到现在 45 天, 平均每天 219 颗星,GitHub 的 star 跟微博点赞不一样, 每一颗都挂在一个真实开发者的账号上, 是国内办公套件里第一个、也是目前唯一一个破万星的开源项目, 但真正让我对这条新闻改观的, 是另一个被很多人划过去的数字,国内三家办公套件都开了 CLI,飞书、钉钉、企业微信, 只有飞书的主干里有 10 位真实外部开发者的代码被合进来,包括一个河南科大的实习生和一个土耳其的电商工程师,另两家是 0 和 0,星是路过给的, PR 是动手写的, 这两个指标的含金量差了一个量级。Notion 和 Figma 走的是 MCP 路线, 飞书选了 CLI,跑过一遍以后我有点理解这个选择了,AI 在 CLI 里执行任务, 每一步是可见的、可预览的、可审查的, 这个对开发者来说不是 fancy, 是真正能放心交给 Agent 去做事的前提,以后让 AI 帮我从拉会到归档跑完一个完整项目流, 可能真就是一句话的事啊。飞书开源命令行工具lark-cli在45天内获得超过1万GitHub star,成为国内首个破万星的办公套件开源项目。该工具允许AI通过命令行直接操作飞书,执行建群、建文档等任务,且每一步操作都可预览、可审查,与云端不可见的MCP模式形成对比。其主干代码已合并10位外部开发者的贡献,而同类产品钉钉和企业微信则为零。这种可见、可控的特性被视为开发者放心将任务交给AI Agent的前提,预示着一句话指令驱动完整项目流程成为可能。

推荐理由:飞书CLI把AI操作办公套件的每一步都摊在终端里,这种透明感是MCP黑箱给不了的,加上1万星和10个外部PR,这组数字比任何PR稿都诚实。
02:00
Claude:Blog(网页)精选
AI 评分 73/100
在大型代码库中高效运用Claude Code:最佳实践与入门指南

Claude Code已成功部署于数百万行的单体仓库、遗留系统及分布式架构中。其核心在于围绕模型构建的“工具套件”,而非仅依赖模型本身。该套件包含五个关键扩展点:提供代码库概览的CLAUDE.md文件、实现持续改进的钩子、按需加载专业知识的技能、插件以及MCP服务器。它采用智能体搜索模式,直接在开发者本地实时代码库上操作,无需构建和维护集中式索引,从而避免了传统RAG系统在活跃大型代码库中索引过时的问题。团队对代码库设置的投入程度直接决定了其导航效果。


推荐理由:这是 Anthropic 官方出的 Claude Code 大型代码库配置指南,把 CLAUDE.md、hooks、skills 的层级和分工讲得比社区经验更系统,做工程落地的团队可以当作部署手册。
02:00
Claude:Blog(网页)精选
AI 评分 74/100
创始人手册:构建AI原生初创公司

Anthropic公司发布了一份面向AI原生初创企业的实用指南,旨在重塑2026年创业生命周期的构思、最小可行产品、发布和规模化四个核心阶段。该手册为每个阶段提供了具体目标、退出标准、常见失败模式及AI驱动练习,涵盖如何利用Claude进行问题验证与客户发现、避免AI生成代码的技术债务、区分真实产品市场契合度与早期炒作,并引入智能工作流替代创始人手动操作。指南还整合了多家初创企业的实践案例,为从零开始围绕AI构建公司的创始人提供架构、范围与安全方面的最佳实践。


推荐理由:这份创业手册把从Idea到Scale四阶段拆成了可复制的流程和prompt,不再是玄学方法论,而是创始人可以直接上手操作的“AI创业作弊本”。
00:08
Google Developers Blog(RSS)精选
AI 评分 63/100
加速设备端AI:Arm与Google AI Edge的优化实践

Arm第二代可扩展矩阵扩展(SME2)与Google AI Edge软件栈集成,将CPU转变为强大的矩阵计算加速器,从而实现高性能的设备端生成式AI。本文以Stability AI的“stable-audio-open-small”模型为例,阐述了利用LiteRT、XNNPACK和KleidiAI构建的“转换、优化、部署”自动化硬件加速流程。该方案在基于Arm架构的移动设备和笔记本电脑上,成功实现了音频生成速度提升2倍以上、内存使用减少4倍的显著效果,同时确保了高音频质量。这一集成方案为在资源受限的边缘设备上高效运行复杂AI模型提供了有效路径。


推荐理由:Google 和 Arm 在设备端 AI 上的联合优化案例很具体,给了开发者一套可复制的流程,2x 加速和 4x 内存节省对于做移动端生成式 AI 的人来说值得动手试一下。

5月14日5月14日周四

星期四 · 6 条
22:45
Hugging Face:Blog(RSS)精选
AI 评分 59/100
解锁连续批处理中的异步性

在连续批处理中,同步方式导致CPU与GPU交替工作,造成闲置浪费。测试显示,使用8B模型生成8K令牌时,GPU有24%的时间处于空闲状态。异步批处理通过分离工作负载,让CPU准备下一批次(N+1)的同时,GPU计算当前批次(N),从而消除闲置间隙。这可通过CUDA流实现操作并发,无需更改内核或模型,仅需协调硬件执行顺序。理论上,该方法可将总生成时间从300.6秒减少至228秒,实现24%的免费加速。相关技术已集成到transformers库的连续批处理中,显著提升推理性能。


推荐理由:文章手把手拆解了异步批处理如何用CUDA流和事件消除CPU与GPU的互相等待,把推理吞吐提升22%,搞推理优化的工程师值得细读。
21:29
Hacker News 热门(buzzing.cc 中文翻译)精选
AI 评分 78/100
克劳德代码与《代码书》技能:有针对性的技能培养

开发者发布了一款名为“克劳德代码与《代码书》技能”的GitHub工具,旨在通过刻意练习提升编程技能。该工具利用AI模型生成特定主题的代码示例与解释,帮助用户进行针对性学习。项目在Hacker News上获得104点热度,关注度较高。其核心变化在于将传统的广泛学习转化为聚焦、可重复的技能训练模式,通过结构化练习提升学习效率。


推荐理由:这个skill把Claude Code变成一对一的代码教练,专门抓你代码里的坏习惯,对想用AI真正提升编码水平的人是个好东西。
08:00
PromptArmor:Threat Intelligence精选
AI 评分 67/100
PromptArmor 解析 LLM 沙箱域名白名单的常见外泄风险

PromptArmor 分析 Agent 沙箱域名白名单的配置与风险,指出 npmjs.com、github.com、docs.google.com 和 *.amazonaws.com 等常用白名单域名都可能被提示注入用作数据外泄通道,例如通过 Google Forms 预填提交链接或攻击者注册的匹配通配符的子域名。


推荐理由:原文列举常见白名单域名的具体外泄路径并给出收紧评估原则,可迁移到自家 Agent 沙箱的网络配置。
07:51
ginobefun@hongming731精选
AI 评分 77/100
BestBlogs早报:AI智能体工程化实战与安全架构http://x.com/i/article/2054698692955996160BestBlogs 05.14 早报 · Claude Computer Use 最佳实践、Codex 沙箱安全与生产级 Agent 评估框架在线阅读和收听早报:https://www.bestblogs.dev/explore/brief/2026-05-14BestBlogs Pro 早鸟内测开放:你可以自定义订阅源、配置兴趣标签,每天获得一份属于自己的头条早报。欢迎抢先体验,并把反馈发回给我们:https://bestblogs.dev导语AI 智能体的工程化落地,今天这期带来三篇拿来就能用的深度实战。Anthropic 和 OpenAI 分别给出了 Claude Computer Use 与 Codex 沙箱的第一手架构经验,直接回答生产环境最棘手的安全与性能问题。评估体系那篇则揭示了一个让人警醒的现实:基准测试 95% 准确率的 RAG Agent,上线后幻觉率可能高达 30%——测试集永远无法覆盖生产流量的真实分布。速览部分有李想与罗永浩的 AI 转型深度对话、Shopify 从零构建多 Agent 系统的工程教训、Databricks 用精度换延迟的速率限制重构,以及快手电商搜索的生成式新框架。今天是 2026 年 5 月 14 日,星期四,欢迎收听 BestBlogs EP56 早报。精讲一:使用 Claude 进行计算机和浏览器操作的最佳实践来源:Claude Blog如果你正在构建任何形式的桌面或浏览器自动化 Agent,这篇来自 Anthropic 的官方最佳实践指南是目前最权威的参考文档。它针对 Claude 4.6 系列(Opus 4.6、Sonnet 4.6、Haiku 4.5)和 Claude Opus 4.7 发布,覆盖了从分辨率配置、安全架构到场景取舍的完整生产经验。点击不准的根本原因:坐标系偏移许多开发者在构建 Computer Use 集成时遭遇点击落点系统性偏移,往往以为是模型能力问题,反复尝试提示工程优化却收效甚微。实际上,根本原因更底层、更隐蔽:截图超过 API 内部尺寸上限后会被静默下采样,但坐标系仍然按你指定的原始分辨率空间返回,导致模型点的地方和你的界面坐标对不上。Claude 4.6 系列的 API 内部处理限制是:最长边不超过 1568 像素,总像素不超过 1.15 兆像素。Opus 4.7 支持更高分辨率:最长边不超过 2576 像素,总像素不超过 3.75 兆像素。超出任意一个限制都会触发内部下采样,进而引发坐标偏移。官方明确指出,这个单一修复的收益超过几乎所有其他优化手段。推荐分辨率策略对大多数场景,推荐从 1280×720 起步。这个分辨率使用约 80% 的像素预算,始终在两个限制之内,是模型训练期间见过的标准分辨率,对现代 Web UI 和传统桌面应用都能良好支持。如果使用 Opus 4.7,建议从 1080p 起步,相比 720p 有明显的画质提升,同时保持 token 使用量和性能的合理平衡。对于想最大化视觉信息量的开发者,文章还提供了「最大 API 适配」方案:按每张截图的原始宽高比动态计算最优分辨率,充分利用可用像素预算而不引入宽高比失真。这种方式在准确率上比固定 1280×720 略有提升,但实现稍复杂。文章也给出了明确的「应当避免的分辨率」指导,帮助开发者排除高分辨率下的常见误区。模型思考能力与任务复杂度文章在内部测试了不同思考努力等级在端到端 UI 自动化任务上的表现,覆盖桌面应用、浏览器和跨应用工作流。测试结果印证了两个关键模式:Opus 4.7 在 OSWorld Verified 基准上表现优于整个 4.6 系列,高思考等级在复杂多步骤任务中的收益最为显著,而简单重复性任务则不一定需要开启高思考。这为开发者在成本和性能之间的取舍提供了实验依据。安全架构:不容妥协的底线文章在安全架构上的态度非常明确,提出了几条硬性原则:任何 Computer Use 集成都必须在专用虚拟机或完全隔离的容器环境中运行,绝不能将包含敏感凭证、个人数据或业务数据的主机文件系统暴露在 Agent 可访问的范围内。Agent 循环中必须设置人工确认门控,对高风险操作——包括表单提交、文件删除、账号操作、支付相关流程——必须暂停等待人工确认,而不是让 Agent 自主完成。这些原则背后的逻辑是:Computer Use Agent 本质上是在执行任意操作序列,攻击面远大于普通的 API 调用型 Agent。任何一次误操作都可能造成不可逆后果。Browser Use 与 Computer Use 的场景取舍文章对这两种模式提供了清晰的场景划分:Browser Use(通过 Playwright 等浏览器自动化 API 控制浏览器)适合结构化 Web 任务,API 层面的操作精度高、可靠性强、可重复;Computer Use(通过截图 + 点击控制整个屏幕)适合无 API 可用的桌面应用、遗留系统或需要跨多个应用的工作流。两者并不互斥,复杂任务可以组合使用——先用 Browser Use 完成可 API 化的部分,遇到需要截图感知的场景再切换到 Computer Use。与今日其他内容的关联这篇文章和精讲三的 Agent 评估框架有直接呼应。Computer Use 集成的准确率指标——点击精度、任务完成率、工具选择准确率——正是精讲三 12 项指标体系中「Agent 行为层」的典型评测对象。如果你在构建桌面自动化 Agent,建议两篇配合阅读:前者告诉你如何让 Agent 执行正确,后者告诉你如何度量 Agent 是否在正确执行。精讲二:在 Windows 上为 Codex 构建安全有效的沙箱来源:OpenAI Blog这篇文章来自一位 2025 年 9 月加入 Codex 工程团队的工程师,记录了他们如何在 Windows 平台上从零构建沙箱隔离方案的完整历程。文章的价值不只在于结论,更在于对失败方案的诚实记录——这些踩坑经验对所有需要在 Windows 上运行不完全受信代码的 Agent 系统都有直接参考价值。背景:Windows 没有开箱即用的沙箱原语在 Linux 上,seccomp 和 bubblewrap 提供了细粒度的系统调用过滤和命名空间隔离;在 macOS 上,Seatbelt(又名 sandbox-exec)可以通过 profile 文件精确控制进程的文件访问权限。这些工具让构建可靠的隔离环境变得相对直接。Windows 没有类似的内置能力。Codex 在 Windows 上的默认模式是以真实用户权限运行,也就是说,如果用户能做某件事,Codex 就能做某件事——包括删除任意文件、修改系统配置、访问所有用户数据。在没有沙箱的情况下,用户只有两个糟糕的选择:批准几乎每一条命令(高频中断,失去自动化价值),或者开启完全访问模式(放弃监督)。逐一评估现有方案及其不足工程师先系统评估了 Windows 提供的现有工具:AppContainer 是 Windows 内置的应用沙箱机制,但其权限模型是为 Store 应用设计的,粒度过于粗放——要么完全隔离,要么保留所有用户权限,无法实现「允许读取任意位置、但只允许向指定目录写入」这种精细控制。Windows Sandbox 本质上是一个轻量虚拟机,Home 版 Windows 不可用,并且每次启动都需要独立的虚拟机实例,资源消耗和启动时间都不适合作为每条命令的执行环境。MIC(Mandatory Integrity Control)完整性标签 可以降低进程的信任级别,但调整整个工作区的完整性标签会改变所有访问该目录的进程的行为,对用户的正常工作流产生不可预期的副作用,风险难以控制。最终方案:专属 SID + 写受限令牌Codex 团队最终选择了自研方案,核心机制是两个 Windows 安全原语的组合:第一步,为 Codex 创建一个专属的 Windows 用户账户,配套一个专属的安全标识符(SID)。这个 SID 不是系统中的任何现有用户,仅属于 Codex 沙箱进程。第二步,使用 写受限令牌(write-restricted token)。Windows 的受限令牌机制在检查写操作权限时会执行双重校验:普通用户身份(令牌的所有者)必须有权限,且受限 SID 列表中至少有一个 SID 也被明确授权,写操作才会被允许。通过对指定工作区目录设置 ACL(访问控制列表),授予 Codex 专属 SID 写入权限,对其他目录不授予,就实现了精确的文件系统隔离:Codex 可以读取几乎任意位置(维持工具的有效性),但只能向你的工作区目录写入。这整套机制在操作系统层面强制执行,无需进程树中的任何软件层面配合,也无需管理员权限。迭代路径:从 advisory 到 enforce文章诚实地记录了中间的失败尝试。早期版本曾尝试通过设置环境变量(NO_PROXY、GIT_SSH_COMMAND)来阻止网络访问,但进程可以直接忽略环境变量、绕过 PATH、或者直接打开套接字,advisory 约束无法真正阻止恶意行为。加入防火墙规则之后仍然是 advisory 级别。最终决定使用操作系统层面的强制隔离,这才提供了真正可靠的保证。工程范式的通用性这个「专属 SID + 写受限令牌 + ACL 白名单」的设计模式,对所有需要在 Windows 上运行不完全受信代码的系统都有参考价值:AI 编程工具、自动化测试框架、RPA 产品,乃至任何需要给用户提供「让 AI 帮你跑命令」能力的服务。文章清晰呈现了从需求分析、方案评估到工程实现的完整思路,是难得的 Windows 系统安全工程案例。精讲三:为生产级 AI 智能体构建评估框架:来自 100+ 次部署的 12 项指标体系来源:Towards Data Science这篇文章来自真实的生产教训,而不是理论框架。作者团队在为医疗行业客户部署 AI Agent 系统三个月后,被合规官问了一个无法回答的问题:「你如何知道你的 Agent 没有在幻觉患者症状?」当时他们有单元测试、集成测试、在 demo 数据集上表现漂亮的模型,但没有任何能够在生产环境度量幻觉率、上下文忠实度或工具选择准确率的框架。这个缺口差点让整个项目夭折。六周后,他们补上了覆盖每条 Agent 响应、每次工具调用、每次检索操作的 12 项指标框架,合规团队签字通过,Agent 正式上线。此后经历 100+ 次企业级 Agent 部署,这套框架演变成了他们的标准交付物。最值得警惕的数据点在基准测试集上准确率达到 95% 的 RAG Agent,在真实生产流量上幻觉率可能高达 30%。这个数字让很多人难以置信,但背后的逻辑简单而扎实:测试集是你精心构建的,覆盖了你认为重要的场景;而生产流量是用户真实发来的,措辞更多样、边界案例更密集、上下文更复杂。你的测试集永远无法覆盖生产流量的真实分布。没有生产级的评估框架,你只是在用基准分数给自己一个安全感幻觉。12 项指标的四层结构这 12 个指标按四个层次组织,每层各有侧重:检索层(Retrieval):上下文相关性,目标阈值 >0.85,衡量检索到的块是否与查询真正相关;召回率,>0.90,衡量是否把所有相关信息都检索到;精确率,>0.80,衡量排名靠前的块是否是最相关的;检索延迟,P95 <200ms,衡量检索速度是否影响整体体验。生成层(Generation):回答忠实度,>0.95,衡量模型的回答是否与检索到的上下文一致,这是防幻觉的核心指标;回答相关性,>0.90,衡量回答是否真正回应了用户的问题;幻觉率,<2%,衡量模型杜撰事实的频率。Agent 行为层(Agent Behavior):工具选择准确率,>0.92,衡量 Agent 是否在正确的场景调用了正确的工具;工具执行成功率,>0.98,衡量工具调用本身是否成功(区别于逻辑正确性);多步骤连贯性,>0.85,衡量 Agent 在长任务中是否保持了逻辑一致性。生产层(Production):单次查询成本,典型值 <$0.05,用于成本控制和单位经济核算;P99 延迟,<3s,衡量最差情况下的响应速度是否在用户可接受范围内。跳过任何一层都意味着盲区。跳过检索层指标,你不知道是不是因为召回率低导致回答质量差;跳过生成层指标,你不知道模型在什么场景下开始编造事实;跳过 Agent 行为层,你不知道 Agent 选错工具是不是系统性问题;跳过生产层,你不知道成本和延迟是否在可接受范围内。三种典型的错误模式模式一:「MVP 之后再补评估」。这是最常见也是代价最高的模式。等 MVP 上线之后,工程团队已经有了 UI、API、集成和用户,这时候再补评估基础设施通常需要 4-6 周。更麻烦的是,数据收集本身有延迟——你必须先有一定量的生产流量,才能开始建立基线、检测回归。这段空窗期里,用户已经在发送不可预期的查询,任何模型更新引发的回归可能要数天后才能被发现,信任损失往往已经无法挽回。模式二:「准确率就够了」。测试集准确率是必要条件,但绝不是充分条件。一个 RAG Agent 可以在你的评估集上拿到 95% 的准确率,同时在生产流量上有 30% 的幻觉率——因为评估集是你选的、生产流量是用户给的,两者分布不同。没有忠实度、幻觉率和工具选择指标,你只是在盲飞。模式三:「人工抽检就行」。每天 100 条查询时人工检查可行,这个方法在 10000 条时就会彻底崩溃。达到那个规模后,要么工程师因为重复审查而过劳,要么实际上已经在接受一个名存实亡的审查体系。自动化评估在超过每日几千条查询时就应该是标配,而不是可选项。实践建议:从第一天就构建文章最核心的行动建议是:在 MVP 上线之前就把评估框架搭好。这意味着在架构阶段就为每层指标的数据采集做好预留,而不是在系统上线后再反向插入。这和「测试先于代码」的 TDD 理念类似——先定义什么叫「正确」,再去实现。如果已经在生产但没有评估框架,文章建议优先从幻觉率和工具选择准确率开始,这两个指标覆盖了最高频的故障模式,也最容易用自动化方式度量。与今日主题的关联这套框架和今天两篇精讲之间的关联非常紧密。精讲一 Computer Use 的点击准确率对应工具执行成功率,多步骤 UI 自动化对应多步骤连贯性;精讲二 Codex 沙箱的隔离机制直接影响工具执行成功率(沙箱失效 = 工具崩溃)。任何生产级 Agent 系统都需要同时具备「执行能力」和「评估能力」,两者缺一不可。速览李想×罗永浩:通过 AI 技术,让普通人也过上富豪的生活 | 罗永浩的十字路口理想汽车创始人李想在这期长达两小时的播客中,深入阐述了公司从传统车企向 AI 与具身智能公司转型的战略逻辑。新旗舰 SUV L9 Livis 搭载了自研马赫 M100 芯片,算力达到 2560 TOPS,以及全球首个完全体全线控底盘和 800V 主动式悬架系统。李想的核心判断是:自动驾驶不会显著影响购车需求,人形机器人是继汽车之后规模最大的硬件赛道,而 AI 技术的终极价值在于让普通人享受到此前只有富豪才能获得的服务质量——从专属管家到全天候健康顾问。播客还涉及 AI 时代顶级人才的标准、激进的组织调整、以及新能源车企出海的路径。对汽车行业 AI 转型方向感兴趣的读者,这是近期最有深度的一手资料。从头构建多智能体系统学到的经验 | InfoQShopify 高级工程师 Paulo Arruda 分享了从零构建多 Agent 系统的完整历程。核心结论是:专注于特定领域的 Agent 远比通才型 Agent 更有效,为领域专家提供更好的工具比组建 AI 特种部队更实用。这个洞察和当下很多团队盲目追求「万能 Agent」的做法形成直接对比。文章以 Shopify 的 Hacker Culture 为背景,记录了从最初 LibreChat 内部工具到真正可用的多 Agent 系统的演进路径,是一份有现实温度的工程经验总结。Databricks 的高性能速率限制:以精度换延迟 | ByteByteGo Newsletter2023 年初,Databricks 的速率限制器基于 Envoy + Ratelimit Service + 单 Redis 实例架构,在 real-time model serving 上线后开始出现尾部延迟飙升、扩容失效、单点故障三个问题。重设计后,团队将计数器从 Redis 迁移到分片内存存储,并引入异步批量上报模式,将尾部延迟降低了十倍。代价是容忍约 5% 的精度超限——部分请求可能在配额刚好耗尽的瞬间被错误放行。这个取舍本身很有代表性:在高并发场景下,严格精度和低延迟往往不可兼得,选择哪个取决于业务场景的容忍度。文章配有架构演进图,适合分布式系统工程师收藏参考。快手 OneSearch-V2:生成式搜索进入「懂你」时代 | 快手技术快手电商搜索团队发布 OneSearch-V2,针对 V1 的三个核心瓶颈——复杂查询理解不足、用户潜在意图推理不足、奖励系统易过拟合——提出了系统性解决方案。关键创新是推理内化的自蒸馏:不引入额外参数,通过信息不对称的自蒸馏机制,将显式推理能力直接编码进模型权重,转化为「直觉」。系统已全量上线,在不增加任何推理成本的前提下,商品点击率提升 3.98%、买家数提升 2.07%、订单量提升 2.11%。搜索和推荐工程师值得深读论文部分,代码已开源。让 AI Agent 感知浏览器渲染:为 Agent 构建前端验收 Harness | 百度 Geek 说百度工程团队开发了基于 Chrome DevTools Protocol 的开源工具,让 Agent 能从路径、内容、视觉、交互、控制台、网络六个维度验证真实浏览器渲染结果,补上 AI 编程流水线「写完代码看不到效果」的盲点。核心洞察是:代码正确不等于界面正确——CSS cascade、运行时数据、异步状态共同决定了最终渲染,这些问题只有在浏览器里才能暴露。工具已开源,可通过 npx skills add hixuanxuan/browser-automation --skill visual-verify 安装,前端 AI 自动化团队可以直接参考。Claude 付费计划将包含程序化调用月度专用额度 | ClaudeDevs从 6 月 15 日起,付费版 Claude 计划将包含一个月度专用额度,覆盖通过 Agent SDK、claude -p 命令行工具、Claude Code GitHub Actions 以及基于 Agent SDK 构建的第三方应用的程序化调用。这实际上将程序化访问权限捆绑到了订阅模式中,开发者无需单独为 API 付费即可构建和部署自动化工作流。对于之前依赖订阅账号进行轻量级自动化的用户,需要关注额度上限细节。五种多智能体架构类型:注意力才是真正的瓶颈 | 跨国串门儿计划Factory 核心 Agent 框架负责人 Luke Alvoeiro 在 AI Engineer 的分享中,拆解了五种多 Agent 通信模式:委派、创作者 - 验证者、直接通信、协商和广播。他的核心判断是:今天的模型已经足够聪明,真正的工程瓶颈是人类的注意力带宽。Factory 的 Missions 系统通过三角色架构(编排者 - 工作者 - 验证者)和「验证合约」机制,实现了最长 16 天的自主任务执行——在编写任何代码之前先定义好与实现无关的正确性断言,从根本上阻断 Agent 系统跑偏的可能。克隆 Slack 的生产案例中,代码内测试占比 50%,覆盖率超过 90%。扩展阅读积压队列的数学原理:面向队列恢复的容量规划 | InfoQ用三阶段数学框架推导队列积压的形成、持续和恢复过程,将「需要多少超额容量才能在 N 分钟内消化积压」从经验估算变成可计算的工程问题。还分析了重试放大和级联积压两个高危模式。适合基础设施和平台工程师,特别是要做 SLA 容量规划的团队。[AINews] 微调时代的终结 | Latent Space围绕 OpenAI 弃用微调 API 展开的行业分析。核心论点是:对大多数 AI 工程师来说,提示工程、RAG 和专用推理栈已经能覆盖绝大多数需求,微调正在成为少数真正需要定制模型行为的顶尖应用的专属手段。想厘清「我的场景到底需不需要微调」的读者值得一读,文章给出了判断框架。Browser Run:现已运行于 Cloudflare Containers,速度更快、扩展性更强 | The Cloudflare BlogCloudflare 将 Browser Run 服务迁移到 Containers 平台,并发限制提升 4 倍(每分钟可启动 60 个浏览器、最多 120 个并发),Quick Action 响应速度提升超 50%。关键架构改动是将状态管理从 KV 迁移至 D1 和 Queues,文章有详细的性能数据对比。需要在云端运行无头浏览器的团队可以直接参考,改进已经上线,无需更改现有代码。今日阅读路径时间有限的话,建议按以下顺序阅读:第一优先:精讲三(Agent 评估框架)这是今天最有普适价值的一篇。无论你在构建哪种 AI Agent,无论规模大小,在上线之前都需要有回答「你怎么知道它没有幻觉」这个问题的能力。12 项指标、四层结构,结合阈值参考值,是可以直接带回去用的框架。那个「基准 95% 准确率、生产 30% 幻觉率」的案例本身就值得每个 Agent 工程师认真对待。第二优先:精讲一(Claude Computer Use 最佳实践)如果你的 Agent 需要控制桌面或浏览器,这篇的分辨率配置和安全架构部分可以帮你避开 90% 的坑。特别是截图下采样导致坐标偏移这个问题,不读原文很难自己发现,修复也非常简单——在发送截图前主动下采样到 1280×720,这一个改动的收益超过绝大多数其他优化手段。第三优先:速览中的 Shopify 多智能体经验篇幅不长,但提供了一个反直觉的工程结论:专才 Agent 优于通才 Agent,为领域专家提供更好的工具比组建 AI 特种部队更有效。如果你正在做 Agent 系统的架构选型,这篇来自 Shopify 生产环境的结论值得认真对待。精讲二(Codex Windows 沙箱)主要面向平台工程师和需要在 Windows 上部署 Agent 的团队,专业性强。如果你的部署目标平台是 Linux 或 macOS,可以跳过,但如果面向 Windows 用户,这篇是目前最完整的参考案例。BestBlogs早报聚焦AI智能体的工程化落地。Anthropic官方指南详解Claude Computer Use最佳实践,包括解决点击偏移的根本原因、推荐分辨率策略及必须采用虚拟机隔离与人工确认门控的安全原则。OpenAI工程师分享了为Codex构建Windows安全沙箱的历程,其最终方案通过专属安全标识符和写受限令牌,实现了操作系统层面的强制文件系统隔离。早报同时指出,基准测试优异的RAG Agent在生产环境中可能出现高达30%的幻觉率。
推荐理由:三篇来自 Anthropic 和 OpenAI 的生产级 Agent 实践精华,从坐标偏移坑到沙箱自研方案到评估框架,都是工程团队踩坑后的一手经验,做 Agent 落地的可以直接抄作业。
03:29
Claude:Blog(网页)精选
AI 评分 73/100
Claude 电脑与浏览器使用的最佳实践

Claude 最新模型在电脑与浏览器使用能力上显著提升,支持构建复杂智能体系统。本文针对Claude 4.6系列和Opus 4.7提供实践指南,重点优化截图分辨率:Claude 4.6系列API限制最大长边1568像素、总像素115万;Opus 4.7提升至最大长边2576像素、总像素375万。发送前将截图缩放到限制内是提升点击准确性的最有效方法。推荐起始分辨率为1280x720,Opus 4.7用户可优先使用1080p,并避免发送未经缩放的原始截图或过低分辨率图像。


推荐理由:如果你正在让 Claude 操作桌面或浏览器,这篇官方指南把分辨率、token 压缩和缓存策略一次讲透了,附带代码和踩坑表,是那种"读完就能少写一堆 bug"的硬核文档。
02:31
OpenAI:官网动态(RSS · 排除企业/客户案例)精选
AI 评分 62/100
在 Windows 上构建安全有效的沙箱以启用 Codex

OpenAI 为 Windows 平台上的 Codex 构建了一个安全沙箱环境。该沙箱通过严格控制文件访问权限和实施网络限制,确保了代码生成与执行过程的安全性。这一举措使得基于 Codex 的编码助手能够以高效且受控的方式运行,在提供强大编程辅助功能的同时,有效隔离了潜在风险,保障了用户系统的安全。


推荐理由:OpenAI 首度公开 Codex 在 Windows 上的沙箱细节,控制文件访问和网络限制的架构设计讲得很实在,做自主编程代理安全的值得一读。

5月13日5月13日周三

星期三 · 4 条
07:09
OpenAI:官网动态(RSS · 排除企业/客户案例)精选
AI 评分 63/100
财务团队如何使用 Codex

财务团队能够利用 Codex,基于实际工作输入构建管理层报告、报告包、差异桥接、模型检查和规划场景。该工具将自然语言指令转化为代码,自动化处理财务数据整合、差异分析和模型验证等复杂任务,从而提升报告生成效率与准确性,并支持快速创建多版本规划场景。


推荐理由:金融团队终于有了一个正经的 AI 用例,用 Codex 自动生成 MBR、差异桥接和规划场景,比手工拉 Excel 高效太多了,做财务分析的建议点开看看。
02:54
Claude:Blog(网页)精选
AI 评分 58/100
Anthropic 网络安全团队如何利用 Claude Code 构建威胁检测平台

Anthropic 检测平台工程团队技术负责人 Jackie Bow 运用 Claude Code 开发了 CLUE 威胁检测与响应平台。该平台通过自然语言界面连接内部系统,包含 CLUE Triage 自动初筛警报,整合上下文信息分配处置建议;以及 CLUE Investigate 支持分析师用自然语言查询日志,由 Claude 自动生成并执行查询,将数小时的人工分析缩短至几分钟。团队在一天内完成概念验证,一周内交付实现,显著提升了安全运营效率。


推荐理由:我一直好奇大模型公司自己怎么用 AI 做安全,这篇挖出了 Anthropic 内部 CLUE 平台的构建细节——从一天出原型到每周省下 234 人天,数据比很多 PR 稿扎实。
01:05
Google Developers Blog(RSS)精选
AI 评分 73/100
使用ADK构建可暂停、恢复且永不丢失上下文的长时运行AI智能体

本文探讨了如何从无状态聊天机器人升级为生产级AI智能体,以管理长达数天或数周的企业工作流程(如HR入职)。通过引入Agent Development Kit(ADK),其架构核心采用持久状态机和持久化会话存储,确保智能体在“空闲时间”或服务器重启时永不丢失上下文。系统利用事件驱动的Webhook和多智能体委托机制,实现在暂停期间“休眠”,并在唤醒后以高推理准确性恢复复杂任务,从而构建出具备韧性和可靠性的长时运行智能体系统。


推荐理由:Google 官方手把手教你把无状态 chatbot 升级成能跨天跨周的持久化 agent,状态机和持久会话是两个关键切入点,做过生产环境 agent 的都懂这东西有多刚需。

5月12日5月12日周二

星期二 · 3 条
23:53
GitHub Blog精选
AI 评分 58/100
Dungeons & Desktops: 使用 GitHub Copilot CLI 构建一款程序化生成的 Roguelike 游戏

一位 GitHub 员工利用 GitHub Copilot CLI 开发了一款扩展程序,能够将任何代码库转换成一个独特的 Roguelike 风格地下城。该工具通过 AI 辅助的代码生成,实现了程序化关卡创建,展示了 Copilot CLI 在创意编码和游戏原型开发中的实际应用潜力。项目核心是自动解析代码结构并生成对应的可探索地下城布局。


推荐理由:用 GitHub Copilot CLI 把代码库变成 roguelike 地牢,玩法挺有脑洞,做 Copilot 扩展的开发者可以看一眼思路。
07:43
Hugging Face:Blog(RSS)精选
AI 评分 58/100
在AWS上进行基础模型训练与推理的核心构建模块

本文面向使用开源框架的机器学习工程师,阐述了AWS如何为大规模基础模型的全生命周期提供核心基础设施。其核心是三大紧密集成的组件:配备多代NVIDIA GPU(如H100、H200及新一代Blackwell B200/B300)的大显存加速计算实例;用于集体通信的高带宽、低延迟网络(节点内NVLink与节点间EFA);以及可扩展的分布式存储。这些基础设施与Slurm/Kubernetes等资源编排系统、PyTorch/JAX等ML框架协同,共同支撑预训练、后训练和推理工作负载,并可通过Prometheus/Grafana实现全栈可观测性。


推荐理由:这篇把AWS上训大模型的全套基础设施串了一遍,从GPU选型到网络存储再到Slurm/K8s编排,是做云端大规模训练的工程师的必读参考。
03:52
Simon Willison 博客精选
AI 评分 80/100
在脚本的shebang行中使用LLM

本文介绍了一种创新方法,将LLM工具直接嵌入脚本的shebang行中执行指令。通过LLM的fragments模式,shebang行可执行简单任务,如生成SVG图像;使用-T选项能调用外部工具(如llm_time)创作包含当前时间的俳句;更复杂的是运行YAML模板,其中定义了Python函数作为工具进行数学计算,示例中演示了计算2344乘以5252加134的过程,并通过调试输出展示了分步结果,最终得到12,310,822。这展现了LLM作为脚本解释器的强大扩展性,能够支持从内容生成到数据查询的多样化任务。


推荐理由:Simon 这个 shebang 技巧让 LLM 直接变成脚本解释器,虽然是极客玩法,但对常写自动化脚本的开发者来说可以直接抄走,创意很妙。

5月11日5月11日周一

星期一 · 1 条
08:00
Together AI 研究与产品博客(RSS)精选
AI 评分 68/100
Together AI 解析 DeepSeek-V4:百万 token 上下文为何是推理系统工程问题

Together AI 发布文章解析 DeepSeek-V4 服务方案,认为其关键变化是架构层面将 1M token 上下文压缩问题转化为推理系统工程问题。


推荐理由:Together 基于自家 B200 布署经验,把 DeepSeek-V4 百万 token 上下文拆解为缓存管理与调度策略问题,给出了可迁移的评测与调优思路。