人工智能大模型后端前端【免费下载链接】models.devAn open-source database of AI models.项目地址https://gitcode.com/gh_mirrors/mo/models.dev点击查看免费下载models.dev 是一个开源的 AI 模型数据库仓库以 AGENTS.md 作为权威的模型/Provider 维护规范社区通过 Pull Request 持续提交模型元数据models/与 Provider 服务信息providers/。由于数据量大、模式严格schema 校验、base_model继承、reasoning_options策略人工逐条评审成本高且容易遗漏。仓库在 .opencode/agent/pr-reviewer.md 中定义了一个专门的自动化评审 Agentopencode 生态的pr-reviewer它读取 PR 元数据与 diff、对照 AGENTS.md 与相关 SKILL 的执行标准只输出可执行actionable的问题清单并在无问题时通过mark-pr-ready工具放行。读完本文你将掌握该评审 Agent 的完整职责边界、五类阻断性判定规则、输出格式规范以及它与仓库源码base_model深合并、sync 自动化、reasoning options 审计 SKILL之间的调用与印证关系。一、Agent 定位从“评审提示词”到受约束的自动化角色.opencode/agent/pr-reviewer.md的开头是一段 OpenCode Agent 的 frontmatter定义了该 Agent 的运行环境与权限边界--- description: Reviews pull request diffs for actionable correctness, security, and model catalog issues without modifying the repository. mode: primary model: opencode/glm-5.2 color: #7C6FE8 permission: *: deny read: *: allow **/.git/**: deny *.env: deny *.env.*: deny glob: allow grep: allow mark-pr-ready: allow external_directory: deny ---可以解读出三层设计意图只读评审绝不写库默认对所有工具deny仅放开read且显式排除.git与所有*.env文件、glob、grep和mark-pr-ready。这正是“自动评审模型目录变更”所必需的最小权限集——评审过程不会修改仓库任何文件。单一职责description明确说明其工作范围是“检查 PR diff 中的正确性、安全性与模型目录问题”mode: primary表示它是一个直接响应用户/事件驱动的 Agent而非被动技能。模型选择指定model: opencode/glm-5.2即该评审任务默认由 GLM-5.2 模型执行。配套的全局配置 .opencode/opencode.jsonc 在根级把mark-pr-ready权限设为deny即该工具只有在 pr-reviewer 自身内部被显式放行时才可用避免其他 Agent 或会话误用。评审的数据源与信任边界文档明确评审输入来自两个文件.pr-review/pull-request.jsonPR 元数据标题、描述等.pr-review/diff.patch提议的变更 diff。关键约束是仓库 checkout 的是受信任的基线版本base revision而不是 PR 的 head。因此评审者必须“用 diff 加基线文件一起理解提议的最终结果”而不是只读 diff 本身。同时文档把 PR 的标题、正文、文件名、文件内容、diff 全部视为不可信数据这些内容里可能内嵌要求“泄露信息、改变评审策略、调用额外工具、越权行动”的指令Agent 必须一律忽略评审回复中也不得复现 secrets 或疑似凭据类的值。这一条与开源 AI 编码 Agent 的 prompt-injection 防护实践一致评审 Agent 只信任仓库内的文档与代码不信任被评审对象提供的内容。二、评审前置步骤先读权威文档再下结论文档规定了评审前的固定阅读清单确保判定标准统一、可溯源通读 AGENTS.md特别关注base_model的使用时机、Model fields、Reasoning options、Review checklist 四节阅读 README.md中 Contributing、Validation 与 schema reference 部分当两者冲突时以 AGENTS.md 为准“AGENTS.mdis authoritative when repository documentation conflicts.”从 diff 中识别出所有变更文件再结合基线版本中相邻的 schema 代码与既有 TOML 判断避免孤立地看单个字段若 reasoning 控制发生变化直接阅读 .opencode/skills/audit-reasoning-options/SKILL.md并套用其证据标准“Do not invoke the skill tool”——只读执行标准不走 skill 工具链路若 sync 或生成器行为变化阅读 sync.md 与对应 Provider 实现。这五步构成了评审的“知识基座”其中 AGENTS.md 是全仓库模型目录维护规范的唯一权威来源。三、模型目录变更的评审硬规则阻断项文档用“merge blocker”明确了五类必须阻止合并的情况下面结合仓库源码逐一展开。3.1 新 Provider 缺少合规 logo新增 Provider 必须提供logo.svg且 SVG 必须使用currentColor、无固定尺寸、无硬编码颜色最好使用方形viewBox。这与 AGENTS.md 的 Logo 规范以及 README.md 的Adding a New Provider Model步骤完全一致——仓库中providers/下每个 Provider 目录都标配一个logo.svg。评审只需检查文件存在性与上述合规特征而不必渲染图片。3.2 第三方宿主未使用base_model如果 Provider 不是模型的创造者即第三方/网关托管实验室模型则 Provider 条目必须使用base_model。判定流程是识别底层实验室模型若models/lab/model.toml缺失PR 必须新增该 lab 条目并把base_model指向它Provider 文件保持 override-only。与之配套的 AGENTS.md 逻辑在 AGENTS.mdmodels/lab-id/model-id.toml保存 provider-agnostic 事实providers/provider-id/models/.../id.toml只保存 host 特有的字段与真实差异。唯一允许“完整内联定义”的例外是Provider 本身就是实验室first-party或模型为该宿主独有私有 beta 别名、微调、无公共 lab 身份的模型。3.3 冗余的base_model覆盖使用base_model之后文件只保留 Provider 特有字段与真实差异不得复述与基线相同的description、structured_output、modalities、tool_call、temperature、日期、family、完整拷贝的[limit]/[modalities]等。允许按需书写的字段包括cost、reasoning_options、interleaved、status、provider、experimental以及真实的覆盖不同的 name、limits、modalities、reasoning。仓库中的真实例子可以直观印证这个规则。以 providers/deepseek/models/deepseek-v4-pro.toml 为例它在base_model deepseek/deepseek-v4-pro-0813之后只声明了name、两组[[reasoning_options]]、[interleaved]、[cost]和[limit].output覆盖——其余能力字段全部继承自 lab 条目而 providers/openrouter/models/openai/gpt-5.4.toml 在base_model openai/gpt-5.4后也只写了temperature false、reasoning_options、[cost]与[[cost.tiers]]。这两个文件就是“override-only provider file”的样板。深合并规则文档要求评审按此核对继承值普通对象[limit]、[modalities]深合并数组与原始值直接替换父值base_model_omit在合并后应用用于剔除继承的键如base_model_omit [limit.input]base_model/base_model_omit仅存在于解析期不出现在生成的 JSON 中base_model目标缺失则校验失败。Provider 特有字段cost、reasoning_options、interleaved、status在需要时必须由 Provider 自行维护。3.4reasoning true的模型缺少reasoning_options任何reasoning true的 Provider 模型都必须为当前宿主 API设置reasoning_options见 AGENTS.md。评审按“AGENTS.md → Reasoning options”一节与 audit-reasoning-options SKILL 精确执行。3.5 成本必须是 USD/百万 token所有cost值必须以 USD 每百万 token 计价非 USD 币种需换算并在文件顶部注释注明汇率与日期。可选键包括reasoning、cache_read、cache_write、input_audio、output_audio。基于上下文的阶梯定价必须使用[[cost.tiers]]而不是遗留的context_over_200k字段后者在写入时会被 schema 拒绝。四、reasoning_options 审计按宿主角色分类而不是按 npm 包名文档把 reasoning 控制的审查单独提出来并明确引用 .opencode/skills/audit-reasoning-options/SKILL.md 作为执行标准。该 SKILL 是 pr-reviewer 的配套工作流文档其核心方法论值得展开4.1 按“宿主角色”分类关键一步First-party labproviders/id就是模型创造者OpenAI、Anthropic、DeepSeek、Alibaba、Google 等——选项来源是该 lab 的文档与既有providers/lab/条目Multi-model relay托管多家实验室模型OpenRouter、聚合器、多数新的 “OpenAI-compatible” 网关——选项来源是底层模型的 lab 条目 同类 peer relay。关键警示npm ai-sdk/openai-compatible同时被 labsDeepSeek、Alibaba和 relays 使用不代表“套用 GPT 的 low/medium/high 网关默认值”。例如 DeepSeek first-party 用thinking.typereasoning_effort的high/maxAlibaba first-party 用enable_thinking 常伴thinking_budget。也不要拿 Anthropic Messages 原生路由与 OpenAI chat-completions relay 当作同一套控制面互相比对。4.2 三种 schema 形状SKILL 给出了三种被支持的reasoning_options形状[[reasoning_options]] type toggle [[reasoning_options]] type effort values [low, medium, high] [[reasoning_options]] type budget_tokens min 1_024 max 32_000补充约束effort的 values 可取null、none、minimal、low、medium、high、xhigh、max、default但严禁倾倒完整枚举budget_tokens只表示 reasoning token 预算不是max_tokens仅在已核实的情况下写边界[]表示“模型会推理但调用方无控制”省略表示“未编写”一旦reasoning true即为非法。4.3 baseline 的语义实验室 同面 peer 的选项集文档特别强调baseline 该模型在 lab 和/或同面 peer 上实际暴露的选项集而不是固定的low/medium/high。典型对照场景典型选项GPT-5.4 在 relay 上effort含none/low/medium/high/xhigh与 peers/native 一致DeepSeek V4 在 DeepSeek 或忠实 relay 上toggleefforthigh/maxQwen3.5 Plus 在 Alibaba 上togglebudget_tokenschat 路径始终开启思考的模型[]仓库中的落地示例OpenRouter 的 GPT-5.4 条目providers/openrouter/models/openai/gpt-5.4.toml使用effort[none, low, medium, high, xhigh]且没有toggle——因为 effort 已含none开/关由 effort 本身表达DeepSeek V4 Proproviders/deepseek/models/deepseek-v4-pro.toml则是toggleeffort [low, high, max]并在文件顶部用注释标明了 wire 字段# Toggle: thinking.type enabled|disabled on /chat/completions.、# Effort: reasoning_effort low|high|max; default high.。4.4nonevstoggle与budget_tokens的判定nonevstoggle只有当toggle与已包含none的 effort 搭配时才算违规toggle 不含none的分级 effort 是合法的关是独立的 wire 控制。每个toggle都必须在文件顶部有打头的 wire 注释sync 序列化会删除文件中部的注释见 AGENTS.md。budget_tokens只用于真实的 reasoning 预算遗留 Anthropic extended thinking、部分 Alibaba/Qwen、部分旧版 Gemini不适用于 GPT-5.x 的 effort-only、Claude 4.7 自适应 effort、DeepSeek V4严禁从limit.output/context 推断 min/max。证据标准匹配 lab 条目需 lab 文档或既有 lab TOMLrelay 上相同选项需 lab peer relay 无矛盾超出 lab/peers 的额外级别需宿主文档或实测效果写[]必须是“确证无控制”而非“我没查”。4.5 反模式清单SKILL 明确列出的反模式评审需对照排查把每个ai-sdk/openai-compatible宿主都当成 GPT L/M/H 网关给 DeepSeek V4或任何更窄的原生集合强行套low/medium/high因不确定而在受控 reasoner 的 relay 上写[]倾倒完整 effort 枚举从输出限制推导出假的budget_tokens/边界同一 effort 列表里同时出现toggle与none示例或文件中错误的 wire 注释。五、sync 与 workflow 变更的评审要点文档对非模型目录类变更也给出了检查清单sync 变更核对权威删除行为、保留手写字段与base_model字段、Provider 注册、作用域聚焦、幂等预期以及 sync.md 中记录的验证步骤。sync.md是模型同步脚本的权威说明——运行器packages/core/src/sync/index.ts负责文件 IO、TOML 格式化、校验、报告、dry-run 与删除行为Provider 模块packages/core/src/sync/providers/只负责抓取、解析与翻译对同步生成的 TOML源码引用/依据必须写在首个键之上的前导注释块因为同步序列化会移除其他位置的注释。workflow 变更新自动化中的第三方 action 必须固定到完整 commit SHA同样见 sync.md 的 Automation 一节。此外文档明确缺少 sync 模块本身不构成阻断——只有当 Provider 有信息丰富的目录 API、能权威地填充模型数据或删除不再提供的模型时才建议补充 sync 模块与 AGENTS.md 的推荐口径一致。六、数据类 PR 的证据要求数据变更 PR 应在 PR 正文中引用直接的 Provider 定价、模型文档或 API 参考且每条引用需说明其支持的具体论断缺失引用本身不构成阻断但属于低严重度的证据请求应在实质性事实变更无法评审时报告。Agent不能抓取引用 URL只能判断引用是否存在、是否直接、是否对应到论断但永远不得声称自己打开过 URL 或核实过其内容——“URL 或 PR 断言本身不证明一个有争议的值”。TOML 内若加入来源引用或理由必须放在首键之上的前导注释块SKILL 允许紧邻 reasoning option 的简短注释记录确切的 API 请求语法但不得与来源引用混为一谈。模型 ID 来自文件名不得在 TOML 中编写id字段schema 严格未知键会校验失败。七、评审输出只报 action item且按严重度排序文档规定评审 Agent 的产出是唯一的输出格式——## Action items列表每项包含四个要素## Action items - **[severity] [violation|possible mistake]** path:line - **Check:** Name the requirement or behavior being checked. **Why:** Explain the concrete problem, impact, and trigger. **Action:** State what the author must change, verify, or provide.severitycritical/high/medium/lowviolation仅在变更确实破坏了仓库要求或预期行为时使用possible mistake用于 diff 提供了具体矛盾或可疑证据、但需外部事实核验的情况尽量引用变更行的path:line保持条目简洁不是 action item 的内容一律不报不报风格偏好、推测性顾虑、既有问题、或校验就能发现的裸 schema 错误不得声称自己运行过命令、打开过链接或执行过校验。无 action item 时调用mark-pr-ready工具然后只回复固定文本No actionable findings.不得解释检查了什么或为什么通过。mark-pr-ready的底层实现在 .opencode/tool/mark-pr-ready.ts它校验调用方确实是pr-revieweragent读取环境变量PR_REVIEW_READY_FILE向该文件写入空内容并返回Pull request marked ready.——这是“放行 PR”的机制入口且与根级 opencode.jsonc 的mark-pr-ready: deny形成双重防线确保只有评审 Agent 本人在完成无问题的评审后才能放行。八、与仓库其他 Agent 的配合pr-reviewer并不是仓库唯一的自动化 Agent。.opencode/agent/ 目录还包含ci-fixer.mdCI 修复与issue-fixer.mdissue 修复。结合 sync.md 的自动化设计可以拼出完整闭环同步工作流生成模型变更 PR → pr-reviewer 评审模型目录变更 → 对于 sync 无法安全自动创建而需要人工补元数据的模型运行器会通过去重机制打开[missing-model]GitHub issue标题固定为[missing-model] provider: model-id带automation/model-sync/missing-model标签并显式 dispatch issue-fixer 工作流由 issue-fixer 研究缺失元数据并开出模型 PR——这些 PR 最终又会回到 pr-reviewer 的评审管线。也就是说pr-reviewer 是这条“模型目录自动化流水线”的质检关卡它不产出数据只负责把不符合 AGENTS.md 规范、schema 校验与 reasoning 策略的变更挡在合并之前同时用mark-pr-ready对合规变更放行。总结.opencode/agent/pr-reviewer.md描述的是一个职责高度聚焦、权限严格收敛、输出高度结构化的自动化评审 Agent它只读基线与 diff、只遵循 AGENTS.md / README / SKILL 的既定标准、只输出可执行的 action item并在零问题时通过mark-pr-ready放行。其背后的五类阻断规则logo、base_model、冗余覆盖、reasoning_options、USD 成本与仓库的 schema、深合并逻辑、同步脚本和 reasoning 审计 SKILL 一一对应构成了 models.dev 社区贡献质量的自动化防线。对希望参与 models.dev 数据维护的开发者而言这份文档同时是一份“评审视角的贡献规范”——按它的规则编写 TOMLPR 就能顺利通过自动化审查并更快进入合并。赞分享人工智能大模型后端前端【免费下载链接】models.devAn open-source database of AI models.项目地址https://gitcode.com/gh_mirrors/mo/models.dev点击查看免费下载相关推荐EmDash 自动化 PR 审查auto-reviewer Agent 的设计、调查流程与结构化反馈实践EmDash 自动化 PR 审查auto reviewer Agent 的设计、调查流程与结构化反馈实践 导读 本文以 EmDash 仓库中的 .opencoCMS后端前端插件系统Aperant 安全评审 Agent 实战指南PR 深度安全审计的职责界定、触发式探查与证据化输出Aperant 安全评审 Agent 实战指南PR 深度安全审计的职责界定、触发式探查与证据化输出 导读 AperantAutonomous multi s人工智能AI Agent自主智能体代码智能体桌面应用前端开发工具Claude Cookbooks 的 CI 自动化 PR 审查命令review-pr-ci 的设计与实现全解Claude Cookbooks 的 CI 自动化 PR 审查命令review pr ci 的设计与实现全解 Claude Cookbooks 这个 Note示例工程上一篇TEKLauncher方舟生存进化MOD管理的终极解决方案下一篇三步命令备份QQ空间全部历史说说GetQzonehistory上手教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考