为什么这很重要

循环运行的智能体有两个会快速累加的成本。配额成本：每次调用MCP工具都会计入你的周额度。Token成本：上下文窗口中的每段数据都会增加处理成本并降低推理质量。

一个精简的上下文块可以同时解决这两个问题：一次小的行情扫描，总结成几行，在对话开始时注入一次。智能体可以在不产生工具调用风暴或Token膨胀的情况下了解情况。

先决条件

在MCP客户端中配置了Cryptohopper MCP — 请参阅设置概览。
一个定期或持续运行的智能体工作流。单次提示不会受益于此技术。
Pioneer套餐就足够了 — 所有套餐的行情调用都很便宜。请参阅订阅套餐。

设置步骤

定义块的内容
四到六行，全部来自行情数据 — 大约100个Token。典型的块涵盖：主要Token的价格和24小时变化，你的扫描范围内的最大涨幅和跌幅Token，任何交易量异常的交易对，以及一个词的市场状态标签。
```
BTC  66,120   (+1.1%, vol normal)
ETH   3,240   (+2.8%, vol elevated)
SOL  148.50   (+1.9%, vol normal)

Top gainer:      ARB +8.2% (vol 2.4x)
Top loser:       DOGE -3.5% (vol normal)
Unusual volume:  LINK (flat price, vol 3.1x)

Market regime:   risk-on, moderate breadth
```

通过按符号循环生成块

没有批量行情工具 — 每个行情都是一次MCP调用。下面的函数为每个符号调用一次。3个主要Token + 10个符号的扫描每次运行需要13次调用。

def build_thin_context() -> str:
    exchange = "binance"

    # Fixed anchor tickers — one call each
    anchors = ["BTC/USDT", "ETH/USDT", "SOL/USDT"]
    anchor_tickers = [mcp.get_ticker(exchange, pair) for pair in anchors]

    # Sweep universe — one call per symbol
    sweep_pairs = [
        "ARB/USDT", "OP/USDT", "AVAX/USDT", "LINK/USDT", "AAVE/USDT",
        "UNI/USDT", "DOGE/USDT", "MATIC/USDT", "SEI/USDT", "TIA/USDT",
    ]
    sweep_tickers = [mcp.get_ticker(exchange, pair) for pair in sweep_pairs]

    # Derive summary fields
    all_tickers = anchor_tickers + sweep_tickers
    top_gainer  = max(all_tickers, key=lambda t: t.change_24h_pct)
    top_loser   = min(all_tickers, key=lambda t: t.change_24h_pct)
    unusual     = [t for t in all_tickers if t.volume_ratio_vs_baseline > 2.5]

    return format_as_context(anchor_tickers, top_gainer, top_loser, unusual)


# Total calls = len(anchors) + len(sweep_pairs) = 13 per run

将块注入智能体的开场白顶部

将块放在任务指令之前，并附带时间戳。智能体首先读取上下文，不应重新获取已列出的任何内容。

[CONTEXT AS OF 2026-04-24 08:00 UTC]

BTC  66,120   (+1.1%, vol normal)
ETH   3,240   (+2.8%, vol elevated)
SOL  148.50   (+1.9%, vol normal)

Top gainer:      ARB +8.2% (vol 2.4x)
Top loser:       DOGE -3.5% (vol normal)
Unusual volume:  LINK (flat price, vol 3.1x)

Market regime:   risk-on, moderate breadth

Your task: [the actual thing you want the agent to do]

当需要更多数据时，让智能体从精简块中升级
该块是摘要。当某件事看起来很有趣时，智能体会调用MCP来获取特定交易对的K线或订单簿深度。大多数运行都会在没有任何升级的情况下结束——这是正确的行为。
以与工作流匹配的节奏刷新
每小时运行的智能体 → 每小时开始时重建。
每日摘要 → 每天一次。
按需助手 → 每会话一次。

不要在节奏边界之间重新使用一个块 — 过时的上下文比没有上下文更糟糕。

计算

一个每小时运行、每天16小时、每周5天、进行13个符号扫描的智能体：

方法	每次运行调用数	每周调用数
朴素（智能体从零开始拉取）	20–100（变化很大）	1,600–8,000
精简上下文 + 选择性升级	13次基准调用 + 约10–30次升级调用	1,840–5,040（稳定）

精简上下文并不总是总成本较低 — 它提供的是可预测性。你知道最坏情况下一周的调用量是多少。在Pioneer的每周6,000次调用额度下，它使得在免费套餐上运行一个轻量级的每小时智能体成为可能。

何时不使用此模式

情况	为什么精简上下文无效
单次会话研究	直接提问 — 助手会处理
总是需要深度数据的流程	网格交易机器人参数生成器已经需要K线历史记录；精简上下文是多余的
滑点敏感的执行流程	这些流程绝不应基于缓存的上下文进行推理 — 始终拉取最新数据