做個什么Agent？

接下來做 AI 產(chǎn)品，不能簡單糾結(jié)“做垂直 Agent 還是通用 Agent”了。

在應(yīng)用層，環(huán)境對大模型能力的限制往往大于 Prompt 本身?，F(xiàn)在更需要糾結(jié)的，是“給 AI 一個終端”，還是“給 AI 一個電腦”。

Claude Code、CoWork 之類客戶端應(yīng)用屬于“終端派”，本質(zhì)上是把終端作為 AI 的工具，讓 AI 通過使用終端來輔助你控制你的電腦。

年前爆火的 OpenClaw，則屬于“電腦派”：它給 AI 的不只是一個執(zhí)行命令的終端，而是整個設(shè)備的最高控制權(quán)限和獨立運行環(huán)境。

這倆派系不只是簡單的“Agent 部署在哪里”的問題，它們的底層思維是完全不同的：

“終端派”的 Agent，定位依然是“副駕”，它跟人共用一個設(shè)備。

這導(dǎo)致它有兩個致命缺陷：

一個是會跟用戶搶資源，比如你不能跟 Agent 一起編輯某個文檔；

另一個是設(shè)備一旦鎖屏或關(guān)機，Agent 也就跟著下線了。

所以，OpenClaw 火了以后，很多人把它部署在自己的電腦上，這就屬于是白湊熱鬧了，完全沒發(fā)揮出它的核心價值。

“電腦派” Agent 的靈魂，來自兩個核心條件：

一個是“7?24 不關(guān)機的服務(wù)器/設(shè)備”，保證了異步和長周期任務(wù)的執(zhí)行；

另一個是“獨立擁有設(shè)備的所有權(quán)限”，保證了它可以不受干擾地搭建環(huán)境、運行程序。

大概相當(dāng)于：一個永遠(yuǎn)不下班、配發(fā)了獨立辦公電腦，可以隨時自己干活的倒霉員工。

可能的問題：Manus 和扣子 2.0 這種每個對話一個云端服務(wù)器，雖然在云端，但生命周期是跟著“對話 Session”走的，一旦對話結(jié)束或超時，環(huán)境就重置了，并不像 OpenClaw 那樣擁有持久化設(shè)備的 Agent 產(chǎn)品，算啥？

我相信，以他們團隊人才的聰明程度，會選擇成為真正的 OpenClaw 的。

（扣子 2.0 的長期計劃功能，其實就是個 OpenClaw）

如果不做Agent，怎么做應(yīng)用？

不是所有產(chǎn)品或業(yè)務(wù)都值得用 AI 重做一遍，但所有產(chǎn)品和業(yè)務(wù)都需要做 AI 適配。

今天產(chǎn)品的交互界面都是為“人”設(shè)計的，其中 90% 都在被人類使用；3 年以內(nèi)，被人直接使用的產(chǎn)品不會超過 10%。

未來的應(yīng)用，最大的客戶群體是 Agent。

Obsidian 前段時間更新的 1.12.0 版本，增加了一個允許從終端（CLI）控制 Obsidian 的功能。

這個改動極其敏銳。

能用終端控制應(yīng)用 = 能使用終端的 Agent 可以直接控制應(yīng)用。

對 Agent 來說，這比通過 MCP （本質(zhì)上是運行腳本程序）或特定的 Skills （本質(zhì)上是用一個 SOP 提示詞讓大模型生成內(nèi)容）來控制應(yīng)用要自然、友好得多。

終端（CLI）是操作系統(tǒng)的“母語”，像 OpenClaw 這樣的 Agent 本身就在操作系統(tǒng)環(huán)境里，敲命令行是它的本能。

飛書很早以前就搞了個大活：把幾乎所有開放的 API 接口封裝成了 MCP，并提供了一個上下文友好的-t指定工具集參數(shù)。

雖然 MCP 因為 Token 消耗之巨，已經(jīng)大概率被判了“死刑”，但飛書這團隊，能夠把“Agent 適配”這件事如此高效的落地，一看就是有極強的前瞻性和魄力的。

所以，未來的產(chǎn)品形態(tài)很清晰：要么你自己做一個 Agent，要么讓你自己能被 Agent 極低成本地調(diào)用。

關(guān)于“Agent 適配”，還有一個容易被忽視的信息：OpenAI 去年 10 月上線的那個 APP SDK。

雖然這是從 Agent 平臺視角來引導(dǎo)應(yīng)用進(jìn)行適配的，但其中透出了兩個關(guān)鍵信號：

1. 你當(dāng)前的應(yīng)用，如果被模型作為工具調(diào)用了，返回給模型的數(shù)據(jù)和呈現(xiàn)應(yīng)該是什么樣的？LLM 能不能理解，或者能不能不讓 LLM 理解（節(jié)省 token）直接使用？

2. 你的應(yīng)用提供的服務(wù)，如何讓模型相信你比其他同類應(yīng)用更值得被調(diào)用？前一個是前面聊的適配改造需要思考的問題，歸產(chǎn)品經(jīng)理；后一個則是如何影響 Agent 決策的真正的 GEO（確切講應(yīng)該叫 AEO—Agent Engine Optimization），看起來歸市場增長管，但因為它本質(zhì)上是在構(gòu)造一個大模型的 Tool Description，所以還是歸產(chǎn)品經(jīng)理…

去年 3 月份，我在給一家企業(yè) IT 部的產(chǎn)研培訓(xùn)時，午餐跟他們 IT 老大聊天，被問了一個很典型的問題：

“我們有必要把所有內(nèi)部工具都重構(gòu)做成 MCP 么？”

我當(dāng)時給的答案是“沒必要”。

第一個原因，MCP 化的工程量比較大，協(xié)議層面的協(xié)調(diào)和對齊成本非常高。在實際業(yè)務(wù)里，模型需要哪個工具，直接通過原生的 API 去做 Function Calling 反而更直接、更輕量。對于那些已經(jīng)有了成熟調(diào)用規(guī)范的企業(yè)內(nèi)部接口來說，MCP 里最重要的那個“P（Protocol 協(xié)議）”成了畫蛇添足，那 MCP 自然就沒意義了。

第二個原因，也是更核心的原因：對穩(wěn)定性要求極高的企業(yè)內(nèi)部應(yīng)用，在很長一段時間內(nèi)依然會保持Workflow（工作流）式的開發(fā)。MCP 這種主打“提供一堆工具讓大模型自由組合”的范式，在嚴(yán)肅的企業(yè)流程中是個偽命題。因為在 Workflow 中，第幾步用什么工具、返回什么數(shù)據(jù)、走哪個條件分支，是寫死的（SOP化）。企業(yè)需要的是確定性，而不是“由模型自由選擇帶來的幻覺風(fēng)險”。

這兩個原因是這部分要討論的重點：

1. “做個 Agent” 或者“適配 Agent”，會像 2025 年年初火了一把的 MCP 一樣成為年度炮灰么？

2. 面向企業(yè)業(yè)務(wù)，“做個 Agent”還是“繼續(xù) Workflow”，咋選？

答案就在這篇文章里提到的各種概念里。

先看炮灰 MCP：它只是讓模型使用工具的其中一種嘗試；比它更早、更底層的是 Function Calling；比它更符合業(yè)務(wù)邏輯的是此刻正火的 Skills。

如果你稍加研究就會發(fā)現(xiàn)，現(xiàn)在這個被熱捧的 Skills，本質(zhì)上其實就是把前面提到的“把終端作為工具讓模型控制電腦”的各種能力，進(jìn)行了原子化的封裝。

再進(jìn)一步，這些 Skills 的內(nèi)核，其實就是之前企業(yè)里那些寫死的 Workflow。

殊途同歸這個詞，應(yīng)該已經(jīng)悄然映上你的心頭了。

所以，第二個問題其實是個偽命題：Workflow 和 Agent 不是二選一的對立選項，而是“主仆”。

企業(yè)不存在放棄穩(wěn)定的 Workflow 去追求不確定的 Agent，而是應(yīng)該把確定的 Workflow 包裝成 Agent 的能力（Skills）。

無論如何，為大模型提供操作環(huán)境（終端/電腦），并通過調(diào)用各種能力去解決復(fù)雜問題，是必然趨勢。

不管這個 Agent 是跑在員工的本機還是云端。

如果你希望極高的探索自由度，你可以直接放出一個“裸奔”的 Agent 讓它自己試錯；

如果你需要極強的業(yè)務(wù)可控性和穩(wěn)定性，你就把原有的 Workflow 封裝為特定的 Skills 配置給 Agent。

所以，具體的落地路徑已經(jīng)很清楚了：

1. 選底座：使用任意成熟的 Agent SDK 封裝一個 Agent（新時代的“套殼”，無論是 Claude Agent SDK、Google 的 ADK、OpenClaw 用的 Pi-mono，還是字節(jié)的 Agentkit、阿里的 AgentScope 都可以）。

2. 造能力：

• 2.1 如果你團隊已經(jīng)沉淀了很多 Workflow，不用擔(dān)心白干，只需把那些 “DSLs” 轉(zhuǎn)化、封裝成供大模型調(diào)用的 Skills。

• 2.2 如果你們還沒搞過 Workflow，那就讓產(chǎn)品經(jīng)理把業(yè)務(wù)的最佳實踐以 Workflow 的形式梳理出來，固化成邏輯，再轉(zhuǎn)化成 Skills。

推上線：把這些編排好的 Skills，做好面向 Agent 的權(quán)限隔離（用于對內(nèi)賦能）或者場景分類（用于對外服務(wù)），直接投產(chǎn)。

至于底層的模型能力問題，完全不用操心。春節(jié)前發(fā)布的國產(chǎn)模型已經(jīng)極度能打了，節(jié)后的 DeepSeek V4 或者 R2 只會帶來更大的驚喜。

如果你還糾結(jié)“國產(chǎn)模型行不行”的問題，說明你已經(jīng)是沒跟上技術(shù)進(jìn)步的外行了。

2026 年，一起擁抱&落地真正能打的 Agent 吧！

我去年 10 月份預(yù)感到這個大趨勢后，就在《AI產(chǎn)品經(jīng)理轉(zhuǎn)崗特訓(xùn)營》課程里更新了關(guān)于 Agent 的課程內(nèi)容。

教學(xué)課程更新后，我們又一起做了一系列關(guān)于 Agent 的項目實踐：

1. 用 Claude Code 的 SubAgents 能力體驗了一下多 Agent 是如何交互的

2. 開發(fā)了一個從需求挖掘到原型圖到輸出 PRD 的全自動多 Agent 協(xié)作流程

3. 開發(fā)了一個上傳 Excel 可以自主規(guī)劃、寫代碼、運行代碼、撰寫分析報告的數(shù)據(jù)分析 Agent

4. 拆解了幾個最基礎(chǔ)的 Agent 項目 DeepResearch 項目

下面是學(xué)員開發(fā)的 Deep Research 作品

不止 Demo，有學(xué)員在學(xué)習(xí)課程后，從 0 到 1 復(fù)現(xiàn)了 LovArt 這個 Agent 產(chǎn)品。

他在找工作的時候，也相應(yīng)的有了更大的選擇權(quán)：

《AI產(chǎn)品經(jīng)理轉(zhuǎn)崗特訓(xùn)營》這套課程的實訓(xùn)營版本，已經(jīng)包含了幾十節(jié)實踐項目的帶教直播，你可以直接查看回放跟做。

添加班主任，了解課程的詳細(xì)課程內(nèi)容和實踐安排：

2026，爭上游！