摘要
Skill、MCP、Plugin 正在让 AI 能力更容易进入 ChatGPT、Codex、Cursor 等工作环境，但“能力可以被调用”并不等于“产品可以被替代”。本文从软件工程治理、合同履约、垂直经营和复杂项目推进等场景出发，讨论一次任务与持续工作的差异，并尝试回答一个更实际的问题：当入口、模型和工具都可以变化时，哪些业务对象、规则、状态、权限和证据必须留在稳定的产品内核中。
关键词：AI Agent　Skill　MCP　Plugin　产品架构　Work
最近在梳理几类 AI 产品的产品形态时，我反复碰到一个问题：既然 ChatGPT、Codex、Cursor 这类工作入口已经可以直接调用外部能力，软件厂商还有没有必要继续维护一套独立产品？从表面看，把原有能力拆成 Skill、MCP Server 或 Plugin，接进用户已经在使用的环境，似乎是一条更轻、更快的路。可一旦把问题放到真实业务里，事情很快就没有那么简单。
我现在更倾向于把“入口”和“产品本身”拆开看。Skill、MCP、Plugin 解决的是能力怎样被发现、接入和调用；真正的产品内核则要回答业务对象是谁、当前状态是什么、规则怎样生效、谁有权执行动作、一次动作到底产生了什么业务结果，以及几天甚至几个月之后，这项工作还能不能从正确的位置继续。两者都重要，但它们不是同一个问题。
一、AI Agent 正在改变软件入口，但没有自动消灭业务系统
传统软件长期有一个很稳定的使用方式：用户先进入系统，再寻找功能。查合同要进合同系统，看客户要进 CRM，管理项目要打开项目管理软件，开发人员写代码则进入 IDE。软件厂商因此会投入大量精力经营自己的首页、工作台和菜单，因为用户只有先来到这里，功能才有机会被使用。
Agent 把这个前提松动了。开发者已经可以长时间待在 Codex、Cursor 这样的开发工作环境里，知识工作者也越来越习惯从通用 AI 工作入口直接表达意图。用户可能只说“检查这个版本还有哪些风险”“这笔应收为什么还没回来”，至于后面调用了哪个系统、经过了哪个接口，并不是他最关心的事情。
平台生态本身也在顺着这个方向发展。OpenAI 目前把 Plugin 作为 ChatGPT 和 Codex 发现工作流能力的重要方式，一个 Plugin 可以包含 Skill、App 和 App template；Cursor 的插件体系则可以把 Skill、MCP Server、Agent、Rule、Command、Hook 等能力组织成可分发的包。MCP 更偏底层，它把外部资源、工具和模型之间的接入方式标准化，使 AI 应用可以用统一方式读取上下文或调用外部动作。能力因此越来越容易离开原来的 UI，进入用户所在的工作环境。
这对软件厂商其实是机会。以前总想着怎样把用户拉回自己的系统，现在可以换个方向思考：用户已经在那里工作，我能不能把能力送过去？问题在于，入口被外部平台承载以后，很多人很容易再往前推一步，认为背后的独立产品也可以一起消失。真正需要警惕的，恰恰是把这两个问题混成一个问题。

二、Skill、MCP、Plugin 解决“能力可达”，产品内核解决“业务成立”

Skill、MCP、API、Plugin 并不是同一种技术。Skill 更接近可复用的任务知识、指令和工作方式；MCP 提供模型与外部数据、工具之间的标准化连接；Plugin 则可以进一步把多种能力打包、分发到具体平台。从工程实现上看，它们解决的问题不同，但从产品视角看有一个共同作用：让能力可以脱离原来的界面，被新的 AI 工作入口发现和使用。
问题是，业务系统真正难的部分通常并不是“能不能调用”。以合同履约为例，Agent 可以调用一个查询工具，告诉用户某笔款项已经逾期；它也可以调用邮件能力生成催收内容。但合同有没有完成交付、客户是否确认、应收金额以哪一个版本为准、谁负责推进、哪些节点已经生效，这些不能靠一次工具调用临时决定。它们构成的是一个长期存在的业务事实集合。
软件工程治理也一样。代码检查可以做成 Skill，代码仓库和 CI 可以通过 MCP 或 API 接入 Coding Agent，但哪些修改可以自动接受、哪些必须人工确认、什么操作属于高风险、验收标准是什么、最终是谁批准的，这些规则与证据不能随着开发人员今天用 Cursor、明天换 Codex 而变化。开发入口可以换，治理事实不能跟着漂移。
“应该进入一个平台”和“应该属于这个平台”，不是一回事。
这也是我现在理解“独立产品内核”的出发点。它并不意味着所有产品都要重新造一套厚重的 UI，也不意味着每个 Skill 后面都必须有庞大的业务系统。它只是要求我们把业务真正需要长期成立的部分找出来，让这些对象、状态、规则和责任有一个稳定的归属。

三、真正的分界线，不是 Skill 还是 App，而是一次任务还是持续工作

把会议纪要整理成待办、从合同里提取付款节点、检查一段代码有没有明显问题，这类任务有明确的输入和输出，执行完成以后基本可以结束。对于这种一次性、低状态依赖的事情，一个 Skill 或一个轻量 Agent 能力完全可能就是更好的产品形态，没有必要为了“独立”而再做一套完整系统。
但“持续跟踪这个版本直到完成验收”“把这份合同持续推进到回款”“持续经营这家店铺”“把一个大型项目从需求推进到客户确认”，性质就完全不同了。系统不仅要知道下一步做什么，还要记得过去发生过什么，区分什么已经生效、什么仍然只是候选，知道谁拥有下一步权限，以及满足什么条件以后工作才可以继续。
我习惯把前一种理解为 Function，后一种理解为 Work。Function 关注一次能力能不能完成，Work 关注同一件事情能不能持续向前推进。这里需要连续的不是聊天记录，而是业务本身：昨天已经确认的事实，今天不能因为打开了新会话重新变成猜测；已经执行过的动作不能第二天重复执行；已经生效的报价、承诺、验收结论也不能因为更换模型或入口而失效。
因此，一个 AI 产品需不需要稳定的独立内核，和它是不是“用了 Agent”关系并没有想象中那么大，反而和状态复杂度、持续时间、参与角色以及责任要求更相关。工作越短、状态越轻，越适合被平台收编；工作越长、参与者越多、业务效力越明确，就越需要自己的状态权威。

四、复杂业务里的产品内核，至少要守住什么

如果把独立产品内核理解成“再做一套后台”，其实又会走回传统软件的老路。真正应该留下的不是页面，而是业务语义。首先是业务对象和它们的生命周期，例如合同、项目、版本、报价、客户确认、订单、库存等；其次是这些对象的当前有效状态，以及状态变化为什么发生。没有这一层，Agent 每次拿到的只是零散数据，很难判断什么才是当前业务事实。
再往下是规则与权限。模型具备某项能力，并不代表它拥有业务授权。一个 Agent 可以生成报价，不等于报价已经生效；可以调用发布接口，不等于任何代码都允许上线；可以拟定催收动作，也不等于它有权代表企业对客户作出承诺。对企业级系统来说，能力、权限、业务效力和最终责任必须分开，否则 Agent 越能执行，风险反而越难控制。
还有一类容易被忽略的是历史和证据。复杂工作不会只关心“现在是什么”，还要解释“为什么变成现在这样”。谁修改了状态、依据是什么、哪些信息来自客户确认、哪些只是内部判断、一次动作有没有真正产生预期效果，这些都需要可追溯。模型可以帮助解释历史，但不应该自己成为历史事实的唯一保存者。
从架构上看，这些内容可以由领域服务、状态存储、规则引擎、授权服务、审计与事件记录等不同组件承担，并不要求物理上集中在一个单体系统里。所谓“产品内核”，更准确地说是一套稳定的业务权威边界：外面的模型和入口可以变化，但这套边界知道什么是真、什么有效、谁能做、做完以后发生了什么。

五、多平台不是多做几个接口，而是入口变化后仍能继续同一项 Work

现在说“多平台适配”，很容易理解成给 ChatGPT 做一个 Skill，给 Cursor 做一个 Plugin，再给企业内部 Agent 接一个 MCP Server。接口数量确实多了，但如果三个入口各自保存一套上下文，用户每换一个地方就要重新解释项目背景，那只是多入口，还不是持续工作。
更有价值的状态是：上午用户在企业自己的系统里确认了一项客户需求，下午从另一个 AI 工作入口询问项目风险，晚上再通过第三个 Agent 发起下一步动作。三个入口完全不同，但业务上仍然是同一个项目。上午确认过的事实下午仍然有效，下午形成的决定晚上能够继续，已经发生过的动作不会重复，权限和责任也不会因为入口变化而丢失。
这背后需要一个稳定的状态权威。Agent 可以拿到当前状态、调用能力、提出下一步建议，甚至在授权范围内执行动作，但它不应该因为自身会话结束就带走工作的唯一真相。对企业级 AI 系统来说，这种“跨入口连续性”可能比支持多少个模型、接了多少个 MCP 更值得关注。

六、未来的软件可能是“入口变薄，内核变重”

如果 AI 工作入口继续发展，我确实认为很多传统 App 的入口价值会下降。用户没有必要为了完成一个动作在十几个系统之间反复切换，一些低状态、低责任、一次性任务也很可能直接被平台内置能力或 Skill 吸收。对这类场景来说，继续坚持“必须让用户打开我的 App”没有太大意义。
但这不等于独立产品会整体消失。对真正掌握业务对象、数据、规则、状态和责任的产品来说，变化更可能发生在外壳：自己的 UI 可以变薄，能力可以通过 Skill、MCP、API、Plugin 进入不同工作入口，但业务内核反而要更加清楚。尤其当 Agent 能够直接执行动作以后，谁是业务事实的权威、什么结果已经生效、谁拥有权限、出了问题如何追溯，只会变得更重要。
所以我现在更认可的不是“独立产品还是 Skill”这道二选一，而是“独立产品内核 + 多平台能力入口”。入口解决用户在哪里工作，Skill、MCP、Plugin 解决能力怎样到达那里，产品内核则负责让业务长期成立。轻量能力可以尽量平台化，复杂业务则应该把状态权威、领域规则和责任边界留在自己手里。
入口可以换，平台可以换，模型也可以换；但同一项工作，应该还能继续。

参考资料

1. OpenAI Help Center：Plugins in ChatGPT and Codex
2. Cursor Docs：Plugins
3. Cursor：Extend Cursor with plugins
4. Model Context Protocol Specification：Overview / Tools / Resources

作者：邓松高

长期从事软件研发与产品架构相关工作，关注 AI Native 产品方法论、产品架构，以及 AI 在真实业务系统中的落地。