假设您的产品会收到支持工单，您希望Claude为每个工单撰写回复。在构建任何东西之前，先决定要构建多少。更大规模的构建通常能获得更好的结果，但往往成本也更高，而且会让客户等待更久。
您可以发送单次请求，运行由您的代码设定顺序的多次请求组成的工作流，或者使用自行选择步骤的智能体。 从最简单的方式开始，只有当测试表明更简单的方式不够用时，才转向下一种方式。
问清楚谁来决定下一步
这三种方式的区别在于，Claude回答之后发生的事情由谁来决定。
- 对于单次请求，接下来不会发生任何事，Claude的回答就是最终结果。
- 在工作流中，由您的代码决定。它会按您事先写好的顺序发送下一次请求。
- 使用智能体时，由Claude决定。它会选择每一个下一步以及要使用哪些工具。
要在这三种方式中做出选择，首先要写下一个好结果是什么样子的。 对于支持工单，一个好的回复可能是：解答了客户的问题、遵循了您的退款政策，并且在发出之前只需要稍作编辑。写下这些之后，您就可以用它来测试最简单的方式，看看是否不够用。
您计划构建一个从已合并的拉取请求中起草发布说明的功能。您还没有开始构建任何东西。在决定要构建多少之前，您应该先写下什么？
从单次请求开始
单次请求就是一次Messages API请求，返回一个答案。除了工单内容本身，它还可以带上您的代码为该工单查找到的帮助文章，以及您认为不错的若干条过往回复，作为参考示例。对于许多功能来说，以这种方式构建的单次请求通常就足够了。
要判断单次请求对您的工单是否足够，可以用上个月的真实工单来运行它。根据您写下的"好回复"标准对每条回复评分。然后阅读不合格的回复，看看它们回答的是哪类工单。这种用真实输入、并有评分方法的测试，称为评估（eval）。
如果回复符合您写下的标准，那就上线这个单次请求方案，到此为止。如果有不符合的地方，在升级之前先改进请求的指令、文章和示例。
单次请求不够用的一个迹象是：针对一类工单的修复会让另一类工单变差。例如，您在提示中加入了退款规则，结果技术问题的回复反而变差了。当您不断地以一种修复换取另一种问题时，就该尝试工作流了。
有一个单次请求用来从已合并的拉取请求中起草发布说明。您用上个月的发布记录运行它并给每条说明评分。什么样的结果会告诉您该尝试工作流了？
当您能列出步骤时，转向工作流
一旦单次请求不够用，如果您能在第一个工单到来之前就写下各个步骤，就选择工作流。 工作流适合能清晰拆分为固定步骤的任务。
支持工单的工作流可以分两步运行：
- 第一次请求将工单归入三类之一：退款、技术问题，或一般问题。
- 您的代码发起第二次请求处理该工单，带上针对该类工单的提示和帮助文章。
现在每类工单都有自己的提示，因此对退款提示的修改不会影响到技术类回复。
将任务拆分为多次请求，还能让您看到各步骤之间产生的结果。每一步都是独立的请求，因此您可以记录它、评分它，并在下一步运行之前检查它。例如，您的代码可以检查第一次请求是否返回了三类之一，并将任何其他答案转给人工处理。
这个工作流会让客户等待更久，因为第二次请求要等到第一次完成后才能开始。您接受这种等待是为了获得更准确的回复，而测试结果必须证明您确实得到了这样的效果。
当您无法事先写下步骤时，工作流就不再适用了。例如，某个回复需要Claude先查询客户的订单，而接下来要检查什么取决于它在那里发现了什么。
只有在别无选择时才转向智能体
只有面对开放式任务时才选择智能体，即Claude必须用您提供的工具自行选择每一个下一步。开放式意味着很难甚至不可能预测任务需要多少步骤，您也无法事先写下这些步骤。
例如，一位客户写道他们的包裹从未送达。Claude先查询他们的订单记录，发现包裹寄到了一个旧地址。于是Claude接下来查阅您关于错误地址的政策文章。然后它要么发放退款，要么更新工单。
智能体成本更高，而且它的错误可能会不断累积。 让智能体变得有用的那种自主选择的自由，也让它更难测试。它可能要运行很多步，因此您需要对它的决策有一定的信任。
在选择智能体之前，先回答以下关于这项任务的问题：
- 更好的结果值得更高的成本和更长的等待吗？
- Claude擅长做这类任务吗？
- 一个错误步骤能否被发现并通过测试、审核或回滚来纠正？
如果其中任何一个问题的答案是否定的，就继续使用工作流或单次请求。对于支持工单，这意味着您要为那些能列出步骤的工单类型保留工作流，其余的则转交给人工处理。
智能体只适合那些查询和退款的顺序因工单而异的情况。由于每笔退款都由人工审批，第三个问题的答案是肯定的。
您的发布说明工作流能处理常规发布，但有些发布需要您无法事先列出的步骤。智能体会直接向客户发布,没有审核环节,也无法撤回已发布的说明。对于这些发布,您该怎么做?
在几个功能设想上试一试
在这三种方式上分别试一试每个功能设想，看看会发生什么。
接下来该做什么
在Claude上构建任何功能之前，先写下一个好结果是什么样子，从单次请求开始，只有在测试表明它不够用时才升级。 现在为您正在规划的功能做出同样的选择。要检验您的选择，说出在您的功能中由谁来决定下一步，以及哪种测试结果会促使您升级。
告诉您何时该升级的测试就是评估（eval）。接下来，学习评估简介（在新标签页中打开），在您自己的数据上构建一个小型评估。
还有两篇文章可以在您做出选择之后提供帮助。如果您的功能为Claude提供了工具，通过Messages API使用工具（在新标签页中打开）展示了如何让工具使用变得可靠、响应迅速且运行成本更低。如果您选择了智能体，什么是Claude托管智能体？（在新标签页中打开）介绍了一个托管环境，它会运行该智能体及其工具，因此这部分工作无需您自己构建。