敏感任务如何让智能体默认走内部模型：按智能体与会话路由 Provider
企业不必在“所有任务都使用内部模型”和“所有任务都交给第三方 API”之间二选一。xAgent 可以为敏感任务创建一个默认使用内部模型的智能体，再让该智能体创建的会话使用对应模型配置：通用任务使用外部模型，受限任务默认使用指向内网服务的模型配置。模型配置决定最终 Provider，因此两类任务会进入不同的模型通道。
这是一种面向特定数据边界的智能体搭建方式，不替代智能体管理中的通用创建说明，也不是一个自动覆盖所有数据流的绝对安全承诺。下面说明这条边界如何建立、怎样验证，以及还需要控制什么。
不要把所有任务放进同一条模型通道
许多团队都同时面对两类任务：
- 日常写作、公开资料整理、一般代码辅助等任务，希望利用第三方 LLM API 的能力和弹性。
- 合同、客户材料、内部经营数据、未公开方案等任务，希望模型请求只到达公司控制的模型服务。
如果只配置一个默认模型，用户需要靠记忆判断什么能发给外部模型。这既容易出错，也无法让不同任务获得合适的能力组合。
更可维护的做法是按任务边界准备不同的模型配置和智能体入口。例如：
| 任务入口 | 选择的模型配置 | 最终 Provider 通道 | 适用材料 |
|---|---|---|---|
| 通用研究助手 | general-external | 第三方 LLM API | 公开资料、非敏感日常任务 |
| 机密资料处理助手 | confidential-internal | 公司内网的自建模型或内部模型网关 | 受限业务材料 |
| 临时敏感会话 | confidential-internal | 公司内网的自建模型或内部模型网关 | 一次性的保密分析 |
表中的名称只是示例。关键不是名称本身，而是每个模型配置都明确对应一个 Provider 类型、Base URL、凭据、真实模型名和能力声明。
三层配置如何形成 Provider 路由
在 xAgent 中，智能体和会话并不直接保存一段 Provider 地址或 API Key。它们选择的是一个模型配置名称，服务端再根据该名称找到对应的 Provider client。这样，凭据和网络地址仍留在管理员配置中，不会被写进智能体提示词或会话内容。
| 层级 | 保存什么 | 作用 |
|---|---|---|
| 模型配置 | 模型名、Provider 类型、Base URL、密钥、能力和默认策略 | 定义模型请求最终发往哪里，以及该模型能做什么 |
| 智能体定义 | 角色、Skill、Tool 和默认模型配置 | 为某类业务准备可复用的能力与路由基线 |
| 会话 | 当前模型配置和会话级策略 | 让一次具体任务在后续模型请求中使用选定通道 |
选择带模型配置的智能体创建会话时，xAgent 会把该模型配置展开到新会话的运行元数据中。后续模型请求按会话当前模型配置路由。会话也可以独立选择模型配置，适合在不新建智能体的情况下处理一次临时敏感任务。
这让“能力隔离”和“模型通道隔离”可以一起设计：机密资料处理助手不仅默认走内部模型，还可以只携带完成该任务所需的 Skill 和 Tool；通用助手则保留面向日常工作的外部模型和能力组合。
上图中的“默认模型”列表来自管理员已经保存的模型配置。选择其中一个名称，是让该智能体创建的会话以对应模型配置作为默认路由；Provider 地址和密钥仍由服务端模型配置保存，不会出现在智能体提示词中。
一个可复查的配置流程
1. 先配置两类模型，而不是只改默认模型
管理员至少准备一条通用模型配置和一条内部模型配置。内部模型可以是公司部署的 OpenAI-compatible 服务、内网模型网关或其他公司控制的 Provider。
为每条配置完成连接测试，并如实标记聊天、文件、视觉、流式输出和 Tool Calling 能力。能力开关必须与实际模型相符，不能为了方便全部开启。
详细字段与连接测试见模型配置和模型要求。如果还没有准备服务端、HTTPS、访问控制和运行环境，先完成私有化部署 AI Agent。
2. 为受限业务创建专用智能体
创建“机密资料处理助手”时，至少明确四件事：
- 默认模型配置选择内部模型。
- 角色说明限定可处理的业务范围与输出要求。
- 只绑定完成任务必需的 Skill 和 Tool。
- 不把密码、API Key 或原始机密材料写进智能体说明。
这一步把“遇到敏感材料时应该用哪个模型”从用户的临时判断，变成一个可复用的任务入口。关于入口、个人与公共范围的管理方式，见智能体管理。
3. 在会话层保留任务级选择
会话级模型配置适合两种情况：
- 某个通用智能体临时要处理一项受限材料；在新会话开始前选择内部模型配置。
- 同一任务的后续阶段确实需要不同模型能力；在确认材料边界后，切换后续请求使用的模型配置。
模型切换从后续模型请求开始生效，不会改写已经发出的请求或已经完成的 Tool 调用。关于这一运行时边界，见任务执行中动态切换模型、Skill 与提示词。
必须用运行证据验证，而不是只看配置页面
模型配置显示为“内部”不等于路由一定正确。上线前应使用不含真实敏感信息的测试材料，完成一次可审计的验证：
- 用机密资料处理助手创建新会话，并提交带有唯一测试标识的材料。
- 在 xAgent 运行记录中确认该会话实际使用的模型配置。
- 在内部模型网关或自建模型服务日志中确认收到相同测试标识的请求。
- 同时检查外部 Provider 网关、出口代理或防火墙日志，确认没有相同请求。
- 再分别测试附件读取、Tool 调用、子会话和后续追问，而不是只测第一轮对话。
记录测试时间、会话 ID、模型配置名、内部网关请求 ID 和网络审计结果。这样讨论的不是“理论上应该路由到哪里”，而是这次真实任务实际走了哪一条通道。
当前边界：默认路由不等于强制数据驻留
这是最容易被忽略的一点。当前智能体的模型配置会作为创建会话时的默认值带入，会话又支持在高级设置中调整后续模型。因此，Agent 或会话级模型选择可以建立清晰的默认 Provider 通道，但不能单独证明用户永远无法切换到外部模型。
同样，模型请求走内部 Provider 也不代表所有数据天然留在公司内：
- MCP、Tool、Connector 或网络请求可能把参数和结果发送给外部系统。
- 文件型模型能力可能把文件上传到所选 Provider；内部模型服务本身也必须在公司受控网络内。
- 其他系统级角色、自动化任务和集成应分别检查其模型与网络配置。
- 审批只决定 xAgent 是否执行某个动作，不替代外部系统的数据权限或企业网络控制。
因此，受限数据场景需要把模型路由放进更完整的控制组合：受限智能体的模型允许列表或锁定策略、最小化 Tool 集合、外部网络出口控制、外部动作审批、Provider 与网关审计，以及对 Connector/MCP 的逐项检查。审批的当前职责和边界见AI Agent 审批与安全控制。
什么时候可以说“机密数据不出公司”
只有在以下条件都经过验证后，才适合使用这个更强的表述：
- 敏感会话不能改用未获准的外部模型配置。
- 所有可能处理材料的模型、文件服务和后台任务都在受控环境内，或有明确的数据处理协议与出口限制。
- Tool、MCP、Connector 和网络访问按数据分类受到限制或审批。
- 内部模型网关、出口网络和任务记录能够提供可追溯的路由证据。
在达到这些条件之前，更准确的表述是：该智能体或会话的模型请求默认路由到内部 Provider。 这已经是一个有价值的能力，但不应被夸大成完整的数据防泄漏体系。
常见问题
模型配置和 Provider 是同一个概念吗？
不是。模型配置是 xAgent 内部用于选择模型的稳定名称，其中包含 Provider 类型、服务地址、凭据和能力等信息。智能体或会话选择模型配置，服务端再用它找到最终 Provider client。
如何搭建一个默认使用内部模型的智能体？
先由管理员创建并测试内部模型配置；然后在智能体管理中创建或复制一个面向受限任务的个人或公共智能体，选择该模型配置作为默认模型，并只保留任务必需的 Skill 和 Tool。用它创建新会话后，再用不含真实敏感信息的测试材料核对内部网关和出口日志。通用创建入口见智能体管理，模型字段见模型配置。
选择机密资料处理助手后，所有内容都会自动留在公司吗？
它会让会话默认使用该智能体配置的内部模型通道，但还要检查会话是否允许切换模型，以及任务使用的 Tool、MCP、Connector、文件能力和网络出口。仅靠模型路由不能替代完整的数据驻留控制。
会话运行中能切换模型吗？
可以。保存新的会话模型配置后，后续模型请求会使用新配置；已经发出的请求不会被中途替换。敏感业务如不应允许切换，需要额外的模型锁定和权限控制。