デイリーAIダイジェスト — 2026-10-31
Hacker News シグナル
AIエージェントの群れをMinecraftとMindustryで動かしてみた
YCombinator Labsは、創発的な協調行動の検証環境として、MinecraftおよびMindustry（リアルタイムの工場・タワーディフェンスゲーム）の2つのゲーム内にマルチエージェントシステムを展開しました。技術的な観点からの注目点は、合成ベンチマークではなく、ゲーム環境をグラウンドされた敵対的評価基盤として活用している点にあります。
Minecraftでは、エージェントの知覚はローカルなボクセル状態とインベントリに限定されており、明示的なメッセージングではなく共有ワールド状態を介した協調が強いられます。Mindustryでは、エージェントはリソースパイプラインと防衛構造物を時間的プレッシャーの下で管理する必要があり、部分観測下での計画能力が試されます。この群れアーキテクチャは、状態同期のための共有ブラックボードを持ち、タスクを専門化されたサブエージェント（採取、建設、戦闘）に振り分ける薄いオーケストレーション層を使用しています。
論文中の主要なエンジニアリング上の観察点は以下の通りです。tool-use APIを備えたLLMベースのエージェントは、コンテキストウィンドウが3次元的な位置の履歴を自然には符号化しないため、逐次的な空間タスクにおいて予想より低いパフォーマンスを示しました。チームは各エージェントに圧縮された「memory tile」――直近のアクションと周辺ブロック状態の構造化サマリー――を与えることで、生のトランスクリプトコンテキストと比較して一貫性が大幅に向上することを発見しました。Mindustryは報酬シグナルが疎で遅延があるためMinecraftより難しいことが判明し、エージェントはリソース収集に過度に特化し、防衛を軽視した結果、連鎖的な失敗を引き起こすことが頻繁に見られました。
群れの協調モデルは本質的に階層的タスクネットワークであり、リーフレベルにLLMノードを配置する構造です。学習済みの通信プロトコルは存在せず、エージェントは共有ゲーム状態を変更するかブラックボードへの書き込みによってのみ通信します。これは、創発的通信の複雑さを避けるための意図的に制約された設計であり、協調帯域幅を犠牲にしています。
より広い文脈で検証されているのは、現在のLLMエージェントが動的な再計画を処理できるかどうかという問いであり、明示的な再プロンプトのトリガーなしにはほぼ対応できないことが示されました。これは有用なnullな結果と言えます。
Source: https://labs.ycombinator.com/projects/games/index.html
Dayjob: Tax – AIエージェントを50の専門的な税務課題で評価する
Surge HQは、実際の専門的なシナリオから抽出した50の税務申告タスクからなるベンチマークを構築しました。対象は、連邦個人申告書（1040）、Schedule C自営業、減価償却の取り戻し、パッシブ・アクティビティ・ロス・ルール、AMT計算、および複数州への按分（apportionment）です。各タスクは、資格を持つ税務専門家が、数値の正確性・正しいフォームの選択・推論の質を網羅するルーブリックに基づいて採点しました。
この方法論が注目に値する理由は、多肢選択式の近道を避けている点にあります。タスクでは、エージェントが完成したフォームや詳細なステップバイステップの計算を出力することが求められており、MCQ形式では隠れてしまう中間推論のエラーが露わになります。採点者は最終的な数値だけでなく、エージェントが適用すべきIRC条項を正しく特定し、適切な計算経路を適用できているかどうかも確認しました。
テストされたモデル（GPT-4o、Claude 3.5 Sonnet、Gemini 1.5 Pro、その他）の結果として、トップのモデルは全体精度で60〜70%台のスコアを記録しましたが、フェーズアウトが相互作用するシナリオ（例：ロスIRAの所得制限と控除制限の組み合わせ）や複数年にわたるキャリーフォワードの追跡については、スコアが大幅に低下しました。また、すべてのモデルが州レベルのコンフォーミティに関する問い（特定の項目について州が連邦の取り扱いに従うかどうか）に苦戦しました。これは、管轄区域固有の法令の検索が必要であり、学習データに十分に含まれていないためです。
構造的な知見として、コード実行（算術にPythonを使用）を活用したエージェントは、数値タスクにおいて純粋な推論のみのエージェントを上回りましたが、分類タスク（例：「この費用はセクション162または212の下で控除可能か？」）ではコード実行は有効ではありませんでした。このベンチマークはこれらの失敗モードを明示的に区別しており、専門分野の評価における有用な設計パターンといえます。
限界として、50タスクというサンプルサイズは少なく、エッジケースにおける採点者間のばらつきが報告されていない点が挙げられます。これは、専門家レベルの採点を謳うベンチマークとして重要な問題です。
Source: https://surgehq.ai/blog/dayjob-tax
階層的ネットワークのスケーリング
Cartesiaの記事では、階層的シーケンスモデルに関する研究が紹介されており、標準的なtransformerの二次コストを伴うattentionを使わずに、マルチスケールの時間的構造をどのように処理するかという問題として定式化されています。本記事は「Part 1」であり、完全な技術的開示ではなくアーキテクチャの動機付けに焦点を当てていますが、核心的な主張は、異なる有効受容野を持つstate-space model (SSM) 層を積み重ねること——時間的階層に類似した構成——によって、局所的な音素・トークンレベルのパターンと長距離の談話レベルの依存関係の両方を捉えられるというものです。
技術的な議論は、単一の再帰的時間スケールを持つフラットなSSM（Mambaなど）が、再帰 h_t = \lambda h_{t-1} + B x_t における減衰パラメータ \lambda を通じて、高速な適応と長期記憶のトレードオフを強いられるという観察に基づいています。階層的なアーキテクチャでは、代わりに異なる有効時間スケールで複数のSSM層を動作させ、粗いスケールの層がより細かいスケールの層の出力を圧縮した表現に対して機能します。これはdilated convolutionのアイデアを反映していますが、学習された再帰的状態に適用されています。
実用的な動機はバイトレベルまたはサブワードに依存しないモデリングにあります。生のバイト列を処理する場合、モデルは低レベルの符号化パターン（マルチバイトのUTF-8シーケンス、BPEに類似した構造）と高レベルの意味的連続性を同時に認識する必要があります。バイトレベルでのフラットな再帰は、シーケンス長が爆発的に増大し、数千ステップにわたるgradient flowが劣化するため、困難を抱えます。
Cartesiaはこれを、トークン化を完全に排除する方向への道筋として位置付けており、バイトストリームを処理しながら階層的SSMが圧縮と推論の両方を担うことを目指しています。アーキテクチャ的にはもっともらしい提案ですが、本記事ではスケーリングカーブやablationを示すには至っていません。長文脈タスクにおいて階層的SSMがtransformerのベースラインに匹敵または凌駕するという主張は述べられているものの、ここでは実証されておらず、おそらくフォローアップ記事で扱われるものと思われます。
Source: https://www.cartesia.ai/blog/from-tokens-to-bytes-part-1
Mistral Large 4の重みを公開
Mistral Large 4は、Mistral Research License（非商用）のもとで公開された128BパラメータのMoEモデルです。このアーキテクチャはforward passあたり約17Bパラメータを活性化し、トークンあたりの計算量をdenseな17Bモデルに近い水準に保ちながら、知識の格納には128Bパラメータ全体の容量を活用します。
主な報告数値は以下の通りです：MMLUで81.2%、HumanEvalで67.4%を達成し、複数のcodingベンチマークでGPT-4oおよびClaude 3.5 Sonnetと競合するレベルにあります。本モデルは128Kトークンのcontext windowをサポートしており、この活性化パラメータ規模のMoEにおいて効率的なサービングは容易ではありません。MistralはLarge 3と比較して、instruction followingおよびfunction callの信頼性が向上したと述べています。
MoEの設計はtop-Kルーティング（このクラスではK=2 expertsがトークンごとに活性化されるのが標準的）と学習済みのルーティング重みを採用しています。Mistralは完全なアーキテクチャ仕様を公開していませんが、活性化パラメータ数と総パラメータ数は、共有のattention layerを持つ約16B規模のexpertを8つ用いた構成、あるいはより細粒度のexpert構成と整合しています。
公開戦略も注目に値します：重みはHugging FaceおよびMistral API経由で利用可能ですが、research licenseが商用利用を制限しており、Llama 3のような真にオープンなモデルとは異なる位置づけになっています。HNのディスカッションでは、permissiveなライセンスを伴わない「open weights」が何らかの意味でオープンソースと言えるのかについて活発な議論が交わされました――これはこの分野で繰り返し浮上し、未解決のまま続いている緊張関係です。
inference engineeringの観点からは、17Bのactive parametersを持つ128B MoEはint4 quantizationにより2x H100上でサービング可能であり、denseな70B以上のモデルよりもアクセスしやすい構成です。また、sparse activation patternにより、同等の容量を持つdenseモデルと比べてトークンあたりのメモリ帯域のボトルネックも軽減されます。
Source: https://mistral.ai/news/mistral-large-4-oss/
Show HN: 約1GBのQweightで動作するNintendo
このプロジェクトは、NESエミュレータのトレースから抽出した状態-行動シーケンスを用いて訓練することで、NESゲームのロジックをエミュレートするようにQwen（1.5Bまたは7Bのバリアント — READMEでは重量子化された小規模ベースを示唆する約1GBの重みファイルを使用）をfine-tuningしたものです。フレームワークは「NESformer」と名付けられており、モデルはゲーム状態のシーケンス（RAMスナップショットの構造化テキストまたはトークンエンコーディングとして表現）にコントローラ入力を加えて、次のゲーム状態を予測します。
技術的なアプローチはピクセルレベルの映像生成ではありません。代わりに、NES RAMの状態（2KBのRAM、スプライトテーブル、レジスタ値）を構造化トークンとしてエンコードし、シーケンス長を管理可能にするとともに予測ターゲットを明確に定義しています。モデルはこれらの状態シーケンスに対するnext-token predictionを通じて、遷移関数 s_{t+1} = f(s_t, a_t) を暗黙的に学習します。
これが興味深い理由はいくつかあります。第一に、小規模なLLMがデータから決定論的な有限状態機械的なシステムを学習できることを示しており、これはRLにおける学習済みシミュレータに対して示唆を与えます。第二に、圧縮の度合いが際立っています：NESエミュレータのソースコードは数万行に及びますが、モデルは同等の振る舞いを重みに凝縮しています。第三に、失敗モードが診断的です — モデルは訓練データでの出現が少ない状況（レアなゲームイベント、特定のエッジケース）でゲーム状態をhallucinateしますが、これはまさにルックアップベースのエミュレータが正確に動作する場面です。
制限は重大です：この「エミュレータ」は訓練したゲームにしか機能せず、未見のゲームへの汎化性能は低く、タイミング精度（サイクル単位の正確なエミュレーション）については主張されていません。また、音声やピクセルレンダリングも扱えません — これは状態遷移モデルであり、完全なエミュレータではありません。それでも、LLMをゲーム環境モデルとして使用するためのクリーンな概念実証となっています。
Source: https://github.com/dbreunig/nesformer
Agent SDK
CursorはAgent SDKをリリースしました。これはIDE拡張機能やサードパーティツール向けに、内部のエージェントインフラをプログラマブルなインターフェースとして公開するものです。コアの抽象化は型付きtool-callプロトコルです。エージェントは型付き関数シグネチャとして機能を宣言し、オーケストレーションレイヤーがルーティング、コンテキスト管理、リトライロジックを処理します。
SDKは3つの主要なプリミティブを提供します。第一に、エージェントが呼び出すことのできる入出力スキーマ（JSON SchemaまたはTypeScriptの型）を持つToolインターフェースです。これは標準的なもので、OpenAIのfunction-calling APIに倣っています。第二に、エディタの状態を保持するContextオブジェクトです。これにはオープンされているファイル、カーソル位置、診断情報、最近の編集履歴、ターミナル出力が含まれます。これが非自明な部分です。エディタのコンテキストをコンテキストウィンドウを溢れさせることなく忠実にエンコードするには、注意深い要約・切り捨てロジックが必要であり、Cursorはこれを明らかにプロダクト化しています。第三に、エージェントが完全なファイルの書き直しではなくdiffとして部分的な編集を出力できるストリーミングレスポンスプロトコルです。これによりインクリメンタルな適用やユーザーによる中断が可能になります。
興味深いエンジニアリング上の課題は状態の一貫性です。エージェントが複数ファイルにわたる一連の編集を適用する場合、後続のtool callが整合性を保つためには、各中間状態をContextオブジェクトに反映させる必要があります。Cursorのアプローチは、エージェントが書き込むシャドウワークスペースを維持し、ユーザーが参照するワークスペースは明示的なコミット時にのみ更新するというものです。これにより、部分的な失敗が生じた際にエージェントがワーキングツリーを破損することを防ぎます。
SDKは主に、エディタ状態との緊密な統合を必要とする特化型コーディングエージェントの構築に有用です。例えば、リファクタリングをトリガーできるlinterや、修正を提案できるテストランナーなどです。これは汎用のエージェントフレームワークではなく、Cursor/VSCode拡張モデルと強く結合しています。より広い意味での重要性は、IDEベンダーがエージェントオーケストレーションを、後付けのプラグインとしてではなくコアインフラとして扱い始めているという点にあります。
Source: https://cursor.com/blog/agent-sdk
Sanstun: RustによるサンズI/O、並列フレンドリーなWireGuard実装
FirezoneはサンズI/Oアーキテクチャパターンを用いて、RustでWireGuardライブラリを実装しました。このパターンでは、ライブラリ自身はI/Oを一切行わず、純粋にバイトバッファを操作し、実行すべきI/Oを記述した構造化された出力を返します。呼び出し元のアプリケーションがすべてのソケットとタイマーを所有し、パケットをライブラリに渡すと、復号されたペイロードか、「このエンドポイントにこのハンドシェイク開始メッセージを送れ」といった指示が返ってきます。
この設計の動機は2つあります。第一に、テスト容易性です。サンズI/Oのコードは、実際のソケットやネットワークインターフェースを必要とせず、合成されたバイト列だけで完全に駆動できるため、ユニットテストが非常に簡単になります。第二に、より興味深い点として、並列性があります。ライブラリが内部的なI/O状態を持たないため、複数のスレッドがそれぞれ独自の TunnelState インスタンスを保持でき、スレッド間で共有されるミュータブルな状態が存在しません。これにより、異なるピア接続を独立したスレッドで処理するシャーデッドアーキテクチャが、同期オーバーヘッドなしに実現できます。
WireGuardの暗号ステートマシンには自然な並列性の境界があります。ハンドシェイクの開始と応答は、X25519とChaCha20-Poly1305を用いたNoise IKによる一時鍵交換を伴うため、ピアごとにシリアライズする必要がありますが、異なるピアからのデータパケットは独立しています。サンズI/O設計はこの並列性を明示的にします。つまり、呼び出し元が操作のスケジューリングを決定し、ライブラリはシングルスレッドの TunnelState 内での安全性を保証します。
この実装は、WireGuardのcookieメカニズム（DoS緩和のため）、ローミング（ピアIPの変更）、タイマー管理（キープアライブ、ハンドシェイクの有効期限）をすべてサンズI/Oインターフェースを通じて処理します。タイマー状態はライブラリから返される明示的なデッドラインとして管理され、呼び出し元がその時刻にコールバックをスケジューリングする責任を持ちます。
wireguard-go やカーネル実装と比較すると、統合インターフェースの単純さをデプロイの柔軟性と引き換えにしています。これは特に、Firezone のアクセスプロキシのようなアプリケーションにおけるユーザー空間WireGuardに有用です。
Source: https://www.firezone.dev/blog/introducing-sanstun
LLM Voice
Martin Fowlerのblikポストは、LLMを基盤とした音声インターフェースの現状を、ユーザーエクスペリエンスの観点からではなく、エンジニアリング上のトレードオフに焦点を当てて解説しています。中心的な技術的懸念はレイテンシの合成です。音声パイプラインはASR（音声認識）、LLM inference、TTS（テキスト読み上げ）を連鎖させており、エンドツーエンドのレイテンシは三者の合計にネットワークのラウンドトリップを加えたものになります。彼は、会話音声における応答性の知覚閾値がおよそ300msであり、三つの独立したサービスを逐次処理することでこれを達成するのは困難だと指摘しています。
現在展開されているアーキテクチャ上の解決策は、二つのアプローチでこの問題に対処しています。第一は、各ステージでのストリーミングです。ASRは部分的なトランスクリプトを逐次出力し、LLMは部分的な入力が得られ次第トークンを生成し（投機的または中断生成）、TTSはLLMの応答が完了する前に合成を開始します。これにより、連続するステージのレイテンシを重複させることができます。第二は、エンドツーエンドの音声モデル（GPT-4oのネイティブオーディオモードやMoshiなど）であり、三段階のパイプラインを音声トークンに直接作用する単一モデルに統合することで、カスケード全体を排除します。
Fowlerは、エンドツーエンドモデルが別種の問題を引き起こすことを指摘しています。すなわち、制御が難しくなること（独立したASRであればログ記録やフィルタリングが可能なテキストトランスクリプトが得られますが、統合モデルではモデレーションが困難になります）、inferenceに必要なメモリが増加すること、そしてクリーンなテキストに対する高品質なTTSと比較して劣る音声アーティファクトが生じる場合があることです。
このポストでは、割り込み処理という真のエンジニアリング課題にも言及しています。人間の会話では、聞き手は発話の途中で割り込むことができます。ストリーミングTTSパイプラインはキャンセルをサポートする必要があり、そのためには部分的に合成された音声バッファをフラッシュし、LLMに生成停止を通知することが必要です。現在のほとんどの本番システムはこれをうまく処理できておらず、割り込みを無視するか、知覚できるほどのギャップが生じるかのいずれかです。
注目の新しいリポジトリ
onehumanbeing/esp32-iphone-agent
7ドルのESP32マイクロコントローラ、AirPlayスクリーンミラーリング、およびUSB HIDエミュレーションを組み合わせて構築された、iPhoneの自律制御システムです。ESP32はUSB HIDペリフェラルとして動作し、Lightning/USB-Cポートを経由してiPhoneに直接タッチおよびキーボードイベントを注入します。ジェイルブレイク不要、デベロッパー証明書不要、Macも不要です。ビジョン入力は、iPhoneのAirPlayストリームをサブスクライブすることで取得します（デバイスがレシーバーとして動作するESP32へブロードキャストする形式）。これにより、AIモデルは画面のライブフレームバッファを利用できます。OpenAI互換のビジョンAPIであれば、ESP32を通じてHIDコマンドを返すことが可能です。制御ループは実質的に次のようになっています：AirPlayフレームをキャプチャし、JPEGとしてエンコードし、visionエンドポイントにPOSTし、JSONアクション（タップ x,y／スワイプ／キー）をパースし、HIDレポートを送信する、という流れです。HIDイベントはハードウェア層で注入されるため、物理的な入力と区別がつかず、アクセシビリティAPIやMDMプロファイルも不要です。主な制約はAirPlayのレイテンシ（通常100〜300ミリ秒）と、解像度を制限するESP32の限られたRAMです。これはロックされたハードウェア上でのモバイルGUI agentの実用的なベースラインであり、同じアーキテクチャはUSB HIDを受け付けかつAirPlay送信が可能な任意のデバイスにも応用可能です。
Source: https://github.com/onehumanbeing/esp32-iphone-agent
mw00/project-maya
非常に大規模な mixture-of-experts モデルをターゲットとするセルフホスト型の inference スタックです。対象モデルは GLM-5.3-Flash（321B MoE）、DeepSeek-V4.1-Flash-1017（748B MoE）、および MiniMax-M3.1-Flash（428B MoE）です。本システムは、tensor-parallel および expert-parallel sharding を備えたカスタム inference エンジン、モデルサーバー、Web ダッシュボード、そして OpenAI 互換および Anthropic 互換の REST エンドポイントを包括しています。NVIDIA または AMD ハードウェア上の Linux または Windows 環境において、1〜16 GPU 間でメモリフットプリントを削減するための量子化ツールが同梱されています。このエンジンは、パラメータセット全体を一度に VRAM にオフロードすることなく expert ルーティングを処理します。これは、単一モデルの dense 相当のサイズがほとんどのマルチ GPU セットアップを超えてしまう場合に実用上不可欠な機能です。OpenAI/Anthropic 互換レイヤーにより、これらの SDK を使用した既存のコードは変更不要です。ダッシュボードでは、リクエストごとのレイテンシ、デバイスごとの GPU 使用率、およびアクティブな expert の負荷分散が確認できます。API レート制限やデータの外部送信に関する制約なしに、フロンティアスケールの MoE モデルの再現可能なプライベート inference を必要とする研究者にとって、本スタックはこれらの特定チェックポイントに対して現在利用可能な最も完全なオープンスタックです。
Source: https://github.com/mw00/project-maya
pgrundev/pgx
PGXはRustで書かれた軽量なPostgresプロトコル互換データベースエンジンであり、単一のOSプロセス内で数千の完全に分離されたデータベースインスタンスを起動できるよう設計されています。中心的な着想は、AIエージェントが中間推論・コード実行サンドボックス・セッションごとの状態管理のためにスクラッチデータベースを頻繁に必要とする場面において、インスタンスごとにフルPostgresプロセスをforkするオーバーヘッドは現実的でないという点にあります。PGXは代わりに、共有バッファプールとWALマネージャ上で複数インスタンスを多重化し、プロセスレベルではなくカタログおよび名前空間レベルで分離を実現します。Rust実装はGCポーズなしでメモリ安全性を提供しており、何百もの並行エージェントセッションがそれぞれDDLを発行する状況において重要です。ワイヤプロトコルはPostgres互換であるため、既存のpsycopg2・asyncpg・libpqクライアントはいずれも無修正で動作します。永続化はオプションであり、エフェメラルなインスタンスはマイクロ秒単位で生成・破棄できます。これはフルPostgres（重量級、DBごとに1プロセス）とSQLite（ネットワークプロトコルなし、真のマルチユーザ分離なし）の間のギャップを埋めるものです。主要なユースケースは、プロセス内ハッシュマップと同等のコストで確保・解放できる構造化ストレージを必要とするエージェントワークフローです。
Source: https://github.com/pgrundev/pgx
storytold/figcraft
FigCraftは、協調的なUIデザインおよびプロトタイピングワークフロー——Figmaが占める機能領域——を、完全にRustで書いたクリーンルーム再実装です。ここでいう「クリーンルーム」とは、Figmaのソースコードも、リバースエンジニアリングによる内部情報も使用せず、設計上の判断はすべて協調デザインツールの観察可能な動作から独立して導出されたことを意味します。レンダリング層は、ベクタープリミティブ、制約、およびコンポーネントインスタンスを持つ構造化されたシーングラフ上で動作します。リアルタイム協調編集はCRDTsによって処理され、中央の競合解決サーバーなしで並行編集が可能です。プロトタイピングのトランジションとインタラクション状態は、シーングラフ上の状態機械としてエンコードされています。Rustで実装されているため、コアエンジンはブラウザ配信向けにWebAssemblyへコンパイルすることも、ネイティブ実行することも可能であり、Electronのオーバーヘッドを回避できます。オープンソースモデルにより、デザイン資産がプロプライエタリなSaaSを経由することにIPの観点から懸念を持つスタジオにとって、監査可能な選択肢となります。ローンチ直後に3,900以上のスターを獲得したことは、セルフホスト可能でオフライン対応のデザインツールへの明確な需要を示しています。主な未解決課題は、フォントレンダリングとプラグインエコシステムにおける機能同等性であり、いずれも容易に再現できるものではありません。
Source: https://github.com/storytold/figcraft
wangzan101/Mika
Mikaは、Android向けのオンデバイスAIエージェントであり、ユーザーの代わりにアプリやブラウザを自律的に操作してマルチステップのタスクを完了します。AndroidのAccessibility Service APIを使用してUIツリーを読み取り、タップ・スクロール・テキスト入力を注入することで、スクリーンショットOCRのみに頼るのではなく、画面状態への構造的なアクセスを実現しています。エージェントのループは以下の通りです：自然言語によるタスクを受け取り、現在のaccessibility treeを構造化された観測として抽出し、次のアクションをオンデバイスまたはローカルネットワーク上のLLMに問い合わせ、accessibility injectionを介して実行し、終了条件を満たすまで繰り返します。オンデバイス（またはローカルネットワークモデル）で動作させることで、プライベートな画面内容をクラウドAPIに送信することを避けられるため、銀行取引・メッセージング・個人カレンダーなどに関わるタスクで重要な意味を持ちます。このアーキテクチャはGUIエージェント研究（例：AppAgent、AndroidWorldのbaseline）に類似していますが、中国語インターフェースを備えたコンシューマー向けアプリケーションとしてパッケージ化されています。主な制限事項としては、一部のサンドボックス化されたシステムUI要素の内部ではAccessibility Serviceが動作できないことと、小規模なオンデバイスモデルと高性能なリモートモデルとの間にレイテンシ・品質のトレードオフが存在することが挙げられます。
Source: https://github.com/wangzan101/Mika
Harvil1/codeAgent
CodeAgentは、透明性が高く検査可能なツールループを中心に構築された、ターミナル常駐型のコーディングエージェントです。リポジトリを軽量なインデックス（ファイルツリー、シンボル参照、grepスタイルの検索）として構築することで取り込み、その後LLMプランナーを使って複数ステップの編集を計画します。このプランナーはread_file、write_file、run_command、run_testsという一連のツール呼び出しを出力します。各ステップはターミナルにログ記録されるため、ユーザーは処理を観察・中断することが可能です。ツールループは明示的に拡張可能であり、新しいツールはJSON schemaとともに登録され、プランナーはそのschemaを用いてツールの呼び出しタイミングを判断します。これは標準的なfunction-callingパターンに従っています。ブラックボックス型エージェントとは異なり、計画のトレースは人間が読める形式であるため、エージェントが誤った方向へ進んだ際の診断が容易です。各書き込みサイクルの後にテストが実行され、失敗はプランナーへの観測値としてフィードバックされることで、編集・実行・観測のクローズドループが形成されます。このプロジェクトはエージェントレベルでは言語非依存であり、言語固有の動作（ビルドコマンド、テストランナー）はプロジェクトごとに設定されます。主要な未解決のエンジニアリング課題は、リポジトリがモデルのcontext windowを超えて大きくなった際のコンテキスト管理です。
Source: https://github.com/Harvil1/codeAgent
outcrawlai/scout
ScoutはOutcrawlが開発したオープンソースのブラウザエージェントフレームワークです。ヘッドレスまたはヘッドありのブラウザ（PlaywrightによるChromium）を制御し、自然言語で記述されたゴールをLLM駆動のアクションループで実行するタスクインターフェースを提供します。エージェントはDOMおよび/またはスクリーンショットを観察し、アクション（クリック、入力、ナビゲート、抽出）を選択して反復処理を行います。Scoutがシンプルなスクレイピングツールと一線を画すのは、静的なCSSセレクタではなくステートフルな推論を必要とする動的なSPA、ログインフロー、複数ページにまたがるワークフローを処理できる点です。アーキテクチャはブラウザコントローラ（Python/Playwright）、観察レイヤ（DOMのシリアライズまたはビジョン）、ポリシー（アクションの構造化出力を伴うLLMコール）を分離しています。このモジュール化された構成により、異なるビジョンモデルや観察戦略への差し替えが容易です。オープンソースかつセルフホスト型であるため、商用のブラウザ利用サービスのようなAPIコールごとのコストが発生しません。主なユースケースとしては、APIを持たないサイトからの自動データ収集、自然言語によるエンドツーエンドテスト、Webエージェントの信頼性に関する研究が挙げられます。主な制限事項はCAPTCHAおよび積極的なボット検出への対処です。
Source: https://github.com/outcrawlai/scout
haydenschmitty/floorplan
Floorplanは、Claude または Codex（OpenAI）に問い合わせることで、コードベースのナビゲート可能な平易な英語マップを生成します。依存関係グラフに各モジュールの責務を人間が読みやすい形式でアノテーションを付けることで実現しています。ワークフローとしては、まず静的解析によってimport/callグラフを抽出し、それをチャンク単位でLLMに渡して、モジュールごとの簡潔なサマリを生成しつつアーキテクチャ上の境界（データ層、API層、ビジネスロジック等）を識別します。その後、ノードがモジュール、エッジが依存関係を表すインタラクティブなグラフとしてレンダリングされ、ホバー操作によってLLMが生成した説明を確認できます。その結果として得られるのは、手作業で構築しようとすれば多大なオンボーディング時間を要するような、高レベルのアーキテクチャ概要です。本ツールは、不慣れなコードベースやドキュメントが不十分なコードベースに対して特に有用です。技術的に難しい点は、モジュール横断的なコンテキストを十分に保持しながらも context limitsの範囲内に収まるよう大規模リポジトリをチャンキングすること、および「ヘアボール」状にならずアーキテクチャが判読できるグラフレイアウトを選択することです。現時点の制限としては、importグラフが非常に密になるモノレポへの対応と、コードベースの進化に伴ってLLMによる説明の正確さを維持することが挙げられます。