做销售自动化的朋友应该都遇到过这种场景线索从各个渠道涌进来手动录入系统要花半天邮件发出去之后谁看了、谁点了、谁回了全靠人工盯邮箱好不容易有了意向客户又要跑到ERP里开客户档案、建商机、下跟进任务。信息在不同工具之间来回搬运中间一旦漏掉一条整个跟进节奏就乱了。我在某个项目里就是被这种来回切换折磨得不行最后用n8n把Emelia和ERPNext对接起来做了一条从线索到邮件再到客户状态自动更新的链路。整个过程跑通之后销售团队省下来的时间非常可观。这篇就记录一下我是怎么做的包括节点的接入方式、智能体工作流的编排思路以及实测中踩过的坑。无论你是刚接触 n8n还是已经用它搭过简单流程这篇应该都能给你一些参考。Emelia 是一个专门做冷邮件外联Cold Email Outreach的工具主打自动跟进、邮件个性化和送达率优化ERPNext 则是一套开源的企业资源计划系统能管客户、销售订单、库存、财务等等。很多中小团队是先用 Emelia 做获客再把谈成的客户往 ERPNext 里录。问题的核心在于这两个工具之间没有原生打通而 n8n 正好可以做中间的胶水层再加上它的 AI Agent 节点还可以把邮件互动行为和 ERP 里的业务动作联动起来实现一个轻量级的业务智能体。1. 这套组合到底在解决什么问题Emelia与ERPNext的天然缺口很多人第一次看到这个标题第一反应可能是Emelia 不是发邮件的吗ERPNext 不是管业务的吗这俩能有什么关系实际上任何一个销售流程跑起来之后都能立刻感受到中间的断层那些断层就是你接自动化最大的动力。1.1 终端用户视角的痛点先从一个普通销售的工作视角来看。假设这家公司用的是 Emelia 做外联用 ERPNext 管理客户和销售订单。过去的工作流大概是这样的每天早上一来先打开 Emelia 看昨晚的邮件发送情况哪些客户打开了邮件、哪些点了链接、哪些回复了。然后要把这些信息手动记录到 Excel 或者脑子里。接下来打开 ERPNext查看最近新增的线索判断哪些是有效线索哪些是垃圾注册。如果一个客户在 Emelia 里回复了邮件说有兴趣了解一下产品销售就得赶紧去 ERPNext 里建一个客户档案、创建线索Lead、再来一个联系人Contact最后还要手动创建一个跟进任务。这些操作每一步都可以完成但每一步都是纯手工。问题出在哪第一是重复同样的客户信息在两个系统里各录一遍第二是延迟邮件回复之后销售未必能第一时间看到第三是状态不同步Emelia 里的已回复和 ERPNext 里的已跟进之间没有任何映射关系。做销售管理的人应该都有这种体会数据一旦靠人来搬就一定会出现漏录、错录、晚录的情况。我当时的场景还要更复杂一点团队在多个渠道投放获客Emelia 里面分了好几个 Campaign每个 Campaign 对应不同的产品线和话术。ERPNext 里不只存客户还要记录每次跟进的结果。之前有人每天花差不多两个小时做这种搬运工作而且经常抱怨系统没提醒我。1.2 为什么由 n8n 来当胶水层既然中间有断层自然有人会想直接把 Emelia 和 ERPNext 做集成不就行了Emelia 本身提供 APIERPNext 也有一整套 REST API理论上完全可以写一个专门的脚本来同步。但问题在于销售流程不是固定的今天要用 A 流程明天要加 B 条件后天要接一个新的邮件模板。写死脚本的维护成本极高。n8n 的优势在于它把这些 API 调用变成了可视化节点你可以像搭积木一样把 Emelia 的发信动作、ERPNext 的写入动作串联起来而且中间可以插入条件判断、数据归一化、AI 判断等逻辑。更重要的是n8n 本身是一个事件驱动的平台可以监听 Webhook也可以在指定时间轮询这就让整个链路不需要人工参与。另外n8n 的节点生态里已经有Emelia 节点和ERPNext 节点不需要自己封装 HTTP Request这大大降低了上手门槛。如果你要做更复杂的智能体n8n 也提供了 AI Agent 节点把 LLM 接入任务队列里让模型根据上下文决定调用哪个工具。这就是标题里智能体开发的含义不是简单地搭两条流程而是让系统具备一定的判断和决策能力。2. 环境准备与两个节点的接入配置在谈流程编排之前先把环境说明白。这个部分看起来简单实际上很多人在配置凭证的时候就卡住了尤其是 ERPNext 的认证方式有两种选错了后续特别麻烦。2.1 n8n 的部署选择n8n 的部署方式主要有这么几种官方云服务、Docker 自托管、npm 直接跑。我个人的建议是如果是给自己用、数据不敏感可以用官方云省心如果是团队用、涉及客户数据最好自托管。自托管最常用的方式是 Docker Compose一个命令就能跑起来数据持久化用之前一定记得挂载 volume 或绑定命名卷否则升级容器之后配置全没了。部署完成之后进入 n8n 的界面左侧面板可以搜索节点类型。搜索的时候你会看到 Emelia 和 ERPNext 的节点都是默认自带的这说明这两个集成是官方维护的稳定性相对有保障。不建议一上来就装社区版节点社区节点的质量和维护频率参差不齐除非真的缺功能否则官方节点优先级最高。版本方面我调试的时用的是当时的稳定版本建议保持升级到最新版因为 Emelia 节点的参数在各个版本之间有调整早期版本字段名和现在不一样。2.2 Emelia 节点的认证与参数Emelia 节点在 n8n 里属于CRM分类做的主要动作是管理联系人、管理 Campaign、发送邮件。它用的认证方式很简单在 Emelia 后台生成一个 API Key然后在 n8n 的凭证里选择 Emelia API把 Key 填进去就行。节点创建之后你需要选择 Resource 和 Operation。以发信为例Resource 选 EmailOperation 选 Send。这时候会出现一堆必填字段收件人邮箱、发件人邮箱、邮件主题、正文内容、模板名称等。这里的模板不是指 Emelia 里配置的完整模板而是指邮件正文里可以嵌入的变量结构n8n 传过去的键值就是模板变量。这里有一个非常容易忽略的地方Emelia 对发件人的邮箱有身份验证要求。如果你在 Emelia 里没有完成发件域名的 SPF/DKIM 配置发信时的送达率会非常低甚至直接被丢进垃圾箱。这不是 n8n 的问题是邮件基础设施的问题但很多人在测试时因为没配置域名验证就误以为是 n8n 节点出了问题。发信时如果要插入个人信息比如收件人姓名、公司名、自定义字段n8n 里可以用表达式引用上游数据。比如在上一步从表格里读到了姓名节点里写{{ $json[contactName] }}邮件发出去之后就会自动替换。这个能力是 Emelia 自身 API 就支持的n8n 只是帮你把替换逻辑前置了。2.3 ERPNext 节点的两种连接方式ERPNext 节点在 n8n 里的配置明显要复杂一些因为它本身就是一套业务系统节点要操作的DocumentType五花八门从 Lead、Customer、Contact 到 Quotation、Sales Order甚至还有 Stock Ledger Entry。你需要在 Resource 里指定操作哪种文档然后在 Operation 里选择增删改查。先解决认证问题。ERPNext 的 API 支持两种方式API Key 方式在 ERPNext 后台的用户设置里生成 API Key 和 API Secret然后在 n8n 凭证里选 ERPNext API填写相应的 Key 和 Secret 以及站点地址。这种方式适合在服务端做程序化访问权限可以精确到用户级别。用户密码方式直接填用户名和密码n8n 用它做基本认证。这种方式不适合生产环境但快速测试的时候很方便。我建议直接用 API Key原因很简单API Key 可以随时在后台吊销密码方式如果泄露就要连带改密码牵连面太大了。连接问题解决之后最常用的两个操作是创建 Lead字段包括 Lead Owner、Source、Company Name、Email ID、Phone/Mobile Number 等创建/更新 Customer字段包括 Customer Name、Customer Group、Territory 等更新 Contact在已有客户和联系人之间建立关联用的是一个字段叫 Links实际使用中你会发现ERPNext 的字段特别多但 n8n 节点只显示了常用字段像自定义字段这类内容需要在节点参数里手动加一个 Name-Value 的列表这个列表的结构是 Key 加 Value。自定义字段允许你在接口里配置顺便提醒一句ERPNext 里自定义字段要确保权限里给了你的 API 用户读写权限。3. 智能体工作流从线索到邮件再到客户状态的闭环配置好两个节点只是第一步真正核心的部分是流程编排。这一节我直接讲一个我在实际环境中跑通的闭环新线索进 ERPNext自动发给 Emelia 进行第一轮触达收到回复之后回写状态并创建跟进任务。3.1 主流程设计整个工作流的触发点我选在 ERPNext 的 Webhook 上。每当有新的 Lead 创生ERPNext 会向 n8n 的 Webhook 节点发送一个 POST 请求带着新线索的全部字段。这样做的好处是实时性最高不需要 n8n 主动轮询也不会漏掉中间没有变化的记录。Webhook 收到数据之后数据并不直接就是干净的。比如网页端提交的线索可能带了一堆 URL 参数、乱码字段等需要用数据清洗节点做一次格式化把 Email 字段统一转小写、去空格去掉明显的垃圾字符。再比如某些线索的 Company Name 为空需要给个默认值否则后面的邮件变量会替换成空白。格式化之后进入一个条件判断这个线索的邮箱域是不是来自免费邮箱比如 gmail.com 或 outlook.com如果是走一条低优先级的流程只加入慢速邮件序列如果是企业域名直接进入高优先级序列。这个判断用 n8n 的条件节点就能完成也可以用代码节点写一个简单的正则判断插件。然后调用 Emelia 发送第一封触达邮件。邮件内容不是死的而是由 AI 根据线索的公司行业、职位、地区背景生成个性化开场白。这里我用的是 n8n 的 AI Agent 节点让它读取线索摘要生成一个不超过 60 字的开场白然后嵌入模板。发出去之后工作流的本源任务就完成了。3.2 AI Agent 如何调度两个节点标题既然叫智能体开发就绕不开 AI Agent 节点的用法。在 n8n 里AI Agent 节点并不是一个独立的泛化节点而是基于 LangChain 的一组子节点组装起来的。你需要指定三个核心部分LLM、工具Tools、提示词System Message。LLM 我选的文本生成模型它对中文的处理能力不错。而 Tools 部分就有讲究了——n8n 允许你把自己写好的官方 Emelia 工作流和 ERPNext 工作流封装成工具暴露给 Agent。也就是说Agent 收到一条新的线索之后它可以自行决定是先把线索写入 ERP还是先通过 Emelia 发邮件具体执行方式由 Agent 依据 prompt 里的描述选择。这种设计的价值在于不需要把每一步判断都写成死逻辑。比如某客户在邮件里回复我们暂时没有预算Agent 读取之后会把这个回复归类为消极反馈然后更新 ERPNext 的 Lead 状态同时把跟进任务暂停两周。这些都是基于语义判断的比硬编码关键词字符串判断要稳健得多。需要负责任地提醒Agent 的能力越强你需要给它约束的信息就越多。我在 System Message 里明确写了一条规则——只有收到客户明确表示同意产品符合需求时才能创建 Quotation不允许 Agent 根据销售人员的单方面反馈直接创建报价单。添加这条约束之后实际产生的误操作率降到了可以忽略的水平。3.3 字段映射与状态回写的关键整个流程中间环节最烦琐的是字段映射。Emelia 回复的数据里可能只有 Email Address 和回复内容没有客户名称你要想把这个回复关联到 ERPNext 中对应的 Lead只能通过邮箱去匹配。所以在设计里我会在回写环节先按邮箱去 ERPNext 查询 Lead拿到 DocType 的编号之后再更新。这一步如果省了系统里就会出现多个重复的 Lead。n8n 里做这个匹配使用的是ERPNext - Get All节点加一个 Filter 条件邮箱字段等于收到的发件人邮箱。注意 ERPNext 的查询语法是用 JSON 格式传过滤条件的你在 node 里写的时候要确认字段名正确。有一个小技巧查询结果是数组哪怕只期望一条也建议先判断数组长度绝对别直接取第一项免得查不到时报错。回写状态的时候我直接把 Lead 的 status 从 Open 改成 Replied然后加一个自定义字段 last_contact_time 记录回复时间。后面销售跟进时一眼就能看到这条线索是什么时候触达的。整个过程完全不用人手工修改 ERPNext。4. 实测中必须避开的那些坑流程跑通之后最大的收获不是自动化本身而是那段时间踩过的一堆坑。这里挑几个最有代表性的给打算复制这套方案的朋友提个醒。4.1 Emelia 发送限制与测试模式Emelia 在测试阶段有一个测试模式开关。打开它之后发邮件并不会真的发出去而是看到一条模拟的成功记录用来验证流程通不通。很多人第一次配置完之后明明日志显示发送成功了却收不到邮件一查后台才发现是测试模式没有关闭。这个开关和 n8n 无关但接在 n8n 工作流里特别容易忽略因为 n8n 的日志并不会告诉你这个邮件是不是真的投递到了收件箱。另一个实际问题Emelia 的每日发送上限受账号配额限制。如果你的线索量大n8n 会瞬间灌进去一大批任务直接把一天的配额全部消耗掉后面的邮件全都排队到第二天。建议在生产流程里加一个节流器比如控制在每小时只发送若干个请求。n8n 里可以用等时节点或循环间隔事件来实现这样能更合理地使用配额。从实测看Emelia 对于邮件回复的检测不是实时回调的它通常有延迟一般 10 到 30 分钟后才把回复事件暴露出来。所以如果你的工作流是依赖邮件回复触发后续动作延迟期是必要的。我当时用了一个两小时一次的定时触发把 Emelia 上新增的回复同步到 ERPNext效果稳定且不会错过窗口。4.2 ERPNext 的 Webhook 与轮询取舍ERPNext 支持自定义 Webhook可以在文档创建或修改时发送通知。这个非常有价值因为它让我们实现了实时接近实时的触发。但是 Webhook 只会在触发事件发生的时候发一次如果你第一次没接到请求之后也不会补发。所以我做的时候加了一层保险每天晚上用定时触发轮询一遍当天所有新增和更新的 Lead去重比对后修正状态。这一套安排下来ERPNext 里的数据实时性和完整性都有了保障。轮询和 Webhook 各有优劣Webhook 是事件驱动的响应快但丢弃风险高轮询是幂等的永远可以追平数据但反应慢。生产环境建议两者都要有实时同步为主定期校准保底。还要提醒一点ERPNext 的 Webhook 在发送请求时没有默认的重试机制你需要自己在 n8n 端处理失败情况。我通常在 Webhook 节点后面加一个异常捕获分支Response 超时或非 2xx 都记录到日志表再放到待重试队列里让定时流程来处理。4.3 时间、时区与数据格式的隐性陷阱亲手调过一遍之后才会发现ERPNext 里的时间字段非常多坑。它默认的日期格式是 YYYY-MM-DD但如果你通过 n8n 写入的是 ISO 时间字符串比如 2025-03-21T08:00:00ZERPNext 会存储它但显示时因为时区偏移而变成前一天。解决方式很粗暴但也很好用在写入之前显式指定你所在的时区然后格式化成本地时间再存进去。有一次我调试最后跟进时间字段怎么查都是差 8 个小时后来才意识到是时区问题。从那之后我统一在 n8n 里用 moment 表达式做转换确保所有进 ERPNext 的时间都转换成服务器本地时区再传参。另一个隐藏陷阱在枚举值。ERPNext 里很多字段是 Select 类型比如 Lead Status 只能选 Open、Replied、Qualified等固定值。如果你直接通过 n8n 传入一个非法值更新接口会直接报错但报错信息经常是Invalid Value完全看不出是哪个字段的问题。这个只能靠不断的试错积累维护文档把常见的 Select 字段值提前列出来配置前先检查。5. 从 Demo 走向生产扩展思路与维护建议跑通闭环只是第一步真正有价值的是把它放到真实业务里稳定运行几个月。这个阶段你会碰到新的问题比如权限控制、数据回滚、异常告警。这节讲一下我的扩展思路。5.1 给工作流加一层人工复核智能体再聪明也免不了偶发判断失误。所以在极其重要的动作上比如创建报价单、删除客户我刻意设计了人工复核环节。AI Agent 做出决策之后不会直接调用 ERPNext 写流程而是先发一条消息到团队的即时通讯工具附上完整分析说明由相关负责人点击确认后再触发后续工作流。很多人会觉得这样失去了自动化的意义但我认为关键节点的人机协作恰恰是智能体落地时最成熟的做法。销售类业务里数据本身不是问题但如果因为误操作产生了错误报价后面的麻烦远超你手动处理那几秒钟的成本。人工复核用 n8n 实现很简单用一个等待节点挂起工作流同时给负责人发送一条审批链接收到点击请求后再继续执行。整个实现复杂度不高收益却非常大至少能消除大约 90% 的自动化恐慌。5.2 日志、监控与重试策略生产环境最怕的不是出错而是出了错你完全不知道。所以我在 n8n 里加了两样东西一个统一的日志表每次执行关键操作后把输入、输出、执行时间都记录下来另一个是失败告警工作流任何一个环节抛异常都通过即时通讯渠道发给值班人员。重试策略方面Emelia 发送失败的大多数原因是临时性网络问题或 API 限流所以我在发送节点上加了一次自动重试间隔 30 秒。ERPNext 的写入操作则不需要重试因为它经常是幂等的而且重复写入反而会造成重复数据宁可报错人工处理也不能不明不白地重试。我还开了 n8n 的执行历史保存功能保持至少 7 天的历史记录。排查问题的时候可以直接看每一次执行的原始数据省去了很多猜测。5.3 后续还可以接什么把 Emelia 和 ERPNext 打通只是起点n8n 的价值在于你可以基于这套底座持续扩展。我目前已经在做的扩展有两个第一个是把表单收集的线索自动去重后直接转换为 ERPNext 的客户和联系人用定时触发脚本做和 Webhook 互补。第二个是每个月末自动从 ERPNext 拉取销售订单数据汇总成交明细、回款状态生成一张销售月报再通过邮件发给管理层。这些功能在 n8n 里用现成节点就能完成不用额外写太多代码。回到这套组合上我的体会是单看 Emelia 节点或者 ERPNext 节点它们都只是普通的 API 封装但当你引入 n8n 的编排和 AI Agent 的调度能力之后它们才真正变成一个能自我运转、能基于上下文做决策的业务智能体。如果你也在做销售自动化不妨从一条新线索自动触达并回写状态的链路开始跑通之后你会回来感谢这个组合的。