夜雨聆风从 ObjectStack 的 Object、Action、Permission 与 MCP，看 AI-Native 企业软件为什么开始从 Endpoint-Centric 走向 Business-Centric
适合阅读：CTO / 技术负责人 / SaaS 创业者 / AI 产品经理 / 架构师 / Agent 工程师 / MCP 关注者
当一个销售对着 AI Agent 说了一句话：帮我把华东区域、过去 30 天没有跟进的高价值客户，找出来。
这句话对人来说毫无难度。但如果这个 Agent 面对的是一套传统 CRM 的 API，它要做的事大概是这样：先找到客户接口、再找到销售机会接口、再找到跟进记录接口、再找到用户和区域接口，然后拼出正确的过滤条件，发好几个 API 请求，自己理解每个字段是什么意思，自己判断哪些返回结果能组合到一起，最后才能做出那个高价值且未跟进的推理。
表面上看，API 都是现成的。但实际上——Agent 拿到了一堆接口，却没有拿到一个真正的业务模型。它得到的是怎么调用，而不是这门生意长什么样。
于是一个问题浮出来了：如果这套 CRM 给 Agent 的，不是几十个 endpoint，而是客户、机会、跟进记录、负责人、区域这些有明确关系的业务对象，再加上查询、创建、转化、审批、关闭这些带权限的业务动作，会发生什么？
MCP 真正重要的地方，也许不是它让 Agent调用 API变简单了，而是它逼着我们重新想一个更根本的问题：企业软件，到底应该怎样向 Agent 表达自己的能力？
这篇文章想借一个具体的开源项目 ObjectStack 作为观察样本，讨论这个比它本身大得多的问题。先说清楚：这不是一篇 ObjectStack 介绍，也不是 MCP 教程。它想回答的只有一个问题——如果 AI Agent 成了软件的新使用者，我们是不是该重新设计软件的接口？
一、REST API 对人很好，但对 Agent 未必
先给 REST 一个公道的评价：它是互联网软件极其成功的一套抽象，这一点不该被否认。
REST 的世界，是为「人 / 开发者」设计的——开发者通过 SDK 或代码，调用 HTTP 接口，操作应用。对程序员来说，下面这组接口清晰明了：
GET /customers GET /customers/123 POST /customers PATCH /customers/123 POST /opportunities |
但 Agent 面对的是另一个问题。对它来说，这些 endpoint 是实现层，而不是业务语义层。
Agent 并不天然知道这些事：
· customer 和 account，到底有什么区别？ · opportunity 和 lead，是什么关系？ · 哪个动作是业务上允许的？ · 哪个字段是敏感字段，不该随便读写？ · 哪个操作需要审批？ · 哪些数据属于当前这个用户？ · 这几个接口，应该先调哪个？ |
这些信息，REST 的 endpoint 列表里都没有。它们藏在文档里、藏在开发者的脑子里、藏在字段命名的潜规则里。所以，接口多，并不等于 Agent 更容易使用这个系统。
甚至可能相反：API 越多，Agent 面对的搜索空间就越大——它要在几十上百个语义模糊的接口里，猜出正确的调用组合。接口的数量，成了它的负担，而不是它的能力。
二、Agent 真正需要的，是业务对象
从这里开始，我们引入 ObjectStack 作为观察样本。（以下涉及仓库能力的描述，以其当前公开 README / 源码为准。）
根据 ObjectStack 当前仓库，它把 Object、Field、Relation 这些东西，定义成带类型的元数据（Typed Metadata）。它 README 里描述的能力，涵盖了业务对象与字段、关系、校验、权限、自动化、审批、视图、仪表盘、动作、API 与 SDK、以及 AI 工具等。
但这里的重点不是罗列它有多少功能，而是一个抽象层面的判断——
Object，是一个比 Endpoint 更接近业务语义的 Agent 抽象。
当 Agent 面对的是一个客户对象时，它看到的是这样一个有结构、有关系的东西：
Customer（客户） ├── name 名称 ├── industry 行业 ├── owner 负责人 └── opportunities 关联的机会（一对多） Opportunity（机会） ├── amount 金额 ├── stage 阶段 ├── owner 负责人 └── customer 所属客户 |
Agent 看到的不再是一串 `GET /api/xxx`、`POST /api/xxx`，而是：客户是什么、机会是什么、二者是什么关系、当前我能对它们做什么。这是一个非常重要的抽象变化：
从 Endpoint-Centric，走向 Object-Centric。
三、但光有 Object 还不够，Agent 还需要 Action
这是全文最关键的一节。因为能看见数据，不等于能操作业务。
企业软件里最重要的东西，往往不是增删改查（CRUD），而是那些真正承载业务含义的动作：
Approve（批准） Reject（驳回） Convert（转化） Close（关闭） Assign（指派） Escalate（升级） Resolve（解决） |
这些是业务动作。它们背后往往牵连着一整套规则：转化一个机会，会改变它的阶段、可能生成合同、触发通知；批准一笔申请，要走审批流、写记录、改状态。这些远不是一个改数据库字段能概括的。
所以 Agent 真正需要的，不是这样一个赤裸的数据库操作：
POST /opportunities/123 （把这条记录改一下） |
而更应该是这样一个带业务含义的动作：
Opportunity（机会） └── Convert（转化） Ticket（工单） └── Resolve（解决） |
根据 ObjectStack 当前 README，它的设计是：对象默认自动暴露，而动作通过一个显式标记来选择性开放——「Objects are exposed automatically; actions opt in with ai: { exposed: true }」。
这里要重点解释：这个设计真正重要的，不是ObjectStack 有一个 MCP 插件这种功能层面的事。真正重要的是它背后的含义——
业务 Action 本身，成为了 Agent 的 Tool。
也就是说，一个原本给人点击的业务动作，经过这样一条链路，变成了 Agent 能调用的工具：
人点的按钮（Human Button） ↓ 业务动作（Business Action） ↓ 权限校验（Permission Check） ↓ 运行时（Runtime） ↓ Agent 工具（MCP Tool） |
于是 Agent 调用的，不再是一个数据库操作，而是一个业务动作。这是从「API」走向Agent API最关键的一步——它交给 Agent 的，是业务能力，不是数据表的读写权。
四、真正的难点，不是暴露 Tool，而是暴露安全的 Tool
讲到这，一个容易让人乐观过头的想法会冒出来：那我把所有 API 都包装成 MCP Tool，企业软件不就一夜之间变成 AI-Native 了吗？
没那么简单。因为企业软件最大的难题，从来不是调用，而是——调用之后，谁负责？
举个例子。Agent 说：把张三名下的所有客户，转给我。
这绝不是一个简单的 API call。系统必须在执行之前，回答一连串问题：
· 当前这个 Agent 是谁？它代表哪个用户在操作？ · 这个用户，有没有「客户转移」的权限？ · 有没有行级限制（这些客户它是否有权碰）？ · 有没有字段级限制（某些字段它不能读/写）？ · 这个操作，是否需要审批？ · 这次操作，要不要写进审计日志（Audit Log）？ |
所以，一个能给 Agent 用的业务动作，必须是被治理的工具（Governed Tool），而绝不能是一个可以绕过权限的万能后门。这条线，是企业软件能不能真正把能力交给 Agent 的生死线。
五、ObjectStack 的 MCP 设计，为什么值得一看？
这一节开始系统地看仓库，且严格基于当前公开事实。根据 ObjectStack 当前 README 的描述：
· 运行时（Runtime）内置提供 MCP Server · MCP endpoint 默认开启，路径为 /api/v1/mcp · Objects 自动暴露给 Agent · Action 通过 ai: { exposed: true } 选择性暴露 · Agent 的操作，仍然要经过 permissions / RLS · Runtime 在调用过程中，执行治理（governance）与审计（audit） |
（说明：以上为 ObjectStack 当前 README 所述能力，引用其官方文档表述，不作为第三方独立验证。）
把这些串起来，Agent 访问业务数据的路径大致是这样：
Agent │ （通过 MCP） ▼ ObjectStack Runtime │ ├── Object（业务对象） ├── Action（业务动作） ├── Permission（权限） ├── RLS（行级安全） ├── Audit（审计） │ ▼ Business Data（业务数据） |
看清这张图，你会得到一个关键判断：MCP 只是入口。真正的Agent-Native能力，不来自 MCP 这个协议本身，而来自它下面那层——Object + Action + Permission + Runtime 四者的组合。协议只是门，门后面有没有一个可理解、可操作、可治理的业务系统，才是关键。
六、这会改变我们设计 API 的方式吗？
我们把两种接口，摆在一起对比。
传统 API | Agent-Native 业务接口 | |
核心单位 | Endpoint、Method、参数、Response | Object、Relation、Action、Permission、Context、Policy、Result |
核心问题 | 怎么调用我？ | 你能对这个业务对象做什么？ |
面向 | 程序 / 开发者 | AI Agent / 业务能力 |
提供的是 | 连接性（Connectivity） | 语义 + 能力 + 治理 |
API 正在从操作接口，变成业务能力接口
传统 API 回答的是怎么调用——它是一个操作接口。而 Agent 需要的接口，回答的是你能对这个业务对象做什么——它是一个业务能力接口。这个转变，比它听起来要深刻。
未来 API 的价值，不只是可调用，更是可理解
过去我们评价一个 API 好不好，看的是它好不好调、文档全不全、稳不稳定。而在 Agent 时代，一个 API 的价值，越来越取决于它可不可被理解——Agent 能不能不靠人写文档，就搞懂它是什么、能干什么、有什么约束。可理解性，正在成为接口的一等属性。
七、MCP 之后，API 会消失吗？
这个问题必须正面回答：不会。
请不要把这篇文章读成REST 已经过时。更合理的判断是：REST 和 MCP，服务的是不同的调用主体。
协议 | 服务的调用主体 |
REST | 应用↔应用、前端↔后端、服务↔服务 |
MCP | AI Agent ↔ 业务系统 |
往前推演，一个企业应用，未来很可能同时拥有好几种一等公民级别的访问方式：
Human（人） → UI Developer（开发者）→ REST / SDK AI Agent → MCP Workflow（流程） → Events / Webhooks |
所以真正的变化，不是MCP 替代了 API，而是——一个企业软件，开始拥有多种一等公民的访问方式。UI 给人，REST 给程序，MCP 给 Agent，事件给流程。它们并存，各司其职。
八、为什么真正的 Agent API，必须建立在 Metadata 之上？
这一节，从 MCP 回到架构的根子上。
提一个问题：如果 Agent 要真正理解客户、机会、工单、审批这些东西，那么这些东西的定义，不能只散落在这些地方——
· 数据库 schema 里（只有表和字段，没有业务语义） · Controller 代码里（藏在实现逻辑中） · React 组件里（只是界面） · API 文档里（是给人读的，不保证和代码同步） |
它们必须存在于一个统一的地方——一个机器可读、可验证、可执行的业务定义层。而这，就是 Metadata。
于是整个结构变成了这样：一份带类型的元数据，向下派生出数据库、REST API、UI 和 MCP。
Typed Metadata（带类型的业务元数据） ↓ Runtime（运行时） ├── Database ├── REST API ├── UI └── MCP |
这里藏着一个关键判断：MCP 不是独立存在的，它是整个元数据驱动的运行时的一个出口。
所以，MCP 的上限，不取决于协议本身，而取决于它下面的软件，有没有一个足够好的业务语义层。协议再标准，接的若是一团没有语义的代码，Agent 依然寸步难行。
九、为什么把所有 API 转成 MCP Tool仍然不够？
举一个反例，把这件事说透。
假设有一个传统 CRM，它有 500 个 REST endpoint。现在你图省事，把它们一键全部暴露成 MCP Tool。Agent 打开一看，面对的是：
· 500 个 tool · 海量参数 · 彼此不明确的依赖关系 · 大量重复的 CRUD · 一堆底层实现细节 |
结果很可能是一场灾难，业界有个词叫它——Tool Explosion（工具爆炸）。Agent 的失败，往往不是因为没有 API，恰恰相反，是因为 API 太多、却没有业务结构。它被淹没在语义模糊的工具海里，根本组织不出正确的调用。
所以一个真正 Agent-Native 的软件，应该尽量向 Agent 提供的是业务对象 + 业务关系 + 业务动作 + 权限 + 上下文这样一个有结构的东西，而不是 500 个扁平的 endpoint。这可以形成一个很强的观点：
Agent-Native API 的第一原则，不是更多 Tool，而是更高的语义密度。
十、Agent 用企业软件，本质是业务操作，不是数据库操作
用三个具体例子，把这个判断坐实。
例子一：CRM
用户说：找出本季度没有跟进的高价值机会，并给我生成跟进计划。Agent 需要理解的是机会、金额、阶段、上次活动时间、负责人、当前用户这些业务概念之间的关系，而不是仅仅去调一个 `GET /opportunities` 然后自己在返回的一堆 JSON 里硬猜。
例子二：工单系统
用户说：把所有 P1 且超过 SLA 的工单升级。Agent 需要的是工单、优先级、SLA、升级（Escalate）动作、权限、审计这一整套业务语义——它调用的应该是一个叫 Escalate 的业务动作，而不是自己去拼一个改状态字段的请求。
例子三：审批系统
用户说：把金额低于 10 万的采购申请，全部批掉。这里最能看出区别。Agent 绝不应该直接去改：`status = approved`。它应该调用的是一个 Approve 动作，然后由运行时去完成这一连串事情：
调用 Approve 之后，Runtime 负责： · 判断当前用户有没有审批权限 · 写入审批记录 · 更新申请状态 · 记录 Audit 日志 · 触发后续的 Workflow（如通知、生成凭证） |
这就是为什么，业务 Action 比 CRUD 更重要。直接改字段，是绕过了业务规则；调用动作，才是让业务规则完整地跑一遍。前者危险，后者才安全。
十一、ObjectStack 为什么把 MCP 放在 Runtime，而不是做成外挂？
这是一个很重要的架构选择。先看两种做法的区别。
传统的、给旧系统加 AI 能力的做法，往往是外挂一层适配器：
Application（应用） ↓ REST API ↓ MCP Adapter（外挂的适配层） ↓ Agent |
而根据其架构，ObjectStack 更接近这样——MCP 和 REST、SDK、UI 是并列的，都从同一个运行时里长出来：
Application Runtime（应用运行时） ├── REST ├── SDK ├── UI └── MCP 它们共享同一套： Object Model / Metadata / Permission / Runtime / Business Action |
这个区别的意义在于：MCP 不是给旧系统补的一个 AI 适配器，而是从运行时层原生提供的 Agent 接口。这意味着，同一份业务定义（客户、机会、工单），可以同时、且一致地服务于人、开发者、和 AI Agent——它们看到的是同一个业务模型，受同一套权限约束，而不是三套各行其是、可能对不上的实现。
十二、SaaS 的入口正在改变
把上面的讨论往上抽一层，会看到一个对 SaaS 影响深远的变化。
传统 SaaS 的入口只有一条路：人，通过 UI，使用 SaaS。所以过去几十年，SaaS 的设计重心是 UI/UX——怎么让人更容易点。
而 AI-Native 的世界里，入口变成了多条并行：
传统：Human → UI → SaaS 现在：Human → UI → SaaS AI Agent → MCP → SaaS 更进一步： AI Agent → 业务对象 / 动作 → Runtime |
结论不是UI 会消失——这个说法太粗暴。更严谨的说法是：UI 从唯一入口，变成了多入口体系中的一种。人依然需要 UI，但软件同时要为 Agent 准备一个同样一等公民的入口。
十三、未来，谁来设计 API？
如果 Agent 使用的不再是 HTTP 接口，而是业务能力模型，那么设计接口这件事本身，也会变。
传统上，API 是后端工程师设计的。而未来，这件事可能会分化成一组新的角色——领域设计者、本体设计者、Agent 工具设计者、策略设计者、运行时工程师。因为要决定的问题，不再是这个 endpoint 参数怎么定，而是一组更偏业务、也更偏治理的问题：
· 哪些 Object 该暴露给 Agent，哪些不该？ · 哪些 Action 该开放，哪些必须留给人？ · Action 的参数语义怎么定义，Agent 才不会误用？ · 哪些操作，Agent 执行前必须二次确认？ · 哪些操作，必须走人工审批？ · 什么角色的 Agent，能调用什么工具？ · 什么场景下，某个 Tool 应该对 Agent 隐藏？ |
这可能会成为一种全新的企业软件设计能力，我们可以叫它Agent 接口设计（Agent Interface Design）。它设计的不是 HTTP，而是一个业务系统，愿意、且安全地，向 AI 敞开哪些能力。
十四、ObjectStack 只是一个案例，这个方向不只属于它
要明确一点：ObjectStack 并不代表这个方向已经成为行业标准，它只是一个很有代表性的开源架构案例。
真正值得观察的，是几个趋势正在同一个地方汇合：
带类型的元数据（Typed Metadata） + 业务本体（Business Ontology） + MCP + Agent Skills + 运行时治理（Runtime Governance） + 由 Schema 驱动的 UI |
根据 ObjectStack 当前 README，它正把这些东西放进同一个运行时里——它提供了 Agent Skills bundle、AGENTS.md、对 Claude Code / Cursor / Copilot 工作流的支持、MCP、Object / Action 的暴露机制、带类型的元数据、校验、权限 / RLS / 审计，以及 ObjectQL、ObjectUI、微内核加插件的架构。
（以上均为其当前 README 所述能力，作为仓库事实引用，不扩展为未经验证的行业结论。）它的价值，不在于支持 MCP这一个功能点，而在于它把这些原本分散的能力，收拢进了同一个业务抽象里。
十五、MCP 之后，真正要重设计的是接口哲学
绕了一大圈，回到最开始那个问题。结论不该是ObjectStack 很厉害，而该回到行业本身。
传统软件 | Agent-Native 软件 | |
接口在说 | 怎么调用我 | 你可以对我的业务做什么 |
接口的对象 | 程序 | Agent |
解决的是 | 连接性（Connectivity） | 语义 + 能力 + 治理 |
所以，MCP 并不是 REST 的下一代版本。更准确地说：MCP 是 Agent 进入软件系统的一扇门；但这扇门后面，是不是一个可理解、可操作、可治理的软件，取决于整个业务架构，而不是这扇门本身。
落到 ObjectStack，它真正有趣的地方，不是它支持 MCP，而是它把 Object、Action、Permission、Runtime 和 MCP，放进了同一个业务抽象里。这才是它作为一个观察样本，最值得被记住的东西。
结语
如果未来每一个企业软件，都需要同时服务人类、程序、和 AI Agent，那么我们现在设计 API 的很多方式，可能都会被重新审视。
API 不会消失。UI 也不会消失。真正在发生变化的，是软件开始需要一种新的、比 Endpoint 更接近业务本质的接口语言。
MCP 只是把这个问题，暴露了出来。而真正的答案，可能还在软件架构本身。
——本文以 ObjectStack 开源项目为案例进行技术分析。涉及仓库能力的部分，以其当前公开源码和文档为准；关于行业趋势与未来软件形态的部分，属于作者判断，非既成事实。
ObjectStack · 开源的 AI-Native 企业软件运行时