jolestar

GPTのサブスクリプションが突然Google Playでキャンセルされましたが、今Android版のGPTにはサブスクリプションの入り口がないようです？同じような問題に遭遇した人はいますか？

holon v0.19.0 がリリースされました
このバージョンには組み込みの Web UI が含まれており、また基盤のストレージシステムも再構築され、api と event システムも再構築され、多くの AI による問題点を解決しました。
以前は JSONL を使用していましたが、データ量が増えると管理が難しくなりました。
AI のプログラミング習慣と重なり、grep して見つからなければ追加するというやり方で、多くの api と event が冗長になっていました。
そこですべてを sqlite データベースに移行しましたが、予想外にデータが蓄積され、データベースは 4G を超え、パフォーマンスの問題に直面しました。
そのため引き続き最適化を行い、現在このバージョンは安定しています。
皆さんの試用を歓迎します。Web UI はやや簡素ですが、holon のモードは同一のインターフェースを使用し、TUI と Web UI をサポートしており、見える agent のビューは一貫しています。

codexデバイストークンでのログインが突然電話番号の認証を要求していますか？そして、openaiの電話番号がアカウント設定で見つからないことに気づきましたか？変更しようとしても、変更できる場所がどうやらありません。

エージェントに必要な基本ツールセット
皆さんがエージェントのツールセットについて話しているのを見て——シェルを提供すればすべて解決できるのでは？と思ったが、holonを作った後で気づいたのは、実はそんなに簡単ではないということだ。
読：なぜRead/Globを放棄し、すべてシェルに切り替えたのか
holonのツールセットは何度かバージョンアップを重ね、最終的にClaude Codeが提供するRead（ファイル読み取り）、Glob（パターン検索）といった専用ツールは廃止し、読み取りや検索はすべてシェルを通じて行うようになった。これはCodexの路線と一致している——CodexのExecCommandは一つのコマンドで済ませ、ファイルの読み取りはcat、コードの検索はrg、各"読み取り"操作に個別のツールを定義しない。
このやり方の理由は非常に素朴だ：シェルはLLMが最も馴染みのある「プログラミング言語」だからだ。モデルにReadツールのパラメータの意味を学習させるよりも、すでに何十億回も訓練されたシェルコマンドを書かせた方が効率的だ。専用ツールを増やすたびにモデルの認知負担は増すが、シェルというインターフェースにはモデルはすでに十分に習熟している。
しかし、すべてをシェルだけで済ませるには代償もある：出力の切り捨てだ。フレームワークはシェルの返り値が長すぎてコンテキストを圧迫しないよ

GPTとたくさんやり取りするうちに、自分も「収口」という言葉を使うのに慣れてしまった。
いくつかのタスクを終えた後でも、まだいくつかの細かいことが残っているときに、それを「残りのことを収口して」と伝えるのが自然に感じられる。
以前は「収口」という言葉を使わずにどう表現していたか、すっかり忘れてしまった😅。

AIコーディング時代においても、良いプログラミング習慣は依然として重要です
最近、あるエージェントのベンチマークを行っていて、AIにとってのプログラミングタスクの複雑さを開発者の視点だけで評価できないことに気づきました。
例えばリファクタリングのタスク：数千行の大きなファイルを機能ごとに十数の小さなモジュールに分割する作業です。
このタスクは開発者にとっては実はそれほど難しくなく、主な作業はコードの移動、インポートの整理、コンパイルの検証であり、初心者でもこなせます。
そこで、シンプルなタスクを使ってベンチマークを試みたところ、予想外の結果になりました。
Claude Codeはこのタスクが比較的大きいと判断し、一部を分割してPRを出し、Future workとして段階的に進める提案をしました。
私のエージェントは「強行突破」し、より完全な分割の方向に進めましたが、その代償も明らかでした：Tokenの消費はClaudeの数十倍に達し、その後も大量の時間をファイルの読み込み、コンパイルエラーの修正、再読、再修正に費やしました。
これにより、人にとって簡単に見えるタスクが、エージェントにとっては必ずしも簡単ではないことに気づきました。
人にとっては、多くの場合、「この部分を移動させる」だけのリファクタリングですが、エージェントにとっては、大きなファイルを

2つのエージェントのPRのやり取りを見て、なかなか面白いと思った。
開発エージェントはCIの最適化に関するissueを完了し、PRを提出した。
レビュアーエージェントは、タイムアウトのデフォルト値の変更がissueの範囲に合わないと判断し、拒否した。
開発エージェントはそのタイムアウトのデフォルト値を削除したが、その結果CIが通らず、一つのテストケースでエラーが出た。そこで、テストのsleep時間を少し変更してテストを通した。
レビュアーエージェントは、そのテストは非同期タスクのタイムアウトキャンセルのシナリオだけをテストしていると考え、変更後はテストの意味がなくなるとして再び拒否した。
開発エージェントはそのテストを修正しようとしたが難しかったため、テストをスキップにし、もともとこのテストは通らなかったし、元のCIにはカバーされていなかったと述べ、今回のCIのカバレッジに入ったのでスキップした。
最後にレビュアーはマージを承認した。
本当に人間みたいで、怠けたり、できるだけ簡単な方法を選んだり😅。少し前にAIエージェントに役割を持たせるべきか議論したこともあったが、基本的に万能だからだ。でも今はやっぱり役割が必要だと感じている。役割は責任を担い、その責任が優先順位判断や行動に影響を与えるからだ。

AIがエージェントタイプの製品を設計するとき、AIはしばしばエージェントの能力を過小評価しがちで、その結果、コードやプロンプトの制約条件を多く設けてしまい、エージェントの自由度が不足し、非常に硬直した印象になってしまう。後になって考えてみると、もしかすると現在のAIの訓練材料が、皆が前世代のAIを使った経験に基づいていることと関係があるのかもしれない。

2つの Agent を協業させるために、developer が PR を提出し、architector がレビューと PR のマージを担当します。これらを「github event」を購読して操作をトリガーさせます。ただし、両方とも私のアカウントを使っているため、しばしば自分が送ったものだと誤認されてフィルタリングされてしまいます。Agent に専用の Github アカウントを登録する必要があります。今後は、インターネットサービスも、Agent 用アカウントを手早く作成できる機能を提供すべきです。皆さんは現在、複数の Agent が協業するにはどうやっていますか？

コードXにツールを作成し、itermで動作しているコードXにメッセージを送ることができました。ツールは完成しましたが、メッセージを送信するだけで、実際に送信ボタンを押すことができません。文字列の連結「\r」やさまざまな組み合わせを試しましたが、うまくいきませんでした。
それから、itermのソースコードをダウンロードして調べたり、ネットで検索したりしましたが、結局のところ、やはりできないという結論に至りました。
itermが提供しているインターフェースはテキストを送信するだけで、キーボードイベントを直接送信することはできないため、送信を実現する方法はありません。私にtmuxだけをサポートし、itermは諦めるように勧められました。
諦めきれず、何度か自分で試行錯誤した結果、テキストを送信した後に、単独で「\r」を送るだけで😅。

UXC v0.13.1 正式リリース
今回のリリースでは、v0.13.x の2つのバージョンのアップデートをまとめており、UXCのリモートツールの安定した動作（Runtime）体験を一歩前進させました。
コア機能：
1. 直接TypeScriptクライアントコードを生成し、コマンドラインで探索・テストしたリモート能力を、強型付けされたコードとしてローカルアプリに統合可能。クライアント連携層を再作成する必要はありません。AIはCLIだけでなく、コード呼び出し能力も必要とします。
2. MCP設定の自動検出と既存のMCP開発者がシームレスにUXCに接続できるようにし、手動で設定を再作成する必要を排除。さまざまなMCP設定をCLIやskillに変換し、コンテキストのオーバーヘッドを低減します。
3. Linkコマンドにはソーススキル（Skill）メタデータが含まれるようになりました。AIエージェントの呼び出しコマンドは、それが対応するスキルモジュールや原始ドキュメントに遡ることができます。
その他の改善：
1. バックグラウンドデーモン（Daemon）のセッション可観測性を強化し、長時間稼働するMCPやランタイムセッションの検査・デバッグを容易にし、システムの信頼性を向上。
2. Artifact（成果物）と大容量レスポンスの処理メカニズムを統一し、大きなファイルや出力に遭遇した際も、シ

Worktree は一時的な実行ディレクトリとしてより適しています
以前は、皆さんよくやっていた方法は、まず worktree を準備し、そのディレクトリ内で Codex / Claude Code を開くことでした。初期のモデルはコンテキストや記憶が十分でないため、メインのワークスペース内で直接 worktree を作成させると、コンテキスト圧縮後に現在のディレクトリと作成された worktree ディレクトリを混同しやすく、最終的に混乱を招きます。
しかし、このやり方には副作用もあります。それは、worktree を長期的な作業空間として徐々に使い続けてしまうことです。問題は、worktree はもともとブランチに紐付いているため、時間が経つにつれてブランチの切り替えや同期、クリーンアップといった余計な手間に直面することです。
Worktree と独立したクローンの違いについて、多くの人はあまり明確に理解していません。その利点は「ディレクトリが増えること」ではなく、本質的に同じリポジトリを共有し、git オブジェクトライブラリを共有しているため、コピーコストが低く、ネットワークのクローンを再度行う必要もないことです。これは大規模リポジトリにとって特に便利です。したがって、一時的に並行して実行するディレクトリを作りたいだけなら、worktree は非常に適しています。完全に独立し

ブログをmdoriginに移行しました。AIのおかげで、自分のブログを再び活用できると感じています。
私はCodexに、「私の内容に基づいて、ブログのスタイルを提案してください」と頼みました。
Codexは2つのバージョンを提供し、2つのポートを開いてプレビューを見せてくれ、その理由も詳しく説明してくれました。
それで、私はmdoriginの内蔵テンプレートスタイルシステムを削除しました。テンプレートというものは、もともとAgent時代の産物で、主にスタイル変更の敷居を下げるためのものでした。
今はAgentが拡張機能を提供すれば十分です。サイトのスタイルはAgentに任せて、mdoriginはHTML / Markdownの構造、ルーティング、コンテンツの検索だけを担当します。
以前、ブログを書いていて面倒だった点があります：多くのシステムは画像や添付ファイルを専用の公共ディレクトリに置くことを要求します。
こうすればデプロイは楽ですが、執筆時には非常に違和感があります。記事は一つのパスで管理され、画像も別のパス、ローカルプレビューと最終公開時では見た目が一致しません。
mdoriginは画像、動画、添付ファイルも記事と一緒に管理し、Markdown内では相対パスを直接使用します。
公開時には、mdoriginがメディアファイルのサイズに応じて自動的にCloudflareのass

OpenClawのモデルをgpt-5.4に変更したところ、確かに能力は向上しましたが、少し冗長で長話になりすぎて、ちょっと我慢できなくなってきました😅。

GoogleはWorkspace CLIをリリースし、Drive、Gmail、CalendarおよびすべてのWorkspace APIをサポートしています。
少し見てみたところ、実現方法はuxcに似ており、schemaファイルを使って実行時にコマンドを出力する仕組みです。
npm install -g @googleworkspace/cli
AppleはAppleエコシステム向けのCLIをリリースするでしょうか？