建议把“要不要上多智能体”拆成三次可独立判定的验证：先让单个智能体跑通一次完整任务并留下基线，再加入一个只接子任务的执行者，最后加一个只能按固定格式派活的编排者。这样每一步出问题时，你能落到具体层面——是模型能力不够、提示词把任务说糊了，还是交接和编排逻辑没约束住。一上手就搭多智能体，失败现象往往是“整体效果差”，日志里看不出断点在哪，回退也无从下手。下面三步都以你自己的任务、日志和页面行为为准，任何一步没跑通就停在那一步，不要继续往上叠。

适用场景：准备从单智能体升级到多智能体，但还没确认单智能体本身是否达标。操作动作：先固定一个任务样本、一份提示词，记录耗时、输出结构、人工合格判定，再逐层增加执行者与编排者。验证方式：每层只改一个变量，用同一任务样本重跑，对比交接是否成功、派活格式是否合规、返工次数是否变化。风险边界：单智能体基线不达标时，加再多角色也只是把不确定性分散到多处；配置项名称需结合你所用的 Agensh 版本确认，不要照抄示例字段。

单智能体跑通一次完整任务并记录基线

这一步的目的不是把效果调好，而是拿到一个后面能对比的对照结果。选一个你真实会遇到、且能人工判断对错的任务样本，固定输入、固定提示词，先跑一次。基线至少记录三项：端到端耗时（从提交到拿到最终输出）、输出结构（是否稳定包含你要求的字段、段落或格式）、人工判定的合格标准（写清楚什么算通过，比如“结论必须给出操作步骤且不含凭空数字”，别只写“看着还行”）。

提示词先用最小版本，把任务、输出格式、禁止项写死，方便后面加角色时复用同一份约束。

你是任务执行者。只处理下面这一件事，不要拆分子任务，不要委派他人。

任务：{task}
输出格式：
1. 结论（不超过 3 句）
2. 操作步骤（有序列表）
3. 不确定项（没有就写“无”）

约束：
- 不编造数据、日期、来源
- 缺少信息时明确写出缺什么，不要猜

建议连续跑同一任务三到五次，观察输出结构是否稳定。判定标准：如果输出格式每次都一致、人工判断能稳定给出合格或不合格、且不合格的原因能归到提示词或任务输入上，说明这个基线可用。如果连自己都判断不了合格与否，先修合格标准，别急着加执行者。基线记录可以直接写成一行日志，后面两步拿它对比：

step=single_agent
task_id=T-01
elapsed_ms=填写实测值
output_shape=ok | drifted
manual_verdict=pass | fail
fail_reason=提示词未约束格式 / 输入信息缺失 / 模型能力不足

只加一个执行者，让它接一个子任务

这一步只验证一件事：单个交接环节能不能跑通。不要同时增加两个执行者，也不要引入编排者。做法是从原任务里切出一个边界清楚的子任务（例如“把结论整理成表格”“把步骤翻译成命令”），交给第二个智能体，主智能体负责把子任务输入传过去、把结果收回来。

配置改动点通常集中在三处，字段名以你所用的 Agensh 版本为准：
1）角色定义——执行者只声明子任务职责和输出格式，不要给它完整任务背景，避免它越界；
2）交接输入——明确主智能体传什么字段，最好是一段结构化文本而不是整段对话历史；
3）返回约定——规定执行者返回的格式，以及主智能体在收到空结果或格式不符时怎么办（重试一次 / 标记失败 / 直接放弃）。

roles:
  - name: planner_agent
    delegates_to: [worker_agent]
  - name: worker_agent
    task: 只把传入的结论整理成 markdown 表格
    output_format: markdown_table
    on_invalid_output: mark_as_failed   # 不静默兜底
handoff:
  payload_fields: [conclusion_text]
  max_retry: 1

这一步要观察的是交接成功率：同一任务样本跑多次，统计执行者是否收到完整输入、是否按约定格式返回、主智能体是否成功解析并继续。日志里建议给每次交接打上标记，例如 handoff=worker_agent status=ok|empty|malformed。如果出现大面积 empty 或 malformed，问题多半在交接字段没对齐或返回格式没约束，先修这两处，不要用“再加一个智能体复核”来掩盖。

再加编排者，规定它只能按固定格式派活

编排者最容易变成第二个自由发挥的模型，所以要把它的行为压进一个可校验的格式里：只允许输出派活清单，不允许直接回答问题，也不允许在清单之外写解释。字段骨架建议保持最小，够用就好。

{
  "plan_id": "string",
  "steps": [
    {
      "step_id": "s1",
      "assignee": "worker_agent",
      "subtask": "一句话描述，不含背景",
      "input_fields": ["conclusion_text"],
      "expected_output": "markdown_table",
      "done_when": "可判断的完成条件"
    }
  ],
  "stop_condition": "全部步骤返回即结束"
}

不合规时的表现要提前定义清楚，才能在执行中识别：出现自由文本段落、assignee 写了不存在的角色、subtask 里夹带完整任务背景、steps 为空、expected_output 与执行者声明不一致、或者派活清单之外还附带自己的结论。处理方式建议是拒收并让编排者按格式重出一次，仍不合规则直接标记该轮失败，不要让人工在每次运行后手动修剪输出。

校验可以放在编排者和执行者之间，用一个格式检查步骤完成：

def check_plan(plan):
    if not plan.get("steps"):
        return "empty_steps"
    for s in plan["steps"]:
        if s.get("assignee") not in KNOWN_ROLES:
            return "unknown_assignee"
        if not s.get("done_when"):
            return "missing_done_when"
    return "ok"

观察点是每一轮派活被拒收的次数，以及在拒收之后任务还能不能收敛。拒收率高但最终能完成，说明格式约束生效、只是编排者需要更明确的字段说明；拒收后反复重出不收敛，说明这个任务不适合交给编排者拆分，回到第二步的单执行者形态更稳。

对比三步的产出差异

三步都用同一任务样本跑，把结果填进同一张表，避免凭感觉判断“多智能体好像更聪明”。完成度按你第一步写下的合格标准打分，轮次按模型调用或派活往返次数计，耗时取端到端实测，返工次数指人工介入修改输出或重跑的次数。

结论怎么下：完成度没有提升而轮次和耗时明显增加，说明多智能体在这条任务上没有增益，保留单智能体基线即可；完成度提升但返工次数也上升，说明增益来自人工修补而不是协作流程，需要回到提示词和派活格式去收敛；三步完成度接近、只有耗时差异，优先选结构最简单的那一档，便于以后排查。只有在同一任务样本上多次重跑都能得到相近结果，才适合把这条流程固定下来，再考虑扩大任务范围。