Anthropic 日本业务拓展代表如何用 Claude Managed Agents 安排日常工作

作为 Anthropic 日本团队的一名业务发展代表，我的工作是向日本公司展示 Claude 如何简化并自动化他们的工作流程，但直到今年早些时候，我自己的大多数流程仍然是手动的。每天早上，我都要花上几个小时来分配并筛选销售线索，然后用日语或英语写邮件。剩下的时间里，我还要更新我们的 CRM，而且往往会滞后一天甚至更久。现在，我的 agents 会在我开始一天工作之前准备好其中的大部分内容，而我只需要进行审核。

我构建的第一个由 Claude 驱动的工作流程相当粗糙，但它确实完成了任务。我一次把自己工作中的一个部分交给 Claude，纠正它出错的地方，并保存这些修改。随着时间推移，这发展成了几个 agents，每个负责一种不同的例行工作。

消息很快传开，队友们开始向我索要我的提示词和技能，以便他们构建自己的版本。而我能发给他们的，只有一个包含我的技能和知识库中几个 Markdown 文件的 zip 文件，他们必须把这些上传到 Claude，然后再回答一轮设置问题，之后一切才能运作起来。连我自己的配置也越来越难追踪。每个 agent 都由一个技能、一个定时任务和一个共享文件夹组成，而我又是在手头随便哪个打开的聊天里让 Claude 去修改它们，所以同一个技能会在很多不同的对话中被编辑。

我想只在一个地方定义每个 agent 一次，并且能够看到我对它做出的每一次更改。所以我决定试试 Claude Managed Agents（在新标签页中打开）（测试版），这是我们在 Claude Platform 上的托管 agent 基础设施。

一开始我对尝试它有些犹豫。文档里谈到了调度、工具和凭证保管库，而我是做销售的，所以我原以为 Managed Agents 是给那些能够构建并维护所需基础设施的开发者使用的。不过我还是试了试，因为我的 agents 本来就已经存在，我只需要把它们迁移过去。

结果证明，我并不需要成为开发者。我用通俗的语言描述了每个 agent 的工作，Claude 写了几个简短的设置脚本，而我就在自己笔记本电脑的终端里运行它们。（如果你是从零开始，Console 里也有一个带现成 agent 模板的 快速入门。）从那以后，就再也没有什么基础设施需要我来照看了。

在这篇文章里，我会介绍我是如何设计并制作这组 agents 原型的，为什么我把它迁移到了 Managed Agents，Claude Tag 如何接住任何落在例行流程之外的事情，这一切怎样改变了我的一周，以及我会对那些想构建自己的 agents 来自动化手动、重复性工作流程的销售人员说些什么。

设计我的 agent 编队

我把自己的工作流程拆分给了多个 agents，并给每个 agent 只分配了一项明确的工作。单一职责让每个 agent 都更容易理解，也更容易追踪，尤其是在出现问题的时候。我还给每个 agent 都起了一个日文名字，因为它们大多用日语工作。合在一起，它们被称为 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 上，我在 Console 中设置执行频率和时区，就在已部署代理的说明和工具旁边，而且我不需要另外维护任何 cron 作业。如果某次运行出了问题，我可以在 Console 里打开它，查看代理执行的每一步。而且当我在试验对某个代理的改动时，定时运行仍会继续使用已部署的版本，所以未完成一半的编辑不会跑进明天的运行中。

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

每个代理都会读取和写入同一个记忆存储（在新标签页中打开），因此任何代理都可以利用其他代理的学习成果。代理会把它们写出的草稿与我实际发送的邮件进行比较，并把每一处差异都保存为一条关于我会如何表述的备注。它们还会保存在研究答案时挖掘到的任何新信息，来源包括我们的内部文档和我们的官方网站。我只要在 Henji 的草稿里修正一次措辞，Sabaki 和 Nokori 就不会再犯同样的错误。

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

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

把后续步骤交给 Claude Tag

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

对于这些情况，代理不会停下来等我。它们会把事项交给Claude Tag（在新标签页中打开）（测试版）。Claude Tag 是被设置为我们 Slack 工作区成员的 Claude：任何在它已加入的频道里的人，无论是某个人还是我的某个代理，都可以用请求 @Claude，它就会接手这个请求并在线程中处理。一旦它在你的工作区中配置好，就没有任何新东西需要学习。你 @Claude 的方式，就和 @ 一位同事一样。

在我的设置中，它是这样运作的。某个代理会把行动项发到 Nakama 的 Slack 频道里并 @Claude。Claude 会读取该线程，检查我们的规则和适用条款，列出可选方案，并起草所需内容。当某个步骤需要我审核或批准时，它会 @我。当需要先等客户或另一个团队回复时，Claude 会为自己设置提醒，在指定日期回头检查。在下面的线程里，它设置了周二的提醒，以检查客户是否已经回复，以及 deal desk 是否已经答复了工单。到提醒时间时，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 的回复时。

我学到的东西

有三点经验，我想分享给任何正在搭建自己智能体编队的人。

1. 你不需要每次都写一个非常详细的提示词。 把工作描述一次，让 Claude 起草，修正草稿，再让它记住这次修正。
2. 知识库比提示词更重要。 每一次修正和过往互动都会被保存到所有智能体都能读取和写入的地方，因此 Claude 会从那里而不是从更长的提示词中获取上下文。为了让草稿听起来像我本人，我经历了几百轮低成本的起草、修正和保存。
3. 更早地给 Claude 更多空间。 一开始，我一直在做那些我以为需要我亲自处理的任务：更新知识库，或者手动编辑每个 agent 的指令。一旦我放手，这两件事都运转得很好。现在，agents 会自己把学到的内容写入知识库，而当我用通俗英语提出要求时，协调者会更新其他 agents 的指令。对于那些我本可以信任 agents 去完成的工作，我之前一直过于谨慎。

开始使用 Claude Managed Agents（在新标签页中打开）