docs: simplify WIP interaction model
This commit is contained in:
+13
-14
@@ -18,7 +18,7 @@ Objectは、短いdescription、利用可能なOperation、子Object、必要に
|
||||
|
||||
一般的なTool Callingでは、モデルは提示されたTool一覧から操作を選ぶ。
|
||||
|
||||
WIPでは、モデルは既知のWorldspaceを辿り、目的に関連する対象を見つけ、公開されたOperationを確認して実行する。Operationの結果から未知のエントリを発見し、既知の世界へ追加できる。
|
||||
WIPでは、モデルは既知のWorldspaceを辿り、目的に関連する対象を見つけ、公開されたOperationを確認して実行する。Operation Resultの`entry`型から未知のpathを発見し、必要なものを取得してClientのKnown Spaceへ追加できる。
|
||||
|
||||
中心となる問題を**Tool SelectionからWorld Explorationへ移す**ことがWIPの狙いである。
|
||||
|
||||
@@ -44,19 +44,13 @@ Clientは、これまでに発見したエントリを既知のWorldspaceとし
|
||||
|
||||
機械的な広域探索の対象は、Hostがindexableとして公開した範囲に限定できる。これにより、大量の検索結果や動的Objectが自動的に探索indexへ流入することを防ぐ。
|
||||
|
||||
## Guard
|
||||
## Operation Resultと新規発見
|
||||
|
||||
Operationには、実行可否とpreconditionを示すGuardを持たせられる。
|
||||
OperationはHost背後の環境を変更し得るが、WIPはその状態遷移や変更差分をClientへ同期するprotocolではない。
|
||||
|
||||
例えばPull Requestの`merge`について、「CIが成功していること」「Reviewが承認済みであること」「書き込み権限を持つこと」を提示できる。Guardはアクセス制御だけでなく、Goal達成に必要なSubgoalを推論する材料にもなる。
|
||||
Operation Resultは型付きの値であり、WIP IDLの`entry`型として、未観測だったエントリのpathを返せる。例えばRAG検索からResult群を発見したり、Agentへの問い合わせからConversationを発見したりできる。
|
||||
|
||||
Guardの強制はLLMではなくHost / Runtime側で行う。
|
||||
|
||||
## World State Transition
|
||||
|
||||
Operationの結果は、単なるTool Responseに限らない。Worldspaceの状態変化や、新たなエントリの発見として表現できる。
|
||||
|
||||
例えばRAG検索からResult群を発見したり、Agentへの問い合わせからConversationを発見したりできる。Operationは、Worldspaceを変化させ、未観測だった領域を可視化する行為でもある。
|
||||
Clientは必要に応じて返されたpathを取得し、変更後の状態を改めて観測する。
|
||||
|
||||
## Narrow Waist
|
||||
|
||||
@@ -64,6 +58,12 @@ WIPの目的は、Filesystem、GitHub、RAG、DBなどを一つの巨大APIへ
|
||||
|
||||
任意のデジタル環境を共通のWorldspaceとして投影し、発見・観測・Operation実行という小さなInteraction Modelへ収束させる。Host内部のAPI、DB、RPC、永続化方式は規定せず、TransportもCore Protocolから分離する。
|
||||
|
||||
## 状態管理の非目標
|
||||
|
||||
WIPは、Host上の任意状態をClientへ同期するdata store protocolではない。Object propertyのreplication、change feed、reactive subscription、分散transaction、domain event deliveryはCore Protocolの規定対象外とする。
|
||||
|
||||
Clientが保持するKnown SpaceとDiscoverable Spaceは、過去の観測から構成されたcacheであり、Host上の現在状態を同期したreplicaではない。HostがClientのcache状態を追跡または更新することを要求しない。Operationのauthorizationと実行条件はHostが実行時に評価する。
|
||||
|
||||
## Post-trainingとの仮説
|
||||
|
||||
Tool Useが事後学習の対象になるなら、個別Tool名ではなくWorldspace上のinteraction policyを学習できる可能性がある。
|
||||
@@ -71,8 +71,7 @@ Tool Useが事後学習の対象になるなら、個別Tool名ではなくWorld
|
||||
1. 既知の世界を探索する。
|
||||
2. 対象の意味とOperationを理解する。
|
||||
3. 必要ならOperationから未知のエントリを発見する。
|
||||
4. Guardやpreconditionを満たす。
|
||||
5. Operationを実行する。
|
||||
6. 変化・発見されたWorldspaceを再び観測する。
|
||||
4. Operationを実行する。
|
||||
5. 必要ならOperation Resultやentry pathをもとに対象を再観測する。
|
||||
|
||||
最も強い仮説は、**未知のToolを使えるモデルではなく、未知のDigital Environmentを探索できるモデルを作れるのではないか**という点にある。
|
||||
+3
-1
@@ -34,7 +34,9 @@ Objectは必要に応じて`ref`を公開できる。
|
||||
|
||||
## 観測整合性
|
||||
|
||||
エントリ自体をObjectとは別実体として扱わなくても、**あるpath上のObjectを観測した後、操作を行うまでの間に、そのpathが別のObjectを指すようになってはならない**。
|
||||
エントリ自体をObjectとは別実体として扱う必要はない。ただし、あるpath上のObjectを観測した後、Operationを実行するまでの間に、そのpathが別のObjectを指すことはあり得る。
|
||||
|
||||
その場合、Client / Runtimeは、以前のObjectを対象としたOperationを新しいObjectへ黙って適用してはならない。実行前に観測時の対応関係を検証し、変化していればOperationを中止する。この性質を**observation consistency**と呼ぶ。
|
||||
|
||||
例えば、AIが`/issues/current`を観測した時点ではIssue Aだったが、`invoke`時にはIssue Bへ差し替わっていた場合、AIはIssue Aへ作用するつもりでIssue Bを操作してしまう可能性がある。
|
||||
|
||||
|
||||
+2
-9
@@ -12,7 +12,6 @@ Operationは少なくとも次の情報を持つ。
|
||||
- `description` — 何を行う操作かを説明する短い自然言語。
|
||||
- `input` — 呼び出し時に受け取る入力の型。
|
||||
- `output` — 呼び出し結果の型。
|
||||
- `guard` — 必要に応じて公開される実行条件・precondition。
|
||||
|
||||
Operation名や型だけに意味を担わせず、`description`をinterface metadataの一部として扱う。長文documentationを埋め込むことは想定しない。
|
||||
|
||||
@@ -36,15 +35,9 @@ Operationの可視性は、頻繁に変化する実行可否やdomain stateを
|
||||
|
||||
例えばread-only主体には読み取り系Operationのみを公開し、maintainerやadminには追加の更新・管理Operationを公開できる。
|
||||
|
||||
WIPはOperationの`available` / `disabled`のような揮発的状態をinterface metadataとして同期することを前提としない。現在の実行可否やpreconditionは、必要に応じてdomain固有のOperationで観測し、最終的なauthorizationや実行条件は`call_operation`時にHostが検証する。
|
||||
WIPはOperationの`available` / `disabled`のような揮発的状態をinterface metadataとして同期することを前提としない。現在状態を判断する必要がある場合は、必要に応じてdomain固有のOperationで観測する。最終的なauthorizationと実行条件の判定は`call_operation`時にHostが行う。
|
||||
|
||||
## 2.2.5 Guard
|
||||
|
||||
Guardを設ける場合は、現在時点のavailabilityを同期する仕組みではなく、Operationに一般的に課されるpreconditionやconstraintを説明するsemantic metadataとして扱う。
|
||||
|
||||
Guardの具体的schemaは未解決事項として管理する。
|
||||
|
||||
## 2.2.6 Operation Result
|
||||
## 2.2.5 Operation Result
|
||||
|
||||
Operationの結果には、通常のdomain valueに加えて、WIP IDLの`entry`型として新しいエントリのpathが含まれ得る。
|
||||
|
||||
|
||||
+1
-1
@@ -18,7 +18,7 @@ GUI、AI用Tools、PTC / REPL向けAPIなどへの投影はClient実装の責務
|
||||
|
||||
HostはClientに対して一つのWorldspaceを提供する。
|
||||
|
||||
どのObject、エントリ、Operation、Guard、可視性を公開するかを決定し、そのClientから見えるWorldspaceを構成する。
|
||||
どのObject、エントリ、Operation、可視性を公開するかを決定し、そのClientから見えるWorldspaceを構成する。
|
||||
|
||||
Host内部でGitHub API、Database、Filesystem、RAG、他Agent、別プロトコルなどをどう接続・集約するかはWIPの規定対象外とする。
|
||||
|
||||
|
||||
+3
-1
@@ -10,6 +10,8 @@ ClientはHostから得た情報をそのまま一時表示するだけでなく
|
||||
|
||||
Known Spaceは、Clientが**現在保持しているエントリの集合**である。過去に発見したすべてのエントリを単調に蓄積する集合ではない。
|
||||
|
||||
Known SpaceとDiscoverable SpaceはClientが過去の観測から構築したcacheであり、Host上の現在状態を同期したreplicaではない。HostはClientのcache状態を追跡または更新しない。
|
||||
|
||||
次のような経路で得られたエントリをKnown Spaceへ追加できる。
|
||||
|
||||
- `fetch`または`fetch_tree`で取得したエントリ
|
||||
@@ -25,7 +27,7 @@ Clientは、Hostから`fetch_tree`で取得したindexableなエントリツリ
|
||||
|
||||
Discoverable SpaceはKnown Spaceの部分集合であり、AI向け`discover`などの機械的探索に利用する。Worldspace rootまたはClientが選択した起点からindexable edgeで到達できる、materialize済みの範囲によって構成される。
|
||||
|
||||
Treeの再取得やHostからの更新によって親のindexable edgeが削除された場合、その子エントリはDiscoverable Spaceから除外する。その結果、保持しているどの起点からも到達不能になったsubtreeは、その場で破棄できる。ただし、別の経路から到達できるエントリ、Clientがpinしたエントリ、実行中のOperationが参照しているエントリは引き続き保持してよい。
|
||||
Clientが`fetch_tree`を再実行した結果、以前存在した親のindexable edgeが返されなくなった場合、その子エントリをDiscoverable Spaceから除外する。その結果、保持しているどの起点からも到達不能になったsubtreeは、その場で破棄できる。ただし、別の経路から到達できるエントリ、Clientがpinしたエントリ、実行中のOperationが参照しているエントリは引き続き保持してよい。
|
||||
|
||||
Operationを通して発見されたpathは、それだけではDiscoverable Spaceへ追加しない。そのエントリを起点として`fetch_tree`を取得した場合に、そのindexableな範囲をDiscoverable Spaceへ追加できる。
|
||||
|
||||
|
||||
@@ -22,7 +22,6 @@
|
||||
- Recursive named typeを許可するか。
|
||||
- `i64`、`u64`、`bigint`、`decimal`等を追加するか。
|
||||
- `description`の必須性と長さ。
|
||||
- Guardの具体的schema。
|
||||
- error型をOperation outputに含めるか、Protocol errorとして分離するか。
|
||||
|
||||
## WIP over HTTPS
|
||||
|
||||
+1
-1
@@ -253,7 +253,7 @@ operation refresh {
|
||||
|
||||
Outputには任意のtype expressionまたはNamed typeを使用できる。ただし、将来fieldを追加する可能性があるOperationではrecord outputを推奨する。
|
||||
|
||||
Operationのname、description、Guardなど、input / output型以外のinterface metadataとの対応付けは[Operation schema](../2.2-operation.md)で定義する。
|
||||
Operationのnameやdescriptionなど、input / output型以外のinterface metadataとの対応付けは[Operation schema](../2.2-operation.md)で定義する。
|
||||
|
||||
## Schema exchange
|
||||
|
||||
|
||||
@@ -8,11 +8,11 @@ Core Protocolの意味論を変えずに、既存のWebインフラを利用し
|
||||
|
||||
## 方針
|
||||
|
||||
標準bindingとしてHTTPSを採用することを第一候補とする。
|
||||
初期の標準bindingはHTTPS上のrequest / responseのみを規定する。TLS、認証、Proxy、Gateway、Observability、Caching、connection reuse、multiplexing、compression等の既存機構を利用してよいが、特定のHTTP versionや実装方式を必須にしない。
|
||||
|
||||
HTTPSを利用することで、TLS、認証、Proxy、Gateway、Observability、Caching、Streamingなど既存の仕組みを再利用できる。
|
||||
OperationがWebSocket等のendpointを通常のdomain valueとして返すことは妨げない。そのendpoint上のprotocol、状態、lifecycleはWIPの規定対象外であり、ClientとHost固有実装の責務とする。
|
||||
|
||||
必要に応じてHTTP/2、HTTP/3、SSE、WebSocket等を利用してよい。ただし、これらは通信上の最適化または補助機構であり、WIP Core Protocolの意味論を変更しない。
|
||||
双方向socket transportをWIP bindingとして標準化する場合は、将来の独立した拡張として定義する。
|
||||
|
||||
## Binding対象
|
||||
|
||||
@@ -22,7 +22,7 @@ HTTPSを利用することで、TLS、認証、Proxy、Gateway、Observability
|
||||
- `fetch_tree`
|
||||
- `call_operation`
|
||||
|
||||
具体的なHTTP method、endpoint、content type、error mapping、認証方式、streaming表現などは、このbinding仕様側で定義する。
|
||||
具体的なHTTP method、endpoint、content type、error mapping、認証方式、batch表現などは、このbinding仕様側で定義する。
|
||||
|
||||
## WIP IDLの取得
|
||||
|
||||
|
||||
Reference in New Issue
Block a user