文章摘要： 本文记录了在仅有 2核4G 内存的轻量级云服务器上，从零搭建基于 Spring AI + Ollama + PgVector 的 MCP（Model Context Protocol）知识库系统的全过程。通过 Docker Compose 解决多环境端口冲突，利用 Swap 虚拟内存打破硬件瓶颈，并结合 Java 定时任务实现自动化内容生产。这是一份关于如何在低配资源下进行 AI 工程化落地的实战笔记。

一、 起心动念：在“小机器”上跑大模型

随着 AI Agent 和 MCP（模型上下文协议）概念的兴起，单纯调用 API 已经无法满足我对 AI 工程架构的探索欲。我决定动手搭建一套完整的 AI 知识库系统，包含 Java 业务后端、向量数据库、缓存中间件以及本地推理引擎。然而，摆在我面前最大的挑战是基础设施的限制——手头只有一台配置为 2核CPU、4GB 内存的阿里云轻量应用服务器。在这台本就运行着其他项目的“寸土寸金”的机器上，我不仅要额外部署 PostgreSQL (PgVector)、Redis、Ollama 等多达 11 个 Docker 容器，还要确保系统运行稳定不崩溃。这不仅是一次代码的编写，更是一场关于服务器资源管理的极限挑战。

二、 破局环境冲突：Docker 容器的多租户生存之道

项目的起步阶段便遭遇了现实的“当头一棒”。当我尝试启动新的 MCP 环境时，Docker 守护进程直接抛出了 Container name already in use 和 Bind for 0.0.0.0:xxxx failed 的错误。原因显而易见：服务器上原本运行的旧项目已经占据了 PostgreSQL 的 5432 端口和 Redis 的 6379 端口。在不停止旧服务的前提下，我必须让新旧两套环境共存。解决这个问题的关键在于对 docker-compose 配置文件的精细化手术。我并没有粗暴地删除旧容器，而是修改了新项目的服务编排，为每一个新容器定义了独一无二的 container_name，例如将向量库命名为 ai_mcp_vector_db。更关键的操作在于端口映射的移位，我将宿主机的端口进行了错位配置，比如将新应用的对外端口映射为 8091，将向量库映射为 15433，而容器内部端口保持不变。这种“移花接木”的策略，成功实现了在同一台宿主机上运行多套微服务环境，且互不干扰。

三、 资源保卫战：4GB 内存下的“苟住”哲学

环境跑通后，紧接着面临的是更严峻的“内存焦虑”。Ollama 加载大模型推理时对内存的需求极高，加上两个 Java 应用和各类数据库，4GB 的物理内存瞬间捉襟见肘。通过服务器监控面板可以看到，物理内存的使用率长期徘徊在红线边缘。为了防止 Linux 的 OOM Killer（内存溢出杀手）强制杀掉核心进程，我采取了至关重要的“保底”策略——配置 Swap（虚拟内存）。根据系统监控数据显示，虽然物理内存仅剩约 121MB 的空闲空间，但系统成功利用了 4GB Swap 空间中的部分资源。这部分硬盘空间虽然读写速度不如内存，但在高负载瞬间充当了关键的缓冲池，确保了系统的稳定性。此外，在模型策略上，我选择了参数量较小的 Qwen2-1.5B 模型或采用 API 调用的方式，避免了本地运行 70B 级巨型模型导致的服务器直接宕机。

四、 业务逻辑与自动化：容错与流水线设计

在基础设施稳固之后，我着手于应用层的逻辑实现。基于 Spring AI 框架，我编写了核心业务类 MCPServerCSDNJob，旨在通过定时任务自动生成技术文章。代码中采用了 Spring 的 @Scheduled 注解来控制任务频率，设定了 Cron 表达式以按需执行。在实际的工程落地中，鲁棒性比功能性更重要。因此，我在代码中包裹了完善的 try-catch 异常处理机制，无论是 AI 服务响应超时，还是因平台限制导致的发布失败，程序都会捕获异常并打印日志，而不会导致整个应用崩溃退出。这种设计确保了自动化流水线具备“自我恢复”的能力，即使某次任务失败，下一个调度周期依然能正常唤起，实现了真正的无人值守运行。

五、 打通最后一公里：云端安全与网络配置

当容器显示 Healthy 且日志无误时，我却一度无法在浏览器中访问新部署的管理后台。排查发现，这是由于云服务器的安全策略导致的。Docker 端口映射只是在操作系统层面打开了通道，但阿里云的安全组防火墙默认拦截了所有非标准端口。为了让 PGAdmin、Redis Commander 以及 Java 应用的 API 能够被外部访问，我登录云控制台，在安全组规则中手动放行了 8091、8082、5050 以及 15433 等自定义端口。随着这一步配置的完成，由于网络隔离导致的服务不可达问题迎刃而解，整套基于 MCP 的 AI 知识库系统终于实现了从后端数据处理到前端可视化管理的全面贯通。

六、 总结与复盘

回顾这次搭建过程，学习 MCP 和 AI 项目不仅仅是学习 Prompt 提示词的编写，更是对全栈工程能力的考验。从 Docker 的网络隔离与端口规划，到 Linux 系统的内存管理，再到 Java 业务逻辑的容错设计，每一个环节都不可或缺。对于想要入门 AI 工程化的开发者来说，不要因为硬件配置低而止步，合理的资源编排和系统调优完全可以让小机器释放出巨大的能量。先让系统跑起来，通过日志排查每一个报错，才是掌握这一前沿技术的最佳路径。