# Trae 名词与覆盖关系说明
## 1. 目的
本文用于统一说明 Trae 对话与执行过程中常见名词的含义，以及它们之间的优先级、覆盖关系与职责边界，便于团队在协作时快速判断：
- 哪些信息属于**约束层**
- 哪些能力属于**执行层**
- 出现冲突时应该以谁为准
- 为什么 MCP/Tools **不参与覆盖裁决**
## 2. 先给结论
Trae 可以理解为一套“**上层给约束，Agent 负责执行，Tools 提供能力**”的体系。
- **约束层**负责定义“能做什么、必须遵守什么、当前任务是什么”
- **执行层**负责“如何落地、如何读取上下文、如何调用工具完成任务”
- MCP/Tools 只是能力接口，**不定义规则优先级，也不参与覆盖裁决**
## 3. 简洁优先级 / 覆盖关系
### 3.1 优先级总览
text
高优先级
System / Mode
> Developer
> User Request
> Context / Memory / OpenSpec（补充上下文与执行依据，不能推翻上层显式要求）
> Skills（被触发后约束执行步骤，但不能违背更高层）
> MCP / Tools（仅提供能力，不参与覆盖裁决）
低优先级
### 3.2 一句话理解
1. **System / Mode** 定边界
2. **Developer** 定执行规范
3. **User Request** 定当前目标
4. **Context / Memory / OpenSpec** 提供补充事实与项目约束
5. **Skills** 把执行流程模板化
6. **MCP / Tools** 只是被调用的能力，不负责“谁覆盖谁”的判断
## 4. 两类层次：约束层 vs 执行层
### 4.1 约束层
约束层决定“应该听谁的”以及“允许怎么做”。
包括：
- **System / Mode**
- **Developer**
- **User Request**
- **Rules**（注意：Rules 不是独立权力源，而是来自上述各层的规则集合）
- **OpenSpec**（在被采用的变更流程内，提供项目级执行约束）
- **Context / Memory**（提供补充背景，但通常不是强覆盖源）
### 4.2 执行层
执行层决定“如何把任务做完”。
包括：
- **Agent**
- **Skills**
- **MCP / Tools**
其中：
- **Agent** 是执行主体
- **Skills** 是执行方法包 / 工作流包
- **MCP / Tools** 是能力接口
## 5. 各名词说明
## 5.1 Agent
**定义**：Trae 中真正读取指令、分析上下文、执行修改、调用工具并产出结果的主体。
**定位**：执行层。
**职责**：
- 读取并综合各层约束
- 判断是否需要使用 Skill
- 判断是否需要读取 Memory / Context
- 调用本地命令、MCP 工具、文件编辑能力
- 对结果负责
**关键点**：
Agent 本身**不是最高规则来源**，它必须服从更高层约束。
## 5.2 Rules
**定义**：规则集合的统称。
**定位**：属于约束层，但**不是一个独立优先级层**。
**来源**可能包括：
- System 规则
- Developer 规则
- User 规则
- 项目规则
**关键点**：
判断规则优先级时，不能只看“它是不是 Rule”，必须看“**这条 Rule 来自哪一层**”。
例如：
- 来自 System 的 Rule，高于 Developer 与 User
- 来自 User 的 Rule，必须服从 System / Developer
## 5.3 Skills
**定义**：面向特定任务的标准化工作流说明，例如 code review、单测生成、OpenSpec 流程等。
**定位**：执行层。
**作用**：
- 告诉 Agent 在某类任务下应该按什么步骤执行
- 约束执行顺序、产物和方法
**关键点**：
- Skill **不是独立最高权威**
- Skill 的生效，来自更高层对它的触发要求
- Skill 一旦被触发，Agent 应遵循其 SKILL.md
- 但 Skill **不能覆盖** System / Developer / User 的显式要求
## 5.4 MCP / Tools
**定义**：Agent 可以调用的外部能力接口与本地工具，例如命令执行、文件编辑、网页搜索、MCP Server 提供的能力等。
**定位**：执行层。
**作用**：
- 提供“能做什么”的操作能力
- 不负责决定“该听谁的”
**必须明确的一点**：
MCP / Tools **不参与覆盖裁决**。
也就是说：
- Tool 只能执行被允许的动作
- Tool 不能决定规则优先级
- Tool 返回的结果可以作为事实输入，但不能据此推翻更高层指令
例如：
- 某个 Tool 能删除文件，不代表 Agent 就可以忽略“不要改 spec 文档”的要求
- 某个 MCP 能返回实时数据，不代表它可以覆盖 System / Developer / User 的约束
## 5.5 Context / Memory
**定义**：帮助 Agent 理解任务背景的上下文信息。
**定位**：约束层的补充信息来源。
**包括**：
- 当前对话上下文
- 工作区已有文件内容
- 项目 memory
- 用户偏好 memory
- 环境信息
**作用**：
- 提高连续性
- 减少重复确认
- 让执行更贴近项目历史与用户习惯
**关键点**：
- Context / Memory 主要是**补充**，不是默认强覆盖源
- 当它与更高层显式指令冲突时，应以更高层为准
- 它可以帮助解释需求，但通常**不能单独推翻**当前明确要求
## 5.6 OpenSpec
**定义**：项目内用于变更提案、设计、任务拆解、验证与归档的规范化流程与文档体系。
**定位**：介于约束层与执行层之间，更准确地说是“**项目级过程约束与执行依据**”。
**常见产物**：
- proposal.md
- design.md
- tasks.md
- 相关 spec / change 文档
**作用**：
- 让复杂变更先形成结构化设计
- 让实现、验证、归档可追踪
**关键点**：
- OpenSpec 的约束力来自项目流程和当前任务是否进入该流程
- 它通常**低于** System / Developer / User 的显式要求
- 一旦当前工作明确采用 OpenSpec 流程，其文档会成为实现时的重要依据
- 但它仍不能覆盖更高层约束
## 5.7 System / Mode
**定义**：系统级指令与当前运行模式。
**定位**：最高约束层。
**包括**：
- 系统消息
- 平台运行边界
- 当前模式要求（如 Plan / Spec / Agent Mode）
- 工具使用规则
- 安全与执行限制
**关键点**：
- 它是整个优先级体系中最高的一层
- 后续所有行为都必须服从这一层
- “Mode” 会改变 Agent 当前允许采取的动作范围
## 5.8 Developer
**定义**：开发者为 Agent 预设的执行规范与工程要求。
**定位**：高优先级约束层，仅次于 System / Mode。
**典型内容**：
- 代码编辑约束
- 工具使用偏好
- 输出格式要求
- 测试、验证、审查方式
- 对用户沟通方式的要求
**关键点**：
- 它高于普通用户请求
- 用户要求如果与 Developer 冲突，通常需要优先满足 Developer
- 它常常决定“应该如何做”，而不仅是“做什么”
**补充结论（Developer 与 Agent 提示词的关系）**：
- Developer 通常**包含** Agent 内置提示词里偏工程执行规范的一大部分，例如工具使用、编辑约束、验证方式、沟通风格等
- 但 Developer **不等于** Agent 的全部提示词
- Agent 的内置提示词通常是一个更大的组合，常见可理解为：System / Mode + Developer + 其他运行时约束
- 因此，如果问“Developer 是否包含 Agent 的提示词”，更准确的说法是：**包含其中一大部分工程执行规范，但不是全部**
## 5.9 User Request
**定义**：用户当前回合明确提出的任务、目标、限制与交付要求。
**定位**：约束层中的任务目标层。
**作用**：
- 决定本轮到底要完成什么
- 决定输出物、范围、语言、风格、限制条件
**关键点**：
- User Request 是执行的直接目标
- 但它必须在 System / Developer 允许的边界内实现
- 用户的新消息通常覆盖自己更早的消息，但不能覆盖更高层规则
## 5.10 这些角色在 Trae 里的来源 / 入口
为了避免把“来源”“入口”“是否可见”混在一起，可以先做一个简单划分：
- **用户在 UI 中通常可直接感知的入口**：当前模式、用户输入、工作区文档、部分 Skills 信息
- **主要属于运行时隐含层的入口**：System、Developer、Agent、MCP / Tools、Memory 装载
- **混合型入口**：Rules、OpenSpec、Context，因为它们一部分来自可见文档，一部分来自运行时注入或加载
下面按名词逐项说明：
### System / Mode
- **典型来源**：
- Trae 平台的系统消息
- 当前运行模式（如 Plan / Spec / Agent Mode）
- 平台附带的工具、安全、输出和执行限制
- **在 Trae 里的典型入口**：
-Mode 往往会以“当前模式”形式出现在 UI 或会话上下文里，属于**用户可感知入口**
-System 更多是运行时注入的系统层约束，通常属于**隐含层**
- **理解重点**：
- 用户通常能感觉到“现在是什么模式”
- 但系统层完整指令一般不是用户逐条配置的业务入口
### Developer
- **典型来源**：
- 平台、团队或当前工作流预置的 developer 指令
- 针对工具使用、编辑方式、验证方式、回复风格的工程规范
- **在 Trae 里的典型入口**：
- 通常不是用户在 UI 中单独点击进入的功能入口
- 更多是会话启动时或运行时注入给 Agent 的**隐含层约束**
- **理解重点**：
- 它决定“怎么做”
- 对用户来说往往不是显式表单，而是系统已经带上的执行规范
- 从组成关系上说，Developer 往往是 Agent 内置提示词中的一个重要组成部分，主要承载工程执行规范；但 Agent 的完整内置提示词通常还包括 System / Mode 等更高层内容，因此不能把 Developer 直接等同于整个 Agent Prompt
### User Request
- **典型来源**：
- 用户当前输入的消息
- 用户补充的限制、文件路径、目标、语言要求
- **在 Trae 里的典型入口**：
- 对话输入框
- 可能附带的选中文本、选中文件、补充说明
- **可见性**：
- 这是最直接、最明确的**UI 可见入口**
- **理解重点**：
- 它定义本轮任务目标
- 也是用户最主动、最显式的控制入口
### Rules
- **典型来源**：
-System 层规则
-Developer 层规则
-User Request 中的显式要求
- 项目文档、团队规范、OpenSpec 文档中的约束
- **在 Trae 里的典型入口**：
- 没有一个独立的“Rules 来源按钮”
- 而是分散地存在于系统提示、开发者提示、用户输入、项目文档中
- **可见性**：
- 属于**混合型**
- 有些规则用户可见，有些规则只在运行时生效
- **理解重点**：
-Rules 更像是规则的集合视角
- 真正判断优先级时，仍要回到它来自哪一层
### Context / Memory
- **典型来源**：
- 当前对话历史
- 工作区已有文件
- 项目 memory
- 用户偏好 memory
- 环境信息（路径、操作系统、日期等）
- **在 Trae 里的典型入口**：
-Context 一部分来自当前会话和工作区，用户能间接感知
-Memory 更多由 Agent 在运行时按需读取，通常属于**隐含层**
- **可见性**：
-Context 偏**可见**
-Memory 偏**隐含**
- **理解重点**：
- 用户通常能看到上下文对象本身，例如当前文件和对话
- 但不一定能直接看到 Agent 本轮具体读取了哪些 memory 条目
### OpenSpec
- **典型来源**：
- 项目中的 spec / change 文档
-proposal.md、design.md、tasks.md
- 相关的变更目录与规范文档
- **在 Trae 里的典型入口**：
- 用户明确要求发起或继续 OpenSpec 流程
- Agent 根据当前任务读取已有 spec 文档
- 工作区中的 OpenSpec 文件本身也是直接入口
- **可见性**：
- 主要是**UI/工作区可见入口**
- 但它是否在当前回合生效，仍取决于运行时是否进入该流程
- **理解重点**：
- 文档本身可见
- 约束力来自“当前任务是否采用 OpenSpec 流程”
### Skills
- **典型来源**：
- Trae 内置 skill 列表
- 项目内 .trae/skills/ 下的技能
- 被点名或被任务语义触发后读取的 SKILL.md
- **在 Trae 里的典型入口**：
- 用户在请求里直接点名某个 skill
- 会话上下文里列出的可用 skills
- Agent 识别任务类型后触发对应 skill
- **可见性**：
- skill 名称和列表通常是**可见入口**
- 真正起约束作用的 SKILL.md 执行细则属于**运行时加载内容**
- **理解重点**：
- “有这个 Skill”与“本轮真正启用它”不是一回事
- Skill 的生效入口既可能来自用户显式指定，也可能来自运行时触发
### MCP / Tools
- **典型来源**：
- Trae 内置工具能力
- 已接入的 MCP Server
- 本地命令执行、文件编辑、网页访问、MCP 工具描述与调用
- **在 Trae 里的典型入口**：
- Agent 发起工具调用
- MCP 工具描述文件
- 工具调用记录或执行日志
- **可见性**：
- 对普通用户而言，通常不是主 UI 功能入口
- 更多属于**运行时执行层**
- **理解重点**：
- 用户能看到“调用了什么工具”的结果或痕迹
- 但 MCP / Tools 本身不是用户定义规则优先级的入口
### Agent
- **典型来源**：
- Trae 的核心执行代理
- 当前会话中综合约束、读取上下文并完成任务的主体
- **在 Trae 里的典型入口**：
- 用户通过对话窗口与 Agent 交互
- Agent 的回复、计划更新、工具调用行为是它对外的主要表现
- **可见性**：
- 用户能看到 Agent 的输出结果
- 但 Agent 作为“执行主体”本身更接近**运行时隐含层**
- **理解重点**：
- Agent 是用户真正对话的对象
- 但它不是一个独立规则来源入口，而是综合各层后执行
可以把这一节浓缩成一句话：
> 在 Trae 里，**User Request、部分 Mode、OpenSpec 文档、Skills 列表**更像用户可直接感知的入口；**System、Developer、Memory 装载、Agent 内部决策、MCP / Tools 调用**更接近运行时隐含层；Rules 与 Context 则常常横跨这两类。
## 6. 覆盖关系怎么判定
建议按下面顺序判断：
1. **先看 System / Mode**：当前模式和系统限制是否允许这么做
2. **再看 Developer**：工程规范、工具约束、编辑限制是否允许这么做
3. **再看 User Request**：用户这次具体想做什么
4. **再看 Rules 的来源**：这条规则来自哪一层，就按哪一层优先级处理
5. **再看 Context / Memory / OpenSpec**：它们用于补充事实、减少歧义、细化执行
6. **最后决定是否启用 Skill，并调用合适的 MCP / Tools**
## 7. 一个容易混淆但很重要的点
### 7.1 Rules 不是单独仲裁者
很多时候会说“按 rules 来”，但真正仲裁优先级时，必须拆开看：
- 这条 rule 是系统规则？
- 是 developer 规则？
- 还是 user 规则？
**规则的优先级来自来源，不来自“rule”这个名字本身。**
### 7.2 MCP / Tools 不是裁判
工具只负责提供能力，例如：
- 能不能读文件
- 能不能改文件
- 能不能运行命令
- 能不能访问外部系统
但工具**不负责**：
- 判断谁优先
- 决定是否允许违反高层约束
- 替代 Agent 做规范解释
因此，MCP / Tools 应被视为“执行接口”，而不是“规则来源”。
## 8. 团队协作建议
团队在讨论 Trae 行为时，建议固定用下面这套口径：
- **System / Mode、Developer、User Request**：主约束来源
- **Rules**：规则集合，优先级取决于来源
- **Context / Memory**：补充上下文，不是默认强覆盖源
- **OpenSpec**：项目级过程约束与实现依据
- **Skills**：任务工作流模板
- **MCP / Tools**：执行能力，不参与覆盖裁决
- **Agent**：综合约束并执行的主体
这样可以减少“工具是不是也算规则层”“Skill 能不能压过用户要求”“Memory 能不能改写当前任务”这类歧义。
## 9. 最终总结
用一句话概括：
> 在 Trae 中，**约束层决定边界，执行层负责落地；覆盖裁决看指令来源层级，不看工具能力；MCP / Tools 只提供能力，不参与覆盖裁决。**
共有 0 - Trae 名词与覆盖关系说明