上个月我花了整整一个周末，反复遭遇同一种挫败。下载一个崭新的开源权重模型，看它在MMLU和HumanEval上碾压对手，然后把它丢给一个多步骤的shell任务——"找出/var/log下最大的日志文件，grep搜索OOM错误，写一份摘要"——它就开始表演：自信满满地编造不存在的命令参数，两步之前运行的东西转眼就忘，或者陷入无限循环，ls敲个不停。
如果你试过把本地模型当成终端代理来用，你懂这种感觉。排行榜上的分数是一回事，实际工作流是另一回事。随着Terminal-Bench 2.0这类代理基准测试越来越受关注（据传Qwen3.6系列的新MoE模型也已登上公开榜单），理解这个鸿沟为何存在、你能做什么，变得值得投入时间。
根源在于：静态基准不是代理基准。你在Hugging Face排行榜上看到的多数分数，衡量的是单轮推理。模型拿到提示，生成答案，结束。这几乎无法告诉你，同一个模型在以下场景会如何表现：决定调用哪个工具、解析真实shell输出的杂乱stdout、在15轮以上对话中保持状态记忆、命令失败时如何恢复。
Terminal-Bench这类基准试图填补的正是这个缺口。它们把模型放进真实的沙盒，分配真实任务，评分标准只有一个：任务是否完成——而非中间推理看起来是否合理。
问题在于，除非你亲自跑一遍代理评估，否则你无法确定自己押注的模型是否真的适用于你的场景。
我摸索出一套本地代理评估框架，用于在选定模型前做 sanity check。核心思路：模拟生产代理会运行的同样循环，但针对你控制的固定任务集。
第一步，最小化的工具调用循环。我用transformers库，因为它开箱即支持多数开源权重模型。
代码片段展示了基础设置：加载模型、定义run_shell函数执行命令并返回stdout与stderr。关键提醒：真实评估中务必使用沙盒环境，示例代码仅作演示。
接下来是代理循环本身。我第一次写这个时惊讶地发现：多数失败不在模型内部，而在边界——解析出错、上下文丢失、没有恢复路径。
agent_step函数展示了关键细节：必须应用模型的对话模板（chat template），这对指令模型至关重要。模板处理后的提示送入模型生成，输出解析为工具调用或最终答案，执行结果回写入历史，循环继续。
实际运行中，我观察到的失败模式高度一致。模型会在第7-12轮左右开始"幻觉"文件路径，把之前成功访问过的目录记错；遇到非零退出码时，有的模型会优雅重试，有的则直接崩溃；长输出截断是重灾区，默认的2048 token输出限制在真实日志分析中经常不够用。
这些细节不会出现在任何公开排行榜上。它们只在真实的、多轮的、有状态的任务中暴露。
我的建议：别只看MMLU分数。花两小时搭一个最小代理循环，跑5个你实际会用的任务。模型选错代价很高，但评估成本很低。
热门跟贴