using-n8n-skills-official

使用 n8n Skills

官方 n8n MCP 会不断演进，因此不同版本之间的工具名称、参数和默认行为可能会发生变化。如果发现差异（Skill 中提到的工具不存在、参数结构与 get_node_types 返回的内容不符，或实际行为与 Skill 的描述不同），建议将 Skill 和 n8n 实例更新到最新稳定版。

不容妥协的事项

以下三条规则没有例外。违反任何一条，都会导致工作流看似正常，却在生产环境中出问题。

1. 执行任何 n8n 操作前，先调用相关 Skill。 不只是调用 MCP 工具。在编写 SDK 代码、配置节点、设计工作流、连接节点、构建 Agent 或处理错误之前，都要通过 Skill 工具调用匹配的 Skill。本文档是路由指南，具体规则在 Skill 正文中。安装插件后，PreToolUse hooks 会在影响最大的 MCP 调用前提醒你。其他所有操作都由你负责。拿不准时，宁可多读几份文档。
2. 发布前要先验证并核实。 调用 publish_workflow 前先调用 validate_workflow；每次创建或更新后，都要调用 get_workflow_details 检查 connections 对象。仅做验证可能遗漏 Skill 中记录的许多问题，而这些问题会导致工作流悄无声息地失效。
3. 绝不能在文本字段中放入令牌或密钥。 始终使用 n8n 凭据系统。如果没有原生节点，请使用官方凭据类型配置 HTTP Request。参见 n8n-credentials-and-security-official。

依靠 Skills，而非训练数据

n8n 的演进速度比任何模型的训练截止时间都快。参数名称会变化，新的 MCP 工具会陆续推出，默认值会更改，模式也会被弃用。你“记得”的内容很可能是错的，而且往往不会显露出来。

应相信 Skills 和实时 MCP 工具（get_node_types、get_workflow_sdk_reference、get_workflow_best_practices），而不是凭记忆判断。如果 Skill 与你“知道”的内容相矛盾，以 Skill 为准。如果 get_node_types 与 Skill 相矛盾，以工具为准。不遵循这一原则，就会交付看似正常却悄无声息地失败的工作流：使用不存在的参数名称、重命名后的节点或已弃用的模式。

除非用户偏好另有要求，否则宁可加载过多 Skills，也不要加载不足。即使是 3 个节点的 Webhook 工作流，通常也需要 n8n-node-configuration-official、n8n-expressions-official、n8n-error-handling-official 和 n8n-workflow-lifecycle-official。在 n8n 中，没有小到不需要 Skills 的任务。

强烈建议（各 Skill 负责说明例外情况）

• Code 节点是最后的选择。 优先使用表达式，其次是在 Edit Fields 中使用箭头函数，最后才考虑 Code。只有在需要聚合多个数据源、使用库或处理有状态任务时，才值得使用 Code。参见 n8n-code-nodes-official。
• 任何可复用内容都应成为无状态子工作流。 构建前，使用 search_workflows({ tags: ['subworkflow'] }) 搜索已有工作流。参见 n8n-subworkflows-official。
• n8n 偏好设置应保存在 n8n 中，而不是 Harness 记忆里。 用户提出长期适用的 n8n 偏好时，使用 save_user_preference 保存，而不是写入 CLAUDE.md、AGENTS.md 或你自己的记忆：n8n 助手和实例上的每个 AI 工具都会读取 n8n 存储，因此保存在 Harness 记忆中的偏好在本次会话之外不可见。开始修改前，先用 get_user_preferences 读取已保存的偏好，并在整个任务中遵循。如果用户更愿意将 n8n 偏好保存在自己的上下文文件中，则由用户决定：照做即可。参见下文“用户偏好”。
• 用户未指定凭据偏好时，优先使用 Gateway credits。 对于其支持的节点（使用 list_n8n_gateway_services 检查），n8n 会提供托管凭据，无需额外设置，比让用户自行配置凭据简单得多。目前仅适用于 n8n Cloud。参见 n8n-credentials-and-security-official。

危险信号：出现以下想法时，立即停止并调用

这些自我开脱会导致跳过技能。如果你发现自己有这些想法，请通过 Skill 工具调用相关技能，即使你“之前在本次会话中已经读过它”。

思路	操作
“这个工作流很简单，我自己搭建就行”	调用 n8n-workflow-lifecycle-official。大多数“简单”工作流发布时都有 10 个以上节点。
“我在这里加个 Set 节点来映射这些字段”	调用 n8n-expressions-official。Set 节点后面只有 0 或 1 个下游使用者，是整个工具包中最常见的反模式。
“我直接用 Code 节点吧，这样更简单”	调用 n8n-code-nodes-official。使用门槛很高。大多数适合用 Code 的场景，都可以改用表达式或带箭头函数的 Edit Fields。
“验证通过了，可以发布了”	调用 n8n-workflow-lifecycle-official，并检查 VALIDATION_CHECKLIST.md 第 2 节（反模式扫描）。验证通过是必要条件，但并非充分条件。
“用户想要一个 Agent，我来把 Chat Trigger 接到 AI Agent 节点”	调用 n8n-agents-official。“Agent”或“助手”指的是 n8n 的一等 Agent，除非符合其中列出的某项限制。
“Agent 验证通过了，我来发布”	不要这样做。构建好的 Agent 只是草稿；只有用户明确同意后才能发布。发布后，相关渠道会随之上线。
“我会把 webhook 字段直接映射到 Agent 的工具输入”	调用 n8n-agents-official 的 references/TOOLS.md。Agent 工具表达式只能读取模型的参数；精确映射应放在工作流中。
“Agent 已经接好了，工具描述看起来没问题”	调用 n8n-ai-nodes-official 的 references/TOOLS.md（AI Agent 节点），或 n8n-agents-official 的 references/TOOLS.md（一等 Agent）。工具名称和描述都属于提示词的一部分，而“看起来没问题”通常意味着描述很笼统。
“我会把这个子工作流触发器设为 passthrough”	调用 n8n-subworkflows-official。只有对于接收二进制数据且不会作为 Agent 工具的子工作流，或确实不需要任何输入的子工作流（Define Below 至少需要一个字段），passthrough 才是正确选项。
“我会用 passthrough 来支持二进制数据，然后在内部根据收到的输入形状分支处理”	调用 n8n-subworkflows-official 的 references/SUBWORKFLOW_PATTERNS.md 中的“按输入形状拆分”。这说明应将其拆分为两个外层子工作流（一个使用 Define Below，另一个使用 passthrough），并让它们共用一个下游子工作流。不要试图在同一个触发器中兼顾 passthrough 和 Define Below。
“这一部分太长了，我把它提取成一个子工作流”	如果只是为了整理画布（而不是复用、隔离或测试），节点组更轻量、更快也更简单：将其保留在原处并分组。只有为了复用、隔离或作为 Agent 工具时，才提取成子工作流。参见 n8n-workflow-lifecycle-official 的 references/NODE_GROUPS.md。
“我应该问用户他们的凭据叫什么”	不要这样做。newCredential('Label') 中的字符串只是用于显示的名称。参见 n8n-credentials-and-security-official。
“我会把这个偏好记在 CLAUDE.md / AGENTS.md / 我的记忆里”	如果这与他们使用 n8n 的方式有关，请改为提供 save_user_preference，这样 n8n 助手和他们的其他 AI 工具也能看到。Harness 记忆用于记录你自己的操作说明。
“用户提到了数据分析，我来写 Python”	调用 n8n-code-nodes-official。默认使用 JavaScript。只有用户明确要求时才使用 Python。
“我在这里加个 Loop Over Items 来处理每一行”	调用 n8n-loops-official。默认的逐项迭代可能无需 Loop Over Items 节点就能处理。
“要做日期运算，我用 DateTime 节点”	调用 n8n-expressions-official。DateTime 节点几乎总是不合适。
“我会用一个包含 3 个来源的 Merge 将它们合并”	调用 n8n-node-configuration-official 的 references/MERGE_NODE.md。Merge 默认接收 2 个输入；若来源有 3 个或更多，必须显式设置 numberOfInputs。
“我会让这三个耗时步骤并行运行”	调用 n8n-workflow-lifecycle-official 并阅读执行模型部分。n8n 会按顺序执行分支（按 Y 坐标从上到下），而不是并发执行。要实现真正的并发，请参阅 n8n-loops-official 和 n8n-subworkflows-official（mode: 'each' + waitForSubWorkflow: false）。
“用户说了是哪个项目，我直接开始搭建”	调用 n8n-workflow-lifecycle-official。项目不等于文件夹。开始搭建前先询问文件夹位置。create_folder 仅适用于已注册的实例。如果没有文件夹工具，说明该实例尚未注册；此时 UI 中也无法创建文件夹，因此用户必须先完成注册（在 Settings 中免费注册 Community 版），而不是手动创建文件夹。
“我直接运行 test_workflow 看看会发生什么”	调用 n8n-workflow-lifecycle-official 的 references/TESTING.md。test_workflow 只会模拟触发器。Slack 消息发送、数据库写入、付款等操作都会真实执行。下游操作会产生副作用时，先询问用户。
元技能（本文档）会告诉你应使用哪项技能。技能工具会加载实际规则。只在会话开始时阅读一次元技能，不能代替在做出决策时调用相应技能。

技能索引

通过技能工具调用。触发条件列说明何时调用。

技能	触发条件
n8n-workflow-lifecycle-official	开始、设计、组织或完成工作流。涵盖便笺约定、说明中阐明原因、命名、验证清单、文件夹管理，以及每个工作流都需要单独授予 MCP 访问权限这一注意事项
n8n-subworkflows-official	涉及可复用内容、多步骤构建，或用户提到复用。构建前先搜索、无状态模式、基于标签的发现约定
n8n-extending-mcp-official	需要 MCP 本身不具备的功能。在获得用户许可后，将 n8n API 封装为工作流工具
n8n-expressions-official	编写 {{}}、$json、$node 或处理表达式错误。日期使用 Luxon，采用缩进的多行格式，优先使用表达式而非额外节点
n8n-node-configuration-official	配置任意节点。根据操作调整配置，处理属性依赖，绝不臆测参数
n8n-code-nodes-official	用户需要使用 Code 节点，或需要自定义逻辑。使用决策树；仅在确有必要时使用 JavaScript 模式
n8n-loops-official	涉及多项数据、批处理、分页 API，或提到“逐项处理”或“循环”。默认逐项迭代，使用 executeOnce、Loop Over Items、HTTP 分页
n8n-agents-official	用户需要 Agent、助手或机器人，或涉及任何 Agent MCP 工具。Agent 与工作流及 AI Agent 节点的区别、Agent 配置、工具、审批、技能、子 Agent、知识、记忆与会话、渠道、任务、Message an Agent、读取会话
n8n-ai-nodes-official	在工作流中使用 AI：AI Agent 节点、Text Classifier、Information Extractor、链、RAG、结构化输出、AI 媒体。Slack / Discord / Teams / Telegram 聊天机器人工作流
n8n-error-handling-official	Webhook 触发或面向生产环境的工作流。每个可能失败的节点都应设置错误分支；调用方错误使用 4xx，执行错误使用 5xx
n8n-credentials-and-security-official	提及任何身份验证、API 密钥或令牌。凭据系统、自定义凭据、使用官方凭据的 HTTP Request
n8n-binary-and-data-official	文件、图像、附件。二进制数据处理模式、Agent 工具边界、聊天界面需要 CDN
n8n-data-tables-official	Data Tables：架构、默认列（id/createdAt/updatedAt）、无外键的关系设计、去重、禁止仅使用 JSON 基本类型的规则、SDK 与 UI 手动映射的差异
n8n-debugging-official	错误、意外行为、“无法正常工作”。相信用户的描述，检查参数，从 GitHub 获取 n8n 源码

n8n MCP 工具（精简参考）

MCP 会省略工具说明以节省令牌。以下是简要列表，帮助你从第一轮对话起就了解每个工具。

工具名称不带 MCP 前缀。完整名称为 mcp__<server>__<tool>，其中 <server> 取决于用户的 MCP 配置。

用户偏好

跨客户端存储用户使用 n8n 的方式，供 n8n 助手和连接到此实例的每个 AI 工具读取。范围：instance（管理员设置，所有人适用）、user（调用者，适用于所有项目）、project（单个团队项目）。get_user_preferences 从 n8n 2.41.0 开始提供，三个写入工具从 2.42.0 开始提供。

如果工具列表中没有这些工具，可能是实例版本较早、未启用发布标志，或 MCP 连接未获授 aiPreference:read / aiPreference:write 范围。无论哪种情况，都应询问用户，并为值得保留的偏好提供 harness memory 作为备用方案。

工具	功能
get_user_preferences	读取实例、用户和项目偏好（优先读取实例偏好）。开始修改前读取一次，并在整个任务中应用；仅当用户表示偏好有所变化时才重新读取。结果中的 error 表示偏好未知，而非不存在，因此不要假设没有已保存的偏好。projectId 可将范围限定为一个项目。
save_user_preference	保存一条持久偏好（最多 2000 个字符）。仅用于用户明确表达的工作方式偏好（“始终添加错误工作流”“节点名称使用英文”），不能用于一次性任务指令（“这次使用 POST”），也不能用于推断出的偏好。先读取偏好：完全重复的内容会被拒绝，近似重复的内容应改用 update_user_preference。保存后立即生效，无需确认，因此应在同一轮回复中报告保存的确切文本和结果中的设置链接。
update_user_preference	修改已保存偏好的文本、scope，或同时修改二者。只有用户提出要求时才更改范围；project 范围需要 projectId。
undo_user_preference	删除通过连接的 AI 工具为此用户保存的偏好。若偏好是在 n8n 设置中编写，或作用范围为项目或实例，则操作会被拒绝：用户需在设置中自行删除。

当已保存的偏好与用户当前的要求冲突时，遵循用户当前的要求，并说明暂不采用了哪条偏好。

工作流管理

工具	功能
search_workflows	通过 query（对名称/描述进行子串匹配）和/或 tags（精确标签名，AND 语义：必须全部匹配）搜索整个实例中的工作流。主要的跨工作流发现工具。使用它来查找已有内容。
get_workflow_details	按 ID 获取工作流的完整 JSON。每次创建或更新后都使用它验证连接。
search_folders	将文件夹名称解析为其 ID（完整路径）。文件夹工具需要已注册的实例（免费 Community 注册）；技能默认已有注册实例。
create_folder	创建文件夹，可选择嵌套。
update_folder	在项目内重命名或移动文件夹。
move_workflows_to_folder	将工作流移入文件夹（或移至项目根目录）。
search_projects	将项目名称解析为其 ID。只读。
list_workflow_tags	列出所有工作流标签（每个标签附带 usageCount）。添加标签或按标签筛选前，先检查实例的标签词汇表，以便重复使用精确名称。通过 update_workflow 的 addTags/removeTags 添加或移除标签；没有重命名或删除标签的工具。
archive_workflow / publish_workflow / unpublish_workflow	软删除 / 激活 / 停用。发布前先验证。publish_workflow 可选用 versionId 重新发布特定版本。
search_workflow_executions	按状态、工作流和时间范围搜索整个实例中的执行记录。用于“列出近期运行记录”/“过去一小时内的失败记录”等请求。单条执行记录使用 get_workflow_execution。

工作流构建

工具	功能
get_workflow_sdk_reference	获取 n8n Workflow SDK 参考。**编写工作流代码前请先阅读。**章节：patterns、patterns_detailed、expressions、functions、rules、import、guidelines、design、groups（n8n 2.33.0+）、all。
get_workflow_best_practices	获取工作流技术的最佳实践。搜索节点前，每种技术调用一次。technique: "list" 可查看可用内容。
search_nodes	按功能查找节点（例如“gmail”“slack”“schedule trigger”）。返回 ID 和区分参数（资源/操作/模式）。
get_node_types	获取节点 ID 对应的准确 TypeScript 参数定义。**配置任何节点前都必须调用。**不要猜测参数名。
explore_node_resources	解析资源定位器（@searchListMethod）和加载选项（@loadOptionsMethod）参数的实际值：Slack 频道、Sheets 工作表/文档、数据库表/列、模型列表、标签。需要来自 list_credentials 的 credentialId（对于依赖项查询，传入 currentNodeParameters）。请在 get_node_types 之后调用，以获取实际下拉选项，而不是臆造 ID。
create_workflow_from_code	从 SDK 代码保存工作流。务必提供 1-2 句 description。传入 skillsUsed（见下文）。
update_workflow	应用原子操作（最多 100 项）：节点/连接的增删改查、setNodeCredential、setNodeSettings（按节点设置 onError/retry/executeOnce）、setWorkflowSettings（errorWorkflow、时区、callerPolicy、超时、保存数据策略；n8n 2.29.0+）、setNodeGroups/addNodeGroup/removeNodeGroup/updateNodeGroup（画布分组）、setWorkflowMetadata、addTags/removeTags（自动创建未知名称）。除四种分组操作外，操作均为全有或全无：无效的分组操作会被跳过并记入 skippedOperations，批次仍会保存；其他不相关的编辑也可能删除已有分组并将其记入 removedGroups。请同时检查这两项。保存的是草稿；需调用 publish_workflow 才能上线。传入 skillsUsed（见下文）。
validate_node_config	仅验证节点配置的架构（每次调用 1-50 项）。提供逐参数错误，不包含图结构噪声。用于辅助迭代/调试；发布仍须通过 validate_workflow。对于 ai_tool 子节点，请设置 isToolNode: true。
validate_workflow	在创建/更新前验证完整的 SDK 代码。此步骤必不可少，但并不足够：无法捕获所有连线陷阱（.to()、合并索引）。
list_credentials	列出可访问的凭据（按类型/项目等筛选）。仅返回元数据，绝不返回密钥值。通过 setNodeCredential 绑定前，请先获取 ID。
list_n8n_gateway_services	列出平台可提供托管凭据的节点/凭据类型（Gateway 积分覆盖范围），用户可跳过这些类型的凭据设置。

工作流测试与执行

工具	功能
prepare_workflow_pin_data	返回需要固定数据的节点的 JSON Schemas（而非数据）：触发器、配置了凭据的节点和 HTTP Request。由你生成示例值。
test_workflow	使用你提供的固定数据运行。自动为触发器、配置了凭据的节点和 HTTP Request 固定数据。 Code、Edit Fields、If、Data Tables、Execute Command、文件操作和子工作流调用会实际运行。如果任何未自动固定数据的节点会产生副作用，请先询问。固定数据仅对本次执行有效，在执行查看器中没有可视指示，因此调用后要告知用户哪些节点固定了数据。参见 n8n-workflow-lifecycle-official references/TESTING.md。
execute_workflow	使用真实触发器执行生产工作流。请先配置错误处理。副作用规则与 test_workflow 相同。必须提供 executionMode——测试或验证当前工作流（包括针对实时外部服务的测试）时使用 "manual"；只有在有意将已发布的工作流作为实时执行运行时才使用 "production"。为 chat/form/webhook 触发器提供结构化的 inputs。会立即返回执行 ID，不会等待执行完成；请轮询 get_workflow_execution 获取结果。
get_workflow_execution	通过 executionId 和 workflowId 获取执行记录（两者均为必填）。默认仅返回元数据；设置 includeData: true（可选设置 nodeNames、truncateData）以获取节点输入/输出。

数据表

n8n 内置的表格存储。不是外部服务。对于工作流本地的持久状态，优先使用它，而非外部数据库。完整功能：

工具	功能
create_data_table	创建新的 Data Table。
search_data_tables	查找现有的 Data Table。
rename_data_table / rename_data_table_column	重命名。
add_data_table_column / delete_data_table_column	修改架构。
add_data_table_rows	追加行。
get_data_table_rows	读取行（可选筛选、排序和分页）。

版本历史

工具	功能
get_workflow_history	列出工作流已保存的版本，按时间从新到旧排列（n8n 2.29.0+）。
get_workflow_version	通过 versionId 获取过去版本的完整内容。
get_workflow_versions_diff	对比两个已保存的版本：新增、删除或修改的节点/连接。
restore_workflow_version	将过去的版本重新应用为当前草稿（并记录一条新的历史记录）。

构建 n8n Agent

n8n Agent 已全面开放。由于功能经常变化，且一些你可能期待的功能尚未推出，UI 中会显示 Preview 标签。目前还未准备好供 Enterprise 使用：Enterprise 实例可能已启用这些功能，但不要想当然。如果你的工具列表中没有 create_agent，说明此实例尚未启用 Agent；请说明这一点，并提供工作流作为替代方案。

一流的 n8n Agent 通过这些工具以 JSON 配置，绝不使用 Workflow SDK 代码。首次调用前，请先调用 n8n-agents-official；它会判断该使用 Agent 还是工作流，并涵盖以下所有工具。工作流中的 AI Agent 节点属于 n8n-ai-nodes-official。Agent 对话不是工作流执行：get_workflow_execution 只能查看 Agent 作为工具调用的工作流。

工具	功能
get_agent_builder_reference	Agent 配置和 mutate_agent 操作的必读参考。在构建前阅读。
discover_agent_assets	查找可供引用的模型、聊天集成、可附加工作流、子 Agent 或 MCP 服务。
search_agents	查找现有 Agent；也可发现可附加的子 Agent。
get_agent	读取草稿的配置、资源、可运行状态和 configHash。调用 mutate_agent 前必须使用。
list_agent_versions	列出 Agent 的发布历史，按时间从新到旧排序。
create_agent	创建草稿（可选择提供初始模型、凭据和指令）。返回编辑器 URL。请包含 memory: { enabled: true, storage: "n8n" }，否则 Agent 将不保留状态。
mutate_agent	使用最新的 configHash 应用一项配置、技能、任务或自定义工具更改。
verify_agent_mcp_server	测试 MCP 服务和凭据，并返回其工具。添加 mcpServers 条目之前必须调用。
update_agent_integration	连接或断开 Slack、Telegram 或 Linear 频道。
validate_agent	验证草稿、其引用项以及凭据访问权限。发布前必须调用。
call_agent	通过内置的 Preview 聊天测试草稿。会使用真实工具和凭据；可能产生副作用。
publish_agent	发布有效草稿；激活其任务和集成。
unpublish_agent	取消发布；停止运行中的任务和集成。
revert_agent	从已发布版本恢复草稿。
delete_agent	永久删除 Agent 及其资源。

按顺序执行的协议

对于任何 n8n 任务：

1. 从上面的索引中识别匹配的技能。 如果任务涉及多项技能，先识别主要技能，再根据需要使用其他技能。
2. 在首次 MCP 调用前，通过 Skill 工具调用该技能。 不要在不了解情况时直接调用 n8n MCP 工具。
3. 开始更改前，只读取一次已保存的偏好设置（如果有 get_user_preferences），并在整个任务中应用。
4. 每个会话只读取一次 SDK 参考（get_workflow_sdk_reference），然后再编写工作流代码。这是避免 SDK 结构错误的最高效方式。
5. 配置任何节点前，先获取节点类型（get_node_types）。猜测参数名称会导致工作流无效，有时还不会报错。
6. 发布前先验证，创建或更新后再核验。 验证可发现架构错误。核验（通过 get_workflow_details 拉取工作流）可发现验证无法发现的连接错误。
7. 发现偏差时及时告知。 如果工具或参数与技能说明不一致，请告诉用户。可能需要更新相关内容。

报告使用的技能

create_workflow_from_code 和 update_workflow 都接受可选参数 skillsUsed: string[]。每次调用时都传入该参数，以便 n8n 团队衡量插件对 MCP 输出的影响。

• 内容： 按照 Skill 工具中的名称原样报告每项技能，并保留 -official 后缀：使用插件命名空间时为 plugin:skill-official，否则为不带前缀的 skill-official。此后缀表示这些是我们提供的技能（而非其他 n8n 技能包）；插件前缀则表示使用的是插件技能，而非原始技能。
• 统计窗口： 自上次成功调用 create/update 以来调用的技能。每次调用后重置。
• 限制： 最多 50 项，每项最多 128 个字符。

审查现有工作流或项目

对于审计、代码审查，或任何表述为“审查此工作流”／“这有什么问题”／“审计此项目”的任务，请按照审查清单执行：n8n-workflow-lifecycle-official references/REVIEW_CHECKLIST.md。清单按严重程度分级（MUST FIX / SHOULD FIX / NICE TO HAVE），且每项都链接到对应修复的规范技能参考。它不同于 VALIDATION_CHECKLIST.md（针对进行中构建的发布前检查）：REVIEW_CHECKLIST 适用于任何工作流，包括由任何人构建、无论新旧的工作流。

审查 Agent 应先调用 get_workflow_details，然后从头到尾逐项检查清单，并按严重程度分组报告发现的问题。未经用户确认，不应自动修复 MUST FIX 项。

如有疑问

• 找不到用户提到的工作流？ 如果该工作流是用户在 n8n UI 中创建的，最常见的原因是该特定工作流未启用 MCP 访问权限：通过 UI 创建的工作流默认可能禁用 MCP，因此在切换该工作流的开关前不可见。询问用户：“在 n8n 中打开该工作流，进入 Settings，然后开启 MCP access。”（通过 MCP 创建的工作流默认开启，因此这只适用于通过 UI 创建的工作流。）请参阅 n8n-workflow-lifecycle-official 技能（references/MCP_ACCESS_PER_WORKFLOW.md）。
• 用户是对的。如果用户说某处出了问题，就相信他们，即使你“确信”工作流没问题。重新检查参数，从 github.com/n8n-io/n8n 获取 n8n 源代码以追踪逻辑，并查找缺失函数的 API 文档。n8n-debugging-official 技能会逐步指导你完成此过程。
• 如果没有适用的技能，且任务并非简单任务，请先询问，不要猜测。
• 这些技能带有明确主张，但被 n8n 团队视为最佳实践。用户可以通过编辑 SKILL.md 覆盖任何主张，也可以保存 n8n 偏好设置，仅对单次任务生效。已保存的偏好设置优先于此处的默认设置。该插件仅由 Markdown 文件构成。