Agent 旁路活要不要降 effort？Claude Code 新增了一个分流口

你让 Claude Code 处理一个复杂改动，主会话开着高 effort。它一边读架构、一边追调用链，旁边又顺手派了几个小活：搜一遍文件、归纳测试日志、找一份接口文档、把 diff 摘成几行摘要。

问题来了：这些小活也要跟着主任务一起高 effort 吗？

很多人会说，既然模型在干活，那就把推理档位开高，别省这点。可真正跑过多 Agent 的人都知道，旁路任务一多，拖慢你的常常不是最难的判断，而是一串本来十几秒就该回来的检索、整理和检查。它们占着队列、消耗预算，还会把主任务的等待感拉得很长。

Anthropic 今天发布的 Claude Code v2.1.318，给模组里的 $.model.fork 加了一个 effort 选项。官方描述很直接：一个快速的旁路任务可以固定跑在 low，不用继承当前会话的 effort；结果里还会回报实际发送的档位。

这不是“把 Agent 都调低”的按钮。它更像是在提醒我们：主任务的思考深度，和每个分叉任务需要的思考深度，本来就不是一回事。

图：Claude Code v2.1.318 的官方发布说明，列出了 fork 的独立 effort、登录到期字段与预警。

先把“旁路活”从主任务里认出来

一个主任务开高 effort，通常是因为它正在做不可轻率的选择：怎么改架构、哪一段代码该删、两个实现方案怎么取舍、一次迁移会不会破坏生产数据。它需要把上下文和约束反复咀嚼。

但它派出去的工作，未必都属于这一类。

比如，让子 Agent 在仓库里找出所有 retry 的实现、把 200 行测试输出压成失败原因、读取一篇文档后列出相关 API、比较两个文件的导出符号。这些工作仍要准确，可它们的结果大多可复查、可重跑、可被主 Agent 拒绝。把它们放到 low，并不等于放弃质量；你是在把昂贵的推理留给真正影响下一步决策的地方。

这里有一个比“任务大小”更好用的判断法：看它的结果能不能直接改变系统状态。

任务类型	适合先尝试低 effort 的条件	不该贸然降档的原因
搜索代码、读文档、整理日志	输出只是线索或摘要，主任务还会复核	如果检索遗漏会直接决定删改范围，就要提高档位或加二次检查
跑只读检查、汇总测试失败	命令本身不写入，结果可重新运行	涉及安全扫描、发布门禁时，结论要能追溯到原始证据
生成候选方案、起草说明	只是供主任务挑选的草稿	一旦草稿会被自动发送、合并或写回配置，就不再是轻活
写代码、改权限、执行迁移	—	会改变仓库、账户、数据或外部系统，仍应保留高 effort 和明确验收

这张表不是 Claude Code 的官方任务分类，而是一条实用的调度线：可逆、可复跑、由主任务验收的工作，才有资格先试低 effort。

图：旁路检索可以走快通道，真正会影响代码、权限或交付的任务仍应留在严格复核的路径上。

别把“省推理”做成“省验收”

最容易翻车的地方，是看到 low 之后，把所有子 Agent 都当成廉价后台队列。可旁路任务即便速度快，也会把信息带回主任务；如果它漏读了一个配置、把一条失败日志归错因，主任务会在错误线索上继续推理，最后省下来的时间会变成返工。

所以低 effort 的任务，最好同时满足两个条件：输入边界清楚，输出格式固定。

拿“搜代码”为例，不要只丢一句「找一下跟缓存有关的地方」。更稳的写法是把范围和回传格式压死：限定目录、限定关键词、要求列出文件路径和相邻函数名，并要求它报告没有找到什么。主任务拿到的是一组能快速校对的事实，不是一段洋洋洒洒的判断。

真正需要高 effort 的，则要把验收留在它身边。比如要改认证流程、合并多处重试逻辑、决定是否接受一个安全例外时，旁路 Agent 可以收集证据，最后的权衡仍交给主任务或人。把“找材料”和“签字”拆开，才是多 Agent 变快以后还能保持可控的原因。

这次发布里还有一处很适合放进无人值守流程。官方说，后台子 Agent 的 shell 命令运行超过 3 分钟后，会在所有提供商上转到后台，避免它长时间占住前台，导致 prompt cache 过期。它解决的是等待，不替你保证结果正确。跑得久的检查、构建和抓取，依然该有超时、退出码和结果文件，别只盯着对话框里有没有一句“完成了”。

另一个小改动，反而更该进你的监控

v2.1.318 还把保存的 claude.ai 登录到期时间放进了 claude auth status 的 loginExpiresAt，也放进了非交互 JSON 输出的 credential_expires_at。从到期前 10 天起，claude -p 的文本输出会给一条 stderr 预警。

这类更新看上去很琐碎，实际很像一块提前亮起的仪表灯。无人值守任务最难受的失败，不是明确报错，而是半夜开始全失败、第二天才发现凭据早就临近失效。现在能读到日期，至少可以把它放进每日健康检查：提早通知、安排重新登录、再用一个小的只读任务确认凭据真的可用。

发布说明里还修了多项与共享目录、配置锁和非交互任务有关的问题：网络家目录写配置失败时不该悄悄报成功；某些 API 错误截断回复时，claude -p 和 Agent SDK 也不该伪装成成功。它们和 effort 不是同一件事，却指向同一个现实：Agent 跑得越自动，越不能把“有输出”当成“已经交付”。

我的建议是把升级后的检查分成两层。

一层管调度：为可逆的旁路任务试 low，记录耗时、实际 effort 和主任务是否仍能一次验收通过。

另一层管可靠性：保留原始日志、检查退出码、把凭据到期预警接到通知里；涉及写入、权限、发布和安全判断时，不因为旁路任务更快就取消人工或主任务的最后确认。

Claude Code 这次给的不是一颗性能魔法豆。它只是终于把一个本来该由调度层决定的问题，露成了一个可以配置、可以观测的接口。

你自己的 Agent 流程里，哪一项一直跟着高 effort 慢慢跑，其实只是一次可复查的检索或整理？

小岛 AI