一个会犯错的 Agent，凭什么进入高风险业务？Shippy 的工程实践

Shippy 是 Ai2 旗下 Skylight 团队面向海事态势感知业务打造的行业专用智能体，核心作用是协助分析人员通过自然语言查询海事数据、解析船舶动态。该智能体输出的分析结论可能会在协助分析时影响到海上巡逻部署与调度资源分配，一旦出现地理范围识别偏差、海上事件遗漏、越权数据访问，或是超出辅助决策职责范围输出结论，都可能引发实际业务风险，严重时甚至会威胁一线作业人员安全。判断这套智能体运行是否可靠，不能只看回答通顺与否，还需要核验用户需求解析、任务执行、工具调用、权限控制和结果复核的整个过程。

针对上述全业务链路，Ai2 配套设计了三类工程机制。首先是智能体定义：依靠 Soul 完成角色定位与行为边界划定，通过 Skills 定义各项业务任务的执行流程，再借助 Config 配置智能体运行框架、底层模型及相关参数。其次是运行阶段的约束：Skylight CLI 将各类复杂 API 封装为类型化命令接口，并统一处理身份认证、分页和结构化输出；Mothership 负责为每次用户会话分配独立的隔离环境，同时注入当前用户的 JWT，将 API 请求限定在该用户有权访问的数据范围内，并把网络连接限制在必要服务。最后是端到端评测：Ai2 使用真实业务任务和实时海事数据测试完整智能体，评测结果将作为版本能否交付给用户的判定依据。

Skylight 是一套海事态势感知平台，其依托卫星和船舶信号持续更新数据，目前已被全球 70 多个国家的 300 余家合作机构使用，涵盖各国政府职能部门与各类非政府组织。Shippy 的主要作用是简化分析人员的操作流程，以往需要多步操作才能完成的数据查询，现在通过自然语言提问即可实现。例如，工作人员可以直接提出复合查询需求：“查询上个月巴拿马专属经济区内的捕捞活动。”

这类需求并非单次简单数据检索，背后是一套多环节联动的执行流程：Shippy 先通过 Skylight CLI 调用 Regions API，将“巴拿马专属经济区”转换成地理边界多边形；再限定相应的地理范围与时间窗口，检索捕捞事件数据；最后整合查询结果、生成配套地图链接，并标注数据来源。整个过程中的身份认证、数据分页和结构化输出，均由 Skylight CLI 统一处理。项目初期尚未接入 CLI 时，原型允许 Shippy 自行构造 API 请求，因此频繁出现分页格式、几何编码和筛选字段理解等错误。这些问题会造成数据缺漏或结果失真，但智能体给出的文字回复依旧通顺。由此可见，单看回答通顺度，不足以判断查询任务是否得到正确执行。

下图为加纳水域船舶查询实例。该场景虽和前文巴拿马捕捞业务属于不同查询任务，但二者采用相同的结果核验方式。返回结果中会附带地理边界来源、数据截止时间、实际查询时间以及 Skylight 地图访问入口。工作人员可通过这些信息确认本次查询使用的数据范围，并跳转到原始地图页面，核对统计数值与地理范围是否准确。

但即便支持通过原始地图进行校验，也不能说明整套查询流程不存在偏差。边界来源、查询时间和地图链接只能作为人工复核的辅助依据，一旦 Shippy 解析地理范围出错、理解筛选条件出现偏差，或在分页处理时丢失数据，最终给出的结果依旧会失真。想要定位、追溯这类流程层面的隐性错误，必须明确生成结果的智能体遵循了哪些行为规范和执行流程，并确认它采用了什么运行配置。基于这一需求，Ai2 将 Shippy 的行为规范和任务流程纳入可版本化定义，并把模型、运行框架等运行配置与之分开管理。

Ai2 在试验中发现，倘若角色约束、业务流程、模型选型与运行参数全部混杂在一段提示词或是单份代码里，后续一旦出现评测指标下滑，很难定位问题根源。为此，Ai2 将 Shippy 定义为三个相互关联、各司其职的组成部分：

1. Soul（行为边界）：
    Soul 是 Shippy 的系统提示词，用来明确智能体在海事分析场景下的定位与行为边界。其中规定：船舶是否违法必须由人工判断，Shippy 不得直接作出法律认定；现有数据不足以支撑结论时，也不得继续推测。这些约束规则直接写在系统提示词中，研发团队可以对其进行审核和调整。
2. Skills（任务流程）：
   Skills 采用带有结构化 frontmatter（文件头部元数据）的 Markdown 文件，每个 Skill 对应一类业务任务的执行方法。以专属经济区捕捞查询为例，对应 Skill 会规定执行步骤：先调用 Regions API 获取地理边界多边形，再查询该地理范围内的捕捞事件，最后生成地图链接并标注数据来源。如果用户需求同时涉及保护区范围、船舶信息和航行行为解读等多类内容，Shippy 会组合多个 Skills，分别完成数据查询、边界确认和轨迹解读。无论调用单项还是多项 Skill，模型都需要按照文件中规定的数据来源、调用步骤和结果组织方式执行任务。Skills 无法消除大模型本身的非确定性，但能够减少模型需要自主决定的环节，缩小潜在的出错范围。
3. Config（运行配置）：
   Config 用于配置智能体运行框架、基础模型及各类运行参数。文章发布时，Shippy 基于 OpenClaw 框架运行，使用的模型是 Claude Opus 4.6；API 密钥等敏感信息在运行时注入。后续如需更换模型或运行框架，只需调整 Config，无需重新构建智能体镜像。

交付部署时，Soul 与 Skills 会统一打包进带版本标识的 Docker 镜像，形成可部署、可追踪版本的 Shippy 定义；模型、运行框架及相关运行参数由 Config 单独管理，API 密钥等敏感凭证则在运行时注入。通过这种拆分方式，团队可以明确每次评测对应的是哪一版 Shippy 定义，同时区分两类变更：一类是底层模型、运行框架等 Config 调整，另一类是 Soul、Skills 业务规则的修改。

Soul 和 Skills 分别规定智能体的行为边界与任务执行流程，却无法保证模型在运行过程中一定能够构造出正确的 API 请求。想要进一步减少此类错误，就需要将复杂、易出错的通用操作封装为稳定、可预测的工具接口。

项目早期原型中，Shippy 可以自主构造 Skylight API 请求，但落地后暴露出不少隐蔽问题：分页格式异常会悄悄丢失部分数据，几何编码可能出现错误，模型也可能误解某种筛选字段，发出形式正确但返回错误数据的接口请求。针对这类问题，Ai2 开发了专用的 Skylight CLI，让 Shippy 通过预定义的类型化命令访问底层接口，不再自行拼装原始请求。整套调用链路分为三层：

1. Skills：
   规定业务执行流程。Skills 文件说明每类任务需要查询哪些数据、采用什么调用顺序以及如何组织结果，为 Shippy 提供具体的任务执行方法。
2. Skylight CLI：
   提供稳定的调用入口。Shippy 调用 skylight events search 等预定义命令，并通过类型化参数传入筛选条件。身份认证、数据分页和结构化输出均由 CLI 统一处理；CLI 还提供丰富的 --help 文本和详细的错误信息。调用出现异常时，智能体或研发人员可以根据提示调整调用方式，而不必继续猜测。
3. Skylight API：
   提供底层数据查询能力。底层接口统一提供船舶行为事件、船舶信息、地理区域、卫星影像和船舶轨迹等多类资源，并通过 search 和 aggregate 两类操作访问。API 的输入和输出由类型化 Schema 定义，各字段均附带说明。

jq 分层的设计也使各个组件能够分别测试：Skylight API 有自己的测试套件；CLI 可以由研发人员或智能体单独执行；Skills 则直接引用 CLI 提供的命令，不需要重复处理身份认证、分页等底层逻辑。

下图展示了这条调用关系：用户请求先通过 OpenClaw 运行框架进入 Shippy，Shippy 依据 Skill 中的任务说明规划查询和组织结果，再通过 Skylight CLI 访问 Skylight API。

整套工具链将身份认证、分页处理、数据序列化等通用底层逻辑从模型的自主决策流程中抽离，让模型把主要精力放在用户需求解析和多步骤任务规划上。但工具调用格式正确，并不代表当前用户有权访问相关数据。系统进入多用户业务场景后，还需要将会话状态、用户身份凭证与数据访问权限绑定在一起。

在 Skylight 平台内，用户自定义的关注区域、船舶观察名单和告警配置均与具体账户绑定。Shippy 调用平台接口时，必须使用当前用户的访问权限。如果用户身份与访问权限没有正确对应，哪怕查询条件和运算逻辑完全无误，也可能读取到其他账户的数据，导致输出结果失去业务使用价值。

除了保证接口只返回当前用户有权访问的数据，系统还需要隔离不同用户的对话记录与会话文件，避免数据交叉混用。为此 Ai2 搭建了智能体托管平台 Mothership。用户发起对话时，Mothership 会为本次会话创建专用的 Kubernetes 部署资源，并启动一组 Pods，其中包含负责运行 Shippy 的 Agent Runtime、任务流程 Skills 以及 Skylight CLI。整组运行资源共同组成独立的会话沙箱，而不是一个单独的“沙箱 Pod”。

这套会话沙箱通过三类机制收紧访问边界：

1. 会话文件隔离：
   智能体在多步骤分析过程中生成的文件仅保留在当前会话，不会在不同用户之间共享。
2. 用户凭证绑定：
   创建会话时，Mothership 会注入当前用户的 Skylight JWT。Shippy 经由 CLI 发起的 API 请求会受到该 JWT 对应数据权限的限制，使工具调用与当前用户身份保持一致。
3. 网络范围限制：
   沙箱内部保留完成复杂分析所需的能力，Shippy 可以编写并运行代码、安装依赖、加载数据集，并完成多步骤分析；但对外网络只开放完成任务所需的服务，从而缩小可以连接的外部范围。

Soul 用来说明业务上哪些行为不可接受；会话沙箱、网络限制和用户凭证则从系统层面缩小 Shippy 实际能够执行的范围。前者属于行为约束，后者属于强制控制，两类机制不能互相替代。

评判 Shippy 的任务执行效果，不能仅看模型最终输出的文本。Skills 的选择与执行、工具调用、实时数据查询和行为边界等环节，都会影响任务能否正确完成。如果仅依靠一批固定的静态问题进行测试，很难覆盖上述完整执行过程。基于这一点，Ai2 的评测对象并非单一大模型，而是由模型、任务流程 Skills 和用户隔离沙箱共同构成的完整智能体。评测使用用户实际面对的实时数据，整套评测体系包含三个核心环节：

1. 行业专家制定评测规则：
   由海事领域专家编写各类业务场景和相应的评分细则，针对不同任务选择评价维度并设置权重。以捕捞活动查询任务为例，数据准确性权重最高，地理范围解析和时间范围次之，数据来源标注与文本表达风格的权重较低。专家还会将具体回答标注为正确或错误，作为大模型裁判评分时的参照。
2. 对真实智能体版本执行评测：
   团队依托开源评测框架 Harbor 运行测试，并通过插件启动待测版本的真实 Shippy 会话。大模型裁判按照专家制定的评判标准，对智能体输出逐项打分并说明评分理由，再将加权总分与预先设定的通过阈值进行比较，判断本次任务是否通过。
3. 评测结果联动版本发布流程：
   评测套件会针对指定的版本化 Shippy 构建并行执行任务，产出带时间戳的结果文件，以及与上一轮评测相比的分数变化报告。Skills、模型或底层数据发生变化后，团队都会重新运行评测套件；如果新版本在既有评测标准上出现退化，就不会交付给最终用户。

下图为单项任务的完整评分流程：用户输入自然语言查询后，请求会进入真实的会话隔离沙箱，Shippy 按照正常流程读取数据并执行任务。随后大模型裁判参照专家制定的评分细则，对各项评判指标给出 0 到 1 之间的分数，并附上判定说明；系统计算加权总分，将得分与预先设定的通过阈值进行比较，最终给出任务通过或未通过的结果。

在最近一次评测中，Ai2 团队发现了三类较明显的问题：执行巡逻规划任务时Shippy 超出决策支持边界，给出了战术建议；涉及地理边界的查询因边界简化而遗漏部分 Events；模型编造了平台实际并未提供的 CLI 命令。评测会记录各项指标的得分和大模型裁判给出的理由，研发人员可以据此看到具体哪项行为没有达到要求。这些结果会用于下一轮 Skills 改进，完成修改后团队可以重新运行评测套件，检验新版本是否仍然存在同类问题。

目前，Ai2 正分批向早期试用用户开放 Shippy，同时邀请用户测试智能体不擅长回答的问题以及仍需加强的行为边界。在此期间，团队正在继续开发三项能力：

1. 地图直接交互：
   当前Shippy 在地图交互方面只能在回复中返回地图访问链接，后续将实现对 Skylight 地图的直接操控，可以定位目标区域、应用筛选条件并调整时间范围。
2. 模型路由调度：
   系统将根据任务需要分配模型：简单查询交给规模更小速度更快的模型，复杂调查任务则继续使用完整规格模型。
3. 跨对话线程记忆：
   现阶段对话历史只能保留在当前线程内，无法带入其他对话线程。团队正在开发跨线程记忆功能，使 Shippy 能够记住分析人员的管辖范围、偏好数据源等信息。后续用户直接提出“展示本周捕捞活动”时，就不必再次说明自己关注的专属经济区。

Shippy 的研发经验也正在向海事场景之外延伸，并已经开始影响 Ai2 对野生动物保护平台 EarthRanger 和地球观测工具套件 OlmoEarth 中智能体设计的思考，承载 Shippy 的 Mothership 从一开始就被设计为通用托管平台，可以继续承载其他智能体。

Shippy 这套方案展示了一套可供参考的工程实现思路，智能体无法做到零失误，但可以依靠多种工程机制限制和发现问题：

1. 将 Soul、Skills 与 Config 分开管理。Soul 规定业务行为边界，Skills 描述任务执行流程，Config 管理模型、运行框架及相关参数；Soul 与 Skills 则被打包进带版本标识、可以直接部署的 Docker 镜像；
2. 通过 Skylight CLI 统一处理身份认证、分页和结构化输出等通用逻辑，提供稳定、可预测的工具接口，减少模型自行拼装复杂 API 请求产生的错误；
3. Mothership 为每个用户会话分配独立的运行资源，并结合用户 JWT、会话文件隔离和网络访问限制，隔离不同用户的运行状态，约束数据访问范围；
4. 建立端到端评测体系，针对待测的 Shippy 版本执行真实业务任务，在版本交付给用户之前发现评测退化和具体失败行为。

上述任何一项机制都无法单独保证整套系统可靠。Soul 无法替代权限控制，CLI 不能判断业务结论是否合理，会话沙箱不能发现地理范围遗漏，单次评测也无法保证后续版本不再出现问题。Skills、模型或底层数据发生变化后，都需要重新运行评测套件。对于高风险业务场景，研发团队交付的不能只是笼统的智能体能力，而应是一套能够明确对应到智能体定义、运行配置、用户权限、工具接口和评测结果的具体系统版本。

目前，Shippy 仍在分阶段向早期试用用户开放。这套工程实践还不能直接视为行业通用标准，但至少说明面向高风险场景的智能体，可靠性必须落实到可定义、可限制、可复核和可持续验证的完整执行链路中，大模型只是整套系统的一个组成部分。

• Kyle Wiggers / Ai2，《What building Shippy taught us about building agents》，2026 年 7 月 15 日。
• 原始材料由 Shippy 开发团队发布，属于项目方对自身架构和评测实践的说明，不是第三方独立验证。
• OpenClaw、Claude Opus 4.6 和后续建设方向代表文章发布时的状态。公开材料未提供完整镜像版本号、运行配置、评测样本量、各任务实际得分、阈值数值或第三方复现结果。