普通聊天接口让大模型“回答问题”，Function Calling 则让大模型参与“选择并调用系统能力”。
两者表面上都接收消息并返回结果，但工程目标完全不同：普通聊天主要生成自然语言；Function Calling 需要模型、工具、权限、状态和错误处理共同组成一个执行闭环。
我在企业诊断报告类 AI 项目中设计过兼容 OpenAI Function Calling 格式的轻量工具调用框架，也做过 MCP 客户端与服务端集成。本文从工程角度说明两者的区别，以及什么时候值得引入工具调用。
本章以企业运营诊断 AI Copilot 为例，展示 Java 服务、DDD、消息、检索、LLM 工具调用、实时推送、工作流与 DevOps 如何形成一个完整系统。它不是特定业务的唯一实现，而是一份可用于架构设计和面试阐述的参考蓝图。
这个项目将 Java、Spring、DDD、Redis、RabbitMQ、Elasticsearch、工作流、LLM Function Calling、MCP、SSE、性能与 DevOps 串成一条完整链路。
企业 AI 应用的本质是将概率模型嵌入确定性系统：程序负责身份、权限、数据、工具与审计，模型负责语言理解、归纳和受约束的决策。RAG 解决知识与事实来源，Function Calling/Skill 解决受控动作，MCP 解决工具互操作，评测与观测解决持续可信。
LLM 擅长语言理解、信息抽取、归纳与受约束的决策；它不天然可靠、不了解实时数据，也不具备权限。生产系统应把模型放在受控流程中：模型负责推理，程序负责权限、数据、动作和校验。
上一篇文章介绍了如何用 Spring AI 构建 Java 版的 MCP Server。但 MCP 远不止 Java——它的官方 SDK 支持 TypeScript/Python/Kotlin，生态非常活跃。
本文将用 Node.js + TypeScript 从零搭建一个 MCP Server，并介绍如何将 AI 对话数据从 Elasticsearch 迁移到 MySQL 的数据管道设计。两个项目结合起来，展示了一条完整的 "AI 工具开发 + AI 数据工程" 链路。
2024-2025 年 AI 领域最火的关键词，除了大模型本身，**MCP（Model Context Protocol）**一定排在前列。Anthropic 提出的这套协议，让 AI 模型能够以标准化的方式调用外部工具和数据源，一夜之间成了 AI Agent 的事实标准。
Spring 社区反应极快——Spring AI 1.0.0-M7 已经内置了完整的 MCP Server 支持。本文将带你从零搭建一个 MCP Database Server，让 AI 助手能够直接查询你的数据库。
