精选

照片由 Jonathan Kemper 拍摄，来自 Unsplash

在发布《代理操作的时代》时，我完全没有想到OpenAI会在几天后发布他们的《构建代理的实用指南》。作为一名自动化领域的资深人士，我立刻意识到这种巧合意义非凡——我认为我们正在见证软件构建方式的一次重大变革。这两篇文章都指向了同一个结论：我们正步入一个开发人员将更少关注实现细节，而更多关注描述意图和结果的时代。这让我想起了我早期使用Puppet和Ansible的经历，但显然已经提升到了一个全新层次。最让我感兴趣的是，我看到了计算历史上的又一层新的抽象层次出现，这一层将从根本上改变我们在软件开发中解决问题的方式。

这张照片由 Didssph 在 Unsplash 上发布

可以把计算历史视为一系列抽象，每一层都让开发人员从更低级别的细节中解脱出来。我们从二进制移至汇编语言，然后是过程化和面向对象的编程语言。每次过渡都提升了我们的视角（就像一根不断攀升的柱子），让我们能够专注于解决越来越复杂的问题，而不是纠结于具体的实现细节。在过去十年中，我们见证了另一层重要的抽象化，当基础设施即代码（IaC）出现时。借助Puppet、Chef、SaltStack和Ansible等工具，我们不再纠结于服务器配置命令，而是开始描述期望的状态。“我希望有三个运行着nginx的web服务器”取代了冗长的手动设置过程。基础设施简单地按照我们的声明来。

AgentOps 代表了这种抽象演变的下一步。就像 IaC 让我们不必担心服务器配置一样，AgentOps 让我们从应用层面的具体实现中解脱出来。这里的一个根本转变是极其深刻的：我们不再指定具体的步骤（“当用户点击此按钮时，验证此表单，然后调用此 API”），而是定义目标、边界和可用工具——然后我们让代理在这些限制内决定如何达成目标。这将我们关注点完全从编写程序代码转移到协调能力上。（如你所见，现在你应该开始理解整个 CRAINE 概念了吧？）

我使用Puppet和Ansible等IaC工具的工作经历为今天AgentOps的发展提供了宝贵见解。两者都共享一个基本特征：它们将我们的关注点从实施转移到意图。使用Ansible时，我停止编写具体的命令脚本，而是编写了一个描述所需状态的YAML配置文件。当一切顺利时，我不必再担心它——系统会自行找到实现该状态的途径。对我来说，这与AgentOps的相似之处显而易见。我们不再定义每一个细小的UI交互和系统调用，而是描述目标，并为代理提供所需的工具和边界。

正是这种抽象的广泛性使得这一刻如此革命性。基础设施自动化将声明性原则应用于定义明确且变量有限的特定领域。AgentOps 将类似的原则应用于更复杂、开放且不确定性更大的任务。使 Puppet 和 Ansible 能运行的工具也需要在其设计中嵌入特定领域的知识——比如了解 EC2 的工作方式。如今大型语言模型驱动的代理具备了可以在任何适当工具和指令的指导下应用于各种领域的通用推理能力。

在AgentOps中，开发人员主要关注三点：明确目标、提供必要的工具、以及设置有效的限制。OpenAI在指南中对此进行了精准的说明，强调开发重心从细节实现转向指令设计。比如，与其编写一系列客服工作流中的API调用，我们定义客服政策，连接相关数据源并提供相应的工具，然后设定代理行为的界限。其中，“如何操作”很大程度上由代理自己负责；我们的任务是明确“做什么”和“为什么”。

考虑一个实际的例子：例如，构建一个支持票处理系统。传统的方法会涉及编写代码来处理表单提交，验证输入数据，查询数据库中的信息，根据规则集触发特定的操作，如执行相应任务，并在整个过程中管理用户界面状态。

使用AgentOps，我们定义了成功标准（“高效解决客户问题同时保持客户满意度”），提供了访问知识库和操作工具的途径，并规定了防护规则（“未经批准不得进行超过$X的退款”）。这代表了我们解决问题方法的根本转变——从实施解决方案转变为协调相关能力。

这种更高层次的抽象带来了新的挑战，特别是在调试和可预测性方面。与 IaC 不同，其中操作是确定性的，代理行为可以根据输入或上下文中的细微差别而变化。当 Ansible playbook 出错时，错误消息是具体且与明确的操作相关的。当代理失败时，找出失败原因可能更加复杂。OpenAI 建议采取分层防护措施和人工监督来应对这一挑战——认识到这种增加的抽象需要新的方法来确保可靠性。采用 AgentOps 的组织需要培养新的调试思维方式，更关注目标对齐和约束条件设计，而不是具体的代码路径。

照片由 Persnickety Prints 拍摄，来自 Unsplash

综上所述，人类与代理之间的关系可能代表了最重要的转变。OpenAI的指南特别关注周到的人类监管，而不是完全自主。在IaC系统中，系统会按照预设规则确定性地执行，不需要任何人工干预。相比之下，代理系统从一个更协作的模型中受益，人类在关键时刻提供指导。这种方法既承认了当前AI技术的强大之处，也认识到其局限性。我发现，最成功的代理实现通常会设立清晰的升级路径——明确规定在何时何地需要人类介入决策过程。这创造了一种强大的共生关系：代理可以快速且一致地处理常规任务，而人类则在必要时提供判断和负责，尤其是在高风险决策或超出预定范围的边缘情况。

采用AgentOps不仅需要技术实现，还需要组织层面的调整。向IaC的过渡让我了解到，技术转型成败取决于组织的准备程度。习惯于传统开发方法的团队需要时间来适应新的思维方式。这意味着需要重新考虑需求的收集和定义、测试和质量保证流程的运作方式，甚至是开发团队中角色的分配方式。成功引入基础设施自动化的组织通常从定义明确的小范围用例开始，然后逐渐扩展，逐步推进。同样的道理，AgentOps的采用也应如此。从代理智能能明显带来好处的小范围工作流程开始，随着团队在新范式中积累经验，逐步扩大范围。在技术实现和团队能力培养上要投入同等的精力。最终，这代表着看待软件开发的一种根本不同的思维方式。

AgentOps 引入了新的经济和治理考量，这些考量在之前的抽象层中并不存在。与基础设施自动化不同，后者计算成本遵循相对可预测的模式，而由大型语言模型（LLM）驱动的代理则带来了与提示复杂性、令牌使用量和推理需求相关的可变执行成本。这需要新的预算和优化方法。同样，治理也变得更加复杂和微妙——如何为具有不同能力的代理建立一致的政策？OpenAI 的指南强调了从输入验证到安全分类器的分层防护措施的重要性。我个人的经验表明，组织应建立中央AgentOps治理团队，以负责定义组织范围内的政策，类似于在云采用早期出现的云中心卓越团队。这些团队可以开发标准模板、分享最佳实践并保持监督，同时在既定的防护措施内促进创新。

我们正站在一个深刻变革的开端，这场变革将彻底改变软件的构建方式。就像十年前基础设施即代码（IaC）彻底改变了运营一样，AgentOps 也在应用开发中通过提升抽象层次来承诺同样的变革——因此有了“Craine”这个名字。这种转变不会一夜之间发生，但我的AgentOps理论与OpenAI的实际指南之间的契合，向我表明了一个加速进行中的行业趋势。在这个新时代中蓬勃发展的组织将是那些拥抱从实施到意图转变的组织，它们将投资于有效管理基于代理系统的所需技能和流程。对于开发人员而言，这意味着要精通明确的目标指定、合适的工具选择和有效的保障措施设计。对于组织而言，这意味着要在创新与治理之间建立平衡的文化。以往的抽象层次变革解锁了计算机技术的巨大新能力。AgentOps也承诺带来同样的影响——通过关注最重要的方面（我们想要达成的目标，而不是达成目标的方法），使我们能够构建比以往任何时候都更智能、更适应的系统。

Jason Clark，Craine Technology Labs的创始人，是一位经验丰富的工程经理和云基础设施方面的专家，拥有超过20年的设计、部署和维护大规模分布式系统的经验。他曾领导专注于云基础设施、容器编排以及DevOps实践的团队。

拥有在 AWS、Azure、GCP、Kubernetes 以及基础设施即代码技术方面的深厚专业知识，Jason 成功地为一些有严格合规性和安全性要求的企业组织实施了云迁移策略。他的工作涵盖从数据中心硬件更新换代到多云优化工作和数字转型项目，还包括各种其它项目。

贾森是一名出版的技术作家，同时也是一位拥有专利的创新者，他采用务实并以经验为驱动的方法来解决复杂的基础设施难题。他的理念是利用开源工具，同时注重运营效率，并在整个合作过程中提升客户的能力。

需要帮助制定云基础设施策略或实施DevOps转型吗？让我们聊一聊，讨论一下我的经验如何帮助您的组织建立安全且合规的基础，支持您的云之旅。访问我的网站craine.io，或通过hello@craine.io给我发邮件。