Navan 最近一次迁移涉及 8 个应用程序和 15 个库，约一周即告完成，开发工作全程未受冻结。而在两年前，一次规模相当的迁移耗时一个多月，还曾因一次失败的合并导致 master 分支被锁定了整整一天。带来这一转变的，正是 Cursor 的云端智能体：Navan 只需规划一次迁移，即可在自有的自托管机器上对 8 个应用程序并行执行，而不必再由一名工程师独自逐一推进。
涉及 8 个应用的迁移，从一个月缩短到一周
两年前，资深软件工程师 Rahul Popuri 将 Navan 的代码库迁移到新的 Spring 版本，花了一个多月的时间。在此期间，不完整的推送和回滚导致 master 分支被锁定了一整天。锁定解除后，影响也并未就此结束：几天后，其他工程师仍在忙着合入积压的更改。而更大的代价还不是锁定本身，而是一名工程师整整一个月的时间都耗在了迁移上，没能用来交付功能或修复缺陷。
Navan 最近一次迁移到 Spring Boot 4，只用了大约一周就完成了，对进行中的开发工作影响也更小。借助 Cursor，Rahul 提前规划好升级方案，再将每个组件委派给运行在 Navan 自托管机器上的云端智能体，让 8 个应用和 15 个库同时迁移，而不是逐个推进。这些智能体使用 Navan 的内部工具体系，并在同一批机器上启动浏览器，逐一点击各个流程来验证自己的更改。
过去，一次错误的合并就可能让各条工作线全部停摆。这一次，我同时推进八个应用的迁移，还把对进行中开发工作的影响降到了最低。
Rahul 不再只是盯着单个任务运行，而是同时监控多个智能体升级不同的应用。他表示，这种规模的并行工作，哪怕在几个月前都还无法实现。
云端智能体承担真实工作负载
Rahul 几乎把所有工作都迁移到了 Cursor 的云端智能体上。GitHub 相关工作运行在 Cursor 托管的基础设施上；面向 Snowflake 和 Slack 的内部 MCP 则运行在 Navan 自己的自托管机器上，智能体还能在这些机器上启动浏览器，自行验证所做的更改。自动化、技能和记忆都基于这套设置运行，因此评估循环和迁移任务可以异步持续推进，无需有人在旁监控。
此后，这一模式早已不止服务于一名工程师：Navan 目前约有 200 人在积极使用 Cursor 的云端智能体，较 2026 年 4 月增长了 10 倍。
在使用 Cursor 之前，Navan 的工程师曾围绕原先的编程智能体搭建了一套像样的基础设施，但它需要有人始终守在一台桌面电脑前，并一直保持会话打开。这样一来，Navan 所需的并行、异步工作便无从实现。
产品团队同样受益
在产品侧，负责报销和账单业务的资深软件工程师 Elton Yang 只需一段简单的描述，就能为报销和账单工作流构建新的智能体。Cursor 会遵循团队现有的设计模式，并自行编写智能体的提示词，因此当天就能开始测试，而不必先花上几个小时手动编写初始提示词。
我们现在连智能体的提示词都不用自己写了。Cursor 会沿用我们之前的设计，当天就能让智能体跑起来。
这一转变扩大了小团队能承担的工作范围。在许多工程师离开 Navan 专职的 AI 智能体团队之后，一名工程师独自接手了以前需要 2 到 3 名工程师花费多个迭代才能完成的功能开发。最典型的例子之一是手动绑定银行账户：这名工程师用 React 重写了一个 Angular 表单，并搭建了与之对接的后端，在任务需要时从纯后端开发转向了全栈开发。这条由个人独立负责的工作线始终聚焦于新功能开发，而没有沦为单纯的维护工作。
Cursor 也改变了替同事顶班的方式。一位同事休假期间，Elton 不得不接手两个他并不熟悉的代码库，Cursor 替他完成了排查工作：在 Elton 打开任何一个文件之前，它就已拉取日志和数据库记录，并把问题梳理清楚。
这两个代码库我都不太熟。我说：'问题是这样的，帮我弄清楚。'它拉取了日志和数据库，带着我把问题过了一遍，就好像我已经在那个代码仓库里待了好几个月一样。
这在两个代码库上节省了大约两天的熟悉时间，也免去了从零开始啃代码的压力。
审查仍然由人来把关。Elton 把智能体当作结对编程的伙伴，而不是无所不知的编程神谕：他会在智能体运行时观察其推理过程，一旦发现错误的假设就立即纠正。代码生成后，会和其他代码一样经过人工与 AI 审查、测试以及暂存流程，复杂的更改会先在暂存环境中验证，然后才上线到生产环境。智能体负责规划和执行工作，但由工程师做出判断，并对最终合并负责。
如果你正在进行迁移，或推进过去需要整个团队投入并锁定代码库才能完成的并行工作线，欢迎联系我们开始试用 Cursor。