北京
在monday.com內部，一組來自生產環境的數據讓技術團隊自己都挺驚訝：九成構建者每月使用AI編碼工具，而一年前這個比例才在五成左右。更關鍵的指標是，每位工程師的PR吞吐量提升了超過一半。這些不是實驗室的預估，而是從實際開發流程里跑出來的數字，背后靠的是在十年老代碼庫之上運轉的AI隊友。
這里沒有綠地項目的從容。monday.com是一個有著數百萬付費用戶、數百個微前端和微服務的SaaS平臺，每一次提交、每一個代理自動打開的PR，都要保證接下來部署時能讓數百萬用戶繼續正常工作。在這樣的系統里跑AI代理，和在一個干凈的demo里跑，完全是兩碼事。
團隊把AI工程化分成了三層來推進。L1是助手階段，工程師用Cursor做快速反應型編碼，用Claude Code處理繁重任務，AI當結對編程的搭檔，年同比使用率幾乎翻了一倍。L2是技能和子代理層，各個團隊把重復工作封裝成可重用的代理，但方向盤依然握在工程師手里——就是在這個階段，每位開發者的PR吞吐一舉拉升了超過一半。L3則是多代理全自動模式：代理直接從看板抓工單，在Slack和monday里跟人對話，端到端交付功能，工程師的角色變成編配者。目前monday.com大規模運行在L2，L3也在逐步鋪開。
但如果只看架構圖，最容易讓人“啊哈”的點，是代理被當成隊友而非任務隊列來看待。內部系統Sphera打開后第一眼不是排隊的job，而是一個Teams頁面：人類和代理混在一起，每個都掛著自己的個人資料、經理、職責范圍和績效評分。文章里反復提到的代理Atlas，角色是軟件工程師，工作就是取工單、寫PR、把功能送上線——沒有IDE，跟所有人共用同一個待辦列表。工程師給Atlas做代碼審查、給Atlas分配任務，就跟對待其他同事一樣。
這么設計還有一個底層的工程理由：每個代理配備了三類一等收件箱——Slack的@提及、monday工單的分配、GitHub PR的審查請求。三條入口接入的是同一個代理會話，同一套記憶和磁盤工作區。也就是說無論協作信號從哪個通道進來，代理都能在同一個上下文里響應，不用切來切去，也不用維護三套獨立的代理系統。整套基礎設施基于Amazon Bedrock構建，承載著從提醒、分派到評估閉環的全部事件流。
monday.com的實踐把“生產級AI代理”這個話題拉到了很具體的層面：在已經有老板、有值班、有合規要求的環境里，代理怎么真正成為團隊的一部分，而不是又多了一個要維護的服務。他們給出的答案之一，就是讓代理擁有穩定的身份，在Slack、GitHub、monday全線可見，可以被標記、指派、審查，甚至停用。這樣一來，哪個代理真的在推動指標、哪個只是在角落里吃資源，所有人都看得一清二楚。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
