AI Agent 调用模型太贵怎么办？Recursant 用路由把隐私、成本和稳定性放在一起
AI 编程 Agent 的成本，往往不是一次回答决定的。它会读取文件、运行测试、分析错误、修改代码，再重复几轮；真正消耗预算的是这些连续的中间步骤。把所有请求都交给最强模型当然简单，却会让大量“读日志”“列出文件”“解释报错”等普通工作也按高价计费。
Recursant 是一个放在 Agent 与模型服务之间的本地模型路由器。它兼容 OpenAI API，Agent 不需要插件，也不需要改代码，只要把原来的模型地址改成 Recursant 的地址。它会按请求所处的步骤、隐私内容和模型状态，在主模型、经济模型、强模型与本地模型之间选择。
它解决的不是“换一个便宜模型”
简单的模型降级有一个隐患：Agent 的上下文和任务状态可能在切换时变得不一致。Recursant 的设计重点是逐请求决策，而不是整段会话固定使用某个模型。项目 README 描述了四层判断顺序：
- 先检查隐私。 如果请求含有个人数据，或者内容无法被安全检查，就送往私有模型；后续的成本决策不能覆盖这条规则。
- 再判断能否切换。 如果此时切换可能扰乱 Agent，或者损失重复文本带来的缓存收益，就继续使用当前模型。
- 观察上一步结果。 上一步成功后，下一步通常属于常规工作；连续失败时则提升到更强的模型，辅助 Agent 从经济模型开始。
- 最后比较允许的模型。 在安全边界内，再考虑价格、负载和可用性。
这种顺序很适合代码 Agent：把“隐私”作为硬约束，把“成本”放到约束之后，而不是为了省钱无条件降级。需要注意的是，项目当前仍处于早期阶段，仓库说明已实际测试 OpenRouter 和自有服务器上的模型，其他服务虽然列在配置中，但未必都经过真实环境验证。
安装：先让路由器跑起来
Recursant 目前以 Linux 为主要运行环境，macOS 支持仍在推进。官方安装脚本会下载源码、安装构建依赖、编译程序，并写入初始配置；它不会自动启动服务，也不会把内容发送到别处。
curl -fsSL https://raw.githubusercontent.com/ajensenwaud/recursant/main/install.sh | bash
安装后，程序位于 ~/.local/bin/recursant，配置文件是 ~/.config/recursant/config.json，密钥保存在权限收紧的 ~/.config/recursant/recursant.env。如果终端找不到命令，可以先补充路径：
export PATH="$HOME/.local/bin:$PATH" recursant check
check 是一个值得保留在日常流程中的命令。它会在重启服务前检查配置，避免把一个错误的模型地址直接带进 Agent 工作流。
配置公有模型与私有模型
首次配置 OpenRouter 密钥时，不要把密钥直接写进 JSON 文件：
recursant configure --set-key OPENROUTER_API_KEY
如果私有模型运行在局域网中的 GPU 服务器上，可以把它登记为私有提供商：
recursant configure --add-provider gpu \ --url http://gpu-box:8000/v1 \ --trust private \ --private-default gpu:my-model-name
项目的初始配置包含 baseline、economy、strong 和 local 等角色。实际使用时，建议先用自己熟悉的模型替换示例中的提供商，再逐步加入隐私规则。例如，业务编号可以通过正则模式标记为私有数据：
recursant configure --add-pattern 'CUST-[0-9]{6}'
隐私检测目前是确定性的正则匹配，覆盖邮箱、电话、银行卡号等模式，也支持用户添加规则。它不是语义级的敏感信息识别系统，因此不能把“命中规则”理解成完整的 DLP 方案；在生产环境中仍应配合日志策略和数据分级。
接入 Agent：它看起来仍像 OpenAI API
启动用户级服务后，默认监听地址是 http://127.0.0.1:8080/v1：
recursant install --user recursant start recursant status
然后在 Agent 中填写三项：Base URL 使用上述地址，API Key 使用 recursant.env 中生成的 RECURSANT_API_KEY，模型名填写 auto。以支持自定义 OpenAI 端点的工具为例，通常只需修改这三个字段。
调试时可以直接观察响应头，而不必猜测请求去了哪里：
source ~/.config/recursant/recursant.env
curl -s http://127.0.0.1:8080/v1/chat/completions \
-H "Authorization: Bearer ${RECURSANT_API_KEY}" \
-H "Content-Type: application/json" \
-d '{"model":"auto","messages":[{"role":"user","content":"Say hello"}]}' \
-D - -o /dev/null | grep -i '^x-recursant'
X-Recursant-Model 和 X-Recursant-Decision 可以帮助排查路由是否符合预期。先在低风险任务上观察几轮，再把它接入会修改代码或访问真实数据的 Agent，是更稳妥的迁移顺序。
适合什么场景？不适合什么场景？
它适合连续调用很多次模型的开发 Agent、同时拥有本地模型和云端模型的个人工作站，以及希望把敏感内容留在内网的团队。它的价值不只是宣称节省成本，而是把每次选择记录成可解释的决策。
它暂时不适合追求“一条命令即可在所有平台运行”的用户：Windows 支持并不成熟，项目也仍在快速迭代。README 提到的“降低 30% 以上成本”是项目方的目标性宣传，实际比例取决于任务分布、模型价格、缓存和本地硬件，部署前应自行记录一段基线数据。
一个实用的评估方法是：先固定同一个 Agent 任务，记录总请求数、每个模型处理的请求数、失败重试次数和最终费用；接入 Recursant 后再次运行同样任务，对比路由决策，而不是只看一次成功请求。若私有模型过慢，隐私规则也可能增加端到端延迟，此时要把延迟、成本和数据边界一起衡量。
结语
Recursant 的思路很直接：模型路由不应该只按价格排序，而要先尊重隐私，再保护 Agent 的连续性，最后才寻找更便宜的答案。对于已经在使用 Claude Code、Hermes、pi 或其他 OpenAI 兼容 Agent 的开发者，它提供了一个低侵入的实验入口。先用 check、status 和响应头建立可观察性，再逐步放大使用范围，通常比一开始就把所有项目接入更可靠。