LLM Agent 核心链路：从 DAG 到 MCP 再到记忆系统

一个 LLM Agent，归根结底是四个要素的组合：

1
Agent = LLM + Prompt + Tool + Memory

这四个东西拼在一起，就是一个可组装 Pipeline。最基础的形态是顺序多轮对话——一步接一步走下去，当前步的输出是下一步的输入。LangChain 就是这个思路的典型代表。

但是现实任务往往没这么规整。三个分析步骤可以并行跑；查完数据之后，是发邮件还是继续分析，取决于数据的值。这时候你需要一张 有向无环图（DAG）——节点是操作，边是依赖，LLM 在节点处做决策。而加上循环和持久化状态，就从 DAG 扩展到了完整的图编排——LangGraph 就是这个思路。

这就是本文要讲的：从线性 Pipeline 到 DAG，把 Agent 的四个要素拆开，看每一层在 API 层面到底发生了什么。

我们会先画出 DAG 这张执行蓝图，然后深入 API 的消息协议理解节点间通信，接着给模型注册能力、加上参数校验闭环，再看 MCP 如何把工具集成标准化，最后理解记忆——记忆的本质就是状态管理，无论是 LangGraph 的 StateGraph 还是 Agent 的记忆系统，都是在解决同一个问题：跨步骤的数据怎么保持、怎么读取、怎么更新。

一、从最简单的调用到任务编排

一次调用就够了？

先看最基础的用法——问一句答一句：

1
2
3
4
5
6
7
8
const reply = await openai.chat.completions.create({
  model: "gpt-4o",
  messages: [
    { role: "user", content: "以太坊创始人是谁" },
  ],
})
console.log(reply.choices[0].message.content)
// "以太坊创始人是 Vitalik Buterin..."

简单 Q&A 场景，一次调用够了。但真实需求不会这么乖。假设用户说：

“查一下以太坊最近7天的链上活跃地址趋势，发邮件给我”

这条指令背后需要：

  1. 查 Dune 仪表盘拿到原始数据
  2. 分析数据判断趋势（增长 / 下降 / 震荡）
  3. 写一段分析报告
  4. 调用邮件 API 发送出去

一个 chat.completions.create 做不到——模型不会帮你查 Dune，不会发邮件。你需要把一个大问题拆成多个步骤，分步执行，再把结果串起来。

用团队分工来理解

想象一个项目组接到任务”出一份以太坊近期链上分析报告”：

graph LR
    A[产品定义需求] --> B[研究员拉取基础数据]
    B --> C[数据分析师
量化维度]
    B --> D[竞品分析师
竞争维度]
    B --> E[用户研究员
体验维度]
    C --> F[报告汇总]
    D --> F
    E --> F
more >>

查看全文 >>

Prediction Market 数据同步服务架构设计与工程实践

前言

Prediction Market（预测市场）是 Web3 领域重要的应用场景之一。Polymarket 作为最大的去中心化预测市场平台，提供 Gamma、Data、CLOB 三套 API 接口供开发者消费数据。

但要基于 Polymarket 数据构建一个面向用户的前端应用，需要解决几个实际问题：

  • 数据获取：API 有频率限制，单次查询量有限，需要周期性同步
  • 数据一致性：多 API 之间的数据需要关联和校验，避免状态不一致
  • 实时性：用户需要看到市场的最新成交和结果，依赖 Kafka 事件流
  • 搜索能力：PostgreSQL 不适合全文搜索，需要用 Elasticsearch 做聚合查询
  • 性能：API 请求和数据库查询需要缓存层支撑

本文介绍的这套系统正是为解决这些问题而生的——一个纯后端 Worker 服务，负责从 Polymarket 拉取数据、持久化存储、实时处理事件，最终为前端提供一致的、高性能的数据底座。

一、整体架构

系统是一个纯 Worker 架构——没有 HTTP API，没有前端，只有一个后台进程持续运行。

flowchart LR
    subgraph Input [数据源]
        G[Polymarket Gamma API
事件/市场/标签/翻译]
        D[Polymarket Data API
排行榜/持仓/交易]
        C[Polymarket CLOB API
订单簿/价格]
        K[Kafka
链上事件流]
    end

    subgraph Worker [Worker 服务]
        J[定时调度器
22 个同步Job]
        CON[Kafka Consumer
实时事件消费]
    end

    subgraph Storage [存储层]
        PG[(PostgreSQL
prediction schema)]
        ES[(Elasticsearch
web3_prediction 索引)]
        RD[(Redis
缓存/队列)]
    end

    Input --> Worker
    Worker --> Storage
    Storage --> FE
more >>

查看全文 >>

Web3 代币数据服务 — 架构设计与工程实践

前言

在 Web3 领域，代币数据是上层应用的基础。无论是行情展示、交易决策、安全风控，还是智能投研，都离不开准确、实时的代币元数据、价格、持有者分布和安全信息。但搭建一个覆盖多链、实时更新的代币数据服务面临诸多挑战：

多链异构：Solana 和 EVM 链（BSC、Base）的链上数据结构、RPC 接口、代币标准完全不同。Solana 使用 SPL Token 标准，通过 PDA 派生账户地址；EVM 链使用 ERC-20 标准，合约状态存储在全局 state trie 中。两者在元数据读取、持有者查询、交易解析等各个层面都有本质差异。

数据来源多样：链上 RPC 提供原始数据，第三方 API（CoinGecko、CoinMarketCap、GoPlus、DexScreener）提供增强信息，链下数据源（Twitter、Discord、Telegram 社交链接）补充元数据。多源汇聚带来了数据冲突、时效不一致、部分缺失等问题。

实时性要求高：从代币创建 → 首笔交易 → 市场数据更新，需要在秒级完成。尤其是 Meme 代币的”内盘”阶段，价格波动极快，数据延迟直接导致用户错过交易窗口。

外部依赖脆弱：数十个外部 API 各有不同的速率限制（QPS）、认证方式、响应格式。部分 API 还有反爬机制和 IP 白名单要求，容错降级是刚需。

本文介绍一个用 Golang 构建的生产级代币数据服务，已覆盖 Solana、BSC、Base 三条链，对接数十个外部数据源。下面从架构设计、核心技术、数据流和工程实践四个维度展开。

一、功能概览

该服务的定位是代币数据中台，核心职责包括：

模块 功能
代币收录 监听链上代币创建事件（Mint），自动入库
元数据补全 名称、符号、图标、描述等信息补充
安全检查 貔貅检测、可铸币/可冻结属性、合约安全打分
持有者分析 持有者分布、持仓变化、聪明钱/开发者标记
市场数据 价格、交易量、流动性、FDV、市值、热度评分
榜单排名 热门榜、新币榜、即将完成榜、已完成榜
池子管理 DEX 流动性池地址解析、池费查询与更新

二、系统架构

2.1 整体架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
            ┌─ token_events ──────────┐
            │  trade_events             │
            │  data_events              │
            └────────┬──────────────────┘
                     │ Kafka
            ┌────────▼────────────┐
            │     Core 编排器      │
            │  ├─ 3 个 Consumer   │
            │  ├─ Scheduler       │
            │  └─ Monitor         │
            └────────┬────────────┘
                     │
      ┌──────────────┼──────────────┐
      ▼              ▼              ▼
TokenUpdater   Scheduler任务    PoolFeeService
      │              │              │
      ▼              ▼              ▼
 Elasticsearch  外部API补全    Redis Cache/Queue
      │
      ▼
 Kafka (下游内盘更新分发)

Core 编排器在启动阶段依次初始化：

  1. Repository - 初始化 ES、PostgreSQL、Redis 连接池
  2. ChainManager - 初始化各链的 RPC 客户端（Solana JSON-RPC、EVM ethclient）
  3. TokenUpdater - 启动统一缓冲写入器
  4. 3 个 Kafka Consumer - 订阅不同事件主题
  5. Scheduler - 注册 29+ 个定时任务
  6. Monitor - 暴露 Prometheus 指标（:8091/metrics）
more >>

查看全文 >>

从一笔链上交易到聪明钱信号 — 实时聪明钱系统的架构设计与工程实践

前言

“聪明钱”（Smart Money）指在链上交易中持续表现出色的钱包地址：它们买什么，什么就涨。实时追踪这些钱包的交易行为，可以发现潜力代币、学习交易策略、获得风险预警。

但构建一个实时聪明钱追踪系统面临三重挑战：

  • 数据真实性问题：链上存在两种”真相”——交易账本推导的仓位，和链上实际余额。转账、空投、跨链会导致两者不一致。
  • 并发一致性问题：同一笔持仓可能被多笔交易并发修改，需要严格的串行化控制。
  • 实时性问题：从交易到达 → 持仓更新 → 钱包画像 → 榜单/Feed，需要在秒级完成。

本文从一笔链上交易进入系统开始，逐步讲解它如何经过处理、聚合、衍生，最终变成聪明钱信号，再到整体架构设计。

一、从一笔交易到持仓更新

1.1 输入：原始交易事件

Kafka 中的每一条消息代表一次链上交易，核心字段如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
  "event": {
    "time":         1717660800,     // 交易时间(秒)
    "network":      "bsc",          // 链
    "tokenAddress": "0xABC...",     // 代币地址
    "poolAddress":  "0xDEF...",     // 交易池地址
    "address":      "0x123...",     // 交易者钱包地址
    "price":        1.2345,         // 成交价格
    "volumeUsd":    50000.0,        // 成交量(USD)
    "side":         "buy",          // 方向
    "baseMint":     "0x...",        // 基础代币
    "quoteMint":    "0x...",        // 报价代币
  }
}

1.2 前置过滤

系统首先过滤两类无意义交易：

  • 无法识别链：chainID == 0，直接丢弃
  • 双边 USD 稳定币：输入和输出都是 USDT/USDC 等稳定币，对持仓分析无意义
more >>

查看全文 >>

链上数据实时K线系统 — 架构设计与工程实践

前言

去中心化交易所(DEX)的链上交易数据具有实时性高、数据量大、来源分散的特点。如何将这些原始的链上交易事件转化为标准化的 OHLCV K 线数据，并支持价格异常检测、流动性追踪、多维度统计等能力，是一个兼具工程挑战和业务价值的课题。

本文从一条交易数据进入系统开始，逐步讲解它如何变成 K 线和行情指标，再到整体架构设计。

一、从一条交易到一根 K 线：OHLCV 计算过程

1.1 输入：原始交易事件

Kafka 中的每一条消息代表一次链上交易，核心字段如下：

1
2
3
4
5
6
7
8
9
10
11
12
{
  "event": {
    "time":         1717660800,     // 交易时间(秒)
    "tokenAddress": "0xABC...",     // 代币地址
    "poolAddress":  "0xDEF...",     // 交易池地址
    "network":      "ethereum",     // 链
    "price":        1.2345,         // 成交价格
    "volumeUsd":    50000.0,        // 成交量(USD)
    "side":         "buy",          // 买卖方向
    "address":      "0x123...",     // 交易者地址
  }
}

1.2 时间窗口定位

系统配置了多个 K 线周期（如 1s、5m、15m、1h 等），每个周期有对应的毫秒级 duration。对于每条交易，先计算它属于哪个时间窗口：

1
currentTs = tradeTime - (tradeTime % duration)

例如 tradeTime = 1717660803，对于 5m 周期（duration = 300s）：

  • currentTs = 1717660803 - (1717660803 % 300) = 1717660800
  • 即该交易属于 5m K 线中 [1717660800, 1717661100) 这个窗口

1.3 从缓存中获取当前 K 线状态

每个 (token, pool, interval) 组合在 Redis 中维护一条”进行中”的 K 线。系统先尝试从本地内存缓存读取，未命中则回源 Redis：

1
cacheKey = "kline:{token}:{pool}:{interval}"
more >>

查看全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

大环境不好工作是越来越难找了<br><br>有能推荐的希望推荐下<br>谢谢大家