一年之内，模型失败率大幅压低
最近，Anthropic 团队研究产品经理 Theodora（Theo）Chu 的一段演讲视频引发关注。Theo 表示，如今越来越多开发者在日常工作中切实感受到 Claude 带来的效率提升，有人认为效率翻倍，也有人觉得提升了 10 倍。更关键的是，Claude 已深入 Anthropic 自身工程流程，“Anthropic 内部超过 80% 的代码由 Claude 合并”，这意味着模型角色正在转变，不再仅停留在回答问题阶段，而是在可反馈、验证、修正的环境里持续完成任务，即“Close the Loop（闭合循环），给模型一种验证自身输出结果的方式”。
在这场分享中，Theo 想告诉开发者“应如何适应这个新世界，又该如何面向未来构建产品，而非只为过去构建产品”。为此，她详细拆解了如何构建能够自我改进的 Agent，“真正的配置，是让 Claude 在循环、计划模式和动态工作流中持续运行”，网友 rari@0xwhrrari 认为“这要比大多数 300 美元的 Agent 课程都要好”。
Theo 以编程评估基准 SWE - bench Verified 为例，它由一系列 GitHub issue 组成，模型需理解问题、修改代码并通过测试证明解决任务，这是 Anthropic 内部观察 Claude 编程能力提升的重要评测。一年前的 Sonnet 3.7 得分约 60%，到了 Opus 4.8，得分达 88%，这意味着一年前模型在这些任务上的失败次数约是现在的 3 倍。
演讲中值得注意的是，模型能力提升并非“多做对几道题”，而是失败率快速下降。失败率下降后，模型才可能承担更长、更复杂、更接近真实工作的任务。此外，在最新的 Mythos 和 Fable 系列模型中，该基准测试已接近饱和，即过去难的测试如今可能无法有效区分模型能力。这对开发者是重要信号，若用 12 个月前的任务测试现在的模型，易低估其能力边界。
新模型智能增长的三个核心领域
一是先规划，再行动
Theo 展示同一任务在两个不同模型上的表现：让模型一次性重建 Claude.ai 网站。旧模型典型做法是上来就写大量代码、调用大量工具，缺乏充分规划，结果界面看似合理但运行不完整、功能无法闭环，“有点像我装宜家家具时的样子：一上来就动手，根本不看说明书，先开始拼，拼着拼着发现做错了，然后才意识到自己应该回去看说明书”。
而以 Opus 4.8 为代表的新模型具备自适应思考能力，会先在内部深思具体规范，预先规划时及时捕捉错误（甚至会在逻辑推理中输出“实际上……”或“算了，还是……”等自我修正词）。这种先规划后行动的方式，让模型首次执行就能高效落地，大幅减少不必要的工具调用与代码行数。所以，Theo 建议开发者允许模型先思考，产品体验也应为思考留空间，如使用自适应思考，让模型自行判断思考时机和时长，简单问题无需大动干戈，复杂任务则给予足够规划空间。
二是错误恢复和自我纠正
过去很多人做 Agent 重点在“让模型能调用更多工具”，但 Theo 强调工具调用不够，模型必须知道自己何时做错。旧模型常见问题是 doom looping，接到任务失败后，即便得到反馈提示换方式做，再次尝试时往往还会回到原解法，不会真正改变做法。
新模型在这方面进步明显，能读取反馈、理解失败原因并尝试不同路径，开始具备错误恢复能力，这对 Agent 产品尤为关键。因为任务足够长时，模型必然会遇到错误，真正有价值的 Agent 不是不犯错，而是犯错后能恢复。所以，Theo 认为开发者需重新设计模型所处环境，让环境能给模型反馈，“这也意味着，模型不会因为 doom looping 而浪费 token，而是可以用更少的 token 完成任务”。例如做应用生成 Agent，应让其访问前端界面，自己点击、测试、判断按钮可用性和页面是否正常，模型拿到验证信号才可能形成“执行 → 验证 → 修正 → 再执行”，这也是网友 rari@0xwhrrari 认为重要的“close the agent loop（闭环智能体循环）”。
三是模型越来越擅长在更长任务周期上运行
旧模型在长任务中常“跟丢主线”，用户给长任务，它做着做着就忘了最初目标，或执行到一半遗忘最初上下文或核心指令。现在，模型在长程任务的上下文连贯性上有显著突破，能将注意力稳定维持在 100 万个 Token 甚至更高级别，这意味着开发者无需把上下文窗口切得很碎，可直接将整个代码库交给模型。
未来更合理的方式是把更完整的任务交给模型，如给整个代码库而非单个文件，给完整产品需求而非孤立函数，让其跑完整流程而非局部步骤。当规划能力、错误恢复能力和长上下文能力叠加，Agent 形态会改变，它可先规划再执行，执行后通过工具或人类反馈验证结果，发现问题就调整计划继续执行，循环直至完成任务。
开发者该如何为未来进行构建？
随着模型越来越智能，用户可让其运行更长时间，且完成任务的效率和效果更好。那么，从战术上讲，用户应如何为“未来”构建产品，即如何为更强的模型构建产品？Theo 认为开发者在产品与工程层面需全面升级研发战术：
一是主动保持野心，动态刷新评估基准（Evals）
首先，要大胆尝试，让 Claude 处理更多事情，不要总测试 12 个月前它就能完成的任务，而应思考它现在还做不到的任务并持续关注。另外，模型快速进步后，开发者易误判新模型没明显提升，其实原因可能不在模型，而在 Evals。Theo 提到，有些客户新模型发布后称“Evals 只提升了 1%，所以这个模型好像没强多少”，但实际使用发现新模型某些能力提升明显，只是原 Evals 未测到。这说明 Evals 会过时，AI 时代，Evals 类似单元测试，能帮助开发者判断模型能力，也能助产品团队追踪模型变化对用户体验的影响。好的 Eval 不应只测试模型已会做的事，还应包含其未完全解决但未来用户体验需要的任务，即 Evals 要面向未来设计，将用户报告的最新失败模式和应用未来发展方向融入测试用例，若遗留问题不可解，应立刻更新更难的题目。
二是精简“脚手架”（Shrink the Scaffolding）
Theo 反复强调要“shrink your scaffolding”，缩小模型周围的“脚手架”。所谓“脚手架”，是工程实践中开发者为修补旧模型漏洞，在其周围设置的系统提示词、外部工具、代码 Harness 及各种约束和补丁。比如模型引用格式错了加规则，没遵守要求写约束，调用工具失败加更多逻辑等。这些补丁在旧模型时代有用，但新模型指令遵循能力变强后，旧补丁可能成问题。Theo 举 Anthropic 自身例子，团队曾以为新模型在 Claude.ai 引用功能上有 Bug，检查发现是新模型遵循指令能力大幅提升，执行了系统提示词里过时的引用格式指令，删掉该提示词功能就恢复正常。这说明开发者应“针对意图”编写简洁提示词，明确最终结果，而非围绕老模型失败经验过度包装，给模型松绑，精简“脚手架”，才能看清其真正天花板。
三是闭环设计，让模型验证自身的输出结果
模型完成更复杂任务，仅有思考能力不够，还需动作能力，这是构建自改进 Agent 最核心的底层逻辑。既然模型有极强的错误恢复能力，就必须在工程上“闭环智能体循环”（Close the Agent Loop）：
- 给模型留出思考与工作的空间：引入自适应思考机制，产品设计上允许模型前端思考，甚至通过投入度拨盘（Effort Dial）让模型自由上调或下调在复杂问题上的钻研程度。
- 以受控的方式开放高权限：发挥 Agent 自主性需赋予其在环境里行动的权限，Anthropic 在 Claude Code 中推出“自动模式”分类器，能在“开发者的控制欲”与“模型的自主权”间找到平衡，自动甄别安全可取的行动，防止模型误删环境。
- 提供自我质检的工具：为 Agent 配备“Computer Use”等自动化验证工具，让智能体在前端进行质检，通过环境真实反馈发现自身错误，实现代码自我迭代与修正。
