n8n 企业用户的 AI Assistant 网关代理

自托管 n8n 的企业用户正把 LLM 访问收敛到内部 AI 网关或共享 service account，但 n8n 的 AI Assistant 只支持 OpenAI 兼容端点，且不支持自定义出站 header。结果是：

• 走内部网关的请求因缺少路由 header 直接被拒——信号 4 原话：“Without that header every request is rejected with a 400, so today the Assistant can’t connect to it at all.”
• 用 Anthropic 兼容端点或路由器（AgentRouter、GoRouter）的用户根本接不上 Assistant（信号 3、5）
• 用共享 API key 的团队无法把 LLM 用量归属到真实用户，信号 1 请求支持 X-User-Email 等 header
• 桌面 Docker 自托管用户配置 Service URL 和 API key 时直接失败（信号 2）

注意：这些需求均以 n8n 社区功能请求形式出现，互动量低（多数 0-2 分、0-1 条评论），说明是真实但小众且分散的痛点。

画像： 自托管 n8n 的企业开发者与平台/IT 团队，其组织通过内部 OpenAI 兼容网关、Anthropic 兼容路由（AgentRouter、GoRouter）或共享 service account 统一管控 LLM 访问。

规模： 定性判断为小众细分——是“n8n 自托管企业用户 × 走内部 LLM 网关”的交集，社区信号互动量低，天花板有限，更像一个切入企业 AI 网关生态的楔子而非大市场。

一个自托管、单容器部署的 OpenAI↔多协议 LLM 网关代理，专门服务 n8n Assistant 这类“只会说 OpenAI 方言”的内嵌 AI 功能：

• 对内暴露 OpenAI 兼容端点，让 Assistant 以为自己在连 OpenAI
• 对外转发到 Anthropic 兼容端点或任意内部网关（对应信号 3、4、5）
• 按 UI/env 配置注入静态与规则化自定义 header（X-User-Email、X-Request-Origin 等，对应信号 1、4）
• 逐请求记录 token 用量，把共享 service account 的消耗归属到真实用户
• 兼容转发 Bedrock per-request metadata（对应信号 1）

AI 的角色： 产品本身不生成内容，价值在于对 LLM API 流量做协议适配、身份注入与用量归因，是企业 AI 基础设施的一环。

信号（均为 2026 年 9 月）显示企业正在把 LLM 访问收敛到内部网关和共享 service account，并开始要求按真实用户归属用量（信号 1 提到 Bedrock per-request metadata），而 n8n Assistant 的连接能力尚未跟上，形成了一个明确的空窗期——但这个窗口随时可能被官方关闭。

第一版做：

• 单容器部署的代理，暴露一个 OpenAI 兼容端点供 n8n Assistant 填入
• 支持一个 Anthropic 兼容上游（如经 AgentRouter/GoRouter 或自托管端点）
• 通过环境变量或简单配置文件注入静态自定义 header（对应信号 4 的 N8N_INSTANCE_AI_MODEL_HEADERS 思路）
• 按请求记录 token 用量与来源标识，可导出简单报表

第一版不做：

• 不做管理后台、多租户、计费
• 不做 Bedrock per-request metadata 的完整兼容（信号 1 提到，留作后续）
• 不修改 n8n 本体，纯外部代理

平台依赖（最大风险）： 整个机会寄生在 n8n Assistant 的连接限制上，5 条信号本身就是官方功能请求，n8n 补齐 Anthropic 端点或 header 支持后需求即消失。

市场规模： 信号互动量极低，付费意愿多为 none，可能只是一个功能补丁级别的需求，撑不起独立产品。

协议碎片化： 各企业内部网关（Bedrock metadata、Anthropic 兼容、自研网关）行为不一，兼容矩阵会持续膨胀。

合规： 代理会接触企业 LLM 流量与用户标识（X-User-Email），需处理日志脱敏与企业部署信任问题。