容联云孔淼：AI Agent应深耕垂直场景，从效率提效向价值挖掘升级

近日，「AI共潮生2025甲子引力X科技产业新风向」大会上，容联云副总裁、诸葛智能创始人孔淼作为行业代表，受邀参与「AI Agent」圆桌论坛，与领军企业共探智能体技术突破与商业化路径，引发业界高度关注。

“现在我们开始融合新旧软件体系，借助computer use或者browser use的能力，在基于大模型去做调度，从而构建更前沿的Agent系统。这也是我们在对Agent理解上的不断升级。”

01、究竟什么是AI Agent？

从两个维度来看，我们从2023年开始接触并尝试AI Agent这个概念。一方面是我们观察行业是如何定义Agent的，另一方面是我们自己如何去理解和应用它。

回顾2023年，当时ChatGPT刚刚兴起，Agent的概念开始受到关注，最早的一些产品，尤其是被称为“四小龙”的公司，已经开始在产品中引入“智能体”这一概念。他们将一个System Prompt所构建的特定角色——例如一位金融工程师的人设视为一个Agent。

随后进入第二阶段，一些flow类的开源工作流编排开始出现，某些人开始认为“编排即Agent”。

到了2024年初，完整的Agent开始被认为应具备几个核心能力：长期记忆、短期记忆、任务规划、工具调用能力以及结果输出能力。

再到Devin出来之后，这种代理自动化编程能力。再到今年的Manus的browser use这种能力。

所以从整个Agent行业发展来看，其实经历了被认为是”智能体”、是”代理”的不同定义的阶段。穿透来看，有人认为LLM大语言模型的一个Feature，就是在特定场景的某种人设是一种Agent，有人认为工作流编排是一种Agent，当然，也有很多走在前沿的开发者，比如Manus，真正实现了让Agent代替人类去使用工具完成任务。

容联云较早地开始了Agent的探索，过程中认知也在不断更新。在服务大模型客户的应用实践中，我们总结出两种主要应用场景：

第一种是辅助坐席型应用，比如在客服或销售坐席的工作流里面，提供提示话术、流程引导或知识检索支持。我们认为这类更接近于Copilot，原因是在既有流程中起辅助作用。

第二种是自主执行型应用，如话术挖掘、话术洞察，甚至包括知识挖掘等任务。我们认为这才是真正的Agent。原因是说，我们会为它定义目标，通过LLM自动理解历史沟通记录和会话记录，并调用一些基础工具——比如函数调用、代码调用或业务API——来挖掘有效话术和服务中的关键信息与结果，实现端到端的自动处理。

但到了今年，我们也发现单纯的端到端方式并不够完善。基于行业前沿的Agent标准——由LLM做决策，结合tool use进行工具调用，并基于业务进行场景设计——如果从这个维度来看，我们需要升维思考。

过去我们的Agent更多是用新的软件替代旧软件，而现在我们开始融合新旧软件体系，借助computer use或者browser use的能力，在基于大模型去做调度，从而构建更前沿的Agent系统。这也是我们在对Agent理解上的不断升级。

“我们的应用场景本身就有一定的垂直属性，而在具体行业落地时，还会结合行业特点进行针对性的功能封装和应用适配。”

02、通用与垂直应该如何选择？

我们所做的相对比较垂直。

从业务场景来看，比如我们在做辅助、洞察、质检等功能时，虽然在客服领域具有一定的通用性，但在产品内部流程中，例如质检项、话术挖掘、话术助手等模块，则是进一步聚焦细分，属于“垂上加垂”。

整体来看，我们的应用场景本身就有一定的垂直属性，而在具体行业落地时，还会结合行业特点进行针对性的功能封装和应用适配。

“我们的大模型与Agent能力，主要集中应用于客服场景的各个环节中，真正实现了从效率提效到价值挖掘的升级”

03、从企业业务实际角度出发，你们的业务有哪些典型痛点，AI又是如何解决这个痛点的？

我们目前的大模型应用主要聚焦在销售与服务的全流程中。

提到大模型，很多人首先想到的就是对智能客服的颠覆。毕竟现在“客服”很多时候已经被称为“智能客服”。但事实上，传统智能客服在中大型企业中的应用效果仍比较有限。

过去以小模型为主的任务型系统，在特定场景下表现良好，但由于沟通本身就是信息长尾型且多样化的，不同用户表达同一问题的方式可能差异很大。如果仅靠小模型穷举各种表达方式，几乎不可行，这也导致了两个核心痛点：

第一是知识运营成本高 ：需要专人整理QA知识库，周期长、效率低；第二是模型调优依赖训练师 ：影响产品落地和商业可行性。

因此，过去基于小模型的智能客服，始终没有真正跑出大的行业玩家。

而大模型的出现 ，很好地解决了语言泛化的问题。作为Foundation Model（基础模型），它为理解多样化的语言提供了强有力的支撑。在此基础上，再通过轻量级小模型完成意图识别等具体任务，就构成了我们当前做智能客服的核心逻辑。

从业务维度来看，智能客服的应用场景非常广泛。企业普遍采用“机器人先行+人工兜底”的模式：先由在线或语音客服由机器人处理，无法解决时转接人工。这是一套典型的智能客服流程。

而在整个流程中，坐席人员通常会经历事前、事中、事后的多个环节：比如事前的培训、知识准备；事中的实时辅助、智能填单、业务管理；事后的质检、报表监控等。这些环节中，很多原本受限于泛化能力不足、多轮对话处理不佳的问题，现在都通过大模型得到了有效改善。比如：

在通话过程中，机器人能更好地理解打断、上下文切换；在线客服也能更准确地把握用户意图，不再“答非所问”。在质检方面，传统上依靠正则或小模型配置规则，不仅繁琐，而且效果有限。现在我们只需用自然语言定义“问题项”，大模型就能自动挖掘异常行为，极大提升了准确率与召回率。

在对话洞察方面也是如此。以往客户沟通记录海量繁杂，靠人工听录音效率极低，而传统NLP方法又难以深入挖掘。现在我们只需将这些数据交给大模型或Agent，就能从中提取潜在需求、商机线索、服务断点，甚至反向推动智能化流程构建。这种从“看指标”到“读内容”的转变，是对话洞察的一大飞跃。

我们的大模型与Agent能力，主要集中应用于客服场景的各个环节中，真正实现了从效率提效到价值挖掘的升级。

“从工具应用来看，现在也是分成两个阶段：前一个阶段主要涉及工程化的手段，第二个是现在流行MCP新技术手段。这两个维度都是属于技术概念和技术跑得很快的。”

04、在Agent和业务结合的过程中，你们企业遇到最大的难点是什么？是如何突破的？

从企业级的Agent落地来看，主要是决策能力、工具调用能力。

从决策能力上来讲，其实是依赖模型能力的。企业级应用的时候有很多企业级内部的领域知识，所以对企业本身的数据工程、知识工程，现在的技术发展很快、概念很快，企业的建设是没跟上的，如果做得不够的话、在任务规划的时候就不会做得很好，不会那么精确。

从工具应用来看，其实现在也是分成两个阶段。前一个阶段主要涉及工程化的手段，但是要把它用好就需要产品技术研发是非常懂业务的，这是一种瓶颈的阻碍。第二个是现在流行MCP新技术手段，就依赖于生态建设和已有的软件工具做结合，所以这两个维度都是属于技术概念和技术都跑得很快，但是企业内部还是处于建设过程，所以最后给人感觉好像什么都可以做、但是做起来效果不是那么好。

“对于上游的模型我们都能较好的适配。

一些大模型厂商虽然具备技术能力，但缺乏具体业务落地方案，因此我们会作为其下游合作伙伴，将产品与他们的模型结合，共同打造面向行业的解决方案。”

05、目前很多互联网的巨头，包括一些大厂在打造自己的AI生态，各位企业是更倾向于独立构建的Agent闭环，还是接入一个生态平台，生态合作中的一个核心的博弈点是什么？

当前云厂商和大模型厂商处于上游生态的位置，但从我们的合作角度来看有所不同。

我们主要对大模型进行微调和本地化部署，对于像上游DeepSeek这类支持开源，或者是千问这种提供良好开发者服务的Model Service可微调的模型，我们都能够较好地适配。

同时，一些大模型厂商虽然具备技术能力，但缺乏具体的业务落地方案，因此我们会作为其下游合作伙伴，将我们的产品与他们的模型结合，共同打造面向行业的解决方案。这是我们对生态的开放态度和落地方式。

而在Agent的工具调用方面，目前企业级生态尚处于早期阶段，还未完全成熟。未来我们也将会积极融入这一生态，推动工具调用能力的发展与协同。