多智能体协作有个绕不开的账：把活分给子代理去干，到底是赚了还是赔了？过去很多系统默认「多几个脑子总比一个强」，但 10 月提交的两份工作把这笔账摊开了算。一份是 MS-Eval（编号 2610.22869），一份是 BRIA（Branch-Inspect-Adopt），再加上 10 月 19 日 Qwen Code 0.25.3 把相关模式做进了产品，这条线正在从论文走向日常。
主代理委派、子代理执行：隔离才是关键
MS-Eval 研究的范式叫 MAD-SAE：主代理切分子任务，交给专业化子代理在各自隔离的上下文里并行执行，再把有用结果收回来。它搭了一套 MCP 密集的基准、一个受控执行 harness、专门的委派与编排指标，以及综合评估的 MSQ 指数，用 4 种委派变体、8 个前沿模型、一套 MCP 重任务集来量化这件事。结论很克制：专业化子代理是最好的实践；开源模型大多在性能与效率上双升，闭源前沿模型反而更贵且成绩掉；冗余的委派把同样的成本变成了纯开销。论文追下来，增益来自更好的单智能体解法、有效的上下文卸载和真正的子任务并行，而不是单纯「多喊几个帮手」。
BRIA：把候选工具丢进隔离分支试
BRIA 处理的是另一个老大难：工具库大到上千件时，怎么找到此刻真正要用的那件。它的做法是 Branch-Inspect-Adopt——把每个候选工具的探查，临时丢进各自独立的分支里跑，主代理只检查执行证据，把有用结果采纳进自己的轨迹。论文在 1897 件工具的共享池上测，MCP-Atlas 上拿到 89.77 的平均 claim 分，比 MCP-Zero 的 75.40 高 14.37 个百分点，同时落在「性能对输入 token 成本」的帕累托前沿上。作者一句话点破：在同一个轨迹里试多个候选，会让失败的尝试污染后续推理——隔离探索，正是这周几条委托结果的共同答案。
产品也开始这么做了
10 月 19 日发布的 Qwen Code 0.25.3 把这套模式落进了产品：宿主主代理可以拉起「快照隔离子代理」，读一份冻结的工作区副本，不改动文件、不跑命令、不影响父代理。这种靠机制而不是靠叮嘱的边界，比「请别乱改」实在得多。把 MS-Eval、BRIA 和 Qwen Code 这三件事放一起看，结论趋于一致：子代理是一个带价签的上下文边界——当它能把可能失败的探索挡在主线程之外，或者活真的并行跑起来，就值得付费；当智能体只是互相读草稿，烧的只是预算。对正在评估多智能体架构的团队，建议先在自家任务上把「有委托」和「无委托」各量一遍，再决定是否采用。
目前官方及行业暂未披露更多细节，包括 BRIA 的完整评测协议与各模型的逐项表现，后续将持续跟进迭代动态。这篇把「子代理到底值不值」从一个直觉，变成了可以分项计、可以对照读的账本。