让计算机智能体（Computer Agent）自己操作桌面，最折磨人的从来不是模型不会点按，而是它常常在调用接口时填错字段，或者干脆把整个任务带进死胡同。Perplexity Research 近期发布了一项针对其计算机智能体 Perplexity Computer 的后训练研究，基于开源的 GLM 5.2 基础模型，在约 10 万用户的真实线上分流对照中，把工具调用失败率从 2.24% 压缩到了 1.77%，相对降幅达 21.2%。
但在同一份实测数据里，线上用户的强不满率仅从 2.58% 挪到了 2.54%，在统计学上毫无显著差异。
把工具调用的格式错误砍掉五分之一，用户体验却近乎原地踏步。这一组极具反差的数据，恰恰撕开了当下计算机智能体研发最隐蔽的痛点：修好单步调用的语法错误，远不等于完成了一次真实的端到端交付。
翻找错题本：OPSD 如何让失败产生价值
业界此前训练智能体的主流做法是拒绝采样微调（RFT）：系统生成多条轨迹，挑出最后达成目标的成功样本拿去微调，其余失败记录直接丢进垃圾桶。这种非黑即白的筛选存在两重硬伤。一个任务最终成功，并不代表中间每一步都走得漂亮；智能体在第三步胡乱传参、第五步侥幸自愈的废动作，全量模仿只会把坏习惯固定下来。更可惜的是那些由于单步参数越界而功亏一篑的失败会话，其前半程所有合理的推演全被一笔勾销。
Perplexity 的核心改动，在于把整轨筛选拆解为针对每个对话轮次的单步裁决，分为模仿、纠正与仅作上下文三种处理：
- 模仿（Imitate）.成功会话中毫无瑕疵的步骤，施加标准的交叉熵损失（CE Loss）。
- 纠正（Correct）.任何会话中被标定出错误的单步，配合一段纠错提示（Hint），施加 KL 散度损失。
- 仅作上下文（Keep as context）：剩余步骤保留在上下文窗口中维持因果连贯，但不反传任何梯度。
负责纠错的关键机制被称为提示引导同策略自蒸馏（OPSD）。它没有额外引入昂贵的外部大模型做教师，而是让同一个 GLM 5.2 权重先后运行两次。在教师遍次中，模型能看到一条极短的事后纠正提示，例如某项搜索参数的 schema 只允许传天、周、月，不能填年；而在学生遍次中，模型盲测运行。训练目标是通过前向 KL 散度，让不带提示的学生去逼近带了提示的教师概率分布。
在 985 个留出的工具错误轮次测试中，这套提示机制让原本未微调的基模在带提示推断时，规避原始失败的比例由 75.1% 提升到 93.7%，采纳正确纠正行为的比例从 60.6% 攀升至 82.3%。而在更模糊的用户反馈场景下，明确证据轮次的修复率从 40.0% 升至 75.0%，意图推断轮次修复率由 32.5% 跃升至 80.0%。这证明提示本身的指导价值足够明确，能为蒸馏提供干净的软目标。
裁判溯源与并不严格的消融数据
既然失败样本能当教材，最大的工程挑战就变成了如何找准责任方。智能体执行复杂工作流时，用户发起投诉的那一刻，出问题的往往早就不是眼下这一步。
Perplexity 的多裁判工程统计显示，用户抱怨前紧挨着的最后一个助手轮次，仅有约 50% 的概率是故障源头。多数情况下，病根早在数轮之前就已经埋下。例如用户要求在薪酬管理软件 Paychex 上查询 W-3 表格，模型在三步前擅自推断用户把 W-2 打错了，自作主张调取了错误报表。为此，研发团队必须引入 3 个大语言模型裁判进行独立倒查，要求至少 2 个达成共识才能锁定真正的根因轮次，并根据执行当时的已有视野生成纠错提示，防止模型产生后见之明偏差。
这套后训练链路在离线跑分上交出了漂亮成绩单：工具错误率从原生 GLM 5.2 的 2.79%，经由纯 RFT 压至 1.35%，叠加 OPSD 进一步压到 0.87%。
但这里埋着一处明显的实验软肋：官方在技术报告中承认，这三个离线测试权重并未基于同一批清洗数据进行严格的对照消融，数据混合比例存在变动。而在真实的线上 A/B 测试中，早期版本对比原生 GLM 5.2 时，工具错误率是 2.82% 对 2.94%，统计学检验毫无显著差异；后期虽然实现了 2.24% 到 1.77% 的显著下滑，但对比的两个对象均是训练后的 Checkpoint，官方并未直接拿最终版与原生基模进行线上正面对决。
实验室跑分可以靠特定的参数纠正刷得很好看，但在现实任务里，调用工具不出语法错误，仅仅是万里长征迈出的第一步。
长程任务深水区：修好螺丝钉，救不回烂尾楼
回到最扎眼的落差：为什么工具报错明显减少，用户却依然不买账？
因为用户使用计算机智能体时，感知到的不是你接口传参准不准，而是任务有没有办成。第三方机构 Contracollective 的横向评测展示了当前主流计算机使用智能体的差距：在 OSWorld、WebArena 和真实采购工作流三项基准中，Claude Computer Use 的胜率分别为 48%、61%、74%，OpenAI Operator 分别为 44%、58%、70%，而 Perplexity Computer 仅有 39%、54%、62%。
这种差距在长程任务中会被指数级放大。面向深度操作的 OSWorld 2.0 评测集包含 108 个长程工作流，平均需要约 318 次 工具调用，相比初代约 30 次的规模扩张了十倍。在这个深度的链条里，即使单步工具调用正确率从 97.76% 提升到 98.23%，累积相乘之后的整轨存活概率依然极其脆弱。
更要命的是，智能体基准审计研究表明，有 15.3% 的评测失败判定本身存在评估器误判或任务破损。而在真正致命的逻辑失败中，几乎全部来自模型对宏观步骤的规划缺失和环境状态检验能力的不足，几乎没有多少是因为找不到输入框或填错了参数类型。
社区对 Perplexity Computer 的实际吐槽也印证了这一点：计费积分飞速蒸发、陷入死循环重复点击、甚至屏幕上赫然宣布任务已完成，用户却找不到任何产出文件。这种假性完成，比直接弹出一个接口报错更令人恼火。
- 风险.如果模型后训练只集中于纠正局部的 API 参数格式，而缺乏对长程状态的真实核验机制，智能体就很容易演变成一个格式极度规范、却满嘴跑火车的昂贵玩具。
古人言“扬汤止沸，莫若去薪”。纠正每一次点击与接口传参的格式，做的是扬汤止沸的末节修补；而在动态变化的操作系统里校验每一步的状态转移，才是真正的任务底薪。Perplexity 证明了失败数据不必白白浪费，自蒸馏架构也能有效修剪多余的废动作。但只要智能体依然无法确认自己到底有没有真正改写那张表格、生成那份报表，那 21.2% 的局部胜率提升，就注定换不来用户的一声赞叹。