Gemini 4 Argon 发布首日实测：n8n 自动化工作流深度体验

Google 最新模型 Gemini 4 Argon 发布当天，一位 YouTube 创作者在 n8n 平台上进行了完整实测：从 AI 助手辅助搭建工作流，到通过 MCP 协议接入 Anti-Gravity CLI，再到构建完整的数据看板。整个过程中，模型展现出了惊人的长程推理能力和安全设计意识，但在 UI 审美上仍有明显短板。

基准测试：三个关键指标

在深入实测之前，先看看 Google 官方公布的基准数据。对于构建 n8n 自动化工作流而言，三个指标最有参考价值：

• Vibe Code Bench：91.9%——衡量模型在代码生成与理解方面的综合能力
• Deep Software Engineering：77.9%——评估深度软件工程任务的表现
• Automation Bench：51.3%——专门针对自动化场景的测试

Google 表示，Argon 专为「在复杂长周期工作流中维持深度推理」而设计。定价方面，首发 API 价格为每百万输入 token 2 美元、每百万输出 token 10 美元，缓存输入可享受 95% 折扣。

助手模式：从提示词到可运行工作流

测试者构建的是一个报价请求自动化流程：表单提交后，AI Agent 对线索进行评分并起草回复，数据存入 n8n 数据表，紧急情况触发 Slack 告警。

这个示例巧妙地展示了同一个模型的两种用法——既作为 n8n 助手背后的 LLM 来搭建工作流，也作为工作流内部的模型节点来执行任务。你可能没注意到，这个场景恰好触达了提示注入的典型风险区域：Agent 需要读取陌生人输入的文本。而根据 Google 在 GraySwan 基准上的结果，Argon 在所有被测模型中拥有最低的攻击成功率。

构建过程并非完全顺畅。首次请求耗时 2 分 39 秒后遭遇了「请求过多」的错误，测试者推测可能是因为短时间内调用了大量工具，也可能只是早期发布阶段的正常波动。继续构建后，模型思考了近 9 分钟才完成凭据配置。最终它自动完成了数据表创建，并在请求授权后执行了实时测试。

一个有趣的细节：模型在测试时移除了所有其他节点中的模拟数据，只保留了初始节点的数据。Slack 频道的消息和 Gmail 中的草稿回复都正确生成，验证了整条链路。

提示注入（Prompt Injection）是 LLM 应用中最常见的安全威胁之一。当 Agent 需要处理来自外部的不可信文本（如用户填写的表单、邮件内容、网页抓取结果）时，攻击者可能在这些文本中夹带指令，诱导模型偏离原始任务，例如泄露系统提示、调用未授权工具或篡改输出。GraySwan 是一家专注 AI 安全红队测试的机构，其基准通过构造大量对抗性输入来评估模型抵抗注入攻击的能力，攻击成功率（ASR）越低代表防御越强。文中提到 Argon 在该基准上取得所有被测模型中最低的攻击成功率，意味着它在面对恶意输入时更不容易被「带偏」，这对于需要读取陌生人文本的自动化工作流而言是关键的安全保障。

MCP 接入：让外部 Agent 操控 n8n

接下来测试者使用 Anti-Gravity 的 CLI 工具，尝试为这套数据构建一个可视化看板。这需要打通 Agent 与 n8n 工作流之间的通信通道，而 MCP（Model Context Protocol）正是答案。

在 n8n 设置中找到 Instance Level MCP 选项，连接后可以获得服务器 URL 和访问令牌。将这段 JSON 配置粘贴到 Anti-Gravity 的 MCP 配置文件中，n8n MCP 就会以绿色状态显示，所有可用工具一目了然。

测试者还推荐安装官方技能包（通过 npx skills add nanio/skills 命令），这套技能为 Agent 提供了关于 n8n 功能和使用方式的上下文，帮助它更高效地找到正确的 API 文档，避免在无效搜索上浪费 token。

MCP（Model Context Protocol）是 Anthropic 于 2024 年底开源的一项协议标准，旨在为 AI 模型与外部工具、数据源之间提供统一的通信接口。它的核心思路类似「AI 领域的 USB-C」：在此之前，每个 Agent 框架要接入某个服务（如数据库、项目管理工具、自动化平台），都需要单独编写适配代码；而 MCP 通过标准化的服务器/客户端架构，让任何支持该协议的模型都能即插即用地调用外部能力。MCP 服务器负责暴露「工具（Tools）」「资源（Resources）」和「提示（Prompts）」三类原语，客户端（即 Agent 宿主）则负责发现并调用这些能力。在 n8n 场景中，启用 Instance Level MCP 后，n8n 本身就成了一个 MCP 服务器，把工作流管理、执行查询等操作封装为工具，Anti-Gravity 等外部 Agent 便可直接操控 n8n，无需为每个操作手写 API 调用逻辑。

看板构建：安全意识到位，审美有待提升

配置完成后，Anti-Gravity Agent 迅速识别出可用技能，获取上下文后开始调用 MCP 工具。测试者的目标是让 Agent 用 Next.js 构建一个替代表单节点的自定义界面，同时提供数据看板——而 n8n 仍然作为后端服务，保持可观测性和执行历史查询能力。

Agent 在完成后标记了两个问题：一是工作流层面的 MCP 未启用（需要在三个点菜单中单独开启），二是建议创建 webhook 保护密钥。测试者指出，这个看板没有登录系统，不适合直接部署到生产环境。

真正令人印象深刻的是模型对安全边界的理解。它主动识别出数据从数据库到看板的传输过程需要安全保障，并正确使用了 n8n 的 webhook 节点来处理错误响应（如 bad request 和服务器错误），还通过分组来优化工作流结构。测试者观察其思考过程长达 20 分钟，发现它「真的在努力寻找边缘情况」。

看板最终产出了 AI 分诊摘要、LLM 分类的思考过程（如为何某请求被评为 10 分）以及自动起草的邮件。但测试者对界面风格并不满意，特别是将报价请求表单直接放在看板内部这个设计决策。

Webhook 是 n8n 中用于接收外部 HTTP 请求的触发器节点，常用于让第三方系统（如前端表单、支付回调、监控告警）主动向工作流推送数据。与普通 HTTP 请求节点不同，Webhook 节点会暴露一个唯一 URL，任何知道该地址的人都能向其发送请求，因此它天然处于信任边界之外。若不加保护，攻击者可以伪造请求注入恶意数据，甚至触发后续的自动化操作。n8n 提供了多种防护手段：可在节点上启用 Basic Auth 或 Header Auth 校验请求头，也可通过 URL 中的路径参数作为简易密钥。文中 Agent 建议创建 webhook 保护密钥，正是识别到看板与后端之间的这条数据通道若暴露在公网将带来风险，体现了它对应用安全架构的理解。

实测结论

Gemini 4 Argon 在 n8n 场景下展现出了鲜明的特点：在代码生成、安全设计和边界情况处理方面表现出色，尤其是对提示注入的防御能力和对应用安全架构的理解超出预期。但在 UI/UX 审美和产品思维方面，仍有明显提升空间。

首发阶段的请求限制和较长的思考时间也提示，这款模型目前更适合对延迟不敏感、但对可靠性和安全性有较高要求的自动化场景。