晨星
声明： 本文档仅代表个人使用体验及尝试结论，不构成对 Trae 框架的官方判定。实际情况以官方文档及框架行为为准。
当前 SubAgent 相关基建总览
规则层（rules/）
技能层（skills/）
当前 M 路径流程图（简化）
writing-plans
└── executing-plans (耦合任务/无子agent)
└── subagent-driven-development (独立任务/有子agent)
└── 逐任务: 分派 implementer → 接收结果 → 两阶段审查 → 验证已做的优化努力
Choice Rule（M 路径选择标准）
新增选择标准，试图让主 agent 在两种执行模式间做出理性决策：
Prefer
executing-planswhen tasks are tightly coupled or the environment lacks reliable implementation subagents. Prefersubagent-driven-developmentwhen tasks are mostly independent and implementation subagents are available.
分派入口补全
-
dispatching-parallel-agents在 Skill Routing Table 中独占一行 -
Subagent Dispatch 在 routing 规则中被单独列为一节，并加入 M/L 执行中的接入注记
dispatching-parallel-agents 与 subagent-driven-development 存在职责边界模糊：前者面向只读并行分析，后者面向实现性任务的子 agent 分派。两者均涉及"分派"行为，但使用场景不同，暂未合并。
Fast-Track Assessment（子代理简化分类）
在 subagent-driven-development 内部，提供一个简化的 T-Shirt Sizing 用于决定是否跳过独立审查代理：
-
Low Risk (S): 纯文档/样式微调 → Fast-Track（跳过独立审查）
-
Normal Risk (M/L): 功能逻辑 → Standard Flow（两阶段审查）
两阶段审查控制器
控制器按顺序执行 specs 合规性审查和代码质量审查，确保子 agent 输出不仅正确且符合项目规范。
未解决的局限性
核心矛盾：主 agent 优先自我执行
目前存在一个根本性的行为问题：
即使规则和触发条件都满足，主 agent 依然优先自己完成，而非委派给子 agent。
具体表现为：
委派行为无法通过规则固化
规则（rules）和技能（skills）的触发机制是建议性的，而非强制性的：
-
alwaysApply: true仅保证规则内容被注入上下文，即使改用更强硬的语气（如 "MUST delegate"），仍无法覆盖 agent 的内部决策 -
技能描述匹配仅提高被调用的概率
-
最终"是否委派"的决策权完全在主 agent 的内部推理中，规则无法强制执行委派行为
上下文依赖——新会话中归零
当用户纠正主 agent 的行为后，当前会话中 agent 能够"反思"并改进。但在新会话中，无上下文的条件下，上述所有问题会重新出现：
-
agent 不记得上次项目的协作模式
-
每条规则的 load 是独立的，agent 不会从历史记忆中学习"应当委派"的模式
-
核心的记忆（Core Memory）系统只存储用户偏好和技术约定，不存储行为模式历史，因此在框架支持之前，无法通过 Core Memory 实现跨会话的委派行为一致性
缺少委派正当性判断
当前体系没有回答一个关键问题：主 agent 何时应该委派，何时应该自己完成？
缺乏以下决策维度：
-
任务复杂度 vs 子 agent 能力的匹配度（缺少子 agent "能力注册表"，主 agent 无法精确知道哪个子 agent 能做什么）
-
委派带来的上下文切换开销
-
子 agent 输出质量的可靠性
-
串行 vs 并行的时间收益对比
子 agent 委派粒度过粗导致上下文膨胀
主 agent 在委派时缺少"任务拆分粒度"的判断能力，典型场景：
项目文件 30+，规则已声明"应按照标准拆分子 agent"，但主 agent 仅委派了一个 search 子 agent，该子 agent 独立扫描并阅读全部 30+ 文件。由于子 agent 上下文容量有限，触发压缩后重新执行，再压缩再执行循环，效率极低。
核心问题：
-
主 agent 将"委派"理解为"交给一个人做"，而非"拆成多份并行做"
-
子 agent 的上下文容量可能小于主 agent（或模型不一致），但主 agent 在委派前未做此评估
-
同样的任务由主 agent 独立执行不会触发上下文压缩，因此用户感知到明显的效率落差
已做努力及仍然存在的问题
针对上述问题，已在规则和技能层面做了以下努力：
核心矛盾：所有努力的共同特征是事后响应（先出问题再降级），而非事前预防（在委派前精准评估子 agent 的上下文容量并据此拆分）。主 agent 缺少"子 agent 上下文有多大"的感知能力和"多大任务量会触发压缩"的预判能力。
根本原因分析
问题层: 主 agent 优先自我执行
↓
机制层: 规则/技能触发是建议性，非强制性
↓
架构层: Trae 的 agent 体系是"主 agent 为中心"的单体架构
子 agent 是辅助工具，而非平等协作节点
↓
设计层: 主 agent 的决策优先级: 自己完成 > 委派给子 agent
主 agent 将"委派"理解为单次任务移交而非拆分并行
子 agent 上下文容量可能低于主 agent，但无预检机制
这是框架的设计选择，非 bug结论
当前子 agent 体系的设计哲学是增强（Augmentation）而非替代（Delegation）。主 agent 是唯一的执行决策者，子 agent 只在其主动选择分派时才会被调用。规则和技能无法改变这一设计前提。
要使子 agent 自主分派成为稳定可靠的行为，需要框架层面的改变——让"委派"成为主 agent 的默认优先策略，而非当前"自我执行优先"的策略。具体而言，框架需要回答：主 agent 在何种条件下应当将子 agent 的"委派"优先级提升到"自己执行"之上，并以此重构决策优先级。
临时缓解方案
当前策略
等待官方优化（Wait for Framework）。
上述所有局限性的根本原因是 Trae 框架的设计选择——主 agent 是唯一的执行决策者，子 agent 是辅助工具而非平等协作节点。规则和技能无法改变这一前提。
在此框架层面改变之前，任何规则层或技能层的修复都只能缓解症状，无法根治。不建议投入更多精力在规则层面继续尝试强制委派行为。