當 agent 的答案會左右巡邏船的航向，可靠性就不再是 benchmark 上的一個分數。Ai2 Skylight 團隊打造的海事 agent Shippy，服務的是 maritime domain awareness 這種高風險決策場景——團隊自己的話：錯誤答案有實際後果。他們在技術文章裡回顧的第一手結論相當直接：在高風險營運域，真正的難題不是選更強的模型，而是建立一個可信正確、守得住界線、跨任務穩定的系統，而且必須對持續更新的 live data 驗證。
這個結論把 agent 可靠性從模型問題轉成工程問題，文章的價值在於把它拆成四個可以動手的層次。
三層解剖：soul、skills、config
Shippy 把 agent 定義切成三塊，各自可獨立演進：
| 層 | 內容 | 職責 |
|---|---|---|
| Soul | system prompt | persona 與行為邊界 |
| Skills | 帶 structured frontmatter 的 markdown | 特定請求類型的工作流 |
| Config | 其餘執行設定 | harness、模型、runtime |
Skills 遵循與 Claude Code、Codex 相同的 agent-skills spec，內容涵蓋 Skylight API 查詢（events、vessel data）、EEZ 與 MPA 邊界、vessel track 解讀與互動地圖 deep links；其中 track 解讀 skill 建立在 Skylight 既有模型（含 Atlantes）產出的 activity classifications 之上，而不是讓 agent 從原始訊號重新判讀。
Soul 與 skills 打包進版本化的 Docker image，secrets 在 runtime 注入。換 LLM 或 agent harness 只是 config 變更、不需 rebuild——目前 harness 是開源框架 OpenClaw，模型是 Claude Opus 4.6。這個分離真正的收益在治理：Shippy 不做船隻是否違法的法律認定、不做資料不支持的推測，這些禁區明寫在 system prompt 而非隱含在 fine-tuning 裡，因此可稽核、可版本化修改，也進得了 review 與 eval 流程。
確定性工具：用專建 CLI 包住複雜 API
早期 prototype 讓 Shippy 從零組 API calls。Skylight API 有數十種 input types、巢狀 filters、pagination cursors 與複雜 geometry，結果是一串 subtle bugs：malformed pagination 靜默丟掉結果、geometry encoding 錯誤、誤解 filter type 導致看似正確的查詢回傳錯資料。這類錯誤最麻煩的是「看起來對」——agent 拿著錯資料繼續推理，人類要到下游才會發現。
解法是收斂介面。Shippy 不發 raw API 呼叫，改走專建 CLI：一句 skylight events search 搭配 typed filter flags，authentication、pagination、structured output 全由 CLI 處理；CLI 帶完整 --help 與清楚的錯誤訊息，agent 錯了能自我恢復，不必用猜的。輸出一律寫入本地 JSON 檔而非 shell pipe——大結果集曾撞 pipe buffer 限制、弄壞 jq 這類下游工具，寫檔同時讓後續步驟可直接重用結果。地名解析也走同一原則：查「fishing activity in Panama’s EEZ」時，skill 指示先經 Skylight regions API 把地名解析成 boundary polygon，而不是猜座標或 hard-code，並以 deep links 與資料來源（Global Fishing Watch、TMT）歸因。
CLI 底層是 standardized API：events、vessels、regions、satellite imagery、vessel tracks 共用 search 與 aggregate 兩種操作，輸入輸出是帶欄位級說明的 typed schemas。分層的意義是每一層都能獨立測試——API 有自己的測試、CLI 可以讓人或 agent 直接操作、skills 引用 CLI 指令而不重新發明。每一層都在縮小下一層可以出錯的空間。
Mothership：每個 session 一個沙盒
Skylight 是免費平台，依官方數字服務 70 多國、300 多個 partners（多為政府機構與 NGO），多租戶隔離因此是專案最重大的工程挑戰之一。團隊自建 Mothership hosting platform：每個 user session 供應一個專屬 Kubernetes deployment，pods 打包 agent runtime、skills 與 CLI；使用者的 Skylight JWT 在 provision 時注入，API 呼叫自動 scoped 到該用戶的資料；session 內建立的檔案不跨用戶共享；sandbox 可寫程式、跑多步分析，但網路只開必要服務。
值得注意的是隔離發生的位置：不是在應用層做過濾，而是靠 runtime 注入與部署邊界。應用層過濾依賴「每次都記得檢查」，Mothership 靠的是「想越界也沒有路」。
評測整個 agent：live data 加 LLM judge
靜態 benchmark 測不出 wired-in agent 的行為——怎麼選工具、怎麼查 live data、何時停手。Shippy 的 eval 直接評整個 agent（model 加 skills 加 sandbox）對真實資料的表現：領域專家寫 scenarios 與 rubrics、設定權重並標注 ground truth；LLM judge 對每個 criterion 給 0 到 1 分，並以書面說明為什麼過或不過，加權總分對固定的 pass threshold。
執行面用開源評測框架 Harbor 撰寫 plugin，在受測版本上啟動真實 Shippy session、以與用戶相同的 real data 平行執行，產出 timestamped 結果與對前次比分的報告；skills、模型或底層資料變更都會重跑。這裡的關鍵定位是 eval 即 release gate：regression 的版本不會到達端用戶。
已知成果與仍在的失敗模式
最新一輪 eval 裡，guardrail 任務表現一致：正確拒絕 military intelligence requests、維持 user data isolation、來源歸因正確。失敗模式也同樣具體：patrol-planning 任務會越界給 tactical recommendations；邊界簡化造成漏 events；還有一例捏造了不存在的 CLI command。這些都不是模型 benchmark 看得見的失敗，而每一條都直接回饋到 skills 的修改。
限制與 builder 建議
限制要照實講：目前沒有 cross-thread memory，分析師每次 session 都要重述管轄範圍；map 只回 deep links，尚未做到 agent-driven UI control；簡單與困難查詢目前走同一個模型，團隊計畫用 model routing 把前者導向小模型省成本；Shippy 正以 rolling basis 開放 early adopters 做壓力測試。另外，Mothership 本身被設計成通用的 agent hosting，這套經驗將移植到 Ai2 的其他計畫，例如 EarthRanger。
對 builder 有三個可直接帶走的判斷：第一，把行為邊界寫進可版本化的 system prompt，而不是散在 fine-tuning 與團隊共識裡——可稽核的禁區才是可測試的禁區。第二，與其讓 agent 直接面對複雜 API，不如投資一層 typed、自文件化的 CLI，把不確定性留在模型、確定性留在工具。第三，把 eval 當 release gate 而非事後報告：whole-agent、live data、rubric 加權，把 regression 擋在端用戶之前。生產 agent 的可靠性不是買一個更強的模型換來的，而是一層層把出錯空間縮小出來的。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。