AI编码代理的隐藏成本

Travis Montgomery

小改动却昂贵又缓慢：为什么AI编码Agent可能过度杀伤

一次一行错别字修复花费了数千个token。了解为什么AI编码Agent对于小改动而言可能过度杀伤，以及如何降低成本和开销。

由AI编码Agent（“Claude Code”）触发的自动化工作流运行，用于修复一个微不足道的拼写错误。该Agent创建了一个issue，发布了一个清单评论，然后创建了一个pull request。最终的“修复拼写错误”PR运行处理一行改动耗时约1分钟。

‍

最近，我们尝试使用一个基于AI的编码Agent来修复一个微小的错别字：将README中的“applicasion”改为“application”。我们发现问题与解决方案之间存在显著的不匹配。该Agent经历了一整个工作流程——列出issue、发布清单评论、创建新分支、提交更改、发起pull request，甚至还在思考是否需要代码审查。最终，它消耗了超过21,000个输入token（大约相当于阅读一本短篇小说），仅仅是为了完成这一行的编辑。

这是一个工具与任务不匹配的明显例子。日志显示该过程远远超出了任务范围。这并非对AI能力的否定；而是当前AI编码Agent工作方式的现实。即使对于最简单的更改，它们也带来了大量的开销。让我们深入探讨一下为什么会发生这种情况，以及其他人对这种现象有何观察。

‍

为什么小改动会有如此大的开销？

AI Agent对于小改动而言昂贵又缓慢有以下几个原因：

‍

• 上下文处理： 大型语言模型不像人类那样，甚至不像IDE的索引那样，能持续地理解整个代码库。每一个新的操作（prompt）都始于一个空白状态，除了你明确输入到其上下文窗口中的内容。现代模型可以有很大的上下文窗口（数十万或数百万个token），但“它们不维护对整个项目的持久性心智模型” [3]。Agent每次运行任务时都必须决定包含哪些信息。在我们的错别字修复案例中，Agent加载了issue描述、仓库信息等等，仅仅是为了确保它有足够的上下文。所有这些都计入token预算。如果你的代码库或任务涉及多个文件或步骤，Agent可能会在上下文内外不断地传输大量文本。一位开发者指出，如果代码紧密耦合或分散在多个文件中，AI必须在prompt中包含更多上下文，这会在时间和token方面带来隐性成本 [4] [3]。本质上，AI对狭窄范围“意识”越低，它就越会通过拉入额外细节进行过度准备。

‍

• 工具调用和多步骤工作流： 与人类的一次性编辑不同，Agent可能会将一个任务分解成许多子任务（就像我们的Agent所做的那样：评论、分支、编辑等）。每个子任务可能涉及调用工具或发出额外的LLM prompt。Hacker News上的一位评论者很好地总结了这一点：“让LLM一直使用工具来解决问题是昂贵且缓慢的。” [5]。每个步骤都有开销。Agent必须编写一个prompt，可能会重新加载上下文，等待响应，等等。在通常的琐碎修复中，开发者只需输入更改即可。然而，AI却将其视为一个需要通过自动化工作流完全解决的issue，从而在每个步骤中产生开销。如果一个Agent为了完成一行更改而发出五六个prompt或工具调用，这本身就比一次直接编辑更慢、更昂贵。

‍

• 缺乏实用性跳过： 经验丰富的开发者或代码审查员懂得在适当时候跳过形式主义。例如，我们不会为了文档中一个单词的错别字修复而提交Jira工单、创建完整分支并运行CI。我们很可能会直接提交。AI Agent缺乏人类判断力，尽职尽责地遵循其通用操作手册：它创建了一个issue，发布了一个清单，并试图对该PR运行代码审查流程。它做事彻底，但在任务的适当上下文方面却不够智能。在我们的运行中，Agent自身的逻辑最终标记出该更改是微不足道的，不需要审查，但仅在花费了时间和token得出这个结论之后。这凸显了当前的一个局限性：如果没有具体的指示，Agent并非总能跳过不必要的步骤。

‍

你可以在这里看到这个机器人做了多少事情，仅仅是为了决定一个README更改不需要代码审查。

‍

• 保守推理： 大型模型通常倾向于谨慎和完整性。它们可能会重复检查工作，生成冗长的解释，或者处理在实践中不适用于微不足道更改的边缘情况。在一个社区示例中，一位开发者指出，使用LLM进行编码可能导致“过度复杂化更改”或添加不必要的步骤 [6]。AI本身并不知道更改很小或风险很低；它操作时仿佛应该尽可能小心和全面。这可能意味着额外的验证轮次或文档，而这些是人类不会为错别字而做的。所有这些都会增加延迟和token使用量。

‍

这些因素导致的结果是，将AI Agent用于非常小的任务可能不切实际或无法扩展。它有效，但效率低下。我们的内部试验生动地证明了这种低效率：运行时间数分钟，消耗数万个token，才能完成一个人用编辑器30秒就能完成的工作。

‍

开发者正在学习的AI Agent成本知识

我们的经验并非孤立的案例。AI编码助手的早期使用者已经注意到相同的模式。许多人分享了关于这些工具何时表现出色、何时力不从心的坦诚反馈。一个共同的主题是：如果未设置正确的工具和范围，AI可能会带来比其消除的更多的开销，尤其是在琐碎任务上。

例如，一位程序员讲述了花费数小时指导LLM编写代码，最终结果却令人沮丧，他总结道“所有这些心智开销比我直接坐下来写代码还要糟糕” [7]。对于任何曾与在小修复上屡次偏离重点的AI纠缠过的人来说，这种感受会很熟悉。存在一个阈值，即解释、重新prompt和验证AI输出所花费的时间超过了手动操作所需的时间。小的bug修复或调整通常低于这个阈值。

另有指出，LLM在某些方面（解释代码、勾勒解决方案）可能出奇地擅长，但却难以高效地生成正确的细小编辑。一位Reddit用户认为，如果没有好的支持工具，“你经常会在简单的bug上长时间陷入困境……通常，prompt和检查的心智体操比修复本身更糟糕”。在我们的案例中，指示Agent修复一个简单的错别字，然后验证其所有程序步骤，远比直接修复复杂得多。

另一个观点来自那些专业构建和使用多步骤编码Agent的人。AI驱动开发的早期先驱Greg Ceccarelli指出，“Agent的每一次轮次都可能需要评论或新的提交。如果管理不当，开销可能巨大。” [8]。换句话说，Agent每多一个循环（这里添加一个评论，那里进行一次提交），都是造成冗余的机会。如果我们不简化Agent的工作流程，它就会做很多不必要的工作，因为它不凭直觉知道哪些步骤是必要的，哪些是过度杀伤的。

好消息是，这些痛点正在促成最佳实践。开发者正在学习何时不使用AI这把重锤。Allen Pike的一篇富有启发性的文章描述了围绕最大、“最智能”模型的最初炒作是如何消退的，因为它们“最终对于日常编码来说太昂贵和缓慢，不值得投入” [9]。许多人发现，对于日常开发而言，API调用和时间成本并不能证明其便利性是合理的，特别是对于直接的任务。Pike的解决方案是将真正强大（且昂贵）的模型留给真正复杂的问题，其余则使用更便宜或不使用AI。他甚至尝试在一段时间内每月花费1000美元在一个高级模型上，发现这对于困难、高影响力的编码来说是合理的，但他仍然建议不要在琐事上浪费昂贵的模型周期 [10] [11]。

关键是，他强调对确定性问题使用确定性工具：“将错误从运行时→测试时→构建时转移，让每个人都更高效。更好的是，使用linter或formatter确定性地修复问题。让你昂贵的LLM和人类专注于那些‘软’的部分。” [11]。文档中的错别字正是非“软”问题的定义。它直接、确定，并且很容易被拼写检查器捕获。这样的任务需要一个自动化脚本或快速手动编辑，而不是豪华的AI处理。

其他人也回应了这一点：如果一个LLM驱动的Agent发现自己反复进行同一种小修复，那么最好在LLM之外自动化该模式。在关于编码Agent循环的讨论中，一位评论者这样说：如果你注意到一个AI Agent频繁调用一系列工具来解决一个重复出现的问题，你应该将该序列提取到一个普通函数或脚本中，并在此情况下“完全绕过LLM” [5]。本质上，就是缓存解决方案，这样AI就无需每次都重新发明轮子。这种方法减少了冗余的prompt调用，节省了时间和金钱。

所有这些社区见解都强调了一个关键点：AI编码助手并非万灵药，它们在琐碎任务上可能会引入显著的开销。 意识到这一点是智能使用它们的第一步。

‍

成本因素：Token和美元的累积

当然，在将AI用于开发时，存在显著的财务成本需要考虑。大多数高级模型（OpenAI的GPT-5.2、Anthropic的Claude等）按token或按请求收费。每次API调用仅需几美分似乎微不足道，但这些调用会迅速增加，尤其当AI在自动化流程中处理大量小任务时。

我们的拼写修复实验只花费了几毛钱，但想象一下，如果规模化或应用于更大的代码库。不难看出，当AI被错误应用时，成本会如何飙升。一个极端（但具有启发性）的例子：OpenAI的GPT-3.5定价一度约为每750个单词0.002美元。一位DoorDash工程师计算，如果他们将其应用于每天100亿次预测（DoorDash的规模），API费用将达到每天2000万美元 [17]。这是一个极端情况，但它强调了每次调用的成本是如何在大量使用中累积的。即使在较小的规模上，公司也报告了巨大的开支：一家物流公司用一个较小的7B参数模型替换了由GPT-4驱动的解决方案，其每次查询成本从约0.008美元降至约0.0006美元，每月节省约70,000美元 [18]。关键的洞察是，更大的模型更昂贵（在API费用和所需基础设施方面），因此你希望避免为更简单的方法可以处理的琐碎工作支付这些费用。

成本的一个主要因素是我们讨论过的token使用开销。更长的prompt、更多的上下文以及多次来回交互都会消耗token，而这些token是需要付费的。如果其中80%的token是“开销”（正如一份报告所说，这很常见），那么你80%的钱也花在了开销上。例如，我们的Claude Agent使用了大约23,000个token来修复错别字。如果我们根据OpenAI的定价（大型模型的输入每1K token约0.016美元）估算Claude的定价，那么这次错别字修复仅token费用就花费了大约0.37美元。我们实际测得修复花费了约0.23美元，审查步骤花费了0.09美元，这与估算范围一致。再次强调，单独看是几分钱，但重要的是原则：为人类几乎免费（且更快）就能完成的事情支付云计算费用。在许多这样的微任务中，或者在一个持续运行的Agent中，这些几分钱会累积成实实在在的美元。

还需要考虑计算资源和能源。为一个小任务运行一个大模型可能构成巨大的过度杀伤。更小、更高效的模型或解决方案通常能以一小部分计算资源达到相同的结果。这就是为什么AI从业者提倡模型蒸馏和多模型架构等技术。例如，一种策略是将简单请求路由到小型模型，而仅将大型模型用于复杂查询 [19]。通过这样做，公司报告称可以在保持性能的同时将LLM成本削减80-90% [20]。在编码环境中：你可以使用轻量级代码分析来进行直接的linting或格式化更改，而将大型LLM留到真正需要对代码进行深度推理时使用。底线是效率很重要。如果你不会为了修复一个错别字而支付高级工程师5小时的工作费，你可能也不想支付一个5000亿参数模型的5分钟时间。

‍

智能选择AI工具的策略

那么，我们如何才能两全其美呢？从我们的研究和经验中得出了一些策略：

‍

• 为任务选择正确的工具： 在炒作中，这个原则经常被忽视。并非每个编码问题都需要AI解决方案。对于真正琐碎的修复（例如重命名变量、修正拼写、小型重构），最快的方法可能是手动完成或依赖基本的IDE功能。将ChatGPT的咨询留给你真正陷入困境或处理复杂问题时使用。正如一位专家简洁地说，“知道何时使用工具是学习过程的一部分” [14]。反过来也一样：当你确实面临一个棘手的问题时，不要害怕使用AI，因为它能为你节省时间。简而言之，运用人类直觉来决定AI对每个任务来说是过度杀伤还是福音。

‍

• 简单任务优先选用更简单/更小的模型： 如果你有一个必须定期处理小改动的自动化流程（例如，一个管理次要代码卫生任务的AI运维机器人），可以考虑使用更小的专用模型或基于规则的自动化。研究表明，经过精心微调的小型模型在处理特定任务方面，几乎可以与大型模型一样好，而成本仅为其一小部分 [21] [18]。例如，一个38亿参数的代码模型在bug修复基准测试中几乎与OpenAI的120亿参数Codex模型持平 [22]。这意味着你并非总是需要GPT-4级别的能力来修复bug。通过采用分层方法（小任务使用小型模型或传统脚本，大任务使用大型模型），你可以将繁重的计算资源保留给真正值得投入的地方 [19]。在编码环境中：你可以使用轻量级代码分析来进行直接的linting或格式化更改，而将大型LLM留到真正需要对代码进行深度推理时使用。底线是效率很重要。

‍

• 优化你的AI prompt和工作流： 当你使用大型模型时，应尽量减少开销。prompt压缩、上下文的语义分块以及结果缓存等技术可以显著减少token使用量 [23] [20]。在实践中，这意味着：如果你只需要修复一个函数，就不要将整个代码库喂给AI；不要让它重复已经完成的工作（缓存中间结果）；并保持prompt集中和简洁。许多团队报告称，通过这些优化，他们在不损失质量的情况下将LLM成本削减了80%以上 [20]。这不仅节省了金钱，还加快了响应速度（因为更短的prompt意味着更快的处理）。本质上，就是削减AI参与的冗余部分。

‍

• 迭代的、人机协作流程： 我们在“一击即中”方法（给AI一个任务，它消失后带着完整的解决方案回来）中发现的一个陷阱是，它可能效率低下，有时会产生臃肿的结果。专家建议，对于代码而言，更好的方法是迭代循环。例如，与其要求AI一次性对代码库应用10处更改（这可能耗时很长并返回错误），不如一步步或小批量地进行更改，并随时检查。Austin Henley在测试Copilot Workspace后指出，迭代的、交互式流程将是理想的，即AI和开发者来回进行增量更改。这样，AI就不会在可能不需要的部分浪费精力，人类也能快速纠正方向。把它想象成结对编程：你不会让一个初级开发者消失一天来为一行修复重写你的应用程序；你会与他们密切合作并指导他们。同样，这也适用于AI助手。在小改动上保持人机协作进行验证和指导，可以防止AI“过度”解决问题。

‍

• 监控和测量： 最后，为了避免AI过度杀伤，你需要注意它何时发生。密切关注AI任务耗时多久以及成本多少。如果你看到一个自动化任务处理一件琐碎的事情需要5分钟，请调查原因。很多时候，这可能是prompt设计效率低下或流程中存在不必要的步骤。通过测量token使用量、延迟和成功率，你可以确定何处可以采用更轻量级的方法替代。在我们的案例研究中，指标清楚地表明，我们不应该将完整的AI流水线用于简单的错别字。一旦你意识到问题，实现一些基本的条件逻辑（例如，“如果差异只有一行，也许只需应用它而无需调用整个Agent”）是一个直接的修复方法。本质上，将你的AI使用视为系统中的任何其他部分：对其进行性能分析、优化，并且不要假设更多的AI总是更好。

‍

结论

AI编码工具为正确的问题提供了巨大的生产力优势。它们可以草拟整个模块，重构遗留代码，并以我们几年前无法想象的方式提升我们的生产力。然而，正如我们所看到的，将一个大型AI模型应用于一个小问题可能会适得其反，导致更慢的结果、浪费的计算资源以及为微不足道的利益付出更高的成本。好消息是，开发者社区的意识正在增强。我们正在学习如何更细致地使用这些工具，以更智能的方式将人类判断与AI辅助结合起来。

归根结底，目标是使我们的工作流程既高效又有效。这意味着在AI真正能带来价值的地方使用它，而不是出于习惯或炒作。如果一项任务手动编码只需一分钟，你很可能直接完成它会比在AI工作流程中花费五分钟更好。另一方面，如果你面临复杂的算法或不熟悉的领域，那可能是请你的AI结对程序员帮忙的最佳时机。通过平衡这些方法，团队可以避免“为AI而AI”的陷阱，并最大限度地提高其工具投资的回报。

‍

构建安全的开发工作流

在Cyfrin，我们通过安全优先的视角评估开发工具，包括AI助手。对于在web3中构建的团队来说，理解你的工具的优势和局限性对于维护代码质量和安全标准至关重要。

无论你是将AI集成到你的开发工作流程中，还是评估其对你的安全实践的影响，我们的团队都可以帮助你做出明智的决策。

联系Cyfrin与团队成员讨论你的开发和安全需求。

‍

‍

来源：

1. ThamizhElango Natarajan，《为什么紧密耦合的代码使AI编码助手昂贵且缓慢》，Medium（2025年12月30日）——讨论了大型上下文窗口和代码架构如何影响AI代码助手的效率 [4] [3]。
2. Allen Pike，《在一个编码Agent上花费过多金钱》，allenpike.com（2025年6月30日）——描述了使用高级编码模型的实际成本以及最大化价值的最佳实践（例如，对琐碎修复使用linter） [9] [11]。
3. Robin Linacre，《LLM对我生产力的新兴影响》，robinlinacre.com（2024年10月）——预测Agentic AI行为（例如从issue编写PR）最初将因为涉及大量prompt而“相对昂贵且缓慢” [14]。
4. Greg Ceccarelli，《超越代码中心：Agent代码，但清晰规范的问题依然存在》，gregceccarelli.com（2025年）——指出，如果没有结构，“Agent的每次轮次……都可能需要新的提交”，并且开销“如果管理不当，可能巨大。” [8]。
5. Reddit – r/ChatGPTCoding 帖子《如果没有好的工具，LLM在纯代码生成方面是糟糕的》——开发者讨论了对LLM在编码任务上表现的沮丧。一条评论指出，在处理简单问题时，“所有这些心智开销比我直接写代码还要糟糕” [7]。
6. Hacker News – 《LLM Agent循环的非凡效率……》（用户deadbabe的评论）——认为持续使用LLM进行重复的基于工具的任务是“昂贵且缓慢的”，建议用直接的代码解决方案替换频繁的多步骤模式 [5]。
7. 内部实验日志（2026年）： Claude Code Agent对一个微不足道的文本修复运行——演示了约21k的token使用量和多步骤工作流，仅为了一词更改。Agent本身得出结论，该更改是“直接、非功能性的”单行代码，不需要审查，这凸显了不成比例的努力。

‍

[3] [4] Why Tightly Coupled Code Makes AI Coding Assistants Expensive and Slow | by ThamizhElango Natarajan | Dec, 2025 | Medium

https://thamizhelango.medium.com/why-tightly-coupled-code-makes-ai-coding-assistants-expensive-and-slow-06ab5399169c

[5] The unreasonable effectiveness of an LLM agent loop with tool use | Hacker News

https://news.ycombinator.com/item?id=43998472

[6] [9] [10] [11] Spending Too Much Money on a Coding Agent - Allen Pike

https://allenpike.com/2025/coding-agents/

[7] Without good tooling around them, LLMs are utterly abysmal for pure code generation and I'm not sure why we keep pretending otherwise : r/ChatGPTCoding

https://www.reddit.com/r/ChatGPTCoding/comments/1dysrye/without_good_tooling_around_them_llms_are_utterly/

[8] Beyond Code-Centric: Agents Code but the Problem of Clear Specification Remains

https://www.gregceccarelli.com/writing/beyond-code-centric

[14] The emerging impact of LLMs on my productivity

https://www.robinlinacre.com/two_years_of_llms/

[17] [19] [20] [23] 7 Proven Strategies to Cut Your LLM Costs (Without Killing Performance) | by Rohit Pandey | Medium

https://learnblockchain.cn/article/24394

[18] [21] [22] Is your LLM overkill? - by Ben Lorica 罗瑞卡 - Gradient Flow

https://learnblockchain.cn/article/24392

[25] The coming explosion in QA testing

https://learnblockchain.cn/article/24391

‍

• 原文链接： cyfrin.io/blog/expensive...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～