# 策展 · X (Twitter) 🔥🔥🔥

> 作者：Petra Donka (@petradonka) · 平台：X (Twitter) · 日期：2026-05-15

> 原始來源：https://x.com/petradonka/status/2054897826149101588

## 中文摘要

# Agent 需要的是回饋迴圈，而不是完美的 Prompt

對於從事需要高度判斷力工作的 Agent 來說，初始的 Prompt 僅僅是個開端。最優秀的 Agent 會從團隊身上學習什麼才是「好的表現」，並隨著時間推移不斷自我優化。

每個人都在嘗試為 Agent 編寫更好的 Prompt。雖然這很有用，但卻忽略了一個重要的挑戰：你今天寫出的最佳 Prompt，一個月後可能就不再是最佳版本了。

你的產品會變，你的使用者會變，你團隊的品味也會隨時間而精進，新的邊緣案例（edge cases）更會不斷出現。如果 Agent 執行的工作需要判斷力和品味，那麼沒有任何靜態的 Prompt 能涵蓋它未來所需的一切知識。

這將問題從「我們該如何寫出完美的 Prompt？」轉變為「我們該如何打造出能在發布後持續向團隊學習的 Agent？」

我們在 Warp 開發一個 Agent 時就遇到了這個問題，該 Agent 的任務是協助我們的開發者體驗（Developer Experience）團隊回應在 Twitter、Reddit 和其他管道提到我們的使用者。我們熱衷於與使用者交流 Warp 的相關話題，傾聽他們的問題與回饋，並非常重視對那些談論我們的人給予回應。我們的社群成員每週會產生超過一千則提及（mentions）！這遠超過任何小型團隊能手動處理的對話量。

## 那些「差點就能用」的 Agent 所面臨的挑戰

在許多 Agentic 程式開發中，核心迴圈非常直觀：Agent 嘗試執行某件事，檢查是否成功，然後重試。如果是在撰寫程式碼，通常會有具體的訊號可供參考：測試、建置、瀏覽器檢查、指令輸出等。

但社群回覆並非如此運作，因為 Agent 沒有一個合理的「外部檢查機制」可用。它無法發送一堆公開回覆，然後等待觀察人們對我們的信任度是增加還是減少，進而推斷品牌語氣是否正確，最後再進行重試。這個回饋迴圈太長、雜訊太多且代價太高。這同樣適用於公司內部許多有用的工作：客戶開發、支援回覆、程式碼審查意見、產品回饋分析、文件撰寫、招募訊息。這些工作都需要判斷什麼才是重要的，以及何時不該採取行動。

我們看過許多 Agent 卡在這種狀態：它們「差點就能用」。它們顯然具備能力，輸出的內容也足以讓你抱持希望，但卻不足以讓你信任。團隊只能不斷調整 Prompt，期待下一個版本能縮小差距。

我認為這是錯誤的抽象層級。讓 Agent 完成一次任務並不是最困難的部分，困難的是建立一個系統，讓 Agent 能從團隊現有的工作方式中不斷進步。

## 我們打造的 Agent

我們將這個 Agent 命名為 Buzz。Buzz 會監控 Warp 在 Twitter、LinkedIn 和其他平台上的提及。當有新的提及出現時，它會決定我們應該回覆、按讚、記錄還是略過。如果需要回覆，它會草擬訊息並將建議發送到 Slack。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778807370311-iaHIRTwg2WAAENTwIjpg.jpg)

最終，每一則回覆仍然是由我們親自撰寫，但光是這樣就節省了大量時間：團隊不再需要盯著每個平台、打開每個討論串、判斷每則提及是否重要，以及從零開始撰寫每一則回覆。我們希望在不犧牲寶貴的互動品質或損害品牌形象的前提下，盡可能地自動化。每一則回覆都是公開的，代表著我們的品牌，並塑造了人們對這家公司的體驗。我們需要 Agent 學習我們團隊對於社群互動的思考方式。

## 原則勝過規則

Buzz 的第一個版本看起來就像許多 Agent 的初版一樣：一份冗長的規則清單。如果有人提到 Bug，就說這句話；如果有人將我們與其他工具比較，就說那句話；如果有人詢問定價，就提到這個方案。

這非常脆弱。Prompt 變得越來越長，回覆顯得機械化，而且只要出現我們未曾告知的情況，Agent 就會出錯。因此，我們將重點從「規則」轉移到了「原則」。我們不再試圖列舉每一個案例，而是寫下指導良好回覆的持久理念：

- 要有幫助，不要防禦。

- 不要用高高在上的態度對待使用者。

- 根據文件核對事實聲明。

- 聽起來像個開發產品的人，而不是處理回饋的機器人。

這讓技能文件（skill file）變得更精簡，Agent 的表現也大幅提升。回覆開始聽起來更像我們會說的話，而且由於指令不再是一個巨大的決策樹，Agent 能夠處理更多情況。不過，原則只給了 Buzz 一個更好的起點，我們無法封裝它可能需要的一切。

## 除非 Agent 能歸納，否則回饋就不是學習

一旦 Buzz 具備了基於原則的基礎技能，我們就開始給它回饋。

它會草擬一則回覆，我會指出哪裡不對，或者寫下我會使用的回覆。然後 Buzz 會嘗試根據這些回饋更新它自己的指令。

這讓我們進入了下一個失敗模式：Agent 傾向於將每一次修正都變回一條規則。例如，如果我說某則回覆感覺太像行銷文案，它會增加一條規則：「永遠不要在第一句話提到定價」。但可轉移的原則應該更接近：「如果有人在發洩情緒，請以同理心引導，而不是推銷」。我們需要教導 Agent 如何從回饋中學習。

因此，我們為此建立了一個獨立的技能。它會檢視 Agent 的建議、人類實際採取的做法，以及目前的指令，然後詢問：為了達到預期的輸出，缺少了什麼原則，或是哪裡不夠明確？

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778807370316-iaHIRTtqwXoAAy2jMjpg.jpg)

學習過程大致如下：

1. 識別出哪裡出錯（或正確）——從具體的回饋開始，務必具體。

1. 詢問：為什麼？——失敗只是症狀，找出根本原因。

1. 抽離出模式——這適用於此案例之外嗎？

1. 對照現有原則——進行強化、編輯、刪除或新增？

1. 將其寫成原則，而非規則——描述思考方式，而非執行動作。

1. 放到正確的位置——章節分類對於 Agent 正確應用原則至關重要。

1. 編輯並提交——更新技能文件，保持精簡，合併重疊的原則。

這感覺很像在教導新進團隊成員，並讓他們學會更廣泛的觀念。一個有用的副作用是，回饋迫使我們必須更清楚地表達自己的判斷標準。許多品味隱含在人們的腦海中，而教導 Agent 則迫使我們將這些想法落實到文字上。

## 回饋迴圈必須適合團隊

至此，Buzz 已經擁有了拼圖的兩塊：執行工作的原則，以及從人類回饋中學習更好原則的方法。但是，誰來持續教導它呢？我們不希望安排定期的會議，也不想將其變成指派給某人的任務。

Buzz 已經會將每則提及連同它的建議和草擬回覆發送到 Slack 頻道，所以我們將回饋介面設計得盡可能簡單：團隊成員只需用 Emoji 反應他們實際採取的行動，並可選擇在討論串中補充說明。點擊一次就是足夠的訊號；討論串則是額外的背景資訊。

接著，Buzz 每天會收集這些反應和討論串回饋，將它的建議與團隊實際採取的行動進行比較，提取出持久的學習心得，更新相關的技能文件，並開啟一個 PR（Pull Request）。

正是這個小小的 Slack 迴圈讓系統在實務中運作良好。從 Agent 獲得槓桿效益的最佳方式，不是把每個人都變成 Prompt 工程師，而是設計出工作流程，讓團隊日常的判斷與品味成為周遭系統的訓練訊號。

## Agent 的技能應被視為程式碼

對於這樣的系統，有一個明顯的擔憂：你真的希望 Agent 重寫自己的指令嗎？答案是肯定的，但不能在無人知曉的情況下進行。我們透過將 Agent 的技能視為程式碼來確保安全性。

當 Agent 重複執行工作時，Prompt 就會成為你需要審查的對象。如果這些指令決定了生產環境的行為，它們就應該存放在儲存庫（repo）中，並具備版本紀錄、審查和復原機制。這個每日學習的 Agent 並不會直接改變生產環境的行為。它會開啟一個 PR，展示它審查了哪些回饋、認為應該修改哪些原則，以及技能文件的確切差異（diff）。人類會像審查任何其他變更一樣審查這些內容。

這讓我們在不放棄控制權的前提下，獲得了自我優化的好處。Buzz 可以持續提出改進建議，但持久的變更必須經過審查，這樣我們才能確保它不會偏離方向。

## 目前的進展

今天，Buzz 每月處理數千則來自 Twitter、Reddit、Bluesky、LinkedIn 和其他管道的提及。大約有一半不需要回覆，這意味著團隊只需將時間花在需要我們注意的提及上——這已經節省了大量的時間。Buzz 運行著約 15 種技能，涵蓋分類、草擬、學習、分析和報告。我們使用 Oz 進行 Agent 管理和編排，因此 Buzz 可以在背景執行，並由排程任務或傳入的提及觸發。

這讓團隊在不增加人力規模的情況下完成更多工作，並能將更多時間花在我們最擅長的事情上：判斷什麼是重要的、做出品味決策、建立社群關係，以及決定 Warp 在外部使用者眼中應該是什麼樣的公司。

## 目標是累積判斷力

從事需要高度判斷力工作的 Agent，需要有一種方式能向那些它們試圖模仿其判斷力的人學習。

每當我們開發類似的 Agent 時，我們都會牢記這三件事：

- 原則勝過規則，因為規則會過度擬合（overfit），而原則可以轉移。

- Agent 需要學習如何學習，否則回饋只會變成脆弱的例外處理。

- 回饋迴圈必須存在於團隊現有的工作環境中，否則人們會停止參與。

我不想從系統中移除人類的判斷力和品味，我想讓它們不斷累積。每次團隊修正 Agent，下一次執行就應該變得更好一點。每一項持久的改進都應該經過審查並提交。

隨著時間推移，Agent 會變得越來越不像某人一次性寫出的 Prompt，而更像是團隊思考方式的「工作記憶」。最優秀的團隊不僅會寫出更好的 Prompt，更會建立出更好的迴圈。

## 標籤

Agent, Skills, 產業趨勢, Agent