一位销售的六个 AI 助手:从线索分配到客户跟进

把线索、邮件、会议和 CRM 串成可持续运行的日常工作流

Shahboz Ibragimov 是 Anthropic 日本团队的业务拓展代表，工作是帮助日本企业了解 Claude 怎样简化和自动化业务流程。他自己的工作起初却仍以手工处理为主：每天早晨花几个小时分配、筛选线索，再写日文或英文邮件，剩下的时间更新 CRM，记录常常落后一天甚至更久。

现在，一组名为 Nakama 的 Agent 会提前准备大部分工作。线索完成分配，客户回复进入草稿箱，Salesforce 记录按规则更新；他审核结果，并处理需要人工判断的事项。这套系统从 Claude 中的几项小任务逐步搭起，后来迁移到 Claude Managed Agents。

01先把一项工作跑通

最初的做法很简单：交给 Claude 一项工作，检查结果，改正错误，再把纠正保存下来。随着重复任务逐渐跑顺，这些工作被整理成多个 Agent，每个负责一种日常事务。

同事开始索要提示词和 Skill，希望搭建自己的流程。那时能分享的只有一个 ZIP 文件，里面是技能和几份 Markdown 知识文件。同事需要先上传到 Claude，再回答一轮设置问题，才能使用。

维护也越来越困难。Shahboz 会在手边打开的聊天中要求 Claude 调整 Agent，同一份 Skill 因而从不同会话中反复修改。他希望每个 Agent 只在一个地方定义，修改有记录，配置能够追溯。

Claude Managed Agents 是 Claude Platform 上的托管 Agent 基础设施，当时处于 Beta 阶段。文档里的调度、工具和凭据库一度让他以为需要开发者维护，但已有的 Agent 已经能工作，迁移可以从这些配置开始。

他用自然语言描述每个 Agent 的工作，由 Claude 编写几段简短的设置脚本，再在自己电脑的终端运行。部署完成后，不再需要自行照看运行基础设施。从零开始时，也可以使用 Console quickstart 中的预设模板。

02五个工作助手，一个维护协调者

这组 Agent 主要使用日语工作，因此有了日文名字，合称 Nakama，意思接近“一起工作的伙伴”。每个 Agent 只负责一项清楚的任务，出了问题也容易定位到相应环节。

Sabaki、Henji 和 Nokori 起草邮件时，都从同一知识库取用背景。协调者负责运行维护，不需要替代各个工作 Agent 的具体职责。每个工作 Agent 都有自己的调度，按时启动，完成这一轮处理后停止。

要修改工作方式，Shahboz 只需在 Nakama 的 Slack 频道用自然语言写出要求。只有他本人可以发起修改 Agent 指令和系统提示的请求，协调者读取后完成更新。

03把原型迁移到托管部署

调度与部署放在一起后，可以在 Console 中设置运行频率和时区，并同时查看 Agent 的指令与工具，不必另外维护 cron 任务。电脑关上或离线，也不会打断云端的计划运行。

某次运行出错时，可以在 Console 打开记录，逐步查看 Agent 做了什么。指令的每次调整会保存为新版本，留下带编号的历史；正在试验的版本与已部署版本分开，计划任务继续使用已部署版本，未完成的修改不会进入第二天的工作。

修改入口也收拢到一个 Slack 频道。小规模时，可以先在 Claude 中把原型跑通；当 Agent 数量和配置已经难以轻松跟踪，再迁移到统一部署环境。

04让修改变成整个团队的记忆

所有 Nakama Agent 都读写同一个 memory store。它们比较自己起草的邮件与最终发出的版本，把差异记成表达习惯和处理方式；在内部文档、官方网站查到的新信息，也会保存到知识库。

Henji 的一处措辞被改正后，Sabaki 和 Nokori 可以读取同一条记录，在后续任务中沿用。纠正不必分别写进每个 Agent 的提示，新的客户背景也能被其他任务使用。

知识库里积累的不只是静态资料，还包括过去的互动和每次修改。经过几百轮成本较低的起草、纠正和保存，邮件逐渐接近 Shahboz 自己的表达方式。

凭据放在受控的 Vault 中

Agent 需要访问邮箱和 Salesforce，但这些连接涉及客户对话与公司记录。OAuth access token、refresh token、API Key 和 personal access token 等凭据保存在 managed vaults 中。

每个 Agent 的 deployment 只连接完成工作所需的 Vault，Agent 本身看不到凭据。需要停止访问时，可以一步撤销。

05把后续事项交到 Slack 线程里

大多数结果只需要审核草稿或查看 CRM 更新。有些客户问题还需要研究升级路径、采购方式，或协调另一个团队，这时 Agent 会把待办发布到 Nakama 的 Slack 频道，并标记 @Claude。

Claude Tag 当时也处于 Beta 阶段。配置后，Claude 成为 Slack 工作区中的一个成员；在它加入的频道里，人和 Agent 都可以通过标记提出请求，后续工作就在同一个讨论线程中展开。

Claude 会读取线程，核对适用规则和条款，列出选项并起草所需内容。需要审核或签字时，它再标记 Shahboz；必须先等客户或其他团队答复的事项，则设置提醒，到指定日期重新检查。

在一个升级跟进示例中，客户希望在续费前从 Team 转到 Enterprise，并采用发票付款。Claude 需要先核对合同路径，补充续费日期和席位数量，再请 deal desk 确认合同设置。它准备客户邮件和内部工单内容，等待人工确认。

Claude 随后为周二设置提醒，检查客户是否回复、deal desk 是否处理工单。提醒到期后，它会把两边的进展写回同一线程。需要催办时，先起草消息，再标记 Shahboz 发送。

Claude 还会在早晨发布产品和价格更新简报。协调者读取简报，将需要更新的内容写进共享知识库，让后续客户回复使用新的资料。

06销售人员审核什么

例行准备工作完成后，Shahboz 把注意力放在需要人工判断的事项上。一份明确的规则手册定义每个 Agent 的职责，定价问题、敏感客户和含糊的请求会转交给他。

Henji、Sabaki 和 Nokori 的每封邮件草稿顶部都有一段简短摘要，说明当前情况。审核时，不必从头追完整个线程，可以先读摘要，确认背景，再修改正文并发送。

邮件示例中的客户为 40 人团队比较 Team 与 Enterprise，并提到上线前的安全审查。摘要列出对话进展、建议方向和资料依据，价格有意留空；正文提出下一步沟通。摘要是给审核者看的背景，不会作为客户邮件的一部分发送。

按每周任务日志，把每项已完成工作折算成他原本手工处理所需的时间，Nakama 完成的任务合计约为 60 小时人工工作量。腾出的精力用于客户对话、主动拓客策略、跨团队项目，以及帮助同事搭建自己的 Agent 工作流。

07按职责和频率选择模型

定时任务每天都会运行，细小的浪费会不断累积。常见问题包括：新要求只往指令末尾追加，旧要求没有更新；上下文超过任务所需；所有任务都使用最大的模型和最高 effort。

单一职责可以让指令保持聚焦，计划运行则让 Agent 做完一轮就停止，共享记忆让一次纠正被多处复用。模型选择还需要结合任务的判断难度与运行频率。

Henji 怎样向更强的模型请教

Henji 对判断能力的需求与 Sabaki 接近，但整天都要处理新邮件。如果每次都运行 Opus，它会成为最昂贵的一项。advisor strategy 让 Henji 使用 Sonnet 执行完整任务，遇到无法独立决定的问题时，再向 Opus 请教。

Opus 阅读 Henji 已经完成的工作，返回计划、纠正建议或停止信号。随后由 Henji 继续处理，完成放入草稿箱的回复，等待人工审核。Opus 在这个流程中提供建议，最终草稿仍由执行者完成。

模型和 effort 分别设置。effort 控制模型回答前投入多少推理，可以按 Agent 单独调整；只有推理确实困难的任务，例如 Henji 的客户回复，才提高 effort。

08从一次描述，积累成可复用的工作方式

开始时可以只选一件重复工作，用自然语言说清任务，让 Claude 起草，改正其中的问题，再保存纠正。后续任务沿用这些记录，不必每次重新写一份很长的提示。

知识库的持续积累比不断加长提示更有用。每次修改和过去的互动，都放到所有相关 Agent 可以读取的位置，通过小范围迭代逐渐积累业务背景和表达习惯。

Shahboz 最初还亲自维护知识库，手动修改各个 Agent 的指令。后来，这些工作也逐步交给 Agent：工作助手保存新知识，协调者根据授权的自然语言请求更新指令。他仍决定要改变什么，并审核需要自己判断的客户沟通。

已有流程可以先在 Claude 中试运行。需要统一管理调度、工具、凭据和版本时，再迁移到 Managed Agents；Console quickstart 提供现成模板，已有工作流则可以整理配置后部署。