要么做一個(gè)Agent產(chǎn)品，要么讓你的產(chǎn)品能被Agent使用

做個(gè)什么Agent？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我相信，以他們團(tuán)隊(duì)人才的聰明程度，會(huì)選擇成為真正的 OpenClaw 的。

（扣子 2.0 的長(zhǎng)期計(jì)劃功能，其實(shí)就是個(gè) OpenClaw）

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

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

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

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

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

這個(gè)改動(dòng)極其敏銳。

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

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

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

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

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

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

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

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

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)用？前一個(gè)是前面聊的適配改造需要思考的問題，歸產(chǎn)品經(jīng)理；后一個(gè)則是如何影響 Agent 決策的真正的 GEO（確切講應(yīng)該叫 AEO—Agent Engine Optimization），看起來歸市場(chǎng)增長(zhǎng)管，但因?yàn)樗举|(zhì)上是在構(gòu)造一個(gè)大模型的 Tool Description，所以還是歸產(chǎn)品經(jīng)理…

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

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

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

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

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

這兩個(gè)原因是這部分要討論的重點(diǎn)：

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

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

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

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

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

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

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

所以，第二個(gè)問題其實(shí)是個(gè)偽命題：Workflow 和 Agent 不是二選一的對(duì)立選項(xiàng)，而是“主仆”。

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

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

不管這個(gè) Agent 是跑在員工的本機(jī)還是云端。

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

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

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

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

2. 造能力：

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

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

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

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

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

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

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

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

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

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

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

4. 拆解了幾個(gè)最基礎(chǔ)的 Agent 項(xiàng)目 DeepResearch 項(xiàng)目

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

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

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

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

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

2026，爭(zhēng)上游！