AG-UI、MCP、Function Calling 应该如何分工：IoT 控制台里的 Agent 交互架构

很多 IoT 控制台团队现在会同时听到三个词：AG-UI、MCP 和 Function Calling。它们看起来都和 Agent 有关，也都可能出现在同一个系统里，但它们解决的不是同一个问题。如果把三者混成一层，控制台通常会出现三类风险：前端无法稳定呈现 Agent 状态，工具权限边界失控，设备命令缺少确认、审计和回滚。

本文的核心结论是：AG-UI 负责 Agent 与用户界面之间的事件、状态和人机协同；MCP 负责 Agent 与外部工具、数据、上下文之间的标准连接；Function Calling 负责一次模型调用里“模型请求应用执行某个函数”的结构化机制。 在 IoT 控制台里，三者可以组合，但不能互相替代。

定义块

在本文中，AG-UI 指 Agent 与用户界面之间的事件交互协议；MCP 指 Agent 应用连接外部工具、资源和提示上下文的协议边界；Function Calling 指模型在一次 API 调用中按 JSON Schema 生成工具调用参数，由应用侧执行并把结果回传模型的机制。

决策块

如果你在做 IoT 控制台的 Agent 体验，先用 AG-UI 定义“用户看见什么、能确认什么、如何中断或恢复”；再用 MCP 定义“Agent 能接触哪些设备、工单、遥测和运维工具”；最后只在具体动作执行点使用 Function Calling，让模型提出结构化请求，而不是让模型直接拥有设备控制权。

1. 先用一张表把三者分开

这个表的实际含义是：AG-UI 让 Agent 变成可交互的应用体验，MCP 让 Agent 有可治理的工具和上下文入口，Function Calling 让模型在单次执行中提出可校验的动作请求。 它们的关系更像三层边界，而不是三个可互换的 SDK。

AG-UI 官方文档把它定义为开放、轻量、基于事件的协议，用来标准化 AI Agent 与用户应用的连接；它强调 Agent 状态、UI 意图和用户交互如何在模型或 Agent runtime 与前端之间流动。MCP 规范则把重点放在 JSON-RPC 基础协议、生命周期、传输、授权，以及服务器暴露的 Resources、Prompts、Tools。OpenAI 的 Function Calling 文档强调工具调用流程：模型产生调用请求，应用执行工具，再把结果交回模型。三份文档本身已经说明了它们处在不同层。

2. IoT 控制台为什么特别容易混淆这三层

IoT 控制台不是普通聊天界面。它同时有设备状态、告警、命令、权限、现场风险和操作责任。Agent 不能只会“回答问题”，还要在不破坏控制链路的前提下协助用户完成运维动作。

一个典型场景是：运维人员在控制台里问“为什么 3 号冷库温度持续偏高，是否需要调整压缩机策略？”系统可能需要完成下面几件事：

• 读取设备实时状态、历史遥测和告警。
• 解释可能原因，并把证据呈现在控制台上。
• 生成一个建议动作，例如下发参数调整或创建巡检工单。
• 要求用户确认高风险命令。
• 把确认、执行、失败、回滚和审计记录展示出来。

如果只用 Function Calling，这个系统可能能调用 get_device_status 或 create_work_order，但它并不能自然定义“前端如何显示 Agent 正在排查、用户如何打断、命令如何二次确认、执行日志如何持续流出”。如果只用 MCP，系统能把设备、工单和遥测暴露成工具，但仍然没有解决用户界面的交互体验。如果只用 AG-UI，前端可以和 Agent 流式交互，但后端工具边界、资源授权和上下文协议仍要由其他层承担。

因此，IoT 控制台的正确问题不是“选 AG-UI、MCP 还是 Function Calling”，而是：哪一层负责交互，哪一层负责工具边界，哪一层负责模型动作请求。

3. 推荐分层：AG-UI 在前台，MCP 在工具边界，Function Calling 在动作点

flowchart LR

A("IoT 控制台用户"):::slate --> B("AG-UI 事件与状态层"):::blue
B --> C("Agent Runtime / 编排层"):::violet
C --> D("MCP 工具与上下文边界"):::cyan
C --> E("Function Calling 动作请求"):::orange
D --> F("设备状态 / 遥测 / 工单 / 知识库"):::green
E --> G("应用侧命令服务"):::orange
G --> H("确认 / 幂等 / 审计 / 回滚"):::slate

classDef blue fill:#EAF4FF,stroke:#3B82F6,color:#16324F,stroke-width:2px;
classDef cyan fill:#E9FBF8,stroke:#14B8A6,color:#134E4A,stroke-width:2px;
classDef orange fill:#FFF3E8,stroke:#F08A24,color:#7C3F00,stroke-width:2px;
classDef violet fill:#F4EDFF,stroke:#8B5CF6,color:#4C1D95,stroke-width:2px;
classDef green fill:#ECFDF3,stroke:#22C55E,color:#14532D,stroke-width:2px;
classDef slate fill:#F8FAFC,stroke:#64748B,color:#1F2937,stroke-width:2px;

这张图的关键不是“谁更重要”，而是每一层都只承担自己该承担的责任。

3.1 AG-UI：负责人能看见和介入的交互层

在 IoT 控制台里，AG-UI 应该解决这些问题：

• Agent 正在分析什么，用户能不能看见。
• Agent 需要用户确认、补充信息或选择方案时，前端如何呈现。
• 长任务是否可以取消、暂停、恢复。
• 前端组件如何接收结构化状态，而不是只接收自然语言。
• 工具结果、推理步骤摘要和执行进度如何作为事件进入界面。

AG-UI 不应该直接变成设备控制协议。它更适合定义“控制台里的 Agent 交互体验”。例如温控策略变更前，AG-UI 可以把风险摘要、影响设备、建议参数、确认按钮和取消路径都传给前端；真正的权限检查、命令幂等和下发仍然应该由后端命令服务承担。

3.2 MCP：负责工具、资源和上下文的治理边界

MCP 更适合放在 Agent runtime 与外部系统之间，尤其是当一个 Agent 需要访问多类工具时：

• 设备档案、设备分组和资产模型。
• 实时状态、历史遥测、告警和日志。
• 工单系统、规则引擎、知识库和诊断脚本。
• 不同租户、站点、角色下可见的工具和资源。

MCP 的价值不是“让模型随便调用更多东西”，而是把工具和上下文变成可描述、可协商、可治理的边界。对 IoT 平台来说，这一点尤其重要：设备命令、客户数据、现场状态和运维工单都有明确权限范围，不能只靠 prompt 约束。

3.3 Function Calling：负责一次具体动作的结构化入口

Function Calling 适合用在具体动作点。例如：

• query_device_state(device_id, fields)
• summarize_alarm_window(site_id, start, end)
• prepare_command(command_type, target_ids, parameters)
• create_work_order(asset_id, priority, reason)

它的优点是参数结构清楚，应用侧可以校验 Schema、执行代码并把结果回传模型。但这不意味着模型可以直接下发命令。对 IoT 控制来说，Function Calling 最好只生成“请求”，由应用侧进入命令服务，再经过权限、确认、幂等、状态机和审计。

4. 命令确认是三者组合的分界线

在 IoT 控制台里，最能检验架构是否清楚的场景是“Agent 建议执行设备命令”。

这里有一个硬边界：高风险设备命令不能因为模型生成了 Function Call 就直接执行。 Function Calling 只能说明模型提出了一个可解析的动作请求；它不等于用户授权、业务审批、设备可达性检查或命令交付保证。

这个边界对冷链、能源、工业控制和楼宇系统尤其重要。一个“调整阈值”“重启设备”“切换模式”的动作，可能影响现场温度、能耗、安全和 SLA。Agent 可以辅助判断，但命令链路必须由平台控制。

5. 什么场景下不需要三者全上

不是所有 IoT Agent 功能都需要 AG-UI、MCP 和 Function Calling 同时出现。

如果你只是做一个后台诊断脚本，让模型总结日志并生成巡检建议，AG-UI 可能不是第一优先级。此时更重要的是工具权限、输入输出记录和结果复核。

如果你只做控制台里的“解释型助手”，它不访问真实工具，也不执行动作，那么 Function Calling 和 MCP 都可以先不引入。你可以先把用户问题、页面状态和文档检索做好。

如果你已经有内部工具注册体系，而且只有一个模型服务调用少量固定函数，MCP 也不一定是第一阶段必须项。你可以先把 Function Calling 的 Schema、权限和审计做好，等工具数量、团队边界和复用需求上来后再抽象 MCP。

但如果你的目标是“多租户 IoT 控制台里的可交互运维 Agent”，三层最终都很难缺席。缺 AG-UI，体验会退化成聊天框；缺 MCP，工具和上下文会变成临时胶水；缺 Function Calling，模型动作会缺少可校验的结构化入口。

6. 推荐落地顺序

对多数 IoT 平台团队，推荐按下面顺序落地：

1. 先定义命令风险等级。把只读查询、低风险建议、高风险命令分开。
2. 为高风险动作建立应用侧命令服务，包括幂等键、状态机、ack、timeout、retry、审计和回滚策略。
3. 用 Function Calling 生成候选动作，不让模型绕过命令服务。
4. 用 AG-UI 把分析过程、确认卡片、执行状态、失败原因和用户中断做成前端事件。
5. 当工具数量、团队边界和复用需求增加后，用 MCP 管理工具、资源和上下文边界。

这个顺序的好处是：先保护真实设备，再提升交互体验，最后扩展工具生态。不要反过来先追协议完整性，却让设备命令链路停留在临时脚本或无审计接口上。

7. 结论

AG-UI、MCP 和 Function Calling 在 IoT 控制台里不是三选一。更准确的分工是：

• AG-UI 管交互事件和用户可见状态。
• MCP 管工具、资源和上下文边界。
• Function Calling 管一次模型调用里的结构化动作请求。

当系统只读、低风险、工具少时，可以从 Function Calling 或现有内部 API 开始；当系统需要用户可见的人机协同，就引入 AG-UI；当系统需要跨工具、跨资源、跨团队治理，就引入 MCP。真正不能省的是命令安全边界：任何会影响真实设备的动作，都必须落到应用侧命令服务里，由权限、确认、幂等、审计和回滚共同约束。

参考资料：

• AG-UI Overview
• Model Context Protocol specification overview
• OpenAI Function Calling guide