當 Coding Agent 開始承接時間更長、修改範圍更大的開發任務，許多團隊會把 Hexagonal Architecture、模組邊界、跨層依賴與前端 Feature Boundary 等規範，寫進 AGENTS.md、CLAUDE.md 或其他 Prompt 文件，希望 Agent 能持續遵守。

但文字規範只能提供方向，無法形成真正的強制邊界。

隨著任務時間拉長、Context 不斷增加，Agent 很容易在修正測試或補齊功能的過程中，遺忘一開始提供的架構限制，轉而採用「最快讓程式跑起來」的實作方式，例如讓 Domain Layer 依賴 Infrastructure、讓 Frontend Component 直接引用 API Client，或繞過團隊既有的抽象層。

這場分享將以實際專案經驗為基礎，說明如何將架構意圖從文字規範轉換成可被機器執行的 Executable Guardrails：

• 後端透過 Go Test 與 Import Graph 檢查跨層依賴
• 前端透過 dependency-cruiser 驗證 Component、Feature 與 API Client 的依賴邊界
• 將架構檢查同時接入本地 Coding Agent Workflow 與 CI
• 把失敗訊息設計成 Agent 下一輪能直接採取行動的 Feedback
• 讓 Agent 在提交變更前，自行發現偏差、修正實作並逐步收斂

分享的核心不是期待 AI 模型永遠不犯錯，而是重新設計 Agent 所處的工程環境：

Prompt 負責表達目標與脈絡；Executable Guardrails 負責驗證不可妥協的工程邊界。

當驗證結果能回到 Agent 的執行迴圈中，架構檢查就不再只是 CI 最後的一道阻擋，而能成為 Agent 自我修正的一部分。

本場也會討論 Executable Guardrails 的限制，包括哪些架構意圖適合形式化、如何處理例外與暫時性豁免，以及如何避免規則過度限制 Agent 的解題空間。

聽眾收穫：

1. 理解為什麼文字規範適合引導 Agent，卻不適合作為不可違反的架構邊界
2. 學會判斷哪些工程規範應保留在文件中，哪些應轉換成可執行政策
3. 了解如何在 Go 後端與前端專案中，實作跨模組與跨層依賴檢查
4. 了解如何設計 Agent 可理解、可採取行動的驗證錯誤訊息
5. 將架構檢查接入 Coding Agent Loop 與 CI，形成偵測、回饋與自動修正的閉環
6. 建立一個更務實的 AI 可靠性觀點：不要求模型不犯錯，而是讓系統能持續發現並限制錯誤