.@trailofbits 的 Buttercup 團隊現在在 AIxCC 舞台上談論我們的競爭策略。這是我們的核心團隊（8 名核心成員 + 約 3 名雇傭兵）:

我們的策略指導原則。簡而言之，使用最適合工作的工具。不要期望大型語言模型在我們知道它們不擅長的事情上表現得神奇出色。

原始的 Buttercup 設計要複雜得多。它被簡化以遵守規則，並考慮到我們團隊的資源限制。

我們在半決賽中表現相當出色，取得了許多首殺，但我們的 Java 錯誤檢測工具壞了，我們仍然不知道為什麼！

半決賽驗證了我們的整體方法，但需要調整以適應決賽的巨大規模增長。我們丟掉了原型，從頭開始為決賽做準備。

Henrik 在協調器上工作：如何、什麼時候以及何時提交到競賽 API。我們決定始終要求提供 PoV，以最大化我們對提交的信心。

運行在我們的漏洞發現引擎上。我們使用了標準的 oss-fuzz 測試工具。我們使用了一個共享的語料庫，其中 LLMs 協助測試工具獲得覆蓋率。

Ronald 在我們的漏洞發現引擎上工作。我們使用了標準的 oss-fuzz 測試工具。我們使用了一個共享的語料庫，LLMs 協助測試工具獲得覆蓋率。

Ronald 在我們的漏洞發現引擎上工作。我們使用了標準的 oss-fuzz 測試工具。我們使用了一個共享的語料庫，LLMs 協助測試工具獲得覆蓋率。

這個修補程式是一個多代理系統，包含6千行代碼，使用LangChain/LangGraph，並且不進行推理的GPT-4.1。安全代理識別根本原因，工程師代理找到測試指令，然後QA代理進行修補並驗證。如果失敗，反思代理會調整策略。

在展覽回合中，我們在第一回合首先得分，在第二回合遭遇重創，然後在第三回合反彈。我們在第一回合資源使用效率高，只用了 $1k 的 $30k LLM 預算。在第二回合，我們有一個小錯字導致一切崩潰。

在評分回合中，我們在有限的預算（可用預算的一半）下發現了很多漏洞，準確率很高，並且在所有任務中得分良好。我們還發現了至少一個其他CRS沒有發現的漏洞，顯示我們開拓了新領域。

我們是怎麼得分這麼高的？我們的準確率達到90%，在所有任務中得分，並為我們的所有錯誤製作了高品質的修補程式。

我們花了上個月的時間製作一個可以在你的筆記本電腦上運行的縮小版 buttercup。我們打算用一部分獲利來維護它。現在它是開源的！