在現代的大型企業中，新進工程師最痛苦的往往不是寫程式碼本身，而是資訊的碎片化。當你需要了解一個系統如何運作時，得在 Confluence、GitHub、Slack 甚至隨機的 PDF 之間來回跳轉，這種「資訊尋找」的過程可能就耗掉入職後的第一個月。
Zoox 的 Staff Software Engineer Amit Navindgi 分享了他們如何透過建構名為 Cortex 的 AI 平台，將開發者的生命週期從「碎片化搜尋」轉向「AI 驅動的自動化流程」。
Cortex 平台的設計核心：安全與擴展性
許多公司在導入 LLM 時會面臨一個兩難：直接使用 ChatGPT 很方便，但企業的程式碼、客戶資料與車輛數據是核心機密，不能上傳到公共雲端。因此，Zoox 並非單純提供一個對外 API，而是建構了一個內部平台 Cortex。
Cortex 的設計必須滿足幾個關鍵限制： 第一是安全性與隱私，所有數據必須留在內部網路，且需嚴格處理 PII（個人可識別資訊），例如員工或乘客的私隱數據。 第二是多模態支持，作為自動駕駛公司，他們處理的不僅是文字，還有大量的影像、影片與音訊。 第三是貢獻者友好，如果只有平台團隊能增加功能，平台會變成瓶頸。因此，Cortex 必須讓所有工程師都能輕鬆擴展工具。
從 RAG 到 Agentic Retrieval 的演進
要讓 LLM 懂 Zoox 內部的專有名詞（例如 VH6 代表第六代車輛），單靠通用模型是不夠的。Zoox 採取了以下步驟：
首先是實作 RAG（檢索增強生成）。他們將 Confluence、Slack、GitHub 等分散的文檔建立索引。實務上的經驗是：為每個數據源建立獨立的知識庫，能有效縮小語義搜索的範圍，提高檢索準確度。
其次是引入 Agent（智能體）概念。在 Zoox 的定義中，Agent 就是一個「LLM 加上一組工具的迴圈」。當使用者詢問問題時，Agent 會根據工具描述（Tool Description）判斷該調用哪個 API。例如，詢問「誰在 On-call」時，Agent 會選擇調用內部 On-call 服務 API，而非去搜尋文檔。
最後是 Agent as API。為了降低開發門檻，Zoox 將 Agent 的部署與執行抽象化。一般團隊不需要自己維護 Agent 框架，只需調用 REST API 並傳入所需的工具清單，Cortex 就會動態生成一個輕量級 Agent。
實務中的關鍵機制：Human-in-the-Loop
在自動化流程中，最危險的是讓 AI 擁有「寫入權限」（Write Access），例如自動創建 Jira Ticket 或發送郵件。為了防止 AI 產生幻覺而亂發郵件給 CEO，Zoox 引入了 Human-in-the-Loop（人類介入）機制。
他們透過 Python 裝飾器（Decorator）將工具標記為需要確認。當 Agent 決定執行寫入操作時，系統會先將擬定的內容呈現給使用者，只有在人類點擊確認後，才會真正執行 API 調用。這不僅增加了安全性，也建立了使用者對 AI 的信任。
AI 應用的兩大類別：Workflow 與 Agent
Zoox 將 AI 應用分為兩種模式，建議團隊從簡單的開始：
AI Workflow（確定性工作流） 這是一種線性流程。例如：監控觸發警報 $\rightarrow$ AI 總結日誌 $\rightarrow$ 觸發 On-call 通知。AI 在其中只是一個可預測的步驟，不決定下一步方向。這類應用易於測試且穩定。
AI Agent（非確定性智能體） Agent 能根據目標自行決定調用工具的順序與時機。雖然強大且靈活，但難以調試且不可預測。
Zoox 的原則是：除非 Workflow 無法滿足需求，否則優先選擇 Workflow。
推動 AI 採用的工程文化
建構平台只完成了一半，另一半是讓工程師願意使用。Zoox 採取了幾項策略：
尋找 AI Champions。在每個部門找出對 AI 有熱情的領頭羊，由他們定義該部門的痛點並推動工具落地。 量化影響力。建立儀表板追蹤使用率，並將 vendor 工具（如 Cursor）的數據與公司內部組織數據對接，分析不同職級、不同團隊的使用模式。 舉辦 Hackathon（黑客松）。這是最快產生高影響力工具的方式。Zoox 曾在一次黑客松中產生超過 50 個 AI 應用。
對待新技術的態度：抗拒炒作，專注影響
面對日新月異的模型更新（如 Gemini 或 Claude 的新版本），AI 負責人的角色是：對所有新技術保持警覺，但不要立即盲目切換。所有的更換都應該基於 Evals（評估集）的量化結果，而非追隨趨勢。
此外，關於近期熱門的 MCP（Model Context Protocol），Zoox 的經驗是：對於內部平台，標準的 REST API 依然是最簡單且高效的選擇。過於複雜的協議可能會增加客戶端（Client）的開發成本，而帶來的收益有限。
來源：infoq.com - Accelerating LLM-Driven Developer Productivity at Zoox
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。