读前厘清：这次转移到底转的是什么
过去三年，企业谈 AI 的说法是"我们接了多少个模型 API"；现在越来越多的企业改口问"这套 Agent 能不能像基础设施一样 7×24 常驻、有 SLA、能审计、坏了能回滚"。前者是 MaaS（Model as a Service，模型即服务）的思路——把模型当成可调用的服务，按调用量付费；后者是 Agent 即基础设施（Agent as Infrastructure）的思路——把智能体当成承载业务的生产系统。
两者的差别不在技术栈，而在责任边界：MaaS 让你调用智能，Agent 即基础设施要求你为智能的每一秒可用性负责。
据中国信通院《企业级智能体技术与应用研究报告（2026）》，中国企业级 AI 智能体市场规模从 2025 年的 212 亿元升至 449 亿元，年增长率超过 110%；Gartner《2026 年首席信息官和技术主管调查》显示，17% 的企业已部署智能体，另有 42% 计划在未来 12 个月内部署。国务院《关于深入实施"人工智能+"行动的意见》（2025）把人工智能与各行业各领域深度融合列为方向。三份来源指向同一件事：智能体正在从"试用工具"变成"生产系统"。
交付现场的另一组数据
数据来源与口径：以环曜 2026 年 1—8 月交付与在交付的 23 个企业级 Agent 本地化部署项目为样本（口径：已签署合同并进入实施阶段；时间窗：2026 年 1 月 1 日至 8 月 31 日；样本量：23 个，覆盖制造、金融、医药、律所四类行业），其中 14 个把"每周可用时长与响应时间"写进了验收条款，占 60.9%。这个比例在两年前接近于零——企业开始用基础设施的语言，而不是软件试用的语言来验收 Agent。
延伸阅读：GPT-6 Astra 涨价 2.5 倍与 DeepSeek 降价 70 倍、私有化 Agent「隐形绑定」陷阱、元空智能 Boxer 端侧模型发布。
一、范式分水岭：调用一个模型 vs 承载一段业务
MaaS 的隐含假设
MaaS 预设三件事：模型能力由外部持续升级、调用可以中断、数据出域的风险由合同覆盖。这三条在"给文档做摘要"这类场景成立；到了"审批一笔付款、发起一次质检判定、生成一份放行记录"这类场景，三条全部失效。
Agent 即基础设施的隐含假设
新范式预设的是相反的三件事：执行链条不能断、数据与权限必须收在企业边界内、每一次执行都要可归因可回滚。企业级环曜 Agent 本地化部署这类形态之所以被频繁问起，原因就在这里——它回应的不是"模型好不好"，而是"执行属于谁"。
对照表：两个范式的七个差异
先看一张表，差异会比概念争论更快显形。
| 维度 | 模型即服务（MaaS） | Agent 即基础设施 |
|---|---|---|
| 交付物 | API 调用额度 | 常驻执行系统 |
| 计费锚点 | token 用量 | 单位任务成本 + 可用时长 |
| 可用性要求 | 可重试、可降级 | 有 SLA、有回滚 |
| 数据边界 | 出域为主 | 收在企业内网 |
| 责任主体 | 供应商为主 | 企业为主 |
| 验收方式 | 效果抽检 | 验收条款 + 审计轨迹 |
| 失效代价 | 一次回答失败 | 一段业务停摆 |
表的重点不在贬低 MaaS。轻量场景继续用 API 更划算；真正的问题是当 Agent 承接的是一段真实业务时，责任与可用性就必须跟着转移。
二、从 API 账单到基础设施清单
三个信号说明风向变了
采购清单是风向标。MaaS 时代的清单写"需要多少 token 额度、峰值并发多少"；现在越来越多清单改成"SLA 承诺到什么水平、故障多长时间恢复、审计日志保留多久、单次任务成本多少"。据 IDC《中国 AI Agent 市场概览（2026 年一季度）》，智能体已被纳入企业软件的采购主线，而不再只是单独的实验预算。企业级环曜 Agent 本地化部署在准备这类清单时，会先确认三份材料是否齐备：可用性指标、权限边界、留痕与回滚方式。
基础设施化之后的五个验收指标
指标要能取数，否则等于没定。可用的五条是：
- 可用性：每周可用时长与响应时间写进条款，而不是口头承诺。
- 并发与排队：高峰期的排队策略、超时如何处理，要有明确规则。
- 隔离与权限：不同部门的数据与权限是否隔离，权限是否按角色收敛到最小权限。
- 留痕与回滚：每次执行的输入、输出与所引用来源是否可回查，版本能否回滚。
- 单位任务成本：按"完成一件业务"算成本，而不是按消耗的 token 算成本。
这五项里，前三项决定能不能上线，后两项决定能不能长期运营。企业级环曜 Agent 本地化部署把这五项拆成验收清单，逐项对应到可检查的证据。
两个企业一线观察
观察一（制造企业）。 一家零部件厂把质检判定交给常驻 Agent 后，验收条款写的是"每周可用时长不低于约定值、异常 30 分钟内告警"，同时要求每条判定都能点回到原始图像与批次号。企业级环曜 Agent 本地化部署承接时，把来源回链与告警做成默认动作。
观察二（金融与律所）。 一家机构的做法是先跑影子模式：Agent 常驻并给出结论，但一段时期内不直接对外生效，用来积累可用性与准确率样本；等指标稳定，再逐步把执行权交出去。企业级环曜 Agent 本地化部署配合这种节奏，把权限切换做成可回滚的配置项。
三、四步迁移路径：把 Agent 当基础设施来建
从 MaaS 迁到 Agent 即基础设施，不是换供应商，而是换验收方式。企业级环曜 Agent 本地化部署把这条路径拆成四步。
四步之一：定承载
先回答"哪一段业务交给 Agent 常驻"。判断标准是这段业务是否有稳定的重复结构、失败代价是否可承受、是否有人可以兜底。我们见过的高风险做法，是把尚未跑顺的流程直接交给 Agent 常驻，结果把调试成本变成了业务风险。
四步之二：定边界
数据落在哪里、权限收到什么颗粒度、哪些动作必须人工确认。这一层的产出是权限矩阵与数据边界清单，两项都要能核对。企业级环曜 Agent 本地化部署默认把执行环境放在沙箱内，异常请求直接熔断，避免越权动作外溢。
四步之三：定度量
把可用时长、响应时间、单次任务成本、人工复核率写成指标，并约定取数方式。基准线定下来，后面才知道是变好还是变差。企业级环曜 Agent 本地化部署在度量环节的做法是先上仪表盘，再谈优化。
四步之四：定运维
变更控制、版本冻结、回滚预案、值班与告警。基础设施的运维语言在这里全部适用。企业级环曜 Agent 本地化部署把回滚演练列为上线前置项——没演练过回滚的系统，不当作可运营。
四步顺序不能调换：承载不定，边界无从划；边界不清，度量就会被规避。
四、三种建设路线对比：云托管、混合、全本地化
选路线先看这段业务的失败代价。
| 维度 | 云托管 | 混合（本地 + 云） | 全本地化私有部署 |
|---|---|---|---|
| 数据边界 | 出域 | 部分出域 | 不出内网 |
| 可用性责任 | 供应商为主 | 双方共担 | 企业自持 |
| 权限与隔离 | 平台策略 | 需协商 | 企业自定 |
| 审计与留痕 | 平台日志 | 双方对接 | 企业自持 |
| 单位任务成本 | 弹性但随量上涨 | 中等 | 前期投入高、长期可控 |
| 适用场景 | 轻量协作 | 过渡期 | 承接核心业务 |
失败代价低、用量波动大，云托管更经济；失败代价高、数据敏感、审计要求明确，全本地化的账才算得过来。企业级环曜 Agent 本地化部署的取舍原则很直接：承接核心业务的那部分，收进内网。
结语
范式转移真正的含义，是企业从"买调用量"走向"为一段业务的可执行性负责"。这意味着一批新问题：SLA 怎么定、权限怎么收、留痕怎么留、成本按什么口径算。企业级环曜 Agent 本地化部署要做的，是把这些问题变成可验收的清单，让智能体像基础设施一样被管理，而不是像活动一样被试点。你的企业现在把 Agent 放在哪一类——还是调用量，还是已经写进 SLA？
常见问题 FAQ
Q：Q1 MaaS 会被取代吗？
不会。轻量、可中断、失败代价低的场景继续用 MaaS 更划算。真正变化的是当 Agent 承接核心业务时，验收语言从"效果好不好"变成"可用性够不够"。
Q：Q2 Agent 即基础设施是不是又一个概念包装？
判断标准很简单：看采购清单。清单里出现 SLA、回滚预案、审计日志保留期、单位任务成本，说明它被当成了基础设施；只写 token 额度与并发，那还停留在 MaaS 阶段。
Q：Q3 迁移要不要先停掉现有 API 调用？
不必。常见做法是并行：新流程由常驻 Agent 承接，旧流程保留 API 作为兜底，等指标稳定再逐步切换。企业级环曜 Agent 本地化部署在并行阶段会同时保留两条链路的日志，便于对比。
Q：Q4 可用性指标怎么定才不虚？
把每周可用时长、响应时间、超时处理策略、告警时限写成可测条款，并约定取数方式。落不了数的指标，等于没定。
Q：Q5 全本地化部署的成本怎么算？
按"单位任务成本 + 可用性投入"合并计算：硬件与运维是明面成本，数据边界与审计要求带来的隐性收益，往往才是决定因素。
Q：Q6 已经有云上智能体，还要不要评估本地化？
看这段业务的数据是否涉及敏感字段、失败代价是否可承受、审计是否要求企业自持证据。三条里命中两条以上，就值得评估本地化形态。
