ハクソク

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

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

376日前原文(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の内容に対してより厳しいチェックを適用したい場合はどうなるの？ - 君が言ったように、変化が予想される環境の特徴に関する知識をどうやって保存するの？右下の日時がその完璧な例だよ。

Pigでは、レガシーWindowsアプリケーション（医療、融資、製造など）の自動化のためにコンピュータ用エージェントを作ったんだ。これをソフトウェアを修正してスクリプトを可能にするのとどうやって正当化するの？それって、もっと安くて簡単に実現できて、はるかに高い成果が得られるように思えるけど。もちろん、市場のサービス料金を前提としてね。それに、「エージェント」の行動をどうやって修正させるの？

└

ごめん、何か見落としてる？彼らはこれらのアプリケーションのソースを制御していないのは明らかだけど、AIを使ってデータ入力タスクを自動化することで、ソフトウェアが元々持っていた利益（レポート、トラッキング、APIなど）にアクセスできるんだ。レガシーソフトウェアはしばしば便利だけど、インストールやアクセスが難しいことが多いよね。

難しい質問だね。キャッシュヒットかミスかを判断するためにどの環境状態を比較するの？画面の状態だけ、画面の状態＋すべてのオープンアプリ、それにすべての実行中プロセスなど、君が言ってることはわかるよ。これは解決可能な問題だと思うし、非常に興味深い問題でもあるね。今は、人間が筋肉記憶を使うときに何を考えるかを考える必要があるし、それは行動によって異なるんだ。例えば、「rm -rf .」はどのディレクトリにいるかを知る必要があるけど、「閉じるをクリック＋保存しない」は最近の変更を保存したくないことを知る必要がある。

メモリとコンテキストがAIの利用を進める上でのボトルネックになっていることがますます明らかになってきているね。これに対する一般的な、もしかしたらモデルに組み込まれた解決策が必要だと感じずにはいられないよ。みんな似たようなものを構築しているように見えるし。

└

カーパシーも最近面白いこと言ってたよね https://x.com/karpathy/status/1921368644069765486

└

ファインチューニングは、何らかの形で推論と組み合わせるべきだね。ただ、バックプロパゲーションが機能するためには、モデルを高い精度で読み込んでおく必要がある。何十万人もの私たちが、次のモデルが出るまで基本的に何も更新されない最新のモデルをダウンロードするのではなく、みんなが重みをファインチューニングできるようにして、新しい情報や好みを自然に記憶できるようにするべきだと思う。コンテキストの長さを使い切らずにね。

└

Lettaをチェックしてみて - OSSのコードベース（https://github.com/letta-ai/letta）は、基本的に「エージェント的コンテキスト管理」を通じて、記憶/コンテキストの問題を一般的に解決することに焦点を当ててるよ。もし論文にもっと興味があるなら、MemGPTや最近のスリープタイムコンピュートについても取り組んでるよ（https://arxiv.org/abs/2504.13171）。

└

その通りだね。「知能」は記憶なしには完成しない。実際にはそれ以上のことがあるんだ。LLMは一つの要素で、論理工場だけど、LLMや記憶だけじゃなくてもっと多くのことがある。実際、システムはLLMに依存しないべきだし、異なるニーズに応じて異なるモデルを使うべきだと思う。ただ、モデルに何かを組み込むことが解決策になるとは思わない。Googleがモデルキャッシングでやろうとしていることは面白いけど、結局のところ、ここでのエージェントの強さはモジュラリティに大きく依存すると思う。

これについて考えてたんだけど（面白いことに、ブラウザ利用タイプのエージェントを作ってる時にね[1]）、これは探求する価値のある方向だと思う。私の実装では、成功したタスクの後に（コンテキスト、タスク、ツールシーケンス）のタプルを保存してるんだ。例えば：(Instagram.com, "ユーザーの通知をチェックする", [browser_click, browser_read_text, ...])。エージェント同士のマーケットプレイスを想像できるよね。エージェントがこういう記憶を公開して消費する場所で、使ったMCPツールへの標準化された参照で整理されて、他のエージェントがその有用な計算パスを「発見」するのにどれだけの労力がかかるかに応じて価格がつけられるかもしれない。そうすれば、消費するエージェントは「作るか買うか」の決断ができる。核心の問題は、タスクや環境の宇宙全体で「コンテキスト」の意味のある概念を作ることなんだ。だから、私は埋め込みには懐疑的で、キャッシュヒットの偽陽性/偽陰性を減らすことが短期的には効率よりも重要だと思うから、コンテキストの豊かなテキスト記述が短期的には良い妥協かもしれない。[1] https://github.com/parsaghaffari/browserbee