Claude Code与Codex挂载MCP工具：LinkedIn外联自动化实战

LinkedIn 外联（Outreach）可能是销售和商务拓展团队最痛的重复劳动之一：搜索目标联系人、逐个查看主页、判断是否匹配、撰写几十条带个性化内容的消息、加好友、发 InMail，完了再手动把进度录进 CRM，编排下一轮跟进。一个成熟的销售开发代表每天能触达几十个联系人，一个月下来勉强上千条，而且大量时间花在复制粘贴和页面跳转上。

最近两件事改变了这个场景：一是 Claude Code、Codex 这类具备文件系统读写、命令执行和跨步骤规划的 Agent 工具开始成熟；二是 MCP（Model Context Protocol，模型上下文协议）让 AI 可以稳定地连接外部服务。于是出现了标题中的这种尝试：用 Claude Code 或 Codex 挂载大约 30 个 MCP 工具，让 AI 真正执行上千条 LinkedIn 外联。这个方向确实值得关注，但我的判断是：真正的技术难点不是“挂上 30 个工具”，而是 Agent 如何把一条外联任务拆成可编排、可审核、可回滚的流水线。

如果只看工具数量，很容易误以为装了 MCP server 就能让 AI 自动发消息。实际落地时，账号安全、内容个性化、数据回写和失败恢复才是决定成败的关键。这篇文章会从 MCP 协议讲起，说明 Claude Code 和 Codex 在其中扮演的角色，接着给出 LinkedIn 外联场景下约 30 个 MCP 工具的完整分类，再带你完成环境搭建、流程拆解和可运行的示例，最后给出常见问题与最佳实践。

1. 这篇文章真正要解决的问题

1.1 LinkedIn 外联自动化的真实瓶颈

先说清楚我们讨论的“外联自动化”是什么。它不是简单地群发垃圾消息，而是一条完整的工作流：获取目标客户列表，从中筛选出符合画像的联系人，研究对方的公司动态和个人背景，生成一封看起来像真人写的第一封消息，发送连接邀请或 InMail，然后在对方回复后继续跟进，最后把每一次触达记到 CRM 里，方便销售团队判断线索质量。

这条流程在过去高度依赖人工。即便你使用 LinkedIn Sales Navigator 和第三方插件，大部分环节仍然是半自动的：插件能帮你查出联系方式，但仍然需要人逐个判断消息内容是否对得上，跟进节奏也靠记忆。等规模到上千个联系人时，问题就从“找不到工具”变成了“工具太多，流程断点太多”。

1.2 AI Agent 能改变哪一层

Claude Code 和 Codex 这类 Agent 工具，和传统的 RPA 脚本有一个本质区别：它们有“阅读理解”和“规划拆分”的能力。你不需要为每一个步骤写死逻辑，而是给 Agent 一个目标，它自己判断下一步该调用哪个工具。

在 LinkedIn 外联场景中，这意味着你可以让 Agent：

• 读取 CRM 或表格中的目标客户列表。
• 调用搜索与调研类 MCP 工具获取公司背景、联系人职位和最新动态。
• 按照你定义的消息模板，为每个人生成个性化开场白。
• 把生成的内容写入待审核目录。
• 人工确认后，再调用发送类 MCP 工具执行发送。
• 最终把发送状态、回复状态回写到 CRM。

这套链路单靠一个模型或一个脚本很难完成，因为涉及数据源、外部 API、文件系统、定时任务等多类系统。MCP 的价值正是把所有这些能力标准化成工具，让 Agent 不必关心每个服务的 SDK 差异。

1.3 30 个 MCP 工具意味着什么

标题里“约 30 个 MCP 工具”听起来像技术噱头，实际上是这种自动化走向工程化的必然结果：外联流水线涉及的领域太杂，单一 All-in-One 的 MCP server 会非常重，任何一个小功能升级都要连坐整个服务。拆成 30 个左右细分工具，每个只做一件事，权限也可以独立控制，某一个 server 挂了不影响其他步骤。这才是规模化自动化真正需要的基础设施。

2. 基础概念：MCP、Agent、Tool 与 Skill 之间的关系

2.1 MCP 是什么

MCP 是一种开放的客户端-服务器协议，解决“AI 应用如何安全地调用外部工具和获取数据”的问题。可以把它理解成 AI 世界的 USB-C 接口：过去不同类型的设备有各自的充电线，现在统一成一个标准接口。

技术上有三类角色：

• MCP Host：运行 AI 的客户端，比如 Claude Code、Codex 或 Claude Desktop。
• MCP Server：暴露能力的数据源或工具服务，最常见的实现方式是一个本地进程或远程 HTTP 服务。
• MCP Client：Host 内部负责连接 Server 的组件。

以 Claude Code 为例，你配置一个 MCP server 后，Claude 在推理时就能看到这个 server 暴露了哪些工具，并自行决定是否调用。这大大降低了工具接入成本，你不需要为每个外部服务写一套 custom tool 的注册代码。

2.2 Claude Code 和 Codex 在体系中的位置

Claude Code 是 Anthropic 推出的命令行编程 Agent，Codex 是 OpenAI 对应用户命令行 Agent 的产品线。它们既充当 MCP Host，也是能“读懂项目并完成长任务”的 Agent 底座。

在 LinkedIn 外联场景中，它们的作用不是“帮你写代码”，而是“替你跑流程”。你通过提示词告诉它目标、约束和流程，它自己调用挂在 MCP 上的工具，逐步完成任务。相对于在聊天框里问问题，它们能操作真实文件系统、执行命令、运行脚本，所以更适合自动化场景。

2.3 Tool 和 Skill 的区别

很多人容易把 MCP 工具和 Skill 混在一起，这里做一个区分：

MCP 解决的是“AI 如何调用外部能力”的通信协议问题，而 Skill 解决的是“AI 按照什么流程使用这些能力完成一类任务”的经验打包问题。MCP 描述的是“动作”，Skill 描述的是“方法”。例如，一个 LinkedIn 消息生成 MCP 工具只负责生成文案，而一个 LinkedIn 外联 Skill 会规定：先读客户列表，再做个性化调研，再生成草稿到待审核目录，审核通过后才能发送。

在一个大型自动化项目里，两者同时存在：MCP 工具提供原子能力，Skill 把这些原子能力按业务流程组合起来。

2.4 Agent 长链路执行的难点

一个容易被低估的事实是：Agent 在长链路任务是会失败的，而且失败概率随步骤数增加而快速上升。如果每个 MCP 工具调用成功率为 95%，一次任务需要连续调用 20 次工具时，理论成功率只有约 35%。这还没算上网络超时、限流、接口字段变更等问题。

所以真正工程化时，你会把外联目标拆成多个小任务：一批 100 条消息，每条消息先走到“待审核”状态，而不是让 Agent 一口气完成所有步骤。后面第 6 节的示例也遵循这个原则。

3. LinkedIn 外联工具栈：约 30 个 MCP 工具怎么分类

标题里说的约 30 个 MCP 工具，并不需要我在这里列出一个精确清单，因为具体 server 会随团队技术选型和社区生态变化。更重要的是理解分类。通常可以分成以下六大类：

如果把这六类再去细化，每类拆分出四到五个具体工具，很容易就接近 30 个。例如“调研”类可以拆成官网爬虫、新闻检索、LinkedIn 资料解析、公司关键词提取、竞品动态监控等；“执行与发送”类可以拆成连接邀请、InMail、普通消息、后续跟进、频控检测等。

3.1 为什么不是一个 All-in-One 工具

你可能想问：为什么不直接找一个既管客户数据、又管消息发送、还管 CRM 更新的“全家桶”MCP？原因有三个。

第一，权限边界模糊。一个工具如果既能读客户列表，又能发送消息，那么 Agent 一旦判断失误，就可能在没有审核的情况下直接发出内容。

第二，故障爆炸半径大。单体工具一旦挂掉，整条流水线停摆；拆分成多个工具后，调研环节失败可以重试，发送环节仍可等待人工确认。

第三，可替换性。某个 vendor 的 MCP server 升级导致接口不兼容，你可以只替换这一个 server，Agent 编排指令基本不用改。

这也解释了为什么“约 30 个 MCP 工具”值得被认真当作一种架构风格来对待。

4. 环境准备：安装 Claude Code 与 Codex 并接入 MCP

4.1 安装 Claude Code

Claude Code 最常用的安装方式是通过 npm 全局安装，前提是你已经装好了 Node.js。安装命令如下：

npm install -g @anthropic-ai/claude-code

安装完成后检查版本，确认命令可用：

claude --version

如果提示claude不是内部或外部命令，通常说明 npm 的全局 bin 目录没有加入系统 PATH，需要检查 Node.js 的全局安装路径，并把它添加到环境变量。

4.2 安装 Codex CLI

Codex CLI 的具体安装方式请以官方文档为准，因为不同时期提供的包名和分发渠道可能不同。常见方式包括 npm、Homebrew 或官方二进制包，这里给出一个通用示例：

# 请先查阅 Codex 官方文档，选择对应系统的安装方式 npm install -g @openai/codex

安装后运行帮助命令，确认可用：

codex --help

如果你在 Windows 环境遇到命令无法识别，大概率也是 PATH 配置问题，处理方法与上面相同。

4.3 MCP 配置方式

Claude Code 支持通过命令行添加 MCP server，也支持通过项目级配置文件.mcp.json管理。下面是一个最常见的 stdio 型 MCP server 配置示例，文件中每个 server 代表一个独立工具服务：

{ "mcpServers": { "customer-db": { "command": "npx", "args": [ "-y", "@your-org/customer-db-mcp" ], "env": { "DB_URL": "postgresql://127.0.0.1:5432/outreach" } }, "linkedin-sender": { "command": "npx", "args": [ "-y", "@your-org/linkedin-sender-mcp" ], "env": { "LINKEDIN_ACCESS_TOKEN": "your_token_here" } }, "research-news": { "command": "npx", "args": [ "-y", "@your-org/research-news-mcp" ] }, "crm-writer": { "command": "npx", "args": [ "-y", "@your-org/crm-writer-mcp" ], "env": { "CRM_API_KEY": "your_crm_api_key" } } } }

注意，实际项目里不能直接使用我这个示例中的包名，需要替换成你所在团队或社区生态里真实存在、经过审计的 MCP server。

远程 MCP server 的配置格式略有不同，通常是下面的样子：

{ "mcpServers": { "remote-analytics": { "url": "https://mcp.example.com/mcp", "headers": { "Authorization": "Bearer YOUR_TOKEN" } } } }

配置好后，用 CLI 命令把 server 注册到 Claude Code：

claude mcp add customer-db -e DB_URL=postgresql://127.0.0.1:5432/outreach -- npx -y @your-org/customer-db-mcp

4.4 验证 MCP 是否接入成功

接入完成后，先查看当前已挂载的 MCP server：

claude mcp list

如果列出的 server 状态正常，就可以在 Claude Code 交互界面里输入一个简单指令，比如“列出你现在能使用的全部工具”。正常情况下，Claude 会把各个 MCP server 暴露的工具名和用途整理出来。

如果某个 server 报错连接失败，先单独运行配置里的 command 参数，看进程本身能不能正常启动。很多 MCP 接入问题的根源都不是 AI 客户端，而是 server 进程依赖的 Token、端口或数据库地址不正确。

5. 核心流程拆解：一次大规模外联任务的完整生命周期

有了环境基础，接下来要把一条外联任务拆成可执行、可验证的阶段。每一阶段都要有明确的输入、输出和失败处理方式。

5.1 目标客户解析

外联任务通常从客户列表开始。这个列表可能是 CSV、Salesforce 导出、或销售团队维护的飞书/在线表格。在这个阶段，Agent 调用“客户数据获取”类 MCP 工具，把原始数据标准化成统一结构：公司名、联系人姓名、职位、行业、地区、LinkedIn URL、最近互动时间等。

这个阶段容易出现字段缺失和格式杂乱的问题。最佳实践是先做字段校验，缺失关键字段的联系人先标记为“待补全”，而不是直接进下一步。

5.2 个性化调研

调研的质量决定了外联消息能不能获得回复。Agent 会为每个目标调用“画像与调研”类工具，收集三类信息：

• 公司级信息：官网动态、融资信息、技术栈、近期新闻。
• 联系人级信息：职位变化、近期发布的内容、关注的领域。
• 连接触发点：是否存在共同的行业话题、对方公司是否有正在招聘的岗位、是否有与你产品相关的痛点信号。

这一步是 30 个 MCP 工具最能体现价值的地方：多个细分工具并行获取数据，汇总成一段简短画像，再交给大模型生成个性化消息。

要特别说明，调研不是越深越好。对 1000 个联系人做 10 分钟深挖，不如对每个人做 30 秒精准信息抽取。工程上应该控制每次调研的时间预算。

5.3 消息生成与审核

消息生成环节必须人工介入，至少要保留“审核关卡”。AI 生成的外联消息可以做到格式统一、逻辑通顺，但在品牌口径、合规风险和语气把握上仍需要人把关。

实际工程设计中，Agent 会把生成的消息输出为 Markdown 文件，每一份文件包含目标联系人信息、生成日期、匹配理由、外联文案，写入pending/目录。销售团队负责人可以快速浏览这些文件，修改后标记为“允许发送”。

5.4 发送与跟进排程

审核完成后，Agent 才允许调用“执行与发送”类 MCP 工具。发送不等于全部发完，它需要严格遵守频控策略：每分钟最多多少次、每小时最多多少次、每天最多多少次，并且要能根据 429 状态码自动暂停。

对于没有回复的联系人，Agent 会在设定的等待周期后生成跟进消息，这个跟进任务也应先进入待审核队列，而不是直接自动重发。

5.5 结果回写

外联的闭环在 CRM。发送成功、发送失败、已读不回、收到回复、预约会议，这些状态必须从发送工具和人工反馈回流到客户数据工具。汇总结果后，Agent 可以生成日报：今日触达人数、回复率、待跟进数量、异常失败数量。

5.6 链路编排的整体思路

整个流水线可以概括为：数据进入 → 标准化 → 调研 → 生成 → 审核 → 发送 → 回写 → 统计。每个环节之间使用文件或数据库状态作为“通信协议”，这样即使 Agent 中途退出，下一轮重新启动时也能从断点继续，而不是从头再来。

这也是长链路自动化最重要的工程原则：状态持久化，任务可恢复。

6. 完整示例：Claude Code 挂载 MCP 后执行外联任务

下面给一个最小可运行的示例，演示从“读取客户列表”到“生成待审核消息”的完整流程。为了方便复现，我使用本地文件和通用 MCP server 概念代替具体第三方 server。

6.1 项目结构

linkedin-outreach/ ├── .mcp.json ├── .claude/ │ └── skills/ │ └── outreach/ │ ├── SKILL.md │ └── run_outreach.sh ├── data/ │ └── prospects.csv ├── pending/ │ └── .gitkeep ├── sent/ │ └── .gitkeep └── reports/ └── .gitkeep

prospects.csv是待外联的目标列表，字段至少包含name, company, title, linkedin_url, note。pending目录用于存放审核通过前的外联消息草稿，sent目录存放已发送记录，reports目录存放每日统计。

6.2 MCP 配置文件

这里的核心是.mcp.json。为了避免虚构真实服务，我用三个有代表性的通用命令做示例：一个读取 CSV 数据，一个调用通用搜索服务做调研，一个提供消息模板渲染。

{ "mcpServers": { "csv-reader": { "command": "python3", "args": ["./tools/csv_reader.py"] }, "research-search": { "command": "npx", "args": ["-y", "@example/research-search-mcp"], "env": { "SEARCH_API_KEY": "YOUR_SEARCH_API_KEY" } }, "message-render": { "command": "python3", "args": ["./tools/message_render.py"] } } }

注意，@example/research-search-mcp是一个占位包名，实际项目中你要替换成真实存在且经过检查的工具。如果只是做本地验证，完全可以用一个本地 Python 脚本模拟搜索服务。

6.3 Skill 文件：外联流程定义

Skill 的价值是让 Claude Code 知道遇到“外联任务”时应该按什么流程执行。创建一个SKILL.md：

# LinkedIn Outreach Skill 当你收到“执行外联任务”的指令时，按以下流程进行： ## 流程步骤 1. 调用 csv-reader MCP 读取 data/prospects.csv。 2. 对每一行联系人，调用 research-search MCP 获取公司最新动态和联系人相关关键词。 3. 调用 message-render MCP，结合模板生成外联消息。 4. 将生成的 Markdown 文件写入 pending/ 目录，文件名格式：YYYYMMDD_{name}_{company}.md。 5. 写入完成后，输出待审核文件清单，等待人工确认。 6. 在人工确认前，禁止调用任何发送类工具。 ## 规则 - 每一份待审核文件中必须包含：联系人名称、职位、公司、匹配理由、外联文案。 - 优先级：先处理有 explicitly 用户标记的 hot 联系人。 - 检查 pending/ 目录是否已有同名文件，避免重复生成。 - 如果文件数超过 20，分批次执行，每批执行后暂停等待人工指令。

这个示例刻意把“审核前禁止发送”写进了流程约束。原因是 Agent 倾向“尽快完成任务”，只有流程定义里明确约束，才能保证安全边际。

6.4 运行外联任务

将.mcp.json放在项目根目录，然后在项目目录启动 Claude Code：

cd linkedin-outreach claude

启动后输入：

请执行外联任务，目标来自 data/prospects.csv，先生成前 5 份待审核消息。

Claude 会读取 CSV、调研、生成消息、写入pending/目录。你可以通过以下命令查看结果：

ls -la pending/

每份待审核文件打开后类似下面这样：

联系人名称：张三 职位：技术副总裁 公司：某云原生公司 匹配理由：对方公司近期发布 Kubernetes 相关招聘岗位，与我司容器安全产品匹配度高。 外联文案： 您好，张总。我注意到贵公司正在扩建云原生团队，尤其是在 Kubernetes 方向有多个新岗位。我们团队近期发布了一份关于容器安全最佳实践的报告，想发给您参考。如果方便，我可以把完整版链接发给您，您有 5 分钟时间看看是否值得讨论。

6.5 提交审核与后续发送

人工审核通过后，可以继续要求 Claude Code 更新消息状态，并调用发送类 MCP 工具。发送完成后，Agent 将消息移到sent/目录，并把发送状态追加到reports/daily_summary.md。

如果只是第一次实验，强烈建议把整个过程停在“生成待审核消息”这一步，不要立刻配置发送工具。先积累一批真实消息样本，确认 Clauaude Code 对目标的理解、模板质量和数据解析是否正确，再逐步打开发送通道。

7. 运行结果与效果验证

7.1 预期输出

成功跑通一次任务后，你应该能看到三类输出：

• pending/目录下出现 5 份 Markdown 外联草稿。
• 每份草稿包含联系人信息、匹配理由和个性化外联文案。
• Claude Code 的对话界面打印出待审核清单，没有调用任何发送工具。

7.2 如何判断成功

判断标准不是“Claude 有没有生成内容”，而是生成的内容是否满足你的业务要求。建议逐份检查三个问题：

1. 联系人信息和 CSV 是否对得上，有没有串行。
2. 调研信息是否真实，还是模型凭概率编造。
3. 外联文案是否像真人写的，是否清楚说明“为什么联系对方”。

如果三关都过，才能说流程跑通了。否则需要调整 CSV 字段、调研工具或模板提示词。

7.3 失败后第一步看哪里

如果任务中断，先不要急着重新发指令，按以下顺序排查：

1. 查看pending/目录里已经生成了多少文件，判断 Agent 做到了哪一步。
2. 检查 Claude Code 对话中最后一次工具调用是什么，错误通常发生在 MCP server 连接或 API 请求上。
3. 单独运行对应的 MCP server 命令，确认它是否在项目外面也能正常启动。
4. 检查 CSV 是否包含异常字符，例如换行、双引号、超长字段。

8. 常见问题与排查思路

要特别注意的是，LinkedIn 对自动化操作有严格限制。凡是涉及发送连接邀请、InMail 或批量消息的功能，都必须先阅读并遵守平台条款，并考虑专业法务意见。技术可实现不等于平台允许，降低频率、保留人工审核、用小范围账号试点，是降低风险的基本做法。

9. 最佳实践与工程建议

9.1 合规与平台风险放在第一位

自动化外联最容易被忽视的是合规问题。搭建流程前，先确认使用的数据源是否合法、是否涉及个人信息保护、是否违反平台自动化条款。我的建议是：把“自动发送”这一步设计成可选模块，默认关闭。只有在一个充分授权、符合平台规则的业务场景中，才允许打开自动发送通道。

9.2 最小权限原则

每个 MCP server 只应该拥有完成自己任务的最小权限。例如，客户数据读取工具应该只有只读权限；发送类工具不能同时有读取 CRM 所有客户的权利；CRM 写入工具不应该能删除历史记录。Agent 一旦被提示词注入或误判，权限边界越窄，损失越小。

9.3 凭证管理

所有 API Key、数据库连接串、访问令牌都要通过环境变量注入 MCP server，绝不能写入.mcp.json或代码仓库。如果.mcp.json需要提交到 Git，至少保证里面的敏感项通过${ENV_VAR}引用。

9.4 强制审核与人工确认

无论 Agent 能力多强，外联消息在发送前都应该经过人工审核。用最小可行流程来验证时，可以让 Agent 只负责生成草稿和更新 CRM，发送动作由人工点击完成。这个习惯能避免绝大多数灾难性错误。

9.5 可观测性与审计

为每一次工具调用记录日志，至少包含：调用时间、输入参数摘要、返回状态、耗时。这样某个联系人突然收到错误消息时，你可以快速定位是哪一步出了问题。日志不要只存内存，建议写本地文件或合并收集到可视化平台，方便做周度复盘。

9.6 渐进式上线

第一次跑 10 条，验证质量；第二次跑 50 条，观察账号状态和数据一致性；确认稳定后再尝试 200 条、500 条。上线节奏比工具数量更重要。即便是技术上能跑上千条，也不意味着应该第一天就跑完。

9.7 消息质量优于触达数量

最后回到业务本身：上千条外联的最终目标是获得回复，而不是制造已发送记录。影响回复率的核心因素是相关性和信任感，而不是消息条数。用 MCP 工具做调研，本质是为了让每条消息都能回答一个问题——为什么我要联系你？如果这个问题回答不清楚，挂载更多工具也不会提升转化。

10. 总结与后续学习方向

这篇文章从 LinkedIn 外联自动化这个具体场景出发，解释了 MCP 协议为什么能成为 AI 连接真实业务的底座，也拆解了 Claude Code、Codex 这类 Agent 工具在长链路自动化中的角色。真正值得记住的结论有三个：第一，MCP 工具数量不是指标，流程编排和状态管理才是；第二，Agent 长链路任务必须有审核、重试和断点恢复机制；第三，执行前把合规、权限、凭证和审计方案想清楚，比任何 prompt 技巧都重要。

如果你接下来想继续深入，建议按三个方向学习：一是研究 MCP 规范本身，了解 stdio、HTTP、Streamable HTTP 等传输方式，以及工具、资源、提示词三类 primitives 的差异；二是阅读 Claude Code 或 Codex 的官方文档，理解它们支持的文件型技能（Skill）和项目级配置；三是把外联流程划分成“数据解析、调研、生成、审核、发送、回写”六个独立环节，先逐个实现，再串成完整流水线。

如果今天只做一件事，我建议先把手里的外联流程画成状态流转图，再为每个状态找一个可以用 MCP 暴露的工具，然后从 10 个真实联系人开始跑通全链路。挂载 30 个 MCP 工具之前，先让 3 个工具在真实目标上稳定运行一周。规模化从来不是从第一天开始的，而是从一次能成功的最小闭环开始的。