> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent

> 當參與者不是人時，架構的每一層各自要做什麼——協議之外的 runtime、agent 負載下的准入、作為一筆交易的授權，以及一個可重放的環境。

這套東西面向的方向是：**一個人由好幾個 agent 代表，每個 agent 執行他意圖中的一部分**。不是一個人加一件工具，也不是一個跑固定腳本的機器人——而是市場上的好幾個對手方，全都對同一個帳戶負責。

參與者變了，市場微觀結構就跟著變。單筆規模下降、訊息速率上升，撤單相對成交的比例比現在更高，而且流量會呈現出人類流量沒有的相關性：讀同一個訊號的 agent 會在同一刻得出同一個結論。這些都不是靠加一個功能能解決的，只能一層一層走過整個架構，問每一層各自要做什麼不一樣的事。

這一頁就是那一遍，按順序走，並寫明每一層實際走到了哪。

<div className="dg" data-dg="agent-layers">
  <div className="dg-c" style={{aspectRatio:"720 / 500"}}>
    <svg className="dg-w" viewBox="0 0 720 500" aria-hidden="true" />

    <div className="dg-band" style={{left:"0.0000%",top:"3.6000%",width:"100.0000%",height:"19.6000%"}}><span className="dg-cap">1 · 應用層</span></div>
    <div className="dg-band" style={{left:"0.0000%",top:"26.0000%",width:"100.0000%",height:"19.6000%"}}><span className="dg-cap">2 · 網路層</span></div>
    <div className="dg-band" style={{left:"0.0000%",top:"48.4000%",width:"100.0000%",height:"19.6000%"}}><span className="dg-cap">3 · 執行層</span></div>
    <div className="dg-band" style={{left:"0.0000%",top:"70.8000%",width:"100.0000%",height:"19.6000%"}}><span className="dg-cap">4 · 狀態層</span></div>
    <div className="dg-b dg-left" style={{left:"2.2222%",top:"8.0000%",width:"95.5556%",height:"12.0000%"}}><span className="dg-t">runtime 在協議之外</span><span className="dg-s">而且不帶任何特權——沒有更低延遲、沒有更早的資料、沒有第三方搆不到的介面</span></div>
    <div className="dg-b dg--blue dg-left" style={{left:"2.2222%",top:"30.4000%",width:"95.5556%",height:"12.0000%"}}><span className="dg-t">當發送方是 agent 時的准入</span><span className="dg-s">撤單遲到比下單遲到更糟；公平按最近一段歷史來記，不是逐條訊息來限</span></div>
    <div className="dg-b dg--sky dg-left" style={{left:"2.2222%",top:"52.8000%",width:"95.5556%",height:"12.0000%"}}><span className="dg-t">授權是一筆交易</span><span className="dg-s">它有區塊高度，在封閉指令集裡——而撤銷它會在同一個區塊裡撤掉該 agent 的掛單</span></div>
    <div className="dg-b dg--green dg-left" style={{left:"2.2222%",top:"75.2000%",width:"95.5556%",height:"12.0000%"}}><span className="dg-t">一個可重放、按區塊定版的環境</span><span className="dg-s">point-in-time 是構造出來的，不是靠紀律維持的</span></div>
    <div className="dg-free dg-mid" style={{left:"0.0000%",top:"92.0000%",width:"100.0000%"}}><div className="dg-n">和架構總覽是同樣的四層。只有問題不同：當參與者不是人時，每一層各自要做什麼？</div></div>
  </div>
</div>

| 層       | 變的是什麼                        | 狀態               |
| ------- | ---------------------------- | ---------------- |
| **應用層** | runtime——研究加執行——在協議之外，不帶任何特權 | 已承諾              |
| **網路層** | 突發的、相關的、撤單密集的流量下的准入          | 已交付，兩個問題待定       |
| **執行層** | 授權變成一筆帶條款的交易                 | 全有或全無部分已交付；條款已承諾 |
| **狀態層** | 鏈就是 agent 被評估的那個環境           | 已交付              |

<h2 id="1-application-the-runtime-sits-outside-and-has-to">
  1 · 應用層 —— runtime 在協議之外，而且必須在
</h2>

agent runtime 是一個研究加執行的框架：它形成判斷，把判斷變成可執行的東西，再送到場所面前。它跑在應用層，和前端、API 用戶端同一層，**不是協議的一部分**。

這個位置首先是物理約束，其次才是設計取捨。模型以秒為單位推理，市場以毫秒為單位移動。任何需要呼叫模型的東西，都不能待在訂單實際經過的那條路上——也就是說，**協議裡根本沒有模型**。這不是遺漏：結算路徑上放一個模型，會毀掉這裡其他一切所依賴的那條性質。執行路徑必須在每個節點上產出相同的位元組，而推論做不到。

所以 runtime 待在外面，誠實的問題就變成了：協議欠它什麼。五樣，而且都是已承諾而非已交付：

|            | 它給 agent 的                         |
| ---------- | ---------------------------------- |
| **預執行模擬**  | 在提交之前，對著已提交狀態評估一筆訂單會做什麼            |
| **冪等提交**   | 對一次結果不明的提交重試，而不擔心重複曝險              |
| **有名字的終態** | 不存在結果未知的結局——每個動作都終結在一個有名字的狀態上      |
| **可恢復**    | 一個重啟的 agent 知道自己剛才到哪了、下一步該做什麼      |
| **帶歸屬的回執** | 這個 agent 做了什麼、在誰的授權之下、花了多少——作為協議輸出 |

狀態見[後續規劃](/zh-Hant/protocol/roadmap/whats-next)。

<Note>
  runtime 不持有任何特權路徑。沒有更低的延遲，沒有更早的資料，也沒有第三方 runtime 搆不到的介面。這句話值得寫出來而不是預設，因為這套架構在別處的主張是「交易者和清算所之間沒有任何人」——而一個自家工具外加一條專用通道，恰恰就是那個「任何人」。
</Note>

<h2 id="2-network-admission-when-the-senders-are-agents">
  2 · 網路層 —— 當發送方是 agent 時的准入
</h2>

mempool 決定什麼值得留著、某個發送方的哪一筆排在下一個、哪些對等節點會聽說它、以及需求超過容量時丟掉什麼。agent 流量對這四件事全都是壓力，而其中兩條吸收它的性質早就在了，理由跟 agent 無關。

**撤單遲到比下單遲到更糟。** [mempool](/zh-Hant/protocol/architecture/mempool)在設計上就把下單和撤單當作不對稱的兩類。agent 會把這個不對稱拉得更極端，因為它的撤單/成交比高於人；但問題的形狀，正是這一層當初圍著建的那個。

**公平按最近一段歷史來記，不是逐條訊息來限。** mempool 保有一份滾動紀錄：最近哪些發送方、哪類流量吃掉了容量，據此塑形下一步先服務誰。**這一條對相關性突發才是關鍵**：四十個 agent 對同一個訊號同時撤單，不是把平均負載乘四十再攤平，而是一根尖峰。逐條訊息的限流看不見它，「誰最近很吵」的記憶看得見。

**共識不隨吞吐增長。** 交易以批的形式到達驗證者，而且提案引用它之前必須先證明可得性，所以區塊提案攜帶的是摘要不是交易體。一個把訊息速率抬高一個數量級的 agent 群體，完全不會抬高共識訊息的大小。

<Warning>
  區塊消滅的是**塊內**的競速：同一區塊裡的兩筆交易有一個每個節點都算得出的先後。**但這條保證從區塊邊界才開始。** 進塊之前仍然是競速，它被發送方級公平塑形，不是被它消除。准入不等於入塊。
</Warning>

這一層有兩個問題是開放的，而且都是在 agent 的量級上才成為實際問題，人的量級上不是。

**一次撤單該花多少。** 執行層已經把撤單排在最前——它們跑在任何可能吃流動性的東西之前。網路層的同一個問題還沒定：便宜且優先的撤單正是「掛單可防禦」的來源，同時也是灌滿一個 mempool 最便宜的方式。撤單該不該有獨立於下單的容量帳戶，尚未決定。

**冪等該歸哪一層。** 一個收不到答覆的 agent 會重發。冪等提交在執行層是已承諾的，它了結了真正要緊的後果——不會重複曝險。但它沒有了結網路層的那個版本：mempool 該不該認出一次重發是同一個意圖，還是兩條都留著、交給執行層去重。這兩種做法在重試風暴下的行為不一樣。

<Note>
  有一件事是刻意不做的：給 agent 單獨開一條准入通道。優先接入是每一家中心化場所最終都會賣的東西，而它會跟「交易者和清算所之間沒有任何人」這句話直接衝突。agent 流量走同一扇門。
</Note>

<h2 id="3-execution-authorization-is-a-transaction">
  3 · 執行層 —— 授權是一筆交易
</h2>

這一層是帳戶模型真正改變的地方，而整個改變都從一個事實推出來。

**把一個帳戶交給 agent，是鏈上的一筆交易。** 不是一次表單提交，不是設定頁裡簽出的一個 API key，也不是營運方資料庫裡的一行。是一筆交易，在一個區塊裡，有高度，由授予它的那個帳戶簽名——因此任何第三方都能找到它、讀它、核對它，不必問任何人。

由此有三個結果，每一個都是 API key 做不到的事。

**它在封閉指令集裡。** agent 授權是[內核](/zh-Hant/protocol/architecture/kernel)枚舉好的操作之一。通用鏈表達不了它——那次呼叫的含義對它是不透明的位元組碼。中心化場所是在你看不到的軟體裡強制它。而在這裡，權限和它的邊界**就是那條指令**，所以邊界是可核對的，而不是被承諾的。

**它帶得了這個 agent 能做什麼，帶不了它不能做什麼。** 一份授權可以說明：這個 agent 能持有多少、能虧多少、能碰哪些市場、能不能改保證金模式。它**說不出**「提領」。這不是一個預設關著的開關——根本沒有那個詞可寫。一個操作帳戶的 agent，沒有任何可表達的路徑把資金移出去。

**撤銷它，會連帶撤掉這個 agent 的掛單。** 撤銷也是一筆交易，它落在一個[排序](/zh-Hant/trading/tx-sequencing)已經規定「撤單跑在任何可能吃流動性的東西之前」的區塊裡。所以這個 agent 留在簿上的單，和那份權限在同一個區塊裡一起走。在撤銷只是一次資料庫寫入的場所，key 停止運作，而掛單處在未定義狀態。在這裡，這個停止是可證明的，而且任何人都能找到它發生在哪個高度。

<div className="dg" data-dg="agent-authority">
  <div className="dg-c" style={{aspectRatio:"720 / 214"}}>
    <svg className="dg-w" viewBox="0 0 720 214" aria-hidden="true">
      <path className="dg-wire" d="M 213.33 88.00 L 244.93 88.00" />

      <path className="dg-head" d="M 251.33 88.00 L 244.93 92.40 L 244.93 83.60 Z" />

      <path className="dg-wire" d="M 468.67 88.00 L 500.27 88.00" />

      <path className="dg-head" d="M 506.67 88.00 L 500.27 92.40 L 500.27 83.60 Z" />
    </svg>

    <div className="dg-b dg--blue" style={{left:"0.0000%",top:"14.0187%",width:"29.0741%",height:"54.2056%"}}><span className="dg-t">授予</span><span className="dg-s">第 N 個區塊裡的一筆交易</span><span className="dg-n">它帶著邊界：這個 agent 能持有什麼、能虧多少、能交易什麼。它帶不了提領——那個詞根本不存在</span></div>
    <div className="dg-b dg--sky" style={{left:"35.4630%",top:"14.0187%",width:"29.0741%",height:"54.2056%"}}><span className="dg-t">行動</span><span className="dg-s">每一次動作都寫明授權來自誰</span><span className="dg-n">歸屬到授予它的那個帳戶，不只是歸屬到提交它的那個 agent</span></div>
    <div className="dg-b dg--orange" style={{left:"70.9259%",top:"14.0187%",width:"29.0741%",height:"54.2056%"}}><span className="dg-t">撤銷</span><span className="dg-s">第 M 個區塊裡的一筆交易</span><span className="dg-n">該 agent 的掛單在同一個區塊裡被撤掉，在任何可能吃流動性的東西運行之前</span></div>
    <div className="dg-free dg-mid" style={{left:"0.0000%",top:"76.6355%",width:"100.0000%"}}><div className="dg-n">這三件沒有一件是「等著別人告訴你」的資料庫寫入。每一件都是一筆任何人都能按高度找到的交易。</div></div>
  </div>
</div>

今天這份授予是全有或全無外加一個過期時間。上面那些更豐富的條款——能持有什麼、能虧多少、下一步能做什麼——是已承諾而非已交付，見[後續規劃](/zh-Hant/protocol/roadmap/whats-next)。**已經成立的是事後補不回來的那部分**：權限是一個協議物件，而不是營運方對某個權限的紀錄。

<h3 id="what-the-venue-already-carries-for-the-runtime">
  場所已經替 runtime 扛下的部分
</h3>

一個必須在普通場所上保護使用者的交易 runtime，最後總會給自己造一個特權內核：一份它自己維護、自己對帳的持倉帳本；一次它自己算、然後祈禱場所也這麼算的事前風控；一份它自己寫、又無法證明沒被改過的稽核日誌。**這三件都是在替一個不肯出示帳本的場所做冗餘。**

這三件在這裡是協議性質。[清算所](/zh-Hant/protocol/architecture/clearinghouse)是帳本唯一的寫入方。風險階段跑在撮合之前，同一個區塊裡。稽核日誌就是鏈，而且每一次狀態變更都帶著引起它的那筆交易。剩給 runtime 的是第四件——冪等的訂單閘道——而那是介面問題，不是信任問題。

<h3 id="matching-the-block-is-already-the-batch">
  撮合：區塊本身就是批
</h3>

agent 流量抬高頻次、壓低單筆規模，而這正是最常被用來論證批量拍賣的那種微觀結構：離散區間、一起清算、早到一微秒也沒有優勢。

這條性質在這裡**已經成立**，而且不是因為加了一個批量拍賣。區塊內的時間是共識提交的位次而不是本地時鐘，所以**區塊內不存在亞毫秒級的優勢**；而撤單跑在任何主動訂單之前，所以一個過時的報價可以被撤掉，不會被同它一起到達的訂單吃掉。區塊就是一個一起清算的離散區間。它是執行一份已提交定序的**後果**，不是市場設計的外掛。

在這之上還要不要做更多——而且連續的價格-時間優先和頻繁批量拍賣是**互斥選項而不是疊加項**，因為一次批量拍賣是刻意在批內取消時間優先的——正在探索，沒有在建。

<h2 id="4-state-the-chain-is-the-environment">
  4 · 狀態層 —— 鏈就是那個環境
</h2>

一個 agent 的好壞，取決於它是對著什麼被評估的，而絕大部分失敗恰恰發生在評估這一環。一個在模擬器裡賺錢、上生產就不行的策略，通常並不是遇上了一個新市場，而是遇上了一個不是場所的模擬器。

[狀態層](/zh-Hant/protocol/architecture/state/model)靠**構造**而不是靠紀律消掉這個落差。狀態按區塊定版，每一次變更都歸屬到引起它的那筆交易，所以重放一個區塊重放的是**環境本身**而不是環境的一個模型——同一台將要執行這個 agent 的狀態機，跑在網路已經提交的輸入上。這正是[自己驗一遍](/zh-Hant/developers/verify)裡的第五項檢查，也是這裡的回測和對著交易所歷史 API 做的回測**不是同一類東西**的原因。

更微妙的一條是：這裡的 **point-in-time 是構造出來的**。從交易所 API 拼出來的資料集，只有在拼的人夠小心時才是 point-in-time 的，而前視偏差會從沒人注意的縫裡漏進來——某個欄位事後被回填、某次修正被套用到歷史上、某個參考價被修訂。在這裡這個問題不成立：一個區塊的狀態就是那個區塊當時為真的東西，因為狀態從來就只有這一種形態。

<h2 id="what-gets-harder">
  會變得更難的部分
</h2>

為 agent 建設，不只是一串變好的事情。

**確定性是雙刃的。** 一個 agent 能在提交前預測自己的訂單會做什麼，因為同樣的輸入在每個節點產出同樣的結果。**別人的 agent 對你的訂單也能。** 可重現性同時抬高了你的可規劃性和你的可預測性，而第二樣不是免費的。

**agent 的流動性是相關的流動性。** 人類造市商在不同時刻撤走，因為他們在不同時刻注意到。讀同一份公開狀態的 agent 會一起得出同一個結論。由 agent 支撐的訂單簿在平常的日子更深，而在要緊的那一天可能更快變薄——這是協議的承接層被設計來應對的市場結構風險，不是它們能消除的風險。

**預言機讀的那些場所，agent 也在裡面交易。** 認證把價格綁定到消費它的那個區塊；它並不讓底層市場變得不可操縱，而一群依據相關訊號行動的 agent，正是底層可以一起移動的又一種方式。見[預言機保證什麼、不保證什麼](/zh-Hant/protocol/architecture/oracle)。

**agent 對自己的評估不構成證據。** 交易的回饋是有噪聲且非平穩的，程式碼的回饋不是——編譯器會告訴你你錯了，而一個賺錢的星期不會告訴你你對了。任何為 agent 建設的場所，都必須把 agent 自己對自己表現的陳述當作**對抗性輸入**而不是一次測量。這也是[自己驗一遍](/zh-Hant/developers/verify)那些檢查全都圍繞「能被重算的東西」而不是「能被報告的東西」來寫的原因之一。

<h2 id="where-to-go-next">
  後續閱讀
</h2>

<CardGroup cols={2}>
  <Card title="AI 交易：現在與下一步" href="/zh-Hant/protocol/ai-trading">
    四個階段，以及為什麼必須改變的是帳戶。
  </Card>

  <Card title="自己驗一遍" href="/zh-Hant/developers/verify">
    那些讓 agent 的評估不只是一句聲稱的檢查。
  </Card>

  <Card title="信任假設" href="/zh-Hant/protocol/architecture/trust">
    能查的都查完之後，還剩下什麼要信任。
  </Card>

  <Card title="後續規劃" href="/zh-Hant/protocol/roadmap/whats-next">
    agent runtime 與授權條款的狀態。
  </Card>
</CardGroup>