Agent 一定要能改数据、发工单，才算有价值吗？Fabric Data Agent 选择了更窄的边界：生成并执行只读的 SQL、DAX 和 KQL 查询，把跨系统写操作留给外部编排。
身份先于查询
数据访问沿用用户的 Microsoft Entra ID 与数据权限。Agent 能看到 Schema，不代表用户能读数据；对 Power BI 语义模型的访问还受 Read 权限、RLS 和 CLS 约束。这使权限检查落在数据平台，而不是交给提示词判断。
不同资产走不同查询语言
Lakehouse、Warehouse 和 SQL Database 通过 SQL 查询；Power BI 语义模型使用 DAX；Eventhouse/KQL Database 使用 KQL。一个 Agent 可以组合多种来源，但语言路由只是第一步，跨源口径、粒度和时间仍需业务定义约束。
只读降低了什么风险
只读阻止 Agent 直接创建、更新或删除数据，也不会从 Eventhouse 触发 Notebook 或其他动作流。这减少了误操作的爆炸半径，并让分析组件更容易嵌入 Copilot Studio 等上层编排。
但只读不等于安全或正确。错误查询仍会误导决策，过宽权限仍会暴露数据，Purview DLP 也可能让结果被截断或阻断。当前聊天输出还有行列限制，不适合被当作完整数据导出接口。
生产设计的三个检查点
第一，验证用户身份和每个数据源的实际权限，而不是只看工作区角色。第二，为关键问题提供示例查询和语义说明，并记录生成查询。第三，把“分析建议”与“业务动作”分开：若外部 Agent 要据此写回系统，必须重新审批目标、参数与接收者。
Fabric 的只读路线说明，一个 Agent 不必包办闭环中的全部动作。把受治理问数做成可靠组件，再由显式编排承担写操作，往往比给同一个模型无限工具更容易审计。
只读 Agent 也需要回归集
可以从真实高频问题构造一组覆盖 SQL、DAX 和 KQL 的任务，记录预期数据源、关键筛选、行级权限和可接受的汇总结果。每次模型、语义模型或数据源结构变化后回放，重点检查错误路由、静默截断和权限差异，而不是只看自然语言答案是否流畅。
当一个问题跨越多个来源时，还要验证时间水位和粒度是否一致。例如实时事件与日级财务模型不能在没有说明的情况下直接合并。只读降低了写操作风险，却把“结果是否足以支持决策”的责任更清晰地留给评测和人工复核。