MCP対スキル議論:役割の理解とコンテキスト腐敗の真の問題

MCP対スキル:AIエージェントの異なる役割
r/openclawでの最近の議論では、「スキルがMCPに取って代わったためMCPは死んだ」という主張が取り上げられています。著者はこれらが異なる機能を持つ2つの別個のコンポーネントであると明確にしています。
スキルとは何か
- スキルはプロンプトです - 「本当に優れた、再利用可能なプロンプト」
- 時にはスクリプトや例と一緒にバンドルされる
- エージェントに「Xを行うときはこのように振る舞うべきだ」と指示する
MCPが提供するもの
- MCPは「配管」です - エージェントのためのインフラストラクチャ
- エージェントにツールと認証を提供する
- コンテキスト制御を提供する(しばしば見落とされる)
- MCPツールからの応答は単にデータを返すだけでなく、エージェントに次に何をすべきかを導く
両者の関係
著者は両方が必要であると主張しています:「ツールのないスキルは、手のないよく書かれた取扱説明書です。スキルのないツールは、方向性のない生の力です。」
真の問題:コンテキスト腐敗
MCP対スキルの議論よりも懸念されるのは、コンテキスト腐敗の問題です:
- エージェントは時間の経過とともに指示を忘れる
- スキルはコンテキストウィンドウの深くに埋もれ、無視される
- ツールが積み重なり、エージェントの注意を圧倒する
- 著者は観察しています:「特定のスキルを使用するように明示的に指示されたエージェントを見てきましたが、ほとんどの場合、彼らはそれを完全にスキップします。」
将来のアーキテクチャ
著者は、将来はスキル「または」MCPではなく、「スキル+ツール+分離されたコンテキスト(サブエージェント)が連携する」ものだと示唆しています。これが彼らがBinduを「エージェントのためのオペレーティングレイヤーとして構築している理由です。なぜなら、動作とツールの質問を解決した後でも、エージェントが実際に生産環境で連携するためには、アイデンティティ、コミュニケーション、支払いが必要だからです。」
投稿は、「MCPは死んだ」という主張は注目を集めるには良いが、「実際にリリースされるエージェントは?彼らはすべてを使用している」と結論づけています。
📖 Read the full source: r/openclaw
👀 See Also

Qwen 35B-A3Bを16GB M4 Macで常時稼働エージェントとして使う場合:RAM不足より先にディスクI/Oが問題に
16GB M4 Macでllama.cppを使ってQwen 35B-A3Bを動かすと、バッチ推論は機能するが、Claude CodeやCodex CLIと一緒に常時稼働のエージェントループにすると、RAMは問題ないもののSSDの競合が発生し、システムが不安定になったりcronジョブが失敗したりする。

Linuxカーネル開発者、LLM生成のバグ報告を理由にレガシーコードの削除を提案
Linuxカーネル開発者は、大規模言語モデルによって生成されるセキュリティバグレポートの処理負担を軽減するため、ISA/PCMCIAイーサネットドライバ、アマチュア無線プロトコル、ATM、ISDNなど、いくつかのレガシーサブシステムの削除を提案しています。

OpenClaw クライアントがコスト追跡とエージェントごとの支出制限を追加
新リリースでは、エージェントごとの支出上限、円形プログレスバーを備えたライブ使用状況UI、サブエージェント管理、スキルのオン/オフ切り替え、エージェントごとのモデル選択が追加されました。

RustプロジェクトにおけるAIの展望:貢献者からの実践的洞察
要約文書は、RustコントリビューターたちのAIツール利用に関する見解を集めたもので、効果的なAI統合には注意深いエンジニアリングが必要であることを強調し、コードベースナビゲーション、コードレビュー支援、半構造化データ処理などの具体的なユースケースを示しています。