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 拿到这份文档就能在调用前评估“能不能做、被不允许做、会不会产生副作用”。服务方也省去了被不懂规矩的调用方反复骚扰的维护成本。关键提醒能力契约不是让你把所有接口都公开。它解决的是“边界声明是否机器可读”而不是“要不要无条件开放”。4. 五个绕不开的工程问题从理想回到地面能力契约只是起点。要让 Agent 在开放网络里长期、稳定、合规地工作还有五个工程问题绕不开。4.1 身份与授权Agent 不是人但它要替人负责Agent 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 拿到这份文档就能在调用前评估“能不能做、被不允许做、会不会产生副作用”。服务方也省去了被不懂规矩的调用方反复骚扰的维护成本。关键提醒能力契约不是让你把所有接口都公开。它解决的是“边界声明是否机器可读”而不是“要不要无条件开放”。4. 五个绕不开的工程问题从理想回到地面能力契约只是起点。要让 Agent 在开放网络里长期、稳定、合规地工作还有五个工程问题绕不开。4.1 身份与授权Agent 不是人但它要替人负责Agent