路径类型 是做什么的？
在定义新类型时应用此指南。仅在明确请求时更改现有代码，并保持编辑最小且适中。将这些规则视为持续迁移的目标状态；如果难以符合，请询问用户如何继续。
- 在 app-server 协议类型中，使用
LegacyAppPathString以在 URI 迁移期间保持向后兼容。在协议边界处，将其转换为PathUri，并在内部使用PathUri。对于主机本地逻辑（例如某些配置值），改用AbsolutePathBuf或PathBuf。 - 在 exec-server 协议类型中，使用
PathUri。在内部，酌情使用PathUri或AbsolutePathBuf。 - 在两个服务器共享的依赖项中，使用
PathUri或解耦其用例的独立 API。 - 模型预期生成的工具调用参数应反序列化为常规
String，并附带特定功能的路径处理代码。
迁移要求
在迁移代码以符合上述指南时，请牢记以下要求：
- 现有 app-server 客户端继续发送和接收遗留本机路径字符串
- app-server 可以保留和操作跨平台路径 URI
- exec-server API 使用 file:// URI
- 本地操作不得改变模型可见文本
- 模型工具参数可能包含任意操作系统的原始相对或绝对路径
- 路径推理必须在相关环境上线之前工作
- URI 不能显式编码执行器的路径约定或操作系统
- 用户不得显式配置环境的操作系统/路径约定
- URI 不应存储在回滚、数据库或其他持久存储中
- 路径转换错误：对于安全相关路径失败闭合，对于 UI/诊断失败开放
- 优先使用
PathUri或LegacyAppPathString上小而专注的方法，而非局部辅助函数 - 在诊断中将
PathUri值表示为 URI
只要能为真实用户做正确的事情，路径与 URI 之间的转换有一定损失是可以接受的。
迁移到 URI 不应增加显著的新故障模式。我们需要在以前无故障的地方显示错误，但应保持最少。