8.0
热点
AI SCORE
编程提效2026-08-05 03:13
面向能力的路由设计：生产级AI Agent实战
dev.to · AI#Agent#架构#路由
Editor brief · 编辑速览
提出以「能力」而非「供应商」作为 Agent 路由单元，详细定义能力契约的五个组成部分及质量度量方法。
大多数 Agent 系统在集成决策上都走同一条老路：选一个搜索、爬取或浏览器自动化的提供商，需要上网时直接调用。
原型阶段这没问题。到了生产环境就脆弱了，因为"上网"不是一种能力。
搜索请求需要相关链接。爬取请求需要来自已知 URL 的干净内容。有来源支撑的回答请求需要带引用的综合结果。浏览器操作请求需要与实时页面成功交互。这些任务的成功条件、延迟特征、成本和失败模式各不相同。
因此路由的基本单位应该是能力，而不是供应商。
本文介绍一种构建该路由层的实用方法。目标不是选出一个全能的最好供应商，而是让每次工具调用都可衡量、可替换，并且与 Agent 实际需要的结果对齐。
从结果出发，而非端点
在选择供应商之前，先定义每种能力成功意味着什么。
一份有用的能力契约包含五个部分：
以 Web 搜索为例。返回 200 OK 是不够的。如果结果包含无关链接、遗漏了请求的时间范围，或返回的摘要没有足够上下文供下一步推理使用，结果仍然毫无用处。
文档解析的成功可能需要可读文本、最小页面覆盖率，以及对扫描页面的 OCR。浏览器操作的成功应该与请求的状态变更绑定，而不是与没有异常绑定。
这一区别避免了一个常见的可观测性错误：将传输成功计为任务成功。
为每种能力构建一张记分卡
一旦成功标准明确，就在每种能力内部评估供应商，而不是把不相关的任务混在一起做全局排名。
实用的记分卡需要四个维度。
1. 质量必须与能力匹配
搜索：在选定截断点下的召回率或相关性。
爬取：内容完整度、Markdown 清洁度、在困难页面上的成功率。
结构化提取：相对于已知 schema 的字段级精确率和召回率。
爬行：发现页面的覆盖率与重复控制。
文档解析：文本准确率、阅读顺序和 OCR 覆盖率。
浏览器操作：请求交互的完成度及结果状态的验证。
避免对所有能力使用一个通用的"质量"测试。指标应该描述下游 Agent 能安全使用什么。
2. 从调用方视角测量墙钟延迟
延迟中位数对了解正常行为有用，但不应作为运营决策的唯一数字。
路由策略还需要一个基于 Agent 总截止时间的超时。如果工作流还剩十秒，一个质量优秀但中位延迟十二秒的供应商对这次调用来说不是可行的主路由。
尾延迟在调用链式场景下很重要。几个单独可接受的延迟可能在最终综合步骤开始前就耗尽整个 Agent 预算。
3. 每个成功结果的成本
每次请求的价格很容易比较，但往往具有误导性。
运营指标是：
每个成功结果的成本 = 总计费成本 / 可用结果数量
假设供应商 A 每次请求收费 $0.001，成功率一半。供应商 B 收费 $0.0015，成功率 90%。忽略重试和二次处理，它们的有效成本是：
看似更便宜的供应商按结果衡量反而更贵。
即使返回了技术意义上有效的响应，失败也应该留在有效成本的计算中。如果 Agent 无法使用数据，系统仍然为一次不成功的尝试付了钱。
将传输错误、超时、格式错误的响应和能力级失败分开追踪。
这种区分有助于回答不同问题：
单一的错误率数字会掩盖修复路径。
4. 保持语料库固定
只有当供应商接收相同任务时，比较才有意义。
对每种能力使用版本化的任务语料库。在给定评估中，每个供应商应该接收相同的查询、URL、目标 schema、截止时间和通过标准。当语料库变更时，递增版本号并记录新的运行日期。
这控制了一种微妙的偏差来源：给一个供应商简单页面，给另一个供应商反爬机器人保护的页面，然后将它们的成功率作为等效工作负载进行比较。
语料库应该包含困难案例，而不仅仅是演示友好的输入。生产级失败往往出现在扫描文档、动态页面、受限速域名、非寻常 schema，以及需要从多个来源获取证据的查询上。
该设计的一个公开例子是 NativePort 运营的基于能力的基准测试方法论。它为每种能力保持固定的语料库，并发布质量、中位延迟、每次成功调用的成本和错误率及运行日期。重要的模式不是其特定的复合分数，而是能力的分离和底层测量的发布。
将选择与执行分离
Agent 应该请求一种能力。路由层应该决定哪个供应商来执行。
概念上，请求包含：
路由器只评估支持该契约的供应商。然后使用最新的合格记分卡和当前运营健康状态选择主路由。
不要让供应商特定的请求字段泄露到 Agent 的规划界面，除非它们代表真实的用户需求。否则，每次更换供应商都会变成一次 Agent 提示的变更。
同时，避免将每个上游响应强制塞进一个过于通用的 schema。归一化在路由边界有用，但能力特定的信息应该在 Agent 需要时仍然可用。
一个好的折中方案是使用一个稳定的外层，包含状态、时间、成本、来源和结果分类，能力响应则保留在其内部。
将降级视为策略，而非重试
重试和供应商降级解决的是不同问题。
重试将相同任务发送到相同供应商，通常在临时故障之后。降级将任务发送到不同供应商，因为第一条路由无法在剩余预算内满足能力契约。
AWS Builders' Library 关于重试和退避的指南解释了为什么重试需要超时、限制、退避和抖动。无限制的重试会放大过载，并将局部故障转变为更大范围的事故。
对于 Agent 工具，降级策略应考虑：
搜索和只读爬取通常比提交表单或变更状态的浏览器操作更容易重试。对于有状态操作，系统需要在安全重试之前具备幂等性或操作后验证。
一个有用的规则是：只有当相同路由可能产生不同结果时才重试。否则，切换路由或停止。
对结果埋点，而不仅仅是请求
路由只有当生产反馈到达记分卡时才能改进。
追踪：
使用分布式追踪连接 Agent 决策、工具调用、重试、降级和最终结果。OpenTelemetry HTTP 语义约定为 HTTP 客户端 span 提供了标准基础，而能力和结果字段可以作为应用属性添加。
注意高基数数据。原始查询、完整 URL 和提取的内容可能包含敏感信息，并会使遥测变得昂贵。优先使用有边界的任务类、适当的哈希标识符和明确的保留规则。
最重要的是，保留"请求完成"和"Agent 收到可用结果"之间的差异。第二个指标才是路由器应该改进的指标。
部署时不要制造路由黑盒
能力路由器应该对运维人员可解释。
对于每个决策，保留足够的信息来回答：
从影子模式开始。让现有集成继续服务流量，同时路由器计算它本会做出的决策。在启用自动切换之前，将这些决策与真实结果进行比较。
然后每次引入一种能力的路由。搜索通常比有状态浏览器自动化更容易，因为成功谓词和重试行为更简单。为事故保持手动覆盖，为记分卡数据缺失或过时的案例保持确定性默认值。
路由器应该可预测地降级。缺失的基准数据不能沉默地变成供应商良好的证据。
实用实现检查清单
在启用能力优先路由之前，确认：
核心思想很简单：Agent 不需要"一个 Web 供应商"。它需要的是在特定预算内完成一次成功的搜索、提取、爬行、文档解析或浏览器操作。
当路由遵循这些能力契约时，供应商选择就变成了运营策略而非永久的架构承诺。这使得 Agent 更容易衡量、失败更安全、演进成本更低。
Disclosure: This article is published by NativePort, whose public benchmark methodology is cited as an implementation example. It does not recommend a product or provider. The draft was prepared with AI assistance and reviewed against the cited sources and public methodology before publication.