不要把外联 Agent 直接接到社交平台：用 Tanchi 把 B2B 调研、邮件草稿与人工发送分层
给销售或开发者关系团队做自动化时，最危险的捷径往往是让 Agent 找到联系人后，立即在所有渠道发送消息。这样做看似提高了触达量，却把事实核查、文案质量、发送权限和合规风险混在一个不可回退的动作里。一次错误归属、过时职位信息，或不恰当的自动跟进，都可能伤害真实的客户关系。
Tanchi 提供了另一种边界明确的实现：这是一个可自托管的 B2B 潜客开发系统，采用 AGPL-3.0 许可证。它让 AI 在夜间完成线索搜集、研究和邮件草稿工作；人则在队列中审阅后决定是否发送。项目特别强调邮件优先：邮件是它唯一定位为可自动化的渠道；其他渠道只应由 AI 辅助起草、再由人发送。
这不是“让 Agent 替你卖货”的魔法，而是把外联过程拆成可检查的流水线。对于需要长期维护客户关系的小团队，这种拆分比多渠道自动群发更有工程价值。
先定义四个边界，而不是先写提示词
一个可靠的外联流程至少要把下面四件事分开：
- 事实来源：联系人档案中的信息应能回到对方公司网站或 LinkedIn，而不是由模型补全空白。
- 研究与决策：模型可以提出匹配理由和优先级，但不应把推测写成已知事实。
- 草稿与发送：生成邮件不等于获得发送权。发送应是一个可见、可撤销的人类决策。
- 学习信号：衡量重点应是回复和约到的会议，而不是容易失真的打开率。
Tanchi 的设计正好围绕这些边界：它会收集和研究潜客、起草外联、安排后续工作；同时把人工批准留在最终动作之前。它还把“已验证的情报”作为原则：潜客档案中的事实来自其网站或 LinkedIn，而不是无来源的填充内容。
这意味着审核者可以问出具体问题：这句个性化描述的来源是什么？为什么这个联系人属于目标 ICP？这封邮件是否真的要现在发？如果答案无法落到来源、队列或明确的人工操作上，就不应把它当作可自动化的生产流程。
用单容器先验证工作流
官方 README 提供了一个适合试用和简单自托管的单容器启动方式。它将 PostgreSQL、Redis、API 与 Web 界面装进同一镜像；首次以交互终端启动时，会引导选择 Claude 的使用方式，并可选配置 Hunter.io 与 SMTP。
docker run -it --name tanchi \ -p 8080:8080 \ -v tanchi-data:/var/lib/postgresql/data \ tanchihq/tanchi
完成向导后访问 http://localhost:8080。持久卷尤其重要：项目说明中提到，初始化配置和会话相关数据会写入数据卷，后续容器重启不应依赖一次性的交互输入。
如果要以非交互方式启动，README 给出的模式是将 Anthropic 凭据作为环境变量传入。不要把真实密钥写进 compose 文件或 Git 仓库；应通过部署平台的 secret 管理、CI 密钥或受控的环境文件注入：
docker run -d --name tanchi \
-p 8080:8080 \
-e ANTHROPIC_API_KEY="${ANTHROPIC_API_KEY}" \
-v tanchi-data:/var/lib/postgresql/data \
tanchihq/tanchi
这里要注意一个容易被忽略的默认行为：邮件验证默认关闭。若在公开域名上部署并希望启用它，README 要求同时提供邮件服务配置，例如 MAIL_SMTP_HOST 或 RESEND_API_KEY，并设置 REQUIRE_EMAIL_VERIFICATION=true。文档说明：如果开启验证却没有可用邮件服务，API 会拒绝启动，避免创建永远无法验证的账户。
从试用容器迁移到可维护部署
单容器适合确认流程，不适合直接承担生产边界。团队开始接入真实发件箱前，更合适的做法是按官方 compose 方式拆开服务：克隆仓库，复制 .env.example，补齐 ANTHROPIC_API_KEY、AUTH_SECRET、ENCRYPTION_KEY 和 POSTGRES_PASSWORD，然后构建并启动。
git clone https://github.com/tanchihq/tanchi.git cd tanchi cp .env.example .env docker compose up -d --build
随后只在受控环境中编辑 .env，填写 ANTHROPIC_API_KEY、AUTH_SECRET、ENCRYPTION_KEY 和 POSTGRES_PASSWORD；不要把该文件提交到版本库。
上线前应额外做三项人工检查。第一，选一个真实但低风险的 ICP，逐条确认档案事实的来源。第二，让审批者只审一小批草稿，检查其中是否出现模型把“可能”写成“已经”。第三，先用测试收件箱跑通发送、退订、失败重试和审计记录，再接入正式发件域名。系统自动化的是重复劳动，不是替团队跳过判断。
发送之外，还要为失败路径设计刹车
外联系统最常见的事故并不来自模型停机，而是它在“不够确定”时仍继续推进。因此，审批队列不应只有“发送”和“删除”两个按钮，还应允许把候选退回研究、标记为不匹配、暂停某个来源，或让某个域名进入冷却期。这样，审核者的反馈才会回流到下一轮筛选，而不是每次都从同一类低质量线索开始。
技术上可以把每次外联看成一条状态机：候选 → 已核查 → 草稿 → 待批准 → 已发送/已跳过。状态转换应保留操作者、时间和理由；尤其是从“待批准”进入“已发送”的转换，不能由普通的后台定时任务绕过。即使系统使用 SMTP 自动发送，也应把真正的发送权限限制到经过批准的记录，并为失败、退信和人工撤回留下独立状态。这样排查异常时，团队能区分是研究数据错误、草稿不合适、审批误操作还是投递失败。
还要避免把表面指标反向训练成垃圾输出。若系统只追求打开率，标题党、像素追踪或频繁重发都可能让数字变好，却不代表关系变好。Tanchi README 明确将回复和会议作为度量对象、不以打开率为指标；这很适合作为内部复盘的起点：每周抽样检查“回复是否与 ICP 假设一致”“被跳过的原因有哪些”“人工改写最多的是哪类事实或承诺”。模型提示词、筛选规则和审批规范应根据这些可审阅的信号调整。
对于开发团队，建议把这些状态和反馈也纳入日常运维：为审批积压设置告警，为同一域名的短期重复触达设置限流，为 SMTP 失败率和退信比例建立单独仪表盘。这样可以避免调研任务正常运行、发送端却在异常重试时悄悄放大影响。发布新的筛选规则或提示词时，先用固定的一小组历史候选进行回放，比较它改变了哪些候选的优先级、哪些草稿更容易被人工修改；确认没有明显回归后，再扩大范围。Agent 系统需要像其他生产自动化一样，拥有灰度、观测和回滚，而不是只在第一次演示时看起来流畅。
把审批队列当成产品接口
许多 Agent 项目把“有人工参与”写成一句口号；外联系统里，它应落实为一个明确接口：队列中的每条候选邮件都应能显示对象、来源、草稿、修改历史和最终决定。批准、编辑、跳过都应成为可观察的结果，而不是聊天窗口里一句“看起来可以”。
Tanchi 适合的场景是：团队已有清晰 ICP、愿意维护事实来源、外联量并不大但十分在意关系质量。它不适合拿来无差别抓取联系人或绕开社交平台规则；也不应把“AI 生成”误认为“内容已正确”。越靠近真实发送动作，越应收紧权限、保留人工批准，并把外部数据来源写清楚。
从工程角度看，最值得复用的不是某个模型提示词，而是这条控制链：有来源的研究 → 可编辑的草稿 → 人工批准的发送 → 基于回复与会议的复盘。把这四层分开，Agent 才能真正为团队节省时间，而不会把不可控风险一起自动化。