Opus 5.5编辑历史消息，须区分服务端清理与客户端改写

为了缩短Opus 5.5的长对话，开发团队可能想删除旧工具结果，或改写早先的消息。但Anthropic现行指南提醒，服务器管理上下文与客户端自行改写历史，并不是同一项操作。服务端与客户端的责任边界，在对话累积较长、需要进一步压缩旧历史时尤其值得先明确。两者对思考块有效性以及提示缓存的影响不同，不能因为画面上都像“删掉旧内容”，就使用相同的处理假设。

服务端上下文编辑发生在提示交给模型之前。文档说明，客户端可以继续保存并发送完整、未经修改的会话历史，不需要为了配合服务端的清理结果而同步删改本地消息。这一设计让应用保留完整记录，同时由平台执行指定的上下文管理策略。它并不要求开发者猜测服务器到底删除了哪些文本，再手动重建历史。

对于Opus 5.5与Fable 5.1，官方进一步说明，服务端上下文管理不会使思考块失效。客户端改写历史则不同：修改较早的一轮内容，会使其后所有思考块失去有效性。这里讨论的是消息序列的完整性，并不取决于修改后的文字在读者看来是否意思相近。即使只是整理此前工具结果，也需要遵循接口对历史的要求。

账户创建时间影响错误处理。迁移指南规定，对二〇二六年八月三十一日零时协调世界时及以后创建的账户，重新提交无效思考块会被拒绝，除非应用明确选择丢弃这些块。报道不能把这一限制描述为所有账户在同一天突然出现的相同行为，也不能据此建议开发者悄悄删除思考内容而忽略产品要求。

缓存是另一条需要独立核查的链路。上下文编辑指南指出，清除工具结果会使缓存前缀失效，后续需要重新写入缓存。文档因此介绍了clear_at_least等设置，用于避免过于频繁地进行小规模清理。这里的取舍涉及腾出上下文空间与重新写入缓存的成本，而不只是把请求压缩得越短越好。