Open Agentic Web与GEA：智能体网络的架构基础与能力契约-平芜编程栈

Open Agentic Web，开放智能体网络。这个词最近在开发者社区的讨论里出现得越来越频繁，但很多人一上来就把注意力放到了“Agent 能多聪明”上，忽略了真正关键的半句话：当 AI Agent 成为互联网上自主执行任务的程序时，网络这一侧到底应该以什么方式向它开放。

上周和一位做数据中台的工程师聊到这个问题，他说了句让我印象很深的话：“现在大家都在把 Agent 当成更聪明的聊天框，但真正难的问题，是怎么让 Agent 变成互联网上合法的、可审计的、能长期工作的居民。”这句话几乎概括了 Open Agentic Web 这个方向要回答的所有问题。

这里不打算聊“哪个 Agent 平台最强”，而是一个更底层的问题：当 Agent 成为网络的一等公民，GEA 这类架构探索到底在解决什么，为什么它比“多训练一个模型”更接近问题的核心，以及开发者今天可以为此做哪些准备。

1. 先搞清楚：Open Agentic Web 要解决的到底是什么问题

1.1 人看的 Web 和智能体用的 Web，已经分道扬镳

今天互联网上绝大多数资源，是按“人眼友好”设计的。页面要好看，按钮要大，信息层级要符合人的阅读习惯。人浏览网页时，可以容忍视觉噪音，可以理解隐喻，可以凭经验从一个杂乱页面里找到关键信息。Agent 不行。

Agent 看到的是一整份 HTML 文档、需要执行的脚本、需要跳转的登录态、需要点击才能展开的折叠内容。让大模型通过浏览器自动化去操作网页，本质上是在用语义理解能力补偿一个本就不该让机器去读的界面。这条路能走通，但非常脆：页面结构一改，流程就断；验证码一上，流程就断；弹窗一出，流程又断。这不是 Agent 不够聪明，而是现在的 Web 从来没有为机器设计过“原生入口”。

Open Agentic Web 的核心命题，就是给网络增加一层面向 Agent 的原生接口。它不是要消灭 HTML，而是要让 Agent 可以绕过“人类界面”，通过结构化协议直接完成任务。这很像 REST API 出现之后，程序集成不再需要爬页面；面向 Agent 的原生协议成熟之后，Agent 就不再需要模拟点击。真正的变化不是模型变强了，而是“入口”变对了。

1.2 “开放”的真正含义：不是裸奔，而是可协商

很多人听到“开放”，第一反应是“谁都能访问”。如果 Agent 网络按这个思路设计，上线第一天就会被滥用打垮。

开放的正确理解应该是三个词：标准化、可协商、可审计。标准化，指服务方公开自己的能力描述，让 Agent 能以统一方式发现和理解。可协商，指服务方可以声明权限边界、频率限制、成本计价，Agent 在任务开始前就能读到这些约束。可审计，指 Agent 的每个动作都能追溯到某个身份、某次授权、某条事件记录。三个词加起来，才叫开放。

这个区分很重要。只要把“开放”理解成“裸奔”，后面所有架构讨论都会跑偏。GEA 这类方案如果要在开放智能体网络里承担关键角色，它首先要提供的能力，不是“让 Agent 随便调”，而是“让 Agent 在明确边界内安全地调”。

2. GEA 的定位：常被忽视的中间层

2.1 从单次调用到持续性网络，缺的是编排层

现在大多数 Agent 应用，本质上还是“单次调用”。用户问一个问题，Agent 调一次模型，生成一段文本。即使加了工具调用，也大多停留在“请求-响应”模式。这种模式能覆盖的任务很有限，因为真实任务几乎都是多步的：查资料、做对比、填表格、确认结果、提交、后续跟进。每一步之间有依赖，有失败，有需要人工介入的时刻。

GEA 放在 Open Agentic Web 的语境下来看，更像是在回答一个问题：Agent 与 Agent 之间、Agent 与网络服务之间的协作，应该用什么架构来承载？

从工程视角看，GEA 更像是一类架构方向，而不是一个开箱即用的具体软件包。它要把 Agent 的每次动作、每个状态变更、每次服务调用，都抽象成可路由、可重试、可追踪的事件。说得直白一点：GEA 想做的事情，是把“Agent 今天干了一件事”这件事本身，变成网络基础设施的一部分。这个中间层现在很缺，因为模型层已经足够热闹，而网络层还没有为 Agent 准备好“道路”。

2.2 事件驱动为什么适合 Agent 场景

为什么是事件，而不是普通 RPC 调用？因为 Agent 任务有几个特点，和传统请求-响应模型天然不匹配。

第一个特点是长周期。一个 Agent 任务可能持续几分钟、几小时，甚至更久。它中间要等外部系统响应，要等人工确认，要跨多个服务。同步调用撑不住这种节奏，需要异步、消息化和状态持久化。

第二个特点是可恢复。Agent 任务执行过程中，任何环节都可能失败：服务暂时不可用、限流、参数不合法、权限不足。事件驱动的架构天然带重试、死信、补偿这些机制，可以把失败处理从业务代码里剥离出来。

第三个特点是可观测。Agent 的行为比人更难预测，同一个任务，模型选择的路径可能完全不同。如果把所有行为都建模成事件并落日志，事后就能像翻监控一样复盘一次完整任务路径。

所以 GEA 这类架构的核心价值，不是让 Agent 更快，而是让 Agent 的行为变得可管理。这个价值在单个任务上不明显；一旦进入“成百上千个 Agent 同时在开放网络上干活”的状态，它就是生死线。

3. Agent 要真正“上网”，缺的不是模型，而是能力契约

3.1 发现、理解、协商、执行：一条完整链路

一个 Agent 要在开放网络上完成真实任务，至少要经过四个环节。

发现。Agent 怎么知道网上有哪个服务能帮它完成任务？靠搜索引擎返回的自然语言摘要不够，Agent 需要结构化的服务目录——给 Agent 用的“应用商店”，每个服务都有机器可读的能力描述、调用方式、依赖和计价。

理解。拿到服务描述之后，Agent 要能理解“接受什么输入、返回什么输出、有什么约束”。这里需要标准。现有 OpenAPI 描述的是接口语法，描述不了任务语义。比如一个“订阅天气预警”的服务，OpenAPI 能告诉 Agent 怎么调/subscribe，但没法告诉它“这个服务会在台风路径变化时主动推送”。Agent 需要的是能力契约，不只是接口文档。

协商。Agent 要确认自己有没有权限、服务方允许多高频率、一次任务要花多少钱。人类世界里靠注册账号和同意条款完成，Agent 世界里必须靠机器协商完成。

执行。到这一步，Agent 才能真正调用服务、获取数据、执行操作、跟踪状态。

现在绝大多数 Agent 应用，第一步靠提示词，第二步靠人写函数调用，第三步直接跳过，第四步靠 try-catch 硬扛。这不是工程化，这是手工作坊。Open Agentic Web 要成，就必须把这四步依次补上。

3.2 最小可行的能力契约长什么样

如果 GEA 要推动开放智能体网络落地，它至少要定义出一种“能力契约”格式。这个格式不一定复杂，但至少要有三类信息：

能力描述：这个服务能完成什么任务，输入输出是什么，有没有副作用。
约束声明：频率限制、并发限制、白名单、黑名单、超时时间、最大请求体。
责任边界：失败时谁负责重试，数据保存多久，是否有人工介入机制。

下面是一个简化示例，用来表示“能力契约”这类文档的常见结构：

{ "service": "weather-alert", "version": "1.2.0", "capabilities": [ { "action": "subscribe", "description": "订阅指定区域的天气预警推送", "input": { "region_code": { "type": "string", "required": true }, "alert_level": { "type": "string", "enum": ["blue", "yellow", "orange", "red"] } }, "output": { "type": "subscription_id" }, "side_effect": true, "idempotent": false } ], "limits": { "rate_per_minute": 10, "max_batch": 20 }, "auth": { "type": "oauth2", "scopes": ["weather:read", "alert:subscribe"] } }

这只是一种常见写法，具体字段名称和格式会随实现变化。重要的是结构：先描述任务语义，再声明约束，再说明权限。Agent 拿到这份文档，就能在调用前评估“能不能做、被不允许做、会不会产生副作用”。服务方也省去了被不懂规矩的调用方反复骚扰的维护成本。