人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载IronClaw 是一款以隐私、安全与可扩展性为核心的 Agent OS其扩展包位于crates/extensions/packages/github通过 WASM 访客guest扩展把 GitHub REST API 封装成一组可供 Agent 调用的工具capability。github.list_repos是其中用于枚举已认证 GitHub 用户可见仓库的核心只读工具。本文以扩展包内的能力提示文档 list_repos.md 为主干结合输入 Schema、WASM 源码与 Manifest 配置讲解该工具的参数语义、身份边界、调用方式与底层实现帮助你在开发 Agent 技能或调试扩展行为时正确使用它。能力定位列出认证用户可见的仓库github.list_repos的作用是列出当前 GitHub 认证账号可以访问的仓库。它的底层对应 GitHub REST 的/user/repos端点——注意这个端点返回的并不是我拥有的仓库而是我能访问的仓库范围包括认证用户自己拥有的仓库认证用户所属组织organization名下的仓库认证用户被授予访问权限的协作仓库collaborator repositories。正如 list_repos.md 明确指出的由于/user/repos会返回组织拥有的仓库结果中的owner.login不能作为认证账号身份的证据。这一点是该工具最容易被误用的地方详见下文身份判定小节。参数说明type过滤与分页该工具的参数约束定义在输入 Schema list_repos.input.v1.json 中共三个字段字段类型默认值取值范围 / 约束说明typestring无不传则 GitHub 默认返回全部可见仓库all、owner、public、private、member仓库隶属关系affiliation过滤直接透传给/user/repos?typepageinteger1最小值1分页页码对应 GitHub API 的page参数limitinteger30最小值1最大值100每页数量对应 GitHub API 的per_page参数底层会被强制截断在 100 以内Schema 中additionalProperties为false即不接受的额外字段会导致参数校验失败同时所有字段都是可选的required: []因此可以不带任何参数直接调用此时使用默认值拉取第一页、每页 30 条。type各取值的语义根据 list_repos.md 的说明type控制 GitHub 的仓库隶属过滤五个取值在认证的/user/repos端点上均合法all返回所有可见仓库包含自己拥有的、组织内的、以及协作的owner仅返回认证用户本人拥有的仓库public仅返回公开可见的仓库private仅返回私有可见的仓库member返回认证用户作为成员可以访问的仓库——当用户需要组织仓库或协作者仓库时应使用member。在 WASM 源码 types.rs 中这五个取值被建模为RepoListType枚举并通过as_str()原样序列化为查询参数对应实现位于 repos.rspub(crate) fn list_repos( repo_type: OptionRepoListType, page: Optionu32, limit: Optionu32, ) - ResultString, String { validate_page(page)?; validate_limit(limit)?; let limit limit.unwrap_or(30).min(100); // Cap at 100 let mut path format!(/user/repos?per_page{}, limit); if let Some(repo_type) repo_type { path.push_str(type); path.push_str(repo_type.as_str()); } if let Some(p) page { path.push_str(format!(page{}, p)); } github_request(GET, path, None) }可见其请求路径固定为GET /user/reposlimit映射为per_page默认 30、上限 100page与type直接拼入查询串。参数校验函数validate_page与validate_limit定义在 validation.rs其中page 0会被判为invalid_pagelimit超出1..100会被判为invalid_limit——这解释了 Schema 中的最小/最大值约束来自何处。身份判定不要用list_repos回答 who am I on GitHub?能力提示文档用一整段强调了该工具最关键的边界github.list_repos不能用来回答我在 GitHub 上是谁。原因在于/user/repos返回的是认证用户可以访问的仓库其中包含组织拥有的仓库因此列表里某个仓库的owner.login很可能是组织名例如acme-inc/website而不是认证用户的登录名。若 Agent 据此宣称我就是 acme-inc就会产生身份误判。正确的做法是调用专门的github.get_authenticated_user工具对应GET /user端点。配套提示文档 get_authenticated_user.md 给出了明确的调用时机用户提出who am I on GitHub?、which GitHub account is connected? 这类身份类问题在做出任何关于已认证 GitHub 登录名的断言之前在github.list_repos返回组织仓库、需要确认真实登录身份时。从源码看get_authenticated_user在 repos.rs 中实现为github_request(GET, /user, None)两者互不替代一个回答我能访问什么一个回答我是谁。字段命名纪律与 GitHub URL 解析能力提示文档要求严格使用该能力 Schema 中的精确 JSON 字段名调用工具。对github.list_repos而言合法的顶层字段只有page、limit、type三个见 list_repos.input.v1.json传入其他字段会被additionalProperties: false拒绝。当用户给出一个 GitHub URL 时应从中提取结构化的字段值提取owner与repo仓库类工具数字型标识字段按工具类型命名pull request 工具用pr_numberissue 工具用issue_number涉及文件路径或分支时提取对应的path或ref键。这条规则在 WASM 侧有对应的严格校验调度层 dispatch.rs 会把参数 JSON 反序列化为GitHubAction枚举解析失败统一返回invalid_parametersGitHubAction::ListRepos变体types.rs仅接受type、page、limit三个可选字段其中type通过#[serde(rename type)]与 Rust 关键字repo_type映射——这再次印证了字段名必须与 Schema 完全一致。底层链路WASM 访客、HTTP 出口与认证github.list_repos不是直接跑在宿主机上的函数而是随扩展包分发的 WASM 模块中的能力。整个包的结构如下manifest.toml工具注册清单id github、version 0.2.8、runtime.kind wasm、module wasm/github_tool.wasmprompts/github/list_repos.md模型可见的能力使用提示即本文主文档schemas/github/list_repos.input.v1.json输入参数 Schemawasm-src/WASM 访客的 Rust 源码不参与工作区构建图仅作为可审计源码随包存放。请求如何发出请求链路为Agent 以github.list_repos为 capability id 发起调用 → 调度层通过action_name_from_capability_idschema.rs把github.list_repos映射为 actionlist_repos→ 反序列化参数 → 分发到list_repos实现 → 调用github_request。github_requestrequest.rs通过宿主的host::http_request走**主机 HTTP 出口host HTTP egress**发起请求这与提示文档最后一句reads from the GitHub API through host HTTP egress完全对应。请求会带上Accept: application/vnd.githubjsonX-GitHub-Api-Version当前仓库固定为2026-03-10由宿主注入的认证头详见下节10 秒超时HTTP_TIMEOUT_MS 10_000。非 2xx 响应会被映射为稳定的错误码如github_api_error_status_401、github_api_error_status_422_validation401时的 GitHub 错误消息会被截断到 512 字符后交给宿主转递给鉴权门见 request.rs这体现了 IronClaw 对访客错误消息暴露面的收敛设计。认证与权限github.list_repos的凭证配置在 manifest.toml 的[[tools.credentials]]段handle github_runtime_token vendor github audience { scheme https, host api.github.com } injection { type header, name authorization, prefix token } placeholder_env GH_TOKEN即使用 GitHub 个人访问令牌以Authorization: token GH_TOKEN的形式注入到api.github.com的请求头中同时[auth.github]段声明该产品账号通过GET /api.github.com/user成功状态 200完成有效性校验。因此调用该能力必须配置 GitHub product-auth 账号这也是提示文档最后一句话的前提条件。工具的权限模型在 Manifest 中也有体现github.list_repos声明effects [network, use_secret]、default_permission allow只读、默认放行而github.create_repo这类写操作则声明了external_write且默认ask。这意味着列出仓库是 Agent 可默认执行的低风险只读操作。典型使用场景与最佳实践综合提示文档与实现github.list_repos的推荐用法如下枚举可见仓库直接调用github.list_repos不带参数即可获得第一页 30 条可见仓库需要更多结果时用page/limit分页遍历limit上限 100。按隶属关系过滤只要自己的仓库 →type: owner需要组织/协作者仓库 →type: member只关心公开或私有仓库 →type: public/type: private。定位后续操作目标把列表结果中的full_nameowner/repo形式提取出来作为github.get_repo、github.list_issues、github.list_pull_requests等工具的ownerrepo参数——提取后务必使用各工具 Schema 规定的精确字段名。不要用它做身份断言涉及当前登录用户是谁的问题一律改用github.get_authenticated_user避免被组织仓库的owner.login误导。总结github.list_repos是 IronClaw GitHub 扩展中语义最容易被误解的只读能力之一它回答的是认证账号能访问哪些仓库而不是认证账号是谁。使用时要记住三个要点用type控制隶属过滤all/owner/public/private/member、用page/limit控制分页上限 100、把身份问题交给github.get_authenticated_user。在实现层面它由 manifest.toml 注册、经 dispatch.rs 分发、由 repos.rs 组装GET /user/repos请求并通过宿主 HTTP 出口与github_runtime_token凭证完成认证——理解这条链路能帮助你在排查 Agent 仓库枚举类任务时快速定位问题所在。赞分享人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载相关推荐IronClaw GitHub 扩展实战使用 github.search_repositories 能力搜索仓库IronClaw GitHub 扩展实战使用 github.search_repositories 能力搜索仓库 本文聚焦 IronClaw一个以隐私、安全人工智能AI 应用交互助手AI AgentIronClaw GitHub 扩展github.get_pull_request_files 能力详解与源码级使用指南IronClaw GitHub 扩展 github.get_pull_request_files 能力详解与源码级使用指南 本文聚焦 IronClaw 开源人工智能AI 应用交互助手AI AgentIronClaw GitHub 扩展github.list_branches 分支列表能力的完整使用指南IronClaw GitHub 扩展 github.list_branches 分支列表能力的完整使用指南 本篇技术指南聚焦 IronClawAgent O人工智能AI 应用交互助手AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
