从Trae SOLO谈多智能体的困局

Trae是字节跳动做的AI编程工具，最近推出了SOLO模式，官方定位叫"上下文工程师（Context Engineer）"，通过AI主导全流程开发，从需求到交付一条龙闭环。这个定位本身是清晰的，也是行业共识的方向。

不过在SOLO的功能矩阵里，有一个引起我兴趣的设计：多智能体协作。你可以创建一组Agent，“前端专家、后端专家、测试工程师”，由一个主Agent当项目经理，根据任务自动派活，各Agent分头干事，最后汇总交付。

这不是Trae独有的思路。多智能体在整个AI编程赛道都是热门概念，论文、开源项目、产品发布会上频繁出现。它背后的直觉很自然：人类团队是分工协作的，AI团队是不是也该这样？

我花了不少时间拆这个思路。拆完之后觉得，问题可能不在于Trae做得好不好，而在于多智能体这条路在AI编程领域本身就有几个很难绕过去的困难。下面把这个思考过程完整讲一遍。

· · ·

给Agent贴"角色标签"还有用吗？

多智能体的底层逻辑是角色分工。你告诉一个Agent"你是前端专家"，告诉另一个"你是后端专家"，期望它们各司其职、术业专攻。

这个思路在两年前是有效的。GPT-4o 那个年代，你加一句"你是一个资深Python工程师"，输出质量确实会有可感知的提升。模型能力不够的时候，角色提示帮它"对焦"，确实管用。

但到了Claude Opus、GPT-5.5 这一代模型，这招的边际收益已经非常小了。你说"你是前端专家"和"现在处理前端任务"，对输出几乎没有区别。模型足够强了，不需要你帮它入戏。

2026年4月有一篇论文做了个直接的实验：同样的token预算，让一个模型自己安静地想，和让多个"角色"Agent互相配合讨论，哪个效果好？结论是前者更好。你给同一个强模型同样多的思考资源，一个人想比几个人传话更靠谱。

这就引出一个值得追问的问题：如果角色分工对强模型没什么用，那多智能体框架的核心假设是不是正在失效？

当然，不是所有模型都足够强。Trae国内版用的豆包、Kimi、GLM，能力确实不如Claude Opus，角色提示对这些模型可能还有一些帮助。但这就形成了一个尴尬的局面，多智能体这个架构，越是在需要它的地方（弱模型）越有一点价值，越是在不需要它的地方（强模型）越像多余的包装。而模型能力只会越来越强。这条路的天花板肉眼可见。

这个发现让我开始想另一件事：就算角色标签本身没什么用，多智能体不是还有一个更实在的卖点吗：上下文隔离？

· · ·

解决了一个问题，制造了一个更难解的新问题

上下文污染确实是真实的痛点。你跟一个AI聊了200轮之后，前端的逻辑、后端的逻辑、之前讨论过又放弃的方案全搅在一起。AI注意力被稀释，改一个地方很容易把另一个地方弄坏。谁用过AI写复杂项目都遇到过这个问题。

多智能体给出的方案是把任务拆到不同Agent上，每个Agent只看自己那部分上下文。前端Agent不会被后端代码干扰，后端Agent也不会被CSS分神。乍一听挺合理。

但拆开之后有一个新问题冒出来了，而且这个新问题可能更难解：Agent之间不知道对方在干什么。

后端Agent决定把一个API的返回格式从JSON改成protobuf，这是个重要决策，前端必须知道才能正确处理。这个信息怎么传过去？靠主Agent转述。而转述就是压缩，压缩就会丢东西。"API格式从JSON改成protobuf"可能被压缩成"后端接口有更新"。前端Agent拿到这个模糊的信息继续按JSON解析，结果翻车。

单Agent的问题是一个人管太多事容易走神。多Agent的问题是几个人各管各的容易信息脱节。矛盾只是转移了，没有消失。

而且有个趋势让这个对比越来越不利于多Agent：上下文窗口在物理上越来越大。但多Agent之间信息传递失真的问题不会因为窗口变大而改善，瓶颈不在窗口大小，在于Agent间通信本身的信息损耗。

一个问题在随着技术进步自动变好，另一个不会。赌哪边，其实很清楚。

想到这里自然就有了下一个问题：多Agent声称要解决的那些事——工具权限、文件范围、上下文隔离——真的只有多Agent才能做到吗？

· · ·

其实不需要多Agent也能做到

答案是不需要。

先说工具权限。Claude Code用一个参数--allowedTools就能限制这次任务只允许用哪些工具。Cursor用Rules文件来定义。一个配置项搞定的事。

再说文件范围。Claude Code用allowedDirectories指定只能看哪些目录。你说"这次只看src/frontend/"，效果跟"创建一个前端Agent并把它的文件范围设为src/frontend/"完全一样。

最后说上下文隔离。分阶段执行就行了——先做完前端任务，压缩上下文只保留结论，再开始后端任务。Claude Code的/compact命令就干这个。效果跟拆成两个Agent差不多，但省掉了Agent间通信的额外开销。

三个简单问题，用三个简单方案各自解决。多智能体把它们打包成一个大架构，引入了调度决策、Agent间通信、额外token消耗一堆新复杂度。

就好比你要拧一颗螺丝，有人递给你一把瑞士军刀说"这个更高级"。能拧吗？能。但一把螺丝刀更顺手。

既然更简单的方案就够用了，那多Agent额外引入的复杂度就不是"能力增强"，而是纯粹的开销。这个开销有多大呢？

· · ·

多Agent的隐性成本

这里需要把一件事说清楚：AI编程的全流程自动化本身就是token密集型的操作，Plan规划、工具调用、上下文检索、代码生成、预览验证，每一步都在花token。这不是多Agent特有的问题，单Agent全流程自动化一样贵。

但多Agent会在这个基础上再叠一层额外开销。主Agent每次调度Sub Agent，都要做一组"管理动作"：分析任务、判断该派谁、给Sub Agent写任务简报交代背景、等Sub Agent跑完、读取结果、汇总。这些管理动作消耗的token，跟你真正想完成的编程任务没有关系。

一个人干活不需要开会。三个人干活，光协调就要花掉一大块时间。Agent也一样。

而且这个开销不是线性的，Agent越多，两两之间的潜在通信路径就越多，协调复杂度会加速上升。这跟软件工程里经典的Brooks定律是一个道理：往一个延期的项目里加人，项目反而更慢，因为沟通成本的增长速度超过了产出的增长速度。

反观Claude Code的做法：一个Agent、一个大上下文窗口、需要确认的时候问你一声。没那么"未来感"，但token花在刀刃上。

到这里，多智能体的几个核心卖点“角色分工、上下文隔离、统一协作”都拆了一遍。还有两个相关的概念也值得聊，因为它们经常跟多智能体一起出现在AI编程工具的宣传里，也都存在"包装大于实质"的问题。

· · ·

"创建智能体"：你在造东西？其实你只是在填表

不少AI编程工具都提供了"创建自定义智能体"的功能。可视化面板，拖拖拽拽，定义角色、写提示词、配工具。有的还支持"让AI帮你写提示词来创建Agent"。

听起来像是你在从零构建一个AI助手。但看看你实际做了什么：

名字：填了个字符串，比如"前端专家"。角色描述：写了一段系统提示词。工具：勾选了几个可用工具。文件范围：选了几个目录。

这就是一个JSON配置文件。一个"前端专家"和一个"后端专家"之间，90%是一样的：同一个底层模型、同一套运行环境、同一套工具框架。差异只有那段提示词和几个勾选项。

这跟下载一个App有什么区别？你没有创造任何东西，只是从货架上拿了一个预制品贴上了自己的标签。

Cursor用一个.cursorrules文件做同样的事。Claude Code用一个CLAUDE.md文件做同样的事。功能完全等价，只是没包装成"创建智能体"这个听起来很了不起的概念。

· · ·

"一句话生成完整项目"：真的，但只在Demo级别

这是AI编程领域另一个流行的营销语。

先说它能做到的部分。你说"做一个Todo应用"，AI确实能从技术选型到写代码到本地预览一条龙搞定。一个落地页、一个简单小游戏、一个博客模板，这类东西确实可以一句话跑通。这个能力是真实的，对快速验证想法有实际价值。

但这些东西有个共同特征：你不说清楚需求AI也不会做错，因为压根没什么可以做错的。一个Todo应用就是那个样子。

一旦到了需要真正做决策的项目：选React还是Vue？用REST还是GraphQL？数据库用MySQL还是PostgreSQL？AI的"自动选型"本质上是在赌训练数据里哪个出现频率最高，不是在选最适合你场景的方案。

而涉及复杂后端、跨服务集成、已有代码库的迭代，用户反馈高度一致："后端生成基本翻车"、"修一处坏一处"、"简单网站启动不了等了半小时还在debug"。

一句话生成完整项目，在Demo场景下是真的。但适用范围被夸大了。

· · ·

说到底

从Trae SOLO的多智能体聊起，但想说的不只是某一个产品。

整个AI编程工具赛道正在经历一轮概念通胀。多智能体、Agent Team、Context Engineer、一句话生成项目，每个概念都有论文、有Demo、有KOL背书。但落到每天真实写代码的场景里，这些概念的实际收益远没有PPT里那么大。

真正决定一个AI编程工具好不好用的就两件事：底层模型有多聪明，上下文管理有多高效。这两件事很朴素，不性感，不适合拿来做营销。但它们是地基。所有的多智能体编排、可视化Agent面板、一键生成项目，都是在这个地基上做加法。地基不够实，加法加得再花也是空中楼阁。

用多智能体来弥补模型能力的不足，就像用更多人来弥补单个人能力的不足。有时候管用，但更多时候光是协调成本就把增益吃掉了。

十个孕妇不能一个月生出孩子。有些问题只能靠模型本身变强来解决。