用Claude Code与MCP构建LinkedIn外展自动化流水线-开发者社区

三周前，一个做 B2B 出海服务的读者在微信上问我：能不能用 Claude Code 批量给 LinkedIn 上的潜在客户发消息？他说他们团队的目标客户有 1000 多个，但手动一个个查看资料、写个性化开场白、点发送，一天最多只能完成 50 个，而且质量还不稳定。后来我们一起花了一周时间，用 Claude Code 和 Codex 搭了一条基于 MCP 工具的外展流水线，并不是为了“自动狂发消息”，而是把找人、验证匹配度、生成个性化内容、人工审核、发送记录这五个环节串起来。第一周只发了 120 条，但回复率比之前手动群发高了一倍多。这个结果让我重新理解了这类自动化的价值：它真正改善的，不是发送数量，而是把高重复、高决策密度的销售工作流变得可控、可复用、可审计。

很多人看到 “1000s of LinkedIn outreach” 的第一反应是：这不就是群发脚本吗？如果从纯技术角度出发，用 Python 加 Selenium 就能模拟点击，用 Claude/Codex 写文案，撑死再加一个 MCP 工具读表格，似乎没有必要引入 30 个 MCP 工具。但实际落地时你会发现，真正能长期使用的系统，不是一锤子买卖的“发送脚本”，而是一个集线索管理、信息验证、内容生成、人工审核、发送执行、效果追踪于一体的增强工作流。下面我拆开讲讲这套方案怎么搭，为什么这样搭，以及哪些边界是你必须提前知道的。

1. 先搞清楚这套自动化真正要解决的是什么

1.1 外展的真正难点不是发消息，而是“决策密度”

LinkedIn 外展看似简单，无非是找到目标客户、发一条消息。但把它拆开，你会发现每一步都需要做大量决策：

这位候选人是不是我们的目标画像？
他现在所在的公司和我们产品有没有交集？
他最近发过什么动态、参加过什么活动，适合用什么切入点？
第一句话是提对方公司的新融资，还是提他分享的一篇文章？
这段消息读起来像流水线群发，还是像一个真正了解他的人写的？

这些决策如果全部靠人工，500 条消息可能就要消耗一个人两周时间。如果全部交给 AI，又会面临错误信息、幻觉、以及内容同质化的问题。传统脚本只能帮你把“发送”这一步自动化，但对前面的信息收集和内容决策没有帮助。这也是我坚持用 Claude Code / Codex 而不是普通脚本的核心原因：它们可以作为“决策代理”，在每一步工具调用之间进行判断和生成。

1.2 为什么选择 Claude Code / Codex，而不是普通自动化工具

Claude Code、Codex CLI 这类工具本质上是一个“能跑在终端里的智能体”。它们不只是执行预定义脚本，而是可以：

读取你本地的文件、CSV、数据库；
通过 MCP 协议，调用浏览器、表格、搜索、CRM 等外部工具；
根据工具返回的结果，生成下一步动作或内容；
以代码或文本的形式输出结果，供你检查或继续执行。

这就解决了传统自动化脚本最尴尬的问题：脚本无法理解语义。比如，当代理打开一个 LinkedIn 个人主页时，它能从“最近动态”里判断出对方在关注什么话题，从而自动生成一句高度相关的话。传统脚本只能按照模板替换变量，效果完全不同。

1.3 为什么需要“约 30 个 MCP 工具”而不是一个全能工具

MCP 的全称是 Model Context Protocol，它给 AI 模型提供了一个标准化的“工具插槽”。你可以理解为，模型不再需要为每个外部服务写一套专门的集成代码，而是通过统一的协议去调用 MCP Server。

对于 LinkedIn 外展这条流水线，我粗略统计了一下，至少需要覆盖这些能力：

浏览器自动化：打开页面、读取内容、点击按钮；
线索领取：从 CSV、Airtable、Notion 或 CRM 读取候选名单；
公司背景查询：通过搜索引擎或公司官网了解目标公司最近动态；
个人信息验证：查看候选人最新职位、工作年限、近期动态；
内容生成：模型本身负责写个性化消息；
发送执行：浏览器自动填写消息框并预览，最终由人点击发送；
状态记录：将每条线索的处理状态写回表格或数据库；
日志和监控：记录每次调用的输入、输出、耗时和错误。

每一种能力背后可能有多个工具。比如浏览器自动化有 Playwright MCP，也有其他 Browser MCP；数据存储有 SQLite MCP、Google Sheets MCP、Notion MCP；如果还要对接公司内部 CRM、邮件系统、Slack 通知，工具数量很容易超过 30 个。

但这里有一个容易被误解的事：工具数量本身不是目标。真正重要的是，你要在同一个代理环境里，把“找线索、分析、生成、审核、发送、记录”这条链路串起来。30 个工具只是这类复杂工作流的自然结果。

2. 把 Claude Code 和 Codex 跑起来：安装、配置和常见报错

2.1 环境准备与初始化

先说明一下，我这里并不打算贴一份“官方安装教程”，因为版本变化很快。你动手之前最好去对应项目的 README 或 CLI 帮助文档里确认最新方式，但无论哪个版本，下面这几个环节是绕不开的：

安装 Node.js，并确认版本满足要求（一般要求 LTS 或更高）。
通过 npm 全局安装 Claude Code 或 Codex CLI。
登录账号，或配置模型服务的 API Key。
在终端输入claude或codex，确认命令可以被识别。
配置 MCP Server，添加你想用的工具。

如果你是 Windows 用户，最容易在第一步就卡住。热搜里经常出现claude : 无法将“claude”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。这通常是 npm 全局安装目录没有写入系统 PATH 导致的。解决方法是：先执行npm install -g @anthropic-ai/claude-code之类命令，随后找到 npm 全局 bin 目录（一般可用npm prefix -g查看），把它加入系统环境变量 PATH，然后重启终端。还有一个常见问题是error: claude native binary not installed. either postinstall did not run，这个大概率是 npm 安装过程中 postinstall 脚本没有正常执行。可以先尝试重新安装，或者检查 npm 缓存、权限。如果重装仍然不行，建议查看安装日志中的 error 栈，不要盲目删除 node_modules。

Codex 这边也有类似情况，很多报错出现在网络或模型配置上。比如cc switch local proxy failed while handling codex endpoint /responses. provi...。这是一个比较典型的提示，说明 CLI 在尝试通过某个本地代理端点发送请求，但连接或协议处理失败了。如果你们公司有统一的开发者代理，需要检查代理地址和认证信息是否正确；如果没有，就不要在配置里随便设 proxy。另外，热搜里还有一条the 'gpt-5.6-sol' model is not supported when using codex with a，这提醒我们：模型名称必须与你接入的服务商支持范围一致。不要因为看到某个模型名很新就乱填，配置前先用codex --help或文档确认可用模型列表。

2.2 配置 MCP Server：把 30 个工具挂进来

MCP Server 的配置方式每个 CLI 略有不同，但核心结构差不多：声明一个 server 名称、启动命令、环境变量和参数。例如，在 Claude Code 中，可以用配置文件或claude mcp add命令来添加。下面是一个简化示例，展示如何添加一个本地运行的 Playwright 浏览器 MCP Server：

claude mcp add playwright -- npx @playwright/mcp@latest --headless=false

有些工具需要配置 API Key，比如搜索 MCP、外部 API 网关等，可以在配置文件里声明环境变量：

{ "mcpServers": { "search": { "command": "npx", "args": ["-y", "@some/search-mcp"], "env": { "API_KEY": "your-api-key" } } } }

这里要特别说一句：不要追求“把热门 MCP 都装一遍”。我曾经见过有人一次配置了 50 个 MCP，结果模型经常不知道该调用哪个，或者多个工具之间的职责重叠导致重复劳动。我更建议按工作流选工具。对于 LinkedIn 外展，最核心的是这几类：

浏览器自动化：Playwright MCP 是绕不开的基础设施，用来打开 LinkedIn 页面、读取资料、填写消息框。注意，--headless=false通常更合适，因为浏览器自动化用于实际外展时，你需要看到页面状态，也便于人工介入验证码。
搜索与网页抓取：用于查公司新闻、行业动态、候选人最近动态。可以是 Search MCP 或通用 HTTP Request MCP。
表格/数据库：读线索 CSV、记录发送状态。可以用 SQLite MCP、Google Sheets MCP、Notion MCP，或者自己写一个轻量文件读写工具。
排程与通知：当需要分批执行时，用 Cron 或定时任务触发；执行完成或失败时，通过 Slack MCP 推送通知。

如果你用 Dify 这类平台，也可以添加本地 MCP 服务来统一管理。它们的原理相同，都是把 MCP Server 注册给 Agent，让模型在对话中调用。

2.3 最小可运行的端到端场景

先用一个最小场景验证流水线是否通：候选名单只有 10 条，不要求发送，只要求生成“建议消息”并写回表格。这样做的好处是，先隔离出最容易出错的环节。

假设你的线索 CSV 长这样：

name,company,title,linkedin_url,last_post Alice,Acme Inc,VP Growth,https://www.linkedin.com/in/alice,We just launched a new API Bob,Beta Ltd,Head of Marketing,https://www.linkedin.com/in/bob,Looking for content ops tools

你可以让 Claude Code 或 Codex 做这样一件事：

请读取 leads.csv 中的前 5 条记录。对于每条记录，先用浏览器 MCP 打开 linkedin_url，读取对方最近一条公开动态，再结合公司名称和职位生成一条不超过 120 字的英文首回合消息。输出格式为 CSV，包含 name, linkedin_url, generated_message 三列，写入 output.csv。

第一次跑通后，再把“打开页面后输入消息、点击发送”加进来。但这一步开始，就要认真考虑合规和质量控制了。

3. 真正决定成败的：批量外展的质量和合规控制

3.1 自动化会放大风险，也会放大错误

LinkedIn 对自动化的态度非常谨慎。如果你的账号在短时间内发送大量重复消息，很可能触发风控机制，轻则限流，重则封号。此外，面向真实用户的商业消息，在很多地区还要遵守反垃圾邮件法、数据保护法规。外展自动化能帮你提高效率，但它同时也把风险放大了。最明显的问题有三个：

账号风险：高频、无差别的自动发送会让平台判定你为机器人。
信誉风险：如果 AI 生成的消息带着错误事实（比如张冠李戴的职位、虚构的共同好友），对方会立刻对你的品牌失去信任。
合规风险：没有获取对方同意就发送营销信息，在某些法律框架下可能违规。

因此，一个负责任的技术方案，必须把“人”留在关键节点上。我强烈建议采用“半自动”模式，而不是所谓的“全自动狂发”。

3.2 把人的判断嵌入流程

我们团队实际采用的流程是这样的：

代理批量读取线索，在本地生成“候选触达消息”清单；
每一条消息都附上生成依据，比如“候选人最近转发了某篇文章”“公司刚宣布融资”；
消息先写入表格的“草稿”列，状态设为pending_review；
人工审核员逐条看，觉得没问题就标记approved，有问题可以修改后标记；
代理只处理approved状态的消息，打开 LinkedIn 消息框，填入内容，但最后一下“发送”按钮由人工点击，或至少预留一个确认确认再执行的开关。

这样做的好处是，即使某个决策点判断失误，也不会直接造成不可逆的负面影响。每次发送前，人都能拦截明显错误的内容。

有人可能会问：既然最后还要人点一下发送，那自动化还有什么意义？意义在于，人工从“阅读资料、构思文案、填写表单”变成“审核一条已经写好的高质量消息”。审核一条消息只需要 5 到 10 秒，而手工写一条可能要好几分钟。这样一天处理 100 条以上是现实的，而且内容质量有了基本保障。

3.3 频率控制与随机化

不要设计“让代理一次性发完 1000 条”的任务。无论从平台策略还是实际效果看，这种极端行为都不可取。

更合理的批次策略是：

每天发送量从 10 条开始，观察账号是否有异常（比如无法访问 LinkedIn、出现安全验证）；
如果没有异常，第二天可以增加到 20 条，再逐步增加；
两条消息之间加上随机延迟，比如 90 到 180 秒；
同一时间段的会话数不要超过 5 个，避免短时间内密集操作。

如果你在运行长时间任务，建议把任务拆成“每天一批”，而不是“一次性跑完”。例如用系统自带的 cron 或 GitHub Actions，每天定时执行一次发送任务。这样即使某天任务卡住，也不会影响第二天的计划。

3.4 个性化内容的质量检查

AI 生成内容最怕的是“听起来很合理，但实际上是编的”。候选人在上个月根本没发过那篇动态，AI 却拿去当切入点，这绝对会翻车。为了避免这种情况，可以做两层校验：

信息来源校验：凡是生成消息中引用的外部事实，必须有一个可验证来源。比如“看到你分享了 XXX”，要让代理记录来源链接，并在输出中一并展示。
人工复核事实：审核员在放行前，如果对某条事实存疑，可以直接点击来源链接确认。无法确认的内容就不要发送。

此外，不要把所有个性化点都押在“对方最近动态”上。可以更多地使用公司公开信息、行业普遍话题、对方职位带来的共同利益点。这样即使个别动态抓取失败，消息依然有一定相关性。

4. 从单条到 1000 条：批次任务、日志和异常排查

4.1 跑通一条和跑通 1000 条是完全不同的工程

一条消息跑通，只能说明代码路径没问题；跑 1000 条时，你会遇到各种意想不到的情况：

某条 LinkedIn 链接失效；
某个人资料需要登录才能查看；
生成消息时，模型突然输出空内容；
浏览器页面加载超时；
某条记录因为网络延迟导致重复发送；
表格写入时遇到非法字符。

所以批量执行前，一定要为数据加上“状态管理”。常见的状态至少包括：

pending // 还没处理 processing // 正在处理中 draft_review // 已生成草稿，等待审核 approved // 人工审核通过 sent // 已发送 failed // 处理失败，需要排查

任务中断后，代理可以根据状态字段自动跳过已经处理过的记录，实现“断点续跑”。例如，如果前 200 条中有 150 条已标记approved，程序恢复后只处理状态为pending和failed的记录，而不会把已发送的消息再发一遍。

4.2 用日志和追踪定位问题

日志不是只打印“成功”“失败”就完了。更实用的做法是，对每次循环输出结构化日志，至少包含：

当前处理的是哪条线索；
步骤编号（读取资料、生成消息、写入表格、发送）；
调用了哪个工具；
工具返回了什么样的结果摘要；
该步骤耗时；
错误类型和堆栈信息。

例如，可以记录成这样的 JSON 行：

{"ts": "2025-02-14T10:00:00Z", "record_id": 17, "step": "fetch_profile", "tool": "playwright", "status": "ok", "profile_title": "VP Growth", "url": "https://www.linkedin.com/in/alice"}

以后排查问题时，你可以直接过滤某个 record_id，看它卡在了哪一步。不要小看这个动作。它省下的不是一天两天的问题复盘时间，而是整个系统的可维护性。

4.3 常见问题排查链路

结合近期安装和使用中高频出现的报错，我列了一个常见问题排查表。它不是万能答案，而是一个比较靠谱的排查顺序。

现象	可能原因	推荐排查顺序
CLI 命令无法识别	npm 全局目录不在 PATH	先执行`npm prefix -g`确认路径，再检查环境变量 PATH
MCP Server 连接失败	端口冲突、启动命令错误、依赖缺失	单独在终端启动 MCP Server 命令，看有没有报错；再检查配置文件中的 command 和 args
浏览器自动化打开页面后一片空白	需要登录、页面加载超时	先手动打开 LinkedIn，确认登录态；考虑增加等待时间或设置`--headless=false`
生成消息内容与资料无关	上下文信息不足或模型幻觉	检查输入的 profile_text 是否完整；增加“必须基于资料原文生成”的系统约束
发送速度过快	循环中没有限速	检查代码中是否配置了随机 sleep；在循环里加并发限制
任务中断后重复发送	状态没有写入磁盘	检查状态更新是否在发送成功之后才提交；增加幂等锁
Windows 下 Claude 安装后仍报错	权限不足 / npm 缓存损坏	重新安装全局包，或使用 npx 的方式临时运行，确认问题来自全局安装还是命令本身
Codex 请求返回模型不支持	endpoint 或模型名配置错误	检查 config 中的 model 字段，确认它是否与当前服务商兼容

4.4 遇到验证码怎么办

浏览器自动化一旦被平台检测到，可能会弹出验证码。技术上有各种处理自动识别的方案，但我不建议在 LinkedIn 外展场景中使用绕过验证码的技术。原因很简单：验证码本身就是平台策略的一部分，强行绕过会大幅增加账号风险，也涉及不正当手段。更稳妥的做法是：

遇到验证码时，代理立即停止自动操作；
通知人工处理；
人工手动解决验证码后，再恢复任务；
如果频繁出现验证码，说明操作频率太高或浏览器指纹异常，需要降低频率并重新评估策略。

把这套逻辑写进自动化代码里，才算是一个有生产意识的方案。

5. 这套工作流的真实边界和长期价值

5.1 适合谁，不适合谁

先说结论：这套方案最适合的是小规模的 B2B 团队、高客单价服务、需要深度个性化的客户开发。它不适合纯粹追求“海量触达”的 C 端营销，也不适合没有任何内容差异化的群发场景。

如果你服务的是大型企业客户，哪怕一天只发 15 条高质量消息，效果也会比发 200 条模板消息更好。因为决策链条长、客单价高、触达质量才是第一位的。反过来，如果你的产品是面向大众消费者的低价商品，这类外展策略本身就不匹配，因为你很难通过人工审核每条消息去覆盖庞大的用户规模。

5.2 和传统方案相比，差异到底在哪里

我用一个表格直观对比：

维度	手动 SDR	传统 RPA 脚本	Claude Code/Codex + MCP
信息收集	人工逐个查，慢	可批量抓取，但无法理解语义	代理可根据目标动态调用不同工具并理解内容
个性化消息	依赖个人经验，质量不稳定	模板变量填充，容易群发感	模型基于真实上下文生成，可解释依据
状态管理	依赖 Excel/CRM 人工维护	脚本可维护，但调整逻辑成本高	可让代理直接读写数据源
风险控制	人工发送相对安全	容易触发风控，且难控制节奏	可以在流程中嵌入审核、限速、暂停规则
长期迭代	经验在人的脑子里	脚本难适应新逻辑	提示词和工具组合可以很快调整，数据沉淀方便

这个表格并不是说 AI 方案一定更好，而是说它把“懂业务的人”和“重复操作”之间的耦合解开了。你能把精力放在策略设计上，而不是每天复制粘贴消息。

5.3 长期价值不在“外展”，而在流程数字化

我见过很多团队，把自动化当成“省钱”手段，目标定在“省掉一个人力”。但真正跑完一轮后会发现，更大的价值是流程被数字化了：哪些线索来源质量更高、哪些开场白更容易得到回复、哪些行业需要什么样的切入点、哪个时间段回复率更高。这些数据积累下来，会形成一个可迭代的销售知识库。

比如，你可以在线索库里为每个目标客户打标签：来源、行业、是否回复、是否有下一步动作。几轮之后，就能分析出“某行业客户更容易被‘案例数据’打动”，还是“创始人背景更容易被‘创始人对创始人’的叙事打动”。这种洞察是任何自动化脚本都替代不了的。

5.4 一套可复用的外展闭环框架

如果你要从零搭建类似系统，我建议按照这个闭环来设计，而不是急着写第一个自动化任务：

线索挖掘：明确目标画像，用人群搜索、推荐、旧客户补充名单；
匹配验证：用工具批量补充公司信息、职位变更、最近动态，判断真实匹配度；
内容生成：基于真实上下文生成差异化消息，并保存引用来源；
人工确认：所有消息在发送前必须过一遍人眼；
发送与追踪：低速、分批、随机化发送，并记录发送时间和后续动作；
反馈回流：把回复、打开、退订等结果写回数据表，更新画像和模板库。

这六个环节不需要一次性做得很重。你甚至可以先用 3 个 MCP 工具做其中三个环节，等稳定后再逐步加工具。真正的难点不是“用 30 个工具”，而是你能不能把每个环节的输入、输出、判定标准定义清楚。

回到开头那个问题：能不能用 Claude Code 批量发 1000 条 LinkedIn 消息？技术上说，可以。但从实际效果和长期信誉看，我更建议把目标改成“用这套工具把 1000 条个性化消息准备好，然后由人确认后以可控节奏发出”。第一次跑通时，只选 10 个线索；稳定后，再逐步扩展到 50、100。你会发现，真正让结果变好的不是海量发送，而是每一次触达前，系统都能帮你回答三个问题：这个人值不值得联系，我该说什么，以及我凭什么让他相信。剩下的“发送”动作，反而是整个流程里最不需要智能的一环。