用 Agent 做领英外联：私信它来处理，沟通记录留在 Busabase

有人第一次听说时很意外：Busabase 还能用来做 LinkedIn？

能。而且这可能是它最被低估的用法之一。销售和客户沟通每天都在 LinkedIn 上发生：加人、破冰、跟进、答疑、约会议。这些对话躺在某个人的账号收件箱里，团队看不见，老板问起来只能凭记忆复述；换一个 Agent 来帮忙，它读不到上文，你还得把背景重新讲一遍。

问题不在渠道，在记录。LinkedIn 负责对话，但它不是为团队留档设计的。这篇文章讲一套可照着搭的工作法：让 Agent 在聊天里处理私信——读消息、分类、起草；你审批；批准后它发送并把结果写回 Busabase；你的每一次审批意见，沉淀成一张经验表，供下一轮起草前先读。 一边聊，一边审，一边办，记录和经验同时长出来。

下面给出完整的表结构、字段、提示词和日常节奏。示例人物与对话均为虚构，标注为示例。

先分清三件事：渠道、Agent、记录

• 渠道是 LinkedIn（也可以扩展到 WhatsApp、邮件等）。对话发生在那里，这是事实。
• Agent是执行者。你在用的 Claude Code、Codex 或其他已接入的 Agent，在聊天窗口里读消息、起草、发送、汇报。
• 记录在 Busabase。谁联系过、聊到哪一步、你批过什么、下一步谁负责——只认记录，不认某个人的记忆或某个 Agent 的上下文。

Busabase 是 The System of Record for AI Agents：records（结构化记录）、docs（口径与标准）、skills（可复用的方法）、apps（给人看的界面）装在一个 base 里，Agent 通过 MCP / API / CLI 读写，关键写入以 Change Request 的形式留下 diff、提交者和批准人。换 Agent，记录不动；换人接手，打开表就知道前因后果。

你需要什么：两个现成模板，加五张表

不用从零建。先从模板库复制两个现成的：

• Busa CRM：公司、联系人、商机和互动记录的骨架，「Agent 记录每一次触达，并起草下一次跟进」；
• Busa Sales Outreach：产品定位、ICP、目标公司、联系人和个性化首触达。

再新建一个文件夹，比如叫 LinkedIn 销售台，放五张表和两个节点。五张表是本文的核心——消息进、回复出、事情办、经验留，联系人是枢纽。

这套台子现在有现成模板了：Busa LinkedIn Desk——五张表、作业 Skill 和待审批台打成一个可安装的包，不想从零拼可以直接装。

1）联系人表 Contacts

2）消息表 Messages：一行一条消息，一切的入口

3）回复表 Replies：一行一份拟回复，审批发生在这里

4）处理表 Actions：回复之外的事，一行一件

其中「更新 CRM 字段」比较特殊：阶段、金额这类字段不要直改，走 Change Request 提案，把原值、候选值和来源摆出来给人判断——本站另一篇文章《AI 更新 CRM，应该把哪些变化交给人判断？》专门讲这层治理，本文不重复。

5）经验表 Experience：一行一条经验，自我进化的载体

再配两个节点：**Doc「ICP 与话术口径」**放人的标准——目标客户定义、可说与不可说、价格与承诺的红线、什么情况必须升级；**Skill「LinkedIn 外联作业」**放 Agent 的方法——分诊规则、跟进节奏、去重键、发送前检查单、写回规范。

方法论：聊 · 审 · 办 · 记 · 学

表是骨架，跑法是这五步循环。它在本站《用 Busabase 搭建自我改进的智能体》提出的「观察 → 决策 → 行动」之上，补了对销售场景最关键的两步：记，和学。

聊。 一切从 Agent 聊天开始，也回到聊天。定时 Agent 读新消息、带回提案；你在这里下指令、看汇报。不用为了查一条记录去翻收件箱，也不用打开五张表逐个看——表是给记录用的，聊天是给人用的。

审。 你对每份草稿只有三种动作：同意；改后发；驳回并说明原因。请注意，这三种动作本身就是标注：同意，是正例，告诉它这类情况这样写是对的；改后发，是最有价值的一种——你改的那几处差异，就是你的标准本身；驳回加原因，是负例和禁区，它下次不会再犯。审批不是额外负担，审批就是在教它。

办。 批准之后才执行：发送回复、建跟进、约会议、发资料。价格、承诺、时间表这类事项不办，直接在处理表里升级给人。发送失败就停下来报告，不许换个说法自行重试。

记。 每一步都写回：消息按 ID 去重落表，回复的草稿、审批、发送版本都在回复表，事情的进展在处理表。判定标准只有一条：下次打开表，能不能不看聊天记录就把来龙去脉讲清楚。

学。 每一轮结束，Agent 把审批意见整理成候选经验写进经验表，附来源记录。周复盘时你逐条确认：采纳的，状态改「已采纳」，Agent 下一轮起草前必须先读；反复验证成立的，经 Change Request 晋升写进 Skill，留下 diff、你的名字和批准记录；不成立的，标「已废止」而不是删掉——知道什么不行，也是经验。

这就是自我进化在销售台上的具体形态：不是模型自己变聪明了，而是团队的标准被一条条存下来、被下一轮真实地读到。

一条消息的旅程（示例）

周一上午，物流公司的运营负责人 Alex 在 LinkedIn 上回复了你的破冰消息（示例对话）：

能私有化部署吗？我们的数据不能出内网。

1. 09:15，分诊轮。 Agent 读到这条消息，按主页 URL 在联系人表匹配到 Alex，在消息表落一条记录：意图 = 咨询，紧急度 = 高，处理状态 = 已分诊。
2. 起草。 它先读口径 Doc 和经验表里「已采纳」的条目，再起草回复——答可行性、给部署周期、约一个电话细谈——写进回复表，状态 = 待审批，并把提案带回聊天。
3. 09:40，你审批。 你在聊天里回：「方向对。补一句部署周期，别承诺上线日期。」——改后批准。你的原话进了回复表的审批意见。
4. 发送与写回。 Agent 按修改后的版本发送，回填发送正文、发送时间和发送消息 ID，消息表同步多一条「发 ...[truncated 8487 chars]出」记录，回复表状态改为已发送；同时在处理表里建一条「给 Alex 发送部署资料」，到期周三。
5. 当晚，沉淀经验。 这一轮结束时，Agent 把你的审批意见整理成一条候选经验写进经验表：「咨询部署时，先答可行性和周期，上线日期不承诺」，来源记录指向这条回复。周五复盘，你把它确认成「已采纳」。

两周后打开这张表，你看到的不只是「聊过了」：他问了什么、你批了什么、实际发了什么、下一步在谁手里、系统学到了什么——全在。这就是「审批即教学」的样子。

提示词包：四段可改用的指令

方法要落地，靠的是给 Agent 的指令写清楚。下面四段对应四个环节，尖括号里换成你的口径就能用。

P0 · 建台（一次性）

在我的 Busabase 里新建文件夹「LinkedIn 销售台」。联系人、公司、商机先引用 Busa CRM 的现有表，再建四张新表：消息表（线程 ID、消息 ID、联系人关联、方向、渠道、时间、原文、意图、紧急度、处理状态）、回复表（针对消息、草稿正文、版本、审批状态、审批人、审批意见、发送正文、发送时间、发送消息 ID、后续结果）、处理表（类型、来源关联、负责人、到期日、状态、完成结果、证据链接）、经验表（标题、类型、来源记录、审批原话、适用范围、反例与边界、状态、晋升去向、最近验证）。再建 Doc「ICP 与话术口径」骨架（ICP、可说与不可说、价格与承诺红线、升级规则，先留空等我填）和 Skill「LinkedIn 外联作业」骨架。先给结构，不填任何客户数据，建完把结构列给我核对。

P1 · 每日分诊（定时）

读今天的新 LinkedIn 对话（来源：〈我贴给你的导出 / 已连接的通道〉）。逐条处理：用主页 URL 在联系人表对人，对不上就建候选并标「未核验」；按消息 ID 去重写进消息表，分类意图（有意向 / 异议 / 转介 / 现在不要 / 找错人 / 拒绝 / 咨询 / 其它）和紧急度；对「有意向」和「咨询」的，先读口径 Doc 与经验表「已采纳」条目，再起草回复写进回复表（状态 = 待审批）；把待审批清单和每份草稿的依据带回这个聊天。不要发送任何东西，等我逐份审批。 涉价格、承诺、时间的，不要起草，直接在处理表建「升级人工」。

P2 · 批准后执行

按我刚批准的版本发送这份回复（回复表记录 ID：〈…〉）。发送成功后回填：发送正文、发送时间、发送消息 ID，并在消息表补一条「发出」记录；按草稿里约定的下一步，在处理表建好跟进（负责人与到期日照约定）。发送失败就停下来报告原因，不要换个说法自行重试。

P3 · 周复盘（每周一次）

汇总本周回复表与处理表：一次通过几份、改后发几份、驳回几份及原因；把审批意见整理成候选经验（每条附来源记录与审批原话），列给我逐条定性；对我确认「已采纳」且本周再次验证成立的，给出晋升写进「LinkedIn 外联作业」Skill 的修改草案（diff 形式），等我确认后再走 Change Request 提交。

日常节奏：每天做决定，每周学一次

每日一轮。 定时 Agent 在约定时间跑分诊：读新消息、落表、分类、为「有意向 / 咨询」起草，然后在聊天里给你一份日报——新消息几条、待审批几份、哪些线程停滞超过阈值、昨日跟进的结果如何。你在聊天里逐份处理：批、改、驳、升级。日报不是看的，是拿来做决定的。

每周一次复盘。 把这周的回复表和处理表过一遍：哪些草稿一次通过、哪些被改、哪些被驳回；候选经验逐条定性——采纳、继续观察、废止；对反复验证成立的经验，发起把要点写进「LinkedIn 外联作业」Skill 的 Change Request 提案，diff、提交者、批准人俱全。晋升完成后，经验表里那条标「已晋升 Skill」并留下链接。

节奏的要点是把人的时间花在判断上：读消息、写草稿、填表、汇总这些事 Agent 做；定标准、批内容、作承诺，人来做。

场景速览

边界，先说清

• 平台条款与账号风险是真的。 LinkedIn 的用户协议对自动化访问并不友好，账号被限制的先例不少。对策是：量保持在真人节奏、先用手工喂料跑通、获批后才发送、永远不把任何连接器当作平台许可。
• 发送量有上限。 邀请与消息的平台配额是设计约束，Skill 里的节奏规则要把 Agent 摁在配额之内。
• 隐私最小化。 只存复核所需的摘录与受控引用，不把整段敏感对话复制得到处都是；示例永远用虚构数据。
• 草稿 ≠ 已发送，提案 ≠ 已合并。 状态字段和发送消息 ID 就是这条线：没有 ID 写回，就不算发生过。

常见问题

不用 Unipile 这类工具，能跑吗？ 能。先手工喂料，让 Agent 做分诊、起草和记录——五张表、审批闭环、经验复盘都不依赖连接器。等「取消息」成为瓶颈，再接消息 API。

Agent 能自己发消息吗？ 技术上经消息通道可以，正因如此本文默认先审批。常规草稿积累足够多正例后，可以给它更宽的常设授权；但价格、承诺、日期永远留给人，聊天里的一句「好」只在范围明确时才算数。

这和 CRM 有什么区别？ 它就从 CRM 长出来：Busa CRM 已经管公司、联系人和商机。销售台补的是 Agent 作业层——每段对话是一条记录、每次发送之前有一次可查的审批、你的审批意见被留存为经验。

同一段对话会不会被记两遍？ 这正是消息 ID 去重键的用途。写消息表之前先查这个键，已有就更新那一行，不新建。

开始：先把记录立起来，再把 Agent 接进来

从模板库复制 Busa CRM 和 Busa Sales Outreach，照本文加上五张表和四个提示词，手工跑通一轮：一份名单、几份草稿、你的审批、写回、第一批候选经验。当这套循环跑顺了，再接消息通道，让每日分诊自己取数。

这套台子已经打包成现成模板上线了——Busa LinkedIn Desk：五张表、作业 Skill 和待审批台都在里面，模板页上还有演示视频可看。不过你亲手搭出来的这一版大概率更合用：里面装的是你的 ICP、你的红线，和写在你自己审批意见里的经验。