在 Agensh 这类多智能体编排里，先把两件事分开：谁负责调度，每个智能体拿到什么上下文。调度决定任务怎么拆、什么时候交给谁、什么时候算完成；上下文决定执行者看到哪些材料、要不要带历史对话、要不要带上游产物。两者混在一起，最常见的结果是编排者一边派活一边替执行者改内容，执行者则收到一大包无关信息，最后既难判断对错，也难复现问题。比较稳妥的顺序是先定调度边界，再把上下文传递收窄成几个可检查的字段。

处理 Agensh 调度与上下文问题时，建议先固定编排层只做派活、收集、判断完成三件事，再把执行者输入裁剪到完成当前子任务所需的最小集合，并用配置字段和一次任务的输出日志做校验。适用场景是多智能体协作的任务拆解；边界是不要用上下文全量透传来换取省事，也不要用编排者代写结果来掩盖拆解不清。

把编排者的职责限定为派活、收集、判断完成

编排者的职责建议只保留三条，每条都要能用行为描述和日志看出来。

第一条是派活。编排者根据任务目标拆出子任务，为每个子任务指定执行者和输入范围，产出类似“子任务编号、目标、执行者、上下文引用”的派发记录。派活时只描述要做什么和验收条件，不替执行者写具体步骤。

第二条是收集。编排者负责接收执行者返回的产物和状态，把产物按子任务编号归档，必要时转交给下游执行者。收集阶段不做内容润色，只检查产物是否落在约定格式内。

第三条是判断完成。编排者依据验收条件判断子任务是否达成，未达成则重新派活或补充上下文，达成则推进下一步。判断完成的依据应当是执行者产物和验收条件的比对，而不是编排者的主观感觉。

越界的典型表现通常有这几种：编排者在派活消息里直接写出完整答案或代码，执行者只需照抄；编排者反复修改执行者产物而绕过重新派活；编排者把多个子任务合并成一次调用，导致某一步失败后无法定位；编排者在收集阶段自行补写缺失字段，掩盖了执行者输出不合规的问题。出现这些表现时，先把编排者的动作收敛回派活、收集、判断完成三条，再排查上下文是否给得不对。

规定执行者只接收完成当前子任务所需的上下文

上下文裁剪的判断依据可以围绕三个问题：执行者要完成当前子任务，必须知道哪些事实；哪些事实可以由执行者自己查询或推导；哪些事实只对编排者判断完成有用。只对编排者有用的信息不要下发，能由执行者自行获取的不要重复塞入。

具体裁剪时，建议按子任务边界切分：上游产物只传与本子任务直接相关的部分，历史对话只保留最近若干轮或与当前子任务相关的片段，工具说明只保留本子任务会调用到的工具。原始全量材料可以作为引用地址保留，但不建议整段塞进执行者输入。

裁剪过度的常见症状也需要先记住：执行者反复追问同一个背景信息；执行者产物缺少关键约束，例如格式、字段、边界条件；执行者把上游已经确定的结论推翻重做；执行者在输出里声明“信息不足”却没有人补上下文。出现这些症状说明上下文被裁剪到影响完成度，应当补回必要字段，而不是让编排者代写。

在配置里把上下文传递固定成几个字段

让上下文传递可检查的做法，是在配置里把传递内容固定成几个命名字段，而不是拼一段自由文本。字段清单骨架可以先按下面几项设计，每一项都标明来源，便于排查时回溯。

• task_id：当前子任务编号，来源是编排者的派发记录。
• task_goal：本子任务要达成的目标与验收条件，来源是编排者的任务拆解。
• upstream_artifacts：上游产物中与本子任务相关的片段，来源是收集阶段归档的产物。
• context_refs：需要时可回查的原始材料地址或标识，来源是归档记录。
• constraints：格式、字段、边界条件等硬性约束，来源是编排者的验收条件和全局规则。
• history_digest：与当前子任务相关的历史摘要，来源是对话记录裁剪结果。

配置示例可以用可替换的占位写法，不绑定具体实现：

agent_context:
  task_id: "{{ dispatch.task_id }}"
  task_goal: "{{ dispatch.goal }}"
  upstream_artifacts:
    - "{{ artifacts.related_slice }}"
  context_refs:
    - "{{ archive.ref }}"
  constraints:
    - "{{ rules.output_schema }}"
  history_digest: "{{ history.recent_digest }}"

每个占位符都应对应一个明确的来源对象，配置里不要出现从整段对话或整份文档直接注入的字段。字段固定后，编排者派发时只需填充这些来源，执行者也只能看到这些内容，排查时可以直接比对输入输出。

跑一次任务，看执行者拿到的是多余还是缺失

配置完成后，用一次小任务验证。验证重点不是看最终答案是否漂亮，而是看执行者实际拿到什么、用了什么、缺了什么。

在输出里检查上下文，可以从三处入手：执行者首次输出是否引用了本子任务不需要的上游内容，这是多余信号；执行者是否在输出中明确提出缺少某个事实或约束，这是缺失信号；执行者是否重复做上游已完成的工作，这通常说明上下文边界没有切干净。

需要记录的证据包括：派发记录里的字段值、执行者实际收到的上下文快照、执行者的原始输出、编排者的完成判断记录。把这些内容按 task_id 对齐保存，后续调整上下文粒度时可以直接对比，而不是凭印象判断。

按观察结果调整上下文粒度再跑

调整上下文粒度时，建议一次只改一类字段，例如只扩大或收窄 upstream_artifacts 的范围，或只调整 history_digest 的摘要长度，避免多种变化混在一起无法归因。

调整前后的对比方式，只比较完成度和返工次数。完成度看子任务是否在验收条件下达成，返工次数看同一子任务被重新派发的次数，以及执行者因信息不足而追问的次数。不要用耗时或主观感受作为主要依据，这些在多智能体调度里波动较大，容易误导调整方向。

如果完成度下降或返工次数上升，优先检查上下文是否被裁剪过头，而不是让编排者代写产物；如果完成度尚可但执行者输出大量无关内容，则收窄上下文范围并复核字段来源。按这个顺序重复几次，上下文粒度会逐渐稳定在可解释、可复现的范围内。