返回资讯中心
外部精选
软件工程
#开发者实时流

开发者指出编码代理倾向自建代码导致维护成本上升

来源标题:Coding Agents Underestimate the Cost of Code They Own

开发者Ben Houston基于用Claude构建3D内容管理平台Land of Assets的经历指出,编码代理常把本可直接安装的库重新实现,使后续每次改动都要为这一决定付出维护代价。他将这类观察称为个人项目经验而非对照研究,并提出应衡量代理生成的代码在之后上百个任务中的变更成本。他还列举了编写与测试两方面的代价:生成代码越多,输出token和审查越多;自建抓取层还要自行负责重试、取消、竞态条件和缓存失效。

Hacker News 最新bhouston2026/11/5 · 今天15 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

你的编程 agent 刚刚重写了一个你本可以直接安装的库。从此之后,每一次改动都要为这个决定付出代价。

Ben Houston • 2026年11月5日 • 阅读时间 6 分钟

编程 agent 让写代码变得廉价。但它们也可能留给你远超任务所需的代码去维护。

在用 Claude 构建 Land of Assets(一个企业级 3D 内容管理平台)时,我反复不得不用成熟的库替换掉自定义实现:

这些是我项目中的观察,不是对照研究。但它们指向了一件值得衡量的事:在未来一百个任务中,agent 写出的代码改动起来要花多大代价?

依赖会带来显而易见的维护义务。自定义代码同样会带来维护义务,只不过它是一行几行地累积起来的,每一行当时看似乎都由当前任务证明了其合理性。

  1. 写它。生成的代码更多,通常意味着更多的输出 token 和更多的审查。用几次库调用替换手写的 fetch 状态管理,能立刻省下工夫。

  2. 测它。用库你仍然需要集成测试。但如果你自己写抓取层,你还要为重试、取消、竞态条件和缓存失效负责。你的测试面现在既包括产品,也包括这些底层管道。

  3. 重新理解它。熟悉的 API 能压缩含义。知道 useQuery 的 agent 往往能直接从调用处入手,再查文档。而自定义的 useFetchWithRetry 必须从它的实现和测试中去理解。当新的 agent 接手,或者某次改动挑战了最初的假设时,这份工作又得重来。上下文缓存能降低 token 账单,但它消除不了理解代码的需要。

  4. 扩展它的设计。一个成熟的库可能凝结了多年关于边界情况和 API 边界的决策。而初版实现往往只编码了一个界面的需求。第二个界面需要不同的东西,于是补丁开始了。下一个功能又继承了这些补丁。

廉价的生成降低了第一项成本。另外三项则在应用的生命周期中不断累积。用按量计费的 agent 时,其中一部分维护工作会直接出现在账单上。用包月访问时,它仍然消耗时间和上下文。

我不知道是什么导致 Claude 在我的项目中做出这些选择。我的工作假设是,有几种激励让自定义代码显得比实际更安全。

“遵循现有模式”可能有利于扩展手写的底层管道。“避免范围蔓延”可能让引入依赖看起来像是一个需要批准的架构决策,而再写一百行则感觉像是在完成任务。

包推荐还有一个真实的失败模式:模型会编造看似合理的名字。研究者已经记录了包幻觉及其供应链影响。对未经证实的包保持谨慎是合理的。但这并不能解决一个成熟实现是否优于自定义实现的问题。

评估设置也很重要。SWE-bench 在真实仓库的 issue 上衡量 agent。解决一个 issue 是有用的能力证据,但它不能告诉我们这个设计让接下来五十个 issue 变得更容易还是更难。

自定义实现可以通过今天的测试,同时制造明天的维护负担。一个终止于今天测试的评估永远看不到这份成本。

我可以把偏好的库写进 CLAUDE.md 或 AGENTS.md。当我已知答案时,这有用。

使用 agent 的一个理由是,它可能知道一个我从未遇到过的有用工具。如果我必须点名每一个库,那我既在提供需求,也在提供架构判断。

经验较少的开发者可能根本没有理由意识到他们的 agent 正在重建一个表单库。提供三个陌生的包未必能帮他们做决定。有用的行为是去调查、给出站得住脚的推荐,并简要解释权衡。

流行的库还提供了一套人和 agent 可以共享的词汇。贡献者无需重建一个私有框架就能认出查询或表单字段。白名单也许能减少安装摩擦,但它不会让 agent 一开始就想到合适的库。

我希望看到一个围绕反复改动一个应用的总成本构建的基准测试,让 agent 能拿到依赖决策。就叫它 LongHaul 吧。

研究已经触及这个问题的部分方面:

LongHaul 会把生命周期成本置于记分卡的中心。每个应用会收到大约一百个连续的改动请求:新功能、修订的假设、删除,以及迫使重构的改动。

两条赛道:从零构建一个应用,或者继承一个带有别扭设计决策的可运行应用。接管赛道类似于我做过的许多软件工作。

持续所有权:每个任务都从 agent 上一次的输出开始。保存检查点以供检查和复现,但不要重置到干净的参考实现。那会抹掉我们试图衡量的后果。

平等访问:给各次运行相同的包注册表快照和文档访问权限。包的选择应当可复现,一次失败的下载不应决定结果。

既记录用量也记录金额,这样定价变化就不会掩盖比较。正确性必须是任何效率主张的前提:一个半途放弃的 agent 不该因为用了更少的 token 而获胜。

代码指标会作为辅助证据。短代码可能不可读,低圈复杂度可能把糟糕的设计藏在几十个小函数后面。决定性的衡量标准是:随着改动累积,应用能否以合理的成本持续满足需求。

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →