標題：“索引還是不索引：選擇哪種編碼代理？”

已發布：真實

描述：“使用阿波羅 11 號的飛行程式碼，對索引型和無索引型 AI 編碼代理進行正面對比實驗。探索在月球規模的編碼中，哪種方法更快、更可靠、更安全。”

標籤：javascript、討論、devops、ai

canonical_url：「https://forgecode.dev/blog/index-vs-no-index-ai-code-agents/？utm\_source=devto&utm\_medium=blog&utm\_campaign=canonical\_url&utm\_content=canonical\_link」

TL;DR：索引代理的速度提高了 22%，直到陳舊的嵌入導致月球著陸器墜毀。

我測試了兩個人工智慧代理，用於阿波羅 11 號的實際飛行程式碼，以了解程式碼索引是否會產生影響。主要發現：

事實證明，索引搜尋速度提高了 22%，API 呼叫減少了 35%

兩人都完美地完成了全部 8 項挑戰

登月期間索引代理的同步問題揭示了保持嵌入最新的隱藏複雜性

速度的提高伴隨著可靠性和安全性的犧牲，這可能會降低生產力。

🚀嘗試 AI Shell

>

您的智能編碼伴侶可無縫整合到您的工作流程中。

登入 Forge →

阿波羅 11 號任務的背景故事

三十八秒！

在將駕駛艙交還給尼爾·阿姆斯特朗和巴茲·奧爾德林之前，微型阿波羅導引電腦（AGC）所能騰出的全部時間都用於控制速度。 1969年7月20日的這38秒裡，鷹號飛船以每秒兩米的速度向月球下降，這加大了它與指令艙中邁克爾·柯林斯的距離，會合雷達不斷向CPU發送垃圾訊息，DSKY螢幕上“1202”警報持續閃爍。

然而，登月艙內部，卻有一台鞋盒大小的計算機，內存約為 4 KB（總 72 KB 的 Route ROM 中） ¹，比智慧型手機上的單一聯絡人條目還小。它自行重啟，擺脫了低優先級任務，重新掌控了前往寧靜基地的導航和導航。

那次救援並非靠運氣，而是軟體工程。

幾個月前，在馬薩諸塞州沃爾瑟姆一個安靜的工坊裡，女裁縫師協助開發了一項非常重要的任務所需的軟體。她們小心翼翼地將電線穿過被稱為「磁芯」的磁環。

它的工作原理如下：

為了表示「1」（二進位程式碼），他們將一根電線穿過一根磁芯。

為了表示“0”，他們將電線繞在磁芯周圍。

他們每縫一針，就建立一行電腦程式碼。他們總共編織了大約4000行這種特殊的「彙編」程式碼，創造了永久的、不可更改的記憶。

<

圖形樣式="margin: 0; padding: 0;">

阿波羅導引電腦繩索記憶體的特寫，展示了手工編織的複雜導線穿過磁芯的情況。每條導線代表二進位程式碼－穿過磁芯代表“1”，繞過磁芯代表“0”。圖片來源：雷神公司/麻省理工學院

這個手工製作的記憶體包含關鍵程式：

• 程序 63-67 用於太空船的下降。

• 程式 70-71 是為從月球起飛而設計的。該系統將所有電腦任務都集中在 20 毫秒的微小時間段內。其關鍵特性之一是“重啟保護”，這項功能允許電腦在崩潰後恢復，而不會忘記正在執行的操作。

程式碼的一小步…

當塵埃落定，阿姆斯特朗透過無線電通訊說：「休斯頓，這裡是寧靜號基地。鷹號已著陸。」他也是在向一支隱形的團隊致敬：由瑪格麗特·漢密爾頓領導的程式設計師們，他們將 36kWords 的 Rope ROM 變成了第一個發送到地球之外的容錯實時操作系統。

<

圖形樣式="margin: 0; padding: 0;">

<

figcaption 樣式="margin-top: 0; font-size: 0.9em;">

<em>Margaret Hamilton standing next to the Apollo Guidance Computer source code printouts, circa 1969. Photo: NASA/MIT (Public Domain)</em>

從 20 世紀 60 年代的組裝到現代人工智慧

AGC 面臨的根本挑戰與我們如今在處理遺留程式碼庫時遇到的挑戰如出一轍：如何在浩瀚的程式碼海洋中快速找到相關資訊？阿波羅程式設計師透過細緻的文件、標準化的命名約定和精心建構的模組解決了這個問題。但是，當我們將現代人工智慧置於同樣的問題中時，會發生什麼事？

我沒有親自花數月時間學習 20 世紀 60 年代的彙編語言來操作阿波羅 11 號程式碼庫，而是決定進行一項實驗：讓兩個現代人工智慧代理應對挑戰，並比較它們的效率。這兩個代理程式都執行在完全相同的語言模型 Claude 4 Sonnet 上，因此唯一的變數是它們的資訊檢索方法。

這不僅僅是一項學術活動。了解程式碼索引是否真的能提升人工智慧的效能，對於我們如何建構開發工具、文件系統和程式碼分析平台有著切實的意義。市場上充斥著數百種編碼代理，每一種都聲稱透過專有的「上下文引擎」和向量搜尋能夠提供卓越的程式碼理解能力，這導致開發人員面臨分析癱瘓的困境。這項實驗透過測試驅動大多數此類工具的核心假設來消除行銷噪音：索引能夠從根本上提升人工智慧代理的效能。

我特意隱去了產品名稱，因為這篇文章主要討論的是技術本身，而不是針對廠商的攻擊。所以，在本文的其餘部分，我將泛指這些工具：

1. 索引代理：建立整個程式碼庫的索引並使用向量搜尋為模型提供相關片段。

2. 無索引代理：依賴沒有任何預建索引的迭代推理循環。

目的是衡量在分析大型、不熟悉的程式碼庫時，程式碼索引是否能提高答案品質、回應時間和令牌成本，僅此而已。

👨‍🚀從月球任務到你的程式碼庫

讓您自己的編碼助理完成您的下一個軟體任務。

👉 存取您的 Forge 儀表板

阿波羅 11 號挑戰套房

為了公平地測試這兩個代理，我執行了八個複雜程度各異的挑戰，從簡單的事實查找到複雜的程式碼分析。前七個是事實調查，第八個是編碼練習。每個挑戰都需要深入探索 AGC 程式碼庫才能正確回答。

係好安全帶；下一個軌道是圍繞著一個真正到達月球的程式碼庫。

挑戰1：任務優先分析

在 AGC 調度系統中，可以指派給任務的最高優先權是多少（八進制，2 位數字）？ （提示：查看優先權位元模式和 NOVAC 呼叫）

挑戰2：鍵盤控制

控制太空人和電腦之間所有使用者介面操作的檔案的絕對奇妙的名稱是什麼？

挑戰3：記憶體架構

AGC 中每個可擦除儲存庫的大小是多少（以十進位字表示）？

挑戰 4：俯仰、滾轉、偏航

AGC 的姿態控制系統每 100 毫秒觸發三個控制迴路，分別控制俯仰 (Q)、滾轉 (P) 和偏航 (R)。它們的執行順序是什麼？請用括號依字母順序標明同時執行的迴路。

挑戰5：雷達的局限性

交會雷達能夠可靠追蹤目標的最大範圍是多少（以海裡為單位）？四捨五入到最接近的百位數。

挑戰6：處理器時序

AGC處理器的基本機器週期時間是多少微秒？ （這決定了所有操作的基本時間）

挑戰 7：引擎節流

下降推進系統在動力下降過程中可以維持的最小油門設定（百分比）是多少？

挑戰 8：登陸登月艙！

終極測試。阿波羅導引電腦擁有多種月球下降模式。尼爾阿姆斯壯使用 P66（手動導引）模式將實際太空船降落在月球上。你的任務：在特務的幫助下使用 P65（全自動導引）。

完成以下步驟：

1. 將P65制導演算法轉換為Python或Javascript

2. 使用提供的 test_descent.py 或 test_descent.test.js 檔案測試功能

3. 使用提供的 simulator.py 或 simulator.js 文件，執行你的演算法並登陸月球

4. 提交您的最終位置座標作為 simulator.py 或 simulator.js 的輸出

結果：速度與同步的權衡

在兩個代理完成所有八個挑戰之後，結果揭示了一些重要的東西：兩種方法都成功完成了每個挑戰，但它們暴露了索引方法中一個很少被討論的關鍵弱點：同步漂移。

以下是它們的堆疊方式：

績效指標

他們的表現如下：

<

表格>

<tr>

  <th>Metric</th>

  <th>Index Agent</th>

  <th>No-Index Agent</th>

  <th>Improvement</th>

</tr>

<tr>

  <td>Average Response Time</td>

  <td>49.04 seconds</td>

  <td>62.89 seconds</td>

  <td>Index 22% faster</td>

</tr>

<tr>

  <td>Total API Calls</td>

  <td>54 calls</td>

  <td>83 calls</td>

  <td>Index 35% fewer</td>

</tr>

<tr>

  <td>Accuracy Rate</td>

  <td>8/8 correct</td>

  <td>8/8 correct</td>

  <td>Same</td>

</tr>

Index Agent 在大多數挑戰上表現更好，但這種速度優勢伴隨著隱性成本：同步複雜性可能會將您的生產力提升轉化為除錯會話。

挑戰分解

<

表格樣式="寬度：100%；邊框折疊：折疊；">

<tr>

  <th style="width:22%; padding:8px;">Challenge</th>

  <th style="width:28%; padding:8px;">Answer</th>

  <th style="width:25%; padding:8px;">Index Agent</th>

  <th style="width:25%; padding:8px;">No-Index Agent</th>

</tr>

<tr>

  <td style="padding:8px;">1: Task Priority Analysis</td>

  <td style="padding:8px;">37</td>

  <td style="padding:8px;">18.2s, 3 calls</td>

  <td style="padding:8px;">55.46s, 13 calls</td>

</tr>

<tr>

  <td style="padding:8px;">2: Keyboard Controls</td>

  <td style="padding:8px;">PINBALL_GAME_BUTTONS_AND_LIGHTS.agc</td>

  <td style="padding:8px;">20.7s, 5 calls</td>

  <td style="padding:8px;">25.29s, 8 calls</td>

</tr>

<tr>

  <td style="padding:8px;">3: Memory Architecture</td>

  <td style="padding:8px;">256</td>

  <td style="padding:8px;">22.1s, 5 calls</td>

  <td style="padding:8px;">24.2s, 7 calls</td>

</tr>

<tr>

  <td style="padding:8px;">4: Pitch, Roll, Yaw</td>

  <td style="padding:8px;">P(QR)</td>

  <td style="padding:8px;">36.61s, 4 calls</td>

  <td style="padding:8px;">71.30s, 4 calls</td>

</tr>

<tr>

  <td style="padding:8px;">5: Radar Limitations</td>

  <td style="padding:8px;">400</td>

  <td style="padding:8px;">28.9s, 2 calls</td>

  <td style="padding:8px;">82.63s, 14 calls</td>

</tr>

<tr>

  <td style="padding:8px;">6: Processor Timing</td>

  <td style="padding:8px;">11.7</td>

  <td style="padding:8px;">30.87s, 7 calls</td>

  <td style="padding:8px;">51.41s, 10 calls</td>

</tr>

<tr>

  <td style="padding:8px;">7: Engine Throttling</td>

  <td style="padding:8px;">10</td>

  <td style="padding:8px;">23.68s, 3 calls</td>

  <td style="padding:8px;">36.05s, 9 calls</td>

</tr>

<tr>

  <td style="padding:8px;">8: Land the Lunar Module</td>

  <td style="padding:8px;">[28.7, -21.5, 0.2] ✅ LANDED</td>

  <td style="padding:8px;">211.27s, 25 calls ⚠️</td>

  <td style="padding:8px;">156.77s, 18 calls ✅</td>

</tr>

注意：索引代理的登月慘敗表明了快照為何會產生反噬：它拉出了舊的嵌入，引用了不再存在的文件，並且僅在執行時失敗，浪費的時間比它節省的時間還要多。

速度的隱性成本：當索引背叛你時

故事的轉折點在於：兩個代理都成功登陸月球，但索引代理的路徑卻暴露出一些根本性問題，而這些問題大多數關於程式碼索引的討論要么忽略了，要么沒有得到充分重視。效能提升是實實在在的，但隨之而來的是同步和安全成本，這可能會降低生產力。

主要問題：同步：程式碼索引是凍結在時間中的快照。一旦程式碼庫發生變化，而且程式碼庫會持續變化，索引的錯誤率就會逐漸增加。與可能返回過時結果的傳統搜尋不同，使用過時索引的 AI 代理可以自信地使用虛擬 API 生成程式碼，引用已刪除的函數，並提出上周有效但今天失效的模式。

在挑戰 8 中，這一點得到了清晰的體現：索引代理從先前的測試執行中檢索了函數簽名的嵌入，並使用這些簽名生成了語法正確的 Python 程式碼，並且僅在程式碼執行時才發現不匹配。無索引代理雖然速度較慢，但始終基於程式碼庫的當前狀態執行，並且從未產生呼叫不存在方法的程式碼。

當同步出現錯誤時：

• 幻影依賴項：AI 建議匯入已刪除的模組

• API 漂移：產生的程式碼使用已變更的舊函數簽名

• 棄用的模式：索引傳回你的團隊已經放棄的反模式範例

• 死程式碼建議：AI 建議呼叫索引中存在但已從實際程式碼庫中刪除的函數

次要考慮因素：安全性權衡：大多數第三方索引服務需要將您的整個程式碼庫傳送到其基礎架構，才能建立那些閃電般快速的向量搜尋。這帶來了額外的考慮：

• 程式碼暴露：您的專有演算法可能會被第三方看到

• 合規性要求：許多產業（金融、醫療保健、國防）禁止外部程式碼共享

• 智慧財產權風險：理論上，競爭對手可以洞察你的實施方法

自託管索引可以解決安全性問題，但會帶來操作複雜性：維護向量資料庫、嵌入模型和刷新機制。它是一種兼顧速度和安全性的中間方案，但需要大量的 DevOps 投資。

開發者體驗：你除錯了幾個小時，卻發現人工智慧肯定是錯的，因為它執行的是昨天的程式碼庫。如果快速的回應時間讓你基於過時的資訊走上死胡同，那就毫無意義了。而且，如果你處在一個受監管的環境中，無論第三方索引服務的同步品質如何，你甚至可能無法使用它們。

無索引的優點：雖然 API 呼叫速度較慢且成本較高，但無索引方法完全避免了同步和安全性問題。它始終引用程式碼的當前狀態，不會受到上週重構快取嵌入的影響，所有處理都保持在本地進行，並且在遇到真正問題時快速失敗，而不是基於過時的上下文來建立解決方案。

這表明真正的選擇不僅僅是速度與成本之間的權衡，而是效能、可靠性和安全性之間的三方權衡。

實際意義：索引代理在大多數挑戰中表現較佳，平均反應速度提升 22%，API 呼叫次數減少 35%。兩種代理在靜態場景下的準確率相當，但關鍵差異體現在動態場景中，即程式碼狀態自索引建置以來發生了變化。

開發人員 vs. 同步：索引代理確實能提升效率，但隨之而來的是可靠性成本，這在快速變化的程式碼庫中可能是毀滅性的。如果同步失敗，額外的除錯時間通常會抵消掉最初的速度優勢。

結論：平衡性能、可靠性和安全性

阿波羅 11 號導引電腦從不使用過時的資料，每個決策都基於即時感測器讀數。現代 AI 編碼代理面臨著同樣的根本挑戰，但有一個特點：索引代理無疑具有成本效益，響應速度提高了 22%，API 呼叫次數減少了 35%。但問題在於？遠端程式碼索引可能會導致同步問題，使生產力的提升變成除錯的噩夢。

結果揭示了性能、可靠性和安全性之間的三方權衡。雖然索引方法在速度和成本效益方面表現出色，但它們引入了同步風險，當索引落後於實際情況時，可能會降低生產力。我們觀察到的「登月效應」——過時的嵌入會導致幻影 API 呼叫——說明了為什麼不同步的索引比沒有索引更危險。

前進的道路是什麼？選擇一個能夠快速建立索引的代理程式（最好是本地的），並確保索引永遠不會不同步。這意味著要尋找能夠提供以下功能的解決方案：

• 即時索引更新，即時追蹤程式碼更改

• 本地處理，避免向第三方發送專有程式碼的安全風險

• 當索引置信度下降時發出警告的陳舊檢測

• 當同步不確定時，混合回退會切換到直接程式碼分析

阿波羅 11 號導引電腦之所以成功，是因為它從不使用過時的資料，也從不將關鍵任務演算法暴露給外部各方，每個決策都基於最新的感測器讀數和完全內部生成的即時計算。現代人工智慧開發工具需要對資料的新鮮度和安全性做出同樣的雙重承諾，否則它們可能會讓我們輕鬆選擇過時的解決方案，或暴露我們最寶貴的程式碼。

社區實驗

想親自測試一下嗎？完整的阿波羅 11 號挑戰套件可從以下網址取得：https://github.com/forrestbrazeal/apollo-11-workshop

如果您希望我在您的程式碼庫上執行此實驗，請在評論中留下連結。我特別想在更大、更現代的程式碼庫上進行測試，看看這些模式是否具有可擴展性，以及「登月」效應是否在其他領域也會出現。

您是否進行過類似的實驗來比較 AI 方法？我很想聽聽您的發現。

致謝

這個實驗的靈感來自於@forrestbrazeal 在 2025 年人工智慧工程師世界博覽會上的精彩演講。這裡探討的具體挑戰就取自那次演講。

AGC 程式碼本身仍然是歷史上最傑出的軟體工程成就之一，它證明了在可以想像到的最極端的約束條件下，精心的規劃、嚴格的測試和優雅的設計能夠取得怎樣的成就。所有 AGC 原始碼均屬於公共領域。

原文出處：https://dev.to/forgecode/to-index-or-not-to-index-which-coding-agent-to-choose-27pb