Ai2 最近公开了海事智能体 Shippy 的技术架构。它回答的是船舶活动、保护区边界和巡逻决策支持这类问题，一次看似合理的错误，可能让人员和船只付出真实成本。团队因此得出一个并不华丽却很重要的结论：生产级 Agent 最难的部分不是选到最强模型，而是让整个系统知道自己能做什么、依据来自哪里，以及什么时候必须停下。
同一周，GitHub 将 Code Quality 推向正式可用，Vercel 则开始把工作流状态固定到运行的主区域。这些发布分属不同产品，却共同说明 Agent 已经越过演示阶段。模型输出一旦进入代码库、业务流程或高风险决策，可靠性就不能再由提示词独自承担。
Shippy 把不确定性关进可测试的接口
Shippy 将 Agent 拆成系统行为边界、技能和运行配置。技能是有版本的 Markdown 文件，与运行环境一起封装；模型和 Agent 框架则留在配置层，可以替换而不必重做整套系统。真正关键的是工具接口：早期版本让模型直接拼复杂 API 请求，结果出现分页遗漏、地理边界编码错误和看似正确却筛错数据的查询。后来团队增加类型化 API 和专用 CLI，由 CLI 处理认证、分页及结构化输出，查询结果写入 JSON 文件，供后续步骤稳定读取。
这不是消灭模型的不确定性，而是把不确定性限制在可观察的位置。Vercel Workflows 的新区域策略体现了类似思路：一次运行的状态、队列调度和输出流留在同一主区域，发生区域故障时再转移。对需要多步执行、检查点和流式反馈的 Agent 来说，状态放在哪里、失败后从哪里恢复，与模型选型同样属于产品行为。
评测对象必须是整个 Agent
传统模型榜单只测静态问题，无法覆盖工具选择、实时数据、权限隔离和停止条件。Shippy 的做法是让领域专家编写场景和加权评分标准，在真实版本、真实工具与实时数据上运行整套 Agent；数据准确性、区域解析、时间范围、引用和拒答分别计分。团队记录到的失败也很具体，包括越界给出战术建议、边界简化漏掉事件，以及虚构不存在的 CLI 命令。版本只要在这些指标上回退，就不会进入用户环境。
GitHub Code Quality 则把这类约束前移到代码合并环节。产品同时使用确定性的 CodeQL 分析和 AI 辅助检测，并增加组织仪表盘、测试覆盖率、规则集质量门禁及修复建议。GitHub 表示，其内部工程团队会在合并前解决 67.3% 的 Code Quality 发现；这个数字是厂商内部数据，不能直接外推，但它说明质量门禁必须进入日常工作流，而不是等 Agent 生成更多代码后再集中清理。
代码增长越快，所有权越不能模糊
自动化能发现问题，却不能替组织决定谁来处理。GitHub 此前有超过 1.4 万个内部仓库，不到一半具备清晰所有者。团队在不到 45 天内为所有活跃仓库绑定经验证的服务、团队或个人所有者，并归档长期无人认领的项目。稳定运行后，活跃仓库约 3000 个，归档仓库约 1.1 万个。所有权不再靠 README 或提交历史猜测，而是成为可查询、可验证、创建时必填的结构化属性。
这项治理还有一个值得 Agent 系统借鉴的细节：当自动任务准备归档或创建的问题数量超过保守阈值时，流程会整体停止并报警，避免服务目录中的陈旧数据引发批量误操作。Agent 的规模越大，越需要这种针对异常批量动作的保险丝。责任归属和停止条件不是行政附录，而是自动化能够被允许执行的前提。
生产可靠性要按四层来建设
一套可上线的 Agent 至少需要四层约束：工具层把复杂 API 收敛成确定性命令；运行层保存状态、隔离权限并设计故障恢复；验收层针对完整任务而不是单个回答做回归测试；组织层为代码、数据和异常处置绑定明确所有者。模型仍然重要，但它反而成了其中最容易替换的一层。
接下来真正拉开差距的，不会只是哪个团队率先接入新模型，而是谁能在模型更换、数据波动和依赖故障时，仍然解释一次结果如何产生、把错误挡在发布前，并在系统越界时找到负责的人。对于准备把 Agent 接入生产的团队，这些能力应当先于更多自主权。