models.dev Issue Fixer 自动化深度解析：从 GitHub Issue 到模型目录数据修复 PR 的完整工作流-北京尧图网络

人工智能大模型后端前端【免费下载链接】models.devAn open-source database of AI models.项目地址https://gitcode.com/gh_mirrors/mo/models.dev点击查看免费下载导读本文围绕 models.dev 仓库中的自动化 Issue 修复 Agent 配置文档 issue-fixer.md 展开完整剖析这个「Issue 修复器」的职责边界、判定标准、编辑约束、数据修复规则与 PR 生成规范。你将理解 models.dev 如何把 GitHub Issue 自动转化为模型目录models/ 与 providers/ 下的 TOML 文件的精确数据修正以及它为何刻意拒绝代码、架构与 UI 类改动。文末结合 sync.md、missing-issues.ts 与 issue-fixer.yml 等源码证据还原「同步缺模型 → 开 Issue → 调度 Agent → 改 TOML → 提 PR」的端到端自动化闭环。一、角色定位models.dev 的自动化 Issue 修复器models.dev 是一个开源 AI 模型目录数据库数据以 TOML 文件形式存储在仓库中模型级元数据位于models/lab-id/model-id.toml提供商级服务数据位于providers/provider-id/models/.../id.toml并据此生成站点与 API见 README.md。仓库在.opencode/agent/目录下维护了多个自动化 Agent 配置其中 issue-fixer.md 定义的是Issue 修复器它的唯一职责是判断新开立的 GitHub Issue 是否属于「具体的模型目录数据修复请求」若是则仅通过修改models/与providers/下的 TOML 文件完成最小修复最终产出评审级 PR 描述。从该文件头部的元数据可以看到它的运行约束mode: primary、hidden: true作为主 Agent 使用不在普通列表中展示permission严格收紧bash: deny禁止执行 shell、external_directory: deny禁止访问仓库外目录编辑权限仅放开models/**/*.toml与providers/**/*.toml其余路径全部deny颜色标识#44BA81与指定的model字段用于区分仓库内多个自动化 Agent对比 ci-fixer.md 的职责是修复 CI 失败。二、判定边界什么值得自动修什么必须留给维护者Issue Fixer 的第一项任务不是改文件而是做裁决。文档明确只处理「可以通过更新既有模型/提供商元数据来解决」的 Issue典型包括新增缺失的模型或提供商模型条目修正价格、令牌上限、模态modalities、能力capabilities、状态、发布日期等事实性元数据修复提供商 TOML 与官方提供商文档之间的不一致。反之以下类型一律不编辑文件仅简短回复「需要维护者评审未发起自动修复」功能请求feature request请求追踪新类型信息的建议策略/产品讨论一般性提问任何不属于「具体模型目录数据修复」的杂项请求。这一判定逻辑与同步流水线形成呼应在 sync.md 中skipCreates: true的提供商如 Mistral、Meta、xAI无法安全地自动创建完整 TOML因此每发现一个远端缺失模型 ID就会开一个去重的[missing-model] provider: model-idIssue并显式派发 Issue Fixer——此时该 Agent 的角色就是接过同步器无法自动完成的部分人工Agent研究缺失的规范与提供商侧元数据后再提 PR见 sync.md 与 missing-issues.ts。三、安全边界权限模型与可编辑范围Issue Fixer 的编辑权限是仓库刻意收紧的。从 issue-fixer.yml 可以看到工作流在运行时强制注入OPENCODE_PERMISSION: {bash:deny}与配置文件中的bash: deny双重约束Agent 不能运行任何 shell 命令分支创建、提交与 PR 开立全部由工作流在 Agent 完成之后处理。工作流在 Agent 结束后还有一个路径白名单校验步骤逐行检查git status --porcelainmodels/*.toml|providers/*.toml # 只允许这两类路径任何超出models/、providers/的 TOML 修改如packages/、.github/、docs/都会导致整个 Job 失败issue-fixer.yml。也就是说代码、Schema、UI、文档与工作流变更被配置层agent 权限与执行层workflow 校验双重拦截。四、修复规则详解最小、可验证、守规范当裁决通过、开始动手修复时issue-fixer.md 给出了一整套硬性规则其底层规范与 AGENTS.md 一一对应4.1 遵循 AGENTS.md倾向最小正确修改文档明确要求修复遵循AGENTS.md的完整约定包括lab 与 provider 的区分、base_model的使用时机、模型字段Model fields、推理选项Reasoning options、override-only 宿主等。核心原则是「Prefer the smallest correct change」——只做解决问题所需的最小修改除非为保持内部一致性所必需且每项都已独立验证否则不扩大 Issue 的范围。4.2 事实核查Issue 只是线索不是证据「Verify every changed factual value against authoritative sources」是文档强调的硬性要求优先使用第一方材料提供商官方文档、定价页、API 参考、模型卡、或线上提供商目录响应把 Issue 本身当作**线索lead**而非充分验证依据禁止引用搜索结果页、禁止凭空捏造 URL。这一原则在仓库中同样体现在providers/deepseek/provider.toml的写法上文件顶部注释逐一注明了访问日期与官方文档链接api-docs.deepseek.com的 thinking mode 与 Anthropic API 指南用「来源 URL 访问日期」的方式让维护者可以复核。4.3 lab 与 provider 二分法base_model 是核心机制修复模型条目时Issue Fixer 必须执行以下判断流程若宿主host并非模型的创造者先识别其底层 lab 模型若models/lab/model.toml缺失则新增该 lab 模型文件提供商文件使用base_model指向 lab 元数据提供商文件是override-only——绝不重复陈述与 base 相同的 description、modalities、structured_output 等字段只有第一方 lab 宿主或该宿主独有的别名unique-to-host aliases才允许完整内联定义。仓库中有大量真实案例可佐证。例如 models/deepseek/deepseek-v4-pro.toml 作为 lab 级元数据声明了name、description、family、release_date、last_updated、能力布尔值与[limit]、[modalities]等完整字段而 providers/openrouter/models/deepseek/deepseek-v4-pro.toml 只有短短几行# Toggle: reasoning.enabled true|false # https://openrouter.ai/docs/guides/best-practices/reasoning-tokens base_model deepseek/deepseek-v4-pro [interleaved] field reasoning_content [[reasoning_options]] type toggle [[reasoning_options]] type effort values [high, xhigh] [cost] input 0.2088 output 0.4176 cache_read 0.0174 [limit] context 1_048_576这正是 override-only 的教科书式写法以base_model继承 lab 事实只保留 provider 专属字段cost、reasoning_options、interleaved、limit覆盖并配以顶部注释说明推理开关的线上路径wire path。base_model的合并语义在 AGENTS.md 中有精确定义普通对象[limit]、[modalities]深度合并数组与原始值子替父缺省字段从models/继承base_model与base_model_omit仅在解析期生效不进入生成的 JSON指向不存在的 lab 目标会导致校验错误。此外当宿主未创建该模型时新建的 lab 文件必须完整日期、能力布尔值、limit、modalities缺一不可否则bun validate会因缺失继承字段而失败AGENTS.md。4.4 Reasoning 选项按宿主类型分类不套固定枚举文档要求对推理选项做严格分类首先区分第一方 lab与多模型中转relay判据是「谁在运行 API」而非 npm 包名ai-sdk/openai-compatible不意味着中转——DeepSeek、Alibaba 都是使用该包的第一方 lab见 AGENTS.md复制该模型在 lab/对等条目上的原生选项集不要给 DeepSeek 风格的high/max强套low/medium/high中转宿主不得因为无法重测就写空数组[]空数组表示无调用方控制不是不确定性toggle与含none的分级 effort 不能共存toggle 不含none的分级 effort 必须配一条文件顶部的 wire 注释sync 序列化会删除节间注释budget_tokens仅按AGENTS.md在宿主确有推理预算字段时使用不是max_tokens。真实案例再次可见providers/deepseek/provider.toml顶部注释记录了thinking.type enabled|disabled与reasoning_effort low|high|max等线上字段providers/openrouter/models/deepseek/deepseek-v4-pro.toml 则用文件首行注释# Toggle: reasoning.enabled true|false声明 wire path再书写toggleeffort [high, xhigh]。完整策略还引用 audit-reasoning-options/SKILL.md 作为深度参考。4.5 保留 provider 专属字段提供商 TOML 中的专属字段cost、reasoning_options、interleaved、status、provider在修复时必须保留。这些字段不属于 lab 元数据永远不应写入models/AGENTS.md。4.6 成本单位与计价层级所有cost值一律为USD / 百万 tokens其他币种必须换算并在文件顶部注释中注明汇率与日期上下文分档定价使用[[cost.tiers]]绝不在新文件中手写context_over_200k该字段是遗留输出项Schema 在写入时拒绝见 AGENTS.md。4.7 来源注释的放置位置「Put durable source URLs in a leading TOML comment block」——新增或修改事实性数据时把可靠的来源 URL 放在文件首部注释块严禁把来源注释放在 TOML 各节之间因为 sync 序列化会将其丢弃。这解释了为何providers/deepseek/provider.toml与 OpenRouter 的推理示例都把注释集中在文件最上方。4.8 不运行命令、不声称未做的验证文档最后一条铁律禁止运行 shell 命令或使用 Bash——提交与 PR 创建由工作流在 Agent 完成后接管同时「Do not claim validation unless you actually performed it」不得声称执行了实际并未运行的验证或线上 API 测试。五、信息不足时拒绝猜测索取缺失信息如果 Issue 缺乏足够的信息来源来做出安全的事实修正Issue Fixer 的默认动作是不改文件、不猜测而是回复具体缺失了哪些信息。这与同步器「fail closed」的设计哲学一脉相承例如 sync.md 中 Mistral 同步在推理控制无法解析时留空并开 Issue、而不是写入猜测值missing-issues.ts 在去重列表窗口被填满时「拒绝创建」而非冒险重复。宁可让问题滞留人工评审也不向目录中注入未经证实的数据。六、PR 描述评审就绪的五段式结构只要编辑了文件Agent 的最终响应就会成为 PR 描述文档要求按以下五段组织章节要求## Summary说明修正内容及其必要性## Changes逐条列出实质字段变更尽可能给出旧值 → 新值## Evidence将每条实质声明或声明组映射到直接来源 URL并简述该来源证明了什么优先第一方来源回退来源需明确标注不引用搜索结果页、不虚构 URL## Validation陈述实际完成的验证不得声称未运行的命令或未执行的线上测试## Review notes披露歧义、假设、有意遗漏的关联改动无则写None要求证据具体到「维护者无需重复全部调研即可评审 diff」。若未编辑文件则用一两句话说明原因。该格式与 issue-fixer.yml 中的 PR 创建逻辑对接Agent 的响应文件被直接作为 PR body并追加Closes #issue与自动化来源说明。七、端到端闭环从同步器到 PR 的源码级链路将 Issue Fixer 放回整个自动化体系中可以看到一条完整的流水线可依 sync.md、missing-issues.ts 与 issue-fixer.yml 逐步追踪同步发现缺口bun models:sync provider按小时运行sync-models.yml。对skipCreates: true的提供商远端存在而本地缺失的模型 ID 由 missing-issues.ts 去重后逐个开 Issue标题稳定为[missing-model] provider: model-id标签为automation、model-sync、missing-model、provider:id派发每次新建 Issue 后立即调用gh api repos/repo/dispatches以event_typemissing-model显式派发 Issue Fixermissing-issues.ts——这一步解决的是「用 GITHUB_TOKEN 创建的 Issue 依然能产出 PR」的问题修复issue-fixer.yml 检出dev分支、加载 Issue 内容并构造成 prompt然后以opencode run --agent issue-fixer执行Agent 按本文前述规则裁决并只改models/、providers/的 TOML白名单校验workflow 检查改动路径超范围即失败提 PR无改动时仅以响应文本评论 Issue有改动则创建issue-编号分支、提交并把 Agent 响应即五段式 Markdown作为 PR bodybase指向dev重试兜底retry-issue-fixer.yml 每六小时扫描最老的无关闭 PR 的自动化 Issue重派最多三个至少一小时前创建的 Issue避免首次派发失败导致任务搁浅。值得注意的细节工作流对provider:openai标签的 Issue 及 openai 派发做了显式排除issue-fixer.yml这与 sync.md 中「OpenAI 的/v1/models作用域有限、trackMissingModels: false」的说明一致——不是所有 provider 的缺失模型都适合走自动修复。八、总结与工程启示issue-fixer.md 虽然只是一份 Agent 行为规范却浓缩了 models.dev 目录工程的核心设计哲学窄职责只做「模型目录数据修复」代码/Schema/UI 一律不碰从 Agent 权限与 workflow 校验两层锁死证据优先任何事实性变更都必须锚定第一方来源Issue 仅作线索来源注释放在 TOML 首部以对抗 sync 序列化最小化与一致性优先base_model继承避免重复lab 缺失则补齐完整元数据新字段如[[cost.tiers]]必须按 Schema 的现行规则书写可审计交付五段式 PR 描述把「改了什么、凭什么、验证了什么、遗留了什么」讲清楚维护者无需重复调研。对任何以数据文件为唯一事实来源source of truth的开源项目来说这套「Issue 裁决 → 受限编辑 → 证据化 PR」的 Agent 范式是一份极具参考价值的实现样本。赞分享人工智能大模型后端前端【免费下载链接】models.devAn open-source database of AI models.项目地址https://gitcode.com/gh_mirrors/mo/models.dev点击查看免费下载相关推荐PyCaret 4.0 issue-fixer 智能体协议从 GitHub Issue 到 PR 的端到端自动修复工作流PyCaret 4.0 issue fixer 智能体协议从 GitHub Issue 到 PR 的端到端自动修复工作流 PyCaret 4.0 采用 Clasentry-javascript 的 fix-issue 技能从 GitHub Issue 到小型修复 PR 的 AI 自动化工作流sentry javascript 的 fix issue 技能从 GitHub Issue 到小型修复 PR 的 AI 自动化工作流导读 sentry j可观测性OpenClaw gh-issues 技能实战从 GitHub Issue 到自动修复 PR 的全自动工作流OpenClaw gh issues 技能实战从 GitHub Issue 到自动修复 PR 的全自动工作流导读 gh issues 是 OpenClawAI 应用AI Agent交互助手后端即时通讯网关上一篇3分钟快速上手drawio-desktop - 你的专属离线流程图绘制工具下一篇IPXWrapper终极解决方案让经典游戏在Windows 10/11上重获联机能力创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

models.dev Issue Fixer 自动化深度解析：从 GitHub Issue 到模型目录数据修复 PR 的完整工作流

相关推荐

Hyperf 分佈式事務實戰：基於 DTM 的 TCC、Saga、XA 與二階段消息完整指南

PaddleNLP 土耳其语模型 dbmdz/bert-base-turkish-uncased 下载与使用实战指南

资源稀缺信号与约束内构建：let-fate-decide 中 Five of Pentacles（五角星五）的工程技术解读

更多资讯

停车场管理系统课程设计：用栈、队列、链表一题通关

仿微信聊天系统源码解析：WinForm桌面端IM开发实战指南

阿里 Qoder 智能体工作台实战：用 TaoToken 统一 Key 打通 Harness 与 Agent 工作流

OpenClaw Talk 模式实战：TaoToken 统一 Key 打通 Voice Call 语音链路配置指南

工控数据类型与值范围详解：从PLC到Modbus的解析避坑指南

新电脑装机指南：从系统初始化到效率工具的科学配置思路

今日更新

PHP htmlentities()函数用法讲解

AI Agent工程实战：从七要素到七个决策点的系统设计指南

AI入局芯片设计验证：验证收敛50倍加速的真相与应对

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？