什麼是 harness engineering？為什麼你應該在意？

什麼是 harness engineering？為什麼你應該在意？ 要如何在完全沒有手動撰寫任何程式碼的情況下，交付一個軟體產品？ 今天有位朋友問了我這個問題，我才發現自己沒有一個簡單的答案。所以我進一步深入研究。 結果發現，答案就在於你如何設計 harness。 作者：@shirmeir86 等等，現在是怎樣？什麼是 harness engineering？ 這之所以成為目前 coding agent 領域最重要的趨勢，是有原因的。現今最大的問題是：如何在不用逐行閱讀的情況下，驗證 AI 產生的程式碼？要怎麼確保 Agent 不會弄壞正式環境，或刪除你的資料？ 我最近讀到一個很有意思的實驗：一個由 3 位工程師組成的團隊，在完全沒有手動撰寫任何程式碼的情況下，建立並發布了一個軟體產品的內部 beta 版本。每一行程式碼——應用程式邏輯、測試、CI 設定、文件、可觀測性，以及內部工具——全部都是由 Codex 撰寫的。 他們是怎麼做到的？他們沒有撰寫應用程式，而是設計了 harness。 harness 究竟是什麼？ 把 AI Agent 想成一匹強大的賽馬。harness 就是賽道、眼罩，以及騎師手中的韁繩，讓它朝正確的方向前進，而不是跳進觀眾席。 正如我的同事 Arthur Thompson 今天所說：對 Agent 而言，harness 是由所有包覆 LLM 的確定性元件組成。 Balaji Subramaniam 在他的部落格中詳細介紹了這些確定性元件——協調層、執行沙盒、狀態持久化，以及驗證工具。 如果你想建立可靠的 agentic 系統，你的工作重心就會從撰寫邏輯，轉變為設計環境。以下是你需要專注的幾件事： 設定嚴格的界線：不要讓 Agent 猜測自己可以碰哪些東西。強制套用嚴格的存取規則（例如把它限制在特定沙盒內），避免它不小心清除正式環境中的資料。 建立「Repair Loop」：Agent 遲早會犯錯。一個優秀的 harness 會自動捕捉錯誤，例如建置失敗或測試失敗，然後把乾淨的日誌直接回傳給 Agent，讓它自行修正程式碼。 給它地圖，而不是操作手冊：正如 OpenAI 團隊所發現的，不要用大量的指示文件淹沒 Agent。應該有邏輯地組織程式庫，讓 Agent 在工作過程中逐步自行探索所需的 context。 讓我看看程式碼 實務上會長什麼樣子？以下是一個使用 Google Antigravity SDK 搭配 Google 的 ADK，設定本機 harness 的簡單範例。請注意，我們嚴格將 Agent 限制在特定的 workspace（workspaces=[“./sandbox”]）中，並提供儲存記憶的位置（save_dir=”./trajectories”），讓它能從過去的經驗中學習。 `python import os from google.adk.labs.antigravity import AntigravityAgent from google.antigravity import LocalAgentConfig from google.antigravity.hooks import policy Ensure absolute paths for workspace containment sandbox_dir = os.path.abspath("./sandbox") os.makedirs(sandboxdir, existok=True) save_dir = os.path.abspath("./trajectories") Engineer the harness environment sdk_config = LocalAgentConfig( system_instructions="You are a helpful local environment assistant.", workspaces=[sandbox_dir], Let the agent write safely within the restricted sandbox boundary policies=[policy.allow_all()], savedir=savedir, ) Wrap the config to run the agent inside the harness root_agent = AntigravityAgent( name="antigravity_assistant", description="Runs an Antigravity SDK agent inside ADK.", config=sdk_config, ) ` 說明 AI Agent 權限控管機制的架構圖，左側為藍色的 AI Agent，右側上方以綠色框顯示可寫入的 ./sandbox folder，中間與下方則以虛線及紅色框顯示遭到政策阻擋的 Production Database 與 Host System Files。 展開畫面重點- 圓形節點「AI Agent」 實線箭頭連接至綠色長方形「./sandbox folder」，上方標籤為「Writes Code」 虛線箭頭連接至紅色圓柱體「Production Database」，上方標籤為「Blocked by policy」 虛線箭頭連接至紅色長方形「Host System Files」，上方標籤為「Blocked by policy」 完成這樣的設計後，你可以把既有程式碼放進沙盒，寫一個簡單的迴圈對它執行單元測試，接著讓 Agent 反覆修正自己的錯誤。 加入測試 那麼，我們實際上要如何對這個受沙盒限制的 Agent 執行測試？ 在現代的 harness engineering 中，測試是 Agent 工作流程圖中的主動元件。使用 Google 的 ADK 2.0——它引入了以圖為基礎的工作流程——你可以把測試驗證步驟定義成一個簡單的路由節點。 如果測試通過，工作就完成了。如果測試失敗，harness 會自動把錯誤回傳給 Agent，讓它再試一次。請注意內建的「kill switch」：我們會追蹤迭代次數，因此如果 Agent 卡在不斷弄壞、修正程式碼的無限迴圈中，harness 就能安全地中止執行。 `python from google.adk.agents.context import Context from google.adk import Event from google.adk.events.event_actions import EventActions from google.genai import types Evaluate the code in the sandbox def executiontestnode(ctx: Context): Safely track our attempts to prevent infinite loops iterationcount = ctx.state.get("iterationcount", 0) + 1 ctx.state["iterationcount"] = iterationcount testpassed = ctx.state.get("testpassed", False) feedback = ctx.state.get("feedback", "") if test_passed: Success! End the workflow. return Event(actions=EventActions(route="END")) if iteration_count > 5: The Kill Switch: The agent is stuck. Stop the loop. return Event(actions=EventActions(route="END")) Failure! Feed the error trace back to the agent and loop it. feedback_msg = f"The unit tests failed with the following traceback:\n\n{feedback}" return Event( cont…