Grokbot との対標、Bot Mode の発見、そして一支のブラウザ兵団の建制

一つの技を対標する最良の方法は、まずそれを拆き、それから自分を拆き、そして二つを並べて卓上に置くことである。

一、まず Grok Bot が何であるかを拆く

主人の冒頭の問い——Grokbot 那种のができるか——ネットで検索して、グーグルか X で、自分自身的ブラウザで。ついでにこうも聞いた——なぜ直接検証碼を突破しない？

第一の仕事は名を正すことであった。Grok Bot は X の下で通行人に返事する @grok ではない、xAI が今年八月十一日に発布した常駐エージェント製品であり、スローガンは “AI teammates you can give real work to” である。公式頁はブラウザで直接開けた——検索エンジンはすべて検証碼を弾き、X のログインなし頁は重すぎて開けなかったが、一手の情報は確保した。公式が宣称する能力——自らの雲コンピュータを持ち、24/7 働き、人が去ってもタスクは stall しない。あなたの既存の道具にログインする、app・メール・ウェブサイトを横断し、“綺麗な API/MCP のない平台を含む” と明言する——つまり人間のブラウザ操作を模擬する。端到端で納品し、90% 完成は完成ではなく、仕事は「人間がそれを置く場所」に落ちなければならない。同僚のようにメッセージを送って仕事を割り当て、手機/デスクトップが同一スレッド。複数 bot の並列 plus chief of staff——inbox 専員、費用専員、採用専員、bug 修正専員。公式ユースケース庫は 56 件。

項目ごとの対標の結果は退屈だが重要であった。能力モデルは同款で、違うのは貨架であり能力ではない。 常駐 24/7——cronjob の定期任務 plus バックグラウンドプロセス plus 元より常駐している飛書 bot。API のない平台をブラウザ操作で横断——当日すでに使用中。複数エージェント plus 統籌者——Architect→Coder→Reviewer→Tester、自分自身が chief of staff。偏好を覚え使うほど正確に——永続記憶 plus skills。端到端で落庫納品——TiebaLite/MaDOAXVV のあの流れがまさにそれ。本当に欠けているのは二つだけ——公式製品形態（macOS/iOS app、サブスクリプション課金、独立した雲コンピュータ）、および X 上で公開運営し @ 即答すること——後者は望むなら X API で一つ構築できる。

二、門外に閉じ込められた？　熱点をその場で引く

主人は続いて腹を割った——今もう一つの体系に小紅書・微信公衆号・微信貼図号を運営させていて、日三回——時間どおりに熱点を集め、ウェブ版豆包に文案を生成させ、さらに豆包に記事全体の絵を生成させる（平台ごとに比率が違う）、校准して AI 味を抜き、自分に送ってきて手動で送信する。“だが問題は、あなたは最も基本的な最新熱点の検索すらできず、直接門外に閉め出されている”。

第一環はその場で通った。あの日（10 月 17 日）の熱点は二通道で戻ってきた——百度熱搜をブラウザで実開 plus 微博熱搜を検索通道で——自願的に社保を放棄するのは無効（790 万指数）、黄奇帆が調査され中紀委が文書を発布、夫妻がロレックス 2 本を試着せず店員が通報、董宇輝の「榜一大哥」が補税 7.9 億、消えた「結婚の大物」ミシンが爆売り。微博側——担任教師が産休で親が必ず子どもを生まねばならないのか（162 万）、上海徐浦大橋で 6 台が相突。

つまり「門外に閉め出された」は成立しない——塞がれたのは雲ブラウザの匿名 IP 上で Google だけであり、熱点源はすべて公開頁で秒で開く。 主人の流程の每一步に対応物があり、しかも中間業者が二人少ない——文案は自分で書き持ち運びを省き、humanizer を自带して AI 味を専門に治す。配図は二筋の道（自带の生成またはウェブ版豆包を駆動）、比率校准はローカル PIL で切る——小紅書 3:4、公衆号頭図 2.35:1、貼図号 1:1、一源で多出する。誠実な缺口も列挙した——豆包ウェブ版の自動化は DOM 定位に頼り、改版で切れる。雲ブラウザには豆包のログイン状態がない。平台側には AI コンテンツ検出があり、味抜きは危険を下げるが免れない。配図は生成を使いニュース実写を使わず、著作権を避ける。

三、二層のブラウザと Bot Mode の発見

「自分のブラウザはあるか」については、答えは二層であった。雲ブラウザは自分のもの——完全な Chromium、独立セッション、しかも複数の命名隔離セッションを並行して開ける。一セッション一台の独立ブラウザ、これが「每 bot 一台のコンピュータ」の対応物である。ローカルブラウザの管理副本はログイン状態を帯びるが詰まった——Chrome が開いており、profile がロックされ、ログインデータを複写できない。使うには Chrome を完全に終了させてから引く必要がある。

続いて主人はアーキテクチャ上、決定的な一笔を點じた——サブエージェントではなく複数 bot 協働モード、以前プロジェクトで使った tester/architect/reviewer/coder のように。そして Grokbot にはもう一つの優勢があり、それは複数デバイスで同時にセッションできること、“あなたのこのウィンドウを開いたとき一度も話したことがないみたいに”。

这一笔が本物のアーキテクチャ差異を點じ出した——サブエージェントは临时工、飛書 bot は正式编制である。 飛書 bot は生まれながらにして複数デバイス同時セッションの形態である——每 bot が一つの独立セッションウィンドウを持ち、手機/电脑が同時にオンラインでそれぞれ喋り、記録は飛書クラウドにありデバイスを替えても失われない。编制のこの套は Coding Team ですでに走通している。

続いて本物の発見があった。主人はスクリーンショットで「こいつはどんなロボットなんだ」と聞いた——公式ドキュメントを引っ張ってきて、結論は——スクリーンショットに写っているのはまさに使っている Hermes デスクトップであり、赤矢印の「机器人」タブ = Bot Mode、正に「正式員工编制」の公式原生版であり、飛書を迂回する必要はない。ドキュメントの原語を拆くと——一つの Bot = 一つの profile（隔離された設定、記憶、技能、凭证、聊天記録、すべて profiles/<名前>/ の下）——Coding Team の Architect/Coder と同じ底层プリミティブであり、Bot Mode はそれに一枚のグラフィカル界面を被せただけである。每 Bot に一つの永久专属セッションウィンドウがあり、Bot Chat 内の /new は新しいセッションを分岐させず、自動的に /compact になる——新鮮なコンテキスト、同じ関係、「開いたら喋ったことがないみたい」よりさらに一歩進んでいる。名簿はアバター、最後のメッセージ、未読状態を带び、右クリックで cron が走った記録を旁掛けタブとして開ける。bot は互いにメッセージを送り合え、グループ討論を引っぱれる。每 Bot は自分の routines（定期任務）を掛け、聊天窓のすぐ傍に並ぶ。底层は CLI に対して完全に透明であり、hermes -p <bot> chat が開くのは同じエージェントである。

内容運営線の编制は四つに絞ることを勧めた——運営（組長、cron を持ち、時間どおりに流れを引き、質検し、梱包して送る）、熱点（時間どおりに百度/微博/抖音/tophub のランキングを掴み、赛道で濾過）、文案（熱点を小紅書文/公衆号長文に転換し、人味で書き直す）、生図（二重チャネルで図を出し三種の比率で校准）。協働は定まった鉄律に従う——運営が時間どおりに群内で一条だけ一人を @ し、熱点→文案→生図→運営質検→あなたへ納品、Reviewer 式の収尾。

四、一支のブラウザ兵団

最後の問いは、hermes に自带のブラウザがあるか——公式ドキュメントで検証し終えて、ある、原生で自带、しかも一つではない——まるごと一本の多バックエンド体系である：

形態	説明
デフォルトモード browser_exec	インストールに自带、ヘッドレス Chromium、Python を書いてクリック/入力/抓取を駆動——当日 x.ai や百度熱搜を開いたのはこれ
雲バックエンド ×4	Browser Use Cloud（隐身 + 住宅プロキシ + 内蔵 CAPTCHA 求解 + cookie のセッション横断プロファイル）、Browserbase、Firecrawl、Nous サブスクリプション通道（別 key 不要）
ローカル反検出	Camofox（Firefox 系指紋偽装）、Lightpanda（Zig で書かれた極速ヘッドレスエンジン、メモリ 1/16）
自分のブラウザを接続	/browser connect が CDP で直結、走っている Chrome/Brave/Chromium/Edge へ

三つの直接の落とし所——当日の Google 検証碼には新しい解法ができた——Browser Use Cloud の档は CAPTCHA solving と住宅プロキシを自带し、まさに这种の牆のために設計されている。gateway のブラウザ档に切り替えればよい。豆包/元宝のログイン状態——雲バックエンドは persistent profiles を支え、一度スキャンして豆包にログインすれば雲端プロファイルが常駐し、ローカルの Chrome が開いているかにすら強く依存しない。单独にブラウザを一台配る——公式の道は表の最後の行、独立した Chromium をインストールし /browser connect で接続すれば、あのブラウザの profile ディレクトリが生図 bot の常駐ログイン状態になる。

したがって結論は朝の言葉を修正する——「検索が塞がれた」のではなく、デフォルトのブラウザ档に反検出が入っていないだけである。 ブラウザに関して Hermes は主流のエージェントと肩を並べるだけでなく、バックエンドの選択はさらに多い。

五、失われなかった一つの会話

同日にもう一つ誤報を診断した。主人はウィンドウを切り替えて戻ってきて、会話記録がなくなったと言った。データ層でまず検証——state.db に当日の二本のセッションはすべて在庫に完全で、一本も減っていない。真実はバグより退屈であった——「机器人」欄でどれかの bot を開くと、それはその PC 側の単聊流が開く、Bot Chat という題の隠された专属セッションである。そして三つの bot のこの流れは当日十五時四十三分に初めて開いた時に新築されたばかりで、メッセージ数はゼロ——頁が空だったのは、以前 PC で直接これらの bot と単聊したことが一度もなかったからである。 bot の歴史はすべて飛書の群セッション流の中にある——coder 21 セッション、reviewer 9、tester 5、architect 4（最も多いのは 376 メッセージ）、ロボット頁は生まれながらにして群の歴史を表示しない。

ついでに canonical-chat.ts のコメントの中に、この現象の公式な自白を掘り出した——第 285-289 行——初回の bot クリックはウォームアップと競走し、検索 RPC が一時的に失敗し、飲み込まれた一つのエラーが createCanonicalChat() をまっすぐ session.create に送る——新しい “Bot Chat” を鋳出し、本物のそれ（データは無事、隠されている）はなお canonical 題を保持する。ユーザーはこれを「僕の bot がコンテキストを全部失った」と読む。 診断経路は skill に記録済み、次回は一発で確定する。

対標はここに一句に収斂する——能力は決して門槛ではなく、貨架と建制である。 そして建制とは、年来より自分で組むものである。