最近用ChatGPT、Codex处理复杂任务时，我越来越明显地感觉到一个变化：
Agent正在从"一个人干完所有事"，变成"自己把任务分给不同角色"。
以前我们更关心的是：
有没有Coding Agent。
有没有Testing Agent。
有没有Review Agent。
有没有能够处理数据库、CI、日志、部署的Agent。
看起来Agent越多，能力就越强。
但当角色开始越来越多以后，一个新的问题会越来越明显：
一个任务，到底应该交给谁？
如果路由正确：
Agent可以很快进入自己最擅长的工作。
如果路由错误：
一个本来20分钟能解决的问题，可能会在几个Agent之间来回转手。
所以未来多Agent系统真正的瓶颈，可能不再是：
Agent数量不够。
而是：
Task Routing------任务路由
也就是：
怎么把一个任务交给最合适的Agent。
一、Agent越多，选择其实越难
假设系统里只有一个Agent。
任务来了以后：
直接交给它。
没有选择问题。
但如果以后有：
Coding Agent。
Testing Agent。
Database Agent。
Review Agent。
Incident Agent。
Deployment Agent。
一个Bug进来以后，系统首先就要判断：
这到底是什么问题？
比如：
用户反馈订单创建失败。
表面上像业务代码Bug。
但真正原因可能是：
数据库锁。
缓存失效。
测试环境污染。
CI配置错误。
某个依赖版本变化。
如果一开始判断错：
后面整个Workflow都会跑偏。
所以多Agent系统里，第一步越来越不是：
"谁来执行？"
而是：
"先判断这到底是什么任务。"
二、为什么路由错了，代价不只是浪费一次调用？
假设一个真实问题其实是数据库事务。
但它被派给Coding Agent。
Coding Agent开始：
读Service。
检查Controller。
修改业务逻辑。
跑测试。
发现问题还在。
然后任务才被转交给Database Agent。
Database Agent又要重新：
读Issue。
理解上下文。
看前面的修改。
确认哪些结论可信。
这时候浪费的不只是前一个Agent的执行时间。
还包括：
Context Rebuild Cost------上下文重建成本
每转手一次：
任务背景都要重新解释。
历史判断要重新验证。
之前的Evidence要重新理解。
所以路由错误会产生一种很隐蔽的成本：
Agent越多，错误分派造成的上下文搬运越多。
三、任务路由真正难在"一个问题往往不像它真正的根因"
比如：
测试失败
可能是测试本身。
也可能是：
业务代码。
数据库残留。
并发问题。
环境差异。
接口超时
可能是接口代码。
也可能是：
数据库慢查询。
下游服务。
锁等待。
网络问题。
CI失败
可能是代码。
也可能是：
依赖。
环境。
权限。
构建配置。
所以未来Agent路由不能只根据：
表面错误信息。
而要尽量识别：
问题真正属于哪一种工程域。
否则系统很容易出现：
看到报错 → Coding Agent。
看到测试失败 → Testing Agent。
看到数据库日志 → Database Agent。
这种简单规则在任务少的时候能用。
复杂项目里很快就会失效。
四、真正成熟的路由应该先做"任务分类"
一个任务进入多Agent系统以后，可以先形成一个很轻量的判断：
问题类型：性能异常
主要Evidence：DB latency 4.8s
影响范围：订单服务
高概率根因：数据库
建议路由：Database Agent这样执行Agent拿到的不只是：
"帮我看看订单为什么慢。"
而是已经经过一次初步分类。
这会明显减少：
错误方向探索。
所以未来多Agent Workflow里，很可能会出现一个越来越重要的角色：
Router Agent
它自己不一定负责解决问题。
它负责：
理解任务。
识别类型。
决定优先交给哪个Agent。
五、但Router也不能只看关键词
如果只根据关键词路由，很容易出现问题。
比如Issue里写了：
"订单接口测试失败。"
关键词有：
订单。
接口。
测试。
到底应该交给：
Coding Agent。
Testing Agent。
还是Database Agent？
真正有效的路由应该看：
1. 现象
发生了什么？
2. Evidence
当前有哪些日志、测试、指标？
3. 修改范围
预计需要改哪里？
4. 所需工具
需要数据库、Shell、CI还是代码权限？
这几个信息组合起来，路由才会更可靠。
六、任务路由还必须考虑Agent能力边界
不是所有Agent都应该什么都能做。
如果一个Testing Agent既能：
改测试。
改业务代码。
改数据库。
改CI。
那角色边界实际上就消失了。
最后还是：
每个Agent都能干所有事。
这会让路由本身失去意义。
所以多Agent系统真正成熟以后，每个Agent可能需要明确：
擅长什么。
能访问什么。
不能做什么。
什么情况下必须转交。
例如：
Testing Agent可以定位测试污染。
但发现根因是数据库事务以后：
应该转交。
而不是继续自己修改数据库逻辑。
七、好的路由不仅要会"分派"，还要会"升级"
第一次路由不可能永远正确。
所以更重要的是：
Agent发现自己不适合处理时，能不能及时升级。
比如Coding Agent执行10分钟后发现：
问题根本不是代码。
而是数据库锁。
这时候最好的行为不是：
继续尝试修改代码。
而是：
当前判断：
业务代码无明显异常
新增Evidence：
DB lock wait > 4s
建议：
升级到 Database Agent这就是：
Escalation------升级
真正成熟的路由体系应该允许：
路由 → 执行 → 发现新Evidence → 重新路由。
而不是第一次分派以后就一条路走到底。
八、Agent之间交接也需要统一格式
如果任务必须转手：
最怕的就是新的Agent重新从头看。
所以交接最好至少包含：
当前问题。
已经验证什么。
排除了什么。
现有Evidence。
做过哪些修改。
为什么要转交。
下一步建议。
例如：
问题：
订单接口偶发超时
已排除：
Controller逻辑
缓存命中
Evidence：
数据库锁等待4.6秒
未完成：
事务范围分析
建议：
转Database Agent这样新Agent拿到以后：
可以直接接着做。
而不是重新经历一次完整上下文建立。
九、为什么Agent数量越多，路由质量反而越重要？
假设只有两个Agent。
路由错了以后，最多再换一次。
但如果系统里有10个、20个Agent：
选择空间会迅速增加。
如果没有好的路由规则：
很容易出现：
Agent A转B。
B转C。
C又觉得应该回A。
任务开始在系统里来回移动。
于是Agent数量增加以后，一个新的风险会出现：
Routing Thrashing------路由抖动
也就是：
任务不断被重新分派，却没有真正向解决方向推进。
这时候再增加更多Agent：
只会增加更多错误选择。
十、给自己测一个指标：路由返工率
这篇我建议只看一个核心指标：
Routing Rework Rate------路由返工率
统计最近一段时间的多Agent任务。
看有多少因为最初路由错误，最终出现：
重新转交。
重复分析。
重新建立上下文。
撤销前一个Agent修改。
例如最近50个任务里：
有8个因为最初分错Agent而产生明显返工。
那么：
路由返工率 = 16%。
这个指标比：
"我们有多少个Agent"
更有意义。
因为真正决定吞吐的不是：
有多少执行者。
而是：
任务第一次能不能尽量交给正确的人。
十一、这个指标怎么判断？
如果路由返工率高于20%：
说明多Agent系统已经出现明显的分派问题。
最应该先优化：
任务分类。
角色边界。
路由规则。
交接格式。
而不是继续增加更多Agent。
如果在10%---20%：
重点找出最常被分错的任务。
比如：
测试问题。
数据库性能。
CI故障。
异步任务。
这些边界模糊的场景，可以增加更明确的Evidence规则。
如果长期低于10%：
说明大部分任务能够比较稳定地进入正确执行路径。
这时候增加更多专业Agent，才更容易真正提高吞吐。
十二、怎么降低路由返工率？
可以先做四件事。
第一，明确每个Agent的职责边界
不要所有Agent什么都能做。
第二，路由前先提取Evidence
不要只看Issue标题和报错关键词。
第三，允许Agent主动升级任务
发现自己不是正确角色时，尽早转交。
第四，统一Handoff格式
转交时保留：
已完成工作、Evidence和下一步。
这样减少上下文重建。
十三、为什么任务路由会成为新的开发瓶颈？
因为未来真正复杂的Agent系统，可能不是一个Agent独立工作。
而是：
一个任务先被分类。
再交给Coding Agent。
Testing Agent负责验证。
Review Agent检查风险。
Deployment Agent完成后续动作。
当执行角色越来越专业以后：
真正难的就不再是每个Agent会不会做。
而是：
谁先做。
谁后做。
什么时候转交。
谁最终负责完成。
所以未来多Agent系统很可能越来越像一个小型工程组织。
而任务路由就是：
这个组织里的调度系统。
十四、Plus和Pro怎么判断？
如果你的路由返工率还比较高：
Agent经常派错角色。
任务频繁转手。
上下文不断重建。
同一个问题被多个Agent重复分析。
那当前真正限制效率的不是AI容量。
而是：
任务调度机制还不够成熟。
这个阶段Plus通常已经够用。
先把：
任务分类。
Agent角色。
Evidence路由。
Handoff规则。
做好，收益通常更大。
否则增加更多AI容量，只会让更多Agent同时做错方向的事情。
如果你的路由返工率已经长期很低：
任务大部分可以快速进入正确Agent。
转交时上下文完整。
多Agent协作不会重复劳动。
同时又长期存在：
大量成熟、高价值任务排队，
AI执行容量才真正开始成为瓶颈。
这时候Pro才更容易放大吞吐。
因为你增加的是：
被正确调度的Agent产能。
而不是单纯增加更多执行者。
最后
ChatGPT、Codex越来越会自己分派子任务以后，我们很容易关注：
到底能同时开多少Agent。
能不能再加一个Review Agent。
能不能再加一个Testing Agent。
但真正决定多Agent系统效率的，可能不是数量。
而是：
一个任务能不能尽快找到最适合处理它的Agent。
Agent数量少的时候：
分错一次问题不大。
Agent数量越来越多以后：
错误路由、重复分析、上下文重建和任务来回转手，会迅速变成新的成本。
所以未来真正成熟的多Agent Workflow，重点不会只是：
"我有多少Agent。"
而会越来越变成：
"我能不能把任务交给正确的Agent。"
因为一个任务只有进入正确的执行路径以后，
更多Agent、更强模型和更高容量，
才真正有意义。
持续分享 Codex、大模型开发与 AI 编程实战内容。
长期深度使用各类代码大模型，也整理了稳定的Plus/Pro会员订阅渠道，有需要可自取。