在日常编写代码的时候，Agent 似乎总喜欢乱改我的代码，或者越权处理它不该处理的事务。
比如：
- • Test Agent 本来只负责测试
- • Review Agent 本来只负责审查
- • Deploy Agent 本来只负责发布
但他们实际上却喜欢：
- × 自行修改代码
- × 越权调用工具
- × 跳过审批流程
- × 覆盖其他 Agent 输出
- × 破坏既定执行链路
这种现象叫：
Architecture Drift（架构漂移）
在日常编码过程中，它们的不可控让我感到糟糕，往往我需要花费更多的时间和精力，才能纠正它们的错误。
Skill 的尝试
有时候，我尝试撰写 Skill 在一定的程度上约束他们，希望它们可以遵守我的意图去执行。
这样似乎起到了一定的效果，在执行轻量任务的时候，它们往往会遵守我给他们划好的约束，而且不用我重复地编写 system prompt。
但模型是会推理的
因为 Skill 本质还是：
语义约束（Semantic Constraint）
它依赖 LLM 自觉遵守。
而架构漂移很多时候不是"恶意"，是模型在推理中自我补全。
帮我仅测试，不允许修改代码
然后你的 agent 开始思考了：
模型内部逻辑会变成：
"虽然我是 tester，但修一下能更高效完成任务。"
它不是违抗。
它是 Goal Over-optimization（目标过度优化）。
LLM 很容易为了"完成目标"跨边界。
所以 Skill 最大问题：
它不能 hard-stop 行为。
Skill 能防什么？
更适合：
1. 职责漂移（Role Drift）
比如：
- • Reviewer 开始写代码。
- • Planner 开始跑 shell。
Skill 很有效。
因为是身份提醒。
2. 输出风格漂移
比如 tester 必须输出：
Skill 可以约束。
3. 推理方向漂移
比如：
"先测试，不要先优化。"
Skill 可以拉住思路。
但它控制不了真正的执行边界。
归根到底，Hooks 才能真正解决问题
因为 Hooks 是：
Execution Boundary（执行边界）
最好的做法：Skill + Hooks 分层
Skill
定义职责。告诉 Agent：
你是谁。
比如：Tester / Reviewer / Planner
解决：
语义漂移。
Hooks
限制行为。告诉系统：
它最多能做什么。
解决：
执行漂移。
Skill 让 Agent 知道自己的角色。
Hooks 让 Agent 记住自己的边界。
当系统开始共享状态时，真正防止架构漂移的，往往不是 Prompt，而是 Hook。