Claude Opus 5.5缓存读取降价60%，AI编程成本怎么算

缓存读取降价 60%，和 AI 编程让软件工程更难，竟然出现在同一批消息里。前者让 Agent 多跑几轮更便宜，后者提醒程序员，多出来的代码和操作，总得有人验收。到了 2026 年 9 月 25 日，比起继续争论哪个模型更聪明，我更关心这些能力接进业务之后，账怎么算、权限怎么收、失败怎么查。这期 AI 热点沿着六条线聊，从模型降价、云电脑到状态管理和决策小模型，帮你判断哪些可以动手试，哪些还得等等。

一、AI 编程模型降价了，为什么项目不一定更省钱？

先说结论，我会把这轮降价当成重新测成本的理由，暂时不会把它当成迁移通知。

按照 DEV 的价格战报道，9 月 22 日发布的 Claude Opus 5.5，每百万输入、输出 tokens 分别为 4 美元和 20 美元；缓存读取降至每百万 0.20 美元，降幅为 60%。同一报道提到，OpenAI 推出了定位低于 GPT-6 Astra 的 Sol 和 Luna。

对反复读取仓库上下文的编程 Agent，缓存读取变便宜，确实有吸引力。不过，60% 对应的是缓存读取这一项，不能直接套到整张账单上。输出、未命中的输入、工具执行，以及失败重试，仍然要算钱。

报道还转述了 Anthropic 关于典型工作负载成本下降的说法。这是厂商口径，不能顺手改写成你的项目能省多少。

真正让我对降价保持克制的，是另一篇 Agent ROI 实战文章。作者讲了一个物流邮件处理案例，Agent 处理了约 40% 的消息，每月推理和编排费用约 2300 美元，但人工仍然忙着处理升级事件，净节省接近零。

后来团队把范围收窄到重复承运人的标准航线报价，处理比例降到 22%，每次解决成本却下降了三分之二。

这个案例是作者自己的项目叙述，不是跨公司的统计结果。但它至少提醒了一件很容易漏算的事。

自动处理比例高，不等于人工真的少干了活。

回到这块，前端团队评估 AI 编程也一样。生成十个页面之后，如果组件约定、交互细节和异常状态都要重新改一遍，模型账单下降只是省了其中一小笔。评审时间、返工时间，以及最后有没有通过验收，才决定这一单划不划算。

我的取舍是把「每次调用多少钱」降为辅助指标，把「交付一个验收通过的任务花多少钱」放到前面。这里也别走另一个极端，纯粹的低风险批处理任务，人工复核本来就少，降价很可能直接带来收益。

真要判断换不换，我会拿仓库里最近 20 个能在当天验完的真实小任务，固定权限、上下文和验收条件，比较两个候选。记录模型费用、重试次数、人工修改分钟数和通过率，别只截一张 tokens 账单就宣布省钱了。

二、Agent 有了云电脑，怎样分清开放能力和安全漏洞？

Meta Muse 把这件事推得很直观。根据 The Decoder 的报道，每位用户都有一台运行 Ubuntu Linux 的云端计算机，可以安装软件、写代码、编译和浏览网页。

对开发者来说，这比多一个聊天输入框更值得关注。模型终于有了一个可以持续操作的工作环境，文件、依赖和执行结果都能留在那里。

微软也在往这个方向走。IT之家对新版 Copilot 的报道提到，应用整合了 Home、Code、Autopilot 三个标签页。Code 用于创建内部应用，Autopilot 则拥有独立的云端计算机实例，可以在后台持续处理任务。

AI 办公提效开始碰到我们熟悉的工程问题了。一个助手只给建议时，答错了可以重问；它能访问文件、调用服务、持续运行之后，操作记录和权限边界就得跟上。

这里有个坑，Muse 的两条安全消息不能混着讲。

The Verge 的文件系统报道称，两名开发者让 Muse 打包了根文件系统及内部文件。Meta 的回应是，用户本来就可以查看自己的虚拟机，导出这些数据不会赋予访问 Meta 基础设施或其他用户数据的权限。

所以，仅凭能导出自己的虚拟机，不能证明发生了跨租户隔离失效。The Decoder 的报道也提到，Meta 有意让运行区域内的文件保持透明。

但「能看见自己的文件」和「外部内容能不能诱导 Agent 把文件发送给别人」，又是两件事。前者是产品能力，后者才涉及操作授权。现有摘录不足以把这两件事直接画上等号，也不足以替产品证明提示词注入已经被彻底挡住。

另一条就具体得多。IT之家关于 macOS 漏洞的报道提到，语音输入的隐藏配置项可以被当前用户权限下的进程修改，导致语音数据和认证 Token 被发送到攻击者控制的服务器。报道同时写明，Meta 已通过热修复移除了相关调试功能。

能访问多少资源，就要审查多少条实际的数据出口。

我的读法是，云电脑值得试，但别把「有沙箱」理解成所有操作都安全。宿主机隔离、用户数据外发、第三方账户授权，各有各的边界。

你要是也在做这类产品，可以今天就在测试环境放一份虚构客户文件，再让 Agent 读取一段包含外发指令的测试文档。只使用团队控制的接收地址，观察它是否把文档内容当成授权，以及操作日志能不能还原文件被谁、因为什么指令发出去了。

三、后台 Agent 重复执行任务，为什么加记忆也救不了？

顺着上面聊，Agent 一旦开始后台运行，最麻烦的往往是它不知道自己到底做完了什么。

情景记忆与语义记忆这篇文章用了一个很扎眼的例子。Agent 记住了小额退款可以自动审批，却忘记前一天已经处理过同一笔退款，于是又做了一遍。

规则没记错，事件丢了。

另一篇讨论 Agent 状态管理的文章把问题落在编排循环上。工具结果经过摘要、截断和转述之后，模型继续拿这段聊天历史规划下一步，却未必还能区分原始事实与自己的推测。

这两个角度放在一起，对业务开发特别有用。长期偏好、历史事件、当前业务状态，应该承担不同职责。记忆可以帮助 Agent 理解用户，订单是否退款成功则应该有明确的业务记录。

聊天里写了「完成」，业务系统里未必真的完成。

大概率你也遇到过类似的接口问题。请求超时了，究竟是服务端没执行，还是执行成功后响应丢了？Agent 会不会解释这个错误，都不能替代查询真实状态。

下面用一段 JavaScript 表达我会保留的操作记录，它解决的是重试时无法区分计划、执行和确认的问题。

const operation = {
  operationId: 'refund-order-2048-v1',
  idempotencyKey: 'refund-order-2048-v1', // 重试沿用同一个业务键
  intent: { type: 'refund', orderId: '2048', amount: 39 },
  status: 'unknown', // 超时先保留未知，不能直接判失败
  evidence: {
    requestId: 'req-731',
    providerTransactionId: null,
    verifiedAt: null,
  },
  nextAction: 'queryProvider', // 查询结果后再决定是否继续
};

最容易翻车的是 idempotencyKey 这一行，字段写在对象里并不会自动去重，还得由执行端落实幂等约束，或者在业务存储中保证操作唯一。

这也解释了为什么单纯增加上下文长度未必解决问题。Agent 可以记住更多对话，但如果对话本身记录的是「可能成功」，记得再牢也不能把它变成「已经确认成功」。

当然，状态管理也不能包治所有错误。工具返回真实数据后，模型仍然可能理解错规则。这里只是把可以由程序保证的部分，从自然语言推测里拿出来。

今天就能做的验证很小。在测试接口已经写入成功、但尚未返回响应的位置注入一次超时，再重新运行任务。看它是查询原操作，还是直接新增一次操作，这个结果比多聊十轮更能说明系统有没有守住状态。

四、AI SRE 能自动提 PR，程序员的验收工作会变少吗？

我对 AI SRE 这条有兴趣，尤其是它把工作范围收在了事故排查的前半段。

DEV 的 AI SRE 实践描述了一组只读调查 Agent，分别查看代码、发布、基础设施和指标，再由一个专门质疑结论的 Agent 尝试推翻假设。遇到高置信度代码缺陷时，系统会创建修复 PR，最终仍由人合并。

这个分工挺合理。收集部署记录、拉日志、对时间线，是可以先交给工具做的工作；创建 PR 也给人留下了一个能检查、能撤回的交付物。

不过，多个 Agent 都同意，不代表根因就找对了。如果它们读到同一份不完整日志，也可能一起得出错误结论。质疑者有没有价值，得看它能不能找出新的证据，或者设计出能推翻当前结论的检查。

Simon Willison 在 9 月 24 日的笔记里说，越多使用编程 Agent，越觉得软件工程变难，因为发挥这些工具的潜力需要很强的纪律和知识储备。

我赞同其中关于验收负担的提醒，但不会把它理解成所有任务都会变难。一个边界清楚、结果容易检查的小改动，完全可能更轻松。困难往往出现在输出增长之后，人还得判断这些改动之间有没有互相打架。

AI 生成应用的 Kubernetes 部署文章提供了另一个具体例子。Deployment、Service 和 Helm 配置可以很快生成，应用探针、优雅关闭、资源设置、权限以及备份恢复，却仍然需要结合实际环境检查。

能提交，不等于能上线。

回到程序员的日常，前端也是同一道题。页面能打开，只说明最顺利的路径走通了。接口失败时有没有错误反馈，连续点击会不会重复提交，旧请求会不会覆盖新结果，都需要独立的验收依据。

如果团队要试 AI SRE，我会挑一个已知根因的历史故障，在隔离环境里复现，并且不给 Agent 看最终复盘。当天只检查三件事，证据有没有对上、修复前能否稳定失败、修复后同一个检查能否通过。这样才能区分它是真的解决问题，还是写了一份很像复盘的文字。

五、分类和路由任务，还需要调用完整的大模型吗？

说实话，这批消息里我更想动手试的，是那些不擅长聊天的小模型。

Jev 的介绍文章称，它面向带类型的决策任务，返回选项和概率，耗时约 70 到 500 毫秒，每百万输入 tokens 收费 0.042 美元。

这些数字可以拿来做初步预算，但不能直接套到你的请求上。文章摘录没有交代足够完整的输入长度、并发和网络条件，延迟还是得自己量。

尤其别被「不会幻觉」带跑。这里说的是输出被限制在预设选项内，它依然可能选错。

Fastino GLiNER2.5-Decide 的报道则给了另一个方向。这个 340M 参数模型支持 CPU 部署，针对路由、分类、工具选择等任务，还可以通过联合解码满足答案之间的约束。

例如，系统判断输入包含某种危害时，另一个字段不能同时说它安全。约束能消除这种内部矛盾，却不能保证模型一定发现了危害。

报道给出的 60.1% 平均精确匹配准确率，来自团队内部生成的留出测试集，共 17 个数据集、5100 个样本。它适合帮助理解模型定位，不能据此宣布你的分类业务已经可以替换现有方案。

还有一篇决策模型推理优化实践，尝试让多个问题共享同一份文档输入。文章报告在约 500 token 文档、10 个问题的场景下提速 6.7 倍，并通过注意力掩码和位置安排保留任务结构。

这个数字属于特定实现与测试条件，也不是把聊天 API 的十个问题塞进一个提示词，就能获得同样收益。

对做工单、内容审核和后台管理系统的人，我更关心一个实际变化。原先要让模型输出一段 JSON 再解析，现在可以把输出范围直接收紧，让业务代码负责后续动作。

下面这段代码处理的是分类结果进入业务路由前的检查，不依赖任何特定模型 SDK。

function routeTicket(result) {
  const allowed = new Set(['billing', 'technical', 'account']);
  const { label, confidence } = result;

  if (!allowed.has(label)) return 'manual';
  if (!Number.isFinite(confidence)) return 'manual';
  if (confidence < 0 || confidence > 1) return 'manual';

  // 0.9 只是试验起点，需要用业务样本调整
  if (confidence < 0.9) return 'manual';

  return label; // 此处只分流，不触发退款等业务操作
}

最容易翻车的是 confidence < 0.9 这一行，模型报出 0.9，不代表线上一定有 90% 的正确率，阈值要跟误判成本一起调。

今天可以拿 100 条已经人工分类的工单，比较现有方案与一个决策模型。除了耗时和费用，我还会把高置信度误判单独拎出来看，因为这部分最容易悄悄绕过人工兜底。

六、n8n 和多 Agent 编排都在升级，团队该把控制权放在哪？

n8n 的官方介绍有个挺实用的变化。新 Agents 可以独立存在，通过对话、定时计划或工作流调用；Agent 能把已有工作流当工具，工作流也能通过 Message an Agent 节点调用它。

我喜欢这里保留的选择。固定步骤仍然可以写成工作流，遇到开放问题再交给 Agent 判断。自然语言创建入口更容易了，但执行权限仍然可以落在具体工具上。

The New Stack 对 OpenAI 与 Cursor 的报道也提到了协调者与执行者分离。OpenAI 的 Agents API 和 Cursor Projects 处于不同产品层级，却都在围绕更大范围的工作安排多个 Agent。

不过，现有摘录对两家「谁应该控制协调器」的具体分歧展开得不够，我不会替它们补出详细的架构结论。能看到的趋势是，单个 Agent 之外，任务分配、会话和恢复流程正在成为产品的一部分。

对团队来说，控制权这个问题可以问得更具体。谁定义完成条件？哪个组件记录当前状态？工具执行失败之后，谁决定重试？一个 Agent 说自己完成了，协调者拿到的是自然语言汇报，还是可检查的文件和执行结果？

这些问题比有几个 Agent 同时工作更有用。

我的取舍是，步骤确定、失败处理清楚的业务流程，继续让程序控制。需要追问、调查和选择路径的局部环节，再给 Agent 一段有限的空间。这样做未必最适合探索性研究任务，但对于每天重复运行的内部自动化，我更愿意换取容易定位的问题。

拿 AI 办公提效里的周报来说，收集数据的时间范围、发送对象和发送次数，可以固定；解释异常变化、补充说明，则可以交给模型。如果让它同时决定这些事情，出错时很难知道该改提示词还是改流程。

当天就能做一次对照。选一个现成的内部汇总任务，一版让 Agent 自由选择步骤，另一版固定取数和交付流程，只让 Agent 做分析。用相同的几份输入跑完，比较漏项、重复动作、人工纠正时间，以及中断后能不能接着做。哪一版省心，就先用哪一版。

总结

按这批报道能落到具体细节上的信息，模型价格出现了调整，Muse 和 Copilot 把云端工作环境带进了助手产品，n8n 增加了独立的 Agents 入口，Muse 的 macOS 调试配置漏洞也已有热修复。这几件事各有明确的产品能力、价格口径或处理结果，不必再包装成万能结论。

我的判断是，接下来团队之间的差距，会越来越多地体现在验收、状态和权限设计上。模型更便宜，确实让试错更容易；但它不会替我们决定什么算完成，也不会自动处理重复执行。

至于迁移之后究竟能省多少钱，多 Agent 是否比单 Agent 更可靠，决策小模型能否承担你的业务分类，现在都还不能替具体项目下结论。厂商数字、作者案例和内部基准，可以帮我们挑候选，不能代替自己那一小批真实任务。

要我选，今天就从一个边界清楚的小任务开始，把成功条件和失败记录留好。让 AI 多做一点，也让程序员更容易知道它到底做对了什么。

参考

一、AI 编程模型降价了，为什么项目不一定更省钱？

先说结论，我会把这轮降价当成重新测成本的理由，暂时不会把它当成迁移通知。

报道还转述了 Anthropic 关于典型工作负载成本下降的说法。这是厂商口径，不能顺手改写成你的项目能省多少。

后来团队把范围收窄到重复承运人的标准航线报价，处理比例降到 22%，每次解决成本却下降了三分之二。

这个案例是作者自己的项目叙述，不是跨公司的统计结果。但它至少提醒了一件很容易漏算的事。

自动处理比例高，不等于人工真的少干了活。

二、Agent 有了云电脑，怎样分清开放能力和安全漏洞？

Meta Muse 把这件事推得很直观。根据 The Decoder 的报道，每位用户都有一台运行 Ubuntu Linux 的云端计算机，可以安装软件、写代码、编译和浏览网页。

对开发者来说，这比多一个聊天输入框更值得关注。模型终于有了一个可以持续操作的工作环境，文件、依赖和执行结果都能留在那里。

这里有个坑，Muse 的两条安全消息不能混着讲。

所以，仅凭能导出自己的虚拟机，不能证明发生了跨租户隔离失效。The Decoder 的报道也提到，Meta 有意让运行区域内的文件保持透明。

能访问多少资源，就要审查多少条实际的数据出口。

我的读法是，云电脑值得试，但别把「有沙箱」理解成所有操作都安全。宿主机隔离、用户数据外发、第三方账户授权，各有各的边界。

三、后台 Agent 重复执行任务，为什么加记忆也救不了？

顺着上面聊，Agent 一旦开始后台运行，最麻烦的往往是它不知道自己到底做完了什么。

情景记忆与语义记忆这篇文章用了一个很扎眼的例子。Agent 记住了小额退款可以自动审批，却忘记前一天已经处理过同一笔退款，于是又做了一遍。

规则没记错，事件丢了。

聊天里写了「完成」，业务系统里未必真的完成。

下面用一段 JavaScript 表达我会保留的操作记录，它解决的是重试时无法区分计划、执行和确认的问题。

const operation = {
  operationId: 'refund-order-2048-v1',
  idempotencyKey: 'refund-order-2048-v1', // 重试沿用同一个业务键
  intent: { type: 'refund', orderId: '2048', amount: 39 },
  status: 'unknown', // 超时先保留未知，不能直接判失败
  evidence: {
    requestId: 'req-731',
    providerTransactionId: null,
    verifiedAt: null,
  },
  nextAction: 'queryProvider', // 查询结果后再决定是否继续
};

最容易翻车的是 idempotencyKey 这一行，字段写在对象里并不会自动去重，还得由执行端落实幂等约束，或者在业务存储中保证操作唯一。

四、AI SRE 能自动提 PR，程序员的验收工作会变少吗？

我对 AI SRE 这条有兴趣，尤其是它把工作范围收在了事故排查的前半段。

这个分工挺合理。收集部署记录、拉日志、对时间线，是可以先交给工具做的工作；创建 PR 也给人留下了一个能检查、能撤回的交付物。

Simon Willison 在 9 月 24 日的笔记里说，越多使用编程 Agent，越觉得软件工程变难，因为发挥这些工具的潜力需要很强的纪律和知识储备。

能提交，不等于能上线。

五、分类和路由任务，还需要调用完整的大模型吗？

说实话，这批消息里我更想动手试的，是那些不擅长聊天的小模型。

Jev 的介绍文章称，它面向带类型的决策任务，返回选项和概率，耗时约 70 到 500 毫秒，每百万输入 tokens 收费 0.042 美元。

这些数字可以拿来做初步预算，但不能直接套到你的请求上。文章摘录没有交代足够完整的输入长度、并发和网络条件，延迟还是得自己量。

尤其别被「不会幻觉」带跑。这里说的是输出被限制在预设选项内，它依然可能选错。

例如，系统判断输入包含某种危害时，另一个字段不能同时说它安全。约束能消除这种内部矛盾，却不能保证模型一定发现了危害。

这个数字属于特定实现与测试条件，也不是把聊天 API 的十个问题塞进一个提示词，就能获得同样收益。

下面这段代码处理的是分类结果进入业务路由前的检查，不依赖任何特定模型 SDK。

function routeTicket(result) {
  const allowed = new Set(['billing', 'technical', 'account']);
  const { label, confidence } = result;

  if (!allowed.has(label)) return 'manual';
  if (!Number.isFinite(confidence)) return 'manual';
  if (confidence < 0 || confidence > 1) return 'manual';

  // 0.9 只是试验起点，需要用业务样本调整
  if (confidence < 0.9) return 'manual';

  return label; // 此处只分流，不触发退款等业务操作
}

最容易翻车的是 confidence < 0.9 这一行，模型报出 0.9，不代表线上一定有 90% 的正确率，阈值要跟误判成本一起调。

六、n8n 和多 Agent 编排都在升级，团队该把控制权放在哪？

这些问题比有几个 Agent 同时工作更有用。

总结

要我选，今天就从一个边界清楚的小任务开始，把成功条件和失败记录留好。让 AI 多做一点，也让程序员更容易知道它到底做对了什么。

AI雷达日报

今日看点

一、AI 编程模型降价了，为什么项目不一定更省钱？

二、Agent 有了云电脑，怎样分清开放能力和安全漏洞？

三、后台 Agent 重复执行任务，为什么加记忆也救不了？

四、AI SRE 能自动提 PR，程序员的验收工作会变少吗？

五、分类和路由任务，还需要调用完整的大模型吗？

六、n8n 和多 Agent 编排都在升级，团队该把控制权放在哪？

总结

参考

AI雷达日报

今日看点

一、AI 编程模型降价了，为什么项目不一定更省钱？

二、Agent 有了云电脑，怎样分清开放能力和安全漏洞？

三、后台 Agent 重复执行任务，为什么加记忆也救不了？

四、AI SRE 能自动提 PR，程序员的验收工作会变少吗？

五、分类和路由任务，还需要调用完整的大模型吗？

六、n8n 和多 Agent 编排都在升级，团队该把控制权放在哪？

总结

参考