AI 正在接手软件开发中最麻烦的部分:长期维护

很多程序失效时，并不会给工程师留下一个醒目的报错。一段每天采集商品信息的脚本照常启动，日志没有异常，输出文件也能打开。直到几周后，有人发现报表里的商品数量越来越少，才意识到网站修改了分页方式，程序一直停留在第一页。另一套程序可能仍然抓得到“价格”，只是页面改版后，它抓到的已经是会员价，而不是原来的公开售价。字段没有消失，数据格式也完全合法，错误就这样安静地流进了下游系统。这类程序并不难写，却很难长期照看。网页会改版，接口会调整，访问规则会变化。工程师写完第一版代码以后，还要不断检查运行状态、定位故障、修改逻辑、重新测试和部署。

AI Coding正在让第一版代码越来越便宜。Firecrawl最近推出的Web数据Agent Prometheus，则把目标放到了代码交付之后：程序上线以后，能不能继续由Agent照看？

第一次运行成功，只是维护的起点

过去做一个定制化的网页数据项目，工程师通常要先研究目标网站，确认数据藏在哪里，再选择采集方式、编写代码、测试结果，最后把任务部署到服务器上。

生成式AI压缩了其中最容易标准化的一段。用户描述需要哪些字段，模型可以快速生成选择器、请求逻辑和数据结构。一段原本需要几个小时才能完成的采集脚本，现在可能很快就能得到可运行的版本。

但能够运行一次，与能够连续运行几个月，属于两种不同的交付。第一版代码面对的是网站此刻的样子。只要它能完成一次采集，开发任务似乎就结束了。上线后的程序面对的却是不断变化的外部环境，每一次改版、网络波动和访问限制，都可能让原来的实现逐渐偏离目标。维护成本也往往来自这种时间差。故障发生时，原来的开发者可能已经在处理其他项目。他需要重新打开代码，恢复几个月前的上下文，读日志、检查页面，再判断问题究竟来自临时异常，还是整套采集逻辑已经过期。AI可以让人更快地部署第一版程序，却没有自动消除这些后续工作。代码生成得越多，需要长期照看的程序可能也越多。

Prometheus想继续照看已经写出来的代码

Firecrawl将Prometheus称为面向Web数据的“Forward Deployed Agent”。这个名称来自一种常见的工程服务：客户知道自己需要什么数据，却不知道怎样稳定获得，于是工程师进入具体项目，分析网站、测试方案并搭建采集流程。Prometheus试图把这部分工作变成一个可以反复调用的Agent。根据Firecrawl在Product Hunt发布页上的介绍，用户可以直接描述需要哪些网页数据。Prometheus会在真实网站上尝试采集方法，生成基于Firecrawl SDK的TypeScript代码，运行并验证代码，然后交付脚本和样例数据。

到这里，它仍然很像一个面向网页采集的AI Coding工具。区别出现在交付以后：用户可以拿走代码自行运行，也可以把任务留给Firecrawl托管。按照目前的产品设想，Prometheus会定时执行采集任务，并在页面变化导致流程失效时尝试修复。

这意味着Agent参与的不再只是“把需求变成代码”，而是一个更长的循环：观察运行结果，发现异常，重新检查网站，修改代码，再通过测试恢复任务。

Firecrawl也明确将Prometheus称为实验性产品。托管后的自动维护目前更多是一项产品承诺，还没有经过长期运行和成熟服务等级协议的充分验证。它现在提供的是一个方向信号，而不是已经被证明的维护方案。

这个方向仍然值得关注。Prometheus想交付的已经不只是一段采集代码，而是这段代码在环境变化以后，仍能继续产生所需数据。

软件开始承担原本属于工程服务的责任

传统开发工具通常只提供能力。API允许工程师获取数据，SDK帮助他们调用服务，云平台提供运行环境。工具需要保持可用，但具体任务怎样实现、程序失效后如何修复，仍由使用者自己的工程团队负责。Prometheus尝试把这条责任边界往前推了一步。用户描述需要什么，系统负责选择实现方法、生成程序、验证结果并安排运行。环境变化以后，它还要继续调整原来的实现。产品交付的重点由“这里有一个可以使用的工具”，逐渐转向“你需要的结果会持续送到指定位置”。这有些像卖钻头与负责把孔打好。卖钻头时，厂商只需要保证工具能够工作；负责打孔以后，墙体材质、钻头磨损和现场变化都会成为服务的一部分。

过去，特殊的数据需求通常需要工程师长期参与。他不仅要写代码，还要理解客户所说的“商品价格”具体指什么，网页变化后哪些差异可以接受，哪些变化已经破坏了原来的业务目标。

Prometheus试图把这名随时待命的工程师装进产品。它所产品化的并非某一次代码生成，而是一段包含实验、实现、运行和维护的持续服务。

类似变化可能出现在更多软件领域。部署一个自动化程序只是开始，长期运行还需要有人检查状态、处理例外，并在外部条件变化后调整实现。Agent如果能够接手这段工作，软件出售的就不再只是静态功能，还包括对功能持续有效的照看。

最危险的故障，没有阻止程序运行

维护型Agent面临的困难，也正在这里出现。页面结构变化导致选择器失效，程序直接报错，这类问题相对容易发现。任务停止了，系统至少知道需要检查代码。更危险的是静默错误。程序仍然运行，数据也能通过格式检查，只是内容已经不完整或不再符合原来的含义。

Prometheus发布后，Product Hunt评论区很快有人问到这个问题：系统如何判断页面发生了需要重新生成代码的结构变化，而不是一次临时异常？如果托管任务当天中断，维护承诺又能提供怎样的恢复时效？

Firecrawl团队表示，系统会参考数据的历史差异判断变化；对于服务等级协议，他们的回答则很克制：Prometheus目前仍是一项实验，未来可能再提供SLA。这两条回答碰到了长期维护的核心。Agent需要发现程序是否还在运行，也需要判断运行结果是否仍然正确。

假设一个任务每天采集一千件商品，今天只返回了三百件。系统不能看到任务成功结束，就认定工作已经完成。它还需要比较历史数据量、字段缺失率和数值范围，判断变化来自商品下架、页面改版，还是采集流程只跑完了一部分。

更复杂的情况无法只靠代码测试解决。页面上的“销量”可能从累计销量变成月销量，字段名称和格式都没有变化，业务含义却已经改变。Agent可以修复程序，却未必能仅凭技术信号确认数据仍然值得信任。

因此，长期维护不只是自动修改代码。它还需要一套持续更新的“正常标准”：什么数据必须存在，数量通常处于什么范围，哪些变化可以接受，什么情况必须交给人重新判断。

程序有没有报错，是运行问题；结果是否还能支撑原来的用途，是验证问题。后者往往更难自动化。

写代码之后，还有更长的时间

Prometheus现在仍是一个早期产品信号。它能否稳定处理复杂网站、登录限制和难以察觉的数据变化，需要更长时间和更多实际任务验证。

但它展示出的变化已经出现了：AI正在从代码交付之前，进入代码交付之后的时间。

AI Coding最先降低的是生成成本，让需求更快变成程序。当这部分逐渐便宜，监测、验证、异常恢复和长期维护就会显得更昂贵。以前由工程师默默承担的后续工作，也开始成为Agent产品试图接手的对象。

这可能改变人们为软件付费的方式。过去，我们主要为某项功能是否存在付费。以后，越来越多产品还需要回答：外部环境变化以后，这项功能是否仍然有效；程序没有报错时，结果是否依然可信。

软件第一次正常运行，只证明它曾经工作过。

AI编程真正成熟的标志，也许不是它一天能写多少代码，而是几个月以后，那些代码是否仍然在正确地工作。