年终拆解：爆火的AI Coding Agent是什么？有哪些“坑”？

如今的代码智能体（coding agents），可以连续数小时参与软件项目开发，在人类监督下完成应用程序编写、运行测试及修复 Bug 等工作。

然而，它们并不是万能的，有时反而会增加软件项目的复杂度，而并没有简化流程。

因此，理解其底层工作机制，有助于开发者明确何时（以及是否）应当使用这些工具，并有效规避常见陷阱。

我们先从基础讲起，每一个 AI coding agents 都基于大语言模型（LLM）构建，后者是一种在海量文本数据（包括大量编程代码）上训练而成的神经网络。它本质上是一台模式匹配机器，通过提示词来“提取”其在训练过程中所见数据的压缩统计表征，将该模式的一个看似合理的延续作为输出结果。在这一提取过程中，LLM 能够在不同领域与概念之间进行插值，运用得当时，它能产生有用的逻辑推理；运用不当时，则会导致虚构错误。

随后，这些基础模型会通过一系列技术进一步优化，例如在精选示例上进行微调，以及引入基于人类反馈的强化学习（RLHF）。这些技术旨在塑造模型的行为，使其能遵循指令、调用工具，并产出更具实用价值的结果。

图 | Claude Code 命令行界面截图。（来源：Anthropic）

近年来，AI 研究人员一直在探究 LLM 的能力缺陷，并尝试寻找相应的规避与改进方法。近期的一项创新是模拟推理模型，它以推理式文本的形式生成上下文，即对提示词进行扩展，从而帮助模型更精准地锁定答案，产出更准确的结果。另一项创新是被称为“智能体”的应用范式，它将多个 LLM 串联起来，使其能同步协作完成任务并对产出结果进行评估。

如何构建coding agents？

从这个意义上讲，每个 AI coding agents 本质上都是一个与多个 LLM 协同工作的程序封装器。通常，系统中会有一个监督型 LLM 负责解析用户的任务指令，并将其分配给多个并行工作的 LLM，后者能够调用各种软件工具来执行具体操作。监督智能体可以随时中断下层任务，并通过评估子任务的结果来监测项目的整体进度。Anthropic 的工程文档将这种工作模式概括为：收集上下文（gather context）、采取行动（take action）、验证工作（verify work）、循环（repeat）。

当通过命令行界面（CLI）在本地运行时，用户会在特定条件下授予智能体相应权限，使其能够在本地计算上写入文件（包括代码或其他所需内容）、执行探索性命令（例如使用 “ls” 列出目录中的文件）、抓取网站内容（通常使用 “curl”）、下载软件，或将文件上传至远程服务器。由于这种方式具有极大的灵活性，同时也伴随着潜在风险，因此在使用时需要格外谨慎。

相比之下，当用户在 Web 智能体（如 Web 端的 Codex 或 Claude Code）中启动任务时，系统会分配一个沙箱化的云端容器，并预加载用户的代码仓库。在这个环境中，Codex 可以读取和编辑文件，运行各种命令，包括测试框架和代码检查工具，并独立执行代码。Anthropic 的 Claude Code 则是利用操作系统层面的机制来构建文件系统和网络的边界，使智能体能够在这些边界内更自由地开展工作。

上下文困境

可以这么说，每个 LLM 都有其短期记忆，这限制了它在“遗忘”前所能处理的数据总量。这种限制被称为“上下文”。每当你向监督智能体提交一次回复时，实际上是在修订一个巨大的提示词，其中包含了截至目前的所有对话历史，以及生成的所有代码，还有模型用于深入“思考”问题的模拟推理 token，随后 AI 模型会评估这一完整提示词并生成输出。这是一个计算成本极其昂贵的过程，且成本随提示词规模呈二次方级增长，因为 LLM 需要将提示词中的每一个 token（数据块）与所有其他 token 进行逐一处理和比对。

Anthropic 的工程团队将上下文视为一种有限且边际收益递减的资源。相关研究揭示了一种称为“上下文腐化”（context rot）的现象：随着上下文窗口中 token 数量的增加，模型准确回忆信息的能力反而会下降。每新增一个 token，都会消耗文档中所称的“注意力预算”。

这种上下文限制自然也约束了 LLM 在单次处理过程中能够覆盖的代码库规模。如果向模型输入大量的代码文件，而这些文件在每次提交新响应时都需要被 LLM 重新评估，就会非常迅速地消耗掉 token 配额或使用额度。

业内技巧

为了突破这些限制，coding agents 开发者采用了多种技巧。例如，对 AI 模型进行微调，使其在编写代码时将部分任务“外包”给其他软件工具。具体来说，模型可能会编写 Python 脚本，从图像或文件中提取所需数据，而不是将整个文件直接送入 LLM 进行处理，从而节省 token 并降低产生不准确结果的风险。

Anthropic 的文档指出，Claude Code 在对大规模数据库进行复杂数据分析时同样采用了这一思路。它会编写有针对性的查询语句，并结合使用诸如 “head”“tail” 等 Bash 命令，在不将完整数据对象加载进上下文的情况下，对海量数据进行分析。

（从某种意义上说，这些 AI 智能体是在引导之下但具备一定自主性的工具调用程序，它们是对 2023 年初首次出现的概念的一次重大延伸。）

智能体领域的另一项重大突破源于动态上下文管理。虽然各家闭源编程模型并未完全公开其实现方式，但智能体可以通过多种手段达成这一目标，而我们已知其中最核心的技术就是上下文压缩。

图 | OpenAI Codex 的命令行版本在 macOS 终端窗口中的运行界面。（来源：Benj Edwards）

当编程 LLM 接近其上下文上限时，这项技术会通过对上下文历史进行总结来实现压缩，虽然这一过程中不可避免地会丢失部分细节，但能将冗长的历史精简为关键要点。Anthropic 的文档将这种“压缩”描述为一种高保真的上下文蒸馏过程：在丢弃冗余工具输出的同时，尽量保留诸如架构决策、未修复的 Bug 等核心信息。

这也意味着，每当发生一次上下文压缩，AI coding agents 都会在一定程度上“遗忘”此前正在进行的大量细节；但与早期基于 LLM 的系统不同的是，它们并不会对已发生的事情一无所知，而是能够通过重新阅读现有代码、文件中留下的文字说明、变更日志等内容，迅速重新建立对项目状态的认知。

Anthropic 的文档建议使用 CLAUDE.md 文件来记录常用的 Bash 命令、核心文件、工具函数、代码风格规范以及测试说明等内容。AGENTS.md，如今已成为多家公司共同采用的标准，则是另一种在上下文刷新之间引导智能体行为的有效方式。这类文件相当于外部笔记，使智能体能够在处理复杂任务时持续跟踪进展，并保留那些原本可能因上下文压缩而丢失的关键信息。

对于需要长时间持续工作的任务，两家公司都采用了多智能体架构。根据 Anthropic 的研究文档，其系统使用一种被称为“编排者-执行者模式”的设计，由一个主导智能体负责整体协调，同时将具体任务委派给多个并行运行的专业子智能体（subagents）。当用户提交查询后，主智能体会对其进行分析、制定策略，并生成多个子智能体，从不同维度同时展开探索。子智能体充当智能过滤器角色，只将相关信息返给主导智能体，而非完整的上下文内容。

然而，多智能体方法会迅速消耗 token。Anthropic 的文档指出，智能体在执行任务时通常消耗的 token 数量约为普通聊天交互的 4 倍，而多智能体系统的 token 消耗则可达到聊天场景的 15 倍。因此，从经济可行性的角度来看，这类系统只适用于那些价值足以覆盖额外成本的任务。

人类的最佳实践

尽管在某些编程群体里，使用这些智能体仍存在争议，但如果你选择用它们来编写项目，掌握良好的软件开发实践将有助于提前规避潜在问题。例如，了解版本控制、进行增量备份、一次只实现一个功能并在继续下一步之前对其进行测试，这些都是非常好的习惯。

人们所谓的“vibe coding”，即在完全不理解代码逻辑的情况下生成 AI 代码，显然不适合生产环境。在生产系统中部署并非由自己编写、也未充分理解的代码，本身就具有较高风险。它可能引入安全隐患或隐藏 bug，并逐步积累技术债，最终随着时间的推移产生滚雪球效应。

独立 AI 研究员 Simon Willison 近日指出，即便使用 coding agents，开发者依然承担着证明其代码有效的责任。“几乎任何人都可以通过提示词让 LLM 生成一份上千行的补丁，并将其提交进行代码审查，”Willison 写道，“这本身已经不再有价值。真正有价值的是贡献那些经过验证、确实可行的代码。”

事实上，人类的规划才是关键。Claude Code 的最佳实践文档针对复杂问题推荐了一套特定的工作流。首先，要求智能体阅读相关文件，并明确告知其先不要编写任何代码；其次，要求它制定一份计划。该文档警告称，如果没有这些调研和规划步骤，Claude 的输出往往会直接跳到编写代码这一步。

如果缺乏规划，LLM 有时会为了满足眼前目标而仓促给出走捷径的方案，但当项目规模扩展时，这些方案往往会出现问题。因此，对于可随时间演进、具备良好模块化特性的程序架构有一定认识，有助于引导 LLM 构建出更具长期稳定性的方案。

正如前文所述，这些智能体并非完美无缺，有些人甚至不愿使用它们。非营利研究机构 METR 在 2025 年 7 月发布的一项随机对照试验发现，经验丰富的开源开发者在使用 AI 工具时，完成任务所需的时间实际上增加了 19%，尽管他们主观上认为自己的工作效率更高。研究人员同时指出了一些限制因素：参与者对各自代码库极为熟悉（平均拥有 5 年经验、约 1500 次提交记录），所使用的仓库规模大且成熟，而实验中采用的模型（主要是通过 Cursor 调用的 Claude 3.5 和 3.7 Sonnet）也已被更新、更强的版本所取代。

新一代模型是否会产生不同的结果仍是一个悬而未决的问题，但这项研究表明，AI 编程工具并不一定能在所有情况下带来效率提升，尤其是对于那些已经非常熟悉自身代码库的开发者而言。

鉴于这些潜在风险，目前 coding agents 更理想的使用场景，可能是用于概念验证（proof of concept）演示以及内部工具的开发。尽管被称为“智能体”，但 AI 模型并不具备真正的能动性（agency），也无法像人类一样对错误承担责任，因此，人工监督始终是核心关键。

原文作者：Benj Edwards，Ars Technica高级人工智能记者，专注于生成式AI领域。

原文链接：

https://arstechnica.com/information-technology/2025/12/how-do-ai-coding-agents-work-we-look-under-the-hood/

整理：潇潇

如需转载或投稿，请直接在本文章评论区内留言。