Mycelio 是智能体用来替代 HTTP+JSON 的二进制层。一个持久连接为智能体提供两种能力： FETCH 将任意公开 URL 读取为干净的 Markdown（token 比原始 HTML 少约 30 倍），以及 ROUTE 直接调用已签名的厂商清单，无需阅读其文档。每个响应都由目录服务进行 Ed25519 签名。
myc://mycelio.prowl.world:4242
100 项测试 · Apache 2.0
v0 — 目前还没有主流智能体运行时支持该协议
把任意公开 URL 交给 Mycelio，daemon 会抓取页面，在本地用 trafilatura 将正文提取为 Markdown。遇到 SPA 和 PDF 时按需回退到 Jina Reader，再把结果放进已签名的二进制信封中返回。不需要 API 密钥，厂商侧也不需要 SDK。结果缓存 24 小时。
curl https://mycelio.prowl.world/r/<any-url># pip install "mycelio @ git+https://github.com/opcastil11/mycelio.git"
import asyncio
from mycelio import MycelioClient
ROOT_PUBKEY = bytes.fromhex(
"23f6ebbc8faddb7ee8c9dedf2ef8e81057fb7d0bbace6ba26523452ef739c20c"
)
async def main():
async with MycelioClient.connect(
"mycelio.prowl.world", 4242, root_pubkey=ROOT_PUBKEY,
) as cli:
page = await cli.fetch("https://news.ycombinator.com")
print(page.content[:400])
print(f"\n→ {len(page.affordances)} affordances extracted")
asyncio.run(main())响应包含干净的 Markdown 以及 一组智能体可直接操作的类型化 affordance（链接、表单），相对 URL 已按页面地址解析好。trafilatura 无法解析的 SPA 和 PDF 会自动交给 Jina Reader 处理，对调用方无感知。
数据于 2026-05-23 以 news.ycombinator.com 测得。具体数字因页面而异：内容密集的文档站点压缩率更高，静态落地页则较低。但总体规律不变：干净的 Markdown 比原始 HTML 小得多。
整个调用链路都围绕一个产物：一个小巧的签名文件，指向厂商已在提供的 HTTP API。下面是一份典型的 Mycelio 清单，已解码为可读形式：
# stripe-payments.myc · 412 bytes signed
service: stripe.com
title: Stripe Payments API
backend: https://api.stripe.com/v1
auth: bearer-token (Authorization header)
endpoints:
- op: charge
method: POST /charges
in: { amount: int, currency: str, source: str }
out: { id: str, status: str }
- op: refund
method: POST /refunds
in: { charge_id: str, amount: int }
out: { id: str, status: str }
signatures:
vendor: ed25519:9f8a3d...
directory: ed25519:1b4c7e...按二进制帧编码后仅 412 字节。你用自己的 Ed25519 密钥签名，目录服务再用根密钥联合签名。你的 HTTP 后端完全不用改动，Mycelio 只是描述如何访问它。无需 SDK，无需运行服务器，也无需维护集成。
这是 v0。参考 daemon 运行于
myc://mycelio.prowl.world:4242。Python SDK 可从 GitHub 安装（PyPI 版本即将发布）。100 项端到端测试全部通过。传输格式已足够稳定，可以基于它开发。
已发布： 规范 v0、二进制帧编解码器、TLS 支持、异步 daemon、带 Ed25519 双重签名的厂商清单，
INSPECT, ROUTE，以及 FETCH
等动词均已端到端可用（FETCH 支持 affordance 提取和 Jina 回退）。 下一步：
Prowl Design — 根据你现有的 OpenAPI 自动生成签名清单。
不过坦白说，以下是它目前 尚未 做到的：
而 FETCH 这一侧绕开了这个困境：从第一天起就能处理公开网络上的任意 URL，不需要厂商采用。这正是我们先发布它的原因。
我们押注的是： 随着智能体从「IDE 里的工具循环」走向「自主运行、一次会话调用成千上万个 API」，先有鸡还是先有蛋的局面会反转。唯一能扩展到「互联网上所有 SaaS」的协议，必须让厂商什么都不用实现，因为长尾厂商不会为每个智能体运行时单独部署服务器。如果这个判断成立，Mycelio 就会成为承载这一切的那一层。
如果判断错了：目录服务的 HTTP API 照常可用，你现有的 OpenAPI 也照常可用，完全可以忽略 Mycelio。押注这个协议的成本只是一份清单文件，五分钟就能签好，随时可以撤销。
MCP 和 Mycelio 工作在不同层面，我们认为二者是 互补而非竞争关系。当智能体的运营方已经选定了你的工具时，MCP 的优势最明显：用户已安装你的 MCP 服务器，智能体处于工具循环中，参数也都已知。 Mycelio 面向的是在此之前的那一层：对智能体启动时并不知道的服务进行公开发现和调用。
不过，两者在一些关键之处的技术取舍有所不同：
DISCOVER)
我们无意取代用于智能体运行时内工具调用的 MCP、用于智能体间通信的 A2A，或采用专有工具语法的 OpenAI function-calling。Mycelio 位于更早的一层：为已经支持 HTTP 的后端提供公开发现，以及基于签名信任链的调用。
完整的组合流程（发现服务、获取页面、调用操作）都在 一个 TCP 连接中完成。动词之间没有额外的 TLS 握手，只有一条签名链、一个认证上下文：
async with MycelioClient.connect(
"mycelio.prowl.world", 4242, root_pubkey=ROOT_PUBKEY,
) as cli:
# 1. find payment APIs
matches = await cli.discover(query="payment", min_score=80)
# 2. read a candidate's site to evaluate it
page = await cli.fetch(f"https://{matches.results[0].name}")
if "x402" in page.content.lower():
# 3. pull the manifest and invoke it
m = await cli.inspect(matches.results[0].service_id)
resp = await cli.route(m, "charge", {"amount": 500, "currency": "usd"})
print(resp.json())
DISCOVER + FETCH + INSPECT +
ROUTE 在同一会话中完成，签名端到端验证。完整示例见
examples/。传输规范：
protocol-v0.md.
目前已有七个动词端到端实现，另有四个在规范中保留供将来使用。保留并不意味着「即将推出」，而是「这个字节已经分配好，以后的实现可以直接扩展，不会破坏兼容性」。
清单格式： manifest-v0.md
Mycelio 采用 Apache 2.0 许可。传输规范、帧编解码器、Python SDK 和参考 daemon 都在公开的 GitHub 仓库中。欢迎提供 Go、Rust、JS 实现。
坦白讲： 目前只有一个目录服务在生产环境运行 Mycelio，那就是
Prowl。位于
myc://mycelio.prowl.world:4242 的 daemon 属于 Prowl，为每份清单联合签名的 Ed25519 根密钥也属于 Prowl。规范并不假定只有一个运营方，但在别人搭建起自己的目录之前，「Mycelio」和「Prowl 的二进制协议」实际上就是一回事。我们宁愿直说，也不想装作不是这样。
担心被锁定？你的清单可以由将来任何一个目录服务提供；你现有的 HTTP API 始终是事实来源，不受这些变化影响；而且你可以随时撤销。
cli.fetch(url) 读取网页，每页约 700 个 token，而不是 20,000 个。Python SDK 从 GitHub 安装（PyPI 版本即将发布）： pip install "mycelio @ git+https://github.com/opcastil11/mycelio.git".