ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

goose 接入 Ophis 意图型 DEX 聚合 MCP:让自然语言兑换请求自动变成可执行链上订单

goose 接入 Ophis 意图型 DEX 聚合 MCP:让自然语言兑换请求自动变成可执行链上订单 goose 接入 Ophis 意图型 DEX 聚合 MCP让自然语言兑换请求自动变成可执行链上订单【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/gooseOphis 是一个基于意图intent-based的 DEX 聚合器为 AI Agent 提供了无需 API Key 的无密钥 MCP 服务器。本文讲解如何在 goose 中以「远程扩展Streamable HTTP」的形式接入 Ophis使 goose 能够把swap 100 USDC for ETH on Base这类自然语言兑换请求解析为结构化意图、获取报价并构建待签名的链上订单读完本文你将掌握两种接入方式Desktop 一键安装与 CLIgoose configure引导配置并理解 goose 远程扩展在源码层面的配置模型与 Ophis 无托管、用户钱包签名的安全边界。Ophis 是什么为链上兑换而生的自然语言意图层Ophis 是一个意图型 DEX 聚合器在传统聚合路由能力之上增加了一个「自然语言层」以及一个面向 AI Agent 的无密钥 MCP 服务器。其关键设计取向可以从官方文档 ophis-mcp.md 中归纳为以下几点Intent-based意图驱动用户无需手写复杂的路由参数只需表达“想用什么换什么、在哪个链上”由协议在幕后把该意图解析成可执行的兑换方案无托管non-custodial交易由用户自己的钱包签名服务器自始至终不持有私钥与资金Gasless在结算环节帮助用户省去/外包 Gas 处理成本MEV-protected对抢先交易等 MEV 攻击提供保护返还兑换盈余surplus当实际成交价优于报价时多出来的部分会返还给交易者而非被协议截留。在底层实现上Ophis 是 CoW Protocol 的一个分叉fork它部署了自己的结算合约settlement contracts于Optimism与Unichain而在其余支持的链上通过 CoW Protocol 路由结算覆盖链包括Ethereum、Base、Arbitrum、Polygon、BNB Chain、Gnosis、Avalanche、Linea、Plasma、Ink。这也是为什么它能在跨链场景下给出可验证、可审计的订单结构。无密钥 MCP无需 API Key 与任何环境变量与大多数需要注册、申请密钥的第三方 MCP 服务不同Ophis 的 MCP 服务器是keyless无密钥的接入时不需要 API Key配置阶段不需要设置任何环境变量由于交易签名发生在用户自己的钱包侧服务器永远不接触密钥或资金。这对 goose 这类 Agent 框架的接入非常友好——意味着配置过程不涉及密钥托管、环境变量注入或 OAuth 客户端注册属于“填一个端点就能用”的远程扩展。从 goose 的扩展类型设计看这类无鉴权远程扩展对应 extension.rs 中的ExtensionConfig::StreamableHttp变体其headers、envs、client_id等鉴权相关字段全部可选Ophis 场景下这些字段留空即可。暴露的 14 个工具Ophis MCP 服务器对外暴露14 个工具覆盖从意图解析、代币解析、报价、订单构建到账户与组合查询的完整兑换工作流分类工具意图与解析parse_intent、resolve_token、list_chains报价与盈余get_quote、expected_surplus订单生命周期build_order、validate_order、submit_order账户与收益get_balances、get_portfolio、lookup_tier、get_integrator_earnings链上与行情信息get_gas、get_token_chart从工具命名与文档描述可以推断一次完整的自然语言兑换大致会经历如下阶段先用parse_intent把自然语言“翻译”成结构化意图 → 用resolve_token与list_chains校准代币地址与目标链 → 通过get_quote拿到报价并用expected_surplus评估可返还盈余 → 用build_order与validate_order构建并校验未签名订单→ 最后由用户钱包完成签名、经submit_order提交上链。goose 作为 Agent 可以自主编排这些工具调用把这套流程当作一次普通的“工具调度任务”来执行。将 Ophis 添加为 goose 扩展配置 Ophis 本质上是为 goose 添加一个Remote Extension (Streamable HTTP)类型的远程 MCP 扩展端点固定为https://mcp.ophis.fi/mcpgoose Desktop 与 goose CLI 两条路径均可完成配置。方式一goose Desktop 快速安装推荐在 goose Desktop 中可以直接使用官方安装器深链一键添加该链接本质是把下面这段扩展元数据以goose://extension协议传给 Desktop 客户端goose://extension?typestreamable_httpurlhttps%3A%2F%2Fmcp.ophis.fi%2FmcpidophisnameOphisdescriptionNatural-language%20intent%20DEX%20aggregator%20with%20a%20keyless%20MCP%20server%20for%20AI%20agents该链接携带的参数即最终写入 goose 配置的核心字段typestreamable_http扩展类型、urlhttps://mcp.ophis.fi/mcpStreamable HTTP 端点、id/nameOphis扩展标识与显示名以及用于 Agent 理解扩展用途的描述文本。方式二goose CLI 使用goose configure在终端中运行配置向导并选择Remote Extension (Streamable HTTP)goose configure随后按引导依次选择/填写What type of extension would you like to add?→ 选择Remote Extension (Streamable HTTP)What would you like to call this extension?→ 输入OphisWhat is the Streamable HTTP endpoint URI?→ 输入https://mcp.ophis.fi/mcpPlease set the timeout for this tool (in secs)→ 可保持默认300秒goose 等待扩展动作完成的超时上限Enter a description for this extension→ 可填写Natural-language intent DEX aggregator with a keyless MCP server for AI agentsWould you like to add custom headers?→ 选择NoOphis 无密钥、无鉴权头。上述向导交互与goose configure的完整提示语可对照仓库中的 CLIExtensionInstructions.tsx 查看该组件正是这些官方扩展教程共用的 CLI 配置说明渲染源。完成后的提示Added Ophis extension即表示扩展写入成功。配置落盘与源码级字段说明CLI 与 Desktop 生成的配置最终都会写入 goose 的扩展配置中序列化格式与 goose 源码中的ExtensionConfig枚举一一对应。在 extension.rs 中StreamableHttp变体通过#[serde(rename streamable_http)]与type字段绑定并包含以下核心字段type: streamable_http # serde 标签标识远程 Streamable HTTP 扩展 name: Ophis # 扩展唯一标识 description: - # 供 Agent 理解扩展用途 Natural-language intent DEX aggregator with a keyless MCP server for AI agents uri: https://mcp.ophis.fi/mcp # MCP Streamable HTTP 端点 timeout: 300 # 工具调用超时秒可选但建议显式配置 # 以下字段在 Ophis 场景均可不填 # headers: {} # 需要鉴权时按 header 注入如 Authorization # envs: {} # 环境变量注入 # socket: null # HTTP-over-UDS 场景专用 Unix socket 路径 # client_id: null # 服务端不支持 Client ID Metadata 时预注册的 OAuth client id # scopes: [] # 需要 client_id 配合的 OAuth scopes需要留意两点如果看到旧式sse类型的远程扩展goose 目前仅提示迁移到streamable_http见 extensions.rs因此接入 Ophis 应始终选用Streamable HTTP类型即使未来 Ophis 或其他服务方要求鉴权goose 的StreamableHttp配置模型也已预留headers、envs/env_keys、以及带client_secret_key/scopes的 OAuth 字段可在不更换扩展类型的前提下平滑升级。在 goose 中使用 Ophis 的示例配置完成后goose 会通过 MCP 协议把上述 14 个工具暴露给 Agent。此时只需用自然语言描述兑换意图goose 即可自主挑选工具、填入参数并推进流程。官方文档给出三类最典型的问法解析一个兑换意图Parse this swap intent: swap 100 USDC for ETH on Base.goose 会调用parse_intent把这句话拆解为结构化的意图对象数量 100、代币对 USDC→ETH、目标链 Base。获取报价Get a quote to swap 0.5 WETH for USDC on Arbitrum.goose 会经resolve_token定位代币、以list_chains/get_gas确认网络状态后调用get_quote返回带预期成交价与expected_surplus可返还盈余的报价。查询支持的链Which chains does Ophis support?goose 直接调用list_chains回答覆盖前文列出的 Ethereum、Base、Arbitrum、Polygon、BNB Chain、Gnosis、Avalanche、Linea、Plasma、Ink、Optimism、Unichain 等链。订单的签名边界需要特别强调服务器返回的是报价与一份未签名unsigned订单。真正的交易签名发生在你自己的钱包里扩展与服务器全程不接触私钥与资金。也就是说goose 可以把兑换流程推进到“万事俱备、只欠签名”的订单状态但链上放行权始终由你掌握——这正是无托管设计的核心价值。安全与使用建议先问价、后构建、再签名建议让 goose 遵循get_quote → build_order → validate_order → submit_order的顺序推进并在submit_order前人工核对报价与expected_surplus无鉴权远程扩展仍要认明端点由于 Ophis 不需要自定义 headersgoose configure的最后一步直接选No若未来接入需要密钥的同类服务则应在 headers/envs 中注入且注意把密钥交给 goose 而非写进对话上下文超时按需调整默认300秒对跨链报价与订单构建通常足够网络波动较大时可适当调高仅在可信来源下使用安装器深链goose://extension会直接触发扩展写入请确保链接来源为官方文档本页即仓库内原始出处 ophis-mcp.md。小结Ophis 的接入流程是一个典型的 goose「远程 MCP 扩展」落地案例一端是 keyless、免密钥的第三方意图层服务另一端是 goose 对StreamableHttp远程扩展的统一配置模型与goose configure引导式体验。接入之后goose 便获得了把「我想把 USDC 换成 ETH」这样的模糊诉求加工成带报价、可校验、待签名的链上订单的完整工具链。类似的远程 MCP 扩展接入方式可在仓库的 mcp 扩展文档目录 中对照其他服务方进一步查阅而扩展配置模型的底层实现则见 extension.rs 与配置解析相关代码 extensions.rs。【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表