Agentic Coding的定义、能力谱系与边界

第2章　Agentic Coding的定义、能力谱系与边界

本章进一步追问一个更基础的问题：究竟什么才算智能体（agent）。上一章从行动能力出发，将智能体与自动补全、对话式助手区分开来。本章将在此基础上进一步明确智能体的概念边界，讨论一个系统需要具备哪些基本特征，才能被称为智能体，并进一步解释为什么Anthropic将工作流（workflow）与智能体视为两种不同的架构方式，而不是同一系统在自主程度上的不同层次。在明确这一基本概念之后，本章还将把当前常见的AI编码工具按照其主要能力划分为五类，分别讨论它们能够解决什么问题、适用于哪些场景，以及各自存在什么局限。与此同时，本章不会只讨论智能体“能做什么”，也会明确讨论它在现阶段“不能做什么”，包括自主决策的边界、复杂任务中的可靠性以及对开发者监督的依赖。

读完本章，读者应当能够用一套相对清晰的标准判断一个系统是否具有智能体的基本特征，理解工作流与智能体在架构和适用场景上的区别，并进一步认识在智能体参与软件开发之后，开发者的职责如何从直接编写代码扩展到任务定义、过程监督和结果判断。

2.1 什么才算智能体：规划、工具访问、反馈闭环与多步自主性

早期的 AI 结对编程工具已经能够理解较大范围的代码上下文，甚至能够识别整个代码库的结构和项目约定，但开发者仍然主导着每一个关键步骤。模型提出建议，开发者决定是否接受；模型指出可能存在的问题，开发者负责浏览代码、运行测试并提交修改。这类工具即使能够生成高质量代码，本质上仍然属于以代码生成为中心的辅助工具，而不是能够独立推进开发任务的智能体。

从 AI 辅助编程走向智能体编码，关键变化并不只是模型生成代码的能力更强，而是模型开始进入实际的软件开发过程，能够围绕目标持续采取行动。为了更清楚地理解这一变化，可以从四个相互关联的能力来看。

第一是规划能力。智能体需要能够理解一个相对复杂的目标，并将其分解为多个相互关联的步骤，同时根据任务状态决定这些步骤的执行顺序。第二是工具访问能力。智能体不能只输出代码文本，还需要能够读取和修改文件、执行命令、运行程序和测试，并与代码仓库等外部环境进行交互。第三是反馈闭环能力。智能体需要观察行动产生的结果，根据结果判断当前方案是否有效，并据此调整后续行动。第四是多步自主执行能力。智能体能够在较少人工干预的情况下连续推进多个步骤，而不是每完成一个动作都等待开发者给出下一条指令。

这四种能力共同构成了编码智能体区别于传统代码生成工具的重要特征。单独具备其中某一项，并不足以形成完整的智能体。例如，一个模型可以生成详细的实施计划，却不能执行计划；也可以调用工具，却只能按照开发者逐步给出的指令行动。只有当目标理解、任务规划、环境交互、结果反馈和连续执行形成一个闭环时，模型才真正开始承担软件开发任务中的一部分行动职责。

在实际编码任务中，这种工作方式表现得非常具体。智能体接到一个任务后，可以先分析代码库结构，定位相关模块，阅读接口和已有实现，再形成修改方案。完成代码修改后，它可以主动运行测试，根据测试结果定位问题并继续调整实现。测试仍然失败时，它可以进一步分析错误信息，修改代码并再次执行测试。任务完成后，还可以整理变更内容、创建分支并生成供开发者评审的修改结果。在这个过程中，开发者不再需要驱动每一个具体操作，而主要负责定义任务目标、提供必要的约束，并对关键结果进行审查和验收。

这一工作模式与经典的ReAct（Reasoning and Acting）框架存在密切联系。ReAct论文发表于ICLR 2023，其核心思想是让语言模型在推理与行动之间交替进行。模型先根据当前信息形成判断，再采取行动获取新的环境信息，然后根据新的观察结果调整后续判断和行动。与单纯生成最终答案相比，这种“推理—行动—观察”的循环使模型能够利用外部环境中的实时信息完成更加复杂的任务。ReAct并不等同于编码智能体的完整定义，但它提供了一种理解智能体执行过程的重要基础范式。后续的编码智能体通常会在这一思想上进一步加入代码库上下文、工具调用、状态管理、测试验证等机制。

因此，判断一个系统是否属于智能体，不能只看它是否使用了大语言模型，也不能只看它是否能够生成代码。更关键的问题是，它能否围绕一个目标自主组织多个行动，与真实环境持续交互，并利用行动产生的反馈调整后续过程。本书后续讨论的各种编码智能体，都将围绕这一基本判断展开。第3章将进一步进入这一执行循环，具体分析编码智能体如何理解任务、调用工具、获得反馈并不断推进工作。这个循环结构可以用一张流程图来表示，如图2-1所示。

图2-1　智能体的观察推理行动反馈闭环

2.2 Workflow与Agent：两种架构的分野

定义了智能体之后，一个更实际的问题随之出现：什么任务应该交给智能体，什么任务并不需要智能体。Anthropic 在 2024 年发布的工程文章《Building Effective Agents》中，对这一问题给出了一个具有代表性的架构划分。该文将基于大语言模型的应用统称为智能体系统，并进一步区分了Workflow和Agent两种实现方式。Workflow通过预先定义的代码路径组织大语言模型与工具调用，执行过程由开发者事先设计；Agent则把更多的执行控制权交给大语言模型，由模型根据任务目标和环境反馈动态决定下一步行动以及工具的使用方式。

两者的差异并不只是术语上的区分，本质上是执行控制权如何分配的问题。在Workflow中，开发者预先规定任务的执行步骤、条件分支和模型调用方式。系统的行为相对确定，执行成本容易估计，测试和调试也更加直接。当出现错误时，通常可以沿着预先定义的执行路径定位具体环节。Agent则将部分控制权交给模型，由模型根据当前状态决定下一步做什么、调用哪个工具、是否需要重新尝试以及何时结束任务。这种方式能够处理事先难以完全预见的情况，但同时也降低了行为的确定性，并可能带来更高的时间和计算成本。

因此，Workflow与Agent并不是“简单”和“高级”的关系，也不是智能程度上的两个等级。它们代表了不同的工程取舍。对于步骤明确、分支有限、执行规则可以提前确定的任务，Workflow通常更加合适。开发者能够直接控制执行路径，系统更容易测试、调试和维护。对于执行路径无法提前完全确定，需要根据任务状态和环境反馈持续调整策略的任务，Agent才具有更明显的优势。此时，模型承担部分过程决策所带来的灵活性，才足以抵消由此增加的不确定性和系统开销。

图 2-2可以从控制权分配的角度直观呈现Workflow与Agent的区别。Anthropic因此提出了一个重要的工程原则，即优先采用能够满足任务需求的最简单方案，而不是为了使用智能体而使用智能体。是否引入Agent，关键不在于它是否比Workflow更先进，而在于任务本身是否需要动态决策。当任务路径可以由开发者可靠地预先定义时，明确的程序控制通常比模型自主决策更加稳妥；当任务需要根据实时环境信息不断调整执行策略时，智能体的自主性才具有实际价值。本书第11章讨论任务类型划分时，还会继续使用这一判断标准。

图2-2　工作流与智能体的架构对比

在实际系统中，Workflow与Agent也并非只能作为两个完全独立的类别。《Building Effective Agents》一文进一步将基于大语言模型的系统划分为三个层次：单次模型调用、Workflow和Agent。单次模型调用由程序直接提出任务并获取结果；Workflow可以包含多次模型调用，但调用顺序和控制流程由代码预先确定；Agent同样可以进行多轮模型调用，但由模型根据当前状态自主决定后续行动。这种划分比简单的二分法更加细致，也有助于工程团队根据任务的实际复杂度选择合适的实现方式，而不是笼统地讨论是否应该使用智能体。

从这个角度看，Agent并不是Workflow的必然升级方向。一个好的系统不是自主程度越高越好，而是在满足任务要求的前提下，把尽可能多的控制权保留在确定性机制中，只在确有必要的地方交给模型。

2.3 五大工具类别谱系

当前市场上的AI编码工具种类繁多，功能也在不断融合。按照它们在软件开发流程中承担的主要功能，可以大致归纳为五类。这里的分类并不是对具体产品进行严格划分，同一个产品往往同时覆盖多个类别，而是为了帮助读者从功能和使用方式上理解不同工具的定位。相比记住某个具体产品当前具备哪些功能，掌握这五类工具的基本边界更具有长期价值。

第一类是AI结对编程工具。这是目前最常见的AI辅助开发形式，代码补全、代码解释、报错诊断和技术问答都属于这一类。GitHub Copilot是其中最具代表性的产品之一，国内的通义灵码、腾讯云CodeBuddy、百度Comate等也提供了类似的代码补全和开发辅助能力。这类工具通常能够利用项目上下文，理解代码库中的文件关系、命名习惯和部分架构约定，从而给出更加贴合当前项目的建议。它们的基本交互模式仍然是“建议—判断”，模型提出代码或修改建议，开发者决定是否采纳。架构如何设计、修改是否合理以及何时提交结果，仍然主要由开发者负责。因此，这类工具更接近开发者的协作助手，而不是独立的任务执行者。

第二类是自主智能体。这类系统符合本章2.1节所讨论的智能体基本特征。Anthropic Claude Code是其中的典型代表，此外，GitHub Copilot也已经提供面向任务执行的编码智能体能力。国内的一些AI编程产品也在逐步加入任务规划、代码修改、命令执行和测试验证等智能体能力。给定一个相对明确的目标和验收条件后，这类工具能够自行拆解任务、调用开发工具、执行多个步骤，并根据中间结果调整后续行动。它们尤其适合路径相对明确但步骤较多的工作，例如大规模重命名、依赖升级，以及按照统一模式修改多个文件。其局限也十分明显：智能体通常高度依赖任务定义的准确性。需求存在歧义时，它可能会非常高效地执行一个与真实意图并不一致的方案。智能体能够执行任务，并不意味着它能够判断这个任务本身是否应该执行。

第三类是AI辅助代码评审工具。这类工具主要承担自动化审查职责，对代码变更进行分析，帮助发现安全漏洞、潜在缺陷、代码异味（code smell）和规范违规等问题。CodeRabbit是这一类别中较为常见的产品，Qodo也提供面向Pull Request的AI代码评审能力。Qodo目前能够结合代码库上下文、Pull Request历史和组织规范进行评审，并通过专门的评审智能体发现缺陷和规则违规。这类工具的优势在于能够持续检查大量代码，不容易受到代码规模和重复劳动的影响。但代码评审并不只是寻找局部缺陷。一个功能是否真正满足产品需求，一种架构选择是否可以承担相应的复杂度和长期维护成本，都需要结合业务目标、系统约束和技术路线进行判断。这些问题仍然需要人类评审者从更高层面介入。

第四类是自然语言到代码生成工具。这类工具重点解决从需求描述或结构化规格到具体实现的转换问题。Vercel v0是这一类别中较有代表性的产品，它尤其强调通过自然语言生成Web界面和应用原型。对于一份较为完整的接口定义、数据模型或数据库Schema，类似工具可以在较短时间内生成相应的基础代码和项目骨架。这里真正决定生成质量的往往不是模型会不会写代码，而是输入规格是否足够明确。需求越清晰、约束越完整，生成结果通常越容易满足预期；如果输入本身存在歧义，生成出的实现即使在技术上成立，也可能偏离真正的业务目标。因此，这类工具实际上进一步凸显了需求表达和规格定义的重要性。

第五类是AI驱动的测试与调试工具。这类工具主要用于生成测试用例、识别潜在的边界条件，以及通过静态分析和动态分析辅助定位问题。Qodo就是一个较有代表性的例子，其产品体系同时覆盖测试生成、测试覆盖分析和代码评审等环节。Qodo的测试工具可以结合代码库和依赖关系生成测试，并分析现有测试覆盖中的不足。这类工具能够快速发现人工测试容易遗漏的输入组合和异常路径，但测试数量增加并不意味着测试质量必然提高。自动生成的测试有时只是让代码路径得到执行，却没有真正验证程序是否产生了正确的行为；调试工具给出的根因分析也可能只是基于当前证据形成的推断。因此，开发者仍然需要验证测试本身是否有效，并确认修复是否真正解决了问题的根源。

这五类工具并不是相互排斥的产品类别，而是按照主要功能和典型使用方式进行的分析框架。随着AI编码工具不断发展，同一个产品可能同时具备代码补全、自然语言生成、智能体执行、代码评审和测试等多种能力。例如，Qodo已经同时覆盖代码评审和测试，GitHub Copilot也已经从传统的代码补全扩展到编码智能体。因此，本节的分类重点不是给产品贴上唯一标签，而是帮助读者回答一个更实际的问题：面对一个具体的软件开发任务，到底需要哪一种AI能力，以及应该把多少控制权交给工具。

五类工具在自主程度、任务范围和开发流程中的作用位置存在明显差异，表2-1进一步对它们的主要能力、典型场景和局限进行对比，读者可以据此建立一个基本的工具选择框架。

表2-1　五大类AI编码工具的核心动作与主要局限

2.4 能力边界：智能体不能做什么

把前面五类工具的能力和局限放在一起观察，可以发现它们最终指向三个更根本的问题。智能体现在已经能够完成大量具体的开发工作，但仍有三类问题不能独立解决。与笼统地说“AI还不够聪明”相比，明确这些问题究竟在哪里，更有助于理解智能体编码的真实边界。

第一，智能体无法替代需求澄清和目标判断。智能体无法从本身含糊的需求中推导出唯一正确的答案，告诉它“把这个功能做得更好一些”，它只能根据已有上下文猜测改进方向；如果同时给出明确的行为要求和验收标准，它才更有可能生成与预期相符的实现。更重要的是，软件开发中有大量问题本身就不是代码生成问题。例如，一个模块是否应该拆分成独立服务，应该采用关系型数据库还是文档数据库，某项功能应该优先满足性能还是开发周期，这些决策都需要结合团队能力、产品路线、系统约束和时间成本进行判断。这些信息有些可能根本没有写进代码库，也不一定能够通过工具访问获得。智能体可以分析已有信息、提出不同方案并说明各自的优缺点，但最终选择什么，以及为什么作出这样的选择，仍然需要由人承担判断责任。

因此，智能体能够很好地执行明确的规格，却不能保证规格本身就是正确的。生成的代码也可能存在逻辑错误、安全漏洞或性能问题。代码评审和测试并不会因为生成速度提高而失去必要性。那些看起来近乎“魔法”的开发体验，真正令人惊讶的是代码生成和修改的速度，而不是软件工程的基本约束已经被消除。

第二，智能体不能替代开发者承担完整的产品和工程责任。即使智能体能够自主完成复杂的编码任务，它仍然不是一个可以独立承担软件开发责任的“另一个开发者”。哪些功能值得开发，目标用户是谁，真正需要解决的问题是什么，这些首先属于产品判断，需要理解用户、市场和业务目标，而不仅仅是理解一份技术需求。

技术方案同样如此，面对一个具体问题，智能体可以提出多个实现方案，并分析它们在复杂度、性能、可维护性和开发成本等方面的差异，但方案选择往往取决于团队现状、项目周期和业务优先级。一个在技术上更优的方案，并不一定是当前项目最合适的方案。智能体可以参与这种决策，却不能替代负责结果的人作出最终判断。

这种责任边界也体现在软件交付环节。即使智能体能够修改代码、运行测试并生成提交，也不意味着它就应该在没有人工审查的情况下直接将变更部署到生产环境。是否允许一个未经评审的变更进入主干，本质上是一个责任和风险管理问题，而不仅仅是一个技术能力问题。智能体拥有多强的执行能力，并不能自动决定它应该拥有多大的交付权限。

第三，智能体生成的结果不能被默认视为正确。AI生成的代码同样可能包含逻辑缺陷，只是缺陷的分布方式可能与人工编写的代码有所不同。开发者仍然需要追问几个基本问题：这段代码是否真正解决了目标问题，是否覆盖了重要的边界条件，是否符合现有架构约定，是否存在安全风险和性能隐患，以及几个月之后其他开发者是否仍然能够理解和维护它。

人类开发者常见的问题，例如只覆盖正常执行路径、遗漏异常处理、忽略边界条件、出现鉴权漏洞或者引入不必要的性能开销，AI生成的代码同样可能出现。因此，代码的来源不应该改变验证标准。不能因为代码由AI生成，就默认它更可靠；也不能仅仅因为它由AI生成，就认为它一定更加可疑。真正应该成为判断依据的，是测试、代码审查、静态分析、运行结果以及其他能够支持结论的证据。

这三类边界背后有一个更深层的原则：软件工程不仅是把需求翻译成代码，更是判断需求是否正确，并通过工程手段证明最终系统确实解决了需要解决的问题。需求的表达本身就可能是不完整的。用户能够说清楚的是“我想要什么”，但未必能够准确说清楚“我真正需要解决的问题是什么”。智能体可以越来越准确地执行一份明确的规格，却不能替代开发者与用户之间澄清目标、发现问题和重新定义需求的过程，也不能替代工程师意识到“即使完整实现这份规格，也没有真正解决问题”时所作出的判断。

因此，随着模型能力不断提升，人和智能体之间的边界确实会发生变化。过去需要人亲自完成的代码编写工作，越来越多可以交给智能体；未来需要人工介入的具体环节也可能继续减少。但这并不意味着监督和责任本身会消失。变化的是人需要把关的具体内容，不变的是对目标、结果和责任的最终判断仍然需要有明确的承担者。

2.5 角色重定位：从代码执行者到编排者

如果智能体已经能够独立完成前面所讨论的多步骤开发任务，那么一个随之而来的问题是，开发者在这样的开发过程中究竟承担什么职责。一种值得关注的组织方式，是将开发者从具体代码执行者转向编排者，根据任务需要组织不同能力的智能体协同完成工作，而不再亲自承担每一个具体操作。

这种分工可以概括为三条原则。

第一，人类负责编排和最终决策。开发者负责确定任务目标，选择适合的智能体和工具，提供必要的上下文，并对最终结果进行审查和确认。智能体可以承担大量具体的执行工作，但不应因此成为最终的决策主体。尤其是在涉及架构选择、业务规则、风险控制和生产环境变更时，最终责任仍然需要由明确的人来承担。

第二，上下文优先。智能体的执行效果不仅取决于模型本身的能力，也高度依赖它能够获得的任务上下文。即使使用能力很强的模型，如果缺少相关代码、接口定义、业务规则、技术约束和验收标准，也可能产生看似合理却不符合实际需求的结果。因此，开发者需要为重要任务准备清晰的任务简报，明确目标、背景、约束和验收条件，并提供完成任务所必需的信息，而不能完全依赖自动检索去猜测任务所需要的上下文。

第三，尽量减少不必要的能力损耗。当任务需要较强的推理和执行能力时，应当尽可能直接使用与任务复杂度相匹配的模型和工具，避免因为不必要的中间转换、信息丢失或不合适的模型选择降低执行质量。这里强调的不是“模型越强越好”，而是让任务要求、模型能力和执行方式相互匹配。

在这种工作方式下，开发者不再需要亲自完成每一行代码，而是成为整个开发过程的组织者和最终判断者。面对一个具体任务，可以根据需要调用不同能力的智能体，分别承担实现、测试、文档编写、重构分析和代码评审等工作。它们可以共享同一个代码库和任务上下文，但针对不同任务采用不同的提示和约束，使模型的能力集中于特定的工作目标。需要注意的是，这些角色并不一定对应不同的模型或独立的软件系统，同一个基础模型也可以通过不同的任务定义、工具权限和上下文配置承担不同的角色。

这种变化使开发者的能力结构发生了明显转移。过去，开发者的价值很大程度上体现在能否准确、高效地将需求转化为代码。随着代码生成和修改越来越多地交给智能体完成，开发者需要投入更多精力解决另外几类问题：能否准确界定任务目标和边界，能否在关键位置作出合理的架构取舍，能否识别需求中的歧义和遗漏，以及能否以足够严格的标准验证智能体的产出。

这并不是开发者作用的削弱，而是工作重心的变化。具体的代码执行可以越来越多地交给智能体，而开发者则需要把更多精力投入到目标定义、任务编排、工程判断和结果验证上。这也构成了本书第6章讨论“意图工程”的出发点：如何将一个仍然带有歧义的想法，逐步转化为智能体能够理解、执行并验证的任务简报。

本章要点

（1）智能体不是单一能力的产物。一个具有完整智能体特征的系统，通常需要同时具备规划、工具访问、反馈闭环和多步自主执行能力。单独具备其中某一项，并不足以构成完整的智能体。

（2）Workflow与Agent代表两种不同的架构选择。它们不是同一架构在自主程度上的高低之分。Workflow通过预先定义的代码路径组织模型调用和工具执行，Agent则将部分执行控制权交给模型，由模型根据任务状态动态决定后续行动。

（3）是否使用智能体，首先取决于任务本身的特征。对于执行路径清晰、规则可以预先确定的任务，Workflow通常更加合适；只有当任务需要根据环境反馈持续调整执行策略时，智能体的自主性才具有明显价值。

（4）AI编码工具可以按照主要功能大致归为五类。包括AI结对编程、自主智能体、AI辅助代码评审、自然语言到代码生成，以及AI驱动的测试与调试。它们在开发流程中承担的角色、拥有的自主程度和适用场景各不相同。

（5）智能体现阶段仍然存在三类重要边界。它无法从含糊的需求中推断出唯一正确的目标，不能替代产品判断和关键工程决策，生成的代码也不能被默认视为正确。因此，需求澄清、人工决策、代码评审和测试验证仍然不可缺少。

（6）智能体可以越来越准确地执行明确的规格，却不能替代对需求本身的理解。软件开发不仅需要理解写下来的需求，还需要理解提出需求的人真正要解决的问题。这一判断涉及用户、业务和系统环境，不会因为模型能力提升而自动消失。

（7）开发者的角色正在从代码执行者逐渐转向开发过程的编排者。随着代码生成和修改越来越多地交给智能体，开发者的价值更多体现在定义任务、明确约束、组织执行、作出工程判断以及验证最终结果。

（8）上下文质量在很大程度上决定了智能体的执行效果。完整、准确且与任务直接相关的代码、文档、约束和验收标准，是智能体正确理解任务的重要基础。如何准备和管理这些上下文，也因此成为智能体编码中开发者需要掌握的核心能力之一。

延伸阅读

[1] Anthropic，《Building Effective Agents》，2024年12月发表于anthropic.com工程博客，提出了工作流与智能体的架构区分，链接 https://www.anthropic.com/engineering/building-effective-agents。

[2] Shunyu Yao等，《ReAct：Synergizing Reasoning and Acting in Language Models》，发表于ICLR 2023。提出推理与行动交替进行的框架，链接 https://arxiv.org/abs/2210.03629

[3] Chris Testa，《The Agentic Coding Playbook：From Idea to Production in 6 Weeks》，2026年。该书对AI编码工具的五大类别及智能体的能力边界进行了更为详细的讨论，并结合大量具体产品说明不同工具的功能定位与适用场景，链接：https://github.com/testaco/agentic-coding-book。