n8n-agents

n8n Agents

n8n AI Agent 节点（@n8n/n8n-nodes-langchain.agent）是一个多轮 LLM 驱动器，包含用于模型、记忆、工具和可选输出解析器的子节点。本技能深入讲解如何设计 Agent 及其周边的 LangChain 系列。有关“Agent 在工作流中适用于何处”的高级概览，请参阅 n8n-workflow-patterns ai_agent_workflow.md——本技能深入一层，讲解如何构建得更好。

关于节点类型格式：在工作流 JSON 中，LangChain 节点使用完整的 @n8n/n8n-nodes-langchain.* 格式（.agent、.lmChatOpenAi、.memoryBufferWindow、.outputParserStructured、.toolWorkflow、.toolHttpRequest、.toolCode）。调用 get_node / validate_node 时，请使用简写格式（nodes-langchain.agent）。格式规则请参阅 n8n-mcp-tools-expert。

---

先选择合适的节点

当任务只是一次性分类或提取时，仍然选择 Agent，是最常见的过度构建。在连接任何节点之前先做出判断：

你需要……	使用	原因
调用工具、进行多轮推理，或保留记忆	AI Agent（.agent）	完整循环：模型 + 工具 + 记忆 + 可选解析器。如果你希望采用统一方案，它也是不错的默认选择。
一次性输入文本 → 输出文本，不使用工具	Basic LLM Chain（.chainLlm）	没有 Agent 循环，更易于调试。仍然接受 outputParserStructured 子节点。
将自然语言输入路由到 N 个分支之一	Text Classifier（.textClassifier）	一个节点，N 个输出端口，直接连接到各个下游节点。不要用 Agent + Switch。
从自由文本中提取结构化字段	Information Extractor（.informationExtractor）	专为基于架构的字段提取而设计。
将情感分为积极／中性／消极三类	Sentiment Analysis（.sentimentAnalysis）	内置分支输出。
压缩长文档	Summarization Chain（.chainSummarization）	内置 Map-Reduce 摘要功能。
生成图像／音频／视频	提供商原生的单次调用节点（OpenAI、Gemini、ElevenLabs……）	绝不要用 Agent 包装媒体生成——请参阅“二进制数据与 Agent 边界”。

Text Classifier 详解（Agent + Switch 反模式）：每个类别都需要同时具备名称和描述。模型根据描述进行路由，而不是名称——没有描述的类别会被随机选中。设置 options.enableAutoFixing: true，以提高对边缘输入的处理稳健性。一个节点，N 个分支，完成。使用 Agent 来“做决定”，再用 Switch 来“路由”，等于为了实现 Text Classifier 原生具备的功能，额外增加两个节点和提示词模板。

聊天模型节点（.lmChatOpenAi、.lmChatAnthropic、.lmChatOpenRouter 等）是子节点——它们不能独立运行。它们通过 ai_languageModel 连接，接入链、Agent、分类器或提取器。

---

子节点模式

Agent 有一个主输入（提示词／用户消息）和最多四个子节点插槽，每个插槽都通过各自的 ai_* 连接类型接入：

插槽	连接类型	必需？	节点示例
model	ai_languageModel	是	.lmChatOpenAi、.lmChatAnthropic、.lmChatOpenRouter
memory	ai_memory	可选	.memoryBufferWindow、.memoryPostgresChat
tools	ai_tool	可选（但这正是 Agent 的意义所在）	slackTool、.toolWorkflow、.toolHttpRequest、.toolCode
outputParser	ai_outputParser	可选	.outputParserStructured

子节点从自身连接到 Agent。在工作流 JSON 中，连接定义在子节点上，以 ai_* 类型为键：

"Main LLM": {
  "ai_languageModel": [[{ "node": "AI Agent", "type": "ai_languageModel", "index": 0 }]]
},
"Simple Memory": {
  "ai_memory": [[{ "node": "AI Agent", "type": "ai_memory", "index": 0 }]]
},
"Search customer DB": {
  "ai_tool": [[{ "node": "AI Agent", "type": "ai_tool", "index": 0 }]]
}

多个工具都连接到同一个 ai_tool 索引 0——它们会叠加，而不是分流到不同索引。使用 n8n_update_partial_workflow 时，为每个工具使用 sourceOutput: "ai_tool" 的 addConnection 操作进行连接。Agent 会将最终答案放在 $json.output 中（而不是 .text 或 .response）——下游节点读取 {{ $json.output }}。

完整的无状态 Agent 核心节点对象代码片段，请参见 EXAMPLES.md。

---

两条不可妥协的原则

1. **工具名称和描述都属于提示词的一部分。**模型通过读取工具的名称和描述来选择工具——除此之外别无依据。名称为 tool1 且描述为空的工具对模型来说形同隐形：模型会跳过它、选错它，或臆造参数。通常不会报错——只会让 Agent “不使用我的工具”。请将两者都视为 API 设计的一部分。→ TOOLS.md
2. 结构化输出必须经过解析和自动修复。在生产环境中，outputParserStructured 配合 autoFix: true 和具备编码能力的修复模型才是推荐模式。没有 autoFix，一次格式错误的 JSON 响应就会中断整个工作流。→ STRUCTURED_OUTPUT.md

---

推荐默认做法

• **每个工具的使用说明应写在工具描述中，而不是系统提示词里。**所有关于如何调用这个特定工具的内容都应放在工具旁边，这样就能在不同 Agent 间复用，并让系统提示词保持专注。→ SYSTEM_PROMPT.md
• **任何多步骤任务都使用子工作流工具（.toolWorkflow）。**任何工作流都可以变成带有类型化 $fromAI() 输入的工具，并支持分支、错误处理和复用。如有疑问，默认采用这种方式。→ SUBWORKFLOW_AS_TOOL.md 和 n8n-subworkflows。
• **对会产生用户可见副作用的工具加入人工审核。**发送消息、付款、退款和账户变更都应通过审批节点进行把关，确保工具触发前由人工批准。→ HUMAN_REVIEW.md
• 提高 maxIterations。工具调用次数的默认上限偏低（大多数版本都只有个位数）——对于只使用一个工具的 Agent 来说足够，但对于每轮串联多个调用的多工具 Agent 来说远远不够。达到上限时会出现“max iterations reached”或输出为空的情况。将 options.maxIterations 设为合理上限（专注型子 Agent 设为 15，广泛型编排器设为 50–200）。
• **通过 {{ $now }}（或 {{ $now.format('DDDD') }}）在系统提示词中加入当前日期。**硬编码的日期会立即过时。

---

四种工具类型

选择能完成任务的最轻量选项：

工具类型	节点	适用场景
原生工具节点	slackTool、gmailTool、toolCalculator、……	能力对应一个现有节点和一个操作。开销最低。
子工作流作为工具	.toolWorkflow	涉及多个节点、需要可复用逻辑，或希望能够独立测试。这是 n8n 的规范做法——拿不准时默认选择它。
HTTP Request Tool	.toolHttpRequest	需要 Agent 直接编排单个外部 HTTP API。复用服务预定义的凭据，以支持原生节点未提供的操作。
MCP Client Tool	.mcpClientTool	已有维护良好的 MCP 服务能满足需求，或者希望一个已发布的工作流为多个 Agent 提供服务。

此外，还有用于纯内联计算的 Custom Code Tool（.toolCode）——但它的运行时约定（字符串输入／字符串输出，不支持 $fromAI、$helpers）由 n8n-code-tool 技能负责。编写此类工具前请先阅读该技能。经验法则：如果你发现自己想在代码中使用 $fromAI()，那你需要的是 .toolWorkflow。

$fromAI()：Agent 如何填写工具参数

需要由 Agent 决定的工具参数应使用 $fromAI() 包装。它是一个真正的 n8n 表达式辅助函数，用于工具节点的参数表达式中：

={{ $fromAI('paramName', 'what to put here — be specific: format, range, example', 'string') }}

• paramName — 模型内部使用的名称（snake_case 或 camelCase，保持一致）。
• description — 告诉模型要生成什么值。它属于提示词的一部分——请按 JSDoc 的风格编写。
• type（可选）— 'string'（默认值）、'number'、'boolean'、'json'。类型错误的值会导致调用失败。
• defaultValue（可选）— 模型未提供值时使用。

$fromAI() 只传递 JSON——无法传递二进制数据（不支持 base64 或文件字节）。而且并非每个参数都要使用 $fromAI：应从工作流上下文中确定性地传入身份信息、权限限制和关联 ID（userId、退款上限、sessionId），以免 Agent 出错，甚至避免 Agent 看到这些信息。→ 完整结构及“给 Agent 一个按钮，而不是方向盘”的模式，请参阅 TOOLS.md。

---

系统提示词与工具描述

应放在系统提示词中	应放在工具描述中
角色设定、身份、语气	此工具的具体功能
全局输出／格式规则（“以 markdown 格式回复”）	何时使用此工具，以及何时改用其他工具
拒绝／安全行为	各参数的含义和格式
显示协议（图片使用 ![]()）	正确与错误调用示例
通用上下文（通过 $now 获取当前日期、用户角色）	工具特有注意事项（速率限制、边缘情况）
工具间流程（“生成后始终显示”）	工具特有的输入转换

为何要拆分：描述完善的工具可用于任何接入它的 Agent；模型只会在考虑使用该工具时“加载”工具详情（提高 token 使用效率）；而且你只需更新一处工具描述，而不必修改埋在 5000 token 提示词中的一段文字。→ SYSTEM_PROMPT.md

---

结构化输出：何时使用以及如何配置

下游需要严格的 JSON 而非自由文本时，添加一个 outputParserStructured 子节点（连接到 ai_outputParser）。请遵循两条规则：

1. 使用 schemaType: 'manual' 和真实的 JSON Schema，不要使用 jsonSchemaExample。 示例无法表达必填项与可选项、枚举、数值范围或数组约束——结构稍微复杂时就会不够用。只有临时使用的简单结构才考虑使用 fromJson 和示例。
2. 设置 autoFix: true，并使用具备编码能力的修复模型。 将第二个模型接入解析器的 ai_languageModel 插槽。根据 Schema 修复有问题的 JSON 是一项编码任务——较弱的修复模型只会再生成一次格式错误的内容，白白消耗 token。

→ 有关 Schema 模式、至关重要的“不要用 markdown 包裹”重试提示行，以及解析失败的处理指南，请参阅 STRUCTURED_OUTPUT.md。

---

记忆：简要心智模型

记忆是一个子节点（ai_memory）。没有它，每次调用都是无状态的——适用于一次性任务（分类、总结）。有了它，Agent 就能保持对话，并使用绑定到 sessionKey 的任意表达式作为键。

• memoryBufferWindow——为每个键保留最近 N 轮对话，并通过 n8n 的存储在多次执行间持久化。这是聊天场景的默认选择。contextWindowLength 默认值为 5，非常低——50 是更合理的起始值。超出窗口的消息会被彻底删除。
• memoryPostgresChat / memoryRedisChat——仅当必须在 Agent 之外读取记忆时使用（例如在自己的 UI、分析系统或跨系统场景中）。若只是为了在重启后保留记忆，则不需要；BufferWindow 已经可以做到。

始终将稳定的键从触发器传递到记忆节点。 聊天触发器会自动填入 sessionId；对于其他入口，则自行生成一个键（例如 Slack 的 thread_ts、Webhook 的对话 ID）。不要将 sessionId 硬编码为 'default'，也不要将 sessionId 交给 $fromAI（模型会编造一个 UUID）。→ MEMORY.md

---

二进制数据与 Agent 边界

这是最容易让人踩坑的接口：

• 模型可以通过 Agent 上的 options.passthroughBinaryImages: true 看到上传的图片（视觉能力）。
• 工具无法接收二进制数据。 $fromAI() 只能处理 JSON——不支持 base64、字节数据，也不支持通过非 AI 绑定传递。
• Agent 的输出是文本形式（或由解析器处理的结构化文本）。当模型返回图像／音频／视频字节数据时，Agent 根本不会将其输出——下游没有任何内容可以恢复。

**解决方法：**在 Agent 运行前，先将上传内容存入存储，将存储键注入系统提示词，并让工具接受字符串形式的键作为参数，在内部重新获取内容。对于一次性的媒体生成，跳过 Agent，直接调用提供方的原生单次调用节点。

二进制数据的处理方式（使用哪种存储、如何暂存、如何重新获取）由 n8n-binary-and-data 负责——参见其中的 Agent 工具二进制参考。本技能只标明边界；不要在此重新推导处理方式。

---

人工审核（为有破坏性的工具设置关卡）

如果某个工具的操作需要人工批准后才能执行（发送、付款、退款、账户变更），请使用审核工具节点进行封装——slackHitlTool、discordHitlTool、telegramHitlTool、gmailHitlTool 等。（n8n 将这些节点称为“Hitl”／人在回路中。）审核节点通过 ai_tool 连接位于被封装工具与 Agent 之间：被封装的工具 → 审核节点 → Agent。

是否需要批准属于产品／策略决策——将这个问题呈现给用户，根据影响范围给出建议，并由用户决定。

关键规则：展示被封装工具实际会收到的参数。 在批准消息中使用字面表达式 {{ $tool.parameters.<name> }}，绝不要使用 $fromAI() 进行转述——否则人工批准的是模型编造的文本，而不是即将执行的调用。→ HUMAN_REVIEW.md

聊天 Agent（Slack、Discord、Teams、Telegram）

无论复杂程度如何，都必须做到这一点：任何由聊天触发且会发布回复的工作流，都必须过滤掉机器人自己的用户 ID，否则它自己的回复会再次触发工作流，形成无限循环，消耗执行次数和令牌。可用时优先在触发器层进行过滤（Slack Trigger 的 options.userIds 是一个排除列表——将机器人 ID 放入其中）；否则，在触发器后的第一个节点中使用 $json.user !== '<BOT_USER_ID>' 进行过滤。

除过滤之外，简单的机器人（触发器 → Agent → 回复）完全可以放在一个工作流中。只有在需要加载状态体验、子 Agent、多平台复用或可靠的错误处理时，才拆分为外壳 + 核心 + 子 Agent：

• 外壳 — 触发器、防循环过滤、事件类型 Switch、加载／错误状态体验，以及回复渲染。不使用大模型。
• 核心 — 无状态 Agent，输入为 chatInput + threadId，按 threadId 键控记忆，并包含工具和子 Agent。
• 子 Agent — 每个子 Agent 负责一个狭窄领域，通过 .toolWorkflow 调用，且为无状态（完整上下文放在 chatInput 中）。

→ CHAT_AGENT_PATTERNS.md 介绍各平台的语义、以线程作为会话的方式，以及完整的拓扑结构。

---

持久化 n8n Agent（n8n_manage_agents）

持久化 n8n Agent 与上文介绍的 AI Agent 节点是不同的产物：它是一条独立的助手记录，包含模型、指令、工具、技能、任务、记忆和渠道，由 n8n 自身存储并进行版本管理，通过 n8n_manage_agents（n8n 的实例级 MCP 服务）管理，而不是工作流 JSON 中的节点。

你需要……	使用
工作流中通过 ai_* 子节点连接的推理步骤	AI Agent 节点（本技能，上文）
拥有独立生命周期（草稿、验证、发布、版本、渠道），不依赖任何单个工作流的独立助手	持久化 Agent（n8n_manage_agents）

前提条件： 已配置 N8N_MCP_ACCESS_TOKEN（与 Public API 密钥分开），并使用启用了 agents 模块的 n8n 2.34+。每项操作都需要此令牌，包括 reference/search——没有令牌，任何操作都无法运行。另外，reference 和 search 适用于任何 Agent，无论其是否向 MCP 开放；其他所有操作都要求目标 Agent 已向 MCP 开放（通过此工具创建的 Agent 会自动开放——此开放门槛仅适用于此工具尚未处理过的现有 Agent）。

构建顺序：

1. action: "reference" — 首先读取配置架构和准确的变更操作。
2. action: "discover_assets" — 列出 Agent 实际可连接的对象。需要提供 projectId（来自 n8n_list_catalog({kind: "projects"})）和 kind：models（需提供 provider）、integrations、workflows、subagents 或 mcpServers。每种类型单独调用一次。
3. action: "create" — 提供 projectId、name、config。
4. action: "mutate" — 每次调用处理一个资源（config.patch、skill.upsert/delete、task.upsert/delete、customTool.upsert/delete），并始终传入最新的哈希值。注意这两个名称：n8n 返回的名称是 configHash，传回时则应放在 args.baseConfigHash 中。args 会原样转发给 n8n，因此任何字段名稍有偏差，都会返回 INVALID_ARGS，而不是给出有用的更正提示——所以步骤 1 会先读取架构。哈希值过期时会返回 STALE_CONFIG——请重新执行 get，并使用最新值重试。
5. action: "validate" — 在提供 call 或 publish 操作前执行。
6. action: "publish" — 仅在用户明确要求时执行，不得主动发布。

action: "call" 会使用真实凭据和真实工具运行 Agent——这是实际执行，而非试运行。结果可能包含需要人工决策的工具调用 approvals[]；绝不能代替用户批准——应将其告知用户，并仅在用户做出决定后恢复执行。

自定义工具使用第三种代码运行时——不要与另外两种混用。 customTool.upsert 的请求体是 TypeScript，且仅允许导入 @n8n/agents 和 zod。这既不是 Code 节点（JavaScript/Python，返回 [{json: …}]），也不是 n8n-code-tool 中介绍的 AI Agent Custom Code Tool（@n8n/n8n-nodes-langchain.toolCode，返回字符串，不使用 $fromAI()）。这里很容易误用，因为这三种方式都是“编写供 Agent 调用的代码”。编写前请先通过 action: "reference" 查看格式；编译失败或未知的 agentId 会返回 AGENT_TOOL_ERROR。

凭据注意事项： 在 n8n 2.36.x 上，agents 运行时会拒绝 azureOpenAiApi 和 aws 凭据（报告为 missing: ["credential"]）；响应中的 hint 会列出可接受的类型。

测试且不留残留： 将临时 Agent 命名为 [TEST] …，完成后将其 delete——持久化 Agent 会在创建它的对话结束后继续存在，不像工作流那样可以留作非活动状态。

→ n8n-mcp-tools-expert ## Agents，查看工具的完整操作列表和错误代码。

---

RAG（检索增强生成）

n8n 内置了 LangChain RAG 基础组件（文档加载器、分割器、嵌入、向量存储、检索器）。有两点建议先说明：

1. 先排除成本更低的查询方式。 精确查询 → 使用数据库或 Data Table 查询，而不是 RAG。需要最新信息 → 使用实时搜索工具。文档集较小或结构化 → 为 Agent 提供列表／获取工具。只有当文档太多，无法逐一列出，且查询是语义查询时，才使用向量存储。
2. 将向量存储接入为检索工具（mode: 'retrieve-as-tool'、ai_tool），让 Agent 判断何时需要检索，并自行组织查询。查询和文档必须使用同一个模型生成嵌入。

→ RAG.md（有意保持精简——默认配置取决于数据形态和规模）。

---

参考文件

文件	适合在何时阅读
TOOLS.md	添加工具、在四种类型中选择、编写名称／描述、了解 $fromAI 结构
SUBWORKFLOW_AS_TOOL.md	通过 .toolWorkflow 将子工作流接入为工具，映射由 Agent 填写的参数与传递的参数
SYSTEM_PROMPT.md	编写／重构系统提示词，了解系统提示词与工具描述的职责划分
STRUCTURED_OUTPUT.md	强制输出 JSON、配置 autoFix、选择修复模型、修复解析失败
MEMORY.md	选择记忆类型、配置持久化、处理 sessionId
HUMAN_REVIEW.md	添加人工审批、编写审批消息、配置多渠道审批人
CHAT_AGENT_PATTERNS.md	构建 Slack／Discord／Teams／Telegram 机器人，了解 shell + core + sub-agents 拓扑
RAG.md	检索增强型 Agent（有意保持精简）
EXAMPLES.md	具体的节点对象片段：无状态 Agent 核心、Slack 路由 shell、领域子 Agent

---

反模式

反模式	问题	修复方法
通用工具名称（tool1、doStuff、runQuery）	模型无法判断该选哪个工具——会跳过工具或臆造参数	使用以动词开头的具体名称：Search customer database、Generate image with Veo
工具描述为空或只有一行	模型不知道何时调用工具，导致选择错误或完全不调用	编写完整描述：说明工具的功能、使用时机和各参数的含义
将每个工具的说明塞进系统提示词	提示词臃肿、无法复用，且每个工具的指引被埋没	将工具专属说明移至工具描述中
使用 Agent + Switch 根据自然语言进行路由	本可用一个 Text Classifier 完成的工作，却用了两个节点和冗长的提示词模板	使用 Text Classifier——每个类别都有独立的输出端口（名称和描述）
使用 Agent 封装图像／音频／视频生成	二进制数据无法通过工具传递，也无法从 Agent 输出	直接使用服务商原生的单次调用节点
outputParserStructured 未启用 autoFix	一次响应格式错误就会中断工作流	使用 autoFix: true + 具备编码能力的修复模型
直接将二进制数据传给工具	无法正常工作——二进制数据不能跨越工具边界	先暂存到存储中，再传递键；参见 n8n-binary-and-data
sessionId 硬编码／缺少 sessionId／将 sessionId 放在 $fromAI 后	对话相互串线，或模型伪造 UUID	从触发器向记忆和工具传递稳定的键
两个几乎相同的工具	选择结果不确定，模型容易混淆	使用一个工具，通过参数控制内部逻辑分支
聊天机器人未过滤机器人用户	它自己的回复会再次触发它 → 无限循环	在触发器或第一个节点排除机器人用户 ID
多工具 Agent 的 maxIterations 保持较低的默认值	出现“Max iterations reached”／输出为空	提高 options.maxIterations
通过 $fromAI() 填写人工审核消息	审批人批准的是改写后的内容，而非实际调用	使用字面量 {{ $tool.parameters.<name> }}

社区 MCP 无法实现的功能

想要实现的功能	实际情况
以交互方式端到端地对工作流的 AI Agent 节点进行聊天测试	n8n_test_workflow 会运行工作流，但要针对该节点进行真正的多轮聊天，需要通过 UI 操作（画布聊天测试器）。相比之下，已保存的 Agent 可以通过 n8n_manage_agents 的 call 实时运行 — 参见上文“已保存的 n8n Agent”。
设置凭据的实际密钥值	n8n_manage_credentials 会创建／更新凭据记录，但 Agent 提供商密钥本身需要在 UI 中输入／验证。
为工作流指定错误工作流	仅支持 UI — 参见 n8n-error-handling。先构建兜底工作流，再引导用户完成 UI 操作。
固定每个实例可用的确切模型	模型列表会随版本变化 — search_nodes／get_node 会反映已安装的模型。请在目标实例上确认。

MCP 可以做的事：搜索并检查每个 LangChain 节点（search_nodes、get_node），验证节点配置和整个图（validate_node、validate_workflow），构建并修补 Agent 及其子节点（在 ai_* 输出上使用 addConnection 调用 n8n_update_partial_workflow），测试（n8n_test_workflow），并提取已保存的 JSON 以验证连线（n8n_get_workflow）。详细的 AI Agent 指南也可通过 tools_documentation({topic: "ai_agents_guide", depth: "full"}) 查阅。

---

与其他技能集成

• n8n-workflow-patterns（ai_agent_workflow.md）— “工作流中的 Agent”的高层结构。本技能会深入讲解；请从这里开始了解架构。
• n8n-mcp-tools-expert — 节点类型格式（get_node 的简写形式、JSON 中的完整形式）和工具选择指南。执行任何 MCP 调用前请先查阅。
• n8n-node-configuration — Agent 和子节点上由 displayOptions 驱动的字段；Slack／Block Kit 消息结构（NODE_FAMILY_GOTCHAS.md，Slack 部分）。
• n8n-expression-syntax — {{ }}、$json.output、$now 和 $fromAI／$tool.parameters 都依赖正确的表达式语法。
• n8n-code-tool — Custom Code Tool 的运行时约定（字符串输入／输出，不支持 $fromAI）。编写 .toolCode 前请先阅读。
• n8n-subworkflows — .toolWorkflow 所基于的子工作流原语（Execute Workflow Trigger 的输入／输出、命名、构建前先搜索）。
• n8n-binary-and-data — 负责处理 Agent 工具的二进制数据边界机制（暂存上传文件、返回生成的文件）。
• n8n-validation-expert — 解读 validate_workflow 结果，包括 AI 连接问题（工具连接到 main 而不是 ai_tool 时会被标记为未连接）。
• n8n-error-handling — 工具子工作流和 Agent 核心调用上的 onError: 'continueErrorOutput'；聊天外壳的错误体验。
• n8n-code-javascript / n8n-code-python — 用于工具子工作流内部的 Code 节点逻辑（与 Code Tool 使用不同的沙箱）。

---

快速参考清单

发布 Agent 前：

• 节点选择正确：处理工具／记忆／多轮对话时使用 Agent；路由时使用 Text Classifier；提取字段时使用 Information Extractor；处理媒体时使用原生节点
• 通过 ai_languageModel 连接模型
• 每个工具都有以动词开头的具体名称，以及真实的描述
• $fromAI() 描述足够具体（格式、范围、示例）；身份信息／限制／sessionId 通过确定性方式传递，而不是通过 $fromAI
• 每个工具的指导信息放在工具描述中，而不是系统提示词中
• 在系统提示词中使用 $now（不要硬编码日期）
• 多工具 Agent 应提高 maxIterations
• 记忆使用来自触发器的稳定 sessionKey 作为键（不要使用 'default'，也不要使用 $fromAI）；将 contextWindowLength 从 5 调高
• 结构化输出：schemaType: 'manual' + autoFix: true + 具备编码能力的修正模型
• 用人工审核封装破坏性工具；审批消息使用 $tool.parameters，而不是 $fromAI
• 聊天机器人应过滤机器人自身的用户 ID（在触发器层级或第一个节点中）
• 二进制数据：通过 passthroughBinaryImages 让模型处理图像；工具接收存储键，绝不接收字节数据
• 使用 validate_workflow 验证，并通过 n8n_get_workflow 确认（子节点连接到 ai_*，而不是 main）

---

请记住：Agent 的能力取决于工具名称、描述以及系统提示词的规范。模型看不到你的连接方式——它看到的是系统提示词和一组带名称及描述的工具。像设计 API 一样设计这些内容，大多数“Agent 不听话”的问题就会消失。