普通聊天接口让大模型“回答问题”，Function Calling 则让大模型参与“选择并调用系统能力”。
两者表面上都接收消息并返回结果，但工程目标完全不同：普通聊天主要生成自然语言；Function Calling 需要模型、工具、权限、状态和错误处理共同组成一个执行闭环。
我在企业诊断报告类 AI 项目中设计过兼容 OpenAI Function Calling 格式的轻量工具调用框架，也做过 MCP 客户端与服务端集成。本文从工程角度说明两者的区别，以及什么时候值得引入工具调用。
老系统不好维护时，团队很容易形成两个极端观点：
两种判断都可能有道理，也都可能把项目带入困境。
我参与过大型中台的服务聚合、接口治理、异构平台迁移和领域模型建设。实践中，决定是否重构的关键并不是代码“看起来有多旧”，而是业务价值、风险边界、经济账和演进路径能否同时成立。
在启动重构前，我通常先看以下四项。
技术团队常见的不满包括代码重复、框架老旧、分层不标准、测试不足。这些是技术债，但不一定足以支持一场大规模重构。
提到企业大模型应用，很多方案的第一反应都是：把资料放进向量数据库，搭一套 RAG，再做一个聊天页面。
RAG 很有价值，但它解决的是“从非结构化知识中找到相关证据，并辅助模型生成回答”。如果业务真正需要的是精确计算、实时查询、流程执行或规则判断，先上 RAG 反而可能绕远路。
在企业智能问数、知识检索和自动诊断报告的实践中，我越来越倾向于先判断任务类型，再决定使用 RAG、工具调用、规则引擎还是普通软件功能。
例如：
“这个接口昨天还是 200ms，今天突然变成 5 秒。”
遇到这类问题，最危险的做法是立即改线程池、加缓存或者重启服务。它们有时能暂时缓解问题，却可能掩盖真正原因，并给系统引入新的不确定性。
我做过中台慢接口治理、性能边界压测和高并发服务调优。面对接口变慢，我通常按照“先界定范围，再沿调用链缩小问题”的方式排查，重点检查以下五个位置。
第一步不是看代码，而是建立事实：
企业知识库项目最常见的错觉是：上传几份文档，问几个预先准备好的问题，模型回答得像模像样，于是大家认为项目已经完成了大半。
但 Demo 能回答，不等于系统有人用；有人试用，也不等于能够进入真实业务流程。
我参与过企业智能问数、卡片检索和诊断报告类 AI 应用的设计与交付。实践中真正困难的部分通常不是“把向量数据库接上”，而是让知识、检索、权限、评测和业务动作形成一个可以长期运营的闭环。
本文总结企业知识库从 Demo 走向生产时最容易忽略的五个问题。
本章以企业运营诊断 AI Copilot 为例，展示 Java 服务、DDD、消息、检索、LLM 工具调用、实时推送、工作流与 DevOps 如何形成一个完整系统。它不是特定业务的唯一实现，而是一份可用于架构设计和面试阐述的参考蓝图。
这个项目将 Java、Spring、DDD、Redis、RabbitMQ、Elasticsearch、工作流、LLM Function Calling、MCP、SSE、性能与 DevOps 串成一条完整链路。
性能工程回答系统在给定负载下能否满足 SLO；DevOps 将构建、测试、发布和回滚变成可重复流程；安全与可信研发限制身份、数据、依赖和操作风险。它们共同决定代码能否在生产环境长期运行，而不只是“功能能否演示”。
性能优化不是“把 TPS 跑高”，而是明确业务场景下的容量边界和服务质量。
每个场景写清：业务动作、数据规模、并发模型、读写比例、依赖模拟方式、成功标准和失败阈值。核心指标至少包括吞吐（TPS/QPS）、P50/P95/P99 延迟、错误率、CPU、内存、GC、线程池、连接池、数据库负载和消息积压。
企业 AI 应用的本质是将概率模型嵌入确定性系统：程序负责身份、权限、数据、工具与审计，模型负责语言理解、归纳和受约束的决策。RAG 解决知识与事实来源，Function Calling/Skill 解决受控动作，MCP 解决工具互操作，评测与观测解决持续可信。
LLM 擅长语言理解、信息抽取、归纳与受约束的决策；它不天然可靠、不了解实时数据，也不具备权限。生产系统应把模型放在受控流程中：模型负责推理，程序负责权限、数据、动作和校验。
关系型数据库保存业务事实与事务约束；Redis 处理低延迟的临时状态；RabbitMQ 负责异步传递与削峰；Elasticsearch 提供搜索、聚合与向量召回；工作流引擎管理长生命周期的人机流程。它们各自解决不同问题，不能互相替代。
MySQL、PostgreSQL、GaussDB、Oracle 的 SQL 细节不同，但设计原则一致：以约束保护数据，以索引支撑访问路径，以执行计划证明性能。
DDD 不是将项目机械分为四个包，而是用统一语言和边界控制复杂性；分布式设计不是追求“最终一致”，而是在不能使用单一事务的地方，明确哪些结果必须立即一致、哪些结果可恢复地异步收敛。
DDD 的价值在于让业务概念和软件模型一致，降低规则散落在 Controller、SQL、定时任务和前端中的风险。先找业务语言，再决定类和表。
