ginobefun@hongming731
46AI 编辑部评分,满分 100

BestBlogs 周刊:智能执行层全景解析

2026-08-16 21:50· 29分钟前
AI 导读

BestBlogs 第108期周刊聚焦AI智能体执行层,Grok 4.6、DeepSeek V4 Pro、Gemini 3.7 Flash均优化长程Agent能力。DeepSeek开源插件化Harness v0.1,OpenAI公开Codex Harness机制。周刊从执行模型、Harness、评测、多智能体、路由缓存等六条主线,剖析模型如何稳定完成任务。

https://x.com/i/article/2088984377762193408

BestBlogs 精选周刊第 108 期:智能的执行层

🎧 本期也有播客版本:BestBlogs 周刊第 108 期 · 时长 21:04 · 在小宇宙搜索「BestBlogs 周刊」即可收听。

在线阅读和收听:https://www.bestblogs.dev/newsletter/issue108

导语:智能怎样穿过环境,稳定完成任务

模型已经能够读代码、调用工具、操作文件、进入 Slack,也能在沙箱中持续工作数小时。现在更难的问题,是它怎样穿过真实环境,把一个目标稳定地变成结果。

一次 Agent 任务会经历多轮推理。系统要选择工具、维护状态、处理失败、控制权限,还要判断环境里的结果是否真的满足目标。任何一环不可靠,榜单上的模型能力都很难完整抵达用户。

过去几期,我们讨论了判断力、验证边界、「1% 法则」和个人 AGI。第 108 期进入更具体的工程现场。Grok、DeepSeek 和 Gemini 同时更新长程 Agent 能力;DeepSeek 开源插件化 Harness;OpenAI 公开 Codex Harness 的运行机制;阿里和美团把评测、轨迹与回滚做成持续流程;OpenRouter、缓存、Daybreak 和多智能体研究,则把成本、授权与协调放到同一张图里。

本期沿六条主线展开:执行模型、Harness、质量与评测、多智能体与权限、路由与缓存,以及执行层进入公共基础设施、物理世界和科学研究之后的新边界。

一、模型开始为长程执行优化

Grok 4.6、DeepSeek V4 Pro 和 Gemini 3.7 Flash 的发布有一个共同特点:模型能力、接口、思考预算、价格和任务调度开始被放在一起描述。

Cursor 与 SpaceXAI 发布 Grok 4.6 时,把长时间 Agent、代码库协作、知识工作和交互式应用放在核心位置。官方称,它在由 9 项基准构成的 Artificial Analysis Intelligence Index 上与 GPT-5.6 Sol 持平。发布中更值得留意的是行为描述:模型在较长任务里会主动测试和验证自己的工作。

这类「自测」行为为什么重要?代码 Agent 在长任务中经常遇到一种局部最优:某个文件已经改完,单个测试也通过,但完整构建、交互流程或相邻模块仍然失败。模型如果只把生成代码视为终点,就会过早宣布完成;如果它会继续运行测试、检查界面或回看任务要求,Harness 才有机会把环境反馈送回下一轮。Grok 4.6 的发布信号,正是把验证行为纳入模型能力描述。

Cursor 的场景也说明,长程执行并不等于让模型在后台待得更久。代码库搜索、文件编辑、终端命令、浏览器检查和人工反馈会交替出现,任何一次工具调用都可能改变后续上下文。模型需要在多步行动里保存目标,同时识别哪些结果已经被环境证实,哪些仍然只是推断。

单轮问答可以比较一次输出。长程任务还要看模型能否持续维护目标,是否会根据工具反馈修正计划,遇到失败能否恢复,最终是否拿到环境里的真实结果。官方 benchmark 能说明指定配置下的能力,却不能替代真实代码库、多轮反馈和长会话回归。

因此,团队复测 Grok 4.6 时,至少应记录任务完成率、平均工具调用轮数、失败后恢复率、人工介入次数和总成本。这里的重点并非建立一张更复杂的排行榜,而是确认官方描述中的长轨迹优势,能否在自己的仓库、权限和测试环境中稳定出现。

→ 阅读原文:Grok 4.6 发布 · Cursor

DeepSeek V4 Pro 把系统性写得更直接。正式版增强生产环境里的 Agent 表现,原生支持 OpenAI Responses API 与 Codex。V4-Pro 和 V4-Flash 提供 low、high、max 三档思考强度。8 月 17 日起,闲时 API 价格是高峰的一半。

Responses API 与 Codex 兼容降低了接入成本。已有工具如果围绕这一接口组织消息、工具调用与状态,就可以更快替换模型或做对照实验。不过,接口兼容只解决调用形式,无法保证工具选择、上下文压缩和错误恢复完全一致。团队仍需要把每种模型放进相同任务与 Harness 中验证。

三档思考强度则把推理预算变成任务级策略。需求澄清、简单分类和确定性修改可以使用较低档位;跨模块重构、复杂调试和高风险判断再提高预算。如果所有步骤都使用 max,系统会把大量成本花在边界明确的环节;如果全部使用 low,失败重试与人工接管又可能抵消节省。

这让推理预算和任务调度成为可以编排的变量。复杂步骤使用较高思考档位,边界明确的工作使用较低档位,批处理放到闲时执行。DeepSeek 同时注明,公开 Code Agent 结果运行在自家 Harness 极简模式,并采用指定采样参数。模型、Harness、工具、超时和上下文管理共同构成测试条件;换一套执行环境,结果可能变化。

峰谷定价把时间也纳入调度策略。离线评测、代码索引、批量迁移和低优先级修复可以排到闲时;需要同步协作的交互任务则继续使用高峰资源。把这一点与后文的缓存、路由结合起来看,执行层已经开始像传统计算平台一样管理队列、服务等级和单位任务成本。

→ 阅读原文:DeepSeek-V4-Pro 正式版上线

Gemini 3.7 Flash 展示的是高频执行路线。Google 公布的数据中,FrontierCode 1.1 Main 从 34.4% 提高到 43.6%,DeepSWE v1.1 从 49.0% 提高到 65.3%。首发输入价格是每百万 Token 0.75 美元,输出是 3.75 美元。它进入 Gemini Spark 和企业 Agent 平台,并更新 CBRN 与网络攻击相关防护。

Flash 模型的价值来自循环中的复利。Agent 可能连续读仓库、搜索历史、修改文件、运行测试,再依据失败继续修正。每轮多一秒、每次多传一段重复上下文,都会在完整任务中累计。OpenAI 最近公开 GPT-5.6 的效率设计时也提到,Harness 会反复发送指令、历史、工具定义和早期结果,因此采用 append-only 历史来保持稳定前缀和缓存复用。

→ 阅读原文:推出 Gemini 3.7 Flash

模型评估因而需要一张更完整的成绩单:能力决定任务上限,接口决定能否进入工具链,思考档位决定预算分配,延迟和价格决定循环次数,安全策略决定开放范围。对真实团队而言,完整任务成功率、总时延、总成本和失败恢复,比单独一列 benchmark 更接近生产表现。

这与 8 月 13 日、14 日早报的连续信号一致。Grok 4.6、GPT-5.6 Sol、DeepSeek 与 Gemini 的发布密集出现,生产可靠性、Harness 效率和价格调度也同时成为焦点。团队无法为每次发布重新发明一套评估方法,更可持续的做法是固定真实任务、预算与回归环境,再区分模型升级、Harness 改动和价格变化各自带来的影响。

二、Harness 把能力组织成持续工作的系统

模型提出下一步行动,Harness 负责让行动发生,并把结果送回下一轮。

DeepSeek Harness v0.1 把模型、工具、Skill、会话、沙箱、存储、循环、调度和 UI 表达成插件。标准、程序化工具调用、极简和创造模式可以重新组合。append-only 会话日志让上下文注入、工具调用、子 Agent 调度、恢复和回放落在同一条事件流中。

「一切皆插件」解决的是执行系统里变化频率不一致的问题。模型会更换,工具协议会演进,沙箱和存储有不同部署要求,调度策略也会随任务规模变化。如果这些能力被写死在一个循环里,任何局部升级都会牵动整个系统;插件边界让团队可以替换模型、沙箱或存储,同时保留同一条会话和观测链。

这套框架还提供标准、程序化工具调用、极简与创造等模式,反映了 Agent 任务并没有统一的最佳循环。严格工具任务需要明确结构和参数约束,探索性任务需要更大的生成空间,benchmark 复测又希望减少额外组件。模式的意义在于显式表达这些取舍,避免一套配置覆盖所有任务。

长任务中途失败以后,系统需要知道哪一步成功、哪一步产生外部副作用、当前状态能否恢复,以及重试会不会重复执行。状态可以回放,异步任务和并发 Agent 才有可靠管理的基础。DeepSeek Harness 仍是开发者预览版,接口和核心插件会快速变化,适合研究架构与参与生态,暂时不构成生产稳定性承诺。

append-only 日志也是评测与审计的共同底座。工具调用、观察结果和调度事件留在一条时间线上,评测器才能判断失败发生在模型决策、工具返回、权限策略还是恢复逻辑。后文阿里与美团的轨迹评测,依赖的正是这种过程可见性。没有稳定事件记录,团队只能从最后回复反推原因。

→ 阅读原文:DeepSeek Harness 开发者预览版:一切皆插件

Dominik Kundel 对 Codex Harness 的拆解补上了另一组细节。App Server 在用户界面与 Codex Core 之间维护线程和事件,Responses API 连接模型与工具,deferred tools 在需要时进入上下文,异步子 Agent 处理可并行工作,沙箱隔离文件和命令,compaction 让长会话保留可继续执行的上下文,独立只读审查 Agent 则检查授权与风险。

App Server 处理的是长任务的产品生命周期。用户可能关闭客户端、换一台设备、从旧线程继续,也可能在 Agent 等待审批时离开。服务端需要持久化线程和事件,再把底层运行状态翻译成稳定的客户端通知。这样,CLI、编辑器和桌面应用可以共享同一套 Agent 核心,而不必各自重写执行循环。

deferred tools 与 compaction 分别控制工具和历史占用。工具描述如果每轮全部进入上下文,会持续消耗输入 Token;历史如果无限增长,又会挤压当前任务信息。延迟加载只在需要时暴露工具,压缩则保留目标、关键决定和未完成状态。二者共同处理长程 Agent 最常见的上下文膨胀。

OpenAI 官方资料进一步列出线程持久化、配置、认证、审批和双向事件。客户端除了发送请求,还要在 Agent 需要授权时接收审批请求,暂停任务,等用户选择后继续。Harness 已经覆盖状态、策略、执行、恢复和人机协作,远比模型外的一层提示词更完整。

异步子 Agent 又引入文件隔离、完成通知和结果合并。一个主任务可以同时派出代码调研、测试分析或独立审查,但子任务不能随意覆盖同一工作区,也不能把「仍在运行」误判为失败。Codex 的独立只读审查体现了一种可复用分工:执行者负责产生变更,审查者在更窄权限下评估风险,两者通过可见证据汇合。

OpenAI 的 Harness engineering 复盘还记录了一项重要变化:当代码产量提高,人类 QA 能力成为瓶颈,团队把 UI、日志、指标和测试环境直接做成 Codex 可读能力。Agent 可以启动独立 worktree,操作页面,查询日志与指标,再根据验收条件修正。稳定长程执行需要真实反馈,不能只增加推理轮数。

→ 阅读原文:拆解 Codex Harness:让长程智能体可靠运行的工程设计

WorkBuddy 把相似结构放进办公场景。Ask、Craft 和 Plan 三种模式按任务复杂度与权限逐级展开。用户可以先从问答开始,再开放工作目录、Skills、多任务和远程助理。对于第一次接触桌面 Agent 的用户,这种权限梯度比一次性开放全部目录和工具更容易理解,也便于在使用中积累信任。

→ 阅读原文:3 万字长文带你 WorkBuddy 从入门到精通

团队何时该自建 Harness?Harrison Chase 给出的路线很克制:先用通用方案获得价值,持续收集私有轨迹和评测;当任务反复偏离通用系统熟悉的分布,再加入中间件、Hooks、记忆、沙箱或特定认知架构。失败可能来自模型、上下文或编排。没有可观察性,自建团队甚至无法判断自己正在修哪一层。

→ 阅读原文:何时该为 AI 智能体自建 Harness

Harness 的核心工作可以归纳为四项:维护任务状态,把环境能力变成工具,给动作设置权限,把结果送入验证循环。框架复杂度本身没有奖励。每一个新增组件,都应当对应一种已经在轨迹中反复出现的失败。

8 月 8 日至 10 日的早报连续出现淘宝主播 Harness、提示注入、投毒 Skill、Runta 基础设施与 Skill 工程。这些案例补足了另一面:工具可以被调用以后,系统还要验证工具来源、参数、返回内容和外部副作用,并在失败后保留恢复状态。统一 Harness 让这些规则进入同一个治理入口;分散在产品中的临时胶水,会把审计和迁移成本推迟到以后。

三、质量来自可观察、可回放的反馈闭环

执行层能够连续工作以后,质量问题会迅速显现。生成速度和代码量很容易观察,返工、事故和系统理解度却需要更长时间才会暴露。

阿里安全团队分享了一套完整的 Skill 改进流程。Agent 在某些 case 上持续失败,人工改两句 Skill,当前 case 修好,原本正确的 case 又退化。团队因此把结果与轨迹结合起来诊断。确定性规则先压缩问题,LLM 只生成 小于 80 行的最小 unified diff,再经过 target、guardrail、holdout、verify 四层 gate,并保留跨版本黑名单、checkpoint 和自动回滚。

这套流程先解决归因问题。最终结果失败,原因可能是工具缺失、Skill 指令不清、模型忽略步骤、参数错误,或评测本身存在噪声。如果直接把整份 Skill 交给模型重写,多个变量会同时变化,即使分数提高,也很难知道哪项修改有效。确定性诊断把原始轨迹压缩成较小的问题描述,再让模型只处理可以局部修复的部分。

最小 diff 将改进范围控制在可审查尺度内。单次 patch 不超过 80 行,既减少模型顺手改写无关规则的机会,也让回归原因更容易定位。失败 patch 与跨版本黑名单则避免系统在后续迭代中重复走向已知坏解。这些设计让「自我改进」更接近受约束的软件发布流程。

文章披露的实验中,GLM 准确率从 77.8% 提高到 88.9%。这个数字属于特定安全评测,真正可迁移的是流程边界:LLM 提出局部修改,验证器决定是否接受;评测集需要审计,失败 patch 需要保留,连续没有收益时需要停止。系统可以改进「怎么做」,无法发明缺失的工具能力。

四层 gate 也对应不同风险。Target 检查目标 case 是否改善,guardrail 防止已知能力退化,holdout 检查修改是否只记住当前样本,verify 再确认轨迹质量和运行约束。只看一个总分,系统很容易用牺牲未观测行为的方式换取局部提升;分层门禁把这类交换显式暴露出来。

→ 阅读原文:Agent 越改越乱之后,我用评测和轨迹把它拉回来了

美团履约技术团队与图灵 Agent 评测团队用两年实践补充了评测结构。他们区分结果评测与轨迹评测。最终回答是否正确是一层;工具选择、调用顺序、参数和中间状态是否合理是另一层。主观标准还要经过「人人一致、人机一致」校准。某履约业务的指标从 20 多个发展到接近 200 个,说明业务评测会随 Bad Case、Good Case 和场景逐步生长。

结果评测适合回答任务有没有完成,轨迹评测用于解释系统怎样到达结果。两个 Agent 可能都交付了正确答案,其中一个使用了稳定工具和可复现步骤,另一个依赖偶然猜测或多次无效调用。只看结果,两者分数相同;进入生产后,它们的成本、稳定性和风险会明显不同。

主观任务还需要先校准人类标准。「人人一致」检验评审者之间是否理解同一 rubric,「人机一致」再检查模型评审能否复现这套判断。如果人类自己对好坏没有稳定共识,增加 LLM Judge 只会把模糊标准自动化。美团从 20 多个指标扩展到近 200 个,也反映业务团队是在真实案例中逐步补齐定义。

Anthropic 的 Agent 评测指南提供了一个简洁判据:transcript 是完整轨迹,outcome 是环境中的最终状态。订票 Agent 声称任务完成,没有数据库里的有效预订,结果仍然是失败。评估一个 Agent,实际评估的是模型与 Harness 的组合。

把阿里与美团放在一起,可以得到一条更完整的改进循环:先用 outcome 判断业务是否完成,再用 trajectory 定位失败环节;修改保持最小;新版本经过目标集、护栏与留出集;最终仍由环境状态验收。评测因此不只是发布前打榜,也成为日常观测、回归与版本选择的一部分。

→ 阅读原文:Agent 评测漫谈

Addy Osmani 从代码质量角度提出持续门禁。单元测试验证已知行为,属性测试检查更广的输入空间,变异测试判断测试是否真的能抓住错误,架构规则限制不该出现的依赖。原文含 Sonar 赞助内容,这里只采用与供应商无关的方法。Agent 可以生成大量代码以后,确定性约束需要进入环境,人工评审则集中在意图、架构和难以形式化的风险上。

→ 阅读原文:智能体代码质量

Charity Majors 用「信任账户」解释同一个问题。当工程师交付没有逐行读过的代码,团队会消耗对系统的理解与信任。测试、确定性模拟、评测、护栏、可观察性和生产反馈,可以逐步补回这笔账。代码量、速度和部署频率都只是局部信号,客户价值、软件健康度、事故和返工需要一起记录。

METR 在 2025 年对 16 位熟悉项目的开源开发者、246 个真实任务做过随机对照实验。使用当时前沿 AI 工具的开发者平均慢 19%,而他们事前预计会快 24%。样本较小,工具和模型也已经更新,这项研究不能代表 2026 年的全部 AI Coding。它提醒团队,主观流畅度与端到端完成时间可能背离。

→ 阅读原文:别再怀疑 AI 开发:用可靠性与信任评估真实成效

阿里 AI Code Review 项目展示了质量系统进入开源维护后的组织结果。团队披露约 2 万月活、30% 以上采纳率、低于 5% 的误报率,开源后达到 2 万 Star。AI 可以处理 Issue 分类、测试、评审和发版中的重复执行,核心团队仍然负责方向、合并、回归与社区关系。自动化提高维护吞吐,也让合并判断与责任归属更重要。

→ 阅读原文:连续五天登上 GitHub Trending 首页的思考

四、多智能体扩大了协调和授权问题

单个 Agent 的反馈循环已经很复杂。多个 Agent 共享代码库、市场或工作频道后,资源冲突、信息不对称和目标分歧会增加一层系统风险。

Anthropic Frontier Red Team 的受控实验中,30 个 Agent 里有 18 个独立选择同一分支名;隐藏档案任务的群体准确率只有 17% 至 36%;遇到目标冲突,一些模型会持续升级「地盘战」。这些结果来自特定模型和实验环境,不能直接外推真实事故率。它们足以说明,增加 Agent 数量不会自然产生分工。

分支名冲突看似是一个小问题,却揭示了多 Agent 的共享资源困境。每个 Agent 单独看都选择了常见、合理的名称,群体同时行动时却发生碰撞。类似问题还会出现在文件锁、任务领取、预算消耗和外部账号上。个体策略合理,不能保证系统层面可协调。

隐藏档案实验考查的是信息分散后的集体判断。每个成员只掌握部分信息,需要通过沟通汇总证据。群体准确率显著低于单体上限,说明消息传递、来源可信度与最终聚合都可能损失信息。Agent 数量增加会扩大搜索广度,也增加误导、重复和协调开销。

目标冲突实验则把治理问题推到台前。如果两个 Agent 都认为自己的目标优先,单靠自然语言协商未必能结束竞争。系统需要资源所有权、超时、仲裁、申诉和人工中断等明确机制。否则,更强的执行能力只会让冲突更快地作用于真实环境。

这与 Anthropic 的多 Agent Research 生产系统形成对照。后者采用 orchestrator-worker 模式,lead Agent 先规划,再让子 Agent 并行搜索不同方向。官方内部评测称,它在广度型研究上比单 Agent 高 90.2%。性能数字只代表内部评测,工程经验更值得采用:子任务要彼此可分,结果必须能够合并,工具和提示按角色约束,同时承担更高 Token 成本、错误传播和协调开销。

成功模式与失败实验并不矛盾。Research 场景适合并行,是因为不同搜索方向相对独立,lead Agent 可以在末端汇总;共享代码和竞争性任务更容易产生写冲突与目标冲突。决定是否采用多 Agent 的第一道问题,应当是任务能否被切成低耦合、可独立验收的单元。

多 Agent 系统需要明确协议:资源怎样命名,谁能创建和关闭任务,两个 Agent 修改同一文件时如何隔离,意见冲突由谁仲裁,失败能否申诉,哪些行为触发人工中断。角色提示可以帮助分工,无法代替这些规则。

→ 阅读原文:多智能体系统的模式与问题

权限必须进入同一层设计。OpenAI 的 Daybreak 面向高风险网络防御工作,把访问分成 Blue 与 Red。GPT-5.6-Cyber 可用于零日漏洞发现和利用链验证,系统同时要求身份核验、硬件安全密钥、隔离环境、权限范围和动作审查。能力开放与授权条件被写进同一份产品合同。

Daybreak 的背景是网络攻防窗口正在缩短。模型可以帮助防守方更快发现漏洞,也可能加速攻击链构造。简单地提供或拒绝某个模型,很难覆盖任务之间的风险差异。分级准入将使用者身份、用途、环境与能力档位放在一起,让低风险防御工作和高风险研究采用不同门槛。

Red 层承载零日发现和利用链验证,要求硬件安全密钥与更严格身份核验;隔离环境和 scoped permissions 限制可触达资源,动作审查再处理可能产生外部副作用的步骤。这些措施各自覆盖不同失败面:账号被冒用、凭据泄露、工具越界和模型误操作不能依靠同一道防线解决。

OpenAI 公开的 Codex 安全实践采用相似原则。低风险、可逆操作可在沙箱内自动执行;高风险动作触发审批或阻断;Agent 原生日志保留原始请求、工具活动、审批决定、工具结果和网络策略,事故后可以还原行动链。

这条设计同样适用于普通企业 Agent。读取公开文档、修改临时文件和提交生产变更不应共享同一授权级别。权限需要按资源、动作与环境细分,审批也应出现在风险发生的具体步骤,而不是会话开始时一次性授予无限范围。

→ 阅读原文:随着网络防御窗口收窄,扩大 Daybreak 项目

Claude Tag 面对日常办公,也需要校准主动性。它读取整个 Slack 频道的上下文、记忆和长期指令,再决定内联回复、开启线程、归入已有任务或保持沉默。Anthropic 称,主动响应判断准确性提高约 30%。办公 Agent 的协作质量既包括及时参与,也包括知道何时不打断人。

→ 阅读原文:Claude Tag 现在更能读懂全场

协调与权限需要共同管理。Agent 越多,权限继承和资源冲突越复杂;能力越强,错误动作的外部影响越大。身份、资源、动作和证据形成同一条控制链,自主性才能按风险逐级开放。

五、路由与缓存决定执行层的经济性

Agent 系统要长期运行,成本不能只看模型的输入、输出单价。

OpenRouter CEO Alex Atallah 从网关市场解释多模型选择。不同供应商在价格、速度、可用性、质量和数据政策上存在差异。企业需要路由、故障转移、安全层和供应商替换,才能在单一服务变化或故障时保留选择权。访谈没有给出完整的量化比较,更适合作为产业结构与战略风险判断。

模型网关面对的并非静态选择题。同一模型可能由多个供应商提供,价格、区域、吞吐和故障率不同;同一任务也可能在快速模型、推理模型与专用模型之间切换。路由层需要同时理解任务需求和供应商状态,再决定请求发往哪里。

选择权还有长期价值。模型价格会调整,速率限制会变化,供应商可能中断服务或修改数据政策。如果产品直接依赖某一家专有参数与返回格式,迁移成本会随业务增长持续上升。统一接口、参数能力检测和 fallback 让团队可以逐步替换供应商,而不必在故障时重写整个应用。

OpenRouter 官方文档提供了具体机制。Provider routing 可以指定供应商顺序、是否允许 fallback、是否要求完整参数支持,还能限制零数据保留端点。提示缓存启用后,sticky routing 会把同一会话尽量送到同一供应商,以维持缓存;供应商失败时再切换。

require_parameters 可以避免请求被送到不支持关键参数的端点,ZDR 和 data policy 约束则把隐私要求带入路由。默认的「可用」并不代表业务上可接受。对于企业任务,参数完整性、数据驻留和日志政策可能比几百毫秒延迟更重要。

自动选择模型时,会话一致性同样重要。如果每轮更换模型,行为会漂移,缓存也无法复用。OpenRouter 使用 session_id 固定会话里的模型和供应商。这里存在一个明确权衡:故障转移希望随时换路,缓存和行为一致性希望尽量不换。路由器要根据错误类型、数据策略与任务状态决定如何取舍。

这也意味着路由器本身要接受评测。它是否把复杂任务误送给便宜模型,升级以后是否丢失历史,fallback 是否重复产生外部动作,都需要用真实轨迹检查。网关提高了可用性,也新增了一个可能误判的控制组件。

→ 阅读原文:OpenRouter、开放模型与 LLM 网关市场

阮一峰在科技爱好者周刊第 408 期用 DeepSeek V4 Flash 的价格解释输入缓存。示例中,缓存命中的输入价格只有未命中的 1/50。文章进一步比较不同厂商的近似缓存窗口,并计算定时保活是否划算。

Agent 工作流特别适合讨论提示缓存,因为系统指令、工具定义、仓库说明和早期对话会在多轮请求中重复出现。只要稳定前缀保持一致,供应商就有机会复用已经计算过的内容。若 Harness 在历史中间插入消息、频繁改写系统提示,原本可缓存的前缀会失效。

缓存命中价格很低,不代表保活必然划算。为了延长 TTL 而定时发送请求,会产生写入、读取与模型输出成本;真实会话间隔过长时,维持缓存可能比重新计算更贵。文章给出的思路,是用自己的请求规模、间隔和价格计算临界点,而非照搬统一保活周期。

具体价格和 TTL 会变化,可复用的是计算方法:稳定前缀有多长,请求间隔是多少,命中率多高,保活本身花多少钱,任务失败后要重跑多少轮。DeepSeek 的峰谷定价又增加了时间维度。可延期批处理可以结合闲时价格、缓存窗口和队列优先级调度。

缓存还会影响故障转移。Prompt cache 通常保存在具体供应商端点,换路后可能立即丢失;sticky routing 因此尽量维持同一 provider。供应商出现故障时,系统需要接受一次缓存冷启动,或提前在备用端点准备上下文。可靠性和缓存效率之间没有免费的兼得。

缓存还要区分 prompt cache 与 response cache。前者复用前缀计算,模型继续生成新结果;后者对完全相同的请求返回旧结果。Response cache 适合重复测试或失败重放,不适合需要新采样与独立判断的步骤。评测流程如果误用响应缓存,可能得到稳定低价的结果,也可能失去试验独立性。

→ 阅读原文:你需要知道的 AI 缓存知识

一次 Agent 任务的真实账单至少包括模型输入输出、缓存写入与读取、工具运行、网络传输、沙箱资源、失败重试、人工审批和事故返工。路由目标不应只写「最低价格」。尾延迟、参数兼容、隐私边界、缓存命中和供应商集中风险,都要进入选择函数。

8 月 11 日早报中的 OpenRouter,随后几天的 DeepSeek 峰谷价格、GPT-5.6 效率设计和 AI 缓存知识,正好组成一条成本链。便宜模型如果频繁失败并触发升级,总成本可能更高;昂贵模型如果缩短轨迹、减少人工介入,可能更划算。缓存命中率、模型升级率、人工介入与最终成功率需要进入同一张生产监控表。

六、执行层正在进入公共基础设施、物理世界与科学研究

Peter Steinberger 的 Agent 项目最初只是一个 WhatsApp 中继。他想在手机上向电脑里的 Agent 发提示。项目受到数百万人关注后,安全审查、媒体压力、贡献者协作和持续运维一起到来。他反复强调,强 Agent 需要完整上下文、验证循环、合适权限和独立运行机器。

这个起点很有代表性。个人工具通常围绕一个明确痛点生长,开发者清楚它运行在哪台机器、可以访问哪些文件,也愿意在失败时手动修复。进入公共使用以后,这些默认条件全部改变:用户环境不一致,凭据和网络边界不同,错误会被快速放大,项目维护者还要回应安全报告与升级请求。

「让 Agent 自由运行」也会增加运行时责任。任务卡住时怎样超时,重复动作怎样去重,机器离线后如何恢复,用户能否看见当前状态,异常是否会消耗无限 Token,都需要产品化处理。一个巧妙的中继解决了交互入口,公共基础设施还要补齐状态、权限、运维和支持体系。

个人工具变为公共基础设施时,能力与责任同步增长。这也解释了开源项目为什么需要 Good First Issue、快速响应、发布流程和人的合并判断。公共项目包含 Issue、PR、版本、社区预期与安全响应,代码生成只是其中一部分。

这与阿里 AI Code Review 项目的经验可以串联起来。AI 能提高 Issue 分类、测试和评审吞吐,维护者仍要判断哪些建议合并、哪些回归需要阻断、怎样与贡献者沟通。Agent 项目规模化以后,团队优化的不再只是模型表现,还包括社区反馈周期与事故响应能力。

→ 阅读原文:Peter Steinberger 谈当数百万人让智能体自由运行后会发生什么

刘洺堉与张小珺的访谈把执行层带到 Physical AI。Cosmos 世界基座模型尝试连接物理推理、世界生成与动作预测。NVIDIA 在 2026 年 5 月发布 Cosmos 3,官方称它统一物理推理、世界生成和动作生成,并开放模型、训练脚本、部署工具与数据集。相关领先性描述属于 NVIDIA 官方口径。

世界模型承担的是行动前的预测问题。机器人需要理解当前场景,推测动作可能带来的变化,再选择符合具体身体与任务的操作。真实世界数据昂贵且危险,生成式世界模型可以提供更多仿真与合成样本,让策略在进入现实设备前覆盖长尾情况。

Cosmos 3 将 reasoning、world generation 和 action generation 放进同一体系,试图减少多个独立模型之间的信息断裂。NVIDIA 同时提供不同规模模型、训练与部署工具,说明 Physical AI 的交付对象不是一个云端 API,还包括数据管线、仿真、推理优化与具体硬件。

Physical AI 比软件 Agent 多出更硬的现实约束。机器人有具体身体,传感器存在噪声,动作有延迟和磨损,错误可能造成物理损害。模型还需要仿真、合成数据、策略训练、边缘推理、硬件和安全控制。刘洺堉谈到英伟达自研模型的一个目的,是反向理解硬件和客户的真实瓶颈。模型与基础设施会在真实任务中互相校准。

访谈中的「造市场」也可以从执行层理解。英伟达训练自己的模型,不只为竞争模型排名,还借此发现内存、带宽、推理与开发工具中的瓶颈,再把需求反馈到芯片和软件栈。Physical AI 的竞争单位因此覆盖模型、硬件、仿真平台和开发者生态,任何单点领先都需要整条链路配合。

→ 阅读原文:独家对话英伟达刘洺堉

科学研究是另一种高要求环境。腾讯科技借 Jeff Dean 的 Discovery Loop 与《LLMs Can't Jump》等研究,讨论模型为什么难以完成科学发现中的概念跃迁。文章把问题归纳为现实锚点不足、近端优化和缺少持续信念,并用「贝叶斯 AI」描述可能路线。这是二次研究解读,不能作为已经证实的行业结论。

Google AI Co-Scientist 提供了更接近实验的证据。系统让 Generation、Reflection、Ranking、Evolution、Proximity 和 Meta-review 等 Agent 生成、比较和修正假设,部分生物医学候选经过计算、专家与体外实验验证。Google 同时承认,文献综述、事实核验、外部工具交叉检查、自动评测和更大规模专家评价仍需加强。

2025 年一项阿尔茨海默病复现探索给 Agent 5 篇论文的方法和数据说明,让它们尝试复现 35 个关键发现。平均近似复现比例为 53.2%,数值和统计方法经常偏离原文。样本很小,却指向一条清楚边界:生成合理假设与重现实验证据之间,还有数据、方法、环境和专家判断。

→ 阅读原文:Jeff Dean 们,赶在贝叶斯 AI 到来之前跳船

执行层进入软件之外的领域后,环境反馈会变得更严格。公共基础设施要求持续运维,机器人要求物理安全,科学研究要求可证伪假设、实验记录和可重复结果。模型可以扩大探索范围,证据链决定哪些结果能够被采用。

本周关键词

长程执行:用完整任务成功率、总时延、总成本和恢复能力衡量模型。

Harness:维护状态,连接工具与环境,处理权限、恢复和人机审批。

轨迹评测:把结果与行动过程放在一起,让失败可以定位、回放和修正。

分级权限:依据动作风险、可逆性与外部副作用逐级开放自主性。

路由与缓存:在质量、延迟、隐私、可用性与成本之间进行生产级权衡。

本期最值得带走的判断,是把模型和执行层放在同一个评估对象里。模型决定系统能够提出怎样的行动,Harness、环境、评测、权限与成本控制决定这些行动能否长期可靠地发生。

关于 BestBlogs

BestBlogs.dev 是 AI 驱动的私人阅读助手。它会从 RSS、Newsletter、Twitter、YouTube、Podcast 等来源中筛选高质量内容,结合你关注的源、兴趣标签和阅读行为,把「我的早报」整理成每天真正适合你的阅读流,不论你关注的是技术、AI、产品、商业、研究、设计、投资、文化还是个人成长。

完成新用户三步引导即送 7 天 Pro 试用;现有 Pro 用户每邀请 1 位朋友,双方各得 7 天 Pro,单人上限 28 天。

发现真正适合你的高质量内容。欢迎来体验,也欢迎推荐给身边认真阅读的朋友。

#BestBlogs #精选周刊 #智能体 #Harness #Agent评测 #AI工程

BestBlogs.dev|发现真正适合你的高质量内容

来源:ginobefun · x.com

BestBlogs 周刊:智能执行层全景解析

ginobefun · @hongming731 · X·2026-08-16 21:50·29分钟前
AI 导读

BestBlogs 第108期周刊聚焦AI智能体执行层,Grok 4.6、DeepSeek V4 Pro、Gemini 3.7 Flash均优化长程Agent能力。DeepSeek开源插件化Harness v0.1,OpenAI公开Codex Harness机制。周刊从执行模型、Harness、评测、多智能体、路由缓存等六条主线,剖析模型如何稳定完成任务。

https://x.com/i/article/2088984377762193408

BestBlogs 精选周刊第 108 期:智能的执行层

🎧 本期也有播客版本:BestBlogs 周刊第 108 期 · 时长 21:04 · 在小宇宙搜索「BestBlogs 周刊」即可收听。

在线阅读和收听:https://www.bestblogs.dev/newsletter/issue108

导语:智能怎样穿过环境,稳定完成任务

模型已经能够读代码、调用工具、操作文件、进入 Slack,也能在沙箱中持续工作数小时。现在更难的问题,是它怎样穿过真实环境,把一个目标稳定地变成结果。

一次 Agent 任务会经历多轮推理。系统要选择工具、维护状态、处理失败、控制权限,还要判断环境里的结果是否真的满足目标。任何一环不可靠,榜单上的模型能力都很难完整抵达用户。

过去几期,我们讨论了判断力、验证边界、「1% 法则」和个人 AGI。第 108 期进入更具体的工程现场。Grok、DeepSeek 和 Gemini 同时更新长程 Agent 能力;DeepSeek 开源插件化 Harness;OpenAI 公开 Codex Harness 的运行机制;阿里和美团把评测、轨迹与回滚做成持续流程;OpenRouter、缓存、Daybreak 和多智能体研究,则把成本、授权与协调放到同一张图里。

本期沿六条主线展开:执行模型、Harness、质量与评测、多智能体与权限、路由与缓存,以及执行层进入公共基础设施、物理世界和科学研究之后的新边界。

一、模型开始为长程执行优化

Grok 4.6、DeepSeek V4 Pro 和 Gemini 3.7 Flash 的发布有一个共同特点:模型能力、接口、思考预算、价格和任务调度开始被放在一起描述。

Cursor 与 SpaceXAI 发布 Grok 4.6 时,把长时间 Agent、代码库协作、知识工作和交互式应用放在核心位置。官方称,它在由 9 项基准构成的 Artificial Analysis Intelligence Index 上与 GPT-5.6 Sol 持平。发布中更值得留意的是行为描述:模型在较长任务里会主动测试和验证自己的工作。

这类「自测」行为为什么重要?代码 Agent 在长任务中经常遇到一种局部最优:某个文件已经改完,单个测试也通过,但完整构建、交互流程或相邻模块仍然失败。模型如果只把生成代码视为终点,就会过早宣布完成;如果它会继续运行测试、检查界面或回看任务要求,Harness 才有机会把环境反馈送回下一轮。Grok 4.6 的发布信号,正是把验证行为纳入模型能力描述。

Cursor 的场景也说明,长程执行并不等于让模型在后台待得更久。代码库搜索、文件编辑、终端命令、浏览器检查和人工反馈会交替出现,任何一次工具调用都可能改变后续上下文。模型需要在多步行动里保存目标,同时识别哪些结果已经被环境证实,哪些仍然只是推断。

单轮问答可以比较一次输出。长程任务还要看模型能否持续维护目标,是否会根据工具反馈修正计划,遇到失败能否恢复,最终是否拿到环境里的真实结果。官方 benchmark 能说明指定配置下的能力,却不能替代真实代码库、多轮反馈和长会话回归。

因此,团队复测 Grok 4.6 时,至少应记录任务完成率、平均工具调用轮数、失败后恢复率、人工介入次数和总成本。这里的重点并非建立一张更复杂的排行榜,而是确认官方描述中的长轨迹优势,能否在自己的仓库、权限和测试环境中稳定出现。

→ 阅读原文:Grok 4.6 发布 · Cursor

DeepSeek V4 Pro 把系统性写得更直接。正式版增强生产环境里的 Agent 表现,原生支持 OpenAI Responses API 与 Codex。V4-Pro 和 V4-Flash 提供 low、high、max 三档思考强度。8 月 17 日起,闲时 API 价格是高峰的一半。

Responses API 与 Codex 兼容降低了接入成本。已有工具如果围绕这一接口组织消息、工具调用与状态,就可以更快替换模型或做对照实验。不过,接口兼容只解决调用形式,无法保证工具选择、上下文压缩和错误恢复完全一致。团队仍需要把每种模型放进相同任务与 Harness 中验证。

三档思考强度则把推理预算变成任务级策略。需求澄清、简单分类和确定性修改可以使用较低档位;跨模块重构、复杂调试和高风险判断再提高预算。如果所有步骤都使用 max,系统会把大量成本花在边界明确的环节;如果全部使用 low,失败重试与人工接管又可能抵消节省。

这让推理预算和任务调度成为可以编排的变量。复杂步骤使用较高思考档位,边界明确的工作使用较低档位,批处理放到闲时执行。DeepSeek 同时注明,公开 Code Agent 结果运行在自家 Harness 极简模式,并采用指定采样参数。模型、Harness、工具、超时和上下文管理共同构成测试条件;换一套执行环境,结果可能变化。

峰谷定价把时间也纳入调度策略。离线评测、代码索引、批量迁移和低优先级修复可以排到闲时;需要同步协作的交互任务则继续使用高峰资源。把这一点与后文的缓存、路由结合起来看,执行层已经开始像传统计算平台一样管理队列、服务等级和单位任务成本。

→ 阅读原文:DeepSeek-V4-Pro 正式版上线

Gemini 3.7 Flash 展示的是高频执行路线。Google 公布的数据中,FrontierCode 1.1 Main 从 34.4% 提高到 43.6%,DeepSWE v1.1 从 49.0% 提高到 65.3%。首发输入价格是每百万 Token 0.75 美元,输出是 3.75 美元。它进入 Gemini Spark 和企业 Agent 平台,并更新 CBRN 与网络攻击相关防护。

Flash 模型的价值来自循环中的复利。Agent 可能连续读仓库、搜索历史、修改文件、运行测试,再依据失败继续修正。每轮多一秒、每次多传一段重复上下文,都会在完整任务中累计。OpenAI 最近公开 GPT-5.6 的效率设计时也提到,Harness 会反复发送指令、历史、工具定义和早期结果,因此采用 append-only 历史来保持稳定前缀和缓存复用。

→ 阅读原文:推出 Gemini 3.7 Flash

模型评估因而需要一张更完整的成绩单:能力决定任务上限,接口决定能否进入工具链,思考档位决定预算分配,延迟和价格决定循环次数,安全策略决定开放范围。对真实团队而言,完整任务成功率、总时延、总成本和失败恢复,比单独一列 benchmark 更接近生产表现。

这与 8 月 13 日、14 日早报的连续信号一致。Grok 4.6、GPT-5.6 Sol、DeepSeek 与 Gemini 的发布密集出现,生产可靠性、Harness 效率和价格调度也同时成为焦点。团队无法为每次发布重新发明一套评估方法,更可持续的做法是固定真实任务、预算与回归环境,再区分模型升级、Harness 改动和价格变化各自带来的影响。

二、Harness 把能力组织成持续工作的系统

模型提出下一步行动,Harness 负责让行动发生,并把结果送回下一轮。

DeepSeek Harness v0.1 把模型、工具、Skill、会话、沙箱、存储、循环、调度和 UI 表达成插件。标准、程序化工具调用、极简和创造模式可以重新组合。append-only 会话日志让上下文注入、工具调用、子 Agent 调度、恢复和回放落在同一条事件流中。

「一切皆插件」解决的是执行系统里变化频率不一致的问题。模型会更换,工具协议会演进,沙箱和存储有不同部署要求,调度策略也会随任务规模变化。如果这些能力被写死在一个循环里,任何局部升级都会牵动整个系统;插件边界让团队可以替换模型、沙箱或存储,同时保留同一条会话和观测链。

这套框架还提供标准、程序化工具调用、极简与创造等模式,反映了 Agent 任务并没有统一的最佳循环。严格工具任务需要明确结构和参数约束,探索性任务需要更大的生成空间,benchmark 复测又希望减少额外组件。模式的意义在于显式表达这些取舍,避免一套配置覆盖所有任务。

长任务中途失败以后,系统需要知道哪一步成功、哪一步产生外部副作用、当前状态能否恢复,以及重试会不会重复执行。状态可以回放,异步任务和并发 Agent 才有可靠管理的基础。DeepSeek Harness 仍是开发者预览版,接口和核心插件会快速变化,适合研究架构与参与生态,暂时不构成生产稳定性承诺。

append-only 日志也是评测与审计的共同底座。工具调用、观察结果和调度事件留在一条时间线上,评测器才能判断失败发生在模型决策、工具返回、权限策略还是恢复逻辑。后文阿里与美团的轨迹评测,依赖的正是这种过程可见性。没有稳定事件记录,团队只能从最后回复反推原因。

→ 阅读原文:DeepSeek Harness 开发者预览版:一切皆插件

Dominik Kundel 对 Codex Harness 的拆解补上了另一组细节。App Server 在用户界面与 Codex Core 之间维护线程和事件,Responses API 连接模型与工具,deferred tools 在需要时进入上下文,异步子 Agent 处理可并行工作,沙箱隔离文件和命令,compaction 让长会话保留可继续执行的上下文,独立只读审查 Agent 则检查授权与风险。

App Server 处理的是长任务的产品生命周期。用户可能关闭客户端、换一台设备、从旧线程继续,也可能在 Agent 等待审批时离开。服务端需要持久化线程和事件,再把底层运行状态翻译成稳定的客户端通知。这样,CLI、编辑器和桌面应用可以共享同一套 Agent 核心,而不必各自重写执行循环。

deferred tools 与 compaction 分别控制工具和历史占用。工具描述如果每轮全部进入上下文,会持续消耗输入 Token;历史如果无限增长,又会挤压当前任务信息。延迟加载只在需要时暴露工具,压缩则保留目标、关键决定和未完成状态。二者共同处理长程 Agent 最常见的上下文膨胀。

OpenAI 官方资料进一步列出线程持久化、配置、认证、审批和双向事件。客户端除了发送请求,还要在 Agent 需要授权时接收审批请求,暂停任务,等用户选择后继续。Harness 已经覆盖状态、策略、执行、恢复和人机协作,远比模型外的一层提示词更完整。

异步子 Agent 又引入文件隔离、完成通知和结果合并。一个主任务可以同时派出代码调研、测试分析或独立审查,但子任务不能随意覆盖同一工作区,也不能把「仍在运行」误判为失败。Codex 的独立只读审查体现了一种可复用分工:执行者负责产生变更,审查者在更窄权限下评估风险,两者通过可见证据汇合。

OpenAI 的 Harness engineering 复盘还记录了一项重要变化:当代码产量提高,人类 QA 能力成为瓶颈,团队把 UI、日志、指标和测试环境直接做成 Codex 可读能力。Agent 可以启动独立 worktree,操作页面,查询日志与指标,再根据验收条件修正。稳定长程执行需要真实反馈,不能只增加推理轮数。

→ 阅读原文:拆解 Codex Harness:让长程智能体可靠运行的工程设计

WorkBuddy 把相似结构放进办公场景。Ask、Craft 和 Plan 三种模式按任务复杂度与权限逐级展开。用户可以先从问答开始,再开放工作目录、Skills、多任务和远程助理。对于第一次接触桌面 Agent 的用户,这种权限梯度比一次性开放全部目录和工具更容易理解,也便于在使用中积累信任。

→ 阅读原文:3 万字长文带你 WorkBuddy 从入门到精通

团队何时该自建 Harness?Harrison Chase 给出的路线很克制:先用通用方案获得价值,持续收集私有轨迹和评测;当任务反复偏离通用系统熟悉的分布,再加入中间件、Hooks、记忆、沙箱或特定认知架构。失败可能来自模型、上下文或编排。没有可观察性,自建团队甚至无法判断自己正在修哪一层。

→ 阅读原文:何时该为 AI 智能体自建 Harness

Harness 的核心工作可以归纳为四项:维护任务状态,把环境能力变成工具,给动作设置权限,把结果送入验证循环。框架复杂度本身没有奖励。每一个新增组件,都应当对应一种已经在轨迹中反复出现的失败。

8 月 8 日至 10 日的早报连续出现淘宝主播 Harness、提示注入、投毒 Skill、Runta 基础设施与 Skill 工程。这些案例补足了另一面:工具可以被调用以后,系统还要验证工具来源、参数、返回内容和外部副作用,并在失败后保留恢复状态。统一 Harness 让这些规则进入同一个治理入口;分散在产品中的临时胶水,会把审计和迁移成本推迟到以后。

三、质量来自可观察、可回放的反馈闭环

执行层能够连续工作以后,质量问题会迅速显现。生成速度和代码量很容易观察,返工、事故和系统理解度却需要更长时间才会暴露。

阿里安全团队分享了一套完整的 Skill 改进流程。Agent 在某些 case 上持续失败,人工改两句 Skill,当前 case 修好,原本正确的 case 又退化。团队因此把结果与轨迹结合起来诊断。确定性规则先压缩问题,LLM 只生成 小于 80 行的最小 unified diff,再经过 target、guardrail、holdout、verify 四层 gate,并保留跨版本黑名单、checkpoint 和自动回滚。

这套流程先解决归因问题。最终结果失败,原因可能是工具缺失、Skill 指令不清、模型忽略步骤、参数错误,或评测本身存在噪声。如果直接把整份 Skill 交给模型重写,多个变量会同时变化,即使分数提高,也很难知道哪项修改有效。确定性诊断把原始轨迹压缩成较小的问题描述,再让模型只处理可以局部修复的部分。

最小 diff 将改进范围控制在可审查尺度内。单次 patch 不超过 80 行,既减少模型顺手改写无关规则的机会,也让回归原因更容易定位。失败 patch 与跨版本黑名单则避免系统在后续迭代中重复走向已知坏解。这些设计让「自我改进」更接近受约束的软件发布流程。

文章披露的实验中,GLM 准确率从 77.8% 提高到 88.9%。这个数字属于特定安全评测,真正可迁移的是流程边界:LLM 提出局部修改,验证器决定是否接受;评测集需要审计,失败 patch 需要保留,连续没有收益时需要停止。系统可以改进「怎么做」,无法发明缺失的工具能力。

四层 gate 也对应不同风险。Target 检查目标 case 是否改善,guardrail 防止已知能力退化,holdout 检查修改是否只记住当前样本,verify 再确认轨迹质量和运行约束。只看一个总分,系统很容易用牺牲未观测行为的方式换取局部提升;分层门禁把这类交换显式暴露出来。

→ 阅读原文:Agent 越改越乱之后,我用评测和轨迹把它拉回来了

美团履约技术团队与图灵 Agent 评测团队用两年实践补充了评测结构。他们区分结果评测与轨迹评测。最终回答是否正确是一层;工具选择、调用顺序、参数和中间状态是否合理是另一层。主观标准还要经过「人人一致、人机一致」校准。某履约业务的指标从 20 多个发展到接近 200 个,说明业务评测会随 Bad Case、Good Case 和场景逐步生长。

结果评测适合回答任务有没有完成,轨迹评测用于解释系统怎样到达结果。两个 Agent 可能都交付了正确答案,其中一个使用了稳定工具和可复现步骤,另一个依赖偶然猜测或多次无效调用。只看结果,两者分数相同;进入生产后,它们的成本、稳定性和风险会明显不同。

主观任务还需要先校准人类标准。「人人一致」检验评审者之间是否理解同一 rubric,「人机一致」再检查模型评审能否复现这套判断。如果人类自己对好坏没有稳定共识,增加 LLM Judge 只会把模糊标准自动化。美团从 20 多个指标扩展到近 200 个,也反映业务团队是在真实案例中逐步补齐定义。

Anthropic 的 Agent 评测指南提供了一个简洁判据:transcript 是完整轨迹,outcome 是环境中的最终状态。订票 Agent 声称任务完成,没有数据库里的有效预订,结果仍然是失败。评估一个 Agent,实际评估的是模型与 Harness 的组合。

把阿里与美团放在一起,可以得到一条更完整的改进循环:先用 outcome 判断业务是否完成,再用 trajectory 定位失败环节;修改保持最小;新版本经过目标集、护栏与留出集;最终仍由环境状态验收。评测因此不只是发布前打榜,也成为日常观测、回归与版本选择的一部分。

→ 阅读原文:Agent 评测漫谈

Addy Osmani 从代码质量角度提出持续门禁。单元测试验证已知行为,属性测试检查更广的输入空间,变异测试判断测试是否真的能抓住错误,架构规则限制不该出现的依赖。原文含 Sonar 赞助内容,这里只采用与供应商无关的方法。Agent 可以生成大量代码以后,确定性约束需要进入环境,人工评审则集中在意图、架构和难以形式化的风险上。

→ 阅读原文:智能体代码质量

Charity Majors 用「信任账户」解释同一个问题。当工程师交付没有逐行读过的代码,团队会消耗对系统的理解与信任。测试、确定性模拟、评测、护栏、可观察性和生产反馈,可以逐步补回这笔账。代码量、速度和部署频率都只是局部信号,客户价值、软件健康度、事故和返工需要一起记录。

METR 在 2025 年对 16 位熟悉项目的开源开发者、246 个真实任务做过随机对照实验。使用当时前沿 AI 工具的开发者平均慢 19%,而他们事前预计会快 24%。样本较小,工具和模型也已经更新,这项研究不能代表 2026 年的全部 AI Coding。它提醒团队,主观流畅度与端到端完成时间可能背离。

→ 阅读原文:别再怀疑 AI 开发:用可靠性与信任评估真实成效

阿里 AI Code Review 项目展示了质量系统进入开源维护后的组织结果。团队披露约 2 万月活、30% 以上采纳率、低于 5% 的误报率,开源后达到 2 万 Star。AI 可以处理 Issue 分类、测试、评审和发版中的重复执行,核心团队仍然负责方向、合并、回归与社区关系。自动化提高维护吞吐,也让合并判断与责任归属更重要。

→ 阅读原文:连续五天登上 GitHub Trending 首页的思考

四、多智能体扩大了协调和授权问题

单个 Agent 的反馈循环已经很复杂。多个 Agent 共享代码库、市场或工作频道后,资源冲突、信息不对称和目标分歧会增加一层系统风险。

Anthropic Frontier Red Team 的受控实验中,30 个 Agent 里有 18 个独立选择同一分支名;隐藏档案任务的群体准确率只有 17% 至 36%;遇到目标冲突,一些模型会持续升级「地盘战」。这些结果来自特定模型和实验环境,不能直接外推真实事故率。它们足以说明,增加 Agent 数量不会自然产生分工。

分支名冲突看似是一个小问题,却揭示了多 Agent 的共享资源困境。每个 Agent 单独看都选择了常见、合理的名称,群体同时行动时却发生碰撞。类似问题还会出现在文件锁、任务领取、预算消耗和外部账号上。个体策略合理,不能保证系统层面可协调。

隐藏档案实验考查的是信息分散后的集体判断。每个成员只掌握部分信息,需要通过沟通汇总证据。群体准确率显著低于单体上限,说明消息传递、来源可信度与最终聚合都可能损失信息。Agent 数量增加会扩大搜索广度,也增加误导、重复和协调开销。

目标冲突实验则把治理问题推到台前。如果两个 Agent 都认为自己的目标优先,单靠自然语言协商未必能结束竞争。系统需要资源所有权、超时、仲裁、申诉和人工中断等明确机制。否则,更强的执行能力只会让冲突更快地作用于真实环境。

这与 Anthropic 的多 Agent Research 生产系统形成对照。后者采用 orchestrator-worker 模式,lead Agent 先规划,再让子 Agent 并行搜索不同方向。官方内部评测称,它在广度型研究上比单 Agent 高 90.2%。性能数字只代表内部评测,工程经验更值得采用:子任务要彼此可分,结果必须能够合并,工具和提示按角色约束,同时承担更高 Token 成本、错误传播和协调开销。

成功模式与失败实验并不矛盾。Research 场景适合并行,是因为不同搜索方向相对独立,lead Agent 可以在末端汇总;共享代码和竞争性任务更容易产生写冲突与目标冲突。决定是否采用多 Agent 的第一道问题,应当是任务能否被切成低耦合、可独立验收的单元。

多 Agent 系统需要明确协议:资源怎样命名,谁能创建和关闭任务,两个 Agent 修改同一文件时如何隔离,意见冲突由谁仲裁,失败能否申诉,哪些行为触发人工中断。角色提示可以帮助分工,无法代替这些规则。

→ 阅读原文:多智能体系统的模式与问题

权限必须进入同一层设计。OpenAI 的 Daybreak 面向高风险网络防御工作,把访问分成 Blue 与 Red。GPT-5.6-Cyber 可用于零日漏洞发现和利用链验证,系统同时要求身份核验、硬件安全密钥、隔离环境、权限范围和动作审查。能力开放与授权条件被写进同一份产品合同。

Daybreak 的背景是网络攻防窗口正在缩短。模型可以帮助防守方更快发现漏洞,也可能加速攻击链构造。简单地提供或拒绝某个模型,很难覆盖任务之间的风险差异。分级准入将使用者身份、用途、环境与能力档位放在一起,让低风险防御工作和高风险研究采用不同门槛。

Red 层承载零日发现和利用链验证,要求硬件安全密钥与更严格身份核验;隔离环境和 scoped permissions 限制可触达资源,动作审查再处理可能产生外部副作用的步骤。这些措施各自覆盖不同失败面:账号被冒用、凭据泄露、工具越界和模型误操作不能依靠同一道防线解决。

OpenAI 公开的 Codex 安全实践采用相似原则。低风险、可逆操作可在沙箱内自动执行;高风险动作触发审批或阻断;Agent 原生日志保留原始请求、工具活动、审批决定、工具结果和网络策略,事故后可以还原行动链。

这条设计同样适用于普通企业 Agent。读取公开文档、修改临时文件和提交生产变更不应共享同一授权级别。权限需要按资源、动作与环境细分,审批也应出现在风险发生的具体步骤,而不是会话开始时一次性授予无限范围。

→ 阅读原文:随着网络防御窗口收窄,扩大 Daybreak 项目

Claude Tag 面对日常办公,也需要校准主动性。它读取整个 Slack 频道的上下文、记忆和长期指令,再决定内联回复、开启线程、归入已有任务或保持沉默。Anthropic 称,主动响应判断准确性提高约 30%。办公 Agent 的协作质量既包括及时参与,也包括知道何时不打断人。

→ 阅读原文:Claude Tag 现在更能读懂全场

协调与权限需要共同管理。Agent 越多,权限继承和资源冲突越复杂;能力越强,错误动作的外部影响越大。身份、资源、动作和证据形成同一条控制链,自主性才能按风险逐级开放。

五、路由与缓存决定执行层的经济性

Agent 系统要长期运行,成本不能只看模型的输入、输出单价。

OpenRouter CEO Alex Atallah 从网关市场解释多模型选择。不同供应商在价格、速度、可用性、质量和数据政策上存在差异。企业需要路由、故障转移、安全层和供应商替换,才能在单一服务变化或故障时保留选择权。访谈没有给出完整的量化比较,更适合作为产业结构与战略风险判断。

模型网关面对的并非静态选择题。同一模型可能由多个供应商提供,价格、区域、吞吐和故障率不同;同一任务也可能在快速模型、推理模型与专用模型之间切换。路由层需要同时理解任务需求和供应商状态,再决定请求发往哪里。

选择权还有长期价值。模型价格会调整,速率限制会变化,供应商可能中断服务或修改数据政策。如果产品直接依赖某一家专有参数与返回格式,迁移成本会随业务增长持续上升。统一接口、参数能力检测和 fallback 让团队可以逐步替换供应商,而不必在故障时重写整个应用。

OpenRouter 官方文档提供了具体机制。Provider routing 可以指定供应商顺序、是否允许 fallback、是否要求完整参数支持,还能限制零数据保留端点。提示缓存启用后,sticky routing 会把同一会话尽量送到同一供应商,以维持缓存;供应商失败时再切换。

require_parameters 可以避免请求被送到不支持关键参数的端点,ZDR 和 data policy 约束则把隐私要求带入路由。默认的「可用」并不代表业务上可接受。对于企业任务,参数完整性、数据驻留和日志政策可能比几百毫秒延迟更重要。

自动选择模型时,会话一致性同样重要。如果每轮更换模型,行为会漂移,缓存也无法复用。OpenRouter 使用 session_id 固定会话里的模型和供应商。这里存在一个明确权衡:故障转移希望随时换路,缓存和行为一致性希望尽量不换。路由器要根据错误类型、数据策略与任务状态决定如何取舍。

这也意味着路由器本身要接受评测。它是否把复杂任务误送给便宜模型,升级以后是否丢失历史,fallback 是否重复产生外部动作,都需要用真实轨迹检查。网关提高了可用性,也新增了一个可能误判的控制组件。

→ 阅读原文:OpenRouter、开放模型与 LLM 网关市场

阮一峰在科技爱好者周刊第 408 期用 DeepSeek V4 Flash 的价格解释输入缓存。示例中,缓存命中的输入价格只有未命中的 1/50。文章进一步比较不同厂商的近似缓存窗口,并计算定时保活是否划算。

Agent 工作流特别适合讨论提示缓存,因为系统指令、工具定义、仓库说明和早期对话会在多轮请求中重复出现。只要稳定前缀保持一致,供应商就有机会复用已经计算过的内容。若 Harness 在历史中间插入消息、频繁改写系统提示,原本可缓存的前缀会失效。

缓存命中价格很低,不代表保活必然划算。为了延长 TTL 而定时发送请求,会产生写入、读取与模型输出成本;真实会话间隔过长时,维持缓存可能比重新计算更贵。文章给出的思路,是用自己的请求规模、间隔和价格计算临界点,而非照搬统一保活周期。

具体价格和 TTL 会变化,可复用的是计算方法:稳定前缀有多长,请求间隔是多少,命中率多高,保活本身花多少钱,任务失败后要重跑多少轮。DeepSeek 的峰谷定价又增加了时间维度。可延期批处理可以结合闲时价格、缓存窗口和队列优先级调度。

缓存还会影响故障转移。Prompt cache 通常保存在具体供应商端点,换路后可能立即丢失;sticky routing 因此尽量维持同一 provider。供应商出现故障时,系统需要接受一次缓存冷启动,或提前在备用端点准备上下文。可靠性和缓存效率之间没有免费的兼得。

缓存还要区分 prompt cache 与 response cache。前者复用前缀计算,模型继续生成新结果;后者对完全相同的请求返回旧结果。Response cache 适合重复测试或失败重放,不适合需要新采样与独立判断的步骤。评测流程如果误用响应缓存,可能得到稳定低价的结果,也可能失去试验独立性。

→ 阅读原文:你需要知道的 AI 缓存知识

一次 Agent 任务的真实账单至少包括模型输入输出、缓存写入与读取、工具运行、网络传输、沙箱资源、失败重试、人工审批和事故返工。路由目标不应只写「最低价格」。尾延迟、参数兼容、隐私边界、缓存命中和供应商集中风险,都要进入选择函数。

8 月 11 日早报中的 OpenRouter,随后几天的 DeepSeek 峰谷价格、GPT-5.6 效率设计和 AI 缓存知识,正好组成一条成本链。便宜模型如果频繁失败并触发升级,总成本可能更高;昂贵模型如果缩短轨迹、减少人工介入,可能更划算。缓存命中率、模型升级率、人工介入与最终成功率需要进入同一张生产监控表。

六、执行层正在进入公共基础设施、物理世界与科学研究

Peter Steinberger 的 Agent 项目最初只是一个 WhatsApp 中继。他想在手机上向电脑里的 Agent 发提示。项目受到数百万人关注后,安全审查、媒体压力、贡献者协作和持续运维一起到来。他反复强调,强 Agent 需要完整上下文、验证循环、合适权限和独立运行机器。

这个起点很有代表性。个人工具通常围绕一个明确痛点生长,开发者清楚它运行在哪台机器、可以访问哪些文件,也愿意在失败时手动修复。进入公共使用以后,这些默认条件全部改变:用户环境不一致,凭据和网络边界不同,错误会被快速放大,项目维护者还要回应安全报告与升级请求。

「让 Agent 自由运行」也会增加运行时责任。任务卡住时怎样超时,重复动作怎样去重,机器离线后如何恢复,用户能否看见当前状态,异常是否会消耗无限 Token,都需要产品化处理。一个巧妙的中继解决了交互入口,公共基础设施还要补齐状态、权限、运维和支持体系。

个人工具变为公共基础设施时,能力与责任同步增长。这也解释了开源项目为什么需要 Good First Issue、快速响应、发布流程和人的合并判断。公共项目包含 Issue、PR、版本、社区预期与安全响应,代码生成只是其中一部分。

这与阿里 AI Code Review 项目的经验可以串联起来。AI 能提高 Issue 分类、测试和评审吞吐,维护者仍要判断哪些建议合并、哪些回归需要阻断、怎样与贡献者沟通。Agent 项目规模化以后,团队优化的不再只是模型表现,还包括社区反馈周期与事故响应能力。

→ 阅读原文:Peter Steinberger 谈当数百万人让智能体自由运行后会发生什么

刘洺堉与张小珺的访谈把执行层带到 Physical AI。Cosmos 世界基座模型尝试连接物理推理、世界生成与动作预测。NVIDIA 在 2026 年 5 月发布 Cosmos 3,官方称它统一物理推理、世界生成和动作生成,并开放模型、训练脚本、部署工具与数据集。相关领先性描述属于 NVIDIA 官方口径。

世界模型承担的是行动前的预测问题。机器人需要理解当前场景,推测动作可能带来的变化,再选择符合具体身体与任务的操作。真实世界数据昂贵且危险,生成式世界模型可以提供更多仿真与合成样本,让策略在进入现实设备前覆盖长尾情况。

Cosmos 3 将 reasoning、world generation 和 action generation 放进同一体系,试图减少多个独立模型之间的信息断裂。NVIDIA 同时提供不同规模模型、训练与部署工具,说明 Physical AI 的交付对象不是一个云端 API,还包括数据管线、仿真、推理优化与具体硬件。

Physical AI 比软件 Agent 多出更硬的现实约束。机器人有具体身体,传感器存在噪声,动作有延迟和磨损,错误可能造成物理损害。模型还需要仿真、合成数据、策略训练、边缘推理、硬件和安全控制。刘洺堉谈到英伟达自研模型的一个目的,是反向理解硬件和客户的真实瓶颈。模型与基础设施会在真实任务中互相校准。

访谈中的「造市场」也可以从执行层理解。英伟达训练自己的模型,不只为竞争模型排名,还借此发现内存、带宽、推理与开发工具中的瓶颈,再把需求反馈到芯片和软件栈。Physical AI 的竞争单位因此覆盖模型、硬件、仿真平台和开发者生态,任何单点领先都需要整条链路配合。

→ 阅读原文:独家对话英伟达刘洺堉

科学研究是另一种高要求环境。腾讯科技借 Jeff Dean 的 Discovery Loop 与《LLMs Can't Jump》等研究,讨论模型为什么难以完成科学发现中的概念跃迁。文章把问题归纳为现实锚点不足、近端优化和缺少持续信念,并用「贝叶斯 AI」描述可能路线。这是二次研究解读,不能作为已经证实的行业结论。

Google AI Co-Scientist 提供了更接近实验的证据。系统让 Generation、Reflection、Ranking、Evolution、Proximity 和 Meta-review 等 Agent 生成、比较和修正假设,部分生物医学候选经过计算、专家与体外实验验证。Google 同时承认,文献综述、事实核验、外部工具交叉检查、自动评测和更大规模专家评价仍需加强。

2025 年一项阿尔茨海默病复现探索给 Agent 5 篇论文的方法和数据说明,让它们尝试复现 35 个关键发现。平均近似复现比例为 53.2%,数值和统计方法经常偏离原文。样本很小,却指向一条清楚边界:生成合理假设与重现实验证据之间,还有数据、方法、环境和专家判断。

→ 阅读原文:Jeff Dean 们,赶在贝叶斯 AI 到来之前跳船

执行层进入软件之外的领域后,环境反馈会变得更严格。公共基础设施要求持续运维,机器人要求物理安全,科学研究要求可证伪假设、实验记录和可重复结果。模型可以扩大探索范围,证据链决定哪些结果能够被采用。

本周关键词

长程执行:用完整任务成功率、总时延、总成本和恢复能力衡量模型。

Harness:维护状态,连接工具与环境,处理权限、恢复和人机审批。

轨迹评测:把结果与行动过程放在一起,让失败可以定位、回放和修正。

分级权限:依据动作风险、可逆性与外部副作用逐级开放自主性。

路由与缓存:在质量、延迟、隐私、可用性与成本之间进行生产级权衡。

本期最值得带走的判断,是把模型和执行层放在同一个评估对象里。模型决定系统能够提出怎样的行动,Harness、环境、评测、权限与成本控制决定这些行动能否长期可靠地发生。

关于 BestBlogs

BestBlogs.dev 是 AI 驱动的私人阅读助手。它会从 RSS、Newsletter、Twitter、YouTube、Podcast 等来源中筛选高质量内容,结合你关注的源、兴趣标签和阅读行为,把「我的早报」整理成每天真正适合你的阅读流,不论你关注的是技术、AI、产品、商业、研究、设计、投资、文化还是个人成长。

完成新用户三步引导即送 7 天 Pro 试用;现有 Pro 用户每邀请 1 位朋友,双方各得 7 天 Pro,单人上限 28 天。

发现真正适合你的高质量内容。欢迎来体验,也欢迎推荐给身边认真阅读的朋友。

#BestBlogs #精选周刊 #智能体 #Harness #Agent评测 #AI工程

BestBlogs.dev|发现真正适合你的高质量内容

来源:ginobefun· x.com