Uno Platform 认为，使用 AI 代理构建跨平台 .NET 应用时，最大的问题不在于编写代码，而在于了解应用运行后代码是否按预期工作。代理可能生成一个能够编译和构建的设置页面，但其中可能存在只有在实际应用中才会显现的布局或行为错误。
为了解决这一缺口，Uno Platform 使用 Microsoft 与社区共同开发的官方 MCP C# SDK 包，以 C# 构建了两个服务器。第一个服务器专注于提供知识和文档，第二个服务器则将代理连接到一个实际运行的应用，使代理能够运行、检查并与应用交互。
两个服务器、两项任务和不同的时间周期
Uno Platform 在设计上的基本决定，是将“什么应该是正确的？”与“现在发生了什么？”这两个问题分开。文档服务器处理的是平台发布更新或页面修改时会变化的信息，而应用服务器处理的是应用运行期间不断变化的特定运行会话状态。
文档服务器以无状态 HTTP 方式公开托管在 mcp.platform.uno/v1 地址。它提供搜索官方文档和以 Markdown 格式获取完整页面的工具，同时提供与正在运行的应用协作的规则，以及使用常见 Uno Platform API 的规则。此外，它还包含两个提示词：/new，用于按照当前最佳实践创建应用；以及 /init，用于初始化与现有代码库相关的对话。
根据所发布的实践，托管该服务器的好处在于，只需更新一个文档页面，就能在代理下次调用服务器时反映给代理，而不必将指南嵌入需要重新发布版本的 NuGet 包中。
应用服务器则作为 .NET 工具通过开发者设备上的 stdio 运行，并将代理连接到 Uno DevServer。这是一个面向单个会话的有状态服务器。它可以在启用 Hot Reload 的调试模式下运行应用，捕获屏幕截图，提取可视元素树的 XML 表示，然后执行点击、按键、文本输入以及调用自动化元素操作。
验证界面需要的不只是屏幕截图
Uno Platform 认为，可视元素树工具是验证循环中最重要的部分。屏幕截图可以帮助代理发现某些东西看起来不对，而元素树则会揭示导致问题的元素及其属性。用实际的说法来说：像素适合发现问题，结构适合诊断问题，而代理需要两者。
平台建议在可能的情况下使用 uno_app_element_peer_action，而不是通过 uno_app_pointer_click 进行坐标点击，因为坐标点击会受到窗口尺寸和像素密度差异的影响，而自动化操作则与元素本身相关。平台将这一建议放入工具描述中，而不是放在代理可能不会加载的独立文档中，因为工具描述会直接影响选择决策。
借助这些工具，代理可以修改界面，然后重新加载应用、捕获屏幕、读取可视树、执行交互流程，并在交付更改前确定结果是否符合要求。Uno Platform 将这种方法比作用于 Web 应用的 Playwright 工具，但其目标是运行在 Windows、macOS、Linux、iOS、Android 和 WebAssembly 上的原生 .NET 应用。
工具成本是上下文设计的一部分
这一实践引起了人们对 MCP 讨论中经常被忽视的一个实际限制的注意：工具定义会在提出任何问题之前消耗模型的上下文窗口。Uno Platform 提到，文档服务器消耗约 6.4 千个 token，而应用服务器消耗约 1.5 千个 token。作为对比，同一会话中集成的 GitHub MCP 服务器约消耗 5.2 千个 token。
因此，工具描述不只是技术文档；根据该材料，它还是一种会影响代理选择工具方式的引导或提示。由此可见，应使名称、描述和输入架构简洁且信息密度高，并将重要的操作偏好写入模型在做决策时会读取的位置。
这对开发者实际上意味着什么？
Uno Platform 不仅提供单独的工具，还增加了其称为 Skills 的内容。这些是有组织的流程，规定何时使用工具、以何种顺序使用，以及任务完成意味着什么。该库涵盖 MVUX、状态、数据源、导航、样式、Uno Toolkit 元素和测试等场景，其中包括名为 uno-testing-ui 的 Skill，用于通过应用服务器自动化界面测试。
这一架构结合了最新文档、可供检查的实时应用以及预先定义的工作流程。平台表示，这些组件支持 Uno Platform Studio 3.0，该工具可以完全在浏览器中创建跨平台 .NET 应用。这一过程依赖 Microsoft Agent Framework 进行规划和执行，并依赖 Roslyn 工作区进行编译、加载程序集、解析 NuGet 更改以及将结果重新加载到正在运行的应用中。
certi.news 的编辑解读：这一实践的实际价值并不在于增加另一个编写代码的代理，而在于将代理从文本生成器的角色转变为能够查询最新知识源，并在真实应用面前测试其产出的参与者。两个服务器的分离也为其他 MCP 项目提供了可适用的设计原则：将长期知识与运行状态分开，并根据部署架构而非形式偏好选择 HTTP 或 stdio。
不过，材料并未证明这种方法消除了人工审查的需要，也未保证应用在所有情况下都正确。它展示的是 Uno Platform 的实践和工具，并未提供关于错误发现率或代码质量的独立测量结果。此外，工具定义的成本，以及应用服务器对 Uno DevServer 和本地会话的依赖，仍然是团队在采用这一模式前应评估的实际限制。