准备：先有评测集
从真实任务里抽五十到一百条，覆盖常见、边界与应当拒答三类；每条写清期望输出与可接受差异。没有这一步，后面的对照都只是印象；评测集本身也是上线后回归的唯一依据，不能省。怎么建题，从真实任务里抽，不要用演示题凑数。
基线：单 Agent 先跑
先让单 Agent 在同一套任务上跑一遍，记录一次通过率、人工接管率与平均步数。这一步不是走过场：若单 Agent 已达到业务可接受水平，拆分就失去了主要理由，剩下的只是偏好与面子。为什么先跑基线，因为没有对照就无法归因改进。
对照：只改一个变量
拆分方案要与基线使用同一模型、同一工具与同一份材料，只改编排方式；否则结果无法归因。每组至少跑两轮，观察波动，避免用一次偶然的好结果下结论，也避免用一次坏结果否定方案。怎么控制变量，同模型、同工具、同材料，只改编排方式。
门槛与灰度
决策门槛应在实验前确定，例如通过率提升与延迟上升的取舍线、排障时间上限。选定后在一个班组灰度两周，观察真实单据下的失败形态与接管频率，通过后再放量并保留回退开关。为什么门槛要事先写，因为事后调整等于没有门槛。
适用与不适用
适合谁
- 正在做架构决策、需要证据链的技术负责人
- 被要求拆分但内部存在分歧的团队
- 需要向管理层提交验证报告的项目
不适合谁
- 没有真实任务可抽样、只能拿演示数据验证的团队
- 不愿设定决策门槛、只想先上线的项目
典型场景
某物流企业想给调度助手加两个角色。技术团队从三个月工单里抽八十条任务，先跑单 Agent 基线，再跑拆分方案，两轮对照后发现通过率变化很小、延迟上升明显。评审据此决定暂不拆分，把预算转去修地址解析，三个月后同一套评测集显示通过率提升。
可执行步骤
- 抽取覆盖常见、边界与拒答的评测任务，逐条写明期望输出与可接受差异
- 先跑单 Agent 基线，记录通过率、接管率与平均步数，连续测两周
- 在同一模型与工具下只改编排方式，跑两轮对照并记录波动幅度与原因
- 按事先写定的门槛评估结果，写明取舍理由与未被采纳的方案及理由
- 小流量灰度两周，记录接管理由，通过后再放量并保留回退开关并演练
常见坑
- 评测集只用演示样例，任务过于干净，两种方案都接近满分，对照失去区分度，结论自然不可信。
- 对照时同时换了模型与编排，结果无法归因，评审各说各话，决策被拖成拉锯，最后靠职位高低定。
- 门槛在看完结果后才定，倾向选择对自己有利的口径，报告经不起追问，也难以向财务解释。
- 跳过灰度直接放量，真实单据下的超时与接管问题集中爆发，回退时又发现没有旧版本入口。
自检与验收清单
- 评测集是否覆盖常见、边界与拒答三类，且逐条写明期望
- 基线是否记录了通过率、接管率与平均步数，并留存样本
- 对照是否只改编排一个变量，并跑满两轮观察波动
- 决策门槛是否在实验前写定，并由双方签字留档
- 是否保留回退开关与旧版本入口，并演练过一次
常见问题
验证要花多久？
准备评测集约一周，基线与对照各一周，灰度两周，合计一个月左右。相比上线后返工，这个周期通常更划算；若业务极简可压缩到两周，但不要省掉评测集，否则结论无法复用。
结果差不多怎么选？
选运维更简单的那个。通过率接近时，单 Agent 在变更、排障与成本上占优；除非拆分带来了明确的隔离或并行收益，否则没有理由承担额外复杂度，团队也很难长期维护两套机制。
验证报告要写什么？
写任务来源、样本量、指标定义、两轮结果与波动、门槛与结论，以及未采纳方案的理由。报告是给未来的自己看的：半年后有人问为什么没拆，翻出来即可，不必凭记忆重新争论。