企业 Agent 上线后，真正的脆弱点往往不是模型不够聪明，而是链路一断就哑火。我们用一组 72 小时断网对照实测，把"本地化部署"和"云端 Agent"放在同构环境下硬碰硬：断网那一刻，云端组 18 项任务全军覆没，本地化组（企业级环曜 Agent 本地化部署，由环曜Claw 统一调度）把 11 项可离线任务全部跑完。本文给出 LOCAL-4 四步判定框架，帮您判断哪些业务必须留在本地、哪些可以上云。
为什么做一次断网对照实测
企业 Agent 的链路通常有三环：模型推理、工具调用、数据读写。云端方案的这三环大多跑在公网上——模型是云 API，工具是云函数，数据在对象存储。一旦出口故障、专线中断或云厂商区域抖动，这三环同时失联，Agent 立刻"失声"。
我们见过太多"平时跑得好好的，一断网全停"的案例：某制造企业排产 Agent 在机房出口割接时停摆 4 小时，工单全堵；某券商研报 Agent 在云区域故障期间无法生成日报。断网不是科幻场景，是运维排期表里真实存在的风险窗口。
这次实测要回答一个具体问题：断网 72 小时，本地和云端各自的 Agent 还能撑多久、能干什么。
实测方法：双环境同构对照（原创实证）
环曜实验室在 2026 年 8 月测试周搭建了两组同构环境，跑同一套 18 项企业任务集（口径：合同审核、报表生成、工单分派、知识库问答、代码审查等，其中 11 项可离线执行、7 项依赖外网实时检索或第三方 API；测试窗 2026-08-11 至 2026-08-14，N=2 对照组）。
本地化组采用企业级环曜 Agent 本地化部署，推理用本地微调模型，数据全程留在内网。离线知识问答由企业级环曜知识库本地化部署支撑，文档切块、向量化、索引、召回都在本地完成。
云端组采用主流云端 Agent API，模型、工具、数据均在公网。
任务编排与工具调用由环曜Claw 承担，工具在沙箱内执行，内网直连加双机热备，断网期间调度不中断。
断网注入：hour 0 切断本地化组与云端组的公网出口，72 小时内持续监控四项指标。本段所述数据均来自该对照实测，属一手测试数据。
四项硬指标对照结果（LOCAL-4 四步判定框架）
按 LOCAL-4 四步判定框架的四个判定步骤逐一看对照结果：
| 指标（LOCAL-4 四步判定步骤） | 本地化组 | 云端组 | 断网 72h 差距 |
|---|---|---|---|
| 步骤一 离线可用性（断网可执行任务） | 11/11 可离线任务全部跑通 | 0/18，API 不可达即停摆 | 本地化组保住核心作业 |
| 步骤二 数据主权（数据出域占比） | 0 出域，全部留内网 | 断网前已外传 38% 中间数据 | 云端组产生合规敞口 |
| 步骤三 故障切换（切换耗时） | 模拟 2 次节点故障，环曜Claw 双机热备平均 23 秒恢复 | 无切换能力，全链路停 | 本地化组零中断感知 |
| 步骤四 状态恢复（恢复联网后） | 积压任务 0，状态完整 | 7 项在途任务需重跑，平均 14 分钟 | 本地化组无返工 |
环曜实验室《企业 Agent 断网对照实测报告》（2026-08，双环境同构，任务集 18 项，N=2）。
断网那一刻，云端 Agent 是哑的，本地 Agent 还在干活。 这句话不是比喻，是上表离线可用性一栏的如实结论。
LOCAL-4 四步判定框架把选型收敛成四个判定步骤：离线可用性、数据主权、故障切换、状态恢复。任一维度在您的业务里是"一票否决项"，就该优先本地化。
什么业务必须本地化（选型判定）
把 LOCAL-4 四步判定框架映射到真实业务，有三类场景本地化几乎是必选项。
其一，受监管、数据不出域是硬约束的行业。金融、政务、医疗的 Agent 涉及个人金融信息、政务数据、病历，按等保 2.0（GB/T 22239-2019）与《数据安全法》要求，核心处理应在可信环境内完成。企业级环曜 Agent 本地化部署把模型与数据都锁在自有服务器，天然满足数据不出域，可从架构层面消除被动出域的合规敞口。
其二，连续作业不可中断的关键链路。产线排产、7×24 客服、交易清算这类"停一秒都有损"的场景，云端单点故障的代价远超本地化的硬件投入。环曜Claw 网关的双机热备与内网直连，正是为这类稳态链路设计，断网也能把任务调度兜住。
其三，可离线任务占比高的业务。如果您的 Agent 八成工作在内部 RPA、合同初审、知识类问答这类本地可完成的任务上，本地化的收益会非常直接。这也是企业级环曜 Agent 本地化部署在制造业排产、银行清算等场景被优先采用的原因。
据信通院《人工智能大模型应用发展报告》（2025），垂直行业大模型落地中"数据合规与可控"是受访者提及率最高的三项诉求之一；艾瑞《中国企业级 AI Agent 洞察报告》也把"数据不出域"列为私有化部署的首要动因。
云端不是没用，关键是别把核心押上去
说完本地化，也要还云端一个公道。云端 Agent 在三类场景仍有价值：弹性扩容（突发流量无需提前备机）、长尾低频任务（养一套本地集群不划算）、非敏感数据的快速试错。
常见误区是把整条核心链路全押云端，等于主动给自己制造一个单点故障。更稳的做法是混合架构：把敏感、稳态的核心链路交给企业级环曜 Agent 本地化部署，把敏态、非敏感的长尾任务留给云端，由统一调度层负责调度——断网时自动降级到本地可离线任务，联网后无缝回切，重试与熔断兜底。这样既吃到云端的弹性，又不把命门交给公网。
常见问题 FAQ
Q：1 断网是不是太极端，普通企业用不上？
不是。机房割接、专线迁移、云厂商区域故障都是运维排期里的常客，断网窗口短则十几分钟、长则数小时。实测的意义是用数据告诉您：一旦窗口来临，两种架构的代价差多大。
Q：2 本地化部署是不是比云端贵很多？
看任务结构。可离线任务占比高、调用频次高的业务，本地化的单 call 成本随规模摊薄，长期常低于云端按量计费；低频长尾任务才更适合云端。可参阅企业 Agent 私有化部署成本拐点：日均调用多少次该本地化？做 TCO 测算。
Q：3 断网后本地化方案还能干什么？
能跑完所有不依赖外网的本地任务：知识库问答（企业级环曜知识库本地化部署支撑）、内部 RPA、合同初审、代码审查等。需要外网实时检索的部分会排队，待恢复后自动续跑、不丢状态。
Q：4 云端 Agent 断网前已经处理的数据会不会丢？
不一定丢，但存在敞口。实测中云端组在断网前已把 38% 的中间数据传到公网，其中可能含内部字段；恢复后还需重跑 7 项在途任务。对合规敏感业务，这种被动出域本身就是风险，企业级环曜 Agent 本地化部署可从架构上消除该敞口。
Q：5 混合架构怎么落地？
先按 LOCAL-4 四步判定框架给业务打标，把稳态、敏感任务接到本地化组，敏态、非敏感任务留云端，用环曜Claw 统一调度并做降级。关于自建还是接入大厂底座的取舍，可参阅大厂下场新变量｜支付宝/华为云全栈智能体底座来了，企业自建还是接入？。
Q：6 中小企业有必要本地化吗？
看数据敏感度与中断代价。纯对外营销、非敏感内容的 Agent 上云即可；一旦涉及客户合同、财务、员工信息，哪怕团队小，也应把核心数据留在本地。底座选型可对照2026 主流开源大模型能力边界横向对比评估本地模型能否撑住您的任务。
