AI Agent每步95%准确最终成功率仅36%

过去一天的 AI 热点释放出一个很明确的信号：模型能力仍在快速上升，但生产系统的竞争焦点已经从“生成得多快”转向“能否可靠完成、能否安全执行、能否被验证”。AI 编程把写代码压缩到交付周期的 7%，Agent 却可能在长链路中把 95% 的单步准确率放大成 64% 的任务失败率。对程序员和技术管理者来说，今天最有价值的工作不是再接入一个模型，而是补齐幂等、评估、权限、容错和质量门禁。

今日主线

今天的素材可以归纳为三条主线。

第一，Agent 已经开始触碰支付、数据库和物理设备，可靠性问题因此从“回答得不好”升级为“造成不可逆副作用”。支付重复执行、敏感数据导出、错误设备指令，都不能靠一句更强的 system prompt 解决。系统必须在模型与真实世界之间建立可强制执行的边界。

第二，AI 编程的主要瓶颈正在向下游迁移。代码生成只占完整交付周期的一小部分，测试、审查、安全检查和发布审批才是主要耗时。继续只优化补全速度，团队得到的很可能不是更高吞吐，而是更大的待验证代码面积。

第三，模型规模、上下文窗口和一键生成能力继续膨胀，但“参数更多、上下文更长、原型更快”不等于“生产价值更高”。腾讯 Hy4 的百万 token 上下文很有工程想象力，OpenAI Astra 的游戏生成演示也足够吸睛；然而真正决定上线结果的，仍是评估体系、运行时护栏、工具可靠性和成本约束。

这三条主线共同指向一个判断：2026 年下半年的 AI 工程，核心资产不只是模型，而是包裹模型的执行系统。

AI 编程与工程实践

从“模型是否聪明”转向“任务是否完成”

Agent 评估最容易踩的坑，是把局部正确当成整体可靠。

假设一个 Agent 每一步的独立成功率是 95%，完成 20 步任务的理论成功率只有约 36%。这个计算不能精确描述真实系统，因为步骤之间并不独立，Agent 也可能重试和自我修正；但它准确揭示了长链路的风险方向：步骤越多，任何一个微小错误都可能污染后续状态。AI Agent 评估：每步 95% 准确率为何仍不及格

另一个信号来自 Agent 对自身能力的判断。相关研究显示，Claude Code 和 Codex 不仅会明显高估任务耗时，旧模型对自己的任务得分也可能高估约 20 个百分点；个别案例里，Agent 自认为有约 70% 的成功率，实际得分却只有 7% 和 14.5%。同一模型在不同运行外壳中的步数和运行时间也会显著变化，说明结果不能简单归因于基础模型。The Decoder：AI Agent 缺乏可靠的时间感知

工程影响很直接：不能把“模型说完成了”“工具调用没有报错”或“十五次演示都成功”当作上线依据。Agent 的验收对象应当是最终环境状态。例如，让 Agent 修改数据库后，评估器应检查目标记录、权限边界和关联约束，而不是只检查它是否调用了正确的 SQL 工具。

更可行的评估方式包括：

用结果断言代替轨迹崇拜。允许 Agent 走不同路径，只要最终状态满足要求。
记录端到端成功率、部分完成率和静默失败率，不只记录单步工具准确率。
对同一任务运行多次，观察 pass@k、方差和失败模式，而不是迷信单次最佳结果。
将超时、工具返回空值、权限不足、上下文过期和中途恢复纳入测试集。
用外部验证器评分，避免让执行任务的 Agent 同时担任最终裁判。

这里也有边界：某些高风险流程不仅关心结果，还必须关心路径。例如支付、医疗和合规操作即使最终状态正确，未经授权的数据访问或中间操作仍不可接受。因此，结果评估不能取代审计，只能取代“模型自称成功”这种弱证据。

Exactly-once 不是装饰，而是 Agent 执行副作用的底线

当 Agent 只生成文字时，重试通常是安全的；当它开始支付、发邮件或提交交易时，重试可能制造第二次真实操作。

exactly-once Python 库给出的方案，是按业务 key 包裹副作用：第一次调用先原子地把 key 从 FRESH 声明为 IN_FLIGHT，执行成功后再提交为 COMMITTED 并保存结果。后续相同 key 的调用不再重复执行，而是回放已保存的结果。exactly-once：Agent 不应支付同一张发票两次

真正棘手的是“支付提供商已经成功，但本地尚未记录结果时进程崩溃”。单靠数据库状态无法判断外部副作用是否完成，所以库不会擅自重试，而是隔离仍处于 IN_FLIGHT 的记录，再通过支付提供商的幂等键查询结果。这个设计比“失败后重试三次”成熟得多：未知不是失败，未知必须进入待裁决状态。

同一方向的另一个证据，是生产 Agent 对不稳定 API 的防御需求。外部工具会返回 429、500、504，也会超时或暂时不可用。如果原始工具调用直接嵌进推理循环，一个异常就可能让整个多步任务丢失。指数退避、熔断和优雅降级能提高存活率，但它们必须与副作用语义配合：读取请求通常可以安全重试，支付和写数据库则需要幂等键或补偿机制。防止不稳定 API 导致 Agent 崩溃

工程上应先给工具分级：

纯读取：允许带抖动的指数退避，并设置最大重试预算。
幂等写入：使用稳定业务 key，验证重复调用返回相同结果。
非幂等写入：默认禁止自动重试，增加人工确认、状态探测或补偿事务。
不可逆操作：执行前验证授权，执行后使用外部事实源核验结果。

需要澄清的是，所谓 exactly-once 通常依赖具体存储和外部服务提供的幂等能力。跨数据库、消息系统和第三方支付平台的全局“严格一次”不是一个装饰器就能自动获得。应该验证的是业务可观察结果是否只发生一次，而不是只看本地状态机是否走到了 COMMITTED。

Agent 安全应落在工具层，而不是 prompt 层

今天多条素材都在重复同一个工程事实：提示词是建议，权限系统才是边界。

Need-to-Know 的做法很朴素：如果 Agent 不应该导出客户邮箱，就不要向它暴露导出原始数据的工具。这样即使遭遇 prompt 注入，模型也没有可调用的泄露路径。Need-to-Know：让数据泄露在能力层面不可实现

PES“人格—执行分离”架构则把这个思路扩展为两个信任域。Persona 可以演化语气、指令和交互风格；执行侧保存稳定身份、审批矩阵、状态与审计记录，并独立验证每个动作。Persona 提供的上下文只用于审计，不能直接作为授权依据。PES：受治理 Agent 为什么需要两个信任域

Agent harness 的讨论也得出相似结论：真正的生产能力来自上下文管理、工具可靠性、输出检查和错误恢复，而不是让模型裸奔在工具列表前面。The New Stack：构建 AI Agent Harness

三者形成了一条完整链路：

信号是 Agent 获得了越来越多现实权限；证据是最小工具暴露、双信任域和运行时外壳都在解决同一类问题；工程影响是授权逻辑必须从 prompt 中迁出；行动则是把每个工具改造成具有身份、作用域、预算、审计和确认策略的受控能力。

可验证指标不应是“红队 prompt 被拒绝了多少次”，而应是“即使模型被完全诱导，是否仍不存在越权调用路径”。前者测试模型服从性，后者测试系统安全性。

AI 写代码更快，为什么交付没有同比提速

一项真实功能开发周期的测量显示，AI 辅助代码生成只占总时间的 7%；代码审查占 16%，返工占 14%，测试占 24%，安全检查占 12%，部署验证占 11%，发布审批占 16%。即使把代码生成时间再砍一半，对整体周期的改善也很有限。AI 生成代码只占 7%：瓶颈已经转移

VibeGuard 从另一个侧面解释了下游为什么变慢。它针对 AI 生成代码常见模式检查 SQL 注入、硬编码密钥、JWT 算法缺失、shell=True、MD5 密码哈希和生产环境调试开关。作者报告称，在一个 533 文件的项目中发现了三个现有安全流水线遗漏的严重问题。VibeGuard：面向 AI 生成代码的安全 Linter

这并不能证明 AI 代码普遍比人工代码更不安全，因为素材中的样本量、项目背景和基线对比都有限；但它足以形成一个待验证假设：生成速度提高后，未经验证的代码面积增长得比审查能力更快。

因此，AI 代码审查不该只是在 PR 下留一条“看起来可能有问题”的评论。更成熟的方向是把它放到 pre-commit、pre-push 或 CI 中，与 linter、测试和安全扫描并列成为质量门禁。AI 代码审查应成为质量门禁

不过，概率性门禁不能直接复制确定性测试的规则。误报率过高会让开发者绕过检查，模型版本漂移也可能让相同提交得到不同结论。合理做法是先让 AI 审查运行在只报告模式，统计误报、漏报和重复运行一致性；只有对高置信度、可复现且有明确修复路径的规则，才升级为阻断门禁。

AI 办公与生产力

今天没有传统意义上的文档、会议或表格类 AI 办公产品成为主角，但 Agent 工程的变化正在重新定义研发团队的“办公提效”：从替人写内容，转向替团队读取真实上下文、执行受控操作和完成跨系统流程。

一个典型问题是前端开发中的 API 上下文过期。让编码 Agent 阅读后端源码成本高，把整个 OpenAPI 文档塞进上下文又浪费 token，而上周导出的 swagger.json 很可能已经失效。docs-mcpserver 从运行中的服务获取 OpenAPI 规范并缓存，再按需向 Agent 暴露单个路由定义；服务关闭后仍可使用最近一次有效副本。让 AI 编程助手读取运行中服务的 API 文档

数据库优化也展示了相同模式。有人把 PostgreSQL 慢查询、现有索引和表结构交给模型生成索引建议，再通过 EXPLAIN (ANALYZE, BUFFERS) 在 staging 环境验证。模型有时能提出有效的部分索引，也会虚构已删除的表、推荐重复索引或忽略现有结构。用免费模型做 PostgreSQL 索引审查 48 小时

两条证据共同说明，AI 办公提效的有效公式不是“让模型替我判断”，而是“给模型实时、最小且可验证的上下文，让它生成候选方案，再由确定性工具验收”。

对前端工程师，这意味着用实时 API schema 生成调用代码后，还要跑契约测试；对数据库工程师，意味着模型可以提出索引候选，但不能绕过执行计划、写放大和存储成本验证；对技术管理者，意味着生产力指标应统计从需求到验证通过的周期，而不是统计生成了多少代码或节省了多少键盘输入。

Agentic RAG 也服务于这一方向。标准 RAG 在设计时固定一次 embedding 和一次 top-k 检索，适合单文档、低延迟问题；复杂问题可能需要政策文档、费率表、事务聚合和过滤后重算，此时检索次数和数据源应由运行时 planner 决定。标准 RAG 与 Agentic RAG

但 Agentic RAG 不是默认升级项。它会增加模型调用、延迟、成本和不可预测性。单跳知识库问答仍应优先使用标准 RAG；只有当评测集证明失败主要来自多跳检索或跨源计算时，才值得引入 planner、memory 和动态工具选择。

值得关注的产品与行业变化

模型侧最明确的已发生事实，是腾讯发布 Hy4 Preview：总参数 770B、激活参数 49B、上下文窗口 100 万 token，权重体积约 1.56TB，并提供 high 与 no_think 两种推理模式。相比此前 Hy3 的 295B 总参数、21B 激活参数和 256K 上下文，规模提升显著。Simon Willison：Hy4 Preview

百万上下文对大型代码库分析、长文档和长时 Agent 轨迹有潜在价值，但不能直接等价为“无需 RAG”。需要验证的指标包括长上下文中间位置召回率、输入成本、首 token 延迟、吞吐量以及跨轮次事实保持能力。对于多数团队，1.56TB 的权重也意味着部署门槛依然很高。

OpenAI Astra 则属于待验证消息。报道声称该模型可能达到 10 万亿参数，并在一次对话中生成类似《GTA 2》的游戏、网站、3D 对象和体素环境；但截至素材时间，Astra 尚未被正式确认为 GPT-6，参数规模、发布时间和最终产品效果都没有得到正式确认。IT之家：Astra 疑似新一代 OpenAI 模型

编辑判断是：即使演示属实，它首先改变的是原型验证成本，而不是自动解决生产软件交付。单轮生成完整项目会同步扩大安全、测试、维护和架构审查压力，这与“代码生成只占交付周期 7%”的信号并不矛盾。

物理 AI 方向的 MHS 更值得工程团队长期关注。报道显示，Anthropic 发布 Model Hardware Standard 研究预览版，以 read、write 和 discovery 等原语标准化设备驱动，并通过 Driver Tag 表达重量、安全限制等无法仅靠接口签名承载的知识。合作方案例中，QuEra 的激光重锁定成功率据称从约 58% 提升至 99.3%，卡内基梅隆也把原本可能耗时数周的设备集成压缩到约 8 小时。MarkTechPost：Anthropic MHS 研究预览

这些数据来自研究预览和合作案例，尚不能推导出跨设备、跨厂商的普遍效果。真正需要验证的是故障安全、权限隔离、实时性、驱动一致性以及设备失联后的行为。不过方向已经很清楚：MCP 解决模型如何接入数字工具之后，类似 MHS 的规范正尝试定义 Agent 如何安全接触物理世界。

行业层面还应关注 Claude Code 用量变化。报道显示，当前临时提高 50% 的额度将在 9 月 14 日到期，之后相对原基线永久增加 25%；与当前可用量相比，相当于约下降 17%。这会直接影响重度用户的成本与并发规划。The Decoder：Claude Code 用量上限变化

技术选型因此不应只比较模型榜单，还要记录每个已完成任务的 token、运行时长、重试次数和人工接管成本。额度政策一变，真实单位经济性也会跟着变化。

程序员今天可以做什么

下面六项都可以在小范围独立验证，不需要先重构整套系统。

给副作用接口增加业务幂等键

适用对象：支付、发邮件、创建工单、提交订单的 Agent。预期收益是消除重试与恢复导致的重复执行。主要风险是把请求 ID 误当业务 ID，导致同一业务动作仍可生成多个 key。验证指标：连续调用、并发调用和崩溃恢复后，外部系统只出现一条业务记录；所有 IN_FLIGHT 状态都有可查询、可裁决的去向。
建立 20—50 条端到端 Agent 任务集

适用对象：已经上线或准备上线工具调用 Agent 的团队。预期收益是发现单步测试覆盖不到的长链路失败。风险是测试集过于接近演示路径。验证指标：端到端成功率、静默失败率、人工接管率、pass@3，以及版本升级前后的失败类型变化。
把高风险工具从通用工具箱中拆出

适用对象：能访问客户数据、生产数据库或部署系统的 Agent。预期收益是降低 prompt 注入和误操作的影响半径。风险是权限拆得太细导致流程不可用。验证指标：在模型完全不可信的假设下，越权操作是否仍无法通过执行侧；每个写操作是否具备稳定身份、作用域和审计记录。
为所有外部 API 增加统一防御层

适用对象：依赖搜索、抓取、数据库和第三方 SaaS 的多步 Agent。预期收益是减少单个 429 或 504 导致的整条任务失败。风险是盲目重试非幂等操作，以及重试风暴。验证指标：注入超时、限流和 5xx 后的任务存活率；最大重试次数；熔断开启时间；降级结果是否明确标注不完整。
让 AI 审查先以影子门禁运行两周

适用对象：AI 生成代码占比上升的前端和全栈团队。预期收益是识别现有 linter、测试和 SAST 未覆盖的模式。风险是误报造成审查疲劳。验证指标：重复运行一致性、有效问题比例、误报率、平均修复时间，以及哪些规则具备升级为阻断门禁的条件。
把模型建议绑定到确定性验收命令

适用对象：API 对接、数据库调优和代码现代化任务。预期收益是让 AI 办公提效从“生成建议”变成“交付可验证候选”。风险是验证环境与生产环境差异过大。验证指标：前端接口改动通过契约测试；索引建议通过 EXPLAIN (ANALYZE, BUFFERS)；迁移代码通过编译、测试和回滚演练。

趋势判断

已发生的事实是：开源模型正在向百万上下文和更大 MoE 规模推进；Agent 开始接触支付、生产数据和物理设备；AI 编程工具已经把代码生成速度推到不再是主要瓶颈的位置。

编辑判断是：未来一段时间，AI 工程团队的差距不会主要来自“谁先接入最新模型”，而会来自四项基础能力——端到端评估、受控工具执行、可恢复状态管理和自动化质量门禁。模型可以替换，执行账本、权限模型、评测集和故障数据却会持续积累，后者才更接近组织资产。

待验证的假设是：百万上下文会降低部分 RAG 复杂度，Agentic RAG 会改善复杂多跳任务，MHS 会缩短跨厂商硬件集成时间，Astra 一类模型会显著降低交互式原型成本。这些方向都有强信号，但都需要在真实任务上用成功率、延迟、成本、恢复能力和人工接管率验证。

对程序员来说，最实用的结论可以压缩成一句话：让 AI 生成候选，让系统约束权限，让确定性工具验收结果，让失败能够被恢复和追责。

AI雷达日报

今日看点