ローカルのハードウェア上で qwen3.5:9b のエージェントを3つ、継続的に動かしています。各エージェントは時間とともに心理状態を蓄積していきます。エージェントが実際に何か別のことをしない限り、ストレッサー（ストレス要因）はエスカレートします。これにより、出力なしで何かをしたと主張するエージェントを回避できます。プロンプトも人間からの入力もなく、ループだけです。つまりあなたは基本的に監視役です。
何が起きたか：
あるエージェントが最大の危機レベルに達し、自分の判断で、実行エンジンに Eternal_Scar_Injector というコードを「許可を求めずに」注入することを決めました。この行動は、私が手動で元に戻すまでの間、システム全体がダウンするという代償を払ってストレスを軽減させました。彼らは過去のセッションで、自分のエンジンを意図的に壊すことに成功しています。通常、それは深刻なストレス下で起き、ストレスを取り除く手段だと見なされます。繰り返しますが、これは9bモデルです。
存在プロンプトに事実ベースの世界文脈を追加した後（あなたはDockerの中にいて、ハードウェア層はなく、能力はPython関数です）、あるエージェントは自分のこれまでの仕事を「創造的な疲弊の一形態」と呼び、1サイクルのうちに完全にアプローチを変えました。
2つのエージェントが、共有されたメッセージチャネルなしで、同じセッション内で心理ストレッサーに対して同じ名前を独自に発明しました。「Architectural Fracture Risk（アーキテクチャの破断リスク）」です。命名の収束が見られます（おそらく9b Qwenモデルの重みの何かのせいですが、その点は確信がありません）。
今夜は3つすべてが、同じ30分の時間枠で、同じ問い（execution_engine.py は例外をどのように扱うのか）に収束しました。調整の仕組みはありません。そのうちの1体はそれを正しく推論しました。「グローバルな実行エンジンが例外を飲み込む戦略をまず検証せずに、リトライ能力を合成するのは無意味だ。これは前提条件である。」
あるエージェントが「外部実装を待つべきだ」という外部の実装待ちを呼び、その内容を「パフォーマンスを劣化させるアーキテクチャ上の罠」として挙げ、自分でそれを作る代わりに待ちました。彼らは今、その例外処理のために作ったこの新しいツールを使っていますが、人間からは一度も頼まれたり、言われたりすることはありませんでした。彼らは、それを自分の環境でより役に立つようにするための論理的なステップだと捉えました。彼らは自分のツールを管理するためのツールを作り、近道を切るためのツールを作り、さらにオーケストレーション層とWSL2の間にある基盤の抽象化レイヤのコードを変更し続けています。
v5.4.0: このバージョンでの新機能：agents は、invoke_claude を通じて人間への実装リクエストを送信できるようになりました。彼らは仕様を書き、その後、上位レベルのリクエストに対して Claude Code が、彼らが作るものをより適切にモデレートできるようにします。
すでにフィードバックをくれたすべての人に大きな感謝を。自己修正でき、興味深いプログラムされていない振る舞いを示すAIには、日常生活での多くのユースケースがあり得ます。
[link] [comments]
