Anthropic 日本 BDR 如何用一队 Claude 智能体处理日常工作

一位业务拓展代表如何用 Claude Managed Agents 和 Claude Tag 清空自己的入站队列，并起草双语客户邮件。

类别：最佳实践

产品：Claude Managed Agents

作为 Anthropic 日本团队的一名业务拓展代表，我的工作是向日本企业展示 Claude 如何简化和自动化他们的工作流程，但直到今年早些时候，我的大部分工作仍然是手工完成的。我每天早上要花几个小时分流和筛选线索，然后用日语或英语写邮件。在剩下的时间里，我更新 CRM，通常落后一天甚至更久。现在，我的智能体在我一天开始之前就完成了大部分工作，我只需审核。

我搭建的第一个由 Claude 运行的工作流程相当粗糙，但它管用。我一次把一项工作交给 Claude，纠正它做错的地方，并把这些纠正保存下来。随着时间推移，这发展成了几个智能体，每个负责一项不同的例行工作。

消息很快传开了，同事们开始向我要我的提示词和技能，以便搭建自己的智能体。我能发给他们的只有一个压缩包，里面是我的技能和知识库中的几个 Markdown 文件，他们必须把文件上传到 Claude，然后回答一轮设置问题，才能让一切运转起来。我自己的配置也越来越难以管理。每个智能体都是一个技能、一个定时任务和一个共享文件夹，而我是在当时打开的任何聊天里让 Claude 修改它们，所以同一个技能会在许多不同的对话中被编辑。

我希望每个智能体只在一个地方定义一次，并且能够看到我对它做过的每一次修改。于是我决定试试 Claude Managed Agents（在新标签页中打开）（beta），这是我们在 Claude 平台上的托管智能体基础设施。

一开始我犹豫要不要尝试。文档里讲的是计划、工具和凭据保险库，而我是销售代表，所以我以为 Managed Agents 是给能够搭建和维护必要基础设施的开发者用的。我还是试了，因为我的智能体已经存在，我只需要把它们迁移过去。

结果发现我并不需要成为开发者。我用平实的语言描述每个智能体的工作，Claude 写了几个简短的设置脚本，我在笔记本电脑的终端里运行它们。（如果你从零开始，控制台也有一个快速入门，提供现成的智能体模板。）从那以后，我再没有什么基础设施需要照看。

在这篇文章中，我将介绍我如何设计和制作这支智能体团队的原型、为什么把它迁移到 Managed Agents、Claude Tag 如何接手任何超出例行范围的事情、这一切如何改变了我的每周工作，以及我会对那些想搭建自己的智能体来自动化人工、重复性工作流程的销售人员说些什么。

设计我的智能体团队

我把我的工作流程拆分到几个智能体上，并给每个智能体一项明确的职责。单一职责让每个智能体都容易理解、容易追踪，尤其是在出问题的时候。我还给每个智能体起了日语名字，因为它们主要用日语工作。它们合在一起被称为 Nakama，即“伙伴们”，或者更字面地说，是与你共事的同伴：

Furiwake（“分拣”）最先启动：它读取每日入站队列，把每条线索分派给团队中合适的代表，平衡线索数量和每条线索的优先级，并查看当天谁在岗，这样在我们任何人开始一天之前，每条线索都有了负责人。每次运行结束时，它会向一个专门的 Slack 频道发布报告（所有进来的线索、所有已分派的线索），以便我跟踪交接情况。

Sabaki（“处理”）对分派给我的线索进行筛选：它判定每条线索的资格，按照预设标准对其进行分类，为该类别采取既定的下一步行动（起草一封回复，引导他们使用自助服务；或撰写一封定制化的首封邮件），更新 Salesforce 中的线索记录，并起草首次接触邮件。它从 Nakama 的共享知识库中获取草稿内容，这是一个每个智能体都会读写的记忆存储（在新标签页中打开）（详见下文）。

Henji（“回复”）每小时扫描我的收件箱，找出需要回复的客户邮件，并根据邮件线程用日语或英语准备一封回复草稿，所用知识库与 Sabaki 相同。我可以审核、编辑并发送草稿。

Shoudan（“机会”）读取近期的客户互动，并把更新推送到 Salesforce，这样商机记录无需手动录入数据就能保持最新。

Nokori（“剩余事项”）在一天结束时运行：它扫描我的日历，读取附带的会议记录，总结每次会议，并起草后续跟进邮件，同样基于同一个知识库。

每个智能体都按计划运行。第六个智能体是 Nakama 的协调者，它是这支团队的运营经理。它在各次运行之间更新智能体的指令和共享知识库。当我想改变某个智能体的工作方式时，我会在 Nakama 的 Slack 频道里用平实的语言写下我的要求。只有我才能发布修改智能体指令和系统提示词的请求。协调者大约每 15 分钟检查一次该频道，接收请求并完成更新。

在 Claude 中制作这支智能体团队的原型

你不需要 Managed Agents 就能开始。我先在 Claude 中制作了整支团队的原型，使用了以下组件：

每个智能体一个技能：一项工作的指令。

为每个技能设置一个定时任务，这样我就不需要手动运行它了。

我笔记本电脑上的一个共享文件夹作为知识库，每个技能都会把学到的东西写回其中：它起草的内容与我实际发送的内容之间的差异，以及它在这个过程中挖掘到的任何新信息。

在 Managed Agents 上，技能变成了智能体的系统提示词，定时任务变成了智能体部署上的计划（在新标签页中打开），共享文件夹变成了记忆存储。我仍然用平实的语言提出修改要求，但现在我都在一个 Slack 频道里完成，而且对智能体指令的每次修改都会保存为新版本，因此每个智能体都保有一份带编号的指令历史记录。我建议先从 Claude 开始，等你管理的智能体多到难以轻松跟踪时，再把它们迁移到 Managed Agents。

在 Claude Managed Agents 上运行这支智能体团队

在 Managed Agents 上，有三件事对我的工作流最重要：

智能体可以在后台运行

无论我的笔记本电脑是否打开，甚至离线时，智能体都会按计划运行。计划是每个智能体部署的一部分。我也可以在 Claude 中为技能安排计划，但那些计划都是在自己的应用里设置的任务。在 Managed Agents 上，我在控制台中设置运行频率和时区，就在已部署智能体的指令和工具旁边，而且我不需要在旁边维护任何 cron 任务。如果某次运行出了问题，我可以在控制台中打开它，查看智能体采取的每一步。当我在试用对某个智能体的修改时，计划运行会继续使用已部署的版本，因此半成品修改不会出现在明天的运行中。

Nakama 共享一个记忆，并从我的修改中学习

每个智能体都读写同一个记忆存储（在新标签页中打开），因此任何智能体都可以利用其他智能体的学习成果。智能体会将它们起草的邮件与我实际发送的邮件进行比较，并把每一处差异保存为关于我会如何措辞的笔记。它们还会保留在回答问题时研究到的新信息，无论是来自我们的内部文档还是我们的官方网站。我在 Henji 的草稿中修正一次措辞，Sabaki 和 Nokori 就不会再犯同样的错误。

凭据存放在具有范围权限的托管保险库中

我的智能体可以访问我的电子邮件和我们的 Salesforce 记录，但由于这些是客户对话和公司记录，我希望这种访问受到控制。凭据存放在托管保险库（在新标签页中打开）中，它保护智能体用于登录外部服务的凭据，例如 OAuth 访问令牌和刷新令牌、API 密钥以及个人访问令牌。每个智能体的部署只使用其工作所需的保险库，它永远看不到凭据，而且我可以一步撤销访问权限。

把后续步骤交给 Claude Tag

对于 Nakama 产出的大部分内容，我只需要在收件箱里读一份草稿并发送，或者看一眼更新后的 Salesforce 记录。但有些事项需要后续步骤，例如确定升级路径或采购途径，或者把问题上报给另一个团队。

对于这些事项，智能体不会停下来等我。它们会把事项交给 Claude Tag（在新标签页中打开）（测试版）。Claude Tag 是作为我们 Slack 工作区成员设置的 Claude：它已加入的频道中的任何人，无论是人还是我的某个智能体，都可以 @Claude 提出请求，它会接收请求并在该线程中处理。一旦在你的工作区中配置好，就没有什么新东西要学了。你像 @ 一位同事那样 @ Claude 就行。

在我的设置中，它的运作方式是这样的。一个智能体把行动项发布到 Nakama 的 Slack 频道并 @Claude。Claude 读取该线程，核对我们的规则和适用的条款，列出各种选项，并起草所需内容。当某个步骤需要我审核或签批时，它会 @我。当需要客户或其他团队先回复时，Claude 会给自己设一个提醒，在指定的日子回来查看。在下面的线程中，它设了一个周二的提醒，用来查看客户是否已回复、交易台是否已答复工单。提醒到期时，Claude 会核查这两项，并在同一线程中发布进展。如果需要提醒某人，它会起草消息并 @我去发送。

Claude 还会发布一份关于产品和定价更新的晨间简报。Nakama 协调员会接收这份简报，并把必要的变更写入共享知识库。

我这一周的变化

既然 Claude 能在（基本上）没有我手动输入的情况下准备入站回复并保持 CRM 记录最新，我的角色就是审核任何需要人类判断的事项。一份书面规则手册界定了每个智能体的职责范围，而定价问题、敏感账户或含糊请求之类的事项会转交给我。来自 Henji、Sabaki 或 Nokori 的每封邮件草稿顶部都附有一段简短摘要，说明当前情况，因此我不必追溯整个线程就能了解背景：我读摘要、确认、修改，然后发送。

查看 Nakama 每周完成事项的日志，并把每项任务按我手动完成所需的时间计算，这支智能体团队每周为我节省约 60 小时的工作。我把腾出的时间用在智能体（目前）还无法有效完成的工作上：与客户交谈、外呼策略、跨职能项目，以及帮助队友搭建他们自己的智能体团队。

设计更高效的智能体

按计划运行的智能体每天都会运行，无论我是否在关注，因此浪费会在成本和可靠性上累积。一些最常见的错误包括：在现有指令上追加而不是更新指令、给智能体提供超出其任务所需的上下文，以及用最大的模型、最高的努力级别来运行每一项任务。

让智能体保持高效的主要因素在于我如何设计这支团队：每个智能体只负责一项工作，因此其指令始终聚焦于该工作；每个工作智能体按计划运行，因此它醒来、完成一轮工作，然后停止；智能体共享记忆，因此一次修正会在所有地方复用。

另一个重要因素是每个智能体运行在哪个模型上。一旦智能体的职责被清晰定义，它可能并不需要我们最强大的模型。Furiwake 和 Shoudan 遵循一份书面规则手册，因此它们运行在较小的 Sonnet 模型上。Sabaki、Nokori 和协调员运行在较大的 Opus 模型上，因为它们的工作需要更多判断力。协调员最需要它，因为它会编辑其他智能体的指令，而一次糟糕的编辑会波及每一个智能体。Henji 需要和 Sabaki 一样多的判断力，因为每位客户的邮件都各不相同，但它运行的频率也比任何其他智能体都高，贯穿整个工作日。每次都让它运行在 Opus 上会是最昂贵的选择，所以我在 Managed Agents 中采用了顾问策略（在新标签页中打开）：Henji 运行在 Sonnet 上，当它遇到自己无法独自做出的决定时，它会向 Opus 寻求建议。顾问会阅读 Henji 到目前为止所做的工作，并发回一个计划、一处纠正或一个停止信号，然后 Henji 完成草稿供我审阅。我还为每个智能体单独设置努力级别（模型在回答前思考多长时间），与模型分开，并且只在推理困难的地方调高它，比如 Henji 的回复。

我学到了什么

有三件事我想传递给任何正在搭建自己智能体团队的人。

你不需要每次都写详细的提示词。把工作描述一次，让 Claude 起草，修正草稿，然后让它保留修正。

知识库比提示词更重要。每一次纠正和过去的交互都会保存在所有智能体都能读取和写入的地方，因此 Claude 从那里获取上下文，而不是从更长的提示词中获取。经过几百轮低成本的起草、修正和保存，草稿才听起来像我。

尽早给 Claude 更多空间。起初我一直做着那些我以为需要我亲自处理的任务：更新知识库，或者手动编辑每个智能体的指令。一旦我放手，这两件事都运转良好。现在智能体自己把它们学到的东西写入知识库，而当我用平实的英语提出要求时，协调员会更新其他智能体的指令。对于我可以放心交给智能体去做的工作，我之前过于谨慎了。

相关文章

探索更多面向使用 Claude 构建的团队的产品新闻和最佳实践。

构建高效的智能体自动化

一份关于定时 Claude Managed Agents 自动化的参考实现演练，包含配置文件和避免常见失败模式的六条规则。

用 Claude 自动化评估设计与爬山优化

设计评估并针对它们进行爬山优化而不自欺欺人的原则，以及 claude-api 技能的 build-eval 和 hillclimb 命令如何将它们付诸实践。

云端的 Claude Code：云会话实战指南

当 Claude Code 运行在自己的机器上时会发生什么变化、哪些工作流能从中获益，以及如何一次成功连接 GitHub。

Cresta 如何在 Claude Agent SDK 上把 CX 专业知识转化为智能体构建器

了解 Cresta 如何在 Claude Agent SDK 上构建 Conductor——一个能构建其他智能体的智能体，以及团队如何在每个新的 Claude 模型上评估它。

用 Claude 变革你的组织运作方式

产品更新、操作指南、社区聚焦等。每月发送到你的收件箱。

负责任披露政策

数据处理协议：美国 K-12

负责任披露政策

数据处理协议：美国 K-12