每日突破性工具推薦｜Agent-Native

今日推薦理由

今天推薦 Agent-Native。它是一套開源 TypeScript 框架，目標不是在既有 SaaS 上「加一個聊天機器人」，而是把 AI Agent 與人類 UI 設計成同一個應用程式的兩個一級操作介面。

近期它快速成長，官方 GitHub 已累積約 6.4k stars；更重要的是，其架構提出一個值得關注的方向：產品能力只定義一次，UI、Agent、HTTP、MCP、A2A 與 CLI 全部共用同一份 Action contract。這使它不是另一個單純的 Agent orchestration library，而更接近一套「Agent-native application framework」。

工具定位與適用情境

Agent-Native 適合用來建立 Agent 與傳統 GUI 必須共同操作同一份資料與工作流程的應用，例如：

AI Mail / Calendar / CRM
AI Analytics Dashboard
文件與內容工作區
具有審核、權限與人工介入流程的 Agent SaaS
需要同時提供 Web UI、API、MCP、A2A 與 CLI 的 AI 產品
人類與 Agent 共同編輯同一份資料的協作型產品

它特別針對一個正在變得明顯的問題：如果 UI、REST API、Agent tools 與 MCP tools 分別實作，同一項產品能力很容易出現 schema、權限與 business logic 漂移。

突破性重點：Action 成為真正的產品能力邊界

Agent-Native 的核心抽象是 defineAction()。

一個 Action 定義後，可以同時成為：

Agent Tool
React UI Query / Mutation
HTTP endpoint
MCP Tool
A2A Tool
CLI command

因此架構從傳統的：

text

UI → API Route → Service
Agent → Tool → Adapter → Service
MCP → MCP Handler → Adapter → Service
CLI → CLI Handler → Service

轉變成：

text

             ┌→ React UI
             ├→ Agent Tool
Action ──────┼→ HTTP
             ├→ MCP
             ├→ A2A
             └→ CLI
                  ↓
            Shared SQL State

真正重要的不是少寫幾個 endpoint，而是 UI 與 Agent 共用相同的 schema validation、access control、implementation 與 audit path。

這使 Action 更接近「產品 capability contract」，而不是一般 framework 中單純的 server function。

核心架構與運作方式

1. Shared Actions

官方將 Actions 定義為應用程式行為的 single source of truth。UI 點擊按鈕與 Agent 執行 tool call 最終會進入相同 Action，因此不用維護兩套產品邏輯。

2. Shared Application State

Agent 不只是讀取資料庫，它也可以取得使用者目前所在頁面、選取紀錄或 active view 等 UI context。

這使 Agent 能理解「使用者現在正在看什麼」，而不需要依靠 computer-use 去辨識畫面並點擊 UI。

3. Shared SQL Data

UI 與 Agent 使用相同 SQL state。官方架構以 Drizzle 為資料存取層，Production 可使用 PostgreSQL；因此 Agent 做出的修改會直接成為應用程式狀態，而不是停留在另一個 Agent memory silo。

4. Protocol-ready Action Surface

同一個 Action 可以直接暴露給 HTTP、MCP 與 A2A。這代表應用本身可以被 Claude、Codex、Cursor 等外部 MCP host 操作，也能讓其他 Agent-native application 透過 A2A 呼叫。

這比「完成產品後再另外做 MCP server」更接近 protocol-first application architecture。

5. Nitro Runtime

Server 層採用 Nitro，主要負責 authentication、startup、agent loop 與少數 Actions 無法表達的 HTTP concerns；核心 business logic 則被推向 Actions。

Nitro 也讓應用可部署到 Node.js、serverless function、edge worker 或其他相容環境。

6. Human / Agent Real-time Collaboration

官方的 collaborative editing 架構使用 Yjs CRDT 與 TipTap。人類與 Agent 的修改都可以成為同一份 Yjs operation stream，因此 Agent 被視為 collaborative editor 中的一個 peer，而不是背景產生整份文件再覆寫結果的外部服務。

主要優勢

避免 UI 與 Agent capability 漂移

傳統 AI integration 很容易形成兩套 API：一套服務 UI，一套服務 Agent。Agent-Native 把它們壓回同一 Action contract，因此新增產品能力時不必重新建立 Agent adapter。

權限模型更容易保持一致

Agent 與 UI 走相同 Action path，因此權限檢查不需要在 MCP、Agent tool 與 REST API 各自複製。

對 Agent 逐漸擁有 write capability 的應用而言，這比單純增加更多 tools 更重要。

不依賴 computer-use 操作自己的產品

如果 Agent 原本就擁有產品的 typed actions，就沒有必要讓 Agent 看畫面、找按鈕、模擬滑鼠操作。

這通常比 GUI automation 更快、更穩定，也更容易做 authorization 與 audit。

對外協定從架構層處理

MCP、A2A、HTTP 與 CLI 都是同一 capability surface 的不同 transport，而不是彼此獨立的 integration project。

Agent 與傳統 UI 可以共存

它沒有假設「未來所有軟體都只剩聊天框」。使用者仍可以使用表格、表單、Dashboard、Editor 等 deterministic UI；自然語言 Agent 則負責跨步驟操作與自動化。

這對真正面向一般使用者的 AI SaaS，比純聊天式 Agent framework 更務實。

相較同類型工具的優點

相較 LangGraph / CrewAI / AutoGen 類 Agent Framework

這些框架主要解決 Agent graph、orchestration、tool calling 或 multi-agent coordination。

Agent-Native 則更偏向 application architecture：資料、UI、Agent、permissions、actions 與 protocol surfaces 都屬於同一產品模型。

如果目標只是建立 headless agent pipeline，前者通常更直接；如果目標是完整 AI SaaS，Agent-Native 的抽象更貼近產品層。

相較一般 Next.js + AI SDK

一般全端框架可以自行實作相同架構，但開發者需要自行維護 API route、tool schema、permissions、MCP server、Agent context 與同步機制。

Agent-Native 的價值在於把這些問題變成 framework-level contract。

相較 Computer-use Agent

Computer-use 最大優勢是可以操作沒有 API 的既有軟體，但若應用本身就是自己開發的，讓 Agent 重新辨識自己的 UI 是額外且脆弱的一層。

Agent-Native 直接讓 Agent 呼叫 typed action，同時保留 UI 給人類使用，架構上更乾淨。

缺點與限制

生態系仍非常年輕

Agent-Native 是 2026 年的新興框架。相較 Next.js、React、LangChain 等成熟生態，第三方 integrations、教學、production case studies 與長期 API stability 都還需要時間驗證。

Framework opinion 很強

它要求開發者接受「Actions 是產品能力 single source of truth」這個核心設計。如果既有系統已經有成熟 Domain Service / REST / GraphQL 架構，遷移成本可能很高。

對既有大型系統不是低成本 retrofit

Agent-Native 最自然的使用方式是從新專案開始。若企業已有多個 backend service、API gateway 與既有 authorization model，把所有能力重新整理成 Actions 未必划算。

Action parity 不等於 Agent safety

即使 UI 與 Agent 使用相同權限路徑，Agent 仍可能做出錯誤決策。高風險 Action 仍然需要 approval、rate limit、audit、transaction boundary 與 server-side policy。

新抽象本身也會形成耦合

雖然框架強調 model、database 與 host 可替換，但一旦大量 business capability 都建立在 defineAction()、Agent-Native runtime 與其 conventions 上，應用仍會對 framework contract 形成實際耦合。

適合的使用者與專案

推薦給：

正在建立新的 AI-native SaaS
希望 Agent 與 UI 具有相同產品能力的團隊
需要 MCP / A2A / HTTP 多介面輸出的產品
想避免重複維護 UI API 與 Agent Tools 的 TypeScript 團隊
需要 Human-in-the-loop 與可視化 Agent 工作流程的產品
希望 Agent 能直接操作 application state，而不是依賴 browser automation 的專案

不適合的使用者與專案

暫時不建議：

只需要簡單 chatbot 的網站
單純建立 headless multi-agent pipeline
已有大型成熟 backend 且沒有重構需求的系統
對 framework stability 有極高要求的長生命週期企業核心系統
主要技術棧完全不使用 TypeScript / Web application architecture 的團隊

結論

Agent-Native 最值得注意的地方，不是又多了一套 Agent SDK，而是它重新定義了 「應用程式能力應該如何提供給人類與 Agent」。

過去 Web 架構通常先為人類 UI 建立 API，再另外替 AI 建立 tools。Agent-Native 反過來把 Action 提升成第一級產品 contract，UI、Agent、HTTP、MCP、A2A 與 CLI 都只是這個 contract 的不同入口。

如果 Agent 真正成為未來軟體中的一級使用者，這種「一次定義 capability，多個 human/machine surfaces 共用」的架構可能會比單純增加聊天介面更重要。

它目前仍屬早期生態，因此不適合無條件投入大型核心系統；但作為 2026 年正在快速成長的新型 Application Framework，Agent-Native 很值得現在開始追蹤與實驗。