Salesforce Missionforce AI Agents 突破聊天边界，进入安全的政府工作流

Salesforce 扩展了 Missionforce，推出两条不同的 AI 路径，尽管政府机构需要一套统一的安全、监督与问责标准。Salesforce Missionforce AI agents 项目结合了通过 Amazon Bedrock 提供的 OpenAI 模型，以及可由机构在受控基础设施中定制和运行的 NVIDIA 模型。

这一组合让 Missionforce 超越了传统的政府聊天机器人。Salesforce 希望其平台能够将政策转化为可执行规则、协调运营工作、支持外勤团队，并在各机构系统之间发起获批操作。

该公告于 2026 年 9 月 16 日发布，距离 Salesforce 成立专门的国家安全业务 Missionforce 已满一年。此举也紧随联邦政府更广泛的推动，即在不放弃敏感数据控制权的前提下，将商业 AI 引入政府环境。

核心问题并不在于先进模型能否回答政策问题。机构需要知道处理发生在何处、智能体能够访问哪些数据，以及由谁批准具有重要影响的决策。

OpenAI 提供前沿模型访问能力和熟悉的 ChatGPT 界面。NVIDIA 则支持机构可在私有云或与公共网络隔离的气隙网络中调优和运行的模型。

Salesforce 位于这两种方案之间。它提供数据、权限、工作流、审计记录和应用层，旨在将模型输出转化为受控的政府操作。

这一定位赋予 Salesforce 重要角色，但也形成了本文的核心张力。Missionforce 承诺在不削弱运营控制力的前提下提供先进能力，但这些目标可能将机构引向不同的架构。

Salesforce Missionforce AI Agents 实际改变了什么

Salesforce 正在将 AI 模型连接到政府规则和工作流，而不只是将另一个助手放在现有系统旁边。

公司的 Missionforce 扩展包含三个主要要素，分别对应政府运营的不同环节。

首先，OpenAI 模型将通过 Amazon Bedrock 接入 Salesforce Public Sector Solutions。Bedrock 是 Amazon Web Services 提供的一项托管服务，用于在云应用中访问和部署模型。

Missionforce 应用和工作流预计也将可通过 ChatGPT 访问。获得授权的人员可在聊天界面中询问任务数据相关问题，并触发获批的 Salesforce 操作。

这一设计之所以重要，是因为它改变了 ChatGPT 的角色。该界面不仅会生成文本，也可能成为进入案件系统、政策流程和多步骤运营工作流的入口。

Salesforce 尚未表示每位 Missionforce 客户都能立即使用每一项已公布的集成。其公告称，服务可用性可能因地区和客户协议而异。

其次，Salesforce 推出了 Missionforce Policy Engine。该系统使用 OpenAI 模型，将获批的政策文件转化为结构化规则代码及相应的测试用例。

确定性规则遵循既定逻辑，而不是针对每个请求生成全新的答案。在机构管理福利、许可证、检查或其他受监管决策时，这一区别尤为重要。

语言模型负责解读源材料并起草规则结构。Salesforce 表示，在部署前，每项输出都必须经过人工审查和批准。

该公司以 Medicaid 资格认定为例。如果一个家庭的收入发生变化，获批工作流可以根据现行政策重新评估儿童的保障资格，并生成审计记录。

这一案例体现了安全政府 AI 智能体背后的雄心。智能体不只是解释一项规则，还会协助执行可能直接影响个人的流程。

第三，Missionforce Operations 将采用基于 NVIDIA 技术的专用模型。Salesforce 表示，将为采购、供应商管理、发票审查和资产物流微调 NVIDIA 模型。

这些模型可在私有云或气隙环境中运行。机构能够将模型处理、运营数据和智能体操作保留在自己控制的基础设施之内。

Salesforce 描述了一个涉及多个仓库库存的车队维护场景。智能体可以定位备件、准备调拨文件，并确定调度计划的优先级。

Missionforce Field Operations 和 Asset Management 增加了离线功能。检查人员或应急团队可在连接不稳定的地点管理工单和维护活动。

这些能力共同构成了更广泛的执行层。OpenAI 负责通用推理和政策解读，NVIDIA 则支持更接近受控运营数据的专用模型。

随后，Salesforce 将这两条路径连接至机构应用。这种编排角色比在采购目录中增加另一款模型更具影响力。

为什么政府的模型选择已成为战略问题

政府机构不再只是决定是否采用商业 AI，而是在决定其运营的哪些部分可以依赖不同的部署模式。

这一时机反映出联邦 AI 市场近期的变化。OpenAI 于 2026 年 4 月宣布，ChatGPT Enterprise 和其 API Platform 获得 FedRAMP Moderate 授权。

FedRAMP 是美国联邦政府用于评估云服务安全性的项目。Moderate 授权适用于保密性、完整性或可用性受损可能造成严重伤害的工作负载。

OpenAI 表示，该授权使机构能够使用托管产品开展研究、起草、翻译、软件开发、案件管理及其他任务支持工作。各个机构仍自行控制其授权和使用决策。

Salesforce 更早实现了另一项里程碑。Agentforce、Data Cloud、Marketing Cloud 和 Tableau Next 于 2025 年 6 月获得 FedRAMP High 授权。

FedRAMP High 面向发生泄露可能造成严重或灾难性损害的系统。获得授权并不意味着每种配置都适合每项任务，但它提供了重要的安全基础。

Missionforce 将这些组件组合在一起，而非将授权视为覆盖全平台的单一标签。机构必须审查所涉及的确切服务、功能、数据路径和责任边界。

当智能体能够执行操作时，这一点尤其重要。文本助手或许会总结一份内部文件，而运营智能体则可以更新案件、创建工单或建议资源调配。

随着系统获得更多权限，风险也会改变。准确性依然重要，但身份管理、访问控制、日志、升级规则和回滚程序同样变得关键。

Salesforce 的战略将模型选择视为这一更大控制系统中的一层。其平台决定哪些数据会传递给模型，以及之后可以执行哪些操作。

这一做法对其他政府 AI 提供商形成压力。模型供应商可以提供强大的推理能力，但机构也需要与保存权威记录的系统集成。

云服务提供商面临类似压力。托管获批模型固然有用，但买方越来越希望模型连接到可审计的工作流，而非孤立的应用程序编程接口。

政府承包商也必须调整。传统集成项目可能耗时数月或数年，而 Missionforce 将可复用的智能体和工作流组件作为更快的路径呈现出来。

不过，机构不能仅以部署速度衡量成功。它们必须评估错误率、异常处理、员工工作量、申诉情况以及对公众的结果。

因此，Salesforce Missionforce AI agents 在运营治理方面的竞争程度不亚于智能水平。决定性问题是，当模型行为发生变化时，周边控制措施是否仍然有效。

政府市场也不适合单一提供商架构。机构往往需要在同一任务中同时使用商业云模型、本地托管模型和传统的基于规则系统。

这种环境有利于能够协调多个模型的平台。但由于责任跨越多个供应商和技术边界，也使问责变得更加困难。

安全政府 AI 智能体面临控制权取舍

OpenAI 和 NVIDIA 的合作为机构提供了有意义的灵活性，但灵活性并不会自动形成连贯的安全模型。

OpenAI 路径强调通过托管基础设施访问前沿模型。机构无需自行运营底层模型系统，便可获得更新后的能力。

这一路径可以降低技术负担，但也更加依赖服务边界、受支持的配置、保留政策，以及覆盖各组件的具体授权。

NVIDIA 路径提供了更强的本地控制力。Salesforce 表示，机构可以使用自身关键数据训练、调优和部署任务专用模型。

其更广泛的受监管部署蓝图将 NVIDIA 基础设施定位于 Agentforce、Data 360、Salesforce 应用和协作工具之下。

本地部署和私有云部署有助于满足数据驻留或网络隔离要求，也能支持无法与外部托管服务通信的工作负载。

这种控制力伴随着并未体现在产品价格中的成本。机构需要计算能力、模型工程师、评估流程、补丁管理和运营人员。

本地托管的模型仍可能产生错误输出，也仍可能获得过多权限，或基于不完整数据采取行动。

气隙部署降低了某些网络风险，但可能使更新和监控更加复杂。团队必须跨越受控边界传递软件、评估结果和安全修复程序。

托管模型则呈现相反的取舍。提供商可以更快地交付改进，但更新可能改变机构先前已评估的行为。

Salesforce 的编排层必须管理这两种模式。无论由哪一种模型进行推理，它都需要保留身份、政策、日志和操作控制。

这正是 Missionforce Policy Engine 成为一项有启发性的测试的原因。Salesforce 正在将生成式解读与确定性执行分离。

OpenAI 模型可以根据政策文本起草规则和测试用例。人工审核结果后，由获批的规则引擎执行。

这一流程承认了一项基本限制：语言模型仍具有概率性，这意味着相同的总体任务可能产生不同的措辞或推理路径。

确定性代码在获批后可提供更可预测的执行，但并不能保证原始解读正确无误。

政策文件可能包含例外、交叉引用、含糊定义或近期修订。将其转换为代码，可能会以更高的一致性保留其中的错误。

因此，所需的人工审查具有重要分量。政府机构需要既理解政策又理解生成式实现的审查人员。

它们还需要版本控制。政策变更时，团队必须知道当时启用了哪套规则、影响了哪些案例，以及由谁批准替换。

审计追踪有助于在决策发生后重建事件。但它无法在错误决策影响公民之前阻止它。

同样的区别也适用于运营型智能体。记录错误的调拨指令可以提供证据，但审批关口能够在库存移动前阻止该指令。

安全的政府 AI 智能体需要基于后果设置控制措施。检索内部指南不应与变更福利资格采用相同的审批流程。

Missionforce 的价值将取决于政府机构能否清晰表达这些差异。权限必须遵循具体任务、数据来源、用户和运营情境。

关于可信 AI 的宽泛承诺无法取代配置证据。采购方需要检查从用户请求到模型输出、再到最终系统操作的完整链路。

政策自动化让问责缺口更加明显

Missionforce 在政府工作缓慢且受规则约束的场景中最具价值，而这些场景中的自动化失误也可能立即造成伤害。

政策管理通常涉及文件、表单、资格标准、截止日期和申诉。这些特征使其适合进行结构化自动化。

但它们也让源材料变得复杂。政策可能来自法律、法规、机构指南、法院判决和临时指令。

AI 生成的规则可能看似精确，却遗漏重要例外。由同一模型生成的测试案例也可能重复同样的错误解读。

独立验证至关重要。政府机构应基于历史案例、边界条件和预期法律结果制定测试，而不应只依赖生成的示例。

人工审批是必要的，但并不充分。当系统生成精致的代码和看似合理的解释时，审查人员可能会过度信任它。

审查界面应显示每条规则的来源。它应将逻辑关联到确切的政策段落，并标记需要判断的解读。

这种可追溯性类似于维护良好的 AI 知识库。不同之处在于，政府系统需要正式授权、受控版本和可辩护的记录。

Salesforce 表示，Policy Engine 将为决策生成完整的审计追踪。但该公告尚未提供来自生产部署的独立证据。

它也未公布准确率、审查时间、申诉结果，或生成规则需要修正的频率。这些指标比演示速度更重要。

Medicaid 场景尤其需要谨慎对待。资格决策会影响医疗保障，而且政策适用方式可能因项目和司法辖区而异。

政府机构应明确何时将案例移出自动化流程并交给受过培训的工作人员。异常收入来源、存在争议的记录或相互冲突的家庭信息，都是明显的升级处理候选情形。

公民也需要易于理解的解释。一份技术上完整的日志未必能告诉家庭，为什么保障发生变化，或如何质疑该决定。

运营型智能体带来相关担忧。车队维护智能体可以减少搜索库存所花费的时间，但其建议依赖于准确的记录。

数据缺失可能导致系统分配不可用、受限制或已被分配到其他地方的零件。本地部署无法解决源数据质量差的问题。

现场智能体面临连接性和同步风险。离线工具必须在设备重新连接时正确协调更新。

应急行动会放大这些问题，因为工作人员在时间压力下工作。政府机构需要明确区分建议、获批操作和自主执行之间的边界。

Salesforce 的安全控制措施是答案的一部分。Agentforce 允许管理员定义允许的操作、数据访问权限和升级路径。

但治理必须延伸到平台配置之外。采购文件、操作程序、员工培训、事件响应和法律审查都会影响最终结果。

更广泛的军事 AI 市场说明了边界为何重要。一份关于机密 AI 扩张的独立报道提到，在自主或半自主任务中需要人工监督。

该示例涉及军事系统，但其原则适用范围更广。即使 AI 提供建议，具有重大后果的行动也需要明确责任归属。

Salesforce 政府 AI 将面临多方面审查。安全团队将检查架构，项目官员将要求提高效率，监督机构则会追问谁仍然承担责任。

成功部署必须同时满足这三方面要求。如果政府机构无法解释或捍卫由此产生的行动，更快的处理速度意义不大。

Salesforce 正在围绕模型之外的层面展开竞争

Missionforce 将政府 AI 的竞争转变为围绕数据访问、工作流控制和部署灵活性的竞争，而不只是模型排名。

OpenAI 提供先进的托管模型和熟悉的界面。NVIDIA 提供适用于更受控环境的模型技术和基础设施。

Salesforce 提供运营情境。其应用程序已在组织案例、关系、资产、服务请求及其他政府工作。

这种情境为智能体提供了有用的基础。基础化意味着向模型提供与当前任务相关、且已获授权的信息。

但这也会形成平台依赖。当数据、工作流逻辑、权限和智能体操作汇聚在单一供应商的架构中时，更换平台就会变得困难。

政府采购方需要制定可移植性计划。他们应确定规则定义、评估集、日志和智能体配置能否在不同环境之间迁移。

模型灵活性降低了一种形式的依赖。政府机构可以为一种工作负载选择 OpenAI 模型，为另一种选择 NVIDIA 模型。

然而，模型选择并不等于平台独立性。周边编排、数据连接和管理控制仍可能与 Salesforce 紧密绑定。

Amazon 同样占据重要位置，因为 Bedrock 提供了 OpenAI 模型与 Salesforce Government Cloud 之间的通路。这又增加了一道责任边界。

如果工作流失败，团队必须确定原因究竟位于机构数据、Salesforce 逻辑、Bedrock 交付、模型行为还是用户配置。

清晰的可观测性因此至关重要。管理员需要能够追踪：运行了哪个模型、它接收了什么情境、调用了哪些工具，以及后续采取了什么操作。

竞争对手可以从多个方向挑战 Salesforce。Microsoft 可以连接政府云基础设施、生产力应用和托管模型。

Google 可以将其模型与公共部门云服务和数据工具相结合。专业国防技术公司则可以聚焦于更狭窄的运营任务。

OpenAI 也可以深化其直接面向政府的合作关系。其联邦授权和政府产品降低了部分客户只能通过软件合作伙伴接触它的必要性。

NVIDIA 在多条路径上受益，因为其基础设施支持 Missionforce 之外的模型开发和部署。它不需要 Salesforce 赢得每一项政府工作负载。

Salesforce 的优势在于工作本已存在于其应用程序中时最为明显。案例管理团队从集成式智能体中获得的收益，可能大于从独立聊天机器人中获得的收益。

当权威数据分散在许多遗留系统中时，其挑战会加剧。安全连接这些系统所需的工作量可能超过配置模型本身。

这正是实施证据将变得重要的地方。政府机构需要生产案例证明，Missionforce 能够缩短处理时间，同时不增加更正或未解决例外情况。

公开案例研究应披露自动化的范围。它们应区分检索、建议、草稿生成和已完成的操作。

这些类别在智能体公告中经常被模糊处理。准备建议的助手，与获授权修改记录的智能体存在显著差异。

Salesforce Missionforce AI 智能体战略认识到，政府机构需要多个层级的自主性。其成功取决于能否让这些层级可见且可执行。

这比基准测试分数更具持久性的竞争衡量标准。模型会变化，但政府机构将持续需要围绕其数据和操作的可靠控制。

Missionforce 进入政府工作流时值得关注的事项

下一阶段的证据应来自获授权的生产部署、可量化的运营成果，以及对智能体行动边界的清晰界定。

第一个信号是产品可用性。Salesforce 描述了计划中的集成，其公告也警告称，可用性可能因地区和协议而异。

采购方应关注哪些 OpenAI 模型进入 Salesforce Government Cloud、哪些功能获得授权，以及 ChatGPT 何时能够触发 Missionforce 工作流。

确切范围至关重要。有限的文档助手并不能验证安全政府 AI 智能体执行多步骤工作的更广泛愿景。

第二个信号是生产表现。Salesforce 应公布来自政策、物流或现场部署的结果，并提供足够细节以便比较。

有用的衡量指标包括审查时间、例外率、规则更正、任务成功完成率，以及需要人工干预的操作数量。

面向公民的工作流还需要额外衡量指标。政府机构应跟踪申诉率、处理一致性、可访问性，以及解释是否有助于人们理解决定。

运营工作负载需要不同的证据。车队或采购团队应衡量停机时间、履约错误、重复订单，以及员工纠正智能体输出所花费的时间。

第三个信号是在真实压力下的治理。政府机构应披露，当模型更新、政策变更或数据错误影响活跃工作流时，它们如何应对。

成熟的系统应能识别受影响的决策、暂停高风险操作、恢复先前配置，并保留审查证据。

OpenAI 和 NVIDIA 也需要明确各自的责任。模型提供商、基础设施运营商、软件平台和政府机构不能各自假定由另一方承担最终风险。

Missionforce 背后的承诺在架构层面是可信的。不同模型可以在共同的工作流平台中服务于不同的安全和运营需求。

尚未解决的问题在于执行。Salesforce 已描述了组件、示例和预期的保障措施，但生产证据仍然有限。

政府技术领导者应从边界明确的任务开始。文档检索、草稿准备、库存匹配和排程，可以在智能体获得重大决策权之前暴露弱点。

团队还需要可搜索、受控的技术记录。可搜索知识库可以帮助实施团队保留评估、决策和事件发现。

目标不应是最大程度的自主性，而应是在政府机构能够测试、监控、解释和撤销的前提下，实现最高的有用自动化水平。

Salesforce 已将自己置于这一决策的核心位置。其与 OpenAI 和 NVIDIA 的合作拓展了可选方案，同时也让责任边界变得更加重要。

随着 Salesforce Missionforce AI agents 接入实时运行的政府系统，采购方应当提出一个务实的问题：每一项具有重大影响的行动，是否都能被追溯、质疑，并被安全地叫停？