人工智能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),仅供参考
企业数字化 ERP 产品动态
相关推荐
Unity Prefab节点改名引发连锁故障?用生成诊断与CI门禁守住资产契约 先提个醒,这篇文章里的“节点”,不是后端同学常说的集群节点、K8s worker node,也不是用 Neo4j 查图时从一个节点顺着边找关联节点的那种图节点。在 Unity 项目里,Prefab 节点就是预制体内部那棵 GameObject 层级树:根… · 2026/9/24 22:06:46
ThinkPHP+Laravel双框架实战:考试刷题与学情分析系统架构解析 1. 选型复盘:ThinkPHP和Laravel在一套系统里怎么分工1.1 为什么不是“二选一”,而是“各干各的”接手这个考试刷题及分析系统时,我一开始也纠结了很久:ThinkPHP和Laravel到底选哪个?后来想明白一个道理——做项目不是比… · 2026/9/24 22:06:46
生产级客服Agent落地指南:从Demo到上线的完整实战解析 1. 为什么一个Demo撑不起生产级客服Agent做客服Agent的都知道,Demo演示和真上线,中间隔着一条鸿沟。我带的这个项目从第一版原型到正式生产环境,前后经历了六轮完整评审,踩过的坑连起来能绕办公室一圈。标题里写的“FDE36记”&… · 2026/9/24 22:06:46
古词新解:从《贺新郎·别友》看离别词的现代回响 第一次认真读这首《贺新郎别友》,是在一个夜深人静的晚上。那时候我对它的印象还停留在“这是一首名人写的离别词”,觉得应该跟课本里那些革命情怀的篇章差不多,结果从头到尾读下来,整个人有点被定住。它没有我预想中的那样昂扬&a… · 2026/9/24 22:44:40
笔记本24G显存跑27B模型:576 tok/s背后的技术解密与实战调优 晚上十一点,我把笔记本从包里拿出来,接上电源,在终端敲下 ninfer 的启动命令。按下回车的时候,我其实没抱什么期望——过去大半年,我在各种设备上跑过 27B 级别的本地模型,结论始终是同一个:能加… · 2026/9/24 22:44:40
多Agent协作实战:用开源桌面端搭建5个Claude Code智能体流水线 把 5 个 Claude Code 智能体同时挂到一个开源桌面端里,让它们像一个小团队那样自己拆任务、自己写代码、自己跑测试,最后把成果汇总给你——这是我最近一直在折腾的玩法。“14K Star 的 Claude Code 开源桌面端”这个项目刷屏的时候,我只是随… · 2026/9/24 22:44:40
Http Mock工具实战拆解:从接口模拟到前后端联调提效 简介:面向前端开发者在后端接口未完成时无法联调的场景,这款Http自动回复请求软件提供了一键式Mock服务方案。通过图形化界面可快速创建、编辑和管理接口,无需安装额外插件或复杂配置,根据接口文档填入模拟数据即可启动服务&#… · 2026/9/24 22:44:40
WorkBuddy、豆包办公都来了,企业AI如何统一纳管? AI助手进入企业,IT管理变得复杂
随着WorkBuddy、豆包办公、千问办公等AI智能体工具在企业办公场景加速落地,员工效率得到显著提升。与此同时,企业引入这类工具时也普遍会遇到一些治理课题:文件与数据分散、自动化执行边界、网络访… · 2026/9/24 22:44:40
读《贺新郎·别友》:从汽笛断肠到昆仑崩壁的离别启示 读一首词,最怕的不是读不懂,而是懂得太快。《贺新郎别友》我第一次读,是在大学图书馆的一本旧词选里。当时只记住了两句,一句是“汽笛一声肠已断”,另一句是“重比翼,和云翥”。等到很多年后自己经历了几场… · 2026/9/24 22:44:34
基于YOLOv8的渔船作业监控系统:从环境搭建到边缘部署全流程 简介:这是一套面向计算机、人工智能、自动化等专业学生与教师的毕业设计级项目资源,围绕YOLOv8实现渔船作业监控系统,可用于毕设、课程设计、大作业或项目立项演示。压缩包共97个文件,约24.21MB,以70个Python源码文件为… · 2026/9/24 0:00:13
1D-CNN时间序列建模实战:从Conv1d原理到工业落地 简介:面向时间序列数据建模的一维卷积神经网络完整实现,适合深度学习入门者及需要快速验证时序模型的研究者,能够从音频、文本、传感器或股价等序列中挖掘局部特征与时间依赖。压缩包体积很小,只有3KB,内含3个Python脚… · 2026/9/24 0:00:26
柔软的L:汉语语流中被忽视的舌肌张力控制 1. 这个“L”不是字母表里的L,而是舌尖上的L最近在几个方言群和语音教学社群里,反复看到有人发一句:“也说字母L:柔软的长舌”。初看以为是英语发音课笔记,点开才发现全是方言爱好者、播音系学生、语言康复师甚至戏曲演… · 2026/9/24 0:00:44