行业示例

模式始终相同：先描述系统能力，再在此基础上构建界面。 领域在变——由 Resource、Tool 和风险等级构成的结构保持不变。 以下示例展示了 MCP-first 在不同行业中的具体形态。

房地产

传统房地产软件以界面为中心：项目列表、联系人管理、 楼书页面、邮件视图、Reminder 弹窗。MCP-first 将其颠倒—— 先建立能力，再将 Web 应用作为同一组 Action 上的 Client。

Web 应用调用与智能体相同的 Action。没有单独的智能体逻辑—— Capability Layer 是两者共同的核心。

薪资与人力资源

薪资系统管理着企业中一些最敏感的数据。MCP-first 在 智能体可以读取的内容、可以准备的内容，以及 仅在明确批准后才能执行的内容之间划出清晰边界。

风险等级概览：

• Low employee.basic.read — 基本信息，对智能体无害
• Restricted salary.read — 需要额外批准，限制传递
• Critical payroll.export — 始终需要确认和审计事件
• Critical salary.change — 建议 Step-up Auth + 四眼原则

DevOps

DevOps 控制面板管理基础设施、部署和 Secret。 风险等级在这里尤为重要：读取日志无害，读取 Secret 则被禁止。

风险等级概览：

• Medium logs.query — 允许自主执行，Scope 受限
• High deployment.create / rollback — 需要确认
• Critical secrets.rotate / firewall.update_rule — 始终需要 Step-up Auth
• Forbidden for AI secrets.read — 智能体不可访问

CRM 与销售

销售智能体需要访问联系人、Deal 和通信——但不需要访问 系统权限、计费或租户管理。MCP-first 确保智能体只看到 其任务所需的 Capability。

智能体可以创建草稿、添加备注、推荐下一步操作和准备会议。 外部邮件为 Critical——人类确认发送，无论上下文多么明确。

客服支持

客服智能体主要需要丰富的读取访问权限：工单历史、上下文数据、 以往通信。写入操作仅限于草稿和内部备注——直到明确批准为止。

客服智能体收集上下文、建议回复并添加内部备注。 一旦回复需要对外发送，原则与其他地方相同： 人类确认——智能体准备。