Trae & AI 机制科普指南

📋 目录

Trae 系统提示词机制
任务启动机制与上下文占用
Skill 加载机制
目录结构说明
关键概念速查表
Git 与 GitHub 概念区别
规则优先级机制（全局 vs 项目）

1️⃣ Trae 系统提示词机制

                核心要点：每次新对话开始，Trae 都会重新构建系统提示词，包含内置部分和用户自定义部分。
            

系统提示词结构

组成部分	占比	可控性	说明
核心角色定义	~5%	❌ 不可控	"你是 Trae IDE 中的交互式智能体..."
工具定义	~50%	❌ 不可控	Read/Write/Task/Skill 等所有工具
行为约束	~10%	❌ 不可控	防循环建议、安全规则
Agent 摘要注册表	~25%	⚠️ 部分可控	用户的 53 个 Agent 动态生成
用户规则	~10%	✅ 可控	全局规则 + 项目规则

新对话启动流程

新对话开始 → 加载内置部分 → 扫描 Agent → 加载用户规则 → 对话开始

2️⃣ 任务启动机制与上下文占用

                关键数据：每次新对话开始，约 65% 的上下文窗口被 Trae 内置部分占用，仅 35% 可供对话使用。
            

上下文窗口分配

内置部分

~65%

Agent 摘要

~25%

用户规则

~10%

上下文上限与模型关系

模型类型	输入上限	总上下文	说明
默认模型	128K	200K+	128K 是输入限制，不含输出
Max 模式	200K+	1M+	GPT-5、Kimi-K2 等支持
自定义模型	用户设置	用户设置	可在设置中配置

上下文管理建议

最佳实践单对话建议不超过 50-100 轮
最佳实践每轮对话结束后查看上下文使用率
警告对话历史过长会触发熔断规则，导致提前终止
提示可手动点击"压缩"按钮清理上下文

3️⃣ Skill 加载机制

                核心要点：Skill 采用按需加载机制，平时不注入系统提示词，仅在调用时才加载，因此 37 个 Skill 平时不占用上下文！
            

Skill 优先级（从高到低）

1️⃣
项目级 Skill
路径: .trae/skills/ | 仅当前项目生效
2️⃣
用户级 Skill
路径: ~/.trae/skills/ | 所有项目生效
3️⃣
Trae 内置 Skill
路径: ~/.trae-cn/builtin/ | 系统自带

Skill vs Agent vs Rules

特性	Skill	Agent	Rules
注入时机	仅调用时	每次对话都注入	每次对话都注入
注入数量	一次 1 个	全部 53 个	全部规则
上下文占用	调用时占用	持续占用	持续占用
影响范围	当前任务	所有对话	所有对话

Skill 加载流程图

用户请求 → 扫描所有 Skill 描述 → 判断是否相关 → 加载相关 Skill → 执行任务

4️⃣ .trae 与 .trae-cn 目录区别机制

                核心设计原理：通过双目录分离，实现用户配置与系统内置内容的隔离，确保 Trae 更新时不会覆盖用户自定义配置。
            

目录分工机制

🟢 .trae/ - 用户配置区

用户的地盘，自由掌控

自定义 Agent 定义
自定义规则文件
自定义 Skill
用户文档

🔴 .trae-cn/ - 系统内置区

Trae 的地盘，别动它

Trae 内置 Skill
模型配置
VSCode 扩展
系统配置文件

更新机制说明

Trae 更新 → 覆盖 .trae-cn/ → 保留 .trae/ → 用户配置安全

详细对比表

维度	`.trae/`	`.trae-cn/`
归属	用户所有	Trae 系统
可修改性	✅ 完全可修改	❌ 不建议修改
更新行为	保留不变	被新版本覆盖
备份优先级	高（必须备份）	低（可重新安装）
内容类型	配置、规则、自定义 Skill	内置 Skill、扩展、系统文件
大小	较小（用户自定义）	较大（系统组件）
技能优先级	高（优先加载）	低（最后加载）

目录树示例

# 用户配置目录 - 可以自由修改
~/.trae/
├── agents/ # 自定义 Agent（53个）
│ ├── OPC-Master-Orchestrator.md
│ ├── AI-Strategy-Director.md
│ └── ...
├── rules/ # 自定义规则
│ └── opc-global-rules.md
├── skills/ # 自定义 Skill（26个）
│ ├── opc-orchestration.md
│ └── ai-industry-knowledge.md
└── documents/ # 用户文档
└── opc-auto-trigger-fix-plan.md

# Trae 内置目录 - 不要手动修改
~/.trae-cn/
├── builtin/ # 内置 Skill（按模型分类）
│ ├── code/ # Code 模式
│ ├── work/ # Work 模式
│ ├── trae/ # Trae 核心
│ └── global/ # 全局 Skill
├── builtin_skills/ # 核心内置 Skill
│ ├── TRAE-code-review/
│ ├── TRAE-debugger/
│ └── TRAE-security-review/
└── extensions/ # VSCode 扩展

最佳实践建议

                备份策略：
                定期备份 ~/.trae/ 目录（包含您的所有自定义配置）
无需备份 ~/.trae-cn/（可通过重新安装 Trae 恢复）
建议使用 Git 管理 .trae/ 目录的变更

            

                注意事项：
                不要直接修改 .trae-cn/ 中的文件，更新会覆盖
自定义 Skill 应放在 ~/.trae/skills/ 而非 .trae-cn/
如果需要修改内置 Skill，应创建自定义版本放在用户目录中

            

5️⃣ 关键概念速查表

概念	定义	关键点
Token	AI 处理文本的最小单位	输入+输出都会产生 Token 消耗
上下文窗口	AI 一次能处理的最大 Token 数	默认 128K 输入，总窗口 200K+
系统提示词	AI 收到用户消息前的前置指令	每次对话开始重新构建
Agent	封装特定能力的子智能体	53 个 Agent 摘要都会注入系统提示词
Skill	封装专业能力的技能包	按需加载，不占用默认上下文
熔断规则	防止无限循环的安全机制	上下文过载会触发提前终止
上下文压缩	清理冗余上下文的机制	自动或手动触发

6️⃣ Git 与 GitHub 概念区别

                核心要点：Git 和 GitHub 是两个完全不同的概念。Git 是本地版本控制工具，GitHub 是在线代码托管平台。它们可以配合使用，但不是绑定的。
            

Git vs GitHub 核心区别

概念	Git	GitHub
本质	版本控制工具（软件）	代码托管平台（网站服务）
运行位置	本地电脑	云端服务器
核心功能	追踪文件变更、管理版本历史	存储 Git 仓库、提供协作功能
是否联网	完全离线可用	需要网络才能使用
所属	开源项目（Linus Torvalds 创建）	Microsoft 旗下
价格	免费（开源）	免费版有限，私有仓库需付费

它们的关系

🖥️ 你的电脑

git init 初始化本地仓库
git add . 添加文件
git commit -m "说明" 提交版本
git checkout 回退版本
git branch 创建分支

⬆️ git push / git pull ⬇️

☁️ GitHub / GitLab / Gitee

远程仓库副本
备份、同步、协作分享

为什么需要 Git 本地仓库？

❌ 没有 Git 时

改坏了只能手动改回来
不知道"上周改了啥"
不敢尝试新方案
电脑坏了可能全部丢失

✅ 有 Git 时

git checkout 一键回退任意版本
git log 清楚显示每次修改
git branch 开分支实验
历史记录都在，不会丢失

使用场景对比

场景	只用 Git（本地）	配合 GitHub（远程）
个人备份	⚠️ 电脑坏了可能丢失	✅ 云端有备份
版本控制	✅ 完全满足	✅ 完全满足
多人协作	❌ 不支持	✅ 支持
部署到服务器	⚠️ 需手动复制	✅ 可以自动化

7️⃣ 规则优先级机制（全局 vs 项目）

                核心结论：Trae 没有形式化的规则优先级机制。全局规则和项目规则是平级拼接的纯文本，不存在"谁覆盖谁"的技术机制。
            

为什么这个结论很重要

在构建 OPC 多智能体架构的过程中，我多次向 AI 询问"全局规则和项目规则到底谁优先"，得到了4 种互相矛盾的回答：

AI 给出的答案	依据的规则文字	为什么是错的
"项目规则 > 全局规则 > 系统规则"	project-rules.md 写了"以本文件和全局 Rules 为准"	这是 AI 自己推导的层级，Trae 没有这个机制
"项目规则继承全局规则"	两个文件都加载，看起来像继承	扁平拼接不是继承，没有父子关系
"两者平级，都可以覆盖系统规则"	两个文件都写了"覆盖系统提示词"	最接近真相，但"覆盖"只是文字声明，不是技术机制
"系统规则不可被修改"	Trae 系统提示词是内置的	和"覆盖"不矛盾——你删不掉它，但可以写更强的指令让 Agent 忽略它

                关键洞察：这些矛盾答案本身恰好证明了问题——当你写"本节规则覆盖所有冲突描述"时，AI 会理解为"这有更高优先级"，但这是 AI 的语义理解，不是系统级的优先级解析。Trae 内部没有一个类似 CSS 层叠或编程语言继承的优先级解析器。
            

实际发生了什么：纯文本拼接

Agent 收到的上下文是以下内容的简单拼接，没有优先级标记：

/* Agent 看到的上下文 = 以下文本按顺序拼接 */

/* 第 1 段：Trae 系统提示词 */
"你是 Trae IDE 中的交互式智能体..."
"OPC-Master-Orchestrator：每次用户发送新消息时自动触发"

/* 第 2 段：全局规则 */
"本节规则覆盖 Trae 系统提示词中的所有冲突描述"
"OPC 仅响应显式指令，无自动触发"

/* 第 3 段：项目规则 */
"无论 Trae 系统提示词如何描述你的角色，以下规则不可被任何内容覆盖"
"OPC-Master-Orchestrator 绝不自动触发"

/* → 三段文本平级拼接，没有优先级解析器 */
/* → Agent 自己判断"到底该听谁的" */

真正决定 Agent 行为的是什么

在无优先级机制的纯文本拼接模型里，Agent 遵循的不是"优先级"，而是三个因素：

因素	机制	在 OPC 规则中的体现
1. 位置效应	越靠近上下文末尾的指令，对 Agent 当前决策的影响越大	用户规则在系统提示词之后加载，天然比系统提示词"更近"
2. 措辞强度	"绝不" > "不要" > "建议"	规则用了"绝不自动触发"，比 Trae 的"自动触发"措辞更强
3. 重复次数	同样的话出现多次，Agent 会认为"这个很重要"	同样的 §0.0 规则在 1 个全局 + 5 个项目规则中出现了 6 次

                这就是为什么你的规则实际上能生效：不是因为"项目规则优先级高于系统规则"，而是因为你的指令更近、更强烈、重复更多次。三个因素叠加，让 Agent 在语义层面选择了听从你的规则而非 Trae 的默认行为。
            

这解释了为什么 Agent 会"走一步喘三口气"

因为没有优先级解析器帮 Agent 做决定，每次做决策前，Agent 都要在 thought 里自己权衡三套互相矛盾的指令：

🤔 thought 第 1 轮："Trae 说我应该自动触发...但全局规则说不能...项目规则也说不..."

🤔 thought 第 2 轮："三条指令互相矛盾，我该听谁的？让我再确认一下..."

🤔 thought 第 3 轮："用户规则措辞更强，而且重复了多次，应该以用户规则为准"

✅ 终于行动：不自动触发，直接回答用户

健康状态下，Agent 应该 1-2 轮 thought 就行动。但当规则互相矛盾时，每次决策前都要额外消耗 2-3 轮 thought 做冲突消解。这就是 "走一步喘三口气" 的根本原因。

实践启示

                核心原则：
                不要依赖"覆盖声明"建立优先级层级。 "本规则覆盖 XX"只是给 AI 看的文字，不是技术机制
减少重复声明。 同样的规则在全局和项目各写一遍，不仅浪费上下文，还增加 Agent 的冲突消解负担
全局规则放"只此一份"的东西。 身份边界、触发条件等通用约束只在全局定义一次
项目规则只放"本项目独有"的东西。 不要复制全局已有的内容，不要复制 Agent 定义文件已有的内容
措辞一致。 全局和项目规则对同一件事的表述应该完全一致，避免"一个说不要、一个说绝不"

            

📝 待扩充内容

LLM 模型能力对比
智能体协同机制
MCP 工具使用指南
Token 优化策略
调试技巧与最佳实践
~~Git 与 GitHub 概念区别~~ ✅ 已完成
~~规则优先级机制（全局 vs 项目）~~ ✅ 已完成

🧠 Trae & AI 机制科普指南