「哪些门店可能缺货？」业务人员问完 AI，得到一段分析：A 门店销量增长，库存只能支撑三天，建议尽快补货。

但工作并没有结束。他还要核对库存口径、查看附近门店能否调货、确认在途商品，最后把处理建议交给负责人。如果这些动作仍要靠人逐个打开系统完成，AI 只是把「找问题」变快了，没有真正进入工作流程。

这正是Agentic UI值得讨论的地方。

01｜Agentic UI，从对话框走向可操作的工作界面

Agentic UI 可以理解为一种交互方式：AI 不只返回文字，还根据任务提供相应的图表、筛选器、明细、表单和操作入口，人可以检查依据、修改条件、确认下一步。

例如，面对「找出需要优先处理的缺货门店」，理想的界面不该只有一句「建议补货」，还应让业务人员看到门店清单、预测销量、当前库存和在途量，并能点开异常原因。AI 负责协助组织信息和提出建议，业务人员负责核验与决策。

它不是「AI 自动生成页面」的同义词，也不意味着每一步都交给 AI 执行。关键变化是：界面开始围绕一项具体工作组织，而不再让用户在对话记录和多个后台之间来回跳转。

02｜MCP 在其中做什么？

如果说 Agentic UI 回答的是「人如何与 AI 一起工作」，MCP（模型上下文协议）回答的则是「AI 如何连接外部工具与数据」。

通过 MCP，应用可以向 AI 提供受控的工具和资源。AI 在获得授权的范围内调用工具，查询数据、获取业务上下文，再据此回应用户。其扩展能力MCP Apps进一步允许工具返回可交互的界面，让用户直接在界面里查看或操作，而不必把所有信息挤进一段文字。并非所有 Agentic UI 都必须基于 MCP 构建，两者不能画等号。

对产品经理来说，比协议名称更重要的是先定义边界：AI 能读取哪些数据？指标由谁确认？哪些动作只提供建议，哪些需要人工审核？没有这些约束，可交互的页面也只是更复杂的演示。

03｜一个业务应用，实际怎么搭出来？

观远数据的超级应用提供了一个具体实现方向：以企业已有的 BI 数据资产为基础，把数据分析、AI 能力和业务操作入口组织成面向某一角色的应用。

以「门店缺货处理工作台」为例，搭建时可以按四步走。

第一步，定义任务。先确定使用者是谁、每天需要判断什么、判断后由谁处理。例如，区域经理需要筛出高风险门店，核对库存和在途数据，再决定补货、调货或继续观察。这里先写清验收标准，比先画页面更重要。

第二步，找到可信数据。检查 BI 中是否已有销售、库存、商品、门店等数据集，以及缺货率、库存可售天数等指标的定义。观远的 GuanCLI 可以帮助 Coding Agent 在权限范围内查询已有数据集、指标、卡片和页面，避免只凭提示词编造数据结构。

第三步，设计人机协作界面。让 Agent 辅助生成应用初版，但页面应围绕工作顺序展开：先列出异常门店，再展示判断依据，随后提供下钻入口和待确认的处理建议。如果需要提交处置结果，还要明确表单、审批或其他业务系统的实际接入方式，不能把「页面上有按钮」当作流程已打通。

第四步，校验后发布。产品、业务和数据团队共同核对指标口径、权限、异常解释及操作路径，完成预览和代码检查，再将应用发布到 BI 中。超级应用复用既有 BI 登录与数据能力，但生成代码仍需检查，敏感凭证也不能直接放进前端。

对数据产品经理而言，这里的核心工作并没有变成「写一个更长的提示词」。真正要设计的仍是：业务问题如何被拆解，数据从哪里来，结论如何核验，以及建议怎样进入有人负责的下一步。

• 爆品卖断货，仓里却还有库存
• 活动销量上涨，补货前却要先算清利润
• 门店异常太多，不知道今天先处理哪一家

这些问题未必都需要同一种 AI 界面，却都需要把数据、判断与行动连接起来。

谢谢你能看到这里。我是木易，每天帮你先一步看见 AI。这篇如果有用，顺手点个赞和在看，转给身边用 AI 的朋友。想第一时间收到更新，给我加个星标⭐。我们明天见。