用 Claude Code/Codex 和30个MCP工具实现LinkedIn外联自动化

如果你关注 AI Agent 编程工具应该已经看到过 Claude Code 和 Codex CLI 这两个名字。前者来自 Anthropic后者来自 OpenAI都是能让模型在终端里读代码、改文件、执行命令的编程助手。而 MCPModel 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、zshWindows 使用 PowerShell 或 WSLClaude Code / Codex CLI二选一也可以都装API KeyClaude 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 CodeClaude 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 CLICodex CLI 是 OpenAI 推出的终端编程 Agent安装方式也以官方文档为准。以下命令仅作示例npm install -g openai/codex codex --helpCodex 通常需要登录或配置 API Key。如果启动时出现与/responses相关的报错先检查 API 地址、模型名称和网络连通性而不是急着改代码。这类问题大多是认证或模型版本不匹配造成的。如果使用的是第三方兼容服务需要在配置里指定对应的 base URL 和模型名。注意这里的 base URL 一定要来自你实际使用的服务商文档不要照搬网上来源不明的配置。4.3 配置 MCP ServersMCP 的配置文件通常是一份 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 Codeclaude在交互会话里输入请列出当前可用的 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 协议承担了“接口服务”的角色。所有外部能力都以工具形式暴露给 AgentAgent 再根据任务目标组合调用。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 配额上。CPUMCP 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 全局目录加入 PATHMCP 工具列表为空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。每一步都验证清楚再谈规模化。