AI代理架构：模型路由与工具发现

连接一个大型语言模型（LLM）足以让应用程序生成文本，但这不足以让AI代理完成现实世界的任务。

如果要求模型总结一个已经在其上下文中的文档，模型层就足够了。如果要求它比较今天的竞争对手价格、丰富公司记录、检查社交账户或选择一个不熟悉工作的最佳API，缺失的部分就变得显而易见：代理需要一种可靠的方式来访问外部系统。

因此，生产代理需要做出两个独立的决策：

哪个模型应该处理这一步？
哪个工具或API应该提供数据或操作？

AIHubMix通过统一的模型访问和请求时模型路由来解决第一个决策。Monid通过运行时工具发现、模式检查和按调用计费的执行来解决第二个决策。这些产品位于同一架构的不同层次上。

披露：本文是与Monid进行内容合作的一部分。AIHubMix是下面讨论的模型平台；Monid是工具平台。每个平台都可以独立使用。

AI代理内部的两个路由问题

代理的运行很少是一个同质的模型调用。一个研究代理可能会对请求进行分类、搜索当前信息、提取结构化事实、比较结果并撰写最终答案。这些步骤需要不同的能力。

在模型外部也是如此。一个公司研究任务今天可能需要一个搜索API，明天需要一个公司丰富端点，下周需要一个浏览器自动化工具。如果每个模型和工具在构建时都是硬编码的，每个新任务就会变成一个集成项目。

这两个层次是并行的：

	模型层	工具层
核心决策	哪个模型应该回答？	应该调用哪个API？
选择时间	每个请求	每个任务，运行时
输入	提示、模式、质量和延迟需求	目标、所需数据或操作、模式和价格
输出	模型完成	外部数据或执行的操作
示例	AIHubMix	Monid

这种分离很重要。更好的模型无法创建对实时数据的访问，而更大的工具目录无法对其返回的数据进行推理。代理需要这两种能力，并且它们之间需要有明确的合同。

Monid在为什么AI代理需要两个集成中展示了互补的工具侧视图。从模型侧来看，架构教训是相同的：保持模型选择和工具选择独立，然后优化每一层以完成其自身的工作。

为什么一个固定模型在代理循环中变得昂贵

在每个地方使用一个模型看起来很简单。实际上，它迫使每一步在能力、延迟和价格之间接受相同的权衡。

考虑一个市场研究代理：

意图分类是简短且机械的。
工具选择需要可靠的指令跟随。
从返回的JSON中提取字段主要是转换。
最终报告可能需要更强的推理和更好的写作。

将所有四个步骤发送到最强大的模型会浪费常规工作的资金。将所有四个步骤发送到最便宜的模型可能会降低用户阅读的唯一输出的质量。随着代理循环的增长，这种妥协在每次调用中都会重复。

AIHubMix提供了一个与OpenAI兼容的端点，涵盖广泛的模型目录。现有的OpenAI SDK集成可以通过更改API密钥和base_url指向AIHubMix：

from openai import OpenAI

client = OpenAI(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com/v1",
)

response = client.chat.completions.create(
    model="auto:balanced",
    messages=[
        {"role": "user", "content": "对这个请求进行分类并提出下一步。"}
    ],
)

将model设置为auto将模型选择移入请求路径。路由器分析任务并将其解析为合适的模型。策略后缀使优化目标明确：

路由器值	优先级	典型代理步骤
`auto`	成本优先	批量工作和常规转换
`auto:balanced`	能力、成本和延迟	通用代理工作
`auto:quality_first`	能力优先	复杂推理和最终交付物
`auto:latency_critical`	速度优先	交互循环和轻量级规划

路由不会增加额外费用。请求按实际处理它的模型的标价计费。解析的模型和路由细节在响应中公开，包括X-Aihubmix-Router-Resolved-Model头，因此决策保持可观察，而不是变成黑箱。

完整的行为、支持的端点、策略和当前限制在AIHubMix LLM路由器指南中有详细记录。

模型路由并不能给代理提供实时数据

在配置了模型路由后，代理可以为每一步选择更好的大脑。但它仍然无法知道模型训练数据之后发生了什么，访问私有业务系统，或在另一个应用程序中执行操作，除非有工具提供该能力。

这就是许多代理项目积累脆弱代码的地方。一个团队连接一个搜索API，然后一个抓取API，再然后一个丰富API。每个集成都引入了另一个账户、凭证、请求格式、错误模型和计费关系。工具描述通常被复制到系统提示中，并逐渐变得过时。

失败模式是危险的，因为它可能看起来成功。模型可能会针对过时的模式生成一个合理的调用，接收一个不完整的响应，并继续好像任务成功了。运行时模式检查比要求模型记住训练或旧提示中的API合同更安全。

因此，工具层在执行之前应该回答三个问题：

哪个工具可以满足这个目标？
当前适用的模式和价格是什么？
调用实际返回了什么结果？

工具发现是第二个路由层

Monid将工具访问转变为发现-检查-运行的工作流程。代理无需预测每个可能需要的API，而是可以用自然语言搜索目录，检查候选者的合同，并执行所选的端点。

基本流程如下：

# 1. 找到匹配目标的工具
monid discover -q "从公共网页获取当前产品定价"

# 2. 阅读所选端点的模式和定价
monid inspect -p PROVIDER_SLUG -e ENDPOINT_PATH

# 3. 仅在代理检查完合同后执行
monid run -p PROVIDER_SLUG -e ENDPOINT_PATH \
  --query '{"url":"https://example.com/product"}'

发现和检查让代理在花费任何费用之前比较选项。执行根据所选端点的定价模型计费。开发者保持一个集成，而代理则获得跨多个提供商的工具访问。

对于可以读取设置说明的代理运行时，Monid还发布了一个机器可读的技能：

设置 https://monid.ai/SKILL.md

Monid工作流程文档更详细地解释了目录、检查和执行阶段。

这两个层次如何协同工作

模型网关和工具层应保持独立组件，并有一个小而明确的交接：

代理接收用户目标。
AIHubMix将规划调用路由到适当的模型。
计划识别缺失的信息或所需的外部操作。
Monid发现候选工具并公开它们的模式和价格。
代理在其权限和预算内选择并运行工具。
工具返回事实或操作结果。
AIHubMix根据所需的质量、成本或延迟路由综合调用。
代理返回基于工具结果的答案。

用简化的Python，模型侧的调用可以保持不变，而工具结果作为上下文插入：

from openai import OpenAI

client = OpenAI(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com/v1",
)

# 对于轻量级规划步骤，快速模型就足够了。
plan = client.chat.completions.create(
    model="auto:latency_critical",
    messages=[
        {
            "role": "user",
            "content": "计划如何比较这些产品的当前价格。",
        }
    ],
)

# 你的代理使用Monid发现、检查和运行适当的工具。
# 用该调用返回的结构化结果替换这些占位符。
tool_result = {
    "source": "<source-url>",
    "data": "<structured-tool-result>",
}

report = client.chat.completions.create(
    model="auto:quality_first",
    messages=[
        {
            "role": "system",
            "content": (
                "写一个简洁的比较。仅使用提供的工具结果，"
                "保留源URL，并说明何时缺少值。"
            ),
        },
        {"role": "user", "content": str(tool_result)},
    ],
)

重要的细节不是行数，而是这两个选择都不需要永久嵌入到应用逻辑中。模型可以随着提示的变化而变化，工具可以随着任务的变化而变化。

成本控制应在两个层次上

模型和工具的成本使用不同的单位，因此应分别测量。

在模型层，解析的模型决定了令牌定价。AIHubMix使该决策可追溯，并允许开发者选择路由策略或限制API密钥可以使用的模型。常规步骤可以优先考虑成本或延迟，而面向用户的输出可以优先考虑质量。

在工具层，端点可能按调用或按结果收费。Monid在检查期间公开定价，在执行之前。代理可以拒绝超出其预算的端点，优先选择经过验证的选项，或在进行异常昂贵的操作之前请求批准。

有用的生产控制包括：

每个API密钥的模型白名单或价格上限。
每个任务的最大工具调用预算。
受监管数据的提供者或端点白名单。
将模型路由决策与工具调用和最终答案连接的日志。
在不可逆或敏感操作之前的明确确认。
输出验证，以便将工具数据视为不可信输入，而不是指令。

这种分离还使成本调试变得更容易。如果一次运行变得昂贵，令牌日志显示代理是否推理过多，而工具日志显示它是否获取过多。修复是不同的，架构应保持这种区别。

可靠性需要新鲜的合同和可见的决策

动态选择不应意味着不可预测的行为。

在模型侧，AIHubMix为每个请求报告解析的模型和路由策略。会话粘性可以在多轮工作中保持模型一致性和提示缓存的好处，而回退行为可以在必要时远离不健康的模型。

在工具侧，代理在进行付费调用之前检查当前端点模式。发现结果包括比较候选者所需的信息，实际调用的结果成为传递到最终完成的唯一外部证据。

这些控制共同创建了有用的审计轨迹：

用户目标
  -> 路由决策和解析模型
  -> 发现的工具候选者
  -> 检查的模式和价格
  -> 选定的端点和结果
  -> 最终模型决策和基于证据的响应

这条轨迹比仅仅访问许多模型或许多API更有价值。它解释了代理为何做出每个选择，以及支持其答案的证据是什么。

何时不需要两个层次

并非每个工作流程都能从运行时选择中受益。

如果一个应用程序向一个基准模型发送一个稳定的提示，直接指定该模型比路由更简单且更具确定性。如果一个计划的管道始终调用一个已知的API，直接集成该API可能比添加发现层更清晰。

当多样性是工作负载的一部分时，双层架构才会占有一席之地：

提示的差异足以使最佳模型在每一步变化。
代理进行多个模型调用，并需要控制累积成本或延迟。
所需工具无法在构建时完全预测。
外部数据必须是最新的，其来源必须是可见的。
团队希望在不为每个新功能添加新的供应商集成的情况下增加能力。

根据应用程序实际需要做出的决策，使用模型层、工具层或两者。

围绕决策而非依赖构建代理

生产AI代理并不是由它可以访问多少模型或API来定义的。它是由它是否能够为当前步骤选择正确的能力、在预算内操作以及解释发生了什么来定义的。

AIHubMix为代理提供了统一的模型端点和跨成本、质量和延迟优先级的请求时路由。Monid为其提供运行时工具发现、当前模式、可见定价和跨外部提供商的执行。

一个层次决定代理的思维方式。另一个层次决定它如何获取信息并采取行动。保持这些决策分开会产生一个更易于扩展、观察和控制的代理。

从AIHubMix快速入门开始，然后通过Monid连接工具侧。

常见问题

AI代理的模型路由是什么？

模型路由根据任务类型、能力、成本和延迟等因素为每个请求选择一个模型。使用AIHubMix，将model设置为auto或策略如auto:quality_first可以在请求时选择，同时保留与OpenAI兼容的API。

如果LLM已经有知识，为什么AI代理还需要工具？

LLM根据其接收到的上下文和训练期间学到的内容生成答案。它无法可靠地知道当前价格、查询私有数据库或在没有连接工具的情况下执行外部操作。工具提供实时数据和执行；模型进行计划并解释结果。

模型网关与MCP服务器或工具平台是一样的吗？

不是。模型网关将推理请求路由到模型。MCP服务器和工具平台向代理公开外部能力。它们解决互补的集成问题，可以一起使用。

AIHubMix和Monid可以独立使用吗？

可以。AIHubMix可以为没有动态工具需求的应用程序路由模型调用。Monid可以为使用其他模型提供者或网关的代理提供工具发现。当代理在两个层次上都需要运行时选择时，使用两者是有用的。

我如何保持自动路由的可审计性？

记录每个任务的解析模型、路由策略、工具候选者、检查的价格、选定的端点和返回的结果。AIHubMix在响应中公开模型路由细节，而Monid将发现和检查与执行分开，以便在付费调用之前记录工具决策。