正在加载，请稍候
11 周交付一个桌面 AI 助手，两次推倒重来都发生在权限沙箱和工具调用并发上，不在模型。附脱敏实测数据与内网部署的验收口径。
客户是某制造业集团，1200 名员工、三套自研生产系统，IT 团队 9 人。11 周里我们给工艺、质检、采购三个岗位交付了一个数据不出内网的桌面 AI 助手。最难的两处不在模型，而在权限沙箱和工具调用并发——两次都是提测后推倒重来。
立项第一周，最省事的方案是内网 Web 应用加一个浏览器插件。评估两天后否掉，原因是三个具体动作浏览器做不了或做起来很别扭：
这三个约束把路线收窄到桌面客户端。这一步判断没问题，代价是后面所有工期风险全压在客户端工程上。
我们用 Electron 做壳，界面与业务逻辑用 TypeScript，重活下沉到一个本地 Go 服务。理由不是生态热闹，而是渲染层和 Node 层能共用一套类型定义，9 个人的 IT 团队后续自己维护得住。同类框架的取舍我们在 桌面应用定制开发 2026 的选型对比里展开过，这里不重复。
容易被漏掉的是升级成本。该框架 44 版于 2026 年 8 月 25 日发布，内置 Chromium 152.0.7977.54、V8 15.2、Node 24.18.1；42 版在 5 月 7 日、43 版在 7 月 2 日，节奏大致两三个月一个大版本（Electron 官方博客）。一年至少 3 到 4 次安全升级窗口，客户合同里若写了漏洞修复时效，这块工作量要提前进报价单。
我们最初的判断是把本地推理当成「可选加速」，主链路仍然全走内网服务。联调时暴露两个问题：车间断网功能全废；采购岗位大量简单字段抽取也要排队等 GPU 配额。
修正后的原则是先划数据边界再定分工：哪类数据允许出端，决定了本地模型的下限。2026 年 9 月 22 日 Hugging Face 宣布 transformers 可直接加载 Hub 上的量化 checkpoint，复用 ggml 的 Metal 内核，在 Apple Silicon 上实测吞吐量接近 llama.cpp（Hugging Face 官方博客），而 llama.cpp 正是 Ollama、LM Studio、Jan 这些本地工具背后的推理引擎。桌面端能跑起可用的本地模型，是这两年才成立的前提。
上线后统计，采购岗位 68% 的请求是字段抽取，3B 级量化模型够用；剩下 32% 的合同条款比对仍必须回内网。这个比例写进方案文档后，验收时客户不会因为本地模型偶发答错而质疑整套架构。端云两端怎么切、切在哪一层，我们单独写过一篇 企业 AI 桌面应用案例分析，本文不再展开，只补一句踩坑记录：模型包 4.7GB，第一版让客户端启动时下载，车间 40 台机器同时拉取把内网带宽占满，产线报工系统卡了 20 分钟。后来改成随安装包分发加版本增量更新。
第一次提测时，我们让客户端直接用当前登录员工的系统账号读写共享盘。安全评审被打回，理由是模型可能被提示注入诱导去读不该读的目录，而桌面客户端握有完整的本地文件权限，风险面比浏览器大得多。
重做后的权限模型分三层：
这一轮多花了 9 个工作日，但把验收从「安全部门有条件通过」变成了「无遗留项通过」。如果重做一次，我会在需求阶段就把权限模型画出来，而不是等提测。
质检批量任务会连续触发 200 次以上工具调用。第一版把这些调用放在主进程同步执行，界面卡死 12 秒，操作员以为程序崩了直接强杀。这是桌面端特有的问题：网页刷新一下就能恢复，桌面端用户会拔电源。
参考大小模型分工的思路——例如 NVIDIA 的 Nemotron 3.5 Lightning 用 30B 总参数、约 3B 激活，专门承接工具调用与编码这类高频、边界清晰的执行步骤，把复杂推理留给 550B 总参数、55B 激活的大模型（OpenRouter 解读）——我们把客户端请求也拆成两档：高频结构化调用走本地小模型加异步任务队列，复杂推理走网关大模型，中间用任务 ID 串起来，界面只订阅进度。超时与重试的副作用处理我们另外整理过一份清单（AI Agent 落地先过这关），这里只强调一点：异步化以后必须给每个任务加幂等键，否则重试会把同一张质检单写两遍。
改造后单台设备峰值工具调用从同步阻塞变成并发 8 路，界面主线程最长阻塞降到 120ms 以内。
12 秒和 120ms 是两个世界，但「响应更快」这种验收条款在两个世界之间什么都说明不了。我们后来把所有体验类指标都换成了可观测量：主线程最长阻塞、首次安装耗时、单次字段抽取 P95。客户的安全部门也接受同一套逻辑——权限模型不给「已加固」这种描述，给三层的具体边界。
以下为该项目脱敏后的实测口径，采样自 3 个岗位共 96 台设备。
| 指标 | 改造前 | 改造后 | 说明 |
|---|---|---|---|
| 断网可用性 | 不可用 | 可完成字段抽取与本地检索 | 本地小模型 + 本地索引 |
| 字段抽取 P95 | 4.1 秒 | 0.9 秒 | 采购岗位 1200 次样本 |
| 推理网关峰值 QPS | 38 | 12 | 68% 请求下沉到本地 |
| 峰值工具调用并发 | 1（同步阻塞） | 8（异步队列） | 主线程阻塞 12 秒降至 120ms |
| 首次安装耗时 | 24 分钟 | 9 分钟 | 模型随包分发，车间 40 台设备 |
顺带一个参考值：AI 提速之后瓶颈往往从写代码转到验证环节，Linear 工程团队把 PR 等待时间从 6 分钟以上压到 5 分钟出头、单测 runner 时间减半（Linear 工程实践）。桌面端项目同理，真正的瓶颈常常在安装、启动、权限确认这些「非 AI」步骤上。
不一定，但只要有断网可用或数据不出端的硬约束，就必须至少支持一档本地能力。实践里更常见的是混合架构：本地承接高频低难度请求，复杂推理回内网网关。全本地或全云端都会在某一类场景上卡住。
看审计要求。制造业客户我们做到进程隔离加数据域切分加出网白名单三层；如果客户有等保或行业合规要求，还要补本地审计日志留存与导出权限分级。
按任务类型判断，不按模型榜单判断。字段抽取、意图分类、固定格式改写这类边界清晰的任务，3B 级量化模型在 2026 年的水平已经可用；涉及多步推理、跨文档比对的场景仍应回大模型。一个简单的判断标准是：这个任务有没有明确的输出格式。
三岗位、含本地推理的客户端，我们实际投入 11 周、4 人并行。如果需求阶段就把权限模型和数据域定下来，可以压到 9 周左右；把安全评审放到提测之后，返工本身就要 2 周。
如果你正在评估桌面端 AI 助手的可行性，可以先看我们已交付的 同类项目记录，也可以把岗位清单、数据边界和断网要求直接发给工程师做一版架构判断（联系我们）。