Cisco内部助手：从安全入口到员工任务，再到共享工程平台

安全入口已经上线，八个月后使用者仍只有约三成员工，且主要是技术人员。Cisco 随后的用户研究发现，员工最想解决的是 IT 支持问题。团队于是把内部人事与帮助资料放到优先位置，而不是继续把模型菜单当作产品的全部。

这条演进后来延伸为共享平台：领域知识让回答接近工作，注册与权限让团队能力能够被接入，多模型路由与安全控制承担基础设施职责。理解它需要分清这几种输入和控制，不能把“有 MCP”理解成每个员工都获得了后台操作权。Cisco内部工程文章，2025年11月

第一版先管输入风险，下一版才解决资料缺口

2023年4月的初始版本使用 Azure OpenAI 模型，保存会话提示记录，实时审计提示，并在处理前自动遮蔽个人身份信息。它首先提供员工可在企业边界内试用模型的条件。

随后设计团队把搜索内容、用户痛点与工作阻力放在一起分析，确认 IT 支持是首要需求。新增资料来自 People and Communities、Help Zone 的文章、网站和报告；团队还复用已在 Cisco.com 与 SalesConnect 建设的检索增强能力，扩展到产品和销售资料。检索增强在这里承担“回答前找到有关企业材料”，不是把企业知识永久写入模型权重。

新员工电脑与手机设置、费用报销等问题，说明这次接入改变了什么：模型现在有机会取得与岗位有关的依据。文章没有公开具体分块、检索查询、排序、引用生成或来源更新协议，也未给出这些任务的逐类完成率。可以借鉴知识范围的选择，不能据此复制一份未公开的检索实现。

后续平台里，注册、路由与安全不是同一个控制

工程文章列出了后续平台的职责。它们是并列能力，不是一条每次必经的固定流水线。

MCP 可以理解为把模型应用与工具连接起来的一套协议；注册表让远程能力可被找到并按资格接入。它不改变业务系统的责任：谁能读、谁能写、一次调用是否真正完成，仍要由相关服务与宿主控制。公开文章披露了这些责任的存在，没有给出单次请求怎样携带身份、如何选择工具、执行失败如何恢复的完整轨迹。

原文还列出基于企业 OneDrive 的个人检索、内部及网络资料深度研究、数据分析和演示文稿生成。它们说明入口已容纳不同任务，但不会证明同一段上下文或同一套权限自动适用于全部任务。把产品能力清单画成同一生产调用链，会掩盖它们对数据与动作的不同要求。

资料质量与员工顾虑，各有自己的修复方式

团队披露，早期难点之一是保证接入资料干净、质量可靠且结构清楚，并持续测试回答。另一难点是员工即使知道工具获准处理高度保密资料，仍担心误用，因此团队增加演示、赋能资源和使用教育。

前者需要知识维护、质量检查和更新责任，后者需要清楚的输入规则与具体任务示范。让员工参加更多培训，并不能补上找不到的文档；多接一个知识源，也不能替员工判断允许输入哪些信息。只有把未完成任务与原因放在一起，反馈才能决定下一步该由哪支团队处理。

文章说团队持续监控反馈并迭代路线，但没有公开反馈分类、转缺陷、回归测试或发布门禁的自动化协议。把“持续反馈”直接画成一个已经闭环的自动训练系统，会比来源多走几步。

使用规模显示覆盖与活跃，任务结果需要另测

Cisco 在该文报告超过4,500万次交互、10万多用户、平均每日约15.6万次交互；73%的用户自报生产力有所改善，平均每周自报节省5小时。它们描述覆盖、使用与感受，不能互换成任务成功率或产出提高的幅度。文章没有提供调查样本、响应率、完整工作计时及错误对照，不能按这些数字推算因果收益。

时间范围也要保留：早期三成采用、2025年平台能力、原文仍称即将推出的 Agent Builder，不属于同一个上线时点。本文讨论的是逐步演进，而非2023年已经具备最终平台全部能力。Cisco 的对客 Support Assistant 与这项内部员工助手也不是同一产品；前者的工单或RMA工具不能移作后者的内部实现证据。

落地检查，从员工上一次没完成的事情开始

选择获准检查的内部支持记录，把缺资料、资料过期、无访问权、输入规则不清、回答有了却事情未完成分别归因。对一个候选能力，要求能指出本次用了哪些材料、身份与资格由谁判定、输出是说明还是执行结果、失败交给谁处理。

若助手只给配置指南，就验证指南适用与问题是否解决；若它调用业务工具，则另外验证授权、参数、结果和重复请求。共享平台注册成功、模型能答、员工愿意尝试，应当各自留有证据，不能用其中一个替另一个过关。这是本文提出的迁移检查；公开资料尚不足以给出Cisco私有平台的逐接口复现。