> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # AgentOps：软件开发新的抽象层 - URL: https://www.hubwiz.com/blog/agentops-new-abstraction-layer/ - Published: 2025-04-30T09:51:34.000Z - Updated: 2025-04-30T09:51:34.000Z - Description: 我们将进入一个开发者更少关注实现细节，而更多关注意图和结果的时代。这将从根本上改变我们在软件开发中解决问题的方式。 - Author: admin - Tags: APPLICATION, AGENT, #Import 2026-10-14 14:41 当我本周早些时候发表《AgentOps时代》时，我完全不知道OpenAI几天后即将发布他们的《构建代理的实用指南》。作为一名在自动化领域工作多年的从业者，我立即意识到这个巧合意义重大——我认为我们正在见证软件构建方式的一次变革。 这两篇文章都指向了同一个结论：我们将进入一个开发者更少关注实现细节，而更多关注意图和结果的时代。这让我想起了早期使用Puppet和Ansible的日子，但这次提升到了一个新的高度。最让我感兴趣的是看到计算历史中抽象的下一个主要层次的出现，这将从根本上改变我们在软件开发中解决问题的方式。 ## 1、抽象的演变 你可以把计算历史看作是一系列的抽象层，每一层都让开发者从低级的关注中解脱出来。我们从二进制发展到汇编语言，然后到过程式和面向对象的编程语言。每一次转变都提升了我们的视角（那是一个里程碑），让我们能够专注于解决越来越复杂的问题，而不是管理实现的细节。 在过去十年里，我们见证了另一个重要的抽象层的诞生——即基础设施即代码（IaC）。通过Puppet、Chef、Salt和Ansible等工具，我们不再考虑服务器配置命令，而是开始描述期望的状态。“我希望有三台运行nginx的web服务器”取代了冗长的手动设置程序。基础设施简单地遵循我们的声明。 AgentOps代表了这一抽象演化的下一步。正如IaC让我们摆脱了对服务器配置的担忧一样，AgentOps让我们摆脱了应用程序级别实现的具体细节。这里的基本转变是深远的：我们不再指定具体的步骤（“当用户点击这个按钮时，验证这个表单，然后调用这个API”），而是定义目标、边界和可用的工具——然后让代理在这些约束内确定如何完成任务。 这完全提升了我们的关注点，从编写程序转移到协调能力。（现在你明白了整个CRAINE的概念了吧？） ## 2、基础设施自动化的见解 我在使用Puppet和Ansible等IaC工具方面的工作为我们今天所看到的AgentOps提供了有价值的见解。这两个转变都共享一个基本特征：它们将我们的注意力从实现转向意图。使用Ansible时，我不再编写执行特定命令的脚本，而是编写一个描述期望状态的YAML文件。当它起作用时，我不必担心它——系统会想办法让它成为现实。对我来说，AgentOps的类比非常明显。我们不再定义每一个小的UI交互和系统调用，而是描述目标，并为代理提供所需的工具和护栏。 使这一刻如此具有革命性的是抽象的范围。基础设施自动化应用了声明式原则于定义明确且变量有限的领域。AgentOps则将类似的原则应用于更加复杂、开放的任务，其模糊性显著增加。使Puppet和Ansible发挥作用的工具也需要嵌入特定领域的知识在其设计中——例如知道EC2是如何工作的。今天驱动代理的大规模语言模型带来了可以应用于几乎任何领域的通用推理能力。 ## 3、新的开发者体验 在AgentOps中，开发者关注三个核心元素：设定清晰的目标，给予代理适当的工具，并启用有效的护栏。 OpenAI的指南很好地说明了这个概念，强调了开发重点从实现细节转向指令设计的变化。例如，与其为客服工作流编写一堆API调用，我们定义客服政策，连接相关数据源和操作工具，然后建立代理行为的界限。"如何做"成为了代理的责任（在一定程度上）；我们的工作是定义"做什么"和"为什么"。 考虑一个实际的例子：构建支持工单解决系统。传统方法涉及编写代码来处理表单提交、验证输入、查询数据库、基于规则集触发特定动作，并在整个过程中管理UI状态。 在AgentOps中，我们转而定义成功标准（"高效解决客户问题，同时保持满意度"），提供对知识库和操作工具的访问，并指定护栏（"未经批准不得发行超过$X的退款"）。这代表了我们解决问题方式的根本转变——从实施解决方案到协调能力。 ## 4、黑盒挑战 这种更高层次的抽象引入了新的挑战，特别是在调试和可预测性方面。 与IaC不同，IaC的操作是确定性的，而代理的行为可能因输入或上下文的细微差异而有所不同。当Ansible剧本出现问题时，错误消息是具体且与定义良好的操作相关的。当代理失败时，理解原因可能会更加复杂。OpenAI建议通过分层护栏和人工监督来解决这个问题——认识到这种更高的抽象需要新的方法来确保可靠性。 采用AgentOps的组织需要开发新的调试思维模型，这些模型较少关注代码路径，而更多关注目标对齐和约束设计。 ## 5、人机协作 在这其中，人类与代理之间的关系可能是最重要的转变。OpenAI的指南非常重视深思熟虑的人类监督，而非完全自主。 在IaC中，系统以确定性的方式执行，无需任何人为干预。相比之下，代理系统受益于一种更协作的模式，在关键时刻提供人类指导。这种方法承认了当前AI能力的力量和局限性。 我发现最成功的代理实现建立了明确的升级路径——精确定义何时以及如何在决策过程中涉及人类。这创造了一种强大的共生关系：代理以速度和一致性处理例行任务，而人类在需要判断和问责的地方贡献智慧，尤其是在高风险决策或超出定义参数的边缘案例中。 ## 6、组织准备 采用AgentOps需要的技术实施之外的组织调整。 向IaC的过渡教会了我技术转变的成功与否取决于组织准备情况。习惯于传统开发方法的团队需要时间来适应他们的思维模型。这意味着重新思考需求收集和规格制定的方式，测试和质量保证流程的工作方式，甚至重新定义开发团队中的角色。成功采用基础设施自动化方法的组织专注于增量转型，从小范围、明确定义的用例开始，然后逐步扩展。 AgentOps的采用也是如此。从代理智能明确增值的离散、有限的工作流程开始，然后随着团队在这个新范式下积累经验逐渐扩展。在技术实施和团队能力上投入同等精力。归根结底，这是一种从根本上不同的软件开发思维方式。 ## 7、成本和治理考虑 AgentOps引入了以前抽象层不存在的新经济和治理考虑因素。与基础设施自动化不同，基础设施自动化中的计算成本遵循相对可预测的模式，LLM驱动的代理引入了与提示复杂性、令牌使用和推断要求相关的可变执行成本。这需要新的预算和优化方法。 同样，治理变得更加微妙——如何在能力各异的代理之间建立一致的政策？OpenAI的指南强调了分层护栏的重要性，从输入验证到安全分类器。我的经验表明，组织应建立中央Agent Ops治理团队。负责定义组织范围内的政策，类似于云卓越中心在云采用过程中出现的方式。这些团队可以开发标准模板，分享最佳实践，并在整个过程中保持监督，同时仍在既定的护栏内推动创新。 ## 8、结束语 我们正处于软件构建方式深刻变革的开端。正如十年前基础设施即代码改变了运维一样，AgentOps通过将抽象提升到新的高度，在应用程序开发中也做出了同样的承诺——这也是“Craine”这个名字的由来。 这一转变不会一夜之间发生，但我的AgentOps理论与OpenAI的实际指南之间的契合表明行业正在加速发展。在这个新时代中蓬勃发展的组织将是那些拥抱从实现到意图转变的组织，投资于有效协调基于代理系统的技能和流程。 对于开发者来说，这意味着培养明确目标设定、适当工具选择和有效护栏设计的专业知识。对于组织而言，这意味着培育一种平衡创新与治理的文化。在以往的时代中，那些改变计算的抽象化解锁了巨大的新能力。 AgentOps承诺做同样的事情——通过将注意力集中在最重要的地方：我们要完成什么，而不是如何完成它，使我们能够构建比以往任何时候都更智能、更具适应性的系统。 --- 原文链接：[AgentOps: The Next Layer of Abstraction](https://medium.com/craine-operators-blog/agentops-the-next-layer-of-abstraction-d82e359c6a44?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处