「套上韁繩不是為了讓馬跑得慢，而是為了讓牠跑向你真正要去的地方。」
——《阿帕契開源審計錄》¹ 卷一·韁繩篇

幕間
天還沒亮，真預言家一人在廊下踱步。
起跳，就是把自己架在火上；不起跳，資訊爛在肚子裡。
他握緊底牌走向長桌，聲音沒有一絲遲疑：「查殺三號，我是預言家。」

長桌正中央的警徽散發著冰冷的光芒，警長的木質法槌在石桌上重重敲下一聲脆響。在九人標準局的議事廳裡，秩序不是憑空產生的，而是被嚴苛的規則硬生生框定出來的。全場嚴格執行「絕發規則」——沒有人可以打斷別人的發言，每位玩家只能在法槌指定的發言順序中闡述觀點。警長手握白天平票時生殺予奪的 1.5 票裁決權，一旦有人試圖用毫無根據的長篇大論混淆視聽、企圖擾亂好人陣營的邏輯鏈條，法槌落下之時，就是胡言亂語者被孤立與審判的起點。

在上一輪輪迴中，我這個只會調用 AI 代筆的狼人，最害怕的就是警長手中那把法槌。當我在前置位慌亂編造藉口時，只要邏輯稍有漏洞，警長便會以冷酷的目光鎖定我，在後置位將我的偽裝一層層剝光。

在 2026 年的現代軟體工程中，我們將 AI 代理人（AI Agent）引入開發工作流時，面臨的正是完全相同的混亂。當我們給予代理人過高的自主權，任由它在專案目錄中自由穿梭時，它往往就像一個失控的發言者：看似產出了成百上千行的精美程式碼，實則隨意修改全域變數、擅自安裝未經驗證的第三方套件，甚至把核心模組重寫得面目全非。這正是我們 2N1P 團隊在重構開發環境時深刻體認到的教訓：如果沒有一把「警長的法槌」為代理人劃定物理邊界，AI-First 的開發只會迅速墮落為一場無法維護的災難。

模式切換：計畫模式與構建模式的界線

許多開發者在使用 AI 工具時最常犯的錯誤，就是直接讓代理人進入「構建模式」（Build Mode）。當你輸入一段模糊的需求描述，代理人立刻開始疯狂敲擊鍵盤，建立新檔案、修改現有類別庫，最後丟出一堆難以通過編譯的半成品。

真正的軟體工程必須建立在嚴謹的「計畫模式」（Plan Mode）與「構建模式」的雙軌架構之上：

1. 計畫模式（Plan Mode）：代理人在這個階段被剝奪任何寫入檔案的權限，只能讀取目錄結構、解析抽象語法樹（AST）與閱讀介面契約。代理人必須輸出一份結構化的技術規劃，清楚列出受影響的模組、預計變更的函式簽名，以及即將執行的驗證指令。這就像警長要求發言者先交代邏輯脈絡，在得到人類工程師核准前，嚴禁擅自更動任何一行代碼。
2. 構建模式（Build Mode）：只有在計畫經過人類驗證、確認架構無誤後，代理人才被允許切換至構建模式。在此階段，代理人的每一次變更都必須嚴格錨定在先前的計畫清單上，遵循最小修改原則，完成單一原子任務後立即執行局部測試。

韁繩工程：AGENTS.md 的黃金規範

為了讓這把法槌在專案根目錄中恆久生效，我們需要落實「韁繩工程」（Harness Engineering）。韁繩工程的核心思想不是去祈求大語言模型「變得更聰明」，而是透過專案內的架構約束檔案，為代理人打造一套無法逾越的護欄（Guardrails）。

在現代開源架構中，這個護欄的核心就是專案根目錄下的 AGENTS.md——一份被 60,000 多個開源專案採用、由 OpenAI、Google、Anthropic 等超過 20 家 AI 工具廠商共同支持的開放格式。官方規範本身並未硬性規定行數上限，但我們 2N1P 團隊摸索出的實務心法是：盡量把它壓縮在幾百行的篇幅內，只留下可執行的具體指令（安裝指令、測試指令、目錄權限、禁止事項），而非長篇大論的哲學說教。當提示詞與規則過於冗長時，模型的注意力機制會發生分散，重要約束將在長文本的深淵中被稀釋忽略。

一份標準且高效的 AGENTS.md 規範範例如下：

# Agent Harness Specification

## 1. Role and Execution Boundaries
- You are an automated implementation agent operating within a sandboxed environment.
- Mode Policy: Always start in PLAN MODE. Propose changes and require human confirmation before writing files.
- Sandbox Constraint: Never execute commands outside the container boundary. No root privileges granted.

## 2. Technology Stack & Constraints
- Runtime: Go 1.22+ or Java 25 (LTS).
- Framework Restrictions: Do not introduce third-party HTTP or logging libraries without explicit authorization.
- Style Guide: Follow standard idioms (`gofmt`, Google Java Style). Zero warnings on default linters.

## 3. Directory Scope
- Editable:
  - `src/`
  - `tests/`
- Read-Only:
  - `config/production/`
  - `deploy/k8s/`
- Forbidden:
  - `.git/`
  - `scripts/secret_bootstrap.sh`

## 4. Pre-Commit Verification Checklist
Before requesting human review or submitting changes, you must execute and pass:
1. Lint Check: `golangci-lint run ./...`
2. Unit Tests: `go test -v -race -cover ./...`
3. Static Analysis: `govulncheck ./...`

## 5. Prohibited Patterns
- Never disable compiler warnings or linters via inline ignore comments.
- Never write tests that mock internal private state directly.
- Never commit hardcoded credentials, mock secrets, or temporary debug logs.

這份規範用清晰、機械式的條款取代了含糊不清的人類建議。當代理人讀取這份韁繩規範時，它清楚知道自己的可操作路徑，任何越界企圖都會被沙盒與預先定義的指令攔截。

上下文衛生：拒絕資訊雜訊的 /compact 紀律

在長週期的開發過程中，代理人的上下文視窗（Context Window）會迅速累積大量垃圾資訊：過往編譯失敗的長篇報錯堆疊、反覆嘗試的無效輸出、以及人類與代理人之間的隨性交談。這些陳舊的雜訊會持續佔用寶貴的注意力權重，導致代理人遺忘最初的架構原則，甚至開始產生虛妄的幻覺。

這正是為什麼我們必須保持嚴苛的「上下文衛生」（Context Hygiene）。當一個階段性子任務完成並通過單元測試後，工程師必須主動執行 /compact 指令。這個操作會主動修剪歷史對話樹，將過往除錯的細枝末節徹底丟棄，僅保留三項核心資產：

• 目前的 Git 變更狀態（git status 與 git diff --stat）。
• 尚未完成的驗收標準清單。
• 專案根目錄的架構規範約束（AGENTS.md）。

透過週期性的壓縮，代理人的推理能力能始終維持在最佳狀態，不被歷史包袱拖垮。

成本校準：讓法槌也懂得節省彈藥

韁繩工程不只是禁止代理人做什麼，也包括校準它「該花多大力氣」去做。2026 年 Anthropic 平台團隊公開的一份成本優化報告指出：把推理的 effort（努力）參數配合任務複雜度動態調整，而不是每次都預設拉到最高檔，在 SWE-bench Verified 這類真實工程任務上可以省下約 55% 的成本——一把子彈一次任務，用得剛好，而不是每次都把彈匣打光。

同一份報告還指出另一件更貼近韁繩本質的事：定期審查 AGENTS.md 與系統提示詞本身，把過時的「驗證儀式」「強調字眼」「已經失效的強制流程」剔除掉，在一次模型升級遷移的實測中同時帶來 14.6% 的成本下降與 5.3% 的準確率提升。換句話說，韁繩本身也會腐朽——警長的法槌用久了同樣需要打磨，而不是無限疊加新規則。這與我們前面談的 /compact 上下文衛生是同一種紀律的兩面：一個清掃的是對話歷史，一個清掃的是規範文件本身；兩者共享的原則，是重複讀取的內容應該被快取而非每次重新計算——這正是 prompt caching 能大幅省下 58%～73% 成本的原因所在。

{
  "model": "claude-sonnet-x/gpt-x-x-terra",
  "effort": "medium",
  "note": "match effort to task complexity instead of always maxing it out"
}

韁繩架構全景

下方的架構圖清晰展示了代理人從接收任務、受到韁繩約束、維持上下文衛生、直至在沙盒中驗證代碼的完整防線：

警長敲槌：找回工程師的統治權

在城堡九人局裡，如果好人陣營任由每個人自由插嘴、各抒己見，村莊不出兩天就會因為資訊超載與狼人帶風向而慘遭屠邊。警長的存在，就是為了讓發言回歸事實、讓辯論遵守秩序。

同樣地，在 AI-First 的浪潮中，工程師的角色從來不是退居二線當一個盲目接受代碼的旁觀者，而是要成為高舉法槌的警長。大語言模型擁有驚人的運算與生成速度，但它缺乏對系統穩定性的敬畏。只有當我們運用 AGENTS.md 套上韁繩、以計畫模式隔離衝動、以 /compact 維持上下文純淨，我們才能真正馴服這匹烈馬，讓 AI 成為打造堅固系統的得力臂膀。

有件事我到現在還沒想通：那把法槌、那套絕發與一票半的規矩，比敲槌的法官還要老——他比較像是被派來執行它們的人，而不是制定它們的人。

讀完這篇文章後，你應該能夠在自己的專案根目錄建立一份符合規範的 AGENTS.md，配置好嚴格的沙盒防線與預先驗證指令，並在每一次任務迭代中貫徹計畫與構建的明確切換。

參考資料與延伸閱讀

• AGENTS.md 官方格式規範（開放標準）
• Anthropic 工程部落格 - Building Effective Agents
• Claude Code 官方文件 - Slash Commands（含 /compact）
• Claude Code 官方文件 - Subagents
• Anthropic 部落格 - Reducing Cost and Improving Performance with the Claude Platform
• 源來適你 (OpenSource4You) Facebook 粉絲專頁
• 關鍵檢索詞（建議使用 Felo.ai / Perplexity 查詢）："AI harness engineering" "AGENTS.md best practices" "context window compaction" "AI agent sandbox" "Claude effort parameter cost optimization"

¹ 註：本書名為情境設定之虛構文獻，非真實歷史或開源紀錄。