Shippy 的经验：高风险海事 AI Agent 不能只靠大模型

导语

Ai2 在 Hugging Face Blog 上复盘了海事 AI Agent Shippy 的构建经验。Shippy 服务于 Skylight 的实时海事态势感知系统，帮助分析人员查询船舶活动、专属经济区、海洋保护区边界和船舶轨迹等信息。这个场景的特殊之处在于：回答错误并不只是体验问题，可能会让巡逻船偏离方向，浪费本就紧张的执法资源，甚至带来人员风险。

因此，Shippy 的重点并不是“换一个更强的大模型”，而是如何让一个非确定性的 Agent 在高风险业务中尽量可验证、可约束、可隔离。

核心要点

• Agent 被拆成 soul、skills 和 config：soul 是系统提示，规定角色和行为边界；skills 是面向具体任务的能力说明；config 则决定运行框架、模型和运行参数。模型或框架更换可以通过配置完成，而不必重建整个 Agent。
• 技能采用 Markdown 规范管理：Shippy 的技能以带结构化 frontmatter 的 Markdown 文件保存，覆盖 Skylight API 查询、EEZ 和 MPA 边界检索、船舶轨迹解释、地图深链生成等任务，便于版本化、审查和迭代。
• 用确定性工具约束不确定性模型：早期让 Agent 直接拼 API 请求时，出现过分页、几何编码和过滤条件误用等隐蔽问题。后来团队提供了专用 Skylight CLI，让 Agent 通过稳定命令调用 API，由 CLI 处理认证、分页和结构化输出。
• 会话级沙箱保障隔离：Shippy 运行在 Mothership 平台上。每个用户会话都会得到独立的 Kubernetes 部署，用户 JWT 在创建时注入，文件和会话历史只存在于该会话中，网络访问也被限制在必要服务范围内。
• 评测对象是整个 Agent，而不是单个模型：团队认为静态问答基准无法反映 Agent 在真实流程中的表现，因此围绕 Shippy 的实际工作方式评估模型、技能和沙箱的组合效果。

意义与影响

Shippy 的案例说明，企业级 Agent 的护城河往往不是一个提示词或一次模型升级，而是一整套工程系统：可测试的 API、稳定的工具层、明确的行为边界、权限隔离和贴近业务的评测机制。

对于高风险行业来说，Agent 不应被鼓励“猜测”。它需要知道何时调用工具、如何展示数据来源、什么时候停止推断，以及哪些判断必须交还给人类。Shippy 明确不做法律定性，也不超出数据范围推测，这一点比“回答得更像专家”更重要。

这也给其他行业的 Agent 落地提供了参考：先把工具链做成可预测的接口，再把权限和数据隔离做扎实，最后用真实工作流检验系统整体表现。只有这样，Agent 才可能从演示产品走向可承担责任的生产系统。

来源：Hugging Face Blog