AI Agent平台和应用落地实践沙龙参会感想及总结

本周六深圳架构同盟有个AI Agent平台和应用落地实践沙龙，笔者公司最近正在做智能体相关的规划，于是毫不犹豫的报名参加了这个沙龙。

本文是笔者基于这个沙龙各位大佬分享的内容，做的一个学习总结，同时也希望对大家智能体建设相关有帮助，如果有不对的地方，也欢迎大家批评指正。

一、智能体平台架构及设计

1、智能体平台架构及设计：

智能体平台应该作为AI的基建来看待。

智能体平台价值：覆盖AI开发框架和流程、可复用的MCP插件模板生态。

智能体Agent平台包含：统一智能体平台、智能体可观测平台、智能体监控管理、智能体安全、智能体沙盒、智能体评测。

a、统一智能体平台包含：智能体注册中心、策略管理器、数据中心、编排引擎。

b、智能体可观测：langfuse，结合信息安全改造，设计用户调用信息，知识库召回的信息

c、智能体监控：uap和langfuse

d、智能体沙盒：独立的容器沙盒环境，一次性运行的通过沙盒来做，本节会单独介绍。

e、智能体安全：智能体安全打标，和知识库打通，不同安全等级有不同的应用

f、智能体评测：智能体评估很重要，用数据集去测试，打造智能体评测平台，和内部评测平台打通

2、智能体分类：

低码智能体平台：类似dify平台，可观测 日志等，解决相当一部分场景。

高码智能体平台：用langgraph等，不同语言选择不同的sdk，独立部署。

高码其实和传统应用类似，高码智能体调用大模型建议都需要走模型广场去调用。

3、智能体沙盒介绍

“智能体沙盒（Agent Sandbox）”是一个集安全隔离、风险仿真与合规校验于一体的核心基础设施。

a、安全隔离层：防止“工具投毒”与“越权执行”

b、风险仿真层：变更前的“数字孪生”验证

c、运行治理层：动态权限与“人机回环”

d、评估与进化层：数据飞轮的“炼丹炉”

沙盒是实现“执行可控”防线的核心组件：

对于 MCP：沙盒确保工具接口调用的绝对安全。

对于 Agent：沙盒提供了逻辑演进与故障闭环的仿真环境。

对于业务：沙盒通过“硬”核管控，满足了银行最严格的企业级合规要求。

4、智能体平台的多种面客形态：

低码智能体平台：提供拖拉拽、固定工作流模式的智能体开发、监控、拓展流程。

高码智能体平台：提供灵活的SDK编程，应用部署托管、监控治理等平台服务。

对话式智能体平台：提供最简单的人机交互模式，通过快速预览、大模型规划调度实现实时代码生成和交互逻辑。

二、MCP协议相关

1、MCP的tools和resource介绍

a、MCP Tools：智能体的“手”，负责执行 (Action)

Tools是智能体通过 MCP 调用的可执行操作。它们是主动的、具有副作用的接口，允许 Agent 改变外部系统的状态。

每个 Tool 包含一个唯一的名称、功能描述以及严格的JSON Schema 输入参数规范

b、MCP Resources：智能体的“眼”，负责感知 (Data)

Resources是智能体可以读取的标准化数据源。它们是只读的，代表了系统的当前状态或背景知识。

Resource 通常由一个URI（统一资源标识符）标识（例如prometheus://metrics/cpu_usage），模型可以像读取文件或打开网页一样获取其内容。

c、Resource 类似“消息订阅和发布”

“订阅/发布”特征主要体现在 MCP 的动态通知机制 (Notifications)上，这是 Resource 区别于传统 API 调用的关键。

在标准 MCP 中，Host（客户端）可以向 Server 订阅某个 Resource 的更新。

机制：当底层数据（如 Prometheus 监控指标）发生变化时，MCP Server 会发送一个notifications/resources/updated通知给 Host。

效果：智能体无需频繁轮询，而是像订阅了 Redis 频道一样，被动接收数据的实时变更。这在IT系统中“分钟级故障感知”场景中应该可以用的到。

MCP Resource的代码样例

2、MCP SSE协议缺陷，导致会话丢失

在企业级智能体（Agent）平台建设中，MCP（Model Context Protocol）通常使用SSE (Server-Sent Events)作为从服务器到客户端的通信协议。

但在生产环境（特别是高可用集群架构）下，SSE 的无状态性和长连接特性确实会引发严重的“会话丢失”或“指令错位”问题。

MCP SSE 是一种单向长连接（从 Server 到 Host）。在分布式架构（如 Kubernetes 部署）中，它存在以下三个致命缺陷：

a、连接与节点的物理绑定 (Affinity Issue)：

现象：用户与 Agent 的会话可能被负载均衡（LB）分配到 Server-A，而随后的某个工具调用请求（Tool Call）可能落到了 Server-B。

后果：由于 Server-B 并没有与该 Host 建立 SSE 物理连接，它无法将结果推送回去，导致“会话丢失”或响应超时。

b、集群扩缩容导致连接中断：

现象：当后端 MCP 服务进行滚动更新或缩容时，长连接会强制断开。

后果：由于 SSE 协议本身不具备复杂的会话恢复机制，一旦断开，Agent 正在进行的推理流会立即中断，用户感知到 Agent“断线”或“失忆”。

c、负载均衡器的超时处理：

现象：企业级网关（如 Nginx, F5）通常对长连接有超时剔除机制。

后果：如果 Agent 推理时间过长（例如长链条的 Agentic RAG），中间没有任何数据传输，连接可能被网关单方面关掉。

解决方案：

为了解决上述问题，需要引入一个解耦层，将“物理连接”与“逻辑会话”分离。Redis 订阅/发布 (Pub/Sub) 是个成熟的方案。

不再让后端服务直接寻找 SSE 连接，而是将所有响应发往 Redis 总线。

Host (客户端)：连接到任一 MCP 网关节点，并在 Redis 中订阅一个专属频道（例如 channel:session{id}）。

Worker (执行节点)：负责处理具体的 Skill 或 Tool 调用。处理完后，不直接回传，而是将结果 Publish 到 Redis 对应的频道。

Gateway (网关节点)：所有网关节点都在监听 Redis。当某个节点发现自己持有的物理连接 ID 与 Redis 中的消息 ID 匹配时，通过该 SSE 连接将数据推送给用户。

三、A2UI 和 Widget

在智能体（Agent）开发演进过程中，A2UI (Agent-to-UI) 和 Widget（小组件） 是实现“人机协同可视化”的两个核心概念。

1、A2UI 和 Widget 联系和区别：

a、A2UI (Agent-to-UI)

本质：一种交互范式或通信协议。它定义了智能体（Agent）如何根据当前任务的上下文，动态地、自主地向用户呈现最合适的图形界面。

目标：解决“对话框局限性”。当复杂的运维数据（如拓扑图、实时曲线）难以通过纯文本描述时，Agent 通过 A2UI 逻辑选择或生成界面。

b、Widget (小组件)

本质：一种前端 UI 组件或载体。它是 A2UI 范式中被推送给用户的具体“零件”。

目标：信息的高效直观展示。它通过图表、进度条、表单等形式，让运维人员一眼看清现状并执行操作。

2、Widget详细介绍

Widget 是一种轻量级、模块化的图形界面组件，它通常嵌入在智能体的工作台（Dashboard）或聊天对话框中。

Widget 是 AI → 人 → 系统 的桥梁。

Widget 本质上是：「把能力、数据或交互，以『可嵌入、可组合、可视化』形式暴露出来的最小前端单元」

Widget（小组件） 是实现“人机交互可视化”与“运维数据即时呈现”的核心载体。它不仅是一个前端 UI 元素，更是智能体能力的图形化输出接口。

Widget 是连接“黑盒 AI 推理”与“白盒运维管理”的桥梁。

一个好的 Widget 设计应该让运维专家一眼看清：AI 正在做什么、依据是什么、风险在哪里。

没有Widget的情况下：Agent黑盒、人不敢点“执行”、安全合规不可解释等。

Widgent的价值：可解释、可审计、可干预、可运营。

3、腾讯智能体开发平台（ADP）的Widget

腾讯智能体开发平台（ADP）定义了对话开发组件—AI原生Widget。

背景：是文本和MD格式交互难以满足复杂对话需求，现有UI交互需定制开发且成本高。

挑战：

1、国内组件支持不足（尤其输入类组件）

2、实现复杂：依赖可视化拖拽前端+手动映射数据字段，与Agent集成困难

解决方案：

自然语言生成：大模型直接输出结构化JSON供前端渲染，降低配置复杂度

标准化：对齐OpenAI Widget标准，开发RDP前端组件

安全机制：使用JSX描述UI并禁止JS执行

四、席勒士九法则（Schillace Laws）

席勒士法则（Schillace Laws）是由微软副总裁 Sam Schillace 提出的，旨在定义一种“由 AI 驱动的新型编程范式”。这些原则不仅是技术指南，更是思维方式的转变。

一共包含9条法则，如下：

1、若模型能胜任编写任务，便无需动手，模型会不断提高，而代码则无法如此：

代码是静态的负载，一旦写下就开始“腐烂”并产生维护成本；模型是动态的，随着算力提升和参数微调，其处理能力会持续增强。

2、以精准为代价，换取更高的杠杆，借助互动缓解风险：

LLM 并非 100% 确定，但它能处理无限的边界情况。与其追求完美的一致性，不如通过 “人机回环 (Human-in-the-loop)” 确认高风险操作，换取模型处理极复杂问题的能力。

3、代码用于语法和过程，模型用于语义和意图：

代码擅长处理确定的过程、解析 JSON、计算数值；模型擅长理解意图、理解运维专家文档中的含糊表述。

4、系统的脆弱程度取决于最脆弱的部分：

在一个 AI 系统中，如果模型推理很强但底层接口（API）不稳定，或 Prompt 存在歧义，整个系统就是脆弱的。

5、问得越好，答得越好：

这强调了 Prompt Engineering 的重要性。高质量的上下文输入决定了高质量的输出。

6、不确定性是抛出的异常：

当模型无法确定或产生分歧时，这本身就是一种信号。程序不应强行执行，而应将其作为“异常”抛给人类或 Supervisor 介入。

7、文本是一种通用的数据传输协议：

文本（尤其是 Markdown/JSON）是人类和模型都能理解的终极格式。

8、对于你来说困难的，对于模型也是困难的：

如果一段任务人类逻辑都理不顺，逻辑极其混乱，模型也容易产生幻觉。

9、当心“意识的错觉”，模型可以用来反过来攻击自身：

不要把 Agent 当成人，它只是复杂的预测器。利用另一个模型（审查模型）去验证执行模型的输出，是最佳的安全实践。

英文原文如下：

1.Don’t write code if the model can do it; the model will get better, but the code won’t.

2.Trade leverage for precision; use interaction to mitigate.

3.Code is for syntax and process; models are for semantics and intent.

4.The system will be as brittle as its most brittle part.

5.Ask Smart to Get Smart.

6.Uncertainty is an exception throw.

7.Text is the universal wire protocol.

8.Hard for you is hard for the model.

9.Beware pareidolia of consciousness; the model can be used against itself.

五、智能客服智能体浅谈

1、货拉拉关于智能客服的实践

王海华老师分享了货拉拉关于智能客服的实践。

客服智能体设计：问题-》问题改写-〉场景路由

智能体客服要实现流程自然对话主要包含如下三个重要模块：

a、ASR：口音识别、背景降噪、声学模型优化

b、TTS：快速复刻，口音还原

c、LLM

货拉拉的智能客服用qwen2.5-72b模型，语音识别准确率93%。

智能客服对时延要求高，需要本地化部署大模型才能满足低时延。

其中介绍了关于智能客服很重要的一点要求：打断的设计。

比如：“嗯，嗯”--不打断；

比如：“那怎么操作呢？”--打断。

2、腾讯ADP-WorkFlow关于多轮对话灵活设计

主要难点：多伦对话灵活自由，如何处理对话意图不明确，意图切换与拉回，用户修改历史对话，中途退出流程等场景。

a、全局意图监听：

难点：对话流程中，用户不按预期流程走，突然结束对话，闲聊等，比如：订酒店场景，机器人问用户询问电话号码，用户说“我不预订了”。

解决方案：全局意图监听对话：解决对话过程中，非预期的场景

b、智能回退

难点：用户修改历史信息（如更正手机号）

方案：全局参数提取，自动跳转修正节点

c、复杂流程控制

难点：并行对话与多条件循环（如交叉询问、多种退出条件）

方案：采用事件驱动递归遍历执行节点（缓存加速）

d、多意图切换

难点：意图频繁切换（如酒店→机票→酒店）

方案：意图栈缓存机制保存对话状态

可以通过事件驱动、参数全局化、状态缓存等机制，实现灵活的多轮对话管理，解决中断、修改、跳转等复杂交互场景。

六、Multi-Agent架构设计

1、Multi-Agent 的自由转交（handoff）

Handoff（交接/自由转交） 是 OpenAI Agents SDK 中的一项核心机制，允许一个智能体（Agent）将对话控制权或特定任务委托给另一个更专业的智能体。

核心原理：将“转交”视为一种“工具”

在底层实现上，Handoff 本质上是一种特殊的函数调用（Function Calling）。

a、工具化表示：当你在代码中为 Agent A 设置了指向 Agent B 的 Handoff 时，SDK 会自动生成一个名为transfer_to_<agent_name>的工具。

b、自主决策：大语言模型（LLM）会根据用户的意图，自主判断是否调用这个“转交工具”。例如，当用户咨询退款时，“分拣智能体”会自动调用transfer_to_refund_agent。

c、返回智能体对象：普通的工具调用返回的是字符串或数字，而 Handoff 工具返回的是另一个智能体对象，从而实现控制权的无缝切换。

2、多个Agent上下文处理

多个Agent上下文处理，存在token消耗多的问题

多Agent区分共享上下文和私有上下文，控制单Agent推理轮数，Agent转交次数。

3、多Agent协同--规划和执行

挑战：

1）、规划任务可靠性，执行漂移

2）、长任务，如何支持中断恢复

方案：

1）、根据任务执行情况，不断更新任务规则

2）、任务异步化，数据和状态持久化，支持SSE和WS重连

4、多Agent协同--不同模式智能体之间打通

挑战：

1）、ADP平台内各种模式下Agent如何打通，比如工作流智能体，自由转交Agent

2）、跨平台之间Agent如何打通

方案：

1）、ADP平台内Agent模式系统：

ARG封装一个tool

Agent as tool

workflow as tool

App as tool

2）、跨平台之间Agent协同：A2A

七、结语

本文是根据几位大佬关于Agent落地实践分享重新打散总结了对笔者比较有感触的点，然后再查阅了相关资料做的总结，所以各个章节的关联不太大，希望这些点对大家也有帮助。