Automation

1. 引言 微软的UFO（UI-Focused Agent，后续发展为UFO²，即Desktop AgentOS）项目代表了在自然语言驱动的桌面自动化领域的一项重要进展 1。该项目旨在通过深度操作系统集成和多智能体协作，将用户通过自然语言表达的复杂任务转化为跨应用程序的、可靠的自动化工作流 1。最初的UFO项目于2024年2月发布，专注于Windows操作系统的UI自动化，利用GPT-Vision等大型语言模型（LLM）的能力，通过双智能体框架观察和分析GUI信息，实现跨应用的导航和操作 3。随着2025年4月UFO²的提出，该项目演进为一个更为宏大的“桌面操作系统智能体”（Desktop AgentOS）概念，强调更深层次的操作系统集成、原生API调用与GUI操作的混合、以及通过持续学习和投机性多动作执行提升效率和鲁棒性 1。 本报告旨在深度剖析微软UFO项目，从其核心目标、关键特性、系统架构、关键技术实现、到社区反馈和未来展望，提供一个全面而深入的分析。 2. 项目概述与核心目标 UFO项目的核心目标是赋能用户通过自然语言指令，在Windows操作系统上实现复杂、跨应用的自动化任务 1。它不仅仅局限于传统的UI层面自动化，而是力求构建一个能够理解用户意图、智能编排多个应用程序以达成目标的“桌面智能体操作系统” 1。 最初的UFO版本专注于利用大型视觉语言模型（如GPT-Vision）来理解和操作Windows应用程序的图形用户界面（GUI）3。其设计理念是通过模拟人类用户观察屏幕、思考决策、执行操作的过程，将繁琐耗时的手动任务转变为简单的自然语言指令即可完成的自动化流程 4。 随着UFO²的提出，这一目标得到了进一步的深化和扩展。UFO²旨在成为一个系统级的自动化平台，其关键特性包括： 深度操作系统集成 (Deep OS Integration): 结合Windows UI Automation (UIA)、Win32和WinCOM技术，实现对控件的精准检测和原生命令的执行 1。这种集成是UFO区别于仅依赖截图和模拟点击的早期计算机使用智能体（CUA）的关键，它为智能体提供了更丰富、更可靠的与操作系统及应用程序交互的手段。 混合GUI与API操作 (Hybrid GUI + API Actions): 智能体能够根据情况选择最优的交互方式，优先使用速度更快、更稳定的原生API；当API不可用时，则回退到模拟点击和键盘输入等GUI操作 1。这种混合策略兼顾了效率和通用性。 持续知识基底 (Continuous Knowledge Substrate): 通过检索增强生成（RAG）技术，融合离线文档、在线Bing搜索结果、用户演示以及历史执行轨迹，使智能体能够持续学习和进化 1。这意味着UFO不仅仅是一个执行器，更是一个能够积累经验、适应新情况的学习系统。 投机性多动作执行 (Speculative Multi-Action): 将多个预测的后续操作步骤捆绑在一次LLM调用中，并进行实时验证，从而显著减少LLM查询次数（据称可达51%），提升执行效率 1。这对于依赖LLM进行决策的智能体系统而言，是降低延迟、提高响应速度的关键优化。 UIA与视觉控制检测 (UIA + Visual Control Detection): 采用UIA和计算机视觉相结合的混合管线，以检测标准控件和自定义控件 1。这增强了智能体对各种复杂界面的适应能力。 画中画桌面 (Picture-in-Picture Desktop) (即将推出): 允许自动化任务在一个隔离的虚拟桌面中运行，用户的主屏幕和输入设备不受干扰 1。这一特性对于提升用户体验至关重要，它使得自动化过程和用户的日常工作可以并行不悖。 UFO的应用场景广泛，包括但不限于自动化办公套件中的重复性任务、简化涉及Web浏览器的流程（如数据录入、表单填写）、以及基于自然语言指令创建自定义的跨应用工作流 1。 3. 系统架构 UFO²的架构设计体现了其作为“桌面智能体操作系统”的理念，其核心是一个多智能体框架 2。 核心组件: 组件名称 描述 来源 HostAgent (主控智能体) 解析用户的自然语言目标，启动必要的应用程序，创建并协调AppAgent，管理全局有限状态机（FSM）以控制任务流程。 2 AppAgent (应用智能体) 每个应用程序对应一个AppAgent。每个AppAgent运行一个ReAct（Reasoning and Acting）循环，具备多模态感知、混合控制检测、检索增强知识以及通过Puppeteer执行器选择GUI或API操作的能力。 2 Knowledge Substrate (知识基底) 融合离线文档、在线搜索结果、用户演示和执行轨迹，构建一个向量存储，在推理时按需检索。 2 Puppeteer Executor (操纵执行器) 集成在AppAgent内部，负责在GUI操作（如点击、输入）和原生API调用之间做出选择并执行。 5 Speculative Executor (投机执行器) 通过预测一批可能的动作并在一次调用中针对实时UIA状态进行验证，从而大幅减少LLM的调用延迟。 1 FollowerAgent (跟随智能体) 继承自AppAgent，用于执行用户提供的明确指令序列，常用于软件测试等场景。 5 EvaluationAgent (评估智能体) 用于评估一个会话或一轮任务的完成情况。 5 数据流: ...

什么是Langchain？ LangChain 为开发者提供了一个强大的框架，用于快速构建和部署复杂的基于语言模型的应用程序，满足了需要集成多种语言处理功能至一体化解决方案的需求。 LangChain 的 PMF： 核心用户和使用场景：LangChain 设计用于简化使用语言模型进行应用开发的过程。它特别适合于需要将多个语言技术集成到一起的开发者和企业，例如集成聊天机器人、自动内容生成工具等。 市场需求：随着 AI 和机器学习技术的发展，市场上对于能够简化和加速语言模型应用开发的工具的需求持续增长。LangChain 通过提供一个结构化的方式来组合不同的语言能力（如理解、生成、概括等），满足了这一需求。 竞争优势：LangChain 的优势可能在于其框架的灵活性和扩展性。对开发者而言，这意味着可以用较少的代码实现更复杂的语言处理任务，这是其吸引用户的一个关键因素。 用户反馈和市场接受程度：衡量 PMF 的一个重要方面是用户的反馈和产品的市场接受程度。如果 LangChain 的用户基础持续增长，且用户反馈积极，那么可以认为它在实现良好的产品市场契合度方面是成功的。 LangChain简化了LLM应用程序生命周期的每个阶段： 开发：使用 LangChain 的开源构建块和组件构建您的应用程序。使用第三方集成和模板开始运行。 生产化：使用 LangSmith 检查、监控和评估您的链，以便您可以充满信心地持续优化和部署。 部署：使用 LangServe 将任何链转变为 API。 langchain 框架组成 具体来说，该框架由以下开源库组成： langchain-core ：基础抽象和LangChain表达式语言。 langchain-community ：第三方集成。 合作伙伴包（例如 langchain-openai 、 langchain-anthropic 等）：一些集成已进一步拆分为自己的轻量级包，仅依赖于 langchain-core 。 langchain ：构成应用程序认知架构的链、代理和检索策略。 langgraph：通过将步骤建模为图中的边和节点，使用 LLMs 构建健壮且有状态的多角色应用程序。 langserve：将 LangChain 链部署为 REST API。 更广泛的生态系统： ...

Go 源码里的这些 go: 指令 && go 自动化工具 开发人员有很强的自动化重复性任务的倾向，这也适用于编写代码。 样板代码可能包括设置基本文件结构、初始化变量、定义函数或导入库或模块等操作。 在某些情况下，包提供样板代码作为开发人员构建的起点，通常是在代码行为配置之后生成。 尽管样板代码对于应用程序功能可能是必要的和有价值的，但它也可能是浪费和冗余的。出于这个原因，有许多工具可以最小化样板代码。 go generate 是Go编程语言的命令行工具，允许自动生成代码。您可以使用 go generate 为您的项目生成易于修改的特定代码，使该工具在减少样板文件方面功能强大。 go generate 这个命令通常用于在编译前自动生成代码。它可以用来创建那些重复性高或者模式化的代码，从而节省时间和减少错误。想想看，这在哪些情况下会特别有用呢？🤔 比如说下面有一个简单的例子，在代码中： //go:generate echo Hello, cubxxw ! 在这个例子中，当我们运行 go generate 命令时，它将执行注释中指定的命令。在这个例子里，它会打印出 “Hello, cubxxw !"。 因此，元编程(metaprogramming)的主题是一个开发和研究的热门领域，可以追溯到 1960 年代的 Lisp。元编程中一个特别有用的领域是代码生成(code-generation)。支持宏的语言内置了此功能;其他语言扩展了现有功能以支持这一点。 go:generate 在我们之前的讨论中，我们已经介绍了 “Go Generate” 命令的基础知识。现在，我们将深入探讨一些更具体的用例和实践技巧。🚀 让我们从一些术语开始。go generate 工作方式主要由三个参与者之间协调进行的： Generator：是由 go generate 调用的程序或脚本。在任何给定的项目中，可以调用多个生成器，可以多次调用单个生成器等。 Magic comments：是 .go 文件中以特殊方式格式化的注释，用于指定调用哪个生成器以及如何调用。任何以文本 //go:generate 行开头的注释都是合法的。 go generate : 是 Go 工具，它读取 Go 源文件、查找和解析 magic comments 并运行指定的生成器。 需要强调的是，以上是 Go 为代码生成提供的自动化的全部范围。对于其他任何事情，开发人员可以自由使用适合他们的任何工作流程。例如，go generate 应该始终由开发人员手动运行; 它永远不会自动调用(比如不会作为 go build 的一部分)。此外，由于我们通常使用 Go 将二进制文件发送给用户或执行环境，因此很容易理解 go generate 仅在开发期间运行(可能就在运行 go build 之前);Go 程序的用户不会知道哪部分代码是生成的以及如何生成的。(实际上，很多时候会在生成的文件开头加上注释，这是生成的，请别手动修改。) ...

云原生领域中GitHub开源Go项目的自动化测试实践与策略 介绍 作为 Github 上的 热门项目 OpenIM，如何在云原生时代中创造出价值，这是非常重要的，OpenIM 是一个优质的小团队，我们在自动化中并没有特别深入的见解。 使用 GitHub Actions 进行持续集成和持续交付 (CI/CD): GitHub Actions 提供了一个平台，可以自动构建和测试 Go 语言项目。通过配置 GitHub Actions 工作流，你可以在代码更改时自动运行测试，确保代码的质量和功能 。 KubeVela 项目实践: KubeVela 是一个 Go 语言的云原生和开源项目，它展示了如何在云原生环境中组织 CI/CD 过程，包括自动化测试。KubeVela 使用声明性工作流来协调 CI/CD 过程，你可以参考 KubeVela 的 GitHub 仓库来理解和应用这些实践3 4 [5](https://github.com/kubevela/workflow#:~:text=KubeVela Workflow is an open,engine in your own repository)。 云原生测试框架与工具: 在云原生开发中，合约测试（Contract Testing）是一种常见的测试实践，它确保服务间的通信符合预定义的 API 协议。例如，Cloud-Native Toolkit 中使用 Pact 进行合约测试。通过编写和集成测试，你可以验证服务间的通信是否符合预期6 。 代码覆盖率检查: 在进行自动化测试时，检查代码覆盖率是一个好的实践。许多测试框架内置了代码覆盖率检查功能，可以配置它们来报告测试的代码覆盖率。例如，使用 SonarQube 工具来读取和报告代码覆盖率信息6 。 利用开源工具和框架: 你可以利用开源工具和框架来进行测试，例如使用 Cypress 进行云原生应用的测试[7](https://dev.to/litmus-chaos/cloud-native-application-testing-automation-2bh5#:~:text=Cloud Native Application %26 Testing,Testing Using Cypress for)。还有其他的项目和资源，例如在 GitHub 上的 learning-cloud-native-go/myapp 仓库，提供了云原生 Go 项目的完成示例，你可以参考这些示例来理解和应用云原生测试实践[8](https://medium.com/learning-cloud-native-go/lets-get-it-started-dc4634ef03b#:~:text=The completed project can be,The completed API)。 自定义自动化测试流程: 通过结合 GitHub Actions 和开源工具，你可以定制项目的 CI/CD 流程，包括自动化测试和验证步骤9 。 自动化测试的价值量化 自动化很明显，是后期的手动成本很低，也就是说，随着时间的推移，自动化运行的次数增多，自动化的价值 ROI 变高 ...

DevOps DevOps 🔥 DevOps是一种软件开发和运营的文化和方法论，旨在通过自动化和协作来缩短软件开发周期和提高软件质量。 DevOps（Development和Operations的混成词 ）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 为什么 OpenIM 需要 DevOps？ 我想用一句话来概括，DevOps 能解决 OpenIM 当前的团队管理，能高效组织团队，并且能通过 自动化 工具协作于沟通。 从而实现用更少的浪费、更频繁的交付更稳定的产品。 最开始的 OpenIM 是什么样子的？ 找到了之前的一个很古老的版本，链接是：https://github.com/OpenIMSDK/Open-IM-Server/tree/test-tuoyun 几乎存在 commit 信息丢失，因为信息不全导致代码无法跟踪问题，导致文档缺失，代码不规范等一系列的问题。 我们跨越了从原始社会到传统的协作方式，再到后面的 devops 为什么说及时到现在，我依旧没有将 OpenIM 转变为 devops，一个很明显的判断标准，每一次运维和交互工作依旧需要我手动去做，无疑是区分了 dev 和 ops 的职责。不仅仅让成本变高，效率变低，更重要的是团队没有了更清晰的定位。 那么我后面的计划如何？ 不管是 prow, actions, 等等 CI 工具，以及各种 ops（gitops, aiops, chatops,） 也不管是各种设计的 自动化 以及 自动化管理工具，自动化交互工具。 无疑他们是一套体系： 提供无感知的开发环境，无论交付是否频繁，每一个 feature 的 PR 都能快速的，规范并且经过大量自动化测试，更加快速上线，也能更快地响应客户需求。每一次发布的变更变少，所以风险，以及合并的冲突，工作量就变少。而且代码 code review 更方便，代码质量和团队水平提升很高的档次。 🔥 OpenIM 当时我的设计理念是 main 分支作为一个类似于传统的 dev 分支，保证代码的最新以及基本可靠，release-v* 分支作为稳定的分支。 DevOps 最重要的就是自动化，和自动化运维。非常鼓励自动化，甚至可以让开发者即使不会任何运维也能去走整套自动化的流程。 ...

创建 actions actions 是可以联合收割机以创建作业和自定义工作流的单个任务。您可以创建自己的操作，或使用和自定义GitHub社区共享的操作。 可以通过编写自定义代码来创建操作，这些代码可以以您喜欢的任何方式与您的存储库进行交互，包括与GitHub的API和任何公开可用的第三方API集成。 可以编写自己的操作以在工作流中使用，或与GitHub社区共享您构建的操作。要与所有人共享您构建的操作，您的存储库必须是公共的。 操作可以直接在机器上或Docker容器中运行。您可以定义操作的输入、输出和环境变量。 可以构建Docker容器、JavaScript和复合操作。操作需要一个元数据文件来定义操作的输入、输出和主入口点。元数据文件名必须为 action.yml 或 action.yaml 。有关更多信息，请参阅“GitHub操作的元数据语法。“ docker 容器操作 Docker容器用GitHub Actions代码打包环境。这创建了一个更加一致和可靠的工作单元，因为操作的使用者不需要担心工具或依赖项。 Docker容器允许您使用特定版本的操作系统、依赖项、工具和代码。对于必须在特定环境配置中运行的操作，Docker是理想的选择，因为您可以自定义操作系统和工具。 对操作进行发布管理 如果您正在开发供其他人使用的操作，我们建议使用发布管理来控制分发更新的方式。 用户可以期望操作的修补程序版本包括必要的关键修复程序和安全修补程序，同时仍与其现有工作流保持兼容。每当您的更改影响兼容性时，您应该考虑发布新的主版本。 在这种发布管理方法下，用户不应该引用操作的默认分支，因为它可能包含最新的代码，因此可能不稳定。 相反，您可以建议用户在使用您的操作时指定一个主要版本，并且仅在遇到问题时才将他们引导到更具体的版本。 要使用特定的操作版本，用户可以配置他们的GitHub操作工作流，以针对标签，提交的SHA或以发布命名的分支。 使用标签进行发布管理 我们建议使用标签进行操作发布管理。使用此方法，您的用户可以轻松区分主版本和次版本： 在创建发布标签（例如 v1.0.2 ）之前，在发布分支（例如 release/v1 ）上创建并验证发布。 使用语义版本控制创建发布 文件列表的右侧，单击Releases 页面顶部，单击草拟新版本。 要为发布选择标签，请选择选择标签下拉菜单。 如果您创建了一个新标签，请选择目标下拉菜单，然后单击包含您要发布的项目的分支。 在“描述此版本”字段中，为您的版本键入描述。如果您在描述中 @mention 任何人，发布的版本将包含一个贡献者部分，其中包含所有提及用户的头像列表。或者，您可以通过单击生成发行说明自动生成发行说明。 或者，要在您的版本中包含二进制文件（例如已编译的程序），请在二进制文件框中拖放或手动选择文件 或者，选择设置为最新版本。如果不选择此选项，将根据语义版本控制自动分配最新版本标签。 如果您准备好发布您的版本，请单击发布版本。要稍后处理该版本，请单击保存草稿。然后，您可以在存储库的发布提要中查看已发布或草稿的发布。有关详细信息，请参阅“查看存储库的版本和标签 ”。 移动major version标签（例如 v1 、 v2 ），指向当前版本的Git ref。例如： git tag -a v1.4 -m "my version 1.4" 引入新的主要版本标记（ v2 ），用于将破坏现有工作流的更改。例如，更改操作的输入将是一个突破性的更改。 主要版本最初可以使用 beta 标签发布，以指示其状态，例如 v2-beta 。 -beta 标签可以在准备好时移除。 带有查询参数的发布表单自动化 要通过使用自定义信息自动填充新发布表单来快速创建发布，您可以将查询参数添加到发布表单页面的 URL。 ...