前言¶

做 Dynamics 365 CE / Dataverse 项目的团队，日常卡顿通常不是写不出代码，而是拿不到环境信息：这个解决方案导到 SIT 会不会压掉别的方案的定制，某个字段被哪些表单和视图引用，两个环境的同一张表单为什么不一样，这次 MR 部署到 UAT 会不会出事。在自己电脑上跑脚本、翻 Power Platform 管理中心，或者手写 Power Platform CLI 命令，都属于「能做但很碎」。

下面介绍的 dsh-d365-kit 是维护者 iTanzhao 发布的一个 DeepSeek Harness（DSH）插件 bundle，专门把这些查询交给 DSH 智能体去做。它默认只读，未授予能力时智能体只能看、不能改。

这是什么¶

一句话定位：dsh-d365-kit 是 Dynamics 365 CE / Dataverse 的开发与部署助手，以 DSH bundle 形式安装，把一个真实的 D365 组织变成智能体可以直接查询的对象——元数据、解决方案分层、快照差异、引用关系、迁移风险、代码改动影响，以及受控制的写入。

用户提供 URL、租户、ClientId 和 secret，插件通过 Dataverse 接口访问环境；智能体看到的是结构化的工具调用结果，而不是需要人肉解析的网页或导出文件。

README 里给的定位是十五个工具、一个设置页，只读为默认。

核心功能¶

连接与环境¶

元数据与解决方案分层¶

• d365_metadata：覆盖 19 种资源类型，包括实体、属性、关系、表单、视图、工作流、业务规则、插件、Web 资源、解决方案、组件、Custom API、站点地图、选项集。
• d365_layers：读取 msdyn_componentlayer，回答某个组件被哪些解决方案覆盖、哪一层在最上面、当前生效的是哪一层。

快照与差异¶

• d365_sync：把环境的元数据拉成本地快照，逐个资源记录「complete / truncated / failed」。
• d365_diff：两个快照之间的字段级差异（新增、删除、修改），带噪声过滤和过期快照提醒。

影响分析与数据¶

• d365_refs：反向查找。字段指向哪些表单/视图/流程，Web 资源被哪些表单和事件引用，程序集对应哪些类型和步骤。
• d365_data：业务记录的 count / group by / sample，需要 data.read 能力。
• d365_data_write：创建或更新单条业务记录，对话中确认后才执行，需要 data.write 能力。

写入¶

d365_write 支持新增、更新、删除选项值和字段，重命名表，增删系统视图列。plan-* 动作只产出计划，execute 需要人工确认，事后有可查询的审计记录。

迁移与检查¶

• d365_migrate：解决方案迁移风险评估，覆盖分层遮蔽、缺失组件、选项值丢失、版本和 managed 状态。
• d365_contract：合约矩阵与漂移，比较程序集、插件类型、步骤、表单库、handler、站点地图、选项值，支持豁免和趋势。
• d365_code_check：读取 GitLab MR，把 JS / C# 改动映射到目标环境，报告 blocker / warning / 需人工确认。JS 改动对应到 Web 资源和表单，C# 改动对应到程序集/类型/步骤/图像。

运维¶

d365_reports：本地产物和磁盘占用，按保留策略清理（默认 dry run），快照压缩。

设置页¶

DSH Web UI 的「设置 → D365 Toolkit」，共六个标签页：

• Environments：环境清单、连接测试、默认环境
• Permissions：按环境勾选能力（读业务数据 / 各类写入）、变更使用的解决方案、复制到其他环境
• Plans：待确认的写入计划、近期变更记录和发布结果（可重新发布）
• Data：各类产物的文件数、大小、保留策略，dry run 与清理，快照压缩
• GitLab：仓库地址、默认项目、只读 token（read_api）
• General：保留快照数、默认行数上限、请求超时

界面语言跟随 DSH（中/英）。环境清单和 d365_configure 走同一套存储代码，因此界面显示和智能体读取的结果一致。

安装与启用¶

前置条件：DSH 桌面端；能访问 *.dynamics.com；一个只读应用用户（ClientId + secret）。

# 从 npm 安装（最短路径，可升级；包发布后可用）
plugin_manager install_bundle target="dsh-d365-kit@0.22.1"

# 从 Git 安装（不需要 registry，可固定 tag）
plugin_manager install_bundle target="git+https://<your-git>/<group>/dsh-d365-kit.git#v0.22.1"

# 从本地目录安装（link 模式，代码改动立即生效）
plugin_manager install_bundle target="D:\path\to\dsh-d365-kit"

dsh-d365-kit@<版本> 从 npm registry 解析；单独的 GitHub 仓库要用 git+https:// 形式。仓库自带 .github/workflows/publish.yml，配置好 NPM_TOKEN 后，推 v* tag 就会发布到 npm。

装完重启一次 DSH，让 Web 客户端把设置页代码加载进模块图。然后在 设置 → D365 Toolkit → Environments 里添加环境（key、URL、tenant、ClientId、secret），测连接后保存。默认只读；需要读业务记录时，在 Permissions 下勾「Read business data」。

典型用法¶

1. 部署前评估解决方案¶

What are the risks of shipping this solution to SIT and UAT?

d365_migrate action=assess source=dev solution=ContosoBase targets=["sit","uat"]

报告回答：目标环境是否已有该解决方案、源版本是否更高、每个组件上谁的层会压住谁（列出被遮蔽的解决方案）、选项集是否会丢值。结果落在 .d365/reports/migration-*.md。

2. 这个字段能不能删¶

Who else still uses account.contoso_customertier? Also check how many records carry a value.

d365_refs   kind=field entity=account attribute=contoso_customertier
d365_data   action=group entity=account field=contoso_customertier

3. 两个环境为什么不同¶

d365_sync environments=["dev","sit"]
d365_diff base=dev head=sit resources=["forms","views","attributes"]
d365_layers component=Account componentType=SystemForm

先拉两个环境的快照，再做字段级差异，最后看这个组件被谁覆盖。

4. MR 能不能上 UAT¶

d365_code_check mergeRequest="https://gitlab.example.com/contoso/powerapps/-/merge_requests/7759/diffs" targets=["uat"]

适用场景与注意¶

适合已经在用 DSH、并且需要频繁跨环境对比和评估 D365 方案的人：解决方案分层遮蔽判断、字段删除前的影响面、跨环境差异定位、MR 部署前检查、上下游插件注册漂移。

几点需要留意：

1. 插件以当前 DSH 进程的权限运行，安装前应检查源码（仓库为 MIT License，可直接看）和许可证，确认没有超出预期的读取范围。
2. 写入类能力默认不授予，需要显式在 Permissions 里勾选，而且 execute 要人工确认。请把只读凭据和写入凭据分开管理。
3. 元数据拉取和业务数据读取受网络与行数上限影响，快照可能被标记为 truncated，发布前先看 d365_sync 的记录状态。
4. 联网工具的可用性取决于 *.dynamics.com 的网络通路和凭据有效性。

结尾¶

dsh-d365-kit 的价值在于把 D365 环境里那些需要反复人工查询的信息变成智能体可调用的工具，并且把写操作挡在人类确认之后。功能面较广，实际用起来通常从只读诊断开始。

目录页：https://www.skillhub.cn/plugins/iTanzhao/dsh-d365-kit

GitHub：https://github.com/iTanzhao/dsh-d365-kit