1. 上下文爆满的三个信号摘要被谁换成了完整轨迹Inngest 联合创始人 Dan Farrelly 曾提出过一个观点一个真正能投入生产的 AI Agent 系统最终都需要三种 sub-agent 模式——同步执行并等待、异步执行后汇报、定时延后执行。这个结论本身不难理解但我发现一个更普遍的现场演示环境里 Agent 一切正常一旦放进生产环境跑不了几轮上下文窗口就爆满响应也跟着变慢。我最近排查一个类似问题时先把 Claude Code 和 Codex 的模型通道统一切到了 TaoToken在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建了排查用的 Key再按 Dan 说的三种模式逐项核对才定位到真正的泄漏点不在 sub-agent 数量而在子任务结果回传的方式和模型通道的重试机制。演示环境的问题在于对话短、任务少、上下文干净。生产环境则是长对话、多任务、频繁中断恢复任何一个环节把完整轨迹塞回父 agent都会让窗口加速耗尽。与其盲目调模型或换更长上下文不如先检查三个信号。1.1 信号一sub-agent 返回的是「报告」还是「日志」Dan 对 sub-agent 的定义很关键它是父 agent 生成的独立 LLM 执行上下文处理完任务后父 agent 应该只看到一份摘要而不是完整执行轨迹。你可以在自己的 Agent 里加一行日志打印 sub-agent 返回的工具结果如果里面是「做了什么、结论是什么、建议的下一步」说明压缩正常如果返回的是「读了哪几个文件、逐行改了什么、中间调用了哪些工具、每步输出是什么」那这份结果本身就是上下文杀手。一个 sub-agent 可能内部读了 8 个文件、做了 15 次工具调用但父 agent 应该只拿到几百 token 的摘要。很多实现不是没有用 sub-agent而是用了却把 sub-agent 的完整 stdout 或工具调用日志当作返回值交还父 agent上下文压缩形同虚设。1.2 信号二所有调用都被同步等待异步被写成了空同步模式本身没有错它适合父 agent 必须拿到结果才能继续的场景。但如果你把每个任务都设计成「等待结果再继续」父 agent 的上下文里就会同时堆积多个任务的摘要。Dan 的决策框架写得清楚需要结果才能继续用同步独立任务不阻塞用异步不确定默认异步。异步模式下父 agent 启动 sub-agent 后立即继续对话sub-agent 完成后再通过渠道回复用户父 agent 完全不需要吸收结果。如果你检查代码发现所有 sub-agent 都被await或等价机制阻塞那等于放弃了异步模式最大的收益——零协调开销和免费并行。更重要的是异步 sub-agent 完成后直接把结果发给用户根本不进父 agent 上下文这才是生产环境长对话能持续跑下去的原因。1.3 信号三模型通道超时重试把无效 token 一遍遍叠加上下文爆满还有一个容易被忽略的源头模型请求超时或报错后Agent 框架自动重试。重试时之前已经生成的中间内容还留在上下文里重试一次就多叠加一轮几次重试下来即使每个 sub-agent 都只返回摘要父 agent 的 token 消耗也会异常膨胀。这种情况常见于多 Key 切换、额度用尽、网络超时这些「通道问题」。排查时我先确认请求是否稳定走同一条通道再把 Claude Code 和 Codex 的 Base URL 统一指向 https://taotoken.net/api注意末尾不带/v1避免因为通道不稳触发重试风暴。通道稳定之后上下文消耗的增速明显下降这时候再回过头看三种模式问题就清楚多了。2. 排查前先统一模型通道拿 Key、填 Base URLAgent 的上下文策略要结合真实请求来看因此排查前先把工具连到同一个可观察的通道上。TaoToken 在这里扮演的是统一 API 通道注册、创建 Key、查模型 ID 都在官网完成而工具里填的接入地址是另一个。2.1 到 TaoToken 创建一把排查专用 Key打开 TaoToken注册登录后进入控制台创建 API Key。排查期间建议单独建一把 Key不要和线上业务混用这样看用量的时候能清楚区分这次调整前后的调用差异。Key 的占位符统一写成YOUR_API_KEY后文配置直接替换。模型 ID 不要照抄任何博客或截图里的历史版本以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场当时列表为准。原因是模型 ID 会随供应商更新而变化写死一个过期 ID 会得到 404 或 model not found反而干扰排查。2.2 Base URL 写接口地址不写官网首页这是一个容易混淆的地方官网落地页用于注册、创建 Key、看模型广场、看用量但填进 Claude Code、Codex 或 CC Switch 的 Base URL统一是https://taotoken.net/api末尾不要加/v1也不要带任何 UTM 参数。如果你在某个工具里看到别的教程让你填https://taotoken.net/v1那是旧版遗留现在按/api写。区分两条线人访问的入口是带utm_sourcetaotoken_aicg_blog_end的官网页面程序访问的入口就是https://taotoken.net/api。2.3 不同工具读不同配置Claude Code 读的是~/.claude/settings.json里的env块通过ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_MODEL三个环境变量指向 TaoToken。Codex 不走ANTHROPIC_*变量它读~/.codex/config.toml用model_provider和base_url定义供应商。CC Switch 作为图形化切换工具需要手动添加一个自定义供应商再填 Base URL、Key、模型 ID 三件套。下面第 4 章会给出每个文件的完整写法。3. 对照原文三种模式逐项检查自己的 Agent 上下文策略拿到可用通道后让 Claude Code 或 Codex 作为一个分析助手把你自己项目的 Agent 代码或日志喂给它按三种模式逐一过。重点不是让它重写代码而是让它按下面的标准回答父 agent 的上下文里到底进了什么。3.1 同步模式确保父 agent 只收到摘要且命令足够简洁同步模式最像函数调用父 agent 生成 sub-agent、阻塞等待、拿到结果继续。检查点有两个。第一sub-agent 的工具描述里是否明确写了「返回给父 agent 的内容必须是摘要控制在 500 token 以内」Dan 的做法是给同步 sub-agent 的框架指令要求「简洁」因为父 agent 会负责综合。第二返回结果里是否混入了完整文件内容或完整工具输出。第二点更隐蔽很多框架自带的 sub-agent 工具会默认把「执行日志」一并放进 result这部分要在工具实现里单独剥离。我在排查时发现多数上下文爆满并非来自同步 sub-agent 本身而是它的返回结构里嵌套了大量中间数据。只要把返回结果从「日志型」改成「报告型」父 agent 的上下文压力立刻小很多。3.2 异步模式确认父 agent 真的没有等待异步模式的检查重点是「父 agent 是不是假异步」。表面写了start_subagent后面却跟着一个轮询状态并阻塞的循环效果等同同步还白白损失了并行能力。正确做法是sub-agent 运行结束后发送事件通过渠道直接把结果交给用户。父 agent 不做综合、不做二次加工也不在上下文里保留执行痕迹。Dan 原文里有一个判断标准如果你启动三个异步 sub-agent每个都在完全隔离中运行父 agent 无法在同一轮里跨它们做综合。这是特性不是缺陷。如果你的代码试图把三个异步结果拉回来做统一总结那要么把它变成同步模式要么彻底交给用户。排障时最容易发现的错误是代码里异步 sub-agent 结束后又回调父 agent 做「确认」这等于绕过压缩边界。3.3 定时模式执行时拉最新数据而不是发送旧快照定时模式真正有价值的地方在于它「到点才执行」比如提醒明天上午 9 点检查部署指标不是那时候发一条写好的提醒而是到点运行一个能拉实时指标的 sub-agent再输出分析。它的上下文收益建立在「不预先占用父 agent 上下文」之上执行时使用世界当前状态而不是创建任务时的快照。检查你的定时任务如果触发时只是把用户当时的对话历史原样转发说明它退化成了普通定时器。正确的日志特征应当是「任务创建时 100 token 的上下文触发时用 1000 token 拉取实况再生成结果」两者隔离。如果定时 sub-agent 的上下文中包含了创建时父 agent 的全部上下文压缩就没生效。4. 可落地的配置示例settings.json、config.toml 与 CC Switch排查工具本身连不通后面的分析都无从谈起。下面三份配置都经过验证按你当前使用的工具选一份填入即可。模型 ID 统一用YOUR_MODEL_ID占位实际填写时以 TaoToken 模型广场当前列表为准。4.1 Claude Code修改 ~/.claude/settings.json在配置文件的env块里加入 Base URL、Key 和模型 ID。注意 Base URL 不能带/v1也不能在这里追加任何导航参数。{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_MODEL_ID } }保存后重新启动claude对话输入一条和上下文策略相关的提问观察请求能否正常返回。遇到 401 检查 Key 是否复制完整遇到 404 检查YOUR_MODEL_ID是否和模型广场一致。4.2 Codex修改 ~/.codex/config.tomlCodex 使用model_provider定义自定义供应商然后用model字段指定模型 ID。不要把上一节的ANTHROPIC_*变量套到 Codex 上。model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api api_key YOUR_API_KEY启动codex后先让它读一段你自己的 Agent 日志并说明上下文构成。如果 Codex 反馈连接失败优先确认base_url是否多写了/v1。4.3 CC Switch添加自定义供应商使用 CC Switch 时在自定义供应商界面新增一条记录供应商名称TaoTokenBase URLhttps://taotoken.net/apiAPI KeyYOUR_API_KEY模型 ID以 TaoToken 模型广场当前列表为准保存后把当前配置切换到这条供应商再打开 Claude Code。CC Switch 的优势是可以在官方通道和 TaoToken 之间快速来回切排查时适合做 A/B 对比同一段对话官方通道重试几次TaoToken 通道重试几次看上下文消耗差异。5. 验证一次真实调用从对话页到控制台用量配置完成不代表上下文策略正确必须用一次真实调用验证通道再用量数据佐证。5.1 先用模型对话页验证 Key 与模型 ID在正式回到 Agent 排查之前先在 模型对话页 用同一把YOUR_API_KEY发一条测试消息。这一步能快速排除三种低级问题Key 复制不完整、模型 ID 过期、Base URL 填错。对话页验证通过后再回到 Claude Code 或 Codex问题范围就只剩工具侧配置。5.2 在 Agent 里跑短任务回控制台看 token 消耗让 Agent 执行一个只触发单个 sub-agent 的短任务例如「读取项目里某个模块的入口文件生成一份 300 字以内的改动风险评估」。任务结束后打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 进入控制台查看这次调用的用量记录。正常情况应当是一次请求内包含少量父 agent 上下文输出sub-agent 的完整执行过程不重复出现在父 agent 的 token 明细里。如果你看到父 agent 那一次请求的 token 数异常大基本可以断定 sub-agent 返回值把中间结果带回了父 agent。用量数据比日志更直观适合用来验证排查结论。6. 排障之后的架构建议三条来自原文的检查线通道稳定、上下文策略确认无误之后再回头看 Dan 原文里几个容易被忽略的设计原则。它们不会直接出现在报错信息里但决定了你的 Agent 系统能否长期维持精简状态。6.1 默认异步不确定时不要阻塞Dan 的决策框架里有一句经常被跳过「不确定默认使用异步它更便宜让父 agent 保持精简。」生产环境里大多数子任务并不需要父 agent 立即拿到结果。所谓的「不放心」往往来自对异步回调链路缺乏观测手段而不是任务本身必须同步。给每个异步 sub-agent 的事件 ID 打上 trace 日志父 agent 就能随时查到任务状态没必要靠阻塞来获得安全感。6.2 深度保持 1sub-agent 不能再生成 sub-agentDan 团队把委托深度限制为 1sub-agent 拥有工作空间工具但不能生成下一层 sub-agent。这个约束避免了递归失控。如果你发现自己的系统出现了两层甚至三层嵌套委托先不要继续优化每一层的提示词直接把深度裁到 1。绝大多数任务用一个 sub-agent 就能完成嵌套只是让上下文的压缩链条多出几个不可控节点。6.3 用两个工具代替 mode 参数让模型自己选择最后一个建议来自 Dan 的工程细节他们用两个独立工具而不是一个带mode参数的工具。原因是模型在工具选择上的表现比阅读参数描述后正确选择更稳定独立工具也带来更清晰的日志和追踪。同步与异步的工具描述写清楚「何时使用」把决策权交给模型。你可以在自己项目里检查现有 sub-agent 工具的签名如果只有一个mode: sync|async|scheduled字段改成三个独立工具后模型选错模式导致的上下文膨胀通常会明显减少。排查完成后这次调用到底消耗了多少 token、是否需要为后续长期任务准备更大额度可以在 Coding Plan 里查看对应套餐如果排查中需要给不同子任务分配独立 Key直接在 控制台 API Keys 继续创建。Claude Code 的环境变量对照说明以 接入文档 为准。配置层面理顺之后再对照 Dan 的三种模式检查自己的 Agent上下文爆满的问题通常能定位到具体某一段返回路径。
AI Agent 上下文窗口爆满？sub-agent 的模型通道改到 TaoToken 再查
1. 上下文爆满的三个信号摘要被谁换成了完整轨迹Inngest 联合创始人 Dan Farrelly 曾提出过一个观点一个真正能投入生产的 AI Agent 系统最终都需要三种 sub-agent 模式——同步执行并等待、异步执行后汇报、定时延后执行。这个结论本身不难理解但我发现一个更普遍的现场演示环境里 Agent 一切正常一旦放进生产环境跑不了几轮上下文窗口就爆满响应也跟着变慢。我最近排查一个类似问题时先把 Claude Code 和 Codex 的模型通道统一切到了 TaoToken在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建了排查用的 Key再按 Dan 说的三种模式逐项核对才定位到真正的泄漏点不在 sub-agent 数量而在子任务结果回传的方式和模型通道的重试机制。演示环境的问题在于对话短、任务少、上下文干净。生产环境则是长对话、多任务、频繁中断恢复任何一个环节把完整轨迹塞回父 agent都会让窗口加速耗尽。与其盲目调模型或换更长上下文不如先检查三个信号。1.1 信号一sub-agent 返回的是「报告」还是「日志」Dan 对 sub-agent 的定义很关键它是父 agent 生成的独立 LLM 执行上下文处理完任务后父 agent 应该只看到一份摘要而不是完整执行轨迹。你可以在自己的 Agent 里加一行日志打印 sub-agent 返回的工具结果如果里面是「做了什么、结论是什么、建议的下一步」说明压缩正常如果返回的是「读了哪几个文件、逐行改了什么、中间调用了哪些工具、每步输出是什么」那这份结果本身就是上下文杀手。一个 sub-agent 可能内部读了 8 个文件、做了 15 次工具调用但父 agent 应该只拿到几百 token 的摘要。很多实现不是没有用 sub-agent而是用了却把 sub-agent 的完整 stdout 或工具调用日志当作返回值交还父 agent上下文压缩形同虚设。1.2 信号二所有调用都被同步等待异步被写成了空同步模式本身没有错它适合父 agent 必须拿到结果才能继续的场景。但如果你把每个任务都设计成「等待结果再继续」父 agent 的上下文里就会同时堆积多个任务的摘要。Dan 的决策框架写得清楚需要结果才能继续用同步独立任务不阻塞用异步不确定默认异步。异步模式下父 agent 启动 sub-agent 后立即继续对话sub-agent 完成后再通过渠道回复用户父 agent 完全不需要吸收结果。如果你检查代码发现所有 sub-agent 都被await或等价机制阻塞那等于放弃了异步模式最大的收益——零协调开销和免费并行。更重要的是异步 sub-agent 完成后直接把结果发给用户根本不进父 agent 上下文这才是生产环境长对话能持续跑下去的原因。1.3 信号三模型通道超时重试把无效 token 一遍遍叠加上下文爆满还有一个容易被忽略的源头模型请求超时或报错后Agent 框架自动重试。重试时之前已经生成的中间内容还留在上下文里重试一次就多叠加一轮几次重试下来即使每个 sub-agent 都只返回摘要父 agent 的 token 消耗也会异常膨胀。这种情况常见于多 Key 切换、额度用尽、网络超时这些「通道问题」。排查时我先确认请求是否稳定走同一条通道再把 Claude Code 和 Codex 的 Base URL 统一指向 https://taotoken.net/api注意末尾不带/v1避免因为通道不稳触发重试风暴。通道稳定之后上下文消耗的增速明显下降这时候再回过头看三种模式问题就清楚多了。2. 排查前先统一模型通道拿 Key、填 Base URLAgent 的上下文策略要结合真实请求来看因此排查前先把工具连到同一个可观察的通道上。TaoToken 在这里扮演的是统一 API 通道注册、创建 Key、查模型 ID 都在官网完成而工具里填的接入地址是另一个。2.1 到 TaoToken 创建一把排查专用 Key打开 TaoToken注册登录后进入控制台创建 API Key。排查期间建议单独建一把 Key不要和线上业务混用这样看用量的时候能清楚区分这次调整前后的调用差异。Key 的占位符统一写成YOUR_API_KEY后文配置直接替换。模型 ID 不要照抄任何博客或截图里的历史版本以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场当时列表为准。原因是模型 ID 会随供应商更新而变化写死一个过期 ID 会得到 404 或 model not found反而干扰排查。2.2 Base URL 写接口地址不写官网首页这是一个容易混淆的地方官网落地页用于注册、创建 Key、看模型广场、看用量但填进 Claude Code、Codex 或 CC Switch 的 Base URL统一是https://taotoken.net/api末尾不要加/v1也不要带任何 UTM 参数。如果你在某个工具里看到别的教程让你填https://taotoken.net/v1那是旧版遗留现在按/api写。区分两条线人访问的入口是带utm_sourcetaotoken_aicg_blog_end的官网页面程序访问的入口就是https://taotoken.net/api。2.3 不同工具读不同配置Claude Code 读的是~/.claude/settings.json里的env块通过ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_MODEL三个环境变量指向 TaoToken。Codex 不走ANTHROPIC_*变量它读~/.codex/config.toml用model_provider和base_url定义供应商。CC Switch 作为图形化切换工具需要手动添加一个自定义供应商再填 Base URL、Key、模型 ID 三件套。下面第 4 章会给出每个文件的完整写法。3. 对照原文三种模式逐项检查自己的 Agent 上下文策略拿到可用通道后让 Claude Code 或 Codex 作为一个分析助手把你自己项目的 Agent 代码或日志喂给它按三种模式逐一过。重点不是让它重写代码而是让它按下面的标准回答父 agent 的上下文里到底进了什么。3.1 同步模式确保父 agent 只收到摘要且命令足够简洁同步模式最像函数调用父 agent 生成 sub-agent、阻塞等待、拿到结果继续。检查点有两个。第一sub-agent 的工具描述里是否明确写了「返回给父 agent 的内容必须是摘要控制在 500 token 以内」Dan 的做法是给同步 sub-agent 的框架指令要求「简洁」因为父 agent 会负责综合。第二返回结果里是否混入了完整文件内容或完整工具输出。第二点更隐蔽很多框架自带的 sub-agent 工具会默认把「执行日志」一并放进 result这部分要在工具实现里单独剥离。我在排查时发现多数上下文爆满并非来自同步 sub-agent 本身而是它的返回结构里嵌套了大量中间数据。只要把返回结果从「日志型」改成「报告型」父 agent 的上下文压力立刻小很多。3.2 异步模式确认父 agent 真的没有等待异步模式的检查重点是「父 agent 是不是假异步」。表面写了start_subagent后面却跟着一个轮询状态并阻塞的循环效果等同同步还白白损失了并行能力。正确做法是sub-agent 运行结束后发送事件通过渠道直接把结果交给用户。父 agent 不做综合、不做二次加工也不在上下文里保留执行痕迹。Dan 原文里有一个判断标准如果你启动三个异步 sub-agent每个都在完全隔离中运行父 agent 无法在同一轮里跨它们做综合。这是特性不是缺陷。如果你的代码试图把三个异步结果拉回来做统一总结那要么把它变成同步模式要么彻底交给用户。排障时最容易发现的错误是代码里异步 sub-agent 结束后又回调父 agent 做「确认」这等于绕过压缩边界。3.3 定时模式执行时拉最新数据而不是发送旧快照定时模式真正有价值的地方在于它「到点才执行」比如提醒明天上午 9 点检查部署指标不是那时候发一条写好的提醒而是到点运行一个能拉实时指标的 sub-agent再输出分析。它的上下文收益建立在「不预先占用父 agent 上下文」之上执行时使用世界当前状态而不是创建任务时的快照。检查你的定时任务如果触发时只是把用户当时的对话历史原样转发说明它退化成了普通定时器。正确的日志特征应当是「任务创建时 100 token 的上下文触发时用 1000 token 拉取实况再生成结果」两者隔离。如果定时 sub-agent 的上下文中包含了创建时父 agent 的全部上下文压缩就没生效。4. 可落地的配置示例settings.json、config.toml 与 CC Switch排查工具本身连不通后面的分析都无从谈起。下面三份配置都经过验证按你当前使用的工具选一份填入即可。模型 ID 统一用YOUR_MODEL_ID占位实际填写时以 TaoToken 模型广场当前列表为准。4.1 Claude Code修改 ~/.claude/settings.json在配置文件的env块里加入 Base URL、Key 和模型 ID。注意 Base URL 不能带/v1也不能在这里追加任何导航参数。{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_MODEL_ID } }保存后重新启动claude对话输入一条和上下文策略相关的提问观察请求能否正常返回。遇到 401 检查 Key 是否复制完整遇到 404 检查YOUR_MODEL_ID是否和模型广场一致。4.2 Codex修改 ~/.codex/config.tomlCodex 使用model_provider定义自定义供应商然后用model字段指定模型 ID。不要把上一节的ANTHROPIC_*变量套到 Codex 上。model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api api_key YOUR_API_KEY启动codex后先让它读一段你自己的 Agent 日志并说明上下文构成。如果 Codex 反馈连接失败优先确认base_url是否多写了/v1。4.3 CC Switch添加自定义供应商使用 CC Switch 时在自定义供应商界面新增一条记录供应商名称TaoTokenBase URLhttps://taotoken.net/apiAPI KeyYOUR_API_KEY模型 ID以 TaoToken 模型广场当前列表为准保存后把当前配置切换到这条供应商再打开 Claude Code。CC Switch 的优势是可以在官方通道和 TaoToken 之间快速来回切排查时适合做 A/B 对比同一段对话官方通道重试几次TaoToken 通道重试几次看上下文消耗差异。5. 验证一次真实调用从对话页到控制台用量配置完成不代表上下文策略正确必须用一次真实调用验证通道再用量数据佐证。5.1 先用模型对话页验证 Key 与模型 ID在正式回到 Agent 排查之前先在 模型对话页 用同一把YOUR_API_KEY发一条测试消息。这一步能快速排除三种低级问题Key 复制不完整、模型 ID 过期、Base URL 填错。对话页验证通过后再回到 Claude Code 或 Codex问题范围就只剩工具侧配置。5.2 在 Agent 里跑短任务回控制台看 token 消耗让 Agent 执行一个只触发单个 sub-agent 的短任务例如「读取项目里某个模块的入口文件生成一份 300 字以内的改动风险评估」。任务结束后打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 进入控制台查看这次调用的用量记录。正常情况应当是一次请求内包含少量父 agent 上下文输出sub-agent 的完整执行过程不重复出现在父 agent 的 token 明细里。如果你看到父 agent 那一次请求的 token 数异常大基本可以断定 sub-agent 返回值把中间结果带回了父 agent。用量数据比日志更直观适合用来验证排查结论。6. 排障之后的架构建议三条来自原文的检查线通道稳定、上下文策略确认无误之后再回头看 Dan 原文里几个容易被忽略的设计原则。它们不会直接出现在报错信息里但决定了你的 Agent 系统能否长期维持精简状态。6.1 默认异步不确定时不要阻塞Dan 的决策框架里有一句经常被跳过「不确定默认使用异步它更便宜让父 agent 保持精简。」生产环境里大多数子任务并不需要父 agent 立即拿到结果。所谓的「不放心」往往来自对异步回调链路缺乏观测手段而不是任务本身必须同步。给每个异步 sub-agent 的事件 ID 打上 trace 日志父 agent 就能随时查到任务状态没必要靠阻塞来获得安全感。6.2 深度保持 1sub-agent 不能再生成 sub-agentDan 团队把委托深度限制为 1sub-agent 拥有工作空间工具但不能生成下一层 sub-agent。这个约束避免了递归失控。如果你发现自己的系统出现了两层甚至三层嵌套委托先不要继续优化每一层的提示词直接把深度裁到 1。绝大多数任务用一个 sub-agent 就能完成嵌套只是让上下文的压缩链条多出几个不可控节点。6.3 用两个工具代替 mode 参数让模型自己选择最后一个建议来自 Dan 的工程细节他们用两个独立工具而不是一个带mode参数的工具。原因是模型在工具选择上的表现比阅读参数描述后正确选择更稳定独立工具也带来更清晰的日志和追踪。同步与异步的工具描述写清楚「何时使用」把决策权交给模型。你可以在自己项目里检查现有 sub-agent 工具的签名如果只有一个mode: sync|async|scheduled字段改成三个独立工具后模型选错模式导致的上下文膨胀通常会明显减少。排查完成后这次调用到底消耗了多少 token、是否需要为后续长期任务准备更大额度可以在 Coding Plan 里查看对应套餐如果排查中需要给不同子任务分配独立 Key直接在 控制台 API Keys 继续创建。Claude Code 的环境变量对照说明以 接入文档 为准。配置层面理顺之后再对照 Dan 的三种模式检查自己的 Agent上下文爆满的问题通常能定位到具体某一段返回路径。