最近在看本地部署的 AI Agent，我发现一个容易被混为一谈的问题：应用运行在自己的电脑上，是否就意味着所有数据都只在本机处理？答案是不一定。
这里用 OpenWorkBuddy 作为一个具体案例，梳理本地办公 Agent 的运行位置、模型调用和工具访问之间的关系。它的价值不仅在于生成 Word、Excel 或 PPT 文件，也在于让我们看清一项 Agent 任务从输入到落盘，中间经过了哪些环节。
一、先区分三个“本地”
讨论本地 AI 时，至少有三个不同层次：
应用本地运行：服务进程运行在个人电脑或自建服务器上；
数据本地存储：会话、配置和成果文件写入部署者管理的目录；
模型本地推理：提示词和上下文由本机模型处理，不发送给云端 API。
这三个条件彼此相关，但并不自动同时成立。应用可以部署在自己的服务器上，却仍然调用云端模型；本地保存生成文件，也不代表模型调用之前没有把必要上下文传出网络。
OpenWorkBuddy 同时支持配置云端模型渠道和 Ollama 等本地模型，也有网页搜索、MCP 连接器和即时通讯入口。因此，数据实际走向取决于选择了什么模型、启用了哪些工具，以及任务中传入了什么材料。
二、把一次 Agent 任务画成数据流
一项“读取表格并生成季度报告”的任务，大致会经过下面几个阶段：
用户指令与附件
↓
会话上下文与项目设置
↓
模型规划和工具选择
↓
读取文件 / 调用外部工具 / 写入成果
↓
文件检查与结果呈现
每个箭头都值得单独问一句：数据有没有离开当前机器？
指令和附件进入云端模型时，遵循对应模型服务的接口与数据条款；
调用本地 Ollama 时，推理请求发给配置的本地服务，但如果同一任务又使用网页搜索或远程 MCP，仍会产生网络访问；
文件写入本机目录，只能说明产物存在哪里，不能反推前面所有计算都在本机完成。
所以，比“它是不是本地软件”更有用的问题是：模型运行在哪、工具连接到哪里、输入材料经过哪些服务、成果保存到哪个目录。
三、准备一个低风险的本机验证
OpenWorkBuddy 项目要求 Node.js 18 或更高版本。从源码目录安装依赖后，可以用 Node 服务启动，也可以启动桌面端：
npm install
npm start
桌面端的启动命令是：
npm run app
服务启动后，先在模型设置中选择一个可用渠道。第一次验证不要使用合同、客户名单或财务原件，准备一份虚构或公开数据的小表格即可。比如提出这样的任务：
读取工作区中的 sample.csv，按月份汇总销售额，生成 monthly-summary.xlsx。保留输入文件，不确定的字段请列出来，不要自行补数据。
接着观察任务实际调用了哪些工具、模型配置是什么、输出写到了哪里。不要只看聊天回复中的“已完成”。可以再检查目标文件是否真实存在：
test -s monthly-summary.xlsx && echo "文件存在且非空"
这个检查只能确认文件存在且非空，不能判断表格数据正确。还应使用表格程序或脚本打开它，检查工作表、关键单元格、公式和图表，并复核计算口径。
以上是复现思路，不代表我在你的机器上跑过这组命令。不同系统、配置和版本可能需要调整工作目录或模型设置。
四、如何设计一份数据流清单
部署前可以按下面的表格逐项填清楚，避免用“本地部署”三个字代替安全评估：
环节需要记录的内容
应用进程运行设备、监听地址、运行账号
工作区可读写目录、附件来源、成果保存位置
模型服务名称、云端或本地、发送的上下文范围
工具Shell、搜索、MCP 等的地址和权限
凭据API Key 存储位置、访问范围、轮换方式
团队访问账号、角色、注册策略和租户隔离
备份备份目录、频率、恢复验证方式
如果组织要求完全离线，除了使用本地推理模型，还要检查启动、更新、插件安装、搜索、IM 和 MCP 等流程是否访问外网。只要还有一个环节访问外部服务，就不能笼统地说整个系统“断网可用”。
五、Agent 的文件交付也需要验收
办公 Agent 和聊天机器人的差别，不应只看它能不能调用工具，而要看工具结果有没有被正确验证。
“模型回复文件已经生成”只是自然语言。更稳妥的成功条件至少包括：
文件路径符合任务要求；
文件真实存在且可以打开；
关键字段或页面结构符合要求；
对不确定的数据明确标记，而非补造结论；
失败时把错误告诉用户，提供可恢复的下一步。
风险越高，验收越严格。一个普通会议纪要草稿可以由员
六、结论：谈数据安全，要谈具体配置
OpenWorkBuddy 展示了一种把模型路由、文件工作区和工具执行放到同一任务链中的方式。它可以连接本地模型，也可以连接云端模型；这让使用者有选择空间，也意味着部署者必须弄清楚当前任务的真实数据路径。
评估任何本地 Agent，都可以从一份无敏感信息的测试文件开始：固定模型，记录工具调用，检查输出文件，再确认网络边界。完成这几步之后，“数据在哪里处理”就不再是产品口号，而是一组可以验证的配置事实。
许可说明
OpenWorkBuddy 主体代码采用 PolyForm Noncommercial 1.0.0。企业实际业务使用、个人商业用途、商业二次开发或客户交付前，应先确认商业授权范围。