前段时间和技术圈的朋友交流经常听到一个略带自嘲的词古法编程。意思是说写代码仍然全靠手写不开 AI 补全不靠对话生成从接口设计、异常处理到 SQL 调优全部一行行自己完成。放在两三年前这是开发者的常态但在 AI Agent 快速演进的当下越来越多人开始把“让模型自主调用工具完成任务”这种开发方式引入日志分析、运维排查、报表生成等真实场景。这篇文章会把古法编程和 AI Agent 开发放在一起做对比先讲清楚 Agent 的核心概念和常见术语再带大家从零实现一个通过 Elasticsearch REST API 智能分析日志的 Agent最后给出框架选型、常见问题排查和工程化建议。无论你是刚开始接触 Agent 的初学者还是已经写了多年业务代码的后端工程师都能在这篇教程里找到可以落地的内容。1. 古法编程和 AI Agent 开发到底差在哪1.1 什么是古法编程“古法编程”并不是一个严谨的技术名词更像是开发者之间的调侃。它描述的是传统软件开发方式开发者自己拆解需求自己设计数据结构自己写每个函数和 SQL自己处理边界条件出现 Bug 以后用断点和日志一点点排查。整个过程的核心是“人肉驱动”AI 工具最多起到补全和提示作用并不能自主完成一个完整任务。这种开发方式在今天依然有不可替代的价值。系统越复杂越需要开发者理解底层原理比如事务边界、索引设计、分布式一致性、接口幂等性。如果你连这些基础都不清楚直接依赖 AI 生成代码反而容易把错误逻辑包装得看起来非常合理。但古法编程也有明显痛点大量时间消耗在重复劳动上。比如排查日志时先想好关键字再写查询语句然后手动翻结果最后汇总成结论。这个流程每一步都不难但组合起来非常耗时。AI Agent 要解决的正是这类“步骤明确但繁琐”的任务。1.2 从“写代码”到“定义目标”传统开发模式下开发者要做的是把需求翻译成一系列指令每个函数、每个判断分支都必须自己定义清楚。AI Agent 开发模式则发生了一个关键转变开发者更多是在“定义目标和边界”具体的步骤拆解和工具调用交给模型完成。举个例子同样是“查询今天订单服务的错误日志”古法编程的写法是# 古法编程预先写好固定的查询逻辑 def get_error_logs(): resp requests.post( f{ES_HOST}/app-logs-*/_search, json{query: {term: {level: ERROR}}, size: 20}} ) return resp.json()这种实现没有问题但每次需求变化都要改代码。Agent 方式则不同你只需要告诉模型“今天订单服务有哪些错误按服务统计一下”模型会自己决定调用哪个工具、生成什么样的查询参数、如何分析返回结果。你不需要预先写死每一种查询场景。这里要注意Agent 不是“不用写代码”而是把代码封装成工具把决策过程交给模型。工具的质量、边界和返回格式仍然需要开发者精心设计。所以在真正的工程实践中古法编程锻炼出来的基本功并没有过时反而成了设计好 Agent 的前提。维度古法编程AI Agent 开发任务定义每个步骤都自己设计描述目标由 Agent 拆解工具调用手动选择 SDK 和 API模型自主选择已注册工具调试方式断点、日志、单测观察工具调用链与中间结果变化点代码逻辑提示词、工具边界、模型决策1.3 AI Agent 到底是什么AI Agent中文常翻译为“智能体”可以理解为以大模型为大脑通过规划、记忆和工具调用自主完成一个多步骤任务的程序。它不是一个单次问答的聊天机器人而是一个能“感知、决策、行动”的执行系统。一个最小可用的 Agent 循环可以用下面的图表示用户输入 - Agent(LLM 决策) - 调用 Tool - 观察结果 - 再次决策 - 输出 |______________________ 循环 ______________________|也就是说Agent 的核心机制是循环模型根据用户目标和已有上下文决定下一步调用什么工具工具返回结果后模型把结果纳入上下文继续判断是否已经完成目标如果没有完成就继续调用工具直到收敛或达到最大步数。理解到这个层面就不会把 Agent 神话了。它本质上仍然是“模型 工具 循环控制”只是把“人写死逻辑”变成了“模型动态决策”。既然决策是动态的就会带来不确定性这也是 Agent 开发和传统开发差异最大的地方。2. AI Agent 核心概念与术语梳理2.1 Agent 的完整架构实际工程中的 Agent 通常包含以下五个组成部分第一是大模型底座也就是 Agent 的“大脑”负责理解任务、生成推理和决策。第二是规划模块负责把复杂任务拆解成子任务决定调用顺序。第三是记忆模块短期记忆保存当前对话上下文长期记忆可以持久化到数据库或向量库用于跨会话复用。第四是工具模块包括 REST API、数据库查询、代码解释器、浏览器操作等是 Agent 连接外部世界的“手脚”。第五是执行与反馈模块负责执行工具并处理异常把结果重新喂给模型。一个完整的 Agent 系统还会包含安全围栏和可观测性组件比如权限校验、调用日志、成本统计。这些内容在后面的最佳实践部分会展开讲。2.2 Agent、Skill、Tool 的区别很多初学者会把 Tool、Skill 和 Agent 混为一谈其实它们描述的是不同层级的抽象。Tool 是最小的可调用单元比如“查询 ES 日志”“发 HTTP 请求”“执行一段 Python 代码”。一个 Tool 通常对应一个函数或一个 API 接口。Skill 是面向某类任务的“能力组合”可以包含多个 Tool、对应的提示词、示例和参数约束。例如“日志分析技能”可能包含查询日志、统计错误、导出报告三个工具再加上一段指导模型如何分析日志的系统提示词。Agent 则是拥有大脑并负责调度这些能力的执行体。你可以把 Tool 理解为工具把 Skill 理解为岗位技能把 Agent 理解为员工。同一个 Agent 可以有多个 Skill同一套 Skill 也可以被多个 Agent 复用。概念类比说明示例Tool工具完成单一动作的函数查询 ES、发送 HTTP 请求Skill技能包一组工具 提示词 示例日志分析、SQL 生成Agent员工自主决策调用哪些能力运维分析助手2.3 HuggingFace Agent 术语速查如果去读 Hugging Face 的 smolagents 项目或者它的 Agents Course会看到一套比较标准的术语体系。Model 指驱动 Agent 决策的大模型Tool 是能被 Agent 调用的函数通常通过tool装饰器把一个普通 Python 函数包装成 Agent 可识别的工具Agent 是在模型之上实现规划、选工具、执行、观察结果的执行体。smolagents 里比较有特点的是 CodeAgent 和 ToolCallingAgent。CodeAgent 会让模型直接生成 Python 代码再由代码解释器执行ToolCallingAgent 走的是标准 JSON 函数调用格式。从稳定性角度看ToolCallingAgent 更适合生产环境因为工具参数是结构化 JSON不容易出现注入风险CodeAgent 更灵活但需要更强的沙箱隔离。下面是一个 smolagents 中注册工具的示例思路from smolagents import tool tool def search_logs(index: str, dsl: dict) - str: 查询 Elasticsearch 日志返回 JSON 字符串。 Args: index: 索引名或通配符 dsl: ES 查询 DSL 字典 # 这里复用前面提到的 requests 查询逻辑 ...注意不同版本的 smolagents API 会有调整实际使用请以官方文档和当前版本为准。2.4 常见 Agent 类型从实现方式上Agent 可以分成几类。单步工具调用 Agent 是指模型只调用一次工具就给出答案适合简单查询多步规划 Agent 会把任务拆成多步适合复杂任务RAG Agent 会先检索相关资料再回答适合知识库问答多 Agent 系统则让多个角色分工协作每个 Agent 负责一个子领域适合更复杂的业务场景。对于大多数后端场景建议先从“多步工具调用 Agent”入手因为它最接近真实业务用户提出目标模型调用多个接口最后整合结果。后续想深入多 Agent 协作时再考虑角色编排和通信机制。3. 环境准备与开发底座3.1 技术选型与版本说明本文示例以常见环境为准重点演示思路。建议准备以下环境Python 3.10 或更高版本使用 venv 创建虚拟环境。Elasticsearch 7.x 或 8.x本机可通过 REST API 访问。openai Python SDK 1.x 以上用于调用大模型接口。requests 库用于调用 ES REST API。python-dotenv用于管理环境变量。大模型接口方面我推荐优先使用兼容 OpenAI Chat Completions 协议的模型服务。国内开发者通常有几种选择调用国内大模型厂商的兼容接口例如通义千问 Qwen、DeepSeek、智谱 GLM、Kimi 等如果数据不能出内网可以在私有化环境用 vLLM 或 Ollama 部署开源模型再封装成 OpenAI 兼容服务。只要接口格式兼容下面的代码可以直接复用。安装依赖命令如下pip install openai1.0.0 requests python-dotenv3.2 搭建开发环境和基础配置先创建项目目录和虚拟环境mkdir log-agent cd log-agent python -m venv .venv source .venv/bin/activate # Windows 使用 .venv\Scripts\activate然后在项目根目录创建.env文件填入模型和 ES 配置ES_HOSThttp://localhost:9200 ES_USERNAME ES_PASSWORD LLM_API_KEYsk-xxxx LLM_BASE_URLhttps://dashscope.aliyuncs.com/compatible-mode/v1 LLM_MODELqwen-plus这里以通义千问的 DashScope 兼容接口为例如果你使用 DeepSeek、Kimi 或其他服务把LLM_BASE_URL和LLM_MODEL改成对应值即可。ES_USERNAME和ES_PASSWORD留空表示本地无认证 ES。接着创建config.pyimport os from dotenv import load_dotenv load_dotenv() ES_HOST os.getenv(ES_HOST, http://localhost:9200) ES_USERNAME os.getenv(ES_USERNAME, ) ES_PASSWORD os.getenv(ES_PASSWORD, ) LLM_API_KEY os.getenv(LLM_API_KEY, ) LLM_BASE_URL os.getenv(LLM_BASE_URL, ) LLM_MODEL os.getenv(LLM_MODEL, )配置完成后写一个简单的连接测试确认模型接口可以正常访问from openai import OpenAI from config import LLM_API_KEY, LLM_BASE_URL, LLM_MODEL client OpenAI(api_keyLLM_API_KEY, base_urlLLM_BASE_URL) resp client.chat.completions.create( modelLLM_MODEL, messages[{role: user, content: 你好}] ) print(resp.choices[0].message.content)如果这里能正常返回内容说明模型底座没问题可以继续下一步。3.3 项目结构规划为了让代码清晰可维护我把示例项目拆成下面的结构log-agent/ ├── .env ├── requirements.txt ├── config.py ├── agent.py ├── main.py └── tools/ ├── __init__.py └── es_tool.pyconfig.py放配置加载逻辑tools/es_tool.py放 ES 查询工具agent.py放 Agent 循环main.py是入口。这样一个结构可以支撑后续增加更多工具比如数据库查询、告警通知、指标聚合等。4. 完整实战让 Agent 通过 ES REST API 分析日志4.1 业务场景设计假设你有几个微服务日志统一写入 Elasticsearch。过去排查问题需要手动打开 Kibana输入查询语句逐个看日志再总结结论。现在我们希望用一个 Agent 完成这件事用户直接用自然语言提问Agent 自动查询 ES、分析结果、输出结论。需求拆解后有三个关键点提供一个 ES 查询工具让 Agent 可以调用。给模型提供工具描述模型才能知道什么时候调用、传什么参数。设计 Agent 循环能让模型多次调用工具直到结论完整。另外要强调安全边界ES 连接建议使用只读账号索引范围限制在特定前缀禁止让 Agent 执行删除、更新等危险操作。本文示例中统一查询app-logs-*索引。4.2 准备 Elasticsearch 测试数据先往 ES 写入几条示例日志方便演示。直接在命令行通过 curl 调用 ES REST APIcurl -X PUT http://localhost:9200/app-logs-2026-01-18/_doc/1 \ -H Content-Type: application/json \ -d { timestamp: 2026-01-18T10:15:0008:00, level: ERROR, service: order-service, message: 连接订单数据库超时重试 3 次后失败 }再写入一条支付服务和一条正常日志curl -X PUT http://localhost:9200/app-logs-2026-01-18/_doc/2 \ -H Content-Type: application/json \ -d { timestamp: 2026-01-18T10:16:3008:00, level: ERROR, service: pay-service, message: 支付回调验签失败 } curl -X PUT http://localhost:9200/app-logs-2026-01-18/_doc/3 \ -H Content-Type: application/json \ -d { timestamp: 2026-01-18T10:17:0008:00, level: INFO, service: user-service, message: 用户登录成功 }写入后可以用POST /app-logs-*/_search验证数据是否正常。4.3 编写 ES 查询工具 AI Agent实战：用Elasticsearch实现日志分析智能体
前段时间和技术圈的朋友交流经常听到一个略带自嘲的词古法编程。意思是说写代码仍然全靠手写不开 AI 补全不靠对话生成从接口设计、异常处理到 SQL 调优全部一行行自己完成。放在两三年前这是开发者的常态但在 AI Agent 快速演进的当下越来越多人开始把“让模型自主调用工具完成任务”这种开发方式引入日志分析、运维排查、报表生成等真实场景。这篇文章会把古法编程和 AI Agent 开发放在一起做对比先讲清楚 Agent 的核心概念和常见术语再带大家从零实现一个通过 Elasticsearch REST API 智能分析日志的 Agent最后给出框架选型、常见问题排查和工程化建议。无论你是刚开始接触 Agent 的初学者还是已经写了多年业务代码的后端工程师都能在这篇教程里找到可以落地的内容。1. 古法编程和 AI Agent 开发到底差在哪1.1 什么是古法编程“古法编程”并不是一个严谨的技术名词更像是开发者之间的调侃。它描述的是传统软件开发方式开发者自己拆解需求自己设计数据结构自己写每个函数和 SQL自己处理边界条件出现 Bug 以后用断点和日志一点点排查。整个过程的核心是“人肉驱动”AI 工具最多起到补全和提示作用并不能自主完成一个完整任务。这种开发方式在今天依然有不可替代的价值。系统越复杂越需要开发者理解底层原理比如事务边界、索引设计、分布式一致性、接口幂等性。如果你连这些基础都不清楚直接依赖 AI 生成代码反而容易把错误逻辑包装得看起来非常合理。但古法编程也有明显痛点大量时间消耗在重复劳动上。比如排查日志时先想好关键字再写查询语句然后手动翻结果最后汇总成结论。这个流程每一步都不难但组合起来非常耗时。AI Agent 要解决的正是这类“步骤明确但繁琐”的任务。1.2 从“写代码”到“定义目标”传统开发模式下开发者要做的是把需求翻译成一系列指令每个函数、每个判断分支都必须自己定义清楚。AI Agent 开发模式则发生了一个关键转变开发者更多是在“定义目标和边界”具体的步骤拆解和工具调用交给模型完成。举个例子同样是“查询今天订单服务的错误日志”古法编程的写法是# 古法编程预先写好固定的查询逻辑 def get_error_logs(): resp requests.post( f{ES_HOST}/app-logs-*/_search, json{query: {term: {level: ERROR}}, size: 20}} ) return resp.json()这种实现没有问题但每次需求变化都要改代码。Agent 方式则不同你只需要告诉模型“今天订单服务有哪些错误按服务统计一下”模型会自己决定调用哪个工具、生成什么样的查询参数、如何分析返回结果。你不需要预先写死每一种查询场景。这里要注意Agent 不是“不用写代码”而是把代码封装成工具把决策过程交给模型。工具的质量、边界和返回格式仍然需要开发者精心设计。所以在真正的工程实践中古法编程锻炼出来的基本功并没有过时反而成了设计好 Agent 的前提。维度古法编程AI Agent 开发任务定义每个步骤都自己设计描述目标由 Agent 拆解工具调用手动选择 SDK 和 API模型自主选择已注册工具调试方式断点、日志、单测观察工具调用链与中间结果变化点代码逻辑提示词、工具边界、模型决策1.3 AI Agent 到底是什么AI Agent中文常翻译为“智能体”可以理解为以大模型为大脑通过规划、记忆和工具调用自主完成一个多步骤任务的程序。它不是一个单次问答的聊天机器人而是一个能“感知、决策、行动”的执行系统。一个最小可用的 Agent 循环可以用下面的图表示用户输入 - Agent(LLM 决策) - 调用 Tool - 观察结果 - 再次决策 - 输出 |______________________ 循环 ______________________|也就是说Agent 的核心机制是循环模型根据用户目标和已有上下文决定下一步调用什么工具工具返回结果后模型把结果纳入上下文继续判断是否已经完成目标如果没有完成就继续调用工具直到收敛或达到最大步数。理解到这个层面就不会把 Agent 神话了。它本质上仍然是“模型 工具 循环控制”只是把“人写死逻辑”变成了“模型动态决策”。既然决策是动态的就会带来不确定性这也是 Agent 开发和传统开发差异最大的地方。2. AI Agent 核心概念与术语梳理2.1 Agent 的完整架构实际工程中的 Agent 通常包含以下五个组成部分第一是大模型底座也就是 Agent 的“大脑”负责理解任务、生成推理和决策。第二是规划模块负责把复杂任务拆解成子任务决定调用顺序。第三是记忆模块短期记忆保存当前对话上下文长期记忆可以持久化到数据库或向量库用于跨会话复用。第四是工具模块包括 REST API、数据库查询、代码解释器、浏览器操作等是 Agent 连接外部世界的“手脚”。第五是执行与反馈模块负责执行工具并处理异常把结果重新喂给模型。一个完整的 Agent 系统还会包含安全围栏和可观测性组件比如权限校验、调用日志、成本统计。这些内容在后面的最佳实践部分会展开讲。2.2 Agent、Skill、Tool 的区别很多初学者会把 Tool、Skill 和 Agent 混为一谈其实它们描述的是不同层级的抽象。Tool 是最小的可调用单元比如“查询 ES 日志”“发 HTTP 请求”“执行一段 Python 代码”。一个 Tool 通常对应一个函数或一个 API 接口。Skill 是面向某类任务的“能力组合”可以包含多个 Tool、对应的提示词、示例和参数约束。例如“日志分析技能”可能包含查询日志、统计错误、导出报告三个工具再加上一段指导模型如何分析日志的系统提示词。Agent 则是拥有大脑并负责调度这些能力的执行体。你可以把 Tool 理解为工具把 Skill 理解为岗位技能把 Agent 理解为员工。同一个 Agent 可以有多个 Skill同一套 Skill 也可以被多个 Agent 复用。概念类比说明示例Tool工具完成单一动作的函数查询 ES、发送 HTTP 请求Skill技能包一组工具 提示词 示例日志分析、SQL 生成Agent员工自主决策调用哪些能力运维分析助手2.3 HuggingFace Agent 术语速查如果去读 Hugging Face 的 smolagents 项目或者它的 Agents Course会看到一套比较标准的术语体系。Model 指驱动 Agent 决策的大模型Tool 是能被 Agent 调用的函数通常通过tool装饰器把一个普通 Python 函数包装成 Agent 可识别的工具Agent 是在模型之上实现规划、选工具、执行、观察结果的执行体。smolagents 里比较有特点的是 CodeAgent 和 ToolCallingAgent。CodeAgent 会让模型直接生成 Python 代码再由代码解释器执行ToolCallingAgent 走的是标准 JSON 函数调用格式。从稳定性角度看ToolCallingAgent 更适合生产环境因为工具参数是结构化 JSON不容易出现注入风险CodeAgent 更灵活但需要更强的沙箱隔离。下面是一个 smolagents 中注册工具的示例思路from smolagents import tool tool def search_logs(index: str, dsl: dict) - str: 查询 Elasticsearch 日志返回 JSON 字符串。 Args: index: 索引名或通配符 dsl: ES 查询 DSL 字典 # 这里复用前面提到的 requests 查询逻辑 ...注意不同版本的 smolagents API 会有调整实际使用请以官方文档和当前版本为准。2.4 常见 Agent 类型从实现方式上Agent 可以分成几类。单步工具调用 Agent 是指模型只调用一次工具就给出答案适合简单查询多步规划 Agent 会把任务拆成多步适合复杂任务RAG Agent 会先检索相关资料再回答适合知识库问答多 Agent 系统则让多个角色分工协作每个 Agent 负责一个子领域适合更复杂的业务场景。对于大多数后端场景建议先从“多步工具调用 Agent”入手因为它最接近真实业务用户提出目标模型调用多个接口最后整合结果。后续想深入多 Agent 协作时再考虑角色编排和通信机制。3. 环境准备与开发底座3.1 技术选型与版本说明本文示例以常见环境为准重点演示思路。建议准备以下环境Python 3.10 或更高版本使用 venv 创建虚拟环境。Elasticsearch 7.x 或 8.x本机可通过 REST API 访问。openai Python SDK 1.x 以上用于调用大模型接口。requests 库用于调用 ES REST API。python-dotenv用于管理环境变量。大模型接口方面我推荐优先使用兼容 OpenAI Chat Completions 协议的模型服务。国内开发者通常有几种选择调用国内大模型厂商的兼容接口例如通义千问 Qwen、DeepSeek、智谱 GLM、Kimi 等如果数据不能出内网可以在私有化环境用 vLLM 或 Ollama 部署开源模型再封装成 OpenAI 兼容服务。只要接口格式兼容下面的代码可以直接复用。安装依赖命令如下pip install openai1.0.0 requests python-dotenv3.2 搭建开发环境和基础配置先创建项目目录和虚拟环境mkdir log-agent cd log-agent python -m venv .venv source .venv/bin/activate # Windows 使用 .venv\Scripts\activate然后在项目根目录创建.env文件填入模型和 ES 配置ES_HOSThttp://localhost:9200 ES_USERNAME ES_PASSWORD LLM_API_KEYsk-xxxx LLM_BASE_URLhttps://dashscope.aliyuncs.com/compatible-mode/v1 LLM_MODELqwen-plus这里以通义千问的 DashScope 兼容接口为例如果你使用 DeepSeek、Kimi 或其他服务把LLM_BASE_URL和LLM_MODEL改成对应值即可。ES_USERNAME和ES_PASSWORD留空表示本地无认证 ES。接着创建config.pyimport os from dotenv import load_dotenv load_dotenv() ES_HOST os.getenv(ES_HOST, http://localhost:9200) ES_USERNAME os.getenv(ES_USERNAME, ) ES_PASSWORD os.getenv(ES_PASSWORD, ) LLM_API_KEY os.getenv(LLM_API_KEY, ) LLM_BASE_URL os.getenv(LLM_BASE_URL, ) LLM_MODEL os.getenv(LLM_MODEL, )配置完成后写一个简单的连接测试确认模型接口可以正常访问from openai import OpenAI from config import LLM_API_KEY, LLM_BASE_URL, LLM_MODEL client OpenAI(api_keyLLM_API_KEY, base_urlLLM_BASE_URL) resp client.chat.completions.create( modelLLM_MODEL, messages[{role: user, content: 你好}] ) print(resp.choices[0].message.content)如果这里能正常返回内容说明模型底座没问题可以继续下一步。3.3 项目结构规划为了让代码清晰可维护我把示例项目拆成下面的结构log-agent/ ├── .env ├── requirements.txt ├── config.py ├── agent.py ├── main.py └── tools/ ├── __init__.py └── es_tool.pyconfig.py放配置加载逻辑tools/es_tool.py放 ES 查询工具agent.py放 Agent 循环main.py是入口。这样一个结构可以支撑后续增加更多工具比如数据库查询、告警通知、指标聚合等。4. 完整实战让 Agent 通过 ES REST API 分析日志4.1 业务场景设计假设你有几个微服务日志统一写入 Elasticsearch。过去排查问题需要手动打开 Kibana输入查询语句逐个看日志再总结结论。现在我们希望用一个 Agent 完成这件事用户直接用自然语言提问Agent 自动查询 ES、分析结果、输出结论。需求拆解后有三个关键点提供一个 ES 查询工具让 Agent 可以调用。给模型提供工具描述模型才能知道什么时候调用、传什么参数。设计 Agent 循环能让模型多次调用工具直到结论完整。另外要强调安全边界ES 连接建议使用只读账号索引范围限制在特定前缀禁止让 Agent 执行删除、更新等危险操作。本文示例中统一查询app-logs-*索引。4.2 准备 Elasticsearch 测试数据先往 ES 写入几条示例日志方便演示。直接在命令行通过 curl 调用 ES REST APIcurl -X PUT http://localhost:9200/app-logs-2026-01-18/_doc/1 \ -H Content-Type: application/json \ -d { timestamp: 2026-01-18T10:15:0008:00, level: ERROR, service: order-service, message: 连接订单数据库超时重试 3 次后失败 }再写入一条支付服务和一条正常日志curl -X PUT http://localhost:9200/app-logs-2026-01-18/_doc/2 \ -H Content-Type: application/json \ -d { timestamp: 2026-01-18T10:16:3008:00, level: ERROR, service: pay-service, message: 支付回调验签失败 } curl -X PUT http://localhost:9200/app-logs-2026-01-18/_doc/3 \ -H Content-Type: application/json \ -d { timestamp: 2026-01-18T10:17:0008:00, level: INFO, service: user-service, message: 用户登录成功 }写入后可以用POST /app-logs-*/_search验证数据是否正常。4.3 编写 ES 查询工具