AWS 開源 ADOP：多代理生成資料管線，但生產環境只執行確定性產物

AWS 發布 Agentic Data Operations Platform（ADOP）參考實作，嘗試把新資料來源由 Bronze、Silver 到 Gold 層的建置工作交給專門代理。使用者描述 S3、Kafka、Kinesis 或 JDBC 來源、更新頻率、品質門檻與治理要求後，協調代理會拆出 metadata、ontology、data quality、transformation、orchestration 及 DevOps 等任務，生成 PySpark、SQL、Airflow DAG、Step Functions、Terraform、CloudFormation、測試，以及 OWL／R2RML 語意產物。程式庫以 MIT-0 授權公開。

其重要設計是「代理留在開發環境，產物進入生產」。模型負責推理和寫檔，但 CI/CD 推送的是可版本控制、可測試的確定性程式碼與 IAM、Cedar 政策；正式資料管線毋須每次執行時再呼叫模型。這比讓代理直接操作生產資料容易稽核，也使推論成本與模型變更不會直接改變既有工作。動態工作流可平行啟動約 15 個代理，官方估計 10 至 20 分鐘完成規格建置；順序模式約需 30 分鐘，而平行模式 token 成本可能增至三至五倍。

安全層面，子代理預設只生成檔案，不取得 MCP、CLI 或 AWS 工具權限；主流程再按伺服器健康狀態、意圖路由及強制不變條件決定工具。專案亦建議只向模型提供 schema、欄位統計及小量隔離樣本，憑證則在部署時由 Secrets Manager 或外部 vault 解析。每次工具選擇、結果與成本可輸出至 CloudWatch 或 OpenTelemetry。

然而，這仍是樣例架構而非受管服務或經第三方驗證的產品。所謂數周縮至數小時主要是 AWS 與專案作者的方向性估算；README 中部分「內建 GDPR、HIPAA、PCI DSS 合規」措辭也不能代替法律或安全審查。生成的遮罩、保留期限和存取政策仍可能看似合理卻語義錯誤。工程團隊應先用非關鍵資料測量首輪產物接受率、回歸測試覆蓋及人工修正量，再判斷代理化是否真正降低總成本。