想知道我们要去哪里，先得正视眼下的局限。传统智能合约很强大，但从根本上说是与世隔绝的。它们依赖确定性的代码和链上的内部状态，实际上是在一个黑盒里运行。要“看见”外部世界，它们得靠第三方中介，也就是标准的预言机，把数据推送进来。
Intelligent Oracles 打破了这种隔绝。
它们构建在 GenLayer 之上，充当通往外部世界的大门，运行在能执行非确定性任务的原生 Python 环境中。从功能上说，Intelligent Oracle 就是一个 Intelligent Contract，专门用来获取任意的公开网页数据（文本、HTML 或图像），通过大语言模型（LLM）处理，并以无需信任的方式就结果达成共识。它们不只是存储数据，还具备解读数据的逻辑。
工程上的难点在于共识：一个去中心化网络，如何就一个动态网站的内容达成一致？网页数据和 AI 推理都可能是非确定性的，不同节点执行同一个任务，可能得到不同的结果。
GenLayer 用 Optimistic Democracy 解决这个问题。它不依赖单一数据源，而是随机选出一个验证者评估组，由它负责达成共识。随机选出的领导者提出一个结果，再由评估组中的验证者依据预先定义的“一致规则”核验这个结果。
这些规则称为等价原则（Equivalence Principles），共有以下几种：
- 严格等价（gl.eq_principle.strict_eq）：验证者各自独立执行任务，要求结果与领导者的结果逐字符完全相同。适合历史代币价格这类确定性数据。
- 比较式等价（gl.eq_principle.prompt_comparative）：验证者各自独立执行任务。核验时，它们运行一个 LLM 提示词，依据开发者定义的标准，同时评估领导者的结果和自己的结果。如果 LLM 判定两个输出之间的关系满足这一标准，就视为达成一致。
- 非比较式等价（gl.eq_principle.prompt_non_comparative）：验证者不重新执行任务，而是让 LLM 充当评判者，核验领导者提出的结果在逻辑上是否满足开发者定义的标准。
- 自定义等价：在高级用例中，开发者并不局限于这些默认选项。你可以定义完全任意的 Python 函数，精确规定领导者和验证者必须如何达成共识。
注：深入分析 Optimistic Democracy 和等价原则的运作机制，超出了本文的范围。如果你想全面了解这套共识架构，可以点击这里阅读。
预言机版图
要看清 Intelligent Oracles 与现有方案的区别，最好的办法是按数据进入区块链的方式来分类。区块链要正常运转，就得依赖预言机，也就是把数据推送上链的链下中介。这些预言机可以归结为两种主流架构：实时数据馈送，或者由人类参与者提出、可被质疑的数据提案。
数据馈送型预言机（Chainlink、Pyth）是高速的订阅服务。对资产价格这类标准数据，它效率极高，但也很僵硬：你的应用能否存在，取决于某条特定的数据流是否受支持。
为了绕开这个限制，乐观预言机（UMA）允许更开放、但也更慢的数据提案。任何人都可以质押一笔保证金来提交结果，系统默认它为真，除非有人在“挑战期”（liveness period）内明确提出质疑。这种模式虽然灵活，却撞上了一道隐形的天花板：人的注意力。争议需要人工投票。你不可能让一个 DAO 每天核验 10,000 笔小额交易。因此，这类模式自然会偏向高价值、低频次的市场，实际上忽略了由日常小额争议构成的“长尾”。
GenLayer 提供了第三条路：Intelligent Oracles 为你的应用装上大脑，让它能接触外部世界，从而治好合约“看不见外界”的毛病。开放，且无需信任。
Intelligent Oracles 如何工作？
Intelligent Oracle 最常见的用途，是把混乱、非结构化的网页，转化为结构化的链上事实。
要理解 Intelligent Oracles 的威力，不需要假设的场景。所有建设者依靠的都是同一个简单的循环，它突破了标准 EVM 的边界：
- gl.nondet.web.render()：离开区块链、访问网页的能力。
- gl.nondet.exec_prompt()：用 LLM 处理这些数据的能力。
- gl.eq_principle：一套规则，迫使由 AI 模型组成的网络就唯一真相达成共识。
选哪种等价原则，完全取决于你所需数据的性质：
- 如果你需要所有节点的输出完全一致（例如提取某个特定地址，或者某个代币的历史数据等），就用语法等价（strict_eq）。
- 如果你提取的是文本，措辞可能不同但意思必须相同（例如总结一篇新闻报道，或者做情绪分析），就用语义等价（prompt_non_comparative、prompt_comparative）。
- 如果你获取的是波动剧烈的数据（比如实时代币价格），就用自定义验证。这类数值时刻都在变，严格等价往往会失败。你大概也不想做一次完整的比较式 LLM 调用，至少这样做效率不高。这时，自定义等价让你可以定义一个“容差范围”（例如价格相差不得超过 1%），而不是要求完全一致。
“Reader”模式（“text”或“html”）
在这种模式下，合约以文本或 HTML 格式获取内容（触发验证者节点渲染某个特定 URL），再把内容交给 LLM，从中提取特定信息。
示例：比特币价格预言机
在这段代码中，合约获取一个网页，让 LLM 提取价格。为了简单起见，这个例子使用严格等价，假设 LLM 能从静态快照中提取出精确的整数。在高频的生产环境中，前面提到的“容差范围”自定义原则会更安全。
完整示例见这里。
“Vision”模式（“screenshot”）
文本固然强大，但有些真相是视觉上的。这种模式借助多模态 LLM 来处理和解读图像。
与文本提取不同，视觉分析天生就带有主观性。两个人描述同一张图片，说法可能各不相同。因此，这种模式最适合用来寻求语义上的一致。
示例：“Proof of Steak”验证器
在这段代码中，合约分析一个图片 URL，判断它是否展示了一块熟牛排。它使用比较式检查，以应对 AI 表述“Yes”时的各种差异。
完整示例见这里。
从理论到实践
这些模式并非纸上谈兵。建设者们正在部署它们，解决过去在链上无法解决的问题。
- Luk 的“Proof of Steak”：GenLayer 2025 年 11 月黑客松的冠军项目。它利用 Vision 模式，打造了一个有趣、可验证的社交游戏。用户上传自己的晚餐照片或其他内容，由去中心化的陪审团验证并打分。
- Ying 的 Price Prediction Oracle：Ying 用 Reader 模式搭建了一个系统，从主要新闻网站和交易所抓取原始 HTML，实际上把任何公开 URL 都变成了潜在的预言机数据源，既不需要 API 密钥，也不需要许可。
- Jay 的“Watchdog”：一个安全应用，监控外部服务器（比如 GitHub 或 CoinGecko）的健康状况。它用 Reader 模式检测宕机，并自动触发链上熔断机制，在服务中断期间暂停合约。
- Pavel 的“Guess the Picture”：Vision 模式的游戏化实现，用户画出某个概念，由 AI 陪审团根据语义准确度打分。
现在，我们有了能看、能读、能反应的合约。然而，离开 EVM 确定性的安全区，进入变幻莫测的互联网，并非没有风险。要构建经得起时间考验的系统，了解 Intelligent Oracles 的局限，和了解它们的能力同样重要。
当前的局限：“真相”的脆弱
最大的挑战不是 AI，而是这张“狂野”的万维网（World Wild Web）本身：在这里，稳定是稀罕事。今天可靠的数据源，明天可能就设了付费墙、被 Cloudflare 拦截，或者干脆下线。这带来一种危险的摩擦：如果你为了确保“无需信任”而把某个 URL 硬编码进合约，你就是在押注这个网站永远不会改变反爬虫策略。依赖静态 URL 会形成单点故障，可能迫使你付出高昂代价重新部署。
建设者提示：部署任何合约之前，先核实你的数据源。你可以用 Intelligent Crawler 确认目标 URL 的内容是否真的能访问。
反过来，允许用户提交任意 URL 同样危险。恶意行为者可以轻松搭建一个假新闻网站，或者仿冒某个信誉良好的域名，向你的预言机投喂虚假数据。解决办法在两者之间：域名白名单。建设者必须把 URL 当作可变的状态，而不是静态的代码。在链上维护一份经过审核、可信的域名列表（例如 coindesk.com、bbc.com），你就能防止错误信息，也让你的协议在某个 URL 失效时可以灵活切换数据源，而且全程无需信任。
这是一段域名白名单的代码。我们先规范化 URL，再检查它是否在白名单之内。这一步很重要，你要在这里定义判断逻辑（例如，你是只允许某个域名下非常具体的路径，还是允许该域名下的任何路径）。
完整代码见这里。
此外，虽然 Intelligent Oracles 在技术上可以用标准 HTTP 请求（GET/POST）从任何 API 获取数据，但这里有个问题：隐私。大多数 API 需要私有的 API 密钥来做身份验证。在传统服务器上，你会把密钥藏在安全的 .env 文件里。可在区块链上，一切都是公开透明的。如果你把 OPENAI_API_KEY 或 BLOOMBERG_KEY 硬编码进合约，网络上的每个验证者和区块浏览器都能看到它。所以在当前模型下，接入私有的订阅制 API 并不现实：恶意行为者可以立刻抓走你的密钥，耗光你的额度。
最后是智能的成本。GenLayer 每一轮共识都要运行多次 LLM 推理。别用超级计算机去干计算器的活。如果你只需要 ETH 的价格，就用 Chainlink 或 Pyth 这样专门的确定性数据馈送；对这种特定任务，它们更快也更便宜。把 GenLayer 留给“长尾”：数以百万计的主观、混乱、复杂的问题，它们需要的是理解，而不只是算术。
潜力：作为经济智能体的 Intelligent Oracles
隐私仍然是一个限制，但业界正在向一种解决方案靠拢，它能把 Intelligent Oracles 从被动的读取者，变成主动的经济智能体。
推动这一方向最有前景的标准，是 x402 协议（基于 HTTP 402 “Payment Required”）。
x402 颠覆了身份验证的模式：预言机不必藏起一个秘密的 API 密钥，只要为自己使用的内容付费即可。当合约请求付费数据时，服务器返回的不是内容，而是一个付款地址。预言机随即自主签署一笔小额交易，“解锁”响应内容。
这实际上消除了对密钥的需求。“身份验证”变成了“付款”。
难点依然存在，尤其是运行在 GenLayer 上的预言机如何完成跨链小额支付。但这套架构打开了一扇巨大的门。它为这样的未来铺平了道路：Intelligent Contracts 不只是抓取开放的网页，还能原生地浏览、协商，并为高质量、有门槛的信息付费，全程无需持有私钥。
需要说明的是：GenLayer 并不想成为又一条通用的 L1 或 L2，取代你现在所用的链。它是一个判定层（Resolution Layer），接入其他 dApp，处理非确定性的决策，相当于一座“互联网的法庭”。
我们已经从只会计算的“智能”（Smart）合约，走到了能够理解的“Intelligent”合约。想现在就开始构建，请访问 IntelligentOracle.com。
在那里，你找到的不只是文档，还有一个专门的 AI 智能体，随时准备实时协助你实现第一个 Intelligent Oracle 模式。基础设施已经上线，浏览器已经打开。唯一缺少的，是你接下来决定构建什么。
开始构建你的第一个跨链 Intelligent dApp 吧。别错过我们的建设者计划（Builders Program）：points.genlayer.foundation。
