连错一个端口，Agent 就"看不见"工具：从 n8n 的 8 种 AI 连接类型到 Dify 的插件审批复用
写 Agent 应用的人大概都经历过类似的排查：提示词没毛病、模型选得没问题、工具节点也建了，但 Agent 运行时就是不调用那个工具。很多人第一反应是怀疑模型能力或者提示词写得不好，结果兜兜转转发现------线接错了端口。这类问题不是玄学故障，而是平台设计里的"隐形接线规则"。今天把 n8n 和 Dify 两个平台在这方面的规则拆开看，整理成一张可以逐项检查的清单。
一、n8n：8 种 AI 连接类型，端口即"可见性开关"
在《n8n+AI工作流：从入门到企业级AI应用实战指南》（腾讯云开发者社区）这篇资料里，有一个被作者称为"整个架构中最重要的事实"的规则：
Agent 节点与子节点之间通过 8 种专门的 AI 连接类型进行协作------一个连接到主端口而非专用
ai_端口的工具，对 Agent 是不可见的。
这句话值得展开解释。n8n 的节点连线是分类型的：Agent 节点下方会延伸出若干专用端口，分别对应不同角色的子节点------工具（Tool）、记忆（Memory）、模型（Chat Model）、输出解析器（Output Parser）等。如果你习惯性地把一个工具节点拖到画布上，从它的主输出端口连到 Agent 的主输入端口，那么在数据流层面这条线是"通的"，但在 Agent 的视角里，这个工具根本不存在------它不会出现在 Agent 可调用的工具列表中，模型自然也不会去调用它。
这就是"连错一个端口，Agent 就看不见工具"的由来。故障的表象是"Agent 不调用工具"，根因却是一根连线。这类问题排查起来特别磨人，因为画布上一切看起来都正常。
由此得出的实操建议：
- 工具必须挂在 Agent 节点的专用工具端口上，而不是主链路的数据端口。工具是"登记给 Agent 用的"，不是"流经 Agent 的数据"。
- 检查连接类型，而不是只检查连线是否存在。n8n 的连接分为 8 种 AI 类型，连错类型就等于功能失效。
- Memory 也要走专用端口。把记忆子节点接错位置，Agent 会表现为"记不住上下文"，同样容易被误诊为提示词问题。
二、Dify：用 Marketplace 和插件审批把"接线"前置到安装环节
如果说 n8n 的接线规则发生在画布上，那 Dify 的对应约束则发生在更上游------插件安装与审批环节。
根据 Dify 官网（dify.ai/zh）的介绍，其 Marketplace 支持：
从 Marketplace 安装模型供应商、工具、数据源与 MCP 集成，或自定义接入。团队可跨应用复用已审批的插件，无需逐项目重复配置。
这说明 Dify 把"工具能否被 Agent 看见"分成了两层：
- 平台层：模型供应商、工具、MCP 集成要先在 Marketplace 安装（或在团队内通过审批）才存在。没装的模型和工具，任何应用和 Agent 都无法使用。
- 应用层：构建 Agent 时手动配置模型、指令、Skills、工具和知识库。装好的插件不等于自动启用，仍要在应用配置里显式勾选。
这个设计的好处是治理清晰：团队管理员审批一次，后续应用直接复用，避免每个项目重复配置、重复授权；坏处是多了一层"你以为装了就能用"的认知落差------比如插件装在平台层了，但构建 Agent 时忘了在工具列表里勾选，效果同样是"Agent 看不见工具"。
另外从《一文入门智能体：dify 超快速构建AI agent》（知乎）可以看到 Dify 在应用层还有一些类似的"结构性约束"，比如：Chatflow 内置聊天记忆（Memory），可在 LLM、问题分类等节点开启，而 Workflow 没有 Memory 相关配置，无法开启 ；Workflow 的结束用 End 节点，Chatflow 的流式输出用 Answer 节点。也就是说，在 Dify 里"Agent 有没有记忆能力"，同样取决于你选了哪类应用、在哪个节点开了什么开关------和 n8n 的端口逻辑异曲同工：能力不是"默认就有"的，而是被平台的结构性设计约束的。
三、一张"工具可见性"排查清单
把两个平台的规则合并，可以整理成一张通用检查表。下次遇到"Agent 不调用工具"，按顺序过一遍：
| 检查项 | n8n | Dify |
|---|---|---|
| 工具是否接入平台 | 集成节点是否存在（400+ 原生集成之外需自定义） | 插件/工具/MCP 是否已从 Marketplace 安装并通过审批 |
| 工具是否连接到正确位置 | 是否连到 Agent 的专用 ai_ 工具端口，而非主数据端口 |
是否在 Agent/应用配置中显式勾选该工具 |
| 模型是否可用 | Chat Model 是否接入专用模型端口 | 模型供应商是否已安装并在应用中配置 |
| 记忆是否生效 | Memory 子节点是否接到专用端口 | 是否使用 Chatflow（或 Agent）并开启了 Memory |
| 数据通路 | 主链路（非 AI 端口）连线是否正确 | Workflow/Chatflow 的节点编排与变量（如 sys.query）是否匹配 |
四、适用范围与局限
这套"接线规则思维"适用于使用 n8n、Dify 这类可视化编排平台构建 Agent 的场景，尤其是多节点、多工具的复杂工作流。它的局限也很明显：
- 它解决不了"模型能力不够"的问题。接线全对，模型仍可能因为工具描述写得含糊而不选用某个工具，这时要优化的是工具的 description 和系统提示词。
- 两个平台的具体 UI 和字段会随版本演进，文中引用的连接类型数量、Marketplace 功能以各平台当前官方文档为准。
- 清单是排查工具，不是设计准则。设计阶段的重点仍是：哪些任务交给确定性工作流，哪些交给 Agent 自主决策------n8n 与 Dify 的组合（Dify 做对话"大脑"、n8n 做执行"手脚"，通过 API 连接）本身就是一种值得考虑的分工方式。
结语
"Agent 看不见工具"这类故障，本质是平台的结构性约束在起作用：n8n 用 8 种 AI 连接类型和专用端口划分数据流与 AI 协作流，Dify 用 Marketplace 安装与插件审批划分平台层与应用层。理解了这些隐形规则，所谓玄学故障就变成了顺着清单走一遍的工程问题。下次画布上一切看起来都正常时，先低头看看------线，接对端口了吗？
参考资料
以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中；资料内容与适用范围以原始页面为准。