談使用者體驗時，我們習慣看畫面是否清楚、流程是否順暢。當 Agent 成為軟體的另一種使用者，問題會換一個角度：系統是否提供 Agent 足夠而不過量的脈絡、可預測的行動介面、可判讀的回饋，以及能延續到下一步的狀態？
CircleCI 對 Agent Experience 的說明把 AX 定義為 Agent 在軟體系統中取得脈絡、採取行動、理解結果並決定下一步的效率與可靠度。它聚焦在 coding agent 與軟體交付，是一個已存在的實務定義。
我在 Personal Context → Agent Experience 論述裡做的，不是發明 AX，而是把這組觀察延伸到個人 Agent 的完整工作循環：
Context → Action → Feedback → State。Agent 的體驗好不好，不只看它能不能呼叫工具，而要看每一次行動是否收到足以修正下一步的回饋，並把真實結果更新成可延續的狀態。
Context：不是塞得越多越好
Agent 開始工作以前，需要知道目標、限制、可用工具、過去進度與判定成功的條件。缺少其中一項，Agent 可能反覆詢問、選錯工具，或在沒有授權的情況下繼續執行。
但完整脈絡不等於完整資料庫。Anthropic 的 context engineering 文章把 context 看成有限資源，主張應在每次推論時挑選能提高成功機率的高訊號內容。長對話、所有文件與全部歷史一起送入模型，不只增加成本，也會讓過期資訊、互相衝突的規則與無關細節競爭注意力。
因此，AX 的第一個設計問題不是「我們保存了多少」，而是「這一步最少需要什麼」。我把它稱為 Minimum Sufficient Context，至少應包含：
- 這次任務要達成的結果與不能違反的條件。
- 已確認的使用者偏好、權限與適用範圍。
- 任務走到哪一步，哪些外部狀態已經改變。
- 可用能力的輸入、輸出、錯誤與風險。
- 如何由外部訊號判定成功或失敗。
這些內容的來源與時效也要清楚。使用者的長期偏好、專案裡的臨時決定、昨天查到的航班價格，不能以相同壽命被注入。
Action：讓能力可預測，而不是讓模型猜
好的 Action 介面，要讓 Agent 在執行以前知道會發生什麼，在失敗以後知道能做什麼。這與為人設計按鈕不同；Agent 更需要明確 schema、穩定輸出、非互動模式、冪等性與可機械判讀的錯誤。
一個 action contract 至少要回答：
- 前置條件：需要哪些身份、權限與必要資料。
- 影響範圍：只讀、可逆寫入，還是不可逆外部行動。
- 輸出結構：成功時回傳什麼識別碼與狀態。
- 失敗語意：輸入錯誤、權限不足、暫時失敗或部分完成如何區分。
- 重試策略：能否安全重試，是否需要 idempotency key。
- 確認點：哪些內容要先預覽，哪些動作必須由人核准。
MCP、CLI 與 API 都能提供行動入口，但協定存在不代表 AX 自動成立。工具描述若模糊、成功回覆沒有可查識別碼、錯誤只吐出一大段文字，Agent 仍然會在推測中工作。
Feedback：回饋必須能推動下一個決定
人可以從畫面顏色、排版與經驗理解「好像哪裡不對」，Agent 更依賴結構化訊號。Feedback 的目的不是回覆一句完成，而是讓系統知道外部世界實際發生什麼。
可以把回饋分成四層：
- 接收回饋：請求是否進入服務，例如取得 job id。
- 執行回饋：工具是否完成、部分完成或失敗。
- 結果回饋：目標狀態是否真的出現，例如測試成功、訂單存在、文件已更新。
- 品質回饋：結果是否符合政策、使用者標準與長期目標。
Anthropic 的 Agent evals 指南強調 Agent 會跨多輪修改環境，因此評估不能只看最後文字；code-based、model-based 與 human graders 應依任務搭配，並保留完整 trajectory。這個觀點對產品執行同樣適用：Agent 的回覆是證據之一，外部狀態與測試才是更直接的結果訊號。
τ-bench進一步用工具、使用者互動、領域政策與最終資料庫狀態評估 Agent。它的重要設計不是某個排行榜數字，而是把「對話看似合理」與「最後狀態符合目標」分開。
State：把真實進度留給下一輪
如果每次 action 的結果只存在對話文字裡，下一輪就必須重新推理發生過什麼。長任務一旦中斷、模型更換或流程跨裝置，狀態很容易漂移。
State 應是可查詢的任務事實，而不是一段由模型自由改寫的摘要。至少要記錄：
- 任務與步驟識別碼。
- 已提交、執行中、等待核准、成功、失敗或取消等狀態。
- 重要輸入、版本、action 回傳與外部證據。
- 誰在什麼時間核准或修改。
- 下一個等待條件與逾時處理。
這裡也要區分 State 與 Memory。State 回答「這件事走到哪裡」；Memory 保存可在未來任務中重用的觀察與經驗。未完成任務不應因為被摘要進 memory，就被誤認成已完成。
四段必須形成可驗證循環
Context、Action、Feedback、State 不是四個獨立模組，而是一個循環：State 選出下一步需要的 Context，Context 約束 Action，Action 產生外部 Feedback，經驗證的 Feedback 再更新 State。
其中任何一段斷裂，都會出現典型失敗：
- Context 不足，Agent 在錯誤前提下做出合理計畫。
- Action 模糊，Agent 用不穩定方式操作同一能力。
- Feedback 貧乏，Agent 把提交請求誤認成工作完成。
- State 缺失，下一輪重做已完成步驟或漏掉待辦。
所以，真正的 AX 指標不只是 token、延遲或工具呼叫次數。還要看端到端任務成功率、安全重試率、人工介入點、狀態恢復率，以及錯誤被發現後能否回到可繼續的位置。
從一條高頻工作流開始改善
團隊不需要先建立完整平台。先選一條經常發生、結果可驗證的流程，例如修正程式錯誤、整理會議行動、處理客服退貨或發布內容，再依序檢查四段。
第一步：固定成功條件
把「完成」寫成外部可查狀態。程式任務可用測試與部署健康檢查；內容任務可用來源、審閱與發布網址；交易任務則需要訂單與持倉狀態。
第二步：記錄一次完整 trajectory
保留每次取得的脈絡、工具選擇、輸入輸出、錯誤、核准與狀態變更。不要只收集最後回答，否則無法知道問題發生在哪一段。
第三步：把重複失敗改成介面改善
如果 Agent 常看錯參數，就改 schema 與描述；常把 job accepted 當完成，就增加狀態查詢；常在中斷後迷路，就補 task state。不要把每個失敗都回推成「模型不夠聰明」。
第四步：建立回歸 eval
把已發生過的代表性失敗凍結成測試案例。更換模型、工具或 context 策略後，重跑相同任務，確認改善沒有破壞其他條件。
Agent Experience 的價值，是把注意力從「模型這次答得好不好」移到「整個系統是否讓 Agent 穩定工作」。當 Context、Action、Feedback 與 State 形成循環，Personal Context 才不只是背景資料，而能真正參與行動、接受結果檢驗，並延續成下一次更好的經驗。