TikTok SRE 技术负责人：AI Agents 说到底就是分布式系统

编译｜宇琪

策划 | Tina

你的 AI Agent 调用退款接口，网络超时了，那退款到底成功没有？

TikTok 站点可靠性工程师 Salman Munaf 用这个例子阐述了他的观点：超时从来不意味着失败，而意味着“未知”。Agent 在遇到任何失败时的第一反应往往是重试，如果没有请求标识符（request identifiers）、幂等键（idempotency keys）以及状态查询（status lookup），这种“先重试再说”的本能就可能导致同一笔退款被执行两次。

Salman 在 TikTok 从事站点可靠性工程工作。他认为，一旦模型开始调用外部服务，问题就不再只是模型问题，而变成了分布式系统问题。这也就意味着，它会遇到这个领域几十年来已经反复研究和命名的各种故障模式。

日前，他在一场演讲中系统拆解了为什么 AI Agent 已经从单纯的 LLM 调用演化成了真正的分布式系统，以及开发者必须从分布式系统工具箱里搬来哪些“武器”，才能让 Agent 在犯错时不至于造成不可逆的后果。基于该演讲视频，InfoQ 对内容进行了整理。

核心观点如下：

• AI Agent 从只会吐字的模型变成了会执行副作用的外部系统协调器，这个转变彻底改变了系统的边界和风险面。

• 上下文能够影响行动时，它就是状态。而状态会变成过期的，状态会和权威数据冲突，状态会污染 Agent 后续的行动。

• 我们应该把记忆当作缓存来处理，它应该可以被失效，它应该带着来源信息。

• 一个无害的模型，当它能执行不安全的操作时，就会变得危险。

• 日志不够用了，你必须记录 Agent 每一步看到了什么、据此做了什么、为什么认为这样是对的

从聊天机器人到生产系统

今天我想聊的是为什么 AI Agent 也是分布式系统。

其实一开始 LLM 模型很简单，就是文本进、文本出，不执行任何动作，它唯一能产生的影响就是一个错误的输出。不过，那时候系统是封闭的，模型错了就错在回答里，不会往外扩散。但随着 Agent 能力的崛起，现在的 Agent 可以跟外部系统交互，变成了一个分布式系统，所以，在构建 AI Agent 时融入分布式系统的思维和概念非常重要。

大家可能听说过由 AI Agent 引发的事故。Replicate 的 AI Agent 删除了生产数据库，Air Canada 的聊天机器人做出了错误的退款承诺。这些事故的背后，都是系统思维的缺失。

比如，Replicate 那个案例，如果我们有稳健的备份，如果我们有作用域权限，本来就不应该允许 AI Agent 去删除生产数据库，这件事根本不会发生。Air Canada 的案子也一样，如果它有一个权威的真相来源，确保它不会基于过时的或错误的政策做决策，那个错误的退款承诺就不会出现。

最初，当 LLM 还只是聊天机器人时，我们输入提示词，输出文本，没有副作用，Agent 没有与任何其他系统交互。然而，在 AI Agent 时代，现在这些 Agent 通过接收提示词，可以运行 Agent Loop、调用外部服务和工具，还可以执行状态变更，架构边界已经远远超出了 LLM 模型本身，可以对外部世界产生副作用。所以在构建 AI Agent 时，重要的是要认识到它正在与哪些外部系统通信，它正在与哪些状态交互，它拥有什么凭证，以及它可以执行哪些操作。

我想强调一个非常关键的对比。在分布式系统里，我们以前也有服务在协调多步工作流，但它们是确定性的，每一步做什么、出错了怎么办，都是预先定义的。但 AI Agent 不一样，它本质上是一个概率性的协调器。它能执行的动作种类、下一步会做什么，变化范围太大了，不是一个传统的决策树能覆盖的。如果这些操作没有确定性控制来约束，它们可能会产生严重后果。因此，确保我们有确定性控制措施，确保 AI Agent 不会执行任何可能有问题的操作，这一点非常重要。

Agent 循环每一步都在过边界

一个典型的 Agent 循环是什么样的？首先它做规划，然后基于规划执行一个动作，接着观察这个动作的结果，可能把结果持久化到某个数据存储里，然后决定下一步做什么。这个循环里的每一步都在跨越系统边界。

规划阶段，它要跟数据源交互去检索信息。行动阶段，它要调用外部 API、工具、数据库，执行真实的操作。观察阶段，它拿到的是部分结果，然后基于这些部分结果决定后续动作。它可以持久化错误的数据，也可以在决策时选择执行一个不正确的动作，更糟糕的是，它可能会发起“重试风暴”。

所以构建 Agent 循环时，有一个原则特别重要：每一个步骤都必须被持久化。Agent 做的每个动作、检索到的每一份上下文，都必须记录下来。为什么？因为如果哪一步失败了，Agent 需要知道自己在哪个位置失败了，它才能执行可逆的操作，执行撤销。同时，每一步都必须明确事务边界。比如 Agent 做了一个调用，这个调用失败了，它应该怎么办？对于不可逆或者不安全的操作，补偿是什么？如果 Agent 给错误的客户发了一封邮件，它该怎么弥补？这些问题必须在设计阶段回答，而不是等事故发生了再想。

重试不是美德

工具调用本质上就是包装了外部 API、数据库、队列等等。当你发起远程调用时，就必须面对那些分布式系统早就遇到过的失败模式：网络延迟、超时、重复请求，还有最微妙的——服务端可能已经成功了，但客户端收到的是错误报告。

我们见过很多这样的情况：数据库已经写入了数据，但由于一些别的错误，服务端给客户端报了错。有人的时候，我们可以去看数据库里的真实状态，然后做出正确的纠正动作。但 Agent 没有这个直觉，它看到错误就重试，它不知道自己对系统的真实状态一无所知。

举一个非常具体的例子。Agent 调用一个“客户退款”工具，这个工具执行了退款操作，然后请求超时了。退款到底发生了没有？Agent 会怎么推断？会重新退款吗？关键认知在这里：超时不代表失败，超时代表未知。

设计这些工具的时候，有几件事是必须做的。第一，要有请求 ID 和幂等键。当重复请求进来的时候，下游系统能识别出这是同一个请求，不会产生重复的副作用。第二，系统要能执行状态查询，去查之前那个请求的状态，搞清楚它到底成功了还是失败了。

AI Agent 面对失败的第一反应就是重试，这是它的默认行为，所以你必须把幂等性焊死在工具层里。如果同样的请求再次进来，工具必须识别出这是一个重复请求，并且确保没有任何副作用发生。

但幂等性只解决了“重复不产生副作用”，它没解决“重试风暴”的问题。Agent 如果不停地重试，它会对你的外部 API 造成海啸式的调用压力，而且这种压力会往下游传导，导致级联故障。所以我们需要设置最大轮次数、预算、花费上限、最大并行调用数，确保它的扇出不会太大。还要有指数退避，让下游依赖有喘息的空间。对于有副作用的操作，补偿操作必须预先定义好。

你的 Agent 有一片会过期的“记忆”

很多团队在构建 AI Agent 时，把 Agent 持有的上下文只当作“上下文”。但我要说清楚：当上下文能够影响行动时，它就是状态。而状态会变成过期的，状态会和权威数据冲突，状态会污染 Agent 后续的行动。

我把 Agent 的记忆分成两类。短期记忆，就是这个执行线程里的上下文。长期记忆，就是项目文件、系统提示词、它交互的数据库、缓存层等等。当这些不同的数据源之间出现信息冲突的时候，你必须决定什么是真相来源。而且，我们应该把记忆当作缓存来处理，它应该可以被失效，它应该带着来源信息。比如当数据库更新了，真相来源更新了，Agent 持有的旧上下文就应该被失效掉，确保它不会基于过期的数据做决策。

Agent 通常会执行多步动作，前面几步成功了，然后在某一步失败了，这是常态。但问题是，已经执行的前面那些步骤怎么办？你需要把整个事务反转，而且这些步骤可能跨越系统边界。

举个例子，Agent 可以更新内部工单、给客户发一封邮件，然后在更新 CRM 时失败了，这时候你需要定义正确的补偿操作是什么。再比如我前面提到的，如果 Agent 给客户发了一封错误的邮件，那补偿操作就是再发一封道歉邮件，或者发一封纠正邮件。

Agent 在循环里跑，它失败的时候会进入重试循环。所以当它调用外部依赖的时候，熔断器是必须的。如果下游系统不健康，熔断器应该阻止 Agent 继续调用那个依赖。这不仅能保护下游，也能防止级联故障。

还有一个很多团队忽视的维度：预算。Agent 如果没有预算和费率限制，它会一直跑、一直重试、一直花钱。所以最大轮次、最大并行度、最大开销都必须设置，确保模型不会超出我们设定的预算边界。

模型聪明不等于系统安全

还有一个特别常见的反模式。构建 Agent 的时候，我们总是倾向于把能给的权限都给了，以为这样它就能完成任务。跟数据库交互？直接给它整张表的读取权限。然而，给它范围限定的凭证很重要。应该有单独的读写权限，并且应该有一个允许列表来限制它可以调用的工具。一个无害的模型，当它能执行不安全的操作时，就会变得危险。

人审批机制也一样。审批不能是一个一揽子的“同意”按钮。审批必须绑定到具体的动作、时间戳、执行者、过期时间。用户批准了一个 30 美元的退款，这个批准不能变成接下来批准 300 美元退款的授权，审批必须和当时请求的具体参数死死绑定。

可观测性是构建 Agent 的刚需，但很多人对它的理解还停留在“加日志”的层面。我想说清楚：日志不够用了。当 Agent 失败的时候，团队需要重建它当时发生了什么、它根据什么信息做出的反应、以及它为什么失败，仅凭日志是做不到这些的。

你需要追踪的是：调用了哪个模型、给了什么提示词、执行了哪些工具调用、发出了什么请求、工具返回了什么响应、遇到了什么错误、检索到了什么上下文、它基于这些上下文做了什么决定、执行了什么写入操作、拿到了什么审批。

我最后想说的是，是的，模型能力很重要。模型越好，做正确操作的概率越高，更聪明的模型能减少错误。但是模型能力不能消除网络失败、不能消除过期数据、不能消除对抗性输入。

构建这种架构的时候，我们需要问自己：我能约束 Agent 的行为吗？我能观察到它的行为吗？我能从它的错误中恢复吗？工具合约必须清晰定义请求和响应的类型、schema，并且把幂等性焊进去。这样当重复请求被发送进来时，不会导致不安全操作被重试。此外，当存在冲突的记忆状态时，应该做出基于真实数据源的决策。重试政策要有费率限制，确保 Agent 不会激进地重试。应该设置权限，应该有追踪和恢复路径。

在构建 AI Agent 的时候，最该问的一个问题其实是：当它犯错的时候，系统允许它做到哪个程度？

演讲原视频链接：

https://www.youtube.com/watch?v=hD9-V56FNRI

声明：本文为InfoQ 编译，不代表平台观点，也不构成投资建议，未经许可禁止转载。

会议推荐

QCon 全球软件开发大会·2026（上海站）现已正式启动。本届大会聚焦 Harness AI 时代的工程实践，从「构建 AI」到「驾驭 AI」，围绕 AI Native 架构、Agent Runtime、AI Infra、Agent 安全与可观测、Loop Engineering、具身智能与世界模型等热门技术方向，邀请全球技术社区与产业一线实践者，共同分享 AI Native 时代最具价值的工程经验。