华为大咖说丨在AI Agent时代,站在架构师的视角谈谈我们的核心

举报
华为云PaaS服务小智 发表于 2025/07/14 15:01:50 2025/07/14
【摘要】 随着AI新产品或技术框架的持续火热,AI Agent变成了各家重点发力的领域。在自智网络的体系下,应该如何构造我们的Agent,哪些是核心控制点,需要重点规划和发力,笔者给出自己的思考。

随着AI新产品或技术框架的持续火热,AI Agent变成了各家重点发力的领域。在自智网络的体系下,应该如何构造我们的Agent,哪些是核心控制点,需要重点规划和发力,笔者给出自己的思考。


01 理想形态的AI Agent是什么样子?


既然是围绕AI Agent讲故事,就需要先统一下Agent的定义,以免产生歧义。
AI Agent:与传统的语言模型LLM纯文本生成或聊天模式不同,Agent是一个能够自主思考、规划、并使用工具来完成用户任务的系统。

重点说明,Agent是个独立的系统,有独立的生命周期,有自己独立的特性树和功能树。我经常听到的声音,一个是开发同学口中的Agent,是指软件产品中的一个模块(子系统),实现智能化相关的业务服务,分别调用管控服务以及大模型的接口,完成AI相关的某个功能;另一个是mkt同学口中的Agent,是商业视角的一个一级特性,比如智能故障Agent、网络优化Agent等。

因为文章的目的是要讨论关键技术控制点,而控制点必须和架构对象明确对应,不能有歧义,因此提前进行说明。有了统一的定义,咱们开始正文。

每次讨论AI的能力,自然而然会拿来和人做对比,后来的一些功能进化,也是分别类比到大脑里承担不同角色的脑组织,非常通俗易懂,因此笔者也用同样的方式类比Agent的工作方式

工具使用:人会选择和使用最合适的工具来完成工作,Agent同样需要具备选择和使用工具的能力,在数字世界里,这些工具主要是各个软/硬件系统提供的API,软/硬件系统本身的UI界面等,我们可以把这个能力类比为工具使用

多智能体协同:人可以不自主完成工作,而是雇佣工人/专家来完成工作,Agent同样需要具备和其他Agent交互的能力,通过把工作委托给其他Agent等方式,来完成工作。这个能力可以类比为多智能体协同

环境感知:人为了完成工作,需要感知工作环境,获取工作需要的资料,Agent同样需要具备环境感知能力,这些环境信息包括Agent的工作场景,对应业务的各类运行数据等,这个能力则可以类比为环境感知

推理能力:人具有丰富的经验,知道如何分步骤的工作,Agent同样需要具备任务分解的能力,相比于人,Agent还需要接收人的指令,所以还需要具备意图理解能力。我们可以把意图理解和任务分解能力类比为推理能力

设想一下,如果Agent的上述能力足够好,可以在很多方面取代人来完成工作了。这个目标不可能一蹴而就,我把几个典型阶段的核心能力特征总结如下:

1、chatbot阶段

chatbot阶段,Agent通过prompt的方式,把任务要求、任务的背景信息等提供给LLMLLM推理完成后,Agent再反馈给用户。这个阶段,核心能力完全依赖于LLM本身Agent只能通过few-shot(少样本学习)的方式,以尽量合理的prompt来驱动LLM工作。

2、简单Agent阶段

简单Agent阶段,已经可以根据具体的故障,调用管控系统的API,来做故障诊断动作了,只不过这阶段,环境感知依然差强人意,不知道网络拓扑(网络拓扑结构是指计算机网络中各节点与通信媒介的布局和物理连接方式),不知道设备配置,不知道设备运行状态;LLM推理能力有限,无法很好的把用户意图分解为具体的执行步骤,需要预置好定制化的步骤脚本,LLM完成简单的意图识别,根据原始意图描述找到对应的处置脚本。可以看到,受限于LLM的能力,以及环境感知的能力。

这个阶段的Agent还处在幼儿园阶段,只能完成预置好的工作,一旦超出预置范围,就变笨了。

3、自主Agent阶段

自主Agent阶段,才应该算是真正意义上的智能助手,在工具使用方面,Agent不会对工具API提要求,而是主动适配工具的使用,当然就像人使用工具一样,如果工具质量越高API被良好治理),人Agent的效率也会越高,Agent甚至应该可以以现有的工具为基础,自动生成新的工具(基于现有的api自动写代码生成新接口)

环境感知方面,一方面需要持续维护完整的实时知识、海量的历史知识,另一方面更需要在使用时能快速检索到匹配的知识,现有的EmbeddingEmbedding,中文常译为嵌入, 简单来说,就是将原本难以直接处理的数据(如文字、图像等)转换为计算机能够理解和处理的向量形式。等知识召回方案,距离基于语义的知识检索,还有很多距离;这个阶段对推理能力的要求,最重要的是需要结合环境感知阶段的知识做推理,这些实时知识可能数量巨大,目前大模型的token约束极大的限制了应用阶段的准确推理,DS最新开源的NSA技术,应该就是一个很好的方向。

另一个最重要的能力是反思和自我改进了,通俗点说就是越用越聪明,需要把运行期间的失败原因记录在知识库中,并在后续的推理过程中参考这些经验数据,给出更优的结果。

有了上述能力为基础,Agent还应该像人一样组成团队,多个掌握不同能力的Agent互相协同,完成复杂任务。

 

02 自智网络体系下的Agent架构应该是什么样子?


 前面聊了自主Agent目标的画像,基于这些黑盒目标我写了一个心目中的目标架构,按照架构4+1视图的概念描述,架构逻辑视图如下

在整个解决方案体系里会有多套管控系统,各套管控系统按照自己的逻辑工作,和新增的智能业务解耦,只需要治理好自己的API和数据,以MCP server的方式对外提供资源服务。

体系里存在多套Agent系统,每个Agent系统做特定领域的智能助手(比如IP承载网智能助手、传送网智能助手等)Agent系统是智能业务里的调度者,负责驱动LLM完成推理任务,调用管控系统使用工具,在Agent系统内部和核心组件包括:

1)知识库服务,提供多种格式的信息存储和查询服务,是支持知识召回的核心组件;

2)小模型,小模型为了提高资源利用率和通信效率,可以先有小模型在业务做本地推理,减小对大模型的使用压力,更快速响应请求,类似于小脑的角色;

3)代码执行虚拟机,提供推理结果的dryrun能力,提前验证推理的结果,再正式执行。

体系里的LLM系统,提供类似大脑的推理服务,受限于LLM的资源以及推理能力,也许会部署多种类型的LLM,比如DS-V3DS-R1等。

有一个能力没有在逻辑架构中体现:Agent协同,参与到多Agent协同过程中的每个独立的Agent个体,也应该遵循这个Agent的架构,只是Agent之间,应该采用什么协议来交互,协议内容应该是NL,协议格式可以通过扩展MCP的方式实现,只是Agent本身需要再增加一个MCP Server的服务,用来支持被其他的Agent调用。

逻辑视图中的不同系统,可以做排列组合,根据产品offering设计,以不同产品形态发布:

产品组合3是目前典型的产品形态,比如某些独立部署的大型管控系统,缺点是太厚重,资源需求巨大。

产品组合2是我个人认为最合理的产品方式,大模型进化太快,而且运营商环境里往往有多套智能系统,独立建立一套大脑,支撑多套智能系统,是高效的一种方式。

产品组合1不用多说了,很多AI产品就是类似的模式。

还有一种产品形态,就是管控系统、AgentLLM分别都是独立的产品形态,这样的划分会导致Agent丢失了土壤(管控系统),丢失了灵魂LLM,直接被架空,目前阶段我觉得不会有哪个产品这样规划。


03 AI Agent的核心控制点

长篇大论了这么多,终于可以引出核心观点了。

回顾前面自主Agent的四个核心能力:工具使用、环境感知、推理能力、多智能体协同,再站在管控系统、AgentLLM三大系统的角度,审视子系统在其中的独特价值。

  • 管控系统提供功能丰富完整、描述清晰的功能接口,可以更好的被Agent使用,是管控系统最重要的一个价值和控制点,设想一下,当Agent提出的各种需求,管控系统都能立刻掏出来一组API,高效的支撑这些需求,这么易用的工具集无法被取代。管控系统另外的一个核心价值和控制点是环境感知,这恰好和数字孪生的概念契合,管控系统对网络做充分数字化,管理历史-实时的数据,是支撑Agent推理的核心知识,这些数据核心资产无法被取代。
  • Agent系统作为智能业务的核心,第一个控制点是知识召回能力,如何组织海量的数据、经验,并能准确快速的检索,这些知识是用于支撑LLM推理的关键信息,LLM推理结果的优劣,和这些信息的准确性直接相关,这也是最体现Agent设计功力的部分。第二个是Agent的工程能力,可以快速集成和使用管控系统的资源API,响应业务变化,更好的用户体验,这方面并不考验什么核心技术。
  • 大模型系统作为大脑,自主Agent的意图识别、任务分解、结果总结严重依赖大脑的能力,足够聪明的大脑,才能让Agent更好的工作,当大脑能力不足,或者因为资源受限只能部署一个阉割版的大脑时,如何训练大脑更好的完成特定场景的推理,以及对应的训练语料、训练框架、评测体系,就是大模型系统的核心控制点了,只不过这个控制点相对于管控系统和Agent系统的几项,太容易被颠覆了,大模型技术进展太快,一旦有更好智商的大模型系统出现,我们特定的训练语料和训练框架就都无用了。

总结一下这些控制点,其中工程能力部分不列在下面了,毕竟这部分的抓手太弱了,同时给一个我心目中的权重排序:

  1.    Agent系统的知识组织和管理能力(如何做知识分类,如何组织这些知识)
  2.    Agent系统的知识召回能力和算法
  3.    管控系统的API丰富度和易用性
  4.    管控系统的数据丰富度和易用性
  5.    大模型系统的推理智商

最后,特别强调一下系统工程,上述这些技术点,并不是孤立存在的,必须基于某一个场景做端到端协同,否则每个技术单独拿出来,根本不知道是否做好了,这也许就是某AI产品负责人提到的端到端训练的核心!

【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。