Agent 执行器是什么？在 Agent 系统中起什么作用？

作者： Dr.n8n 更新时间：2025-12-14 17:00:41 分类：n8n教程

为什么你的智能客服总“答非所问”？问题可能出在执行器上

上周，我帮一家跨境电商客户排查他们的自动客服系统。用户问“订单什么时候发货”，系统却回复“感谢您的支持”。查了半天，发现不是大模型理解错了，而是负责执行动作的模块——也就是“Agent 执行器”——根本没把“查询物流状态”这个指令传给后端API。这就像你让助理帮你订机票，他听懂了，但压根没打开订票网站。

执行器：Agent 系统里的“手脚”与“翻译官”

简单说，Agent 执行器（Executor）是连接“大脑”（决策模块/LLM）和“现实世界”（工具/API/数据库）的桥梁。它不负责思考“该做什么”，而是负责“怎么做”以及“做完后怎么反馈”。

你可以把它想象成餐厅里的服务员：顾客（用户）点菜 → 经理（LLM）决定推荐哪道菜 → 服务员（执行器）跑去厨房下单、端菜、收钱、反馈“菜已上齐”。没有服务员，再聪明的经理也只能干瞪眼。

执行器的三大核心职责，缺一不可

指令解析与参数绑定：把 LLM 输出的自然语言指令（如“查询用户ID为123的订单状态”），转换成结构化 API 调用（如 GET /orders?user_id=123）。这一步最容易出错——参数名拼错、类型不匹配，都会导致调用失败。
工具调用与错误处理：实际发起 HTTP 请求、读写数据库、调用 Python 脚本等。它必须能处理网络超时、权限不足、数据格式异常等错误，并决定是重试、降级还是上报给 LLM 重新规划。
结果封装与上下文回传：把原始 API 返回的 JSON 数据，清洗、裁剪、转译成 LLM 能理解的自然语言摘要（如把 {"status": "shipped", "tracking": "SF123456"} 变成“您的订单已发货，快递单号 SF123456”），并更新到对话上下文中。

实战：在 n8n 中搭建一个最简执行器工作流

假设我们要构建一个“天气查询 Agent”，当用户问“北京明天天气如何？”时，执行器需要调用 OpenWeatherMap API 并返回结果。以下是关键节点配置：

// 1. 接收 LLM 指令（假设来自 Webhook）
// 输入示例：{ "action": "get_weather", "params": { "city": "Beijing" } }

// 2. 用 Function Item 节点解析参数并构造 API URL
return {
  json: {
    url: `https://api.openweathermap.org/data/2.5/weather?q=${$input.item.json.params.city}&appid=YOUR_KEY&units=metric`
  }
};

// 3. HTTP Request 节点调用 API
// Method: GET, URL 来自上一步输出

// 4. 用 Function Item 节点格式化结果
const data = $input.item.json;
return {
  json: {
    reply: `北京当前气温 ${data.main.temp}°C，${data.weather[0].description}`
  }
};

// 5. 将 reply 字段传回给 LLM 或直接返回用户

注意第2步和第4步——这就是执行器的核心价值：它把模糊的“查天气”意图，翻译成精确的 API 调用；再把冰冷的 JSON 数据，翻译回人类可读的句子。