返回
原文
ginobefun@hongming731
精选
77AI 编辑部评分，满分 100

BestBlogs早报：AI智能体工程化实战与安全架构

2026-05-14 07:15· 90天前
AI 导读

BestBlogs早报聚焦AI智能体的工程化落地。Anthropic官方指南详解Claude Computer Use最佳实践，包括解决点击偏移的根本原因、推荐分辨率策略及必须采用虚拟机隔离与人工确认门控的安全原则。OpenAI工程师分享了为Codex构建Windows安全沙箱的历程，其最终方案通过专属安全标识符和写受限令牌，实现了操作系统层面的强制文件系统隔离。早报同时指出，基准测试优异的RAG Agent在生产环境中可能出现高达30%的幻觉率。

推荐理由

三篇来自 Anthropic 和 OpenAI 的生产级 Agent 实践精华，从坐标偏移坑到沙箱自研方案到评估框架，都是工程团队踩坑后的一手经验，做 Agent 落地的可以直接抄作业。

http://x.com/i/article/2054698692955996160

BestBlogs 05.14 早报 · Claude Computer Use 最佳实践、Codex 沙箱安全与生产级 Agent 评估框架

在线阅读和收听早报:https://www.bestblogs.dev/explore/brief/2026-05-14

BestBlogs 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 转型方向感兴趣的读者,这是近期最有深度的一手资料。

从头构建多智能体系统学到的经验 | InfoQ

Shopify 高级工程师 Paulo Arruda 分享了从零构建多 Agent 系统的完整历程。核心结论是:专注于特定领域的 Agent 远比通才型 Agent 更有效,为领域专家提供更好的工具比组建 AI 特种部队更实用。这个洞察和当下很多团队盲目追求「万能 Agent」的做法形成直接对比。文章以 Shopify 的 Hacker Culture 为背景,记录了从最初 LibreChat 内部工具到真正可用的多 Agent 系统的演进路径,是一份有现实温度的工程经验总结。

Databricks 的高性能速率限制:以精度换延迟 | ByteByteGo Newsletter

2023 年初,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 Blog

Cloudflare 将 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 用户,这篇是目前最完整的参考案例。

智能体AnthropicOpenAI安全/对齐

来源：ginobefun · x.com

导出 Markdown
返回
精选AI 评分 77/100在 X 查看原推
导出 Markdown

BestBlogs早报：AI智能体工程化实战与安全架构

ginobefun · @hongming731 · X·2026-05-14 07:15·90天前
AI 导读

BestBlogs早报聚焦AI智能体的工程化落地。Anthropic官方指南详解Claude Computer Use最佳实践，包括解决点击偏移的根本原因、推荐分辨率策略及必须采用虚拟机隔离与人工确认门控的安全原则。OpenAI工程师分享了为Codex构建Windows安全沙箱的历程，其最终方案通过专属安全标识符和写受限令牌，实现了操作系统层面的强制文件系统隔离。早报同时指出，基准测试优异的RAG Agent在生产环境中可能出现高达30%的幻觉率。

http://x.com/i/article/2054698692955996160

BestBlogs 05.14 早报 · Claude Computer Use 最佳实践、Codex 沙箱安全与生产级 Agent 评估框架

在线阅读和收听早报:https://www.bestblogs.dev/explore/brief/2026-05-14

BestBlogs 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 转型方向感兴趣的读者,这是近期最有深度的一手资料。

从头构建多智能体系统学到的经验 | InfoQ

Shopify 高级工程师 Paulo Arruda 分享了从零构建多 Agent 系统的完整历程。核心结论是:专注于特定领域的 Agent 远比通才型 Agent 更有效,为领域专家提供更好的工具比组建 AI 特种部队更实用。这个洞察和当下很多团队盲目追求「万能 Agent」的做法形成直接对比。文章以 Shopify 的 Hacker Culture 为背景,记录了从最初 LibreChat 内部工具到真正可用的多 Agent 系统的演进路径,是一份有现实温度的工程经验总结。

Databricks 的高性能速率限制:以精度换延迟 | ByteByteGo Newsletter

2023 年初,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 Blog

Cloudflare 将 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 用户,这篇是目前最完整的参考案例。

来源：ginobefun· x.com