一万八千人专职做智能体，说明卡点不在模型能力，在「从试点走到生产」这一段路上没人扛。

10 月 19 日，Cognizant（Nasdaq: CTSH）与 Google Cloud 宣布扩大合作，成立 Gemini Frontier Capability Group。公告里三个数字值得记：

• 18,000 名专职工程师进入这个团队；

• 55,000 名员工完成了 Build with Gemini 工作坊，公告称这是迄今规模最大的 Gemini 合作伙伴工作坊；

• 公司内部 2026 年把 Gemini 铺到 100,000 名员工，计划扩到 200,000 名。

Cognizant 首席执行官 Ravi Kumar S 的说法很直接：成立这个团队，是让最前沿的工程人才「完全专注于把前沿 AI 投入生产」。Google Cloud 首席执行官 Thomas Kurian 的表述则点出了合作方视角——大规模部署智能体，需要的是「具备深厚架构与集成专业知识的可信伙伴」。

两家都在讲同一件事：智能体不缺模型，缺的是把它送进生产的那批人。

一、先看它选了什么架构

公告里最该被技术人注意的不是人数，是这句：团队计划部署标准化、安全优先的智能体架构，构建在 Model Context Protocol（MCP）之上，并由 Google Cloud 的 Model Armor 加固。

这句话包含两个工程决定：

第一个决定是工具协议统一到 MCP。 企业内部的智能体要能用业务系统，就得有统一的工具描述与调用约定。每个项目各写一套函数调用封装，短期能跑，长期会在审计、权限、版本管理上失控。选一个协议并把服务端改造标准化，是把一次性交付变成可复制能力的前提。

第二个决定是把防护层放在协议之外。 Model Armor 这类组件处理的是提示注入、敏感数据泄露、不当内容这类问题，位置在模型调用链路上，而不是在工具里。这个分工很关键——工具侧负责「能做什么」，防护层负责「不许做什么」，两者不混在一起，才能各自演进。

公告把这条架构称作「security-first」，用词克制，但它对应的现实是：企业里智能体一旦接上真实的写操作，「它会不会被一段提示词诱导去执行错误动作」就成了必须回答的问题。

二、四个起步方向，全是硬骨头

这个团队初期聚焦四件事：遗留系统现代化、开发者体验、业务流程智能体化、前沿网络防御。

这份清单的选择很有指向性。四个方向里没有一个是「做个聊天机器人」，全是企业里最难推动、也最容易在半途失败的类型：

• 遗留系统现代化的难点在于，改造对象往往没有完整文档，接口风格从 SOAP 到私有 SDK 都有，智能体要在这种环境里工作，先得把能力包装出来。

• 开发者体验是内部提效，衡量口径相对清楚，也是多数企业愿意先试的方向。

• 业务流程智能体化的难点在权责：一步操作该由谁批准，出错谁负责。

• 前沿网络防御则直接进入安全域，容错空间最小。

三、三个交付形态，透露了落地路径

公告点了三个生产级方案：面向零售的 Catalog Support Agent（CSA）、由 Neuro San 编排的医疗智能体市场（Healthcare Agentic Marketplace）、面向制造业的多智能体 Order-to-Cash（O2C）工作流。

这三种形态恰好对应三条不同的落地路径：

形态	结构	适合解决什么
零售目录支持	单智能体 + 业务系统工具	客服、商品与订单查询这类高频、边界清晰的场景
医疗智能体市场	多智能体编排（Neuro San）	需要多个专业角色协作、且要能组合成「市场」供选择的场景
制造业 O2C	多智能体串成端到端流程	跨部门流程，单点智能体无法闭环的场景

三者对工程能力的要求依次上升：单智能体的难点在工具封装，多智能体编排的难点在状态与交接，端到端流程的难点在异常处理——真实订单会缺字段、会重试、会部分失败，流程编排要把这些情况全部定义清楚。

四、一个可核查的样本，但要看清口径

公告给了一个效力证明：把 Gemini 模型接进某大型零售商的软件开发生命周期后，该客户实现开发者生产力提升 40%、上市时间缩短 30%、成本节省 35%。

这三个数字来自厂商公布，没有独立的第三方验证，也没有说明统计口径（是人均提交量、需求交付周期，还是项目总成本）。引用时可以写，但必须带「厂商公布」四个字。

真正能作为判断依据的，是另一个数字：55,000 人完成工作坊。培训规模是可验证的组织事实，它说明的不是模型多强，而是这家公司愿意为「会用」付多少成本。

五、这条新闻的真正信息量

把上面几段合起来看，可以得出一个不太好听但很有用的判断：智能体进生产的瓶颈，已经从模型能力转移到组织能力。

三个证据：

1. 投入的是人，不是算力。 一万八千人的规模，等于承认每个客户的智能体项目都需要嵌入式工程支持，而不是给个 API 文档就能自助。

1. 先定协议，再谈场景。 架构选择排在应用清单前面，说明他们判断复用性来自协议统一，而不是来自场景复制。

1. 交付形态按复杂度分层。 单智能体、多智能体编排、端到端流程三条线并列，等于承认不存在一种形态通吃。

这对国内做同类事情的人有直接参考：如果一个智能体项目卡住了，先别怀疑模型，先看三件事——工具是不是统一协议接入的、权限与审计是不是独立于工具实现的、异常路径是不是被显式定义过。

六、产业坐标

企业内部的智能体一旦要写业务系统，问题就从「模型会不会答」变成「这次操作谁批准、出问题谁负责、事后能不能复盘」。信创环境里这层约束更硬：要接的系统多是存量资产，接口风格不统一，数据不能出域，审计要能落到具体操作。金蝶天燕 Apusic 智能体平台 AIAP 这条线承接的正是这层工程化——把工具调用放进沙箱隔离、敏感操作执行前要求人工确认、危险操作自动拦截，并保留全链路推理轨迹供追溯；它要解决的不是让智能体更聪明，而是让一次由智能体发起的变更在事后能被完整解释。

七、结论

一万八千人的新闻，表面是巨头加码，实质是一份「智能体落地成本清单」：人、协议、防护、异常路径，四样都得付。

模型能力还会继续涨，但这四样的成本不会因为模型变强而自动下降。看清这一点，比追逐下一个模型版本更有用。

---

你们单位的智能体项目，卡在工具接入、权限审批还是异常处理？如果只能先解决一个，你会选哪个？欢迎在评论区聊聊。