1. 缘起为什么我会花一个月做“Agent-Reach”这个触达系统Agent-Reach 是我最近一个月集中精力做的一个智能触达系统起因特别简单我一直在做的独立开发者工具需要持续寻找潜在合作方和早期用户手动找邮箱、写介绍信、跟进回复效率低得让人想摔键盘。每天花三四个小时做重复劳动换来的有效对话却少得可怜这让我开始认真考虑把“找线索、建档案、写文案、发邮件、跟进”这条完整链路交给 Agent 去做。先说清楚我理解的 Agent-Reach它不是一个简单的“邮件群发工具”而是一个由多个 Agent 协作完成的外联工作流。主控 Agent 负责调度发现型 Agent 负责收集线索画像型 Agent 负责把零散信息整理成可用档案交付型 Agent 负责发送与跟进。整个系统围绕“触达”这个词展开它能触达多少人、触达的质量如何、后续对话能不能被有效承接。1.1 原来一天能触达的人少得可怜没做 Agent-Reach 之前我的流程是打开社交媒体和行业网站手动翻用户主页找邮箱复制到表格再手动写一封看起来不那么像模板的邮件。一上午大概能处理 15 到 20 个联系人写入表格的信息还经常不完整有的只有名字有的只有公司名邮箱能不能用全靠猜。问题不只是速度而是“上下文丢失”。我一个星期前跟某个人聊过什么下次跟进时经常要想很久才能想起来。手动维护线索表的代价极大尤其是联系人超过 100 个之后表格里存的就不再是资产而是负担。Agent-Reach 的核心价值就是把这一整套容易中断、容易遗漏的流程变成有状态、可追踪、能复盘的系统。1.2 Agent-Reach 想做的是“调度式触达”而不是“模板群发”市面上的群发工具不少但它们通常只解决“把邮件发出去”这一个环节。真正让外联有效果的是对联系人的理解、对文案的迭代、对跟进节奏的把握。比如一个做开发者工具的人和一个做跨境电商的人他们的关注点完全不同如果共用一套模板结果只能是低打开率和高退订率。Agent-Reach 的思路是让每个 Agent 只做自己最擅长的事发现 Agent 不负责写文案画像 Agent 不负责发信交付 Agent 也不需要理解业务背景有多深。它们之间通过结构化数据传递而不是互相塞一段含糊的自然语言 prompt。我第一次尝试时也走过弯路让一个 Agent 从头到尾包办结果模型上下文撑爆输出质量越来越差。后来改成“流水线式”协作稳定性提升非常明显。1.3 这个项目适合谁参考如果你正在做独立产品、代理销售、内容商业化或者你所在的小团队需要定期联系大量潜在客户但不想招一堆人专门做外联Agent-Reach 这套思路会有直接参考价值。如果你是技术背景可以通过我的架构快速搭出原型如果你偏运营也可以只拿走“多 Agent 分工”的流程设计配合现成的低代码自动化工具来落地。我不会给你一套“填了就能火”的模板只分享我踩过的坑和最终跑通的结构。2. Agent-Reach 的架构拆解四个 Agent 之间怎么分工协作整个系统的核心是一张“触达流水线”。我用过很多自动化编排工具最后选择了自己熟悉的代码链路来写 Agent 之间的调度逻辑核心原因是可调试性。可视化编排在流程简单时很爽但一旦涉及条件分支、失败重试、状态持久化代码比拖拽节点更容易发现问题。2.1 Orchestrator触达流水线的调度核心Orchestrator 不直接干活它管理的是“状态”。每次运行它从待处理队列里拉一批候选联系人根据候选人的完整程度决定下一步该调用哪个子 Agent。举个例子如果发现 Agent 拿回来的联系人只有公司名和职位没有邮箱Orchestrator 会先让画像 Agent 补全信息如果补全失败超过两次就直接把这条线索标记为“低质量”不再浪费后续资源。下面是我简化后的调度配置关键词部分直接结构化传给下游 Agent{ orchestrator: { pipeline: [discover, profile, compose, deliver], max_attempts: 2, checkpoint: true, state_store: sqlite }, discover: { source: public_api, batch_size: 50 }, profile: { enrich_fields: [email, company_size, tech_stack], min_confidence: 0.7 }, compose: { model: gpt-4o-mini, tone: casual_professional } }这个配置的核心思路是每一步都有明确的输入输出格式绝不依赖 Agent 在自由对话中“顺便”完成别的步骤。我给每一步定义了 JSON Schema下游 Agent 拿到的永远是干净的结构化数据而不是一段可能带废话的文本。2.2 Discovery Agent从公开信息里找候选联系人Discovery Agent 的职责是“找得到”。它可以从行业目录、社交媒体公开资料、产品社区的贡献者列表里提取候选线索。我一开始想做成完全无人值守的自动爬取后来放弃了因为公开网站的页面结构变化太快爬虫代码经常要修。最终的做法是保留“半自动”模式Discovery Agent 读取我手动维护的“线索源清单”然后对每个源做定向抓取。这里有个容易被忽略的细节去重一定要做。同一个候选人可能同时出现在三个来源里如果不去重后续流程会重复触达同一个邮箱轻则被人标记垃圾邮件重则影响发信域名信用。我在 Discovery Agent 的输出端加了一个基于邮箱哈希的去重表新线索进来先查一次库命中就直接跳过。2.3 Profiling Agent把“一个邮箱”变成“一份人物画像”拿到邮箱只是开始。真正让触达有效的是知道这个人关心什么、最近在做什么。Profiling Agent 会去翻候选人的公开主页、技术文章、社交动态把散落信息聚合成一个 200 字以内的画像摘要同时抽取几个“个性化锚点”他最近发布的项目、他在论坛里提到的问题、他所在团队的招聘方向。这些锚点会被 Compose 阶段的模型直接用进邮件开头。比如“看到你最近在重构日志系统我对这一块刚好有点实践经验”比“很高兴认识你”有效得多。画像 Agent 的准确度我设了阈值置信度低于 0.7 的画像宁可放弃也不用。为什么因为错误的个性化比没有个性化更糟一封把 A 公司的产品安利给 B 公司的邮件只会让收件人觉得你连功课都没做。2.4 Delivery Follow-up Agent真正决定回信率的环节触达的最终结果由 Delivery Follow-up Agent 负责。它读取画像、调用文案生成服务然后根据预设的节奏发出邮件和跟进信。我这里说的“节奏”不是固定间隔三天一封而是结合收件人行为动态调整对方打开过邮件但没回复两到三天后跟进一次对方回复了但说“现在不是时候”就自动进入一个月后的长间隔序列对方彻底不打开第五封后停止触达并标记为“沉睡线索”。发信环节我不建议自己写 SMTP 客户端直接用成熟的邮件发送服务更省心。Agent-Reach 里我封装了一个很薄的适配层底层可以随时切换发送通道这样即使某个通道的日限额不够也不会影响整体流程。你如果做类似系统一开始就保留这层抽象会省掉后面很多麻烦。3. 踩坑记录Agent-Reach 第一版差点死在邮件投递上这个项目真正的转折点不是 Agent 功能实现而是邮件投递。我第一版跑通之后兴致勃勃从线索库里挑了一批人发出测试邮件结果发出 500 封退信 130 封打开率只有 9%。我当时的第一反应是“文案不行”但冷静下来查数据才发现问题根本不在文案而在投递层。3.1 事故现象发出去 500 封退信 130 封退信名单里有大量我明明确认过“格式正确”的企业邮箱。有些是真实存在的邮箱但因为我的发信域名和 IP 没有被对方邮件系统信任直接被拒收。更麻烦的是有 20 多封是被对方标记为垃圾邮件后自动退回来的这会直接拉低我发信域名的信誉分。如果只看邮件内容我写的文案挑不出大问题有称呼、有背景说明、有明确的行动号召。所以这个事故给了一个很重要教训在批量触达场景里“内容正确”不等于“能进收件箱”。投递本身是一个独立的工程问题必须在 Agent 之外单独设计和监护。3.2 排查链路从 Spam 报告到 SPF/DKIM/DMARC我的排查过程是逐步往下钻的。先看了邮件发送服务的失败回调把错误码分成了几类域名不存在、邮箱不存在、对方服务器拒收、被判定为垃圾内容。前两类是数据质量问题后两类才是投递信誉问题。接着我检查了发信域名的 DNS 配置发现 SPF 记录虽然配了但只包含了发送服务的 IP没包含可能备用的二级发送通道DKIM 签名在邮件头部显示通过但 DMARC 的策略是 none等于只做了监控没有真正约束。这一类问题排查起来并不复杂但很多人容易漏因为仅在本地调试时邮件发到自己的测试邮箱几乎不会触发严格过滤。真实的收件方邮件服务会对齐 SPF、DKIM、DMARC 三个维度任何一个不完整都可能被归入垃圾箱。我用邮件头分析工具逐封检查被拒邮件确认消息头里缺少“对齐的发送者身份”后才定位到根因。3.3 修复方案域名信用、预热和限速修复分三步。第一步是把 DNS 记录补齐SPF、DKIM、DMARC 全部按发送服务商的最佳实践配置DMARC 先从 none 过渡到 quarantine稳定后再切 reject。第二步是做发信域名预热新域名不要一上来就发大量邮件我从每天 20 封开始连续七天逐步加到每天 200 封让收件方服务器逐步建立对你的信誉感知。第三步是限制单日发信总量Agent-Reach 里加了硬性限速每小时最多发 30 封每天最多 150 封超出部分自动进入第二天队列。这样做之后退信率从 26% 降到了 3% 以下收件箱到达率明显回升。最直接的验证是后续某次测试邮件的打开率从 9% 涨到了 41%。同一份文案前后效果差距这么大完全不是文案技巧而是投递层修好了。3.4 还踩过的第二个坑Follow-up 固定间隔不如行为触发第一版的跟进逻辑是每三天给所有未回复联系人发一封结果退订率一路走高。后来我回看数据发现那些已经打开过邮件但没回复的人跟进邮件打开率很高而那些从未打开过的人跟进邮件大多进了垃圾箱或直接删掉。这说明跟进的价值在于“唤醒已经产生的兴趣”而不是“骚扰没有兴趣的人”。Agent-Reach 现在把跟进触发条件改成了行为驱动打开过但没回复触发一次带有补充信息的跟进点过链接但没留下联系方式的触发一次带有直接预约链接的跟进完全未打开发者不跟进只放进月度回顾队列。这样一轮序列跑下来总发信量减少了一半回复率反而上升因为每封信都是“有理由出现的”。4. 从 Demo 到长期服役状态、成本、合规三个维度的收敛Agent-Reach 过了投递这一关之后我以为剩下的都是小修小补结果真正投入时间的是另外三件事让流程可以中断恢复、让成本不要失控、让触达动作符合基本的社会规范与平台要求。这三件事看起来不性感但缺了任何一个项目都不可能长期跑下去。4.1 状态恢复给 Agent 装上“记忆”Agent 系统最怕的不是慢而是跑到一半挂了然后全部重来。我第一次跑 200 人的批次时程序因为第三方接口限流直接抛异常退出重启之后所有联系人状态都被重置重复发送了 40 多封邮件。这种事故非常尴尬也让我立刻意识到必须做持久化。我现在给每个联系人建了一张状态表记录他处在流水线的哪个阶段、已尝试过几次、最后一次操作时间、结果码是什么。Orchestrator 每次启动时只处理“卡在中间”的任务不重复执行已经成功的步骤。这种断点续跑能力对任何长时间运行的 Agent 系统都重要你可以在自己的项目里用一个简单的 SQLite 表就实现不需要引入重型消息队列。4.2 成本控制模型调用从失控到可控Agent-Reach 的文本生成主要有两个场景构建联系人画像和撰写个性化邮件。第一版设计得很粗糙每次画像都要调一次大模型邮件标题和正文分别再调两次一个联系人走完流水线差不多要烧掉一万多 token。批量跑 500 人时成本很快就让人心疼了。优化思路是“能不用模型就不用模型能用小模型就不用大模型”。联系人画像的部分我改成先用规则模板抽取公开信息只把不确定的地方交给模型补全邮件正文通过组合几个经过测试的段落模板生成每个模板里的个性化词从画像里取这样只有开头句真正需要模型生成。整体算下来单个联系人的成本降到了原来的三分之一左右回复率几乎没有变化。4.3 触达合规退订链接、身份标识与频率限制批量外联做得越顺越要在意收件人的感受。Agent-Reach 里我强制开启了退订链接每一封触达邮件底部都有一段“我不想再收到此类邮件”的标识退订动作会同步回写联系人状态表系统会永久跳过该地址。这个设计不是为了应付平台规则而是长期运营的基础被高频骚扰而不给出口的信箱一定会把你的发信域名拖进黑名单。频率限制方面我除了在发送通道层限流还在业务流程层对单个联系人做了上限控制每轮触达序列最多五封每封之间最短间隔两天任何一封被退订或投诉都立即终止后续动作。这里我给不了你“具体怎么合规”的答案因为不同场景要求差异很大但原则是通用的尊重对方的退出意愿每一次触达都要有明确的目的。4.4 安全边界本地数据最小化与脱敏Agent-Reach 存储了联系人邮箱、公司、职位、画像摘要等信息属于高度敏感的业务数据。我的处理原则叫做“最小化留存”画像只用得上的字段才存模型生成的原始回复文本不落盘只抽取结构化标签进数据库。本地开发环境的数据库做了脱敏处理真实联系人数据只在带密码的独立库里存放。这一点很多人忽略总觉得“数据都在自己电脑上没风险”。但当 Agent 系统开始对接多个外部服务时数据会在第三方接口里流转你无法控制对方怎么处理。提前在架构层做数据分域至少能保证一旦某个环节出问题波及面是可控的。5. 实测数据与经验沉淀Agent-Reach 能带来什么实际收益Agent-Reach 从第一版跑通到现在我在三个不同类型的项目里各用了一个月左右前后处理了接近 2000 个联系人。数据说不了谎一组对比能说明这套多 Agent 流水线到底值不值。5.1 一组对照数据指标我的手动流程Agent-Reach 第一版Agent-Reach 稳定版日均新增联系人15-205050邮件打开率22%9%41%回复率2.8%1.6%12%退订率1.2%4.5%0.8%单人处理时间3-4 分钟自动自动第一版的数据其实很打脸打开率比手动还低回复率几乎腰斩。这是因为第一版根本没解决投递信誉和画像质量的问题光有自动化没有质量保障等于用更快的速度犯错。稳定版数据是在修复投递、引入行为驱动跟进之后测得的我认为那才是 Agent-Reach 该有的样子。回复率从 2.8% 提到 12% 听起来不算夸张但换算到实际场景里意义很大以前要联系 1000 个人才能换来 28 次有效对话现在只要 250 个人省下的时间和冒犯潜在用户的概率都大幅下降。5.2 值得复制的经验清单先把投递层当独立工程对待。Agent 写得再漂亮邮件进不了收件箱就是零。SPF、DKIM、DMARC、预热、限速这些都不该最后补课。画像比文案更值钱。与其花时间调 prompt 写花哨句子不如花时间把联系人背景数据搞准确。Orchestrator 必须做状态持久化。没有 checkpoint 的 Agent 系统只配叫脚本不配叫自动化产品。行为触发跟进的收益远大于固定间隔。让系统读懂“对方是否感兴趣”比单纯增加触达次数重要得多。成本和合规在架构早期就要留好扩展点。能在配置层控制频率就别把限制写死在代码里。5.3 后续迭代方向Agent-Reach 目前还只覆盖了邮件触达我的下一版计划把触达渠道扩展到社交私信并引入回复意图分类 Agent让系统能区分“明确拒绝”“现在不方便”“有潜在兴趣”三种回复然后自动把后两者导入不同的下一步序列。我也会在触发方式上继续做试验比如结合对方公开动态的新行为触发即时跟进而不是依赖固定时间点。如果你也想做一个类似的 Agent 系统我的建议是从一个非常窄的场景开始目标人群是怎么找到的你希望他们做什么动作你用什么节奏跟进。这些问题想清楚了Agent 的架构自然会浮现出来。Agent-Reach 不是一套开箱即用的产品它更像是从真实外联需求里长出来的一套方法论代码你可以自己实现但过程中的每一份教训很难用钱买到。