Docker 主張 AI agent 治理要靠「執行期強制」而非提示詞建議
Docker Blog · 2026-07-22
Docker 在 2026-07-22 的部落格文章中提出一個治理框架：prompt（提示詞）只能影響agent 行為，無法真正限制它；要讓組織放心把工作委派給 agent，限制手段必須落在執行期，而不是寫在系統提示詞裡「建議」它別做什麼。
原本的問題
文章把 agent 治理拆成三個邊界：執行邊界（能否讀寫檔案、跑指令、裝依賴、開網路連線）、工具邊界（能接觸哪些外部系統，如 GitHub、Jira、雲端服務、內部 API、資料庫、MCP 連接的工具）、憑證邊界（憑證怎麼管理、權限與身分控管、稽核與可觀測性）。目前多數團隊仍只靠 prompt 層級的規則來約束這三個邊界，等於沒有邊界。
採用的方法
- 隔離：透過容器與沙箱環境劃出 agent 可觸及的明確範圍，對應到新產品 Docker Sandboxes
- 政策控制：在執行期強制套用組織政策，對應 Docker AI Governance
- 可視性：agent 行為的可觀測與可稽核，透過 MCP（Model Context Protocol）連接的 Docker MCP Catalog and Toolkit 統一管理
實際效果
文中強調的核心原則是：「當團隊理解限制在哪裡、又知道限制如何被強制執行時，才更願意把工作委派給 agent。」這篇文章沒有給出程式碼範例或版本號，屬於架構層級的治理論述，但明確點出目前多數 agent 部署仍停留在「寫在 prompt 裡」的脆弱狀態。
Terraform Stacks 轉為正式量產：用宣告式編排取代腳本拼接多環境部署
HashiCorp Blog · 2026-07-23
HashiCorp 在 2026-07-23 發文詳解 Terraform Stacks——一層架在既有 Terraform 模組之上的編排層，把橫跨多雲端帳號、多環境、多區域的一組 Terraform 設定當成單一單位管理，目前已對 HCP Terraform 與 Terraform Enterprise 2.0 以上版本開放正式量產（GA）。
原本的問題
在 Stacks 出現以前，團隊要管理跨帳號、跨區域的相依基礎設施，只能手動追蹤設定之間的相依關係，也沒有內建方式讓同一份設定用不同輸入值重複佈署多次，多數團隊只能仰賴外部腳本拼接，容易出錯且風險高。
採用的方法
Stacks 引入四個核心概念：.tfcomponent.hcl 定義的 Components（哪些模組與基礎設施屬於這個 Stack）、.tfdeploy.hcl 定義的 Deployments（要在哪裡、部署幾次，同一設定可用不同輸入值重複套用到不同區域/帳號/環境）、Deployment Groups（自動核准規則與編排順序）、以及 Deferred Changes（遇到太多未知值時允許部分規劃，適用如 Kubernetes 部署這類複雜情境）。
實際效果
Stacks 現以「受管理資源數（RUM）」計價方式對外提供，官方定位為「production-ready」。對照 Docker 同週發表的 agent 治理框架，兩者都反映同一個趨勢：基礎設施與 agent 的操作都在往「宣告式編排 + 執行期強制」的方向收斂，減少對人工腳本與臨場判斷的依賴。
Consul 支援單一服務多埠註冊，DNS 與 Service Mesh 都能按埠名路由
HashiCorp Blog · 2026-07-22
Consul 新增多埠服務（multi-port services）能力，讓一個服務同時對外開放多個具名埠（例如 API 流量、metrics、管理端點），不必再為每個埠各自建立一筆服務登錄。
原本的問題
過去要在 Consul 表達「同一支應用開了 API port、metrics port、admin port」，得建立像 order-http、order-admin、order-metrics 這樣的多筆獨立服務項目。這造成健康檢查與可觀測性資料分散在多個服務名稱下、存取政策要同時考慮好幾個名稱而非單一身分，也讓 Consul 的服務登錄方式和 Kubernetes 原生的 Service 定義（一個 Service 本就可以有多個 port）對不太起來。
採用的方法
新機制讓單一服務定義內帶一個 ports 清單，每個項目有名稱、埠號與是否為預設埠。DNS 查詢可以直接指名埠（如 _order-service._tcp.service.metrics.port.consul），Service Mesh 流量則靠 TLS 交握中的 ALPN 欄位，讓單一 sidecar proxy 就能正確路由到對應埠。
實際效果
服務發現層面的多埠支援自 Consul 1.22.0 起可用；Service Mesh 路由（beta）則要 Consul Enterprise 2.0.0 以上。這讓 Consul 的服務模型第一次能與 Kubernetes Service 一對一對應，不必再靠命名慣例模擬多埠關係。
原始來源：HashiCorp: One service, many doors: Multi-port services in Consul