# 策展 · X (Twitter) 🔥🔥🔥

> 作者：Steve (Builder.io) (@Steve8708) · 平台：X (Twitter) · 日期：2026-04-28

> 原始來源：https://x.com/Steve8708/status/2048906021654151326

## 中文摘要

# 打造 Agent-native 應用程式的正確方式（以及該避免什麼）

這是我在開發 AI 應用程式時，看到人們不斷犯下的最大錯誤：

```javascript
// 不要這樣做
const output = await llm(prompt)
```

讓我向你展示如何以 Agent-native 的方式，將其大幅優化。

## 第一步：工具與迴圈

首先，我們需要兩個新東西：工具（tools）與迴圈（loop）。LLM 本身無法獨立完成任何事，但你可以提供它們工具——以電子郵件應用程式為例，這可能是 `draftEmail`、`searchEmails` 等。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777339454407-diaHG7fW0bEAAHxeFjpg.jpg)

你發送呼叫給 LLM，它會回傳想要執行的工具，接著執行這些工具，然後將結果回傳給 LLM，如此循環直到任務完成。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777339454397-iaHG8ALAIb0AA0RM6jpg.jpg)

你可以檢查每一個步驟，並將每個片段輸出到 UI 上，例如顯示進度。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777339454414-iaHG8AeFjaQAAfWCHjpg.jpg)

## 第二步：別預設 AI 是正確的

但這仍然有一個巨大的問題：我們依然預設 AI 是正確的。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777339454361-iaHG8BAfYaIAA9P0fjpg.jpg)

在這種情況下，我們只是跑完一個迴圈，然後直接使用結果，卻沒有給使用者提供回饋的管道。我們都知道，對於非確定性系統（non-deterministic systems）來說，回饋至關重要。

所以，更好的做法是：建立一個 UI，在 Agent 輸出內容時即時顯示串流結果。讓使用者可以隨時停止、提供回饋，並將下一則訊息加入佇列。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777339454505-iaHG8BTz0boAAHIDNjpg.jpg)

這算是目前最先進的做法。但我認為我們還可以再往前邁進一大步。

## 第三步：自訂化（指令、技能、記憶）

像 Claude Code、Codex 和 OpenCode 之所以強大，是因為你可以對 Agent 進行更多自訂化。

📷

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777339454394-iaHG8Bk1XbAAAxO5ejpg.jpg)

你可以給它們各種專屬於你、你的使用情境以及你的專案的自訂指令。你可以提供額外的檔案作為 context，讓它們直接從檔案系統中參照。你可以賦予它們技能。它們可以在學習與改進的過程中，追蹤自己的「記憶」。

這些功能會帶來巨大的差異，這也是 Claude Code 目前如此爆紅的主要原因。

但你可能會問：我該如何在自己的應用程式中提供這些功能？這開發起來工程浩大。

我個人的觀點是，這是一個幾乎所有應用程式都應該採用的最佳模式。但確實，要為你的應用程式打造一個既友善、具備適當權限與防護機制，且邏輯通順的 Claude Code 類工具，開發起來非常複雜。

📷

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777339454611-diaHG7fW2bYAAmx7Ajpg.jpg)

## 打造 Agent-Native

我一直在開發一個名為 Agent-Native 的開源專案。雖然還在早期階段，但它實現了一些有趣的特性。

首先，你的應用程式被定義為一組「動作」（actions）。這些動作透過 API 公開，因此你的前端也會使用這些相同的動作——例如 `email`、`searchMail`、`draftMail` 等。

📷

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777339454618-ediaHG7fWb0AAz70vjpg.jpg)

Agent 可以將這些核心動作作為工具來使用。Agent 本身還內建了許多功能，稍後我會展示給你。

你可以在應用程式的任何地方渲染 Agent 聊天視窗與 workspace，使用者可以與之對話，或者你也可以從應用程式的其他部分發送訊息給 Agent。

📷

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777339454637-diaHG7fXCa8AArKpzjpg.jpg)

因為應用程式相較於純 Agent 的一大優勢在於，你可以擁有工作流程（workflows）和按鈕來引導使用者。但同樣地，你不希望這些按鈕只是單純呼叫 LLM 然後把結果隨便丟出來。

你希望它們透過 Agent 執行，這樣你才能查看、修改並提供回饋。這會受到那些指令、技能與其他自訂設定的影響。如果輸出結果不正確，你可以回到聊天視窗，告訴它哪裡錯了，並在下一次得到正確的結果。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777339454348-ediaHG7fXJbkAESHBjpg.jpg)

當然，你需要一些基礎設施。Agent 和 UI 必須始終保持同步——當 Agent 進行更新時，UI 會隨之更新，反之亦然。這就是該框架所提供的功能。

我們有標準的聊天功能，也有 workspace。這個 workspace 就像 Claude Code 或 Codex 的 workspace，你可以設定指令、技能與「記憶」。你可以新增檔案、新增子 Agent，進行真正的自訂化。

這些設定的儲存方式，讓每個使用者都能根據自己希望 Agent 在應用程式中的表現方式來客製化體驗；而在組織層級上，你也可以設定標準。當你與 Agent 對話時，它會遵守所有這些設定。

所以我可以隨時介入並說：「新增一個營收儀表板」，根據我的設定，它可能知道這些術語代表什麼，並開始執行正確的查詢與呼叫正確的工具來完成任務。

## Agent + 應用程式，而非二選一

這很酷。我們可以進入全 Agent 模式——讓 Agent 佔滿整個螢幕，就像完全在使用一個聊天應用程式一樣。

但我提到過，應用程式本身也很有價值，我發現人們太傾向於將這兩者視為二選一。我通常認為，大多數應用程式若內建 Agent 會更好，而大多數 Agent 若具備 UI 能力也會更好。正如你最近在 Cursor、Codex 和 Claude Code 中所看到的，這些工具都能產生 UI——但它們運作起來不像應用程式。

如果我正在使用一個 Agent 進行分析，我會希望它能將某些檢視畫面儲存為儀表板。我希望選擇誰有權存取該儀表板。我希望它像應用程式一樣運作，但我不想失去任何 Agent 的便利性。

我也想要按鈕。最酷的是，按鈕可以帶有 Prompt。當你說出「幫我製作一個流量與註冊儀表板」並提交時，該任務會委派給 Agent。你可以看到 Agent 的運作過程。它的運作方式與你習慣的 Claude Code 及其他產品完全相同，但它是你應用程式的原生功能。

在這個框架中，Agent 還能看到你螢幕上的內容、更新螢幕畫面、導航你到其他頁面。總而言之：如果 UI 做得到，Agent 就做得到；如果 Agent 做得到，UI 也做得到。

這不需要任何超級複雜的容器設定或在機器上運行的開發環境（dev boxes）。你可以將其部署到任何地方。你可以使用任何你想要的 LLM。你可以有效地使用任何相容 Drizzle 的資料庫或任何 SQL 資料庫。而且它非常容易使用——至少我是這麼認為的。

## 好、更好、最好

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777339454389-diaHG7fXQbMAAKJBujpg.jpg)

無論你是想要這種包羅萬象的解決方案，還是只想整合到現有的產品中，我都希望這個「好、更好、最好」的階梯對你有幫助。

如果你想嘗試 Agent-Native，它已經在 GitHub 上開源，採用 MIT 授權。那裡有一堆範例應用程式，你可以直接試用並感受一下。雖然它還處於非常早期的階段，但我很期待你的回饋——無論是對整體概念，還是如果你嘗試過後的實作心得。

但你怎麼看？應用程式最好不要整合 Agent 嗎？還是說 Agent 比應用程式更好，未來沒人會再使用 UI 了——只剩下 Agent 和 Telegram 裡的文字，這將是使用產品的唯一方式？

我很想在留言區聽到你的想法。

## 標籤

Agent, 教學資源, LLM
