代理应用程序的基础架构模式

换云？获得高达 10K 美元的积分 + 实践帮助。立即申请 公司 2026 年 7 月 29 日 公司代理应用程序的基础设施模式 Jacob Prall 2026 年 7 月 29 日 Jacob Prall 大多数团队开始构建代理的方式与构建任何其他 Web 功能相同：将模型包装在路由处理程序中，解析请求，然后等待响应。这对于演示来说很好。这也是生产中第一个中断的事情。代理是长期运行的、有状态的且不确定的。它们调用工具、等待外部 API、分支到子任务、达到速率限制，并在多步骤序列中途崩溃。如果您的代理与单个 HTTP 请求相关联，则您已将应用程序的可靠性与非确定性循环的挂钟时间耦合起来。超越演示意味着打破这种耦合。这篇文章将介绍团队用来将脆弱的代理脚本转变为可扩展、有弹性的生产系统的三个核心模式。代理的本质 代理的核心是一个循环：接收目标，决定下一步做什么，调用模型或工具，观察结果，更新状态，重复直到完成。该循环有一些特性使其对朴素的 Web 架构产生敌意。代理是长期运行的。正常的 API 请求应该很快完成。代理通常不会这样做，有时需要数小时甚至数天才能完成。代理是有状态的。一次运行不是一次函数调用。它是一个目标、一个计划、工具调用和输出、重试、错误、决策和最终输出。如果进程崩溃，您需要知道已经发生了什么。如果没有，您要么会失去进度，要么盲目地重新运行工作。两者都不是很好，特别是对于长期运行的代理来说。代理是不确定的。传统的工作流代码表示：代理代码表示：模型在运行时选择下一个操作，这使得恢复、重放和调试变得更加困难。跑步可能需要三步或三十步。它可能会分散到多个工具上，等待人类，产生大量的中间工件，或者提前停止。基础设施必须通过超时、预算、检查点、批准和明确的终止条件来围绕这种不可预测性设置边界。总而言之，这些属性意味着代理需要的不仅仅是包装在应用程序代码中的模型调用。他们需要将运行与请求分离的架构，以及保留进度、记录决策、控制副作用以及与模型上下文分开管理工件的基础设施。模式：Web-Queue-Worker 第一个生产模式是停止在 Web 请求内运行整个代理。请求对于代理运行来说是错误的生命周期。它应该创建持久的运行记录、将工作排队并立即返回。这为应用程序提供了一个简单的边界：API 将作业排队。队列持久地存储作业。工人执行工作。数据库记录进度。客户端立即获得运行 ID。代理运行在其他地方。用户检查状态、订阅更新或在运行完成时接收回调。队列是创建工作的事物和执行工作的事物之间的持久缓冲区。当运行时间比正常请求长、任务大多是独立的并且您需要工作人员扩展、重试或突发吸收时，这是默认起点。陷阱：队列知道作业存在，但不知道作业所属的逻辑进程。一项后台工作就可以了。队列无法为您管理二十个相关步骤、三次重试、两个分支和人工批准暂停。您将自己构建该逻辑。正如我们稍后将看到的，这就是工作流引擎的用武之地。 可靠性：安全重试和部分失败 将工作移至队列解决了生命周期问题。它不能解决执行的持久性问题。大多数生产队列都是至少一次：一个作业可以运行多次。这是为了避免丢失工作而故意进行的权衡，并且您的代码必须能够幸存下来。一旦代理可以调用​​工具、写入记录、发送消息或配置资源，重试行为就成为应用程序正确性模型的一部分。有两个学科最重要。幂等性回答了当一个步骤运行两次时会发生什么。补偿解决了运行在一系列步骤中途停止时发生的情况。重试使第一次成为一项要求。永久性故障使得第二个故障成为生产所必需的。接触远程服务的代理需要两者。幂等性：在运行两次的步骤中幸存 坏的工作代码假设步骤之间不会崩溃：更好的代码创建幂等性边界：对于代理，每个副作用工具调用都需要相同的处理：在调用工具之前检查已完成的记录，更新插入“正在运行”的记录，调用该工具，将其标记为完成。除非重试操作是安全的，否则重试不是恢复策略。补偿：在中途停止的运行中幸存下来 考虑一个完成五个步骤中的三个步骤的代理：它对卡进行收费、配置资源并发送确认电子邮件。然后第四步就永久失败了。没有任何