多智能体协作是2026年AI领域最火热的概念之一，但你真的算过这笔账吗？
2026年7月，OpenAI正式推出GPT-5.6系列模型，包含旗舰模型Sol、均衡模型Terra和轻量模型Luna。与此同时，Codex迎来Multi-Agent V2更新，允许Sol将任务委派给Luna等子智能体。表面上看，这是一个效率飞跃的故事。但翻开账单你会发现：推理强度每高一档，token消耗可能暴涨5到10倍。多智能体并行听起来很美，可如果每个agent都在用高档推理跑简单任务，你的钱就变成了一行行没人看的日志。
这篇文章要说的就是一件事：多智能体系统最大的敌人，不是模型不够聪明，而是你舍不得让它们“偷懒”。
三档推理，三种烧钱速度
GPT-5.6 Sol提供从low到max共六档推理强度。low档做轻量推理，开销最小；medium档平衡速度与质量；high档做多步推理；xhigh和max则把推理链拉到最长。
每一档之间的token消耗差距，不是线性的，而是跳跃式的。medium和ultra档之间，差距可达5到10倍。
什么意思？一个用ultra跑的任务，可能吃掉十个medium任务的token预算。
但问题不在于高档推理贵——贵有贵的道理，复杂问题确实需要深度思考。问题在于：你把高档推理用在了什么地方。
如果你的coordinator在用ultra思考“这个文件在哪个目录”，你的scout在用high档查代码路径，你的worker在用max档写一个三行改动的补丁——那你不是在用AI，你是在用印钞机写代码。
让Scout当Scout，别让它当教授
Codex的多智能体编排系统里，有一个非常务实的默认角色划分：
- Scout负责窄范围、只读任务——定位文件、追踪代码路径、找到相关测试。它应该用GPT-5.6 Sol Light，推理强度low。
- Worker负责有边界的改动、运行检查或辅助工作。它用Sol Medium，推理强度medium。
- Smart worker负责困难实现、处理歧义、协调其他agent。它用Sol High，推理强度high。
这个划分的核心逻辑是什么？是“把推理强度匹配到任务难度”。
Scout不需要思考“这个文件为什么在这里”，它只需要找到它。low档足够。Worker不需要思考“这个改动对整个系统意味着什么”，它只需要按规格执行。medium档足够。只有那些真正需要多步推理、需要处理不确定性、需要协调他人的任务，才值得开high档。
但现实中，太多人把每个agent都设成同一个高档推理。结果就是：三个agent各烧各的钱，干的活加起来还不如一个medium档的coordinator安排得好。
这就怪了——多智能体系统本来是为了提效，结果你却在为每个agent的“过度思考”买单。
协调不是开会，是分活
多智能体系统的核心是协调者coordinator——主协调agent。它的工作是分配实质性任务、避免重复调查、追踪每个agent在做什么。
但coordinator最容易犯的错误是什么？是把自己当成项目经理，而不是任务分发器。
项目经理要开会、要同步、要汇报。任务分发器只需要做一件事：把对的活派给对的agent，然后闭嘴。
Codex的设计里有一个关键机制：agent之间可以直接互相发消息，通过一个公共消息系统，每个agent有自己的收件箱。当scout发现了worker需要的信息，它可以主动传递，不用等coordinator中转。
这意味着什么？意味着coordinator不需要当传话筒。它派完活，scout和worker自己对接。coordinator省下来的推理资源，可以拿去处理更高层的决策。
并行度默认是四个agent，包含coordinator在内。在这个预算里，coordinator可以同时派出三个scout分头调查三个问题，也可以让一个smart worker协调一个scout和一个worker。
关键不是“能并行多少个”，而是“每个并行任务用了几档推理”。
上下文继承：省事还是烧钱？
多智能体系统里有一个容易被忽视的开关：fork_turns。
fork_turns控制子agent继承多少父agent的对话历史。设置为“none”时，子agent得到一个干净、聚焦的独立任务。不设置时，子agent会继承父agent的全部上下文——包括之前的讨论、决策、甚至协调指令。
继承上下文的好处是：子agent理解全局目标，不用重新解释。
但代价是什么？是token消耗。
一个继承了完整对话历史的子agent，每次调用都要为那些它根本不需要看的上下文付费。如果这个子agent本身只是去查一个文件路径，那它带着三万token的历史记录出发，就像开着卡车去买一瓶酱油。
更隐蔽的问题是：继承上下文的agent可能也会看到父agent的协调指令。如果它误解了这些指令，可能会尝试自己再派agent——造成层层嵌套、无限递归的agent树。
解决方案很简单：给叶子agent加一句边界指令——“直接完成这个任务，不要生成其他agent”。
但很多人连这句话都懒得写。然后他们奇怪为什么账单涨了。
一个skill模板能省多少钱？
Codex社区的一名开发者发布了一个多智能体编排的skill模板。核心指令极其简洁：
保持对用户可用，同时把实质性工作委派出去。用low推理强度和fork_turns:none并行派出只读scout。用medium推理强度做常规实现。用high推理强度处理难题。给每个agent清晰的职责，避免重叠任务，告诉叶子agent不要委派。汇总结果，把审批权留给用户。
这段话翻译成人话就是：别让你的agent想太多，别让它们带太多行李出门，别让它们互相抢活，别让它们自己再招人。
就这么几句话，可能决定你的月度账单是三位数还是四位数。
一件事还没完：你怎么知道哪档够用？
说到这里，一个更棘手的问题浮出水面：你怎么提前知道一个任务该用low、medium还是high？
你可以在任务跑完之后回头看——哦，这个任务其实low档就够了，刚才开high是浪费。但那是事后诸葛亮。
你可以在任务开始前猜——根据任务类型、复杂度、历史经验做判断。但猜错了怎么办？猜低了，agent完不成任务，要重跑；猜高了，钱白烧了。
OpenAI的解决方案是提供从none到max六档可调，让开发者自己实验。但“实验”本身也是成本。你不可能每个任务都跑六遍再决定用哪档。
更复杂的是：在多智能体场景里，一个任务的“合适档位”可能取决于其他agent在做什么。如果scout查得快，worker就能早开工；如果worker用低档搞不定，smart worker就得介入——整个系统的推理强度是动态变化的。
目前没有一个现成的公式能算出“这个任务用这档、那个任务用那档、总成本最低”。每个团队都在靠试错积累经验。
这意味着什么？意味着多智能体编排不是一个“设好了就不用管”的系统。它是一个需要持续观察、调整、优化的过程。你今天觉得合理的配置，明天换一批任务可能就不成立了。
所以问题不是“有没有标准答案”——而是“你怎么知道自己当前的答案对不对”。
账单会告诉你。但账单告诉你的时候，钱已经花了。