Goal-Prompt

一句話定義

Goal-Prompt 是寫給 long-running agent 的任務提示結構:先定義 outcome、verification、constraints、iteration policy 與 error handling,讓 agent 能持續執行、驗證、修正,直到完成或遇到明確停損條件。

核心要點

自動化要移除注意力 open loop

2026-05-25-Gary-Chen-AI-Agent-27小時-Goal功能 把 AI 自動化的重點從「把任務丟給 AI」推到「把任務從人的心上移開」。如果使用者每隔幾分鐘就要回來看 agent 做到哪、要不要改方向、是否偏題,那只是把工作移到 AI 手上,沒有解放注意力。

這與 蔡格尼克效應 相鄰:未完成任務會維持 open loop。好的 goal prompt 要能讓人知道「什麼狀態才算完成、什麼狀態才該回來問我」,否則 agent 跑多久都只是另一個需要管理的待辦。

五個必要元素

元素問題寫法重點
Outcome完成後應該是什麼狀態?用可判斷的結果描述,不寫「改好一點」
Verification怎麼證明真的完成?測試、截圖、指標、人工 rubric、trace 或對照樣本
Constraints哪些事情不能做?可改範圍、不可破壞功能、工具限制、成本與時間邊界
Iteration policy每輪之間要做什麼?記錄嘗試、結果、下一個最值得試的方向
Error handling什麼情況要停下?工具失效、驗證跑不起來、方法耗盡、需要人補資料

這組結構把 SMART目標完成的定義 移植到 AI agent 場景:SMART 幫 goal 變具體,DoD 幫任務知道何時收尾,verification / error handling 則防止 agent 無限空轉。

壞 prompt 的問題是沒有完成邊界

「把這個專案改得好一點」會失敗,不是因為模型懶,而是因為「好一點」沒有可被評審判斷的邊界。模型會自己定義 definition of done,通常做幾個小改動就回報完成。

好的 goal prompt 會把「完成」交給外部標準:

  • 速度降到多少?
  • 用什麼工具測?
  • 哪些檔案不能碰?
  • 每輪要回報什麼?
  • 什麼時候不要硬做?

這讓 Evaluator-Optimizer/goal 類功能有可追的胡蘿蔔,而不是靠 agent 自己猜使用者滿意點。

停損規則不是消極,而是長任務安全邊界

Long-running agent 不應該「無腦一直做」。如果驗證工具跑不起來、必要資訊缺失、所有合理方向都試過仍未改善,正確行為是停下來報告:

  • 已嘗試哪些路徑。
  • 每個路徑的結果或錯誤。
  • 目前卡點是工具、資訊、權限、任務定義還是技術瓶頸。
  • 需要人提供什麼才能繼續。

這是 Agentic-Engineering 的責任邊界:大量試錯要伴隨可停止、可回滾、可審計,而不是把失控包裝成自動化。

與其他概念的關係

  • Prompt-Engineering:Goal-Prompt 是 prompt engineering 在 long-running agent 場景的子型,重心從一次性輸出轉為完成條件、驗證與迭代政策。
  • 完成的定義:本頁是 AI agent 任務的 DoD 前置寫法;DoD 回答「何時算完成」,Goal-Prompt 把它放進任務指令。
  • LLM-Evaluation:Verification 可以是測試、metric,也可以是 rubric / LLM-as-Judge;沒有 eval,goal mode 只會變成長版猜測。
  • Evaluator-Optimizer / Ralph-Loop:Goal-Prompt 提供 evaluator 判斷是否繼續迭代的標準。
  • Agentic-Engineering:constraints、time budget、error handling 與 rollback 是 goal prompt 的工程化上層。
  • 品味外化:質化任務的 verification 通常要靠品味 rubric;沒有 rubric,agent 很難知道主觀品質何時過關。

相關來源

備註

本頁先以 Gary-Chen 影片中的二手整理與實務建議建頁;Claude Code / OpenAI Codex / Hermes Agent 的 goal 功能細節需待官方文件校準,對應追蹤項見 觀察清單.md 的「Long-running Agent Goal 與品味 Rubric 引用來源叢集」。