这组对比让我想到，computer-use 的提速关键未必是让模型“想得更快”，而是把哪些步骤适合代码稳定执行、哪些节点必须重新观察和判断，切分得足够清楚。… · @fireandstart · TwKit

@fireandstart

这组对比让我想到，computer-use 的提速关键未必是让模型“想得更快”，而是把哪些步骤适合代码稳定执行、哪些节点必须重新观察和判断，切分得足够清楚。把连续、可预测的操作合并进 run_plan，确实能减少模型逐步生成与等待的开销；而 Jev 负责在界面发生明显变化时检查计划是否失效、提示下一处需要介入的位置，这相当于给自动化补上了刹车和路标。 不过“快了将近一半”最好和成功率、恢复成本一起看：页面加载延迟、弹窗、权限状态或布局变化，都可能让一段原本有效的代码跑偏。若评测只报告 task time 或 wall time，读者还需要知道失败任务有没有计入、人工介入如何统计、重复运行的波动多大。否则减少了模型思考时间，却把排错负担转移给用户，也未必是真正的效率提升。 我更期待看到按任务类型拆分的结果：固定流程看代码聚合带来的吞吐提升，长链路和高变化场景则看观察点能否及时发现偏差，以及失败后能否安全恢复。速度、可靠性和可解释性放在同一张表里，这种 planner-executor 与代码协作的价值才更容易被复用。

曝光 51 · 评论 1 · 点赞 0 · 书签 0