完全本地化部署AI智能体平台：每个组件需要什么？

想让一套AI智能体平台完全运行在本地模型上，数据不出内网，这在技术上可行，但远比想象中复杂。Vstorm团队的开发者在Reddit上分享了基于其开源平台AgenticOS（Apache-2.0协议）的实践经验，拆解了实现"零第三方介入"所需的每一个环节。核心观点很直接：仅仅"自托管"这个标签并不能保证数据完全不外流，每个组件都是一次独立的选择。

完全本地化需要配齐哪些组件

要搭建一套数据不离开网络的智能体系统，需要逐一确认以下几个关键部件，任何一处疏漏都可能让数据悄悄流向外部。

对话模型

核心的聊天模型可以通过Ollama配置文件（无需API密钥，指向自己托管的端点），或者自建的LiteLLM代理来转发到本地模型。vLLM和LM Studio则通过OpenAI兼容端点接入。作者特别强调了一个容易被误解的点：一个配置之所以算"自托管"，是因为它的端点在本地，而不是因为它没有密钥。换句话说，没有密钥并不等于本地化。

嵌入与文档解析

嵌入（Embeddings）同样需要自建Ollama服务，注册为本地服务后按知识库集合逐一选择。文档中强调嵌入模型是"永久性选择"——分块数据和搜索查询只会发往这个指定的主机，不会流向别处。

文档解析方面，默认采用PyMuPDF，配合LiteParse和Tesseract OCR在worker中运行。需要注意的是，LlamaParse属于云端方案且需要密钥，想要完全本地化就必须关掉它。

嵌入（Embeddings）在RAG（检索增强生成）架构中扮演着将文本转化为向量的关键角色。当用户上传文档或提问时，系统会调用嵌入模型将文本转换为高维向量，存储在pgvector这类向量数据库中，检索时再通过语义相似度匹配找到相关内容。正因如此，嵌入模型是一个"永久性绑定"决策——一旦知识库用某个模型完成了向量化，切换模型意味着所有历史数据必须重新嵌入，否则新旧向量之间的距离计算将失去意义。如果嵌入服务指向云端API，每一次文档上传和查询请求都会将文本内容发送到外部，这是隐私泄露中最容易被忽视的一条路径。

追踪与工具调用

追踪（Traces）环节的处理很简单：不设置LOGFIRE_TOKEN，也不在任何agent或环境上配置追踪令牌，运行记录就会留在本地。

工具是最大的"外流风险点"。作者明确建议不要绑定网络搜索、网页抓取、浏览器自动化、mem0记忆或任何MCP服务器——因为这些功能每一个都会向外发起调用。这意味着完全本地化会牺牲一部分能力，需要在隐私与功能之间做权衡。

MCP（Model Context Protocol）是由Anthropic提出的一套开放协议，旨在标准化AI模型与外部工具、数据源之间的交互方式，类似于为AI智能体提供一个统一的"插件接口"。MCP服务器可以暴露文件系统、数据库、网络服务等各类能力供模型调用。问题在于，公共MCP服务器注册表本身托管在外部，而每个MCP服务器在执行时都可能向其自身的远程端点发起网络请求。因此，即便对话模型和嵌入模型都已完全本地化，一个接入了外部MCP服务器的智能体仍然会在工具调用阶段将数据带出内网。这也是文章中建议用--no-mcp跳过注册表镜像的原因。

本地模型的两个隐藏陷阱

在采用本地模型时，有两个容易被忽视但影响重大的问题值得警惕。

第一个是预算控制失效。平台的费用是按运行所使用的API密钥来归属的，而无密钥的本地模型不记录任何花费。这就带来一个隐患：常规的美元预算机制管不住本地模型的失控行为。真正能阻止工具陷入死循环的，是每个agent的步数上限（max_steps，即单次运行的模型请求数上限）。作者反复提醒：一定要设置这个值。

第二个是智能体的能力完全取决于模型的工具调用能力。规划、文档搜索、沙箱操作全部通过工具调用完成。作者坦诚表示，团队目前没有本地模型的基准测试可供分享，因此不会声称某个模型"效果很好"。这种实事求是的态度，反倒点出了本地部署当前最大的不确定性所在。

max_steps（最大步数）限制是智能体系统中防止"失控循环"的基本安全机制。在多步工具调用场景中，智能体会反复调用模型来规划下一步动作——若某个工具调用始终返回错误或模型陷入错误的推理循环，没有步数上限的智能体会持续运行并消耗资源。对于使用付费API的场景，账单本身会形成自然的外部约束；但本地模型几乎零边际成本，失控运行的代价转移到了计算资源和时间上，且完全不可见。在生产环境中，max_steps通常需要结合具体任务复杂度来设置——过低会导致复杂任务无法完成，过高则失去保护作用。

部署环境与现状

搭建这套系统需要Docker Compose 2.24及以上版本，两个已发布的镜像（支持amd64和arm64架构），外加由同一个compose文件启动的带pgvector的Postgres、Redis和Prefect。

安装器带有一个--check标志，仅用于测试前置条件。由于安装器默认只提供托管服务商选项，想要本地化就得选择"稍后决定"（--provider none），然后在控制台里手动添加Ollama或vLLM配置。它还会默认镜像公共MCP服务器注册表，因此需要用--no-mcp来跳过这次下载。

作者也坦率说明了项目的局限：目前仍是0.0.x版本，仅支持单主机，没有Kubernetes清单，也没有重排序器（reranker）。此外还有一个面向HIPAA合规的配置，会解析每个模型端点的主机名来判断是否为本地——所以像https://ollama.vendor.example这样的地址并不算本地。作者特别澄清，这只是一项配置检查，而非合规认证。

留给社区的开放问题

作者在文末抛出了一个颇具实操价值的问题：目前大家在用哪些本地模型能稳定实现多步工具调用？在什么参数规模、什么硬件上？

这个问题恰恰点中了本地化智能体的痛点。对于隐私敏感的医疗、金融、政务等场景，完全本地化部署的需求真实存在；但本地模型在多步工具调用上的可靠性仍是未知数。平台层面可以做到数据不外流，可智能体最终的表现，依然被底层模型的能力所限制。

项目仓库和文档已开源，本地部署的完整说明可在其数据保护文档中找到。对于想要构建真正"零外部依赖"智能体系统的团队来说，这份组件清单提供了一个务实的起点——它没有夸大效果，而是把每一处可能泄露数据的环节都摆在了明面上。