n8n付费模板：WhatsApp房产线索自动接待并推荐房源

原文要点

这是iamvaar发布的付费n8n模板且定价较高，购买后才能拿到工作流文件。按其说明：WhatsApp触发器收到消息后提取发送人、消息ID、类型与文本，非文本消息直接回复请发文字；用Redis按消息ID去重、对同一号码的消息做短窗口缓冲并只处理最后稳定的一条，再加短锁防止并行；在HighLevel查联系人，不存在则补建；从Google Sheets读全部房源聚合后，连同合并后的用户消息交给带Redis聊天记忆的Gemini agent；解析agent的JSON输出，回资格追问或房源推荐，并把Cal.com链接替换为自动填好信息的预约URL，最后释放锁。

这次做成什么

在不购买模板的前提下，先用一个虚构号码、三条合成房源和一段连续三条的WhatsApp消息，在纸面加简化自搭流程上验证"去重缓冲→锁→联系人补建→库存注入→JSON分支回复"这套设计是否适合你的业务，再决定是否需要原模板的完整实现。

准备什么

• WhatsApp Business Cloud API账号与Phone Number ID，配webhook到n8n
• 可设置键TTL的Redis实例，用于去重、缓冲、时间戳、锁和聊天记忆
• Google Service Account凭据和一张房源库存表
• Google Gemini（PaLM）API凭据，供agent聊天模型使用
• HighLevel OAuth2凭据及locationId，若不用CRM可暂时跳过补建步骤
• 可选：Cal.com事件链接，且该事件支持prefill查询参数

具体怎么做

1. 搭最小验证链路

   新建n8n工作流：Webhook节点模拟WhatsApp入站消息，接一个Code节点实现Redis去重（键dedup:{messageId}，TTL 10分钟）和缓冲（键buffer:{phone}，存消息数组与时间戳）；先用本站下方测试JSON手动POST验证重发同一messageId会被忽略。

2. 实现稳定窗口与锁

   在Code节点里比较当前时间与buffer里最后一条消息时间戳，不足缓冲窗口（本站练习设15秒，原模板默认值需购买后核对）就结束本轮；通过时用SET lock:{phone} NX EX 60抢锁，抢不到直接退出，结尾务必DEL释放。

3. 联系人与库存注入

   HTTP请求HighLevel按号码查联系人，404则POST补建（字段：phone、firstName可取号码后四位）；另一个节点读Google Sheets整表房源，用聚合节点拼成JSON数组塞进agent上下文。

4. 配置Gemini agent分支

   建AI Agent节点，模型选Gemini聊天模型并挂Redis聊天记忆（键chat:{phone}），系统提示词用下方材料，要求只输出JSON：{"action":"qualify"|"recommend",...}；后接Switch节点按action分支。

5. 回复与预约链接

   recommend分支里把agent返回的cal_link用表达式拼成自动填充URL：https://cal.com/你的账号/看房?name={姓名}&email={邮箱}&notes={需求摘要}，连同推荐文案经WhatsApp发送节点回给该号码；qualify分支直接回追问文案。两种分支结束都要释放锁。

可直接复制的材料

你是房产中介的WhatsApp接待助手。你只能输出一个JSON对象，不要输出任何其他文字。
输入包含：客户合并后的消息文本、对话历史、房源库存JSON数组（字段：id,小区,户型,月租,区域,入住日期）。
规则：
1. 若客户未说明预算或区域或户型中的任意两项，输出{"action":"qualify","reply":"用一条不超过60字的消息追问缺失的信息"}。
2. 信息足够时，从库存中选最多2套匹配的房源，输出{"action":"recommend","reply":"不超过120字的口语化推荐，逐套说明小区、户型、月租","listing_ids":["选中的id"],"cal_link":"https://cal.com/your-team/viewing"}。
3. 库存没有完全匹配时，推荐最接近的一套并在reply里说明差距。

id,小区,户型,月租,区域,入住日期
P001,滨江壹号,两室一厅,4500,滨江,2026-10-01
P002,城西雅苑,一室一厅,2800,西湖,2026-09-20
P003,云栖小镇公寓,三室两厅,6200,西湖,2026-10-15

{"entry":[{"changes":[{"value":{"messages":[{"id":"wamid.TEST001","from":"8613800009999","type":"text","timestamp":"1789450000","text":{"body":"你好"}}]}}]}]}
第二条同号码：{"id":"wamid.TEST002","from":"8613800009999","type":"text","text":{"body":"想租两室一厅"}}
第三条同号码：{"id":"wamid.TEST003","from":"8613800009999","type":"text","text":{"body":"预算5000以内，滨江附近"}}
重复重发wamid.TEST001应被去重忽略。

输入与输出示例

本站虚构演示，未实际调用WhatsApp/Gemini/Cal.com，agent输出为按提示词规则推演的示意。

输入

三条合成消息在15秒内先后到达，缓冲合并后文本为"你好 想租两室一厅 预算5000以内，滨江附近"，库存为上方3套房源。

对应输出

去重层忽略重发的wamid.TEST001；锁获取成功。agent判定预算、区域、户型齐全，输出{"action":"recommend","reply":"推荐滨江壹号：两室一厅，月租4500，在你的预算内且就在滨江，10月1日可入住。","listing_ids":["P001"],"cal_link":"https://cal.com/your-team/viewing"}；发送节点把链接替换为https://cal.com/your-team/viewing?name=客户9999&notes=两室一厅预算5000滨江后回复该号码，最后释放lock:8613800009999。

做完检查这些

• 同一messageId重发两次，第二次在Redis去重键处被拦截，不产生第二条回复
• 三条消息在缓冲窗口内只触发一次agent调用，发给模型的是合并后的完整文本
• 库存只有3套时，recommend输出的listing_ids必须全部来自库存，不允许编造房源
• 非文本消息（如图片）走单独分支，回复提示用户发文字，不进入agent
• agent返回非法JSON时流程进入错误处理并释放锁，锁不残留超过TTL
• Cal.com链接替换后包含name或notes查询参数，且该事件在Cal.com后台允许prefill

容易卡住的地方

• 这是付费模板且定价较高，购买前只能依据说明页评估；本站内容是按公开说明自建的练习，不是原工作流文件，也不含可导入的n8n JSON
• 缓冲窗口、锁时长、去重TTL的具体默认值未公开，需购买后在原模板中核对，本站练习值仅为演示
• WhatsApp Cloud API有按对话计费的规则，Gemini按token计费，Redis与HighLevel也可能产生订阅费，模板价格不含这些
• HighLevel的locationId填错会把线索写进错误的子账户；Cal.com事件若未开启prefill，自动填充参数会被忽略
• 房源库存整表注入上下文，库存很大时会超出模型上下文或推高费用，真实使用需先做区域/价格预过滤，原模板是否处理需购买后确认