超越文字：为什么 AI Agent 需要交互式 UI
文字陷阱
ChatGPT、Claude、Gemini——都有同样的瓶颈。你让它算个东西，它回复：
99.5 × 3 = 298.5对的——但是死的。改成 4 件？新的一轮。加税？再来一轮。图表、表单、滑块——全部被压扁成你无法交互的文字。
生态解决了输入（MCP、Function Calling、REST），输出仍是文字。
你当然可以直接嵌入 iframe
ERI（嵌入式结果界面）是一个开放规范，把临时的 iframe 嵌入变成可复用的模式：你的 Web 应用通过一个 skill.md 和一个 URL，以可交互 UI 出现在任何 Agent 对话中。
那为什么还需要一个规范？因为没有约定，每次 Agent-提供者的集成都是临时拼凑。一个 Agent 把数据放在 hash 里嵌入你的 URL。另一个放在 query 参数里。第三个忘了在不支持 iframe 的平台提供纯文本降级。你的 API 每次被不同的方式调用，嵌入页面没有一个一致的契约。
ERI 定义了这个契约：skill.md 指导 Agent 调用特定 API、编码结果、嵌入特定 URL、并包含纯文本降级。同样的模式，每个 Agent，每个支持 iframe 的平台。结果是一致且可复用的——不是一次碰巧。
行业格局
交互式 Agent 输出存在三种方案。ERI 利用平台已有的 iframe 渲染，大多数平台今天就能用。MCP Apps 和 A2UI 提供更丰富的能力但需要平台特定的运行时。详见规范对比表——或直接看在线演示。
关键点：MCP Apps 同样在沙箱 iframe 中渲染。ERI 嵌入页面天然与 MCP Apps 运行时结构兼容，而且 Level 2 使用相同的 ui/* JSON-RPC 桥。从 ERI 开始，嵌入页面无需修改即可沿用。
为什么选 ERI
低承诺。你的嵌入页面无论有没有 ERI 都能独立运行。skill.md 约十五行 Markdown。MIT 许可规范，任何人可以 fork。从零到可运行嵌入，不到一天。
代价：快照式输出（每轮用户对话产生全新嵌入），无原生设备 API，URL 大小限制。详见规范局限性和大数据集模式。
被说服了？试试演示、阅读团队采用指南、或直接用可复制模板开始。
分享这篇文章
AI Agent 输出文字。ERI 让它们输出可交互的 UI——用一个 skill.md 把任何 Web 应用嵌入 ChatGPT、Claude、Gemini。开放规范，MIT 许可。2234839.github.io/eri-spec