🔧 阿川の電商水電行
Shopify 顧問、維護與客製化
💡
小任務 / 單次支援方案
單次處理 Shopify 修正/微調
⭐️
維護方案
每月 Shopify 技術支援 + 小修改 + 諮詢
🚀
專案建置
Shopify 功能導入、培訓 + 分階段交付

我從事人工智慧方面的工作已經有一段時間了。

不是以遊客的身份,也不是以週末黑客的身份。我是深度參與其中。出貨、將模型整合到產品中、凌晨三點查看日誌、在出現異常情況時向用戶道歉。

然而,每次我看到這樣的帖子:

“自主代理將為您運營業務。”

我覺得腦海裡有個平靜卻令人不安的聲音:

“也許是我沒理解吧。”

大家似乎都對這個想法充滿信心,所以我們可以:

  • 將模型插入工具層

  • 用幾個提示語概括一下

  • 讓它呼叫API。

  • 然後觀察它如何“執行營運”或“管理您的公司”。

而我卻站在一旁,問一些聽起來幾乎無聊的問題:

  • 我們真的要賦予這個東西在重要決策中擁有真正的權力嗎?

  • 我們的控制面究竟是什麼?

  • 如果失敗的方式出乎我們的意料,會發生什麼事?

  • 我們真的認為prompt = governance嗎?

我的一部分擔心自己是不是太謹慎了,太老派了,太固守“工程思維”,而世界正在朝著更加靈活和概率化的方向發展。

但我內心深處也想:

或許需要有人大聲說出來:提示不等於控制。

這是我的嘗試。

一半是懺悔,一半是技術上的抱怨,充滿了自我懷疑。


在一群樂觀主義者中間做懷疑論者,那種感覺很不自在。

讓我來描述一個不斷重複的模式。

我參加了一個關於「人工智慧應用」、「維運代理」或「工作流程自動化」的會議或電話會議。有人分享了一張投影片,內容大致如下:

User request -> LLM -> Agent framework -> Tools -> Profit

敘述通常是這樣的:

“我們將擁有能夠自主處理客戶工單、管理支付、調整價格、編寫程式碼、進行增長實驗、生成內容等等的智能體。人類只需進行監督。”

當周圍的人都點頭時,我覺得自己像個尷尬的角落裡的人,心裡想著:

「這仍然是一個根據訓練資料和提示上下文補全文本的隨機模型,對吧?難道我錯過了什麼通知,說它已經成為一個真正可靠的決策者了嗎?”

然後,自我懷疑就開始作祟。

或許:

  • 我低估了這些模型的優秀程度。

  • 我太執著於用明確的邏輯和清晰的不變式來建構系統這種舊方法了。

  • 我之所以有偏見,是因為我在練習中見過太多不易察覺的失誤。

  • 我投射出了自己對失去對本來應該理解的系統控制權的恐懼。

在糟糕的日子裡,內心獨白簡直就是:

“其他人似乎都樂於把這件事委託出去。也許是我缺乏遠見。”

但當我仔細審視這些模型和工具鏈的實際特性時,我理智的那部分大腦卻悄悄地堅持:

“不,等等。這不是缺乏遠見的問題。這是關於基本的控制理論和風險的問題。”


提示會讓人感覺像是在控制別人,但實際上並非如此。

這裡面蘊含著一種深刻的心理技巧。

寫徵求意見稿的時候,感覺就像在寫政策文件一樣。

例如:

“你是運營助理。你總是遵守公司政策。”

未經人工審核,絕不發放超過 200 歐元的退款。

你們始終將客戶安全和資料隱私放在首位。

這看起來像是一套規則。幾乎就像是一份小型規範。

但實際上,你所做的就是將自然語言文字作為條件輸入到一個統計模型中,該模型具有以下特點:

  • 並不能完全保證這些話會被遵守。

  • 沒有內建的「保單」或「違規」概念

  • 沒有確定性的執行路徑

  • 完全沒有意識到一次錯誤行為的“爆炸半徑”

你輸入了文本,模型返回了更多文本。

這種掌控感來自於你自身,而不是來自體制。

是你的大腦讀了這條提示,然後說:

“啊,是的,我已經告訴它該怎麼做了。所以現在它會照做。”

這個模型並不「知道」這些指令是神聖不可侵犯的。

它的權重中存在一些模式,表明: “當輸入內容是這樣的,接下來通常會出現這樣的文本。”

這兩件事之間的距離,恰恰蘊藏著巨大的風險。


軟體系統中真正的控制是什麼樣的

如果我暫時拋開人工智慧的熱潮,像個枯燥的後端工程師那樣思考,「控制」一直以來都意味著:

  • 權限

  • 哪個身分可以執行哪些操作、在何處執行以及執行頻率如何

  • 邊界

  • 網路分段、防火牆、唯讀存取與讀寫存取、速率限制

  • 可審計性

  • 誰在何時使用了哪些參數,做了什麼

  • 可逆性

  • 我們可以撤銷這個操作嗎?我們可以從備份中恢復嗎?

  • 約束和不變數

  • 在這個系統中,帳戶餘額絕對不能為負數。

  • 訂單必須始終包含有效的使用者 ID 和產品 ID。

  • 此服務每秒最多只能推送 X 次更新。

然後,在所有這些之上,我們疊加:

  • 監測

  • 警報

  • 備用路徑

  • 緊急停止開關

  • 變革管理

它枯燥乏味,毫無吸引力,但卻是維持嚴肅系統不崩潰的關鍵。

現在,請將此與我們談論人工智慧代理時的「控制」進行比較:

  • “我們在模型上加入了一條提示訊息,告訴它要安全。”

  • “我們加入了一條訊息:如有疑問,請諮詢人工客服。”

  • “我們配置了一些工具,讓客服人員決定呼叫哪個工具。”

這兩個世界之間存在著巨大的鴻溝。

我一直在問自己:

“我對人工智慧自動化提出類似的嚴格要求,是不是反應過度了?”

或者,我們是否因為介面太友善、輸出太流暢而集體反應不足呢?


為什麼基於提示的控制很脆弱

讓我列舉一下我難以信任prompt = control作為一種可靠的安全機制的主要原因。

非決定論

使用相同的提示符號和溫度 0.7 對同一模型呼叫十次,結果如下:

  • 略有不同的推理鏈

  • 偶爾會有截然不同的答案

  • 有時罕見但後果嚴重的故障模式

在聊天環境中這樣做沒問題。但在以下情況就非常不合適了:

  • 輸出結果批准或拒絕退款

  • 輸出結果決定是否將合規性問題升級。

  • 輸出結果會向一位重要客戶發送電子郵件。

如果你的「策略」僅僅體現在提示符中,那麼當某些令牌路徑出現異常時,模型可能會隨機偏離該策略。

語境稀釋和指令衝突

在複雜的代理設定中,模型上下文看起來像這樣:

  • 系統訊息(“您是 X”)

  • 任務說明

  • 工具規格

  • 歷史記錄、先前步驟、錯誤

  • 使用者訊息

  • 工具回應

您精心編寫的安全說明可以:

  • 被埋沒在上下文的深處

  • 被後續訊息掩蓋

  • 與工具描述相衝突

  • 與用戶輸入進行奇怪的交互

你無法確定模型內部權重分配中哪一條指令會優先執行。你只能寄望於最重要的部分能夠被清楚地傳達出來。

分佈偏移和異常邊緣情況

該模型使用靜態資料進行訓練。然後,它被投入到以下環境:

  • 不斷發展的產品

  • 改變使用者行為

  • 新型業務流程

  • 來自聰明用戶的對抗性輸入

您在內部測試中觀察到的任何行為都不能作為正式保證。這僅僅證明在某些特定條件下,它的表現「足夠好」。

可能只需要一個奇怪的極端情況就會導致大問題。

缺乏基本狀態和正式規則

舊系統有明確的狀態機和規則。你可以對它們進行形式化描述、證明,或至少推理。

人工智慧代理通常不具備:

  • 環境的正式內部模型

  • 可證明的決策過程

  • 成分保證

這意味著,如果你想要真正的控制,你需要圍繞模型來建立它,而不是在提示符號內部建立它。

這就引出了我一直想問的問題:

為什麼這麼多人樂於跳過這一部分?


三大要素:自動化、自主性、權威性

我發現將行銷資料中經常混為一談的三個概念分開來很有幫助。

自動化

幾十年來,我們一直都是這樣做的:

  • 定時任務

  • 腳本

  • 管道

  • 惡魔

自動化是指: “這一特定的例行步驟由機器處理。”

設計糟糕的自動化仍然會造成問題,但至少其邏輯是明確的。

自治

自主性更強:

  • 系統可以決定採取哪些步驟。

  • 它能對環境做出反應

  • 它可以從多種可能的操作中進行選擇。

  • 它可以產生你沒有硬編碼的計劃。

這就是基於LLM的智能體所處的環境。它們選擇工具、推斷目標並適應環境。

權威

然後還有權威:

  • 該系統有能力直接影響重要資源。

  • 它可以轉移資金、改變生產系統、與客戶溝通、簽署看似承諾的文件。

權力是風險爆發的來源。

你可以使用以下方式建立自主代理:

  • 完全沒有權威性(純屬建議)

  • 權限有限(沙盒操作)

  • 完全權限(對現實世界系統擁有無限制的寫入權限)

我所恐懼的並非自主權本身。

我擔心的是,在只有提示性的「控制」和極少保護性保障的情況下,賦予自主權和權威。

感覺就像一座脆弱的塔。


為什麼「讓AI來運作」如此誘人?

平心而論,我能理解這種吸引力。這並非炒作或愚蠢之舉,而是存在著一些現實的壓力,促使人們希望這是真的。

其中一些:

  • 經濟壓力

  • 減少員工人數

  • 用更小的團隊做更多的事

  • 與那些聲稱擁有代理驅動營運模式的其他公司競爭。

  • 認知超負荷

  • 企業很複雜

  • 人們很容易會想把日常決策工作交給一個能夠讀取所有文件和日誌的系統。

  • 介面錯覺

  • 與LLMs交談感覺就像在和一位能力很強的人交談。

  • 聽起來很有自信。

  • 它失敗時會道歉。

  • 我們賦予它的理解遠遠超出了它實際擁有的理解。

  • 敘事動力

  • 投資者、創辦人、供應商、內容創作者都能從「這就是未來」這個說法中受益。

  • 沒人會因為說「我們建構了一個權限受限、風險邊界很小的自動化系統」而獲得按讚。

於是,我眼看著「人工智慧將掌控你的公司」這股浪潮興起,而我自己的立場開始讓我感到有些尷尬:

“抱歉,我仍然認為我們應該把他/她當作一個不可靠但有用的同事,而不是一個無所不知的運營大佬。”

我是不是太悲觀了?還是其他人太樂觀了?我真的不知道。


更誠實的控制架構可能會是什麼樣子

讓我試著闡述一下我腦海中反覆出現的模型。也許這是我的偏見,也許只是枯燥但有效的練習。

我設想的人工智慧系統是分層的。

模型作為建議引擎

LLM、視覺模型或其他元件的核心是:

  • 建議引擎

  • 規劃助理

  • 模式辨識器

它提供的是選擇,而非真理。它起草方案、提出建議、歸類並解釋觀點。

在這種框架下,預設值為:

“模型得出的所有結論都需要通過其他因素進行驗證或約束。”

模型之外的政策與約束

「未經人工批准,不得退還超過 X 美元的款項」之類的政策不應僅存在於提示文本中。

它們應該生活在包裹模型的實際邏輯之中。

MAX_AUTO_REFUND = 200  # euros

def handle_refund_suggestion(user_id, suggestion_amount):
    if suggestion_amount <= MAX_AUTO_REFUND:
        issue_refund(user_id, suggestion_amount)
        log_event("refund_auto_approved", user_id=user_id, amount=suggestion_amount)
    else:
        create_manual_review_ticket(user_id, suggestion_amount)
        log_event("refund_needs_review", user_id=user_id, amount=suggestion_amount)

該模型仍然可以說「我認為我們應該退款 300 歐元」。

但權力是透過嚴格的限制來授予的,而不是透過禮貌的提示來提醒。

工具作為通往世界的狹窄接口

代理程式不應該看到原始資料庫或root shell。

他們應該看看:

  • 功能單一的狹義工具

  • 具有明確的安全預設值

  • 透過輸入驗證和清理

  • 通過速率限制和配額

  • 清晰的日誌記錄

def send_email(to, subject, body, *, template_id=None):
    # Validation
    assert isinstance(to, str)
    assert "@" in to
    assert len(subject) < 200
    assert len(body) < 5000

    # Logging
    log_event("email_requested", to=to, subject=subject, template_id=template_id)

    # Send through provider
    provider.send(to=to, subject=subject, body=body)

代理可以選擇呼叫send_email ,但不能繞過以下步驟:

  • 驗證

  • 日誌記錄

  • 提供者邊界

人為檢查點和自主程度

「代理人掌控一切」這種想法我覺得不太對勁。

更貼近實際的模型:

  • 0級:僅供參考

  • 該模型表明,人類決定

  • 一級:低風險自主

  • 此模型可以執行影響小、易於逆轉的操作。

  • 二級:中度風險自主性

  • 模型可以執行,但必須遵守更嚴格的限制並接受額外的監控。

  • 第三級:高風險決策

  • 模型只能提出方案。必須進行人工審核。

您甚至可以將其編碼到配置中:

tasks:
  - id: reply_to_low_risk_tickets
    autonomy_level: 2
    max_impact: "single_customer_message"

  - id: adjust_pricing
    autonomy_level: 0
    requires_human_approval: true

  - id: issue_refund
    autonomy_level: 1
    max_amount: 200

然後,在編排層強制執行此操作,而不僅僅是在一段英文文字中強制執行。

可觀測性和可追溯性

如果一個系統在任何意義上“執行著你的業務”,你肯定想知道:

  • 它決定了

  • 它為什麼做出這個決定

  • 它呼叫了哪些工具?

  • 它看到了哪些輸入

  • 它出錯的次數有多少?

這意味著:

  • 結構化日誌

  • 每個請求的跟踪

  • 指標

  • 故障分類

  • 能夠重現某個場景,並查看究竟發生了什麼事。

沒有它,你就如同盲人。


那個不斷低語的聲音:“也許你做得過頭了。”

說實話吧。

當我設計系統時:

  • 編曲家

  • 多代理

  • 衛兵

  • 檢查

  • 大量伐木

我有時覺得自己像個偏執狂,身處在一個勇敢的探險家世界。

每一次「自主」系統的自信演示都會引發一次小小的內部比較:

  • 他們移動得更快了。

  • 他們運送大膽的東西

  • 他們談論的是「免持操作」。

  • 它們擁有漂亮的介面和流暢的敘事手法。

然後我檢視了自己的思考模式:

“把人工智慧當作一個不可靠的同事。只在嚴格限定的範圍內賦予它權力。時刻監視它。”

這可能會讓人感覺保守,甚至有些限制。

自我懷疑是真實存在的。

有時我真的會想:

“也許我應該放鬆一些,並更加信任經紀人。”

然後我想起了實際發生的事:

  • 模型產生從未存在過的幻覺事實

  • 由於工具描述略有含糊不清,導致工具呼叫錯誤

  • 當上下文視窗變大時,提示符號會發生細微的偏移。

  • 兩個未曾一起測試過的智能體之間出現了令人驚訝的相互作用。

  • 簡單的失敗案例就能徹底打破「自主性」的幻覺

我謹慎的一面再次佔了上風。


我難道全都錯了嗎?

公平地說,是的。我可能在很多方面都錯了。

我考慮的幾種可能性:

  • 模型的可靠性可能會達到我目前無法預期的水平。

  • 透過更好的訓練、更好的微調、更好的安全措施

  • 或許我們最終能夠達到這樣一個境界:預先制定的政策能夠得到高度一致的執行。

  • 一般企業或許比我想像的更能承受風險。

  • 或許對很多流程來說,「大多時候夠好」就完全沒問題了。

  • 或許節省的成本足以彌補偶爾出現的錯誤。

  • 新的代理框架可能會在內部強制執行更多結構。

  • 它們可能不會基於原始的提示做出決策,而是以更穩健的方式對策略和約束進行編碼,即使介面看起來仍然像「代理」。

  • 我可能仍然固守著過時的思考模式。

  • 我的訓練方向是建立顯式系統。

  • 或許我的不適感只是因為那種訓練與全新的機率世界不匹配。

我努力保持這種謙遜的態度。我不想永遠做那個叫囂「汽車危險,馬匹更好」的人。

但即便我對風險的程度判斷有誤,我仍然相信:

“任何時候,當你把自主權和權威混為一談時,你需要的是真正的控制結構,而不僅僅是漂亮的英語。”

我還沒有看到任何令人信服的論據,證明提示本身足以作為重要決策的控制機制。


我個人是如何應對這種緊張局勢的

我不想在「代理人是未來」與「代理人毫無用處」的爭論中選邊站隊,而是試圖保持中立:

  • 我承認LLMs學位是推理、寫作和規劃方面極其強大的工具。

  • 我不認同這種權力使他們天生就成為值得信賴的決策者的觀點。

  • 我仍然希望在重要的系統中充分利用它們。

  • 我想設計一些具有清晰、乏味、老式控制介面的系統。

這就是我為什麼關心以下這些事情的原因:

  • 明確定義流程的協調器

  • YAML 或其他聲明式格式,將「應該發生什麼」與「模型如何推理」分開。

  • 將功能封裝在嚴格邊界之後的服務節點

  • 可觀測性讓你能夠重現發生了什麼以及為什麼。

這也是為什麼當人們告訴我:

“我們有一個可以執行 X 的自主代理。”

我的第一個問題是:

  • 單次執行能造成的最大破壞力是多少?

  • 你怎麼知道它什麼時候做錯了?

  • 如何快速阻止它?

  • 除了提示之外,還有哪些硬性規定?

如果答案含糊不清,我的自我懷疑就會暫時消失,而我對自己的懷疑態度的信心就會增強。

同時,我自己也在開發這方面的工具。這增加了一層奇特的意味:

  • 我不想聽起來像是在攻擊我所從事的這個領域。

  • 但我也不想過度誇大自主性而忽略控制權。

所以當我提到自己的作品時,我盡量直截了當:

「我正在開發一個用於 AI 代理的編排層,它具有明確的流程、分支、服務節點和可追溯性。

關鍵不在於“讓人工智慧控制一切”,而是給人類一個清晰的框架,來決定人工智慧可以做什麼、何時做以及採取哪些保障措施。

如果你有興趣的話,這項工作存在於OrKa Reasoning計畫中。

這是我試圖調和「深度使用人工智慧」與「不要透過感覺放棄控制」之間矛盾的一部分。


OrKa 推理

如果您對明確控制人工智慧代理的想法感興趣,可以點擊此處了解 OrKa 推理堆疊:

  • OrKa 推理庫:

https://github.com/marcosomma/orka-reasoning

  • 快速入門和文件:

https://github.com/marcosomma/orka-reasoning/blob/master/docs/getting-started.md

OrKa Reasoning 是我嘗試為開發者提供一個以 YAML 為先的編排層,其中:

  • 流程和分支是明確的

  • 記憶體、工具和服務都封裝在清晰的節點中。

  • 您可以查看相關記錄,了解做出某項決定的原因。

換句話說,這是一項實驗,旨在建立我希望在現代人工智慧堆疊中預設存在的控制介面。


向其他心存疑慮的建築商發出邀請

如果你也有類似的困擾,我想明確地告訴你:

“你並不孤單。”

你可以:

  • 尊重這些模型的功能。

  • 以創意的方式挑戰他們的極限

  • 圍繞它們建構嚴謹的系統。

而且仍然會說:

“不,我不會讓他們對重要決策擁有完全、不受限制的控制權。”

控制權屬於人類,並編碼在可理解、可審計的系統中。

你可以成為:

  • 既興奮又謹慎

  • 好奇又懷疑

  • 雄心勃勃,不願假裝提示文本等同於治理。

每次表達這些擔憂時,我幾乎都會對自己產生懷疑。

我仍然擔心自己在一群熱情洋溢的孩子麵前會顯得像個無趣的大人。

但我寧願忍受這種不適,也不願假裝我們在提示語頂部寫上「請注意安全」就能解決控制問題。

如果我的這些絮絮叨叨中有什麼引起了你的共鳴,我很想聽聽你的想法:

  • 你們是如何在人工智慧系統中設計控制機制的?

  • 你如何界定自主權和權威之間的界線?

  • 您是否找到過一些能夠真正減輕您對房屋仲介行為焦慮的方法?

請留言,指出我的想法漏洞,或告訴我我錯在哪裡。

我非常願意接受自己「沒理解」這種可能性。

但是,如果我們要讓人工智慧代理商接觸真實的企業、真實的資金和真實的人,我真的希望我們首先要確保控製到位。


原文出處:https://dev.to/marcosomma/maybe-i-just-do-not-get-it-5e3f


精選技術文章翻譯,幫助開發者持續吸收新知。

共有 0 則留言


精選技術文章翻譯,幫助開發者持續吸收新知。
🏆 本月排行榜
🥇
站長阿川
📝16   💬4   ❤️4
361
🥈
我愛JS
📝1   💬5   ❤️2
54
評分標準:發文×10 + 留言×3 + 獲讚×5 + 點讚×1 + 瀏覽數÷10
本數據每小時更新一次
🔧 阿川の電商水電行
Shopify 顧問、維護與客製化
💡
小任務 / 單次支援方案
單次處理 Shopify 修正/微調
⭐️
維護方案
每月 Shopify 技術支援 + 小修改 + 諮詢
🚀
專案建置
Shopify 功能導入、培訓 + 分階段交付