SongRyeon Core - LLMが書いた発言とコードが検証した情報を分離するローカルエージェントランタイム実験

こんにちは。コーディングを学びながらAIエージェントランタイムを自分で実験しているジョンフです。

SongRyeon Coreは、「LLMが述べた判断」と「コードが実際に確認した事実」を分離して扱う、小さなローカル優先の(agent runtime)実験です。

最近LLMベースのエージェントを作っていると、次のような問題がよく起きると感じました。

• LLMが推測した内容をシステム上の事実のように見せてしまう
• コードが作ったfallbackやヒューリスティックが、LLMの判断のように混ざってしまう
• いくつの文書を読んだのか、どの実行が実際に起きたのかが、画面ごとに違って見える
• 最終回答が内部ランタイム状態と食い違う

そこでこのプロジェクトでは、情報を大きく3つに分けて扱います。

• 絶対情報: コード/trace/schema/tool resultで確認可能な値
• 相対情報: 1つの絶対情報に対応するLLMの判断
• 混合情報: 複数のsource bundleに基づくLLMの判断

現在はまだ小さな練習版ですが、次のような構成を実験しています。

• node_0 memory supplier
• node_1 router
• L loop
• node_3 reporter
• node_4 verifier
• smoke-testベースの回帰検証
• runtime terminal/final rendererの誠実性チェック

目標は「すごいデモ」よりも、AIエージェントがどんな根拠で何を述べたのかをできるだけ隠さない、小さなランタイムを作ることです。

まだ私自身がコーディングを学んでいる途中なので、粗い部分が多いです。
構造、README、テスト、用語定義、agent runtime設計についてフィードバックをいただけると本当にありがたいです。

GitHub:
https://github.com/Junghoo-developer/SongRyeon

[anima]

補足です。

現在のSongRyeon Coreは、Webサービスの形態というより、ローカルCLI / smoke-test中心のランタイム実験です。

すぐに確認できるのは、READMEの実行方法と:

• python -m compileall songryeon_core main.py
• python main.py smoke-test

です。

特にフィードバックをいただきたい点は次のとおりです。

• 絶対情報 / 相対情報 / 混合情報の区分が設計上納得できるか
• LLMの判断と code-verified fact を分ける方式が、実際のagent runtimeに有用そうか
• READMEで初見の人が理解しにくい部分がどこか

まだ学習中のプロジェクトなので、粗い部分が多いです。気軽に突っ込んでいただけるとありがたいです。