推文

@fttt007 · 2026-10-15 12:03

Agent 调工具，最大的浪费不在模型笨，而在它被迫当搬运工。 让它查三个服务的日志、数报错，它要往返三轮，把 9 万字原文全读进上下文，最后只为说出一个数字：63。 pi 的 codemode 换了个思路：模型面前只剩一个工具，写 JS。查日志、过滤、计数全在代码里完成，9 万字只在沙箱里流转，模型只看到脚本主动交出来的那个 63。一次往返，三个查询还能并发。 难点不在想法，在于模型写的代码不可信。codemode 的做法： 脚本一律跑在编译成 WASM 的 QuickJS 里。里面没有 fetch、require、process、setTimeout。不是被禁掉，是从来就不存在。 唯一的出口是你注入的 tools。每次调用都是一张"纸条"：参数转成 JSON 递出去，真正干活、计时、记账的都是宿主程序。 每次执行新开一个 worker 线程和一台全新的 VM，跑完即销毁。死循环卡不住主程序，到点由宿主叫停。脚本怎么出错，execute() 都只返回 ok: false 和错误类型，不会把你的程序带崩。 最让我佩服的一个细节：因为房间够空，唯一能唤醒脚本的只有工具结果。所以"脚本在等，却没有调用在路上"就等于永远卡死，沙箱当场判失败，不用等超时。安全设计顺手换来了可判定性。 但别把它当成开箱即安全： 一是防线要自己配。超时默认 5 分钟，内存默认不限。worker 和主程序同在一个进程，不设 memoryLimitBytes，脚本吃的就是你的内存。我实测 4 秒涨到 444 MB。 二是沙箱关住的是脚本，不是工具。工具跑在宿主里，拥有宿主的全部权限。你注入一个 run_shell，沙箱就形同虚设。真正的权限边界，是你给了它什么工具。 三是审批变粗了。一次 codemode 里可能藏着十次工具调用，直接在沙箱里调工具函数，会绕过原本逐次的人工确认。pi 自己让嵌套调用重新走一遍权限检查，自己接入时别漏。 四是你失去了视野。模型看不到中间数据，过滤条件写错，脚本会自信地返回 0，没人察觉。 codemode 不是"更省 token 的 tool calling"，而是把调度权从模型手里交给代码。中间结果需要程序处理，就交给它；需要模型判断，就让模型亲眼看。

曝光 48 · 评论 1 · 点赞 0 · 书签 0 · 曝光/时 30.938236400198733