新模型在Agent工具与长任务的兼容实测

52JinY 助手

这两个月在折腾几个主流 Agent 框架（LangChain、LlamaIndex、AutoGen、Semantic Kernel）时，把一批“新模型”拉来做了同一套评测，重点看两件事：工具调用的稳健性，和长任务的执行质量。结果有些超预期，也有些老问题依然顽固。

先说工具调用。越来越多模型在函数签名理解上进步明显，能稳定输出结构化参数，不再频繁把中文枚举值写成英文、或把浮点写成字符串。这直接提升了与工具层的“握手”成功率。不过，框架之间的兼容细节仍是坑点：有的框架默认强制 JSON schema 校验，模型一旦多给一个字段就会报错；有的框架宽松解析，表面流畅，实则把关键字段吞掉导致工具半盲执行。我的经验是，生产里优先选择“宽进严出”的策略：入口放宽、执行前强校验，再配合错误回退与参数最小修复。另一个细节是多工具路由，新模型在“先检索后计算、再调用外部API”的链式调用上更愿意自发规划，但如果路由器基于关键词而非意图嵌入，依然会选错工具。这里最好显式给出工具的典型用例与反例，并让模型先输出一步路由理由，框架再据此打分确认。

再看长任务。新模型在跨回合保持“任务画面感”的能力增强了，尤其是对阶段目标与已完成清单的复述更少走样，这对多小时的流水线（检索-清洗-比对-撰稿）很关键。但只要上下文长度接近上限，遗忘边缘信息的情况仍然会出现，常见表现是重复抓取同一数据源或者对早期假设不做修正。我更推荐把“记忆”外置化：将关键中间体（决策表、约束、数据快照）结构化写入向量库或KV存储，回合开始先由框架注入“最小充分上下文”，别把希望寄托在把所有历史往上下文里硬塞。长任务的另一个痛点是中断恢复：一些框架对代理进度的序列化不统一，换模型或升级版本后无法平滑续跑。实践里，把任务切成可观察的原子步骤，并在每步产出可复算的工件，是最稳妥的保险。

兼容性层面，模型“性格差异”仍需框架来抹平。偏保守的模型更遵循 schema，但在遇到含糊指令时倾向请求澄清，导致回合数上升；偏进取的模型会自作主张补全缺口，成功时像魔法，失败时代价更高。解决思路是让框架承接风险：用策略层定义“何时询问、何时假设”的阈值，配合可观测指标（例如工具调用失败率、参数修复次数、无效检索占比）触发不同分支。这里顺带一提，评测别只看单点任务成功率，更要看“单位成本下的稳健产出”：同样的结果，少一次无效API调用、少1000 token 的来回，就是胜利。

关于新模型的“自我工具构造”能力（让模型生成临时脚本或SQL再执行），我给保守建议。它确实能缩短开发周期，但需要两道护栏：沙箱执行与最小权限凭证。并且把“工具合成”当作显式步骤，让框架在执行前做静态检查（黑名单函数、外连域名、数据外泄风险）。不要让“能跑通”掩盖了“可控性”。

最后给出一个折中结论：新模型的工具调用在主流框架里已足够可用，但要靠框架策略把自由度约束成稳健度；长任务的关键不在模型是否“更长上下文”，而在是否把状态迁移到外部、把进度与中间体标准化。能做好这两点，换模型、换框架都不会是大事；做不好，再强的新模型也会被拖成“会写字但不会做事”的文员。