抽象的进化：AgentOps-CSDN博客

本文链接：https://blog.csdn.net/wireless_com/article/details/148435747

我们，正在进入一个开发人员将更少关注实现细节而更多关注描述意图和结果的时代。这让我想起了原来使用 Puppet 和 Ansible 的日子，但是已经达到了一个全新的水平。最让我感兴趣的是看到计算历史上下一个主要的抽象层的出现，它将从根本上改变我们在软件开发中解决问题的方法。

1.抽象的进化

我们可以将计算机历史视为一系列的抽象，每一层都将开发人员从较低层次的关注中解放出来。从二进制语言转向汇编语言，然后是过程语言和面向对象程序设计语言。每次转换都提升了我们的视角 (这是一个障碍) ，允许我们专注于解决日益复杂的问题，而不是管理实现的细枝末节。在过去的十年中，我们目睹了另一个重要的抽象层，即基础设施即代码 (IaC) 的诞生。使用 Puppet、 Chef和 Ansible 等工具，我们不再考虑服务器配置命令，而是开始描述所需的状态。“我想通过Nginx运行3个服务” 取代了冗长的手动设置过程。基础设施将完全符合我们的预期。

或许，AgentOps 代表了这个抽象演进的下一个逻辑步骤。正如 IaC 使我们不必担心服务器配置一样，AgentOps 使我们不必担心应用程序级别的实现细节。这里的根本转变是深刻的：我们现在定义目标、边界和可用的工具，然后让Agent决定如何在这些限制内完成目标，而不是指定确切的过程，例如，“当用户点击这个按钮时，验证这个表单，然后进行这个 API 调用”。这完全将我们的注意力从编码过程提升到编排功能。

这些转变有一个基本特征：它们将我们的注意力从执行转移到意图上。使用 Ansible 时，我不再编写执行特定命令的脚本，而是编写一个 YAML 来描述我想要的状态。当它起作用的时候，我不必担心其它，因为这个系统知道如何使这个状态成为现实。对我来说，与 AgentOps 的相似之处是显而易见的。我们现在不再定义每一个小的 UI 交互和系统调用，而是描述目标，并为Agent提供它们需要的工具和护栏。

使这一时刻如此具有革命性的是抽象的范围。基础设施自动化将声明性原则应用于具有有限变量的预定义域。AgentOps 将类似的原则应用于更加复杂、开放式的任务，这些任务具有更大的模糊性。使 Puppet 和 Ansible 工作的工具还需要在其设计中嵌入特定的领域知识，例如，知道 ec2 如何工作。今天的 llm 驱动Agent带来了通用的推理能力，这些能力可以通过正确的工具和指令应用于几乎任何领域。

2.新的开发体验

在 AgentOps 中，开发人员关注三个核心要素：设置明确的目标、给予Agent适当的工具以及启用有效的护栏。OpenAI 的指南很好地说明了这个想法，强调了开发如何从实现细节转移到指令设计。例如，我们不需要为客户服务工作流编写一堆 API 调用，而是定义客户服务策略，连接相关的数据源和操作工具，然后为Agent行为建立边界。“如何” 成为Agent的责任 (在一定程度上) ; 我们的工作是定义 “什么” 和 “为什么”。

考虑一个实际的例子：构建一个支持工单的解析系统。传统的方法包括编写代码来处理表单提交、验证输入、查询数据库、基于规则集触发特定操作，以及在整个过程中管理 UI 状态。

在 AgentOps 中，我们转而定义成功的标准，例如“在保持满意度的同时有效地解决客户问题” ，提供知识库和行动工具的访问权，并指定护栏 (“未经批准不退还超过 x 元的款项”)。这代表了我们处理问题的方式的根本性转变ーー从实现解决方案到编排功能。

3.黑匣子的挑战

这种更高层次的抽象引入了新的挑战，特别是在调试和可预测性方面。与操作是确定性的 IaC 不同，Agent行为可以根据输入或上下文的细微差别而变化。当 Ansible 剧本中出现问题时，错误消息是特定的，并且与定义良好的操作相关联。当一个Agent失败时，理解为什么会失败可能要复杂得多。通过建议分层护栏和人工监督可以解决这个问题，认识到这种增加的抽象需要新的方法来确保可靠性。采用 AgentOps 的组织将需要为调试开发新的心智模型，这些模型较少地关注代码路径，而更多地关注目标一致性和约束设计。

3.1人与Agent的协作

在所有这一切中，人类和Agent之间的关系可能代表了最重要的转变。OpenAI 的指南致力于深思熟虑的人类监督，而不是完全的自治。使用 IaC，系统在没有任何人为干预的情况下确定性地执行。而Agent系统受益于一个更具协作性的模型，在这个模型中，人类在关键时刻提供指导。这种方法承认了当前人工智能能力的力量和局限性。最成功的Agent实现建立了清晰的升级路径ーー精确地定义了何时以及如何让人类参与决策过程。这就创造了一种强大的共生关系： Agent以快速和一致的方式处理日常任务，而人类则在需要的时候做出判断并承担责任，特别是对于高风险的决策或超出既定范围的边缘案例。

3.2 组织准备就绪

采用 AgentOps 需要技术实现之外的组织调整。向 IaC 的转变让我明白，技术转变的成败取决于组织的准备状态。习惯于传统开发方法的团队将需要时间来适应他们的心智模型。这意味着重新思考需求是如何收集和指定的，测试和 QA 过程是如何工作的，甚至在开发团队中角色是如何定义的。成功采用基础设施自动化方法的组织关注于增量转换，在扩展之前从狭窄的、定义良好的用例开始。这同样适用于 AgentOps 的采用。从离散的、有界的工作流开始，其中Agent增加了明确的价值，然后随着团队在这个新范例中构建经验的积累而逐渐扩展。在技术实施和团队能力方面平等投资。归根结底，这是对软件开发的一种完全不同的思考方式。

3.3 成本和治理的考虑

AgentOps 引入了新的成本和治理方面的考虑，这在以前的抽象层中是不存在的。与基础设施自动化 (计算成本遵循相对可预测的模式) 不同，llm 驱动的Agent引入了与提示复杂性、令牌使用和推断需求相关的可变执行成本。这就需要新的预算和优化方法。同样，治理变得更加微妙ーー如何在具有不同能力的Agent之间建立一致的策略？分层护栏非常重要，从输入验证到安全分类器。组织应该建立中心 Agent Ops 治理团队，负责定义组织范围内的策略，类似于在云采用过程中专业云团队的出现。这些团队可以开发标准模板，分享最佳实践，并维护监督，同时在已建立的护栏内支持创新。

4.小结

我们正站在软件构建方式发生深刻转变的开端。正如十年前 “基础设施即代码” 改变了运维体系一样，AgentOps 通过将抽象提升到新的高度，承诺在应用程序开发中实现同样的目标。这种转变不会在一夜之间发生，那些拥抱从实现到意图转变的组织，将投资于有效协调基于Agent的系统所需的技能和过程。

对于开发人员来说，这意味着在明确的目标规范、适当的工具选择和有效的护栏设计方面发展专业知识。对于组织来说，这意味着培养平衡创新与治理的文化。从前的时代改变了计算的抽象概念释放了巨大的新能力。AgentOps 承诺做同样的事情，通过将我们的注意力集中在最重要的地方，使我们能够设计出比以往任何时候都更加智能、适应性更强的系统：关注我们想要完成什么，而不是如何完成它。

【关联阅读】