尽管今年似乎每家公司都在谈论构建代理，但真正这样做的公司却少得多。很容易让您的想象力在代理如何改变您的业务方面天马行空，但许多团队不确定从何开始，如何取得进展，以及在哪里设定预期。
在本指南中，我们将通过一个构建电子邮件代理的真实世界示例，带您了解从构思到产生影响的框架。
第一步：通过示例定义您的代理任务
选择一个现实且需要代理的任务。
选择一个您可以教给聪明实习生的任务。如果您的顶尖实习生花费足够的时间和资源也无法完成该任务，那么该任务可能不切实际或过于雄心勃勃。在启用专家模式之前，请证明您可以掌握基本知识。
首先，想出 5-10 个具体的任务示例。这有两个目的：
- 首先，它验证您的想法范围是否合适——既不琐碎也不含糊。
- 其次，它为您提供了一个衡量未来绩效的基准。
示例：构建一个电子邮件代理
在此阶段，我们将定义我们的代理需要处理哪些任务，这可能包括：
- 优先处理来自关键利益相关者的紧急邮件
- 根据日历可用性安排会议
- 忽略垃圾邮件或不需要回复的电子邮件
- 根据公司文档回答产品问题
应避免的红旗
- 如果您无法想出具体的示例，那么您的范围可能太大了。
- 在传统软件可以更好地完成任务时使用代理（例如，当逻辑简单、固定且已在其他地方实现时）。代理速度慢、成本高，有时还很挑剔。如果传统软件可以完成工作——那就用它吧！
- 期望不存在的魔力（例如，连接到不存在或尚未构建的 API 或数据集）
第二步：设计操作流程
撰写详细的标准操作规程 (SOP)，其中包含人类将如何执行任务或流程的分步说明。
此步骤有助于确认您选择的问题范围清晰且合理。它还揭示了您的代理可能需要处理的关键步骤、决策和工具——为构建什么奠定了基础。
示例：构建一个电子邮件代理
对于我们的电子邮件代理，分步流程可能如下所示：
- 分析电子邮件内容和发件人上下文，以确定回复优先级
- 检查日历可用性；安排视频会议
- 根据电子邮件、发件人和日程安排的上下文起草回复
- 在经过快速的人工审核和批准后发送电子邮件
写出这个过程有助于确保任务范围适当，并揭示了我们的代理需要处理的工具和逻辑。
第三步：使用提示构建 MVP
选择一个起点很重要。如果您的代理很复杂，一次性完成所有事情过于雄心勃勃。首先设计 SOP 概述的代理架构：它的流程如何，它需要做出哪些决策，以及在哪里 LLM 推理至关重要。
然后，通过专注于最关键的 LLM 推理任务（例如，分类、决策制定）并创建能很好地处理这些任务的提示来构建 MVP。大多数代理之所以失败，是因为 LLM 无法足够好地为任务进行推理。让单个提示处理手动输入的数据将帮助您在继续构建完整代理之前建立信心。像 LangSmith 这样的提示工程工具可以帮助简化此过程，从管理提示版本，到跨场景或数据集进行测试，以及在您进行迭代时跟踪性能。
保持简单，通过
- 从手动输入提示所需的任何数据或上下文开始（暂时搁置自动化）
- 根据步骤 1 中概述的示例进行测试，以验证在常见用例中的性能
- 专注于获得正确的 LLM 推理
示例：构建一个电子邮件代理
在此阶段，我们首先确定并解决一个高杠杆推理任务。
对于我们的电子邮件代理，这可能意味着只专注于按紧急程度和意图对电子邮件进行分类（例如，会议请求、支持问题），因为这是代理其余部分所依赖的基础步骤。
从编写一个核心提示开始，只做这个，并提供手动输入的示例，例如：
- 电子邮件内容：“下周能否开会讨论 LangChain 的产品路线图？”
- 发件人：“Jeff Bezos”，职位：“亚马逊首席执行官”
- 输出：“意图 = “会议请求”，紧急程度 = “高”
一旦模型在您的测试用例中始终正确执行此操作，您就会确信核心逻辑是健全的——并且拥有坚实的基础来构建。
第四步：连接与编排
现在我们有了一个有效的提示，是时候将提示连接到真实数据和用户输入了。
首先确定提示需要什么上下文或数据——例如电子邮件内容、日历可用性和产品文档——并计划如何以编程方式访问它（例如，通过 API、数据库或文件系统）。
然后，编写编排逻辑将正确的数据连接到您的提示中。在简单的情况下，这可能只是直接传递输入。对于更复杂的流程，您可能需要代理逻辑来决定查询哪些数据源、何时调用它们以及如何组合它们的输出，然后再提示 LLM。
示例：构建一个电子邮件代理
对于我们的电子邮件代理，此步骤可能涉及与Gmail API（读取传入电子邮件）、Google Calendar API（检查可用性）以及CRM 或联系人数据库（丰富发件人上下文）集成。
然后，我们将构建如下的编排逻辑：
- 一封新邮件触发代理
- 代理从 CRM 或通过网络搜索获取发件人信息
- 它将完整上下文传递到提示中，以确定紧急程度和是否需要回复
- 如果会议是合适的，它会检查日历可用性并提议时间
- 代理起草回复
- 在人工审核后，发送电子邮件
第五步：测试与迭代
首先手动测试您的 MVP，使用您在步骤 1 中定义的示例。目标是验证您的代理是否为核心用例生成了合理、准确的输出。如果您的系统涉及多个 LLM 调用或步骤，使用LangSmith 等工具设置跟踪以可视化流程并调试每个阶段的决策过程会很有帮助。
一旦手动测试稳固，扩展到自动化测试以确保一致性并捕捉边缘情况。团队通常会增加示例的数量到几十个，以便更好地了解代理的优势和劣势。这也有助于您在增加更多复杂性之前量化性能。
- 以编程方式运行所有示例（原始 + 新的）通过您的代理
- 定义自动成功指标——这迫使您清晰地了解代理的预期行为
- 选择性地使用人工审核来捕捉指标可能遗漏的问题
示例：构建一个电子邮件代理
对于电子邮件代理，我们希望在几个关键领域定义和测试成功：
- 语气和安全性：回复应专业、尊重，并且没有虚构或不当内容
- 意图和优先级检测：电子邮件应根据发件人和内容正确分类和优先处理
- 工具使用效率：代理应仅触发必要的工具（例如，如果不需要安排会议，则避免检查日历）
- 草稿质量：建议的回复应清晰、相关且基于输入上下文准确
第六步：部署、扩展和优化
一旦您的 MVP 表现可靠，就开始扩展其范围——添加新功能、更广泛的用例，甚至多代理工作流。对于每个新功能或集成，重复步骤 5 的测试过程，以确保您没有破坏现有功能。
准备就绪后，部署到生产环境中供用户使用。LangGraph Platform 允许您通过一键部署快速发布、扩展和管理您的代理。
监控人们实际如何使用您的代理。LangSmith 等工具可让您实时跟踪代理的操作，从而更容易发现成本飙升、准确性问题或延迟。实际使用情况通常与您的初步假设不同，这些见解可以揭示差距、发现意想不到的需求，并指导您在下一个迭代中的优先级排序。
关键是将发布视为迭代的开始，而不是开发的结束。
示例：构建一个电子邮件代理
在部署了我们的电子邮件代理之后，我们可能会通过监控流量和常见用例发现未解决的用例。
这些新兴模式预示着扩展范围的机会。从那里，我们可以迭代地添加新集成并更新我们的提示和编排逻辑——在进一步扩展之前，始终通过测试和用户反馈来验证每个添加项。
结论
此流程旨在帮助您构建基于清晰用例、针对真实示例进行测试并根据实际工作方式进行塑造的代理。它不仅仅是让代理运行，而是构建有用、可靠且与人们实际工作方式一致的东西。
无论是自动化电子邮件分类还是编排复杂的工作流，这六个步骤都提供了一条从构思到产生影响的实用路径。但工作在部署后并未结束——最好的代理是通过迭代构建的。
因此，从小处着手，保持以用户为中心，并不断优化。