24张工单压到17秒，他把审批权留给了自己

周日晚上11点52分，笔记本已经合上，手机亮了。第一张工单：早上刚开SSO，整个团队被锁在门外，两小时后要上线。紧接着第二张：生产部署失败，退出码137，客户打不开新版本。第三张：数据库连接池耗尽，线上服务间歇性返回500。第四张：发票上多了一行重复条目，财务在付款前要个解释。

队列里一共24张工单。四张在烧，剩下的都是"API密钥怎么轮换""账单联系人去哪改"。做支持的人大概都对自己说过同一句话：Bas do minute ka kaam hai——两分钟的事。它从来不是两分钟。读完24张、按截止时间排序、给每张找到对应的处置手册、打上紧急标签、再认真写两条首轮回复，这是一小时的活，而且其中大部分不需要人来做。真正需要人的只有最后一步：决定到底发什么出去。

于是他做了VOX：把队列交给它，批准它的计划，回来只做两个决定。Kaam VOX karega. Faisla aap——活VOX干，决定你来做。

没人写进手册里的那些坑

• 紧急工单被埋了。"被锁在门外、两小时后上线"这条，夹在一个分页问题和一个发票PDF请求中间，响应截止时间不会替你排序。
• 上下文在别处。退出码137的修法在手册里、在文档里、在上个月的讨论串里，找它的时间比写回复还长。
• 首轮草稿是最让人发怵的部分：要礼貌、要具体、要正确，还不能承诺一个没人批准过的退款。
• 把Agent丢下不管让人不放心。服务器中途重启，回复会不会发两遍？会不会重复扣费？大多数演示从不关服务器。
• "合法JSON"不等于"做对了"。模型可以返回一个格式完美的计划，然后选错动作。

这些难点不在代码，在琐碎，也在没人愿意把最关键的那一步交给一个机器人。

计划先摆出来，人才点头

一条指令就够：分诊所有支持工单，研究修复方案，标记紧急项，起草两条回复，发送前问我。VOX把它拆成一个有边界的计划——检查队列、带证据地排优先级、找处置指引、更新内部标签、准备回复草稿、准备简报。每一步都标明它只是读取、写内部标签，还是需要你批准。计划不批准，什么都不跑。

准备工作由它做完：按响应截止时间和报告的影响给24张工单排序，拉取指引，保存7个内部标签，起草2条回复。在MacBook Air M4上本地跑，耗时17.19秒（10次运行的中位数）。

然后是两个决定：一条批准，一条驳回。每条草稿都在等这个动作，服务器会校验每条回复的归属、状态和有效期，并拒绝重复决定。人的全部工作就是：批准一次计划，做两个回复决定。简报会统计每一处保存下来的变更，并列出还有什么在等你。证据→导出JSON，能看到每个已保存动作和服务商回执。

他还做了一次关服务器测试：两条回复都还在等待时，把托管服务器关掉。重新起来后，VOX接着同一次执行往下走，两条回复仍在等待，没有任何已完成的请求被跑第二遍。这是他敢把活丢下走开的底气。

模型可以提议，但不能给权限

工单是私密的，里面有客户姓名、故障和发票。本地模式下，Gemma 3 4B通过Ollama处理意图、规划和回复起草，SLA优先级由确定性规则设定，服务端那套审批校验照旧生效。云集成会留下明确的"本地模式已跳过"回执，本地请求失败时，VOX不会悄悄切到云端推理，工单留在本机。

开放权重让他能把模型捏成只干一件窄活。他用Tinker在53条合成样本上训练了一个rank-8的Qwen3-8B LoRA，用于托管模式的意图抽取：准确率上去了，token降下来了，代价是更慢，这是下一步要调的。闭源API做不到这两件事——离线跑，或者为一种指令格式重新训练。

信任不依赖模型完美。模型可以提议一条回复，但它没有权限把它发出去。权限在执行器里，不在提示词里。

实测里最扎心的一条：Gemma返回的JSON在30/30个规划用例里都合法，但动作完全符合要求的只有11/30。改了一次提示词后到19/30。这就是计划为什么永远摆在明面上等人批准。

还有几个跟他对着干的问题：服务器可能死在最糟的时刻——服务商已经干完活，结果还没存下来。所以每次调用服务商之前先写一条预留记录，已完成的请求复用保存的结果，状态不确定的直接停下找人，而不是冒着重复扣费的风险重放。轮询曾经自己吃掉自己，每次轮询取消上一次，慢服务器能让界面一直转圈，现在改成等每次响应落定，即使每个响应都延迟2.1秒，界面也能加载出来。证据导出也撒过谎，两条回复都决定完了还说在等待，现在改为从已保存的工作重建计数。

部署版本2202631通过了68项测试、类型检查和生产构建。10月21日的托管运行，从一条录制的语音指令走到24次分诊、7个标签、2条草稿、1次模拟发送和1次驳回，跨九个服务商拿到16条成功回执。10月23日又在桌面和390px手机布局上重跑了一遍完整流程，结束时零待审批，刷新后依然存活。

边界也说清楚了：24张工单和身份全是虚构的，发送是模拟的，VOX还没接真实收件箱。下一步是一个只读的帮助台连接器，让它能读真实队列但改不了；再往后是一个有真实支持团队参与的小规模试点；以及一个更快的适配器，保住16/16的准确率又不带额外延迟。

每个支持队列迟早都会把你叫醒。VOX只保证一件事：等你的只剩下那个决定。