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

BestBlogs 早报 · 09-19｜Anthropic 研发指标，Agent 业务评测治理，菜鸟托管交付

在线阅读本期早报

BestBlogs.dev 是 AI 驱动的私人阅读助手。这是面向所有人的每日早报内容，如果你希望它基于你的兴趣和阅读习惯整理，可以体验「我的早报」。

导语

代码生成占比超过 90%，需求交付却只快了约 10%，这个来自菜鸟的反差把问题说得很直接：模型能力的增长，尚未自动变成组织交付速度。研发、运营和产品团队真正需要处理的，是怎样量出进展、校准判断，并让一项长程工作在交接处不断线。

本期三条精讲分别给出三个信号。Anthropic 试着把前沿实验室内部的研发过程转化为可追踪指标；大淘宝把策略类 Agent 的评测拉回业务效果和上线治理；菜鸟则用结构化状态管理端到端交付。它们不是同一事件，却共同把注意力从「模型能不能做」推进到「系统是否可测、可控、可接续」。

最近几期早报已讨论过模型失准报告、可验证安全和语音 Agent 的验收。今天的材料补上了另一层：当能力进入日常流程后，团队应该留下哪些口径、证据和状态，才知道一次改进是否真的发生。

★ 精讲一：理解前沿实验室 AI 研发进度的衡量指标

来源：anthropic.com · BestBlogs 评分：90

前沿模型越来越多地参与下一代模型的研发，但外部往往只能看到发布节点和能力演示。Anthropic 的这篇文章尝试补上过程侧的观察口径：AI 做了多少研发工作、这些 Agent 的行动如何被监督、算力投向了哪些用途。它关注的是模型如何被开发，而不只是最终模型完成了什么任务。

第一组指标叫研发自动化指数。Anthropic 把公司里的 AI 研发工作整理成任务树，再按六级自动化标准为任务评分，从没有 AI 参与，到 AI 协作、AI 主导和完全自主。二零二六年八月的内部快照显示，Claude 主导了 26% 的被测研发工作，达到 AI 协作及以上的工作超过 90%，但没有任何被测任务完全由 Claude 自主完成。

这套做法的关键不是给「自动化」一个好看的总分。固定任务树和权重后，同一组织才可比较不同月份的变化；公开分级方法后，外部才知道数字究竟描述了哪些工作。文章给出的问题也很实用：当一个实验室说 AI 加速研发时，究竟是辅助了零散步骤，还是能在人的监督下主导大段任务？

第二组指标转向 Agent 监督。Anthropic 区分执行前的在线监控与执行后的离线审阅，并用覆盖率、审查延迟和升级率来描述它们。原文称，在最常用的内部平台里，二零二六年八月任一时刻约有三万个研发和工程 Agent；这些 Agent 的行动会先经过在线监控，行动后也会进入离线监控。

这比一句「系统受监督」更容易被检验。覆盖率说明多少行动落在视野内，审查延迟说明发现风险后多久能处理，升级率则暴露哪些异常需要进一步判断。随着 Agent 的运行时间变长、彼此之间开始委派任务，监督能力是否跟得上自动化程度，本身就应该成为可披露的工程指标。

第三组是算力分配。Anthropic 取二零二六年七月十三日至二十日的一周，将工作负载分类后估算研发算力中有多少用于安全。它报告约 6% 的 AI 研发算力、以及约 12% 的 AI 驱动研发算力投向安全相关工作。数字旁边也需要保留原文的限定：安全研究不一定像前沿训练那样消耗大量算力，因此它更适合用来比较同口径下的变化，而不是单独代表安全投入总额。

这篇文章仍然是 Anthropic 的内部披露，而非行业普查。作者也承认，当前缺乏跨实验室的共同方法，部分评估使用自家模型，可能出现评估器与被评对象相似的偏差。因此它提出第三方核验的方向。对读者而言，最有用的收获是一张观察表：AI 是否主导更多研发任务，Agent 行动能否被及时看见和介入，算力又是否持续流向安全与评估。

★ 精讲二：让 Agent 可评、可控、可迭代：业务效果导向的评测体系与场景实践

来源：大淘宝技术 · BestBlogs 评分：92

策略类 Agent 的难点，通常不是生成一段看起来合理的建议，而是它的输出会影响真实业务。营销补贴、广告投放或商品策略都没有唯一标准答案，离线评分好看，线上结果仍可能受货盘、周期、流量和实验噪声影响。大淘宝的文章因此把问题从「如何给 Agent 打分」改写成「怎样让质量判断进入一个持续运行的闭环」。

它提出「五层、四步、三阶段」的组织方式。五层评测对象覆盖输入约束、知识和上下文、执行过程、策略推理、业务效果与持续监控。这样做是为了区分失败来源：提示词目标矛盾、知识供给错误、工具执行异常和策略方向偏差，不能被同一个通过率掩盖。

文章的一个例子很典型。字段是否合法、预算是否越界，可以用确定规则拦截；策略是否合理、是否正确引用上下文，需要经校准的模型评估器辅助；ROI 是否提升，只能依赖真实业务实验。三类判断分别回答不同问题，不能把离线 Judge 的高分直接等同于线上效果。

四步质量归因负责把评测结果变成改进行动：先诊断问题在哪一层，再定位根因，将改进路由给 Prompt、数据、模型或业务规则，最后用回归验证检查是否退化。三阶段上线治理则把这套诊断接到准入、灰度和监控回流。对于会影响业务指标的 Agent，这条链路比单次验收更像一套长期质量基础设施。

文章还把 Judge 自身当成需要被校验的对象。团队通过 Auto Rubrics 从偏好对中挖掘候选规则，再用违反率、比较评估、位置交换一致性、稳定性筛选和交叉验证来选择规则。一个具体改进是，将绝对判断改为两个输出的对比判断，并随机交换选项位置，以识别模型的偏好偏差；文中报告模型自我判断的一致率从 46% 提高到 84%。

这套方法并不宣称已经消除了业务不确定性。原文反复提醒，离线合理不等于线上有效，评估器也可能没能表达业务目标。它留下的判断更稳妥也更有操作性：评测要能解释问题在哪里、让变更安全上线、再把真实数据带回下一轮。若一个团队只保留最终分数而没有归因、灰度和回归，质量闭环就还没有真正建立。

★ 精讲三：AI Coding 贡献率超 90%，需求交付却只快了 10%：菜鸟如何用 Agent 托管端到端交付？

来源：InfoQ 中文 · BestBlogs 评分：90

菜鸟的复盘提供了一个很好的效率校准。过去半年多，内部 AI Coding 贡献率从约 10% 提升到 90% 以上；这里的指标是 AI 生成代码行数在提交代码中的占比。但比较有 AI 参与和没有 AI 参与的需求后，需求变更周期只相差约 10%。编码自动化变快，并没有按同样比例传递到整个需求交付链。

原因在于链路比写代码长得多。需求仍要经过澄清、方案设计、测试用例、编译、测试和部署；即便一个阶段完成，往往还需工程师确认结果、切换工具并发起下一步。文章把这个停顿归结为「人主导流程」的限制：人的注意力和时间，会在多个阶段之间成为端到端瓶颈。

菜鸟的回答是托管交付。任务从需求澄清运行到预发部署，由 Agent 主导，工程师只在必要节点确认。它选择云端沙箱作为运行环境，一方面让任务可持续运行，另一方面让流程和经验不只留在个人电脑。这个选择也说明，所谓端到端并不是让 Agent 自己连续聊天，而是给它一个可运行、可复用、可审查的企业环境。

文章将方案拆成四层。通用 Agent 提供 Harness，负责上下文管理、会话恢复或独立执行；Plugin 承载 Skill、Subagent、Hooks、MCP 和 CLI 等可分发能力；Playbook 用自然语言描述企业流程；todo.json 记录每个任务的前置条件、状态与产物。它们分别处理执行、能力、流程和状态，而不是把所有细节塞进一个长 Prompt。

其中最值得借鉴的是结构化状态。菜鸟不使用容易被模型随意增删的 todo.md，而是限制 Agent 只处理序号最小的未完成任务，只修改状态与时间。每次执行先检查前置产物，再进入进行中状态，调用对应能力，核查输出真实存在，最后再更新状态。需求澄清和方案阶段需要人工确认时，流程会进入等待人工状态，而不是把不确定性藏进下一轮对话。

这并非一套可以直接复制到任何组织的配方。它依赖已有的流程、云端沙箱和任务边界；上线后最近 30 天交付了一百多个需求，仍是有限范围的实践。它的价值在于明确了先后顺序：先挑选验证成本低、边界清楚的任务，为每一步定义产物、状态和人工确认，再判断 Agent 是否真正缩短了交付，而不是只统计代码生成比例。

速览

LoRA 一作、OpenAI o1 核心成员的新工作：首次公开 397B 模型的 Agent RL 训练配方

来源：青稞AI · BestBlogs 评分：91

SkyRL 团队公开了一个 397B 参数知识工作 Agent 的强化学习训练案例。Qwen3.5 397B A17B 在 APEX Agents 上的 Pass@1 从 16.11% 提高到 27.29%，相对提升约 70%。397B 指的是总参数量，MoE 架构下每个 Token 实际激活约 17B 参数。

文章最有价值的部分不是结果曲线，而是训练顺序：先构建稳定的环境和 Agent Harness，再让推理与训练使用一致的 Token 序列，先在小任务上证明链路能过拟合，再做 35B 模型的算法消融，最后扩展到 397B。它还采用全异步 RL 来提高长轨迹训练的资源利用率。

这提醒团队把 Agent RL 视为系统工程。环境、Verifier、Token 对齐和调度中的任一偏差，都可能让长轨迹变成错误训练信号。原文也检查了更换 Harness 后的迁移，说明最终要观察的不是某个训练环境里的单一分数，而是能力能否离开原有工具配置继续成立。

Claude 如何提升生物分子建模能力

来源：Anthropic Research · BestBlogs 评分：90

Anthropic Research 介绍，Claude 在不到四周内优化了 30 多个开源生物分子模型，覆盖结构预测、蛋白设计、基因组学和蛋白语言模型。原文报告平均约 4 倍加速，同时尽量维持精度，并将优化代码开源。

一个技术切入点是结构预测中的三角注意力和三角乘法，它们对运行时间和显存都很昂贵。团队与 Claude 一起开发定制 Kernel，并结合缓存重复计算、简化无效分支等模型级优化。文章称，经过加速的版本会在下游任务上确认性能没有受到影响。

它还做出低内存的 Big 模式，使超过 10,000 个 Token 的生物分子系统可在单个 NVIDIA GPU 节点上进行准确预测。推理效率的下降门槛，可能让更多实验室能使用专用科学模型；但计算预测仍不等于实验验证，原文也通过后续竞赛和湿实验验证来连接这两条链路。

日志服务 TLS AgentLoop：让多模态调用清晰可见

来源：字节跳动技术团队 · BestBlogs 评分：90

火山引擎日志服务 TLS AgentLoop 处理的是多模态 Agent 的排障视角。当一次截图修复或图片问答结果不对时，仅看调用成功、耗时和 Token 消耗，无法判断模型究竟看到了什么。媒体如果只留下附件 ID，又会和提示词、模型输出及工具执行断开。

它沿用 Session、Trace 和 Span 的结构：Session 串联多轮会话，Trace 对应一次请求或一轮任务，Span 记录模型调用和工具执行。图片、音频或视频会出现在对应消息和调用节点中，开发者能够沿调用树定位带媒体的步骤，并在上下文里预览输入与输出。

系统不把大段 Base64 直接塞进日志，而是把文件留在对象存储，在 Trace 中保存对象位置、媒体类型、大小和摘要等引用。这既避免超长日志被截断，也让排查回到同一条上下文。正式接入时，媒体访问权限、临时地址和保留周期仍需要与业务数据治理一起设计。

Canto：为真实世界打造的语音模型 | Wispr Flow

来源：Hacker News · BestBlogs 评分：90

Wispr AI Lab 发布 Canto，目标是实时口述，而不是只在干净、录制条件受控的音频上取得好成绩。它用来自 2,300 多名用户的 10 小时英文 Wispr Flow 口述建立评估集，并将训练集和测试集中的说话人分离，以减少对说话人特征的过拟合。

在这组真实口述评估中，Canto 在全部比较模型里取得最低词错率。文章也给出更细的结果：完整挑战集上，Gemini 3.1 Pro 这一更大的多模态模型排在前面；Canto 在实时转写模型中最低，并在低音量和短口述上并列领先。这些条件比朗读语料更接近日常输入。

训练上，Canto 先用音频与参考转写进行监督微调，再通过 GRPO 比较同一段音频的多个转写候选，以相对奖励强化更好的完整转写。它的意义不只是一条榜单成绩，而是把噪声、低音量、短语音等真实失败条件变成可训练、可复查的目标。

DoorDash 利用多智能体 LLM 清理 60,000 个特性标志

来源：InfoQ · BestBlogs 评分：86

DoorDash 用多智能体 LLM 系统清理过时的特性标志。其平台管理超过 60,000 个标志，分布在约 623 个代码仓库，每月还会新增约 2,300 个。一个标志超过 90 天未修改、仍被代码引用且没有归档或排除，才会被定义为过时。

工作流分为两个阶段：协调 Agent 读取 Jira 工单、搜索仓库，并通过 MCP 查询实验平台的发布比例和目标值；工程师先审查报告并确认目标值，随后清理 Agent 在隔离的 Git worktree 中修改代码和测试，运行构建、测试、覆盖率和静态分析，全部通过后才创建拉取请求。

在 50 个过时标志的评估中，系统为 45 个生成了可用拉取请求，平均每次 13.8 分钟、成本 4.79 美元，DoorDash 对人工的估算是 1 到 2 小时。案例的重点不是把维护工作交给无人值守的模型，而是把人工批准、隔离环境和自动验证设为通向下一步的条件。

为智能体重建 Web：MCP Apps 与面向意图的互联网

来源：AI Engineer · BestBlogs 评分：90

AI Engineer 的这场分享讨论面向 Agent 的 Web 如何演化。MCP Apps 可以把服务方的交互组件放入对话中，使品牌、身份和必要的操作界面不会被压缩成一段数据或文本。例如用户在对话里预订酒店时，仍能看到自己正在与哪项服务交互。

它主张服务先把能力以接口和可发现资源的方式提供给助手，再只在需要人判断的最后一段把交互带回对话。目标不是让 Agent 像人一样逐页浏览，而是让它在用户意图的层次组合不同服务的能力。

分享还提到用不同 Agent 在同一网站上反复运行旅程，观察它们实际寻找什么、在哪一步失败。这个方向尚在变化中，但对网站团队的启发很明确：可访问性、清晰的信息结构和可调用的能力，未来既服务人，也会决定 Agent 是否能正确找到服务入口。

同样的时间与预算，做 3 条还是做 30 条？AI 如何改写内容的生产逻辑

来源：非凡产研 · BestBlogs 评分：90

非凡产研以星榜创始人的内容生产实践，讨论 AI 如何改变创意生产的账本。传统方式是一周做 3 条广告片，投放后跑出 1 条效果好的；工业化方式在相同时间和近似成本下做 30 条，投放后跑出 8 条。命中率从 33% 降到 27%，但效果好的内容总量是前者 8 倍。

这个案例并非主张用生成数量掩盖质量问题。原文将关键放在三项控制上：减少无效调用、控制返工范围、复用已确认内容。它把策划、脚本、分镜、视觉与剪辑放进同一套协作流程，让中间结果可见、可修改，也让一次跑通的方法能被保存为模板。

当生成能力跨过基础可用门槛，内容团队要解决的会是更长的任务链：上下文如何保留，状态如何交接，工具怎样协作，效果又怎样反馈。与其只比较单条素材的生成成本，不如先建立从创意到交付、从投放到复盘的系统账本。

今日小结

回顾今天的内容，Anthropic 提出研发过程的三组观察指标，大淘宝把评测接回业务闭环，菜鸟把交付写进结构化状态；它们共同强调，能力增长需要被测量、被校准，也要有可验证的后续动作。

时间有限时，可先从菜鸟的交付反差读起，再按需要选择大淘宝的评测体系或 Anthropic 的指标框架。关注训练系统、科学计算、可观测和产品入口的读者，则可从七条速览中按自身工作场景继续展开。

欢迎分享或评论：你的团队目前最难量化的是研发进展、业务效果还是交付状态？当 Agent 完成一个步骤后，你会用什么证据决定它能进入下一步？

👉 近期早报

• BestBlogs 早报 · 2026-09-18

• BestBlogs 早报 · 2026-09-17

• BestBlogs 早报 · 2026-09-16

• BestBlogs.dev 第 113 期：模型之外的尺子

• BestBlogs.dev 第 112 期：可托付的智能

• BestBlogs.dev 第 111 期：经验复利

BestBlogs 是 AI 驱动的私人阅读助手，帮助你发现真正适合你的高质量内容，关注你感兴趣的来源和主题，每天生成一份更适合自己的「我的早报」，欢迎体验和关注我们。