78 lines
5.1 KiB
Markdown
78 lines
5.1 KiB
Markdown
# 1. コンセプト
|
|
|
|
## 背景
|
|
|
|
現在のLLMエージェントは、Filesystem、検索、Issue Tracker、データベース、外部API、他のAgentなどを、それぞれ別個のToolとして扱うことが多い。統合先が増えるほど、モデルに提示するTool SchemaとAction Spaceも増えていく。
|
|
|
|
Unix filesystemは、異なる資源を単一の名前空間へ配置し、少数の操作で探索できる強い抽象化を持つ。一方、file / directoryとread / write中心の操作だけでは、`Issue.close()`、`PullRequest.merge()`、`Agent.ask()`のような意味的操作を自然に表現しにくい。
|
|
|
|
## 中心アイデア
|
|
|
|
WIPは、任意のデジタル環境を一つの**Worldspace**として公開する。
|
|
|
|
WorldspaceはObjectのTreeとして構成される。本書では、Tree上に配置され、Pathで到達できるObjectを**エントリ**と呼ぶ。Objectとエントリは別スキーマではない。
|
|
|
|
Objectは、短いdescription、利用可能なOperation、子Object、必要に応じて`ref`を公開できる。本文やmetadataなどのドメインデータは常時露出せず、Operationを通して取得・操作することを基本とする。
|
|
|
|
## Tool DiscoveryではなくWorld Discovery
|
|
|
|
一般的なTool Callingでは、モデルは提示されたTool一覧から操作を選ぶ。
|
|
|
|
WIPでは、モデルは既知のWorldspaceを辿り、目的に関連する対象を見つけ、公開されたOperationを確認して実行する。Operationの結果から未知のエントリを発見し、既知の世界へ追加できる。
|
|
|
|
中心となる問題を**Tool SelectionからWorld Explorationへ移す**ことがWIPの狙いである。
|
|
|
|
## Worldspaceの構造
|
|
|
|
Pathはidentityではなく、現在のWorldspace上の配置位置である。同一Objectが複数のエントリとして現れてもよい。
|
|
|
|
親子関係は所有・内包を表す。所有関係にない意味的な関連は、それを表す名前付きOperationから関連エントリのpathを返し、Treeへ無理に押し込まない。
|
|
|
|
Worldspace全体を事前にmaterializeする必要はない。Hostはlazy / virtualなTreeとして、必要な範囲だけを動的に公開できる。
|
|
|
|
## 操作中心のモデル
|
|
|
|
WIPではObjectを受動的なJSON recordとして扱わない。
|
|
|
|
本文を読む、metadataを取得する、検索する、状態を変更するといった行為はいずれもOperationとして表現する。例えばIssueであれば、`read_body()`、`get_metadata()`、`close(reason)`などを公開できる。
|
|
|
|
Operationには、名前や型に加えて、用途を判断するための短いdescriptionを持たせる。長文documentationや大量のドメインデータをinterface metadataへ埋め込むことは想定しない。
|
|
|
|
## 発見と既知世界
|
|
|
|
Clientは、これまでに発見したエントリを既知のWorldspaceとして保持できる。既知のエントリはClient側で自由に辿り、Operation結果から得たエントリを追加して、さらに探索できる。
|
|
|
|
機械的な広域探索の対象は、Hostがindexableとして公開した範囲に限定できる。これにより、大量の検索結果や動的Objectが自動的に探索indexへ流入することを防ぐ。
|
|
|
|
## Guard
|
|
|
|
Operationには、実行可否とpreconditionを示すGuardを持たせられる。
|
|
|
|
例えばPull Requestの`merge`について、「CIが成功していること」「Reviewが承認済みであること」「書き込み権限を持つこと」を提示できる。Guardはアクセス制御だけでなく、Goal達成に必要なSubgoalを推論する材料にもなる。
|
|
|
|
Guardの強制はLLMではなくHost / Runtime側で行う。
|
|
|
|
## World State Transition
|
|
|
|
Operationの結果は、単なるTool Responseに限らない。Worldspaceの状態変化や、新たなエントリの発見として表現できる。
|
|
|
|
例えばRAG検索からResult群を発見したり、Agentへの問い合わせからConversationを発見したりできる。Operationは、Worldspaceを変化させ、未観測だった領域を可視化する行為でもある。
|
|
|
|
## Narrow Waist
|
|
|
|
WIPの目的は、Filesystem、GitHub、RAG、DBなどを一つの巨大APIへ統合することではない。
|
|
|
|
任意のデジタル環境を共通のWorldspaceとして投影し、発見・観測・Operation実行という小さなInteraction Modelへ収束させる。Host内部のAPI、DB、RPC、永続化方式は規定せず、TransportもCore Protocolから分離する。
|
|
|
|
## Post-trainingとの仮説
|
|
|
|
Tool Useが事後学習の対象になるなら、個別Tool名ではなくWorldspace上のinteraction policyを学習できる可能性がある。
|
|
|
|
1. 既知の世界を探索する。
|
|
2. 対象の意味とOperationを理解する。
|
|
3. 必要ならOperationから未知のエントリを発見する。
|
|
4. Guardやpreconditionを満たす。
|
|
5. Operationを実行する。
|
|
6. 変化・発見されたWorldspaceを再び観測する。
|
|
|
|
最も強い仮説は、**未知のToolを使えるモデルではなく、未知のDigital Environmentを探索できるモデルを作れるのではないか**という点にある。 |