monday.com 說明其如何在 Amazon Bedrock 上運行生產環境 AI 代理，顯示企業程式設計代理正進入更偏向營運的階段

monday.com 詳細說明了其如何在 Amazon Bedrock 上為軟體交付運行生產環境 AI 代理，為市場提供了一個具體案例，展示「agentic AI」在大型企業 SaaS 環境內，而不是在示範環境中，究竟是什麼樣子。

這項披露是透過 AWS Machine Learning Blog 的文章以及 AWS 的新聞項目而來，因此資訊在很大程度上由供應商掌控。即便如此，這仍然值得注意，因為 monday.com 不僅在描述模型使用情況，還包括讓內部 AI 代理在生產環境中與 Slack、GitHub 和 monday workflows 互動所需的系統、佇列、儲存層、審核流程與營運保護措施。對 AI 建構者與企業買家而言，重點與其說是一個基準測試，不如說是可靠性、重放、可稽核性與人類監督背後的架構選擇。

根據 AWS 對 monday.com 設定的說明，該公司將其內部「AI Teammates」分為三個層級。在第一層，人類使用 AI 程式設計工具作為助理。在第二層，團隊為重複工作建立可重用的技能與子代理。在第三層，代理承擔端到端交付任務，而人類則負責協調與審核。AWS 表示，monday.com 的內部系統 Sphera 讓代理在各系統之間擁有穩定身分，使其能像人類隊友一樣被指派工作、接受審核或停用。

從程式設計助理到受管理的代理工作流程

monday.com 敘述中最有趣的部分在於，它將 AI 採用描述為一個營運上的進程，而不是單一產品上線。AWS 表示，monday.com 使用 Cursor 處理快速的結對程式設計任務，使用 Claude Code 處理較重的工程工作，並將這一部分歸類為其 L1 助理層。接著，它再推進到 L2 的可重用內部代理，以及 L3 的多代理交付。

這一點很重要，因為許多企業 AI 部署會停留在「copilot」實驗與生產自動化之間。monday.com 的說法顯示，這個落差並不是單靠更好的模型就能解決，而是要透過一層能理解工作分派、會話記憶、工具使用、程式碼審查、重放與失敗處理的協調層來包裝模型存取。

在 monday.com 的系統中，代理可透過三個管道觸發：Slack 提及、monday 項目指派或 GitHub pull request 審查請求。AWS 表示，這三條路徑都會進入同一個代理會話，共享相同的記憶體與磁碟工作區。這種設計似乎是為了避免不同協作工具之間的脈絡碎片化。

文章中強調的核心代理 Atlas，被描述為一個軟體工程師代理，可以接手 ticket、撰寫 pull request 並交付功能。AWS 將 Atlas 呈現為 Sphera 內更廣泛團隊結構中的一員，在那裡代理有明確的角色、範圍、管理者與績效分數。這種說法聽起來可能帶有形式意味，但 monday.com 指出，這其實是代理如何被呼叫與治理的營運架構的一部分。

為什麼這裡的 AWS stack 很重要

monday.com 透露的架構之所以引人注目，部分原因在於它不是單一的巨型代理平台。相反地，AWS 表示 monday.com 是在標準雲端服務之上建立了一套分層系統，由 Amazon Bedrock 處理模型存取，而更廣泛的事件與儲存 stack 則承擔了大多數營運工作。

根據文章，外部觸發首先會進入 Amazon SNS，接著再分發到 Amazon SQS 佇列。運行在 Amazon EKS 上的消費者會拉取訊息、判定應由哪個代理負責，並將工作交給一個代理 runner pod。monday.com 表示，這種 pub/sub 加佇列的設定讓它獲得重試、當 Amazon Bedrock 限流時的 back-pressure、用於測試修補後建置的持久重放，以及並行 fan-out。

這對於規劃生產環境 AI 代理的團隊來說是個重要訊號。困難之處往往不在於產生程式碼或文字，而是在於管理突發性工作負載、在失敗後重新執行任務、追蹤發生了什麼，並在相依服務或模型端點不可用時安全復原。monday.com 的架構顯示出對平實但經過驗證的基礎架構模式的偏好。

該公司還表示，它包裝了 Claude Agent SDK，而不是直接依賴它。AWS 將 monday.com 的三個理由歸納為：透過 Amazon Bedrock 在呼叫端保持供應商中立、利用預熱快取降低冷啟動延遲，以及保留其所稱的「harness」層控制權，也就是評估、外掛組合、通訊與審核邏輯所在之處。這對建構者來說是一個有用訊號。它暗示模型執行環境可能是可替換的，而控制平面與工作流程邏輯則成為持久的內部優勢。

儲存、記憶體，以及沒那麼光鮮的工程選擇

這項披露的第二個啟示是，代理系統需要多種狀態，而這些狀態不應該全部放在同一個資料庫裡。

AWS 表示，monday.com 會將目前任務、心跳、鎖與訊息日誌等即時狀態存放在 Amazon ElastiCache，以便低延遲存取。會話記憶體與工作檔案儲存在 Amazon EFS，而像逐字稿、產物、快照與評估等持久性紀錄則送往 Amazon S3。Amazon RDS 也列在使用的服務之中，不過文章摘錄並未說明其具體角色。AWS Secrets Manager 則用於每個會話的秘密資訊處理。

這種拆分很重要，因為許多代理原型會把記憶體視為單一抽象概念。實際上，程式設計代理需要更接近傳統分散式系統的架構：快速的暫態狀態、供需要 POSIX 語意的工具使用的共享檔案系統，以及用於稽核與證據保存的長期儲存。

AWS 表示，monday.com 在活動會話中選擇 Amazon EFS 而不是物件儲存，是因為 Claude Agent SDK 與常見開發者工具如 git、npm 期待的是真實檔案系統。這也讓同一個路徑可以掛載到另一個 Amazon EKS pod，從而讓會話在不同 pod 上續接。這是一個務實的選擇，也反映了軟體代理往往依賴與人類開發者相同的檔案與程序假設這個現實。

對企業 AI 團隊來說，這是這個故事中較具可信度的部分之一。它超越了「記憶體」這個行銷式簡寫，並顯示持久工作區、可續接性與決定性的工具環境，對代理可靠性至關重要。

證據、主張，以及仍未驗證的部分

由於來源材料來自 AWS 與 AWS Machine Learning Blog，因此最強的效能與採用主張都應視為供應商報告。AWS 表示，文章中的所有數據都來自 monday.com 的內部生產資料。

這些主張包括：monday.com 有十分之九的 builders 每個月都使用 AI 程式設計工具，約比半年前提升了一倍，以及每位工程師的 pull request 吞吐量提升超過一半。AWS 還表示，目前 monday.com 大多數工作都發生在這個 L2 技能與子代理層。

如果屬實，這些都是有意義的主張，但讀者也應注意現有證據中沒有提供的內容。沒有獨立方法論，沒有「builders」的原始分母，沒有超出大略相對語言之外的基準期間，也沒有說明更高的 pull request 吞吐量是否真的轉化為更短的 cycle time、更少的事故，或不同的審核負擔。材料也沒有量化成本、缺陷率，或人類審查者拒絕或重寫代理輸出的頻率。

同樣地，AWS 表示 Amazon Bedrock 透過 Application Inference Profiles 等機制，幫助 monday.com 將成本追蹤、容量規劃與模型呼叫稽核軌跡集中在同一處。這作為平台優勢是合理的，但這裡的證據仍然是描述性的，而非比較性的。沒有與其他部署路徑直接對照的基準測試。

儘管如此，這篇文章仍比許多 AI 案例研究更強，因為它花在系統設計上的篇幅遠多於抽象的轉型說法。缺乏獨立驗證並不會抹去架構訊號；它只是限制了買家應該賦予生產力數字多少權重。

這對建構者與企業買家意味著什麼

對軟體團隊而言，monday.com 的例子指出 AI stack 中一個實用的分工。像 Cursor 與 Claude Code 這類產品可以迅速提升個別開發者的產出，但要擴展到超越個人協助，就需要更接近平台工程而不是提示工程的基礎架構。

對企業 AI 買家而言，這個案例提醒人們，將 AI 代理部署到面向客戶的軟體組織，會帶來比聊天機器人上線更嚴格的要求。會開啟 pull request 或根據 ticket 採取行動的代理，需要持久身分、受限權限、可觀測性、回復路徑、審核檢查點，以及足夠的稽核細節，以滿足資安與合規團隊的需求。

這個故事也讓 Amazon Bedrock 周邊的競爭定位更清楚。AWS 將這項服務定位為不只是模型存取，而是跨多個代理的容量、治理與成本核算控制點。對已經標準化採用 AWS 的公司來說，這種訴求很可能具有吸引力，尤其是那些希望保有模型選擇彈性、但又不想從零建立自己的 gateway layer 的企業。

同時，monday.com 自身的設計也顯示，僅靠雲端服務無法解決核心工作流程問題。真正的差異化層是內部 harness：路由、評估、外掛邏輯、審核政策，以及與 Slack、GitHub 與 monday 本身的團隊整合。購買代理平台的企業需要決定，自己想擁有這個 harness 的多少部分。

接下來要關注什麼

下一個值得觀察的訊號，是 monday.com 或 AWS 是否提供更有力的軟體品質與營運成本證據，而不只是活動指標。pull request 數量很有用，但企業買家會想看到事故率、回復頻率、審核時間與資安例外的資料。

第二個訊號是 monday.com 是否將代理自主性擴展到內部工程工作流程之外。如果代理能安全地從程式設計支援擴展到更廣泛的產品與營運任務，這將強化一個論點：結構化的多代理系統可以成為通用的企業模式。

第三，值得留意 AWS 是否會把這個架構轉化為更產品化的指引或功能，圍繞 Amazon Bedrock、Amazon EKS 與協調工具展開。目前的描述仍暗示 monday.com 做了大量客製化工程。

最後，也值得追蹤競爭對手是否會發布同樣細緻的生產故事。市場上有很多關於 AI 代理的說法，但真正能解釋代理如何持續保有脈絡、如何從故障中恢復，以及如何在真實企業 stack 中通過人類審核的案例相對不多。

Creati.ai 觀點

這裡真正的新聞不是 monday.com 用 AI 來寫程式碼。很多公司都這麼做。更重要的發展是，monday.com 正在描述一種針對 AI 代理的生產運作模型，把它們視為既有軟體交付系統中的受管理工作者，並搭配佇列、檔案系統、稽核軌跡與明確的審核邊界。

這正是企業 AI 市場前進的方向。贏家不會是那些擁有最炫示範的團隊，而是能讓 AI 代理對工程經理、資安團隊、財務團隊與 on-call 操作人員都清楚可理解的團隊。AWS 所呈現的 monday.com 架構顯示，當代理的採用先以基礎架構建成、再以智慧加值時，它才真正變得可信。