你的运行环境（版本号「点击帮助-关于-复制」）：
3.3.73
问题描述（你遇到了什么问题？）：
如下面图二，多智能体调用，之前没事，更新之后可能是因为加了子智能体配置并行啥的，导致trae不能识别我自定义的，会胡乱的创建子智能体来执行，这样的话我个人定义的prompt就起不到效果了。想了很多办法，尝试之后都不行，还是感觉是智能体路由的问题，求助大佬们答疑解决啊！！！！！
项目规则里面也都写死了但是还是不行，全局规则也加了
复现步骤（如何才能重现这个 Bug/问题？）：
1.我是创建了多智能体流程之后按照这个来运行，不定期出现，不一定百分之百能实现
2.模型用的minimax3 不知道和模型有没有关系
报错信息或截图（如有）：
这个问题确实比较让人头疼！从你的截图和描述来看，现象很明确：主智能体在调用子智能体时，没有准确传递（或系统没有匹配到）你配置的英文标识（如 sql-business-verifier），导致系统触发了兜底机制，回退到了默认的通用子智能体 Sub Coding Agent (general_purpose_task)。
更新后引入了更复杂的机制，可能对模型调用工具（Tool Calling）时的参数匹配要求更严格了。你可以尝试从以下几个方向排查和调整：
进入每个自定义智能体的设置页面，确认以下两点：
sql-business-verifier）是否完全一致，注意检查有没有多余的空格等不可见字符。你提到目前使用的是 minimax3 模型。在多智能体协同和复杂的工具调用场景下，不同模型对参数格式的遵循能力差异很大。更新后的路由机制可能对参数的精准度要求更高，导致模型在生成调用指令时，没有把正确的标识名传进去。
强烈建议：暂时切换到 Claude 3.5 Sonnet 等其他更强的模型跑一次相同的流程，看看是否能正确路由。如果换模型后能精准命中，那大概率是模型对工具调用参数的遵循能力导致的。
如果大模型容易把它识别为 general_purpose_task，我们需要在项目规则中对调用动作施加更强的约束。
不要只写“强制要求使用以下智能体”，建议明确指出调用的具体动作。例如可以加上：
“
严格警告：当主智能体需要分配任务给子智能体时，必须严格使用对应的英文标识名（如
sql-business-verifier）指定目标。绝不允许将其作为普通任务（general_purpose_task）或使用默认的 Sub Coding Agent 处理。”
就像你在截图二里分析的那样，作为临时的解决方案，可以在主智能体或全局规则里加一条“防误调”逻辑：
“如果发现当前任务被错误分配给了通用的
Sub Coding Agent而不是具体的专家智能体，必须立刻停止执行，并使用正确的英文标识重新发起调用。”
你可以先试试切换一下模型和强化提示词，看看能不能把路由纠正过来。如果还是无法命中，随时来同步新情况～
1.肯定开了，这个都配置好英文名字，并且项目规则里面也都要求了几个智能体什么时候调用都写好了。
2.直接就让我用claude吗？
3.这个看不出来是主智能体推送了智能体名称之后，trae掉用了其他得了吗？这个后续更新不会找原理呢吗？
4.兜底防御想了很多没有一个明确的角度去处理，最有可能实现的是，trae的 solo agent可以看他们的指纹，就是我在他们的prompt里面添加自己叫什么名字，开始干活的时候先报道，主智能体发现没有这个报道之后直接打断，重新调用。但是我试了试好像trae不支持，就得干完了之后才能看到他们的名字啥的。这个很麻烦
哈哈，别误会，建议用 Claude 并不是让你以后只能用它，这其实是一个控制变量的测试手段～
你问到原理，其实多智能体调用的过程是这样的：主智能体决定分配任务时，会输出一段包含“子智能体英文名”的调用指令，TRAE 接收到指令后再去匹配对应的子智能体。
如果在 3.3.73 版本中加入了并行等新机制，这个调用指令的格式可能变复杂了。如果 Minimax3 生成的指令有哪怕一点点格式偏差，TRAE 的路由没有精准匹配上，就会触发兜底，强行分配给默认的 Sub Coding Agent。
所以建议用 Claude 试一次，如果 Claude 能精准命中，说明是 Minimax3 对新格式的适配问题；如果 Claude 也全军覆没，那就是 TRAE 这一版的路由代码本身出了 Bug。
关于你说的“指纹报到”机制，思路真的非常巧妙！但确实如你所试，目前 TRAE 的子智能体是在独立上下文里异步执行的，必须等它完全跑完才会把结果返回给主智能体，所以没法做到“不对就立刻打断”。这个绕行方案确实太折腾了，不建议你继续在这上面耗费精力。
既然你的配置都没问题，且是更新后才出现的，这大概率是版本更新带来的退化问题，研发团队肯定需要从底层去修复它。为了能让他们直接看到“主智能体到底推送了什么名字、TRAE 是怎么解析的”，我们需要抓取一下底层的调用日志：
需要你提供 AI Trace 信息来帮助定位问题：
在出问题的 AI 对话中，双击 AI 的头像即可自动复制 trace 信息，然后粘贴到这里发给我。研发同学可以通过这段 Trace 直接看到底层路由的断点在哪里。
.2957040698272860:2dd8fea7fb66f7c249b77a6e8331d29a_6a4779307c6eda49059ef9ff.6a4ca169edf581c242d473e5.6a4ca1670ad30a571f8eb7b4:Trae CN.T(2026/7/7 14:49:13)
收到 Trace 信息啦，非常感谢！
有了这串代码，研发同学就能直接去后台捞底层日志，看清楚当时主智能体到底输出了什么调用指令，以及 TRAE 的路由为什么没有成功匹配到你自定义的英文标识，而是触发了兜底的 Sub_coding_agent。
这对于排查 3.3.73 版本更新（特别是加入多智能体并行等机制后）带来的路由退化问题非常有帮助，能精准定位到底是 Minimax3 的格式适配问题，还是底层解析逻辑的 Bug。
既然你是在论坛发的帖，官方研发同学会直接关注到这个帖子，并通过你提供的 Trace 展开排查。再次感谢你这么详细的测试和反馈（特别是那个“指纹报到”的思路，真的非常极客
）！
后续排查和修复有进展，团队会在帖子里同步给你。如果还有其他发现，随时来聊～
你换下glm5.2试试看，minimax我似乎在别的帖子也看到类似的问题
我研究过，因为我这一套RAG+多智能体协同重点还是侧重智能体的agent能力，评分来看minimax是最高的，GLM还是变成比较多，我试试DS吧，现在用DS的人太多排队有点严重，我看看还有这个现象不
你的路径是固定要用哪些agent来解决的吗，如果是的话写个skill限制把这些workflow描述在其中试试看，启动对话的时候强制/用你那个skill
我写到trae的.rule里面了 
问题是主智能体这么调用的，然后trae跑的别的就跟我截图那个是的