这是一个夸克网盘资源 且:这是一个买断制的skill

先说结论

我给 AI agent 写了一套行为约束框架，叫 trae-adapter。它不是教 agent 怎么写代码，而是给它在执行部署/自动化任务时戴上三道枷锁——防止死循环、防止发散、防止乱扔文件。代码在文末。

死穴一：死循环

表现：部署脚本跑不通 → 换端口重试 → 还是不行 → 换个参数再试 → 失败 → 再试 → 再试 → 再试……

agent 没有"够了"的概念。它会用一个策略反复试到天荒地老，因为从它的视角看，每一次失败只是一次"暂时的挫折"。

我看到的真实案例：一个部署任务，agent 在同一个端口冲突上重试了 11 次，每次只是换一个随端口号。

根因：agent 缺少自监控——它不知道自己"已经试了几次、几种方式、多久了"。

死穴二：瞎逛（发散）

表现：本来让它部署项目，结果它看到了配置文件，顺带看到了 nginx 配置，觉得"顺便优化一下"，然后去读 nginx 文档，然后发现构建脚本写得不好，顺手重构了构建脚本……

半小时后，部署没完成，代码结构已经变了。

根因：agent 没有作用域意识。"顺便"在 agent 的逻辑里不是一个跳出信号，而是一个新任务入口。

死穴三：垃圾文件

表现：工作区里多了 deploy_v1.py、deploy_v2.py、nginx.conf.bak、_test_output.txt、temp/、backup/……

Agent 对文件系统的态度是"先写再说"。它不觉得试错产生的中间文件需要清理——因为"清理"不在它的默认行为集里。

根因：agent 缺少写文件的门槛意识。在很多场景下，信息完全可以用 cat/rg 查看，或者在终端输出里确认，不需要写文件。

解法：不是管住它，而是给它一组合约

我一开始的想法是"写一个更长的 prompt，提醒它别乱来"。试了，没用——prompt 越长，agent 越容易忽略中间部分。

后来换了个思路：给 agent 一套可执行的规则文件，让它在任务开始前强制加载。

规则一：熔断（Circuit Breaker）

- 同一个失败原因，最多试 2 次
- 2 次后必须换策略
- 换了 3 种不同策略都失败 → 停，向我报告
- 一个子步骤超过 5 分钟 → 停，向我报告

不弹性的地方：硬数字。但硬数字才管用。试了 2 次不行，说明这条路不对，不是第 3 次就能妙的。

规则二：作用域围栏（Scope Fence）

- 每次行动前自问：这一步是不是当前子步骤的目标？
- 不是？不做。
- 不读任务范围外的文件
- 禁止"顺手"（顺便改、顺便看、顺便优化）
- 子步骤严格按顺序走，不能回头，不能提前

这条的核心不是限制能力，而是把"发散冲动"转换成"记录冲动"——觉得什么有趣，记下来，做完再回来看。

规则三：文件卫生（File Hygiene）

- 能不写文件就不写文件（用 cat/rg/apply_patch 代替）
- 必须写临时文件 → 写到 .trae_tmp/，前缀 _trae_，用完马上删
- 禁止生成 backup 文件（git 就是 backup）
- 任务结束前扫一遍工作区

这条是最容易执行的，因为都是可验证的操作——不需要判断，只需要照做。

---

这套东西长什么样

目录结构就是一个 Skill：

trae_skill/
├── SKILL.md                          ← 主入口，定义流程
├── agents/openai.yaml               ← UI 元数据
├── rules/
│   ├── 01-circuit-breaker.md        ← 熔断细则
│   ├── 02-scope-fence.md            ← 作用域细则
│   └── 03-file-hygiene.md           ← 文件卫生细则
└── templates/
    ├── task-decomposition.md        ← 任务拆解模板
    └── cleanup-checklist.md         ← 收尾检查清单

SKILL.md 是入口，定义了标准的执行流程：

Step 0 拆解任务 → Step 1-N 顺序执行（每步前检查 scope + 文件，执行时受熔断保护）→ Step N+1 收尾清理

每个文件很瘦（最长的 2500 字符），因为规则不需要长篇大论，需要的是可执行。

---

实际效果

用 vs 不用，差别最大的不是单个任务的完成率，而是行为的可预测性：

• 不用：你不知道 agent 下一步会做什么，可能完成、可能跑偏、可能死循环
• 用了：你知道它最多试几次、不会碰不该碰的文件、做完会打扫

对于一个自动化工具来说，可预测性比能力更重要。一个你信不过的 agent，能力再强你也不敢让它跑通宵。

---

一些代码

规则放这里了，如果你想在你的 agent 上用同样思路：

熔断规则（01-circuit-breaker.md）：

## Retry Limit (same cause)

If a tool call fails, diagnose the cause. For the **same root cause**, retry at most 2 times.

## Strategy Switching

After exhausting retries for one cause, switch to a materially different approach.
After 3 distinct strategies have all failed, stop and report.

作用域规则（02-scope-fence.md）：

## Pre-Action Self-Check

1. Does this action directly serve the current sub-step" explicit goal?
2. Is the action listed in the current sub-step" plan?

If the answer to either is "no" — do not execute.

文件卫生（03-file-hygiene.md）：

## Default: Avoid Writing Files

- Can I achieve this by reading existing files with cat/rg/git show?
- Can I achieve this by running a terminal command?
- Can I achieve this by using apply_patch on an existing file?

If yes to any, do not write a new file.

---

最后

这套规则的核心理念其实就一句话：

Agent 不是能力不够，它是边界感太差。

它什么都能做，是因为它不知道什么不该做。给它一组合约，不是限制它，而是让它成为一个你可以信任的同事——不会突然消失跑去干别的事，不会把同一个问题试一百遍，不会把你的工作区弄得一团糟。

以上是核心思路，够你手搓一份类似的约束规则了。

如果你想直接拿来用，封装好的 skill 文件（SKILL.md + 3条规则 + 2份模板，UTF-8 校验通过）收你一毛钱