技术深度解析
核心的技术挑战在于创建一种协议，它既要足够强大以捕捉现实世界服务的复杂性，又要足够简单以实现广泛采用。领先的概念模型是 结构化服务清单，这是一种机器可读的文件，充当服务提供商与AI代理之间的数字握手。
架构与规范：
一个健壮的清单很可能使用如JSON Schema或OpenAPI这样的模式语言来定义，以确保可验证性和互操作性。其结构必须包含几个关键层次：
1. 身份与认证： 数字签名、API密钥、OAuth端点以及提供商验证凭证。
2. 服务描述： 服务的分层分类法（例如 `cloud.compute.gpu.a100`）、自然语言描述以及机器可解释的能力标签。
3. 定价与SLA模型： 结构化定价表（按单位、订阅、分层）、保证正常运行时间百分比、延迟界限以及惩罚条款。
4. 交互协议： 实际的API端点（REST、GraphQL、gRPC）、其规范（OpenAPI/Swagger）以及支持的动作原语（例如 `reserve`、`purchase`、`query_status`）。
5. 可组合性钩子： 指示此服务如何与其他服务链接的元数据，包括输入/输出数据格式和依赖声明。
算法挑战：
对于代理而言，任务从解析HTML转变为 语义服务匹配与优化。这涉及：
- 清单的向量嵌入： 将结构化服务描述转换为嵌入向量，可实现相似性搜索。寻找“视频编辑”的代理可以通过向量邻近度找到相关服务，如“动态图形”或“色彩校正”。
- 约束满足与多属性效用优化： 代理必须解决复杂的优化问题，在多个提供商之间平衡成本、SLA、质量评级和交付时间。谷歌的 OR-Tools 或开源求解器等框架将被集成到代理的推理循环中。
- 信任与验证图谱： 代理需要评估提供商的可靠性。这可能涉及链上声誉系统（使用智能合约记录SLA合规情况）或联合信任评分。
开源基础：
多个GitHub仓库正在开创相关概念。谷歌的 `ServiceWeaver` 是一个将分布式应用程序编写为单一模块化二进制文件的框架，其编译器负责处理部署。其声明式服务组合的理念与清单的理想模型高度契合。另一个相关项目是Spotify的 `Backstage`，这是一个用于构建开发者门户的开源平台，可编录软件组件及其所有权——这是组织内部服务发现的原始形式。缺失的部分是一个公开的、跨公司的标准。
| 协议层 | 人类网络（当前） | 代理优化网络（提议） |
|---|---|---|
| 发现 | 搜索引擎（Google）、目录（Yelp） | 清单注册中心、分布式哈希表（DHTs） |
| 数据格式 | HTML、非结构化文本 | 结构化YAML/JSON清单（例如 `.service.yaml`） |
| 查询方式 | 关键词搜索、浏览 | 语义向量搜索、基于约束的查询 |
| 交易 | 结账表单、支付网关 | 带有标准化认证和支付令牌的API调用 |
| 验证 | 用户评论、信任印章 | 加密签名、链上SLA日志、代理审计追踪 |
数据启示： 上表突显了从呈现层网络到意图层网络的范式转变。提议的技术栈从根本上对机器更高效，将模糊的解释任务转变为精确的数据检索和优化问题，有可能将代理交易延迟降低数个数量级。
关键参与者与案例研究
定义这一协议的竞赛涉及从云巨头到雄心勃勃的初创公司在内的多元参与者。
具有战略利益的现有巨头：
- 谷歌与Alphabet： 凭借DeepMind的 Gemini 代理和 Vertex AI 平台，谷歌对能够无缝编排服务——尤其是谷歌云服务——的代理有着既得利益。他们在 Knative（用于无服务器工作负载）和 Apigee（API管理）方面的工作提供了基础构件。一个通用清单将极大提升其代理生态系统的效用。
- 微软： 通过 Azure AI 及其对OpenAI的深度投资，微软正将Copilot定位为数字和物理工作流程的协调者。其 Power Platform 连接了数百项服务，是更通用系统的先驱。微软可以倡导一个清单标准，使Azure成为代理发现服务的首选后端。
- 亚马逊： AWS的 Bedrock 代理框架已经允许创建使用AWS服务的机器人。亚马逊对标准化服务接口的兴趣在于巩固其市场地位，并使其庞大的AWS服务目录更易于被自主代理发现和利用。