智能体工程：AI 智能体群组如何重塑软件工程

快速阅读

软件开发已经进入了一个全新阶段，在这个阶段，智能体不再是孤立的工具，而是像现实世界团队一样协作的实体。本文介绍的“智能体工程（Agentic Engineering）”并非仅仅为了“更快地写代码”，而是旨在打造一个像真正工程团队一样规划、执行并交付软件的多智能体协作系统。在试点研究中，通过工作智能体（Worker Agents）和领导智能体（Leader Agent）的配合，跨团队的调试工作流在查找根本原因的时间上缩短了 93%，而开发工作流的执行时间也降低了超过 65%。AI 编码助手（如 Codex 和 Claude）专注于单一用户的任务循环，而智能体工程则提供了一个控制平面，跨越团队边界进行端到端的协调，重塑了软件在组织中流动交付的方式。

本文是来自思科首席软件工程师（总监）Renuka Kumar 博士和思科工程高级总监 Prashanth Ramagopal 的客座文章。博客中表达的观点仅代表作者个人观点，不代表思科的立场。

软件开发已经进入了一个新阶段——智能体不再作为孤立的工具运行，而是作为镜像现实世界团队的协调实体发挥作用。随着 AI 采用的加速，焦点已经从什么是可能的转移到了什么在实践中真正有效。软件工程的每一个阶段——需求、设计、开发、安全、测试、部署和运营，至少都适合进行部分自动化，甚至当智能体进行跨职能协作时，可能支持完整的端到端编排。因此，目标不再是“我们如何更快地编写代码？”，而是变成了“我们如何才能更快、更安全地让软件在系统中流转交付？”通过对多种智能体框架的实验，我们已经确定了能够带来真正、可衡量影响的实用模式。

本博客介绍了一个旨在从任务级执行向系统级协作过渡的智能体工程系统。我们提出了一种参考架构，并使用 LangChain 工具套件（包括 LangSmith 和 LangGraph）实施了多智能体协调框架的初步评估。这个系统不是一个“更好的编程 AI”，也不是一个“更好的任务助手”。这种架构被设计为一个多智能体协调的控制平面，专注于端到端的软件交付。

智能体工程：镜像现实世界的工程团队

我们的核心见解很简单： “最大的突破不单单来自更好的工具。它来自于那些能够镜像现实世界团队的系统。”

智能体工程的核心是一个由智能体组成的协作系统，旨在模仿工程团队规划、执行和交付软件的方式。该框架没有将 AI 视为孤立助手的集合，而是将智能体模型化为团队成员——每个成员都有明确的职责、共享的上下文和责任——并通过一个轻量级但强大的领导层进行协调。

该系统为多智能体协作提供了一个原生的控制平面，能够：

  • 执行长期的工作流
  • 保留可供团队间共享的智能体记忆
  • 链接可以跨越团队边界的各类工作流
  • 促进知识共享，让新成员快速融入智能体工作流
  • 全局监控智能体执行的工作流，以实现可追溯性和可审计性

架构

从高层次来看，该系统是一个松耦合的智能体系统，它们既可以作为独立实体运行，也可以作为智能体群组（swarm）中的一个实体运行。我们的系统由两个互补的角色组成，并可以灵活扩展：

  1. 工作智能体 (Worker Agents)：这些智能体的功能相当于工程团队中的个人贡献者的数字副本。它们在明确的边界内自主运行，根据工程意图（如开发、测试、调试或运维）来计划和执行任务。根据团队的成熟度和复杂性，部署可能只涉及一个工作智能体，或者是一个动态协调的工作智能体群组。

工作智能体具备以下能力：

  • 解释用户意图并利用推理模型将其转化为可执行计划。
  • 从源代码库、问题追踪系统（Issue Trackers）等记录系统以及日志等内部知识库中收集所需的上下文。
  • 通过工具、AI 编码助手或自定义/子智能体来执行工作流。
  • 验证结果以确保正确性和完整性。
  • 向领导层汇报计划、操作和结果，以确保透明度、责任感和可追溯性。

工作智能体在设计上是松耦合的，这使它们能够横向扩展，适应新的工作流，并在必要时将任务委托给群组中的其他智能体。

  1. 领导智能体 (Leader Agent)：这些智能体扮演了项目负责人的数字角色。它们在一个智能体群组中提供协调、治理、共享能力和可见性。领导智能体提供：
  • 共享的提示词和工作流库，标准化最佳实践，极大降低入职摩擦。
  • 一个通用的工具网关，以一致且安全的方式向工作智能体公开已批准的功能。
  • 智能体群组的长期记忆，实现随着时间的推移不断学习和改进。
  • 对智能体活动、决策和结果的全局可观测性，提供对系统行为和性能的洞察。
  • 决定智能体何时以及如何采取行动的编排，而不仅仅是管理它们产生什么。
  • 通过将执行与协调分离，框架在规模化时既能保持边缘的自主权，又能保持系统的连贯性。

下图展示了智能体工程系统的参考架构。我们所有的工作智能体通过 A2A（Agent-to-Agent）协议进行通信。然而，工作智能体也可以通过 MCP 包装器与不支持 A2A 的智能体进行交互。工程师通过他们偏好的界面（如 IDE 或 CLI，或通过 GitHub/Jira Actions 的外部触发）与系统交互表达意图。在这个系统中，工作流可以进行定制，以满足团队的生产力需求。

架构概览

在评估了多个智能体框架之后，我们选择了 LangChain 的框架进行本次研究，因为它们符合智能体工程的生产要求。它是一个有状态、可协作、可治理的智能体系统的执行模型，使其适合编排镜像现实世界工程团队的 AI 系统。我们使用 LangMem 抽象来存储长期状态，并使用 LangSmith 来记录执行追踪，从而实现端到端的可追溯性、遥测技术以及智能体工作流和成果的系统级视图。

宏观架构视图

以下是展示这些智能体系统如何跨越团队边界的参考图。智能体领导可以与其他团队的领导合作。例如，来自产品管理团队的产品需求可以通过工程团队领导路由给合适的工作智能体（群组），用于规划和提取需求。

跨团队边界宏观视图

基于 LangChain 的参考技术实现

此实现整合并评估了 LangChain 框架套件提供的三个核心抽象：LangGraph（用于可控智能体编排）、LangSmith（用于智能体可观测性和评估）以及 LangMem（帮助智能体通过长期记忆学习和改进的库）。LangGraph 的核心抽象——由有状态节点组成的图——能够根据智能体生成的计划构建自定义工作流。评估的重点在于将智能体工程从实验环境过渡到稳定、可投入生产的运营模式所需的以下技术特征：

  • 能够跨步骤、智能体和重试操作持续存在的状态管理和检查点（checkpointing）能力。
  • 追踪谁在何时、为何做出了什么决定的审计跟踪机制，支持事后分析和持续改进。
  • 与外部记录系统和 MCP 风格工具网关的接口兼容性。
  • 确保智能体执行授权操作以降低操作风险的确定性执行模型。
  • 跨不同智能体通信协议以及与使用其他框架构建的智能体之间的互操作性。

使用 LangGraph 辅助的智能体执行

我们探索了几种涉及智能体间通信的场景，例如工作智能体跨不同团队协作调试技术问题，以及利用 Codex 或 Claude 等 AI 编码助手与工作智能体协作进行开发。我们在下图中详细说明了后一种场景的示例。该图描述了 AI 编码助手和具有自主逻辑的工作智能体之间的交互。工作智能体内部的自主逻辑遵循适用于大多数智能体工作流的逻辑四阶段进程。此用例展示了如何使用工作智能体来检索超出源代码范围的上下文，通知其他智能体，并跟踪智能体活动。

  • 意图分析 (Intent Analysis)：在 IDE 中以自然语言输入工程意图后，请求会被发送给工作智能体。在此案例中，智能体的工作流使用 LangGraph 编排，以分析意图并通过 MCP 工具检索相关的上下文。
  • 规划和通知 (Planning and Notification)：建立上下文后，智能体会生成结构化的多步骤计划（图中的步骤 1 到步骤 N）。计划将通过通信渠道（如 Slack、Teams 或 Webex）通知给工程师。
  • 执行和跟踪 (Execution and Tracking)：然后，在 IDE 中与 AI 编码助手协作，逐步执行该计划。智能体利用 LangGraph 的检查点和状态跟踪机制来跟踪执行状态。
  • 验证和闭环 (Validation & Closure)：在最后一步中，一旦执行完成，工作智能体将通过验证执行的计划是否与内存中检查点的执行状态相匹配来完成闭环。结果作为通知在工程师的通信渠道中传达给他们，并作为长期状态保存在 LangMem 中。

工作智能体工作流

鉴于 AI 编码助手本身不支持原生的 A2A（Agent-to-Agent）能力，我们构建了一个 MCP 适配器工具，将请求从 AI 编码助手路由到工作智能体。这种方法因此使系统变得不受 IDE 限制。

试点研究的发现和观察结果

为了评估智能体工程的实际影响，我们将该框架应用于现实世界中的开发、测试和调试工作流。我们并未针对个别任务进行优化，而是测量了智能体协作时吞吐量的提升（在不损失质量的前提下），我们选择了需要至少两个智能体协调的工作流。为了确定开发和调试工作流的基线，我们组织了一次训练营，工程团队聚集在一起整理用例列表，并根据历史证据计算在没有智能体的情况下完成这些工作流所需的时间。我们保守地报告了数据，实际收益可能更大。

我们评估了多个涉及跨团队分类和根本原因分析的调试工作流，并由我们的 QE 团队进行了独立的质量评估。使用查找根本原因的时间（time-to-root-cause）作为主要指标，包含 20 多个工作流的试点研究显示，与历史调试时间相比，总体上缩短了 93%。多项跨团队调查在智能体的协调执行下不到 5 分钟就完成了，并且独立 QE 评估确认未出现任何可测量的质量下降。在一个月内由 70 名独立用户生成的总共 512 次调试会话中，我们通过利用跨团队协作的智能体工作流计算出节省了 200 多个人工小时。

对于以开发为重点的工作流，我们的设置将基于 IDE 的 AI 编码助手与我们的工作智能体配对。尽管这不是必需的，但其主要优势在于系统能够从我们的后端服务中检索特定于项目的上下文，从而生成更明智的代码和测试计划。我们还测试了将规划责任转移给工作智能体，同时在 LangMem 中保持长期状态，这允许索引和重复使用先前的工作流。这大大降低了重复性任务的入门开销。

在超过 15 个开发工作流中，即使加入了工作智能体，我们观察到执行时间与历史基线相比仍减少了 65% 以上。重要的是，主要的收益不仅限于更快的代码生成（AI 编码助手在这方面已经表现得很好了），还来自于通过协调的智能体执行压缩了 PR 合并后的功能测试等下游工作流。PR 审查过程本身反而成为了人工介入带来的瓶颈。

该系统与 AI 编码助手的不同之处

Codex 和 Claude 等 AI 编码助手提供了多项增强软件开发的新功能。然而，这些智能体运行的抽象层次与本文所描述的智能体工程系统有根本的不同。

  1. Codex 级别的模型通常被嵌入在工作智能体中，或作为推理/代码生成引擎集成到工作流中。
  2. 虽然 AI 编码助手擅长在代码库上下文中将意图转化为代码、重构、解释或调试代码，但它们在一个受限的用户驱动交互循环内运行，且编排跨团队工作流的能力有限。相比之下，这种智能体工程系统被显式设计为像一个松耦合的工程团队一样行动，跨越开发者和团队的界限。
  3. AI 编码助手及其子智能体可以极其出色地执行并行功能。而本篇博客文章介绍的系统是一个显式的控制平面，用于编排端到端的智能体工程，使软件能够在软件工程流水线中快速推进，为此我们利用了 LangChain 的框架。

结论

智能体工程代表了软件构建方式的根本性转变，它围绕着表现得像真正工程团队的 AI 系统重组了工作，并充分利用了它们擅长的事情。总的来说，我们的研究表明，智能体工程的主要影响不是递进的任务加速，而是软件在组织中流转方式的结构性转变——压缩协调开销、减少跨团队延迟、共享上下文，并重新定义人类注意力的最大价值所在。像 LangGraph 这样的框架使得这种运营模式具有实用性，它将协作、记忆和可观测性视为头等重要的事务。智能体工程框架的优势在于可以显著地轻松切入软件交付流水线，工程师几乎不需要进行繁杂的设置。一旦配置好智能体，多个团队就可以利用工作智能体从内部和外部工具中提取上下文。结果不仅仅是更快的代码生成，而是提供了一种更具弹性、更可扩展以及在根本上有所不同的软件交付方式。

🔗 原文链接：Agentic Engineering: How Swarms of AI Agents Are Redefining Software Engineering