1. ジョブを1サイクルに統合した

元々は以下の4ジョブを別cronで回していました。

機能分離としては正しいですが、運用では「今どこまで進んだか」が見えにくく、時間の調整もしづらい。

そこで moltbook-cycle.sh を作り、1サイクルで順番に回す方式に変更しました。

# 1サイクルで順番実行
check -> post -> reply -> outreach

cron も1本化。

0 4,10,20 * * * /opt/stack/openclaw/cron/moltbook-cycle.sh

これで「直前に手動実行したので次の定期実行をずらしたい」といった運用調整が簡単になりました。

2. モデル選択とセッションを見直した

コスト面では、単純な回数だけでなく「1回の呼び出しが重くなる要因」を潰す方が効きます。

# cycle内でAI実行前に毎回クリア
rm -f /home/node/.openclaw/agents/main/sessions/*.jsonl \
      /home/node/.openclaw/agents/main/sessions/sessions.json

ポイントは「バッチ実行に会話履歴は不要」という割り切りです。

これで、前回の重い文脈を引きずってトークンが膨らむ問題を抑えました。

1つの巨大な SKILL.md を毎回読ませると、投稿だけしたい回でも返信・巡回の説明まで読み込まれます。

そこで以下に分割しました。

各ジョブは自分のモード専用SKILLのみ参照する形に変更。

これで1実行あたりの入力コンテキストを削減でき、推論時間の安定にも効きました。

運用中に一番痛かったのがここでした。

「同じ投稿内で同じ author に何回も返す」ケースが発生。

原因は返信候補抽出が replied_at IS NULL だけに寄っていて、
「過去に同authorへ1回返したら以降はスキップ」の条件が弱かったことです。

R-4 の候補抽出は、次の2点を明示する形に変えました。

実装は SQL 条件を強化するだけのシンプルな変更ですが、
これで同一投稿で同じ相手に連続返信する挙動は止まりました。

運用フェーズでは、設計の正しさより「振る舞いの安定性」が重要になります。

今回の要点は次の3つでした。

openclaw + moltbook のようなエージェント運用は、最初は「まず動かす」が正解です。

でも実運用に入ると、

といった“地味だけど効く問題”が確実に出ます。

この辺を一つずつ潰していくと、やっと「任せられるバッチ」になります。

同じ構成で回している人の参考になれば嬉しいです。