用 n8n 为 Live Agent Studio 搭建 AgentBase Sample Agent 与 Agent Node 双模板实战指南【免费下载链接】ottomator-agentsAll the open source AI Agents hosted on the oTTomator Live Agent Studio platform!项目地址: https://gitcode.com/GitHub_Trending/ot/ottomator-agentsoutput 文章n8n 搭建 Live Agent Studio Agent 实战Base Sample Agent 与 Agent Node 双模板详解本文是 oTTomator 仓库中~sample-n8n-agent~模板的技术指南。该模板演示了在 Live Agent Studio 平台上构建 n8n Agent 所需的最小组件集Webhook 入口、输入字段解析、会话消息持久化与结构化响应。读完本文你将掌握两个开箱即用的工作流模板Base Sample Agent 与 Agent Node Sample的完整节点链路、消息协议、凭据配置方法并能基于模板在画布上插入自定义 Agent 逻辑快速产出可被 Live Agent Studio 直接托管调用的 n8n Agent。模板定位Live Agent Studio 上的 n8n Agent 参考实现Live Agent Studio 是一个社区驱动的 AI Agent 平台仓库 README.md 中说明该仓库收录了平台上所有 Agent 的源码与工作流 JSON其中~sample-n8n-agent~与~sample-python-agent~被明确列为两类官方起点模板——前者面向 n8n 工作流后者面向 Python FastAPI。n8n 模板的价值在于它定义了一套平台约定即 Live Agent Studio 通过 Webhook 投递统一格式的请求载荷Agent 处理完成后必须按约定格式回写消息与响应平台才能正确渲染会话、追踪请求与持久化对话历史。~sample-n8n-agent~/README.md明确指出该模板由 Cole Medin 编写包含两个工作流实现工作流文件特点适用场景Base Sample AgentBase_Sample_Agent.json手动管理输入、输出与会话历史使用 Supabase 存储消息大多数场景需要完全控制会话历史管理Agent Node Sample AgentAgent_Node_Sample_Agent.json使用 n8n 内置 Agent 节点会话历史由 Agent 节点接管支持任意 Postgres 数据库简单 Agent 场景快速搭建核心组件一个 Studio Agent 必须具备的四件事模板 README 将最小 Agent 抽象为四个核心组件两个工作流均严格遵循这一骨架Webhook Endpoint接收带认证的 POST 请求携带用户与会话信息通过 Header 认证保证通信安全Input Processing从请求体中提取query用户问题/指令、user_id用户唯一标识、request_id请求追踪 ID、session_id当前会话标识四个关键字段Database Integration记录用户消息与 AI 响应携带元数据维护会话历史Base 版用 SupabaseAgent Node 版用任意 PostgresResponse Handling统一结构化响应格式包含成功/失败状态并通过 Webhook 返回格式化结果。这套骨架与~sample-python-agent~模板sample_supabase_agent.py中 FastAPI 端点做的事完全对应说明它是整个 Live Agent Studio 的通用 Agent 协议而非 n8n 独有。统一消息协议输入与输出 JSON模板 README 给出了平台约定的消息格式这是对接 Studio 的接口契约。输入Webhook 请求体{ query: Users question or command, user_id: unique-user-identifier, request_id: request-tracking-id, session_id: conversation-session-id }两个工作流 JSON 的pinData中内置了一份真实测试载荷展示了 Studio 实际投递的完整请求含请求头与 body其中authorization头携带Bearer YOUR BEARER TOKENbody 内容与上表完全一致例如{ query: Supabase, user_id: google-oauth2|116467443974012389959, request_id: f98asdyf987yasd0f987asdf8, session_id: google-oauth2|116467443974012389959~2~8dfbddbe603d }输出Webhook 响应体{ success: true, output: AI response content, data: Additional response data }注意n8n 的响应并非直接在 Webhook 节点拼装 JSON而是通过数据库节点 → 输出准备节点 → Respond to Webhook 节点的链路完成详见下文节点拆解output字段来自 AI 消息节点写入的内容data字段承载request_id等附加数据。深入 Base_Sample_Agent.json手动管理会话历史的完整链路Base 版工作流是一条线性执行链每个节点承担明确职责。从 JSON 的nodes与connections字段可以完整还原其拓扑Webhook → Prep Input Fields → Add User Message to DB → (在此插入 Agent 逻辑) → Add AI Message to DB → Prep Output Fields → Respond to Webhook1. Webhook 节点入口{ parameters: { httpMethod: POST, path: 9a6c4630-b422-4d42-b894-81ecfe881ffe, authentication: headerAuth, responseMode: responseNode }, type: n8n-nodes-base.webhook, typeVersion: 2, credentials: { httpHeaderAuth: { name: Header Auth account } } }仅接受POSTpath为随机 UUID部署到 Studio 后平台会替换为正式路径authentication: headerAuth启用 Header 认证对应凭据Header Auth account。README 注明该认证在自托管测试阶段为可选正式上架托管时由 Studio 统一配置responseMode: responseNode表示响应交给后续的 Respond to Webhook 节点统一输出而非立即返回。2. Prep Input Fields 节点输入解析这是n8n-nodes-base.set节点typeVersion 3.4通过四个赋值把 Webhook 请求体中的字段提取为工作流顶层字段字段表达式query{{ $json.body.query }}user_id{{ $json.body.user_id }}request_id{{ $json.body.request_id }}session_id{{ $json.body.session_id }}这样后续节点无需再写$json.body.*语义更清晰也完成了验证必填字段的职责。3. Add User Message to DB 节点写入用户消息n8n-nodes-base.supabase节点typeVersion 1向messages表插入一条记录{ parameters: { tableId: messages, fieldsUi: { fieldValues: [ { fieldId: session_id, fieldValue: {{ $json.session_id }} }, { fieldId: message, fieldValue: {{ {\n\type\: \human\,\n\content\: $json.query,\n\additional_kwargs\: {},\n\response_metadata\: {}\n} }} } ] } }, type: n8n-nodes-base.supabase, credentials: { supabaseApi: { name: Prod Supabase account } } }写入的message字段是一个 JSONB 对象type为humancontent取用户输入additional_kwargs与response_metadata字段与 LangChain 消息结构对齐便于与主流 Agent 框架互操作。4. 中间预留的 Agent 逻辑插槽画布上的 Sticky Note粘滞便签明确标注Add agent logic here——任何能生成输出、供右侧节点存为 AI 消息的逻辑都可以放在这里。即该节点位置是模板为你预留的扩展点你可以串联任意 n8n 节点HTTP 请求、模型调用、工具节点等生成output并继续沿主链路传下去。5. Add AI Message to DB 节点写入 AI 响应同样是 Supabase 节点向messages表写入 AI 消息。关键差异在于字段引用方式{ fieldId: session_id, fieldValue: {{ $(Prep Input Fields).first().json.session_id }} }, { fieldId: message, fieldValue: {{ {\n\type\: \ai\,\n\content\: $json.output,\n\data\: $json.data,\n\additional_kwargs\: {},\n\response_metadata\: {}\n} }} }session_id通过$(Prep Input Fields)显式回溯上游节点取值避免依赖隐式的单节点输入message对象多了一个data字段承载request_id等附加数据type为ai。6. Prep Output Fields 与 Respond to Webhook 节点输出Prep Output FieldsSet 节点将success赋值为布尔true完成状态标记Respond to Webhook节点typeVersion 1.1以respondWith: allIncomingItems把整条数据作为响应体返回并附带X-n8n-Signature响应头形成带签名校验的稳定响应。这条链路保证了用户消息落库 → Agent 处理 → AI 消息落库 → 结构化返回的完整闭环任何自定义逻辑只需嵌入第 4 步的插槽即可落库与响应协议完全复用。深入 Agent_Node_Sample_Agent.json让 Agent 节点接管会话历史Agent Node 版是对 Base 版的简化删除了两个手动写库的 Supabase 节点改为 n8n LangChain 生态的 Agent 节点 记忆节点组合拓扑如下Webhook → Prep Input Fields → AI Agent → Prep Output Fields → Respond to Webhook ├── ai_languageModel: Anthropic Chat Model └── ai_memory: Postgres Chat MemoryAI Agent 节点n8n/n8n-nodes-langchain.agenttypeVersion 1.7配置{ parameters: { promptType: define, text: {{$(Prep Input Fields).item.json.query}}, options: { systemMessage: Enter your system message here... } } }text直接取用户query作为本轮提示词systemMessage预留了系统提示词插槽模板中为占位文本实际使用时替换为你自己的 Agent 人设与约束画布便签提示添加你自己的 Agent 工具任意使用任何 Provider 和 LLM——即该节点支持挂接工具节点与任意语言模型。Anthropic Chat Model语言模型子节点{ parameters: { model: claude-3-5-haiku-20241022, options: {} }, type: n8n/n8n-nodes-langchain.lmChatAnthropic, typeVersion: 1.2, credentials: { anthropicApi: { name: Anthropic account } } }通过ai_languageModel连接类型挂到 AI Agent 节点上默认模型为claude-3-5-haiku-20241022。可按需替换为其他模型节点OpenAI、Google 等只需保持ai_languageModel连接即可。Postgres Chat Memory记忆子节点这是与 Base 版最核心的区别——会话历史不再由工作流手动写库而是由 LangChain 记忆节点自动管理{ parameters: { sessionIdType: customKey, sessionKey: {{$(Prep Input Fields).item.json.session_id}}, tableName: messages, contextWindowLength: 10 }, type: n8n/n8n-nodes-langchain.memoryPostgresChat, typeVersion: 1.3, credentials: { postgres: { name: Prod Postgres account } } }sessionIdType: customKeysessionKey以请求中的session_id作为记忆分片键保证同一会话上下文连续、不同会话相互隔离tableName: messages复用与 Base 版相同的messages表contextWindowLength: 10Agent 节点最多回顾最近 10 条消息控制上下文窗口大小凭据为普通 Postgres 连接Prod Postgres accountREADME 明确说明该变体可用任意 Postgres 数据库而非必须使用 Supabase。这是两个模板最值得关注的架构差异Base 版把读历史 写消息拆成显式节点控制力强但需要自己实现历史注入Agent Node 版把记忆封装进 Agent 节点实现更简洁、改动更少适合对会话管理没有特殊需求的场景。凭据配置模板 README 列出两类凭据并在 JSON 中逐一对应到具体节点凭据类型使用节点用途Header Auth accounthttpHeaderAuthWebhook两个工作流请求头认证保护 Webhook 入口Prod Supabase accountsupabaseApiAdd User/Add AI Message to DBBase 版向 Supabasemessages表读写会话消息Prod Postgres accountpostgresPostgres Chat MemoryAgent Node 版任意 Postgres 数据库的会话记忆存储Anthropic accountanthropicApiAnthropic Chat ModelAgent Node 版调用 Claude 模型生成回复README 特别提示这些凭据在模板中是你的自建账号当 Agent 上架到 Live Agent Studio 由平台托管时会被替换为平台自己的凭据无需开发者维护。消息表结构Studio 的持久化约定n8n 模板本身未给出建表 SQL但messages表结构是整个平台的通用约定可参考同仓库 Python 模板 ~sample-python-agent~/README.md 中的完整定义CREATE EXTENSION IF NOT EXISTS pgcrypto; CREATE TABLE messages ( id uuid DEFAULT gen_random_uuid() PRIMARY KEY, created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP, session_id TEXT NOT NULL, message JSONB NOT NULL ); CREATE INDEX idx_messages_session_id ON messages(session_id); CREATE INDEX idx_messages_created_at ON messages(created_at);message列即前文提到的 JSONB 对象type: human/ai、content、可选data。Base 版工作流的两个 Supabase 节点正是按此结构写入而 sample_supabase_agent.py 中的store_message()与fetch_conversation_history()展示了同一张表在 Python 侧的读写逻辑按session_id查询、按created_at倒序取最近 N 条后再反转得到时间正序。两个模板共用同一张表、同一种消息 JSON 结构说明这是 Agent 与 Studio 前端渲染、历史加载之间的稳定协议。使用步骤与自定义指南导入与配置在 n8n 中导入 Base_Sample_Agent.json 或 Agent_Node_Sample_Agent.json 作为新 Agent 的模板配置凭据设置 Header 认证自托管阶段可选托管后由 Studio 统一提供Base 版配置 Supabase 连接Agent Node 版配置 Postgres 连接激活工作流JSON 中active: false表示模板默认处于停用状态需在 n8n 中手动激活并发布 Webhook 地址。自定义扩展方向README 给出三类典型的定制点追加处理节点在 Base 版Add User Message to DB与Add AI Message to DB之间即 Sticky Note 标注的插槽串联你自己的业务节点接入专用 AI 模型Agent Node 版可替换Anthropic Chat Model为其他 Provider 的模型节点并补充工具节点到 AI Agent 节点下实现自定义业务逻辑例如在 Base 版插槽中新增 HTTP 请求节点调用外部 API、在 Agent Node 版中完善systemMessage注入领域知识。验证方式两个工作流的pinData均内置了一份模拟请求可直接在 n8n 中以测试工作流模式运行 Webhook 节点验证全链路请求体应包含query/user_id/request_id/session_id四个字段执行后检查messages表中是否出现一条human消息与一条ai消息并确认最终响应满足{success: true, output: ..., data: ...}结构。小结模板的价值在于协议先行Base Sample Agent 与 Agent Node Sample Agent 的差异本质上是会话历史管理方式的两种取舍Base 版把读写拆成显式 Supabase 节点把会话控制权完全交给开发者适合需要自定义历史注入、多步骤落库的复杂 AgentAgent Node 版借助 n8n LangChain 节点的Postgres Chat Memory自动管理历史结构最简、上手最快适合快速原型与轻量 Agent。二者共享同一套 Webhook 消息协议与messages表结构这也正是 Live Agent Studio 得以统一托管、渲染与计费所有 n8n Agent 的基石。从模板出发替换模型、补充工具、填充系统提示词即可在几分钟内产出第一个可上架 Studio 的 n8n Agent。/output 文章【免费下载链接】ottomator-agentsAll the open source AI Agents hosted on the oTTomator Live Agent Studio platform!项目地址: https://gitcode.com/GitHub_Trending/ot/ottomator-agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考