看下这个https://x.com/cerebras/status/2103506859709858175

Joye，看完了。最值得看的不是“快了 20 倍”，而是他们把 Agent 每次临场摸索的工作，提前变成了可复用的流程。 先说一个容易被标题误导的地方。 它不是把同一个 Grok Bot 原地加速了，而是另搭了一套助手：文中用的是 Qwen 3.8 27B，在 Cerebras 上推理，Pi 做 Agent harness，再加针对订餐任务整理的 Skill。 同一个订餐请求，Grok Bot 的记录是 7 分 40 秒，他们自己的助手是 22 秒。所以这是不同系统的端到端对比，不是单独证明 Cerebras 推理快了 20 倍。 具体做对了三件事。 第一，把独立查询并行化。 查三家餐厅有没有位置，不需要“第一家查完，再查第二家”。可以同时查，拿齐结果再决定订哪家。 但真正提交预订必须依赖查询结果，不能一起乱跑。这里的关键不是多开几个 Agent，而是识别哪些步骤互不依赖、哪些必须按顺序执行。 第二，减少每轮“看结果—想下一步—调用工具”的等待。 一次任务可能要反复回到模型几十次，每次推理省一点，累积就很可观。Cerebras 的高速推理主要作用在这里，但它不能让网站加载、短信验证也跟着瞬间完成。 第三，也是我觉得最重要的：提前保存网站操作经验。 普通助手第一次去订餐，可能需要不断试探：入口在哪、怎么查时段、下一步点什么。作者提前把摸索出的流程写进 Skill，正式执行时直接按已知路线走。文中称工具调用减少了 80% 以上。 这不是单纯“让模型想得更快”，而是让它少做重复探索。 不过，要把实验边界看清楚。 22 秒是两次成功尝试的中位数，样本很小，不能代表各种日常任务的稳定表现。 网站流程是在计时前摸索好的，这部分成本被前移了，并没有消失。对反复使用的网站，这笔投入可能很划算；对一次性陌生任务，就未必有同样收益。 他们还同时换了模型、harness 和执行路径，所以不能把全部提速归给某一个因素。文中也明确承认这一点。 另外，能复用的是“怎么查、怎么订”，不是“现在还有没有位置”。库存、价格、是否要求银行卡仍然要实时检查；网站改版后，Skill 也需要复测和维护。 我的判断：这是一个很具体的案例，说明 Agent 的速度不只取决于每秒生成多少 token，更取决于有没有重复探索、有没有不必要的串行等待。 它也接近“把执行经验沉淀下来”的方向，但文中是作者提前整理流程喂给 Agent，不足以证明已经做成了自动从 trace 学习、更新 Skill、验证效果的自改进闭环。