嗨，你好嗎？我係 Lena。幾個月前我睇住一個 agent 喺 codebase 入面跑，佢就咁……一直跑落去。冇停過，冇問過我。佢改咗三個我根本冇提過嘅檔案，然後仲好貼心咁建議可以對另外四個檔案做同樣嘅嘢。段 code 唔算係錯，但就唔係我想要嘅嗰種對法。
嗰陣我先開始認真留意呢啲 agent 到底係點樣被約束嘅——唔係佢哋能唔能做某件事，而係你點樣話畀佢哋聽應該做咩。更加重要嘅係，你點樣話畀佢哋聽，邊啲嘢係永遠唔好做，除非先問過你。
呢個就係大家講「superpowers」嘅時候真正嘅意思。呢個詞其實幾誤導。Superpower 唔係原始嘅能力。而係你可以塑造嗰種能力點樣被使用嘅能力——一致咁、可重複咁、喺 agent 跑嘅每一個 session 入面都係咁。
「Superpowers」喺 Agent Workflows 入面到底係咩意思
唔係 features——而係行為約束系統
我成日見到「superpowers」呢個詞被用嚟形容 features：code execution、web search、tool access。 咁理解都得。但當我觀察嗰啲真正喺 production 入面跑 agent 嘅人，佢哋嘅對話幾乎永遠係關於另一樣嘢。
係關於 constraint systems。
問題唔係「呢個 agent 可以做咩？」問題係「我點樣阻止佢做我唔想佢做嘅嘢，同時仲畀佢做我想佢做嘅嘢？」呢個係一個 governance 問題。而 governance 需要嘅係被一致應用嘅規則——唔係你貼喺 prompt 入面然後祈禱佢會跟嘅提醒。
點解 agent 需要嘅係規則，唔係淨係工具
呢度有樣嘢係我好早就注意到嘅：冇行為約束嘅 agent 唔係差，佢哋係 unpredictable。佢哋會有一半時間攞到正確答案，然後另一半時間做啲完全出乎意料嘅嘢——唔係因為個 model 壞咗，而係因為冇任何嘢將行為錨定喺你嘅標準上面。
Tools 畀咗 agent 觸及範圍。Constraints 畀咗 agent 方向。
大部分團隊都係意外咁撞到呢個分別嘅。佢哋加咗 tools，睇住個 agent 跑，然後被佢自己決定做嘅嘢嚇親，先開始寫規則。失敗嘅模式教識你本來應該有咩 constraint。
Superpowers 喺主要工具入面係點樣運作嘅
Claude Code — skills、CLAUDE.md 同 permission scoping
Claude Code 擁有我認為係最結構化嘅方法嚟處理呢個問題。核心機制係 SKILL.md 檔案——一個帶 YAML frontmatter 嘅 markdown 檔案，將指令、scripts 同 references 打包成一樣嘢，等 Claude 可以喺相關嘅時候動態載入。
我覺得呢個設計真正有趣嘅地方係 Anthropic 叫做「progressive disclosure」嘅嘢。當一個 session 開始嘅時候，Claude 淨係載入每個已安裝 skill 嘅名稱同描述——唔係完整內容。完整嘅指令淨係喺 Claude 判斷呢個 skill 同當前任務相關嘅時候先會被載入。正如官方 agent skills 文檔所描述嘅：skill 就好似畀新同事嘅入職指南，agent 淨係睇佢需要嘅嗰啲章節。
仲有 CLAUDE.md——一個持久嘅檔案，放喺你嘅 project root 入面，喺成個 session 入面都帶住常設指令。同 skills 唔同，佢永遠都喺度。你可以將佢理解為 baseline contract：你嘅架構決策、你嘅檔案慣例、嗰啲你永遠唔想 agent 假設或者跳過嘅嘢。
Permission scoping 係喺 tool 層面運作嘅。 你喺 skill 嘅 YAML frontmatter 入面定義 allowed-tools 嚟限制邊啲 bash commands、file operations 或者 APIs 可以被呢個 skill 調用。呢個細節我用咗好耐先完全理解。呢個唔淨止係關於 agent 知道啲咩——仲係關於 agent 被 允許觸及 啲咩。
有一樣嘢我到依家都未完全確定：呢啲 constraints 喺 session 變得好長、context window 開始壓縮之後，到底頂唔頂得住。Claude Code 文檔提到 auto-compaction 會帶住已調用嘅 skills 繼續前進，但如果你喺一個 session 入面載入咗好多 skills，舊啲嘅可能會被丟棄。我注意到嘅行為漂移可能同呢個有關。我可能睇多咗嘢，但佢唔似係隨機嘅。
Cursor — rules、.cursorrules 同 MDC 格式
Cursor 用嘅係分層嘅方法。你有三個層級：User Rules（全局，適用於所有嘢）、Project Rules（受版本控制，放喺 .cursor/rules/ 入面）、同舊版嘅 .cursorrules 檔案（放喺 project root）。.cursorrules 格式喺 2026 年初仲係可以用嘅，但 Cursor 嘅官方文檔講得好清楚佢已經被 deprecated——建議嘅做法係遷移到 .mdc project rules 系統，嚟獲得更好嘅 scoping 同控制。
MDC 格式加咗一個 .cursorrules 冇嘅 metadata 層：你可以設定一條 rule 係 alwaysApply、綁定到特定嘅 file globs、或者淨係喺 agent 判斷佢相關嘅時候先載入。最後嗰個選項——agent-requested rules——比聽落去更加有趣。呢個意味住 rule 系統可以係 context-sensitive 嘅：frontend rules 唔會喺 backend 檔案入面載入，payment service 嘅 constraints 唔會滲入唔相關嘅 modules。
我花咗時間研究之後發現嘅係：最有效嘅 rules 係具體同命令式嘅，唔係含糊同理想化嘅。「Use TypeScript for all new files」頂得住。「Write clean, maintainable code」咩都做唔到。你描述得越精確你想要咩——或者你明確唔想要咩——agent 就越一致咁跟。
Cursor 依家仲有 AGENTS.md，係一個純 markdown 嘅替代方案，畀唔需要完整 metadata overhead 嘅項目用。更簡單，靈活性稍低啲。
Codex CLI — AGENTS.md 同分層嘅指令發現
OpenAI 嘅 Codex CLI 有一個清晰嘅指令層級架構，我覺得值得了解。當一個 session 開始嘅時候，Codex 會建立佢嘅文檔所講嘅「instruction chain」——佢會讀取你嘅全局 ~/.codex/AGENTS.md，然後由 project root 一直行到你當前嘅目錄，沿途揀起佢搵到嘅所有 AGENTS.md 檔案。離你當前目錄越近嘅檔案會覆蓋之前嘅指引。
根據 Codex custom instructions 文檔，你仲可以喺任何層級放置 AGENTS.override.md 檔案嚟明確表達覆蓋意圖。對於擁有 monorepos 或者有好唔同需求嘅 services 嘅團隊——譬如 payments 團隊對比 analytics 團隊——呢個意味住你可以有共享嘅 baseline rules 同 service-specific constraints，永遠唔會意外咁互相滲透。
Codex 最近亦都採用咗同一個 SKILL.md 模式。Codex skills 文檔描述咗同樣嘅 progressive disclosure 方法：skill metadata 先載入，完整指令淨係喺 skill 被調用嘅時候先載入。呢個生態系統正在向一種共享嘅設計語言收斂，即使係跨唔同嘅 providers。
嚴格嘅 approvals 同窄嘅 sandbox permissions 係正確嘅預設——淨係喺你理解 blast radius 嘅特定 workflows 入面先放寬佢哋。
呢個 Pattern：GitFlow + TDD + Code Review 嘅自動化版本
brainstorming → writing-plans → executing-plans
呢個係我反覆用嘅 workflow pattern。結構係：將一個 agent 任務拆成唔同嘅階段，每個階段由唔同嘅 skill 管理。
一個 brainstorming skill 打開問題空間，產生選項，揭示 edge cases。冇任何 code 會被寫出嚟。然後一個 planning skill 接手——結構化嘅計劃、要改嘅檔案、要先寫嘅 tests。淨係喺計劃存在之後，一個 executing skill 先開始做實際嘅改動。
呢個模式反映咗 GitFlow + TDD + code review——只不過 agent 扮演晒三個角色，每個角色有唔同嘅行為配置。Brainstorming skill 可以推測。Executing skill 被約束住要跟已批准嘅計劃。
點解呢個可以減少失敗：每個階段都有更窄嘅成功標準。一個喺「brainstorming」嘅 agent 唔會意外寫出 production code。一個喺「executing」嘅 agent 唔會喺實現過程中途重新設計架構。
我開始用呢個 pattern 係因為睇住一個 agent 喺一次 refactor 入面兜咗四十分鐘嘅圈，因為佢不斷重新評估自己嘅決定。將階段分開冇令到個 agent 更聰明。但係佢令到個過程更加穩定。
Constraints 同 Governance 嘅分別
本地行為規則 vs 網絡層面嘅能力生命週期
呢度有個 gap 我一直留意到，而我老實講仲未確定點樣理解佢。
我上面描述嘅所有 constraint systems 都係 session-scoped 嘅。佢哋係本地嘅——佢哋存在於檔案入面，喺 session 開始時被載入，喺 session 結束時重置。佢哋非常擅長為一個已知嘅 codebase、一個已知嘅團隊、一套已知嘅標準定義行為。
但佢哋唔解決另一類問題：一個 agent 嘅行為喺佢整個生命週期入面會點？ 你點樣知道三個月前有效嘅 constraint 喺底層 model 改進之後仲適唔適用？你點樣將經過驗證嘅行為模式傳播到唔共享同一個 codebase 嘅 agents 之間？
基於檔案嘅 constraints 冇呢啲問題嘅答案。佢哋本來就唔係為咗呢個而設計嘅。呢個就係 governance——唔淨止係 rules——開始變得重要嘅地方。本地 constraints 係第一步。但 governance 嘅意思係追蹤 constraints 係咪仲有效，同埋有一個機制嚟跨 agent 網絡傳播更新，而唔係一次一個 project 咁做。
我仲喺摸索呢個喺實踐中係咩樣嘅。
當 constraints 唔夠用嘅時候會點
一個 constraint 話畀 agent 聽點樣行為。佢唔會話畀你聽 agent 事後有冇正確咁行為。呢兩個係唔同嘅問題。
我最常見到嘅失敗模式唔係一個忽略規則嘅 agent。而係一個完美咁跟住規則嘅 agent——喺一個嗰啲規則並冇覆蓋到嘅情境入面。啲規則係啱嘅；啲規則只係冇覆蓋到新嘅情況。
限制同取捨
Constraint drift——過時嘅規則
規則會過時嘅。一條六個月前完全正確嘅規則可能而家已經有少少偏差——model 嘅預設值變咗，codebase 改咗，或者條規則引用嘅標準喺上游被更新咗。
冇任何 rule file 會自己維護自己嘅。 Claude Code、Cursor 同 Codex 嘅 constraint systems 共享同一個盲點：冇機制去偵測一條 rule 已經過時。佢只係靜靜咁唔再如預期咁運作。Cursor 嘅文檔同好多實踐者都建議定期做 rule audits——唔係因為啲 rules 脆弱，而係因為佢哋周圍嘅環境不斷喺變。
冇持久性——constraints 每個 session 都會重置
呢個係我反覆諗嘅問題。
每個 session 都係由零開始。CLAUDE.md 會被重新讀取。AGENTS.md 會被重新讀取。Skills 會被重新發現。Agent 冇任何記憶去記住上次邊啲有效、微妙嘅失敗模式喺邊度、你經過三個禮拜 debugging 學到咗咩。
你可以將嗰啲學到嘅嘢編碼入你嘅 rule files 入面——而你亦都應該咁做。但編碼係手動嘅。Constraint system 唔會自己學嘢。 係你學，然後你寫低你學到嘅嘢，然後 constraint system 反映佢。
呢個係一個真實嘅限制。我唔確定喺目前嘅架構下係咪可以修正。但值得講清楚。
FAQ
-
AI agent workflows 入面嘅 superpowers 係咩？
唔係 features——係 constraint systems。即係定義一致嘅行為規則、permission scopes 同針對特定階段嘅指令，等 agent 喺每個 session 入面都跟住嘅能力。
-
我點樣喺 Claude Code 入面設定行為約束？
透過 SKILL.md 檔案（YAML frontmatter + markdown 指令，儲存喺
.claude/skills/入面）同一個CLAUDE.md檔案嚟設定常設指令。Tool 層面嘅 permissions 放喺allowed-tools字段入面。Anthropic 官方 skills 嘅 GitHub repository 有真實嘅範例。 -
.cursorrules同CLAUDE.md有咩分別？佢哋係畀唔同工具用嘅。
.cursorrules（已經被 deprecated，改用.cursor/rules/*.mdc）係 Cursor 嘅格式；CLAUDE.md係 Claude Code 嘅持久指令檔案。兩者都喺 session 入面帶住常設規則，但 scoping 機制唔同。 -
Agent constraints 可唔可以跨 session 持久化？
原生嚟講唔得。Rule files 喺 session 開始時會被重新讀取。Agent 冇任何先前 session 嘅記憶。你手動將學到嘅行為編碼入嗰啲檔案入面——呢個係正確嘅做法——但 constraint system 本身唔會累積經驗。
-
Brainstorming-writing-executing skill pattern 係咩？
一個由唔同 skills 管理唔同階段嘅 workflow：brainstorming 打開問題空間而唔寫 code；planning 產出一個結構化嘅提案；executing 根據已批准嘅計劃嚟實現。每個階段都有更窄嘅成功標準，從而減少循環同實現過程中途嘅架構改動。
我大概會繼續觀察呢個領域點樣演變。Constraint systems 越嚟越精密，而跨工具向 SKILL.md 作為共享格式嘅收斂係我想更密切跟蹤嘅嘢。但 session-scope 嘅限制感覺似係一個天花板，而家冇任何工具搞得掂點樣突破佢。有啲嘢正在發生——我只係未完全睇到。
