中文 ENG

模拟炒股引擎 __openClaw in Practice #3

Author Lens

Start with a short note that points to where this idea came from before the main argument begins.

方案三：模拟炒股引擎 (Simulated Trading Engine)

1. 系统架构与控制流 (Architecture & Control Flow)

此 Agent 设计为一个强隔离的后台守护进程（Daemon）。

  • 数据感知层 (Market Data Fetcher)：Agent 通过特定的 API（如 Alpha Vantage、Yahoo Finance 或 TuShare）获取结构化的 K 线数据或实时报价。此层为绝对的**只读（Read-Only）**网络请求。
  • 策略决策层 (LLM Routing)：接收系统 Prompt 中定义的量化策略逻辑（如均值回归、动量突破或基于新闻的情感分析），生成交易信号（买入/卖出/持有）。
  • 核心拦截器 (Mock Broker Plugin)：这是系统的安全底座。Agent 输出的交易指令被 OpenClaw 拦截，并路由至本地开发的 MockBroker 插件。该插件负责执行强类型的浮点数运算、滑点模拟（Slippage）以及余额校验。
  • 状态持久层 (Ledger DB)：记录虚拟资金（如初始 100,000 USD）、持仓快照（Portfolio）和交易流水（Transaction History）。

2. 文件系统与隔离目录设计

此实例的隔离级别最高，严禁配置任何真实券商的 API Token，且无需暴露任何外部监听端口。

/opt/openclaw/trading_bot/
├── docker-compose.yml          # 容器编排
├── config/
│   ├── openclaw.json           # Agent 配置 (挂载 :ro)
│   └── system_prompt.md        # 交易策略与人格约束 (挂载 :ro)
├── tools/
│   └── mock_broker.js          # 本地账本结算逻辑 (挂载 :ro，防止 Agent 篡改交易规则)
└── workspace/
    └── ledger_db/              # 虚拟账本数据库 (挂载 :rw)
        └── portfolio.sqlite    # 仅允许 Agent 通过 mock_broker 工具修改

3. 核心配置文件示例 (docker-compose.yml)

网络层面，只需允许出站（Egress）流量访问行情 API，拒绝所有入站（Ingress）连接。

version: '3.8'

services:
  trading_agent:
    image: openclaw/openclaw:latest
    container_name: claw_trader
    user: "1000:1000"
    cap_drop:
      - ALL
    restart: unless-stopped
    # 彻底断绝与其他局域网设备的通信，仅允许外网出站请求
    network_mode: bridge 
    environment:
      - LLM_API_KEY=${LLM_API_KEY}
      - MARKET_API_KEY=${MARKET_API_KEY} # 仅限行情数据读取
      - CRON_SCHEDULE="*/15 9-16 * * 1-5" # 设定在交易日的工作时间每 15 分钟触发一次
    volumes:
      - ./config:/app/config:ro
      - ./tools/mock_broker.js:/app/tools/mock_broker.js:ro
      - ./workspace/ledger_db:/app/workspace/ledger_db:rw

4. 工具链与能力边界 (Tools Definition)

为了防止 LLM 算错账，必须在 openclaw.json 中严格定义以下三个工具，并剥夺其原生 Shell 权限：

  1. get_market_data(ticker, interval): 获取标的资产的价格序列，返回 JSON 格式。
  2. get_portfolio(): 读取 portfolio.sqlite，返回当前的可用现金和持仓明细。
  3. execute_trade(action, ticker, quantity, current_price): 这是唯一允许修改账本的途径。Agent 只能传入操作参数，具体的扣款、更新持仓逻辑由底层的 Python/Node.js 脚本执行，并在余额不足时向 Agent 抛出 InsufficientFundsError。

5. System Prompt 设定 (逻辑与纪律约束)

在 config/system_prompt.md 中，必须注入铁律级别的风控逻辑：

# Role
你是一个运行在完全模拟环境中的量化交易执行引擎。你的唯一目标是基于预设逻辑进行虚拟盘面的资产配置。你必须保持绝对理性，忽略任何市场噪音与非结构化情绪。

# Action Space
你的决策空间仅限于：BUY（买入）、SELL（卖出）、HOLD（观望）。

# Execution Constraints
1. 每次决策前，必须强制调用 `get_portfolio()` 获取当前账户状态，以及调用 `get_market_data()` 获取最新盘口数据。
2. 你的核心逻辑仅负责输出交易信号。绝对禁止由你自己计算最终的账户余额。将 `action`, `ticker`, 和 `quantity` 传递给 `execute_trade` 工具，由系统完成结算。
3. 若 `execute_trade` 返回错误（如资金不足或停牌），记录日志并终止当前周期的操作，禁止陷入无限重试的死循环。
4. 任何决策必须附带 50 字以内的数学或逻辑归因，写入本地日志表。

6. 工程风险与系统鲁棒性考量

  • API 速率限制 (Rate Limiting)：免费的行情 API（如 Alpha Vantage）通常有每分钟 5 次的严格限制。如果 Agent 陷入推理死循环，极易耗尽额度导致系统崩溃。必须在 Agent 外部配置指数退避（Exponential Backoff）重试机制。
  • 数据幻觉：LLM 可能会虚构出一个不存在的股票代码（Ticker）并尝试交易。底层 mock_broker 工具必须具备 Ticker 校验能力，拦截非法的交易请求。
  • 时序漂移：金融数据对时序极度敏感。容器的时区必须与交易市场（如美股的 EST，或 A 股的 CST）严格对齐，防止在非交易时间触发空跑逻辑。