OpenDocBot 完全指南：把 M365 的 Word/Excel/PPT 接上 100% 本地、可自由切换的 AI 模型
把整份合同、报表或 PPT 交给云端 AI 助手改，代价很直接：你的文档离开了机器，模型跑在别人的服务器上，还常常要按座位付费。OpenDocBot 想换一种做法——它是一个 100% 客户端、provider 无关的 Microsoft Office 插件，同时覆盖 Word、Excel、PowerPoint 的桌面版和 Web 版：AI 助手跑在你自己的浏览器里，文档只发给你自己选的模型，甚至能完全离线。这篇指南覆盖它的定位、数据流、支持范围、三种上手方式和安全模型，适合已经在用 M365、又在意文档数据不出内网的人。
定位：一个 100% 客户端的 M365 AI 插件
OpenDocBot 是一个 fair-code（源码公开、可审计）的 Microsoft 365 AI 插件：整个代码库和开发过程都在 GitHub 上公开，个人与 30 人以内的小团队免费使用，超过该规模的商业部署才需要商业授权。它的口号很直接——”the Office AI agent you can actually trust”，主打客户端运行、无供应商锁定、零遥测。
技术上它偏前端：React 18 + TypeScript + Vite + Zustand，通过 Word.js、Excel.js、PowerPoint.js 这三套 Office API 操作文档，测试用 Vitest 和 React Testing Library。它不是又一个要装重型后端的工具，本质是一个跑在 Office taskpane 里的 web app，这也解释了为什么它的部署和权限都围绕”浏览器 + 一个 HTTPS 端口”展开。
“本地”是真的吗：看数据流
这是它最核心、也最值得一看的一点。官方托管实例 opendocbot.com/app 只在 Office taskpane 首次加载时把插件下发一次，之后所有计算都在你机器上完成，插件直接和你的模型通信——官方声明没有任何文档数据到达它的服务器，且零遥测。换句话说，他们的服务器只负责”把 app 发给你一次”，之后你和模型之间的对话、文档的读写，都发生在你的环境里。
它本身不绑定任何模型。你用自己的 API key，在 OpenAI、Anthropic（Claude）、Gemini、DeepSeek、Ollama（本地）、OpenRouter、OpenCode 之间即插即换，也支持任意 OpenAI 兼容端点（走 Custom 预设）。内部它们都实现同一个 LLMProvider 接口：OpenAI、DeepSeek、Ollama、OpenRouter、Custom 走 Responses API 加 /chat/completions；Claude 走 Messages API（/v1/messages）；Gemini 走 generateContent / streamGenerateContent。提示词缓存方面，OpenAI、DeepSeek、OpenRouter 自动缓存，Anthropic 在服务端缓存系统提示与会话前缀，Ollama 和 Custom 则取决于网关，插件本身不控制。
配 Ollama 就能彻底离线：文档数据完全不离开你的内网，这是它隐私叙事的落脚点，也是它相对云端 SaaS 最实在的差异。
边界：只认 Microsoft 365
别被”Office”两个字带偏。它只支持 Microsoft 365 的 Word/Excel/PowerPoint（桌面 + Web），Office 2016/2019/2021 永久授权版、LibreOffice、Google Docs 都不支持——文档的 Compatibility 表写得很清楚。选工具前先对一下自己用的到底是哪个版本，这是它最容易被误判的边界；如果你还在用永久授权版，这个插件暂时帮不上忙。
上手：三种部署路径
1. 托管实例（最快）：直接用 opendocbot.com/app。插件只被下发一次，之后全在本地跑，适合先试用再决定要不要自托管。
2. 侧载到 Office（当前正式方式）：目前处于 Early Access，微软商店分发还没上，需要按文档的 Sideloading Guide 手动侧载，体验和将来的商店版一致。
3. 自托管：把静态 web app 和可选的 proxy 部署到自己的基础设施，适合想完全掌控部署的人。所有服务监听单一端口 3000；Office 拒绝纯 HTTP，所以必须 HTTPS，需要在装插件的机器上有一个可信的 TLS 证书。文档推荐用 Docker Compose（Option 1，最省事）：克隆仓库、cp .env.example .env，再在 .env 里配置端口与 TLS。关键变量有 OPENDOCBOT_HOST_PORT（默认 3000）、PORT（监听端口）、HOST（默认 0.0.0.0）、DIST_DIR（要 serve 的构建产物），以及 HTTPS 必需的 TLS_CERT/TLS_KEY——它们要填 base64 编码的 PEM。流程大致是：
git clone https://github.com/OpenDocBot/OpenDocBot.git cd OpenDocBot cp .env.example .env
mkcert -install mkcert -key-file ~/.opendocbot-key.pem -cert-file ~/.opendocbot-cert.pem localhost base64 -w0 ~/.opendocbot-cert.pem base64 -w0 ~/.opendocbot-key.pem docker compose up -d --build
把两条 base64 输出分别粘进 .env 的 TLS_CERT/TLS_KEY，启动后插件就挂在 https://localhost:3000 上。注意 Docker 镜像在构建时就把 proxy 固定为开启（VITE_PROXY_ENABLED 是构建期变量，不在运行时 .env 里读）；文档还给了另外两种非 Docker 的部署方式（Option 2/3），需要 npm install。
proxy 本身是可选能力：用来转发那些浏览器端会被 CORS 挡掉的 provider（比如 OpenCode）；对允许浏览器直连的 provider（OpenAI/DeepSeek/Gemini/Anthropic/OpenRouter）不需要 proxy，静态 app 直接就能跑。
安全模型：人在回路与建议模式
它把模型对文档的每次改动都放在人工审批之后（human-in-the-loop）：AI 提出要改哪里，你批准后才落笔。还有一个 Suggestion Mode（只读审查）：模型以 Word/Excel 原生评论的形式提出修改建议，而不直接改内容——适合”先看 AI 建议、再决定要不要用”的工作流，把误改风险降到最低。
适合谁，现在能预期什么
- 用 Microsoft 365（不是老版本 Office）、在意文档数据不出内网的个人和小团队（30 人以内免费）；
- 想自由切换模型、或希望完全本地跑（Ollama）的人；
- 想要”先审后改”、全程可审计的 AI 文档工作流的人。
要预期的现实是：它还在 Early Access，功能可用但需要侧载，官方也明说”expect some rough edges”（预期有些毛边）。把它当作一个方向很对、适合小范围先试的工具，而不是开箱即用的成熟产品。