今日の収穫、3行で。

『もう一つハーネスを作ればAGIだ』という揶揄から、『汎用ではなくドメイン特化が既に勝りつつある』『ファイルよりベクタDBやKVの方がLLMに適した抽象では』という技術的反論まで幅広い。一方でリーン・透過的・監査可能というUnix哲学への共感も多く、Ambianceを唯一のハーネスではなく変種を載せるカーネルと見る意見が支持を集めた。FSを常時監視してカーソルを走らせるコストへの疑問（月額トークン代は？）も出た。

権限を絞れば安全だが生産性は落ち、緩めれば任意コード実行やメモリ汚染のリスクを負う。プロキシで通信を仲介する・危険コマンドをガードする・コンテナで隔離するなど層ごとの防御が提案されるが、いずれもエージェントの自律性とのトレードオフから逃れられない。

Sx 2.0のHNコメントは『なぜ素のgitやプライベートGitHubリポジトリで済ませないのか』というほぼ全会一致の疑問に収束した。バージョン管理とAIBoM（どのスキルがどのLLMで使われたか）の追跡ができないDropbox方式への懸念が強く、rsyncやリポジトリ内配置で十分という声が目立つ。ただし非技術者に『魔法のように』同期させる用途では簡便さに一定の支持もあった。

グローバルな強整合の合意はレイテンシと可用性のトレードオフ（CAP）に直面するため、エッジ分散環境で実用的な合意を得るのは難問。Meerkatはその実験的アプローチで、Cloudflareが自社のエッジネットワークを分散システムの実験場として使っている点が興味深い。

NobieのHNでは、xlsxをpixel perfectなPNG/PDFに描画し、入力と出力セルを指定してワークブックをそのままJSON APIにできる点が評価された。DenoやBunがNode.jsに対して果たした役割をExcelに対して担う存在という位置づけへの共感がある一方、実体はmacOS版であり『agents and humans』という打ち出しはやや過剰では、という指摘も出た。

Q. なぜ1ページで68,000トークンにもなるのか
A. リンク・マークアップ・脚注・関連情報まで含めて丸ごと投入すると、本文以上の量になりやすいため。必要な断片だけ抽出すれば大幅に削減できる。

Q. 決断を減らすとトークンが増えるのはなぜ
A. 少数の決断に集約するほど各決断に厚いコンテキストを与える必要が生じ、往復や説明が増えてトークンが膨らみうる、という計測上の因果。

著者は2016年Xeonで動かした先行記事に対し、自分の2013年（Ivy Bridge）はAVX2非対応でビルドが落ちた経緯と、MoEグラフの静かなバグをPRで修正した話を補足した。コメントでは『同じ構成で8〜12トークン/秒出る』『速度よりコンテキスト窓こそ実用の決め手』といった反応や、2027年半ばには200B級MoEが一般消費者ハードで動くという予測も出た。RAM容量の記載が無い点への突っ込みもあった。