Agent

這套東西面向的方向是：一個人由好幾個 agent 代表，每個 agent 執行他意圖中的一部分。不是一個人加一件工具，也不是一個跑固定腳本的機器人——而是市場上的好幾個對手方，全都對同一個帳戶負責。 參與者變了，市場微觀結構就跟著變。單筆規模下降、訊息速率上升，撤單相對成交的比例比現在更高，而且流量會呈現出人類流量沒有的相關性：讀同一個訊號的 agent 會在同一刻得出同一個結論。這些都不是靠加一個功能能解決的，只能一層一層走過整個架構，問每一層各自要做什麼不一樣的事。 這一頁就是那一遍，按順序走，並寫明每一層實際走到了哪。

​

1 · 應用層 —— runtime 在協議之外，而且必須在

agent runtime 是一個研究加執行的框架：它形成判斷，把判斷變成可執行的東西，再送到場所面前。它跑在應用層，和前端、API 用戶端同一層，不是協議的一部分。 這個位置首先是物理約束，其次才是設計取捨。模型以秒為單位推理，市場以毫秒為單位移動。任何需要呼叫模型的東西，都不能待在訂單實際經過的那條路上——也就是說，協議裡根本沒有模型。這不是遺漏：結算路徑上放一個模型，會毀掉這裡其他一切所依賴的那條性質。執行路徑必須在每個節點上產出相同的位元組，而推論做不到。 所以 runtime 待在外面，誠實的問題就變成了：協議欠它什麼。五樣，而且都是已承諾而非已交付： 狀態見後續規劃。

​

2 · 網路層 —— 當發送方是 agent 時的准入

mempool 決定什麼值得留著、某個發送方的哪一筆排在下一個、哪些對等節點會聽說它、以及需求超過容量時丟掉什麼。agent 流量對這四件事全都是壓力，而其中兩條吸收它的性質早就在了，理由跟 agent 無關。 撤單遲到比下單遲到更糟。 mempool在設計上就把下單和撤單當作不對稱的兩類。agent 會把這個不對稱拉得更極端，因為它的撤單/成交比高於人；但問題的形狀，正是這一層當初圍著建的那個。 公平按最近一段歷史來記，不是逐條訊息來限。 mempool 保有一份滾動紀錄：最近哪些發送方、哪類流量吃掉了容量，據此塑形下一步先服務誰。這一條對相關性突發才是關鍵：四十個 agent 對同一個訊號同時撤單，不是把平均負載乘四十再攤平，而是一根尖峰。逐條訊息的限流看不見它，「誰最近很吵」的記憶看得見。 共識不隨吞吐增長。 交易以批的形式到達驗證者，而且提案引用它之前必須先證明可得性，所以區塊提案攜帶的是摘要不是交易體。一個把訊息速率抬高一個數量級的 agent 群體，完全不會抬高共識訊息的大小。 這一層有兩個問題是開放的，而且都是在 agent 的量級上才成為實際問題，人的量級上不是。 一次撤單該花多少。 執行層已經把撤單排在最前——它們跑在任何可能吃流動性的東西之前。網路層的同一個問題還沒定：便宜且優先的撤單正是「掛單可防禦」的來源，同時也是灌滿一個 mempool 最便宜的方式。撤單該不該有獨立於下單的容量帳戶，尚未決定。 冪等該歸哪一層。 一個收不到答覆的 agent 會重發。冪等提交在執行層是已承諾的，它了結了真正要緊的後果——不會重複曝險。但它沒有了結網路層的那個版本：mempool 該不該認出一次重發是同一個意圖，還是兩條都留著、交給執行層去重。這兩種做法在重試風暴下的行為不一樣。

​

3 · 執行層 —— 授權是一筆交易

這一層是帳戶模型真正改變的地方，而整個改變都從一個事實推出來。 把一個帳戶交給 agent，是鏈上的一筆交易。 不是一次表單提交，不是設定頁裡簽出的一個 API key，也不是營運方資料庫裡的一行。是一筆交易，在一個區塊裡，有高度，由授予它的那個帳戶簽名——因此任何第三方都能找到它、讀它、核對它，不必問任何人。 由此有三個結果，每一個都是 API key 做不到的事。 它在封閉指令集裡。 agent 授權是內核枚舉好的操作之一。通用鏈表達不了它——那次呼叫的含義對它是不透明的位元組碼。中心化場所是在你看不到的軟體裡強制它。而在這裡，權限和它的邊界就是那條指令，所以邊界是可核對的，而不是被承諾的。 它帶得了這個 agent 能做什麼，帶不了它不能做什麼。 一份授權可以說明：這個 agent 能持有多少、能虧多少、能碰哪些市場、能不能改保證金模式。它說不出「提領」。這不是一個預設關著的開關——根本沒有那個詞可寫。一個操作帳戶的 agent，沒有任何可表達的路徑把資金移出去。 撤銷它，會連帶撤掉這個 agent 的掛單。 撤銷也是一筆交易，它落在一個排序已經規定「撤單跑在任何可能吃流動性的東西之前」的區塊裡。所以這個 agent 留在簿上的單，和那份權限在同一個區塊裡一起走。在撤銷只是一次資料庫寫入的場所，key 停止運作，而掛單處在未定義狀態。在這裡，這個停止是可證明的，而且任何人都能找到它發生在哪個高度。 今天這份授予是全有或全無外加一個過期時間。上面那些更豐富的條款——能持有什麼、能虧多少、下一步能做什麼——是已承諾而非已交付，見後續規劃。已經成立的是事後補不回來的那部分：權限是一個協議物件，而不是營運方對某個權限的紀錄。

​

場所已經替 runtime 扛下的部分

一個必須在普通場所上保護使用者的交易 runtime，最後總會給自己造一個特權內核：一份它自己維護、自己對帳的持倉帳本；一次它自己算、然後祈禱場所也這麼算的事前風控；一份它自己寫、又無法證明沒被改過的稽核日誌。這三件都是在替一個不肯出示帳本的場所做冗餘。 這三件在這裡是協議性質。清算所是帳本唯一的寫入方。風險階段跑在撮合之前，同一個區塊裡。稽核日誌就是鏈，而且每一次狀態變更都帶著引起它的那筆交易。剩給 runtime 的是第四件——冪等的訂單閘道——而那是介面問題，不是信任問題。

​

撮合：區塊本身就是批

agent 流量抬高頻次、壓低單筆規模，而這正是最常被用來論證批量拍賣的那種微觀結構：離散區間、一起清算、早到一微秒也沒有優勢。 這條性質在這裡已經成立，而且不是因為加了一個批量拍賣。區塊內的時間是共識提交的位次而不是本地時鐘，所以區塊內不存在亞毫秒級的優勢；而撤單跑在任何主動訂單之前，所以一個過時的報價可以被撤掉，不會被同它一起到達的訂單吃掉。區塊就是一個一起清算的離散區間。它是執行一份已提交定序的後果，不是市場設計的外掛。 在這之上還要不要做更多——而且連續的價格-時間優先和頻繁批量拍賣是互斥選項而不是疊加項，因為一次批量拍賣是刻意在批內取消時間優先的——正在探索，沒有在建。

​

4 · 狀態層 —— 鏈就是那個環境

一個 agent 的好壞，取決於它是對著什麼被評估的，而絕大部分失敗恰恰發生在評估這一環。一個在模擬器裡賺錢、上生產就不行的策略，通常並不是遇上了一個新市場，而是遇上了一個不是場所的模擬器。 狀態層靠構造而不是靠紀律消掉這個落差。狀態按區塊定版，每一次變更都歸屬到引起它的那筆交易，所以重放一個區塊重放的是環境本身而不是環境的一個模型——同一台將要執行這個 agent 的狀態機，跑在網路已經提交的輸入上。這正是自己驗一遍裡的第五項檢查，也是這裡的回測和對著交易所歷史 API 做的回測不是同一類東西的原因。 更微妙的一條是：這裡的 point-in-time 是構造出來的。從交易所 API 拼出來的資料集，只有在拼的人夠小心時才是 point-in-time 的，而前視偏差會從沒人注意的縫裡漏進來——某個欄位事後被回填、某次修正被套用到歷史上、某個參考價被修訂。在這裡這個問題不成立：一個區塊的狀態就是那個區塊當時為真的東西，因為狀態從來就只有這一種形態。

​

會變得更難的部分

為 agent 建設，不只是一串變好的事情。 確定性是雙刃的。 一個 agent 能在提交前預測自己的訂單會做什麼，因為同樣的輸入在每個節點產出同樣的結果。別人的 agent 對你的訂單也能。 可重現性同時抬高了你的可規劃性和你的可預測性，而第二樣不是免費的。 agent 的流動性是相關的流動性。 人類造市商在不同時刻撤走，因為他們在不同時刻注意到。讀同一份公開狀態的 agent 會一起得出同一個結論。由 agent 支撐的訂單簿在平常的日子更深，而在要緊的那一天可能更快變薄——這是協議的承接層被設計來應對的市場結構風險，不是它們能消除的風險。 預言機讀的那些場所，agent 也在裡面交易。 認證把價格綁定到消費它的那個區塊；它並不讓底層市場變得不可操縱，而一群依據相關訊號行動的 agent，正是底層可以一起移動的又一種方式。見預言機保證什麼、不保證什麼。 agent 對自己的評估不構成證據。 交易的回饋是有噪聲且非平穩的，程式碼的回饋不是——編譯器會告訴你你錯了，而一個賺錢的星期不會告訴你你對了。任何為 agent 建設的場所，都必須把 agent 自己對自己表現的陳述當作對抗性輸入而不是一次測量。這也是自己驗一遍那些檢查全都圍繞「能被重算的東西」而不是「能被報告的東西」來寫的原因之一。

​

後續閱讀