10月7日，Cisco在WebexOne 2026期间公布了一系列围绕Agentic Collaboration的更新，涉及Webex、Claude Managed Agents、Model Context Protocol（MCP），以及客户服务、智能办公和企业IT管理等场景。
从技术角度看，这次更新真正值得关注的并不只是Cisco增加了哪些AI功能，而是一个更加明显的变化：企业AI正在从“生成内容”走向“执行工作流”。
过去的AI应用通常围绕一个相对独立的任务展开。用户输入问题，模型理解需求并生成答案，后续操作仍然由人完成。Agent则试图把任务拆分成多个步骤，让AI能够结合业务上下文调用工具、处理数据，并在一定范围内完成连续操作。
这会直接改变企业AI系统的架构。
从AI助手到Agent，核心变化是什么？
传统AI助手的工作方式比较简单：
用户输入 → 模型理解 → 生成结果 → 用户处理结果
这种模式非常适合问答、内容生成、摘要和信息整理，但它有一个明显限制：模型本身并不能直接完成企业环境中的大量实际操作。
例如，员工要求AI制作一份客户分析报告，真正完成这项工作可能需要先从CRM获取客户数据，再从数据平台获取交易信息，完成分析后生成报告，最后把报告放进企业协作平台。
如果没有Agent，员工需要自己完成这些步骤。
Agent的思路则是把任务拆解为多个可执行环节：
用户提出目标 → Agent理解任务 → 获取业务上下文 → 调用工具 → 处理结果 → 生成输出 → 人工确认
因此，Agent与普通聊天机器人的区别，并不只是“回答得更聪明”，而是它开始具备围绕目标组织多个步骤的能力。
这也是为什么企业Agent最终一定会涉及工具、数据、身份、权限和系统连接。
Agent为什么需要工具调用？
一个模型即使拥有很强的推理和生成能力，也无法凭空获得企业实时数据。
模型可能知道CRM是什么，却不知道某个企业今天有多少客户；它可以理解订单系统的概念，却无法自动知道某个客户刚刚产生了什么订单。
所以，Agent需要通过工具访问外部环境。
从架构上看，可以把工具理解成Agent与企业系统之间的接口。CRM查询、数据库检索、搜索服务、文档系统、邮件系统、办公平台甚至云服务，都可能成为Agent能够调用的工具。
整个过程可以简单理解为：
Agent理解任务 → 判断需要什么信息 → 选择对应工具 → 获取结果 → 根据结果继续执行
这与传统应用程序调用API有一定相似之处，但Agent增加了一层动态任务判断。
传统程序通常由开发者预先确定调用哪个接口、什么时候调用以及参数是什么；Agent则可能根据当前任务和上下文决定下一步需要使用哪个工具。
这也是Agent系统复杂度开始上升的地方。
MCP解决的是“怎么连接”的问题
当企业拥有越来越多的AI Agent之后，一个现实问题很快出现：不同Agent如何连接企业已有的工具和数据？
Model Context Protocol，也就是MCP，因此受到关注。
可以把MCP理解成一种帮助AI模型与外部工具、数据和上下文进行交互的标准化方式。它关注的不是模型本身有多强，而是模型如何获得完成任务所需要的外部信息和工具能力。
这一点很重要。
如果每一个Agent都需要针对CRM、数据库、办公软件、搜索系统分别开发一套连接方式，那么随着工具数量增加，维护成本也会不断上升。
标准化接口能够降低这种连接的复杂度，让Agent与外部能力之间形成相对统一的交互方式。
但需要注意，MCP并不等于AI获得了企业系统的自动执行权限。
Agent能不能访问某个系统、能够读取哪些数据、是否允许执行写入操作，仍然需要由企业自身的身份认证、权限策略和业务规则决定。
因此，从技术架构来看，MCP更接近“连接层”，而不是完整的企业AI治理方案。
多Agent协作，本质上是在拆分复杂任务
当企业AI从简单问答进入复杂业务流程后，一个Agent承担所有事情并不一定是最合理的方式。
例如，一项客户分析任务可能包含数据查询、数据分析、报告生成和内容审核等多个环节。不同环节需要的能力不同，对数据的访问范围也可能不同。
因此，可以让不同Agent分别承担相对明确的任务：
用户任务
↓
任务Agent
↓
数据分析Agent / 内容Agent / 系统操作Agent
↓
企业工具与业务系统
↓
结果汇总
↓
人工确认
这种方式可以让任务边界更加清晰，也有利于控制不同Agent能够访问的数据和工具。
不过，多Agent并不意味着Agent越多越好。
Agent数量增加以后，任务编排、上下文传递、状态管理、错误处理和权限控制都会变得更加复杂。对于企业系统来说，真正需要解决的是如何划分Agent职责，而不是单纯增加Agent数量。
Agent进入企业后，系统架构会发生什么变化？
传统企业应用通常是“人操作系统”。
员工登录CRM，查询客户；打开数据平台，查看报表；进入办公软件，编辑文件。不同系统之间虽然存在数据接口，但很多业务动作仍然由员工完成。
Agent加入之后，可能逐渐变成“人提出目标，Agent调用系统”。
这会增加企业系统之间的交互频率。
一个Agent可能需要从CRM获取客户数据，再调用数据分析服务，随后访问文档系统生成报告，最后把结果发送到协作平台。
从架构上看，原本相对分散的业务系统之间，会增加更多由AI驱动的调用关系。
这时候，企业需要关注的问题就不再只是AI应用本身，还包括：
-
系统之间的连接是否稳定；
-
Agent身份如何认证；
-
不同工具的访问权限如何划分；
-
数据在系统之间如何流动；
-
工具调用是否能够被记录；
-
Agent出现错误时能否快速定位。
Agent因此会把原本属于应用层的问题，逐渐延伸到企业IT基础设施。
权限控制可能成为Agent落地的关键问题
人和AI使用企业系统时，一个很大的区别在于操作速度。
员工通常一次完成一个操作，并能够理解自己正在处理什么；Agent则可能在很短时间内连续调用多个工具。
这意味着，一旦Agent获得过大的权限，错误操作的影响范围也可能被放大。
因此，企业Agent不能简单复用员工账号权限，而需要考虑更加细粒度的访问控制。
例如，可以按照Agent身份、任务类型、数据范围和操作类型划分权限：
可以读取什么数据
可以调用什么工具
可以执行什么操作
哪些操作必须人工确认
对于涉及客户数据、财务数据、内部知识库或生产环境的系统，这种权限边界尤其重要。
同时，企业还需要记录Agent到底做了什么。
一个完整的Agent任务应该能够回答几个基本问题：它访问了什么数据？调用了什么工具？执行了哪些操作？最终产生了什么结果？
这就是可观测性的重要性。
企业Agent需要的不只是日志，而是完整的运行链路
传统应用出现问题时，开发人员通常会查看应用日志、数据库日志或者接口调用记录。
Agent系统的排查会更加复杂。
因为一次任务可能经过模型推理、工具调用、外部API、数据库查询和多个Agent协作。如果只记录最终结果，很难判断问题到底发生在哪一个环节。
因此，企业需要逐渐建立完整的Agent运行链路，包括任务状态、工具调用、响应结果、异常信息和人工干预记录。
这样，当Agent出现错误时，才能知道它是理解任务出现偏差，还是获取了错误数据，或者某个外部系统没有正常响应。
从这个角度看，Agent的可观测性实际上与传统分布式系统存在一定的相似之处。
AI只是加入了一个新的决策层，但底层依然需要解决系统稳定性、错误处理和运行监控的问题。
网络和基础设施为什么也会受到影响？
Agent进入企业之后，网络问题也可能从“用户访问应用”逐渐转变成“系统之间持续交互”。
过去，一个员工访问海外SaaS平台，可能只是一次页面访问；Agent执行任务时，则可能连续访问多个API、云平台和业务系统。
对于跨区域、多云或者海外业务环境来说，系统之间的连接质量会直接影响Agent工作流。
尤其是一个任务涉及多个外部系统时，任何一个关键环节出现连接异常，都可能导致整个任务中断。
因此，企业在部署Agent时，需要把网络稳定性、跨区域访问、云服务连接和系统可用性纳入整体架构考虑，而不能只关注模型和应用层。
Agent真正落地，需要解决四个层面的问题
从企业技术架构来看，Agent规模化应用至少涉及四个层面。
第一层是模型能力，负责理解任务、分析上下文和生成结果。
第二层是Agent与工具层，负责任务拆解、工具调用、工作流编排以及与外部系统交互。
第三层是企业系统层，包括CRM、SaaS、数据库、云平台和内部业务应用。
第四层则是基础设施与治理层，包括身份认证、权限管理、网络连接、安全策略、日志审计和运行监控。
这几个层面缺一不可。
模型能力再强，如果无法获取企业数据，Agent依然无法完成实际工作；工具连接再完善，如果没有权限边界，也很难进入生产环境；基础设施再稳定，如果工作流本身没有合理设计，同样无法产生实际业务价值。
结语：Agent的竞争正在从模型走向系统
Cisco此次围绕Agentic Collaboration进行的更新，可以看作企业AI发展方向变化的一个缩影。
AI正在从“生成一个答案”逐渐走向“完成一项工作”。这意味着企业需要解决的问题也从模型能力扩展到了工具调用、业务系统连接、权限控制、网络基础设施和运行可观测性。
对于开发者和企业技术团队而言，Agent真正值得研究的地方，也许并不是如何再做一个聊天机器人，而是如何把模型放进真实业务流程，让它能够在明确的权限和治理边界内调用工具、处理数据并完成任务。
当AI开始成为工作流的一部分，企业AI的技术竞争就不再只是模型能力的竞争，而是整个系统工程能力的竞争。
