前端智能体开发（五）：企业级 AI 前端：AI Coding、工具调用、MCP 与本地推理

企业级 AI 前端工程网络

这张图把企业级 AI 前端画成工程网络：AI Coding 负责提升开发效率，本地模型负责隐私与成本，Tools 让模型执行动作，MCP 把外部系统接成标准工具，端侧推理把一部分模型能力放回浏览器。企业场景的重点不是单个模型有多聪明，而是 AI 能不能进入安全、可控、可复用的工程网络。

一、AI Coding 改变的是开发流程，不只是补全速度

传统自动补全主要根据局部上下文猜下一个 token 或 API。AI Coding 的差异在于，它能理解更长上下文，能根据文件、类型、注释、测试和项目结构生成更完整的变更。

这会带来三个变化。

第一，类型变得更重要。以前很多人觉得 TypeScript 类型声明麻烦；现在类型是 AI 理解项目的重要线索。类型越完整，模型越容易知道函数输入输出、状态结构和边界条件。

第二，测试变得更重要。AI 可以快速改代码，但测试负责判断改动是否正确。没有测试的项目，AI 生成越快，风险也越快。

第三，项目规则变得更重要。目录结构、命名规范、构建命令、代码风格、禁止修改区域，都应该写成 Agent 能读取的规则，而不是只存在团队成员脑子里。

一个适合 AI Coding 的项目，通常具备：

清晰类型。
可运行测试。
明确目录边界。
统一 lint 和 format。
可复现构建命令。
小而明确的任务描述。

这不是为了服务 AI，而是把项目变得更工程化。AI 只是放大了这些工程习惯的价值。

二、Vibe Coding 适合启动项目，但不能代替验收

AI Builder、Trae Builder、Cursor Agent 这类工具让项目初始化、配置、脚手架和迁移变得非常快。过去需要手动处理的 Vite、TypeScript、ESLint、测试、README、license、构建脚本，现在可以通过对话快速生成。

这类能力特别适合：

新项目初始化。
小型工具开发。
老代码迁移成 TypeScript。
补测试和文档。
重构重复样板代码。

但企业级开发不能只看“生成出来了”。每个 AI 生成的项目都要经过验收：

依赖是否合理，有没有引入不必要的大包。
配置是否能在 CI 跑通。
类型检查是否开启严格模式。
测试是否覆盖核心逻辑。
安全配置是否默认关闭危险能力。
README 是否与实际命令一致。

AI Builder 像一个速度很快的助理，可以快速搭页面、连组件、写初稿；最终能不能进入真实项目，还要靠工程验收。

三、本地模型：隐私、成本与能力的取舍

Ollama 这类工具让开发者可以在本地运行模型，例如 qwen、llama、phi 等。它带来的价值很明确：

数据不离开本机或内网。
单次调用成本可控。
可离线或半离线运行。
方便做工具调用实验。

但本地模型也有代价：

小模型能力有限，复杂推理不如云端强模型。
推理速度受硬件影响。
多用户并发需要额外服务设计。
模型下载、更新和版本管理也要维护。

因此本地模型更适合这些场景：

文件分类、摘要、标签生成。
内部工具助手。
隐私敏感的轻量问答。
离线开发辅助。
工具调用流程验证。

如果任务需要高质量长推理、复杂代码理解或高可靠事实判断，仍然要考虑云端强模型或混合架构。

四、Tools 让模型从“回答”变成“执行”

工具调用是企业 AI 的关键分水岭。没有工具时，模型只能输出文本；有工具后，模型可以查文件、读数据库、调用搜索、执行业务接口、创建任务。

一个工具通常包含：

名称。
描述。
参数 schema。
执行函数。
权限边界。
返回格式。

例如给模型一个列目录工具：

const tools = [
  {
    type: "function",
    function: {
      name: "listFiles",
      description: "列出指定目录下的文件",
      parameters: {
        type: "object",
        properties: {
          path: { type: "string" }
        },
        required: ["path"]
      }
    }
  }
];

工具调用最容易犯的错误，是只关注“模型会不会调用”，忽略“模型能调用什么”。企业里必须把权限设计清楚：

读和写分开。
测试环境和生产环境分开。
普通用户和管理员分开。
高风险动作需要确认。
所有工具调用要有日志。

工具不是让模型随便操作系统，而是给模型一组受控动作。

五、MCP 解决的是工具生态标准化

普通工具调用很灵活，但每个项目都要重复定义工具、连接方式和参数。MCP 的价值，是把外部能力标准化成 server，客户端可以发现工具、读取 schema、调用工具并接收结果。

可以把 MCP 理解成“AI 时代的工具插座”。一个文件系统 server 暴露读写文件能力，一个数据库 server 暴露查询能力，一个搜索 server 暴露检索能力，一个设计系统 server 暴露组件文档。模型不需要知道每个系统内部怎么连，只需要通过统一协议使用工具。

一个 MCP 工具定义通常包含：

server 名称和版本。
tool 名称。
tool 描述。
参数 schema，常用 Zod 定义。
执行逻辑。
transport，例如 stdio 或 HTTP。

这种标准化有三个好处。

第一，复用。一个工具 server 可以被多个 Agent 或 IDE 使用。

第二，治理。权限、审计、版本和参数都可以集中管理。

第三，组合。模型可以根据任务动态选择工具，而不是每个应用都硬编码一套接口。

但 MCP 不是安全魔法。server 暴露什么能力，模型就可能尝试调用什么能力。企业落地时，最小权限仍然是第一原则。

六、RAG 从搜索走向项目知识网络

企业 AI 助手最常见需求是“基于我们的资料回答”。这就需要 RAG。

RAG 有不同层级：

搜索式 RAG：调用搜索引擎或内部搜索，适合公开资料和实时信息。

文件式 RAG：根据目录结构读文档和代码，适合项目资料清晰的仓库。

向量式 RAG：把文档切块后向量化，适合大规模知识库。

混合式 RAG：先搜索或向量召回，再让模型读关键文件或补充上下文。

企业场景不要一上来就迷信向量数据库。向量检索适合语义相似，但不一定适合精确版本、路径、代码引用和权限边界。很多内部助手需要混合策略：

先根据问题判断资料类型。
如果是代码问题，优先查文件结构和符号。
如果是政策或 FAQ，优先查文档库。
如果是实时状态，调用业务系统 API。
最后把最相关材料交给模型回答。

RAG 的质量取决于检索质量，而不只取决于模型质量。

七、端侧推理让前端重新拥有模型能力

Transformers.js 和 WebGPU 让浏览器直接运行一部分模型成为现实。它不适合替代所有云端大模型，但非常适合轻量任务：

情感分析。
文本分类。
简单摘要。
图片分类。
语音或视觉预处理。
隐私敏感的本地判断。

端侧推理有几个明显优势：

数据不出浏览器。
延迟低。
服务端成本低。
离线能力更强。

也有约束：

首次加载模型体积大。
低端设备性能不稳定。
浏览器兼容和 WebGPU 支持要检测。
适合小模型，不适合复杂长推理。

一个合理架构是：端侧模型做轻量预处理和分类，云端模型做复杂推理；端侧先判断用户评论情绪、图片类型或输入风险，再决定是否调用后端大模型。

八、企业级 AI 前端的参考架构

可以把企业 AI 前端分成六层：

UI 层：聊天、表单、文件上传、任务状态、历史记录。
状态层：当前会话、流式内容、工具调用进度、错误恢复。
BFF 层：鉴权、限流、模型路由、日志、费用统计。
Agent 层：提示词、工作流、工具选择、记忆和策略。
工具层：MCP、业务 API、搜索、数据库、文件系统。
模型层：云端强模型、本地模型、端侧轻量模型。

用户只看到 UI；工程质量主要取决于后五层。尤其是 BFF 和工具层，它们决定了安全边界和成本边界。

九、工具调用的安全清单

企业场景使用 Tools 或 MCP 时，建议至少检查：

工具是否只暴露必要能力。
参数是否有 schema 校验。
路径、SQL、命令是否有注入风险。
写操作是否需要确认。
是否区分用户身份和权限。
是否记录输入、输出、耗时和调用者。
是否支持 dry-run。
是否能撤销或补偿失败操作。

例如 listFiles(path) 看似无害，但如果允许任意路径，就可能读取不该读的目录。exec(command) 更危险，除非限定命令白名单，否则不应该直接暴露给模型。

十、未来前端会更像 AI 运行环境

前端过去主要负责展示和交互。进入 AI 时代后，前端会承担更多智能编排能力：

组织用户上下文。
展示流式结构化输出。
管理多模态任务状态。
接入端侧模型。
与后端 Agent 和工具网络协作。
用 AI Coding 改进自身开发流程。

这不是说前端要变成全部后端，也不是说浏览器要运行所有模型，而是前端会成为 AI 产品体验的主要战场。用户对 AI 的感受，很大程度来自前端如何处理等待、状态、错误、信任和控制权。

企业级 AI 前端不是某个模型单点发挥，而是一张工程网络知道何时调用工具、何时检索知识、何时切换本地模型、何时把能力放到端侧。AI Coding 提升研发速度，Tools 与 MCP 扩展行动能力，RAG 提供知识基础，本地和端侧模型提供成本与隐私选项。把这些组合好，AI 才能从“会回答”走向“能工作”。