在上一章中，我们明确了 AI Agent 的核心概念，并描绘了最终项目的蓝图。从本章开始，我们将正式进入工程落地阶段。

在动手写下第一行代码之前，我们必须先完成技术选型与架构设计。很多 AI 项目最终沦为“玩具”或“烂尾工程”，根本原因往往不是业务逻辑太复杂，而是底层技术栈选错了，导致后期扩展性极差、性能瓶颈频发。

本章的目标是解释我们为什么选择这些特定的技术，而不是简单地罗列依赖。我们将构建一个兼顾开发效率、运行性能和未来扩展性的企业级架构。

1. 前端技术栈：为 AI 而生的 Web 框架

构建 AI Agent 的前端，与传统的 CRUD 应用有本质区别。我们需要处理流式响应（Streaming）、复杂的 UI 状态（如工具调用的中间态）以及多模态交互。

为什么选择 Next.js (App Router) + React？

• Next.js：AI 应用对首屏加载和流式渲染要求极高。Next.js 的 App Router 原生支持 React Server Components (RSC) 和 Streaming，这意味着我们可以将 AI 的流式响应直接作为 Server Component 渲染，极大降低客户端压力。
• React：拥有最丰富的生态，无论是 Vercel AI SDK 还是各种 UI 组件库，React 都是第一公民。

为什么选择 TypeScript？

• 类型安全：AI Agent 涉及大量的工具调用（Tool Calling）、JSON 解析和状态流转。在 JavaScript 中，一个字段名拼写错误可能导致整个 Agent 流程崩溃。TypeScript 能在编译期拦截这些问题。

为什么选择 Tailwind CSS + HeroUI？

• Tailwind CSS：AI 应用的 UI 迭代极快，Tailwind 让我们无需在 CSS 文件和组件之间频繁切换，快速构建现代化界面。
• HeroUI：基于 NextUI 演进而来，专为现代 Web 设计。它内置了暗色模式、流畅的动画，且对 React 极其友好。对于 AI 聊天界面，HeroUI 提供了开箱即用的输入框、气泡等组件。

2. AI 核心层：为什么是 AI SDK 而不是 LangChain？

这是很多开发者最容易陷入的误区。LangChain 确实是一个伟大的框架，但它并不总是最优解。

LangChain 的痛点

• 过度抽象：LangChain 试图包揽一切，导致学习曲线极其陡峭。
• 不够 React：它的很多设计理念偏向 Python 后端，与 React 的前端流式渲染结合时显得笨重。
• 黑盒效应：当 Agent 出现幻觉或工具调用失败时，LangChain 复杂的内部链路让 Debug 变成一场灾难。

为什么选择 Vercel AI SDK？

• 极致轻量：AI SDK 不试图做所有事情，它只专注于解决一个核心问题：如何将大模型的流式响应无缝接入你的前端 UI。
• 更符合 React 范式：它提供了 useChat, useCompletion 等 Hooks，完美契合 Next.js App Router 的开发体验。
• Tool Calling 更自然：AI SDK 将工具调用视为一等公民，支持在服务端定义工具，并在前端自动渲染工具调用的 UI 状态。
• 统一接口：一套 API 无缝切换 OpenAI, Anthropic, DeepSeek 等主流模型。

3. 数据层：为什么是 PostgreSQL + pgvector？

AI 应用需要存储两类截然不同的数据：结构化的业务数据（用户、对话记录）和非结构化的向量数据（文档 Embedding）。

为什么不用 MongoDB？

• MongoDB 在事务支持和复杂关系查询上较弱。Agent 的对话历史、工具调用记录之间存在强关联，关系型数据库是更稳妥的选择。

为什么不用 Pinecone / Weaviate 等专用向量数据库？

• 架构复杂度：引入专用向量数据库意味着你要维护两套数据库、两套备份策略、两套权限系统。对于中小型甚至部分大型应用，这是不必要的运维负担。
• 数据一致性：当你的业务数据和向量数据分离时，跨库事务和同步是噩梦。

为什么选择 PostgreSQL + pgvector？

• All-in-One：PostgreSQL 是世界上最强大的开源关系型数据库，而 pgvector 扩展让它同时具备了高性能的向量检索能力。
• 生产环境建议：一套数据库，一次备份，一个连接池。Prisma 已经完美支持 pgvector，让你用熟悉的 ORM 语法进行向量相似度搜索。

4. 工具生态：为什么必须关注 MCP？

什么是 Model Context Protocol (MCP)？

MCP（模型上下文协议）是由 Anthropic 提出并逐渐被行业广泛接受的开放标准。它定义了 LLM 与外部数据源、工具之间的标准化通信协议。

为什么它会成为未来标准？

• 打破孤岛：过去，每个 AI 应用都要自己写一套对接 Notion、GitHub、Slack 的代码。有了 MCP，这些工具只需提供一次 MCP Server，任何支持 MCP 的 Agent 都能即插即用。
• 解耦：Agent 不再需要硬编码 API 密钥和调用逻辑，MCP 提供了统一的鉴权和数据流规范。

在本项目中，我们将原生集成 MCP，让你的 Agent 具备无限扩展外部工具的能力。

5. 系统整体架构设计

基于以上选型，我们设计了如下企业级 AI Agent 架构：

架构流转解析：

1. 用户在 Browser 发起对话。
2. Next.js 接收请求，交由 AI SDK 处理。
3. AI SDK 将请求路由给目标 LLM。
4. 如果 LLM 决定使用工具，AI SDK 会在服务端执行 Tools 或发起 MCP 请求。
5. 工具执行结果、Memory 上下文、RAG 检索结果被组装回 Prompt。
6. LLM 生成最终流式响应，通过 Next.js 实时推送到浏览器。
7. 所有的状态、向量数据统一沉淀到 PostgreSQL。

本章总结

• 前端：Next.js + React + TypeScript + Tailwind + HeroUI，为 AI 流式交互提供最佳体验。
• AI 核心：Vercel AI SDK 替代 LangChain，更轻量、更 React 原生、更易于调试。
• 数据层：PostgreSQL + pgvector 实现“一库多用”，降低运维复杂度，保证数据一致性。
• 工具扩展：拥抱 MCP 协议，为 Agent 接入无限外部能力打下基础。
• 架构：高度模块化，前后端流式打通，数据层统一。

技术栈已经敲定，地基已经打好。从下一章开始，我们将正式初始化项目，配置 Prisma 与 pgvector，并搭建 Next.js 的核心目录结构。