n8n项目中Google Gemini模型在Agent节点中的兼容性问题分析

问题概述

在n8n工作流自动化平台中，用户报告了一个关于Google Gemini模型与Agent节点兼容性的技术问题。当用户尝试在LangChain Agent节点中使用Google Gemini模型时，系统会返回错误信息，而同样的配置在OpenAI模型上却能正常工作。

错误现象

主要错误表现为两种形式：

1. 参数类型错误：系统提示"GenerateContentRequest.tools[0].function_declarations[3].parameters.properties[Query__JSON_Format_].type: must be specified when not using one_of, any_of or all_of fields"，表明在请求参数中缺少必要的类型定义。

2. 空内容部分错误：另一种常见错误是"contents.parts must not be empty"，指出API请求中包含了一个空的parts数组，这违反了Gemini API的要求。

技术分析

通过对问题工作流的深入分析，发现问题的根源在于LangChain Agent节点与Google Gemini API之间的消息格式转换问题。

消息格式转换问题

当Agent节点处理输入时，它会构造一个messages数组发送给Gemini模型。问题工作流中构造的消息格式如下：

"messages": [
  "System: You are an expert AI assistant...",
  "Human: Title: \ntesting\n\nDescription:\n\n\nDiff:\n\ndiff --git a/.docker/auth.Dockerfile...",
  "Human: []"  // 问题所在
]

可以看到，Agent节点在消息数组末尾添加了一个空的"Human: []"消息。当这个格式被转换为Gemini API请求时，会导致生成一个空的parts数组，从而触发API的验证错误。

与不同模型的兼容性差异

值得注意的是，这个问题仅出现在Google Gemini模型中，而OpenAI和Ollama模型却能正常工作。这表明：

1. 不同AI模型API对输入格式的要求存在差异
2. Gemini API对输入格式的验证更为严格
3. 当前LangChain Agent节点的消息构造逻辑未能完全兼容Gemini API的要求

解决方案

针对这一问题，我们建议以下几种解决方案：

1. 简化工作流结构

由于许多使用场景并不需要Agent节点的全部功能，可以考虑使用更简单的节点组合：

• 使用Chat Prompt Template节点（@n8n/n8n-nodes-langchain.promptTemplateChat）明确构造系统消息和用户消息
• 直接将模板输出连接到Google Gemini Chat Model节点
• 这样可以完全控制发送给LLM的消息格式，避免Agent节点的中间转换

2. 更新节点版本

检查并更新以下节点到最新版本：

• @n8n/n8n-nodes-langchain.agent
• @n8n/n8n-nodes-langchain.lmChatGoogleGemini

新版本可能已经修复了相关的格式转换问题。

3. 添加安全设置

虽然不是导致当前错误的原因，但建议在Google Gemini Chat Model节点中添加safetySettings配置，以防止未来可能的内容审核问题。

最佳实践建议

1. 明确消息格式：在使用Gemini模型时，确保每条消息都有明确的内容，避免空的parts数组。

2. 逐步测试：构建复杂工作流时，建议逐步测试每个节点的输出，确保中间格式符合下游节点的要求。

3. 模型特性了解：不同AI模型API有各自的特性要求，使用前应充分了解其文档中的输入输出规范。

4. 错误处理：在工作流中添加适当的错误处理节点，捕获并记录API返回的错误详情，便于调试。

总结

n8n平台中Google Gemini模型与Agent节点的兼容性问题主要源于消息格式转换的不匹配。通过简化工作流结构或更新节点版本，可以有效解决这一问题。理解不同AI模型API的特定要求，对于构建稳定可靠的工作流至关重要。随着n8n平台的持续更新，这类兼容性问题有望得到进一步改善。