用 GitHub Action 让 AutoAgent 自动修 IssueOpenHands 集成实践指南【免费下载链接】AutoAgentAutoAgent: Fully-Automated and Zero-Code LLM Agent Framework项目地址: https://gitcode.com/GitHub_Trending/au/AutoAgentAutoAgentFully-Automated Zero-Code LLM Agent Framework是一套支持通过自然语言创建、编排和部署 LLM Agent 的开源框架。本指南所讲解的核心主题是如何借助OpenHands GitHub Action把自动解决 Issue的能力接入仓库既可以在 AutoAgent 自身的仓库内体验建 Issue → 机器人自动修复 → 提 PR的完整闭环也可以把它安装到任何第三方仓库让 LLM Agent 替你处理 bug 与功能请求。读完本文你将掌握fix-me标签与openhands-agent宏的触发机制、迭代式人机协同的修复工作流以及通过仓库机密Secrets与变量Variables做高级定制的全部配置方法。认识 OpenHands GitHub Action 与 AutoAgent 的关系OpenHands GitHub Action 是一个事件驱动的自动化入口它监听仓库中的 Issue 与 Pull Request 事件当检测到指定触发信号标签或宏评论时便启动一个 LLM 驱动的代理resolver读取 Issue 描述、相关评论与仓库上下文自主完成代码修改并提交 Pull Request。这一机制与 AutoAgent 的能力高度互补AutoAgent 负责造 AgentAutoAgent 的核心定位是让用户仅凭自然语言创建和定制自己的 Agent、工具与工作流详见 README.md并提供了诸如Github Agent这样的现成角色。OpenHands Action 负责跑 AgentAction 提供的是在 CI/CD 事件流中自动调度 Agent 解决问题的运行时管道。在 AutoAgent 仓库中你可以通过 github_agent.py 看到对 GitHub 自动化能力的原生封装它内置了push_changes与submit_pull_request两个工具函数遵循先推送变更、再询问是否提交 PR的标准流程。其中submit_pull_request的具体实现在 github_ops.py这与 OpenHands Action 自动解决 Issue 后提交 PR 的目标是殊途同归的——你可以把 GitHub Action 看作是这一能力的零代码部署版。在 AutoAgent 仓库中使用 Action要在仓库中启用 OpenHands GitHub Action操作非常轻量只需两步在仓库中创建一个 Issue清晰描述你希望代理解决的问题建议包含复现步骤、期望行为与当前行为。为 Issue 添加fix-me标签或在 Issue 中留下一条以openhands-agent开头的评论。一旦触发该 Action 会自动运行OpenHands 代理会分析 Issue 内容在沙箱环境中定位问题、修改代码、运行验证然后提交一个解决问题的 Pull Request 供你审查。说明本指南对应的原文档来自 OpenHands 项目文档体系并随 AutoAgent 仓库的文档目录一同维护。若你的仓库尚未安装该 Action请先参照下文完成安装再按上述步骤触发。在新仓库中安装 ActionOpenHands GitHub Action 的安装与配置遵循OpenHands Resolver的官方规范。通用安装流程包括在仓库的 GitHub Actions 工作流目录.github/workflows/中新建一个工作流文件如resolve-issues.yml。在工作流中引入 OpenHands Resolver Action并配置必要的事件监听如issues与issue_comment类型的事件。为工作流配置LLM_MODEL等环境变量或仓库机密详见下文自定义配置小节。将工作流提交推送到仓库后Action 即开始监听 Issue 事件。安装完成后你就可以按上一节的两步法触发自动修复了。具体的 Action 版本与参数细节以 OpenHands Resolver 的 README 为准。使用技巧迭代式人机协同解决 IssueOpenHands Action 不是一次性全自动的黑盒它设计了一套迭代式工作流让你能像带一名工程师一样逐步引导代理完成修复在仓库中创建一个 Issue描述问题。为 Issue 添加fix-me标签或留下以openhands-agent开头的评论触发首次自动修复。通过检查 Action 提交的 Pull Request审查代理解决问题的尝试——重点看 diff 是否精准、是否引入回归。通过一般评论、审查评论或内联线程评论提供反馈告诉代理哪里不对、应该如何调整。为 Pull Request 添加fix-me标签或通过以openhands-agent开头的评论触发代理针对你的反馈继续迭代修复。如此循环往复直到 PR 质量达到你的要求再自行合并或关闭。标签与宏两种触发语义理解fix-me标签与openhands-agent宏的区别是用好 Action 的关键标签fix-me请求 OpenHands 解决整个Issue 或 Pull Request。适用于这个问题你全权处理的场景代理会综合 Issue 描述、全部评论与相关上下文给出完整修复。宏openhands-agent请求 OpenHands仅考虑 Issue/PR 描述和特定评论。适用于只针对某条反馈做修改的精确定位场景可以避免代理被无关讨论干扰。触发方式作用范围适用场景fix-me标签整个 Issue / PR全权托管问题让代理做完整修复openhands-agent评论描述 特定评论针对某条反馈做定点迭代高级设置添加自定义仓库设置自定义指令默认情况下OpenHands 代理依据 Issue 描述与仓库上下文自行判断如何修复。如果你的项目有特殊的编码规范、构建命令或约束条件可以按照 OpenHands Resolver 的 README 中Providing Custom Instructions一节为代理提供自定义指令custom instructions。这些指令会作为系统提示注入代理从而让修复结果更贴合你的项目约定例如必须遵循的代码风格或目录结构修复后必须运行的具体测试命令禁止修改的文件或模块范围。自定义配置仓库机密与仓库变量GitHub resolver 启动时会自动检查仓库中有效的仓库机密Repository Secrets 或仓库变量Repository Variables并据此定制自身行为。你不需要修改工作流文件只需在仓库的Settings → Secrets and variables → Actions页面添加对应的键值即可。目前支持的自定义选项如下表所示属性名称类型用途示例LLM_MODELVariable设置与 OpenHands 一起使用的 LLMLLM_MODELanthropic/claude-3-5-sonnet-20241022OPENHANDS_MAX_ITERVariable设置代理迭代的最大限制防止代理无限循环或过度消耗 tokenOPENHANDS_MAX_ITER10OPENHANDS_MACROVariable自定义用于调用 resolver 的默认宏默认即openhands-agentOPENHANDS_MACROresolveitOPENHANDS_BASE_CONTAINER_IMAGEVariable自定义沙箱镜像为代理指定运行环境详见 custom-sandbox-guide.mdOPENHANDS_BASE_CONTAINER_IMAGEcustom_image各选项的实操要点LLM_MODEL决定代理的推理能力与成本。若未设置resolver 会回退到默认模型。示例中的anthropic/claude-3-5-sonnet-20241022采用provider/model的命名规范可替换为任何 OpenHands 支持的模型标识。OPENHANDS_MAX_ITER限制代理在单个任务中的最大执行迭代次数。数值过小可能导致修复不完整过大则会增加耗时与成本建议根据 Issue 复杂度从10起步逐步调整。OPENHANDS_MACRO允许你重命名触发宏。例如团队希望统一使用resolveit而不是openhands-agent时可在此配置。修改后评论必须以你自定义的宏开头才会触发代理。OPENHANDS_BASE_CONTAINER_IMAGE指定代理运行沙箱的基础镜像适用于项目依赖特定系统环境如特定 Python 版本、系统库或构建工具链的场景与 custom-sandbox-guide.md 中讲解的自定义沙箱思路一致。配置方式的注意事项机密 vs 变量若某些配置如 API Key 类敏感信息不应出现在公开日志中应优先使用 Secrets纯行为开关类配置则用 Variables 即可。优先级与生效时机resolver 在每次运行时读取配置修改后对下一次触发的任务立即生效无需重启或重新部署。命名必须精确属性名称区分大小写请严格按上表拼写否则 resolver 将无法识别。结合 AutoAgent 的落地实践结合 AutoAgent 的框架特性你可以将这套 GitHub Action 工作流进一步延伸用 AutoAgent 的Github Agent做人工辅助在fix-me全权托管之前可先用 Github Agent 的人工对话流程推送变更 → 确认是否提交 PR做精细修改再把批量、重复性的 Issue 交给 OpenHands Action 自动消化。善用OPENHANDS_MAX_ITER控制成本AutoAgent 的定位是高效、低成本的 Agent 编排建议在团队实践中结合 Issue 规模设定合理的迭代上限避免代理在简单问题上空转。与 AutoAgent 的沙箱机制对齐OPENHANDS_BASE_CONTAINER_IMAGE的自定义思路与 AutoAgent 文档中 custom-sandbox-guide.md 的自定义沙箱指南同源二者可以共享同一套镜像与依赖管理策略。小结通过本文你已掌握 OpenHands GitHub Action 在 AutoAgent 仓库生态中的完整用法两种触发方式fix-me标签处理整个 Issue/PRopenhands-agent宏处理描述与特定评论迭代解决闭环Issue → 自动修复 → PR 审查 → 评论反馈 → 再触发形成可收敛的人机协作循环四种高级配置LLM_MODEL、OPENHANDS_MAX_ITER、OPENHANDS_MACRO、OPENHANDS_BASE_CONTAINER_IMAGE全部通过仓库机密与变量即可完成无需改动工作流代码。这套机制让提一个 Issue睡一觉醒来就有 PR成为现实是把 LLM Agent 接入日常开发流程的零代码起点。【免费下载链接】AutoAgentAutoAgent: Fully-Automated and Zero-Code LLM Agent Framework项目地址: https://gitcode.com/GitHub_Trending/au/AutoAgent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
用 GitHub Action 让 AutoAgent 自动修 Issue：OpenHands 集成实践指南
用 GitHub Action 让 AutoAgent 自动修 IssueOpenHands 集成实践指南【免费下载链接】AutoAgentAutoAgent: Fully-Automated and Zero-Code LLM Agent Framework项目地址: https://gitcode.com/GitHub_Trending/au/AutoAgentAutoAgentFully-Automated Zero-Code LLM Agent Framework是一套支持通过自然语言创建、编排和部署 LLM Agent 的开源框架。本指南所讲解的核心主题是如何借助OpenHands GitHub Action把自动解决 Issue的能力接入仓库既可以在 AutoAgent 自身的仓库内体验建 Issue → 机器人自动修复 → 提 PR的完整闭环也可以把它安装到任何第三方仓库让 LLM Agent 替你处理 bug 与功能请求。读完本文你将掌握fix-me标签与openhands-agent宏的触发机制、迭代式人机协同的修复工作流以及通过仓库机密Secrets与变量Variables做高级定制的全部配置方法。认识 OpenHands GitHub Action 与 AutoAgent 的关系OpenHands GitHub Action 是一个事件驱动的自动化入口它监听仓库中的 Issue 与 Pull Request 事件当检测到指定触发信号标签或宏评论时便启动一个 LLM 驱动的代理resolver读取 Issue 描述、相关评论与仓库上下文自主完成代码修改并提交 Pull Request。这一机制与 AutoAgent 的能力高度互补AutoAgent 负责造 AgentAutoAgent 的核心定位是让用户仅凭自然语言创建和定制自己的 Agent、工具与工作流详见 README.md并提供了诸如Github Agent这样的现成角色。OpenHands Action 负责跑 AgentAction 提供的是在 CI/CD 事件流中自动调度 Agent 解决问题的运行时管道。在 AutoAgent 仓库中你可以通过 github_agent.py 看到对 GitHub 自动化能力的原生封装它内置了push_changes与submit_pull_request两个工具函数遵循先推送变更、再询问是否提交 PR的标准流程。其中submit_pull_request的具体实现在 github_ops.py这与 OpenHands Action 自动解决 Issue 后提交 PR 的目标是殊途同归的——你可以把 GitHub Action 看作是这一能力的零代码部署版。在 AutoAgent 仓库中使用 Action要在仓库中启用 OpenHands GitHub Action操作非常轻量只需两步在仓库中创建一个 Issue清晰描述你希望代理解决的问题建议包含复现步骤、期望行为与当前行为。为 Issue 添加fix-me标签或在 Issue 中留下一条以openhands-agent开头的评论。一旦触发该 Action 会自动运行OpenHands 代理会分析 Issue 内容在沙箱环境中定位问题、修改代码、运行验证然后提交一个解决问题的 Pull Request 供你审查。说明本指南对应的原文档来自 OpenHands 项目文档体系并随 AutoAgent 仓库的文档目录一同维护。若你的仓库尚未安装该 Action请先参照下文完成安装再按上述步骤触发。在新仓库中安装 ActionOpenHands GitHub Action 的安装与配置遵循OpenHands Resolver的官方规范。通用安装流程包括在仓库的 GitHub Actions 工作流目录.github/workflows/中新建一个工作流文件如resolve-issues.yml。在工作流中引入 OpenHands Resolver Action并配置必要的事件监听如issues与issue_comment类型的事件。为工作流配置LLM_MODEL等环境变量或仓库机密详见下文自定义配置小节。将工作流提交推送到仓库后Action 即开始监听 Issue 事件。安装完成后你就可以按上一节的两步法触发自动修复了。具体的 Action 版本与参数细节以 OpenHands Resolver 的 README 为准。使用技巧迭代式人机协同解决 IssueOpenHands Action 不是一次性全自动的黑盒它设计了一套迭代式工作流让你能像带一名工程师一样逐步引导代理完成修复在仓库中创建一个 Issue描述问题。为 Issue 添加fix-me标签或留下以openhands-agent开头的评论触发首次自动修复。通过检查 Action 提交的 Pull Request审查代理解决问题的尝试——重点看 diff 是否精准、是否引入回归。通过一般评论、审查评论或内联线程评论提供反馈告诉代理哪里不对、应该如何调整。为 Pull Request 添加fix-me标签或通过以openhands-agent开头的评论触发代理针对你的反馈继续迭代修复。如此循环往复直到 PR 质量达到你的要求再自行合并或关闭。标签与宏两种触发语义理解fix-me标签与openhands-agent宏的区别是用好 Action 的关键标签fix-me请求 OpenHands 解决整个Issue 或 Pull Request。适用于这个问题你全权处理的场景代理会综合 Issue 描述、全部评论与相关上下文给出完整修复。宏openhands-agent请求 OpenHands仅考虑 Issue/PR 描述和特定评论。适用于只针对某条反馈做修改的精确定位场景可以避免代理被无关讨论干扰。触发方式作用范围适用场景fix-me标签整个 Issue / PR全权托管问题让代理做完整修复openhands-agent评论描述 特定评论针对某条反馈做定点迭代高级设置添加自定义仓库设置自定义指令默认情况下OpenHands 代理依据 Issue 描述与仓库上下文自行判断如何修复。如果你的项目有特殊的编码规范、构建命令或约束条件可以按照 OpenHands Resolver 的 README 中Providing Custom Instructions一节为代理提供自定义指令custom instructions。这些指令会作为系统提示注入代理从而让修复结果更贴合你的项目约定例如必须遵循的代码风格或目录结构修复后必须运行的具体测试命令禁止修改的文件或模块范围。自定义配置仓库机密与仓库变量GitHub resolver 启动时会自动检查仓库中有效的仓库机密Repository Secrets 或仓库变量Repository Variables并据此定制自身行为。你不需要修改工作流文件只需在仓库的Settings → Secrets and variables → Actions页面添加对应的键值即可。目前支持的自定义选项如下表所示属性名称类型用途示例LLM_MODELVariable设置与 OpenHands 一起使用的 LLMLLM_MODELanthropic/claude-3-5-sonnet-20241022OPENHANDS_MAX_ITERVariable设置代理迭代的最大限制防止代理无限循环或过度消耗 tokenOPENHANDS_MAX_ITER10OPENHANDS_MACROVariable自定义用于调用 resolver 的默认宏默认即openhands-agentOPENHANDS_MACROresolveitOPENHANDS_BASE_CONTAINER_IMAGEVariable自定义沙箱镜像为代理指定运行环境详见 custom-sandbox-guide.mdOPENHANDS_BASE_CONTAINER_IMAGEcustom_image各选项的实操要点LLM_MODEL决定代理的推理能力与成本。若未设置resolver 会回退到默认模型。示例中的anthropic/claude-3-5-sonnet-20241022采用provider/model的命名规范可替换为任何 OpenHands 支持的模型标识。OPENHANDS_MAX_ITER限制代理在单个任务中的最大执行迭代次数。数值过小可能导致修复不完整过大则会增加耗时与成本建议根据 Issue 复杂度从10起步逐步调整。OPENHANDS_MACRO允许你重命名触发宏。例如团队希望统一使用resolveit而不是openhands-agent时可在此配置。修改后评论必须以你自定义的宏开头才会触发代理。OPENHANDS_BASE_CONTAINER_IMAGE指定代理运行沙箱的基础镜像适用于项目依赖特定系统环境如特定 Python 版本、系统库或构建工具链的场景与 custom-sandbox-guide.md 中讲解的自定义沙箱思路一致。配置方式的注意事项机密 vs 变量若某些配置如 API Key 类敏感信息不应出现在公开日志中应优先使用 Secrets纯行为开关类配置则用 Variables 即可。优先级与生效时机resolver 在每次运行时读取配置修改后对下一次触发的任务立即生效无需重启或重新部署。命名必须精确属性名称区分大小写请严格按上表拼写否则 resolver 将无法识别。结合 AutoAgent 的落地实践结合 AutoAgent 的框架特性你可以将这套 GitHub Action 工作流进一步延伸用 AutoAgent 的Github Agent做人工辅助在fix-me全权托管之前可先用 Github Agent 的人工对话流程推送变更 → 确认是否提交 PR做精细修改再把批量、重复性的 Issue 交给 OpenHands Action 自动消化。善用OPENHANDS_MAX_ITER控制成本AutoAgent 的定位是高效、低成本的 Agent 编排建议在团队实践中结合 Issue 规模设定合理的迭代上限避免代理在简单问题上空转。与 AutoAgent 的沙箱机制对齐OPENHANDS_BASE_CONTAINER_IMAGE的自定义思路与 AutoAgent 文档中 custom-sandbox-guide.md 的自定义沙箱指南同源二者可以共享同一套镜像与依赖管理策略。小结通过本文你已掌握 OpenHands GitHub Action 在 AutoAgent 仓库生态中的完整用法两种触发方式fix-me标签处理整个 Issue/PRopenhands-agent宏处理描述与特定评论迭代解决闭环Issue → 自动修复 → PR 审查 → 评论反馈 → 再触发形成可收敛的人机协作循环四种高级配置LLM_MODEL、OPENHANDS_MAX_ITER、OPENHANDS_MACRO、OPENHANDS_BASE_CONTAINER_IMAGE全部通过仓库机密与变量即可完成无需改动工作流代码。这套机制让提一个 Issue睡一觉醒来就有 PR成为现实是把 LLM Agent 接入日常开发流程的零代码起点。【免费下载链接】AutoAgentAutoAgent: Fully-Automated and Zero-Code LLM Agent Framework项目地址: https://gitcode.com/GitHub_Trending/au/AutoAgent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考