北京
我坐在屏幕前，打開a2a-benchmark的提交日志，那行“N=22”像根刺扎在眼里。這套跨語言的Agent-to-Agent性能套件跑了快一年，結果就卡在第22個梅森素數上，Python那一欄永遠干干凈凈——不是慢，是根本不給數。一股無名火躥上來，我開始剖代碼，一剖就剖出九個讓人血壓飆升的Bug。
先說最離譜的那個：CPython 3.11以后，整數轉字符串默認上限4300位。官方說法是防拒絕服務攻擊，但在我這兒，這個限制直接把第24個梅森素數給封殺了。M(19937)有6002位，我的Python代理偏偏要把它轉成字符串存進列表，一行mersenne_primes.append(str((1 << p) - 1))，踩個正著。于是代理不返回計算結果，只甩回一坨“Exceeds the limit (4300 digits)...”的棧跟蹤文本。翻看歷史數據，N≥24的那一列不是缺失，是從根上就不可能產數。更可笑的是，我從來沒有真正用過這個字符串列表，工具只返回耗時，修復方法就是刪掉那個str()，順便把再也不會被用到的死代碼清理干凈——Go那邊也有個一模一樣的val.String()白算一場。一行刪減，換回整列復活。
以為定時函數就沒坑？第二個Bug教我做人。time.time()取的是墻上時鐘，非單調，系統時間一跳，我的基準就跟著歪。Python代理里還混著一套雙軌計時：結構化構件里有個規規矩矩的elapsed_time，而模型輸出的自然語言里又夾著另一套時間。采集程序偏偏先去正則匹配“It took...seconds”，Gemini一時興起說“Calculating the first 5 Mersenne primes took 4.9591064453125e-05 seconds.”，一時又換成“The calculation took 2.40715261301375 seconds.”，哪句也踩不中那個正則。數據沒全崩，全靠一個保底分支才把構件里的真計時撈回來。計量數據淪落到依賴語言模型當天的心情造句，這膽子也太肥了。我直接把計時函數換成time.perf_counter()，采集邏輯也調了個頭：優先讀結構化構件，文本匹配當最后的救命稻草。
接下來三個Bug排著隊來扇我臉。Node.js和Rust代理，計時輸出用了四舍五入的毫秒格式——toFixed(2)——結果10微秒以內的運行被印成“0.00ms”，解析成0.0，進了對數圖直接消失在基線里，連個影都留不下。這倆代理還都滿嘴跑火車，指數表里明明只有26個素數，你請求“前100個梅森素數”，它張口就答“Found first 100 Mersenne primes”，而實際上只算了26個，撒謊不打草稿。更要命的是，這份數據被拎去畫了張往返時延對比圖：Python和Go走過Gemini工具調用通路，Node和Rust直接算，兩邊壓根不在一個世界里，圖卻把它們糊在同一張畫布上，比誰快誰慢簡直荒謬。
清單一拉到底，九個坑我排在這里：一個4300位截斷直接封死整列數據；一個墻鐘替代單調時鐘讓計時漂移；一個依賴大語言模型措辭來提取數值；一個微秒級歸零讓散點隱沒；一個謊報計算數量污了報告；一個通道差異讓對比圖全無意義；再加上兩個語言端無用的字符串化拖累性能。每一樁都指向一個更根本的問題——寫基準的人總愛在定時區域外做多余操作，讀數路徑又東取一處西撿一句，最后還把不同執行模型端到一張坐標紙上硬比。
這套修復現在全塞進了三個拉取請求里：刪str()切perf_counter加回歸測試，采集邏輯翻修讓結構化值優先，代理老老實實匯報primes.length，輸出精度提到四位小數。一年盲區，幾行刪改就亮回來，我自己都氣笑了。寫基準這件事，別信任何隱性的“反正用不到”，也別把計量通道交到模型的心情手里，所有不在同一跑道上的對比都是耍流氓。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
