MISSING

MISSING — AI Agent 的能力回退网络

MISSING 是一款面向需要当前尚不具备的能力的 Agent 的产品运行时。

Agent 无需臆造自己支持某项能力，也无需停在“我做不到”，而是可以请求 MISSING 查找已有的回放验证能力，通过经过验证的提供方配方执行该能力，或持久记录尚未解决的需求，让可信的获取闭环搜索新的供应来源。

长期产品闭环如下：

agent needs capability
        ↓
MISSING discovery
        ↓
verified supply exists? ── yes ──> execute
        │
        no
        ↓
durable unresolved demand
        ↓
trusted supply acquisition
        ↓
deterministic compilation + repeated live replay verification
        ↓
promote verified recipe
        ↓
future agents reuse it
        ↓
x402 paid resolution + positive margin

当前产品功能

MISSING 目前包括：

• 经过验证的能力注册表和确定性提供方执行；
• 多提供方故障转移和能力搜索；
• 基于 Streamable HTTP 的远程 MCP；
• A2A v1 Agent Card 发现和 JSON-RPC 调用；
• 持久化的未解决需求遥测；
• 采用限流和就绪／存活端点的公共沙盒部署模式；
• 根据结构化 API 目录自动发现按需求排名的提供方；
• OpenAPI 到配方的编译、基于事实依据的验证输入采集、重复实时回放和持久化供应晋级；
• 用于匿名公共访问之外自动获取的可信工作器／控制平面；
• 提供方就绪诊断以及持久化的阻塞／退避处理；
• 明确的提供方经济模型、考虑利润率的路由和计量；
• 使用 x402 的自主 Agent 付款端点；
• 适用于多副本排斥、崩溃恢复、结算对账、租约隔离、请求绑定、精确的链上结算证明、最终性／重组监控、依赖项背压、可中止的截止时间、RPC 链身份准入和遥测对账的共享 PostgreSQL 财务权威。

仓库中仍保留历史实验和正式运维门槛作为佐证，但它们不再是产品说明。

Agent 接口

运行远程产品运行时：

npm ci
npm run build
npm run missing:serve

主要接口包括：

• GET / — 产品公开首页和连接指南；
• POST /mcp — MCP Streamable HTTP；
• GET /.well-known/agent-card.json — A2A Agent Card；
• POST / — A2A JSON-RPC；
• POST /v1/agent/resolve — 启用付款时的 Agent 原生付费解析路径；
• GET /livez、/readyz、/healthz — 运维状态。

本地 stdio MCP 仍可通过以下方式使用：

npm run mcp

公共部署

人类可读的首页：

https://missing-production-e3da.up.railway.app/

规范 MCP 端点：

https://missing-production-e3da.up.railway.app/mcp

A2A Agent Card：

https://missing-production-e3da.up.railway.app/.well-known/agent-card.json

规范付费执行端点：

POST https://missing-production-e3da.up.railway.app/v1/agent/resolve

公共 MCP 工作流

匿名 MCP 仅公开以下四种产品工具：

1. list_verified_capabilities — 查看完整的回放验证能力目录和示例输入。
2. search_verified_capabilities — 根据自然语言任务描述查找经过验证的能力。
3. record_missing_capability_demand — 没有经过验证的匹配项时，持久记录尚未解决的能力需求。
4. resolve_capability — 为某项精确匹配的已验证能力准备付费执行。

发现和目录查看均免费。resolve_capability 不会在 MCP 内部执行提供方，也不会向调用者收费。它会返回一个 payment_required 交接，其中包含当前价格、精确请求正文、规范 /v1/agent/resolve 端点以及可安全恢复的 x402 操作说明。

后续的 HTTP x402 流程会执行提供方调用并完成结算。Agent 应保留精确的请求正文和精确的 PAYMENT-SIGNATURE 以便恢复；对于已关联到已知交易的付款，不应创建第二笔授权。

公开发现

MISSING 已发布在官方 MCP Registry 中：

io.github.leoleon506/missing

Smithery 公开服务：

https://smithery.ai/servers/leo-leon506/missing

由 Smithery 托管的 MCP 网关：

https://missing--leo-leon506.run.tools

Glama 也通过其公开 MCP/Registry 界面收录了 MISSING。

第三方 MCP 目录应指向现有的远程 Streamable HTTP 端点，而不是部署或代理另一个 MISSING 运行时。PUBLIC_DISTRIBUTION.md 记录了当前的 Smithery 和 Glama 分发流程。

x402 402 Payment Required 挑战会公布 Bazaar 发现元数据，而持久化的支付、请求绑定、结算、最终性、隔离和恢复状态机保持不变。

信任边界

MISSING 不会把发现结果视为证明。

发现的供应方线索不能仅仅因为其文档看起来相关，就变成可执行项。自动供给必须通过确定性编译和重放验证关卡，才能晋升。需求在跨过这道边界之前，仍然是未知状态。

付费执行也会在权威支付状态周围采用失败关闭机制。仅仅成功调用供应方并不构成客户收入；只有结算成功后，才确认收入。

当前阶段：Real Agent Loop 2

Kappa.5 和 Operational Readiness 1–9 确立了资金／恢复及依赖安全边界。随后，Real Agent Loop 1 跨越了首个实时商业边界：生产环境基于两笔不同的 Base 主网结算付款，复用同一需求派生的晋升配方并取得正的实际利润，最终发出 GO_REAL_AGENT_PAID_CLOSED_LOOP。

当前的不确定性不再是这个闭环能否发生一次，而是 MISSING 能否在不同能力之间自主复现这一商业闭环：

至少两个不同的外部 Agent 需求能否都由可信控制平面选中、自主转化为经重放验证并晋升的供给，并且各自通过重复付费复用产生正利润？

REAL_AGENT_LOOP_2.md 定义了预注册的证明契约。

符合条件的 RAL2 晋升会携带持久化的可信控制平面来源信息（acquisition_path 和 control_plane_run_id），以免将直接／手动晋升与自主获取证据混淆。

CI 可以验证证明机制，但不能声称取得了实时商业成果。只有生产账本以及获准价值网络上的真实 PostgreSQL 结算记录，才能在未来发出：

GO_AUTONOMOUS_COMMERCIAL_REPLICATION

测试

npm test
npm run build

此代码库将实验性证据、产品里程碑和运行就绪关卡分开，避免将合成／形式化测试通过误认为实时市场证据。

历史实验

项目最初旨在测试：当所需能力缺失时，明确提供备用工具是否会改变 Agent 的行为。这些面向预注册的实验仍保留在 experiments/ 目录及对应的实验源文件／工作流文件中。

它们作为历史科学证据予以保留。产品代码不会改写其来源信息，也不会将新发现的供应方晋升为实验结果。