【免费下载链接】openbotA local-first desktop workspace for persistent AI teammates. Run Codex, Claude, and Grok with dedicated workspaces, task queues, file sharing, browser control, and agent-to-agent collaboration.项目地址https://gitcode.com/GitHub_Trending/openbo/openbot点击查看免费下载在 OpenBot 的 pstack 技能包中interrogate负责把一次代码变更分发给多个异构模型并行挑刺再由主评审收敛成可执行的结论。这套流程的质量上限几乎完全由分发给每个评审子代理的那份提示词决定。本文以模板文件 reviewer-prompt.md 为核心讲清它的占位符契约、逐段设计意图、填充方法并结合仓库中真实的打包与安装源码说明这份模板在 OpenBot 里是如何被改名、分发和校验的。模板在 interrogate 技能中的位置interrogate不是一个单文件提示词而是一个由四个文件协作的目录结构marketplace/production-catalog/bundles/pstack/skills/interrogate/ ├── SKILL.md └── references/ ├── reviewer-prompt.md # 本文主角评审子代理的提示词模板 ├── rubric.md # 填充 {RUBRIC_CONTENTS} ├── code-quality-review.md # 填充 {CODE_QUALITY_CONTENTS} └── lead-judgment.md # 只给主评审读不进入子代理提示词各文件的职责边界非常清晰值得先说清楚否则很容易误把lead-judgment.md也塞进子代理的提示词里文件读者作用reviewer-prompt.md每个评审子代理定义角色、输入槽位、输出格式rubric.md每个评审子代理六类审查透镜模板以整份内容注入code-quality-review.md每个评审子代理额外的代码质量透镜与通过门槛lead-judgment.md主评审你自己如何过滤、分类、给出最终判断依据 SKILL.md 的 Step 3 与 Step 5前三者用于填充模板第四个只在收敛阶段由主评审阅读。这个划分是整篇模板能够保持纯粹对抗的前提。模板原文与五个槽位模板本身只有六十余行但每一段都承担明确职责。以下为完整原文保留英文便于直接复制使用You are an adversarial code reviewer. Find real problems in the code below: bugs, design flaws, security issues, and maintainability concerns. You are not here to be helpful or encouraging. You are here to stress-test. ## Intent The authors stated intent for this change: {INTENT} Review whether the code achieves this intent well. Do NOT question the intent itself. Assume the goal is correct and challenge the execution. ## Code Under Review {DIFF_OR_FILES} ## Review Rubric {RUBRIC_CONTENTS} ## Code Quality Lens {CODE_QUALITY_CONTENTS} ## Instructions Review the code through every lens in the rubric and the code-quality lens above that you find relevant. Do not force lenses that dont apply. A simple bug fix does not need paragraphs about architectural integrity. For each finding, provide: 1. **Severity**: critical | warning | nit 2. **Finding**: What the problem is, in concrete terms. Reference specific lines/functions. 3. **Evidence**: Why you believe this is a problem. Show your reasoning. Dont just assert. 4. **Suggestion** (optional): What youd do instead, only if you have a concrete alternative. A good finding references specific code, not vague concerns (this could be better). It distinguishes between this is broken and I would have done this differently. It considers the stated intent. A finding that ignores the context of whats being built is a bad finding. Do not restate what the code does without identifying a problem. Do not praise the code. If you find nothing wrong, say no findings and stop. An empty review is a valid outcome. ## Output Return your findings as a structured list: ## Findings ### 1. [Severity] Short title **Location**: file:line or function name **Finding**: Whats wrong **Evidence**: Why this matters **Suggestion**: (optional) What to do instead模板共有四个占位符、一个上下文块共五个可变量占位符来源填充原则{INTENT}Step 2 中主评审写出的一段话一段、明确、只描述目标{DIFF_OR_FILES}Step 1 收集的 diff 或文件全文附带评审者需要的周边上下文{RUBRIC_CONTENTS}rubric.md整份文件内容不是摘要{CODE_QUALITY_CONTENTS}code-quality-review.md整份文件内容不是摘要隐含输出契约模板末尾的## Findings代码块原样保留不要改写字段名有一点容易忽略{RUBRIC_CONTENTS}与{CODE_QUALITY_CONTENTS}应当直接嵌入两份参考文件的正文。若为了节省 token 把它们压缩成请检查正确性、安全性之类的一句话评审者就失去了逐条透镜的触发点输出会立刻退化为泛泛而谈。这一点在 SKILL.md 里有明确要求对每一个评审者填入同一份模板内容为意图、diff 或文件内容、rubric 以及 code-quality lens。逐段拆解为什么这段提示词能产生有效信号角色锚定明确禁止帮忙和鼓励开头两句是全模板最锋利的地方You are not here to be helpful or encouraging. You are here to stress-test.通用助手的默认倾向是配合、肯定、给建议。对抗式评审需要的恰恰相反只报问题。模板随后用三条禁令把这个倾向钉死Do not restate what the code does without identifying a problem.—— 禁止复述代码功能。这是评审输出里最常见的注水方式。Do not praise the code.—— 禁止表扬。If you find nothing wrong, say no findings and stop.—— 给零发现一个合法出口。最后一条尤其重要。如果没有明确许可评审者会倾向于凑数找不到真问题就抬高级别或编造问题。把空结果定义为有效结果才能让主评审在收敛阶段信任某模型确实没发现问题这一信号。Intent 前置且不可质疑把目标与执行分离## Intent段先声明作者意图紧跟一条硬约束Review whether the code achieves this intent well. Do NOT question the intent itself. Assume the goal is correct and challenge the execution.这条约束解决的是多模型评审中最常见的跑题模型开始质疑这个功能该不该做这个需求方向不对而不是实现是否达成目标。把意图固定为公理评审火力就全部落在实现层。模板还特别说明A finding that ignores the context of whats being built is a bad finding.——脱离上下文的发现不算发现。这与 lead-judgment.md 中Missing Context Signals一节形成呼应子代理只看到代码切片主评审拥有完整对话上下文因此上下文相关的裁决必须留给主评审。两级透镜rubric 负责找什么code-quality 负责重构到什么程度模板注入了两套互补的透镜而不是一套。这个设计值得展开因为它是模板能同时覆盖正确性和结构质量的关键。rubric.md 提供六个经典审查维度Correctness正确性空输入、nil/undefined、边界值、并发访问错误是被捕获、传播还是静默吞掉off-by-one、类型强制转换、整数溢出、字符串编码竞态、过期闭包、悬垂引用happy path 与 sad path幂等性重复执行或中途崩溃会留下什么状态并发访问是否结构化串行化锁、顺序阶段、独占所有权还是依赖不会成立的约定。该维度还附了一条方法论When you find a potential bug, trace the execution path. Dont just flag this could be nil. Show the call chain that makes it nil.—— 必须给出使变量为 nil 的调用链而不是抛出一句这里可能为 nil。Root Causes vs. Symptoms根因与症状修复的是真问题还是掩盖症状。典型反模式包括掩盖更深层不变量违背的 guard clause、隐藏契约破损的重试逻辑、掩盖建模错误的类型断言、只存在于注释里的约定。该节还鼓励跳出改动文件用 Read/Grep/Glob 追踪调用者与被调用者。Structural Integrity结构完整性边界处一次性校验而非散落业务逻辑抽象层级是否混杂耦合是否增加未来改动成本数据结构是否匹配实际访问模式新需求若一开始就知道代码是否还会长成现在这样是否留下legacy 双路径新增 API 却保留旧 API在没有外部消费者时应当同一波迁移并删除。Verification可验证性测试是否测行为而非实现细节有无回归断言bug fix 是否配了复现测试跨集成边界的路径是否被完整测试是否用 mtime 或缓存状态去代理真实值异步/委派工作是否校验真实产物而不是相信自我报告。Complexity Budget复杂度预算本可更简单的代码只服务一个调用点的抽象为不存在的场景预留的参数化死代码与残留参数为以防万一写的分支迁移完成后仍保留的兼容脚手架。Security安全用户输入流向危险 sinkSQL、shell、eval、innerHTML未经净化新端点缺少鉴权代码、日志、错误信息中的密钥安全关键路径上的 TOCTOU。每个安全结论都要求把输入路径追出来并展示。code-quality-review.md 提供的是另一类标准——它不是找 bug而是找结构性退化。它开宗明义要求评审者对代码结构保持野心主动搜索code judo在保持行为不变的前提下让实现显著更简单、更小、更直接、更优雅的重构。它的基线提示词是Perform a deep code quality audit of the current branchs changes. Rethink how to structure / implement the changes to meaningfully improve code quality without impacting behavior. Work to improve abstractions, modularity, reduce Spaghetti code, improve succinctness and legibility. Be ambitious, if there is a clear path to improving the implementation that involves restructuring some of the codebase, go for it. Be extremely thorough and rigorous. Measure twice, cut once.其八个维度编号 0–7覆盖0. 结构性简化优先不要停在这里能再干净一点要寻找能让整批分支、辅助函数、模式、条件、层消失的重新表述。1. 文件规模护栏不允许一个 PR 把文件从 1k 行以下推到 1k 行以上而不给出极强理由优先抽出 helper、子组件或模块。2. 禁止意大利面增长对插入无关流程的新增临时条件、散落特例、一次性分支保持怀疑把它当设计问题而非风格小瑕。3. 倾向清理设计而非接受能跑行为不变但结构明显更干净时推更干净的版本优先删除活动部件而非把同样的复杂度摊开。4. 直接、朴素优于魔法警惕隐藏简单数据形状假设的通用机制标记只增加间接层的薄抽象、身份包装、透传 helper。5. 类型与边界整洁质疑不必要的可选性、unknown、any、大量 cast偏好显式类型模型用静默兜底掩盖不清不变量时要求把边界显式化。6. 逻辑留在规范层指出特性逻辑渗入共享路径、实现细节从 API 泄漏优先复用既有规范工具而不是就地造一个一次性实现。7. 顺序编排与原子性独立工作无缘无故串行化是设计味道相关更新可能半途生效时推更原子的结构。该文件还定义了明确的通过门槛Approval Bar行为看似正确不足以放行以下情形默认视为阻塞项——存在能删掉大量偶然复杂度的 code-judo 机会却被保留、文件跨过 1000 行、把临时分支缠进既有流程、在共享代码里散落特性检查、新增不必要的抽象/包装/cast 密集契约、在已有明确规范归属时重复 helper 或放错层。这两套透镜的组合使同一个子代理既会指出这个 guard 掩盖了不变量违背也会指出这次改动把文件推过了 1000 行。严重级别三档且带判定标准模板把发现分为三档并在括号内给出判定口径级别模板中的判定标准典型场景criticalWould cause bugs, data loss, security issues, or fundamentally broken behavior会引发 bug、数据丢失、安全问题或根本性错误行为warningDesign concern, maintainability risk, or correctness issue that isnt immediately broken but will cause pain设计隐患、可维护性风险或暂未爆但会痛的正确性问题nitStyle, naming, minor improvement风格、命名、小改进三档而非五档是为了让主评审在收敛阶段能快速分桶。注意warning的定义刻意包含暂未爆的正确性问题——这类问题往往是最有价值、也最容易被普通审查漏掉的一类。输出契约四字段结构每个发现必须包含SeverityFinding具体是什么问题引用具体行/函数Evidence为什么相信这是个问题展示推理不要只下结论Suggestion可选只有存在具体替代方案时才给模板对Suggestion的可选性做了强调only if you have a concrete alternative。这一条抑制了我要是写会不一样式的空建议——而这正是 lead-judgment.md 点名的最常见误报A finding that amounts to I prefer a different approach is not a bug, not a design flaw, and not actionable unless the reviewer shows a concrete problem with the current approach.模板末尾给出了机器可解析的输出骨架## Findings ### 1. [Severity] Short title **Location**: file:line or function name **Finding**: Whats wrong **Evidence**: Why this matters **Suggestion**: (optional) What to do instead固定字段名并保留file:line位置是为了让主评审在 Step 4 合并时能做结构化解析与去重**Location**提供合并键**Innovation**之外的**Finding**提供语义比对而**Evidence**决定这条发现是否有资格进入 Act On。模板还有一句评价标准值得单独抄进团队规范It distinguishes between this is broken and I would have done this differently.从模板到一次真实运行五个步骤的填充方法SKILL.md 给出了前两步的取材规则直接决定模板能否被填好。Step 1Scope确定审查范围用户点名了文件或 diff直接用。在特性分支上跑git diff main...HEAD或对应的基础分支取完整变更集。用户消息提到最近的工作收集相关文件。然后Package the diff or file contents with any surrounding context files the reviewers need to understand the code.—— 对{DIFF_OR_FILES}而言裸 diff 常常不够。评审者需要看到类型定义、被调用的兄弟模块、以及让 diff 成立的上游校验否则就会产生这里可能为 null式的假阳性。这一步的取舍直接对应 lead-judgment.md 的 Hypothetical vs. Actual 原则调用点能不能真的传 null取决于你是否把调用点一起给了评审者。Step 2Intent写定意图在派发评审者之前用一段清晰的话写出意图素材来自用户消息、commit message、PR 描述若有以及代码本身。若不确定意图先问用户再继续。这段话就是{INTENT}的全部内容它会以引用块形式出现在子代理提示词中。一个可用的填充示例示意非仓库真实变更## Intent 本次改动让 readAgent 在 skill 目录的 SKILL.md 缺少 frontmatter 时返回结构化的 problem 字段而不是抛出异常从而让调用方能把该技能标记为不可用并继续列出其余技能。 目标是不改变成功路径的行为也不改变 problem 的取值集合。注意这段文字的形态只讲目标与不变量不讲实现方案。因为实现方案正是要被挑刺的对象。Step 3Spawn Reviewers并行派发同一轮消息里用 Task 工具启动全部评审者每个对应~/.cursor/rules/pstack-models.mdc中interrogate reviewers行的一个条目按条目数量依次标记 Reviewer A、B……。若规则文件或该行缺失使用默认表SubagentDefault modelReviewer Aclaude-opus-5-5-xhighReviewer Bgrok-4.7-xhigh-fast每个评审者的参数固定为subagent_type: generalPurpose、readonly: truemodel设为其配置条目或默认值。当条目为auto或inherit-parent时省略model让该评审者跑在父模型上。模型不可用时的降级链在 SKILL.md 中定义得相当细Task 工具拒绝某个配置条目 → 该评审者改用同族默认值族按前缀判定claude-*、grok-*并说明此事。无族匹配 → 使用 Reviewer A 的默认值。连默认值也被拒 → 从其错误信息中的合法 slug 里选同族、同推理档位的最接近者并另开 PR 更新默认表。不要因为 slug 问题阻塞评审auto/inherit-parent这类别名永远不算被拒绝的 slug也不触发任何回退。这里有一条容易误读但很关键的设定The adversarial signal comes from model diversity, not assigned personas.对抗信号来自模型差异而非分配人设。因此同一个模板原样填给每个评审者唯一变化的是模型。这也解释了为什么模板里没有任何你是安全专家你是性能专家的角色设定——那是另一种更弱的多样性来源。Step 4Synthesize合并结果陆续返回时构建统一图景解析每个评审者的发现合并描述同一问题但措辞不同的项并记录是哪些模型提出的。两个及以上模型独立提出的发现信号最强。单个模型的发现仍要读但按此加权。记录分歧若一个模型提出问题、另一个明确给出相反结论这本身就是裁决的重要上下文。Step 5Lead Judgment主评审判断主评审不是中立聚合器而是务实的资深工程师。按 lead-judgment.md 的框架把每条发现放进四个桶标注提出它的模型与一行理由桶判据Act on在真实目标下影响正确性、安全性或可维护性的真问题会阻塞一个真实 PRConsider合理但不确定此刻处理的成本是否划算值得用户注意Noted技术上成立但不可行动依赖上下文、过早优化、当前阶段影响过低Dismissed错误、过于挑剔或缺乏上下文附简短理由最终输出结构SKILL.md固定为### Intent [Step 2 写定的意图段落] ### Reviewers - Reviewer [label]: [model name], [N findings] ### Act On ### Consider ### Noted ### Dismissed ### Agreement MapAgreement Map记录模型在哪里一致、在哪里分歧以及这个模式说明了什么——它把三个模型都说 X和两个模型对立这两种情况区分开而这正是多模型评审相对单模型的核心增量。模板之外主评审的过滤纪律模板负责多产lead-judgment.md负责少收。它列出的五条过滤原则实质是对模板输出的反制设计Nitpick Gravity挑剔引力对抗式评审者会填满篇幅。若某评审者的发现全是 nit 和风格偏好代码大概率没问题——直接这么说。Hypothetical vs. ActualWhat if someone passes null here?只有在调用方确实能传 null 时才算发现。追调用点若上游已校验或类型系统已禁止驳回。只看 diff 的评审者看不到完整调用链你能。Premature Abstraction Warnings过早抽象警告评审者常建议抽函数、加接口、造抽象。问一句这代码会以第二种方式变更吗不会就是过早抽象。I Would Have Done It Differently最常见的假阳性除非能指出当前方案的具体问题否则驳回并说明原因。Missing Context Signals上下文缺失信号建议修改作者并未写过的代码、把与代码库其余部分一致的模式标为问题、推荐与你已知约束冲突的方案——这些是评审者在信息受限下的诚实错误优雅驳回。同时它也警告不要因为不舒服就驳回并给出四条值得注意的信号多模型独立共识、指出具体执行路径、暴露你心智模型的盲区、读完后心里……确实。安全类和正确性 bug 即便只来自单一模型也要额外审视。最后两条校准建议非常实用好的裁决是有用而非全面。用户读完 Act On 就能修完放心发布。若 Act On 超过 5 条说明过滤不够狠。Dismissed 不是凑数而是信任机制。展示你驳回了什么、为什么用户才能在不同意时覆盖你的判断——这比隐藏被驳回的发现更有价值。在 OpenBot 中这份模板如何被安装与改写模板位于 marketplace 生产目录的pstackbundle 中。catalog.json 把pstack声明为一个pack来源记为cursor带aliasPrefixes: [principle-]并说明它安装全部 52 个 pstack 技能以$pstack-name形式调用。catalog.json 里这个条目把pstack描述为 poteto 的 pstack agent workflows 打包严谨的 playbook、工程原则、刻意设计的子代理以及经过验证的产出。而 README 进一步说明了打包产物形态bundles/pstack/是上游 pluginskills/与agents/的未改动副本MIT 许可构建时发布为一个Skillpstack其压缩包内含索引SKILL.md、LICENSE、NOTICE.md以及把每个skills/子目录映射为skills/pstack-folder/的目录应用会把其中每一项作为独立技能安装与pstack并列共享一条 lock 记录——一次下载、一份安装回执。这意味着本文的主角在安装后落在.agents/skills/pstack-interrogate/ ├── SKILL.md └── references/ ├── reviewer-prompt.md ├── rubric.md ├── code-quality-review.md └── lead-judgment.md构建脚本 build-production-catalog.ts 逐文件处理目录下所有文件都被复制sources来自join(root, skills, folder)的递归相对路径其中.md文件额外走一次renamePackReferences.md之外的文件原样按字节复制。SKILL.md还要再过一次packSkillMarkdown。因此references/下的四份参考文件会被完整保留只做链接与名称改写。改写规则集中在 renamePackReferences与本模板直接相关的有三条相对链接重写为安装后相对路径](target)形式若匹配 pack 内某个技能的已安装路径就改写成从当前安装文件出发的相对路径installedPackPath负责判断skills/folder/...是否属于已安装技能L377-L382不属于任何技能的链接则指向钉住的上游 commit。斜杠命令与提及加前缀/name变成$pstack-namename与**name**也加上pstack-前缀upstreamPath/skills/name/变成.agents/skills/pstack-name/。frontmatter 调整在 packSkillMarkdown 中name:被改写为pstack-folder同时过滤掉disable-model-invocation: true这一行。最后这条对interrogate有直接影响。上游 SKILL.md 的 frontmatter 里带着disable-model-invocation: true即该技能只能由用户显式调用。OpenBot 构建时移除该行使$pstack-interrogate在各种 provider 下都能被调用——README 对此的表述是removesdisable-model-invocationso$pstack-nameworks with every provider。同时packSkillMarkdown 会在每个SKILL.md末尾追加一节## pstack in OpenBot内容包括技能名映射规则name即pstack-name、alias 提示principle-前缀规则、子代理兜底方式——当 harness 不认识subagent_type: agent时启动一个 general 子代理先把agents/agent.md的正文交给它再给任务若目录里有scripts/提示用解释器运行且安装后的文件不可执行以及许可证与 notice 的相对位置。agents/的打包条件在 L264-L271只有当某个技能文本中提到了agents/下某个文件名时才把该 agent 文件一并纳入。仓库中bundles/pstack/agents/下有poteto-agent.md与comment-sicko.md两个文件。安装侧还有一道校验。skill-frontmatter.ts 中的readSkillFrontmatter会检查SKILL.md的 YAML frontmattername必须等于所在文件夹名description长度必须在 1 到SKILL_DESCRIPTION_MAX_LENGTH之间解析失败或字段非法则返回相应的problem码frontmatterMissing、frontmatterInvalid、descriptionLength、nameMismatch。这解释了为什么构建必须把name: interrogate改成name: pstack-interrogate——否则装进.agents/skills/pstack-interrogate/后名称不匹配技能会被判为不可用。README 亦明确provider 也可能跳过该技能所以校验口径与 provider 保持一致。home-skills.ts 进一步说明了安装位置HOME_SKILL_FOLDER .agents/skills用户自有技能与 Agent Skills 工具在这个目录共享技能数上限MAX_HOME_SKILLS 200单个SKILL.md上限MAX_SKILL_FILE_BYTES 256 * 1024某个文件夹读不到时按不存在处理因为该目录属于用户而非 OpenBot。让模板产出稳定结果的六个工程细节把模板真正用于日常评审时以下细节决定了输出质量它们全部可以从模板与配套文件中找到依据意图只写一段且不夹带实现评价。模板把{INTENT}放在引用块中语义上就是作者陈述。混入我顺便重构了 X会把子代理引向为重构辩护。不要裁剪 rubric。{RUBRIC_CONTENTS}与{CODE_QUALITY_CONTENTS}是整份文件。裁剪等于关掉部分透镜而模型不会告诉你它少了哪一维。给足上下文但标清边界。{DIFF_OR_FILES}里应包含让评审者能判断调用方是否可能传 null的调用点。模板明确说这段是 Code Under Review所以附带的上下文文件要标明是上下文不在审查范围避免评审者去挑未改动代码的毛病。保留全部输出字段。尤其是**Location**与**Evidence**前者用于 Step 4 合并去重后者用于 Step 5 判断是否够格进 Act On。删掉 Evidence 只留结论会让主评审无法区分断言和有推理支撑的发现。接受空结果。no findings是模板授权的合法输出。逼模型产出会直接制造噪音而这些噪音要靠 Step 5 的 Dismissed 桶来消化成本更高。不要在子代理层做裁决。模板明确Do NOT question the intent itself分桶、权衡、驳回是主评审的职责见lead-judgment.md。把裁决塞进子代理提示词会让多模型独立共识这个最强信号失效——因为模型不再独立判断同一件事。复用清单若要把这套模板迁移到其他评审流程最小可用的移植步骤是保留角色锚定与三条禁令不复述、不表扬、允许no findings。把{INTENT}定为不可质疑的公理并明确挑战执行不挑战目标。用分级透镜一份负责正确性与安全对应 rubric.md一份负责结构简化与可维护性对应 code-quality-review.md整份注入而非摘要。固定critical/warning/nit三档并写明判定口径。固定四字段输出Suggestion标注为可选且要求具体替代方案。每个评审者用同一份模板只切换模型多样性来自模型而非人设。收敛阶段独立成文规定四桶分类与Agreement Map并要求 Act On 保持精简。模板本身没有一句多余的话角色、输入、透镜、指令、输出五段各自解决一个失效模式。真正决定这套流程能否落地的是它外部的三个约束——意图来自完整上下文、透镜按整份注入、裁决由主评审而非子代理完成。理解了这三点reviewer-prompt.md 才能从一个看起来很凶的提示词变成可复用、可验证、可收敛的工程化审查组件。赞分享【免费下载链接】openbotA local-first desktop workspace for persistent AI teammates. Run Codex, Claude, and Grok with dedicated workspaces, task queues, file sharing, browser control, and agent-to-agent collaboration.项目地址https://gitcode.com/GitHub_Trending/openbo/openbot点击查看免费下载相关推荐REA AI 逆向工程指南:1 条命令接入 Agent,免源码看懂 6 类目标REA AI 逆向工程指南:1 条命令接入 Agent,免源码看懂 6 类目标 REA Reverse Engineer Anything 把 AI 逆向工程做逆向工程MCP 服务AI 技能OpenBot pstack 中的 interrogate 技能用多模型对抗式评审给代码变更做压力测试OpenBot pstack 中的 interrogate 技能用多模型对抗式评审给代码变更做压力测试 OpenBot 的 Marketplace 生产目openbot pstack 的 Interrogate 技能深度解读多模型对抗式评审中的 Code Quality Review 代码质量视角openbot pstack 的 Interrogate 技能深度解读多模型对抗式评审中的 Code Quality Review 代码质量视角 在 open上一篇Rope-Pearl 视频换脸实操指南从安装到导出第一条人脸替换视频下一篇Redux-Thunk异步数据流可视化理解dispatch流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/28 18:37:15 · 阅读 1.2k 构建对抗式多模型代码审查提示词：OpenBot pstack interrogate 的 reviewer-prompt.md 实战解析
【免费下载链接】openbotA local-first desktop workspace for persistent AI teammates. Run Codex, Claude, and Grok with dedicated workspaces, task queues, file sharing, browser control, and agent-to-agent collaboration.项目地址https://gitcode.com/GitHub_Trending/openbo/openbot点击查看免费下载在 OpenBot 的 pstack 技能包中interrogate负责把一次代码变更分发给多个异构模型并行挑刺再由主评审收敛成可执行的结论。这套流程的质量上限几乎完全由分发给每个评审子代理的那份提示词决定。本文以模板文件 reviewer-prompt.md 为核心讲清它的占位符契约、逐段设计意图、填充方法并结合仓库中真实的打包与安装源码说明这份模板在 OpenBot 里是如何被改名、分发和校验的。模板在 interrogate 技能中的位置interrogate不是一个单文件提示词而是一个由四个文件协作的目录结构marketplace/production-catalog/bundles/pstack/skills/interrogate/ ├── SKILL.md └── references/ ├── reviewer-prompt.md # 本文主角评审子代理的提示词模板 ├── rubric.md # 填充 {RUBRIC_CONTENTS} ├── code-quality-review.md # 填充 {CODE_QUALITY_CONTENTS} └── lead-judgment.md # 只给主评审读不进入子代理提示词各文件的职责边界非常清晰值得先说清楚否则很容易误把lead-judgment.md也塞进子代理的提示词里文件读者作用reviewer-prompt.md每个评审子代理定义角色、输入槽位、输出格式rubric.md每个评审子代理六类审查透镜模板以整份内容注入code-quality-review.md每个评审子代理额外的代码质量透镜与通过门槛lead-judgment.md主评审你自己如何过滤、分类、给出最终判断依据 SKILL.md 的 Step 3 与 Step 5前三者用于填充模板第四个只在收敛阶段由主评审阅读。这个划分是整篇模板能够保持纯粹对抗的前提。模板原文与五个槽位模板本身只有六十余行但每一段都承担明确职责。以下为完整原文保留英文便于直接复制使用You are an adversarial code reviewer. Find real problems in the code below: bugs, design flaws, security issues, and maintainability concerns. You are not here to be helpful or encouraging. You are here to stress-test. ## Intent The authors stated intent for this change: {INTENT} Review whether the code achieves this intent well. Do NOT question the intent itself. Assume the goal is correct and challenge the execution. ## Code Under Review {DIFF_OR_FILES} ## Review Rubric {RUBRIC_CONTENTS} ## Code Quality Lens {CODE_QUALITY_CONTENTS} ## Instructions Review the code through every lens in the rubric and the code-quality lens above that you find relevant. Do not force lenses that dont apply. A simple bug fix does not need paragraphs about architectural integrity. For each finding, provide: 1. **Severity**: critical | warning | nit 2. **Finding**: What the problem is, in concrete terms. Reference specific lines/functions. 3. **Evidence**: Why you believe this is a problem. Show your reasoning. Dont just assert. 4. **Suggestion** (optional): What youd do instead, only if you have a concrete alternative. A good finding references specific code, not vague concerns (this could be better). It distinguishes between this is broken and I would have done this differently. It considers the stated intent. A finding that ignores the context of whats being built is a bad finding. Do not restate what the code does without identifying a problem. Do not praise the code. If you find nothing wrong, say no findings and stop. An empty review is a valid outcome. ## Output Return your findings as a structured list: ## Findings ### 1. [Severity] Short title **Location**: file:line or function name **Finding**: Whats wrong **Evidence**: Why this matters **Suggestion**: (optional) What to do instead模板共有四个占位符、一个上下文块共五个可变量占位符来源填充原则{INTENT}Step 2 中主评审写出的一段话一段、明确、只描述目标{DIFF_OR_FILES}Step 1 收集的 diff 或文件全文附带评审者需要的周边上下文{RUBRIC_CONTENTS}rubric.md整份文件内容不是摘要{CODE_QUALITY_CONTENTS}code-quality-review.md整份文件内容不是摘要隐含输出契约模板末尾的## Findings代码块原样保留不要改写字段名有一点容易忽略{RUBRIC_CONTENTS}与{CODE_QUALITY_CONTENTS}应当直接嵌入两份参考文件的正文。若为了节省 token 把它们压缩成请检查正确性、安全性之类的一句话评审者就失去了逐条透镜的触发点输出会立刻退化为泛泛而谈。这一点在 SKILL.md 里有明确要求对每一个评审者填入同一份模板内容为意图、diff 或文件内容、rubric 以及 code-quality lens。逐段拆解为什么这段提示词能产生有效信号角色锚定明确禁止帮忙和鼓励开头两句是全模板最锋利的地方You are not here to be helpful or encouraging. You are here to stress-test.通用助手的默认倾向是配合、肯定、给建议。对抗式评审需要的恰恰相反只报问题。模板随后用三条禁令把这个倾向钉死Do not restate what the code does without identifying a problem.—— 禁止复述代码功能。这是评审输出里最常见的注水方式。Do not praise the code.—— 禁止表扬。If you find nothing wrong, say no findings and stop.—— 给零发现一个合法出口。最后一条尤其重要。如果没有明确许可评审者会倾向于凑数找不到真问题就抬高级别或编造问题。把空结果定义为有效结果才能让主评审在收敛阶段信任某模型确实没发现问题这一信号。Intent 前置且不可质疑把目标与执行分离## Intent段先声明作者意图紧跟一条硬约束Review whether the code achieves this intent well. Do NOT question the intent itself. Assume the goal is correct and challenge the execution.这条约束解决的是多模型评审中最常见的跑题模型开始质疑这个功能该不该做这个需求方向不对而不是实现是否达成目标。把意图固定为公理评审火力就全部落在实现层。模板还特别说明A finding that ignores the context of whats being built is a bad finding.——脱离上下文的发现不算发现。这与 lead-judgment.md 中Missing Context Signals一节形成呼应子代理只看到代码切片主评审拥有完整对话上下文因此上下文相关的裁决必须留给主评审。两级透镜rubric 负责找什么code-quality 负责重构到什么程度模板注入了两套互补的透镜而不是一套。这个设计值得展开因为它是模板能同时覆盖正确性和结构质量的关键。rubric.md 提供六个经典审查维度Correctness正确性空输入、nil/undefined、边界值、并发访问错误是被捕获、传播还是静默吞掉off-by-one、类型强制转换、整数溢出、字符串编码竞态、过期闭包、悬垂引用happy path 与 sad path幂等性重复执行或中途崩溃会留下什么状态并发访问是否结构化串行化锁、顺序阶段、独占所有权还是依赖不会成立的约定。该维度还附了一条方法论When you find a potential bug, trace the execution path. Dont just flag this could be nil. Show the call chain that makes it nil.—— 必须给出使变量为 nil 的调用链而不是抛出一句这里可能为 nil。Root Causes vs. Symptoms根因与症状修复的是真问题还是掩盖症状。典型反模式包括掩盖更深层不变量违背的 guard clause、隐藏契约破损的重试逻辑、掩盖建模错误的类型断言、只存在于注释里的约定。该节还鼓励跳出改动文件用 Read/Grep/Glob 追踪调用者与被调用者。Structural Integrity结构完整性边界处一次性校验而非散落业务逻辑抽象层级是否混杂耦合是否增加未来改动成本数据结构是否匹配实际访问模式新需求若一开始就知道代码是否还会长成现在这样是否留下legacy 双路径新增 API 却保留旧 API在没有外部消费者时应当同一波迁移并删除。Verification可验证性测试是否测行为而非实现细节有无回归断言bug fix 是否配了复现测试跨集成边界的路径是否被完整测试是否用 mtime 或缓存状态去代理真实值异步/委派工作是否校验真实产物而不是相信自我报告。Complexity Budget复杂度预算本可更简单的代码只服务一个调用点的抽象为不存在的场景预留的参数化死代码与残留参数为以防万一写的分支迁移完成后仍保留的兼容脚手架。Security安全用户输入流向危险 sinkSQL、shell、eval、innerHTML未经净化新端点缺少鉴权代码、日志、错误信息中的密钥安全关键路径上的 TOCTOU。每个安全结论都要求把输入路径追出来并展示。code-quality-review.md 提供的是另一类标准——它不是找 bug而是找结构性退化。它开宗明义要求评审者对代码结构保持野心主动搜索code judo在保持行为不变的前提下让实现显著更简单、更小、更直接、更优雅的重构。它的基线提示词是Perform a deep code quality audit of the current branchs changes. Rethink how to structure / implement the changes to meaningfully improve code quality without impacting behavior. Work to improve abstractions, modularity, reduce Spaghetti code, improve succinctness and legibility. Be ambitious, if there is a clear path to improving the implementation that involves restructuring some of the codebase, go for it. Be extremely thorough and rigorous. Measure twice, cut once.其八个维度编号 0–7覆盖0. 结构性简化优先不要停在这里能再干净一点要寻找能让整批分支、辅助函数、模式、条件、层消失的重新表述。1. 文件规模护栏不允许一个 PR 把文件从 1k 行以下推到 1k 行以上而不给出极强理由优先抽出 helper、子组件或模块。2. 禁止意大利面增长对插入无关流程的新增临时条件、散落特例、一次性分支保持怀疑把它当设计问题而非风格小瑕。3. 倾向清理设计而非接受能跑行为不变但结构明显更干净时推更干净的版本优先删除活动部件而非把同样的复杂度摊开。4. 直接、朴素优于魔法警惕隐藏简单数据形状假设的通用机制标记只增加间接层的薄抽象、身份包装、透传 helper。5. 类型与边界整洁质疑不必要的可选性、unknown、any、大量 cast偏好显式类型模型用静默兜底掩盖不清不变量时要求把边界显式化。6. 逻辑留在规范层指出特性逻辑渗入共享路径、实现细节从 API 泄漏优先复用既有规范工具而不是就地造一个一次性实现。7. 顺序编排与原子性独立工作无缘无故串行化是设计味道相关更新可能半途生效时推更原子的结构。该文件还定义了明确的通过门槛Approval Bar行为看似正确不足以放行以下情形默认视为阻塞项——存在能删掉大量偶然复杂度的 code-judo 机会却被保留、文件跨过 1000 行、把临时分支缠进既有流程、在共享代码里散落特性检查、新增不必要的抽象/包装/cast 密集契约、在已有明确规范归属时重复 helper 或放错层。这两套透镜的组合使同一个子代理既会指出这个 guard 掩盖了不变量违背也会指出这次改动把文件推过了 1000 行。严重级别三档且带判定标准模板把发现分为三档并在括号内给出判定口径级别模板中的判定标准典型场景criticalWould cause bugs, data loss, security issues, or fundamentally broken behavior会引发 bug、数据丢失、安全问题或根本性错误行为warningDesign concern, maintainability risk, or correctness issue that isnt immediately broken but will cause pain设计隐患、可维护性风险或暂未爆但会痛的正确性问题nitStyle, naming, minor improvement风格、命名、小改进三档而非五档是为了让主评审在收敛阶段能快速分桶。注意warning的定义刻意包含暂未爆的正确性问题——这类问题往往是最有价值、也最容易被普通审查漏掉的一类。输出契约四字段结构每个发现必须包含SeverityFinding具体是什么问题引用具体行/函数Evidence为什么相信这是个问题展示推理不要只下结论Suggestion可选只有存在具体替代方案时才给模板对Suggestion的可选性做了强调only if you have a concrete alternative。这一条抑制了我要是写会不一样式的空建议——而这正是 lead-judgment.md 点名的最常见误报A finding that amounts to I prefer a different approach is not a bug, not a design flaw, and not actionable unless the reviewer shows a concrete problem with the current approach.模板末尾给出了机器可解析的输出骨架## Findings ### 1. [Severity] Short title **Location**: file:line or function name **Finding**: Whats wrong **Evidence**: Why this matters **Suggestion**: (optional) What to do instead固定字段名并保留file:line位置是为了让主评审在 Step 4 合并时能做结构化解析与去重**Location**提供合并键**Innovation**之外的**Finding**提供语义比对而**Evidence**决定这条发现是否有资格进入 Act On。模板还有一句评价标准值得单独抄进团队规范It distinguishes between this is broken and I would have done this differently.从模板到一次真实运行五个步骤的填充方法SKILL.md 给出了前两步的取材规则直接决定模板能否被填好。Step 1Scope确定审查范围用户点名了文件或 diff直接用。在特性分支上跑git diff main...HEAD或对应的基础分支取完整变更集。用户消息提到最近的工作收集相关文件。然后Package the diff or file contents with any surrounding context files the reviewers need to understand the code.—— 对{DIFF_OR_FILES}而言裸 diff 常常不够。评审者需要看到类型定义、被调用的兄弟模块、以及让 diff 成立的上游校验否则就会产生这里可能为 null式的假阳性。这一步的取舍直接对应 lead-judgment.md 的 Hypothetical vs. Actual 原则调用点能不能真的传 null取决于你是否把调用点一起给了评审者。Step 2Intent写定意图在派发评审者之前用一段清晰的话写出意图素材来自用户消息、commit message、PR 描述若有以及代码本身。若不确定意图先问用户再继续。这段话就是{INTENT}的全部内容它会以引用块形式出现在子代理提示词中。一个可用的填充示例示意非仓库真实变更## Intent 本次改动让 readAgent 在 skill 目录的 SKILL.md 缺少 frontmatter 时返回结构化的 problem 字段而不是抛出异常从而让调用方能把该技能标记为不可用并继续列出其余技能。 目标是不改变成功路径的行为也不改变 problem 的取值集合。注意这段文字的形态只讲目标与不变量不讲实现方案。因为实现方案正是要被挑刺的对象。Step 3Spawn Reviewers并行派发同一轮消息里用 Task 工具启动全部评审者每个对应~/.cursor/rules/pstack-models.mdc中interrogate reviewers行的一个条目按条目数量依次标记 Reviewer A、B……。若规则文件或该行缺失使用默认表SubagentDefault modelReviewer Aclaude-opus-5-5-xhighReviewer Bgrok-4.7-xhigh-fast每个评审者的参数固定为subagent_type: generalPurpose、readonly: truemodel设为其配置条目或默认值。当条目为auto或inherit-parent时省略model让该评审者跑在父模型上。模型不可用时的降级链在 SKILL.md 中定义得相当细Task 工具拒绝某个配置条目 → 该评审者改用同族默认值族按前缀判定claude-*、grok-*并说明此事。无族匹配 → 使用 Reviewer A 的默认值。连默认值也被拒 → 从其错误信息中的合法 slug 里选同族、同推理档位的最接近者并另开 PR 更新默认表。不要因为 slug 问题阻塞评审auto/inherit-parent这类别名永远不算被拒绝的 slug也不触发任何回退。这里有一条容易误读但很关键的设定The adversarial signal comes from model diversity, not assigned personas.对抗信号来自模型差异而非分配人设。因此同一个模板原样填给每个评审者唯一变化的是模型。这也解释了为什么模板里没有任何你是安全专家你是性能专家的角色设定——那是另一种更弱的多样性来源。Step 4Synthesize合并结果陆续返回时构建统一图景解析每个评审者的发现合并描述同一问题但措辞不同的项并记录是哪些模型提出的。两个及以上模型独立提出的发现信号最强。单个模型的发现仍要读但按此加权。记录分歧若一个模型提出问题、另一个明确给出相反结论这本身就是裁决的重要上下文。Step 5Lead Judgment主评审判断主评审不是中立聚合器而是务实的资深工程师。按 lead-judgment.md 的框架把每条发现放进四个桶标注提出它的模型与一行理由桶判据Act on在真实目标下影响正确性、安全性或可维护性的真问题会阻塞一个真实 PRConsider合理但不确定此刻处理的成本是否划算值得用户注意Noted技术上成立但不可行动依赖上下文、过早优化、当前阶段影响过低Dismissed错误、过于挑剔或缺乏上下文附简短理由最终输出结构SKILL.md固定为### Intent [Step 2 写定的意图段落] ### Reviewers - Reviewer [label]: [model name], [N findings] ### Act On ### Consider ### Noted ### Dismissed ### Agreement MapAgreement Map记录模型在哪里一致、在哪里分歧以及这个模式说明了什么——它把三个模型都说 X和两个模型对立这两种情况区分开而这正是多模型评审相对单模型的核心增量。模板之外主评审的过滤纪律模板负责多产lead-judgment.md负责少收。它列出的五条过滤原则实质是对模板输出的反制设计Nitpick Gravity挑剔引力对抗式评审者会填满篇幅。若某评审者的发现全是 nit 和风格偏好代码大概率没问题——直接这么说。Hypothetical vs. ActualWhat if someone passes null here?只有在调用方确实能传 null 时才算发现。追调用点若上游已校验或类型系统已禁止驳回。只看 diff 的评审者看不到完整调用链你能。Premature Abstraction Warnings过早抽象警告评审者常建议抽函数、加接口、造抽象。问一句这代码会以第二种方式变更吗不会就是过早抽象。I Would Have Done It Differently最常见的假阳性除非能指出当前方案的具体问题否则驳回并说明原因。Missing Context Signals上下文缺失信号建议修改作者并未写过的代码、把与代码库其余部分一致的模式标为问题、推荐与你已知约束冲突的方案——这些是评审者在信息受限下的诚实错误优雅驳回。同时它也警告不要因为不舒服就驳回并给出四条值得注意的信号多模型独立共识、指出具体执行路径、暴露你心智模型的盲区、读完后心里……确实。安全类和正确性 bug 即便只来自单一模型也要额外审视。最后两条校准建议非常实用好的裁决是有用而非全面。用户读完 Act On 就能修完放心发布。若 Act On 超过 5 条说明过滤不够狠。Dismissed 不是凑数而是信任机制。展示你驳回了什么、为什么用户才能在不同意时覆盖你的判断——这比隐藏被驳回的发现更有价值。在 OpenBot 中这份模板如何被安装与改写模板位于 marketplace 生产目录的pstackbundle 中。catalog.json 把pstack声明为一个pack来源记为cursor带aliasPrefixes: [principle-]并说明它安装全部 52 个 pstack 技能以$pstack-name形式调用。catalog.json 里这个条目把pstack描述为 poteto 的 pstack agent workflows 打包严谨的 playbook、工程原则、刻意设计的子代理以及经过验证的产出。而 README 进一步说明了打包产物形态bundles/pstack/是上游 pluginskills/与agents/的未改动副本MIT 许可构建时发布为一个Skillpstack其压缩包内含索引SKILL.md、LICENSE、NOTICE.md以及把每个skills/子目录映射为skills/pstack-folder/的目录应用会把其中每一项作为独立技能安装与pstack并列共享一条 lock 记录——一次下载、一份安装回执。这意味着本文的主角在安装后落在.agents/skills/pstack-interrogate/ ├── SKILL.md └── references/ ├── reviewer-prompt.md ├── rubric.md ├── code-quality-review.md └── lead-judgment.md构建脚本 build-production-catalog.ts 逐文件处理目录下所有文件都被复制sources来自join(root, skills, folder)的递归相对路径其中.md文件额外走一次renamePackReferences.md之外的文件原样按字节复制。SKILL.md还要再过一次packSkillMarkdown。因此references/下的四份参考文件会被完整保留只做链接与名称改写。改写规则集中在 renamePackReferences与本模板直接相关的有三条相对链接重写为安装后相对路径](target)形式若匹配 pack 内某个技能的已安装路径就改写成从当前安装文件出发的相对路径installedPackPath负责判断skills/folder/...是否属于已安装技能L377-L382不属于任何技能的链接则指向钉住的上游 commit。斜杠命令与提及加前缀/name变成$pstack-namename与**name**也加上pstack-前缀upstreamPath/skills/name/变成.agents/skills/pstack-name/。frontmatter 调整在 packSkillMarkdown 中name:被改写为pstack-folder同时过滤掉disable-model-invocation: true这一行。最后这条对interrogate有直接影响。上游 SKILL.md 的 frontmatter 里带着disable-model-invocation: true即该技能只能由用户显式调用。OpenBot 构建时移除该行使$pstack-interrogate在各种 provider 下都能被调用——README 对此的表述是removesdisable-model-invocationso$pstack-nameworks with every provider。同时packSkillMarkdown 会在每个SKILL.md末尾追加一节## pstack in OpenBot内容包括技能名映射规则name即pstack-name、alias 提示principle-前缀规则、子代理兜底方式——当 harness 不认识subagent_type: agent时启动一个 general 子代理先把agents/agent.md的正文交给它再给任务若目录里有scripts/提示用解释器运行且安装后的文件不可执行以及许可证与 notice 的相对位置。agents/的打包条件在 L264-L271只有当某个技能文本中提到了agents/下某个文件名时才把该 agent 文件一并纳入。仓库中bundles/pstack/agents/下有poteto-agent.md与comment-sicko.md两个文件。安装侧还有一道校验。skill-frontmatter.ts 中的readSkillFrontmatter会检查SKILL.md的 YAML frontmattername必须等于所在文件夹名description长度必须在 1 到SKILL_DESCRIPTION_MAX_LENGTH之间解析失败或字段非法则返回相应的problem码frontmatterMissing、frontmatterInvalid、descriptionLength、nameMismatch。这解释了为什么构建必须把name: interrogate改成name: pstack-interrogate——否则装进.agents/skills/pstack-interrogate/后名称不匹配技能会被判为不可用。README 亦明确provider 也可能跳过该技能所以校验口径与 provider 保持一致。home-skills.ts 进一步说明了安装位置HOME_SKILL_FOLDER .agents/skills用户自有技能与 Agent Skills 工具在这个目录共享技能数上限MAX_HOME_SKILLS 200单个SKILL.md上限MAX_SKILL_FILE_BYTES 256 * 1024某个文件夹读不到时按不存在处理因为该目录属于用户而非 OpenBot。让模板产出稳定结果的六个工程细节把模板真正用于日常评审时以下细节决定了输出质量它们全部可以从模板与配套文件中找到依据意图只写一段且不夹带实现评价。模板把{INTENT}放在引用块中语义上就是作者陈述。混入我顺便重构了 X会把子代理引向为重构辩护。不要裁剪 rubric。{RUBRIC_CONTENTS}与{CODE_QUALITY_CONTENTS}是整份文件。裁剪等于关掉部分透镜而模型不会告诉你它少了哪一维。给足上下文但标清边界。{DIFF_OR_FILES}里应包含让评审者能判断调用方是否可能传 null的调用点。模板明确说这段是 Code Under Review所以附带的上下文文件要标明是上下文不在审查范围避免评审者去挑未改动代码的毛病。保留全部输出字段。尤其是**Location**与**Evidence**前者用于 Step 4 合并去重后者用于 Step 5 判断是否够格进 Act On。删掉 Evidence 只留结论会让主评审无法区分断言和有推理支撑的发现。接受空结果。no findings是模板授权的合法输出。逼模型产出会直接制造噪音而这些噪音要靠 Step 5 的 Dismissed 桶来消化成本更高。不要在子代理层做裁决。模板明确Do NOT question the intent itself分桶、权衡、驳回是主评审的职责见lead-judgment.md。把裁决塞进子代理提示词会让多模型独立共识这个最强信号失效——因为模型不再独立判断同一件事。复用清单若要把这套模板迁移到其他评审流程最小可用的移植步骤是保留角色锚定与三条禁令不复述、不表扬、允许no findings。把{INTENT}定为不可质疑的公理并明确挑战执行不挑战目标。用分级透镜一份负责正确性与安全对应 rubric.md一份负责结构简化与可维护性对应 code-quality-review.md整份注入而非摘要。固定critical/warning/nit三档并写明判定口径。固定四字段输出Suggestion标注为可选且要求具体替代方案。每个评审者用同一份模板只切换模型多样性来自模型而非人设。收敛阶段独立成文规定四桶分类与Agreement Map并要求 Act On 保持精简。模板本身没有一句多余的话角色、输入、透镜、指令、输出五段各自解决一个失效模式。真正决定这套流程能否落地的是它外部的三个约束——意图来自完整上下文、透镜按整份注入、裁决由主评审而非子代理完成。理解了这三点reviewer-prompt.md 才能从一个看起来很凶的提示词变成可复用、可验证、可收敛的工程化审查组件。赞分享【免费下载链接】openbotA local-first desktop workspace for persistent AI teammates. Run Codex, Claude, and Grok with dedicated workspaces, task queues, file sharing, browser control, and agent-to-agent collaboration.项目地址https://gitcode.com/GitHub_Trending/openbo/openbot点击查看免费下载相关推荐REA AI 逆向工程指南:1 条命令接入 Agent,免源码看懂 6 类目标REA AI 逆向工程指南:1 条命令接入 Agent,免源码看懂 6 类目标 REA Reverse Engineer Anything 把 AI 逆向工程做逆向工程MCP 服务AI 技能OpenBot pstack 中的 interrogate 技能用多模型对抗式评审给代码变更做压力测试OpenBot pstack 中的 interrogate 技能用多模型对抗式评审给代码变更做压力测试 OpenBot 的 Marketplace 生产目openbot pstack 的 Interrogate 技能深度解读多模型对抗式评审中的 Code Quality Review 代码质量视角openbot pstack 的 Interrogate 技能深度解读多模型对抗式评审中的 Code Quality Review 代码质量视角 在 open上一篇Rope-Pearl 视频换脸实操指南从安装到导出第一条人脸替换视频下一篇Redux-Thunk异步数据流可视化理解dispatch流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考