推出面向政府服务的 Gemini：Google 将智能体引入机构工作流程

Google 于 10 月 20 日推出 Gemini for government services，将其工作场所智能体引入政府运营，同时对关键步骤保留人工审批。其题为“Introducing Gemini for government services”的公告介绍了一款软件，可将机构知识与完成行政工作的工具连接起来。核心张力在于委托执行与公共问责之间：起草文件与批准发布承担着不同责任。

首批发布为面向美国联邦、州和地方政府的预览版。Google 点名密苏里州和卫生与公众服务部为参与机构。这些合作关系表明已有早期参与，但并不能证明准确性提升、积压缩减，或面向公众服务的改善已获得独立验证。

Microsoft 已经提供 Copilot Studio 的政府版本，该平台用于构建对话式智能体。因此，Google 进入的是一个既有的政府自动化市场。更重要的竞争围绕运营模式展开：机构委托多少工作、员工在何处介入，以及事后保留哪些证据。对公务员、开发者和采购方而言，这项公告将采购讨论从生成有用答案转向监督跨机构系统的工作。

推出面向政府服务的 Gemini，超越了单纯提供答案

Google 正将政府知识、系统访问权限和受监督操作打包为面向机构工作流程的产品。

AI 智能体是利用模型和连接工具来完成指定目标的软件。与独立助手相比，它的重要性来自于生成答案后还能做什么。

Google 的政府服务预览结合了可复用的政府指令、系统连接器、合作伙伴智能体和集中式控制功能。连接器是让软件通过已定义接口访问另一系统的集成组件。Google 表示，访问遵循现有权限，并可查询已连接系统，无需迁移数据。

该公司将记录发现和拟议文件脱敏列为支持的工作流程。脱敏是指在材料送达获授权受众之前，删除应保密的信息。Google 表示，关键步骤由人员审批。

这种安排改变了员工与软件之间的关系。员工不再只是请求摘要并手动组织下一项任务，而是委托一项范围有限的工作。实际问题在于，这一边界能否在整个执行过程中保持可理解性。

设想一项假设性的公共记录请求，涉及往来文件和支持性材料。查找相关材料、整理审查包和批准披露是不同的活动。智能体可以协助完成前两项活动，而记录官员仍保留对发布的责任。

这一差异至关重要，因为中间环节会影响最终决定。收到不完整审查包的审查者，可能永远看不到会改变其判断的文件。最后阶段的人工审批无法自动弥补流程早期的遗漏。

因此，审批界面需要的不只是一个接受按钮。一份有用的审查包应展示搜索范围、被排除的材料、未解决的问题和拟议操作。否则，员工只能审查智能体的结论，却看不到其足够多的工作过程。

这是对委托式工作流程的分析性推论，而非已报告的预览结果。公告确立了 Google 的预期设计。机构仍需获得证据，证明该设计在自身文件、权限和例外情形下会如何运行。

产品边界同样值得关注。一项政府产品可能包含多项成熟度不同的能力。采购方应区分已演示的工作流程、受支持的生产配置，以及在更广泛平台介绍中描述的功能。

因此，推出面向政府服务的 Gemini 为 Google 创造了一个具体机会：在底层模型之外销售受监督的行政流程。其价值取决于这一流程能否经受住日常机构复杂性的考验。

这种复杂性包括材料提交不完整、记录相互矛盾、特殊案例，以及需要澄清的请求。一场有说服力的演示应展示：当现有证据不足以支持完成任务时，工作如何停止并交还给员工。

机构采购方将面临不同的评估问题

委托工作使流程质量、审查工作量和异常处理成为核心采购标准。

Google 的政府智能体发布公告将该产品定位为构建于 Gemini 平台之上的行业解决方案。公司将密苏里州和 HHS 列为早期用户，但公告未提供已衡量的部署成果。

因此，应以有限的方式解读它们的参与。这支持了早期机构参与确实存在，但不能证明相同配置适用于其他部门、项目或辖区。

压力首先落在机构技术负责人和项目所有者身上。他们必须评估，在计入监督所需工作后，拟议工作流程是否真正改善了服务交付。

生成的草稿可能看似完整，却将工作转移到后续环节。员工可能花更少时间整理材料，却花更多时间核查引用、调查例外情况或修正格式。相关衡量应覆盖完整任务。

对于一个假设性的文件受理流程，机构应检查自动检查标记问题后会发生什么。申请人能否收到清晰说明？员工能否纠正分类？案件是否保留原有排队位置？

这些问题将内部生产效率与公众体验联系起来。如果一个流程减少了员工处理时间，却增加了不必要的重复提交，那么它只是将工作转移到了别处。要称之为改进，需要采用更广泛的核算方式。

审查工作量也会影响采用。如果员工必须像审查未经辅助的草稿一样仔细检查每份输出，承诺的能力提升就更难证明。减少准备时间仍然重要，但需要加以衡量。

历史背景支持谨慎评估。GAO 的联邦 AI 清单发现，在选定机构中，已报告的生成式 AI 使用案例从 2023 年的 32 个增加到 2024 年的 282 个。这些数量描述的是已报告的使用情况，而非经过审计的服务改善。

GAO 还记录了涉及政策合规、技术资源、预算以及保持适当使用政策更新的挑战。其发现针对的是整体机构采用情况，并非对这一 Gemini 预览版的评估。

这一差异为采购方提供了有用框架。采用规模增长解释了为何打包式政府 AI 会受到关注，而采用本身并不能回答成果问题。机构仍需建立自己的基线和验收标准。

对于实施合作伙伴而言，压力也在变化。构建可运行的集成只是交付的一部分。还必须有人维护指令、记录变更、处理连接失败，并帮助员工理解何时应升级处理。

最有力的采购论证应将技术性能与明确的行政结果关联起来。例如，减少返工、更清晰的通知，或在审查流程不变的情况下更快完成。这些是评估目标，而非 Google 公告已证实的成果。

推出面向政府服务的 Gemini 使这些目标更加紧迫，因为拟议产品超越了个人起草。一旦软件协调行政步骤，机构就必须将由此产生的服务流程作为整体进行评估。

现有系统成为竞争核心

政府 AI 的竞争日益取决于对机构知识和既有工作流程的受控访问。

Microsoft 提供了有用的对比，因为面向政府的特定环境已经塑造了其智能体产品。其政府智能体环境文档描述了美国内容驻留、受限的管理访问权限，以及政府版和商业版能力之间的差异。

Microsoft 还警告，连接的第三方服务可能不在其政府服务的合规与数据保护承诺范围内。这一警告说明了更广泛的采购问题：围绕集成的边界与承载该平台本身同样重要。

这并不能证明 Microsoft 的产品与 Google 的预览版功能相当。采购方需要比较其预期部署所能获得的精确环境、能力和连接服务。

对于已经使用成熟协作和案件系统的机构而言，更换模型提供商只能解决部分问题。其余工作涉及身份管理、文档组织、系统访问和审批责任。

因此，竞争优势在一定程度上取决于降低实施的不确定性。机构需要知道哪些连接受支持，哪些需要定制开发，以及上游系统变化时由谁负责维护。

连接器的存在并不能回答所有这些问题。读取文件、搜索档案和更新案件涉及不同权限和故障模式。采购方应评估其打算授权的具体操作。

设想一个假设性的工作流程：从多个存储库中准备案件摘要。智能体需要访问相关记录，但审查者也需要确信，无法访问的材料没有悄然扭曲结果。

如果明确说明部分来源不可用，将有助于审查者解读摘要。缺少这一警告的精致回答，可能会诱发超出可用证据范围的信心。

这正是政府 AI 智能体面临底层知识环境条件的地方。不一致的文档命名、重复的指导文件和不明确的所有权，都会使任何需要检索可靠机构背景信息的系统变得复杂。

同样的区别也出现在普通的 AI 知识库中：个人检索和全组织访问解决的是不同问题。政府部署则在这种底层知识挑战之上增加了项目责任和公共问责。

对开发者而言，这会将注意力转向系统行为。处理过期凭据、不可用的存储库、部分搜索结果和中断的工作，都会成为用户体验的一部分。这些情况应始终对监督任务的人员可见。

对于政府机构而言，这带来了一个比“哪款助手最擅长写段落”更具体的竞争问题：哪家供应商能够支持既定流程，同时让访问限制、故障情况和审查责任清晰可见？

Google 的产品组合使其能够在这一层面展开竞争。Microsoft 已公布的政府环境表明，控制措施和部署边界已构成市场的一部分。

这两种立场都无法免除对特定工作负载证据的需求。只有沿着同一项任务，贯穿源数据访问、准备、审查和获授权完成等环节，平台比较才具有价值。

人工审批需要有证据支撑

只有当审查者能够对拟议行动进行实质性质疑时，人工检查点才能支撑问责。

受监督自动化的承诺听起来很直接：软件准备工作，员工批准结果。其有效性取决于员工获得了什么，以及审查需要多少时间。

面对一份冗长材料的审查者，需要能够定位不确定性的方式。重要遗漏、相互冲突的证据和未解决的例外情况，应当在其影响决策的位置呈现，而不应被流畅的文字掩盖。

NIST 的生成式 AI 风险概况将“虚构”——即以高度自信的方式呈现错误内容——列为相关风险。该文件还指出，生成的解释和引用本身也可能具有误导性。

该指南提供了一个通用的风险视角。它并未证明 Gemini 的政府预览版曾产生某个具体错误。相关含义是，即使答案看起来有来源支撑，仍需要进行实质性核查。

引用可以帮助审查者定位证据，但其存在并不能证明证据支持该结论。审查还需要核验适用性、范围，以及相反信息是否会改变答案。

在一个假设性的政策问题中，检索到的段落可能准确描述了一项通用规则，却遗漏了与该案例相关的例外情况。因此，最终答案可能看似证据充分，却不适合用于决策。

因此，政府机构应在常规案例之外测试困难案例。一套有用的评估集应包括不完整记录、相互冲突的指导意见、无法读取的文件，以及需要系统请求协助的情形。

这些是拟议的评估条件，而非对已观察到故障的断言。其目的在于区分准确完成任务与证据不足时仍继续执行的系统。

同一原则也适用于文件发布。审查材料应让员工能够在上下文中检查拟议的处理方式。批准一个孤立标签所提供的保证，不如审查周边文件及拟议行动的理由。

工作负载同样会影响审查质量。如果代理生成材料的速度快于员工评估的速度，审批队列就会成为下一个瓶颈。管理者需要在衡量准备速度的同时衡量审查能力。

当员工不同意软件结论时，还涉及责任归属问题。一个可用的流程应让他们能够拒绝、修正或升级处理输出，同时不丢失事件记录。

这些修正能够揭示问题是来自源材料、指令、系统访问还是模型行为。若将每次修正都视为个别员工的偏好，就会掩盖改进工作流所需的信息。

因此，最有力的审慎视角是具体的。该公告描述了旨在支持监督的控制措施，而有意义的监督需要关于员工如何在实际工作负载下使用这些控制措施的证据。

为政府服务引入 Gemini 应按照这一运营标准来评判。人工审批在能够实现知情干预时值得肯定，而其有效性需要评估，而非假定。

问责不止于代理的答案

政府机构需要一份可辩护的流程记录，包括变更、例外情况和员工干预。

行政工作流产生的不只是最终文件。它还会形成一段历史，记录所查阅的来源、提出的决策、作出的修正和获授权的行动。当有人质疑结果时，这段历史就会变得重要。

GAO 的AI 问责框架围绕治理、数据、绩效和监测组织监督工作。它提供了比核查单个答案是否看似准确更广泛的框架。

应用于这一公告，该框架表明存在持续的管理责任。政府机构需要对工作流拥有明确责任，并能够判断其是否会随着系统和运行条件变化而继续适用。

一次成功的试点并不能永久解决这个问题。指令可能过时，源资料库可能变化，员工也可能发现原始评估遗漏的例外情况。

政府机构应决定由谁负责每一项修正。政策专家可能维护实质性指导内容，技术团队则维护连接。项目领导层仍必须对行政结果负责。

缺乏这些职责时，维护工作可能落入供应商与部门之间的空隙。即使没有人承担保持某条具体指令最新的责任，系统仍可能继续运行。

版本历史在此很有价值。如果员工质疑某项输出，调查人员需要了解当时的指令和可用来源。只审查最新配置，可能掩盖早期结果产生的原因。

这是一个实施层面的含义，而非对某项已记录 Gemini 功能的陈述。它描述了政府机构重建受委托工作过程所需的证据。

准备与授权之间的界限也必须保持清晰。一项建议、一份通知草稿和一项获授权的通信，应具有清楚的状态。员工应了解软件何时仅完成准备，何时已经采取行动。

一个假设性的中断工作流说明了这一问题。如果草稿准备完成后连接失败，用户应知道是否有内容被保存、提交或发送。模糊性会造成可避免的核查和重复工作。

采购团队还应审查政府机构如何退出一个工作流。仅导出文件，可能会遗留在其他地方复现流程所需的指令、评估材料和决策历史。

这并不意味着迁移必须毫不费力。它意味着买方应在让该工作流变得具有运营重要性之前，了解哪些部分由其控制，哪些部分仍依赖供应商。

这些问题将问责与长期采购价值联系起来。即使一个产品组合能加快初始部署，也仍需要可持续的运营安排。维护、审计支持和变更管理都应纳入评估。

对于知识工作者而言，结果很实际：监督政府 AI 代理将成为一项独立职责。员工需要可理解的证据、明确的权限，以及可靠地报告不确定性的方式。

随着预览版发展，需要关注什么

接下来有价值的证据涉及可用性、可衡量的结果，以及政府机构监督的质量。

第一个信号是更清晰的部署范围。在未来几个月里，应关注有关谁可以访问预览版，以及哪些配置支持特定工作负载的详细说明。

更广泛的发布将强化 Google 能够超越少数早期合作项目的论据。可用性本身仍会留下绩效问题，但它能明确哪些政府机构可以直接评估该产品。

文档应区分已支持的连接和计划中的连接。它还应明确功能在哪里准备信息、在哪里提出行动建议，以及员工必须在哪里介入。

这些区分能帮助买方避免用广泛的平台承诺来评估仅在狭窄范围内可用的配置。它们也会使与 Microsoft 及其他供应商的比较更有意义。

第二个信号是具有明确基线的部署结果。一份有用的政府机构说明，应阐明原始流程、接受评估的工作负载，以及引入代理后发生的变化。

完成时间很重要，但修正工作量、未解决案例和审查时间同样重要。包含这些指标的证据，将比快速生成文件的演示更有力地支持生产力判断。

某个具名政府机构的积极反馈可以提供背景。公开的评估若说明其方法论，则能为判断另一家机构是否应期待类似收益提供更坚实的基础。

混合结果同样具有参考价值。如果常规案例有所改善，而例外情况需要更多工作，买方就能评估部署在哪些场景合理。透明的限制有助于建立有用的运营范围。

第三个信号是关于监督的证据。应关注员工覆盖操作、失败任务、访问限制，以及政府机构如何重建某项输出背后工作过程的说明。

这些信息将增强对拟议问责模式的信心。若只关注成功输出，核心矛盾仍无法解决：在受委托的工作转化为行政行动之前，谁能发现问题？

这些信号应按这一顺序评估。首先确定政府机构可以部署什么，然后审视其实现了什么，最后判断随着使用范围扩大，监督是否仍然有效。

对于开发者和公共部门买方而言，当前任务是在扩大其权限之前，明确试点必须产出的证据。选择一个边界明确的工作流，记录其当前绩效，并识别需要员工判断的节点。要求供应商在展示成功完成的同时，也展示未完成的工作和失败的连接。要求明确说明员工审查什么、系统记录什么，以及修正如何改变未来行为。为政府服务引入 Gemini 开启了关于受委托行政工作的具体讨论。应将这一讨论落实到政府机构的实际流程中：什么会更快，什么需要核查，以及哪些证据支持扩大应用的决定？