一个会犯错的 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 定义为三个相互关联、各司其职的组成部分Soul行为边界Soul 是 Shippy 的系统提示词用来明确智能体在海事分析场景下的定位与行为边界。其中规定船舶是否违法必须由人工判断Shippy 不得直接作出法律认定现有数据不足以支撑结论时也不得继续推测。这些约束规则直接写在系统提示词中研发团队可以对其进行审核和调整。Skills任务流程Skills 采用带有结构化 frontmatter文件头部元数据的 Markdown 文件每个 Skill 对应一类业务任务的执行方法。以专属经济区捕捞查询为例对应 Skill 会规定执行步骤先调用 Regions API 获取地理边界多边形再查询该地理范围内的捕捞事件最后生成地图链接并标注数据来源。如果用户需求同时涉及保护区范围、船舶信息和航行行为解读等多类内容Shippy 会组合多个 Skills分别完成数据查询、边界确认和轨迹解读。无论调用单项还是多项 Skill模型都需要按照文件中规定的数据来源、调用步骤和结果组织方式执行任务。Skills 无法消除大模型本身的非确定性但能够减少模型需要自主决定的环节缩小潜在的出错范围。Config运行配置Config 用于配置智能体运行框架、基础模型及各类运行参数。文章发布时Shippy 基于 OpenClaw 框架运行使用的模型是 Claude Opus 4.6API 密钥等敏感信息在运行时注入。后续如需更换模型或运行框架只需调整 Config无需重新构建智能体镜像。交付部署时Soul 与 Skills 会统一打包进带版本标识的 Docker 镜像形成可部署、可追踪版本的 Shippy 定义模型、运行框架及相关运行参数由 Config 单独管理API 密钥等敏感凭证则在运行时注入。通过这种拆分方式团队可以明确每次评测对应的是哪一版 Shippy 定义同时区分两类变更一类是底层模型、运行框架等 Config 调整另一类是 Soul、Skills 业务规则的修改。Soul 和 Skills 分别规定智能体的行为边界与任务执行流程却无法保证模型在运行过程中一定能够构造出正确的 API 请求。想要进一步减少此类错误就需要将复杂、易出错的通用操作封装为稳定、可预测的工具接口。三、模型的自由度要被约束在工具边界内项目早期原型中Shippy 可以自主构造 Skylight API 请求但落地后暴露出不少隐蔽问题分页格式异常会悄悄丢失部分数据几何编码可能出现错误模型也可能误解某种筛选字段发出形式正确但返回错误数据的接口请求。针对这类问题Ai2 开发了专用的 Skylight CLI让 Shippy 通过预定义的类型化命令访问底层接口不再自行拼装原始请求。整套调用链路分为三层Skills规定业务执行流程。Skills 文件说明每类任务需要查询哪些数据、采用什么调用顺序以及如何组织结果为 Shippy 提供具体的任务执行方法。Skylight CLI提供稳定的调用入口。Shippy 调用 skylight events search 等预定义命令并通过类型化参数传入筛选条件。身份认证、数据分页和结构化输出均由 CLI 统一处理CLI 还提供丰富的 --help 文本和详细的错误信息。调用出现异常时智能体或研发人员可以根据提示调整调用方式而不必继续猜测。Skylight API提供底层数据查询能力。底层接口统一提供船舶行为事件、船舶信息、地理区域、卫星影像和船舶轨迹等多类资源并通过 search 和 aggregate 两类操作访问。API 的输入和输出由类型化 Schema 定义各字段均附带说明。jq分层的设计也使各个组件能够分别测试Skylight API 有自己的测试套件CLI 可以由研发人员或智能体单独执行Skills 则直接引用 CLI 提供的命令不需要重复处理身份认证、分页等底层逻辑。下图展示了这条调用关系用户请求先通过 OpenClaw 运行框架进入 ShippyShippy 依据 Skill 中的任务说明规划查询和组织结果再通过 Skylight CLI 访问 Skylight API。Shippy从用户请求到Skylight API的整体调用架构整套工具链将身份认证、分页处理、数据序列化等通用底层逻辑从模型的自主决策流程中抽离让模型把主要精力放在用户需求解析和多步骤任务规划上。但工具调用格式正确并不代表当前用户有权访问相关数据。系统进入多用户业务场景后还需要将会话状态、用户身份凭证与数据访问权限绑定在一起。四、权限与会话隔离越界的数据查得再准也是错误在 Skylight 平台内用户自定义的关注区域、船舶观察名单和告警配置均与具体账户绑定。Shippy 调用平台接口时必须使用当前用户的访问权限。如果用户身份与访问权限没有正确对应哪怕查询条件和运算逻辑完全无误也可能读取到其他账户的数据导致输出结果失去业务使用价值。除了保证接口只返回当前用户有权访问的数据系统还需要隔离不同用户的对话记录与会话文件避免数据交叉混用。为此 Ai2 搭建了智能体托管平台 Mothership。用户发起对话时Mothership 会为本次会话创建专用的 Kubernetes 部署资源并启动一组 Pods其中包含负责运行 Shippy 的 Agent Runtime、任务流程 Skills 以及 Skylight CLI。整组运行资源共同组成独立的会话沙箱而不是一个单独的“沙箱 Pod”。这套会话沙箱通过三类机制收紧访问边界会话文件隔离智能体在多步骤分析过程中生成的文件仅保留在当前会话不会在不同用户之间共享。用户凭证绑定创建会话时Mothership 会注入当前用户的 Skylight JWT。Shippy 经由 CLI 发起的 API 请求会受到该 JWT 对应数据权限的限制使工具调用与当前用户身份保持一致。网络范围限制沙箱内部保留完成复杂分析所需的能力Shippy 可以编写并运行代码、安装依赖、加载数据集并完成多步骤分析但对外网络只开放完成任务所需的服务从而缩小可以连接的外部范围。Soul 用来说明业务上哪些行为不可接受会话沙箱、网络限制和用户凭证则从系统层面缩小 Shippy 实际能够执行的范围。前者属于行为约束后者属于强制控制两类机制不能互相替代。五、端到端评测不仅为结果打分还要指出具体失败行为评判 Shippy 的任务执行效果不能仅看模型最终输出的文本。Skills 的选择与执行、工具调用、实时数据查询和行为边界等环节都会影响任务能否正确完成。如果仅依靠一批固定的静态问题进行测试很难覆盖上述完整执行过程。基于这一点Ai2 的评测对象并非单一大模型而是由模型、任务流程 Skills 和用户隔离沙箱共同构成的完整智能体。评测使用用户实际面对的实时数据整套评测体系包含三个核心环节行业专家制定评测规则由海事领域专家编写各类业务场景和相应的评分细则针对不同任务选择评价维度并设置权重。以捕捞活动查询任务为例数据准确性权重最高地理范围解析和时间范围次之数据来源标注与文本表达风格的权重较低。专家还会将具体回答标注为正确或错误作为大模型裁判评分时的参照。对真实智能体版本执行评测团队依托开源评测框架 Harbor 运行测试并通过插件启动待测版本的真实 Shippy 会话。大模型裁判按照专家制定的评判标准对智能体输出逐项打分并说明评分理由再将加权总分与预先设定的通过阈值进行比较判断本次任务是否通过。评测结果联动版本发布流程评测套件会针对指定的版本化 Shippy 构建并行执行任务产出带时间戳的结果文件以及与上一轮评测相比的分数变化报告。Skills、模型或底层数据发生变化后团队都会重新运行评测套件如果新版本在既有评测标准上出现退化就不会交付给最终用户。下图为单项任务的完整评分流程用户输入自然语言查询后请求会进入真实的会话隔离沙箱Shippy 按照正常流程读取数据并执行任务。随后大模型裁判参照专家制定的评分细则对各项评判指标给出 0 到 1 之间的分数并附上判定说明系统计算加权总分将得分与预先设定的通过阈值进行比较最终给出任务通过或未通过的结果。单项任务的端到端评测过程在最近一次评测中Ai2 团队发现了三类较明显的问题执行巡逻规划任务时Shippy 超出决策支持边界给出了战术建议涉及地理边界的查询因边界简化而遗漏部分 Events模型编造了平台实际并未提供的 CLI 命令。评测会记录各项指标的得分和大模型裁判给出的理由研发人员可以据此看到具体哪项行为没有达到要求。这些结果会用于下一轮 Skills 改进完成修改后团队可以重新运行评测套件检验新版本是否仍然存在同类问题。六、Shippy 未来引入的新能力目前Ai2 正分批向早期试用用户开放 Shippy同时邀请用户测试智能体不擅长回答的问题以及仍需加强的行为边界。在此期间团队正在继续开发三项能力地图直接交互当前Shippy 在地图交互方面只能在回复中返回地图访问链接后续将实现对 Skylight 地图的直接操控可以定位目标区域、应用筛选条件并调整时间范围。模型路由调度系统将根据任务需要分配模型简单查询交给规模更小速度更快的模型复杂调查任务则继续使用完整规格模型。跨对话线程记忆现阶段对话历史只能保留在当前线程内无法带入其他对话线程。团队正在开发跨线程记忆功能使 Shippy 能够记住分析人员的管辖范围、偏好数据源等信息。后续用户直接提出“展示本周捕捞活动”时就不必再次说明自己关注的专属经济区。Shippy 的研发经验也正在向海事场景之外延伸并已经开始影响 Ai2 对野生动物保护平台 EarthRanger 和地球观测工具套件 OlmoEarth 中智能体设计的思考承载 Shippy 的 Mothership 从一开始就被设计为通用托管平台可以继续承载其他智能体。结语可靠性来自可追责的具体系统版本Shippy 这套方案展示了一套可供参考的工程实现思路智能体无法做到零失误但可以依靠多种工程机制限制和发现问题将 Soul、Skills 与 Config 分开管理。Soul 规定业务行为边界Skills 描述任务执行流程Config 管理模型、运行框架及相关参数Soul 与 Skills 则被打包进带版本标识、可以直接部署的 Docker 镜像通过 Skylight CLI 统一处理身份认证、分页和结构化输出等通用逻辑提供稳定、可预测的工具接口减少模型自行拼装复杂 API 请求产生的错误Mothership 为每个用户会话分配独立的运行资源并结合用户 JWT、会话文件隔离和网络访问限制隔离不同用户的运行状态约束数据访问范围建立端到端评测体系针对待测的 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 和后续建设方向代表文章发布时的状态。公开材料未提供完整镜像版本号、运行配置、评测样本量、各任务实际得分、阈值数值或第三方复现结果。