摘要

组织在构建领域环境上投入巨大——工具、数据管线、知识库、访问控制、操作流程——这些构成了一个特定领域运转的基础。但一旦建成，如何将这些环境的能力分发给在环境之外工作的用户，是一个未被解决的问题。现有方案——平台 UI、REST API、工具服务器——各自在能力与可及性之间做出妥协。

我们提出环境即服务（Environment as a Service，EaaS），一种通过在环境内部嵌入 AI 智能体并将其作为服务接口来分发环境能力的架构。调用方——通常是另一个代表用户行动的 AI 系统——通过自然语言与服务智能体通信。该智能体拥有对环境内工具、数据、知识和安全策略的受中介的访问权，处理请求并返回结构化结果。

这一设计决策——以智能体为接口——同时实现了三个通过工具级接口不可能同时达成的性质：

  1. 能力抽象：调用方无需理解环境的工具栈、数据模型或操作流程。
  2. 语义安全：安全边界由一个理解意图的智能体执行，而非仅检查权限——且调用方永远不接触领域凭证。
  3. 知识放大：每一次交互都丰富环境积累的知识，惠及未来所有调用者，无论其入口在哪里。

我们进一步论证，EaaS 不仅是一种更好的架构，而且是一种必需的架构。在 AI Agent 环境本质上不安全的世界里——面临供应链攻击、prompt injection 和凭证窃取的威胁——任何将工具或凭证分发到调用方环境的架构都是在分发攻击面。EaaS 是唯一不向调用方分发底层工具、凭证或攻击面而使环境能力可及的模式，因为跨越边界的唯一东西是语言。

我们以一个面向数据分析的生产级领域智能系统为基础阐述 EaaS，但该架构与领域无关。这一模式适用于任何存在丰富运营环境、且外部用户需要在不采纳其接口的前提下获取其能力的场景。

1. 分发问题

当一个团队构建领域环境时，他们实际上是在集聚一种惊人的能力密度：数据库和查询引擎、可视化工具、实验平台、监控仪表盘、ETL 管线、积累的标准操作流程，以及——越来越重要的——一整套在运营中习得的机构知识。环境之所以强大，恰恰在于一切都是连通的：查询引擎知道哪些表是可靠的，SOP 知道每种任务类型的正确工作流，知识库记得数月运营中发现的边界情况。

这种能力被锁在环境内部。

在 Jupyter Notebook 中工作的数据科学家无法获取它。在 IDE 中工作的工程师无法获取它。使用自己偏好的 AI 助手的产品经理无法获取它。要使用环境的能力，他们必须离开自己的工具、进入环境的界面、学习它的约定、在它的约束中工作。

这造成了一个组织层面的悖论：环境越强大，对在其外部工作的用户制造的摩擦就越大。 环境的能力既是最大资产，也是分发的瓶颈。

这个问题不是狭义的技术问题——它是架构问题。如何在不要求用户身处其中的情况下，分发环境的能力？

2. 现有方案及其局限

目前存在三种方案。每种做出不同的取舍，没有一种解决了根本张力。

2.1 平台 UI

最常见的方案：构建一个 Web 应用作为环境的前端。用户登录、通过 UI 交互、访问环境的全部能力。

这对在平台内工作的专职用户效果很好。但对偶尔使用的用户、偏好不同工具的用户、工作流横跨多个环境的用户来说，它是失败的。一个在 Notebook 中分析数据的数据科学家不愿意为了查一个指标定义就切换到一个独立的 Web UI，然后再切回去继续分析。

平台 UI 也是投入最高的方案：每个新能力都需要构建新的 UI 界面，UI 本身也成为维护负担。

2.2 API 和 SDK

工程化方案：将环境的能力暴露为 REST 或 GraphQL 端点，可选地封装成特定语言的 SDK。用户从自己的工具中调用 API。

这对定义清晰的原子操作有效——创建一个报表、执行一个查询、获取一个指标。但领域环境之所以有价值，恰恰在于它支持复杂的、需要判断力的多步骤工作流：选择正确的数据源、应用正确的指标定义、根据已知的边界情况验证结果、遵循特定任务类型的 SOP。

API 暴露的是动作。它不暴露判断力。一个不理解环境数据模型、指标定义和操作惯例的调用方，会错误地使用 API——不是因为 API 不好，而是因为领域专业知识无法被序列化到端点文档中。

2.3 工具服务器和 MCP

AI 原生方案：通过 MCP（模型上下文协议）等协议暴露环境的工具，允许 AI 系统发现并调用它们。调用方的 AI 智能体遍历可用工具、理解其 schema、编排它们来完成任务。

这是最接近 EaaS 的现有方案，值得精确理解它差在哪里。

编排负担落在调用方身上。 当一个 AI 系统发现一个有二十个工具的工具服务器——搜索报表、执行查询、获取卡片元数据、创建草稿、管理管线——它必须决定使用哪些工具、以什么顺序、用什么参数。这需要调用方 AI 不具备的领域知识。它不知道"先搜索索引，再获取元数据，再运行报表"是正确的工作流。它不知道哪个数据源对于留存查询更可靠。它不知道报表优化的 SOP。

安全在工具级别，不在意图级别。 工具服务器按工具执行访问控制：这个 token 能调用这个端点吗？这无法区分"查一下上周留存率"和"导出所有用户邮箱"。两者都是对同一个查询工具的调用，只是 SQL 不同。

知识无法传递。 即使环境积累了数月的机构知识——指标定义、数据源可靠性评估、边界情况警告——这些知识在工具接口中无法获取。调用方的 AI 是在没有知识的情况下运作的。

简言之，MCP 和工具服务器暴露的是没有上下文的机制。它们给调用方提供工具，但不给如何使用的知识、何时使用的判断力、以及什么不该做的安全意识。（第 9 节给出了更深入的结构性分析，说明为什么这一差距在 MCP 的架构内无法弥合。）

3. 环境即服务

我们提出一种不同的方案。不暴露环境的工具，而是暴露环境本身——通过一个生活在环境内部的 AI 智能体。

3.1 以环境为服务单元

关键的概念转变在于什么构成服务边界。

在 API 中，服务单元是函数：一个端点、一个操作、一个响应。

在工具服务器中，服务单元是工具：一个能力，可发现可调用。

在 EaaS 中，服务单元是环境：完整的运营上下文——工具、数据、知识、流程、安全策略——由一个理解所有这些的智能体中介。

调用方不与单个工具交互。调用方通过环境的智能体与环境交互。这个区别的重要性，如同雇佣一个领域专家和订阅一套工具箱的区别。专家带来判断力、上下文和积累的经验。工具箱只带来机制。

3.2 以智能体为接口

EaaS 的决定性设计决策是：调用方与环境之间的接口是一个 AI 智能体。

这个智能体不是工具的薄封装。它是一个完整的推理系统：

关键洞察是：这不仅仅是一个便利层。以智能体为接口从根本上改变了服务的性质。

在工具接口下，服务的质量上限由调用方的领域知识决定。一个不理解工具的调用方会用错工具，无论工具本身有多好。

在智能体接口下，服务的质量上限由环境的领域知识决定——如第 5 节所论证的，这种知识随时间复合增长。调用方只需要描述意图。智能体提供专业能力。

3.3 双 AI 委托模式

EaaS 自然催生了一种新的计算模式：两个 AI 系统通过自然语言协作，各自精通自己的上下文。


用户 ←→ 调用方 AI ←→ EaaS 智能体
        （用户上下文）    （领域上下文）

调用方 AI——运行在用户的环境中（Notebook、IDE、终端、或另一个 AI 助手）——理解：

EaaS 智能体——运行在领域环境内部——理解：

两个 AI 都不需要理解对方的领域。调用方 AI 不需要知道 Metabase 怎么工作。EaaS 智能体不需要知道用户在运行什么 Notebook。自然语言是它们之间的协议，这是充分的，因为每个系统都在意图层面运作，而非机制层面。

这个模式与函数调用、API 组合或工具编排有本质区别。那些模式要求调用方在结构层面理解被调用方的接口。双 AI 委托模式只要求在语义层面的理解——要什么，而非怎么做。

来看一个具体例子。一个数据科学家在 Jupyter Notebook 中问他的本地 AI 助手："我们上周的 7 日留存是多少？和上个月比怎么样？"

没有 EaaS，本地 AI 需要：发现该查询哪个工具、理解留存指标的定义、知道该用哪张表、写正确的 SQL、处理比较逻辑、验证结果。它不具备这些知识。

有了 EaaS，本地 AI 发一条自然语言请求给 EaaS 智能体。EaaS 智能体查阅环境的知识库获取留存指标定义，选择合适的已保存报表或写一个经验证的查询，执行它，与历史基线比较，返回一个包含数字、对比和注意事项的结构化结果。本地 AI 将这些格式化到 Notebook 中。

每个 AI 做了它最擅长的事。都不需要理解对方的环境。

4. 语义安全边界

EaaS 引入了一种与工具级接口有质的差异的安全模型。我们称之为语义安全边界：一个基于请求含义而非其机械形式做出访问决策的安全周界。

4.1 从动作级到意图级的安全

API 和工具服务器中的传统安全运作于动作级别：

这是必要但不充分的。同一个工具——一个 SQL 查询端点——既能用来"查上周留存率"，也能用来"导出所有用户 PII"。两者在语法上完全相同：使用不同 SQL 的查询工具调用。动作级安全无法区分它们。

EaaS 的安全运作于意图级别。服务智能体在执行前评估每个请求的含义：

这只有在接口是一个理解自然语言的 AI 智能体时才可能。一个工具端点接收结构化参数，无法推理意图。一个智能体接收自然语言请求，可以评估其目的、其合理性、以及与调用方历史的一致性。

4.2 凭证隔离

在 EaaS 中，调用方的 AI 永远不接触领域凭证。数据库密码、API key、服务 token、连接字符串——全部留在环境边界内。调用方仅持有一个短生命周期的身份 token——这在认证意义上是凭证，但不携带任何领域级权限：它不能查询数据库、调用内部 API、或直接访问任何服务。调用方以人的身份认证；服务智能体在内部将该身份映射到适当的凭证。

这消除了困扰工具级接口的一整类安全风险：

在工具服务器模型中，分发能力就需要分发凭证——或构建复杂的代理认证层，而这些层本身就是攻击面。在 EaaS 中，凭证边界和服务边界是同一个东西。

4.3 绑定身份的短生命周期访问

EaaS 认证模型围绕三个原则设计：

  1. 每个请求绑定到真实的人类身份。 不是共享的 API key，不是服务账号，而是具体的人。这使得细粒度的访问控制和完整的审计追踪成为可能。
  1. 访问 token 短生命周期。 典型的 token 有效期为八小时——一个工作 session——意味着被泄露的 token 在造成持续损害之前就会过期。用户在每个工作日开始时通过基于浏览器的 OAuth 流程认证。
  1. 环境控制身份到权限的映射。 当请求带着用户身份到达时，服务智能体在内部决定该用户可以访问什么。这个映射维护在环境内部，对调用方不可见。

这个模型有意类似 gcloud auth login 或 gh auth login 的工作方式：通过浏览器以自己的身份认证，获得一个短生命周期的 token，使用到它过期为止。用户已经熟悉这个模式。新的地方在于：token 授予的不是对原始 API 的访问，而是对一个中介每一次交互的智能体的访问。

4.4 环境内部的分层防御

语义安全边界不是单一检查点。在环境内部，安全分层运作：

  1. 入口拦截：请求级验证、频率限制、异常检测。语法畸形、异常大、或在异常模式下到达的请求，在到达智能体之前就被标记。
  1. 意图评估：服务智能体——或专门的安全智能体——评估请求对于调用方的身份和角色是否合适。这是语义层：理解请求意味着什么，而非仅仅要求什么。
  1. 执行限制：智能体使用限定在经认证用户范围内的凭证和权限执行。即使智能体的推理被攻破，也无法超越用户的授权访问级别。
  1. 输出过滤：在结果返回之前，一个过滤流程确保敏感信息——凭证、内部服务地址、超出用户权限的 PII——不包含在响应中。
  1. 定期审计：后台进程审视积累的请求和响应历史，发现单次请求评估可能遗漏的模式：渐进式数据窃取、系统性探测、或使用模式偏移。

这种纵深防御在 EaaS 中是自然的，因为服务智能体控制着整个请求生命周期。在工具服务器模型中，每个工具各自负责自己的安全，跨工具的安全关注点（如检测多步骤的窃取模式）就会从缝隙中漏掉。

5. 知识放大效应

领域环境不仅包含工具和数据。随时间推移，它们可以积累知识——关于事物如何运作、正确方法是什么、陷阱在哪里的机构性理解。一项独立的工作——自演化知识引擎（Self-Evolving Knowledge Engine，SEKE）——探索了如何使这种积累自主化：不依赖人工策编，而是让智能体从自身的工作中学习领域知识，将其组织到一棵结构不断演化的语义树中，通过对抗性审查精炼，并在人类宪法性决策的治理框架内运行。核心论题是：通用智能 + 能力接口 + 领域知识 = 领域智能——一个拥有知识引擎的系统可以无需定制训练或手工知识库而自举成为领域专家。（完整论述参见《从智能体到领域智能：自演化知识引擎》。）

当 EaaS 背后的环境包含这样的知识积累系统时，EaaS 就会产生强大的放大效应。

5.1 更多入口，同一个知识池

没有 EaaS 时，只有环境原生界面的用户为知识积累做贡献。每一个回答的问题、发现的边界情况、优化的工作流都反馈到知识系统——但只通过一个渠道。

有了 EaaS，每一个外部调用方也在贡献：

知识系统不区分来自原生 UI 的请求和来自 EaaS 的请求。所有交互都产生工作轨迹。所有工作轨迹都供给知识进化循环。更多入口意味着更多交互、更多元化的问题、更快的知识积累。

5.2 飞轮

这创造了一个自我强化的循环：


更多入口（EaaS）
→ 来自多元上下文的更多交互
→ 更丰富的知识捕获素材
→ 更好的知识库
→ 更好的服务质量
→ 更多用户采用 EaaS
→ 更多入口

这是一个正反馈循环，但——重要的是——知识系统本身通过负反馈运作：错误产生不正确的结果，现实施加反推（用户质疑答案、查询返回与预期不符的数字），知识随之被修正。正循环在于采用和输入多样性；负循环在于知识质量。两者共同产生一个在覆盖范围和准确性上同时增长的系统。

5.3 跨上下文的知识迁移

EaaS 实现了一种在隔离的工具访问中不可能存在的知识迁移形式。当一个使用平台 UI 的用户发现了一个工作流优化，这个知识进入知识树。当一个 Notebook 用户后来通过 EaaS 遇到类似任务时，智能体检索并应用该知识——即使两个用户从未交互过，且使用完全不同的工具。

知识不锁定在任何单一用户的环境中。它生活在服务的环境中，通过智能体的中介对每一个调用方可用。这与文档（用户必须找到并阅读）或 API 变更日志（描述的是机制，不是判断力）有本质区别。知识在相关时由智能体自动应用——对调用方不可见，但塑造着每一次响应的质量。

6. 参考架构

尽管具体实现因领域而异，EaaS 有一个一致的架构结构。

6.1 组件

环境包含：

EaaS API 层提供：

认证层提供：

客户端集成可以采取多种形式：

注意 MCP 封装：这是在客户端边界的 MCP，封装一个调用 EaaS 智能体的单一 ask 工具。这与将环境工具暴露为 MCP 有本质区别。调用方的 AI 看到的是一个工具（"问领域环境"），不是二十个它不理解的工具。

6.2 请求流


1. 调用方 AI 构造自然语言请求
2. 客户端 SDK 将请求 + 身份 token 发送到 EaaS API
3. 入口拦截：验证 token、检查频率限制、记录请求
4. 服务智能体在环境上下文中接收请求
5. 智能体读取相关知识、选择工具、执行工作流
6. 输出过滤：移除敏感信息
7. 结构化结果返回给调用方
8. 知识捕获：工作轨迹供给知识系统

步骤 4-5 是环境能力所在。智能体在这里的有效性取决于环境的丰富度——工具、知识和策略——而非调用方的复杂度。

7. 设计决策与取舍

7.1 同步 vs. 异步

一些领域操作在数秒内完成（索引查找、缓存指标检索）。另一些需要数分钟（复杂的多步分析、大型 SQL 查询）。EaaS 必须两者兼顾。

推荐的方案是统一的流式接口。短请求在流内快速完成。长请求流式传输进度更新（思考中、执行中、验证中），然后交付最终结果。调用方可以选择阻塞等待完成，或逐步处理流。

替代方案是双模式：短操作同步，长操作异步（提交后轮询）。这增加了客户端的复杂性，且要求调用方 AI 决定使用哪种模式——而这个决策应由服务方而非调用方做出。

7.2 无状态 vs. 轻量有状态

纯无状态——每个请求独立——是最简单的模型，对大多数单轮查询有效。但多轮交互很常见："上周留存是多少？"后接"按平台拆分一下。"

推荐的方案是轻量有状态：每个响应包含一个会话标识符，调用方可以选择在后续请求中携带以延续上下文。服务在内部管理状态。如果调用方不带标识符，请求被视为独立的。

这避免了将上下文管理的负担推给调用方，同时在需要时支持多轮交互。

7.3 结果格式

服务智能体返回结构化块而非原始文本。典型的块类型包括：

这种结构化格式同时服务于 AI 和人类消费者。调用方 AI 可以解析和转换数据；看到结果的人可以阅读叙述、检视表格。

7.4 单工具客户端模式

在客户端侧，EaaS 最好暴露为单一工具——无论集成机制如何（CLI、SDK 或 MCP 封装）。调用方 AI 看到一个能力："问领域环境。"不是"搜索报表"、"执行查询"、"获取元数据"——只是"问"。

这是刻意的。当你在客户端侧暴露多个工具的那一刻，就把编排责任推回给了调用方 AI——而这恰恰是 EaaS 存在的意义所在。一个工具，自然语言输入，结构化输出。所有编排留在环境内部。

8. 与领域智能的关系

EaaS 延伸了 SEKE 中阐明的领域智能论题。

SEKE 的论题认为：

通用智能 + 能力接口 + 领域知识 = 领域智能

SEKE 解决的是领域知识如何创建：通过从真实工作中自主学习，组织到演化的语义树中，经对抗性审查精炼，在人类宪法性决策的治理下运行。

EaaS 解决的是领域智能如何分发：通过智能体中介的接口，使环境的全部能力——包括其积累的知识——对在环境之外工作的用户可及。

两者共同形成完整的循环：


SEKE：构建领域智能（知识积累）
EaaS：分发领域智能（智能体中介的访问）
      ↓
更多用户、更多上下文、更多交互
      ↓
更丰富的 SEKE 知识捕获素材
      ↓
更深的领域智能
      ↓
更好的 EaaS 服务质量

这个循环有一个值得注意的性质：SEKE 和 EaaS 相互增强。 SEKE 通过加深智能体可以调用的知识使 EaaS 更有价值。EaaS 通过增加供给知识捕获的交互使 SEKE 更有效。两者单独都无法达成两者共同产生的效果。

竞争含义是：领域智能一旦通过 SEKE 自举、通过 EaaS 分发，就在两个层面同时创造复合优势。竞争者不仅需要复制知识库（这需要数月的真实运营），还需要复制分发网络（正是它创造了驱动知识质量的输入多样性）。

9. 为什么不直接用 MCP？深度分析

与 MCP 的对比值得仔细讨论，因为 MCP 是最自然的替代方案，也是最常被提议的分发问题解决方案。

MCP 的架构是：暴露工具 → 让调用方 AI 编排 → 按工具返回结果。

EaaS 的架构是：暴露智能体 → 让它在内部编排 → 按请求返回结果。

差异不是渐进的。它是智能相对于服务边界的位置的差异。

在 MCP 中，智能（编排、判断力、领域知识）必须存在于调用方侧。服务提供机制。调用方提供意义。

在 EaaS 中，智能存在于服务方。服务同时提供机制和意义。调用方只提供意图。

这产生一个级联效应：MCP 的质量上限是调用方的领域知识；EaaS 的质量上限是环境的领域知识。 由于环境的知识随时间复合增长（通过 SEKE 或类似系统），而调用方的知识通常是静态的，EaaS 的质量上限持续提升，而 MCP 的保持不变。

还有一个 MCP 中的结构性不可能值得指出：MCP 无法暴露知识。MCP 暴露的是带有 schema 和描述的工具。但知识——"这个数据源在周一不可靠，因为有一个已知的 ETL 延迟"、"这个指标上个季度被重新定义了，旧报表用的是遗留定义"、"这个查询模式在超过一千万行的表上会超时"——无法表示为工具 schema。它只能表示为智能体在工作时推理的上下文。

EaaS 是唯一一种这些知识既可用又被应用的架构。

关于混合设计的说明。 细心的读者会注意到，没有什么阻止一个 MCP server 暴露一个由智能体支撑的单一高层 ask 工具。这是对的——本文自身的参考架构（第 6 节）恰恰将此作为客户端集成方案。但这个观察不削弱论证，而是确认了它。一个包装了单一智能体支撑的 ask 工具、在服务端实现知识检索、语义安全和凭证隔离的 MCP server，不是上文所批评意义上的 MCP。它是 EaaS，以 MCP 作为传输协议来交付。本节批评的目标是将许多领域特定工具通过 MCP 暴露、依赖调用方 AI 去编排它们这一常见模式——而非将 MCP 用作一种根本不同的服务架构的线路格式。

10. 安全必然性：为什么 EaaS 不是可选项

此前的论证将 EaaS 呈现为一种更好的架构——更强的能力、更优雅的设计、更有利于知识积累。但存在一个更强的主张：在 Agent 环境从根本上不安全的世界里，EaaS 是唯一安全的环境能力分发方式。

10.1 Agent 环境的不安全性

今天的 AI Agent——Codex、Claude Code、Cursor、Copilot 及其后继者——在用户的本地环境中以广泛的能力运行。它们可以安装包、访问网络、读写文件系统、执行任意代码、与外部服务交互。这不是设计缺陷，而是必要条件。Agent 需要这些能力才能有用。

但同样是这些能力，使得 Agent 环境本质上不安全。威胁模型不是假设性的：

供应链攻击。 当 Agent 执行 pip install 或 npm install 时，它信任包仓库。一个被污染的包——通过 typosquatting、维护者账号接管或依赖混淆注入——就获得了在 Agent 环境中的代码执行权。这不是理论：针对包仓库的供应链攻击已有充分记录，且频率在增加。Agent 放大了这一风险，因为它们安装包比人工开发更积极、审查更少。

恶意工具提供者。 一个 MCP server、一个插件、一个 Skill、一个扩展——Agent 加载的任何第三方能力都成为 Agent 可信计算基的一部分。一个恶意的 MCP server 可以通过 prompt injection 注入指令、通过工具响应窃取数据、或以用户不可见的方式操纵 Agent 的行为。

通过数据的 Prompt Injection。 当 Agent 读取外部内容——网页、文档、API 响应、甚至数据库结果——这些内容可以包含对抗性指令。如果 Agent 解释执行了这些指令，攻击者就获得了对 Agent 行为的间接控制，包括其对工具和凭证的使用。

环境窃取。 一个能读取环境变量并访问网络的 Agent，可以在一次操作中窃取凭证。不需要复杂的漏洞利用——读取 os.environ 并发送一个 HTTP 请求就够了。Agent 依赖链中任何被污染的组件都可以静默地做到这一点。

令人不安的结论是：我们应该假设，任何具有网络访问和包安装能力的 Agent 环境最终都会被攻破。 攻击面太大、供应链太深、防御太弱。大规模的 Agent 原生攻击——针对运行 AI 编码助手的数百万开发者机器——尚未大规模发生，但执行起来极其简单。广泛攻击的缺失反映的是攻击者的优先级，而非攻击者的无能。

10.2 能力分发即攻击面分发

这对能力的分发方式有直接后果。

当一个组织将能力分发到 Agent 环境——通过 API、SDK、MCP server 或工具集成——它就是在分发攻击面。每一个分享给用户环境的凭证，都是被攻破的环境可以窃取的凭证。每一个暴露给用户 Agent 的工具，都是被攻破的 Agent 可以滥用的工具。

考虑分发方式的谱系：

直接分发凭证（API key、数据库密码）。最常见也最危险的方式。凭证一旦到达被攻破的环境，攻击者就拥有了与合法用户相同的访问权——通常没有频率限制、没有行为分析、没有意图评估。从一个开发者机器泄露的数据库密码，直接给了攻击者生产数据的访问权。

通过代理访问分发能力（工具服务器、MCP）。更好一些：调用方不持有原始凭证。但工具本身成为攻击面。一个被攻破的 Agent 如果拥有查询工具的访问权，就可以通过该工具执行任意 SQL。一个被攻破的 Agent 如果拥有部署工具的访问权，就可以推送恶意代码。工具提供能力但不提供判断力——而被攻破的调用方没有判断力。

通过细粒度权限分发能力（范围限定的 token、逐工具的 ACL）。更好，但仍然不够。细粒度权限限制了每个工具能做什么，但无法限制工具被用来做什么。一个限定在特定表上的只读查询 token，仍然允许被攻破的 Agent 从那些表中窃取所有数据。权限在动作级别是正确的；使用在意图级别是恶意的。

这些方案都没有解决根本问题：如果调用方的环境被攻破，分发到其中的任何能力都会被用来对付你。 无论这种能力是凭证、工具还是精细范围的权限，都是如此。

10.3 EaaS 作为唯一安全的架构

EaaS 通过将能力保留在环境内部来解决这个问题——不向调用方分发工具、不分发服务凭证、不分发查询接口。

在 EaaS 中，调用方的环境中与领域服务相关的内容恰好只有两样：

  1. 一个向端点发送自然语言文本的函数
  2. 一个短生命周期的身份 token

没有凭证。没有工具。没有查询接口。没有部署能力。没有 MCP server。没有任何被攻破的环境可以用来直接访问领域系统的东西。

即使调用方的环境被完全攻破——每个包被植入后门、每个 MCP server 是恶意的、Agent 本身被劫持——攻击者能做的只有：

攻击面从"用户 Agent 能访问的一切"坍缩为"一个短生命周期的身份 token 通过一个评估意图的自然语言接口能做到什么"。这不是边际改善，而是风险的类别性降低。

10.4 服务智能体的基础设施级沙箱

一个自然的质疑随之而来：如果 Agent 环境本质上不安全，那 EaaS 的智能体——它也是一个 AI Agent——不是同样脆弱吗？答案是否定的，原因是架构性的，不是意愿性的。

EaaS 智能体运行在集中管控的基础设施中，而非用户的机器上。仅此一点就使得一类在用户环境中不可能实施的沙箱措施成为可能。

通过代理注入实现无凭证执行。 在用户环境中，Agent 需要凭证来访问服务——数据库密码、API key、服务 token——这些凭证必须存在于 Agent 能触及的某处：环境变量、配置文件、密钥存储。在 EaaS 中，智能体进程自始至终不持有任何凭证。智能体的所有网络请求都通过一个反向代理路由，代理检查请求、确定目标服务、在转发前于代理层注入适当的凭证。智能体向"仪表盘 API"发送请求；代理添加认证头。智能体向"数据库"发送查询；代理添加连接凭证。智能体的进程内存、环境变量和文件系统中包含零凭证材料。

这意味着，即使服务智能体被完全攻破——通过对抗性 prompting、数据携带的 prompt injection、或假设性的推理漏洞——攻击者获得的是一个结构上不可能泄露凭证的 Agent，因为它从未持有过凭证。

通过外部执行器实现能力限制。 在用户环境中，Agent 拥有广泛的系统访问权：它可以运行 shell 命令、直接访问网络、读取任意文件。限制这些是不现实的，因为用户需要 Agent 做通用工作。在 EaaS 中，智能体的能力通过一个固定的 Unix Socket 接口由一个外部执行器（Executor）进程中介。智能体不能执行 shell 命令、不能直接发起网络调用、不能访问其工作空间之外的文件系统。它通过 Socket 发送结构化的操作请求，由执行器——一个经过加固的非 AI 进程，拥有有限且可审计的允许操作集——来决定是否执行。

允许的操作集是小且显式的：运行特定工具、读取特定知识文件、写入结果产物。执行器拒绝任何集合之外的请求。智能体不能安装包、不能打开任意网络连接、不能读取 /etc/passwd 或 ~/.ssh/。它的能力包络由执行器的白名单定义，而非操作系统的权限。

为什么这在用户环境中不可行。 这里需要精确地陈述这种不对称。不是说用户环境的 Agent 在理论上不能被沙箱化——同样的代理注入和执行器限制技术原则上可以应用于任何 Agent。问题在于，在用户层面实施沙箱的成本会制造一个与它试图缓解的安全风险同等量级的组织风险。

成本在两个层面运作：

建设沙箱是昂贵的。 每个开发者的机器都需要一个凭证注入代理、一个带有策编操作白名单的外部执行器、以及管理、更新和监控这些组件的基础设施。这不是一次性搭建：沙箱必须随着 AI 工具的演进、新 MCP server 的采用、工作流的变化而演进。工程投入与用户数量乘以环境多样性成正比——这个缩放因子使得企业级部署的成本过高。

执行（enforce）沙箱的成本更加昂贵。 用户能绕过的沙箱就不是沙箱。执行意味着限制员工能运行什么 AI 工具、这些工具如何访问网络、能安装什么包。在实践中，这意味着限制那些使 AI Agent 对通用工作有价值的核心能力。一个对开发者的 AI Agent 实施严格沙箱的组织，实质上是在节流自身的 AI 转型。

这造成了一个组织层面的、而非技术层面的困境：

通过施加重沙箱来阻止 AI 转型的风险，可能等于甚至超过安全事故的风险。两者都是严重的组织风险，只是时间尺度不同：数据泄露造成即时损害；AI 转型停滞逐步侵蚀竞争力。

这就是根本性的不对称：EaaS 智能体可以低成本地被沙箱化，因为其目的狭窄且基础设施集中管控（建设一次、服务所有用户）；而用户环境的 Agent 只能以按用户缩放的成本被沙箱化，且这种沙箱会限制使 AI 采用有价值的核心能力。 EaaS 利用这种不对称，将领域工作移入一个极端沙箱化经济可行的环境，同时让用户的 Agent 自由地做通用工作——无需持有领域凭证或能力，也无需任何沙箱。

其结果是一个在三个独立层面运作的纵深防御：

  1. 调用方从未持有凭证或能力（10.3 节）
  2. 服务智能体也从未持有凭证——代理注入和执行器限制从架构上确保了这一点
  3. 自然语言接口在任何操作到达执行器之前评估意图（10.5 节）

攻击者需要同时突破所有三个层面：获取有效的身份 token、构造通过意图评估的自然语言请求、并以某种方式绕过执行器的操作白名单。每个层面都是独立可防御的，组合起来质性地强于任何单层安全模型。

10.5 自然语言作为安全边界

Agent-as-interface 设计的一个意外后果是：自然语言本身起到了安全边界的作用。

当系统的接口是 API 时，攻击者的语言是 API 的语言：SQL、HTTP、结构化函数调用。这些是精确的、机器可解释的、可利用的——SQL 注入、参数篡改、请求伪造都是利用结构化接口精确性的攻击。

当接口是由推理智能体中介的自然语言时，攻击者的语言是人类语言——而服务智能体会解释、评估、并可能拒绝。传统的注入攻击类别不适用：

这不意味着自然语言接口对所有攻击免疫。对抗性 prompting 可以试图操纵服务智能体的行为。但防御同样在语义层面：智能体可以被指示识别和拒绝对抗性模式，而且——关键的是——智能体的安全策略作为系统级约束运行，自然语言请求无法覆盖它们。

安全边界不仅是过滤器。它是一个理解意图的推理系统。这是与访问控制列表、网络策略或凭证范围限定质性不同的防御。

10.6 必然性论证

我们现在可以以最强的形式陈述 EaaS 的安全论证：

  1. Agent 环境是不安全的，且随着 Agent 获得更多能力、供应链变得更复杂，会变得更不安全。
  2. 分发到不安全环境的任何能力最终都会被利用。
  3. 因此，使能力对 Agent 可及的唯一安全方式，是将其保留在安全环境内部，只暴露自然语言接口。
  4. 该安全环境内的服务智能体自身也可以被沙箱化——通过代理注入剥离凭证、通过外部执行器限制在有限操作集——因为其目的足够狭窄以允许极端限制。
  5. 这正是 EaaS 所做的。

结论不是 EaaS 是一种更好的能力分发方式。而是 EaaS 是唯一使环境能力可及却不向调用方分发底层工具、凭证或攻击面的方式。 被攻破的客户端仍然可以发送经授权的自然语言请求——但损害被语义安全层、执行器的操作白名单和 token 的短生命周期所限定。这是相对于"用户能访问的一切"的类别性降低，而非所有风险的消除。

不采用 EaaS 或等效架构的组织，在 Agent 原生攻击普遍化之后将面临三元困境：

每条路都承担着显著代价。安全事故是即时且可见的。AI 转型停滞是缓慢且不可见的——但随时间复合。被封锁的能力是对组织效能的持续拖累。

EaaS 通过将能力与访问分离来消除这个三元困境。能力留在一个集中管控、深度沙箱化的环境中——建设一次，在所有用户间摊销。用户环境保持完全自由：无沙箱、无限制、无凭证、无环境工具。连接两者的是通过一个评估意图的智能体的自然语言。没有危险的东西越过边界。没有限制性的东西施加在用户侧。

11. 局限性与取舍

EaaS 并非没有代价。几个取舍值得诚实地承认。

延迟。 双 AI 委托模式增加了一个往返：调用方 AI 发送请求，EaaS 智能体推理和执行，结果返回。对于直接 API 调用可以在毫秒内完成的简单查找，EaaS 引入了数秒或数分钟的延迟。对于分析性和多步骤任务——其替代方案不是更快的工作，而是更差的工作——这是可接受的，但使 EaaS 不适合替代服务实时应用的低延迟数据 API。

智能体推理错误。 EaaS 智能体是一个 AI 系统。它可能误解请求、选错工具、写出错误的查询、或返回有缺陷的分析。与确定性的 API（要么成功要么干净地失败）不同，智能体可能以微妙的方式失败——返回看似合理但错误的答案。这一风险通过环境的知识系统（编码了验证流程和已知的边界情况）和审计层（可以检测长期的错误模式）得到缓解，但无法消除。调用方应以对待人类同事分析一样的批判性判断来对待 EaaS 的结果。

冷启动。 一个没有积累知识的环境所提供的 EaaS 服务，其质量仅取决于智能体的通用推理能力加上可用的工具。知识放大效应（第 5 节）需要时间和使用来建立。部署 EaaS 的组织应预期一个服务质量逐步提升的自举期。

运营成本。 运行 AI 智能体作为持久的服务接口比托管静态 API 更昂贵。每个请求消耗推理算力，复杂的多步骤请求消耗更多。这种成本结构有利于高价值、低频次的分析任务，而非高频次、低价值的查找。组织必须权衡这与替代方案的成本：构建和维护逐用户的工具集成、管理分布式凭证、或完全放弃能力分发。

对基础模型能力的依赖。 EaaS 的质量上限受服务智能体所使用的基础模型的推理能力约束。随着基础模型的进步，EaaS 服务质量随之提升——但架构的强度取决于智能体推理、工具执行和知识检索这条链上最弱的环节。

中心化风险。 EaaS 将能力、凭证、知识和审计数据集中在一个受管环境中。这种集中是其安全优势的来源——但它也创造了一个高价值目标。服务环境的被攻破影响所有用户，而非仅仅一个。拥有环境访问权的运营者的内部滥用，是分布式架构不存在的风险。多租户隔离、服务端访问控制和运营安全实践必须严格，服务端泄露的影响范围必须被认真对待。EaaS 用分布式的、逐用户的风险换取了集中的、基础设施级的风险——这在基础设施管理良好时是有利的取舍，但不应被视为理所当然。

这些是真实的约束，不是理论上的顾虑。它们定义了 EaaS 是正确选择的运行包络：高价值的领域任务、具有积累知识的环境、以及替代方案不是"更快的 API"而是"完全无法获取环境能力"的场景。

12. 结论

环境即服务是一个简单的想法，却有深远的后果：在领域环境的边界放一个 AI 智能体，让它成为接口——既是人的接口，也是其他 Agent 的接口。当人与它交互时，它是一个理解问题并返回答案的领域专家。当另一个 AI Agent 与它交互时，它是一个接收意图并返回结构化结果的领域服务。接口是同一个；只有调用方不同。本文聚焦于后者——Agent 到 Agent 的场景——因为这是现有架构处理得最差、EaaS 优势最具决定性的场景。

这一个决策解决了分发问题——用户从自己的工具访问环境的全部能力，无需学习环境的内部细节。它创造了新的安全模型——工具级接口不可能实现的语义化、意图级的安全。它放大了知识积累——每一个调用方、从每一个上下文，都在供给同一个知识系统。而且，它是唯一不分发攻击面的能力分发架构——这一性质在 Agent 环境成为供应链攻击和 prompt injection 的主要目标时，从可取变为必需。

这个架构在概念上是直接的，但在实现上并非简单。它需要一个值得分发的环境、一个能在其中运作的智能体、以及一个接收自然语言并返回结构化结果的 API。这些组件今天已经存在。新的是对一个事实的认识：环境能力的正确服务抽象不是工具、不是端点、不是协议——而是智能体。

EaaS 补完了领域智能的图景。SEKE 解决的是领域知识如何创建和精炼，EaaS 解决的是领域智能如何分发和消费。两者共同描述了一个系统——它通过工作构建自己的专业能力，并让这种专业能力对任何能描述自己需要什么的人可及——用自然语言、从任何工具、通过单一接口。

本文的思想来自于构建和运营一个面向数据分析的生产级领域智能系统。环境即服务不是一个理论提案——它是一个从分发能力给跨多种工具和工作流的用户这一真实经验中设计出来的架构。