Agents SDK v0.30.0 の PiHarness が Pi 1.4 に、上げると Pi 1.3 へ戻せない

Agents SDK v0.30.0 で、PiHarness が Pi 1.4 上で動くようになった。上げる前に知っておくべきことは一つある。Pi 1.4 は Durable Object の SQLite データベースにあるセッション保存領域を、Pi 1.3 では開けないスキーマに移行する。公式の changelog は、このアップグレードを越えてデプロイをロールバックできないと書いている。

PiHarness を使っていない Agents SDK の利用者には、この一方通行は関係しない。PiHarness で動かしているエージェントがあるなら、v0.30.0 のデプロイは「失敗したら前のバージョンに戻す」という通常の逃げ道がない変更として扱うことになる。

一度デプロイすると前のスキーマには戻らない

移行の対象は、オブジェクトの SQLite に保存された Pi のセッションだ。新しいコードがスキーマを書き換えた後に旧バージョンのコードを戻しても、Pi 1.3 はそのセッションを開けない。changelog の表現は「a deployment cannot roll back past this upgrade」で、段階的に戻す手段や移行を巻き戻す方法には触れていない。

Pi 自身の破壊的変更について、Cloudflare の告知は Pi Durable 1.4.0 の changelog を参照するよう案内している。SDK 側のアップグレード手順は Agents SDK v0.30.0 の changelog に段階ごとに載っている、とも書かれている。戻せない以上、本番に入れる前にこの二つを読み、ステージング環境で既存セッションが新しいスキーマで読めることを確かめておくのが順当だろう。ただし、検証の方法そのものは告知に書かれていない。

復旧まわりの挙動は四か所で変わる

戻せないという代償と引き換えに、v0.30.0 はエビクション、クラッシュ、ストレージエラーからの復旧を改善したと説明されている。告知に書かれた前後の差を並べると次のようになる。

場面	これまでの挙動	v0.30.0 / Pi 1.4
タスクがスリープ中（モデル再試行のバックオフなど）	Durable Object がメモリに残り続ける	期限まで hibernation できる
オブジェクトを繰り返しクラッシュさせるタスク	再起動を延々と繰り返す	parked になり、再起動しない
ストレージエラーの後	オブジェクトが再起動するまで全呼び出しが失敗	PiHarness が Pi を開き直す
途中で切れた・止まったモデルストリーム	ターンが失敗	一時的なエラーとして扱われ、Pi がターンを再試行

出典：Cloudflare Changelog「Agents SDK now supports the latest Pi 1.4 release」（2026年10月22日）

onWake を受け取るのはハーネスのファクトリ

hibernation を可能にしているのは、Pi 1.4 で追加された onWake コールバックだ。PiHarness はこれをハーネスのファクトリに渡す。タスクがスリープしている間、Durable Object はメモリに留まらず、タスクの期限が来るまで hibernation できる。自前のファクトリでこのコールバックをどう扱うべきかは、告知の範囲では示されていない。

parked になったタスクは自動では戻らない

クラッシュを繰り返すタスクは parked の状態で止まり、pending() では parked として表示される。再実行するのは session.retry() だ。裏返すと、これまで再起動ループで「動いているように見えていた」タスクが、上げた後は止まったまま残りうる。監視で pending() を見ているなら、parked という状態が新たに現れることを前提にしておきたい。

ストレージエラーの後は、PiHarness が Pi を開き直す。起床用のジョブは、失敗したステップを捨てずにバックオフ付きで再試行するようになった。モデル側では agents/models/pi-ai が、途中で切れたストリームや無応答になったストリームを一時的なエラーとして報告する。その結果、Pi はターンを失敗にせず再試行する。

上げる順番の考え方

PiHarness のアップグレードで運用側が押さえる点は、次の三つに絞れる。

• Agents SDK v0.30.0 の changelog にあるアップグレード手順と、Pi Durable 1.4.0 の changelog にある Pi 自身の破壊的変更を、デプロイ前に読む
• 本番の Durable Object に一度入れたら Pi 1.3 には戻れないので、ロールバックを前提にしたリリース手順を見直す
• 上げた後は、pending() に parked のタスクが出ていないかを確認し、必要なら session.retry() で再実行する

復旧の改善はどれも、これまで失敗やメモリ常駐で終わっていた場面を扱うものだ。ただ、得られるのはスキーマを戻せなくなった後になる。ここが判断の中心になる。