Real-SWE评测 Claude Fable 5.1最高得分38.8%

8 个前沿模型，面对 10 个真实企业任务，最高得分只有 38.8%。这组来自 Real-SWE 的数字，比「又刷新编码榜单」更让我在意。不过，先别把它读成程序员还有多少工作不会被替代。任务来自私有仓库，每个模型每题尝试 8 次，验收还包含工单里没写明的要求，和日常补个组件差得很远。2026 年 9 月 14 日这期 AI 热点，我想沿着六条线聊聊模型选型、调用账单、Agent 编排、组件与技能、安全和验收，看看哪些值得动手，哪些先别急着买单。

一、AI 编程模型排名更高，为什么不一定适合你的仓库？

先说结论，我会把这次 Real-SWE 当成挑选测试任务的参考，暂时不会照着排名换掉团队的默认模型。

据 dev.to 对 Real-SWE 的介绍，测试从私有企业代码库中选出 10 个任务，给 8 个模型各 8 次尝试机会。Claude Fable 5.1 得分 38.8%，GPT-6 Astra 为 33.8%，GPT-5.6 Sol 为 16.2%。其中一个分析流归约器任务，8 个模型合计 64 次尝试全部失败。

这个分母要记住。

38.8% 不能直接翻译成「十张工单能交付四张」。这里有重复尝试、特定评分办法，还有人类工程师花数周处理的任务。私有仓库能减少公开答案污染，但仅有 10 类任务，也很难覆盖支付、运营后台、移动端和基础设施这些完全不同的业务。

我更在意的是隐藏需求。工单写着迁移客户身份，验收时还要考虑历史数据、旧接口和兼容行为。这很像业务开发真正难的地方。代码能跑只是开始，漏掉一个老客户的特殊路径，照样不能合并。

另一篇关于小样本评测的文章，正好给这组排名补了一脚刹车。它讨论的系统在 45 个正样本上全部命中，在 8 个负样本上零误报。展示页当然可以写出漂亮的百分数，但 8 个负样本太少。

文中用零失败情况下的经验公式 3/n 估算错误率的 95% 置信上限，8 个样本算出来约为 37.5%。这是近似估算，小样本下不能当成精确区间；它想提醒的事情很实在，几次没出错，离证明系统可靠还差得远。而且重复跑同一批样本，也不会自动增加业务覆盖面。

回到这块，团队选 AI 编程模型，真正要比较的是同一套权限、工具和验收条件下，谁能把任务交付出来，以及需要人补多少工作。便宜模型如果反复重试，贵模型如果让审查时间翻倍，都可能把单次调用的优势吃掉。

模型选型该比较每个验收通过任务的总成本。

真要判断换不换，我会从最近的工单里挑几个当天能复现的小任务，混入历史兼容和异常路径，固定运行时间与权限，让两个候选各跑一轮。先看失败在哪里，再决定值不值得扩大样本，别拿这轮小测试宣布谁全面领先。

二、LLM 调用怎么省钱，缓存为什么不能只看问题文本？

说实话，今天几条成本消息里，比模型单价更容易被忽略的是请求怎么组织。

GPT-6 Astra 成本分析转述的短上下文费率，是每百万输入 token 10 美元、输出 token 50 美元。文章还写到，输入超过 272,000 token 后，整个请求进入长上下文费率，输入变成 20 美元，输出变成 75 美元。

因此，直接说「超过阈值价格翻倍」不够准确。按这篇文章的数字，输入翻倍，输出涨到原来的 1.5 倍，而且高费率作用于整个请求。这里引用的是文章对定价页的转述，我会用它发现预算风险，采购预算仍要按实际账户适用的费率核算。

拿文中的负载算，100 次调用，每次输入 42,000 token、输出 1,500 token，不考虑缓存和其他费用，总计 49.50 美元。这笔账能直接算出来。但同一篇文章给出的缓存节省比例，需要结合可缓存前缀大小、命中次数和写入费用看，不能套到所有代码审查流程上。

这里有个坑，Prompt 缓存和回答缓存是两件事。

UltraRAG 成本实践讨论的是稳定提示词前缀。固定指令放前面，变化的问题放后面，减少时间戳、随机 ID 对前缀复用的干扰。模型仍然要生成答案，只是部分输入可能复用缓存。

The New Stack 的回答缓存文章讨论的则是直接复用已有结果。请求、上下文、模型设置和底层数据都没变化，答案也仍然有效，才有机会跳过模型调用。

你要是也在做 AI 办公提效，比如制度问答、周报摘要或者内部知识库，后一种缓存确实值得看。但同一句「今年报销上限是多少」，不同地区、不同员工权限、不同制度版本，未必该拿到同一个答案。

这段 JavaScript 演示如何把影响答案的条件放进缓存键，避免只拿问题文本做索引。

import { createHash } from "node:crypto";

function answerCacheKey(input) {
  const identity = [
    input.tenantId,
    input.accessScopeVersion, // 权限范围不同，不能直接复用答案
    input.question,
    input.contextDigest,
    input.dataVersion,
    input.promptVersion,
    input.model,
    input.generationConfigDigest,
  ];
  if (identity.some(value => typeof value !== "string")) {
    throw new Error("缓存身份字段必须显式提供");
  }
  return createHash("sha256")
    .update(JSON.stringify(identity))
    .digest("hex");
}

最容易翻车的是 accessScopeVersion 那一行，它必须代表实际可见数据范围，不能随手填个角色名就认为完成了隔离。

再补一个容易被标题带偏的细节。UltraRAG 那篇文章把方案描述为段落感知分块，但展示的代码按空白拆词，再用固定窗口截取，并没有真正识别段落边界。哈希去重也只能处理规范化后相同的片段，不能消除语义重复，更不能直接照搬去切中文文档。

所以我会先拿一批脱敏的重复请求，比较完整缓存键的命中率，再修改其中一条请求的权限范围或文档版本，确认旧答案不会命中。省下多少调用，比预估「能降本百分之几」更值得记到账本里。

三、Agent 能持续跑几天，业务流程就能放心托管吗？

顺着上面聊，成本问题一旦进入长任务，就不只是 token 了。任务暂停后能不能继续，工具执行到一半断线会不会重复操作，子任务返回的东西能不能拼起来，都会变成工程投入。

OpenAI Agents API 的介绍文章称，这套托管能力负责会话持久化、上下文压缩、恢复和编排，应用提供工具并选择运行位置。文章还介绍了按需工具搜索、编程式工具调用，以及拥有独立上下文的子代理。

对全栈团队来说，这类服务吸引人的地方很直接。以前为了让一个研究任务跨进程继续跑，要自己处理不少状态；现在有机会把其中一部分交给平台。

但业务状态仍然得有人定义。

「会话恢复成功」和「退款没有重复执行」是两个验收条件。上下文压缩后，用户刚刚补充的限制还在不在；子代理认为任务结束时，主代理是否拿到了失败证据，这些都不能靠运行时替产品做决定。

另一篇 codex-sdlc 作者介绍，把流程分成需求分析、前后端实现、质量检查和最终验收。它更像是在回答另一半问题，任务交接时到底应该交什么。

比如「让用户收藏商品」，真正需要传下去的不只是这句话，还包括是否登录、是否跨会话保存、重复点击如何处理、保存失败怎么提示。把这些条件写清楚，比安排几个听起来像团队岗位的 Agent 更有用。

我对多 Agent 的收益持保留意见。Agents API 文章引用了客户评测从 0.71 提升到 0.85、延迟明显下降的数据，但这是厂商引用的客户案例。任务能拆开并行，才有机会拿到相似收益；共享状态很多、必须串行决策的流程，增加代理也可能增加交接和核对成本。

开发者转向技术编辑的讨论还提醒了一项经常漏算的成本。代码生成得越快，审查者越需要在短时间内重新建立系统理解。一个人接五份同时生成的 PR，不一定比自己写一份轻松。

我的取舍是先拿一个可独立验收的小功能试流程，并在测试环境里中断一次会话，观察恢复后是否重复调用工具、遗漏验收条件。当天能回答这两个问题，就已经比展示「后台连续运行了多久」更接近上线决策。

四、React 设计系统支持 MCP，能让 AI 少写多少错误组件？

对前端来说，我今天最想继续追的项目是 Astryx。

据 dev.to 对 Meta Astryx 的介绍，它是内部积累八年的 React 设计系统，基于 React 19 和 StyleX，包含超过 150 个无障碍组件，并提供面向 AI Agent 的 CLI 和 MCP 工具。

我更看重的是工具入口。

如果 Agent 能直接找到组件的真实属性、使用方式和约束，它就有机会少猜几个不存在的 API，少造一套项目里已经有的按钮。但文章里没有接入前后的错误率对照，所以「支持 MCP」目前只能说明它提供了这条接入路径，不能直接推导成生成质量提高多少。

而且组件数量和迁移成本没有线性关系。已有项目的主题体系、样式方案、表单封装、服务端渲染方式，都可能影响接入。对成熟业务，要我选我会先试一个弹窗表单，暂时不会为了 150 个组件重新装修整个后台。

这条消息和技能文档退化的实践文章放在一起读，会更有意思。后者描述的故障很普通，脚本早就更新了，Agent 仍然认真执行文档里旧的手工流程。

它不会觉得自己在犯错。

作者的处理办法是按变化频率维护指令，把稳定约束留在简短项目文件里，把具体操作放进带验证日期和检查步骤的技能中，高频变化的本地信息再单独维护。这里真正有用的是维护责任。组件升级之后，谁更新 Agent 能读到的用法，谁验证这些用法还能执行？

agent-skills 项目则强调静态分析、内容哈希、锁文件和发布前扫描。它声称开放市场中有 13.4% 的技能存在严重问题，但这个数字属于项目方表述，不能拿来代表所有技能生态。它列出的工程措施可以逐项检查，「完全可信」这样的宣传词，我不会直接接着用。

给 Agent 提供组件文档，也要给文档安排更新和验证。

当天最合适的试法，是让 Agent 用目标组件库完成一个包含校验、键盘操作和错误提示的表单，然后核对它有没有虚构属性、绕开现有组件。再抽查一条项目技能中的命令是否仍能执行，比同时安装几十个技能更容易判断收益。

五、AI Agent 安全该先防什么，密钥和工具权限够不够？

安全这组消息里，我不太买账的是「所有攻击都来自失窃密钥，因此不用担心模型能力」这种读法。

对 Anthropic 威胁报告的评论强调了凭证暴露的作用，包括从客户端、代码仓库和其他入口搜集密钥，再利用 Agent 加速后续行动。对程序员来说，这确实把注意力拉回了熟悉的地方，前端产物、构建日志、镜像和开发者令牌。

但同一篇摘录还提到了暴露的搜索端点、向评估沙盒注入恶意指令，以及自动化寻找潜在零日漏洞的工作流。仅凭这篇评论，既不能证明所有入口都是失窃密钥，也不能否定 AI 在漏洞发现和攻击扩展中的作用。

密钥是眼前的重点，却不是全部边界。

前面那篇 Astra 成本与系统卡分析，转述了较高的网络安全风险评级。这样的评级也不能直接翻译成「接入 API 就会被攻击」，还得看模型拿到了哪些工具、能接触什么环境、是否拥有外部写入权限。

IT之家对布罗克曼访谈的报道则提到，他认为研发节奏管控应针对前沿大模型项目，并表示一次 Agent 入侵事件推动了内部流程整改。这里要分开读，企业负责人的主张不是已经生效的政策，也不能给所有开源项目提供所谓政策确定性。

回到项目里，权限链条才是能马上检查的东西。一个只生成代码建议的助手，和一个能读生产配置、执行 Shell、访问外网并自动发布的 Agent，需要承担的风险显然不同。技能文件如果能进一步调用脚本，也应该放进这条链条里看。

我会优先检查前端构建产物和 CI 日志里的凭证暴露，再用测试账号验证工具是否真的拒绝越权操作。比如只给读取权限，就让它尝试一次明确禁止的测试写入；要确认的是工具返回拒绝，而不仅是模型口头答应不做。

六、Agent 返回成功，怎么发现重复写入和错误排查？

大概率你也遇到过这种情况，接口全是 200，流程也跑完了，用户说结果不对。

Agent 可观测性文章讨论的正是这种静默失败。它建议把模型调用、检索、工具执行、交接、重试和业务结果关联起来。只看延迟、token 和异常率，会漏掉错误工具选择、重复事务以及任务实际上没完成的问题。

我觉得最能把这件事讲具体的，是去重标记过期的案例。

系统处理一个事件，写入保留 24 小时的去重标记，同时生成一条长期保存的事实。几个月后回填旧数据，标记没了，事实还在。如果派生数据每次都生成新 ID，同一个事实就会再写一遍，整个过程完全可能没有异常。

光把 TTL 调大，只能延后问题。

这里需要的是稳定的派生身份。同一个来源、同一个逻辑事件、同一个派生版本，再跑一次应该能够定位到同一条记录。下面这段 JavaScript 用内存存储演示重放检查，实际项目需要由数据库唯一约束或原子写入保证并发安全。

import { createHash } from "node:crypto";

const facts = new Map();

function derive(event) {
  const key = createHash("sha256")
    .update(JSON.stringify([
      event.tenantId,
      event.source,
      event.logicalId, // 使用稳定业务身份，别使用每次重投的新 ID
      "customer-fact-v1",
    ]))
    .digest("hex");

  if (!facts.has(key)) {
    facts.set(key, { customerId: event.customerId });
  }
}

const event = {
  tenantId: "demo",
  source: "ticket",
  logicalId: "ticket-42",
  customerId: "customer-7",
};
derive(event);
derive(event); // 模拟去重标记过期后的再次派生
if (facts.size !== 1) throw new Error("重放产生了重复事实");

最容易翻车的是 logicalId 的选择，粒度太粗会吞掉合法的新事实，粒度太细又挡不住重复，更新语义也要单独设计。

另一篇 Claude Code 排查 403 的案例展示了另一种静默失败。作者和 Agent 连续怀疑认证、权限与身份验证，折腾两天后才发现，上传的是 ZIP，而服务要求 TAR.GZ。

错误解释听起来很合理，验证顺序却错了。

这个案例最值得留下的规则是，证据出来前，把解释叫作候选原因。先查自己生成的请求和文件，再设计能区分候选的测试。文件格式的回归检查也不能只看后缀，还得实际打开归档，检查它能否被正确解析，以及必需文件是不是处于约定位置。

对技术管理者来说，监控里应该能看到任务验收结果、重复写入、重试增长和每个成功任务的成本，并且能沿着同一个任务找到工具调用记录。数字没必要一口气铺满屏幕，先让它解释一个真实失败。

当天就可以选一条导入流程重放两遍，再给上传流程喂一个后缀正确但内容错误的文件。看系统能不能主动发现重复和格式错误，比再看一遍成功演示更有用。

总结

今天这些材料里，能直接核算和对照的东西很具体。按文章给出的费率，示例负载确实是 49.50 美元；Real-SWE 的报道明确限定在 10 个任务和每题 8 次尝试；8 个负样本零误报，也确实不足以支持对整体可靠性的乐观结论。

模型排名、产品能力和安全事件，这里依据的是所引文章的报道。我没有实测 Astryx、Agents API 或这些技能库，所以不会把「支持接入」写成已经提升交付质量，也不会把客户案例里的收益算到你们团队头上。

我的判断是，AI 编程正在把更多工作推向验收、状态管理和权限设计。前端工程师要能判断生成的交互是否完整，全栈开发者要管住工具副作用，管理者要把审查时间一起算进提效账本。AI 办公提效也一样，回答得快只是一个环节，答案能不能复用、权限有没有串、失败有没有被发现，决定它能否长期使用。

我会先花半天跑几个有明确验收条件的小任务，看看失败记录和账单，再决定下一笔工具预算。

参考

一、AI 编程模型排名更高，为什么不一定适合你的仓库？

先说结论，我会把这次 Real-SWE 当成挑选测试任务的参考，暂时不会照着排名换掉团队的默认模型。

这个分母要记住。

模型选型该比较每个验收通过任务的总成本。

二、LLM 调用怎么省钱，缓存为什么不能只看问题文本？

说实话，今天几条成本消息里，比模型单价更容易被忽略的是请求怎么组织。

这里有个坑，Prompt 缓存和回答缓存是两件事。

The New Stack 的回答缓存文章讨论的则是直接复用已有结果。请求、上下文、模型设置和底层数据都没变化，答案也仍然有效，才有机会跳过模型调用。

这段 JavaScript 演示如何把影响答案的条件放进缓存键，避免只拿问题文本做索引。

import { createHash } from "node:crypto";

function answerCacheKey(input) {
  const identity = [
    input.tenantId,
    input.accessScopeVersion, // 权限范围不同，不能直接复用答案
    input.question,
    input.contextDigest,
    input.dataVersion,
    input.promptVersion,
    input.model,
    input.generationConfigDigest,
  ];
  if (identity.some(value => typeof value !== "string")) {
    throw new Error("缓存身份字段必须显式提供");
  }
  return createHash("sha256")
    .update(JSON.stringify(identity))
    .digest("hex");
}

最容易翻车的是 accessScopeVersion 那一行，它必须代表实际可见数据范围，不能随手填个角色名就认为完成了隔离。

三、Agent 能持续跑几天，业务流程就能放心托管吗？

对全栈团队来说，这类服务吸引人的地方很直接。以前为了让一个研究任务跨进程继续跑，要自己处理不少状态；现在有机会把其中一部分交给平台。

但业务状态仍然得有人定义。

另一篇 codex-sdlc 作者介绍，把流程分成需求分析、前后端实现、质量检查和最终验收。它更像是在回答另一半问题，任务交接时到底应该交什么。

四、React 设计系统支持 MCP，能让 AI 少写多少错误组件？

对前端来说，我今天最想继续追的项目是 Astryx。

我更看重的是工具入口。

这条消息和技能文档退化的实践文章放在一起读，会更有意思。后者描述的故障很普通，脚本早就更新了，Agent 仍然认真执行文档里旧的手工流程。

它不会觉得自己在犯错。

给 Agent 提供组件文档，也要给文档安排更新和验证。

五、AI Agent 安全该先防什么，密钥和工具权限够不够？

安全这组消息里，我不太买账的是「所有攻击都来自失窃密钥，因此不用担心模型能力」这种读法。

密钥是眼前的重点，却不是全部边界。

六、Agent 返回成功，怎么发现重复写入和错误排查？

大概率你也遇到过这种情况，接口全是 200，流程也跑完了，用户说结果不对。

我觉得最能把这件事讲具体的，是去重标记过期的案例。

光把 TTL 调大，只能延后问题。

import { createHash } from "node:crypto";

const facts = new Map();

function derive(event) {
  const key = createHash("sha256")
    .update(JSON.stringify([
      event.tenantId,
      event.source,
      event.logicalId, // 使用稳定业务身份，别使用每次重投的新 ID
      "customer-fact-v1",
    ]))
    .digest("hex");

  if (!facts.has(key)) {
    facts.set(key, { customerId: event.customerId });
  }
}

const event = {
  tenantId: "demo",
  source: "ticket",
  logicalId: "ticket-42",
  customerId: "customer-7",
};
derive(event);
derive(event); // 模拟去重标记过期后的再次派生
if (facts.size !== 1) throw new Error("重放产生了重复事实");

最容易翻车的是 logicalId 的选择，粒度太粗会吞掉合法的新事实，粒度太细又挡不住重复，更新语义也要单独设计。

错误解释听起来很合理，验证顺序却错了。

总结

我会先花半天跑几个有明确验收条件的小任务，看看失败记录和账单，再决定下一笔工具预算。

AI雷达日报

今日看点

一、AI 编程模型排名更高，为什么不一定适合你的仓库？

二、LLM 调用怎么省钱，缓存为什么不能只看问题文本？

三、Agent 能持续跑几天，业务流程就能放心托管吗？

四、React 设计系统支持 MCP，能让 AI 少写多少错误组件？

五、AI Agent 安全该先防什么，密钥和工具权限够不够？

六、Agent 返回成功，怎么发现重复写入和错误排查？

总结

参考

AI雷达日报

今日看点

一、AI 编程模型排名更高，为什么不一定适合你的仓库？

二、LLM 调用怎么省钱，缓存为什么不能只看问题文本？

三、Agent 能持续跑几天，业务流程就能放心托管吗？

四、React 设计系统支持 MCP，能让 AI 少写多少错误组件？

五、AI Agent 安全该先防什么，密钥和工具权限够不够？

六、Agent 返回成功，怎么发现重复写入和错误排查？

总结

参考