AI Agent全栈架构

主题

Nuxt AI 应用开发 · 高级项目面

如何用 Nuxt 设计一个生产级 AI 对话应用的整体架构？

考察候选人能否把 Nuxt 页面、Nitro API、模型网关、会话存储和观测体系组织成可演进的 AI 应用。

适合阶段：高级 / 资深前端 · AI 应用面 / 架构面核心能力：Nuxt · Nitro · AI 工程化 · 生产治理

面试官想考什么 ​

  • 能否先定义 AI 场景和 Nuxt 的边界？
    考察候选人能否把 Nuxt 页面、Nitro API、模型网关、会话存储和观测体系组织成可演进的 AI 应用。
  • 能否讲清端到端链路？
    重点考察：浏览器 -> Nuxt 页面与交互状态 -> Nitro API/BFF -> 模型或 Agent 编排 -> 数据库、RAG、工具 -> 流式事件 -> 客户端消息状态。
  • 能否说出工程取舍？
    重点考察：把模型调用放浏览器开发快但会泄露密钥、难控成本和权限；全部逻辑放单体服务简单但难以独立扩展，应该按数据、实时性和团队边界拆分。
  • 能否处理线上风险？
    重点考察：页面只管理输入、消息展示和连接状态；server/api 负责鉴权、限流、请求校验和模型代理；领域服务负责 prompt、RAG、工具和持久化，所有外部响应都要归一化。

一句话回答 ​

text
我会把 Nuxt 作为 BFF 与交互层，浏览器只访问自有 Nitro API，模型密钥和编排逻辑留在服务端，再把会话、流式传输、持久化、评估和监控拆成明确边界。

面试回答详解 ​

这道题的核心不是“会不会调用模型”，而是能否把 Nuxt 的页面和 Nitro 服务端能力放进 AI 应用的完整闭环：输入、上下文、模型或工具、流式结果、持久化、权限、观测和失败恢复。

1. 问题边界 ​

考察候选人能否把 Nuxt 页面、Nitro API、模型网关、会话存储和观测体系组织成可演进的 AI 应用。 把模型调用放浏览器开发快但会泄露密钥、难控成本和权限；全部逻辑放单体服务简单但难以独立扩展，应该按数据、实时性和团队边界拆分。

2. 核心链路 ​

浏览器 -> Nuxt 页面与交互状态 -> Nitro API/BFF -> 模型或 Agent 编排 -> 数据库、RAG、工具 -> 流式事件 -> 客户端消息状态。

text
用户交互 -> Nuxt 客户端状态 -> Nitro/BFF -> AI 编排
        -> 模型/RAG/工具 -> 结构化或流式结果
        -> 持久化、观测、评估和恢复

3. Nuxt 项目落地 ​

页面只管理输入、消息展示和连接状态；server/api 负责鉴权、限流、请求校验和模型代理；领域服务负责 prompt、RAG、工具和持久化，所有外部响应都要归一化。

  • 服务端边界：模型密钥、provider 选择、权限、工具执行和成本控制放在服务端；客户端只拿到最小必要结果。
  • 状态边界：区分页面状态、会话状态、run 状态和持久化数据，避免刷新、重连或多标签页时串话。
  • 协议边界：流式事件、结构化输出和错误响应要有版本化契约，不能让组件猜测 provider 的原始格式。
  • 安全边界：用户输入、RAG 文档、工具结果和模型输出都可能不可信，必须做权限、校验、脱敏和审计。

4. 工程取舍 ​

把模型调用放浏览器开发快但会泄露密钥、难控成本和权限；全部逻辑放单体服务简单但难以独立扩展，应该按数据、实时性和团队边界拆分。

成熟答案要明确哪些工作适合同步请求，哪些必须进入队列或工作流；哪些数据可以缓存，哪些属于用户私有数据；哪些失败可以重试，哪些副作用只能人工恢复。

5. 生产风险与验证 ​

页面只管理输入、消息展示和连接状态；server/api 负责鉴权、限流、请求校验和模型代理；领域服务负责 prompt、RAG、工具和持久化，所有外部响应都要归一化。 方案上线前至少覆盖正常、超时、限流、断流、取消、重复请求、权限变化、provider 故障和版本回滚。用 trace、指标、评估集、组件测试和 E2E 验证，不把“本地能显示回答”当作完成。

可直接背诵的 30 秒回答 ​

text
我会先把 AI 功能拆成输入、上下文、模型或工具、结果传输、持久化和观测几层。我会把 Nuxt 作为 BFF 与交互层，浏览器只访问自有 Nitro API，模型密钥和编排逻辑留在服务端，再把会话、流式传输、持久化、评估和监控拆成明确边界。 在 Nuxt 中，页面负责交互和状态展示，Nitro 负责鉴权、模型代理、流式协议和服务端数据访问，长任务进入可恢复的任务系统。最后我会补齐权限、成本、失败恢复、评估和灰度回滚，确保它不只是一个 Demo。

扩展知识 ​

AI 应用通用链路 ​

text
Auth -> Input Validation -> Context/RAG -> Model/Tool
     -> Stream/Structured Output -> Persistence -> Trace/Evaluation

Nuxt 中常见的职责分配 ​

  • 页面与 composable：输入、消息列表、连接状态、重试、取消和可访问反馈。
  • Nitro server/api：认证、限流、模型代理、流式协议、数据访问和错误归一化。
  • 后台任务：文档索引、批量生成、长 Agent、转码和重试。
  • 外部系统：模型 provider、向量库、对象存储、队列、数据库和观测平台。

常见误区 ​

  • 把 AI SDK 或模型 SDK 直接导入 Vue 页面，泄露密钥和业务边界。
  • 只实现 token 流，不处理断开、取消、重复、乱序和最终一致性。
  • 把 RAG 文档、工具结果和用户记忆当成可信指令。
  • 只看回答是否“看起来不错”，没有 Prompt/模型/检索/工具版本和评估集。

面试官追问链 ​

追问一：为什么不让浏览器直接调用模型 API？ ​

  • 考察点：确认候选人是否能把 AI 功能落到可靠的 Nuxt 生产链路。
  • 回答方向：结合状态、权限、失败恢复、成本、可观测性和部署边界回答，不要只罗列 SDK API。

追问二：Nuxt BFF 和独立 AI Gateway 如何选择？ ​

  • 考察点：确认候选人是否能把 AI 功能落到可靠的 Nuxt 生产链路。
  • 回答方向：结合状态、权限、失败恢复、成本、可观测性和部署边界回答，不要只罗列 SDK API。

追问三：如何为多模型和多租户预留扩展点？ ​

  • 考察点：确认候选人是否能把 AI 功能落到可靠的 Nuxt 生产链路。
  • 回答方向：结合状态、权限、失败恢复、成本、可观测性和部署边界回答，不要只罗列 SDK API。

推荐阅读 ​

基于 MIT 协议开源

Copyright © 2026 AI Agent全栈架构