10月7日，Cisco在WebexOne 2026期间公布了一系列围绕Agentic Collaboration的更新，涉及Webex、Claude Managed Agents、Model Context Protocol（MCP），以及客户服务、智能办公和企业IT管理等场景。
从开发和架构的角度看，这类更新真正值得关注的并不是某个具体AI功能，而是企业AI正在发生的一次架构变化：
AI开始从一个“生成结果的模型”，变成能够参与业务工作流、调用外部工具并与企业系统交互的执行节点。
这意味着企业原有的软件架构中，可能增加一个新的参与者——Agent。
而Agent一旦进入生产环境，问题就不再只是“模型能不能回答正确”，还会涉及任务编排、工具调用、上下文管理、权限控制、系统连接以及运行可观测性。
从Chat到Workflow，Agent到底改变了什么？
传统大模型应用的调用链通常比较简单：
用户输入 → LLM → 输出结果
例如用户让模型生成一份客户分析报告，模型可以完成文本生成，但数据从哪里来、报告生成之后放在哪里，通常还需要人工处理。
Agent的工作方式则有所不同：
用户目标 → Agent理解任务 → 获取上下文 → 调用工具 → 处理结果 → 再次调用工具 → 输出结果
这里最重要的变化不是多了一个“Agent”名词，而是LLM开始参与工作流决策。
模型负责理解任务和当前上下文，Agent运行时负责维护任务状态，并根据当前结果决定下一步需要调用什么工具。
因此，Agent系统本质上是在传统应用架构中增加了一层动态任务编排能力。
工具调用是Agent进入生产环境的基础
Agent如果只能生成文本，它与普通AI助手之间的区别并不明显。
真正让Agent能够进入业务系统的是工具调用能力。
一个企业级Agent可能需要调用：
- CRM查询接口；
- 企业知识库；
- 数据分析服务；
- 文件存储；
- 邮件或协作平台；
- 云服务API；
- 内部业务系统。
因此，一个典型的Agent运行过程可能是：
接收任务
↓
判断需要的数据
↓
调用数据工具
↓
分析返回结果
↓
判断下一步操作
↓
调用业务工具
↓
汇总结果
↓
人工确认
这与传统业务系统中的固定流程有明显区别。
传统程序通常由开发者预先定义调用顺序，而Agent可以根据任务上下文动态决定下一步动作。
这带来了更大的灵活性，同时也带来了更高的系统不确定性。
MCP解决的是工具和上下文连接问题
当企业中的工具数量不断增加，Agent如何连接这些工具会成为一个实际问题。
Model Context Protocol（MCP）受到关注，与此有直接关系。
MCP可以为模型与外部工具、数据以及上下文之间的交互提供标准化方式。对于开发团队来说，它的价值之一在于减少针对不同工具重复设计连接机制的成本。
可以把它简单理解为：
Agent / LLM
↓
MCP
↓
外部工具与数据
但需要注意，MCP并不是一个完整的权限控制或者安全治理体系。
它解决的是连接和交互方式，而“这个Agent到底能访问什么”仍然需要由企业的身份认证、授权策略和业务规则控制。
因此，在实际架构中，MCP应该被看作Agent工具生态的一部分，而不是替代企业现有的IAM、API Gateway或者安全控制体系。
多Agent并不是简单增加几个模型
当任务变复杂之后，企业可能进一步采用多Agent架构。
例如：
主Agent
├── 数据分析Agent
├── 内容处理Agent
├── 企业知识Agent
└── 系统操作Agent
不同Agent负责不同任务，可以降低单个Agent承担全部职责带来的复杂度。
但多Agent也会引入新的工程问题。
首先是任务编排。主Agent如何决定把任务交给哪个Agent？其次是上下文传递，不同Agent之间需要共享哪些信息？再往后，还有状态管理、错误恢复、超时处理和权限隔离。
因此，多Agent架构真正的难点并不是“多部署几个Agent”，而是如何设计Agent之间的职责边界和通信关系。
对于简单任务，一个Agent加几个工具可能已经足够；只有当业务流程确实存在明显的职责拆分时，多Agent才有实际价值。
Agent进入企业后，权限模型需要重新设计
传统企业系统的权限模型主要围绕“人”建立。
员工登录系统后，根据角色决定能够查看哪些数据、执行哪些操作。
Agent加入之后，系统中出现了新的调用主体。
这时需要回答：
Agent是谁？
它代表谁执行任务？
它可以访问什么？
它可以执行什么？
哪些操作必须由人确认？
这实际上把企业身份和权限体系从Human Identity进一步扩展到了Machine Identity。
对于Agent来说，最危险的设计之一就是直接继承一个权限过大的员工账号。
更合理的方式是根据任务、Agent身份、工具以及数据范围建立更加细粒度的授权策略。
例如，同一个Agent可以允许读取某类客户数据，但不允许删除数据；可以生成报告，但不能直接修改核心业务记录。
这类权限边界，是Agent能否进入生产环境的重要条件。
Agent的可观测性比传统应用更加复杂
传统应用出现异常时，开发者通常查看日志和接口调用记录。
Agent系统的链路更加复杂。
一次用户请求可能经过：
用户 → Agent → LLM → 工具 → API → 数据库 → LLM → Agent → 最终结果
如果任务进一步采用多Agent架构，调用链还会继续增长。
因此，Agent系统需要记录的不只是最终结果，还包括：
- Agent接收到什么任务；
- 使用了什么上下文；
- 调用了哪些工具；
- 工具返回了什么结果；
- 哪一步发生异常；
- 是否进行了人工干预；
- 最终输出如何产生。
这也是Agent Observability逐渐成为企业AI工程体系重要组成部分的原因。
没有完整的调用链，出现错误时很难判断问题到底来自模型、工具、数据还是基础设施。
网络问题也会进入Agent工程体系
Agent工作流通常不是一次调用。
一个复杂任务可能需要访问多个SaaS平台、API、云服务和企业内部系统。对于跨区域、多云或者海外业务场景，这些系统之间的连接质量会直接影响Agent任务执行。
例如，一个Agent需要依次访问CRM、海外SaaS平台和内部数据服务，其中任何一个关键调用超时，都可能导致整个任务失败。
因此，Agent架构虽然看起来属于AI应用层，但实际运行依赖的仍然是完整的IT基础设施。
网络连接、API可用性、DNS、身份认证、服务发现、访问控制以及故障恢复，都可能成为Agent工作流稳定性的组成部分。
企业Agent架构可以拆成几个层次
从工程实现角度，可以将企业Agent系统粗略拆分为几个层次：
模型层
负责推理、理解任务和生成结果。
Agent运行层
负责任务状态、上下文、工具选择和工作流编排。
工具与协议层
负责连接数据库、API、SaaS平台以及其他外部能力，MCP可以在这一层发挥作用。
企业系统层
包括CRM、ERP、知识库、数据平台、云服务和内部业务应用。
治理与基础设施层
包括身份认证、权限管理、日志审计、网络、安全策略和可观测性。
这几个层次之间并不是完全独立的。
例如模型选择会影响工具调用策略，工具调用会影响权限设计，而跨系统调用又会直接影响网络和可观测性。
所以，企业Agent并不是单独部署一个模型就完成了。
真正的工程问题是“如何让Agent可控”
Agent最大的优势是能够根据任务动态调整执行路径，但这同时也是它最大的工程挑战。
传统软件强调确定性：输入是什么、执行什么逻辑、最终得到什么结果，通常都可以提前定义。
Agent则具有一定的不确定性。
它可能根据上下文选择不同工具，也可能因为模型判断不同而采取不同执行路径。
因此，企业真正需要建立的是一套“可控的不确定性”机制。
包括限制Agent可使用的工具范围，控制数据访问权限，对高风险操作增加人工确认，同时记录完整运行链路，并为异常任务设置超时、回滚和终止机制。
只有这样，Agent才有可能从Demo进入真正的生产环境。
从模型工程走向Agent工程
Cisco此次围绕Agentic Collaboration的布局，反映出的并不只是企业AI产品形态变化。
对于开发者和架构师来说，更重要的变化是：AI应用正在从模型调用工程，逐渐走向完整的Agent工程。
过去开发一个AI应用，重点可能是Prompt、模型选择、RAG和上下文管理；当Agent开始调用企业系统之后，工具编排、权限管理、状态管理、可观测性和基础设施都会进入技术栈。
这意味着未来企业AI架构可能越来越接近一个分布式系统。
模型负责推理，Agent负责决策和编排，工具连接外部能力，企业系统提供业务数据，而身份、安全、网络和可观测性负责保证整个系统能够稳定运行。
Agent真正的技术价值，不是让AI“看起来更聪明”，而是让模型能力能够安全地进入真实业务流程。
当企业开始从Chat转向Workflow，AI应用的核心竞争力也会从单纯的模型能力，逐渐扩展到整个系统工程能力。
