做 Agent，绕不开过去那些架构问题
文章目录
最近读了 Kiran Prakash 发表在 Martin Fowler 网站上的 《Long-horizon agents and durable execution》，想到一个问题：过去围绕高并发、大流量积累的架构经验，到了 Agent 开发里，还能用上多少？
我觉得可以先从交付物看起。以前交付一个接口，关注请求能否及时返回；现在让 Agent 处理一件事，还要关心它明天能不能接着做、做到一半失败怎么办。把时间拉长以后，很多熟悉的工程问题就又出现了。下面结合原文的持久执行思想，谈谈我对这些关系的理解。
原文给我最直接的启发，是把长期运行的 Agent 看成需要恢复能力的程序。所谓持久执行（Durable Execution），就是记录步骤的执行结果，发生故障后，通过回放历史恢复状态，已经记录结果的步骤直接复用。它解决了任务如何继续推进的问题，但业务结果是否正确，还需要另外设计。原文
先看容量。做大流量系统时，我们习惯看 QPS、响应时间和资源利用率。Agent 的入口流量可能不大，但一件任务会展开成多轮模型调用、工具调用和等待。假设每天进入一千件任务，平均三天完成，稳定运行后就可能同时存在约三千件未完成任务。这是容量估算的假设，不是压测结果，但足以提醒我们：接口请求少，不代表系统负担轻。
因此，我会把等待中的任务和真正执行中的任务分开计算。等待审批的任务保留状态和唤醒条件，需要执行时再分配 Worker。这里延续的是异步化的思路：让计算资源服务于实际工作。持久化存储、调度和恢复仍有成本，不能因为进程没有一直运行，就认为等待完全免费。
再看状态。以前为了水平扩容，会尽量让应用实例无状态，把业务状态放到数据库。Agent 同样可以这样拆：执行实例允许替换，任务进度必须留下来。聊天记录能帮助模型理解上下文，但不能单独承担业务账本的职责。某个退款是否执行、谁批准了操作，都应有明确的结构化记录。
这里还有一个容易忽略的细节：恢复任务时，不能把已经得到结果的模型调用重新跑一遍，否则下一步可能发生变化。以 Temporal 为例，模型和外部工具调用可以放进 Activity，回放时使用已记录的结果；工作流里的控制逻辑则需要满足确定性要求。这个边界决定了恢复是否可信。Temporal 文档
第三个关系是幂等。比如让 Agent 处理售后退款，支付服务已经退款成功，只是响应在网络中丢了。此时重试没有问题，重复退款就有问题。对同一笔业务操作，重试应携带同一个幂等键，由接收方识别重复请求。超时表示没有按时收到结果，不能直接推导出业务没有发生。这和以前处理重复消息、重复提交是同一类问题。AWS Builders’ Library
沿着这个思路，我会给结果不明确的操作保留“待确认”状态，提供查询和对账入口。已经产生的业务影响，需要撤销或补偿时，也要遵守业务规则。让模型再想一次可以帮助分析情况，却不能代替退款流水和订单状态。
并发边界也要跟着业务走。两个 Agent 同时处理同一订单，即使各自没有重试，也可能做出冲突操作。我会按订单标识组织任务，在写入时检查版本或状态，让不同订单并行，让同一订单的关键变更受到约束。这和过去避免并发覆盖的考虑一致。
第四个关系是流量治理。一个用户请求可能触发十次模型调用，再访问多个下游。如果失败后每一层都重试，原本的小故障就可能被放大。所以超时、退避和重试次数上限仍然有用；退避加入随机抖动，可以减少大量客户端同时重试造成的压力。AWS 重试设计
放到 Agent 场景，我还会给单个任务设置最大轮数、调用预算和截止时间，并按租户或下游服务限制并发。预算耗尽后，要能暂停、结束或交给人工处理。模型持续输出，不等于业务持续取得进展；这部分成本需要在设计时就算进 ROI。
当然，Agent 也带来了新的变量：部分执行路径由模型根据上下文选择。开发者因此需要把“可选择的动作”和“允许执行的条件”定义清楚。比如模型可以建议退款，退款工具仍要检查订单归属、金额和审批状态。以前前端按钮隐藏了，后端仍要鉴权；现在模型认为可以操作，服务端同样需要独立校验。
从稳定性建设的角度，我也会调整观测方式。除了接口错误率，还要能回答：哪些任务长时间没有进展，卡在哪个依赖，花了多少调用成本，最终是否完成了用户的目标。任务 ID 应当串起模型调用、工具执行和业务结果，否则每个接口都显示成功，整件事却可能一直没有做完。
如果现在开始落地，我会先选一个边界明确、能够核验结果的小流程，把正常执行、超时、重试、重启恢复和人工接管走通，再逐步扩大自主决策范围。先利用已有数据库、消息队列和稳定性工具，随着任务复杂度增加，再评估持久执行框架的收益与维护成本。过去积累的工程经验，正好可以帮助我们判断：哪些能力值得交给模型，哪些约束必须落实到代码，以及这件事做成以后，究竟给业务省下了什么。