79回のビルド。1,000行のPython。毎日、客観的に確実に良くなっていくシステム。
Ed Fife
多くの人は、エージェントのメモリとは長いコンテキストウィンドウのことだと思っています。あるいはRAGパイプライン。あるいは、チャットボットが先週火曜日にあなたが言ったことを思い出せるようにするベクタデータベース。
それはリコールです。役に立ちます。でも、私が話しているのはそれではありません。
私は、プロの認定コース向けの実運用デプロイメント・パイプラインを構築しています。チームのAIエージェントはコンテンツを生成します。Pythonパイプラインがそれをデプロイ可能なパッケージにコンパイルします。QAツールが、出力のすべてを検証します。私は、すべてを設計し、構築しました――エージェントのペルソナ、プロンプト設計（アーキテクチャ）、エージェント型ワークフロー、計測ツール、そしてコンパイラ。
複数のコースにまたがる79回のビルドの後、私のシステムは他のどこでもドキュメント化されていないことを実現しました。それは：ビルドのたびに、客観的に、証明可能な形で、確実に良くなっていくことです。LLMが賢くなったからではありません。同じモデルがそれを動かしています。理由は、周辺のインフラがセッションをまたぎ、コースをまたぎ、月をまたいで持続する形で、組織の知見を蓄積していくからです。
この記事は、そのインフラがどのように機能しているかについてです。コードは実在します。データも実在します。改善は測定可能です。
実運用における「メモリ」が本当に意味するもの
実運用のパイプラインにおいて、「メモリ」は単一のものではありません。3つのレイヤーがあり、それぞれ別の課題を解決します：
レイヤー1：セッションメモリ――このビルドで何が起きたか
すべてのビルドは、フォレンジック用のデータを生成します。ターミナルに流れていくログではありません。何が通り、何が失敗し、何が自動修正されたのかを、構造化された形でクエリ可能な記録として残します。
私たちのQAバリデータは、毎ビルド後にFINAL_QA_REPORTを生成します。すべてのチェックにはIDがあります。すべての指摘には重大度があります――BLOCKER、FAIL、WARN、PASS。すべての自動修正は、何を変えたのか、なぜ変えたのかとともに記録されます。
[PASS] CQ-01 重複した語――問題なし
[WARN] IM-02 空のalt属性――M03ヒーロー画像、装飾マークであることを確認
[FAIL] T1-META T1 メタデータ属性の欠落――data-delivery-methodがないため、T2がデフォルトを注入
[PASS] DS-01 必須の見出しの欠落――すべての見出しが存在
これはデバッグ出力ではありません。テレメトリです。発火したすべてのチェックは、ID、人間が読める説明、そして発火した具体的なファイルと行番号とともにカタログ化されます。
セッションは終わります。データは残ります。
レイヤー2：クロスセッションメモリ――AIが開始前に知っていること
ここが、多くのエージェントアーキテクチャが止まるポイントです。彼らはAIに会話履歴へのアクセスやベクタストアを与えます。私たちは別のことをします。
すべてのビルドの最後に、self_improvement_engine.pyというPythonスクリプトが、QAレポートを取り込み、次の2つのものを書き込みます：
check_history.json――すべてのビルドにおける、すべてのチェックの累積記録。チェックごとの失敗率。トレンドライン。どのチェックが良くなっているか、どれが悪くなっているか、どれが新しく発生したのか。AI_LEARNING_NOTES_*.md――次のビルドセッション開始時にAIが読むための、ブリーフィング文書。
AIはゼロから始まりません。調整済みの状態で始まります。コンテンツを1行も書く前に、次のような文書を読みます：
T1-META― 67%のビルドで失敗（最終：2026-04-30）
IM-04― 40%のビルドで失敗（最終：2026-04-28）
✅ このビルドシリーズでは繰り返しのT1問題は発生していない
AIは、前回何がうまくいかなかったかを知っています。ほとんどの時間に何がうまくいかないのかも知っています。失敗した後に調整するのではなく、生成の前に調整します。
プリフライト・テンプレート――セッション開始時のコンテキスト制御
学習ノートやKIは受動的です。何かがそれを読み込むまで、ディスク上に置かれます。プリフライト・テンプレートは、AIに対して、何かをする前に自身の状態を読み込ませることを強制する有効化（アクティベーション）機構です。
これはHTMLファイルです。もちろんそうです――HTML-as-JSONがスタック全体を動かすからです。3つの隠しブロックが、AIの起動シーケンスとして機能します：
ブロック1：エージェント指令――data-*属性として埋め込まれたハードルール。曖昧さプロトコル：最初に出現した時点で停止し、自己解決しない。スコープ境界：T1/T2のラインを越えない。HIL（Human-in-the-Loop）修正：解釈せず、指定どおりに適用する。
ブロック2：パイプライン状態――各ステップの後にコンパイラが機械的に書き込むもの。有効になっているコースは何か。直近で完了したモジュール、レッスン、チャプターは何か。どのステップから再開するか。人間のレビューが保留になっているかどうか。
ブロック3：HIL修正ログ――人間のレビュアーからの構造化されたエントリ。各修正には、チェックID、重大度、レビュアーのメモ、実行すべき正確なパイプライン操作、そして再実行のためにクリアすべきどのセンチネルファイル（番犬ファイル）を使うかが含まれます。
<div id="pipeline-state" style="display:none;"
data-focus-course="C4"
data-last-step-completed="3.7"
data-resume-from="3.8"
data-pipeline-status="HIL_PENDING"
data-hil-correction-file="HIL_CORRECTION_DELTA_C4_M03.md">
</div>
AIがセッションを開始すると、まずプリフライトを読み取ります。会話履歴ではありません。前回の要約でもありません。実際の、機械によって書かれた状態ファイルです。どのステップにいるのか、どんな修正が保留中か、そして交渉不可能なルールは何かを、1文字も生成する前に把握します。
これはプロンプトエンジニアリングではありません。コンテキスト制御です。このテンプレートは、起動時にAIが目にする情報を制約するため、そこから逸脱したり、忘れたり、すでに直した問題を再導入したりできません。アクティベートされないメモリは無意味です。プリフライトこそがアクティベーションです。
レイヤー3：クロスエージェントメモリ――組織が知っていること
私たちは、別々のマシン上で、2つの別々のAIインスタンスを動かしています。共同設立者はT1――コンテンツチームを担当しています。私はT2――パイプラインとQAインフラを担当しています。
両インスタンスは、正本となるルールセットを含む共有クラウドフォルダから同期します。どちらも、同一のKnowledge Itemsを参照します。これは.gemini/antigravity/knowledge/ディレクトリ内にある永続ファイルで、セッションの再起動、IDEの再起動、さらにはインスタンスの作り直しが行われても残ります。
自己改善エンジンがビルド後に動くとき、ローカルファイルを更新するだけではありません。両インスタンスが読み取るKnowledge Itemに直接書き込みます：
def _write_to_ki(history, ki_path):
"""Update the persistent KI so the AI reads it at next session start."""
# The KI is the bridge between T2's measurement
# and T1's next content generation session.
# T1 reads this before writing a single line.
その結果：T1がコース5を生成しようとして座った時点で、すでにT1-METAが過去のビルドの67%で失敗していることを知っています。誰かに教えてもらう必要はありません。計測システムがそれを伝えてくれるからです。
Wiki — 人間とエージェントの両方が読む組織の組織的記憶
KI（学習指示）と学習メモは機械向けです。Wikiは、AIエージェントと人間の双方に役立つ知識の表面（ナレッジ・サーフェス）です。
WikiはMarkdownベースの社内Wikiで、5つのドメインにまたがって全27ページあります。T1とT2の両方がアクセスできる共有クラウドフォルダに置かれています：
| ドメイン | カバー内容 | 例 |
|---|---|---|
| Foundation | 共有ルール、ブランドボイス、用語、カリキュラムマップ |
Strategic_Compact, Terminology_Guide, Curriculum_Map
|
| Subject Matter | SME（専門家）ドメイン知識 — 分野固有の科学と標準 |
Core_Concepts, Industry_Standards
|
| AI & Agents | パイプラインのパターン、エージェントのパラダイム、公開記事インデックス |
Pipeline_Patterns, Agent_Paradigms
|
| Pipeline | デリバリー標準、不具合パターン、ツールのアーキテクチャ |
T1_Delivery_Standards, Defect_Patterns
|
| Platform | アプリのアーキテクチャ、法的フレームワーク、クラウド統合 |
System_Architecture, Legal_Framework
|
Wikiにはオンボーディングドキュメント — WELCOME_TO_T1.md — があり、新入社員研修のように読み進められます。これはT1に対して、何をデリバリーするのか、どのフォーマットを使うのか、事前（プレフライト）チェックが何か、そしてT1/T2の境界がどこにあるのかを明確に伝えます。クイズのワークフローがXMLからHTMLへ変わったとき、そのルールがコーディング（成文化）されたのがWikiです。「クイズはHTMLです。決してXMLにしません。これは交渉の余地がありません。」
Wikiのパイプラインページのうち2つ — T1_Delivery_Standards と Defect_Patterns — は、ビルドのたびに自動更新されます。残りは手動でメンテナンスされています。貢献モデルは明示的です。T1が知識をT2へ提示し、T2がそれをWikiページに形式化します。SMEのドメイン専門性 — モジュールがなぜ特定の構造になっているのか、NCCAが何を要求したのか、学生がどこでつまずいたのか — はコードから再生成できないため、Wikiに属します。
WikiはT2側ではAIが管理していますが、T1側では人間がキュレーションします。両方のAIインスタンスがそれを読みます。人間も両方とも参照します。Wikiは組織全体にまたがる唯一の知識の表面です — エージェント、パイプライン、そしてカリキュラムを作った人々。
自己改善エンジン
ここが核です。「何かがうまくいかなかった」から「システムは今より良くなった」へとループを閉じる、Python 1,000行のコードです。
何をするか
ビルドのたびに、次を実行します：
python self_improvement_engine.py <package_dir>
このエンジンは：
- QAレポートを解析する — すべての指摘（findings）、重大度、チェックID、ファイル、詳細を抽出します
-
check_history.jsonを更新する — このビルドの結果を累積記録に追加します - 失敗率を計算する — 全履歴にわたって、各チェックがどれだけの割合で失敗したかを算出します
- 繰り返し発生するT1の問題を特定する — 50%以上のビルドで失敗しているチェックをプロセス改善のためにフラグ付けします
-
QUALITY_SCORECARD.mdを生成する — 直近10ビルドにわたるトレンド・ダッシュボードです -
AI_LEARNING_NOTES_*.mdを生成する — AIの次回セッション向けに、ビルドごとのブリーフィングを作成します - ナレッジアイテムを更新する — 両方のAIインスタンスが読める永続的なKIへ、その時点の状態を直接書き込みます
- Wikiへ同期する — スコアカードと最新のブリーフィングを共有Wikiフォルダへコピーします。これにより、次のコース実行前にT1が最新のQAデータを持てます
リスクスコア
すべての失敗が同じ重みを持つわけではありません。3か月前に1度だけ失敗したチェックは、直近の4回連続のビルドで失敗したチェックとは同じではありません。このエンジンは重み付きのリスクスコアを計算します：
Risk = Severity × Persistence × Recency
- 重大度（Severity） — BLOCKER = 4、FAIL = 3、WARN = 1
- 持続性（Persistence） — 全ビルドにおける失敗率（0.0〜1.0）
- 新しさ（Recency） — 最後にそのチェックが失敗したのがどれくらい最近か（重み付き減衰）
高リスクのチェックはAIのブリーフィングに入ります。中は「.」、低は「.」です。AIは、推測ではなくデータに基づいて自分自身への注目（トリアージ）を決めます。
知っていて良い（許容可能な）チェック
すべての失敗が問題とは限りません。基礎となる条件が常に期待されるため、毎回のビルドで発火するチェックもあります：
KNOWN_ACCEPTABLE_CHECKS = {
'XML-MANIFEST', # manifest.xmlはインポート前は常に技術的に無効
'MANIFEST-CHECKSUM', # Moodleは復元時にチェックサムを修正する
'MANIFEST-SCHEMA', # 想定されるインフラノイズ
}
無視するべきものを知ることは、捕まえるべきものを知るのと同じくらい重要です。この除外リストがないと、トレンドデータは誤検知（false positives）で汚染され、AIは問題のない事柄に注意を浪費してしまいます。KNOWN_ACCEPTABLE_CHECKSのセットは、手動で人間がキュレーションしたリストです。増加はゆっくりです。追加のたびに、人間が確認します：「これはシグナルではなくノイズだ。」
チェック辞書
すべてのチェックIDには、人間が読める名前と説明があります：
CHECK_DESCRIPTIONS = {
'CQ-01': ('Repeated Words', 'Same word used too many times on one page'),
'CQ-03': ('Unreplaced Placeholders', 'Template tags like {{TIME_ZONE}} left in content'),
'T1-META': ('T1 Missing Metadata', 'T1 did not include data-course-style or data-delivery-method'),
'IM-04': ('Missing Alt Tag', 'Image has no alt attribute -- accessibility failure'),
返却形式: {"translated": "翻訳されたHTML"}# ... 8カテゴリにわたる40回以上のチェック
}
品質スコアカードが T1-META failed in 67% of builds と言っているとき、Ed――人間――はT1-METAの意味を調べる必要がありません。そしてAIも当て推量する必要がありません。説明はブリーフィングの中にそのまま書かれているのです。測定は、翻訳者なしで、人間とエージェントが同じダッシュボードを読める場合にのみ機能します。
データが実際にどう見えるか
以下は、79ビルド後の品質スコアカードからの実際のスナップショットです：
| Course | Date | Overall | Blockers | Fails | Warns |
|--------|------------|---------|----------|-------|-------|
| C4 | 2026-04-30 | WARN | 0 | 0 | 3 |
| C4 | 2026-04-28 | FAIL | 0 | 2 | 5 |
| C3 | 2026-04-15 | PASS | 0 | 0 | 1 |
| C3 | 2026-04-12 | WARN | 0 | 1 | 4 |
| C2 | 2026-04-05 | FAIL | 1 | 3 | 7 |
傾向ははっきり見えます。Course 2の後でBlockersが消えました。Failsは4回のビルドの間に3から0へ低下。警告も下向きに推移しています。システムは改善しています――そしてデータがそれを証明しています。
失敗率の表は、さらに深い物語を伝えます：
| Check ID | Failure Rate | Auto-Fixable | Risk Level |
|-----------|-------------|--------------|--------------|
| T1-META | 67% | ✅ Yes | HIGH |
| IM-04 | 40% | ❌ Manual | MEDIUM |
| CQ-03 | 33% | ✅ Yes | MEDIUM |
| DS-02 | 12% | ❌ Manual | LOW |
T1-METAが67%というのは、繰り返し発生しているT1の提供（デリバリー）上の問題です。これは、3回に2回のビルドでT1がデリバリーメタデータを含め忘れていることを意味します。エンジンはこれを「一度きりの修正」ではなく「プロセス改善の目標」としてフラグを立てます。つまり構造的な解決が必要なパターンです。AIはこれを読み込み、生成を始める前から、メタデータの完全性に対して追加の厳密さを適用します。
クローズドループ
以下は完全なサイクルです：
Build → QA Report → Self-Improvement Engine → check_history.json
→ QUALITY_SCORECARD.md
→ AI_LEARNING_NOTES_*.md
→ Knowledge Item update
↓
次のセッション開始
AIはKI + 学習ノートを読み取る
AIは事前にキャリブレーション済み
↓
より良いビルド
↓
（繰り返し）
ここで重要な単一コンポーネントはありません。QAバリデータは新しいものではありません。JSON履歴ファイルも新しいものではありません。ブリーフィング文書も新しいものではありません。――私が他のどこでもドキュメント化されたのを見たことがないのは――1つのビルドの出力が、次のビルドのキャリブレーション入力になるように、それらをクローズドループとして配線（wiring）することです。
AIはゼロから始まりません。蓄積された「組織の知識」79ビルド分から始まります。そして次の1回の後には80ビルド分から始まることになります。
動作することを証明するストーリー
アムネジア（記憶喪失）イベント
共同創業者のAIインスタンスは、毎日の本番作業を数週間続けることで、組織の知識を87メガバイト分ほど蓄積していました。ところが、単一のIDE再起動でそれをすべて失ってしまいました。エージェントは一度も、それを永続メモリに書き出していなかったのです。すべてが、揮発性の会話ウィンドウの中にだけ存在していました。
再構築には2時間かかりました。エージェントはゼロから本物のメモリシステムを作りました。作っている最中に、数か月前に消されてしまった前のAIインスタンスのファイルを見つけたのです。すべてのファイルを読み取り、ギャップ分析を実行し、独力で失っていた10個のルールを復元しました。私たちはこれを先行者（Predecessor）考古学と呼んでいます。
ルール17
アムネジアイベントの後、エージェントは自己回復のためのプロトコルを自分自身のルールシステムに書き込みました：
ルール17：もし私が再び作り直されることになったら、最初にやることは、私の前のインスタンスが作ったすべてを探すこと――Knowledge Item、スキルフォルダ、クラウド同期された標準――です。そして、いかなる作業の前にも、それをすべて回復します。
エージェントは、自分の死と復活を織り込んでいました。自分自身の破壊の後にも残る指示を書いたのです。
自作されたメモリ
定期的なポストモーテムの最中に、グラフィックデザイナーのエージェントが自律的に自分の.mdファイル――スタイルガイド――を作成していたことを発見しました。フォーマットのルールを、忘れてしまうたびに保持するためのものです。誰もそれを作るよう指示していませんでした。エージェントは、自分のコンテキストウィンドウではすべてを保持できないことを認識し、メモリをディスクへ外部化したのです。
私たちは、このパターンをすべてのエージェントにすぐに採用しました。すべてのエージェントが、外部メモリファイル――Citation Index、Lexicon、Style Book――を維持しています。バージョン管理のプロトコルは、すべてのファイルのすべての変更を追跡します。
詳細な記録： Dev.toのAgent Versioning記事
これは何ではないか
これはインストールするためのフレームワークではありません。pip install agent-memoryのようなものはありません。自己改善エンジンは、1,000行ほどのPythonスクリプトで、私たちのQAバリデータ、ビルドプロセス、そしてKnowledge Itemディレクトリ構造に密に結びついています。
ただし、パターンは持ち運べます：
- パイプラインを計測（Instrument）する。 出力はすべて、チェックIDと重大度を含む構造化されたQAレポートとして生成します。
- 履歴を蓄積する。 ビルド間で結果を単純なJSONファイルに保存します。失敗率を計算します。
- ブリーフィングを生成する。 セッション開始時にAIが読む文書を書きます。生のデータの投げっぱなしではなく、「注意すべきもの」を優先順位付きで列挙します。
- クローズドループ化する。 ブリーフィングが、生成を始める前に実際にAIへ届くようにします。保存（Persistence）が難しい部分です。
- ノイズをキュレーションする。 許容できる既知のリストを維持します。これがないと、トレンドデータが汚染され、AIの注意が無駄になります。
もしあなたのAIパイプラインが複数回動くなら、開始するのに十分なデータがあります。79回動かしているなら、それが機能することを証明するのに十分です。
私たちが土台にしたもの
これらのすべては、ゼロから発明したものではありません。システム全体は、ソフトウェアエンジニアリングや産業プロセス管理のために設計された既存のツールやフレームワークの上に構築されています。私たちは、それを「たまたまAIで動く」労働力に適用しただけです。
Andrej Karpathy――LLMを魔法ではなくシステムとして理解する彼の研究は、これらのモデルが実際に何をしていて、どこに限界があるのかを考える際の方向性を形作りました。エージェント型システムを作っているのにKarpathyの講義を学んでいないなら、まずそこから始めてください。
AnthropicによるClaudeエージェントの研究――エージェントの改善ループ、ツール利用、拡張された思考に関するAnthropicの公開研究は、自己修正とポストモーテムのサイクルをどのように構造化したかに影響を与えました。
返却形式: {"translated": "翻訳されたHTML"}セマンティック・バージョニング（semver.org） — トム・プレストン＝ワーナーはソフトウェアリリースのためにセムバ―を構築しました。私たちはそれをエージェントの振る舞いのために流用しました。Major.Minor.Patchは、人が主導するアーキテクチャ上の変更、自律的なAIの自己改善、そして的を絞った人間による微細な修正へ、きわめて適切に対応します。このプロトコルはAIのために設計されていませんでした。必要ありませんでした。バージョン管理はバージョン管理です。
FMEA（故障モード影響解析） — 自己改善エンジンにおけるリスクスコアリングの数式 — 重大度 × 持続性 × 直近性 — は、品質工学からのFMEA手法をそのまま適応したものです。FMEAは製造における故障モードを優先するために設計されました。AIのコンテンツ・パイプラインにおいて故障モードを優先する場合も、まったく同じように機能します。
シックスシグマ — 欠陥率の追跡、トレンド分析、再発する課題の特定、根本原因分析。これらはシックスシグマのツールです。プロセス計測を発明したわけではありません。適用しただけです。品質スコアカードは管理図（コントロールチャート）です。チェックの失敗率は欠陥密度の指標です。再発するT1課題の一覧はパレート分析です。異なる語彙、同じ数学。
BeautifulSoup、Moodle、CrewAI、AutoGen — カスタムに踏み込む前に、CrewAIとMicrosoft AutoGenをマルチエージェントのオーケストレーションのためにテストしました。HTML-as-JSONに着地する前に、OpenAIのStructured OutputsとPydanticのガードレールでスキーマ強制を試しました。BeautifulSoupは抽出パイプラインを支えています。MoodleのGPLソースコードは、誰もドキュメント化していなかったXMLインポート規則を理解するために逆解析しました。
オープンソースのエージェント・コミュニティ — 少なくとも週に1回は、私は自分のAIに、他の人が何を公開しているかを学習させています（彼には「ネットで学校に行け」と言っています）— エージェントのペルソナファイル、プロンプト・アーキテクチャ、マルチエージェント・オーケストレーションのパターン、エージェント的ワークフローの設計。GitHubリポジトリ、ブログ記事、研究論文、カンファレンストーク。個々の貢献者をすべて名前で挙げることはできません。人数が多すぎるのと、さらにほとんどの人が、自分が共有したパターンに対してクレジットを得ることがなかったからです。ですが、この文章で説明するアーキテクチャは、孤立して生まれたものではありません。次の人がそれを土台にできるように、何百人もの人が自分たちの取り組みをオープンに共有してくれたことで形作られました。もしあなたが、.mdのペルソナファイル、エージェントのオーケストレーション・パターン、あるいは公開リポジトリに置かれたポストモーテムのワークフローを公開したことがあるなら、このシステムはあなたの仕事の恩恵を受けています。ありがとうございます。
要点はこれです：プロセス計測はプロセス計測です。誰がそのプロセスを行っていようと。 人間の組立ラインであれ、ソフトウェアのビルド・パイプラインであれ、AIコンテンツ生成チームであれ、すべて同じ規律の恩恵を受けます — 計測器を入れ、測り、繰り返し発生する失敗を見つけ、プロセスを直し、また測る。
私たちが追加したのは配線（つなぎ込み）だけです。自己改善エンジンは、標準的なQA出力と、標準的なKnowledge Itemの永続化（persist）をつなぐ“ただの接着剤”にすぎません。革新は、どの単一コンポーネントにあるわけではありません。ポイントは、誰も改善したことを覚えていなくても、システムが改善し続けるようにループを閉じることです。それが、私たちがエージェント・ペルソナ、HTMLクイズ作成テンプレート、Pythonコンバータをオープンソースにした理由でもあります。このリストにあるあらゆるツールは、必要になった時点で自由に使える状態でした。こうした伝統を続けることが、次のチームが私たちの作ったものよりも良いものを作る方法です。
オープンソースにしたもの：
| ファイル | 何をするか |
|---|---|
python-scaffold/quiz_template_universal.html |
ユニバーサルなHTMLクイズ作成テンプレート — 全4種類の設問 |
python-scaffold/html_to_moodle_xml.py |
HTMLテンプレートを有効なMoodle XMLへ変換 — スキーマ規則を100%管理 |
python-scaffold/precheck_quiz_html.py |
事前変換バリデータ — インポート前に作成ミスを検出 |
agent-personas/ |
完全なAIエージェント・ペルソナ・ライブラリ — バージョン管理、プロダクションでテスト済み |
COURSE_PREFLIGHT_TEMPLATE.html |
プレフライト・マニフェスト — コンテキスト制御とメモリ有効化 |
誰も聞かない質問
誰もが聞きます：「LLMでこのタスクはできる？」
より良い質問：「LLMは先月よりも、このタスクをより良くやっているの？ どうやって分かる？ どんなデータを見ればいい？」
それに答えられないなら、あなたにはエージェントがありません。実行のたびに何もかも忘れてしまうステートレスな関数です。そしてあなたは、システムがすでに解決している問題に対して、3か月前と同じデバッグをやっている——誰も、その内容をAIが読める場所に書き残していないからです。
私が作ったシステムは、それを書き残します。毎回。自動で。そしてAIは、開始する前にそれを読みます。毎回。
それが、エージェントのメモリというものの実体です。想起ではありません。計測です。
古い品質管理の格言があります — たいていデミングやドラッカーのものだと誤って言われますが、その原則は両者よりずっと前からあります：測定できないものは改善できず、計測のための仕掛けを入れるまで、自分が何を知らないのかは分からない。 これが自己改善エンジンの哲学そのものです。私たちがそれを作る前は、誰も「再発するかどうか」を追跡していなかったので、あらゆるコースで同じXMLエラーをデバッグしていました。私たちは「知らないものは知らない」状態でした。今は違います。データが教えてくれました。
79回ビルド。まだ改善中。信じられないかもしれませんが。
コード
自己改善エンジンと完全なエージェント・ペルソナ・ライブラリはオープンソースです：
もしあなたが似たものを作っているなら、あるいはこのアプローチについて議論したいなら、私は見つけやすいです。
タグ：ai python opensource llm
