接口标准作为熵减：Agent 时代的基础设施与交互设计

一个帖子引发的问题

最近在即刻上看到一个观点：AI Agent 正在重写基础设施的 playbook，未来不是容器，而是 Stateful Containers。

这个判断抛出了一个正确的直觉——当 agent 从”调一个函数返回结果”演变为”在一个环境里持续工作”，底层基础设施的范式确实在变。但如果仔细追问下去，会发现事情远比”加个状态”复杂得多。

本文试图从 agent infrastructure 和交互设计的交叉视角，理清以下几个问题：agent 到底需要什么样的运行环境？Skill 作为 agent 时代的”App”意味着什么？以及，为什么接口标准可能是这个时代最重要的设计工作。

从 Stateful Container 开始追问

传统 serverless（如 AWS Lambda）是无状态的：函数被调用，执行，返回结果，环境销毁。这对 agent 来说不够用。一个 agent 可能需要安装依赖、操作文件系统、运行多步任务，它需要的不是一个函数，而是一个”地方”。

Stateful container 的直觉就是：给 agent 一个持久化的容器环境，状态不丢。

但这里有一个反直觉的事实：很多看起来需要 stateful container 的场景，其实不需要。

以最常见的 agent 用例为例——每天早上自动分析新闻并发送早报。这本质上是一个 cron job 加 LLM API 调用，每次执行之间是独立的，不需要环境持久化。一个 GitHub Actions 就够了。

即便需要”跨执行周期积累认知”（记得昨天报了什么、追踪事件脉络、学习用户偏好），这些”状态”用一个外部数据库就解决了。不需要整个容器保持活着。

而在另一端，Claude Code 的 resume 功能之所以好用，恰恰是因为没有容器——它跑在你的本机，文件系统天然持久，环境天然不会消失。“状态”根本不是一个需要显式管理的问题。

那什么场景才真正需要容器级别的环境管理？

• Agent 需要 7×24 在云端运行，而云端环境默认是 ephemeral 的
• Agent 作为服务给他人使用，需要隔离的运行环境
• Agent 运行不受信任的代码，需要安全边界
• 多 agent 需要在同一个环境中协作或接力

这些都是真实的需求。但更精确的判断可能是——agent 需要的不是”一直活着的环境”，而是**“需要的时候能快速拿到一个完整环境”**。这指向的不是 stateful container，而是 serverless container：给你完整的容器（可以装任意依赖、有完整文件系统、有 root 权限），但按需启动、按使用计费、空闲时 scale to zero。

启动足够快的话，你不需要保持状态——每次重建就行。环境定义为 image，有价值的输出存到外部存储，环境本身用完即弃。Modal、Fly Machines、E2B 都在走这条路。

Skill 即 App？未必

如果 container 解决了”在哪跑”的问题，下一个问题就是”跑什么”。在 agent 的语境下，这个”什么”就是 skill。

Anthropic 在 Claude Code 的 skills 架构中提出了一个清晰的分层：Agent Loop（推理）→ Agent Runtime（执行）→ MCP Servers（连接）→ Skills Library（知识）。Skill 被定义为打包了领域专业知识的文件集合——prompt、脚本、文档。

这让人自然地想到一个类比：skill 就是 agent 时代的 App。

但这个类比立刻碰到一个根本问题：App 之所以是一个清晰的产品概念，是因为 GUI 给了它边界感。你”打开”一个 App，你看到它能做什么，你操作它，用完你”关掉”它。整个交互是可见的、有界的、直觉的。

Skill 没有这些。它被调用时用户可能根本不知道，它在后台跑了什么也看不见，它和其他 skill 的边界是模糊的。对用户来说，agent 是一个整体，skill 是不可见的实现细节。

更麻烦的是依赖冲突。一个个人 agent 可能同时配置了数据分析 skill（需要 pandas + jupyter）、网页抓取 skill（需要 playwright + chromium）、音频处理 skill（需要 ffmpeg）。这些东西塞在一个环境里会出问题，但完全隔离又会让 skill 间的协作变得困难。

这里的设计挑战是：在隔离和共享之间找到正确的边界。

一个可能的模型是两层架构：

• 共享层：一个持久的工作空间，存放 agent 的个人数据、配置、中间产物。所有 skill 都能读写。这是”agent 的家”。
• 执行层：每个 skill 被调用时，启动一个 serverless container，里面是该 skill 自己的依赖环境。它挂载共享层来读写数据，但 runtime 本身是隔离的。执行完就销毁。

这样一写出来，你会发现它和操作系统的结构惊人地相似：共享层 = 文件系统，执行层 = 进程，skill 的 image = 应用程序，manifest = 权限声明，agent 平台 = 内核调度。

我们在 agent 层面重新发明了 OS 的每一个核心组件。

如果不是 App，那是什么？

当我们说 skill 即 App 的时候，脑子里的想象其实是基于 GUI 的。但 skill 没有 GUI，它更像一个 tool，一个后端进程。

这逼我们重新思考一个问题：agent 时代的”应用”到底是什么形态？

传统 App 是三个东西的紧密捆绑：计算逻辑 + 数据 + 界面。一个 iOS App 把这三层打包在一起，形成一个用户能理解的单元。

在 agent 时代，这三层被拆散了：

• 计算逻辑 = skill（脚本、CLI 工具、各种能力），跑在 container 里
• 数据 = agent 的共享工作空间 + 外部存储，跨 skill 存在
• 界面 = 被拆成两部分：agent 的叙述（轻的）+ generative UI（重的）

也许 agent 时代根本不存在”App”这个等价物。这三层不会再像 App 那样紧耦合，而是松散组合的：

Agent = 调度内核
  ├── Skills    （计算层，跑在 container 里）
  ├── Workspace （数据层，持久化存储）
  └── Surfaces  （呈现层，按需生成）

这里引入了”Surface”的概念——它不是 App 的 GUI，也不是 skill 的一部分，而是 agent 根据当前任务选择的呈现方式。有时候 surface 就是一句话（“文件已处理完”），有时候是一个动态图表，有时候是一个完整的交互界面。

这和传统的前端 / 后端 / 数据库三层架构在结构上同构。但有一个根本不同：谁在做决策。

传统架构里，开发者在 build time 就决定了前端长什么样、后端怎么处理、数据怎么流转。用户使用时这些都是固定的。Agent 架构里，这些决策推迟到了 runtime，而且做决策的不是开发者，是 agent。开发者提供的是组件和约束，不是完整的应用。

Generative UI 的位置

Generative UI 在这个框架里扮演什么角色？

它的承诺是：agent 根据当前任务动态生成界面，而非使用预设的固定 UI。这可以解决 skill 没有视觉存在感的问题——skill 跑完之后，agent 不只是吐文字，而是即时生成一个交互式界面让你探索结果。

但 generative UI 和 agent 之间存在一个张力：generative UI 的逻辑是把交互权交还用户（给你界面，让你操作）；而 agent 的逻辑是替你做完（你不需要操作）。如果每个 skill 执行完都弹出一个 UI 让用户确认，agent 就退化成了一个花哨的 wizard 流程。

更现实的问题是实现成本。目前 generative UI 的实现方式——无论是 iframe、JSON schema 渲染、还是让 AI 直接生成 React component——都比 skill 本身（script + CLI）重得多。

所以 generative UI 不应该是 skill 执行的常态，而应该是按需展开的细节层。默认路径是 agent 叙述 + 结果呈现，足够就结束。当用户想深入（“让我看看原始数据”、“这个结论怎么来的”），agent 才动态生成交互界面。

这本质上是 progressive disclosure 在 agent 交互中的应用——同一个设计原则，从技术架构层延伸到了用户体验层。

接口标准：看不见的体验设计

至此，我们面对一个松散耦合的系统：skills 在 containers 里执行，数据在共享工作空间流转，surfaces 按需生成。Agent 在 runtime 做调度决策。没有人提前设计完整的用户流程。

这个系统的自由度极高。但自由度高意味着不可预期性高。用户不知道 agent 会做什么，开发者不知道 skill 会在什么环境下被调用，skill 之间不知道彼此的输出格式。没有约束的系统会迅速走向混乱——熵增。

接口标准做的事情，就是在不限制能力的前提下引入可预期性。 它不告诉 agent 该做什么，但定义 agent 做事的方式必须遵循什么契约。就像语法不限制你说什么，但让别人能听懂你说的话。

目前这个层面存在明显的空白。MCP 定义了工具调用接口，但没有覆盖环境需求和呈现需求。Anthropic 的 skill spec 走了一部分但也没到 surface 层。一个完整的 skill manifest 应该声明：

• 环境契约：skill 需要什么系统依赖、什么 runtime、什么资源限额
• 数据契约：skill 会读写工作空间的哪些路径、输入输出的数据格式
• 叙事契约：skill 用一句话怎么描述（让 agent 向用户解释）、执行过程的关键节点（让 agent 汇报进度）、可能的失败模式（让 agent 管理预期）
• 呈现契约：skill 的输出适合什么 surface 形式（纯文本 / 图表 / 交互界面）、是否提供 generative UI 模板

其中”叙事契约”是最容易被忽视、但对用户体验影响最大的部分。它本质上是 skill 的 narrative interface——不是给人直接操作的 GUI，而是给 agent 用来跟人沟通的素材。现有的工具定义（MCP 也好、function calling 也好）几乎只关心技术接口，没有人在认真设计这个叙事层。

一个设计张力，而非一个技术问题

这里存在一个核心的设计张力：约束太少，系统混乱，体验不可控；约束太多，agent 的灵活性被杀死，退化成传统软件。找到那个”刚好够用的约束”是最难的部分。

这不是一个纯粹的系统工程问题，而是一个交互设计问题。

好的设计从来不是给用户无限自由，也不是把所有路径都定死，而是设计合理的约束让自由和秩序共存。Agent 时代的接口标准设计，本质上就是在做同样的事情——只不过你面对的”用户”不只是人，还有 agent 本身。

Agent 可以做任何事情。但一个系统要持续运行下去，需要有东西帮它做熵减。接口标准就是 agent 时代的熵减机制。 它决定了在一个高自由度的系统中，什么是可预期的、什么是可组合的、什么是可信赖的。

而这些看不见的边界，恰恰是决定用户体验的东西。

2026.02