摘要： 當 agent 給出的答案能左右一艘巡邏船的航向時，可靠性就不再只是 benchmark 上的一個分數。Shippy 是 Ai2 Skylight 團隊打造的海事 agent，服務的是 maritime domain awareness 這種高風險決策場景——用團隊自己的話說：錯誤答案有實際後果。他們在技術文章裡回顧的第一手結論很直白：在高風險營運域，難題不在於挑一個更強的模型，而在於做出一套能被信任為正確、守得住界線、跨任務穩定的系統，而且必須對持續更新的 live data 驗證。
當 agent 給出的答案能左右一艘巡邏船的航向時，可靠性就不再只是 benchmark 上的一個分數。Shippy 是 Ai2 Skylight 團隊打造的海事 agent，服務的是 maritime domain awareness 這種高風險決策場景——用團隊自己的話說：錯誤答案有實際後果。他們在技術文章裡回顧的第一手結論很直白：在高風險營運域，難題不在於挑一個更強的模型，而在於做出一套能被信任為正確、守得住界線、跨任務穩定的系統，而且必須對持續更新的 live data 驗證。
這個定調把 agent 可靠性從模型問題搬成工程問題；文章的可貴之處，是把問題拆成四個 builder 能實際動手的層次。
三層拆解：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，結果是一連串細微 bug：pagination 寫壞了會默默漏掉結果、geometry 編碼出錯，或是 filter type 理解錯誤，讓看起來正確的查詢回傳錯的資料。這類 bug 最麻煩的是「看起來是對的」——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，而不是猜座標或寫死，並以 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 量不出已接進系統的 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 平行執行，產出帶 timestamp 的結果與對前次比分的報告；skills、模型或底層資料只要變動就會重跑。這裡最關鍵的定位是：eval 就是 release gate。在標準上退步的版本，到不了端用戶手上。
已知的成果，以及仍未解掉的失敗模式
最近一輪 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 的可靠性不是買一個更強的模型換來的，而是一層一層把出錯空間縮小累積出來的。