Ford Prior：用 AI 作战室改造 GEICO 遗留代码

过去几年，我们一直试图加快软件开发生命周期，尤其是构建阶段。编码速度大幅提升，但 GEICO 是一家风险管理公司，编码之外的工作仍然决定交付节奏：内循环变快了，决策与交付的外循环却没有跟上。

我们想象：如果外循环也能以同样的速度运转，软件交付会是什么样？我的团队负责理赔技术。事故发生后，理赔是保单兑现承诺、帮助客户重新上路的过程。

我是 Ford Prior，GEICO 理赔技术团队的资深工程师和技术布道者。我们的团队约有 300 名工程师，分成约 32 个小组。我的工作是推广更好的开发实践、运营理赔创新实验室，并分享经验。

六个月前，我们发现工程师处理完补丁和小版本升级后，最多只有 25% 的时间留给保持竞争力的重大改动。于是我们开始用 GEICO 管理的智能体，配合不同框架和模型，承担从规格到部署的小型工作。

重大改动仍依赖在恰当的时间召集恰当的人。决策出现时，团队还需要事实、代码分析和不断加深的领域理解。我们既需要更快的协作，也需要为协作提供信息支持。

我们的做法是建立多人参与的 AI 原生作战室：决策者和领域专家一起参与，由一名操作者使用 AI 工具，并共享沟通、设计和代码仓库。工作流、技能、MCP 连接及智能体群负责分析、综合和核查。

挑战是让智能体能够调用遗留理赔系统的能力。这些系统有数百万行代码，建立上下文成本很高，但可以重复使用。我打赌用一天和 1,000 美元的 AI token，就能端到端梳理一个领域并完成一项有意义的变更。

目标是在下午四点向上级演示：为遗留系统提供可供智能体调用的 API，并部署到智能体平台。我们做了三次实验，使用 Anthropic 代码现代化插件中的升级、转换和重新构想分类。

第一项是租车领域：我们用同类技术的新版本扩展现有 API。智能体把不同信息关联起来，发现了向客户提供最新租车信息的方法。Prior 表示，这可能每月减少约 8,500 通电话。

第二项是在损失定价领域新增可供智能体调用的 API。第三项针对更复杂的残值处理，也就是车辆全损后的流程，产出了包含规格和设计稿的迁移计划，并获得产品和技术负责人认可。这个过程还发现了一个生产问题。

供应商提供模型、运行框架、FleetKit 和代码现代化插件；这些组件可以替换。GEICO 自己必须提供的则是上下文：知识库、标准、过往决策、可用工具、工作方法，以及每个关卡有权作判断的人。

FleetKit 与 Anthropic 合作开发，演讲时尚未开源。它是一组管理智能体群的 Markdown 规则与指令：先拆解目标，派出负责研究的智能体，再把方案放入人工参与的队列；获得批准后，由构建智能体实施变更。

队列可以用类似 GitHub issue 的方式实现：人们评论或批准，其他智能体补充上下文。最终目标是产生实质性变更，例如对系统提出变更请求或修改代码。

启动任务时，系统加载相关仓库并建立共享沟通频道，邀请决策者和领域专家加入。当智能体缺少产品信息时，它可以识别并提醒负责的人，而不必等操作者自行寻找。

智能体还会生成可交互的工作表来填补信息缺口，并制作可编辑的设计文档，包括架构图。人们修改后，智能体可以重新读取。团队保留了一些图表，因为它们记录了此前没有这样梳理过的系统。

工作由两类智能体支持：云端智能体深入分析遗留语言代码并绘制关系图；本地智能体使用我笔记本上的企业工具和 MCP。一个绑定文件说明本机有哪些能力，以及它们如何接入 FleetKit。

操作者的笔记本就是运行环境。流程包括启动、限定范围、研究、目标、计划、构建、测试、部署和维护九个步骤。工作表充当审批关卡，脚本则确定性地检查前一阶段是否产出了所需文件。

成本是一个教训。Prior 提醒，不要让智能体仅为检查工作进展就定时启动新的 AI 会话，否则预算可能迅速耗尽。他还发现提示缓存使用量高于预期，并观察到一些不寻常的子智能体行为。

在建立上下文之后，团队用最近编写的遗留代码作为参考数据比较模型。Prior 表示，在这项特定测试中，Sonnet 5.5 的表现与 Fable 相当或更好。这说明应针对实际任务评估模型选择，不能默认最贵的选项必不可少。

接下来，Prior 希望加强审批关卡的执行，改进决策与模型选择，并更好地搜索和组织目前存放在 Markdown 中的上下文。他还希望录制并转写讨论，让操作者不必手工记录每一条信息。

更大的问题是如何在控制成本的同时，把这种方法推广到整个组织，并让人在恰当的环节作决定。Prior 希望智能体解决眼前的问题时，工程师能够选择下一座值得攀登的山。