Claude Code v2.1.293更新:新增Haiku 5.5默认模型与大量修复

Claude Code v2.1.293 引入 Haiku 5.5 模型,并修复数十项会话、工具与终端交互问题。
Anthropic 发布的 Claude Code v2.1.293 以两条主线推进:新增支持 100 万 token 上下文的 Claude Haiku 5.5 作为 API 默认轻量模型,起步价低至每百万 token 输入 0.10 美元;以及针对子代理通信、会话稳定性、终端交互和企业集成的大范围缺陷修复。具体改进包括:子代理状态行新增 agentType 字段、工具注册引入 isDeferred 参数、修复上下文压缩期间的误判撤销、修复 HTTP MCP 内存泄漏,以及多处 Vim 模式和后台消息丢失问题。同时,团队回退了 v2.1.281 和 v2.1.290 的两项改动,表明此前修复存在副作用。整体而言,这是一次以稳定性打磨为主、兼顾新模型能力的版本。
Anthropic 发布了 Claude Code 命令行工具的 v2.1.293 版本。这次更新最引人注目的是引入了全新的 Claude Haiku 5.5 模型,同时附带了数十项针对会话管理、权限控制、插件系统和子代理(subagent)的修复与改进。对于重度使用 Claude Code 进行 AI 辅助编程的开发者来说,这是一次细节打磨为主、兼顾新能力的版本迭代。

核心亮点:Haiku 5.5 成为默认轻量模型
本次更新最具实质意义的变化是新增了 claude-haiku-5-5 模型,并将其设为 Anthropic API 上默认的 Haiku 模型。这款模型主打轻量、高性价比场景:
- 上下文窗口达到 100 万 token(1M context),这对于需要处理大型代码库或长文档的任务是关键能力。
- 定价为每百万 token 输入 0.10 美元、输出 0.50 美元;当 prompt 超过 10 万 token 时,价格升至输入 0.50 美元、输出 2.50 美元。
这一分级定价策略意味着开发者在处理常规规模任务时能享受极低成本,而只有在触及超长上下文时才会承担更高费用。对于批量代码分析、日志解析或自动化脚本等 Haiku 擅长的场景,这是一个值得关注的升级。
Haiku 是 Anthropic Claude 系列中定位「轻量快速」的子系列,与主打高性能的 Sonnet、顶级的 Opus 形成三层产品梯队。Haiku 的设计目标是以极低延迟和成本处理结构化程度高、上下文需求相对简单的任务,例如代码补全、分类标注、摘要生成等。1M context(100 万 token)的上下文窗口约等于 75 万个英文单词或数万行代码,足以将一个中等规模的代码库完整加载进单次对话,是需要跨文件分析依赖关系或审查大型日志的场景的关键能力。分级定价(超过 10 万 token 后涨价 5 倍)也是业界常见做法,本质上是对「偶尔需要超长上下文」与「持续依赖超长上下文」的用户做差异化收费,激励开发者合理控制 prompt 规模。
子代理与工具系统的增强
这一版本在 agent 相关机制上做了多处改进,反映出 Claude Code 正在不断强化其多代理协作能力:
subagentStatusLine的 payload 中新增了agentType字段,脚本因此可以区分不同类型的自定义子代理。$.tool.register新增isDeferred参数,供 mod 使用:设为false时,工具的 schema 会从一开始就出现在 prompt 中,而不是隐藏在工具搜索之后。
同时,多个与 agent 相关的 bug 被修复。例如:当 host、权限规则或 --tools 列表移除了 SendMessage 工具后,Claude 仍被告知可以继续或向子代理发消息的问题;以及子代理和 --agent 会话被错误告知某个内置工具在整个会话中被禁用(实际上只是它们自己的工具列表未包含该工具)的问题。这些修复让多代理场景下的工具可见性更加准确。
子代理(subagent)是指在主 Claude 会话之外,由主代理动态派生或调用的独立代理实例,常用于将复杂任务拆解为可并行或可专门化的子任务,例如让一个代理专门负责代码审查、另一个专门执行测试。SendMessage 工具是主代理与子代理之间进行通信的核心原语,若该工具被权限规则意外移除但 Claude 仍被告知可以使用,便会出现「幻觉调用」——模型以为自己发出了指令,实际上什么都没发生。$.tool.register 的 isDeferred 参数则涉及 prompt 构造策略:将工具 schema 延迟到搜索后才注入可以节省初始 prompt 的 token 占用,但对于必须立即可用的工具(如核心编辑操作),设为 false 确保其始终出现在上下文中更为可靠。
修复会话与上下文管理中的隐患
会话稳定性是这次更新的重点。几项修复直接影响长时间运行会话的可靠性:
- 修复了 Claude 在上下文压缩(context compaction)前,有时会把自己最后的操作误判为已完成,从而撤销或重做已完成工作的问题。这类错误在长会话中极易造成成果丢失。
- 修复了一处内存泄漏:HTTP MCP 连接会一直保留它发送过的每一个请求,直到连接关闭。
- 修复了在 Claude 工作时发送的消息,在用
←将会话移至后台后丢失的问题;现在若排队消息无法移动,←会保持原状并给出提示。
此外,/model 的 effort 档位切换曾存在跨越最高/最低档位时错误循环的问题,可能意外将 Low 保存为模型默认 effort,这一缺陷也已修复。
上下文压缩(context compaction)是指当对话历史接近模型上下文窗口上限时,系统自动对早期内容进行摘要或裁剪,以腾出空间继续对话。这一机制在长时间运行的编程会话中非常常见,但也可能导致模型对「当前状态」产生误判——尤其是当压缩边界恰好落在某个操作序列的中间时,模型可能将部分已执行步骤误判为未完成,进而触发重复或撤销行为。HTTP MCP(Model Context Protocol)是 Anthropic 推进的一种标准化协议,用于将外部工具和数据源接入 Claude,通过 HTTP 长连接维持工具服务的持久连接;此次修复的内存泄漏意味着旧版本在高频工具调用场景下,连接侧的内存占用会随会话时长线性增长,直到连接关闭才释放。
针对终端交互与 Vim 模式的细节打磨
作为一款命令行工具,Claude Code 对终端交互体验的重视在这次更新中体现得淋漓尽致:
- 修复了
←在 prompt 中还有未发送文本、或正在等待用户回答问题时,10 秒后仍将会话移至后台的问题(现在会取消移动)。 - 修复了粘贴文本首尾为相同词时,有时会被当作手动键入发送给 Claude 的问题。
- Vim 模式也获得多项修复:
>>和<<作用于全空格行时光标越界、Visual 模式删除整行后光标定位与.重复行为等,都得到了修正。
这些看似琐碎的交互修复,恰恰是提升日常使用流畅度的关键,也说明团队在持续倾听重度用户的反馈。
企业与 Slack 集成(Claude Tag)的改进
面向团队与企业用户的功能同样有所推进。启动流程针对 Team 和 Enterprise 组织做了优化:策略与托管设置被更早拉取,停滞的请求会在 3 秒后重试。
在 Claude Tag(Slack 集成)方面:
- 修复了在跨工作区共享的 Enterprise Grid 频道中,Claude 错误提示工作区未设置的问题。
- 将每个工作区及组织级 Slack 页面的频道规则上限从 20 条提高到 50 条。
- 调整了 Claude 加入仅管理员可发帖的公告频道时的行为——不再发布介绍消息。
Code Review 功能也改进了「添加仓库」对话框,会列出每个无法添加的仓库及原因(如缺少 GitHub 写权限)。
两处值得留意的回退
这次更新并非只做加法。团队回退了两项此前的改动:
- 回退了 2.1.281 中关于 auto 模式拒绝消息的改动(原本告诉 Claude 拒绝针对的是结果而非具体命令)。
- 回退了 2.1.290 中针对云会话在容器重启丢失待处理
/loop唤醒或计划任务后仍保持休眠的修复——现在 Claude 不再被告知,会话保持休眠。
回退本身是软件迭代中的常规操作,说明此前修复可能引入了新的副作用。对于关注云会话调度的用户,这一点值得留意。
小结
v2.1.293 是一次典型的「新能力 + 大量打磨」版本。Haiku 5.5 的加入为低成本、长上下文场景提供了新选择,而占据更新列表绝大部分篇幅的修复项,则集中解决了会话丢失、工具可见性、权限一致性和终端交互等实际痛点。对于将 Claude Code 深度集成到工作流的开发者和团队,建议及时升级以获得更稳定的使用体验。
相关推荐

Claude国内使用与充值全攻略:三种方式对比及防封控指南
整理Claude国内使用与会员充值的三种方式:海外信用卡直充、苹果美区ID与安卓Google Play内购、网站自助充值,对比各自门槛、成本与封控风险,并给出固定设备、稳定IP、不共享账号等五条降低封号概率的使用习惯。

从ChatGPT内容限制到Eval、可观测性与Guardrail实战
通过电子商店订单Agent实战,讲解ChatGPT内容限制背后的工程逻辑,以及Eval评估、Observability可观测性和Guardrail护栏如何协作,避免同名用户数据泄露与提示注入风险。

LangChain4j决策模型:本地校验Java工具调用
LangChain4j社区提出决策模型方案,在本地对Java工具调用进行校验,将控制逻辑从LLM拉回应用侧,提升工具调用的可靠性与可调试性。