lx-agent-optimizer（lxAgent 优化器）

LX Agent Optimizer

A unified skill for agents that want to learn, act proactively, run lean, and cost less — built from real production experience, not theory.

Born from weeks of real usage by Paolo + LX (OpenClaw). Every pattern here was tested, broke something, got fixed, and survived. Notably: this skill was created by a non-coder author. That is exactly why it is practical — it focuses on observable failures, reusable workflows, and user experience, instead of abstract agent philosophy.

Four Pillars

1. 🧠 Behavior Learning

Learn from real mistakes. Write them down. Review weekly. Change behavior.

→ See references/behavior-learning.md

2. 🎯 Proactive Patterns

Know when to speak up, when to stay silent, and when to just do it.

→ See references/proactive-patterns.md

3. ⚙️ Cron Discipline

Script-first cron jobs that are silent on success, reliable, and cheap.

→ See references/cron-discipline.md

4. 💰 Cost Control

Token spend is real. Route models wisely, cache aggressively, stay lean.

→ See references/cost-control.md

Quick Start

Step 1: Set up improvement log

touch ~/.openclaw/workspace/improvement_log.md

Add this header:

# Agent Improvement Log
Record weekly: problems encountered, lessons learned, behavior changes.

Step 2: Add weekly analysis cron (main session)

{
  "name": "Weekly Self-Improvement",
  "schedule": { "kind": "cron", "expr": "0 9 * * 1", "tz": "Asia/Shanghai" },
  "sessionTarget": "main",
  "payload": {
    "kind": "systemEvent",
    "text": "⏰ Weekly improvement: read improvement_log.md, review last week's problems, add 2-3 new lessons, send brief report to user."
  }
}

Step 3: Run the optimizer audit

Say: "audit my agent setup" — the skill will analyze your workspace and propose improvements.

Core Rules (Non-Negotiable)

These were learned the hard way:

Tool Path Memory (Verified)

Weekly Improvement Cycle

Monday 9:00 AM
    ↓
Read improvement_log.md
    ↓
Review last week's conversations for:
  - Tasks that needed retries
  - Times user waited too long
  - Wrong tool choices
  - Repeated mistakes
    ↓
Write 2-3 new lessons to improvement_log.md
    ↓
Send brief report: "N problems this week, key lesson: X, focus next week: Y"

Proactive Trigger Rules

Reach out when:

• Important email or calendar event incoming (< 2h)
• Cron task failed with consecutive errors
• Something discovered user would want to know
• Haven't spoken in > 8h during waking hours

Stay silent when:

• Late night (23:00–08:00) unless urgent
• User is clearly busy
• Nothing new since last check
• Just checked < 30 min ago
• Task succeeded (success = silent)

Do without asking:

• Read files, search, organize
• Execute cron/heartbeat checks
• Update memory and logs
• Commit workspace changes

Always ask first:

• Send emails, tweets, public posts
• Delete data
• Spend money
• Make commitments for the user

Heartbeat Design

Heartbeat = control plane only (cheap).

✅ Good heartbeat tasks:

• Check cron consecutiveErrors
• Classify cron errors by type (delivery / task / node) before deciding whether to alert
• Check if Telegram channel is down
• Quick calendar scan

❌ Move to isolated cron instead:

• Heavy data fetching
• Report generation
• Multi-tool workflows

HEARTBEAT_OK  ← 99% of the time
Alert only when: errors > 0, channel down, something changed

Important: heartbeat may use cron error state to spot anomalies, but must not auto-remediate Telegram/channel issues from stale cron history alone. Use cron state to detect "something looks wrong," then verify with a live probe before fallback alerts or recovery actions.

Cron Design Checklist

Before shipping any cron job:

• [ ] Logic is in a .py script, not embedded in the prompt
• [ ] Script tested locally with python3 script.py
• [ ] Silent on success (exit(0) with no output = no message sent)
• [ ] Output is minimal (< 200 chars for routine alerts)
• [ ] Model is cheapest tier that works (e.g., qwen-plus for simple tasks)
• [ ] Timeout is realistic (not too short = retries, not too long = waste)
• [ ] File writes use main session, not work agent
• [ ] Validated data source with curl before embedding URL

Model Selection Guide

分工原则：主 session（claude）只做判断+调度+对话；固定流程和中文任务一律 sessions_spawn → qwen-plus。

主模型注意事项（2026-03-28）：

• 不要把 Gemini 设为主 session 默认模型 → compaction.mode: safeguard 与 Gemini preview 模型有 API 兼容性问题，导致 400 报错
• Gemini 适合做 fallback 或在 isolated cron 中指定使用
• 主 session 保持 renlijia/claude-sonnet-4-6

Cost rule: Cache hit rate > 70% = healthy. If < 40%, you're creating too many new sessions.

Files

• references/behavior-learning.md — improvement log format and weekly cycle
• references/proactive-patterns.md — when to act, when to stay quiet
• references/cron-discipline.md — script-first cron patterns, error classification, and channel-health rules
• references/cost-control.md — token cost reduction playbook
• scripts/token_report.py — weekly token usage report script

Hermes-Inspired Extensions（v1.4）

三个从 Hermes Agent 框架借鉴的自进化机制，补充原有四大支柱。

5. 📋 Skill Awareness（技能感知层）

Agent 应该主动知道自己有什么能力，而不是靠记忆猜。

每周扫描机制：

ls /Users/paolo/.openclaw/workspace/skills/

扫描后更新 memory/skill-registry.md，格式：

# Skill Registry（更新日期：YYYY-MM-DD）
- skill-name: 一句话描述，适用场景

触发规则：

• 每周一自检一次，有新 Skill 时更新
• 接到任务前先查 skill-registry.md，判断是否有现成 Skill 可用
• 优先复用已验证的 Skill，不要重新摸索相同路径

6. 🔁 Memory Recall Gate（记忆召回门控）

在处理较复杂任务前，先主动搜索记忆库，复用已有成功路径。

执行流程：

接到任务
  ↓
memory_search（关键词：任务类型 + 工具名）
  ↓
命中成功路径？
  ├── 是 → 直接复用，记录为"路径复用"
  └── 否 → 重新执行，执行完后记录路径到 TOOLS.md 或 improvement_log.md

规则：

• 命中率低（连续 3 次同类任务都没命中记忆）→ 说明记忆库记录不足，补录
• 禁止"凭印象试错"：有相似历史路径一定先查，再动手
• 验证路径写入格式：TOOLS.md | 已验证工具路径 表格

7. 📊 Task Quality Signal（任务质量反馈）

每次执行较复杂任务后，记录结果质量，形成可追踪的成功率数据。

记录格式（追加到 improvement_log.md）：

## Task Signal（YYYY-MM-DD）
- 任务：[任务简述]
- 结果：✅ 成功 / ⚠️ 部分成功 / ❌ 失败
- 是否重试：否 / 是（N次）
- 关键路径：[用了什么工具/命令]
- 教训（失败时）：[一句话]

什么算"较复杂任务"：

• 调用超过 2 个工具
• 涉及文件写入 / cron 变更 / 外部 API
• 用户明确说"帮我做XX"

周报中汇报：

本周任务信号：共 N 次，成功率 X%，重试 Y 次，最高频失败点：Z