本站

只输出选项和概率的 AI，怎样调用工具？

2026-09-20 · 模型 · AI · 工具调用

一个模型如果不会生成代码，只返回选项和概率，还能调用工具吗？

Jev 把这个问题摆得很直接。按照 TypeSafe 的说明，它处理结构化判断，不负责生成自由文本或代码。但工具调用未必需要模型现场写出一段程序：模型可以选择已经定义好的动作，由外部程序执行。Jev 的能力说明

真正需要拆开的，是“选下一步做什么”与“把下一步做成”。下面用一个假设的代码审查器，看看两者怎样连接，以及连接之后还缺什么。

审查器收到一份登录功能的修改。我们给它准备四类动作：读取相关文件、运行已有测试、查询执行结果、转交开发者。

模型根据当前材料返回动作编号。程序检查参数与权限，调用对应工具，再把真实结果放回状态，供下一轮判断使用：

当前代码和已有记录
    ↓
模型选择一个已定义动作
    ↓
程序核对权限与参数，执行工具
    ↓
保存结果，更新状态，再决定下一步

这个循环里，函数名不必由模型创造。参数也可以来自已有信息：测试名称取自可信列表，当前提交号由仓库提供，文件路径由程序枚举。

TypeSafe 的函数调用示例就把函数名称及有限取值的参数转成选择题，再交给分发程序执行。“有限取值”指答案来自预先列出的范围，例如选择日线或小时线；任意字符串、开放式数值等参数，不能因此自动变成同一种选择题。官方函数调用示例

无论返回 JSON、编号还是概率数组，都是在传递一个动作提议。结构合法可以减少解析错误，却不能保证选对动作，更不能证明工具已经运行。

假设开发者说：“这次已经修好了重复登录失败的问题。”审查器选择运行已有登录测试，工具返回全部通过。此时系统有依据说：这些用例在这个提交上通过了。结论的范围就到这里。

接着，审查器读取测试文件，回答一组事先定义的覆盖问题，其中一项是“有没有覆盖登录状态过期后再次登录”。模型判断没有覆盖，并从动作列表选择“转交开发者补充测试”。开发者核实这个遗漏、编写用例，再运行，结果失败。

这里刻意保留了分工：选择器回答已有问题，开发者写出新的测试。 如果希望系统自行提出未预设的缺陷线索或编写代码，就需要另一个具备生成能力的组件，不能把这一步含糊地算到只输出选项的模型头上。

新测试的失败，会改变先前“可以合并”的判断。这个循环有价值，因为外部执行带回了原来没有的信息。ReAct 研究讨论过通过行动获取外部信息、再调整后续推理的方式；它支持这种流程思路，但不是对这里这个假设审查器的效果验证。ReAct 论文

执行记录也要保留下来：运行了什么、对应哪个提交、退出状态是什么。只存一句模型总结的“测试都过了”，后续就难以分清它在转述哪次结果，也难以复查判断依据。

从现有测试里挑一个，与写出一个新测试，需要的能力不同。后者可能涉及构造输入、理解边界条件、组织断言。没有候选时，选择器无法选出一个未被提供的方案。

可以让生成式模型提出测试候选，让判断组件辅助筛选，再在合适的环境中执行。但筛选仍受候选质量限制：三个测试如果都绕开了出错路径，选出其中最好的，也不能说明问题已经被覆盖。流程应容许“当前候选都不合适”，再交给人或其他组件处理。

Jev 1.13 的限制文档也建议把生成任务交给生成式模型，而不是串联选择题硬凑文本。这是该版本公开说明的能力边界，不应因为系统里最终出现了代码，就把代码生成能力归给每个参与组件。Jev 1.13 限制说明

有限动作空间的价值在于容易检查和管理，代价是灵活性受限。如果任务需要临时写脚本、提出新的调查方向或处理任意路径，这部分成本仍然存在。演示中能顺畅选择几个按钮，不足以说明它已经能独立完成开放式编程任务。

Jev 的文档称，同一次请求中的问题针对同一份状态并行、分别评估。这适合一次检查多个条件，但不意味着每道题都获取了独立的外部证据。并行问题说明

例如，同时问“该运行哪个测试”“测试是否通过”“是否可以合并”，可以一次得到三个数值，但测试仍可能一次都没执行。后两个决定若依赖执行结果，就必须等工具返回后再作判断。并行推断不能替代流程中的因果顺序。

同样，把一个问题换十种说法反复问，可能带来新的分析角度，却不自动构成十份独立证据。回答可能共享同一处遗漏，也可能一起被不完整的输入误导。值得保留的下一轮，应当能说明它在补什么信息，或检验哪个尚未解决的判断。

这也不意味着所有问题都必须运行测试才能回答。代码中明确删掉了一个权限检查，可以通过阅读具体修改指出；类型检查、静态分析和形式化方法，也各有适用范围。关键是结论要与依据匹配：“这里少了一个条件”与“整个系统不会出问题”，所需证据的强度不同。

工具执行失败时也要保留这个区别。数据库没启动、权限不足或输出被截断，可能使原问题暂时无法回答。此时应该记录执行失败或尚未核实，不能让模型用一个确定的语气补上缺失结果。

假设模型选择了“运行测试”，参数却指向生产环境；或者选择“读取文件”，对象超出当前用户权限。函数名称和参数类型都可能合法，动作仍然不该执行。

因此，程序需要依据用户授权、目标对象和运行环境决定是否执行。模型提供提议，不能用自己同一次判断替自己放行。结果来源也要区分：用户粘贴的“全部通过”，与测试环境针对当前提交返回的记录，不能直接当成同一件事。

一些确定性信息更适合直接读取和判断：提交号、退出码、是否超时，都不必让模型猜。模型可以把精力放在语义问题上，例如哪些文件值得调查、这条错误可能与哪处修改有关。

流程还需要一个正常结束的条件。同一项测试在相同版本和环境下已经失败，无变化地重复执行通常不会增加信息。若怀疑偶发故障，重试应有具体理由；否则就根据已有结果修复或转交。已有证据可以复用，版本、环境或问题变了再检查相关部分。

我会把这类选择模型放在边界清楚的位置：用它判断下一步，把开放式创作交给合适的组件，让工具提供执行结果，让程序维护权限与状态。能否组成有用的 Agent，最终取决于这些环节是否接得起来，而不取决于模型能不能把行动理由写成长文。

2026 年 9 月 27 日修订。文中的审查器为说明性设计，不是 Jev 的实测项目。