人工智能AI AgentAgent 框架工具调用Agent 工作流RAGMCP Clients强化学习【免费下载链接】agent-core-javaopenJiuwen agent core Java是 openJiuwen Core的 Java版本提供AI Agent开发、运行、调优与演进相关的全套SDK能力。项目地址https://gitcode.com/openJiuwen/agent-core-java点击查看免费下载导读本文以 openJiuwen agent-core-java 中 Auto Harness 代码评审代理的提示词 evaluate.md 为主线剖析 Auto Harness 自优化闭环中评审Evaluate环节的角色定义、strict-but-fair 评审标准与结构化输出协议并结合 MetaVerifyStage.java、FixLoopController.java 等源码还原评审代理在修复循环Fix Loop中的实际调用链与判定逻辑。读完你将掌握如何理解、复用并定制这套代码变更自动评审机制。一、evaluate.md 是什么评审代理的系统提示词在 Auto Harness 的流水线中每一个阶段代理Stage Agent都由系统提示词驱动。evaluate.md 是评审Evaluate阶段代理的系统提示词。它通篇只做一件事让 LLM 扮演代码评审代理根据给定的任务描述、代码变更git diff与 CI 状态输出一个二值结论PASS / FAIL和一句理由。提示词本身包含 5 个占位变量由调用方在运行时注入占位符含义注入来源{task_description}任务描述任务上下文中的原始任务说明{git_diff}代码变更git diff与基线提交的差异内容{ci_status}CI 状态由 CI 门禁结果格式化而来Verdict评审结论模型输出PASS 或 FAILReason评审理由模型输出一句话理由在 AutoHarnessAgentFactory.java 中createEvalAgent直接以loadPrompt(evaluate.md)作为系统提示词并装配了verify、verify_ext技能与只读 RailsSysOperationRail、AutoHarnessContextRail、LspRail、AutoHarnessExperienceRail默认最多 10 次迭代eval: 10。也就是说评审代理被设计为只读代理它可以读文件、跑命令、做验证但被 Rails 约束为不写代码、不修改工作区。二、strict-but-fair 评审标准逐条拆解提示词中的评审标准是整个机制的核心原文共 6 条语义如下FAIL实现与任务描述不符——变更没有解决任务描述中提出的问题FAIL破坏了现有功能——变更引入了回归影响了既有行为FAIL引入安全问题——存在注入、路径遍历、凭据泄露等安全风险FAIL存在阻塞型门禁失败——例如static_check、ut或st的代码失败不因以下情况单独判 FAIL风格偏好问题、非阻塞告警、st 的环境失败——这是 fair 的部分PASS其他情况——即默认放行。strict-but-fair严格但公平的含义可以这样理解strict任务符合度、功能回归、安全、阻塞型 CI 失败这四类硬性红线一旦触碰即判 FAIL不存在模棱两可的中间态fair风格偏好、非阻塞告警、环境类失败如 st 环境不可用被明确排除在 FAIL 理由之外避免评审代理因鸡毛蒜皮的问题否决整体变更。这一设计在 verify/SKILL.md 的评审要点中也有呼应验证时关注正确性、安全性、兼容性、测试覆盖与风格但风格仅作为参考项并不构成独立的否决条件。为什么需要把环境失败与代码失败分开提示词特别强调stsystem test的环境失败不应单独判 FAIL。在分布式 CI 场景中环境失败依赖安装失败、沙箱资源不足、网络抖动与代码失败是两类问题前者与本次变更无关判 FAIL 会导致修复循环空转。从源码看VerifyStage.java 的formatCiStatusForEvaluator在生成 CI 状态文本时会把所有门禁结果含lint、type-check逐条输出为- name: PASS/FAIL | 详情并对未匹配到任何 CI 门禁的情形输出结论: blocking failure确保评审代理拿到的 CI 状态是结构化、可判读的。三、输出协议Verdict Reason 的机器可解析设计提示词规定的输出格式只有两行Verdict: PASS 或 FAIL Reason: 一句话理由这个极简协议是刻意为之其核心目的是机器可解析。在 MetaVerifyStage.java 中修复循环对评审输出的判定逻辑是boolean approved output.toString().toLowerCase().contains(verdict: pass);即只要评审代理的输出文本中包含verdict: pass不区分大小写即视为评审通过。这种字符串匹配策略对格式要求极高——评审代理必须严格遵循Verdict:前缀任何自由发挥如先写一大段分析再下结论都可能因格式漂移导致判定失败。因此evaluate.md 的输出格式小节是整个提示词中与代码逻辑耦合最紧密的部分。相比 assess.md 要求输出多章节 Markdown 评估报告evaluate.md 刻意压缩为两行结构化输出这正是评审结论只需要一个位bit的工程取舍。四、在修复循环Fix Loop中的实际调用链评审代理并非孤立存在它被 MetaVerifyStage 的修复循环Fix Loop作为第二阶段评审器调用。调用链如下运行 CIMetaVerifyStage.stream调用ciGate.run(all)执行全部门禁并通过iterCiGateMessages将结果转为可读消息Phase 1自动修复若 CI 未通过FixLoopController.run进入 Phase 1最多重试 10 次phase1MaxRetries 10每次超时 600 秒由修复代理根据 CI 错误反复修改并重跑 CIPhase 2评审门当 CI 通过后进入 Phase 2最多重试 9 次phase2MaxRetries 9此时才调用createEvalAgent构建评审代理注入如下 query任务描述: {task.description} 代码变更: {preview(diff, 5000)} CI 状态: {formatCiStatusForEvaluator(ciResult)} 请评审这些变更。判定与循环解析评审输出中是否含verdict: pass通过则修复循环成功结束未通过则评审代理的 Reason如evaluator rejected作为修复目标继续驱动修复代理直至 Phase 2 重试耗尽。值得注意的是 Phase 2 的评审发生在修复代理已把 CI 修到全绿之后。这意味着评审代理评审的是已经通过 CI 的变更它要捕捉的是 CI 覆盖不到的语义问题如任务符合度、安全隐患、功能回归与 CI 门禁形成互补的双闸门。从 FixLoopController.java 可见Phase 2 中evaluator rejected同样会驱动agentFixer.fix(evaluator rejected)再次修改代码且评审与修复共享同一个超时控制timeoutPerAttempt。若最终失败MetaVerifyStage 会丢弃 worktree 变更、将任务状态置为REVERTED并把失败经验写入经验库ExperienceType.FAILURE。五、评审标准背后的 CI 门禁与配置支撑要理解ci_status的语义需要结合 Auto Harness 的 CI 门禁配置。仓库中的 ci_gate.yaml 定义了默认门禁ci_gates: - name: lint command: make check COMMITS1 required: true - name: type-check command: make type-check COMMITS1 required: true fix_loop: phase1_max_retries: 10 phase1_timeout_per_attempt: 600 phase2_max_retries: 9 revert_on_exhaustion: true评审标准中提到的阻塞型门禁失败static_check、ut、st即对应此类required: true的门禁。revert_on_exhaustion: true则与 MetaVerifyStage 的回滚行为一一对应修复循环耗尽后自动 revert。同一目录还提供了 Auto Harness 的默认配置模板见 AutoHarnessSchema.java 中的DEFAULT_CONFIG_TEMPLATE其中agent.eval: 20表明评审代理在外部配置中的默认迭代上限而 Java 实现内置默认值为eval: 10见defaultAgentIterations两者均可通过配置文件覆盖。此外AutoHarnessAgentFactoryTest.java 验证了createEvalAgent与其他阶段代理一样会采用配置的completionTimeout确保评审代理不会因模型调用超时而拖垮整个修复循环。六、如何理解、调试与定制评审机制1. 评审不通过时的排查思路当修复循环在 Phase 2 反复被评审拒绝时可从三个方向排查格式漂移评审代理未按Verdict: PASS/FAIL格式输出例如先输出分析段落、或把 verdict 写成小写加粗导致contains(verdict: pass)匹配失败——这是最容易被忽略的失败模式标准误判提示词注入的ci_status不完整或含非阻塞告警导致模型把环境失败误判为阻塞失败——可检查formatCiStatusForEvaluator的输出是否把门禁逐条列出任务描述与 diff 不匹配{task_description}与{git_diff}错位如 diff 截断超过 5000 字符的preview限制模型无法判断实现是否符合任务。2. 定制评审标准的边界evaluate.md 位于openjiuwen/auto_harness/prompts/目录。需要注意的是ci_gate.yaml 将auto_harness/prompts/identity.md列为 immutable 文件而 evaluate.md 本身不在不可变清单中属于可定制提示词。若需调整评审口径例如增加性能回归FAIL 条件、放宽安全红线直接编辑 evaluate.md 并保持Verdict:/Reason:两行协议不变即可判定逻辑无需改动。3. 复用建议若要在自己的流水线中复刻该机制只需准备任务描述 → 生成 git diff → 格式化 CI 状态 → 用 evaluate.md 作为系统提示词 → 解析输出中的verdict: pass若评审需要更严格的证据链可在 evaluate.md 中追加必须引用具体行号/文件路径作为 FAIL 证据的约束但不建议改变输出协议本身评审代理装配了verify技能见 verify/SKILL.md它可调用read_file、bash_tool、glob_tool、grep_tool做主动验证因此评审不是盲审而是可以实际检查代码的。七、小结evaluate.md 用不足 30 行文本定义了一个最小但完备的代码评审协议明确输入任务描述 git diff CI 状态、明确标准strict-but-fair 四类 FAIL 红线、明确输出Verdict Reason。它在 Auto Harness 修复循环中作为 Phase 2 的评审闸门与 CI 门禁构成双层校验是AI 自动改进代码流程中防止改对了 CI 却做错了事的关键防线。其设计思路——机器可解析的结构化输出、显式排除非阻塞噪声、只读代理加验证技能——对任何希望构建自动代码评审或自优化流水线的开发者都具有直接的参考价值。延伸阅读评审代理同族的其他提示词见 prompts 目录assess / plan / select_pipeline / learnings / pr_draft修复循环实现见 FixLoopController.java流水线编排见 AutoHarnessOrchestrator.java。赞分享人工智能AI AgentAgent 框架工具调用Agent 工作流RAGMCP Clients强化学习【免费下载链接】agent-core-javaopenJiuwen agent core Java是 openJiuwen Core的 Java版本提供AI Agent开发、运行、调优与演进相关的全套SDK能力。项目地址https://gitcode.com/openJiuwen/agent-core-java点击查看免费下载相关推荐提示词定生死给阿里代码评审 agent 定制评审规则与结构化输出提示词定生死给阿里代码评审 agent 定制评审规则与结构化输出 AI 代码评审在 2026 年几乎成了每个团队的标配实验CI 里接一个 agent让人工智能AI 应用代码评审开发工具代码质量深入解析 agents24 代码审查 Agent基于 git-pr-workflows 插件的现代 AI 代码评审系统提示词设计深入解析 agents24 代码审查 Agent基于 git pr workflows 插件的现代 AI 代码评审系统提示词设计 导读 本篇技术指南围绕当前仓AI 插件AI 技能开发工具Wasmtime 代码评审机制全解析PR 自动分配评审人、四支评审团队与三阶段评审法Wasmtime 代码评审机制全解析PR 自动分配评审人、四支评审团队与三阶段评审法 Wasmtime 作为一个由 Bytecode Alliance 维护、语言运行时JIT编译编译器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考