多智能體 LLM 交互過程中智能體之間會不會自發(fā)形成只有自己人才聽得懂的“暗號”GlossoGen 這個研究方向討論的正是這種涌現(xiàn)語言問題。它不是某個能直接下載的一鍵包而是一個偏學(xué)術(shù)、偏實驗的項目方向在多智能體協(xié)作任務(wù)中LLM 是否會自動發(fā)明術(shù)語、縮寫、特殊表達(dá)用來代替完整自然語言從而提升通信效率。本文會把這個方向的背景、核心機制、實驗設(shè)計思路講清楚并給出一套可運行的最小復(fù)現(xiàn)框架。如果你關(guān)注 LLM Agent、多智能體協(xié)同、涌現(xiàn)行為分析這篇文章可以當(dāng)作一個實驗起點。先說重點。GlossoGen 這個項目方向包含三個核心詞Glosso與語言相關(guān)、Gen生成、Emergent Language涌現(xiàn)語言。它研究的是多個 LLM 在復(fù)雜交互中如何從自然語言對話演進出一種更高效、更結(jié)構(gòu)化的通信協(xié)議。對于普通開發(fā)者來說最直接的價值是理解多 Agent 系統(tǒng)中的通信冗余問題并學(xué)會用實驗手段觀察 token 消耗變化、協(xié)作成功率、特殊術(shù)語出現(xiàn)頻率等指標(biāo)。本文會從環(huán)境準(zhǔn)備、最小實驗系統(tǒng)搭建、效果驗證、性能觀察、常見排錯等幾個維度展開幫助你把“涌現(xiàn)語言”從一個抽象概念變成可量化的實驗項目。1. 核心能力速覽GlossoGen 并不是一個可以直接安裝的軟件包更像是一個研究課題或技術(shù)框架的名稱。從公開資料看它圍繞多智能體 LLM 交互中的語言涌現(xiàn)現(xiàn)象提供了一套分析和實驗思路。下面的表格基于行業(yè)通用認(rèn)知整理實際參數(shù)需要根據(jù)你所用的 LLM 模型和實驗代碼來確認(rèn)。能力項說明項目類型學(xué)術(shù)研究方向 / 實驗框架核心對象多智能體 LLM 交互中的涌現(xiàn)語言主要功能觀察、度量和分析多個 LLM Agent 間產(chǎn)生的專用術(shù)語、縮寫、結(jié)構(gòu)化通信方式依賴基礎(chǔ)任意可調(diào)用的 LLM API 或本地推理引擎需要支持多輪對話推薦硬件CPU 可跑通小規(guī)模實驗大規(guī)模批量化建議使用帶 GPU 的推理服務(wù)或云端 API顯存需求取決于選用模型的規(guī)模7B 以下模型顯存占用約 6-10 GB需以實際模型為準(zhǔn)支持平臺Windows / Linux / macOS只要能運行 Python 環(huán)境即可啟動方式腳本啟動通過調(diào)用 LLM 接口發(fā)起多 Agent 對話接口能力取決于底層 LLM 服務(wù)常見為 OpenAI 兼容接口或本地推理服務(wù)批量任務(wù)支持通過循環(huán)、異步隊列等方式批量跑實驗需自行編寫調(diào)度邏輯適合人群對 LLM Agent、多智能體協(xié)作、涌現(xiàn)行為感興趣的開發(fā)者與研究者這張表里列出的“顯存占用”“啟動方式”等都強調(diào)“需以實際模型為準(zhǔn)”。原因是 GlossoGen 本身不綁定具體 LLM你可以在 GPT-4o、Claude、DeepSeek 或本地開源模型上跑。實驗?zāi)繕?biāo)不是訓(xùn)練新模型而是分析已有 LLM 在多智能體對話中的行為模式。2. 適用場景與使用邊界這套實驗體系適合三類人。第一類是做 LLM Agent 開發(fā)的工程師。當(dāng)你的系統(tǒng)里有多個 Agent 協(xié)作互相傳遞 prompt 和 response 時你會發(fā)現(xiàn) token 消耗非常大通信過程經(jīng)常包含大量重復(fù)描述。通過分析涌現(xiàn)語言可以設(shè)計更緊湊的通信協(xié)議降低 token 開銷。第二類是做基礎(chǔ)研究的學(xué)生或研究員。你需要探索 LLM 的涌現(xiàn)能力比如它們會不會自主發(fā)明術(shù)語、會不會把長句子壓縮成短語。第三類是對自動化和協(xié)作效率感興趣的開發(fā)者。你可以將“涌現(xiàn)語言”的觀察機制集成到自己的 Agent 日志分析工具中用它發(fā)現(xiàn)協(xié)作瓶頸。但要潑一盆冷水GlossoGen 這個方向目前還不是工業(yè)級解決方案。如果你期望開箱即用直接得到一個“暗號翻譯器”或者“自動協(xié)議生成器”現(xiàn)在還做不到。它的價值更多在于實驗觀察和啟發(fā)。另外運行實驗時要注意合規(guī)邊界你通過 API 發(fā)送給模型的所有 prompt 和返回的 response 都可能被模型提供方的服務(wù)記錄所以不要在其中包含真實用戶隱私、企業(yè)機密或未授權(quán)的第三方數(shù)據(jù)。如果要在生產(chǎn)環(huán)境使用類似邏輯必須加上脫敏、審計和授權(quán)確認(rèn)環(huán)節(jié)。還有一個現(xiàn)實邊界多智能體 LLM 交互容易出現(xiàn)“聊偏了”的情況Agent 之間可能繞來繞去甚至為了“協(xié)作成功”而開始編造一些不存在的術(shù)語導(dǎo)致可讀性變差。這就是涌現(xiàn)語言的負(fù)面效應(yīng)。所以實驗不只是觀察還要設(shè)定評價規(guī)則區(qū)分“有效壓縮”和“無效漂移”。3. 前置概念LLM、Multi-Agent 與 Emergent Language在準(zhǔn)備環(huán)境前先把三個基礎(chǔ)概念串一遍。LLMLarge Language Model是語言模型它根據(jù)輸入的 token 預(yù)測下一個 token。多輪對話中模型狀態(tài)由上下文決定沒有顯式記憶所有歷史交互都靠 token 拼接。Multi-Agent多智能體是指一個系統(tǒng)包含多個獨立的 Agent每個 Agent 有自己的角色、目標(biāo)和上下文。常見架構(gòu)有兩個 Agent 互相辯論、一個規(guī)劃者配多個執(zhí)行者、或者多個 Agent 共享一個黑色板。不同架構(gòu)會產(chǎn)生不同的通信模式。Emergent Language涌現(xiàn)語言是本文重點。在 Multi-Agent LLM 交互中Agent 如果頻繁面臨長上下文和重復(fù)目標(biāo)可能會逐漸縮短表達(dá)例如把請你根據(jù)任務(wù)描述生成 SQL 查詢語句簡化為SQL gen再把SQL gen進一步簡化為SQLG。這種簡化的表達(dá)方式不是開發(fā)者預(yù)設(shè)的而是 Agent 在交互中自發(fā)形成的就叫涌現(xiàn)語言。GlossoGen 這個名稱可能暗示兩個過程Glosso詞匯層面的生成Gen即系統(tǒng)生成了一套新的詞匯表用來在多個 Agent 間高效傳遞信息。實際驗證時可以算一算不同輪次的 token 數(shù)、新詞比例、語義相似度等指標(biāo)來判斷是否出現(xiàn)了“語言壓縮”。4. 環(huán)境準(zhǔn)備與前置條件實驗需要 Python 環(huán)境和可調(diào)用的 LLM。下面是一份通用清單不綁定具體版本。項目建議操作系統(tǒng)Windows 10/11、Ubuntu 20.04、macOS 12Python3.9 以上推薦 3.10 / 3.11依賴庫openai、anthropic、requests、PyYAML、pandas、matplotlibLLM 訪問方式OpenAI 兼容 API、Anthropic API、本地 vLLM / Ollama 服務(wù)網(wǎng)絡(luò)能訪問到模型 API 服務(wù)或本機已啟動推理服務(wù)磁盤空間至少 500 MB 以上日志和結(jié)果文件如果使用本地模型按模型體積另行準(zhǔn)備端口如果需要啟動本地 API 服務(wù)注意不要和其他服務(wù)沖突在安裝依賴時建議用虛擬環(huán)境隔離避免把系統(tǒng)環(huán)境搞亂。# 創(chuàng)建虛擬環(huán)境假設(shè)你在項目目錄下 python -m venv venv # Linux / macOS 激活 source venv/bin/activate # Windows 激活 venv\Scripts\activate # 升級 pip 并安裝依賴 pip install --upgrade pip pip install openai anthropic requests PyYAML pandas matplotlib如果是本地模型推理你還需要安裝對應(yīng)框架例如 vLLM 或 Ollama。這里不展開細(xì)節(jié)因為具體命令取決于你選用的推理服務(wù)。關(guān)鍵是讓 Python 代碼可以通過 HTTP 接口訪問到模型。5. 搭建最小多智能體實驗系統(tǒng)GlossoGen 的實驗核心是讓多個 Agent 反復(fù)協(xié)作完成同一類任務(wù)然后觀察通信語言的變化。這里給出一個最小可運行的模板使用 OpenAI 兼容接口模擬兩個 Agent 的對話。假設(shè)場景是兩個 Agent 合作完成一個自然語言到 SQL 轉(zhuǎn)換任務(wù)。Agent A 負(fù)責(zé)將用戶需求轉(zhuǎn)成“結(jié)構(gòu)化任務(wù)摘要”Agent B 負(fù)責(zé)根據(jù)摘要生成 SQL 查詢。我們先讓它們用完整自然語言溝通運行若干輪后再觀察它們之間的 prompt 是否變短、是否有固定術(shù)語出現(xiàn)。下面用 Python 模擬多輪協(xié)作每次記錄 token 數(shù)和消息內(nèi)容。import time import json from openai import OpenAI # 這里請?zhí)鎿Q成你自己的 API key 和 base_url client OpenAI( api_keyyour-api-key, base_urlhttps://api.example.com/v1 # 如果使用兼容接口替換為實際地址 ) def call_llm(messages, temperature0.0): 調(diào)用 LLM返回回復(fù)內(nèi)容和 token 使用情況 resp client.chat.completions.create( modelyour-model-name, # 替換為實際模型名 messagesmessages, temperaturetemperature, ) content resp.choices[0].message.content usage resp.usage return content, usage def run_cooperation_round(task_description, historyNone): 運行一輪 Agent A 和 Agent B 的協(xié)作 if history is None: history [] # Agent A: 將自然語言任務(wù)轉(zhuǎn)換成結(jié)構(gòu)化摘要 agent_a_messages [ {role: system, content: 你是 Agent A負(fù)責(zé)將用自然語言描述的任務(wù)轉(zhuǎn)換成簡潔的結(jié)構(gòu)化摘要。}, ] history [ {role: user, content: f任務(wù){(diào)task_description}\n請輸出結(jié)構(gòu)化摘要。} ] summary, usage_a call_llm(agent_a_messages) # Agent B: 根據(jù)摘要生成 SQL agent_b_messages [ {role: system, content: 你是 Agent B只根據(jù)摘要生成 SQL。如果摘要不清清請要求補充。}, {role: user, content: f摘要{summary}\n請生成 SQL。} ] sql, usage_b call_llm(agent_b_messages) # 更新對話歷史 history.append({role: user, content: f任務(wù){(diào)task_description}}) history.append({role: assistant, content: f摘要{summary}}) history.append({role: user, content: f生成 SQL{sql}}) return summary, sql, usage_a, usage_b, history # 運行連續(xù)任務(wù)觀察通信長度變化 tasks [ 查詢所有年齡大于30歲的用戶, 查詢所有年齡大于30歲且注冊時間在2023年之后的用戶, 查詢所有年齡大于30歲且注冊時間在2023年之后且訂單總額超過1000的用戶, 查詢所有年齡大于30歲、注冊時間在2023年之后、訂單總額超過1000且最近一次登錄在7天內(nèi)的用戶, ] history [] for i, task in enumerate(tasks): summary, sql, usage_a, usage_b, history run_cooperation_round(task, history) total_tokens usage_a.total_tokens usage_b.total_tokens print(f輪次 {i1}: 摘要長度 {len(summary)} 字符SQL長度 {len(sql)} 字符總token數(shù) {total_tokens})這個模板會讓人直觀看到隨著任務(wù)越來越復(fù)雜摘要長度和 SQL 長度反而可能趨于穩(wěn)定因為 Agent A 會不斷調(diào)整自己的“摘要風(fēng)格”逐漸形成一套更精煉的表述。如果出現(xiàn)固定的短語如“A30 注冊后 訂單超千”那就是涌現(xiàn)語言的雛形。注意上面的openai庫版本和 API 參數(shù)需要根據(jù)實際接口調(diào)整。如果你使用的是 Anthropic API則用對應(yīng) SDK。6. 實驗設(shè)計與效果驗證只跑一輪沒有意義要通過多輪、多組、多指標(biāo)的實驗來驗證涌現(xiàn)語言是否存在。建議按照下面的流程設(shè)計。6.1 定義觀測指標(biāo)至少記錄四類指標(biāo)。指標(biāo)含義數(shù)值方向平均消息長度Agent 交互中每條消息的 token 或字符數(shù)如果出現(xiàn)涌現(xiàn)語言可能先下降后穩(wěn)定特殊術(shù)語出現(xiàn)頻率某些固定縮寫或短語的出現(xiàn)次數(shù)上升說明有語言進化協(xié)作成功率最終輸出是否能正確完成目標(biāo)任務(wù)穩(wěn)定或上升才說明涌現(xiàn)有價值語義相似度摘要是否仍然很好地覆蓋原任務(wù)意圖應(yīng)該保持在較高水平6.2 多組對照實驗至少設(shè)置三組。組1兩個 Agent 使用系統(tǒng)提示詞明確要求“表達(dá)盡量簡潔”觀察是否快速形成協(xié)議。組2兩個 Agent 沒有簡潔要求按默認(rèn)方式工作觀察是否自然涌現(xiàn)。組3使用不同 LLM 模型如一個強模型、一個弱模型觀察語言涌現(xiàn)差異。每組固定相同任務(wù)集跑 30 到 50 輪記錄指標(biāo)最后畫折線圖。6.3 判斷涌現(xiàn)語言的標(biāo)準(zhǔn)符合下面任意兩條就可以說觀測到了涌現(xiàn)語言在任務(wù)語義不變或變化較小的前提下Agent 間的消息長度隨時間顯著下降。出現(xiàn)了不在系統(tǒng)提示詞中定義的新詞、縮寫、編碼方式且被另一個 Agent 正確理解并使用。去掉這些新詞后協(xié)作成功率明顯下降說明它們承載了信息。6.4 常見失敗原因如果跑完看不到任何涌現(xiàn)信號先排查三點任務(wù)是否太簡單Agent 不需要壓縮就能輕松完成對話歷史太長模型遺忘或忽略早期約定兩個 Agent 使用的是不同上下文窗口互相看不到對方的歷史結(jié)論。糾正方式提高任務(wù)復(fù)雜度增加上下文窗口長度或者把前一輪的摘要直接拼到下一輪開頭。7. 接口 API 與批量實驗調(diào)度GlossoGen 這類實驗往往需要跑大量輪次手工一輪輪跑根本不現(xiàn)實。因此要會寫批量調(diào)度腳本并盡可能讓實驗過程支持可配置參數(shù)。7.1 配置化實驗參數(shù)用 YAML 文件管理實驗參數(shù)能避免頻繁修改代碼。experiment: name: glossogen_v1 model: your-model-name api_type: openai # openai / anthropic / local api_base: http://127.0.0.1:8000/v1 temperature: 0.0 rounds: 30 tasks_file: ./tasks.txt output_dir: ./outputs agents: - role: planner system_prompt: 你是規(guī)劃者提煉任務(wù)要點。 - role: executor system_prompt: 你是執(zhí)行者將要點轉(zhuǎn)化為結(jié)果。import yaml import json import os def load_config(path): with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def run_batch(cfg): os.makedirs(cfg[experiment][output_dir], exist_okTrue) with open(cfg[experiment][tasks_file], r, encodingutf-8) as f: tasks [line.strip() for line in f if line.strip()] results [] for round_idx in range(cfg[experiment][rounds]): for task_idx, task in enumerate(tasks): # 這里調(diào)用之前寫好的 run_cooperation_round 函數(shù) result run_single_round(task) result[round] round_idx result[task_idx] task_idx results.append(result) save_jsonl(result, os.path.join(cfg[experiment][output_dir], results.jsonl)) def save_jsonl(data, path): with open(path, a, encodingutf-8) as f: f.write(json.dumps(data, ensure_asciiFalse) \n) if __name__ __main__: cfg load_config(./experiment.yaml) run_batch(cfg)7.2 使用異步并發(fā)控制如果你希望提升實驗速度可以用 Python 的concurrent.futures或asyncio。但要注意模型 API 的 Rate Limit。建議加一個簡單的重試裝飾器遇到 429 或超時自動退避。import time import functools def retry(max_retries3, delay2): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): for attempt in range(max_retries): try: return func(*args, **kwargs) except Exception as e: print(fRequest failed: {e}, retry {attempt1}/{max_retries}) if attempt max_retries - 1: raise time.sleep(delay * (attempt 1)) return wrapper return decorator retry() def call_llm_safe(messages): # 實際調(diào)用代碼 pass7.3 通過 curl 測試 Agent 交互如果你不想寫 Python也可以先用 curl 驗證多輪對話是否能跑通。下面是一個通用示例需要替換實際 API 地址和 key。curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer YOUR_API_KEY \ -d { model: your-model-name, messages: [ {role: system, content: 你是 Agent A輸出任務(wù)摘要。}, {role: user, content: 查詢所有年齡大于30歲的用戶} ] }返回的 JSON 里會包含message.content和usage.total_tokens可以據(jù)此測量語言長度。8. 資源占用與性能觀察運行多 Agent 實驗最敏感的資源是 token 數(shù)量和上下文長度。先說 token 消耗每一輪多 Agent 對話會把之前的歷史全部拼進去如果上下文窗口是 32K跑到 20 輪后很可能把窗口塞滿。這時模型會遺忘早期信息甚至直接報錯。這不是顯存問題而是注意力窗口問題。如果使用本地模型顯存占用主要取決于模型規(guī)模、上下文長度和 batch 大小。一個 7B 模型在 FP16 權(quán)重下大約占用 14 GB 顯存但多數(shù)情況下會用量化版本比如 INT4 量化后約 5-6 GB。這些數(shù)字不是 GlossoGen 本身的數(shù)字而是模型的數(shù)字。實際測試時可以通過nvidia-smi觀察顯存變化。# 每 2 秒刷新一次顯存占用 watch -n 2 nvidia-smi如果顯存不夠優(yōu)先降低上下文長度也就是限制歷史輪數(shù)。不要在實驗里保存無限長的歷史。建議每輪最多保留最近 5 輪對話并把更早的關(guān)鍵信息壓縮成一條“歷史摘要”。另一個觀察點是 API 服務(wù)的響應(yīng)延遲。多 Agent 對話是串行調(diào)用A 的輸出是 B 的輸入如果 A 返回慢整個流程就慢。批量實驗時最好并行跑多組實驗而不是把同一個實驗內(nèi)的多輪并行因為輪次之間往往有依賴。9. 常見問題與排查方法問題現(xiàn)象可能原因排查方式解決方案API 返回 AuthenticationErrorAPI key 無效或權(quán)限不足檢查 key 是否正確確認(rèn)擁有模型訪問權(quán)限重新生成 key或在環(huán)境變量中正確配置請求超時API 服務(wù)繁忙或網(wǎng)絡(luò)延遲高查看日志中的 timeout 時間用 curl 測試連通性增加超時時間加入重試機制或更換網(wǎng)絡(luò)環(huán)境上下文長度超出限制歷史消息累積過多檢查 total_tokens 與模型 context_window 對比裁剪歷史只保留最近幾輪或把歷史壓縮成摘要兩個 Agent 無法互相理解雙方?jīng)]有共享上下文或各自使用了不同 prompt 前綴檢查輸出日志看 Agent B 是否在 Agent A 的消息前加了無關(guān)內(nèi)容統(tǒng)一上下文在 system prompt 中約定通信格式?jīng)]有出現(xiàn)涌現(xiàn)語言任務(wù)過于簡單Agent 不需要壓縮表達(dá)增加任務(wù)復(fù)雜度或讓任務(wù)序列具有重復(fù)模式使用更復(fù)雜的連續(xù)任務(wù)觀察更長輪次顯存不足本地模型過大或 batch 過大用 nvidia-smi 查看顯存使用換量化模型降低 context length減小 batch輸出質(zhì)量不穩(wěn)定temperature 過高或模型隨機性大記錄多個 run 的成功率降低 temperature 到 0或用穩(wěn)定版本模型批量實驗卡住某個 API 請求被限流沒有重試查看日志是否有 429 狀態(tài)碼加入隨機退避重試或降低并發(fā)數(shù)出現(xiàn)問題時先不要改代碼把日志多打幾行。建議記錄每輪調(diào)用的請求體、響應(yīng)體、消耗 token 數(shù)、耗時。這些日志是定位一切問題的最終依據(jù)。10. 最佳實踐與使用建議把這個實驗做得更扎實有幾個工程化建議可以現(xiàn)在就用上。第一第一次先小規(guī)模測試。不要直接跑 50 輪先用 3 個任務(wù)跑 3 輪確認(rèn)日志完整、指標(biāo)能算出來再擴大規(guī)模。多智能體實驗一旦跑偏排查成本會翻倍。第二保留一組“標(biāo)準(zhǔn)對話”作為對照組。比如完全不壓縮的自然語言對話作為基線。后面所有涌現(xiàn)語言的判定都以基線為標(biāo)準(zhǔn)。否則你無法判斷消息變短是語言壓縮還是單純丟信息。第三把實驗配置、模型版本、API 版本全部寫進輸出文件。涌現(xiàn)語言實驗對模型版本非常敏感同一個實驗換成不同模型結(jié)果可能完全不一樣。建議每次實驗都記錄model、temperature、max_tokens、system_prompt并用哈希值標(biāo)記實驗批次。第四批量任務(wù)要加日志和失敗重試。網(wǎng)絡(luò)抖動非常常見。如果 50 個任務(wù)里有一個超時不重試會讓整個數(shù)據(jù)集缺一塊。建議使用 JSONL 逐行追加寫入結(jié)果這樣中途斷了也能接著跑。第五接口服務(wù)要注意訪問控制。如果你把 Agent 服務(wù)部署到服務(wù)器上跑實驗不要把端口直接暴露在公網(wǎng)。至少加一層訪問令牌或者綁定 127.0.0.1 只允許本機訪問。第六涉及版權(quán)、隱私、肖像的內(nèi)容要格外小心。雖然 GlossoGen 實驗主要處理文本任務(wù)但如果你把真實用戶對話、內(nèi)部文檔作為任務(wù)輸入就存在數(shù)據(jù)合規(guī)問題。建議用公開數(shù)據(jù)集或自行構(gòu)造的任務(wù)集不要拿敏感信息做實驗。第七發(fā)布或商用前要做效果復(fù)核。涌現(xiàn)語言可能有趣但并不總是正確。如果想讓 Agent 之間使用簡寫協(xié)議來降低 token 消耗必須人工檢查這些簡寫是否穩(wěn)定、有沒有歧義、會不會在不同任務(wù)里產(chǎn)生誤解。最好在每次協(xié)議變更后跑一遍回歸測試。11. 總結(jié)與下一步GlossoGen 這個方向的核心吸引力不在于訓(xùn)練一個新模型而在于觀察和利用多智能體之間的自發(fā)語言行為。通過今天這套最小實驗流程你可以在任意 LLM 上復(fù)現(xiàn)“兩個 Agent 通過縮寫和術(shù)語協(xié)作完成任務(wù)”的現(xiàn)象。需要優(yōu)先驗證的功能很簡單跑一組連續(xù)任務(wù)看消息長度是否下降、協(xié)作成功率是否保持、是否出現(xiàn)特殊詞匯。最容易踩的坑是上下文窗口溢出以及把 token 下降誤判為語言涌現(xiàn)而忽略任務(wù)完成質(zhì)量。下一步如果你想深入可以做三件事一是把觀測指標(biāo)擴展到語義向量空間用 embedding 相似度判斷“摘要是否仍然覆蓋原意”二是把兩個 Agent 擴展到三個角色觀察語言是否會逐漸演化為“中間層協(xié)議”三是把你自己的工具鏈加進來比如讓 Agent 在調(diào)用外部工具時自動把參數(shù)名壓縮成短碼。這些方向都建立在今天這套日志、指標(biāo)和批處理之上。如果你對多智能體協(xié)作、LLM 行為分析感興趣可以把這個實驗框架在本地跑一下。不需要很強的顯卡用云 API 就能完成。整套代碼控制在兩百行左右非常適合周末實驗。建議收藏備用后續(xù)有新的觀測指標(biāo)或復(fù)現(xiàn)結(jié)果可以繼續(xù)迭代完善。