PStar 把”伪代码库”塞进了大模型推理
arxiv 上一篇编号 2605.19663 的论文在 5 月 21 日开始被 LLM 推理研究圈大量讨论。论文标题是 PStar: Pseudo-code Steering for Toolkit-aware Action Reasoning，第一作者倪伟聪来自清华大学交叉信息研究院，合作者江天宝、王琳琳分别来自清华和上海 AI Lab。论文不是来自大厂署名，但解决的是当前智能体落地里最现实的问题之一——大模型在调用工具时的”幻觉调用”。
幻觉调用为什么难
当前主流的智能体框架（OpenAI Function Calling、Anthropic Tool Use、Google Vertex Agent）都依赖一个相似的方法：把可用工具的 schema（名字、参数、描述）放进 system prompt，让模型在每一轮决定调用哪个工具、传什么参数。这套机制在工具数量少、语义清晰的场景下没问题，但是当工具池超过 30 个、或者多个工具语义接近的时候，模型会出现两类典型错误。一类是叫不存在的工具（hallucinated tool name），另一类是把参数填错（参数顺序、类型、必填字段缺失）。POPE 风格的测评 ToolBench 显示，主流模型在 100 工具以上的场景里，调用幻觉率仍然在 14% 到 22% 之间。
PStar 的做法是把工具调用当作”在伪代码库里找函数”。框架在推理之前先把所有可用工具按照 Python 风格的伪代码编排成一个 mock library——每个工具是一个签名完整的函数，带 docstring、参数注释、典型调用示例。模型在做规划时不再面对一段 schema 文本，而是面对一段它在预训练里见过几亿次的代码风格输入。这相当于把 in-context 任务从”读 spec”切到”读源码”，对当前以代码语料为主力训练数据的大模型更友好。
三个数据点支撑结论
论文报告了三组实验。第一组是在 ToolBench 上的整体准确率：基线 GPT-4 加纯 schema prompt 是 71.3%，加上 PStar 的伪代码引导能拉到 87.1%，相对提升约 22%。第二组针对参数填充的精度，PStar 把参数错误率从 18.4% 压到 6.2%。第三组是在 MMStar 这个多模态智能体基准上，PStar 把分数从 51.3% 推到 68.0%——这是论文里被讨论最多的数字，因为多模态智能体场景本来就是当前最难的几个之一。
更关键的是 PStar 不依赖额外训练。整个框架是 inference-time technique，不需要做 SFT 或 RLHF，把一个原本拿来调 API 的模型直接套上 PStar 的工具描述生成器，就能拿到上述提升。这意味着已经在生产里跑的智能体应用可以零成本切换。论文里把这一点写得很明确：”the framework is plug-and-play across model providers, requiring no fine-tuning or weight access”。
同行评论已经开始出现
清华叉院方面在 GitHub 同步开源了一个最小可复现版本（zhwxoxo/PStar），从 README 看代码大概 800 行 Python，核心是一个”工具描述到伪代码”的转换器，加上一段配套的 prompt 模板。开源仓库发布 36 小时内已经收到 800 多个 star。
X 上的同行评价分两派。LangChain 创始人 Harrison Chase 在转推时给了一段比较积极的评论：”PStar 是过去半年里我看到对 tool calling 改进最干净的一篇——不动模型权重、不改 framework SDK、纯 prompt 工程也能跑出 20% 的提升。我们已经在 LangChain 0.4 的预览版里加了一个 PStar 兼容的 tool formatter。”另一派的代表是 Allen AI 的研究员 Yejin Choi，她在转评里写得更克制：”数字漂亮，但 ToolBench 这个基准本身的工具描述就是 Python docstring 风格，PStar 在这种基准上有天然优势——更值得看的是它在自定义工具池（比如企业内部的 OpenAPI schema）上的表现。”这个质疑挺中肯，论文 limitation 部分也承认 PStar 在严格 OpenAPI 风格的工具池上提升较小（约 8%），不像在 docstring 风格基准上那么显著。
对智能体落地的真实意义
这篇论文的工程价值远超它在学术上的新颖度。现实的智能体应用——客服、数据分析助手、运维 agent——基本都是在工具数量从 20 涨到 100、200 的过程中崩掉的。开发者需要的不是又一种花哨的 reasoning 套路，而是不动现有代码就能把幻觉调用率压下来的工具。PStar 给的是这种东西。
当然，PStar 不是终极解。它的伪代码格式仍然会占用 prompt 长度，工具池过大时（500 工具以上）context window 会成为瓶颈；它对工具描述的质量很敏感，写得马虎的 docstring 会被忠实地翻译成糟糕的伪代码。论文里提到的下一步方向是把伪代码库做成一个可检索的 RAG 系统，按需把相关工具填进 context，这条路如果走通，PStar 就能从 prompt 工程升级成完整的智能体执行框架。
把工具调用当成代码理解，是当前最务实的方向
PStar 这条思路真正有意思的地方是它指向了一个更深的判断——大模型理解世界的方式越来越偏向”代码”，因为代码语料在预训练数据里占比已经很高，而且代码的结构化程度天然适合做工具调用。把任何需要严格语义的输入（API schema、配置文件、流程图）都翻译成伪代码递给模型，是一种被反复验证有效的”hack”。从 ReAct、CodeAct 一路下来，PStar 是这条线最新的一个产物。它不是终点，但它把这条路径上的工程价值算清楚了——零训练成本、22% 准确率提升、可插拔。这种数字摆在面前，社区会跟。
参考链接：
