Qwen Code/review的 Aone Codepr-context支持用平台读取层解除 Aone 评审的上下文不可用上限【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code本篇技术指南围绕设计文档 docs/design/2026-08-21-review-aone-pr-context.md 展开它是 Qwen Code/review技能跨平台改造Platform Provider Abstraction的Phase 3b在 Aone Code阿里内部基于 GitLab 的代码评审平台上为pr-context子命令提供读取后端从而解除此前 Aone 评审强制上下文不可用context-unavailable、verdict 永远封顶在 COMMENT的限制。读完本文你将掌握pr-context的平台中立化设计、Aone 频道/元数据/账本ledger的映射规则以及该改动如何一次性解锁 Aone 目标的 APPROVE、Agent 0 与跨轮账本恢复。背景Aone 目标上pr-context的跳过级联在 Phase 2Aone 读路径docs/design/2026-08-15-review-aone-provider.md与 Phase 3submit写切片落地之后Aone 的读、写路径都已就绪唯独pr-context——负责把目标的元数据与既有讨论抓取进每个 agent 都会读取的上下文文件的子命令——仍然是 GitHub 直连实现。在 Aone 目标上它被SKIP而这个跳过引发了一连串后果每次 Aone 评审都是 context-unavailablesubmit对 Aone 写路径强制该上限导致 verdict 永远无法超过 COMMENT已接线的a1 repo mr approve从未触发cap 先于它执行Agent 0issue fidelity被跳过——它以pr-context成功为门控尽管其证据命令issue-context已经是 Aone 后端机器账本machine ledger无法从 MR 恢复所以每轮都以第 1 轮重新开始尽管已发布的摘要评论带有标记。给pr-context提供 Aone 后端是同时解除上述四个问题的单一改动cap 是跳过的后果Agent 0 的门控是pr-context成功账本恰好就存在于该子命令现在要读取的已发布评论中。本期明确不在范围内均有独立跟踪comment-status/presubmit 后端与跨轮去重#9613、AI 评论标记#9614、removed-line 锚点#9615、self-PR 检测#9616已通过 #9629 落地并入本分支、cleanup 审计#9617、AGit-Flow 下的增量缓存#9618已通过 #9630 落地并入本分支见 D6、test-plan 路由 / composeUrl / a1 版本下限#9619。已核实的平台事实a1 命令面覆盖本阶段全部读取Phase 2 的事实表2026-08-13 针对maxcompute/odps_src、a1 v0.1.90 探测已覆盖本阶段要读取的一切2026-08-21 又通过help无需鉴权复核了 a1 命令面需求a1 命令面备注MR 元数据a1 repo mr view id -f json→title, description, state, sourceBranchAGit-Flow 下即 head SHA, targetBranch, author, detailUrl无 additions/deletions 统计——上下文头部降级全部评论a1 repo mr comment list --mr id -f json [--sort asc]→id, note, author, closed, outdated, path, line, side, parentNoteId, isAiComment, isDraft一个扁平集合有path⇔ 行内评论无分页参数返回完整列表默认排序descReview / verdict无——Aone 上不存在 review 对象approval 只能通过mr status检查体现当前用户a1 auth whoami -f json→account2026-08-21 探测澄清的形状probe-pending RESOLVED在 a1 鉴权恢复后针对真实 MR 探测澄清了以下形状author是对象{id, name, username}——username就是a1 auth whoami的account所处的身份空间在一个 MR 上双重验证过。容错读取器优先取account其次username。createdAt存在带时区偏移的 ISO-8601closed是数字outdated/isAiComment/isAiSummary/isDraft是布尔——草稿跳过是真实的live不是假设。评论信封还携带updatedAt、adopted、labels——本阶段不读取。同一 E2E 暴露了一个新的预先存在的缺口已记为 #9620不在本阶段范围mr view不携带 head-SHA 字段且非 AGit-Flow基于分支的 MR 的sourceBranch是分支名称——provider 的sourceBranch 即 SHA假设事实表、submit 的 drift gate、meta的 headSha只在 AGit-Flow 下成立。设计决策D1 — 新增一个读取操作getReviewContext外加getCurrentUserpr-context是唯一消费者因此 reader 只增加两个成员getReviewContext(prNumber, ownerRepo): ReviewContext——归一化打包元数据、拆分为 inline/thread 两个频道的扁平评论列表、平台级 verdictgetCurrentUser(): string——已鉴权账号空输出形状返回查找失败抛错。父文档中的终态接口称其为getContext(req)——description, comments, verdicts, selfself之所以保持独立操作是因为 pr-context 的身份策略刻意不是总是拉取查找只在存在评论时运行且其失败语义当已发布的根评论带有关键标记时 fail-closed是 pr-context 的安全逻辑而非平台逻辑。把该逻辑放在一处、保持平台中立正是本设计要点。归一化类型定义见 lib/platform/types.tsinterface ReviewContextComment { id: number; author: string; // login/account缺省为 body: string; createdAt: string; // ISO平台未给时为 path?: string; // 存在 ⇔ 行内评论 line?: number; parentId?: number; // GitHub in_reply_to_id / Aone parentNoteId } interface ReviewContextVerdict { id: number; author: string; body: string; state: string; // APPROVED | CHANGES_REQUESTED | COMMENTED | … submittedAt: string; commitId?: string; // GitHub: 该 review 所针对的 head } interface ReviewContext { title: string; body: string; authorLogin: string; state: string; baseRefName: string; headRefName: string; // GitHub 为分支名Aone: sourceBranch——AGit-Flow 下是裸 SHA headRefOid: string; additions?: number; // 平台不报统计时缺失 deletions?: number; changedFiles?: number; comments: ReviewContextComment[]; verdicts: ReviewContextVerdict[]; /** 本平台机器账本标记所在处按可交给 recoverLedger 的 verdict 形状给出 * GitHub — review 正文Aone — 线程级评论即已发布的摘要。 */ ledgerCarriers: ReviewContextVerdict[]; }github.ts的实现是抽取pr-context 现有调用一次gh pr view 三次分页ghApiAll拉取ledgerCarriers verdicts。传输接缝仍是lib/gh.js因此 pr-context 现有测试套件mock 该模块原样钉住这次抽取——该套件不改一行即通过就是无回归证据。D2 — Aone 频道映射一个扁平评论集合服务 GitHub 的三个频道有path→ 行内评论parentNoteId→in_reply_to_id因此classifyInlineThreads/findRootId无需改动即可遍历 Aone 线程无path→ issue 级MR 总线程评论——blocker 提升与 Already discussed 频道与 GitHub issue 评论的处理完全一致账本载体 无path的评论映射进 verdict 形状state: COMMENTED无commitIdqwen 摘要落在这里recoverLedger遍历载体——own/foreign 切分、round-first 选择、headroom、merge-over-own 并集——零 Aone 专属代码。Aone 评论不带commit_id所以恢复出的 Aone 账本没有年龄参照——收敛姿态convergence posture本就在该形状上跳过年龄规则skip the age rule, not the reviewisDraft评论被跳过PENDING-review 的对应物草稿既不是已发布轮次也不是已定论的讨论已解决resolved评论被包含默认comment list排除它们实测返回的是 MR 的comments减closedComments而 GitHub REST 拉取包含已解决线程评论——所以getReviewContext将默认列表与--resolved列表做按 id 去重后的并集与cleanup审计用的并集相同。closed/outdated标志本阶段仍被忽略其消费者是 comment-status#9613并集只决定哪些评论到达不决定其状态如何渲染。已披露残差已解决回复仍不可见——--resolved列表只返回已解决的根行内评论因此一个已解决线程只渲染根、不含回复链re-check 遍历不受影响——单条回复永远不会终结一个 blockerverdicts为空Aone 没有 review 对象Review summaries 段落在 Aone 上什么都不渲染人类总体评论是线程评论像 GitHub issue 评论一样进入线程频道渲染。approval 仅通过mr status可见随去重/presubmit 阶段加入。源码印证Aone 侧aoneReader.getReviewContext通过aoneAllComments默认 --resolved并集、按 id 去重、带a1.error/v1信封形状检查读取过滤isDraftpath缺失的评论映射为ledgerCarriers见 lib/platform/aone.ts 与 aone.ts 的 getReviewContext 实现。D3 — 元数据映射自mr viewtitle、description→ body、author→ authorLogin、state直通、targetBranch→ baseRefName、sourceBranch→ headRefOidAGit-Flow 下它就是 head SHA。headRefName也取sourceBranchAGit-Flow 下该字符串是 head SHA上下文头部渲染master ← sha既真实又有信息量非 AGit-Flow MR 的真实分支名以与 GitHub 相同方式渲染。Diff 统计在 Aone 无来源头部行降级为 not reported by the platform 而非打印零零会断言一个空 diff。pr-context 不在本地计算统计——worktree 属于 fetch-pr在这里重复其 merge-base 算术会是有家的逻辑的第二份拷贝。渲染侧印证buildMarkdown中meta.changedFiles ! undefined时输出Diff: N files, x/-y否则输出- **Diff:** not reported by the platform见 pr-context.tsPrMetadata的三个统计字段均为可选pr-context.tsrunPrContext只在ctx.additions等存在时透传。D4 — Aone 上重取命令烘焙--pr只有显式--host才烘焙pr-context 的截断注释会发射comment-body命令。在 GitHub 上行内与 issue 评论 id 是全局的所以只有--kind review携带--pr在 Aone 上每条评论正文都按 MR 寻址comment-body 本就拒绝无--pr的 Aone 调用。发射的命令构造器学会平台Aone 上每条发射的重取都带--pr id。一个 reader 无法运行的重取就是一条无人能完成的截断而 fail-closed 的部分读取 cannot tell规则会把它变成停滞的 re-check。host 半边契约Aone 上只有显式--host标志才烘焙进发射的重取命令。环境变量GH_HOST永远不会——那是另一个平台的 host烘焙它会把每条重取静默重定向到 GitHub host重新打开--pr规则刚关上的跨平台泄漏。无标志的 Aone 运行的重取依赖 cwd clone 的 origin——与本次运行自身所用的检测相同。GitHub 保持既有策略显式--host否则运算符导出的GH_HOST烘焙。源码印证commentBodyCommand中kind review || ctx?.platform aone时追加--pr ${n}pr-context.tsrunPrContext的bakeHost逻辑——Aone 只取显式--host且必须通过HOSTNAME_RE否则不烘焙pr-context.ts。D5 — 强制的 context-unavailable 上限离开 Aone 写路径submit为 Aone 写强制contextUnavailable: true理由是本阶段 pr-context 无 Aone 后端——这正是本改动移除的前提。该强制被移除Aone 路径像 GitHub 一样直接采信状态声明原样透传畸形值由 compose-review 拒绝。该强制原本关闭的伪造类别——伪造/省略字段合成 APPROVE——重新开放到与 GitHub 相同的级别读取有后端声明成立。comment-status/presubmit 仍无后端但它们喂给presubmit降级字段从不喂contextUnavailable其含义是pr-context 失败或被跳过见 Step 1。结果读取过上下文的 Aone 运行现在可以合成 APPROVE接线的a1 repo mr approve首次触发。D6 — AGit-Flow 下的账本锚点经 no-ancestry 规则保持活跃恢复出的 own-ledger 的sha像 GitHub 一样进入旁车文件side file与区块的锚点裁定。AGit-Flow 下锚定的 head 每次更新都被 amend孤儿化GitHub 增量路径依赖的血缘测试会对每次更新失败因此fetch-pr --since用 no-ancestry 规则解析 Aone 锚点父文档 D7本分支在途时由 #9630 落地锚点落后于 head 的测试与 merge-base 夹紧均跳过恢复的锚点把轮次增量限定到该更新触碰的文件——rebase 漂移保持在其中则范围保持更宽则回退全范围且没有任何漂移字节进入已发布范围。锚点在 Aone 上是活跃的不是惰性的草案中直到 #9618 前惰性的文字早于该落地自合并起就是错的。D7 — 技能与文档面SKILL.md 的 Aone 段落每次 Aone 运行不再是context-unavailablepr-context像 GitHub 一样运行同样的失败处理——warn、continue、context-unavailable 状态Agent 0 运行其焊接的issue-context命令是 Aone 后端plan-diff在 fetch 成功时获得--pr/--repo。跳过列表缩减到仍未后端的项comment-status、presubmit、test-plan、Step 9 绕过审计、publish-assets。重复轮次的注意事项缩减到仍成立的两条无去重后端无 self-PR 检测。本阶段 approve 不触发的文字删除。docs/users/features/code-review.md的 Aone 段落与父文档的阶段跟踪同步更新。源码落地的完整证据链读取接缝ReviewPlatformReader的终态getReviewContext与getCurrentUser已加入 lib/platform/types.ts 的ReviewPlatformReader接口与resolveRepo、getPrMeta、getCommentBody、composeUrl等并列。接口注释明确说明身份 fail-closed 策略留在 pr-contextgetReviewContext是纯读取。Aone provider 实现lib/platform/aone.ts 中getReviewContextL707-L768一次mr view拿元数据aoneAllComments提供默认 --resolved、按 id 去重的完整评论面isDraft过滤author 经aoneCommentAuthor容错依次尝试account/username/login/name与a1 auth whoami的身份空间对齐headRefName与headRefOid都走唯一的aoneHeadSha归一化sourceBranchtrimgetCurrentUserL770-L784a1 auth whoami读account空输出/异常都安全返回getCommentBodyL659-L688Aone 评论正文按 MR 寻址prNumber undefined时直接抛错读取面与getReviewContext相同含已解决评论保证截断注释发射的重取命令总能找到正文。pr-context 路由pr-context.ts 的runPrContext现在通过getPlatformReader({ host: args.host })取平台ensureAuthenticated()后调用platform.getReviewContext(prNum, ownerRepo)把归一化 bundle 拆回渲染器能讲的语言有path→ inline 频道无path→ issue 频道ctx.verdicts→ reviewsctx.ledgerCarriers→ 载体L2612-L2653。所有渲染与安全逻辑——blocker 提升、recoverLedger、fail-closed 身份、截断纪律——保持平台中立。GitHub 侧无回归抽取github.ts的实现将 pr-context 现有的一次gh pr view 三次分页拉取抽取进getReviewContextledgerCarriers verdictslib/gh.js传输接缝不变因此 pr-context 现有测试套件原样通过。测试策略pr-context 套件不改一行通过传输接缝未变——抽取的无回归证据lib/platform/aone.test.ts 新增映射测试频道切分、draft 跳过、载体形状、author 回退、统计缺失pr-context.test.ts新增 Aone 路由测试发射的--pr重取、降级的 diff 行、从评论恢复账本submit套件的强制-cap 钉子翻转为 parity 钉子与 GitHub 对齐。未决问题与边界探测待定形状author 字段、createdAt、isDraft 可见性。已解决——见事实表附录映射测试钉住真实形状。评论量长寿命 odps_src CR 的评论列表以一个不分页的 JSON 负载到达64 MiB 的 aone-client 上限可覆盖但超大线程的上下文文件会越过read_file阈值——既有的尺寸警告 分页指引已处理该形状。基于分支非 AGit-Flow的 MRsourceBranch携带分支名且mr view无 head-SHA 字段——provider 的 sourceBranch-as-SHA 假设在其上失效submit 的 drift gate 会拒绝每个 post。预先存在记为 #9620不在本阶段范围。总结Phase 3b 用一次给pr-context提供 Aone 后端的改动同时解除了 Aone 评审的四重限制verdict 上限context-unavailable 强制移除APPROVE 首次可发、a1 repo mr approve首次触发、Agent 0 门控随pr-context成功而解锁、跨轮账本恢复载体从无path的线程评论中恢复配合 D6 的 no-ancestry 锚点规则保持活跃、以及重取命令的可运行性Aone 上每条都烘焙--pr只烘焙显式--host。其核心方法是平台中立化ReviewContext归一化 bundle 之上渲染、安全、账本逻辑零 Aone 专属代码GitHub 侧以既有测试不改一行通过作为无回归证据。这份设计也清晰划出了边界——resolved 回复不可见、分支式 MR 无 head-SHA#9620等残差被显式披露并跟踪为后续 comment-status#9613、AI 评论标记#9614等阶段保留了准确的出发点。【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考