人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载本篇技术指南围绕 IronClaw 开源仓库中 GitHub 扩展包的github.list_pull_request_comments能力展开讲解如何在 Agent 会话中按仓库与 PR 编号列出 pull request review comments评审评论并利用sort、direction、since参数实现有序或增量拉取。阅读完本文你将掌握该能力的完整输入参数、默认值与校验规则、底层 REST 请求的构造方式以及认证、权限与错误处理的实现细节可直接在 IronClaw 的 Agent 编排或扩展开发中落地使用。能力定位github.list_pull_request_comments是什么github.list_pull_request_comments是 IronClaw GitHub 扩展中用于列出 Pull Request 评审评论的工具。在 GitHub 的语义里评审评论review comments与时间线评论issue comments是两类不同的对象前者是评审者在 PR 的 diff 行内留下的批注后者是 PR 页面上普通对话流中的评论。本能力面向前者对应 GitHub REST API 的GET /repos/{owner}/{repo}/pulls/{pull_number}/comments端点。官方 prompt 文档prompts/github/list_pull_request_comments.md给出了使用该能力的四条核心指引用github.list_pull_request_comments列出 pull request review comments当用户要求有序或最近更新的评审评论时使用sort、direction和since参数必须使用该能力 schema 中的精确 JSON 字段名如果用户提供 GitHub URL要提取出owner和repo字段以及 schema 指定的编号、路径或 ref 键——对 PR 类工具用pr_number对 issue 类工具用issue_number该能力通过 host HTTP egress 读取 GitHub API并且需要一个已配置的 GitHub product-auth 账户。从扩展包结构看该能力属于 GitHub 扩展扩展 id 为github它是 IronClaw 工具目录中覆盖面最大的扩展之一仓库 README.md 显示共 49 个工具且是纯数据包data-only package没有独立 crate行为以 WASM 访客guest形式交付源码位于 wasm-src/编译产物为wasm/github_tool.wasm。输入参数详解从 JSON Schema 到字段语义该能力的输入严格由 schemas/github/list_pull_request_comments.input.v1.json 约束。这是一个additionalProperties: false的对象 schema即传入 schema 之外的多余字段会被直接拒绝。各字段说明如下字段类型必填约束 / 默认值说明ownerstring是长度 1–100^[^\s/?#]$且禁止..仓库所有者或组织名repostring是长度 1–100^[^\s/?#]$且禁止..仓库名pr_numberinteger是最小值 1Pull request 编号sortstring否枚举created、updated评审评论排序字段directionstring否枚举asc、desc提供sort时的排序方向sincestring否长度 1–100格式date-timeISO 8601只返回该时间戳之后更新过的评论pageinteger否最小值 1默认 1分页页码limitinteger否范围 1–100默认 30每页条数值得注意的字段细节owner/repo的严格校验schema 层禁止空白、/、?、#等字符和..路径穿越片段这与源码中validate_path_segment的防护逻辑一致见 wasm-src/src/validation.rs目的是防止构造出越权或畸形的请求路径。pr_number的命名schema 明确规定 PR 类工具使用pr_numberissue 类工具则是issue_number。同时在 Rust 反序列化层wasm-src/src/types.rs为pr_number声明了number、pull_number两个别名#[serde(alias number, alias pull_number)]提升了容错性。since的时间格式要求 ISO 8601 的date-time格式例如2026-06-23T00:00:00Z用于实现只看最近更新的增量场景。分页上限limit最大 100超出即校验失败默认 30与 GitHub API 的常规分页习惯对齐。从 URL 到参数owner / repo / pr_number 的提取规则官方 prompt 文档要求当用户给出的是 GitHub URL 而不是结构化参数时模型需要先做字段提取。规则可以概括为从形如https://github.com/{owner}/{repo}/pull/{pr_number}的 URL 中提取owner、repoPR 场景的编号键是pr_number若是 issue 场景/issues/{issue_number}编号键则必须是issue_number所有字段名必须与能力 schema 中的精确 JSON 字段名一致不能自造别名。这条规则的统一性很重要GitHub 扩展的 49 个工具共享同一套从 capability id 到 action、从 URL 到参数的解析约定便于模型在多工具间保持一致行为。实现层面schema.rs中的action_name_from_capability_id会把github.list_pull_request_comments这类 capability id 去掉github.前缀映射为 action 名wasm-src/src/schema.rs而 wasm-src/src/dispatch.rs 负责把解析出的参数 JSON 与 action 名合并后分发到具体的 API 实现。底层调用链与请求构造调用github.list_pull_request_comments时请求会经历如下链路分发dispatch.rs的execute_inner根据 capability id 反序列化出GitHubAction::ListPullRequestComments枚举并调用list_pull_request_commentswasm-src/src/dispatch.rs。校验进入 wasm-src/src/api/pulls.rs 中的同名函数先做validate_path_segmentowner/repo、validate_pagepage 不能为 0、validate_limit1–100三组校验since若提供还需通过validate_input_length的长度检查。构造 URL核心实现构造出如下 REST 路径GET /repos/{owner}/{repo}/pulls/{pr_number}/comments?per_page{limit}之后按需追加查询参数sort{sort}、direction{direction}、since{since}since 值经url_encode_query百分号编码、page{page}。从 wasm-src/src/api/pulls.rs 的源码可以看出limit会先取默认值 30 再与 100 取最小值即limit.unwrap_or(30).min(100)与 schema 的约束保持一致。发起请求最终交给github_request(GET, path, None)wasm-src/src/request.rs。请求固定携带以下请求头Accept: application/vnd.githubjsonContent-Type: application/jsonX-GitHub-Api-Version: 2026-03-10User-Agent: IronClaw-GitHub-Reborn-WASM请求基址为https://api.github.com超时时间为 10 秒。值得注意的是GitHub 扩展是 WASM guest其 HTTP 出口是通过 host 侧的http_request能力完成的——这正是 prompt 文档所说reads from the GitHub API through host HTTP egress的底层含义。排序与增量查询sort / direction / since 的实战用法prompt 文档特别强调当用户要求有序或最近更新的评审评论时应使用sort、direction和since。结合 schema 与源码它们的组合语义如下sortcreated按评论创建时间排序sortupdated按评论最后更新时间排序。枚举值定义在 wasm-src/src/types.rs 的PullRequestCommentSort。directionasc/desc配合sort指定升序或降序。注意 schema 注释写明Sort direction when sort is supplied即 direction 依赖 sort 而存在。sinceISO 8601 时间戳只返回该时间点之后更新过的评论适合上次检查之后有哪些新批注的增量同步场景。三个参数可组合使用。以查看某个 PR 最近更新、按更新时间倒序、只看 2026-06-23 之后的评论为例一个合法的调用参数如下{ owner: nearai, repo: ironclaw, pr_number: 12, sort: updated, direction: desc, since: 2026-06-23T00:00:00Z, page: 1, limit: 30 }这条调用在仓库的单元测试中有精确断言见 wasm-src/src/lib.rs 的list_pull_request_comments相关测试它验证了上述参数组合最终生成的请求路径为/repos/nearai/ironclaw/pulls/12/comments?per_page2sortupdateddirectiondescsince2026-06-23T00%3A00%3A00Zpage3注意since中的冒号被编码成了%3A这正是url_encode_query生效的结果也再次印证了 prompt 文档要求使用 schema 精确字段名、按字段语义传参的必要性。认证与网络出口需要怎样的 GitHub 账户配置prompt 文档明确指出该能力需要一个已配置的 GitHub product-auth 账户。从 manifest.toml 可以看到该工具完整的认证与权限声明凭据句柄github_runtime_token供应商vendor为github受众audience { scheme https, host api.github.com }即凭据只对 api.github.com 生效注入方式injection { type header, name authorization, prefix token }即运行时把 token 以Authorization: token TOKEN的形式注入请求头占位环境变量placeholder_env GH_TOKEN方便本地以GH_TOKEN环境变量提供占位值。在扩展包的[auth.github]配置段中认证方式为api_keyGitHub personal access token字段 handle 同样是github_runtime_token校验方式是向https://api.github.com/user发GET请求并期望200注入前缀为Bearer。这意味着一个有效的 GitHub Personal Access Token 即满足 product-auth 的配置前提配置完成后github.list_pull_request_comments这类只读工具在default_permission allow下可直接执行无需每次询问。权限模型何时允许、何时需要门禁该工具在 manifest 中的声明如下manifest.tomlorigin_gate_matrix { loop_run gated_unless_granted, product forbidden, automation forbidden }loopAgent 主循环场景下默认受门禁控制除非已授予权限product 与 automation 场景直接禁止。effects [network, use_secret]声明副作用为网络访问与使用机密token不包含external_write——它是只读能力不会对外产生写入。default_permission allow默认放行即只读查询通常可直接执行。visibility model对模型可见。因此在实际使用中读评论属于低风险操作默认即放行而像github.create_pr_review、github.reply_pull_request_comment等写操作则声明了external_write且default_permission ask需要显式确认。这与 IronClaw 面向隐私与安全的权限分层设计是一致的。错误处理与边界行为请求失败时的错误码映射同样值得了解wasm-src/src/request.rs非 2xx 状态码统一映射为github_api_error_status_{status}例如 404 对应github_api_error_status_404422 且响应体符合 GitHub Validation Failed 结构时映射为github_api_error_status_422_validation有errors数组才算校验失败普通的 abuse detection 消息不会被误判401 时会把 GitHub 返回的message字段截取前 512 字符暂存供上层在认证门禁处向模型呈现可读诊断host 层网络失败按类型映射AuthRequired、invalid_parameters、github_api_body_limit输出过大、github_api_egress_denied出口被拒、github_api_request_failed等。此外WASM 入口层若能力 id 不合法会返回unsupported_github_capability参数不是合法 JSON 则返回invalid_parameters且参数对象中不允许自带action字段见 wasm-src/src/dispatch.rs。与相邻能力的配合github.list_pull_request_comments不是孤立存在的它属于 PR 评审工作流工具组prompts 目录见 prompts/github/。完整的评审闭环通常还需要reply_pull_request_comment.md回复某条评审评论POST /pulls/{pr_number}/comments/{comment_id}/repliesget_pull_request_reviews.md列出 PR 的 review 汇总GET /pulls/{pr_number}/reviewslist_pull_request_review_threads.md列出内联评审线程走 GraphQL/graphql端点且刻意不加载每线程评论详情见 wasm-src/src/lib.rs 中的review_threads_use_graphql_endpoint测试create_pr_review.md提交评审。典型的使用姿势是先用list_pull_request_comments拿到某 PR 的既有批注可配合since只取增量再决定是否回复、解析线程或提交新的评审从而在 IronClaw 的 Agent 工作流里完整承担 PR 评审的读写职责。验证与扩展开发参考如果你想进一步验证或二次开发该能力仓库中值得关注的落点包括能力注册与声明manifest.toml 中id github.list_pull_request_comments的工具条目输入约束list_pull_request_comments.input.v1.json请求构造与校验api/pulls.rs 的list_pull_request_comments函数参数反序列化types.rs 的PullRequestCommentSort、Direction枚举与ListPullRequestCommentsaction端到端测试断言lib.rs 中验证完整查询串的单元测试。整体来看github.list_pull_request_comments是 IronClaw GitHub 扩展中一个典型的小而严谨的只读能力参数 schema 严格、校验前置、请求构造透明、认证与权限模型清晰可以作为理解整个 GitHub 扩展包乃至 IronClaw 扩展机制的入门样例。赞分享人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载相关推荐IronClaw GitHub 扩展使用 reply_pull_request_comment 回复 Pull Request 审查评论IronClaw GitHub 扩展使用 reply_pull_request_comment 回复 Pull Request 审查评论 本指南围绕 Iron人工智能AI 应用交互助手AI AgentIronClaw GitHub 扩展实战用 list_pull_request_review_threads 查询 Pull Request 行内评审线程IronClaw GitHub 扩展实战用 list_pull_request_review_threads 查询 Pull Request 行内评审线程 g人工智能AI 应用交互助手AI AgentIronClaw GitHub 扩展实战使用 github.comment_issue 为 Issue 与 Pull Request 添加评论IronClaw GitHub 扩展实战使用 github.comment_issue 为 Issue 与 Pull Request 添加评论 github.人工智能AI 应用交互助手AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 IronClaw GitHub 扩展实战：使用 github.list_pull_request_comments 查询 Pull Request 评审评论
人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载本篇技术指南围绕 IronClaw 开源仓库中 GitHub 扩展包的github.list_pull_request_comments能力展开讲解如何在 Agent 会话中按仓库与 PR 编号列出 pull request review comments评审评论并利用sort、direction、since参数实现有序或增量拉取。阅读完本文你将掌握该能力的完整输入参数、默认值与校验规则、底层 REST 请求的构造方式以及认证、权限与错误处理的实现细节可直接在 IronClaw 的 Agent 编排或扩展开发中落地使用。能力定位github.list_pull_request_comments是什么github.list_pull_request_comments是 IronClaw GitHub 扩展中用于列出 Pull Request 评审评论的工具。在 GitHub 的语义里评审评论review comments与时间线评论issue comments是两类不同的对象前者是评审者在 PR 的 diff 行内留下的批注后者是 PR 页面上普通对话流中的评论。本能力面向前者对应 GitHub REST API 的GET /repos/{owner}/{repo}/pulls/{pull_number}/comments端点。官方 prompt 文档prompts/github/list_pull_request_comments.md给出了使用该能力的四条核心指引用github.list_pull_request_comments列出 pull request review comments当用户要求有序或最近更新的评审评论时使用sort、direction和since参数必须使用该能力 schema 中的精确 JSON 字段名如果用户提供 GitHub URL要提取出owner和repo字段以及 schema 指定的编号、路径或 ref 键——对 PR 类工具用pr_number对 issue 类工具用issue_number该能力通过 host HTTP egress 读取 GitHub API并且需要一个已配置的 GitHub product-auth 账户。从扩展包结构看该能力属于 GitHub 扩展扩展 id 为github它是 IronClaw 工具目录中覆盖面最大的扩展之一仓库 README.md 显示共 49 个工具且是纯数据包data-only package没有独立 crate行为以 WASM 访客guest形式交付源码位于 wasm-src/编译产物为wasm/github_tool.wasm。输入参数详解从 JSON Schema 到字段语义该能力的输入严格由 schemas/github/list_pull_request_comments.input.v1.json 约束。这是一个additionalProperties: false的对象 schema即传入 schema 之外的多余字段会被直接拒绝。各字段说明如下字段类型必填约束 / 默认值说明ownerstring是长度 1–100^[^\s/?#]$且禁止..仓库所有者或组织名repostring是长度 1–100^[^\s/?#]$且禁止..仓库名pr_numberinteger是最小值 1Pull request 编号sortstring否枚举created、updated评审评论排序字段directionstring否枚举asc、desc提供sort时的排序方向sincestring否长度 1–100格式date-timeISO 8601只返回该时间戳之后更新过的评论pageinteger否最小值 1默认 1分页页码limitinteger否范围 1–100默认 30每页条数值得注意的字段细节owner/repo的严格校验schema 层禁止空白、/、?、#等字符和..路径穿越片段这与源码中validate_path_segment的防护逻辑一致见 wasm-src/src/validation.rs目的是防止构造出越权或畸形的请求路径。pr_number的命名schema 明确规定 PR 类工具使用pr_numberissue 类工具则是issue_number。同时在 Rust 反序列化层wasm-src/src/types.rs为pr_number声明了number、pull_number两个别名#[serde(alias number, alias pull_number)]提升了容错性。since的时间格式要求 ISO 8601 的date-time格式例如2026-06-23T00:00:00Z用于实现只看最近更新的增量场景。分页上限limit最大 100超出即校验失败默认 30与 GitHub API 的常规分页习惯对齐。从 URL 到参数owner / repo / pr_number 的提取规则官方 prompt 文档要求当用户给出的是 GitHub URL 而不是结构化参数时模型需要先做字段提取。规则可以概括为从形如https://github.com/{owner}/{repo}/pull/{pr_number}的 URL 中提取owner、repoPR 场景的编号键是pr_number若是 issue 场景/issues/{issue_number}编号键则必须是issue_number所有字段名必须与能力 schema 中的精确 JSON 字段名一致不能自造别名。这条规则的统一性很重要GitHub 扩展的 49 个工具共享同一套从 capability id 到 action、从 URL 到参数的解析约定便于模型在多工具间保持一致行为。实现层面schema.rs中的action_name_from_capability_id会把github.list_pull_request_comments这类 capability id 去掉github.前缀映射为 action 名wasm-src/src/schema.rs而 wasm-src/src/dispatch.rs 负责把解析出的参数 JSON 与 action 名合并后分发到具体的 API 实现。底层调用链与请求构造调用github.list_pull_request_comments时请求会经历如下链路分发dispatch.rs的execute_inner根据 capability id 反序列化出GitHubAction::ListPullRequestComments枚举并调用list_pull_request_commentswasm-src/src/dispatch.rs。校验进入 wasm-src/src/api/pulls.rs 中的同名函数先做validate_path_segmentowner/repo、validate_pagepage 不能为 0、validate_limit1–100三组校验since若提供还需通过validate_input_length的长度检查。构造 URL核心实现构造出如下 REST 路径GET /repos/{owner}/{repo}/pulls/{pr_number}/comments?per_page{limit}之后按需追加查询参数sort{sort}、direction{direction}、since{since}since 值经url_encode_query百分号编码、page{page}。从 wasm-src/src/api/pulls.rs 的源码可以看出limit会先取默认值 30 再与 100 取最小值即limit.unwrap_or(30).min(100)与 schema 的约束保持一致。发起请求最终交给github_request(GET, path, None)wasm-src/src/request.rs。请求固定携带以下请求头Accept: application/vnd.githubjsonContent-Type: application/jsonX-GitHub-Api-Version: 2026-03-10User-Agent: IronClaw-GitHub-Reborn-WASM请求基址为https://api.github.com超时时间为 10 秒。值得注意的是GitHub 扩展是 WASM guest其 HTTP 出口是通过 host 侧的http_request能力完成的——这正是 prompt 文档所说reads from the GitHub API through host HTTP egress的底层含义。排序与增量查询sort / direction / since 的实战用法prompt 文档特别强调当用户要求有序或最近更新的评审评论时应使用sort、direction和since。结合 schema 与源码它们的组合语义如下sortcreated按评论创建时间排序sortupdated按评论最后更新时间排序。枚举值定义在 wasm-src/src/types.rs 的PullRequestCommentSort。directionasc/desc配合sort指定升序或降序。注意 schema 注释写明Sort direction when sort is supplied即 direction 依赖 sort 而存在。sinceISO 8601 时间戳只返回该时间点之后更新过的评论适合上次检查之后有哪些新批注的增量同步场景。三个参数可组合使用。以查看某个 PR 最近更新、按更新时间倒序、只看 2026-06-23 之后的评论为例一个合法的调用参数如下{ owner: nearai, repo: ironclaw, pr_number: 12, sort: updated, direction: desc, since: 2026-06-23T00:00:00Z, page: 1, limit: 30 }这条调用在仓库的单元测试中有精确断言见 wasm-src/src/lib.rs 的list_pull_request_comments相关测试它验证了上述参数组合最终生成的请求路径为/repos/nearai/ironclaw/pulls/12/comments?per_page2sortupdateddirectiondescsince2026-06-23T00%3A00%3A00Zpage3注意since中的冒号被编码成了%3A这正是url_encode_query生效的结果也再次印证了 prompt 文档要求使用 schema 精确字段名、按字段语义传参的必要性。认证与网络出口需要怎样的 GitHub 账户配置prompt 文档明确指出该能力需要一个已配置的 GitHub product-auth 账户。从 manifest.toml 可以看到该工具完整的认证与权限声明凭据句柄github_runtime_token供应商vendor为github受众audience { scheme https, host api.github.com }即凭据只对 api.github.com 生效注入方式injection { type header, name authorization, prefix token }即运行时把 token 以Authorization: token TOKEN的形式注入请求头占位环境变量placeholder_env GH_TOKEN方便本地以GH_TOKEN环境变量提供占位值。在扩展包的[auth.github]配置段中认证方式为api_keyGitHub personal access token字段 handle 同样是github_runtime_token校验方式是向https://api.github.com/user发GET请求并期望200注入前缀为Bearer。这意味着一个有效的 GitHub Personal Access Token 即满足 product-auth 的配置前提配置完成后github.list_pull_request_comments这类只读工具在default_permission allow下可直接执行无需每次询问。权限模型何时允许、何时需要门禁该工具在 manifest 中的声明如下manifest.tomlorigin_gate_matrix { loop_run gated_unless_granted, product forbidden, automation forbidden }loopAgent 主循环场景下默认受门禁控制除非已授予权限product 与 automation 场景直接禁止。effects [network, use_secret]声明副作用为网络访问与使用机密token不包含external_write——它是只读能力不会对外产生写入。default_permission allow默认放行即只读查询通常可直接执行。visibility model对模型可见。因此在实际使用中读评论属于低风险操作默认即放行而像github.create_pr_review、github.reply_pull_request_comment等写操作则声明了external_write且default_permission ask需要显式确认。这与 IronClaw 面向隐私与安全的权限分层设计是一致的。错误处理与边界行为请求失败时的错误码映射同样值得了解wasm-src/src/request.rs非 2xx 状态码统一映射为github_api_error_status_{status}例如 404 对应github_api_error_status_404422 且响应体符合 GitHub Validation Failed 结构时映射为github_api_error_status_422_validation有errors数组才算校验失败普通的 abuse detection 消息不会被误判401 时会把 GitHub 返回的message字段截取前 512 字符暂存供上层在认证门禁处向模型呈现可读诊断host 层网络失败按类型映射AuthRequired、invalid_parameters、github_api_body_limit输出过大、github_api_egress_denied出口被拒、github_api_request_failed等。此外WASM 入口层若能力 id 不合法会返回unsupported_github_capability参数不是合法 JSON 则返回invalid_parameters且参数对象中不允许自带action字段见 wasm-src/src/dispatch.rs。与相邻能力的配合github.list_pull_request_comments不是孤立存在的它属于 PR 评审工作流工具组prompts 目录见 prompts/github/。完整的评审闭环通常还需要reply_pull_request_comment.md回复某条评审评论POST /pulls/{pr_number}/comments/{comment_id}/repliesget_pull_request_reviews.md列出 PR 的 review 汇总GET /pulls/{pr_number}/reviewslist_pull_request_review_threads.md列出内联评审线程走 GraphQL/graphql端点且刻意不加载每线程评论详情见 wasm-src/src/lib.rs 中的review_threads_use_graphql_endpoint测试create_pr_review.md提交评审。典型的使用姿势是先用list_pull_request_comments拿到某 PR 的既有批注可配合since只取增量再决定是否回复、解析线程或提交新的评审从而在 IronClaw 的 Agent 工作流里完整承担 PR 评审的读写职责。验证与扩展开发参考如果你想进一步验证或二次开发该能力仓库中值得关注的落点包括能力注册与声明manifest.toml 中id github.list_pull_request_comments的工具条目输入约束list_pull_request_comments.input.v1.json请求构造与校验api/pulls.rs 的list_pull_request_comments函数参数反序列化types.rs 的PullRequestCommentSort、Direction枚举与ListPullRequestCommentsaction端到端测试断言lib.rs 中验证完整查询串的单元测试。整体来看github.list_pull_request_comments是 IronClaw GitHub 扩展中一个典型的小而严谨的只读能力参数 schema 严格、校验前置、请求构造透明、认证与权限模型清晰可以作为理解整个 GitHub 扩展包乃至 IronClaw 扩展机制的入门样例。赞分享人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载相关推荐IronClaw GitHub 扩展使用 reply_pull_request_comment 回复 Pull Request 审查评论IronClaw GitHub 扩展使用 reply_pull_request_comment 回复 Pull Request 审查评论 本指南围绕 Iron人工智能AI 应用交互助手AI AgentIronClaw GitHub 扩展实战用 list_pull_request_review_threads 查询 Pull Request 行内评审线程IronClaw GitHub 扩展实战用 list_pull_request_review_threads 查询 Pull Request 行内评审线程 g人工智能AI 应用交互助手AI AgentIronClaw GitHub 扩展实战使用 github.comment_issue 为 Issue 与 Pull Request 添加评论IronClaw GitHub 扩展实战使用 github.comment_issue 为 Issue 与 Pull Request 添加评论 github.人工智能AI 应用交互助手AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考