AI 智能体（使用大语言模型 (LLM) 作为决策引擎，自主规划和执行实现预定目标所需任务的软件系统）的强大功能和普及，已经引发了企业工作流程的快速转型。这种转型的速度已经超过了许多组织调整传统 IT 结构以反映智能体式 AI 整合独特需求的能力，从而造成一个碎片化的生态系统。ADLC 引入了通用规范和共享实践，以促进跨不同工具、平台、供应商和企业环境的可靠智能体系统。
当今许多标准的 IT 流程都是在传统软件开发的背景下发展起来的，是基于静态、确定性系统的假设量身定制的。此类过程通常不适合驱动智能体行为的 LLM 的动态、概率性的本质：它们被称为“AI 智能体”，因为它们确实拥有自主权来决定如何执行任务。能够考虑这一转变的共同准则和规范，可以显著降低相关风险，加快负责任的智能体式 AI 的采用。
为了实现智能体式 AI 可持续且有效的扩展，AI 智能体必须跨不同模型、平台、供应商和行业生态系统之间可预测地集成。目前，几乎所有构建 AI 智能体的平台都有自己的智能体定义格式、工具和函数调用模式、内存和状态管理模型、测试套件、部署协议和版本控制系统。这种碎片化会阻碍互操作性，增加转换成本并导致供应商锁定。最近的研究发现，这是业务和技术领导者在探索 AI 智能体供应商生态系统时仅次于安全性的主要问题。1 在操作方面，这种碎片化也降低了技能和工作流的可转移性。
虽然标准化的规范和实践可以缓解这些低效率问题，但对于组织来说，重要的是要接受并执行与开发人员既定的倾向和偏好相配合（而不是相悖）的结构性协定。因此，ADLC 旨在将新兴开发者实践转化为一流的智能体体验。
ADLC 整合了 DevSecOps 的核心原则，将 AI 智能体开发映射到一系列相互关联且在很大程度上相互依赖的阶段。本文稍后将深入探讨每个阶段的目的和实践以及它们之间的关系。完整的细节、建议和规范载于官方的 IBM ADLC 指南中。
通过 Think 时事通讯，了解有关 AI、自动化、数据等方面最重要且最有趣的行业趋势。请参阅 IBM 隐私声明。
传统软件开发生命周期 (SDLC) 的一些标准假设和最佳实践不适合构建 AI 智能体。企业 AI 智能体计划要想取得成功，组织必须了解并考虑传统软件和智能体系统之间的根本差异。
确定性模型与概率性模型对比：传统软件接收明确、具备确定性的指令（命令式代码形式），目标仅作为隐含需求；AI 智能体接收清晰的最终目标与行为约束，依靠工具、数据源与自主推理，自行推导最优实现路径。在智能体架构下，两次输入完全相同的内容，可能得到两份不同输出结果。
静态与自适应：传统软件功能固定，只有当规范某行为的代码被主动变更时，行为才会发生变化。而智能体的行为可能根据来自环境的反馈而演变。
代码驱动与结果驱动：传统软件的确定性、线性本质使开发人员能够通过稳定、（相对）客观的代码质量衡量标准来预测程序的成功与否。智能体式 AI 的概率特性意味着，即使是最优执行，也可能产生次优智能体性能，而混乱、次优提示仍可能产生准确的输出。因此，评估智能体系统需要系统地衡量业务结果和智能体行为随时间的变化。
也许最关键的是，智能体系统和传统软件具有截然不同的故障模式。
传统软件出现故障，是逻辑漏洞、边界场景打破代码固化指令导致。这类故障表现直观：程序崩溃，或是输出无意义内容。传统软件具备确定性，任何故障都能追溯至代码内特定缺陷，便于调试修复。
与之相反，智能体系统故障多源于幻觉输出或对齐偏差。AI 智能体依靠概率推演解读意图（系统提示、约束规则、上下文提供需求信息），而非执行传统软件固定的规则逻辑。智能体看似完成问题处理，实则可能突破约束条件，或是笃定输出错误内容。这类故障更容易被忽略：看似合理的错误输出，远比程序崩溃难以识别。故障溯源难度更高：复杂多阶段智能体工作流整体出错，可能只是单次概率化工具调用返回错误导致，且复测时该问题未必复现。
因此，ADLC 在每个阶段都构建了可观测性、遏制功能和持续评估机制。智能体开发必须有效地平衡现实场景中全面测试的需求和遏制现实世界风险的需求。
智能体开发生命周期 (ADLC) 将构建、部署、优化和管理 AI 智能体的过程划分为不同的阶段，其中一些阶段组合起来形成迭代循环。
规划：组织全部相关利益相关者对齐用例、目标、成功指标与预期业务成果，以此搭建评估框架。使用自然语言定义并记录智能体标准行为与标准操作流程。
编程与构建：开发智能体（包括模型选择、提示设计和编排）。识别相关的外部服务，例如工具、数据库和 API，并使用模型上下文协议 (MCP) 将它们集成到企业层。实施深思熟虑的版本控制、沙盒化和网关模式。
测试与发布：根据预定义基准运行结构化评估、实施策略检查、执行安全测试和红队演习，并验证智能体是否在受控目录中。根据需要，反复循环执行编程与构建和测试与发布。
部署：获得认证后，将智能体移至生产环境，逐步部署以管理风险。采用网关模式，以实现有效的治理和政策执行。通过沙盒化、版本控制、回滚策略、安全执行和性能限制来确保运行时监管。
运行：持续观测、调优已上线智能体，实时追踪准确率、延迟、成本、用户满意度等指标，警惕模型漂移、性能回落问题。依托反馈循环优化提示、工具、模型、存储策略，兼顾性能与安全，按需反复执行部署-运行循环。
监控：一旦系统得到充分验证和优化，就应继续监控并进行持续审计，以确保公平性、透明度和合规性。维护管理完善的智能体和工具目录，以促进可观测性和可复现性。
通过遵守这些阶段及其旨在应对的优先事项（各部分将在下面的章节中进行更详细的探讨），组织可以保持智能体的可信、可审计并与业务价值保持一致，从而安全、自信地进行扩展。
智能体开发过程始于用例对齐，所有其他规划考量皆由此展开。
智能体需要达成的业务目标，决定了用于评估其运行效果的关键绩效指标 (KPI) 与各类成功衡量标准。客户支持自动化方案的评估核心指标为终端用户满意度与成本压降，而编码智能体的评估维度为响应延迟与代码质量。为各项指标选定计算公式本身就是一项关键架构决策，不同计算逻辑会产出差异化的达标判定标准，也会引导出不同的运营导向。
依托智能体落地特定业务目标，需要由智能体自动化执行对应流程、主任务与子任务，其中大量任务需为 AI 智能体分配指定工具、数据集、知识库与 API 的访问权限。编码与构建阶段启动前，梳理并采购全部所需资源清单，是保障开发流程高效顺畅的关键。
也就是说，规划阶段需要做出的最重要的决定是：您是否应该构建 AI 智能体。
IBM 建议选用能够匹配您专属业务需求的最简方案。如果传统自动化、检索系统或设计完善的提示即可解决问题，引入智能体式 AI 反而会徒增额外复杂度。例如，自动回复客户邮件的系统需要部署 AI 智能体，但邮件分类系统仅需搭配 LLM 与设计完善的提示即可实现。
若智能体式 AI 相较轻量化方案带来的性能提升，足以覆盖配套产生的成本与延迟涨幅，企业场景下智能体式 AI 的标准落地流程通常包含：
明确的产品范围。优先处理那些需要判断或多步骤推理，因此无法通过广泛的基于规则的自动化充分解决的特定业务问题。需要上下文判断、多步推理和规模化复杂决策的问题是智能体式 AI 的理想处理对象。
明确的成功指标。智能体式 AI 可在能够客观、定量评估成功并能够执行标准的场景中取得成功。这不仅提供了从业务角度所需的合理理由，还提供了从运营角度所需的优化目标。
可管理的复杂性。智能体式 AI 的概率特性意味着多智能体系统存在脚手架风险，即单一步骤失败可能带来深远后果。理论上，智能体系统的优势显然应该超过操作的复杂性。
对企业部署智能体式 AI 的深入分析，揭示了具有一致价值和可控风险的具体模式：文档冗繁的流程、客户支持（或客户服务）以及可记录的知识工作。这些都是理想的起点。
所有集成场景，无论是企业数据、第三方应用程序还是外部系统对接，均可视作由 MCP 服务器支撑的工具集成。理想情况下，您选用的智能体开发平台支持基于自身专属用例自定义 MCP 行为。采用 MCP 网关架构，依托后端系统对全部对接链路做安全防护与统一管控。
应尽可能优先考虑可复现性和开放标准，例如用于工具和资源的 MCP、用于可观测性的 OpenTelemetry 以及用于提示的可重用模式。同样，您应该采用一致的模式进行存储和检索、工具访问和任务委派。
对于将面临现实世界风险的企业系统来说，智能体式 AI 的安全性应利用安全设计原则直接融入每个开发步骤，而不是事后加装。
每一款 AI 智能体需分配独立身份标识，确保智能体所有操作均可完整记录、审计并精准归属。该机制不仅能够精准溯源各类安全问题，同时便于组织适配随智能体式 AI 普及持续更新的监管规范。
沙盒隔离与其他隔离管控手段是风险约束的核心措施。智能体的运行环境、网络访问、文件系统访问权限需全程遵循最低特权原则。智能体系统内所有组件仅授予完成既定任务所需的最低权限。
测试智能体原型以确保其准备好投入生产环境，所需的不仅仅是传统软件设计生命周期中的单元测试和静态分析。它还必须针对真实世界场景或高保真模拟进行广泛的行为验证。鉴于智能体系统的概率性质，这些测试场景的样本量必须足够大且足够多样化，以合理确保所有潜在的智能体涌现行为均已被观察和评估。
需基于预设基准与规范校验标准测试 AI 智能体，确保其行为符合预期管控要求。该环节可能需要采集或构建基准数据集，明确智能体面对各类输入与场景时的标准处理流程。还需同步采用 LLM 评审与人在回路人工复核，兼顾自动化评审的规模化能力与人工复核的准确性保障。
在初始部署之前和之后，强大的持续集成/持续交付 (CI/CD) 管道对于以必要规模运行测试和评估、自动运行评估、测试工具信心和加强安全护栏措施至关重要。在测试期间，持续集成 (CI) 系统有助于确保智能体的推理逻辑在更新其组成模型和提示时不会中断。在动态环境中，即使切换为已经在使用的 LLM 的最新模型版本，也会产生不可预知的影响。
红队主动识别对抗脆弱性和潜在的协调失误。它模拟敌对条件，如提示注入攻击和越狱尝试，以检测标准行为测试可能忽略的场景中的安全约束。
经过全面测试、优化和验证后，AI 智能体被安全地部署到企业环境中。部署阶段应该被理解为一种深思熟虑的、有策略的分层激活，而不是像按下一个经典的“部署”大红按钮那样的单一行为。ADLC 通过沙盒化、版本控制、回滚战略和故障安全机制，确保运行时的系统安全。
AI 智能体的部署应逐步执行，以管理风险。考虑不同的部署战略，例如蓝绿、滚动或金丝雀部署，以确定哪种策略最有利于您的使用流量模式。在真实的商业环境中，稳定性必须始终是首要考虑因素：将部署过程仔细划分为多个阶段，可以验证系统对有意义更新的灵活性。
沙盒隔离指将智能体及其配套工具运行在受限执行环境中，严格限制其操作范围与能力，环境对计算、存储、网络、系统应用程序接口强制实行最小权限访问。即使智能体出现故障或异常操作，完善的沙盒隔离也能最大限度缩小问题波及范围与影响程度。若智能体的工具误用、代码生成、数据转换操作会影响代码库、数据完整性、客户数据或其他智能体，沙盒隔离是必不可少的管控手段。
沙盒化的常见实施策略包括：
轻量级虚拟化
容器安全配置文件
网络控制（通常依托 MCP 网关实现）
文件系统访问策略
网关层级规范执行
您的 AI 智能体完全成功部署后，ADLC 没有结束。与编程与构建阶段和测试与发布阶段形成的迭代循环类似，部署与运行阶段也应该被理解为持续反馈循环的两个部分。初始构建/测试循环的最终目标是让智能体满足实现预期业务成果所需的最低性能阈值，而部署/运行循环的目标是优化。
上线部署后，需持续开展运行监控，保障智能体在真实业务环境中稳定、高效、安全运行。统一报表仪表板汇总实时指标并开放查询，需持续监控模型漂移与性能衰减问题。运行效率、终端用户反馈出现明显下滑时，需及时介入处理。针对突发问题产出的优化方案，需完成全面测试后分阶段灰度上线。
全栈可观测性对智能体系统至关重要，因为智能体系统不仅能实现最佳性能、安全性和可靠性，还能将这些特性长期保持。
一旦您的智能体实施在实际生产中得到充分验证和优化，就应持续进行公平性、透明度、安全风险和合规性的审计，同时评估整体表现。
行业标准与法律法规持续更新，未能同步跟进会引发监管处罚、丧失行业竞争优势，或两者同时发生。模型漂移是一种无法完全规避的现象，最优应对方式为主动前置管控。随着业务需求持续变动，配套的智能体系统也需同步迭代适配。
为了满足当前和未来的需求，企业应该建立一个清晰有序的智能体和工具目录，其中应注明：
所有权，以辅助问责制和问题上报
版本，用于规范的变更管理实践
风险态势，为决策提供信息
覆盖全部业务环境，实现全方位运行监控
可审计能力，加速取证、评估、审批与红队安全测试流程
构建、部署和管理强大的 AI 助手和智能体，运用生成式 AI 实现工作流和流程自动化。
借助值得信赖的 AI 解决方案，您可以勾勒未来业务发展蓝图。
IBM Consulting AI 服务有助于重塑企业利用 AI 实现转型的方式。
1. “The State of AI Inference Strategies: Optimizing Deployment, Performance, and Impact”，Omdia，2026 年 4 月 17 日