先记住这个答案
只传递子任务所需的最小上下文，包括任务目标、关键约束、必要的数据摘要或引用，以及期望的输出格式。整个对话历史会让 worker 被无关信息干扰，增加 token 消耗，且可能泄露敏感内容。可裁剪为任务相关的原始数据或结构化摘要，必要时附上来源标识。
- 整个对话历史会使 worker 上下文拥挤且成本失控
- 子任务上下文应聚焦目标与必要数据
- 过简上下文丢失约束，需平衡自包含与裁剪
上下文传递的机制：历史膨胀与注意力稀释
orchestrator 与用户多轮交互后，对话历史可能包含大量中间陈述、已修正的错误和无关闲聊。若把完整历史原样塞给每个 worker，LLM 的上下文窗口被无差别占用，有效信息密度下降，模型对关键指令的注意力会被稀释。尤其在使用长上下文模型时，细节位置错乱可能导致 worker 忽略任务核心。
更隐性的问题是“上下文偏差”：历史中未撤销的旧指令、其他 worker 的结果或对同一术语的不同用法，都会成为干扰源。worker 只应看到完成该子任务所必需的输入和规则。token 成本也随输入长度线性增长，整段传递会使成本随子任务数乘数上升，令多 Agent 协作在经济上不可持续。
场景：代码库多文件变更的分解
假设 orchestrator 接管一个修复任务：用户报告某个 API 返回超时，需要检查后端服务、前端调用和数据库查询。orchestrator 决定派两个 worker——一个分析后端日志，一个审查前端代码。如果给每个 worker 传完整 5 万 token 对话历史，其中包含用户最初的产品讨论、团队闲聊、以及给另一个 worker 的长篇指令，worker 不仅要付出高成本，还可能错误地修改前端代码以适应后端日志中的奇怪提示。
有效做法是给后端 worker 传：任务目标、相关日志文件的路径、超时错误的堆栈片段、明确要求只输出根因分析；给前端 worker 传：前端调用 API 的代码位置、超时现象描述、禁止改动后端。这样每个 worker 的上下文限制在 2-3 千 token，输出质量更高，成本更可控。orchestrator 需在任务描述中写清验收标准，并让 worker 在结果中引用它看到的输入片段，保证可追溯。
适用边界：上下文裁剪何时失效
当子任务强烈依赖全局约束时，过度裁剪会失败。比如用户要求“修改所有涉及金额的地方，并确保使用 decimal 类型”，若裁剪后没告诉 worker 全局金额处理规范，worker 可能只在局部改动而遗漏其他位置。此时应把全局规范压缩成简短的原则列表加入每个 worker 的上下文，而不是传整个历史。
另一个风险是上下文中的隐含引用：worker 需要理解用户原话中的委婉说法或指代。若直接删掉历史上下文，模型可能误解意图。解决之道是 orchestrator 在派发前主动“改写”任务，用自包含的语句复述目标与约束，并校验 worker 的计划是否符合预期。此外，有些 worker 需要结合前序 worker 的输出，则应传前序的最终结论而非其内部推理长文。
容易答错的地方
- 传整个历史是损失最小的做法
- 事实上，完整历史会引入大量无关 token 和指令冲突，导致 worker 聚焦困难、输出质量下降，并显著提高成本。现代模型虽支持长上下文，但注意力分布并不均匀，相关细节可能埋没在噪声中。应该用最小必要上下文。
- 裁剪就是提取最后几轮对话
- 简单保留最后几轮可能遗漏早期设定的关键约束。裁剪应是语义级的，需要识别任务所依赖的目标、约束、数据源和输出格式，并重新组织成自包含的指令，而非机械截断。
面试官还会怎么问？
如何决定哪些上下文必须传给 worker？
可基于任务描述逆向推导：worker 要执行动作需要哪些输入数据、哪些边界条件不可违背、最终输出需满足什么形式。用 checklist 验证，遗漏时 worker 应主动询问或根据默认假设执行。
上下文裁剪是否适用于所有 orchestrator-workers 场景？
不适用。若子任务个数极少、历史极短，裁剪收益可忽略。而当 worker 需要全局视野（如跨文件重构）时，可传压缩后的全局规则而非原始历史。裁减策略应基于任务依赖度。
如何避免裁剪导致上下文缺失关键信息？
引入校验循环：worker 执行前先让它复述任务目标和关键约束，若 orchestrator 发现复述有遗漏则补充上下文。也可在 worker prompt 中强调“如缺少必要信息请明确请求”。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。