Building effective agents

type

status

date

slug

summary

Building effective agents

在过去的一年里，我们与多个行业的数十个团队合作，共同构建大型语言模型（LLM）代理。我们发现，最成功的实现方式往往并不依赖复杂的框架或专门的库。相反，它们采用的是简单且可组合的模式。

在这篇文章中，我们将分享与客户合作及自主构建代理的经验，并为开发者提供构建高效代理的实用建议。

什么是代理？

“代理”（Agent）可以有多种定义。一些客户将代理定义为完全自主的系统，这些系统可以在较长时间内独立运行，利用各种工具来完成复杂任务。另一些客户则将代理描述为遵循预定义工作流的更具规范性的实现方式。

在 Anthropic，我们将这些不同的实现方式统称为 代理系统（agentic systems），但在架构上，我们对 工作流（workflows） 和 代理（agents） 进行了重要区分：

工作流 是指通过预定义的代码路径协调 LLM 和工具的系统。

代理则是指 LLM 动态地管理自身的流程和工具使用方式，控制任务的执行方式。

接下来，我们将详细探讨这两种类型的代理系统。在 附录 1（“实践中的代理”） 中，我们将介绍两个客户在实际应用中发现代理系统价值的领域。

何时（以及何时不）使用代理

在构建基于 LLM 的应用程序时，我们建议尽可能寻找最简单的解决方案，并仅在必要时增加复杂性。这意味着在许多情况下，可能根本不需要构建代理系统。代理系统通常会以更高的延迟和成本换取更好的任务执行能力，因此你需要权衡这种取舍是否值得。

当任务的复杂性增加时，工作流 适用于需要可预测性和一致性的明确任务，而代理则更适用于需要灵活性和基于模型的决策的大规模应用。然而，对于许多应用而言，通过 检索增强（retrieval） 和 上下文示例（in-context examples） 来优化单次 LLM 调用通常就已经足够了。

何时以及如何使用框架

有许多框架可以简化代理系统的实现，包括：

LangGraph（来自 LangChain）

Amazon Bedrock 的 AI Agent 框架

Rivet（一个可视化拖放式 GUI LLM 工作流构建工具）

Vellum（另一个用于构建和测试复杂工作流的 GUI 工具）

这些框架可以帮助开发者快速入门，简化诸如调用 LLM、定义和解析工具、以及链式调用等标准低级任务。然而，它们往往会引入额外的抽象层，从而掩盖底层的提示（prompt）和响应，使调试变得更加困难。此外，它们可能会让开发者在不必要的情况下引入额外的复杂性，而一个更简单的方案可能已经足够。

我们建议开发者优先直接使用 LLM API，因为许多常见模式仅需几行代码即可实现。如果确实使用框架，请确保你理解其底层代码。对框架内部机制的错误假设 是客户常见的错误来源之一。

查看我们的示例手册（cookbook），获取一些具体的实现案例。

构建模块、工作流与代理

在本节中，我们将探讨在生产环境中常见的代理系统模式。从最基础的增强型 LLM（augmented LLM）开始，逐步提升复杂性，从简单的组合式工作流到完全自主的代理系统。

基础构建模块：增强型 LLM

代理系统的核心构建模块是 增强型 LLM，即通过**检索（retrieval）、工具（tools）和记忆（memory）**等增强功能提升 LLM 的能力。

我们当前的模型可以主动使用这些增强能力，例如：

生成搜索查询，以获取外部信息

选择合适的工具，执行特定任务

决定保留哪些信息，以进行长期推理和任务管理

接下来，我们将探讨如何从这个基础模块扩展到更复杂的工作流和自主代理。

关键实现要点

在实现增强型 LLM 时，我们建议关注以下两个核心方面：

根据具体用例进行定制：确保增强功能（如检索、工具、记忆）适用于你的特定需求。

提供易用且文档完善的接口：让 LLM 能够轻松访问这些功能，并确保开发者可以高效集成和维护。

尽管有多种方式可以实现这些增强功能，其中一种方法是使用我们最新发布的 Model Context Protocol。该协议允许开发者通过简单的客户端实现，与不断扩展的第三方工具生态系统无缝集成。

在本文的其余部分，我们将假设每次 LLM 调用都能访问这些增强功能，并基于此展开更复杂的构建方式。

工作流：提示链（Prompt Chaining）

提示链（Prompt Chaining） 是一种将任务分解为一系列步骤的工作流模式，其中每次 LLM 调用都会处理前一步的输出。这种方法能够提高任务执行的可控性和稳定性。

在提示链的设计中，你可以在中间步骤加入程序化检查（称为“gate”），用于验证当前进程是否仍然按照预期进行。例如，检查某个中间结果是否符合特定标准，或者在必要时调整后续步骤。

提示链适用于：

结构化任务（如文档摘要、数据处理）

多步推理（如代码生成、复杂查询）

内容转换（如格式转换、语言翻译）

通过提示链，你可以提高 LLM 任务的可预测性和一致性，同时在不同步骤进行适当的干预，确保最终结果符合预期。

何时使用提示链工作流

提示链 适用于可以清晰拆分为固定子任务的场景。它的主要目标是 以较高的延迟换取更高的准确性，让每次 LLM 调用都处理更简单的任务，从而提高整体输出质量。

适用场景示例

生成营销文案并翻译成不同语言

步骤 1：使用 LLM 生成营销文案。

步骤 2：调用 LLM 进行语言翻译。

步骤 3（可选）：检查翻译质量，确保符合品牌语气和文化适配性。

文档写作流程

步骤 1：生成文档大纲。

步骤 2：检查大纲是否符合预定义标准（例如是否包含所有关键要点）。

步骤 3：基于最终确定的大纲撰写完整文档。

这种方式能够确保任务按逻辑顺序进行，并提供更多控制点，使每个步骤的输出质量更可控。

工作流：路由（Routing）

路由（Routing） 是一种对输入进行分类，并将其引导至特定后续任务的工作流模式。这种方法可以分离不同任务的关注点，并构建更具针对性的提示（prompt），从而优化整体性能。

如果没有路由机制，试图为所有输入优化同一个提示，可能会导致某些类型的输入表现良好，而另一些输入的性能下降。

适用场景

当需要根据输入的不同类型采取不同处理方式时，路由是一个理想的选择，例如：

客户支持自动化

步骤 1：识别用户意图（如技术支持、账单查询、产品咨询）。

步骤 2：将请求分配给适当的处理流程（例如，提供 FAQ 文章、升级到人工客服等）。

内容生成系统

步骤 1：判断用户请求的内容类型（如博客文章、社交媒体文案、技术文档）。

步骤 2：选择相应的提示模板，以生成最符合预期的内容。

多语言处理

步骤 1：检测输入语言。

步骤 2：选择适当的翻译或本地化流程。

这种方法不仅提高了任务处理的效率，还能确保不同类型的输入获得最优化的处理方式，避免“一刀切”式的泛化策略影响整体性能。

何时使用路由工作流

路由工作流适用于复杂任务，尤其是当任务可以划分为多个明确的类别，并且这些类别需要采用不同的方法处理时。 只要分类可以准确完成（无论是由 LLM 还是传统分类模型/算法执行），路由就能显著提高效率和效果。

适用场景示例

客户服务自动化

步骤 1：使用 LLM 或分类模型识别用户查询类别（如常见问题、退款请求、技术支持）。

步骤 2：将不同类别的请求引导至相应的处理流程、提示（prompt）或工具。

优化 LLM 计算资源

步骤 1：对输入问题进行复杂度分类。

步骤 2：

简单/常见问题 → 发送至更轻量的模型（如 Claude 3.5 Haiku）以节省计算成本并加快响应速度。
复杂/罕见问题 → 发送至更强大的模型（如 Claude 3.5 Sonnet）以获得更高质量的答案。

为什么使用路由？

提升处理效率：确保每个任务由最适合的模型或流程处理。

降低成本：将简单任务交给轻量级模型或更高效的方法执行。

提高准确性：让特定类别的任务使用最优化的提示和工具，而不会因泛化处理而牺牲质量。

通过这种方式，路由工作流能让系统更智能、更高效，并优化计算资源的分配。

工作流：并行化（Parallelization）

在某些任务中，LLM 可以同时处理多个任务，并将其输出进行程序化聚合，这就是并行化工作流。并行化主要有两种关键模式：

分段处理（Sectioning）：将任务拆分为多个独立的子任务，并行执行，提高处理速度。

投票机制（Voting）：对同一任务运行多个 LLM 实例，生成多个不同的输出，并进行比较或合并，以提高结果的质量和可靠性。

适用场景示例

1. 分段处理（Sectioning）

适用于任务可以拆分为多个独立部分的情况。 例如：

长文档摘要

步骤 1：将文档拆分为多个部分（如按章节、按主题划分）。
步骤 2：并行运行多个 LLM 进程，对每个部分进行摘要。
步骤 3：合并各部分摘要，形成最终摘要。

大规模数据处理

步骤 1：将待分析的数据集拆分成多个子集。
步骤 2：让多个 LLM 进程并行分析不同子集的数据。
步骤 3：汇总分析结果，生成整体结论。

2. 投票机制（Voting）

适用于提高结果质量或减少随机误差的情况。 例如：

提高文本生成的质量

步骤 1：让多个 LLM 实例生成同一问题的答案。
步骤 2：采用投票机制，选择最优答案（如基于词频、模型置信度、人工筛选等）。

代码生成与错误校正

步骤 1：让 LLM 生成多个版本的代码实现。
步骤 2：对比不同版本，选择最优代码或合并最佳部分。

何时使用并行化工作流？

并行化适用于两种情况：

任务可以拆分成独立的子任务，并行执行以加快处理速度。

任务需要多个视角或多次尝试，以提高结果的置信度和准确性。

对于复杂任务，让每个 LLM 调用专注于一个具体的方面，通常会比让单个 LLM 处理所有方面效果更好。

适用场景示例

1. 分段处理（Sectioning）

适用于任务可拆分为多个独立部分，并行处理提高效率的情况。

多模型安全过滤

模型 A：处理用户查询，生成响应。
模型 B：同时审核查询内容，筛查是否包含不适当内容或敏感请求。
这种方式通常比让同一个 LLM 既处理查询又进行审核更高效，且能提升安全性。

自动评估 LLM 性能

每个 LLM 进程独立评估不同的性能指标，如：

语言流畅度
事实准确性
逻辑连贯性

最终汇总各方面的评分，形成全面评估。

2. 投票机制（Voting）

适用于需要多个模型或多个提示（prompt）提供不同答案，以提高准确性和置信度的情况。

代码安全审查

让多个 LLM 使用不同的提示（prompt）检查代码漏洞，如：

SQL 注入
跨站脚本（XSS）攻击
逻辑漏洞

若多个 LLM 发现相同问题，则高度可信；否则可以进一步复审。

内容审核（减少误判）

让多个 LLM 以不同角度评估内容是否违规，例如：

语言攻击性
事实准确性
文化敏感性

设定不同的投票阈值，减少误判（如降低误封或误放）。

并行化的优势

✅ 提高处理速度（多个 LLM 进程同时运行）

✅ 提升结果质量（每个 LLM 专注于一个方面）

✅ 增强安全性与可靠性（通过多次尝试或投票机制提高准确度）

并行化特别适合数据处理、内容审核、模型评估等高负载任务，使 LLM 系统更加高效和稳定。

工作流：编排者-工作者（Orchestrator-Workers）

在 编排者-工作者（Orchestrator-Workers） 工作流中，一个中央 LLM 负责动态拆分任务，分配给多个工作者 LLM（Worker LLMs） 进行处理，最后综合它们的结果，形成最终输出。

适用场景

适用于复杂任务，需要多个 LLM 处理不同子任务，并最终合并结果的情况。

任务具有多个不同的子任务，需要专门化处理（如代码生成、项目管理）。

任务需要多个 LLM 之间协作，且需要一个中心 LLM 进行协调（如多语言翻译、大规模数据分析）。

需要动态调整任务分配，而不是预先定义固定的工作流。

适用场景示例

1. 自动化文档处理

编排者 LLM：分析文档并拆解为多个子任务。

工作者 LLM 1：提取关键主题和要点。

工作者 LLM 2：生成摘要或转换格式（如 Markdown、JSON）。

工作者 LLM 3：检查语法和可读性，并优化文案。

编排者 LLM：合并各部分内容，生成最终文档。

2. 代码生成与调试

编排者 LLM：根据需求拆分代码功能（如 API 设计、数据库查询、前端逻辑）。

工作者 LLM 1：编写 API 端点代码。

工作者 LLM 2：优化 SQL 查询，确保高效性。

工作者 LLM 3：检查代码安全性（防止 SQL 注入、XSS 等漏洞）。

编排者 LLM：整合代码，生成完整项目，并进行测试。

3. 多语言翻译与本地化

编排者 LLM：分析文本，确定不同部分的翻译需求（如技术术语、文化敏感内容）。

工作者 LLM 1：翻译技术文档部分，确保专业性。

工作者 LLM 2：翻译营销内容，确保符合目标受众的文化习惯。

工作者 LLM 3：进行质量审查，优化语法和流畅度。

编排者 LLM：整合最终译文，生成完整的多语言版本。

何时使用编排者-工作者（Orchestrator-Workers）工作流？

这种工作流适用于复杂任务，且无法提前预定义子任务的情况。与并行化（Parallelization）工作流类似，但关键区别在于：

✅ 并行化（Parallelization） 适用于预定义的子任务（如固定的文本分析步骤）。

✅ 编排者-工作者（Orchestrator-Workers） 动态决定子任务（基于输入数据调整任务拆分和分配）。

适用场景示例

1. 代码生成与修改

适用于需要对多个文件进行复杂修改的场景。

编排者 LLM：分析代码变更需求，动态决定需要修改的文件和改动内容。

工作者 LLM 1：更新核心业务逻辑文件。

工作者 LLM 2：修改前端 UI 代码以适配新功能。

工作者 LLM 3：更新相关的测试用例，确保功能正确性。

编排者 LLM：整合所有代码修改，生成最终提交版本。

✅ 优势：灵活适配不同规模的代码改动，无需提前定义所有文件修改规则。

2. 信息检索与分析

适用于需要从多个来源收集、分析信息的搜索任务。

编排者 LLM：根据查询动态决定信息收集策略（如新闻搜索、学术文献、社交媒体分析）。

工作者 LLM 1：从新闻网站提取相关报道。

工作者 LLM 2：检索学术论文，提取研究结论。

工作者 LLM 3：分析社交媒体趋势，提取公众观点。

编排者 LLM：整合所有信息，生成综合分析报告。

✅ 优势：灵活适应不同的信息需求，确保全面性和准确性。

编排者-工作者工作流的核心优势

🚀 动态调整任务：无需预定义子任务，适应不同输入需求。

🛠 模块化架构：每个子任务可独立执行，提高可扩展性。

🎯 优化任务执行：确保任务分工合理，避免单一 LLM 负担过重。

适用于大规模代码改动、信息收集分析、跨领域数据处理等动态、多步骤任务，使 LLM 具备更高的自动化能力。

工作流：评估者-优化者（Evaluator-Optimizer）

在 评估者-优化者（Evaluator-Optimizer） 工作流中，一个 LLM 负责生成响应（优化者），另一个 LLM 负责评估结果并提供反馈（评估者），两者在循环中交互，持续改进输出质量。

何时使用评估者-优化者（Evaluator-Optimizer）工作流？

这种工作流特别适用于具有清晰评估标准，且迭代优化能够带来显著改进的任务。

✅ 适用两大条件：

当 LLM 生成的内容可以通过人类反馈改进 → 说明 LLM 也能通过自动化评估者提供类似反馈。

当 LLM 可以清晰地提供有用的评估和优化建议 → 使优化过程高效且可衡量。

这种方法类似于人类作家反复修改文本，以达到更完美的效果。

适用场景示例

1. 文学翻译（捕捉语言细微差别）

优化者 LLM：进行初步翻译。

评估者 LLM：检查翻译的语境、风格、文化适配性，并提供优化建议。

优化者 LLM：根据评估者的反馈进行调整。

重复此过程，直至翻译既准确又符合文学表达方式。

✅ 优势：增强翻译的自然性，使其更贴近母语读者的语言习惯。

2. 复杂信息检索与分析（多轮搜索）

优化者 LLM：执行初步搜索，提供信息摘要。

评估者 LLM：分析结果，判断信息是否充分，是否存在遗漏。

优化者 LLM：根据评估者的反馈，调整搜索策略，执行更深入的信息挖掘。

持续优化，直到获取完整、准确的信息。

✅ 优势：适用于深入研究、市场调查、新闻分析等需要多轮验证的信息搜索任务。

核心优势

🔄 支持多轮优化：LLM 不仅生成内容，还能自我评估并改进。

🎯 确保高质量输出：避免一次性生成导致的不准确或不自然问题。

📊 适用于可衡量标准的任务：适合有明确优化目标的应用，如翻译、写作、搜索优化等。

这种工作流能够让 LLM 更加智能地调整自身生成策略，使其在质量要求较高的任务中表现更出色。

代理（Agents）

随着 LLM 在核心能力上的成熟（如理解复杂输入、推理与规划、可靠使用工具、错误恢复），代理（Agents）正逐步进入生产环境。

代理的工作方式

起始阶段

代理从用户指令或交互式对话开始任务。

通过讨论澄清任务需求，确保目标明确。

规划与执行

代理自主制定计划，开始执行任务。

在执行过程中，代理会不断从环境获取“真实世界反馈”（如工具调用结果、代码执行输出）来评估进度。

适应性调整

代理可在关键检查点暂停，征求用户反馈，或者在遇到阻碍时请求人类介入。

任务通常在完成后终止，但可以设定停止条件（如最大迭代次数）以避免无限循环。

关键设计原则

✅ 可靠使用工具：代理通常依赖工具（API、数据库、计算系统等）来获取信息或执行任务，因此工具的设计和文档必须清晰。

✅ 环境反馈驱动：代理不应仅依赖 LLM 内部知识，而是要通过工具调用或代码执行实时获取信息。

✅ 可控性与透明性：

代理应在合适的节点请求人类反馈，避免完全“黑箱”操作。

需要设定明确的终止条件，确保系统不会陷入无限执行状态。

适用场景示例

自动化代码修复代理

用户提交错误代码，代理分析问题。

代理生成修复方案，并调用工具运行测试。

如果测试失败，代理根据反馈调整方案，继续优化。

最终，代理提供修复后的代码，并解释更改内容。

市场调研与数据分析代理

用户请求关于某一市场趋势的分析。

代理依次调用新闻爬取、数据库查询、数据可视化工具，整理相关信息。

代理总结发现，并在关键数据不足时请求用户补充方向。

代理 vs. 其他工作流

方法	特点	适用任务
工作流（Workflow）	预定义步骤、可预测	适用于固定任务，如文档处理、内容审核
代理（Agents）	自主决策、基于环境反馈调整	适用于复杂、动态任务，如代码修复、自动化调研

最佳实践

🔹 设计清晰的工具接口，确保代理能够高效调用外部资源。

🔹 提供良好的文档，让代理能够理解工具的使用方式，避免错误调用。

🔹 允许人工干预，在必要时让用户提供反馈，确保任务朝正确方向发展。

代理虽然可以处理复杂任务，但其核心实现通常较为简单，本质上是 LLM 在循环中利用工具执行任务。 在 附录 2（"Prompt Engineering your Tools"） 中，我们将深入探讨工具开发的最佳实践。

何时使用代理（Agents）？

代理适用于开放性问题，即无法预先确定执行步骤或硬编码固定路径的任务。其自主性允许 LLM 在多个回合内运行，因此系统需要具备一定的信任度，确保 LLM 具备合理的决策能力。

✅ 适用于：

任务步骤数量不确定（如代码修复、数据爬取）。

无法硬编码工作流（如跨系统操作、自动化办公）。

需要长期自主执行（如 AI 代理执行任务，无需人类实时监控）。

⚠️ 注意事项：

代理的自主性越高，成本也越高（计算资源消耗较大）。

错误可能会累积，导致意外行为，因此建议在受控环境下充分测试。

需要适当的安全防护（如任务检查点、人工干预机制）。

适用场景示例

1. 代码修复代理（Coding Agent）

✅ 场景：

代理接收软件工程（SWE-bench）任务，分析所需修改的文件。

代理逐步编辑代码，运行测试，检查是否解决问题。

任务可能涉及多个文件，具体修改步骤难以预先定义，因此代理必须自主决策。

⚡ 优势：能够自动处理复杂代码任务，提高开发效率。

2. 计算机操作代理（Computer Use Agent）

✅ 场景：

代理（如 Claude）通过 API 或 UI 自动化操作计算机，完成任务。

可能涉及文件管理、表单填写、数据分析、软件运行等多个子任务。

代理根据环境反馈调整操作，可能多次迭代以完成最终目标。

⚡ 优势：自动化办公、跨软件操作，减少人工干预。

代理 vs. 其他方法

方法	特点	适用任务
工作流（Workflow）	预定义步骤、低自主性	适用于可预测任务，如数据处理、审核
代理（Agents）	高度自主、动态决策	适用于复杂、不可预测任务，如代码修复、计算机操作

最佳实践

✅ 沙盒测试（Sandboxing）：在安全环境中测试代理，防止意外操作。

✅ 检查点机制：设置人工反馈点，确保任务朝正确方向发展。

✅ 使用可靠工具：代理依赖工具执行任务，因此工具的稳定性至关重要。

代理适用于信任环境（Trusted Environments），如内部企业自动化、研发辅助等，但在高风险任务（如金融决策、医疗建议）中，应谨慎评估可行性。

组合与定制这些模式

这些构建模块并不是固定的规则，而是灵活的模式，开发者可以根据具体应用需求进行调整、组合。关键在于不断测量性能、优化实现方式，并仅在必要时增加复杂性，确保它能够切实提升任务结果。

如何灵活运用这些模式？

✅ 组合不同模式，匹配具体场景

示例 1：代码生成系统

使用“编排者-工作者”模式 让 LLM 先分析需求，拆解不同代码模块。
结合“评估者-优化者”模式 让 LLM 自动优化代码，提高质量。

示例 2：自动化内容审核

先使用“路由”模式 根据内容类型（如文本/图像）选择不同的处理路径。
再使用“并行化”模式 让多个 LLM 从不同角度审查内容（如检测攻击性、误导性等）。

✅ 优化工作流，提高系统效率

示例 3：大规模数据分析

结合“并行化”模式 让多个 LLM 处理不同数据子集，加快处理速度。
使用“评估者-优化者”模式 让系统自动检查结果的准确性，并优化分析报告。

✅ 逐步增加复杂性，避免过度设计

先用最简单的 LLM 解决方案，看是否满足需求。

仅在需要时添加工具增强、并行计算或自主代理，以提升性能。

关键原则

📊 测量 & 迭代：持续监控 LLM 的任务执行效果，确保优化方向正确。

🔍 最小复杂性原则：仅当更复杂的模式能显著提高性能时才引入。

🛠 可组合性：不同模式可以自由组合，以适应特定业务需求。

LLM 代理和工作流的成功关键，不是使用最复杂的框架，而是找到最适合当前任务的设计。

总结

在 LLM 领域的成功不在于构建最复杂的系统，而是构建最适合你需求的系统。先从简单的提示（prompts）开始，通过全面评估优化，并仅在必要时 添加多步骤的代理系统（agentic systems）。

代理系统的三大核心原则

✅ 保持简单

设计尽可能精简，避免不必要的复杂性。

仅在实际证明需要时，才增加新功能或多步骤逻辑。

✅ 优先透明性

明确展示代理的规划步骤，避免黑箱操作。

让用户能够理解并信任代理的决策过程。

✅ 优化代理-计算机接口（ACI）

清晰设计工具接口，让代理高效、准确地调用外部资源。

提供详尽文档与测试，确保工具可维护、可靠。

关于框架的建议

🛠 框架可以帮助快速入门，但在进入生产阶段时，不要害怕减少抽象层，回归基本组件（如直接调用 LLM API）。

📊 在生产环境中，稳定性、可维护性和透明度至关重要，远比单纯追求复杂性更重要。

最终目标

通过遵循这些原则，你可以构建既强大又可靠的 LLM 代理系统，让其不仅高效执行任务，还能赢得用户的信任，并适应不断变化的需求。 🚀

致谢

本文由 Erik Schluntz 和 Barry Zhang 撰写。

本工作基于我们在 Anthropic 研发代理系统的经验，同时也受益于客户分享的宝贵见解。在此，我们深表感谢！

附录 1：代理在实践中的应用

我们与客户的合作表明，AI 代理在两个关键应用场景中展现了显著的价值，这些场景很好地体现了前文讨论的代理模式的实用性。

代理最适用于需要结合对话和操作、具有明确成功标准、支持反馈循环、并能融入人工监督的任务。

A. 客户支持代理

客户支持代理结合了传统聊天机器人界面与增强的工具集成能力，使其成为开放式代理的理想应用场景。

为什么客户支持适合代理？

✅ 支持对话式流程：客户咨询通常以对话形式进行，而代理能在此过程中访问外部数据并执行操作。

✅ 工具集成能力：代理可以自动调用 API，查询客户信息、订单历史、知识库文章，提供精准答案。

✅ 可执行操作：代理不仅能提供信息，还能自动执行退款、更新支持工单等任务。

✅ 成功标准明确：用户问题是否成功解决可以通过预定义指标衡量，例如用户满意度、工单关闭率。

💡 成功案例：

一些公司已采用按成功解决案例计费的模式，仅对最终有效解决客户问题的交互收费，表明对其代理性能的高度信任。

B. 代码代理（Coding Agents）

软件开发是 LLM 代理最具潜力的应用领域之一，其能力已从代码补全发展到自主解决问题。

为什么代码代理表现优异？

✅ 代码解决方案可验证：自动化测试可以客观评估代码是否满足功能需求。

✅ 可基于反馈循环优化：代理能使用测试结果作为反馈，迭代改进代码。

✅ 问题空间明确：软件开发具有结构化的问题定义，便于代理制定和执行计划。

✅ 输出质量可衡量：代码质量可以通过测试通过率、代码风格、性能分析等方式客观评估。

💡 成功案例：

在我们自己的实现中，代理已经可以基于 GitHub Pull Request 描述，解决 SWE-bench Verified 基准测试中的真实问题。

自动化测试 能够帮助验证代码功能是否正确，但人工审查仍然至关重要，确保代码符合更广泛的系统需求和工程最佳实践。

附录 2：工具的提示工程（Prompt Engineering Your Tools）

无论构建哪种代理系统，工具（Tools）都是代理的重要组成部分。工具允许 Claude 与外部服务和 API 交互，其结构和定义需要在 API 中明确指定。当 Claude 计划调用工具时，它会在 API 响应中包含工具调用块（Tool Use Block）。

工具的定义和规范化与整体提示工程同样重要，精心设计工具接口（Agent-Computer Interface, ACI）可以显著提高代理的可靠性和效率。

如何优化工具的提示工程？

在设计工具时，同一个操作往往可以有多种实现方式，例如：

✅ 文件编辑：可以用diff 方式（只写入更改部分），也可以重写整个文件。

✅ 结构化输出：可以用 Markdown 格式嵌入代码，也可以用 JSON 结构化存储。

在软件工程中，这些格式上的差异是可以无损转换的，但对于 LLM 而言，某些格式比其他格式更容易处理。例如：

写 diff 文件 时，LLM 需要事先计算要更改的行数，否则可能会写错 chunk 头部。

JSON 嵌套代码 需要额外转义换行符和引号，比 Markdown 复杂。

工具格式设计建议

🔹 确保 LLM 有足够的 token 预算，避免陷入无法正确生成的困境。

🔹 选择 LLM 在互联网上最常见的格式（如 Markdown，避免冷门格式）。

🔹 避免额外的格式开销（如计算代码行数、转义字符串等复杂步骤）。

一个简单的经验法则：

👉 就像人机交互（HCI）需要设计优化，代理-计算机接口（ACI）也需要同样多的设计投入！

如何提升工具的可用性？

✅ 站在 LLM 的角度思考：

工具的描述和参数是否足够清晰？

使用工具时是否需要“深思熟虑”？如果是，模型也可能会犯错。

一个好的工具定义 应该包含：

示例用法（Example Usage）
边界情况（Edge Cases）
输入格式要求（Input Format Requirements）
与其他工具的区分点（Clear Boundaries from Other Tools）

✅ 优化参数名称和描述

将参数设计得更直观，就像给新手开发者写清晰的 Docstring。

尤其是在多个类似工具共存时，要确保每个工具的用途明显。

✅ 测试工具的实际使用方式

在 Workbench 中运行多种输入示例，观察 LLM 的错误模式。

迭代优化，不断调整工具描述，使 LLM 更准确地调用工具。

✅ 防错设计（Poka-Yoke）

修改参数减少可能的误用，例如：

发现 LLM 误用相对路径？改成强制要求绝对路径！
发现 LLM 误填某些参数？使用默认值或限制参数范围！

实际案例：SWE-bench 代理的工具优化

在构建 SWE-bench 代码代理时，我们发现：

❌ LLM 在使用相对路径时经常出错，特别是当代理移动到非根目录后。

✅ 解决方案：调整工具参数，要求始终使用绝对路径，结果模型调用工具的准确率大幅提升！

🔹 结论：优化工具接口的效果，甚至比优化整体 Prompt 还要显著。