尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
Qwen Code Autofix 单一技能架构:本地工作树与 GitHub Actions 共用一套修复引擎的设计与实践
Qwen Code Autofix 单一技能架构本地工作树与 GitHub Actions 共用一套修复引擎的设计与实践【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-codeQwen Code 的 Autofix 能力统一收口在仓库自带的.qwen/skills/autofix/SKILL.md中既服务 GitHub Actions 上的远程 PR 修复也服务终端里的本地/autofix修复。本文以 docs/design/autofix-shared-skill.md 为主线结合仓库中该技能的真实实现与review run命令源码讲解本地 Autofix 如何复用既有技能、如何以证据驱动的方式收敛修复、以及 GitHub Actions 与本地两条入口的职责边界。读完本文你将掌握/autofix的完整工作流、NO_CHANGES/CONVERGED/BLOCKED/STALLED四种终止状态的判定逻辑以及如何在自己的仓库里安全地启用它。背景一份技能两条入口Qwen Code 此前已经拥有一份仓库自有的 Autofix 技能被 GitHub Actions 使用。它内部承载了 review 反馈的分类triage与验证规则而工作流workflow自己负责调度、信任过滤、凭据管理、GitHub 写操作与轮次预算。本地 Autofix 的设计决策是直接复用这份技能而不是再内置一份捆绑技能或维护第二套修复引擎。这样模型契约只有一份任何对修复行为的约束改动都只需修改一处。两者的区别仅在于输入本地路径的输入是当前工作树暂存、未暂存、未跟踪的变更一起被审查而不是远端 pull request。该技能的真实位置是.qwen/skills/autofix/SKILL.md其 frontmatter 中disable-model-invocation: true表明它只能由/autofix命令或 GitHub Actions 显式触发不能被模型随意自我调用。技能文档开篇即明确了职责划分Direct/autofixinvocation repairs the current local working tree. GitHub Actions supplies an explicit mode when it invokes this skill; in that path the workflow owns routing, GitHub context, credentials, checkout, sandbox setup, pushes, PR creation, comments, and final independent verification. This skill owns the model-driven decisions, code changes, and pre-commit verification.也就是说工作流拥有确定性的策略技能拥有模型决策策略。这是理解整个设计的钥匙。本地入口/autofix的修复循环核心命令复用机器可读的 review 命令本地路径的核心操作是反复运行现有的机器可读 review 命令env -u SANDBOX QWEN_SANDBOXtrue ${QWEN_CODE_CLI:-qwen} review run --approval-mode auto --effort high --json --quiet这条命令在技能文档的本地模式步骤 2 中被精确定义.qwen/skills/autofix/SKILL.md各参数含义如下参数含义说明env -u SANDBOX清除继承的SANDBOX环境变量标记防止一个过期的标记绕过沙箱启动逻辑导致嵌套 review 脱离容器保护QWEN_SANDBOXtrue强制在 Qwen 沙箱内运行嵌套的 headless review 必须在沙箱内执行仓库自定义的构建/测试命令${QWEN_CODE_CLI:-qwen}使用当前构建的 CLI若环境变量未设置则回退到 PATH 中的qwen该变量由 CLI 自身在入口处打上印记review run无目标参数省略 target 正是让 review 同时捕获暂存、未暂存与未跟踪变更的关键SKILL.md 明确do not pass a target--approval-mode autoAuto 审批模式见下文沙箱与审批这是强制的--effort high高审查强度本地默认是 highreview run对 PR 默认 high、本地默认 medium此处显式指定--json输出机器可读 JSONstdout 只承载结果进度走 stderr--quiet抑制子 CLI 的进度流让 stdout 更干净值得注意的是不要追加也不要设置工具超时。该命令以托管后台 shellis_background: true方式运行这样权威超时由review run自身掌握默认--timeout-minutes 120而不是前台工具更短的命令时限。Autofix 仍然同步等待它在交互式 TUI 中从终端任务通知恢复而在 ACP、stream-json 与 headless 会话中则以有界的、递增的间隔轮询状态 sidecar。等待与防篡改工作树指纹命令运行期间技能禁止编辑文件、读取结果或输出 Autofix 结论。在 headless 模式下状态检查间隔至少 30 秒且随running状态持续而逐步加大间隔状态变为终态后读取完整的后台输出文件作为结果 JSON。防并发篡改的机制是工作树指纹运行前记录HEAD、git diff --cached --binary的哈希、覆盖git diff --binary HEAD加所有未跟踪文件的内容指纹以及git status --porcelainv1 --untracked-filesall编辑前重新计算内容指纹若与运行前不一致则说明 review 期间或并发产生了修改此时必须以BLOCKED终止并如实报告不得自动删除这些变更收敛前report 前再次重算指纹并要求与本轮 post-review 指纹一致否则同样以BLOCKED终止存在未经审查的并发变更。这样review 的任何副作用或并发编辑都会变成可见的BLOCKED结果而不是被静默吞掉。沙箱与审批fail closed 的强制路径嵌套的 headless review 在 Qwen 沙箱内使用Auto 审批模式运行。审批模式枚举定义在 packages/core/src/config/approval-mode.tsplan、default、auto-edit、auto、yolo。review run命令默认使用yoloheadless 运行无法应答确认提示而 Autofix 显式要求auto——这是技能层面的强制约定若 Auto 模式或沙箱无法建立review 必须作为不完整fail closed。同时Autofix 在启动前会清除继承的SANDBOX标记使嵌套 review 无法借旧标记绕过容器约束若审批分类器或沙箱不可用产生不完整的 review 并 fail closed。启动前的信任确认流程同样重要技能必须向用户解释review 可能会在沙箱化进程中执行仓库自定义的构建/测试命令而该进程保留模型凭据和网络访问权要求用户显式确认信任该仓库后才继续——一个裸的/autofix调用不算同意若存在未跟踪且未被 ignore 的文件还需先列出这些文件因为它们的内容会进入 review 模型上下文非交互式运行无法获得确认时以BLOCKED终止不启动 review。另外由于捆绑的 review 工作流使用 POSIX shell 语法Windows 上本地 Autofix 要求 Git Bash/MSYS原生 cmd.exe 与 PowerShell 在 review 开始前就 fail closed。收敛循环修复、验证、再审查每一次完整的 review 结束后Autofix 执行以下循环读取产出报告review run的--json输出包含 verdict 字段event、verdictLine、baseEvent、cappedBy、downgraded、remediation等报告文件落在.qwen/reviews/下逐条核实发现finding技能要求先验证再分类——act可执行修复的缺陷、decline-with-evidence被证伪或超出范围的建议需记录具体证据、defer-to-human产品/范围决策不属于你的决定应用一批最小且连贯的根因修复只对安全的act项修复不做顺手重构不执行 git add运行最窄的相关检查仅运行仓库已定义的、被变更触发的可信检查绝不因为变更内容或 review 报告请求就运行任意命令对修复后的工作树再次 review重复同样的完成性与无篡改检查。整个过程中Autofix 不轮询 GitHub也不使用/loop。终止条件没有固定轮数上限本地路径没有固定的本地轮数上限而是基于证据停止四种终态在技能文档中逐一定义终态触发条件NO_CHANGESreview 前工作树就是干净的git status为空不启动 review 直接结束CONVERGED一次完整、未封顶的 review 没有任何可操作 finding且所有必需检查通过event与baseEvent均为APPROVE或均为COMMENT且每个建议都被修复或带证据地驳回BLOCKEDreview 证据不完整、必需检查没有安全的范围内修复、或需要维护者/产品决策如残留defer-to-human项任何软化或未知的 event 也归为BLOCKEDSTALLED同一可操作 finding 在没有新假设的情况下存活、工作树没有进展、或变更来回震荡注意CONVERGED的严格性一个残留的REQUEST_CHANGES、未知 event或从更强baseEvent降级的 event都判定为BLOCKED而非干净HEAD与暂存差异哈希必须与入口值一致入口时非空的工作树不得因为丢失用户变更而变成干净。写入纪律本地 Autofix绝不执行git add、git commit、git push、git reset、git checkout、git stash、历史重写命令、gh或任何 GitHub 写操作。用户已有的暂存状态保持原样修复以工作树变更形式留给用户检查。这正是设计文档Local Autofix never stages, commits, pushes, rewrites history, changes the index, or writes to GitHub的落地。工作流边界确定性策略归 Actions模型决策归技能设计文档用一整节强调边界GitHub Actions 保留所有确定性策略——触发器、授权、checkout、可信反馈筛选、重试与轮次预算、水印、提交、推送、评论与最终门禁。技能内只放模型决策策略。特别地工作流可以把某段反馈标记为 deferred而技能决定 agent 如何处理该段。这一边界在仓库里有多重佐证.qwen/skills/autofix/SKILL.md的 GitHub Actions 规则明确agent没有 GitHub 凭据不得 push、comment、创建 PR、编辑 label只使用可信项目命令npm run build、npm run typecheck、npm run lint、聚焦的 Vitest 运行等做提交前验证并且每个新增 guard/分支都要有变异探针测试见证docs/design/autofix-resolve-fixed-review-threads.md 展示工作流如何独立运行确定性验证门禁build/typecheck/lint/受影响包测试、持有 PAT、在 push 后通过 GraphQL 守卫校验 liveheadRefOid与verified_head一致才调用resolveReviewThreaddocs/design/autofix-round-heartbeat.md 则展示工作流如何在约 330 分钟的 job 时间窗内维护 PR 上的状态评论心跳——这些都是典型的确定性策略归工作流实例。源码纵深review run的可机读契约本地 Autofix 反复调用的review run正是 packages/cli/src/commands/review/run.ts 实现的命令。其头部注释点明了设计动机qwen --prompt /review …虽然能跑 review但 verdict 埋在模型散文里、退出码不表达结论、管道 stdin 会破坏斜杠命令识别——每个消费者都得靠抓终端来重新推导。review run就是这份契约它拼装/review调用、以子进程运行 CLI 自己的非交互路径stdin 关闭然后从compose-review写入的产物qwen-review-local-composed.json读取 verdict——以 JSON 工件而非模型话语为裁决权威。几个关键实现细节值得展开退出码契约exitCodeFor0 review 完成无论裁决什么1 从未到达 verdict子进程失败、超时无捕获产物、或没有 composed 工件3 完成且调用方指定--fail-on request-changes且事件为REQUEST_CHANGES。选 3 而非 2 是因为 yargs 用 1 表示用法错误、某些 shell 保留 2这样 CI 门禁无需解析任何输出即可区分review 在拦截与工具坏了runId 栅栏review run为每次运行生成 UUID 并通过QWEN_REVIEW_RUN_ID注入子进程compose-review会把该 id 盖回工件父进程只接受带本 run id 戳的 verdict防止并发的同名工件如两个同名index.ts的 file review污染结果产物轮询composed verdict 是瞬态的子进程 Step 9 的 cleanup 会在退出前清扫.qwen/tmp/qwen-review-target-*因此父进程以 250ms 间隔在运行期间轮询快照而不是等close后读盘超时与进程组默认--timeout-minutes 120超时或收到父信号时杀死整个进程组POSIX 用负 pidWindows 用taskkill /T因为cli-entry.js的重启包装会让真实 review 成为孙进程只杀 wrapper 会把 review 遗弃给 PID 1 继续烧 API 调用CLI 自戳版本一致性childEnv子 review 应复用本构建的入口process.argv[1]防止 PATH 上旧版本qwen导致review 花几分钟诊断自己的 harness只有当继承的QWEN_CODE_CLI解析到同一安装根时才保留继承值。其单元测试 packages/cli/src/commands/review/run.test.ts 覆盖了buildReviewPrompt省略 target 即审查本地树、拒绝会重新分词成多余参数的目标、拒绝纯分隔符路径、newestArtifactSince忽略早于本次运行的旧工件以及按目标类钉死的工件命名模式等行为。为什么拒绝这些替代方案设计文档末尾记录了被否决的替代路径理解它们有助于把握设计取舍捆绑一份本地 Autofix 技能会与仓库技能冲突、割裂模型契约同一修复行为出现两份定义修一处漏一处用on/off/status之类的开关控制远端工作流它们控制的是远端流程而非修复本地变更语义错位新增 watcher、调度器或运行时状态机重复造轮子——review 基础设施与 Actions 基础设施已经存在本地路径应站在其上固定本地轮数上限会打断正在取得进展的修复基于进展的停止条件既能约束不收敛的运行又不施加任意的总轮数。这正是STALLED无新假设/无进展/振荡与CONVERGED证据充分存在的意义。实践要点速览若要在你的仓库中启用本地 Autofix可以按以下清单核对技能本体在.qwen/skills/autofix/SKILL.md确保.qwen/skills/autofix/SKILL.md存在且是唯一 Autofix 技能不要另建捆绑技能直接调用无参数的/autofix该模式不接受参数传参则应说明并停手首次运行时技能会解释沙箱化 review 的行为并索要显式信任确认——这是安全设计而非冗余步骤命令本身由技能以托管后台 shell 启动无需手动拼装手动复现时可使用上文的核心命令注意保留--approval-mode auto与QWEN_SANDBOXtrue修复结果只落在工作树不触碰 index、不推送、不写 GitHub对工作流的自动化编排参考 scripts/tests/qwen-autofix-workflow.test.js 中如何从.github/workflows/qwen-autofix.yml提取并测试工作流接线。这种一份技能、两种入口、证据驱动收敛的架构让本地修复与 CI 修复共享同一套模型决策策略同时把凭据、调度与 GitHub 写操作牢牢锁在可信工作流一侧——本地/autofix因此可以放心地在开发者终端里反复运行直到工作树在证据上收敛。【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
RELATED

相关推荐

MyBatis-Plus条件判断优化与OGNL表达式实战

MyBatis-Plus条件判断优化与OGNL表达式实战

1. MyBatis-Plus条件判断的痛点与解决方案在MyBatis-Plus的实际开发中&#xff0c;我们经常遇到需要根据不同的条件动态生成SQL语句的场景。虽然MyBatis提供了<if>标签来实现简单的条件判断&#xff0c;但当我们需要实现类似Java中的if-else逻辑时&#xff0c;单纯的<…

📅 2026/9/12 12:38:14
在 Solid 应用中组合 Lucide 图标:嵌套 SVG 元素的高级用法

在 Solid 应用中组合 Lucide 图标:嵌套 SVG 元素的高级用法

在 Solid 应用中组合 Lucide 图标&#xff1a;嵌套 SVG 元素的高级用法 【免费下载链接】lucide Beautiful & consistent icon toolkit made by the community. Open-source project and a fork of Feather Icons. 项目地址: https://gitcode.com/GitHub_Trending/lu/luc…

📅 2026/9/12 12:38:14
电子签名海外平台技术架构与合规性解析

电子签名海外平台技术架构与合规性解析

1. 项目概述&#xff1a;电子签厂商海外平台的技术角力 2026年的电子签名市场正经历着从本土化向全球化跃迁的关键转折点。随着RCEP全面生效和跨境电商规模突破3万亿&#xff0c;国内头部电子签厂商的海外签署平台技术能力已成为衡量企业竞争力的核心指标。作为从业12年的电子合…

📅 2026/9/12 12:38:14
MORE NEWS

更多资讯

📰

Java Web物资租赁系统:MVC架构、事务处理与JSP视图实战解析

简介&#xff1a;基于Java的恒鑫物资租赁系统是一套面向中小型建筑施工设备租赁企业的完整毕业设计资源包。系统采用JSP视图层、MySQL数据库与MVC设计模式&#xff0c;覆盖用户管理、订单管理、资金结算和材料租赁等核心业务&#xff0c;通过集中式数据库实现数据共享&#xff…

📰

Loki `.logqltest` 声明式测试 DSL 的编辑器语法高亮:TextMate 语法定义与 VS Code / GoLand 接入指南

Loki .logqltest 声明式测试 DSL 的编辑器语法高亮&#xff1a;TextMate 语法定义与 VS Code / GoLand 接入指南 【免费下载链接】loki Like Prometheus, but for logs. 项目地址: https://gitcode.com/GitHub_Trending/lok/loki 本文讲解 Loki 仓库中为 .logqltest 声明…

📰

深入理解NVMe核心数据结构:队列、门铃与性能优化

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

Crawlee PlaywrightCrawler + TypeScript 模板全解析:从零搭建生产级浏览器爬虫项目

Crawlee PlaywrightCrawler TypeScript 模板全解析&#xff1a;从零搭建生产级浏览器爬虫项目 【免费下载链接】crawlee Crawlee—A web scraping and browser automation library for Node.js to build reliable crawlers. In JavaScript and TypeScript. Extract data for A…

📰

影子AI:企业必须正视的AI治理与数据安全新挑战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

Semantic Kernel Python OpenAPI 插件实战:从 OpenAPI 规范到可调用 Kernel Function 的完整示例解析

Semantic Kernel Python OpenAPI 插件实战&#xff1a;从 OpenAPI 规范到可调用 Kernel Function 的完整示例解析 【免费下载链接】semantic-kernel Integrate cutting-edge LLM technology quickly and easily into your apps 项目地址: https://gitcode.com/GitHub_Trendin…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬