作者：来自 Elastic Sumana MannemJames Spiteri
在 Elasticsearch 中原生统一脚本化自动化和 AI agents。消除集成，直接对你的数据采取行动。
今天，我们正式推出 Elastic Workflows，这是直接内置在 Elasticsearch 中的自动化引擎。Workflows 为简单任务提供可靠的脚本化自动化，并为需要推理的复杂问题提供由 AI 驱动的自动化。
Elastic Workflows 现已以 技术预览 形式提供。
挑战：数据孤岛和被迫的权衡
组织需要自动化来跟上当今数字环境的复杂性。但大多数自动化解决方案都存在两个主要限制。
- 自动化通常与运行数据分离。这意味着团队必须构建并维护集成，才能为自动化提供所需的上下文。数据必须在系统之间导出、同步或查询。凭证需要单独管理。当上游发生变化时，集成就会中断。维护这些集成会增加不必要的工作量。
- 团队还面临可靠性与推理能力之间的权衡。传统自动化可以可预测地处理已定义的任务 ------ 每次都以相同方式运行，这正是成熟流程所需要的。但当遇到意外情况时，它无法适应。没有判断，没有解释，只有预定义逻辑。
由 AI 驱动的工具承诺填补这一空白。它们可以在没有明确指令的情况下对模糊情况进行推理、权衡选项并建议下一步。但它们往往缺乏关键业务流程所需的精度和可预测性。而且其中大多数距离你的数据更远，又增加了一层需要管理的集成。
直到现在，组织要么在这些方法之间做出选择，要么尝试通过中间件和自定义代码将它们拼接在一起。Elastic Workflows 通过在单一系统中同时提供这两种能力，消除了这种选择。
Elastic Workflows：数据、上下文和行动统一
Elastic Workflows 通过将自动化引擎直接带到你数据所在的位置来解决这些问题。无需导出管道、无需中间件，也无需管理单独的安全模型。当工作流需要上下文时，它已经在那里。
工作流使用 YAML 定义，既足够简单，便于进行版本控制和审查，又足够有表现力，能够处理真实的运维逻辑。它们由内置引擎执行，该引擎为企业级可靠性和规模而设计。
工作流是完全可组合且事件驱动的。它们可以响应 Elasticsearch 中数据的变化、通过 webhook 接收来自外部 system 的事件，或响应由用户发起的操作。你可以将工作流串联起来、进行嵌套，或将它们暴露为可被其他 system 调用的 tool。
在运行后，工作流会连接到你组织已经使用的外部 system，包括云提供商、服务台、消息平台和身份提供商。但 Elasticsearch 始终处于中心位置，因此工作流中的每一步都可以访问你环境的完整上下文。
结果是一个更简单的架构，具有更少的移动部件，并且执行更快，因为获取基础上下文时不需要往返外部 system。同时，可出问题的地方也更少，因为你不再维护一张复杂的集成网络。
用于智能自动化的 workflows 和 agents
在 Elasticsearch 上将自动化和 AI 统一的架构，使一件一直很难实现的事情成为可能：在同一个流程中，将可预测执行的可靠性与 AI 推理的灵活性结合起来。
它的工作方式是这样的。workflow 负责处理流程中结构化的部分 ------ 每次都应该以相同方式运行的步骤。当 workflow 运行到需要判断的节点时，它可以调用一个 AI agent 来分析可用的上下文并决定下一步该怎么做。agent 基于数据进行推理，做出决策，并返回结果。然后 workflow 根据这个输入继续执行。
这种集成是双向的。workflows 可以在更大的流程中把 agents 作为智能步骤来调用。而 agents 也可以把 workflows 当作 tools 来调用，从而具备采取具体行动的能力 ------ 不只是生成文本，而是真正在你组织运行的各个 系统 中执行操作。
Elastic Workflows 通过与 Elastic Agent Builder 的集成获得其 agentic 能力。Agent Builder 是 Elasticsearch 中用于创建自定义 AI agents 的原生能力。使用 Agent Builder 构建的 agents 可以访问与 workflows 相同的数据和上下文，这意味着它们可以做出更好的决策。并且由于 workflows 和 agents 都运行在同一平台上，推理与执行之间不存在集成断层。
与标准 AI 工具通常只生成建议不同，Elastic Workflows 使 agents 能够采取行动，例如重启服务、更新记录、发送通知或触发另一个 workflow。
为构建 agents 的开发者
AI 的进步使开发者能够构建比以前强大得多的 agents，从而自动化更多任务。agents 不再只是用于聊天；它们现在可以自行做出决策并采取行动。然而，许多 agent 构建框架要求大语言模型（ LLMs ）规划和管理自动化的每一个步骤。虽然 AI 擅长推理，但它缺乏业务通常需要的、已定义动作所具备的可靠性。
Workflows 可以通过 MCP 作为 tools 提供给 agent，从而弥补这一差距。Workflows 是 agents 的 "手"，让 agents 能够以可靠的方式与 各种系统 交互，执行操作并收集信息。
Workflows 帮助开发者将复杂流程转化为可预测、可复用的 tools，用于信息收集和执行操作。例如，构建 agent 应用通常需要通过运行符合公司标准的内部和外部系统流程来获取信息。Workflows 通过将复杂流程转化为可预测、可复用的动作来解决这一问题，例如集成企业数据、调用服务、关联信号以及更新记录。这简化了多种搜索和自动化任务，如客户支持分流、内容上传和业务逻辑自动化。它使基于 Elasticsearch 构建的应用能够智能地响应不清晰的请求，同时由 Workflows 提供支撑这些决策所需的可靠执行能力。
为安全分析师
安全分析师需要处理源源不断的告警，而大量初始分流工作都遵循可预测的模式：为告警补充上下文、检查相关活动、拉取资产和身份信息、更新案件，并通知合适的人员。这正是自动化应该处理的工作类型。
Workflows 让安全团队能够以完全的控制力和可预测性将这些流程编码化。常规步骤始终会自动且一致地执行。
但调查并不总是常规的。有时告警不符合任何已知模式。有时攻击者采用了新的手法。在这些情况下，分析师通常需要从零开始，手动收集日志、追踪用户行为、在多个系统之间关联信号，并形成对事件经过的假设。
这正是 workflows 与 agents 结合改变局面的地方。分析师不再从一张空白屏幕开始，而是由 agent 先完成早期准备工作：审查证据、识别异常模式、检查预期的控制是否到位，并建议哪些线索值得继续深入。workflow 保持整体流程的结构化和可审计性，而 agent 负责处理不确定性。
分析师仍然保持控制权，但起点更高 ------ 已经组装好上下文，并且有可供评估的初始假设，而不是从零开始构建。
对于 SREs
运维团队大量自动化：健康检查、容量决策、告警路由和修复手册。这些流程在已知模式下保持服务平稳运行。
但并非每个事件都有模式。复杂的性能下降、意外回归和级联故障 ------ 这些情况很少有明确的操作手册。操作人员通常必须从零开始调查，跨仪表板和工具关联数据，以弄清实际发生了什么。
使用 workflows 和 agents，调查可以更快开始。一个可以访问你的日志、指标和 trace 的 agent 可以扫描最近部署，识别关联异常，并提出最可能的解释。操作人员不必手动组装上下文，而是从一个假设和支持证据开始。
如果假设成立，workflow 可以继续执行修复操作，如回滚变更、扩展服务或调整配置。agent 提供判断，workflow 提供执行。操作人员保持在环中，批准关键决策并在需要时干预。
结果是在不放弃监督或控制的情况下，更快地解决问题。
开始使用 Elastic Workflows
Elastic Workflows 现已作为技术预览提供。你可以从 Elastic Cloud 试用开始，并查看文档。
我们正在持续构建预制 workflows 和 agent 集成，以帮助团队自动化更多工作。如果你一直在寻找一种方法，将自动化更贴近你的数据，同时不牺牲可靠性或灵活性，这是一个很好的起点。
如需更深入的技术细节，请参阅 Workflows技术博客。
本文中描述的任何功能或特性的发布和时间完全由 Elastic 自行决定。任何当前不可用的功能可能无法按时提供，甚至可能永远不会提供。
在本文中，我们可能使用或提及了第三方生成式 AI 工具，这些工具由各自所有者拥有和运营。Elastic 对这些第三方工具没有任何控制，也不对其内容、操作或使用承担责任，也不对你使用这些工具可能产生的任何损失或损害负责。请在使用包含个人、敏感或机密信息的 AI 工具时谨慎操作。你提交的任何数据可能会用于 AI 训练或其他用途。无法保证你提供的信息会被安全或保密地保存。在使用任何生成式 AI 工具之前，你应了解其隐私政策和使用条款。
Elastic、Elasticsearch 及相关商标是 Elasticsearch B.V. 在美国及其他国家的商标、徽标或注册商标。所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。
原文：https://www.elastic.co/search-labs/blog/elastic-workflows-automation