Google 于 2026 年 9 月 15 日宣布，Gemini in Workspace 可通过 MCP 集成访问 Asana、Atlassian Rovo、HubSpot、Mailchimp、QuickBooks、Monday 和 Salesforce。管理员可控制连接器的启用与访问。企业可以据此设计跨系统查询，但应逐项确认实际开放的工具动作。Google Workspace 公告
一个常见需求是“查某项目的商机、执行进度和开票情况”。这些数据往往分布在 CRM、项目工具和财务系统中。连接器提供访问通道，业务对象如何对应仍需要企业定义。
查询问题的拆分
先把自然语言问题拆成对象、期间、指标和用途。查询项目进度时，应说明是合同交付进度、任务完成比例还是开票进度。三个数字可以放在同一份简报里，但不能直接互相替代。
| 业务问题 | 主要来源 | 需要保留的条件 |
|---|---|---|
| 商机是否已成交 | CRM | 商机阶段与更新时间 |
| 项目是否可交付 | 项目工具 | 验收节点与阻塞事项 |
| 是否已经开票 | 财务系统 | 发票状态与作废情况 |
| 营销是否有响应 | 营销工具 | 活动、渠道和统计期间 |
问题中没有明确期间时，应先补充，或者在结果中清楚显示采用的时间范围。
对象编号的映射
同一家企业在不同系统中可能有简称、英文名和历史名称。可靠关联应使用已确认的编码关系，并保留来源系统与对象编号。名字相近只能成为候选，不能自动当作同一对象。
示例：CRM 中的采购方对应项目系统里的两个独立项目，财务系统又按不同签约主体开票。查询时应先明确目标合同或项目，再汇总关联记录。按企业名称直接合计，可能把不同项目的金额混在一起。
数据时点与完整性
每个来源应显示最近查询或更新时点。若某个连接器返回失败，结果应说明缺失部分，不能用其他系统的数据推算补齐。例如项目进度可见，但发票系统不可用时，应保留“开票情况未取得”。
对同步型连接器，还要区分同步时间与原记录修改时间。刚完成一次同步不代表源记录刚被业务人员更新，两个时间应分别理解。
访问范围的验证
选择不同岗位账号测试同一个问题，核对各自能看到的记录范围。部门负责人能看汇总，普通成员只能看分配给自己的对象时，AI 结果也应保持相同边界。
不要用管理员账号测试通过后，就默认普通员工同样可用。正式试用应覆盖实际使用者的权限、授权状态和连接器配置。失效授权应有清晰提示和恢复方式。
一份可用的跨系统简报
建议输出对象名称与编号、各系统事实、差异、缺失资料和需要人员判断的事项。对金额和日期附来源链接，便于进一步核查。模型推断应与系统事实分开，不把“可能延误”写成已经确定的延期。
查询结果若要转成业务动作，例如更新阶段或发催办，应走独立确认和权限检查。拥有读取能力并不意味着拥有写入权限。
