手机自己操作 App 的 Agent 火了:多 Agent 专家团这样拆才不烧钱

按模型、工具、记忆与成本拆角色，再用路由表、并发上限和一张 token 账单验证分工是否真的省了事

最近 B 站上那个让手机自己操作 App 的开源安卓项目，之所以让人眼前一亮，功劳不在模型变聪明，而在它把"会操作 App"这件事收敛成了一个边界清晰的角色：能碰什么、不能碰什么、输出必须长什么样，全都写死了。

这套切法可以直接搬到多 Agent 专家团上。你要做的不是拼提示词，而是先回答四个问题：这个角色用什么模型、能调用哪些工具、跨轮记什么、一次任务值多少钱。

下面是我自己落地时反复用的顺序：按轴拆角色 → 写路由表 → 补不变量与结束条件 → 用账单验证分工到底省没省。

💡 拆角色的切法：四个轴，不是四个部门

按部门、按业务线拆听起来合理，但落不到任何一行配置上。可落地的切法是四个轴：

四个轴都能落到一行行具体字段上，角色卡才算写完。

✅ 角色卡片：四行就够

每张角色卡先在纸上写死，再谈框架：

工具白名单写宽了几乎没人发现——所以它必须是一行显式字段，而不是 system_prompt 里一句"请谨慎使用工具"。

角色卡写到第五张，你那份配置通常已经两屏长了，改个字段全靠肉眼确认有没有写错。有人干脆把这类配置搬进浏览器里点着改、改完原样导回去；我现在的做法是在 Crusbro Agent Studio 里维护 Catalog，字段写错当场就能看出来，不用等上线才发现。

🎯 路由表：至少写清三类派发规则

📌 每条路由都要额外标注两件事：触发条件，以及失败重试归属。少了失败归属，并行里只要有一个分支卡住，整条链就悬着互相等待。

📌 不变量、并发上限与结束条件：集群的护栏

不变量要写成"协作边界"，不是"期望"：

关键在于这些边界能在配置期被校验，而不是上线后靠人盯着。结束条件同样要显式定义：没写 finalize 规则，集群要么提前收口漏掉分支结果，要么一直等不到静默——两种情况都会在演示时当场翻车。

有人把这类集群配置收在一处声明：成员、路由、不变量、并发上限和结束条件放在同一张清单里，谁负责哪一步一眼看得见，演示时也不用临时拼装脚本。

📊 一张成本表，验证"分工是不是真的省了"

并行派发之后，按角色维度记录 token 与耗时：谁贵、谁慢、谁经常被重跑。

判断标准不是"Agent 变多了"，而是同一个任务的总 token 与总人工介入次数有没有下降。

✨ 一个反直觉的点：调用次数从 1 次变成 3 次，单次 prompt 变短，token 反而更省——因为省掉的是"一个大脑反复自我怀疑"的长上下文。真正的成本大头从来不是模型单价，而是重复推理，以及你在中间反复纠正它的时间。

所以昂贵的判断型角色留给大模型，机械执行交给便宜模型。走到这一步，账单才真的好看。

⚠️ 两个高发的翻车姿势

❌ 把"多 Agent"当成把提示词拆成几段、然后同时开跑。 少了角色边界与路由规则，多 Agent 只会放大 token 消耗和重复劳动：同一个判断被三个角色各做一遍，谁也不对汇总结果负责。

❌ 只写角色、不写结束条件。 并发跑起来的任务没有 finalize 规则，集群要么提前收口漏掉结果，要么一直等不到静默。

🔧 改配置：固定三步，能回滚

配置一旦超过三五个角色、超过一屏 JSON，改错字段就是灾难。所以改配置的流程也固定下来：

配置层能当场校验字段合不合法，比事后读几百行 JSON 便宜得多。

👉 把角色卡变成能跑起来的项目

写完角色卡、路由表、不变量和结束条件之后，还差最后一步：让它真的跑起来，并且下次还能改回去——能导出、能导入，才谈得上回滚和交接。

想按上面这套拆法把一支 Agent 专家团搭出来，可以看看 Crusbro Agent Studio 的落地页：在浏览器里搭你的 Agent 专家团