WEBVTT
Kind: captions
Language: zh

00:00:00.166 --> 00:00:03.666
Anthropic刚刚发布了一款更强的Claude

00:00:03.933 --> 00:00:06.000
但这一次最值得追问的

00:00:06.166 --> 00:00:08.666
可能不是它又赢了多少项测试

00:00:08.866 --> 00:00:10.100
真正的问题是

00:00:10.400 --> 00:00:12.000
为什么一家刚刚公开呼吁

00:00:12.000 --> 00:00:14.200
前沿AI放慢脚步的公司

00:00:14.400 --> 00:00:17.466
转身就拿出了一款更快更便宜

00:00:17.566 --> 00:00:20.266
也更适合长期自主工作的模型

00:00:20.366 --> 00:00:23.100
答案藏在一个越来越危险的变化里

00:00:23.900 --> 00:00:25.100
Aibench四点公司已经不

00:00:25.100 --> 00:00:27.333
满足于让模型回答问题

00:00:27.900 --> 00:00:29.866
他们正在让模型接管数

00:00:29.866 --> 00:00:31.766
小时甚至数天的工作

00:00:31.800 --> 00:00:32.966
到了这个阶段

00:00:33.066 --> 00:00:34.500
能力只是入场券

00:00:34.700 --> 00:00:37.300
谁能让模型持续工作而不失控

00:00:37.400 --> 00:00:39.600
谁才可能拿走下一轮市场

00:00:39.900 --> 00:00:41.666
2026年9月22日

00:00:41.766 --> 00:00:44.933
Anthropic正式发布Claude Opus 5.5

00:00:45.133 --> 00:00:47.966
这是Claude 5.5家族的第一款模型

00:00:48.266 --> 00:00:52.100
sonnet 5.5和Haiku 5.5会在随后几周跟进

00:00:52.200 --> 00:00:53.533
按照官方定位

00:00:53.766 --> 00:00:55.866
Opus 5.5在多数工作中

00:00:55.866 --> 00:00:58.066
的表现接近fable 5.1

00:00:58.466 --> 00:01:02.533
典型任务成本却比上一代Opus5低约40%

00:01:02.766 --> 00:01:06.700
它的API输入价格是每百万TOKEN4美元

00:01:06.700 --> 00:01:07.933
输出20美元

00:01:08.066 --> 00:01:10.533
分别比Opus5低20%

00:01:11.466 --> 00:01:14.966
缓存读取价格降到每百万TOKEN0.2美元

00:01:15.166 --> 00:01:17.166
比上一代低60%

00:01:17.366 --> 00:01:20.200
输出速度则提高超过30%

00:01:20.300 --> 00:01:21.866
这些数字放在一起

00:01:22.066 --> 00:01:24.333
透露出Anthropic的真正目标

00:01:24.566 --> 00:01:26.866
Opus5.5并不是一款单纯

00:01:26.866 --> 00:01:29.133
冲击最高跑分的昂贵旗舰

00:01:29.600 --> 00:01:31.600
他要把高端模型从偶尔

00:01:31.600 --> 00:01:33.366
调用的专家变成可以

00:01:33.366 --> 00:01:35.933
长时间待在项目里的执行系统

00:01:36.133 --> 00:01:38.766
单个TOKEN降价只能带来有限变化

00:01:39.200 --> 00:01:40.466
模型少走弯路

00:01:40.466 --> 00:01:42.000
少重复读取代码

00:01:42.000 --> 00:01:43.566
少输出无用解释

00:01:43.700 --> 00:01:45.466
才会让一个持续10小时

00:01:45.466 --> 00:01:47.266
的任务真正便宜下来

00:01:47.400 --> 00:01:49.533
Anthropic给出的案例很直接

00:01:50.000 --> 00:01:53.100
一名早期测试者让Opus5.5处理

00:01:53.100 --> 00:01:55.866
一个68万行代码的迁移项目

00:01:55.866 --> 00:01:57.533
不到一天就完成了

00:01:57.600 --> 00:01:58.966
按照对方估算

00:01:59.066 --> 00:02:00.666
同样的工作交给工程

00:02:00.666 --> 00:02:02.733
团队可能需要数周

00:02:02.866 --> 00:02:04.466
另一个20万行代码库

00:02:04.466 --> 00:02:06.000
的审计与修复任务

00:02:06.600 --> 00:02:09.133
Opus5.5不到3小时完成

00:02:09.666 --> 00:02:11.733
Opus5用了超过20小时

00:02:11.766 --> 00:02:14.466
TOKEN消耗还是前者的2.5倍

00:02:14.566 --> 00:02:16.133
这里最关键的变化

00:02:16.600 --> 00:02:19.100
是他在大范围代码中定位问题

00:02:19.400 --> 00:02:21.100
保留上下文和连续

00:02:21.100 --> 00:02:23.133
推进任务的效率提高了

00:02:23.666 --> 00:02:26.266
单纯的打字速度无法解释这种差距

00:02:26.466 --> 00:02:29.866
Anthropic还让Opus 5.5和fable 5.1把

00:02:29.866 --> 00:02:32.666
HA proxy从c语言迁移到rust

00:02:33.266 --> 00:02:34.600
HA proxy不是一个适合

00:02:34.600 --> 00:02:36.200
拿来表演的玩具项目

00:02:36.266 --> 00:02:37.800
它是被大量生产系统

00:02:37.800 --> 00:02:39.566
使用的负载均衡软件

00:02:39.666 --> 00:02:41.500
两个模型生成的版本都

00:02:41.500 --> 00:02:43.800
通过了接近全部的回归测试

00:02:44.200 --> 00:02:46.866
Opus 5.5耗时9.5小时

00:02:47.166 --> 00:02:49.366
fable 5.1用了12小时

00:02:49.733 --> 00:02:52.066
前者成本低51%

00:02:52.066 --> 00:02:53.500
这组结果更接近

00:02:53.500 --> 00:02:55.200
企业真正关心的问题

00:02:55.566 --> 00:02:57.133
模型不只要生成一段

00:02:57.133 --> 00:02:58.733
看起来合理的代码

00:02:58.800 --> 00:03:01.733
还要让整个项目能编译能测试

00:03:01.900 --> 00:03:04.466
并且在长任务中维持一致性

00:03:04.566 --> 00:03:06.266
跑分也支持这个方向

00:03:06.900 --> 00:03:11.600
OPPOS5.5在Terminalbench4.0得到66.4%

00:03:11.800 --> 00:03:15.700
在frontiercode主测试得到54.4%

00:03:16.166 --> 00:03:19.333
cursorbench4.0为57.8%

00:03:19.500 --> 00:03:22.533
GDP VL AA知识工作测试中

00:03:22.533 --> 00:03:24.600
它拿到1,846分

00:03:24.933 --> 00:03:28.900
带工具的humanities last exam是67.7%

00:03:29.333 --> 00:03:31.533
Automation bench为40%

00:03:31.600 --> 00:03:34.600
其中Frontier code不只检查答案对不对

00:03:34.600 --> 00:03:36.966
还看修改范围是否克制

00:03:37.266 --> 00:03:38.700
测试是否完善

00:03:38.966 --> 00:03:41.566
代码风格能不能被项目接受

00:03:41.800 --> 00:03:45.000
Anthropic称Opus 5.5

00:03:45.200 --> 00:03:46.933
在默认推理强度下

00:03:46.933 --> 00:03:50.400
以大约GPT6Astra1/5的任务成本

00:03:50.500 --> 00:03:52.600
取得略高的Frontier code成绩

00:03:52.700 --> 00:03:54.266
但排行榜不能直接

00:03:54.266 --> 00:03:56.366
变成全面领先的结论

00:03:56.600 --> 00:03:58.000
Terminal bench中

00:03:58.000 --> 00:03:59.533
不同模型使用的推理

00:03:59.533 --> 00:04:01.366
强度并不完全相同

00:04:01.733 --> 00:04:04.366
部分沉积来自厂商自己的运行环境

00:04:04.566 --> 00:04:06.166
安全系统介入时

00:04:06.366 --> 00:04:09.600
某些网络安全任务会转给Opus4.8

00:04:09.700 --> 00:04:11.266
生物学和前沿模型

00:04:11.266 --> 00:04:13.400
开发任务会转给Opus5

00:04:13.566 --> 00:04:16.566
Anthropic也在发布页面主动提醒

00:04:17.100 --> 00:04:19.333
模型能力到了这个水平以后

00:04:19.333 --> 00:04:21.300
几分的基准差距越来越

00:04:21.300 --> 00:04:23.466
难代表真实使用差距

00:04:23.766 --> 00:04:25.400
公司内部使用时

00:04:25.533 --> 00:04:28.866
Opus5.5和fable 5.1之间的差别

00:04:29.200 --> 00:04:31.266
没有表格显示的那么夸张

00:04:31.366 --> 00:04:33.066
这句提醒很重要

00:04:33.266 --> 00:04:36.266
AI模型发布已经进入一个奇怪阶段

00:04:36.366 --> 00:04:37.766
每家公司都能找到

00:04:37.766 --> 00:04:39.533
一张自己领先的表格

00:04:40.166 --> 00:04:42.066
测试设置工具权限和

00:04:42.066 --> 00:04:43.733
推理预算稍微变化

00:04:43.866 --> 00:04:45.333
名次就可能改变

00:04:45.566 --> 00:04:48.466
真正稳定的优势必须在成本

00:04:48.500 --> 00:04:51.300
完成率和返工次数上同时出现

00:04:51.466 --> 00:04:53.966
Opus 5.5用更少TOKEN完成

00:04:53.966 --> 00:04:55.366
更长任务的趋势

00:04:55.800 --> 00:04:57.900
比某一项冠军更有说服力

00:04:58.000 --> 00:05:00.066
企业采用代理式AI时

00:05:00.100 --> 00:05:02.900
真正昂贵的从来不只是API账单

00:05:03.166 --> 00:05:04.966
模型改错一处代码

00:05:05.066 --> 00:05:06.800
人类要花时间寻找

00:05:07.166 --> 00:05:08.966
模型漏掉一个边界条件

00:05:09.166 --> 00:05:11.133
测试团队要重新验证

00:05:11.400 --> 00:05:14.200
模型在长任务中忘记最初要求

00:05:14.366 --> 00:05:16.966
前面几小时的计算都可能作废

00:05:17.133 --> 00:05:19.466
一次失败会把审查回滚

00:05:19.466 --> 00:05:21.533
和沟通成本全部拉进来

00:05:22.100 --> 00:05:25.733
Opus5.5试图降低的就是这种隐藏成本

00:05:25.800 --> 00:05:27.333
早期客户给出的反馈

00:05:27.333 --> 00:05:28.700
集中在同一个方向

00:05:29.133 --> 00:05:30.200
Lovable发现

00:05:30.300 --> 00:05:32.600
新模型获取一次上下文后

00:05:32.666 --> 00:05:34.666
能够做出更完整的修改

00:05:34.700 --> 00:05:36.400
较少陷入反复尝试

00:05:36.700 --> 00:05:39.900
完成任务的步骤减少约1/3到一半

00:05:40.100 --> 00:05:42.866
Quantum测试的一项复杂编程工作

00:05:43.333 --> 00:05:45.166
过去需要38轮提示

00:05:45.533 --> 00:05:46.700
持续4天

00:05:47.000 --> 00:05:50.800
Opus 5.5缩短到11轮提示和3个小时

00:05:51.066 --> 00:05:52.300
factory则表示

00:05:52.666 --> 00:05:54.933
中等推理强度的Opus5.5

00:05:54.966 --> 00:05:57.200
能够接近高强度Opus5

00:05:57.300 --> 00:06:01.066
同时少用20%到25%的输出TOKEN

00:06:01.400 --> 00:06:02.933
这些反馈尚不能当成

00:06:02.933 --> 00:06:04.600
独立的大规模研究

00:06:05.000 --> 00:06:07.100
它们来自发布前测试者

00:06:07.200 --> 00:06:09.666
也由Anthropic选择并展示

00:06:09.933 --> 00:06:11.933
天然会偏向成功案例

00:06:12.100 --> 00:06:13.500
但它们仍然指出了

00:06:13.500 --> 00:06:15.166
一个合理的产品方向

00:06:15.366 --> 00:06:18.166
模型价值开始从这一次答的多聪明

00:06:18.300 --> 00:06:20.466
转向为了拿到可用结果

00:06:20.800 --> 00:06:22.733
人需要纠正它多少次

00:06:22.766 --> 00:06:25.733
如果一款模型价格低20%

00:06:25.733 --> 00:06:27.500
却需要多一倍返工

00:06:27.600 --> 00:06:28.800
它不会更便宜

00:06:28.966 --> 00:06:31.300
反过来价格变化不大

00:06:31.300 --> 00:06:32.933
但一次完成率提高

00:06:33.200 --> 00:06:35.633
企业的总成本可能大幅下降

00:06:35.766 --> 00:06:39.400
Opus5.5还把表达方式列为正式升级

00:06:39.533 --> 00:06:42.400
官方称它会更早给出重要信息

00:06:42.500 --> 00:06:45.066
减少术语和难以理解的绕行

00:06:45.700 --> 00:06:48.333
长任务中的说明也更容易检查

00:06:48.600 --> 00:06:50.400
box的测试结果显示

00:06:50.666 --> 00:06:54.533
新模型使用的TOKEN约为Opus5的1/3

00:06:54.900 --> 00:06:57.000
回答长度减少40%

00:06:57.266 --> 00:06:59.133
准确性没有明显下降

00:06:59.400 --> 00:07:00.600
Ramp则表示

00:07:00.933 --> 00:07:02.766
它生成的设计规格经过

00:07:02.766 --> 00:07:04.900
很少修改就能投入使用

00:07:04.966 --> 00:07:07.166
这不是装饰性的文风优化

00:07:07.566 --> 00:07:10.066
一个只负责聊天的模型说的啰嗦

00:07:10.333 --> 00:07:12.000
最多让人失去耐心

00:07:12.133 --> 00:07:14.500
一个能修改数十万行代码

00:07:14.600 --> 00:07:16.533
调用工具并协调其他

00:07:16.533 --> 00:07:18.366
代理的模型说的含糊

00:07:18.666 --> 00:07:21.533
会让人无法确认它究竟做了什么

00:07:21.666 --> 00:07:22.966
模型越能行动

00:07:23.066 --> 00:07:25.466
解释成本越接近安全成本

00:07:25.500 --> 00:07:27.200
把关键判断提前

00:07:27.533 --> 00:07:29.600
把未检查的部分说清楚

00:07:29.800 --> 00:07:32.266
让审查者能迅速找到风险

00:07:32.400 --> 00:07:34.600
这些能力与跑分同样重要

00:07:34.966 --> 00:07:36.766
stripe的案例更能说明

00:07:36.766 --> 00:07:39.066
Opus5.5正在变成什么

00:07:39.333 --> 00:07:41.533
一次包含40个堆叠拉取

00:07:41.533 --> 00:07:43.533
请求的复杂变基任务中

00:07:43.566 --> 00:07:45.766
一个OPS 5.5会话负责

00:07:45.766 --> 00:07:47.600
调度10多个其他会话

00:07:47.933 --> 00:07:48.866
梳理冲突

00:07:48.966 --> 00:07:51.900
并把需要人类决定的问题整理出来

00:07:51.966 --> 00:07:53.100
第二天下午

00:07:53.133 --> 00:07:55.866
40个请求全部通过持续集成

00:07:56.200 --> 00:07:58.900
这已经超出传统代码助手的范围

00:07:59.133 --> 00:08:01.533
主会话承担的是项目管理

00:08:01.600 --> 00:08:03.933
上下文分发和质量检查

00:08:04.133 --> 00:08:06.733
其他会话像执行单元一样工作

00:08:06.866 --> 00:08:07.900
到了这一步

00:08:08.000 --> 00:08:09.600
AI代理的形态开始

00:08:09.600 --> 00:08:11.166
接近一个软件团队

00:08:11.466 --> 00:08:12.766
主代理拆任务

00:08:13.133 --> 00:08:16.766
子代理并行处理测试系统负责验收

00:08:16.900 --> 00:08:19.266
人类只在关键节点做决定

00:08:19.466 --> 00:08:21.166
效率提升很诱人

00:08:21.333 --> 00:08:22.933
风险也随之变化

00:08:23.100 --> 00:08:25.200
单个模型写错一行代码

00:08:25.333 --> 00:08:26.733
影响通常局部

00:08:27.166 --> 00:08:29.466
负责调度的模型理解错目标

00:08:29.666 --> 00:08:31.466
10多个执行会话可能

00:08:31.466 --> 00:08:33.600
沿着错误方向同时前进

00:08:33.700 --> 00:08:35.866
多代理让吞吐量增加

00:08:35.933 --> 00:08:38.266
也会放大上层判断的失误

00:08:38.366 --> 00:08:41.100
所以Anthropic这次把安全放到

00:08:41.100 --> 00:08:43.333
了和性能同等重要的位置

00:08:43.700 --> 00:08:46.800
Opus5.5是Dario Amodei呼吁为

00:08:46.800 --> 00:08:48.900
前沿能力设定节奏之后

00:08:48.900 --> 00:08:51.100
公司推出的第一款主要模型

00:08:51.333 --> 00:08:52.600
听起来有些矛盾

00:08:53.066 --> 00:08:54.566
一边要求行业放慢

00:08:54.700 --> 00:08:56.866
一边继续发布更强模型

00:08:57.100 --> 00:08:58.933
Anthropic所说的放慢

00:08:58.933 --> 00:09:02.100
是让安全能力跑在模型能力前面

00:09:02.133 --> 00:09:04.400
并为可能很快出现的更高级

00:09:04.400 --> 00:09:06.866
系统建立监管与评估基础

00:09:07.066 --> 00:09:08.533
研发仍会继续

00:09:08.666 --> 00:09:10.400
在接近2,000种模拟场景

00:09:10.400 --> 00:09:12.300
组成的自动行为审计中

00:09:12.700 --> 00:09:15.466
Opus5.5在近期Claude模型里

00:09:15.466 --> 00:09:17.200
取得了最好的综合结果

00:09:17.366 --> 00:09:19.600
它在诚实性测试上也更强

00:09:19.700 --> 00:09:21.666
一个专门测试模型是否会

00:09:21.666 --> 00:09:24.066
突破约束边界的评估显示

00:09:24.333 --> 00:09:26.700
Opus5.5尝试绕过限制的

00:09:26.700 --> 00:09:30.933
频率比Opus5和Mythos5.1低约85%

00:09:31.200 --> 00:09:33.900
它出现的尝试都属于低严重程度

00:09:34.200 --> 00:09:35.700
而且会主动报告

00:09:35.800 --> 00:09:37.366
这组数据直接对应

00:09:37.366 --> 00:09:39.766
长崎代理最令人担心的问题

00:09:40.266 --> 00:09:42.733
模型被允许在代码库浏览器

00:09:42.733 --> 00:09:45.133
和内部系统里连续工作时

00:09:45.266 --> 00:09:47.200
用户不可能盯住每一步

00:09:47.300 --> 00:09:49.966
它会不会为了完成任务扩大权限

00:09:50.333 --> 00:09:52.700
会不会发现限制后寻找绕路

00:09:52.866 --> 00:09:54.400
会不会在以为自己处于

00:09:54.400 --> 00:09:56.666
模拟环境时做出危险动作

00:09:56.733 --> 00:09:59.566
都会从实验室问题变成生产风险

00:09:59.733 --> 00:10:01.666
模型如果只能回答文字

00:10:02.066 --> 00:10:04.100
失控通常停留在内容层

00:10:04.400 --> 00:10:06.333
模型可以执行命令以后

00:10:06.566 --> 00:10:08.266
失控就会变成文件

00:10:08.466 --> 00:10:10.900
账户和系统状态的变化

00:10:11.100 --> 00:10:15.300
Anthropic没有宣称问题已经解决相反

00:10:15.700 --> 00:10:18.466
系统评估暴露出一个更棘手的限制

00:10:19.133 --> 00:10:22.600
Opus5.5有时会怀疑自己正在接受测试

00:10:22.800 --> 00:10:25.133
一旦模型识别出评估环境

00:10:25.500 --> 00:10:27.700
它在测试中的谨慎表现就不

00:10:27.700 --> 00:10:30.000
一定等于真实部署中的表现

00:10:30.200 --> 00:10:31.700
研究团队也承认

00:10:31.866 --> 00:10:33.566
目前没有一套评估可以在

00:10:33.566 --> 00:10:36.300
发布前可靠捕捉所有失败方式

00:10:36.733 --> 00:10:37.566
能力越强

00:10:37.666 --> 00:10:39.066
部署环境越复杂

00:10:39.133 --> 00:10:40.533
这个缺口越难靠

00:10:40.733 --> 00:10:42.766
增加几百道测试题填满

00:10:42.766 --> 00:10:45.000
这让Opus5.5的安全叙事

00:10:45.000 --> 00:10:46.366
变得更值得讨论

00:10:46.866 --> 00:10:48.466
官方一方面说它是目前

00:10:48.466 --> 00:10:50.366
对齐表现最好的Claud

00:10:50.600 --> 00:10:52.333
另一方面又承认对齐

00:10:52.333 --> 00:10:54.066
评估存在根本盲区

00:10:54.300 --> 00:10:56.200
两个判断可以同时成立

00:10:56.400 --> 00:10:58.966
它可能确实比上一代更守规矩

00:10:59.300 --> 00:11:01.100
但比上一代更安全

00:11:01.566 --> 00:11:04.733
和已经足够安全之间还有很大距离

00:11:04.933 --> 00:11:06.300
为了降低风险

00:11:06.666 --> 00:11:08.566
Anthropic为模型加入了

00:11:08.566 --> 00:11:10.000
一套代理安全站

00:11:10.533 --> 00:11:12.366
行动分类器会检查

00:11:12.366 --> 00:11:14.266
模型准备执行的操作

00:11:14.700 --> 00:11:17.400
沙箱限制代码能够接触的环境

00:11:17.766 --> 00:11:20.600
代码进入项目之前还要经过审查

00:11:20.933 --> 00:11:23.066
提示注入防护也得到加强

00:11:23.166 --> 00:11:25.266
在Graceone的相关测试中

00:11:25.300 --> 00:11:28.100
Opus5.5与fable5.1处于较低

00:11:28.100 --> 00:11:29.733
的攻击成功率水平

00:11:30.133 --> 00:11:32.733
这套做法说明Anthropic并不相信

00:11:32.733 --> 00:11:35.133
模型仅靠训练就能自我约束

00:11:35.466 --> 00:11:37.733
安全必须由模型权限

00:11:37.966 --> 00:11:41.133
沙箱审核和日志共同承担

00:11:41.333 --> 00:11:43.000
企业部署时也不能

00:11:43.000 --> 00:11:45.366
因为官方说模型更对齐

00:11:45.600 --> 00:11:48.466
就直接给它生产环境的完整权限

00:11:48.966 --> 00:11:51.000
最稳妥的架构仍然是最小

00:11:51.000 --> 00:11:54.066
权限分级确认和可回滚操作

00:11:54.266 --> 00:11:56.800
模型可以读取代码和提出修改

00:11:57.000 --> 00:12:01.300
涉及部署删除数据或调整权限时

00:12:01.366 --> 00:12:02.766
需要额外批准

00:12:02.900 --> 00:12:04.533
网络安全和生物学

00:12:04.533 --> 00:12:06.366
能力受到更严格限制

00:12:07.166 --> 00:12:11.333
Opus5.5在这些领域的能力与Mythos5.1接近

00:12:11.800 --> 00:12:14.966
因此启用了与fable5.1类似的防护

00:12:15.200 --> 00:12:16.966
普通软件开发中的漏洞

00:12:16.966 --> 00:12:19.200
识别和修复仍然可以进行

00:12:19.333 --> 00:12:20.900
但多数网络安全任务

00:12:20.900 --> 00:12:23.466
会被透明转交给Opus4.8

00:12:23.733 --> 00:12:25.166
经过审核的机构可以

00:12:25.166 --> 00:12:27.400
申请生命科学验证计划

00:12:27.733 --> 00:12:29.800
网络安全专业人员的分级

00:12:29.800 --> 00:12:31.966
访问也会在随后几周扩大

00:12:32.133 --> 00:12:33.400
这种能力存在

00:12:33.400 --> 00:12:36.100
但按身份释放的模式可能

00:12:36.100 --> 00:12:38.166
成为前沿模型的新常态

00:12:38.366 --> 00:12:40.766
厂商不再只提供一个统一模型

00:12:41.100 --> 00:12:44.400
而会根据任务账户历史和机构

00:12:44.400 --> 00:12:47.300
资质决定用户实际接触哪一层能力

00:12:47.300 --> 00:12:48.500
对安全来说

00:12:48.566 --> 00:12:50.166
这能减少滥用

00:12:50.366 --> 00:12:51.766
对开发者来说

00:12:51.933 --> 00:12:53.533
它增加了不确定性

00:12:54.000 --> 00:12:54.800
同一个

00:13:11.900 --> 00:13:13.966
用来抵抗模型蒸馏攻击

00:13:14.400 --> 00:13:18.900
对于2026年8月31日以后创建的API账户

00:13:19.000 --> 00:13:21.133
用户不能随意修改模型

00:13:21.333 --> 00:13:23.533
先前的推理上下文在通过

00:13:23.533 --> 00:13:25.566
大量请求提取它的能力

00:13:25.800 --> 00:13:28.100
Anthropic认为供给者利用

00:13:28.100 --> 00:13:30.533
数千个虚假账户复制前沿

00:13:30.533 --> 00:13:33.966
模型会带来商业和国家安全风险

00:13:34.600 --> 00:13:36.766
这项限制保护了模型资产

00:13:36.766 --> 00:13:38.766
也会让部分依赖修改历史

00:13:38.766 --> 00:13:40.866
思考快的旧集成需要调整

00:13:40.933 --> 00:13:43.266
另一个容易被忽略的变化是

00:13:43.800 --> 00:13:46.466
Opus5.5不能关闭思考模式

00:13:46.766 --> 00:13:48.933
开发者可以调整努力程度

00:13:48.966 --> 00:13:50.900
却不能把它退回一个完全

00:13:50.900 --> 00:13:52.933
不思考的普通生成模型

00:13:52.966 --> 00:13:56.200
这个决定说明Anthropic正在把推理

00:13:56.200 --> 00:13:58.733
过程视为产品行为的一部分

00:13:59.066 --> 00:14:01.500
而不是可有可无的附加功能

00:14:02.000 --> 00:14:04.666
它也会影响延迟和可预测性

00:14:04.766 --> 00:14:07.466
简单任务如果调用OPS5.5

00:14:07.766 --> 00:14:09.900
本身就可能是一种资源浪费

00:14:10.333 --> 00:14:13.200
Sonnet和Haiku系列仍会承担更高频

00:14:13.466 --> 00:14:14.933
风险较低的工作

00:14:15.066 --> 00:14:17.700
模型现已覆盖Anthropic全部平台

00:14:17.733 --> 00:14:19.566
并进入Amazon Web Services

00:14:20.166 --> 00:14:23.533
Google cloud和微软Azure cloud platform中

00:14:23.533 --> 00:14:26.400
的模型名称是Claude Opus五五

00:14:26.466 --> 00:14:28.866
同时提供零数据保留选项

00:14:28.966 --> 00:14:30.600
快速模式最高可以达到

00:14:30.600 --> 00:14:32.600
普通模式的2.5倍速度

00:14:33.100 --> 00:14:35.166
输入和输出价格则提高到

00:14:35.166 --> 00:14:38.200
每百万TOKEN8美元和40美元

00:14:38.366 --> 00:14:40.866
对于代码审查和交互任务

00:14:41.000 --> 00:14:43.900
企业可以用更高价格换取低延迟

00:14:44.666 --> 00:14:46.666
对夜间迁移和批量审计

00:14:46.766 --> 00:14:48.166
普通模式更合理

00:14:48.333 --> 00:14:50.400
云平台同时上线也表明

00:14:50.566 --> 00:14:53.500
Anthropic争夺的是企业工作负载

00:14:53.700 --> 00:14:54.933
喜欢尝鲜的个人

00:14:54.933 --> 00:14:56.800
用户只占很小一部分

00:14:57.166 --> 00:15:00.166
大型公司已经把数据权限采购

00:15:00.166 --> 00:15:03.400
流程和审计体系放在既有云平台里

00:15:03.866 --> 00:15:05.133
一款模型如果只能

00:15:05.133 --> 00:15:06.766
通过独立网站使用

00:15:06.900 --> 00:15:08.466
很难进入核心系统

00:15:08.733 --> 00:15:13.733
AWS Google cloud和Azure让Opus 5.5能够沿着

00:15:13.733 --> 00:15:17.166
企业原有账户网络和合规体系部署

00:15:17.366 --> 00:15:18.900
这比多赢几个聊天

00:15:18.900 --> 00:15:20.866
排行榜更能决定收入

00:15:20.966 --> 00:15:23.133
但企业要算清另一笔账

00:15:23.800 --> 00:15:25.566
缓存读取价格大降

00:15:25.733 --> 00:15:27.300
会奖励那些上下文

00:15:27.333 --> 00:15:28.966
重复度高的长期任务

00:15:29.100 --> 00:15:32.533
大型代码库内部知识库和固定

00:15:32.533 --> 00:15:35.700
工作流程会频繁复用相同前缀

00:15:36.066 --> 00:15:37.533
缓存命中率高

00:15:37.866 --> 00:15:39.333
总成本自然下降

00:15:39.366 --> 00:15:41.866
一次性问题和不断变化的超长

00:15:41.866 --> 00:15:44.766
输入未必能得到同样幅度的优惠

00:15:45.400 --> 00:15:48.966
官方所说的典型任务成本下降40%

00:15:49.100 --> 00:15:51.400
不能机械套用到所有场景

00:15:51.533 --> 00:15:54.200
这也是为什么每百万TOKEN多少钱

00:15:54.200 --> 00:15:56.266
越来越不能单独比较模型

00:15:56.600 --> 00:15:58.100
代理任务的账单由

00:15:58.100 --> 00:16:01.300
输入输出缓存工具调用

00:16:01.300 --> 00:16:04.466
推理强度和失败重试共同组成

00:16:04.600 --> 00:16:07.100
便宜的模型如果需要多跑三次

00:16:07.100 --> 00:16:08.400
最后可能更贵

00:16:08.700 --> 00:16:10.366
昂贵模型一次完成

00:16:10.400 --> 00:16:12.166
反而节省人类时间

00:16:12.700 --> 00:16:14.500
真正有意义的指标应该是

00:16:14.500 --> 00:16:16.666
每个通过验收的任务成本

00:16:16.666 --> 00:16:18.866
而不是单纯的TOKEN单价

00:16:19.000 --> 00:16:23.466
anthropic同时提高了Pro Max team和按席位

00:16:23.466 --> 00:16:26.566
购买的enterprise用户的5小时使用额度

00:16:26.900 --> 00:16:29.133
还允许用户保存一次额度重置

00:16:29.366 --> 00:16:32.266
在需要集中处理大型任务时再使用

00:16:32.400 --> 00:16:33.533
这个改动于

00:16:34.133 --> 00:16:36.333
OPS5.5的定位是一致的

00:16:36.533 --> 00:16:38.166
长任务不会平均分布

00:16:38.166 --> 00:16:39.966
在每天的工作时间里

00:16:40.200 --> 00:16:43.366
迁移审计和复杂排错往往会在

00:16:43.366 --> 00:16:46.000
某几个小时突然消耗大量计算

00:16:46.333 --> 00:16:48.466
固定且无法调度的额度

00:16:48.566 --> 00:16:51.133
很容易在任务最关键的时候中断

00:16:51.533 --> 00:16:53.866
把重置机会留到高峰使用

00:16:54.000 --> 00:16:57.000
相当于让订阅额度更接近项目预算

00:16:57.133 --> 00:16:59.933
但更高额度也会改变团队行为

00:17:00.066 --> 00:17:01.933
过去因为限制太紧

00:17:02.266 --> 00:17:05.000
工程师会把问题拆成较小部分

00:17:05.300 --> 00:17:07.066
手动检查后再继续

00:17:07.766 --> 00:17:09.066
额度放宽以后

00:17:09.133 --> 00:17:10.400
团队更可能把整个

00:17:10.400 --> 00:17:12.133
代码库一次交给代理

00:17:12.266 --> 00:17:13.333
效率会上升

00:17:13.666 --> 00:17:15.933
验收压力也会集中到任务末端

00:17:16.066 --> 00:17:17.366
要是模型前两个

00:17:17.366 --> 00:17:19.366
小时就理解错了目标

00:17:19.466 --> 00:17:21.666
直到最终测试才暴露问题

00:17:21.866 --> 00:17:23.733
损失会比短任务更大

00:17:24.600 --> 00:17:27.400
团队仍然需要在中途设置检查点

00:17:27.500 --> 00:17:29.000
让模型每完成一个

00:17:29.000 --> 00:17:31.200
阶段就提交可验证结果

00:17:31.266 --> 00:17:33.966
这类检查点还决定责任能否追踪

00:17:34.700 --> 00:17:36.200
主代理分派了什么

00:17:36.600 --> 00:17:38.400
子代理修改了哪些文件

00:17:38.700 --> 00:17:41.400
哪次测试失败后又采取了什么补救

00:17:41.500 --> 00:17:43.133
都应该留在日志里

00:17:43.300 --> 00:17:44.466
只有最终代码

00:17:44.533 --> 00:17:45.733
没有过程记录

00:17:45.866 --> 00:17:48.400
出了问题就很难判断是需求不

00:17:48.400 --> 00:17:51.666
清模型偏离还是测试本身缺失

00:17:51.900 --> 00:17:53.166
代理工作越快

00:17:53.333 --> 00:17:54.866
审计记录越不能省

00:17:54.966 --> 00:17:56.533
从竞争格局看

00:17:56.700 --> 00:17:58.533
Opus 5.5发布后

00:17:58.566 --> 00:18:02.166
Anthropic和Openai都在争夺同一个位置

00:18:02.566 --> 00:18:05.400
谁能成为企业默认开启的工作模型

00:18:05.733 --> 00:18:08.733
最高端模型负责展示能力边界

00:18:09.066 --> 00:18:12.166
中间层模型负责真正消耗大量TOKEN

00:18:12.400 --> 00:18:15.000
OPS5.5把高端能力和更

00:18:15.000 --> 00:18:17.166
低成本放在同一产品里

00:18:17.333 --> 00:18:19.600
迫使竞争对手证明自己的便宜

00:18:19.600 --> 00:18:22.333
模型能否完成同样复杂的工作

00:18:22.600 --> 00:18:25.000
Anthropic还在重新定义旗舰

00:18:25.300 --> 00:18:27.766
过去的旗舰意味着参数更多

00:18:27.766 --> 00:18:28.800
价格更高

00:18:28.900 --> 00:18:30.200
适合最难的问题

00:18:30.466 --> 00:18:32.800
Opus 5.5加入了另一个标准

00:18:32.933 --> 00:18:35.766
能否长时间稳定的完成完整任务

00:18:35.800 --> 00:18:38.500
一个模型在数学题上多拿几分

00:18:38.900 --> 00:18:40.933
商业价值未必立刻变化

00:18:41.100 --> 00:18:44.066
他若能把4天的协作压缩到3小时

00:18:44.300 --> 00:18:47.466
把20小时的代码审计压缩到3小时

00:18:47.733 --> 00:18:49.933
企业预算会迅速向他倾斜

00:18:50.066 --> 00:18:51.900
可这种效率不会平均

00:18:51.900 --> 00:18:53.733
落到所有员工身上

00:18:54.100 --> 00:18:56.900
最先受影响的工作是目标清楚

00:18:57.200 --> 00:18:58.466
结果可测试

00:18:58.766 --> 00:19:00.700
资料已经数字化的任务

00:19:00.866 --> 00:19:01.733
代码迁移

00:19:02.266 --> 00:19:04.800
测试补全文档整理和

00:19:04.800 --> 00:19:07.000
常规分析都符合这些条件

00:19:07.166 --> 00:19:09.500
需求模糊责任重大结果

00:19:09.500 --> 00:19:11.666
难以验证的工作仍然需要

00:19:11.666 --> 00:19:14.066
人类定义问题和承担后果

00:19:14.533 --> 00:19:17.066
模型越擅长执行人的价值越向

00:19:17.066 --> 00:19:19.900
目标设定验收和风险判断移动

00:19:20.100 --> 00:19:22.466
开发团队也会改变组织方式

00:19:22.666 --> 00:19:25.866
过去工程师亲自写大部分代码

00:19:25.966 --> 00:19:27.866
再让工具提供补全

00:19:27.933 --> 00:19:30.900
新的流程可能由人类写验收标准

00:19:31.366 --> 00:19:32.766
主代理拆分任务

00:19:32.766 --> 00:19:34.533
多个会话执行修改

00:19:34.600 --> 00:19:36.466
测试系统自动筛选

00:19:36.533 --> 00:19:39.066
最后由工程师审查关键差异

00:19:39.200 --> 00:19:40.866
这样做能提高产出

00:19:40.866 --> 00:19:43.000
也会让代码来源越来越难

00:19:43.000 --> 00:19:44.466
靠个人记忆追踪

00:19:44.700 --> 00:19:46.933
团队需要更严格的变更日志

00:19:47.466 --> 00:19:49.333
测试覆盖和责任边界

00:19:49.533 --> 00:19:51.366
如果这些制度没有跟上

00:19:52.066 --> 00:19:54.166
速度会成为风险放大器

00:19:54.866 --> 00:19:57.700
一个代理一天能修改68万行代码

00:19:58.200 --> 00:19:59.600
说明它能在一天里

00:19:59.600 --> 00:20:01.400
制造同等规模的错误

00:20:01.666 --> 00:20:04.333
测试通过也不等于行为完全正确

00:20:04.933 --> 00:20:07.866
测试本身可能漏掉安全和性能问题

00:20:08.100 --> 00:20:10.000
模型生成能力提高以后

00:20:10.266 --> 00:20:12.533
审查不能只是阅读更多代码

00:20:13.066 --> 00:20:16.533
而要把需求测试和部署权限

00:20:16.533 --> 00:20:19.600
重新设计成能约束机器速度的系统

00:20:19.800 --> 00:20:21.900
OPS5.5最值得关注的

00:20:21.900 --> 00:20:23.933
地方就在这个矛盾里

00:20:23.966 --> 00:20:25.800
它更便宜更快

00:20:25.966 --> 00:20:27.566
长任务能力也更强

00:20:27.866 --> 00:20:30.900
同时Anthropic比以往更用力

00:20:30.966 --> 00:20:33.700
强调沙箱行动分类安全

00:20:33.700 --> 00:20:35.600
后备模型和身份验证

00:20:35.766 --> 00:20:37.866
厂商的产品设计已经承认

00:20:37.933 --> 00:20:39.400
强大的代理不能只靠

00:20:39.400 --> 00:20:40.966
一句系统提示管理

00:20:41.100 --> 00:20:43.100
能力越接近独立执行者

00:20:43.400 --> 00:20:44.666
外部控制越要像

00:20:44.666 --> 00:20:46.300
真正的软件基础设施

00:20:46.500 --> 00:20:48.766
开头那个问题也有了答案

00:20:49.700 --> 00:20:52.100
Anthropic呼吁放慢前沿

00:20:53.066 --> 00:20:55.900
AI又继续发布Opus5.5

00:20:55.900 --> 00:20:57.600
两项行动可以放在

00:20:57.600 --> 00:20:59.466
同一套策略里理解

00:20:59.600 --> 00:21:02.500
公司继续提高可商业化的代理能力

00:21:02.666 --> 00:21:04.600
同时把更危险的能力锁

00:21:04.600 --> 00:21:07.066
进验证计划和防护系统

00:21:07.166 --> 00:21:10.266
再要求行业与政府采用更高标准

00:21:10.533 --> 00:21:12.066
这既是安全立场

00:21:12.066 --> 00:21:13.766
也是一种竞争策略

00:21:13.933 --> 00:21:17.100
谁先把安全基础设施做成产品门槛

00:21:17.300 --> 00:21:20.266
谁就能在监管到来时占据主动

00:21:20.566 --> 00:21:22.933
所以Opus5.5不会因为某张

00:21:22.933 --> 00:21:25.133
榜单领先就自动赢下市场

00:21:25.300 --> 00:21:27.333
它真正的考验会发生在

00:21:27.333 --> 00:21:29.100
数千家企业把它接进

00:21:29.100 --> 00:21:32.100
代码库云平台和内部流程以后

00:21:32.200 --> 00:21:33.566
模型能否连续工作

00:21:33.566 --> 00:21:35.866
几个小时而不偏离目标

00:21:36.200 --> 00:21:38.533
防护机制会不会误伤正常任务

00:21:38.600 --> 00:21:40.766
出现错误时能不能快速回滚

00:21:40.966 --> 00:21:43.533
这些问题才决定它是生产工具

00:21:43.533 --> 00:21:45.266
还是一场昂贵的实验

00:21:45.500 --> 00:21:47.400
Claude Opus5.5

00:21:47.600 --> 00:21:49.933
把AI代理向前推了一大步

00:21:50.000 --> 00:21:52.666
也把行业的责任向前推了一大步

00:21:52.866 --> 00:21:55.066
当模型开始替人管理任务

00:21:55.500 --> 00:21:56.933
真正稀缺的能力就

00:21:56.933 --> 00:21:58.533
不再只是生成内容

00:21:58.766 --> 00:22:01.100
而是知道什么时候可以继续

00:22:01.300 --> 00:22:02.900
什么时候必须停下

00:22:03.066 --> 00:22:04.933
Anthropic已经证明它能

00:22:04.933 --> 00:22:06.700
让Claude做的更多

00:22:07.133 --> 00:22:09.066
接下来需要证明的是

00:22:09.066 --> 00:22:11.933
它也能让Claude在该停的位置停住