本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 不断演进的代理人工智能软件交付
现代软件交付是由一个简单的假设塑造的，那就是您可以控制自己交付的系统。您可以定义需求，编写逻辑，根据预期结果进行测试，并部署可预测的服务。即使是敏捷和 DevOps 方法也仍然依赖于这样一个原则，即每个冲刺都能提供确定性、可验证的东西，并且在很大程度上处于人类监督之下。
Agentic AI 颠覆了这一基础。代理系统解释、推理和改编，而不是遵循脚本。他们的行为取决于你编写的代码、他们操作的上下文、他们获得的输入、他们可以访问的工具以及他们被分配的目标。简而言之，他们不听从命令；他们追求结果。
这使得交付与其说是控制，不如说是对齐。与其提供说明，不如塑造它的行为方式。这意味着传统的软件开发生命周期 (SDLC) 不再适合，因为它是为基于逻辑的、人为控制的系统设计的。
**Topics**
+ [代理人工智能的意向区域](#software-delivery-zones)
+ [改变代理人工智能的交付生命周期](#software-delivery-evolution)
+ [让团队为代理人工智能做好准备](#software-delivery-preparation)
## 代理人工智能的意向区域
我们需要的不是*定义*、*构建*、*测试*和*发布*等僵化的阶段，而是包含自主性、不确定性和出现性的模型。相反，你使用意图区域。*意图的 z 定义了一个有限的*空间，在这个空间中，代理可以在约束条件下自主地进行操作。目标是从微观管理每项任务转变为设计支持人员可以安全地行动、学习和协作的环境。您可以指定什么（期望的结果）、原因（意图）和护栏（约束、策略和信任边界）。考虑到这些界限和这些信息，代理商会弄清楚如何做。
与其说是装配线，不如将环境视为空域。你可以控制谁可以进入，他们能做什么，以及他们可以去哪里。但是一旦进去，他们就可以根据需要自由导航。这就是代理系统在没有混乱的情况下扩展的方式。
这不仅仅是哲学上的转变；更是一种实际的转变。无法通过单元测试对基于代理的系统的非确定性输出进行全面测试。它不能像静态二进制文件那样进行版本控制。代理会随着时间的推移而变化，适应新数据，并以不可预测的方式与其他系统交互。试图使用传统模型交付它们会导致架构脆弱、无法扩展。在最坏的情况下，它会导致人们对你无法实际治理的系统的错误信心。
当团队采用基于意图的交付时，他们将获得两个优势：
+ **控制最重要的地方** ——他们定义界限而不是输出。
+ **通过委托实现可扩展性** — 它们使代理能够处理人类无法硬编码的复杂性。
这就是你如何从孤立的原型转变为真实的生产级代理系统，这些系统可以反复可靠地提供价值。
## 改变代理人工智能的交付生命周期
为了支持智能的自适应行为，必须将 SDLC 从确定性控制转变为自适应意图。以下是发展适用于代理人工智能的传统 SDLC 所必需的更改：
+ *规划*变成*意图设计*。团队定义目标、限制和预期的代理行为。政策和成功标准是根据一致性而不是逻辑来制定的。
+ *建筑*变成了*脚手架*。团队专注于定义角色、接口、护栏、后备机制和可观察性，而不是编写每条决策路径的脚本。
+ *测试*变成*行为评估*。团队不是断言具体的产出，而是验证代理人是否保持在可接受的范围内，并在不同的输入下实现意图。
+ *部署*变成了*持续的编排*。Agentic 系统部署了运行时控制、实时监控和反馈通道，可实现实时调整。
+ *迭代*变成了*反馈*和*适应*。团队不是传统的代码更改补丁周期，而是观察代理是如何演变的、他们在哪里成功或何时漂移。必要时，团队会通过更新约束、再培训以及添加或修改控制机制进行干预。
侧重于迭代、实验和快速反馈的现有实践已经过时了。向代理系统的转变并不是对敏捷原则的拒绝。实际上，这是它们的自然演变。敏捷思维强调适应性、反馈和可行的解决方案，而不是僵化的计划。这与代理系统的本质完全一致，代理系统可以实时学习、适应和响应上下文。如果你已经在运行较短的周期，快速验证假设并通过持续交付来管理不确定性，那么你完全有能力领导这种过渡。
但是有一些关键的区别。传统的敏捷方法假设交付的东西是确定性的。它假设，一旦建成，事物就会表现得一致且可预测，对于相同的输入，结果是可重复的。这种可重复性可帮助您放心地进行调试、测试和迭代。代理系统打破了这种模式。它们具有概率性、上下文敏感性，并且能够独立演变。这意味着一些敏捷实践变得不那么有用了，例如基于故事完成的速度跟踪、严格的验收标准或确定性的冲刺计划。
传统 SDLC 的以下方面适用于代理人工智能：
+ 迭代开发和交付
+ 将客户反馈作为主要信号
+ 跨职能协作
+ 持续集成和部署
对于代理人工智能，传统 SDLC 的以下方面必须不断发展：
+ 将*完成*重新定义为*与意图一致。*重点关注代理的行为是否在定义的限制条件下满足其预期目标。
+ 从接受标准转向行为护栏。
+ 将 d *on* e 的定义扩展到包括运行时就绪性，其中包括支持持续学习和信任的可观察性、可解释性和反馈机制。
+ 优先考虑实时反馈回路和行为跟踪，而不是前期规划
好消息是你不需要抛弃 SDLC 剧本。你只需要将其从管理规范发展到塑造行为即可。在代理系统中，成功不仅在于软件能否运行，还在于软件的行为方式。
## 让团队为代理人工智能做好准备
软件工程不会消失。它在不断演变。工作从编写函数转向塑造智能行为的框架和控制机制。在代理人工智能的世界中，建筑不再是困难的部分，管理崛起才是困难的部分。对于大多数工程团队来说，这种演变感觉就像是思维方式的转变，而不是技术上的飞跃。而不是问 “系统会做什么？” 问题变成了 “我们授权它追求什么，我们如何知道它是否保持正轨？”
对于工程团队而言，向代理 AI 的演变需要进行以下更改：
+ **文化转变** ——团队必须适应他们无法完全控制的系统中的不确定性和自主权。
+ **新角色** ——意图设计师、行为测试人员和可观察性工程师成为交付的核心。
+ **共享语言** — 团队需要对目标、护栏和成功信号有清晰、共同的理解，就像他们曾经需要规格和测试用例一样。
随着生成式人工智能的成熟，我们将看到更多的代理系统与客户、产品和运营进行交互。成功的组织不会是拥有最佳模式的组织。它将能够自信、控制和快速地将代理集成到现实世界的工作流程中。这意味着交付模型和工程团队必须共同发展。意图区域可以让你抽象地做到这一点。它们可以帮助您在不放弃问责制的情况下实现自主权。他们还提供了跨团队共享的框架，以帮助管理无法硬编码的系统。
有关让团队为代理人工智能做好准备的更多信息，请参阅本[指南的为大规模代理 AI 做好业务](preparing-business.md)准备部分。