要么做一个Agent产品，要么让你的产品能被Agent使用

做个什么Agent？

接下来做 AI 产品，不能简单纠结“做垂直 Agent 还是通用 Agent”了。

在应用层，环境对大模型能力的限制往往大于 Prompt 本身。现在更需要纠结的，是“给 AI 一个终端”，还是“给 AI 一个电脑”。

Claude Code、CoWork 之类客户端应用属于“终端派”，本质上是把终端作为 AI 的工具，让 AI 通过使用终端来辅助你控制你的电脑。

年前爆火的 OpenClaw，则属于“电脑派”：它给 AI 的不只是一个执行命令的终端，而是整个设备的最高控制权限和独立运行环境。

这俩派系不只是简单的“Agent 部署在哪里”的问题，它们的底层思维是完全不同的：

“终端派”的 Agent，定位依然是“副驾”，它跟人共用一个设备。

这导致它有两个致命缺陷：

一个是会跟用户抢资源，比如你不能跟 Agent 一起编辑某个文档；

另一个是设备一旦锁屏或关机，Agent 也就跟着下线了。

所以，OpenClaw 火了以后，很多人把它部署在自己的电脑上，这就属于是白凑热闹了，完全没发挥出它的核心价值。

“电脑派” Agent 的灵魂，来自两个核心条件：

一个是“7✕24 不关机的服务器/设备”，保证了异步和长周期任务的执行；

另一个是“独立拥有设备的所有权限”，保证了它可以不受干扰地搭建环境、运行程序。

大概相当于：一个永远不下班、配发了独立办公电脑，可以随时自己干活的倒霉员工。

可能的问题：Manus 和扣子 2.0 这种每个对话一个云端服务器，虽然在云端，但生命周期是跟着“对话 Session”走的，一旦对话结束或超时，环境就重置了，并不像 OpenClaw 那样拥有持久化设备的 Agent 产品，算啥？

我相信，以他们团队人才的聪明程度，会选择成为真正的 OpenClaw 的。

（扣子 2.0 的长期计划功能，其实就是个 OpenClaw）

如果不做Agent，怎么做应用？

不是所有产品或业务都值得用 AI 重做一遍，但所有产品和业务都需要做 AI 适配。

今天产品的交互界面都是为“人”设计的，其中 90% 都在被人类使用；3 年以内，被人直接使用的产品不会超过 10%。

未来的应用，最大的客户群体是 Agent。

Obsidian 前段时间更新的 1.12.0 版本，增加了一个允许从终端（CLI）控制 Obsidian 的功能。

这个改动极其敏锐。

能用终端控制应用 = 能使用终端的 Agent 可以直接控制应用。

对 Agent 来说，这比通过 MCP （本质上是运行脚本程序）或特定的 Skills （本质上是用一个 SOP 提示词让大模型生成内容）来控制应用要自然、友好得多。

终端（CLI）是操作系统的“母语”，像 OpenClaw 这样的 Agent 本身就在操作系统环境里，敲命令行是它的本能。

飞书很早以前就搞了个大活：把几乎所有开放的 API 接口封装成了 MCP，并提供了一个上下文友好的-t指定工具集参数。

虽然 MCP 因为 Token 消耗之巨，已经大概率被判了“死刑”，但飞书这团队，能够把“Agent 适配”这件事如此高效的落地，一看就是有极强的前瞻性和魄力的。

所以，未来的产品形态很清晰：要么你自己做一个 Agent，要么让你自己能被 Agent 极低成本地调用。

关于“Agent 适配”，还有一个容易被忽视的信息：OpenAI 去年 10 月上线的那个 APP SDK。

虽然这是从 Agent 平台视角来引导应用进行适配的，但其中透出了两个关键信号：

1. 你当前的应用，如果被模型作为工具调用了，返回给模型的数据和呈现应该是什么样的？LLM 能不能理解，或者能不能不让 LLM 理解（节省 token）直接使用？

2. 你的应用提供的服务，如何让模型相信你比其他同类应用更值得被调用？前一个是前面聊的适配改造需要思考的问题，归产品经理；后一个则是如何影响 Agent 决策的真正的 GEO（确切讲应该叫 AEO—Agent Engine Optimization），看起来归市场增长管，但因为它本质上是在构造一个大模型的 Tool Description，所以还是归产品经理…

去年 3 月份，我在给一家企业 IT 部的产研培训时，午餐跟他们 IT 老大聊天，被问了一个很典型的问题：

“我们有必要把所有内部工具都重构做成 MCP 么？”

我当时给的答案是“没必要”。

第一个原因，MCP 化的工程量比较大，协议层面的协调和对齐成本非常高。在实际业务里，模型需要哪个工具，直接通过原生的 API 去做 Function Calling 反而更直接、更轻量。对于那些已经有了成熟调用规范的企业内部接口来说，MCP 里最重要的那个“P（Protocol 协议）”成了画蛇添足，那 MCP 自然就没意义了。

第二个原因，也是更核心的原因：对稳定性要求极高的企业内部应用，在很长一段时间内依然会保持Workflow（工作流）式的开发。MCP 这种主打“提供一堆工具让大模型自由组合”的范式，在严肃的企业流程中是个伪命题。因为在 Workflow 中，第几步用什么工具、返回什么数据、走哪个条件分支，是写死的（SOP化）。企业需要的是确定性，而不是“由模型自由选择带来的幻觉风险”。

这两个原因是这部分要讨论的重点：

1. “做个 Agent” 或者“适配 Agent”，会像 2025 年年初火了一把的 MCP 一样成为年度炮灰么？

2. 面向企业业务，“做个 Agent”还是“继续 Workflow”，咋选？

答案就在这篇文章里提到的各种概念里。

先看炮灰 MCP：它只是让模型使用工具的其中一种尝试；比它更早、更底层的是 Function Calling；比它更符合业务逻辑的是此刻正火的 Skills。

如果你稍加研究就会发现，现在这个被热捧的 Skills，本质上其实就是把前面提到的“把终端作为工具让模型控制电脑”的各种能力，进行了原子化的封装。

再进一步，这些 Skills 的内核，其实就是之前企业里那些写死的 Workflow。

殊途同归这个词，应该已经悄然映上你的心头了。

所以，第二个问题其实是个伪命题：Workflow 和 Agent 不是二选一的对立选项，而是“主仆”。

企业不存在放弃稳定的 Workflow 去追求不确定的 Agent，而是应该把确定的 Workflow 包装成 Agent 的能力（Skills）。

无论如何，为大模型提供操作环境（终端/电脑），并通过调用各种能力去解决复杂问题，是必然趋势。

不管这个 Agent 是跑在员工的本机还是云端。

如果你希望极高的探索自由度，你可以直接放出一个“裸奔”的 Agent 让它自己试错；

如果你需要极强的业务可控性和稳定性，你就把原有的 Workflow 封装为特定的 Skills 配置给 Agent。

所以，具体的落地路径已经很清楚了：

1. 选底座：使用任意成熟的 Agent SDK 封装一个 Agent（新时代的“套壳”，无论是 Claude Agent SDK、Google 的 ADK、OpenClaw 用的 Pi-mono，还是字节的 Agentkit、阿里的 AgentScope 都可以）。

2. 造能力：

• 2.1 如果你团队已经沉淀了很多 Workflow，不用担心白干，只需把那些 “DSLs” 转化、封装成供大模型调用的 Skills。

• 2.2 如果你们还没搞过 Workflow，那就让产品经理把业务的最佳实践以 Workflow 的形式梳理出来，固化成逻辑，再转化成 Skills。

推上线：把这些编排好的 Skills，做好面向 Agent 的权限隔离（用于对内赋能）或者场景分类（用于对外服务），直接投产。

至于底层的模型能力问题，完全不用操心。春节前发布的国产模型已经极度能打了，节后的 DeepSeek V4 或者 R2 只会带来更大的惊喜。

如果你还纠结“国产模型行不行”的问题，说明你已经是没跟上技术进步的外行了。

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

我去年 10 月份预感到这个大趋势后，就在《AI产品经理转岗特训营》课程里更新了关于 Agent 的课程内容。

教学课程更新后，我们又一起做了一系列关于 Agent 的项目实践：

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

2. 开发了一个从需求挖掘到原型图到输出 PRD 的全自动多 Agent 协作流程

3. 开发了一个上传 Excel 可以自主规划、写代码、运行代码、撰写分析报告的数据分析 Agent

4. 拆解了几个最基础的 Agent 项目 DeepResearch 项目

下面是学员开发的 Deep Research 作品

不止 Demo，有学员在学习课程后，从 0 到 1 复现了 LovArt 这个 Agent 产品。

他在找工作的时候，也相应的有了更大的选择权：

《AI产品经理转岗特训营》这套课程的实训营版本，已经包含了几十节实践项目的带教直播，你可以直接查看回放跟做。

添加班主任，了解课程的详细课程内容和实践安排：

2026，争上游！