多年来，计算机科学课程一直为学生铺就一条清晰的职业道路，即软件工程，这条路径曾经行之有效。我亲身经历过这一点，但随着人工智能辅助编码和智能体编码的出现，软件构建方式正在重塑，这条路径正变得不再那么传统。我们正在见证一种新事物的诞生，被称为智能体工程。

在本视频中，我们将剖析软件工程与智能体工程之间的区别，以及这种转变如何改变开发者的角色。数十年来，软件工程意味着为计算机编写明确的指令。如今，我们正进入一个工程师越来越多地定义目标，而人工智能智能体负责确定执行方案的世界。但必须明确的是，这并不会取代软件工程，它只是改变了工程努力的投入方向。

传统软件工程本质上是确定性的。你提供明确的指令和控制流。如果相同的输入出现两次，你期望得到两次相同的输出。这意味着需要手动定义边缘情况、权限、重试机制、验证和执行路径。每一步都是预先定义的。然而，大型语言模型引入了根本不同的东西。

这些系统不再仅仅执行僵化的逻辑，而是能够解释目标。一旦将这种能力与记忆、工具使用、规划和反馈循环相结合，你就会得到一种更接近人工智能智能体的产物。因此，从高层视角来看，在传统软件工程中，开发者编写行为；而在智能体工程中，开发者塑造行为。

简而言之，智能体工程使我们能够摆脱确定性逻辑，转向概率性判断的细微领域。如果我们将这个词拆解开来，这一点会更加明显。其中，“智能体”指的是编写代码的智能体组织，以及监督并验证输出的人类开发者。当智能体或多智能体系统迭代处理子任务时，我们保持“人在回路”的状态。

另一方面，“工程”描述了使用智能体工作流进行有意义代码生产所需的专业水平，且不会危及代码质量。诸如智能体编码、氛围编码和智能体工程等一系列术语的涌现，反映了开发者与人工智能互动方式的更广泛转变。

然而，很容易混淆几种人工智能辅助编码的术语，尤其是每年都有新术语被创造出来。为了帮助区分一些最常用的术语，我倾向于将其视为某种光谱，而不是从好到坏的排序，而是基于人类保留的自主权与委托给系统的自主权之间的比例。

在一端，你有传统软件工程，开发者明确定义几乎每一个工作流、规则和实现细节。人工智能可能提供辅助，但人类在架构和决策过程中仍保持完全的控制。沿着光谱移动，你进入人工智能辅助编码阶段。

在这里，工具帮助……自动补全、重构或生成代码片段，而开发者仍然主导整体实现。接下来是氛围编码。

在氛围编码中，开发者越来越多地用自然语言定义或描述意图，并迭代地塑造结果，而不是手动编写每一行代码。重点从精确的实现转向创造性的指导和快速实验。再进一步，则是智能体编码。

在这种模式下，系统可以自主规划任务、使用工具、编写和执行代码、调试失败，并在有限监督下朝着目标迭代。最后，我们有智能体工程，其范围完全超越了代码生成。

在这里，工程师不仅仅是在构建软件，而是在描述和设计环境，使自主系统能够在约束条件下推理、协调、评估结果并动态适应。重要的是，这些并不是僵化的类别。它们代表了从直接编程行为到越来越编排智能的抽象层面的渐进转变。

这些术语实际上相互渗透。团队通常从氛围编码开始，以快速原型化想法，然后随着风险和复杂性的增加，逐渐演变为智能体编码，最终走向智能体工程。

与其将人工智能仅仅视为编码助手，智能体工程将人工智能系统视为协作者，能够在人类监督下处理多步工作流。工程师越来越多地成为系统的编排者，而不是手动执行每一项任务。

重要的是，这并不意味着将人类排除在回路之外。事实上，关于智能体系统最大的误解之一，就是认为它们消除了对工程专业知识的需求。现实情况恰恰相反。随着这些系统变得更加自主，人类监督的价值实际上增加了。

因为现在工程师不仅要负责编写代码，还要确保概率性工作流的可靠性。这可能意味着培养一种鼓励实验同时保持问责制的文化。这意味着，智能体系统应该加速开发，而不是取代软件工程专业知识。

开发者社区对这一转变 understandably 有一些复杂的反应。一些人将其视为追求更具启发性和满足感工作的机会，但其他人则持怀疑态度。诚然，这种怀疑是有道理的。

传统软件系统的故障方式相对可预测。你想想，如果有 bug，你通常可以直接将其追溯到错误的条件、状态转换或实现细节。智能体系统则不同。

因为这些系统以概率方式运行，它们可能在表面看起来正确，但在底层却做出有缺陷的决策。它们可能会产生幻觉。它们可能会误解意图、误用工具，或者生成技术上有效但架构上糟糕的解决方案。

这就是为什么智能体工程中的核心挑战在于编排和验证。工程瓶颈正从手动编写每一行代码，转向监督、约束和评估日益自主的系统。这也解释了为什么氛围编码在大规模应用时会变得成问题。

氛围编码在快速实验和原型制作方面非常有效。但如果没有强大的工程纪律，这些工作流也会迅速产生技术债务。缺乏结构、测试或架构一致性的 AI 生成代码，可能会变得难以维护。

随着时间的推移，我认为“代理工程”（Agentic Engineering）这一术语变得有用，因为它强调了工程活动仍在继续。这并非要取代整个软件工程，而是将其扩展到一个新的抽象层。代理工程改变了工程师大部分时间所从事的工程内容。

你可能想知道，回顾我们之前探讨的光谱，下一步是什么？随着人工智能辅助软件开发生态系统的不断演变，其术语很可能也会继续变化。虽然代理工程为开发者如何与自主系统协作提供了一个更成熟、更准确的框架，但随着人工智能代理能力的提升，其背后的实践也将不断进步。

与此同时，开发者的角色将从单纯编写代码演变为设计代码，塑造这些人工智能系统的行为，并对它们进行监督。如果你不确定从哪里开始，不妨从小处着手。尝试在当前工作流程中使用这些工具，留意它们在哪些地方能提供帮助，又在哪些地方会出错，然后在此基础上逐步构建。

但请不要忘记，要抵制用自动化来替代理解和质量的诱惑。如果你喜欢这个视频，请记得点赞和订阅，并在下方的评论区告诉我，你希望下期看到关于人工智能的哪个话题。感谢观看！