從 Agent Demo 到 Production:Postman 如何打造可靠的 AI Agent 基礎設施

TL;DR

• 微服務的教訓在 agent 上重演:hackathon 產出的一堆專用 agent,帶來的是 compounding cost 與 compounding confusion——agent 之間的交接與測試才是真問題。這其實是 decomposition 問題,而不是「再多做一個 agent」能解的。
• 結果越 deterministic,agent 越可靠:win-loss agent 能說出「這筆生意輸在報價太高」而且人類可以逆推驗證;但同一個 agent 被問「怎麼開發潛在客戶」就會脫軌,產出無法判斷對錯。要挑輸出可被回推驗證的問題來自動化。
• 知識 ≠ 策略,對的答案不等於能用的答案:agent 被問「該賣給哪個 persona」永遠回答 procurement——技術上不算錯,實務上會被客戶笑出會議室。策略性內容必須由擁有它的團隊(業務放 account plan、field engineering 放 solution play)人工餵進去。

重點整理

問題:為什麼選企業銷售流程,以及 hackathon 揭露的三個核心問題(約 00:13:39–00:17:45)

Postman 原本是「開發流程 agent-first」的組織,但想進一步做出能在營運中做決策的 runtime agent。做完原型後,CEO 與董事會的興奮反而帶來更難的問題:怎麼衡量?怎麼管理?怎麼確保交付的東西維護得下去?ROI 與 runbook 就是在這一步冒出來的。

選定的題目是企業銷售:流程定義清楚(從發掘機會到續約),但跨很多團隊,而這些團隊之間很難把上下文交接乾淨;底下又是一大群系統,資料之間的關係難以釐清。結果是一個不透明的流程,每一步都在掉 context。

於是辦了 hackathon(約 00:15:52),工程師在 30 小時內做出一堆 agent——畫出來就是一團系統、連線與 agent 的亂麻。其中真正有價值的是 win-loss agent。從這裡歸納出三個核心問題:

1. 輸出越 deterministic,agent 表現越好(約 00:16)。win-loss agent 能回答「這個客戶為什麼流失」,而人可以從它給的理由往回推——「嗯,報價太高,所以這筆輸了」,合理。但同一個 agent 被問「產生 leads 的最佳方式是什麼」就開始脫軌,產出無從判斷對錯。另外,模型越複雜、推理品質越好,但理解那些結果的難度也同步上升。
2. 這是個會複利的問題(約 00:17:13)。做過微服務架構的人會認得這個形狀:A2A、agent 社群……最後拿到的是 compounding cost 與 compounding confusion,agent 之間的 handoff 與測試變成更大的難題。
3. 這其實是 decomposition 問題(約 00:17:31)。他們一個個造 agent,卻沒意識到這些 agent 全都屬於同一個 domain(現場點名 Martin Fowler 的設計模式)。真正的難處是系統之間的介面與 context 的交接。

解法:四層框架(約 00:18:00–00:20:45)

第一層 — monolith agent(約 00:18:00)。地基是一個掌握整個銷售流程知識的單一 agent:Salesforce、Gong 通話與逐字稿都進來,可以問出很有意思的問題與答案。它是很好的 co-pilot 與答案產生器,但灰色地帶會開始編;它是很強的通才,可是面對專門問題資訊太雜,給不出對的結果。

第二層 — decomposition,兩個關鍵零件(約 00:18:42)。 - Hallucination layer:除非你清楚知道資訊來源,否則不要給建議;如果沒有來源,就得解釋你為什麼得到這個結論。兩件事都做不到的輸出,直接忽略。 - Domain-specific agents:這不是寫程式的工作,而是 prompt——「我是業務,我平常會做這些事」,agent 就以那個 persona 回答問題。輸出變銳利、幻覺大幅減少,但變成「自信地答錯」。

第三層 — 策略內容由人負責(約 00:19:35)。知識與智能不等於策略。問業務 agent「該賣給哪個 persona?」——它每次都答 procurement。真去跟客戶說「我要賣給你們的採購部門」,會被笑出會議室。所以他們找出擁有策略內容的團隊來負責餵資料:業務團隊放 account plan,field engineering 放 solution play。輸出開始有策略相關性。

第四層 — 以職務為界的授權(約 00:20:20)。此時他們手上是一個懂整個組織的 super agent,卻沒有任何控制。除了「這是不是真的」之外,還得加一層:「這份內容跟提出請求的職務有關嗎?」所以去問 CTO agent,它不會把全公司 P&L 倒給你——它會把你的 context 與職務納入考量,只回你該看的部分。

Agent autonomy curve 與複利效應(約 00:20:50–00:22:56)

Autonomy curve 的核心是:每個階段,決策由人還是 agent 做?而且有兩個決策要分開看——誰提出請求,以及誰決定何時把結果推上去。

• Help:兩個決策都在人身上——我提問,我分析結果。
• Recommend:agent 開始接手其中一部分。
• Act:最大的 step change 在這裡——在 guardrail 範圍內,agent 同時做兩件事。
• Own:大家都在往這裡走——長時間執行、擁有整個生態系的 agent。

效果超出預期地好:建一個 agent 從「30 小時 hackathon」變成「幾個小時」——有了框架,有人只要進來設好 guardrail,再接上既有的知識體。消費端也從一小群使用者擴散到全公司。開發時間與受益人數兩邊同時複利。

還有一個沒預期到的行為改變:業務知道自己產出的 context 與提出的問題會直接餵養 agent 的價值之後,discovery 做得更多、內容品質也更好。

最後他們也把這些學到的東西做成平台:能衡量產出的 outcome、有一份可用 agent 的 catalog 讓團隊「聘用與解僱」,並看清每個 agent 在成本與投資報酬上的實際影響(約 00:22:42)。

金句

"The more deterministic the outcome, the better the agent was."(約 00:16:20)

挑題目比調 prompt 重要:輸出能被人逆推驗證的場景,才是 agent 該先進的地方。

"Don't recommend something unless you have a clear understanding of where you're getting that information from."(約 00:18:42)

Hallucination layer 的一句話規格。

"It sharpened the output and it stopped doing a lot of the hallucinations, but it was confidently wrong. Knowledge and intelligence does not mean strategy."(約 00:19:25)

Persona 解決了幻覺,卻解決不了「沒有策略」——那是必須由人擁有的資產。