如果你最近在 Claude Code 里输入过 /effort，可能注意到菜单底部多了一个叫 ultracode 的选项——也可能根本没看到它，然后疑惑这东西到底存不存在。再加上社区里 ultrathink、xhigh、max 几个词经常被混着说，很容易越看越糊涂。
这篇文章把这几个概念一次性讲清楚：ultracode 到底做了什么、怎么开（以及哪些看起来能开实际没用的方式）、各订阅档位能不能用、真实的 token 开销有多大，以及最重要的——什么时候值得用，什么时候纯属烧钱。
Ultracode 到底是什么
按 Anthropic 模型配置文档的说法：「Ultracode 是一个 Claude Code 设置，而非模型的 effort 级别：它向模型发送 xhigh，并额外让 Claude 为实质性任务编排动态工作流。它只对当前会话生效。」
也就是说，ultracode 同时做两件事：
- 把每条消息的推理努力固定在
xhigh级别； - 开启自动工作流编排——由 Claude 自行判断哪些任务值得拆分给多个子智能体并行处理。
工作流编排针对的是单上下文窗口在大任务上的三个可预见的失败模式：提前收工（大范围任务没做完就宣布完成）、自我评估过于宽容（自己检查自己的产出天然有偏向）、目标漂移（长对话中逐渐偏离最初的目标）。把工作分摊给多个拥有独立上下文窗口的隔离智能体后：任务清单写在编排脚本里，防止提前终止；验证交给与产出无利害关系的智能体，消除自我偏向；每个智能体只聚焦自己那一小块，在上下文压缩发生前就完成了任务。
Anthropic 的工作流文档里举的例子是：「一个理解代码，一个做修改，一个做验证。这套机制应用于会话中的每个任务，所以每次请求都会比低 effort 级别消耗更多 token、花更长时间。」
关于动态工作流本身的详细介绍，可以看我之前写的Claude Code 动态工作流指南。
Ultracode vs xhigh vs max vs ultrathink
| 设置 | 是什么 | 发给 API 的 effort | 触发工作流？ | 作用范围 | 跨会话保留？ |
|---|---|---|---|---|---|
xhigh |
模型 effort 级别（深度推理，token 消耗较高） | xhigh |
否 | 会话级设置 | 是 |
max |
模型 effort 级别（最深推理，无 token 上限） | max |
否 | 会话级设置 | 否（仅当前会话） |
ultrathink |
单轮提示词关键词，请求更深推理 | 不变 | 否 | 仅单轮 | 不适用（不是设置） |
ultracode |
Claude Code 设置：xhigh + 自动编排 |
xhigh |
是（自动） | 会话级设置 | 否（仅当前会话） |
最容易混淆的是 ultrathink 和 ultracode。ultrathink 是一个单轮提示词关键词——把它打在提问里，只会给那一轮加一条「推理深一点」的上下文指令。它不修改会话的 effort 级别，不改变发给 API 的 effort 值，也不触发任何工作流。它就是一次局部的推理加强，只影响那一次交互。它不是设置项，所以你在任何菜单里都找不到它。
Ultracode 正好相反：它是一个贯穿整个会话的模式，把 effort 锚定在 xhigh，并且——这是关键——在关闭之前会为每个重要任务自动编排工作流。前者是单轮的推理增强，后者是重构 Claude 行为方式的会话级模式。虽然两个词长得像，背后是完全不同的机制。
再用失败模式的框架看 xhigh 和 ultracode 的区别就很清楚了：两者发送的都是 xhigh，基础推理能力完全一样。但单独的 xhigh 仍然跑在一个孤立的上下文窗口里，在大任务上照样会提前收工、自我偏向、目标漂移。Ultracode 多出来的那层自动工作流，正是从结构上消除这些隐患的部分。如果你只想要更深的推理、不想让 Claude 自己拉起一堆并行子智能体，直接设 xhigh、不开 ultracode 就行。
Claude Code 的 effort 阶梯
Effort 级别控制的是自适应推理——让模型自己决定每个动作要不要思考、思考多深。完整的阶梯如下：
| 级别 | 适用场景 | 跨会话保留 |
|---|---|---|
low |
简短、范围明确、对延迟敏感且不吃智力的任务 | 是 |
medium |
对成本敏感、可以牺牲一点智力的工作 | 是 |
high |
大多数编码工作的平衡默认值，也是多数模型的默认级别 | 是 |
xhigh |
更深的推理，更高的 token 消耗 | 是 |
max |
最深推理，无 token 上限。容易过度思考，采用前先测试 | 否（仅当前会话） |
ultracode |
xhigh + 对实质性任务自动编排动态工作流 |
否（仅当前会话） |
前五档只改变孤立窗口内的推理强度，唯独 ultracode 还会改变执行架构——把工作从单一窗口重新分配到多个并行进程。它排在阶梯顶端，不是因为「想得更深」，而是因为它是唯一一个解决结构性失败模式、而非只做内部优化的级别。
需要注意的是，并非所有模型都支持完整的阶梯——xhigh 只在部分模型上可用。由于 ultracode 发送的就是 xhigh，它只会出现在支持 xhigh 的模型的 /effort 菜单里；在不支持 xhigh 的模型（比如一些较早的版本）上，ultracode 整个选项都不会出现。模型迭代很快，某个模型到底支不支持，最可靠的判断方法就是看你本地 /effort 菜单里有没有 ultracode 这一项。我自己实测，目前最新的 Fable 5 是支持 ultracode 的。
怎么开启 Ultracode
有三种方式有效，还有三种看起来能行、实际无效。
有效的三种：
最直接的是 /effort 菜单。运行 /effort 打开调整界面，或者直接：
/effort ultracode
也可以通过设置传一个布尔值——启动时用 --settings，或通过 Agent SDK 的控制请求：
{ "ultracode": true }
无效的三种：
- 设置文件里写
"effortLevel": "ultracode"—— 静默无效果 --effort命令行标志 —— 不识别CLAUDE_CODE_EFFORT_LEVEL环境变量 —— 不识别
官方文档的原话是：ultracode「不属于 effortLevel 设置、--effort 标志或 CLAUDE_CODE_EFFORT_LEVEL」——它是会话级的，走的是另一套机制。
「仅当前会话」这个特性值得强调：ultracode 在当前会话内一直有效，开新会话后回到默认值。Anthropic 的原话是：「回到日常工作时，用 /effort high 降回去。」它不像 high 或 xhigh 那样跨会话保留——这是有意的设计：昨天开的多智能体审计级编排，不该悄悄延续到今天改个错别字的小活上。
如果只想让某一个任务走工作流、又不想把整个会话切到 ultracode，还有个办法：在提示词里任意位置加上 ultracode 这个关键词（v2.1.160 之前的版本用的是 workflow），或者直接用自然语言说「用 workflow 跑这个」，Claude Code 就会把那个任务作为工作流执行，不改变会话的 effort 级别——可以理解为单次请求版的 ultracode。如果关键词被误触发，按 Option+W（macOS）/ Alt+W（Windows/Linux）可以跳过本条提示的触发，或在高亮文字后立即退格删除。想彻底关掉这个触发器，在 /config 里禁用「Ultracode keyword trigger」。
订阅档位与模型可用性
Ultracode 依赖的动态工作流在所有付费订阅档位上提供，也覆盖 Anthropic API、Amazon Bedrock、Google Vertex AI 和 Microsoft Foundry。默认开关状态因档位而异：
| 订阅 | 工作流默认状态 | 开启方式 |
|---|---|---|
| Pro | 关 | 在 /config 里打开 Dynamic workflows 那一行 |
| Max | 开 | 开箱即用 |
| Team | 开 | 开箱即用 |
| Enterprise | 关 | 需要管理员先开启 |
注意 Pro 用户并没有被排除在外——「工作流编排是 Max 以上专属」是个常见的错误假设。Pro 订阅者在 /config 里开启后，在支持 xhigh 的模型上同样可以使用 ultracode。
有两个前置条件卡着所有人：第一，Claude Code 版本至少 v2.1.154，旧版本先跑 claude update；第二，只有工作流处于开启状态时，ultracode 才会出现在 /effort 菜单里。通过 /config 开关、设置里的 "disableWorkflows": true，或环境变量 CLAUDE_CODE_DISABLE_WORKFLOWS=1 任一方式禁用工作流，ultracode 都会从菜单里彻底消失——编排组件没有基础设施可用，ultracode 自然也就不存在了。
Token 成本：必须正视的一笔账
这部分最重要，需要讲得准确、讲得平衡。
官方对成本的表述很直白：工作流会拉起大量智能体，所以「单次运行消耗的 token 可能明显多于在对话里完成同一个任务。运行计入你订阅的用量和速率限制。」而 ultracode 一旦开启，这个乘数效应作用于会话中的每一个重要任务，不是你挑出来的那几次。击败三大失败模式靠的是隔离，而隔离正是 ultracode 贵的原因：每次都在供养一群智能体，而不是一个。
一个经常被忽略的关键信息：默认没有任何花费上限。你可以显式给 token 预算（比如「用 10k token」会设一个天花板），但没设预算的工作流是「答案收敛了才停」，不是「花到固定额度就停」。这对需要反复证伪、反复检查直到结论稳定的难题很有价值；但在简单任务上就成了问题——没有任何内在保护机制阻止系统判定「这个小活值得派九十个智能体」。
社区的反馈也呈现出这种两面性（以下是使用者的个人记述，不是 Anthropic 的官方数据，仅作为案例参考）：有 Hacker News 用户报告「拉起了 62 个子智能体，18 分钟就打满了 5 小时的用量上限」；另一位描述约 90 个智能体在执行一个小的依赖包评估；更尖锐的批评者称其为「包装成产品的 tokenmaxxing」；也有人记录了可靠性问题，比如运行「动不动就放弃」。另据 findskill.ai（引用 r/ClaudeAI）的记录，有 Max（$200/月）用户第一天就消耗了接近 20% 的周度 token 配额，有 Pro 订阅者约十分钟就打满了上限。评价分裂得很清楚：对真正的大型工作极其能打，对简单工作极其容易超支。
应对方法也很直白：上正式工作负载前先测。先用范围明确的小任务跑一跑 ultracode，观察它怎么拆解任务、拉起多少子智能体，再对照你的真实工作量评估预算是否扛得住。Anthropic 也针对更重的工作流用量扩大过 Claude Code 的速率容量，之前经常撞限的用户能拿到更大的额度。
什么时候用 Ultracode（以及什么时候别用）
判断标准和动态工作流指南的结论一致：这个任务真的需要额外的处理量吗？ 普通的编码任务通常不需要一个五人评审小组。把 ultracode 留给那些本来就会交给多名工程师并行处理的工作——任务天然可以拆解、独立视角的交叉验证确实有价值的那种。一个人一个下午能干完的活不值得上 ultracode，high 或 xhigh 下的单智能体才是合适的工具。
适合用 ultracode 的场景：
- 横跨整个代码库的审计（安全、废弃代码、性能），完整性比速度重要，单窗口的「提前收工」会漏掉文件
- 涉及数百个文件的迁移，合入前需要对所有改动做全面验证
- 对方案做多角度压力测试，让独立的智能体尝试推翻这个方案
- 风险高到值得为对抗性验证付费的场合
不适合的场景：
- 单智能体一遍就能做完的任务——没有需要修补的失败模式，token 开销与收益不成比例，验证延迟也是白等
- 角色分工已经预先定好的场合——如果你已经定义了「前端、后端、质量」这样的角色，刻意配置的智能体团队比让 Claude 自主编排可控得多（三种编排方式的对比见这篇）
- 日常修修改改——ultracode 对每个重要任务一视同仁地上工作流，不管实际需不需要
还有几个运行层面的事项值得知道。工作流子智能体始终以 acceptEdits 模式运行，并继承会话的工具权限，与你的权限配置无关——也就是说工作流内部会自动改文件。并行智能体改同一个文件会冲突，所以涉及文件修改的并行任务会被隔离到独立的 worktree 里。运行中途无法人工干预转向，没法实时给智能体纠偏。不过运行本身有韧性：可以中断后暂停再恢复，被打断的进程从最后完成的位置继续而非从头重来，靠的是 run ID 的缓存回放而不是重新计算。如果要无人值守地跑工作流，可以把 ultracode 和 Auto Mode 组合：在 Auto 权限模式下，ultracode 开启时每次运行的工作流授权提示会完全消失。
执行环境也有保护机制：工作流的并发智能体上限为 16 个（资源受限的机器上更低），单次执行总智能体上限 1000 个，作为失控循环的保险。工作流编排器本身没有文件系统和 shell 访问权，只有派生出去的智能体才接触系统和目录。这些边界限制的是破坏潜力，但没有 token 上限——成本纪律的责任在用户自己。
常见问题
Ultracode 和 ultrathink 有什么区别？
完全不同的机制。ultrathink 是单轮提示词关键词：写进提示里只对那一轮触发更深推理，不改会话 effort，不改发给 API 的 effort 值，不触发工作流。Ultracode 是会话级设置，把 effort 锚定在 xhigh 并对会话中每个重要任务自动编排动态工作流。一个是局部的推理加强，一个是从根本上重构 Claude 工作方式的模式。
Ultracode 跨会话保留吗？
不保留。只对当前会话生效，新会话开始时重置。Anthropic 建议回到日常工作时用 /effort high 降回去。low / medium / high / xhigh 跨会话保留；max 和 ultracode 都只在当前会话有效。
管理员能为整个组织禁用 ultracode 吗？
可以，间接地。Ultracode 依赖动态工作流，组织管理员可以通过托管设置或 Claude Code 管理界面在全组织范围禁用工作流。工作流一禁，ultracode 自动从 /effort 菜单消失。
Ultracode 有花费上限吗？
没有。不存在预设的 token 上限，工作流运行在答案稳定时收敛，而不是在固定 token 额度处停止——开销在设计上就是开放式的。运行计入订阅用量和速率限制。实际的管理办法是：先用小范围任务校准，观察子智能体数量，再据此决定预算。
Ultracode 对模型有要求吗？
有。它要求当前会话的模型支持 xhigh effort——不支持 xhigh 的模型，/effort 菜单里完全不会出现 ultracode。模型更新很快，与其记某个版本号支不支持，不如直接打开 /effort 看菜单里有没有这一项（实测最新的 Fable 5 支持）。
Pro 用户能用 ultracode 吗？
能。动态工作流向包括 Pro 在内的所有付费订阅档位提供。Pro 用户先在 /config 的 Dynamic workflows 行开启工作流，之后在支持 xhigh 的模型上，ultracode 就会像其他档位一样出现在 /effort 里。
一句话总结
Ultracode 是 /effort 阶梯上最高的一档，也是唯一一个重构 Claude 行为方式（而非单纯加深思考）的级别。这个会话级的工作流开关从结构上消除了单窗口上下文在大任务上的三个失败模式——提前收工、自我偏向、目标漂移。对于天然适合拆给多名工程师的审计、迁移和方案压力测试，它提供了实打实的能力；同时它也是最容易超支的设置，因为自动工作流作用于每个实质性任务，且没有 token 上限兜底。Bun 团队的 Zig 转 Rust 移植（约 75 万行 Rust，首次提交到合并 11 天，测试套件通过率 99.8%）展示了这种编排能力的规模上限——但大多数团队不会去移植一个运行时，他们要做的是逐任务判断：这个活，值不值得按「等效于多名并行工程师」的 token 价格来买。
把 ultracode 当成一个深思熟虑的选择，而不是默认状态：值得的工作才开，先用小任务校准成本，回到日常修改时记得 /effort high 降回去。
关于
关注我获取更多资讯
