作者来自 Elastic Joe Reuter 及 Vignesh Shanmugam探索 Elastic Ramen一个将 Agent Builder 对话、技能和工具带入终端的 CLI 工具框架使工程师能够在同一线程中从调查直接进入修复操作。可观测性工具告诉你出了什么问题但很少能帮你修复它。在处理事故时工程师会在 Kibana、Slack 和终端之间切换时间。在每一步中AI 助手都会停留在上一个界面而调查往往不得不从头开始。Elastic RamenRoot-causeAnalysis MonitoringEngine - 根因分析与监控引擎弥补了这一断层。它是一个本地 CLI 代理直接连接 Elastic Agent Builder将相同的对话、技能和 Elastic 上下文带入终端。Ramen 在真正执行修复操作的环境中运行没有交接、没有重新认证、也没有中间转换层。Ramen 是开源的可在 elastic/elastic-ramen 获取。为什么终端很重要Agent Builder 为工程师提供了一个强大的环境用于查询可观测性数据。Ramen 将同样的能力带到最需要它的两个工作流中。入职配置Onboarding。配置采集器、管理凭证以及验证数据流都发生在 shell 中。本地代理可以在凭证和工具已经存在的环境中直接指导这些操作。故障缓解Mitigation。真正的修复操作 —— 无论是重启 Pod、扩展部署还是回滚发布 —— 都需要 kubectl、gcloud、git 或内部脚本。CLI 代理运行在团队已经信任的硬件上并使用工程师机器上已有的凭证。Ramen 的工作原理Ramen 是一个面向 Agent Builder 的 CLI 客户端。它不是一个拥有独立记忆的助手。它通过一个简单的认证流程将你的本地环境连接到你在 Kibana 中已经使用的相同对话、技能和工具。在首次启动时 Ramen 会连接到你的 Elastic 部署并为你开箱即用提供以下能力通过 Kibana 网关进行 LLM 推理使用你现有的 AI 连接器用于管理工作流和代理的原生 Kibana 工具用于 ES|QL 查询和文档搜索的 Agent Builder MCP 服务器内置 elastic CLI用于集群健康状态、数据流和 SLO用于根因分析和 SLO 管理的内置技能该代理可以在不同界面之间携带你的调查历史因此当你从 UI 切换到 CLI 时无需重新解释事件。终端中的操作会自动同步回 Elastic从而为团队构建可搜索的运维知识记录。开始使用你需要一个 Elastic Observability Serverless 项目。在 Kibana 中打开 Stack Management然后进入 Advanced Settings或者直接访问 https:///app/management/kibana/settings?queryramen。启用elasticRamen:enabled然后安装 CLInpm i -g elastic/ramen bun add -g elastic/ramen你也可以使用安装脚本或者从 GitHub Releases 下载预构建的二进制文件curl -fsSL https://raw.githubusercontent.com/elastic/elastic-ramen/dev/install | bash安装完成后连接到你的部署elastic-ramen --kibana-basehttps://your-kibana-urlRamen 会打开一个浏览器认证流程生成凭证并将其存储在本地。之后它会自动重新连接。你可以在 Agent Builder 中启动一个对话然后通过 /kibana-conversations 在终端中继续该对话。下一步Ramen 是多界面代理系统的第一个入口。同样的架构可以扩展到工程师已经在使用的所有界面空间范围协作Space-scoped collaboration用于在故障期间共享代理上下文Slack、Teams、Jira、PagerDuty 集成从告警开始在聊天中协作在终端中修复保持同一线程共享记忆Shared memory逐步将对话提炼为持久的运维上下文以改进未来的调查除了事故响应之外这一模型同样适用于部署风险分析、生产环境调试、CI/CD 策略检查以及成本异常分析。总结Ramen 将信号连接到行动Elastic 数据与 Agent Builder 上下文加上使用本地工具执行操作的能力全部在一个连续线程中完成。Elastic 作为持久上下文层而你使用的每一个界面都是交互入口。在 GitHub 上试用并告诉我们你的想法。原文https://www.elastic.co/observability-labs/blog/elastic-ramen-agent-builder-cli