如果你关注 AI Agent 编程工具，应该已经看到过 Claude Code 和 Codex CLI 这两个名字。前者来自 Anthropic，后者来自 OpenAI，都是能让模型在终端里读代码、改文件、执行命令的编程助手。而 MCP（Model Context Protocol）则是把它们和外部工具连接起来的开放协议。最近有个社区方案把这三件事组合在一起：让 Claude Code 或 Codex 带着约 30 个 MCP 工具，自动跑 LinkedIn 外联（outreach），标题甚至写到了“1000s”。
先给结论：这个思路对做销售技术、CRM 集成和 AI Agent 工作流的开发者来说值得研究，但不能把“1000s”理解成靠脚本无脑群发。LinkedIn 对自动化访问和私信有明确限制，绕过风控、批量骚扰真实用户，很可能导致账号受限，也涉及平台条款和隐私问题。所以这篇文章只讲技术链路：怎么安装 Claude Code / Codex CLI，怎么配置 MCP，怎么用 dry-run 测试外联工作流，怎么设计合规的小批量任务。真正的用户触达，建议走官方 API 或人工审核流程。
全文围绕三条主线展开：MCP 工具链的搭建、批量任务编排的工程方法、自动化外联的安全边界。读者看完可以自己搭一套最小可用链路，用测试账号验证效果。
1. 核心能力速览
| 能力项 | 说明 |
|---|---|
| 项目定位 | 基于 Claude Code / Codex CLI 的 LinkedIn 外联自动化方案 |
| 核心依赖 | Claude Code、Codex CLI、MCP 工具链 |
| MCP 工具规模 | 标题中约 30 个，通常包含搜索、读取、写入、消息发送等能力 |
| 硬件门槛 | 不需要 GPU，普通开发机能运行；重点在 API 配额和网络环境 |
| 启动方式 | 终端命令启动，支持交互式会话和 batch/dry-run 模式 |
| API 能力 | 通过 MCP Server 暴露给 Agent，可被 Claude Code / Codex 直接调用 |
| 批量任务 | 支持脚本循环、任务队列、日志记录，但实际发送量必须受平台限制 |
| 合规风险 | 高；必须遵守 LinkedIn 服务条款，建议仅用于测试和获客前的线索筛选 |
| 适合读者 | 做技术验证、销售工具开发、CRM 集成、AI Agent 工作流的开发者 |
这套方案的核心不是某个单一模型，而是“Claude Code / Codex CLI + MCP 协议 + 外部工具”的组合。Claude Code 和 Codex CLI 负责理解任务、拆解步骤、调用工具，MCP 负责把 LinkedIn 相关的数据访问、消息生成、CRM 写入等能力统一暴露给 Agent。30 个 MCP 工具听起来多，但实际使用时可以按工作流分成几组，不一定全部同时启用。
2. 适用场景与使用边界
这类“AI Agent + 外联自动化”方案能做的事情可以拆成 4 个环节：
- 线索发现：从自己的 CSV、CRM 或公开资料中找出潜在联系人，并补充公司、职位、地区等公开信息。
- 资料分析：根据对方的公开资料生成个性化外联理由，减少“复制粘贴”感。
- 消息草稿生成：生成适合 LinkedIn 消息长度和语气的英文或本地化文案。
- 消息发送与记录：把最终确认后的消息发送出去，并把状态写回 CRM 或数据库。
其中最安全、也最适合先验证的环节是前两个。你可以让 Claude Code 读一个含 100 条姓名的 CSV，再通过 MCP 工具去查询公开资料，生成个性化草稿。这个过程中不直接触达真实用户，风险很低。
消息发送环节最危险。LinkedIn 对未经验证的自动化消息有很强的检测能力，高频发送、同一模板换变量、短时间内大量加好友，都容易被风控。更稳妥的做法是：Agent 只负责准备草稿和排期，最终点击发送按钮由人工完成，或者使用 LinkedIn 官方推荐的广告、Sponsored Messaging 等产品化能力。
从“能不能做”的角度看，技术上确实可以在本地跑一套自动化流程，用约 30 个 MCP 工具覆盖从线索导入、资料补充、草稿生成到 CRM 同步的完整链路。但从“该不该做”的角度看，必须注意三条边界：
- 平台条款边界：不要绕过登录验证、验证码、频控限制。
- 隐私边界：不要批量采集个人隐私数据，不要将非公开信息用于营销。
- 内容边界：不要发送虚假宣传、欺诈性内容，不要冒充他人身份。
所以这篇文章后续所有的批量任务设计，都默认是在测试环境、测试账号、获得授权或使用官方接口的前提下进行。
3. 环境准备与前置条件
开始部署之前，先确认本机环境是否满足条件。这套方案没有 GPU 依赖，普通笔记本或云服务器都能跑，但需要能正常访问 Claude Code / Codex CLI 的服务地址，并具备以下基础条件：
| 前置条件 | 说明 |
|---|---|
| Node.js 环境 | Claude Code 和 Codex CLI 通常依赖 Node.js 运行 |
| 终端工具 | Linux / macOS 使用 bash、zsh，Windows 使用 PowerShell 或 WSL |
| Claude Code / Codex CLI | 二选一，也可以都装 |
| API Key | Claude API Key 或 Codex 登录凭证，具体以官方文档为准 |
| MCP 工具包 | 至少一个可用的 MCP Server，用于验证协议链路 |
| LinkedIn 测试账号 | 建议使用封闭测试账号，而不是主账号 |
| 目录规划 | 输入、输出、日志分目录管理，避免文件混乱 |
这里有一个容易忽略的点：约 30 个 MCP 工具不一定需要你从零开发。很多常见能力如网页搜索、浏览器操作、数据库读写、消息发送、CRM 写入，都可以找到现成的 MCP Server。真正的工程量在于把这些工具接入到同一个 Agent 会话里，并让 Claude Code / Codex 知道什么时候该调用哪个工具。
在安装依赖之前，先把目录结构准备好：
mkdir -p linkedin-outreach/{inputs,outputs,logs,configs}inputs放候选人名单，outputs放生成的消息草稿和任务结果，logs放每次运行的日志，configs放 MCP 配置和模型配置。这样后面批量跑任务时，出问题能快速定位。
4. 安装部署与启动方式
4.1 安装 Claude Code
Claude Code 官方提供了 npm 安装方式。以下命令是通用示例，具体版本号以官方文档为准：
npm install -g @anthropic-ai/claude-code claude --version安装完成后，在终端输入claude就会进入交互式会话。如果系统提示“claude 无法识别”，通常是 npm 全局目录没有加入 PATH，或者是安装过程中断。这种情况先检查 Node.js 和 npm 是否正常，再重开终端窗口。
Claude Code 原生支持 MCP，所以后续配置 MCP Server 时不需要额外启动一套客户端服务，直接在配置文件里声明即可。
4.2 安装 Codex CLI
Codex CLI 是 OpenAI 推出的终端编程 Agent，安装方式也以官方文档为准。以下命令仅作示例：
npm install -g @openai/codex codex --helpCodex 通常需要登录或配置 API Key。如果启动时出现与/responses相关的报错，先检查 API 地址、模型名称和网络连通性，而不是急着改代码。这类问题大多是认证或模型版本不匹配造成的。
如果使用的是第三方兼容服务，需要在配置里指定对应的 base URL 和模型名。注意这里的 base URL 一定要来自你实际使用的服务商文档，不要照搬网上来源不明的配置。
4.3 配置 MCP Servers
MCP 的配置文件通常是一份 JSON，里面声明了每个 MCP Server 的启动命令、参数和环境变量。下面是一个最小示例：
{ "mcpServers": { "search-people": { "command": "npx", "args": ["-y", "your-search-mcp-server"], "env": { "API_KEY": "替换为真实密钥" } }, "crm-writer": { "command": "npx", "args": ["-y", "your-crm-mcp-server"], "env": { "CRM_TOKEN": "替换为真实密钥" } } } }注意：your-search-mcp-server和your-crm-mcp-server是占位符，你需要替换成实际可用的 MCP Server 包名或本地脚本路径。密钥不要硬编码到仓库里，建议通过环境变量注入，或者用密钥管理工具统一管理。
4.4 启动与连接确认
配置完成后，启动 Claude Code：
claude在交互会话里输入：
请列出当前可用的 MCP 工具如果配置正确，Agent 会返回已加载的工具列表。如果列表为空，说明 MCP Server 启动失败或配置文件没有被正确加载。这时应该先单独在终端运行npx -y your-search-mcp-server，看有没有报错，确认 Server 本身能起来，再回到 Agent 里排查。
Codex CLI 的启动方式类似，只是命令不同。核心流程是：先让 Agent 连接成功的 MCP Server，再逐步加入测试数据。
5. 功能测试与效果验证
完成部署后，不要直接跑上千人的批量任务。先按下面的顺序做功能验证，每一步都确认无误后再进入下一步。
5.1 MCP 工具连接测试
这一步的目的是确认 Agent 能真正调用工具。以 Claude Code 为例，在终端执行：
claude -p "请调用 search-people 工具，搜索最近活跃的 3 个目标客户，只返回姓名和公司，不要发送消息"预期结果是：Agent 调用 MCP 工具并返回结构化结果。如果报错，先看日志里是“工具不存在”还是“工具调用超时”。前者是配置问题，后者可能是网络或 Server 进程问题。
5.2 外联草稿生成测试
准备一个最小 CSV 文件inputs/prospects.csv，内容可以只包含几行测试数据：
name,company,title,linkedin_url 张三,某科技公司,CTO,https://www.linkedin.com/in/example 李四,某电商平台,VP Marketing,https://www.linkedin.com/in/example2然后让 Agent 读取 CSV 并生成草稿：
读取 inputs/prospects.csv，为每一行生成一条不超过 150 字符的英文外联消息，保存到 outputs/drafts.json，不要发送。这条命令的关键是“保存文件”和“不要发送”。先确认 Agent 是否具备文件读写能力，再看生成的消息质量。LinkedIn 消息长度有限，超过 150 字符容易被截断或显得不专业，所以建议先规定长度上限。
5.3 dry-run 发送测试
dry-run 是指不真正发送消息，只模拟整个播放流程。可以设计一个规则文件，让 Agent 在发送前做检查。例如：
claude -p "读取 outputs/drafts.json，逐条检查是否包含个性化字段，如果包含'公司名'和'职位'，标记为 ready，否则标记为 review；不要实际发送。"这样做的好处是，能在不触达任何真实用户的情况下，验证任务链路是否完整。如果你需要把发送环节也纳入自动化，这里建议停止自动化，改为人工审核。
5.4 小批量实发测试
如果一定要验证真实发送，最安全的方式是：先让 Agent 生成 3 条草稿，人工确认内容无误后，再通过官方接口或人工手动发送。发送后观察账号状态和消息送达情况，确认无异常后再小范围扩大。
不要跳过 dry-run 直接全量发送。外联自动化最大的成本不是代码，而是账号权重和品牌信誉。一次批量翻车可能让整个账号受限。
6. 接口 API 与批量任务设计
Claude Code 和 Codex CLI 本身不是 REST API，但 MCP 协议承担了“接口服务”的角色。所有外部能力都以工具形式暴露给 Agent，Agent 再根据任务目标组合调用。
6.1 任务队列示例
批量任务可以用一个 JSON 队列来描述，每条任务包含类型、输入文件、延迟时间等参数：
{ "tasks": [ { "id": "task_001", "type": "draft", "input": "prospects.csv", "delay_seconds": 60 }, { "id": "task_002", "type": "review", "input": "drafts_001.json", "delay_seconds": 300 } ] }delay_seconds是任务之间的等待时间，用来控制频率。真实外联场景里，频率过高会触发风控，所以批量任务一定要设置合理的间隔和限速。
6.2 批量循环示例
下面是一个 shell 循环示例，演示对候选列表逐条处理：
for row in $(cat inputs/prospects.txt); do echo "process $row" claude -p "对 $row 生成外联草稿并保存到 outputs/" sleep 30 done注意：这个示例只是演示循环和延时，不建议在没有人工审核的情况下直接发送。实际项目中，建议用 Python 或 Node.js 写一个任务调度器，记录每条任务的状态、耗时和结果，而不是在 shell 里裸奔。
6.3 失败重试建议
批量任务出现失败是很正常的。建议每个任务记录pending、running、success、failed四种状态。失败任务最多重试 2 次，重试间隔逐步拉长。如果第 3 次仍然失败，写入单独的错误日志，等待人工排查。
{ "task_id": "task_001", "status": "failed", "error": "MCP tool timeout", "retry_count": 2, "next_retry_at": "2025-06-01T12:00:00Z" }这样的结构化日志能让你快速判断是单条数据问题，还是整个 MCP Server 不可用。
7. 资源占用与性能观察
这套方案不需要 GPU 推理，主要资源消耗集中在 CPU、内存和 API 配额上。
- CPU：MCP Server 和 Agent 进程都会有 CPU 占用。如果同时启动 30 个 MCP Server，每个 Server 独立进程，内存占用会明显上升。
- 内存：Node.js 进程通常占用 100MB 到 500MB 不等，具体取决于 MCP Server 的复杂度。如果内存不够，可以只在需要时启动对应工具，而不是一次性全开。
- 网络带宽：查询公开资料、调用模型 API、上传下载文件都会消耗带宽。大 CSV 文件建议拆分处理。
- API 费用：这是最大的成本项。每次让 Claude Code 或 Codex 调用工具、生成草稿，都会消耗 tokens。批量任务越大，费用增长越快。
建议在logs目录里记录每次任务开始和结束的时间，以及期间调用的工具和 tokens 消耗。这样不仅能观察性能，还能在月底对账时知道钱花在哪里。
还有一个容易被忽略的性能点：约 30 个 MCP 工具意味着 Agent 在每次决策时都要考虑更多工具，模型的选择成本也会变高。如果某个任务只需要 3 个工具，就不要把所有 MCP Server 都注册进去。按工作流分组启动，能明显减少误调用和超时。
8. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
claude无法识别 | npm 全局目录不在 PATH | 执行which claude | 重开终端，或把 npm 全局目录加入 PATH |
| MCP 工具列表为空 | MCP Server 崩溃或 JSON 配置错误 | 单独运行 MCP Server 命令 | 查看启动日志，修正配置 |
| Codex 请求报错 | API 地址、API Key、模型版本不匹配 | 检查环境变量和日志 | 按官方文档配置 base URL 和 model |
| 批量任务卡住 | 单次任务超时或 API 限流 | 查看任务日志 | 增加超时和重试，降低并发 |
| 账号出现风控提示 | 请求频率过高或违反平台规则 | 检查发送频率和内容 | 停止自动化，人工处理，等待恢复 |
| 输出消息质量不稳定 | 提示词不明确或输入资料不完整 | 检查输入 CSV 和 prompt | 增加数据清洗规则和人工审核 |
| MCP Server 端口冲突 | 多个 Server 使用了同一端口 | 查看端口占用 | 修改配置中的端口 |
| 文件读写权限不足 | 工作目录不可写 | 检查目录权限 | 使用用户目录下的项目文件夹 |
排查时优先看日志。如果日志是空的，说明 Agent 可能还没走到调用工具那一步，问题出在模型调用或 MCP 连接之前。如果日志里有明确的 timeout 或 401 错误，就按对应类型处理。
9. 最佳实践与使用建议
这类“Agent + MCP + 批量任务”项目，真正决定成败的不是模型多聪明，而是工程上是否足够稳。下面几条建议可以长期复用。
第一，第一次跑任务时，用小数据、小参数。比如先用 3 条 CSV 数据、1 个 MCP Server、0 条真实发送，跑通全链路。链路通了再逐步扩大规模。
第二，保留一套最小可运行配置。把能正常工作的 MCP 配置、prompt 模板和目录结构保存到一个模板目录里。后续换机器或者复现问题时，可以直接套用，不用重新排查环境。
第三，输入、输出、日志必须分开。不要把原始 CSV、生成草稿、运行日志混在同一个目录。每次运行前可以用时间戳生成独立文件夹，例如：
mkdir -p outputs/$(date +%Y%m%d_%H%M%S)第四，接口服务要限制访问范围。如果 MCP Server 暴露了数据库或 CRM 的写入能力，不要让 Agent 在没有审核流程的情况下直接写正式环境。建议指向测试库，或者加一个--dry-run参数。
第五，涉及用户资料、联系人信息、消息内容时，必须有授权和数据脱敏。不要用真实客户数据做公开 demo。更不要采集非公开信息用于营销。
第六，发布或商用前要做效果复核。生成的外联文案要人工检查，确认没有虚假宣传、不涉及隐私泄露，再决定是否发送。
10. 总结与下一步
回到标题：”Let Claude/Codex run actual 1000s of LinkedIn outreach with ~30 MCP tools“。从技术实现上看，Claude Code / Codex 加约 30 个 MCP 工具，确实可以把外联流程拆成多个可执行节点，并且通过 MCP 协议把搜索、分析、草稿、CRM 写入都串起来。这套思路对做销售技术、CRM 集成、AI Agent 工作流的人来说，有明确的工程参考价值。
但我也要说一句大实话：不要把“1000s”当成一次性群发上限来追求。更合理的用法是，让 Agent 帮你做前面最耗时的信息收集和草稿生成，把发送动作保留给人工审核。这样既能提升效率，又能控制风险。
如果你准备尝试，建议从以下三步开始：
- 第一步：装好 Claude Code 或 Codex CLI，配置一个最简单的 MCP Server。
- 第二步：用 3 条测试数据跑通“读 CSV -> 生成草稿 -> 保存文件”的链路。
- 第三步：加入日志和 dry-run 机制，验证批量任务的稳定性和可审计性。
在此基础上再考虑是否接入更多 MCP 工具、是否扩展成接口服务、是否对接 CRM。每一步都验证清楚，再谈规模化。
