AI Agent引爆企业效率革命！告别繁琐编码，拥抱自然语言工作流。利用LLM模型，企业可快速构建分类器、文本生成器，驱动业务流程自动化。低代码平台如ServiceNow崛起，Spring AI等框架助力高代码复制。微服务到纳米服务，Model Context Protocol赋能，企业应用开发迎来“Agentic”新纪元！
译自：AI Agents: Why Workflows Are the LLM Use Case to Watch
作者：Jonathan Eyler-Werve
在现代企业中，有一个默默无闻的英雄：工作流。它有时被称为规则引擎、流程流、单状态机或软件定义的工作流。在用户界面 (UI) 中，它是一个“向导”。开发人员经常（有些不屑地）称其为“业务逻辑”。
我想请您花点时间欣赏一下这位默默无闻的英雄的庄严，因为我们即将把硅谷炙手可热的炒作之光投向它的家门口：AI 代理。
关于 AI、大型语言模型 (LLM) 和代理应用程序的文章已经很多了，很难相信我们中有多少人（是的，包括我）仍然对它们感到困惑。但我们感到困惑是有充分理由的：AI 代理是我们默默无闻的业务英雄——工作流——的一个实现细节。
代理是如何。工作流是什么。
这种区别至关重要，因为 AI 代理可以被定义 得非常简单明了：您的业务应用程序在整个工作流程中使用基础模型。我们在 Anthropic 的朋友区分了代理工作流和代理，其中代理可以循环和分支，并且具有一定的自主性。以我的经验，业务工作流也会这样做；这是一个模糊的界限。
让我们来谈谈 AI 如何改变工作流应用程序
代理应用程序使用基础模型来识别在工作流程中进行干预的位置。例如：基础模型可以是非常出色的分类器，用更灵活、开箱即用的高性能模型取代费力编码的规则集或监督学习模型。
将基础模型指向电子邮件收件箱或帐户摘要，然后开始询问：当前情况是应用程序知道如何处理的吗？是否应根据非技术业务专家编写的规则升级此案例？此项目应该进入专家质量控制 (QC) 流程，还是默认 QC 流程？这封电子邮件是垃圾邮件吗？骚扰？销售机会？客户流失风险？
此处的模型输出是“是”或“否”，与聊天机器人相比，这带来的准确性风险要小得多。这是您可以立即交付的东西，具有安全性和可衡量的结果。
有效、廉价的自然语言分类器的突然出现将加速许多企业应用程序，因为企业想要什么与在软件中编码的规则之间的距离目前是财富 500 强公司中人类痛苦的主要来源。事情被错误地听到。事情会衰退并失去同步。技术约束向上游流动并被编码到业务流程中。
代理应用程序弥合了我们的意图和软件之间的差距，因为大部分业务逻辑可以用自然语言表示，从而邀请新的利益相关者和贡献者参与到软件开发过程中。它与 1985 年左右电子表格的出现以及 2005 年左右协作电子表格的出现一样，是企业内部权力的一次重大转变。
企业中到处都是小而昂贵的工作流程故障，而 AI 代理为应用程序开发人员提供了一套强大的工具来解决这些问题。
但对于工作流程而言，代理的意义不仅仅是分类器！它们还可以开始评估输出（问题真的解决了吗？），充当文本生成器（这是一个系统事件日志，变成了状态更新），有时甚至可以通过执行函数（预订会议、更新库存、调度卡车）来启动操作。
所有这些都可以通过传统的业务软件和人工队列来完成，但通常很难做到正确，而且成本非常高。
低代码时刻和高代码未来
AI 正在经历一个消费者聊天机器人的文化时刻，并且在代码助手方面取得了一些进展。我们尚未看到的是——今年可能会发生的事情——AI 的采用从软件和少数其他领域扩展到其他业务垂直领域，特别是那些似乎在企业内部产生最多自定义应用程序的运营层。
根据其财务披露，第一家看到 AI 投资获得正回报的公司不是纯粹的技术公司。它是一家运营软件即服务 (SaaS) 提供商，ServiceNow。它与 Workday 和 Salesforce 一起，正在提供一个低代码桥梁，连接非技术主题专家记录的业务意图和软件自动化。AI 正在提供帮助。
感谢这些先行者为此所做的努力。我认为这会遵循大多数低代码解决方案的模式，这些方案承诺赋予业务用户权力并削减 IT 支出，但同时也存在对平台供应商的重大依赖。
我认为下一波浪潮将是对这些工作流引擎的高代码复制，因为它实现起来并不难。开放的基础模型和现有框架（包括我的团队维护的 Spring AI）可以让一个团队在几天内启动。这可能看起来像一个用于业务任务工作流的大型 GUI 平台，但更快、更安全的路径是找到小的、可交付的干预点……无处不在。而且今天看起来比几年前更轻量、更快。
一个假设的 Agentic 应用：比你想象的要小
想象一下，一个客户购买了一个室内自行车训练器，并且已经发货。管理自行车的软件无法连接。客户要求退货，然后我们就开始邮寄自行车。但如果这是一个已知问题，并且有可用的解决方案呢？更新一些固件，就可以骑了。
您在支持过程中的人工可能会识别出这一点，但并不完美。很难每次都知道每个问题。
因此，我们构建了一个小型应用程序来查找此问题并修复它。首先，我们构建一个监听器，标记此已知问题的可能事件。如果它检测到一个案例，它会在支持系统中插入一条消息，其中包含指向解决方案的链接。现在尝试足够安全，并且有可衡量的结果。如果代理有良好的记录，可能会变得更加自信。我们可以将建议的解决方案直接通过电子邮件发送给客户吗？除非人工支持人员确认问题，否则我们可以暂停退货吗？代理是否可以开始更准确地识别可能的问题，链接到特定的固件版本或以其他方式改进向客户发送的消息？
企业中到处都是小而昂贵的工作流程故障，而 AI 代理为应用程序开发人员提供了一套强大的工具来解决这些问题。
你需要一个平台
那么，我们如何才能更接近这样一个世界：您的应用程序开发人员有权在您的业务中部署小助手？
您可以首先询问为什么他们没有在没有 LLM 的情况下快速部署小型实验。这通常看起来像是开发体验的故事：自助服务配置、有据可查的生产黄金路径、强大的测试自动化以及安全和法律监督的预先批准的通道。如果应用程序团队有权以最小的外部依赖性交付小的、持续的改进，那么事情就会进展得很快。
我们如何将此应用于我们的 agentic 应用程序未来？首先，我们需要将自助服务模式和开发人员授权围绕我们新的好朋友——基础模型。我们看到数据科学或 AI 工作组与全栈应用程序开发团队之间出现了能力分离。在我看来，这是一种健康的角色专业化：有模型提供商，有机器学习 (ML) 运维模型基础设施团队，还有使用这些资源的应用程序。前两者可能是即服务外部供应商；应用程序团队不会是。
为了使模型提供商和应用程序团队之间的这种抽象能够工作，您需要处理反馈、可观测性、版本控制和其他问题；通过正式的 API 或至少良好的工作协议。您不希望每个应用程序团队都孤立地解决这个问题；您可能需要一个 AI 框架，但您不需要 50 个相互竞争、资源不足的 AI 框架。
我还认为像 AI 网关这样的中间件平台发挥着作用，它可以促进整个组织的配置、可观测性、模型反馈和隐私保护。
未来：微服务到纳米服务
如果配置和平台化得到解决，我们将一头扎进这样一个世界：我们有很多企业数据的非常薄的包装器，这些数据过去是被锁定的，并且我们有 agentic 应用程序可以以巧妙的方式访问它们。小型解决方案开始遍地开花。
一个非常轻量级的工具包装器的示例，其中包含关于基础模型如何与其交互的自然语言指令。
这与我们之前在云原生架构和通过 API 通信的微服务中遇到的情况类似。不同之处在于工作规模；我们正在从微观转向纳米。非常薄的包装器，例如 模型上下文协议（Model Context Protocol），允许基础模型请求数据并执行操作。非常轻量级的工作流应用程序允许业务用户用自然语言解释应该发生什么。平台按需提供安全性、安全性和适当的模型。您可以在几天内交付，而不是几个月，并不断迭代直到它工作。
这里的重点是，代理应用革命不是一个将改变前沿科技公司的故事。这是一个现代化故事；一个利用现有团队解决现有企业中小型问题的机会。
