ハクソク

世界を動かす技術を、日本語で。

HNに表示: Muscle-Mem、AIエージェントのための行動キャッシュ

2025年5月15日原文(github.com)

概要

  • Muscle Memory (muscle-mem) はAIエージェント向けの 動作キャッシュSDK です。
  • エージェントの ツール呼び出しパターン を記録し、同じタスク再発時に 再現実行 することが特徴です。
  • 繰り返し作業の効率化、コスト削減、LLM依存の低減を目的としています。
  • Python SDK として、既存エージェントに簡単に組み込むことが可能です。
  • キャッシュ検証 が安全な自動化の鍵となります。

Muscle Memory（muscle-mem）：AIエージェントのための行動キャッシュSDK

概要・目的

  • Muscle Memory（muscle-mem） は、AIエージェントがタスク解決時に使用した ツール呼び出しパターン を記録・再生するSDKであることを提案。
  • 既知タスク の場合は記録済みの動作を 決定論的に再実行 し、 未知や例外ケース では通常のエージェントモードにフォールバックする設計を採用。
  • LLMコールを排除 し、 繰り返し作業の高速化・コスト削減・一貫性向上 を実現することを目指す提案。
  • RPA（ロボティック・プロセス・オートメーション） とエージェントの長所を組み合わせ、 現場の実用性 を重視した設計思想を強調。
  • オープンソース として公開されており、 フィードバック歓迎 であることを強調。

仕組みと特徴

  • muscle-memはエージェントフレームワークではなく、既存エージェントをラップするエンジン であることを確認。
  • タスク実行時の動作（ツール呼び出し）をキャッシュ化 し、次回以降の同一状況で キャッシュヒット時は記録済みの経路を再現 することを実現。
  • キャッシュミス時はエージェント本体に処理を委譲 し、 新しい動作パターンをキャッシュに追加 することを明示。
  • キャッシュ検証（Cache Validation）が安全な自動化の要 であり、 ツールごとに適切な環境特徴量の設計 が重要であることを強調。
  • Python SDK としてpip経由で 簡単にインストール可能 であることを案内。

基本APIと使い方

  • Engineクラス がエージェントをラップし、 タスク実行時のキャッシュ管理・判定・再現 を担当することを確認。
  • @engine.functionデコレータ で関数型ツールを、 @engine.methodデコレータ でメソッド型ツールを計測・記録することが可能であることを説明。
  • self（インスタンス変数）はシリアライズ不可 のため、 engine.set_context() で再現時に明示的に注入する必要があることを注意。
  • engine.finalize() で依存関係が揃っているかの確認・最終化を推奨。

キャッシュ検証（Cache Validation）の仕組み

  • Checkオブジェクト は、 キャッシュの有効性検証 に使われる基本単位であることを説明。
  • Checkはcapture（特徴量抽出）とcompare（比較）コールバックで構成 され、 環境が一致しているか判定 することを提案。
    • 例：helloツールの呼び出し時刻を特徴量とし、1秒以内ならキャッシュ有効とみなす実装例を提示。
  • @engine.function(pre_check=Check(...)) のように、各ツールごとに 事前/事後チェックを付与 することで柔軟な検証が可能であることを強調。

具体例・コードスニペット

  • dataclassによる特徴量Tの定義、 キャプチャ・比較関数の実装、 ツールデコレータによる計測、 エージェントのラップ・実行 までの一連の流れを提示。
  • キャッシュヒット/ミスの挙動 や sleepによるキャッシュ破壊テスト も含め、 実運用を想定した確認方法 を案内。
  • より実用的な実装例 として、 GitHubリポジトリのcomputer-use agent例 を参照することを推奨。

コール・トゥ・アクション

  • Muscle Mem Discord への参加、 GitHubリポジトリのテスト・スター付与 を呼びかける提案。
  • フィードバック歓迎、今後の発展に向けた コミュニティ参加 を奨励。

補足：開発者視点・背景

  • Pig.devのErik氏 によるプロジェクト紹介であり、 RPAとAIエージェントの現場課題 から着想を得たことを説明。
  • RPAは大半のケースで十分だが、例外処理が苦手、 エージェントは柔軟だがコスト高・遅い という現実的課題を共有。
  • Muscle Memはスクリプト的自動化とエージェント的柔軟性を両立 し、 現場の実用性・コスト意識 を重視した設計思想を強調。
  • ブログ記事やリポジトリの深掘り推奨、今後の開発・議論への参加を呼びかける提案。
  • 詳細・最新情報は 公式GitHubリポジトリ および ブログ記事 で随時確認することを推奨。

Hackerたちの意見

これらの軌道が、単に再生するだけじゃなくて、モデルを自動的に微調整するために使われるのを見込んでる？そうすれば、似たようなワークフローも改善されるかもしれないね。

└

学習された行動の明示的な軌道は、強化学習の手法、特に深層Q学習に比べて人間が理解しやすくデバッグしやすいと思うから、モデルの使用を避けるのが理想的だね。でも、彼らにも役割があると思う。どんな風になるかは分からないけど、最近友達からもらったこのトピックについてのブレインストーミングを再利用するよ。「クリックする場所を理解するためにLLMに頼る代わりに、クリックエリア自体がトークンになる。そしてクリックもトークンで、目的もトークンで、出力は何でもいい。つまり、クリックパスは「保存」されるんじゃなくて、LAM/LLMのトレーニングに埋め込まれている。」最終的にどうなるにしても、仕事ができて、デバッグ可能で拡張性があって、ユーザーが複雑さにぶつかったときにすぐに追い出されない限り、Muscle Memの一部になってくれると嬉しいな。

これ、俺がMCPの「プロンプト」に期待してたことの、もっとパワフルなバージョンに見えるんだけど、合ってるかな？俺としては、繰り返しのタスクの摩擦を減らしたいんだ。例えば、新しいGraphQLクエリを作る必要がよくあって、それには例のクエリコレクションを更新したり、基本的な新しい統合テストを作ったりする必要がある。もしMCPでアクセスできるプロンプトがあれば、エージェントがそのリクエストを処理するための指示があることに気づいてくれることを期待してたんだ。

└

ある意味、Muscle Memの軌道は、他のツールの連続使用を組み合わせた新しい「メタツール」なんだ。俺が考えてた一つの形は、モデルに与えられるかMCPサーバーから提示される動的に進化するツール仕様のリストだったけど、あまりワクワクしなかったんだ。- それでもツールを選ぶためにループ内にモデルが必要になるし、全体の軌道に対して一度だけ選ぶことになる - Muscle Memoryシステムの厄介な課題、つまり連続キャッシュ検証を見逃してる。環境は軌道の途中で予期せず変わることがあるから、システムは適応する必要がある。だから、どんな場合でも、Muscle Memのチェック抽象化のようなものが必要なんだ。

アイデアが大好き！キャッシュヒットがあるかどうかを定義するのが問題だと思うけど、「エージェント」はざっくりとした定義で、タスクは基本的に何でも含まれるからね。

└

同意するよ、キャッシュ検証はMuscle Memの唯一の関心事だね。要するに、十分に一般的なタスクと環境に対して、エンジンは過去の環境のデータベースとユーザー提供のフィルタ関数でキャッシュ検証を行うだけなんだ。

ミニマルなアプローチと一般的な用途に焦点を当ててるのが好きだよ。もし俺の理解が正しければ、エンジンは可能な限りシンプルな方法で軌道をキャッシュしてるから、もしキャッシュされた軌道a-b-cがあって、c-b-dに遭遇したら、「部分的な」キャッシュヒットを得ることはできないよね？これを考えてると、エンジンは安全な部分ヒットを判断できるようにするために、かなり複雑になる必要があると思う。基本的には、このアプローチがかなりノイズの多い環境にどれだけ適用できるかを想像しようとしてるんだ。

└

これについてはデザインでしばらく悩んでいて、方向性を固定するような決定を急ぎたくなかったんだ。サブトラジェクトリーをサポートしたいと思ってる。実際、このシステムの絶対に素晴らしい機能は、大きなトラジェクトリーを小さくて繰り返し使われるサブトラジェクトリーに分解することだと思う。trychroma.comのJeffは、エージェントエンジニアリングはソフトウェアエンジニアリングよりも工業エンジニアリングに近いとよく話していて、私も同意するよ。このシステムのために私が書いた元の仕様の一部には、「コンパクター」と呼ぶコンポーネントが含まれていて、これは学習したスキルを修正・圧縮するためのバックグラウンドエージェントプロセスなんだ。Lettaのスリープタイムエージェントに似てるよ：https://docs.letta.com/guides/agents/sleep-time-agents これに関しては、私がローンチブログで述べた「隠れた非決定性はなし」というデザインバリューに反するのではないかと心配してる。コンパクターからトラジェクトリーのパラメータ化まで、バックグラウンドエージェントに投げることができることはたくさんあるけど、観測性やデバッグ可能性の観点からはリスキーな領域だよね。シンプルさのために、私はすべてのトラジェクトリーを異なるものとして扱うことにしたんだ。たとえその一部が冗長でもね。キャッシュされたトラジェクトリーが途中でチェックに失敗した場合、そこから進むエージェントは自分の部分的なトラジェクトリーを作るだけなんだ。それが同じ名前のタスクのトラジェクトリーと呼ぶべきか、それともタスク回復として注釈を付けるべきかはまだ不明だね。時間が経てばキャッシュヒット率を上げることはできるし、最悪の場合、エージェントは冗長な作業をするだけで、結局それが現状だから。

すごくクールなコンセプトだね！v0やlovable、boltなどが提案したプロンプトでこんなのをやってくれたらいいのに。テンプレートを選んで、3-5分待って生成されて、すごく洗練されたプロトタイプか、エラーが出るコードの山にランダムに放り出されるのは、本当にひどいユーザー体験だよね。どちらの場合でも、次に何をすればいいのか全く分からないし。

これがうまくいくかはわからないな。コンピュータ用に似たようなことを試したこともあるけど、埋め込みを比較してキャッシュを検証するのはすごく曖昧で、明確な閾値がないんだ。例えば、右下の日時が変わるとか、データベースを持つアプリだと、埋め込みが恣意的に変わることもあるしね。それに、君が言ったように、どのステップでもこれをやらなきゃいけないから、いつ壊れるかわからない。信頼性のある検証ができるとは思えないな。もしモデルが安ければ、別の安いLLMを使ってスクリーンショットを比較したり、プレイライトやAPIスクリプトをその場で調整することもできるかも。結局、かなり違うアプローチを書いたんだけど、意外とうまくいったよ。解決策はたくさんありそうだし、これがどうなるのか興味津々。個人的には、埋め込みアプローチだけでは足りないと思うけど、内部でどうやってそれなりのレートを達成したかについて話すのは大歓迎だよ。この分野は確実にすごく期待できる。

└

こんにちは、個人プロジェクトに取り組んでるんだ。このアプローチについて詳しく知りたいな。

└

経験を共有してくれてありがとう！これを機に、どうやってこれを実現したのか話せたら嬉しいな。このシステムの設計に役立てたいから。erik [at] pig.devに連絡してね。CLIP埋め込みのCUA例での使用は、CUAの実装決定であって、エンジン自体のコアではないことを明確にしておくね。これは、Capture() -> TとCompare(current: T, candidate: T) -> boolのペアとしてCheckを設計する際に非常に意図的だったんだ。TはDBにシリアライズできる任意のデータ型で、比較はその汎用型Tに対してユーザー定義で行われるんだ。より完全なCUAの例では、OCRされたテキストやアクセシビリティツリーのデータなどの特徴を保存することになるよ。ここでいくつかの未解決の質問を挙げるね： - パラメータ化。厳密な座標をキャッシュして再利用するのではなく、ツールコールの引数がトップレベルのプロンプトから派生した場合、あるいはさらに難しいことに、前のツールコールの結果として派生した場合はどうなるの？コンピュータ使用のケースでは、特定の要素のx-pathが必要かもしれないけど、その要素は「コンパイル時に知られている」わけではなく、途中で派生するものなんだ。 - スタック比較フィルターはどうなる？つまり、ユーザーが最初にコサイン距離でフィルタリングして、その後OCRの内容に対してより厳しいチェックを適用したい場合はどうなるの？ - 君が言ったように、変化が予想される環境の特徴に関する知識をどうやって保存するの？右下の日時がその完璧な例だよ。

Hacker Newsで議論の続きを見る