GitHub Actions 導入 Docker Sandboxes microVM，讓 AI Coding Agent 能安全跑 Testcontainers 自己開 PR
GitHub gh-aw PR #45006 · 2026-08-21
原本的問題
GitHub Agentic Workflows（gh-aw）讓 AI agent 在 CI 裡執行任意 shell 指令、啟動 Docker 容器、安裝套件，藉此完成除錯、修 bug、開 PR 等工作。但這類 agent 需要的權限範圍，與 CI runner 本身的信任邊界互相衝突：直接把 Docker socket 或 runner 權限交給 agent，一旦 agent 誤判或遭提示注入攻擊，破壞範圍就是整台 runner。
採用的方法
gh-aw 在 v0.82.9（PR #45006，2026 年 7 月 12 日合併）新增 docker-sbx runtime，把 agent 丟進一個獨立的 microVM，而不是共用 runner 的容器層。每個 sandbox 都有自己的核心、檔案系統與私有 Docker daemon，彼此不共用 image cache 與 layer。設定方式只需在 workflow frontmatter 宣告：
sandbox:
agent:
id: awf
runtime: docker-sbx
sudo: true
network:
allowed:
- defaults
- github
- containers
- java寫好的 Markdown workflow 透過 gh aw compile 編譯成標準 GitHub Actions .lock.yml，不需要額外自訂 action。VM 與 host 之間只有明確掛載的 repository 目錄互通，其餘檔案系統彼此隔離；對外流量統一經 host 端 proxy 做網路政策與憑證注入，MCP 呼叫也集中經由一個 gateway 端點轉發，而非讓 agent 直接持有各服務憑證。這個 runtime 的實作（docker_sbx_install.go、sandbox_validation.go 等 13 個檔案）包含開機前的 KVM 可用性檢查、Docker 憑證驗證、daemon 初始化與 smoke test，並會擋掉巢狀虛擬化這類不相容設定。
實際效果
Docker 官方部落格用一個示範驗證了整條鏈路：workflow 在 GitHub-hosted Ubuntu runner 上，於 sandbox 內啟動 Java 21 + Maven 容器，跑 Testcontainers 搭配 PostgreSQL 的整合測試，找出一個刻意埋入的 email 大小寫比對 bug，agent 自行修正程式碼後開出 draft pull request，全程耗時 11 分 16 秒。
原始來源：gh-aw PR #45006、Docker Sandboxes architecture、Docker Blog
用 OpenTelemetry 資料庫語意慣例，把慢查詢攤平成可排序的可靠性指標
OpenTelemetry Database Semantic Conventions · 2026-08-21
原本的問題
資料庫慢查詢是連鎖故障最常見的起點，但多數團隊手上只有原始 trace span，回答不出「哪一條查詢現在最該修」。單看單次查詢耗時沒有意義——一條平均 200ms、但每秒被呼叫上千次的查詢，對整體延遲的影響遠大於一條耗時 2 秒、卻一天只跑一次的報表查詢。CNCF 部落格用一個開源實驗專案示範了如何把這些 span 轉成可直接排序、告警的指標。
採用的方法
整條管線起點是用 otelsql 這個 Go 函式庫包裝 database/sql driver，依照 資料庫語意慣例（Database Semantic Conventions）自動送出帶有 db.system、db.query.text、db.namespace 等屬性的 client span。這份規範目前狀態是 Mixed（部分穩定、部分實驗性），舊版（v1.24.0 以前）實作預設不應自行切換慣例版本，新舊行為可用環境變數 OTEL_SEMCONV_STABILITY_OPT_IN=database 或 database/dup 控制切換或雙送。
第二層是在 OpenTelemetry Collector 接上 spanmetrics connector，直接從 DB span 算出以下維度的 histogram 指標，不需要額外埋點：
connectors:
spanmetrics:
dimensions:
- name: db.system
- name: db.query.text
- name: db.statement第三層是拿這些指標接上 Prometheus 的 PromQL anomaly-detection recording rule，用自適應基準線（adaptive baseline）區分「本來就慢」與「這週忽然變慢」兩種查詢，而非設一個固定的絕對門檻。
實際效果
範例程式碼開源在 causely-oss/slow-query-lab，用 Go 服務、PostgreSQL 與 docker-otel-lgtm（打包 Loki、Tempo、Mimir、Grafana）組成一鍵可跑的環境，docker-compose up -d 後會自動起流量產生器灌資料，並附上四張 Grafana dashboard：
- v1：單純依查詢耗時排序的基礎指標
- v2：耗時 × 呼叫頻率的流量加權影響分析
- v3：帶自適應邊界的異常偵測
- 整合版：三種視角疊在同一張儀表板
原始來源：OpenTelemetry Database Semantic Conventions、slow-query-lab、CNCF Blog