前言
人工智能正在重塑软件的生产方式，这一变化的影响不会止步于程序员的工作台。从最初只能补全下一行代码的模型，到如今可以理解需求、规划步骤、调用工具、验证结果的Agentic Coding（智能体编程），编程活动第一次出现了“由谁执行”这个问题，在大语言模型出现之前这个答案毫无疑问是人，现在答案变得复杂。软件工程作为一门学科，历史上经历过若干次生产方式的转折：从汇编到高级语言、从瀑布模型到敏捷迭代、从本地部署到云原生。Agentic Coding很可能是下一次这样的转折，它改变的不只是写代码的效率，还包括谁对代码负责、如何验证一段自动生成的逻辑值得信任、团队协作与人才培养该如何重新组织。这些问题超出了任何一门编程语言课程或工具培训的范畴，也正是本书试图系统回应的问题。
一、为什么这不是一本工具使用手册
过去，编程工具主要用于代码编辑、补全、调试和构建，软件的需求分析、架构设计、代码实现和测试验证仍然主要由开发者完成。随着大语言模型进入软件开发过程，这种分工正在逐渐改变。开发者可以通过自然语言描述需求，由模型生成代码、解释代码、定位错误，并根据运行结果继续修改。软件开发由此逐渐形成了一种新的协作方式，开发者负责确定目标和作出判断，模型则参与代码实现和部分开发任务。
这种变化也带来了一个值得关注的问题。软件开发工具的更新速度越来越快，具体产品的界面、命令和功能可能在较短时间内发生变化。如果把开发方法建立在某一款工具的具体操作之上，相关经验很容易随着工具版本变化而失效。真正值得掌握的，应当是这些工具背后相对稳定的工作机制，以及在实际开发中反复出现的问题和解决方法。本书因此更关注软件开发过程中人与模型如何协作，模型能够完成什么，容易在哪些环节出错，以及开发者如何通过上下文管理、任务分解、工具调用和结果验证来建立可靠的开发流程。
生成式AI对软件开发方式的影响，也催生了一些新的实践模式。其中受到广泛关注的一个概念是Vibe Coding（氛围编程）。2025 年，Andrej Karpathy 使用这一术语描述一种以自然语言与生成式AI协作完成编程的方式。开发者不再需要从头编写所有代码，而是向模型表达自己的想法和目标，让模型生成和修改代码，再通过运行程序、观察结果和继续反馈来推进开发。Vibe Coding体现了一个重要变化，即编程过程中人的工作开始更多地从直接编写代码转向表达意图、评估结果和指导模型。这种方式对于快速原型和探索性开发具有明显优势，但也存在局限。能够运行并不意味着软件设计合理，更不意味着代码具备良好的可维护性和可靠性。当项目规模扩大，开发者仍然需要处理需求分析、架构设计、依赖管理、测试验证、错误定位以及版本控制等问题。因此，Vibe Coding 更适合作为理解生成式AI编程的一个起点，而不是终点。
当模型进一步具备项目级上下文理解能力，并能够主动调用编译器、测试框架、代码仓库和其他开发工具，根据执行结果调整方案并持续推进任务时，人机协作的方式又会发生进一步变化。此时，开发者面对的已经不只是一个能够生成代码的助手，而是一个能够围绕开发目标执行一系列行动的软件工程参与者。这种以目标为导向、以持续执行和反馈为特征的开发方式，构成了Agentic Coding所要研究的核心内容。
本书对内容取舍有一个明确的原则。凡是高度依赖具体工具版本、容易随着产品更新而失效的内容，不作为正文的核心知识。命令行参数的具体写法、某个平台配置文件中的字段名称等操作细节，可以放在脚注或附录中，正文则关注这些操作背后的工程问题。例如，为什么需要区分模型本身的能力与模型所处的运行环境和工具链（harness），为什么上下文窗口的容量会影响智能体对任务的理解和判断，以及一个复杂任务应当如何拆解，才能既发挥智能体的自主性，又保持开发者对关键结果的控制和责任。
这种取舍并不意味着回避技术的局限。编码智能体的输出具有概率性和非确定性，模型声称“任务已经完成”并不能替代实际的测试和验证。生成代码的速度越来越快，也可能让开发者更容易忽略需求理解、架构设计和边界条件等问题。对于软件工程而言，真正重要的并不是让智能体看起来更加可靠，而是承认它始终存在出错的可能，并在此基础上建立相应的约束、验证和追责机制。
因此，如何使用智能体并不是简单的效率问题，也是一个工程控制问题。编码智能体可以成为能力很强的协作者，但不能被默认视为可信的执行者。开发者需要通过任务分解、上下文管理、测试验证、权限控制和结果审查等机制，将这种不完全信任转化为一种可控的开发流程。这也是理解Agentic Coding的重要出发点。它关注的不只是智能体能够生成多少代码，更关注在真实的软件工程环境中，如何让智能体参与开发，同时保持系统的可靠性、可维护性和责任边界。
二、贯穿示例：IoTFlow
为了把抽象的概念放到真实的软件开发场景中，本书构造了一个虚拟项目IoTFlow，并将其作为贯穿全书的案例。IoTFlow是一个跨协议的物联网设备管理平台，包含 MQTT/CoAP双协议网关、时序数据存储、告警引擎和运维仪表盘四个主要模块。平台中的设备和数据均通过软件模拟，不依赖真实硬件，读者可以在普通的软件开发环境中完成相关示例。
IoTFlow的作用不是让读者从头到尾完成一个完整项目，而是提供一个相对稳定的技术背景。不同章节会在同一项目背景下讨论代码生成、任务分解、上下文管理、工具调用、测试验证等问题，并尽可能沿用相同的模块名称、接口和协议适配器。这样可以减少读者在不同示例之间切换时需要重新理解的背景信息，也使前后章节之间形成自然的联系。
同时，各章不会要求读者按照固定顺序推进项目。每个示例都围绕当前讨论的问题组织，具备相对完整的上下文，即使没有阅读前面的章节，也能够理解示例所要解决的任务。IoTFlow因此更像是一条贯穿全书的案例线索，而不是一项必须持续维护的课程项目。它的主要作用，是让不同章节讨论的Agentic Coding方法始终落在具体的软件工程问题上。
三、阅读路径建议
全书分为六个部分：第一部分（第1章至第5章）认识Agentic Coding，第二部分（第6章至第10章）智能体编码的工作循环，第三部分（第11章至第15章）编码活动实践，第四部分（第16章至第18章）多智能体编码，第五部分（第19章至第22章）代码库与交付，第六部分（第23章、第24章）角色转型与未来展望。整体安排遵循从概念理解到方法掌握，再到工程实践和系统治理的递进关系，但各部分之间并不是严格的先后依赖关系。
第一部分至第三部分，即第1章至第15章，主要建立理解Agentic Coding所需要的基本概念和分析方法。这里首先讨论什么是智能体，它与传统代码生成工具有什么不同，以及为什么不能把智能体的输出直接视为可信结果。随后进一步进入开发过程中的具体问题，包括如何把模糊的开发意图转化为可执行的任务规范，如何组织上下文，如何让智能体调用工具，以及如何对生成结果进行测试和验证。这部分内容默认读者具备基本的软件工程或数据结构知识，但不要求已有智能体开发经验，因此适合第一次系统接触大模型软件开发的读者从头阅读。
从第四部分开始，即第16章至第24章，讨论的重点逐渐转向更复杂的工程环境。第四部分（第16章至第18章）讨论多智能体协作的基础、编排方式与团队规模化问题；第五部分（第19章至第22章）回到代码库、编程语言、软件交付和工具生态，讨论这些已有的软件工程基础设施需要作出怎样的调整；第六部分（第23章、第24章）回到开发者本身，讨论角色转型、能力结构变化以及尚未解决的前沿问题。这几部分的讨论都建立在前面已经介绍的单智能体工作机制之上，此时关注的问题不再只是“智能体能不能完成一个任务”，而是当任务规模扩大、参与者增多、软件进入真实生产环境之后，如何组织协作关系，如何划分责任，如何控制权限和风险，以及如何保证整个开发过程仍然可验证、可维护。对于已经具有软件开发或系统运维经验的读者，可以不必严格按照章节顺序阅读，从第4章开始建立分析框架，再根据自己的工作或研究方向选择后续章节。