上一篇文章—《【最佳实践】Anthropic：如何构建有效的 Agent，详述了Agentic系统中Workflow和Agent的基本模式和常见场景，本篇继续分享附录中的内容——Agentic系统实践案例与通过提示词工程使用工具。
TL;DR
适用于 Agentic 系统的场景特点
- 既包含对话又包含任务执行
- 具有明确的正确标准
- 支持反馈迭代
- 具有人工监督
Agentic系统实践应用：
- **客户支持场景：**结合对话式界面与外部工具，适用于需要获取信息、处理操作和反馈的任务，能通过明确的成功标准衡量效果。
- **编码Agent：**软件开发中使用Agent进行代码自动化验证和问题解决，通过测试结果迭代优化，确保输出质量，并依赖人工检查确保解决方案符合系统需求。
提示词工程与工具使用：
- 工具是Agent的重要组成部分，使其能与外部服务API互动。
- **优化工具格式：**使格式符合模型处理习惯，避免多余的格式复杂性。
- **经验建议：**提供足够的tokens让模型思考，优化工具定义（示例用法、边界情况等），并测试模型与工具交互的表现。
- **减少错误的工具设计：**通过优化参数和工具定义，避免模型使用中的常见错误。
原文翻译
附录 1：实践中的 Agent
我们与客户的合作揭示了 AI Agent 的两个特别有前景的应用，它们证明了上述讨论模式的实际价值。 这两个应用程序都说明了对于既需要对话又需要执行、具有明确的正确标准、支持反馈迭代以及结合有意义的人工监督的任务，如何最大地发挥 Agent 的价值。
A. 客户支持场景
客户支持场景将聊天机器人界面与通过工具集成的增强功能相结合。 这个场景很适合更开放的 Agent，因为：
- 客户支持场景很自然地遵循了对话流程，同时需要访问外部信息和操作；
- 可以通过集成工具来提取客户数据、订单历史记录和知识库文章；
- 可以以编程方式处理诸如发放退款或更新工单之类的操作；以及
- 可以通过用户定义的解决方案清楚地衡量成功。
一些公司通过基于使用情况的定价模式（仅对成功的解决方案收费）证明了这种方法的可行性，从而显示了他们对其 Agent 有效性的信心。
B. 编码 Agent
软件开发领域显示了 LLM 功能的显著潜力，其能力从代码补全发展到自主问题解决。 Agent 特别有效，因为：
- 可以通过自动化测试验证代码解决方案；
- Agent 可以使用测试结果作为反馈来迭代解决方案；
- 问题空间是明确定义的和结构化的；并且
- 可以客观地衡量输出质量。
在我们自己的实现中，Agent 现在可以在 SWE-bench Verified 基准测试中仅基于拉取请求描述来解决实际的 GitHub 问题。 然而，虽然自动化测试有助于验证功能，但人工检查对于确保解决方案符合更广泛的系统需求仍然至关重要。
附录 2：通过提示词工程使用工具
无论您构建哪个 agentic 系统，工具都可能是 Agent 的重要组成部分。工具（Tools）使 Claude 能够通过在我们的 API 中指定其确切的结构和定义来与外部服务和 API 交互。当 Claude 响应时，如果它规划使用工具，它将在 API 响应中包含一个 工具使用块（tool use block）。工具定义和说明应该与您的整体提示词一样受关注。 在这个简短的附录中，我们将介绍如何通过提示词工程使用工具。
通常有几种方法可以指定相同的操作。 例如，您可以通过编写 diff 或重写整个文件来指定文件编辑。 对于结构化输出，您可以在 Markdown 中或 JSON 中返回代码。 在软件工程中，这些差异都是表面的，并且可以从一种格式无损地转换为另一种格式。 然而，对于 LLM 来说，某些格式比其他格式难得多。 编写 diff 需要知道在编写新代码之前，代码块标题中有多少行正在更改。 在 JSON 中编写代码（与 Markdown 相比）需要额外转义换行符和引号。
我们关于决定工具格式的建议如下：
- 在模型开始执行之前，给模型足够的 tokens 来“思考”。
- 使格式接近于模型在互联网文本中自然看到的内容。
- 确保没有格式的“额外开销”，例如必须准确计算数千行代码，或字符串转义它编写的任何代码。
一条经验法则是考虑在人机交互（HCI）上花费了多少精力，并计划投入同样的精力来创建一个好的 agent-计算机交互（ACI）。 以下是一些关于如何做到这一点的想法：
- 站在模型的角度思考。 基于描述和参数，使用此工具是否显而易见，或者您还需要仔细的思考？ 如果是这样，那么对于模型来说可能也是如此。 良好的工具定义通常包括示例用法、边界情况、输入格式要求以及与其他工具的明确边界。
- 您如何更改参数名称或描述以使事情更明显？ 将此视为为团队中的初级开发人员编写一个很好的文档。 当使用许多类似的工具时，这一点尤为重要。
- 测试模型如何使用您的工具：在我们的 workbench 中运行许多示例输入，以查看模型会犯哪些错误并进行迭代。
- 让你的工具避免出错（Poka-yoke your tools）。 更改工具参数，使其更难犯错。
在为 SWE-bench 构建我们的 Agent 时，我们实际上花费了更多的时间来优化我们的工具，而不是整体的提示词。 例如，我们发现，在 Agent 删除根目录后，模型在使用相对文件路径的工具时会犯错误。 为了解决这个问题，我们将工具更改为始终需要绝对文件路径——我们发现模型完美地使用了这种方法。
感谢阅读到这里，如果这篇文章对你有所帮助，欢迎关注【算法工程笔记】公众号！
