企業級 AI Agent 生產落地參考架構：從 DoorDash、Shippy 拆出的 5 條可複製工程模式

TL;DR（先給答案）：企業級 agent 怎麼上生產環境?難點不在選哪個模型,而在模型外圍的 5 件工程事——① 用確定性工具包住不確定的模型;② 編排與業務解耦的 MCP 層;③ 分層記憶;④ 評估 agent 而非評估模型;⑤ 領域團隊 × 平臺團隊的 FDE 式分工。下面用 DoorDash「Ask DoorDash」與 Allen Institute 的 Shippy 兩個一手生產案例,把這 5 條逐一拆開。

把一個 agent 在 demo 裡跑通,和把它送進每天服務真實使用者、真實交易的生產環境,是兩件難度差一個數量級的事。過去一年我們已經寫過不少「為什麼 AI agent 會在生產環境失敗」這類文章;這一篇不談「為什麼難」,只談「照著做的藍圖」——把本週兩個剛公開、都自帶公司名與硬數字的生產案例,拆成可複製的工程模式。

兩個案例互不相干,卻指向同一個結論:決定 agent 能不能上生產的,不是模型本身,而是模型外圍那一圈確定性的工程。 DoorDash 用轉化率數字證明這些投入直接變現;Shippy 則把「為什麼這麼做」講得極其乾淨。

生產環境的 AI agent 架構長什麼樣?(demo 級 vs 生產級)

一句話定義:生產級 agent 架構,是把一個不確定的語言模型,包在一圈確定的、可測試、可審計的工程元件裡——工具、編排層、記憶、評估、隔離,一樣都不能少。 demo 之所以是 demo,恰恰因為它省掉了這一圈。

下面這張表把差距量化落地。每一行的「生產級」列,都由 DoorDash 或 Shippy 的真實做法支撐:

維度	Demo 級 agent	生產級 agent
工具呼叫	讓模型直接拼 API 呼叫	專建確定性 CLI/工具(處理鑑權/翻頁/結構化輸出)
架構	提示詞裡塞業務邏輯	編排與業務解耦,業務能力走共享 MCP 層
記憶	單輪上下文 / 無記憶	分層記憶(長期/會話/代理)+ 語義檢索注入
評估	人工抽查、跑一次看感覺	自動化評估框架,評「被測確切版本 + 真實資料」
隔離/安全	共享上下文	按使用者臨時沙箱隔離、護欄寫進系統提示(可審計)
組織	一個人 / 一個模型搞定	領域團隊建 agent × 平臺團隊維護編排/工具/記憶/評估

DoorDash 的「Ask DoorDash」正是這張表右列的樣板:它把一個對話式購物助手做到了生鮮雜貨結賬轉化率 +約 24%、購物車規模 +17%、對話輪次 −7%,餐廳搜尋的開放式查詢轉化率 +15%(據 InfoQ 報道)。這些數字不是模型換了個更大的版本換來的,而是右列那一整套工程堆出來的。

怎麼讓不確定的 agent 變得可靠?——給它確定性的工具

生產級 agent 的第一條範式,Shippy(Allen Institute 與 Skylight 合作的海事監測 agent)講得最直白。Hugging Face 上的這篇工程部落格有一句話值得貼在每個團隊的牆上:

"Agents are nondeterministic. You can't control what the model decides to do, but you can make the tools it reaches for predictable." (agent 是非確定性的。你控制不了模型決定做什麼,但你可以讓它伸手去夠的那些工具變得可預測。)

Shippy 早期讓模型直接去拼原始 API 呼叫,結果是「a steady stream of subtle bugs」——翻頁錯誤靜默丟資料、幾何編碼出錯、看起來正確卻返回了錯誤資料。這類 bug 最危險的地方在於它們不報錯、不崩潰,只是悄悄給出錯的答案。團隊的解法是:不讓模型碰原始 API,而是給它一個專門構建的 CLI,由這個 CLI 統一處理鑑權、翻頁、結構化輸出。模型的不確定性還在,但它能觸到的每一個動作都變確定了。Shippy 把這套分層架構總結為一句「Each layer narrows what the next layer can get wrong.」(每一層都收窄下一層可能出錯的空間。)

DoorDash 走的是同一條路的另一種形態:編排與業務功能徹底分離。助手執行時只負責編排各個專用 agent,而商品搜尋、推薦、購物車、結賬、訂單歷史、使用者記憶這些業務能力,統一由一個共享 MCP 層提供——業務邏輯不寫進提示詞,而是做成可複用的工具被呼叫。連版本化的資源更新,DoorDash 都用**確定性操作(無需呼叫 LLM)**來完成。能用確定性程式碼解決的,就不交給模型去猜。

agent 怎麼記住上下文而不失控?——分層記憶 + 確定性操作

有狀態是生產級 agent 和一次性 demo 的分水嶺,但「記住一切」不等於「把所有歷史一股腦塞進提示詞」。DoorDash 的做法是三層記憶:長期離線記憶、會話記憶、代理記憶,三者經語義向量檢索排序後,只把相關的部分注入當前提示。

這套記憶系統的價值不是抽象的「體驗更好」,而是可以直接換算成數字:正是這套計算型消費者記憶,帶來了前面提到的生鮮雜貨結賬轉化率 +約 24%、購物車規模 +17%、對話輪次 −7%。聯合創始人 Andy Fang 的說法很具體:「Ask DoorDash 生成購物車比手動快約 5 倍,一條提示 2 分鐘內完成。」

關鍵原則依舊是那條:能不調 LLM 就不調。記憶的檢索、排序、版本化更新儘量走確定性操作,把語言模型的算力留給真正需要推理的環節。這既省成本,也把「模型出錯」的暴露面壓到最小。

怎麼評估一個 AI agent 好不好用?——評估 agent,而非評估模型

這是整篇最該反覆讀的一節。大多數團隊評的是「模型」——跑幾個基準、看幾條 case,憑感覺判斷好壞。生產級團隊評的是**「agent」**:被測的那個確切版本、在真實資料上、跑出來的真實行為。

DoorDash 把這件事做成了工業級流水線:規模達到每日 >2000 次自動評估,由此把質量評分提升 8 分、迴歸測試從 6 小時縮短到 20 分鐘;一次模型遷移在質量不變的前提下延遲降低 35%。評估不是上線前的一道關卡,而是能天天跑、快速迭代的基礎設施。DoorDash 推薦系統與搜尋負責人 Raghav Saboo 的一句話點破了為什麼值得投入:

「構建一個有用的 AI 助手很難。而判斷它是否真正優秀,則更難。」

Shippy 把方法論補齊了:它明確提出**「評估 agent,而非評估模型」,用 Harbor 框架加上專家設定的加權 rubric,對被測的確切版本、真實資料**執行評估。這套評估揪出來的問題非常真實——agent 越界給出戰術建議、把邊界簡化導致漏檢,甚至「發明了一個根本不存在的 CLI 命令」。這些都是純看模型基準永遠發現不了、只有評估「這一個具體 agent」才會暴露的問題。想更系統地把評估與可觀測接起來,可參考我們的生產級 agent 可靠性與可觀測性與agent 可觀測、審計與評估兩篇。

團隊要怎麼組織,才能把 agent 送上生產?——FDE × 平臺分工

架構和評估都到位了,還有最後一塊常被忽略的拼圖:組織怎麼分工。 agent 上生產不是一個人、一個模型能扛下來的事。

DoorDash 的分工很清晰:領域團隊負責建各自的專用 agent,平臺團隊維護編排、MCP 工具、記憶、評估與共享元件。 領域團隊懂業務、離使用者近;平臺團隊沉澱可複用的地基。兩邊各司其職,新 agent 才能快速、安全地長出來。

Shippy 從工程側印證了同一套分層思路。它把一個 agent 拆成三段可獨立管理的組成:Soul(系統提示,定義 persona 與行為邊界)+ Skills(帶 frontmatter 的 markdown,版本化、可審計)+ Config(模型、harness 等執行時設定)。安全上,它按使用者臨時沙箱隔離——每個使用者在獨立的 Kubernetes 會話裡與 Shippy 互動,使用者 JWT 在開通時注入,使 API 呼叫被死死限定在該使用者的資料範圍內,因此能同時服務 70 個國家、300+ 合作方而互不串資料。護欄也不是靠 fine-tuning 隱式塞進模型,而是顯式寫在系統提示裡,用 Shippy 自己的話說「…makes them auditable and easy to revise」(可審計、易修訂)——例如它會拒絕做法律判定:「that is a determination for people, not an agent.」(那是該由人、而非 agent 來下的結論。)

這套「領域 × 平臺」的分工,正是 6AM 一直在做的事:讓 FDE(Forward Deployed Engineer)把 AI 真正長進企業的業務流程裡——領域側貼著業務建 agent,平臺側維護那一圈確定性的工程地基。我們不吹這套方法有多神,上面 DoorDash 與 Shippy 的數字就是最好的背書。

生產級 agent 落地清單(可照抄的藍圖)

把上面 5 條模式收斂成一份可勾選的 checklist——照著逐項打鉤,就是一份從 demo 到生產的遷移路線圖:

• 確定性工具:模型不碰原始 API,統一走專建 CLI/工具,由工具處理鑑權、翻頁、結構化輸出。
• MCP 解耦:編排與業務分離,業務能力做成共享 MCP 層的可複用工具,業務邏輯不寫進提示詞。
• 分層記憶:長期 / 會話 / 代理三層記憶,語義檢索排序後按需注入;能用確定性操作就不調 LLM。
• 評估閉環:自動化評估被測的確切版本 + 真實資料 + 加權 rubric,做到能天天跑、可迴歸。
• 按使用者隔離:臨時沙箱 + 身份令牌注入,把每個會話的資料邊界釘死。
• 護欄寫進系統提示:行為邊界顯式宣告、可審計、可修訂,而非隱式 fine-tune。
• FDE × 平臺分工:領域團隊建 agent,平臺團隊維護編排 / 工具 / 記憶 / 評估等共享地基。

七項打完鉤,你的 agent 就從「demo 裡能跑」跨到了「生產裡敢跑」。

---

想知道自己團隊離這份清單還差幾步? 6AM 的 FDE 就是幹這個的——把上面這套參考架構,落到你自己的業務流程和資料邊界裡。歡迎從落地診斷開始,或到常見問題裡找更多答案。