DecisionAct v0.1.2：不用LLM，用决策模型构建多工具调用Agent

一个不依赖LLM的Agent框架

大多数Agent框架把大语言模型当作推理核心，但开源项目DecisionAct选择了另一条路：用决策模型（如JEV和Cloudflare Clef）来驱动任务型Agent。开发者只需定义Python工具、输入参数、意图和回复模板，决策模型负责选择动作与输入，函数负责执行。据Reddit帖子介绍，v0.1.2版本重点改进了多工具调用的可靠性与输入解析机制。

这种设计的直接好处是降低对LLM的依赖——推理环节交给更轻量的决策模型，工具执行则完全由开发者可控的Python函数完成。对于流程明确、输入结构化的任务场景，这比让LLM自由发挥更容易调试和审计。

决策模型（Decision Model） 是这里的核心概念，它区别于生成式大语言模型：不产生自由文本，而是在给定的候选动作/参数集合中做分类式选择。JEV 和 Cloudflare Clef 都属于此类——它们接收结构化上下文，输出一个离散决策（选哪个工具、填什么参数），因此推理开销小、输出可约束、行为更可预测。这也解释了为何该框架适合流程明确的任务：决策空间被开发者预先限定，模型只需在有限选项中判别，而非开放式生成。

意图（Intent） 在对话式Agent中通常指对用户请求的语义归类，例如“查询订单”或“计算数值”。框架据此决定可调用哪些工具及参数模板。把意图识别与工具执行解耦，使每个请求先落到一个明确的处理分支，再由决策模型在该分支内完成多步工具编排——这也是它每请求仅支持单一意图的原因。

v0.1.2 改了什么

重复调用不再复用旧参数

此前的版本在连续调用同一工具时，可能沿用上一次的参数。新版本改为每次重复调用都重新解析输入，避免“拿着旧值算新账”的错误。

工具结果可作为后续输入

更实用的变化是支持链式执行。帖子给出的例子是“先算4加5，再把结果乘以2”——前一个工具的返回值能够成为后一个工具的输入参数。这使多步任务可以在一次请求内完成，而不必让用户分两次提问。

执行上下文更清晰

新版本把指令、消息和已完成的工具调用在上下文中分离，减少模型混淆不同来源信息的可能。这一点对多轮、多工具交织的流程尤为关键。

输入不确定时先复核再追问

当输入选择存在不确定时，框架会给模型一次复核机会；如果仍然无法确定，就自动向用户提问澄清。这相当于在自动执行和人工介入之间加了一道缓冲，减少错误执行的代价。

更长的工具序列与人工审批后的续跑

框架允许更长的工具调用序列，但设有硬性上限，同时改进了人工审批之后的流程继续能力。对于需要中途确认的敏感操作，这一机制比较实用。

输入解析的三种方式

根据帖子说明，输入解析支持三类候选：正则表达式候选、预定义分类选项，以及基于参数描述选择的文本候选。模型能否选对，很大程度上取决于参数描述是否清晰、上下文设置是否合适。作者也坦承，框架目前每个请求只支持一个意图配合多次工具调用，且模型的选择仍可能出错——这是使用方需要预留兜底逻辑的地方。

候选式输入解析与LLM的自由生成有本质差异：正则表达式候选适合格式严格的值（订单号、日期）；预定义分类选项适合枚举型参数（如“加急/普通”）；基于参数描述的文本候选则由模型在描述语义上做匹配。三者的共同点是先把可能的取值空间收窄，再让决策模型在其中挑选，因此参数描述的清晰度直接决定准确率。实践中应尽量把描述写成可区分的判别特征，并为每类候选设置失败回退，例如解析失败时触发澄清提问而非强行猜测。

上手方式与适用边界

安装命令为 pip install -U decisionact，使用前需要准备所选决策模型提供商的凭证。官方文档提供了快速入门，以及计算器、订单支持和航班柜台三个示例。

需要注意的是，DecisionAct的定位是任务聚焦型Agent，而非通用对话助手。当任务边界清晰、工具接口规范时，决策模型驱动的方案在可靠性和可解释性上更有优势；反之，开放式任务仍可能需要LLM参与。作者在帖子末尾也以玩笑口吻强调“没有LLM受到伤害”，点明了项目的差异化方向。

对于想尝试非LLM Agent路线的开发者，这个项目提供了一个轻量、可读性强的起点，作者也公开欢迎贡献与反馈。