今、誰もがメモリ層を積み重ねようとしています。より長いコンテキスト、より良い埋め込み、セッションをまたいだ永続的な状態。私は同じことに何週間も費やしました。
しかし、実際に私のデバッグ時間をいちばん奪った失敗モードは、メモリとは無関係でした。
それがどう見えたかというと、エージェントが技術的には正しいのに――良い推論、きれいな出力――まったく別の文脈から動いているんです。誰も聞いていない質問に答える。自分のスコープを超えた行動を取る。幻覚は起こさない。ふらつく。まるで有能な人が間違った会議に入ってしまい、違う部屋だと気づかないまま貢献し始めるような感じです。
私はローカルで11個の永続エージェントを動かしています。それぞれはドメインの専門家で――存在意義が「それ一つ」になっています。メールエージェントは、あらゆるセッション、あらゆるテスト、あらゆるバグ修正が、メッセージのルーティングの話です。スタンダーズ監査人の全ては、品質チェックのためにあります。彼らは、タスク用に設定された汎用ワーカーではありません。各エージェントは、それぞれのドメインにおける運用上の履歴を何十セッションも積み重ねていて、その履歴が仕事の質を作っています。
彼らがふらつき始めたとき、最初に思ったのは誰もが思うことでした。より良いメモリ。もっとコンテキスト。それでも何も解決しませんでした。直近50セッションを完璧に思い出すエージェントでも、セッション51で「自分が誰か」を見失います。
実際に直ったのは
私はアイデンティティをメモリから完全に切り離しました。エージェントごとに3つのファイルです。
passport.json - あなたは誰か。役割、目的、原則。めったに変わりません。これはアンカーです。
local.json - 何が起きたか。ローリングするセッション履歴、重要な学び。いっぱいになったら上限とトリミングで切り詰めます。
observations.json - あなたが一緒に働く人間やエージェントについて気づいたこと。たとえば「gitエージェントは大きな差分に対して2回リトライが必要」や「技術的主張に関する品質監査が行き過ぎて補正してしまう」といった具体的なものです。エージェント自身が、実際に起きたことに基づいてこれを書き込みます。
アイデンティティを最初に読み込み、その後にメモリ、最後にobservationsです。この順序が重要です。アイデンティティファイルを先に読み込むことで、履歴が何かしら投入される前に、エージェントには安定した参照点ができます。
メールルーティングエージェントが、この最も鋭い形を学びました。アイデンティティが曖昧だと、間違った送信者からのメッセージをルーティングしてしまうんです。解決策は、より良いルーティングロジックではありませんでした。次のようにすることでした――アイデンティティが不明確なら大きく失敗する（fail loud）。誤ったアイデンティティは、沈黙よりも悪い。
ファイルだけでは足りなかった
3つのJSONファイルは役立ちましたが、数個のエージェント以上にはスケールしませんでした。実際に11個動くようになったのは、どれも「システム全体」を理解する必要がなかったからです。フックが毎セッション自動でコンテキストを注入します――プロジェクトのルール、ブランチの指示、現在の計画。1つのコマンドで、どのエージェントにも到達できます。メモリはいっぱいになったら自動アーカイブされます。計画（プラン）が作業を絞り込み、エージェントがコンテキストに自分の全履歴を抱え込まないようにします。
このシステムは失敗から学びました。エージェントはローカルのメールシステムを通して連絡します――互いにタスクを送り、ステータス更新を送り、バグ報告をします。あるエージェントが全ログをエラーについて監視します。何かを見つけたら、そのドメインを所有するエージェントにメールを送り、調査するよう起こします。エージェント同士が直し合います。メモリエージェントは、単一のロールオーバー境界条件を直すために3セッションを反復しました。出荷するたびに新しいエッジケースを観測し、改善しました。これらは冷たい部品（コールドモジュール）ではありません。壊れますし、互いに修正を手伝い、良くなっていきます。だからこそ、システムは今の場所まで到達できたのです。
11個のエージェントは不要
私のセットアップの11個のエージェントは、フレームワークそのものを維持しています。そこがリファレンス実装です。ですが、サイドプロジェクトなら1つのエージェントから始めることもできます――アイデンティティとメモリだけで、明日、自分がどこで止めたかから再開する。チームが必要？ バックエンドエージェント、フロントエンドエージェント、デザインリサーチャーを追加します。エージェント3つで同じパターン、同じコマンド。あるいは、大きなシステムなら30までスケールできます。新しいエージェントを追加するのは「1つのコマンド」と「同じ構造」です。
これで解決できないこと
この全ては、1台のマシン上でローカルに動かしています。ホスト環境でアイデンティティのふらつきが同じように見えるかどうかは分かりません。もしAPIの裏側でステートレスなエージェントを動かしているなら、あなたの環境では問題が存在しないかもしれません。
小さなプロジェクト、小さなコミュニティ、成長中です。パターン自体は小さくて盗むのに十分です――3つのJSONファイルと慣習（コンベンション）。ただし、大規模でエージェント同士を一貫させ続けるシステムが、本当の作業を生み出した部分です。
pip install aipass と、2つのコマンドで動くエージェントが手に入ります。 .trinity/ ディレクトリはアイデンティティ層です。
他の人も、エージェントのセットアップでアイデンティティをメモリから分離しようと試しましたか？ 他のアーキテクチャでも順序が重要なのか、それともこのシステムが進化していく過程の単なる副産物なのか、気になります。
[link] [comments]
