當軟體不再是 deterministic，「對」不再是唯一答案；Agent 的價值，開始從正確性轉向決策品質

最近在做 AI Agent 產品的時候，我反覆遇到一個很有意思的情境。

客戶會說：

「我希望這個東西是 turn-key 的。」

翻譯一下就是：

• 不想參與訓練
• 不想定義規則
• 不想反覆調整
• 但希望結果是對的
• 不想導入失敗

聽起來很合理。

但問題是，這裡面其實藏著一個結構性的矛盾。

一段很真實的對話

某次我跟一個客戶討論他們的數據分析 Agent，大概是這樣的：

客戶： 這個分析不太對。

我： 哪裡不對？

客戶： 就…不是我想要的。

我： 那你想要的是什麼？

（停頓）

客戶： 我也很難講，但我看到就知道。

客戶： 但我不希望每個問題都要我定義……

這段對話其實很關鍵。

某種程度上，它也反映了一個轉變：

我們正在用一種「新的系統型態」，去解一個「舊的期待」

因為它揭露了一件事情：

「對」這件事，在多數商業場景裡，是一種隱性標準。

它存在，但沒有被說出來。

為什麼 Agent 很容易被說「不夠聰明」

當 Agent 給出一個結果，而客戶覺得不對時，直覺反應通常是：

「這個 Agent 不夠聰明。」

但實際上，問題通常不是「能力」，而是：

「評價標準沒有對齊」

換句話說：

• Agent 在某一個標準下是合理的
• 客戶在另一個標準下覺得是錯的

但這兩個標準，從來沒有被明確定義過。

真正的問題：誰在定義「什麼是對」？

這裡有一個很核心但很少被講清楚的點：

AI Agent 並不是在「變聰明」，而是在「優化某個目標」

而這個目標，如果沒有人定義，它就會漂浮。

在傳統軟體裡，這件事情比較單純：

• input → output
• 對 / 錯 很明確
• 行為是可預期、可驗證的

也因此，開發流程通常是：

定義需求 → 實作 → 上線

只要規格寫清楚，系統就應該穩定地產生相同結果。

但在 Agent 系統裡：

• 沒有單一正確答案
• 有 trade-off（速度 / 準確 / 成本 / 完整性）
• 同一個輸入，可能產生不同但合理的輸出

所以「對」其實變成：

一個被選擇出來的偏好

而這也帶來一個很關鍵的改變：

軟體不再是「一次做對」，而是「透過反覆調整逐漸靠近」

Turn-key 的本質：拒絕參與定義標準

當客戶說「我要 turn-key」，其實潛台詞是：

「我不想參與定義什麼是好的結果，但我希望結果符合我的期待」

這會導致一個很典型的錯位：

• 客戶：用「感覺」在評估
• 系統：用「隱含規則」在生成

而這兩者之間，如果沒有對齊機制，就一定會出問題。

換個角度看這件事

如果換個更溫和的說法：

多數人以為 Agent 的問題是「不夠聰明」， 但很多時候，其實是「我們還沒有定義清楚什麼叫做聰明」

這也是為什麼同一個系統：

• 有人覺得很好用
• 有人覺得完全不行

因為他們在用不同的標準。

當然，也需要承認一點：

有些情況確實是能力問題（例如明顯的邏輯錯誤、hallucination、遺漏關鍵資訊）

但在多數模糊、開放式的任務中，更常見的，其實是「標準沒有被對齊」。

那該怎麼辦？

這裡其實有一個需要被理解的現實：

在 Agent 系統中，「迭代」不是優化選項，而是系統的一部分

因為當輸出不是 deterministic 時，就不可能一次定義出完美行為。

如果客戶不想迭代（iterative），那你就不能依賴 feedback loop。

你只能做三件事：

1. 把「錯」變得很明確

例如：

• 數據不能錯
• 不能亂編
• 必須能解釋

這一層是底線。

2. 預設一個「你的標準」

你必須自己決定：

• 你認為好的分析是什麼
• 你偏好簡潔還是完整
• 你重視 insight 還是細節

這其實是一種產品觀，而不是技術問題。

3. 把複雜選擇壓縮成少數選項

不要問客戶：「什麼是好的？」

改成：

• 你要「快速結論」還是「完整分析」？
• 你要「探索」還是「驗證」？

本質上，是把無限維的評價空間，壓縮成幾個可選模式。

這三件事的目的，其實不是幫系統「做對」

而是把決策的形狀，重新交還給使用者。

當「對」不再是單一答案時，系統的角色就會改變：

• 不是替你做出唯一正確的選擇
• 而是幫你看見不同選擇之間的差異

也因此，真正的收斂，不是讓所有輸出變一致，而是讓使用者可以在有限的選項中，做出對自己長遠更有價值的決定。

換句話說：

Agent 不只是產生答案，而是在幫助你建立「如何選擇答案」的能力

這也是為什麼，在這個範式下：

軟體的價值，不再只是正確性，而是決策品質

回到那段對話

如果再回到一開始那段對話，其實可以這樣理解：

客戶說「這不對」，不是在說：

你做錯了

而是在說：

這不符合我心裡那個沒說出來的標準

而你的任務，不只是讓 Agent 更聰明。

而是：

讓那個「沒說出來的標準」，有辦法被表達、被選擇、或被限制。

補充：能力、責任與邊界

為了讓這件事更完整，有幾個容易被忽略但很關鍵的面向：

1. 不是客戶不願意，而是本來就難以形式化

很多時候，問題不在於「不想定義」，而是：

很多決策本來就難以被寫成規則

也因此，期待一開始就有完美 specification，本身就不太現實。

2. 有些 turn-key 的期待，其實是「責任配置」

當有人說要 turn-key，某種程度上也可能是在說：

我希望系統能承擔結果的正確性

這會影響的不只是產品設計，也包含：

• 誰為錯誤負責
• 什麼時候需要 human in the loop

3. 「決策品質」需要被具體化

如果我們說軟體的價值在於決策品質，那至少包含：

• 降低明顯錯誤的風險
• 提供可比較的選項
• 讓決策過程可以被理解

這些，比單一答案是否「完美」，更貼近實際價值。

4. 不是所有場景都適合 Agent

也有一些場景，仍然需要 deterministic：

• 財務報表
• 法規遵循
• 高風險決策

在這些情境下，「一次做對」仍然是必要的。

最後

當你在做 Agent，然後聽到有人說：

「這個不夠聰明」

你可以先問自己一個問題：

我們有沒有真的對齊過，什麼叫做「聰明」？

如果沒有，那問題大概率不在模型。

而在我們怎麼定義世界。