摘要

  • 10 月 26 日提交的一份 IETF 个人草案要求先确认请求者能看见哪些代理、哪些代理满足硬性条件，再进行语义匹配。
  • 不认识的强制条件应返回 unsupported_constraint；可以忽略不支持的可选偏好，但须在 ignored_preferences 中说清楚。

假设一家 AI 代理把履历写得天花乱坠：懂中文、会总结、反应快。门口的保安只问一句：这位请求者有权把工作交给你吗？《Semantic Routing for AI Agent Communication》个人草案把这句扫兴的话放在了匹配算法前面。作者是 Yong Cui、Yihan Chao 和 Chenguang Du。

草案提出的语义选路功能接收任务意图、执行环境、必需能力、限制条件和偏好，再依据本地可见的代理档案与策略，返回一个目标或一个错误。这里选的是应用层的工作接收者，不是互联网数据包走哪条路。

草案第 6.1 节写明顺序：建立请求者安全身份及其获准查看的目标范围，检查输入，剔除停用或不合策略的候选，落实必需能力与约束，最后才比较任务语义和可选偏好。硬条件淘汰的代理，不能靠漂亮分数复活。

这个顺序遇到不认识的规则时尤其关键。系统无法理解或判断一项强制要求，就该返回 unsupported_constraint。可选偏好则可以放下，但成功决策要列出哪些偏好被忽略。否则，一个“最佳匹配”可能只是系统悄悄删掉要求后的最佳匹配。

另一个小字眼足以改变名单。请求里的 data_location、language 等上下文字段本身是描述；若要强制执行数据驻留或语言要求，还得把它们写进约束。草案用中文机密报告与中国境内数据驻留作示例，这是设计中的假设场景，并非现实事故。

决策还有有效期。改选其他目标时，原先的硬约束必须保留；真正调用代理时，目标或网关还要重新检查当时的授权。选中代理既不预留算力，也不自动给任务开工许可。相亲成功，不能当结婚证用。

IETF 记录显示这是一份 10 月 26 日提交的个人草案。已获批准的 DAWN 工作组章程首先处理公开发现代理，明确把语义撮合、排序与按意图选择排除在初期范围外。找到名字之后，谁有资格被选，仍是另一道题。