断连代理模式：为不稳定的网络环境进行设计

空乘人员要求你切换到飞行模式。你的团队上季度交付的客服代理正在一个标签页中对话到一半，接下来的用户回合却返回了一个永远无法解决的加载动画。这个智能体并没有以任何有趣的方式崩溃。它只是在一百个未写明的细节中假设了网络是存在的。

这个假设是你的产品团队从未写下的最昂贵的代码行。它支配着你如何存储对话状态、如何调用工具、如何呈现错误、你针对什么进行评估，以及当连接在对用户重要的工作过程中中断时，用户会怎么做。“离线智能体模式”是一种将这一假设从基础架构中抽离出来、审视它，并明确决定当通往托管 API 的往返不可用时应该发生什么的纪律。

围绕 AI 智能体的论述一直建立在“前沿模型”的框架之上：托管在别人数据中心、可通过 HTTPS 访问的最强模型。这种框架对于演示和营销网站来说没问题。但当你的产品遇到用户生活的实际物理环境时，它就会崩溃。飞机上的笔记本电脑。地下室混凝土墙后的现场技术人员。每晚会自动重启的 Wi-Fi 路由器后的零售自助终端。运行在具有深度数据包检测、会随机中断流式连接的访客网络上的医院平板电脑。穿过隧道的汽车。这些地方都是使用 AI 功能的合理场景，而这些地方，“每一步都往返托管 API”并不是一个可行的假设。

你的团队从未写下的构建时假设

如果你问构建智能体的人：“当网络消失时，系统会做什么？”，你通常会得到一个漫长的停顿，然后是一个听起来像是在猜测的答案。停顿就是迹象。离线情况并未经过设计；它是框架在 fetch 失败时碰巧做出的反应。这几乎绝不是你想要的。

当你去观察时，通常会发现：对话历史仅存在于服务器上，因此断网后的刷新会清空历史。下一个用户回合调用托管模型，遇到网络错误，并渲染一个通用的“出了点问题”提示，没给用户提供任何可操作的信号。工具调用——那些起草邮件、提交工单、安排回访的操作——是在智能体循环中同步发出的，因此当网络消失时，智能体根本无法执行操作，也没有等待冲刷的队列。用户认为已经提交的状态（保存的草稿、置顶的答案、配置好的计划）存在于不稳定的内存状态中，并在重新连接时消失。“加载中”的 UI 是用户获得的唯一反馈，而且它无法区分“模型正在思考”和“网络已经中断了 40 秒”。

这都不是框架的 bug。这是由于没有人做出设计决策的结果。离线行为只是从“网络始终存在”的构建时假设中衍生出来的产物。

离线优先架构的四步走

将断网视为一等状态（first-class state）而非错误情况，需要四种架构转变。每种转变都改变了大多数智能体技术栈自带的默认设置。

位于核心路径（hot path）上的本地模型，在可连接时使用云端增强。 1B–3B 参数规模的小语言模型已经跨越了处理常规智能体任务的可用性门槛。像 Phi-3 Mini、Gemma 3n 2B 和 Llama 3.2 1B/3B 这样的模型可以运行在通用硬件上，占用 1–2 GB 内存，在 M 系列 Apple 芯片和现代移动 NPU 上以每秒数十个 token 的速度解码。它们在处理困难推理方面不是 GPT 级别的，也不需要是。它们只需要足够好，能够处理上下文回答、线程摘要、起草回复等占据智能体大部分工作量的任务，而云端模型则保留给真正需要它的长尾查询。架构上的反转是重点：本地模型是默认路径；托管模型是在连接允许时分层其上的增强。大多数团队的做法恰恰相反。

带延迟副作用的队列化工具调用。 当智能体决定提交工单、发送消息或更新记录时，该调用在触及网络之前应进入一个持久化的发件箱（outbox）。该发件箱是一个预写日志：一个仅追加（append-only）的预期副作用记录，每一项都带有一个稳定的客户端生成标识符，以便在服务器上实现重试幂等。当连接恢复时，同步工作线程通过退避（backoff）、去重以及对服务器乱序接收的条目进行显式冲突解决来消耗队列。用户在意图被捕获的那一刻就得到反馈，而不是在副作用落地时。这在离线优先的移动开发领域是成熟的领地；AI 智能体栈只是晚了十年才重新发现它。

用户可见的功能降级阶梯。 “无网络”用户体验最糟糕的版本是一个单一的布尔值：在线或损坏。真实的断网是一个频谱。有时本地模型可以回答。有时本地模型可以回答，但工具调用后端无法触达。有时关键文档位于未在本地镜像的远程向量库中。有时连接通畅但延迟高到无法使用。每一种都是不同的能力阶梯，UI 应该明确暴露用户当前处于哪一阶梯——通过一个显眼的小图标或状态行。如果用户明白自己处于降级模式，他们会容忍。他们不会容忍一个在自身能力上保持沉默并撒谎的智能体。

内存和状态的最终一致性语义。 如果智能体拥有记忆——置顶的事实、用户偏好、先前的上下文——并且这些记忆可以从多个地方（手机、笔记本电脑、网页）修改，那么你就面临着一个分布式系统问题，其形式与任何多设备同步产品相同。CRDT 和事件溯源状态（对话是 prompt、工具调用和结果的仅追加日志）为你提供了一个确定性的合并方案。另一种选择——在单个可变记录上采用“最后写入者胜”——在两个设备重新上线且其中一个静默覆盖另一个的工作之前运行良好。基于 SQLite 的本地存储配合 CRDT 同步层现在已经足够成熟，这不再是一个研究项目，而是一个库的选择。

将飞行模式作为一等公民的测试环境

大多数 Agent 评估套件都假设网络存在，并在拥有网络的环境中运行。结果就是，断连路径成为了产品中最大的未经测试的领域。团队发现 Bug 的方式和用户如出一辙：在实际现场，在最糟糕的时刻。

将飞行模式视为一等公民的测试环境意味着几件具体的事情。评估框架应包含以下场景：网络在轮次中途断开、在工具调用中途断开、在流式传输期间断开，以及在长时间运行的后台同步期间断开。它应该包括延迟很高但并非无限的情况——即移动用户在一天中有相当长一段时间所处的“技术上在线但功能上无效”的连接长尾。它还应该包括网络恢复后，积压的排队操作需要按顺序处理的场景，评估需要对功能正确性和处理过程中的用户感知体验进行评分。

AI Agent 的混沌工程是一个年轻的领域，但来自更广泛的基础设施领域的经验可以完美迁移：在 CI 中持续注入故障，并对用户可见的结果（而不不仅仅是内部异常）进行断言。注入点有所不同——失败的工具调用、模型超时、流式传输断开、部分响应——但原则是一样的。一个只在良好网络条件下测试过的 Agent，等于没有经过测试。

有一种特定的失败模式值得关注：在运行断连场景的评估时，观察到 Agent 返回了“某些”答案，并将其评定为通过。本地模型产生了输出，所以测试显示为绿色。但答案是错误的，因为 Agent 在一个需要 70B 模型的问题上静默回退到了 1B 模型，而测试框架中没有任何环节检查模型的降级。评估评分需要区分“在可用能力下正确回答”和“仅仅是回答了”，能力降级梯度需要纳入评分标准中。

云端和本地之间的接缝究竟在哪里

在断连 Agent 架构中，最难的设计问题不是“是否”要有一个本地模型，而是“路由决策发生在何处”以及“谁能看到这个接缝”。目前出现了三种模式。

第一种是静默回退：Agent 在可行时运行在云端，不行时运行在设备端，用户永远不知道是哪种。这种模式最容易发布，但最难运维。当单个用户的质量出现退化时，你完全不知道他们是通过本地路径还是云端路径提供服务的。调试全靠猜测。

第二种是带有可见指示器的显式路由：用户会看到一个小图标，告诉他们当前处于哪种模式，评估套件会分别跟踪每种模式的质量。这更诚实，也更易于调试。事实证明，这也更容易获得用户的信任——用户往往会原谅他们理解的降级模式，而会反感一个莫名其妙表现不佳的单一模式。

第三种是用户控制模式：用户显式选择“快速本地”还是“最佳云端”，就像他们目前选择推理强度或模型大小一样。这对于高级用户来说效果很好，但对其他所有人来说都很糟糕，而且它只是将路由问题推给了用户，而不是解决它。大多数产品最终会采用第二种模式——将显式路由作为一种状态而非设置展示出来——因为它在可操作性和用户负担之间找到了平衡点。

云端和本地之间的接缝也是你的架构决定 Agent 是一个产品还是两个产品的地方。如果本地 Agent 和云端 Agent 共享相同的会话日志、相同的记忆模式、相同的工具注册表和相同的评估套件，那么它们就是一个拥有两个后端的单一产品。如果它们发生分歧——不同的工具集、不同的记忆、不同的 Prompt——那么你实际上发布了两个 Agent，而用户成了它们之间的集成层。后者是团队默认会走向的结果，也往往是接缝处最严重 Bug 的源头。

这对路线图有何改变

断连 Agent 模式不是你在云端版本完成后才额外附加的一个功能。这是一种架构承诺，必须在你发布数据模型之前就确定下来，因为后期重构需要改变状态的存储方式、工具的调用方式、UI 反馈的结构以及你的评估方式。一个先发布纯云端版本并计划“稍后添加离线支持”的团队，几乎总是会发现“稍后”意味着“重写 Agent”。

在产品层面，这意味着“此产品是否应支持离线？”这个问题不是一个功能勾选框，而是对产品本质的一种定调。手机上的消费级聊天应用必须假设会断连。在飞机上使用的开发工具必须假设会断连。安装在加固平板电脑上的现场服务应用必须假设会断连。使用消费级 Wi-Fi 的零售自助终端必须假设会断连。网络稳定存在且带宽充足的产品集合，其实比大多数 Agent 技术栈的架构决策所暗示的要小得多。

以前，当 AI 产品存在于办公室桌面上的浏览器标签页中时，网络存在的假设是合理的。但对于 AI Agent 正在走向的领域——手机、笔记本电脑、自助终端、车辆、设备以及用户实际所在的任何地方——这就不再合理了。那些明确写下这一假设、正视它并决定断连行为应当如何的团队，将发布在用户生活场景中真正可用的产品。而那些不这样做的团队，发布的产品只会在演示中运行良好，在实际使用中却漏洞百出。

选择一个视角：网络除非证明不存在，否则就是存在的；或者，网络除非证明存在，否则就是不存在的。第一种视角产生了 2024 年的 Agent 技术栈。第二种视角则是 2026 年所要求的。