上一篇文章---《【最佳实践】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 删除根目录后，模型在使用相对文件路径的工具时会犯错误。 为了解决这个问题，我们将工具更改为始终需要绝对文件路径------我们发现模型完美地使用了这种方法。
感谢阅读到这里，如果这篇文章对你有所帮助，欢迎关注【算法工程笔记】公众号！