Which LLM? Deterministic model selection for agents

核心功能

Decision Economic Optimizer（Which‑LLM）是一款面向AI Agent的决策优化技能，核心解决"在给定成本与质量约束下选择最优LLM"的问题。它并非直接调用模型，而是通过API返回确定性的模型推荐及备选方案。

核心用法

1. 免费发现端点：GET /capabilities、/pricing、/status用于服务发现
2. 付费决策端点：POST /decision/optimize提交目标与约束，获取推荐模型
3. 结果反馈端点：POST /decision/outcome上报实际执行结果，赚取未来请求抵扣的信用代币

典型请求结构包含：任务目标（goal）、约束条件（质量下限、成本上限）、工作量预估（token数、请求数）。

支付与信用机制

• HTTP 402 支付流程：API返回402 → 验证支付地址 → 人工审批（默认模式）→ 签名并提交USDC → 携带支付凭证重试请求
• 支持链：Base、Ethereum、Arbitrum、Optimism、Avalanche
• 信用抵扣：通过结果反馈获得X-Credit-Token，降低后续请求成本

显著优点

| 维度 | 优势 |

|------|------|

| 确定性决策 | 基于明确约束输出可审计的模型选择，避免随机性 |

| 多链支付灵活性 | USDC跨链支付，支持主流L2与主网 |

| 经济激励闭环 | 结果反馈赚取信用，形成"使用-反馈-抵扣"的正向循环 |

| 降级预案 | 自动提供fallback_plan应对主模型失效 |

| 透明度 | 支付地址通过多通道验证（well-known端点+ENS），降低单点信任风险 |

潜在局限性与风险

架构局限：

• 不直接执行LLM调用，仅提供决策建议，需额外集成模型调用层
• 依赖外部API可用性，无本地降级能力

关键风险：

• 资金风险：技能需配置钱包私钥或keystore，虽声明"默认人工审批"，但实际执行依赖host层 enforcement，存在未经提示自动签名的可能性
• 验证依赖：支付地址需人工多源验证，但所有通道共享同一运营方控制，非完全独立信任锚
• 无密码学强证明：缺乏链上attestation或独立域名签名的地址声明

适合人群

• 构建多模型Agent平台的开发者，需程序化模型选型
• 成本敏感型AI工作流（如批量文本处理），需严格预算控制
• 追求可审计决策链的企业级应用

常规风险缓解建议

1. 钱包隔离：严格使用独立低余额钱包（建议$2-10 USDC），禁用主钱包
2. 审批确认：在host层确保per-request approval生效，不盲目信任skill文件声明
3. 地址验证：首次使用前交叉验证/.well-known/payment-address.txt、agent.json、ENS三通道
4. 小额测试：首次使用以$1-2 USDC验证完整支付-反馈流程
5. 定期审计：监控钱包交易记录，异常立即停用

核心用法

Which-LLM 是一个决策优化型 API 技能，旨在帮助 Agent 在成本与质量约束下选择最优语言模型。其核心工作流程分为三步：

1. 决策请求：调用 POST /decision/optimize 提交任务目标、质量阈值、预算上限及工作量预估，API 返回推荐的模型与降级预案；

2. 支付处理：若触发 HTTP 402，需通过配置的 EVM 钱包完成 USDC 转账，支持 Base、Ethereum、Arbitrum、Optimism、Avalanche 五条链，支付后携带交易证明重试请求；

3. 结果反馈：执行推荐模型后，调用 POST /decision/outcome 上报实际成本、延迟、质量评分与成功状态，系统发放 credit_token 用于抵扣后续请求费用。

技能本身不直接调用 LLM，仅提供确定性、可审计的模型选择建议，适合需要成本精细化控制的自动化场景。

显著优点

• 成本可控优化：在质量门槛内自动选择最便宜模型，避免过度配置；
• 多链支付灵活：支持主流 L2 与主网 USDC，Gas 费用可选最优链；
• 结果积分回馈：通过上报真实执行数据获得未来请求抵扣额度，形成正向循环；
• 确定性决策逻辑：非黑盒推荐，提供可解释的选择依据与降级方案；
• 文档完善：详尽描述支付流程、凭证管理与安全验证要求，降低误用风险。

潜在缺点与局限性

• 纯外部依赖：无可执行代码，完全依赖 api.which-llm.com 可用性，单点故障风险；
• 支付摩擦较高：每笔付费请求需链上交易确认，延迟显著高于纯 API 调用；
• 地址验证负担：用户需自行跨多个渠道（ENS、well-known 文件、文档）验证收款地址，操作门槛较高；
• Host 执行不确定性：虽声明默认需逐笔审批，但实际强制力由 Host 环境决定，存在自动扣费风险；
• T3 来源可信度：无开源代码仓库、无已知维护者背景，无法独立审计服务端算法；
• 积分机制封闭：信用代币仅适用于本平台，不具备流通性，长期价值依赖服务持续性。

适合的目标群体

• 成本敏感的企业级 Agent 开发者：需要在质量达标前提下最小化模型调用成本；
• 多模型路由架构师：构建需要智能降级与备选方案的 LLM 编排系统；
• Web3 原生自动化工作流：已熟悉钱包管理、链上支付流程的加密原生团队；
• 实验性项目团队：愿意承担 T3 来源风险以换取潜在成本优化的新兴项目。

不适合：对支付延迟敏感的高频实时场景、无法接受链上操作复杂性的传统 Web2 团队、要求服务商具备强审计背景的企业合规场景。

常规使用风险

• 资金安全风险：钱包凭证配置不当或 Host 未强制审批时，可能导致意外资金流出；
• 网络与 API 可用性：服务中断将导致决策能力完全丧失，需设计本地降级逻辑；
• 支付地址欺诈：若未严格执行多通道验证，可能遭遇 DNS 劫持或文档篡改导致的钓鱼地址；
• Gas 波动成本：低余额钱包可能因 Gas spike 导致交易失败或资金锁定；
• 隐私泄露：向第三方 API 传输任务描述、成本预期等元数据，存在商业意图暴露风险。