最近MiroThinker 1.5をじっくり調べてみたのですが、エージェント圧縮方法は少し悪質ですが、理解できて本当に役立つと思います。 カーネルは「256Kの文脈で400のツール使用をどう詰め込むか」という問題を解決します。 彼らは非常に大胆なことをしました。ReActの歴史において、思考・行動・観察の中で観察(ツールが結果を返す)を物理的にマスクしたのです。 最近のKラウンドで元のテキストを保持した以外、これまで数百件のツール結果はすべて「ツール結果はトークンを保存するために省略されている」という文に置き換えられています。 しかし、それらはすべて無傷で残されています<thought>。 この件は非常に直感に反する部分があります。このエージェント自身が深く調査しているため、最後のKラウンド、つまり5ラウンド目の原文だけを保持しており、その前に誰もいないので、どうやって質問に答えればよいのか疑問です。 これは非常に曖昧ながらも重要な前提を持っています。すなわち、思考が十分に密かであれば、実際には要約を無限に近似しているということです。 各思考生成は本質的に現在の観察に対するモデルからの情報の断片です。 T1が生成された時点で、O1の重要なデータはすでに脳に「吸収」されていました。 O1は仮の名称に置き換えられましたが、T1はそのまま残りました。 T1はO1の「情報圧縮パッケージ」となります。 追加のサマリーエージェントを付ける必要はなく、この完全なThoughtチェーン自体が高忠実度の「動的サマリー」であり、常に段階的に更新されます。

コンテキストエンジニアリングについて。 特に人々のレベルを把握できると思う2つの質問があり、私はXXビジネスシナリオでread_file write_fileをどう設計するか彼に尋ねました。 もし本当に特定の文書だけを読んで書くなら、ここで終わりにしても構いません。

人間的というのは理論と実践の橋渡しです スキル送信時に提案された方法は、プロンプト階層的読み込み/多重化、コード実行および連結API/mcp(manusはこれをコンテキストオフロードと呼びます)です。 一昨日、これら2つの手法を推論APIレベルに修正しました。ツールの発見や怠慢な読み込みを解決するTool Search Toolと、コード実行ツールを実装するためのProgrammatic Tool Callingです。 私は、Anthropic APIプロトコル😂が将来的にOpenAIに取って代わる大きな可能性を持っていると感じています