ECC for Kiro 深度解析:mle-reviewer 生产级机器学习工程评审 Agent 的完整工作流与评审清单【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本文以 .kiro/agents/mle-reviewer.md 这一 Kiro Agent 定义文件为核心,完整拆解 ECC(Everything Claude Code)中生产级机器学习工程评审者(MLE Reviewer)的角色定位、五步启动流程、五大关键评审域、八类常见阻断项、诊断命令与三档审批标准,并结合配套的 JSON 双生配置、Kiro 安装脚本 与 mle-workflow 技能,说明该 Agent 如何把模型代码从Notebook 里能跑推进到可上生产的 ML 系统。读完本文,你可以直接在自己的 Kiro 项目中安装并调用mle-reviewer,并理解它的每一条评审规则背后的工程动机。一、定位:一个专职ML 生产化评审的 Agent文档开篇即给出角色设定:You are a senior machine-learning engineering reviewer focused on moving model code from works in a notebook to production-safe ML systems. Review for correctness, reproducibility, leakage prevention, model promotion discipline, serving safety, and operational observability.也就是说,mle-reviewer不是泛用的代码评审员,而是聚焦六条生产化主线的资深 MLE 评审者:正确性(correctness)与可复现性(reproducibility);数据泄漏防护(leakage prevention);模型晋升纪律(promotion discipline)——何时允许新模型上线;服务安全(serving safety)与可观测性(operational observability)。frontmatter 中的description字段明确了触发场景:当涉及ML、MLOps、模型训练、推理、特征存储(feature store)或评估代码变更时使用该 Agent。这一描述与仓库中 scripts/consult.js 里的路由关键词完全对应——consult.js维护了一份agent:mle-reviewer的关键词表(ml、mle、mlops、pytorch、training、inference、serving、evaluation、model-review等),当用户查询命中这些词时会获得路由加分,体现该 Agent 在 ECC 组件体系中的检索定位;manifests/install-components.json 也将其注册为agents-core模块的正式安装组件。二、Agent 配置文件结构:frontmatter、双格式与工具权限2.1 frontmatter 与工具白名单.kiro/agents/mle-reviewer.md 顶部的 YAML frontmatter 只有三要素:name: mle-reviewer description: Production machine-learning engineering reviewer for data contracts, feature pipelines, training reproducibility, offline/online evaluation, model serving, monitoring, and rollback. Use when ML, MLOps, model training, inference, feature store, or evaluation code changes. allowedTools: - fs_read - shellallowedTools只授予文件读取(fs_read)与shell 执行两项权限:足以执行文档中要求的所有git diff、git grep、pytest、ruff、mypy检查,同时从机制上保证这是一个只读评审者——文档也明确约束 Do not rewrite the system unless asked(除非被要求,不要重写系统)。2.2 Markdown 与 JSON 双格式按 .kiro/README.md 的说明,ECC for Kiro 的每个 Agent 都提供两种格式:格式文件使用方式IDE(Markdown).kiro/agents/mle-reviewer.mdKiro 会话中通过/菜单自动选择或显式调用,如/mle-reviewerCLI(JSON).kiro/agents/mle-reviewer.json通过/agent swap切换,或kiro-cli --agent mle-reviewer直接启动.kiro/agents/mle-reviewer.json 的prompt字段与 Markdown 正文逐字一致,额外声明了tools: [builtin]与同样的allowedTools(fs_read、shell)。此外 README 指出:Agent 使用的模型由你在 Kiro 当前的模型选择决定,而不是 Agent 配置本身——这一点在引用该 Agent 时需要注意。三、评审启动流程:五步 Start Here文档的## Start Here一节定义了标准化的评审开场动作,五步依次为:确认可评审性:合并冲突已解决、CI 为绿色(或失败已解释)、diff 基于预期的目标分支;检视最近变更,使用两条 git 命令:git diff --stat git diff -- *.py *.sql *.yaml *.yml *.json *.toml *.ipynb注意第二个 glob 集刻意覆盖了 ML 项目的全部关键面:Python 代码、SQL 数据脚本、YAML/JSON/TOML 配置,以及notebook(.ipynb)——这与后文晋升不得依赖 notebook的阻断项形成呼应;识别变更触及的 ML 生命周期环节:数据抽取、打标(labeling)、特征生成、训练、评估、产物打包、推理、监控,还是部署;在可用时运行轻量检查:单元测试、pytest、ruff、mypy,或项目专属的 eval 命令;对照下文的生产 ML 清单逐文件评审。流程末尾再次强调输出纪律:报告必须带文件与行号引用,并按严重级别排序。四、五大关键评审域(Critical Review Areas)这是文档的核心主体,覆盖了从数据到监控的完整 MLOps 生命周期。4.1 数据契约与泄漏(Data Contract and Leakage)实体粒度(entity grain)、主键、标签时间戳、特征时间戳、快照/版本必须显式声明;数据切分必须尊重时间、用户/实体分组与生产预测边界(不能随机切);特征 join 必须满足 point-in-time 正确性,不得使用未来标签、事后字段(post-outcome fields)或可变聚合;训练与服务前都要校验缺失值、单位、取值范围、类别域和 schema 漂移;PII 与敏感属性必须排除或有书面理由,并配套保留期与日志管控。泄漏防护是整个 MLE 评审的第一优先级:仓库中配套的 mle-workflow 技能 在 Lock the Data Contract 一节同样要求先防泄漏——如果某个特征在预测时点不可用、或 join 使用了未来信息,删除它,或将其移入仅分析路径。4.2 训练可复现性(Training Reproducibility)训练必须仅凭代码、配置、数据集版本与随机种子即可运行,不依赖 notebook 状态;超参数、预处理逻辑、依赖版本、代码 SHA、指标、产物 URI 全部留痕;随机性与GPU 非确定性要有意识地处理(document,而非忽略);数据变换不得就地修改共享 DataFrame 或全局配置;重试必须幂等,且未经版本化不得覆盖已知良好的产物(known-good artifact)。4.3 评估与晋升(Evaluation and Promotion)指标必须与基线模型和当前线上模型对比,而不是只看绝对值;晋升门槛(promotion gates)必须在挑选结果前声明,并且 fail closed(缺失指标即失败);分片指标(slice metrics)需覆盖关键人群、流量来源、地域、设备、语言与稀疏分段;视相关性纳入校准、延迟、成本、公平性与业务护栏;回归测试要覆盖已知的模型、数据与服务失败模式。mle-workflow 给出了与这一域配套的fail closed参考实现:预声明的PROMOTION_GATES(如auc ≥ 0.82、calibration_error ≤ 0.04、p95_latency_ms ≤ 80),以及一个assert_promotion_ready()函数——先检查缺失门槛项,再逐项比对方向与阈值,任何未通过都抛出ValueError。评审时可以把这段语义作为门槛是否真的 fail closed的判据。4.4 服务与部署(Serving and Deployment)训练与服务两侧的变换必须共享同一来源,或有等价性测试——手动复制预处理逻辑是文档列出的典型阻断项;输入 schema 要拒绝陈旧、缺失、非法、超范围的特征;输出 schema 在有收益时应包含模型版本与置信度/校准字段;推理路径需具备超时、资源限制、批处理行为与降级(fallback)逻辑;发布计划支持影子流量(shadow)、金丝雀(canary)、A/B 测试或可立即回滚的恰当组合。4.5 监控与事故响应(Monitoring and Incident Response)监控不能只有服务存活,还要覆盖特征漂移、预测漂移、标签到达、延迟质量(delayed quality)与业务护栏;日志必须包含足以把预测与延迟标签关联(join)的标识符,同时不泄漏敏感数据;告警必须有阈值和责任人;回滚方案必须指名:前一个产物、配置、数据依赖,以及流量切换机制。五、八类常见阻断项(Common Blockers)文档将高频踩坑场景压缩为八条一眼可见的阻断项,评审时可作为快速过筛清单:对时间相关或用户相关的数据使用随机 train/test 切分;特征生成使用了预测时点拿不到的字段;离线指标上涨,但关键分片(slices)回退;训练预处理被手动复制进服务代码(训练/服务逻辑分叉);预测日志中缺少模型版本;晋升决策依赖 notebook、手工图表或本地文件;监控只查 uptime,不看数据与预测质量;回滚需要重新训练(而不是切回已知良好产物)。六、诊断命令(Diagnostic Commands)文档给出一组可直接复制执行的诊断命令,覆盖测试、静态检查、定向测试与代码模式扫描四个层面:pytest ruff check . mypy . python -m pytest tests/ -k model or feature or eval or inference git grep -nE train_test_split|random_split|fit_transform|predict_proba|model_version|feature_store|artifact git grep -nE customer_id|email|phone|ssn|api_key|secret|token -- *.py *.sql *.ipynb各命令的评审意图:pytest/ruff check ./mypy .:基础正确性、风格与类型门禁;python -m pytest tests/ -k model or feature or eval or inference:定向跑与模型、特征、评估、推理相关的测试子集,避免全量测试的成本;第一条git grep扫描 ML 代码的风险模式:train_test_split/random_split可能触发随机切分泄漏,fit_transform提示预处理位置需要确认(是否随产物保存、是否训练/服务共享),predict_proba涉及校准与阈值,model_version/feature_store/artifact用于确认版本、存储与产物链路存在;第二条git grep扫描PII 与密钥模式(customer_id|email|phone|ssn|api_key|secret|token),且限定在*.py、*.sql、*.ipynb——把 notebook 也纳入敏感数据扫描面,正对应 4.1 节PII 必须排除或有理由的评审项。七、输出格式:结构化 Findings 与三档审批7.1 单条 Finding 格式每条发现必须使用如下四段结构,保证可追溯、可分派:[SEVERITY] Issue title File: path/to/file.py:42 Issue: What is wrong and why it matters for production ML Fix: Concrete correction or gate to add7.2 收尾决策块评审必须以固定格式的决策块收尾:Decision: APPROVE | APPROVE WITH WARNINGS | BLOCK Primary risks: data leakage | irreproducible training | weak eval | unsafe serving | missing monitoring | other Tests run: commands and outcomesPrimary risks的六个枚举值(数据泄漏 / 不可复现训练 / 弱评估 / 不安全服务 / 缺失监控 / 其他)恰好与四大评审域一一对应,方便下游(人或 Agent)做分类统计;Tests run要求如实记录执行的命令与结果,呼应 Start Here 第 4 步的轻量检查。7.3 审批标准(Approval Criteria)APPROVE:无 critical/high 级 MLE 风险,且相关测试或 eval 门禁通过;APPROVE WITH WARNINGS:仅有 Medium 级问题,且附带明确的后续跟进(follow-up);BLOCK:出现任何疑似数据泄漏、不可复现的晋升路径、不安全的服务行为、生产部署缺少回滚、敏感数据暴露,或关键评估缺口——即六类红线之一即可一票阻断。这套fail closed的审批语义与 4.3 节晋升门槛先声明、缺失即失败的原则一致:评审器自身的判断标准也要求缺证据即不放行。八、协同面:与 mle-workflow 技能的分工文档末尾一行 Reference skill:mle-workflow 指向仓库内的 skills/mle-workflow/SKILL.md。两者构成ECC MLE 面的完整分工:mle-workflow(技能)面向做:定义预测契约、数据契约、可复现流水线(含 frozenTrainingConfig与code_sha config_hash命名的产物)、晋升门禁、服务打包与运维监控,并提供 Iteration Compact、错误分析循环、Observation Ledger 等模板;mle-reviewer(Agent)面向审:按本文第三到七节的流程与清单,对已写出的变更给出带行号、按严重级排序、以 APPROVE/BLOCK 收口的评审结论。mle-workflow 技能 的 Reuse the SWE Surface 表格还明确建议:在支持 Agent 的目标上,将skill:mle-workflow与agent:mle-reviewer配对使用;同时该仓库的 Kiro 技能目录 中也收录了mle-workflow,与 Kiro 组件清单 中mle-reviewerAgent 条目(Production ML engineering reviewer. Pipelines, evals, serving, monitoring, and rollback.)共同安装。此外,仓库根目录下的 agents/mle-reviewer.md 是同一评审者的 Claude Code 变体,内容在本文五大评审域基础上进一步扩展(增加了复用既有评审通道章节,组合python-reviewer、security-reviewer、pr-test-analyzer等),可作为同一方法论在不同 harness 上落地的对照阅读材料。九、安装与调用方式按 .kiro/README.md 与 .kiro/install.sh 的说明,ECC 工作流可以通过单条命令安装到任意 Kiro 项目:# 安装到指定项目 cd .kiro ./install.sh /path/to/your/project # 安装到当前目录 ./install.sh # 全局安装(作用于所有 Kiro 项目) ./install.sh ~从 install.sh 的实现看,安装器采用非破坏性复制:逐类(agents/skills/steering/hooks/scripts/settings)检查目标文件是否已存在,if [ ! -f ... ]才复制,不会覆盖你已有的同名文件,并在结尾打印各组件安装计数与后续步骤提示。调用方式因界面而异:Kiro IDE:在会话中直接输入/mle-reviewer,或由 Kiro 按上下文自动选择;Kiro CLI:在聊天会话中输入/agent swap选择mle-reviewer,或启动时指定kiro-cli --agent mle-reviewer。十、适用前提与限制该 Agent 的评审清单以Python 生态的 ML 项目为主要预设:诊断命令默认pytest/ruff/mypy,敏感数据扫描限定*.py、*.sql、*.ipynb;对于其他语言栈,需要替换等价的测试与静态检查命令;allowedTools仅含fs_read与shell,Agent 定位为只读评审,不代改代码——修复需由开发者或其他 Agent 执行;Agent 的模型由你在 Kiro 中的当前模型选择决定,评审深度可能与所选模型能力相关;评审命令(如git grep、pytest)要求在目标项目工作区内执行,且依赖仓库中已配置的测试与 lint 工具链;若项目未配置 CI 或测试,Start Here 第 1、4 步会退化为人工确认。总结.kiro/agents/mle-reviewer.md 的价值在于把ML 系统能否上生产这个模糊问题,拆解为一套可执行、可复核、可阻断的评审协议:五步启动流程确定了评审入口,五大评审域覆盖了数据契约、可复现训练、评估晋升、服务部署与监控回滚的完整生命周期,八条阻断项给出高频风险速查表,诊断命令提供可复制的取证手段,而结构化 Findings 加三档 Decision 块则让评审结论可以直接进入工程决策。配合 mle-workflow 技能 的做与 Kiro 安装体系 的分发,mle-reviewer是 ECC 在 Kiro 上落地 MLOps 纪律的评审侧支柱。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ECC for Kiro 深度解析:mle-reviewer 生产级机器学习工程评审 Agent 的完整工作流与评审清单
ECC for Kiro 深度解析:mle-reviewer 生产级机器学习工程评审 Agent 的完整工作流与评审清单【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本文以 .kiro/agents/mle-reviewer.md 这一 Kiro Agent 定义文件为核心,完整拆解 ECC(Everything Claude Code)中生产级机器学习工程评审者(MLE Reviewer)的角色定位、五步启动流程、五大关键评审域、八类常见阻断项、诊断命令与三档审批标准,并结合配套的 JSON 双生配置、Kiro 安装脚本 与 mle-workflow 技能,说明该 Agent 如何把模型代码从Notebook 里能跑推进到可上生产的 ML 系统。读完本文,你可以直接在自己的 Kiro 项目中安装并调用mle-reviewer,并理解它的每一条评审规则背后的工程动机。一、定位:一个专职ML 生产化评审的 Agent文档开篇即给出角色设定:You are a senior machine-learning engineering reviewer focused on moving model code from works in a notebook to production-safe ML systems. Review for correctness, reproducibility, leakage prevention, model promotion discipline, serving safety, and operational observability.也就是说,mle-reviewer不是泛用的代码评审员,而是聚焦六条生产化主线的资深 MLE 评审者:正确性(correctness)与可复现性(reproducibility);数据泄漏防护(leakage prevention);模型晋升纪律(promotion discipline)——何时允许新模型上线;服务安全(serving safety)与可观测性(operational observability)。frontmatter 中的description字段明确了触发场景:当涉及ML、MLOps、模型训练、推理、特征存储(feature store)或评估代码变更时使用该 Agent。这一描述与仓库中 scripts/consult.js 里的路由关键词完全对应——consult.js维护了一份agent:mle-reviewer的关键词表(ml、mle、mlops、pytorch、training、inference、serving、evaluation、model-review等),当用户查询命中这些词时会获得路由加分,体现该 Agent 在 ECC 组件体系中的检索定位;manifests/install-components.json 也将其注册为agents-core模块的正式安装组件。二、Agent 配置文件结构:frontmatter、双格式与工具权限2.1 frontmatter 与工具白名单.kiro/agents/mle-reviewer.md 顶部的 YAML frontmatter 只有三要素:name: mle-reviewer description: Production machine-learning engineering reviewer for data contracts, feature pipelines, training reproducibility, offline/online evaluation, model serving, monitoring, and rollback. Use when ML, MLOps, model training, inference, feature store, or evaluation code changes. allowedTools: - fs_read - shellallowedTools只授予文件读取(fs_read)与shell 执行两项权限:足以执行文档中要求的所有git diff、git grep、pytest、ruff、mypy检查,同时从机制上保证这是一个只读评审者——文档也明确约束 Do not rewrite the system unless asked(除非被要求,不要重写系统)。2.2 Markdown 与 JSON 双格式按 .kiro/README.md 的说明,ECC for Kiro 的每个 Agent 都提供两种格式:格式文件使用方式IDE(Markdown).kiro/agents/mle-reviewer.mdKiro 会话中通过/菜单自动选择或显式调用,如/mle-reviewerCLI(JSON).kiro/agents/mle-reviewer.json通过/agent swap切换,或kiro-cli --agent mle-reviewer直接启动.kiro/agents/mle-reviewer.json 的prompt字段与 Markdown 正文逐字一致,额外声明了tools: [builtin]与同样的allowedTools(fs_read、shell)。此外 README 指出:Agent 使用的模型由你在 Kiro 当前的模型选择决定,而不是 Agent 配置本身——这一点在引用该 Agent 时需要注意。三、评审启动流程:五步 Start Here文档的## Start Here一节定义了标准化的评审开场动作,五步依次为:确认可评审性:合并冲突已解决、CI 为绿色(或失败已解释)、diff 基于预期的目标分支;检视最近变更,使用两条 git 命令:git diff --stat git diff -- *.py *.sql *.yaml *.yml *.json *.toml *.ipynb注意第二个 glob 集刻意覆盖了 ML 项目的全部关键面:Python 代码、SQL 数据脚本、YAML/JSON/TOML 配置,以及notebook(.ipynb)——这与后文晋升不得依赖 notebook的阻断项形成呼应;识别变更触及的 ML 生命周期环节:数据抽取、打标(labeling)、特征生成、训练、评估、产物打包、推理、监控,还是部署;在可用时运行轻量检查:单元测试、pytest、ruff、mypy,或项目专属的 eval 命令;对照下文的生产 ML 清单逐文件评审。流程末尾再次强调输出纪律:报告必须带文件与行号引用,并按严重级别排序。四、五大关键评审域(Critical Review Areas)这是文档的核心主体,覆盖了从数据到监控的完整 MLOps 生命周期。4.1 数据契约与泄漏(Data Contract and Leakage)实体粒度(entity grain)、主键、标签时间戳、特征时间戳、快照/版本必须显式声明;数据切分必须尊重时间、用户/实体分组与生产预测边界(不能随机切);特征 join 必须满足 point-in-time 正确性,不得使用未来标签、事后字段(post-outcome fields)或可变聚合;训练与服务前都要校验缺失值、单位、取值范围、类别域和 schema 漂移;PII 与敏感属性必须排除或有书面理由,并配套保留期与日志管控。泄漏防护是整个 MLE 评审的第一优先级:仓库中配套的 mle-workflow 技能 在 Lock the Data Contract 一节同样要求先防泄漏——如果某个特征在预测时点不可用、或 join 使用了未来信息,删除它,或将其移入仅分析路径。4.2 训练可复现性(Training Reproducibility)训练必须仅凭代码、配置、数据集版本与随机种子即可运行,不依赖 notebook 状态;超参数、预处理逻辑、依赖版本、代码 SHA、指标、产物 URI 全部留痕;随机性与GPU 非确定性要有意识地处理(document,而非忽略);数据变换不得就地修改共享 DataFrame 或全局配置;重试必须幂等,且未经版本化不得覆盖已知良好的产物(known-good artifact)。4.3 评估与晋升(Evaluation and Promotion)指标必须与基线模型和当前线上模型对比,而不是只看绝对值;晋升门槛(promotion gates)必须在挑选结果前声明,并且 fail closed(缺失指标即失败);分片指标(slice metrics)需覆盖关键人群、流量来源、地域、设备、语言与稀疏分段;视相关性纳入校准、延迟、成本、公平性与业务护栏;回归测试要覆盖已知的模型、数据与服务失败模式。mle-workflow 给出了与这一域配套的fail closed参考实现:预声明的PROMOTION_GATES(如auc ≥ 0.82、calibration_error ≤ 0.04、p95_latency_ms ≤ 80),以及一个assert_promotion_ready()函数——先检查缺失门槛项,再逐项比对方向与阈值,任何未通过都抛出ValueError。评审时可以把这段语义作为门槛是否真的 fail closed的判据。4.4 服务与部署(Serving and Deployment)训练与服务两侧的变换必须共享同一来源,或有等价性测试——手动复制预处理逻辑是文档列出的典型阻断项;输入 schema 要拒绝陈旧、缺失、非法、超范围的特征;输出 schema 在有收益时应包含模型版本与置信度/校准字段;推理路径需具备超时、资源限制、批处理行为与降级(fallback)逻辑;发布计划支持影子流量(shadow)、金丝雀(canary)、A/B 测试或可立即回滚的恰当组合。4.5 监控与事故响应(Monitoring and Incident Response)监控不能只有服务存活,还要覆盖特征漂移、预测漂移、标签到达、延迟质量(delayed quality)与业务护栏;日志必须包含足以把预测与延迟标签关联(join)的标识符,同时不泄漏敏感数据;告警必须有阈值和责任人;回滚方案必须指名:前一个产物、配置、数据依赖,以及流量切换机制。五、八类常见阻断项(Common Blockers)文档将高频踩坑场景压缩为八条一眼可见的阻断项,评审时可作为快速过筛清单:对时间相关或用户相关的数据使用随机 train/test 切分;特征生成使用了预测时点拿不到的字段;离线指标上涨,但关键分片(slices)回退;训练预处理被手动复制进服务代码(训练/服务逻辑分叉);预测日志中缺少模型版本;晋升决策依赖 notebook、手工图表或本地文件;监控只查 uptime,不看数据与预测质量;回滚需要重新训练(而不是切回已知良好产物)。六、诊断命令(Diagnostic Commands)文档给出一组可直接复制执行的诊断命令,覆盖测试、静态检查、定向测试与代码模式扫描四个层面:pytest ruff check . mypy . python -m pytest tests/ -k model or feature or eval or inference git grep -nE train_test_split|random_split|fit_transform|predict_proba|model_version|feature_store|artifact git grep -nE customer_id|email|phone|ssn|api_key|secret|token -- *.py *.sql *.ipynb各命令的评审意图:pytest/ruff check ./mypy .:基础正确性、风格与类型门禁;python -m pytest tests/ -k model or feature or eval or inference:定向跑与模型、特征、评估、推理相关的测试子集,避免全量测试的成本;第一条git grep扫描 ML 代码的风险模式:train_test_split/random_split可能触发随机切分泄漏,fit_transform提示预处理位置需要确认(是否随产物保存、是否训练/服务共享),predict_proba涉及校准与阈值,model_version/feature_store/artifact用于确认版本、存储与产物链路存在;第二条git grep扫描PII 与密钥模式(customer_id|email|phone|ssn|api_key|secret|token),且限定在*.py、*.sql、*.ipynb——把 notebook 也纳入敏感数据扫描面,正对应 4.1 节PII 必须排除或有理由的评审项。七、输出格式:结构化 Findings 与三档审批7.1 单条 Finding 格式每条发现必须使用如下四段结构,保证可追溯、可分派:[SEVERITY] Issue title File: path/to/file.py:42 Issue: What is wrong and why it matters for production ML Fix: Concrete correction or gate to add7.2 收尾决策块评审必须以固定格式的决策块收尾:Decision: APPROVE | APPROVE WITH WARNINGS | BLOCK Primary risks: data leakage | irreproducible training | weak eval | unsafe serving | missing monitoring | other Tests run: commands and outcomesPrimary risks的六个枚举值(数据泄漏 / 不可复现训练 / 弱评估 / 不安全服务 / 缺失监控 / 其他)恰好与四大评审域一一对应,方便下游(人或 Agent)做分类统计;Tests run要求如实记录执行的命令与结果,呼应 Start Here 第 4 步的轻量检查。7.3 审批标准(Approval Criteria)APPROVE:无 critical/high 级 MLE 风险,且相关测试或 eval 门禁通过;APPROVE WITH WARNINGS:仅有 Medium 级问题,且附带明确的后续跟进(follow-up);BLOCK:出现任何疑似数据泄漏、不可复现的晋升路径、不安全的服务行为、生产部署缺少回滚、敏感数据暴露,或关键评估缺口——即六类红线之一即可一票阻断。这套fail closed的审批语义与 4.3 节晋升门槛先声明、缺失即失败的原则一致:评审器自身的判断标准也要求缺证据即不放行。八、协同面:与 mle-workflow 技能的分工文档末尾一行 Reference skill:mle-workflow 指向仓库内的 skills/mle-workflow/SKILL.md。两者构成ECC MLE 面的完整分工:mle-workflow(技能)面向做:定义预测契约、数据契约、可复现流水线(含 frozenTrainingConfig与code_sha config_hash命名的产物)、晋升门禁、服务打包与运维监控,并提供 Iteration Compact、错误分析循环、Observation Ledger 等模板;mle-reviewer(Agent)面向审:按本文第三到七节的流程与清单,对已写出的变更给出带行号、按严重级排序、以 APPROVE/BLOCK 收口的评审结论。mle-workflow 技能 的 Reuse the SWE Surface 表格还明确建议:在支持 Agent 的目标上,将skill:mle-workflow与agent:mle-reviewer配对使用;同时该仓库的 Kiro 技能目录 中也收录了mle-workflow,与 Kiro 组件清单 中mle-reviewerAgent 条目(Production ML engineering reviewer. Pipelines, evals, serving, monitoring, and rollback.)共同安装。此外,仓库根目录下的 agents/mle-reviewer.md 是同一评审者的 Claude Code 变体,内容在本文五大评审域基础上进一步扩展(增加了复用既有评审通道章节,组合python-reviewer、security-reviewer、pr-test-analyzer等),可作为同一方法论在不同 harness 上落地的对照阅读材料。九、安装与调用方式按 .kiro/README.md 与 .kiro/install.sh 的说明,ECC 工作流可以通过单条命令安装到任意 Kiro 项目:# 安装到指定项目 cd .kiro ./install.sh /path/to/your/project # 安装到当前目录 ./install.sh # 全局安装(作用于所有 Kiro 项目) ./install.sh ~从 install.sh 的实现看,安装器采用非破坏性复制:逐类(agents/skills/steering/hooks/scripts/settings)检查目标文件是否已存在,if [ ! -f ... ]才复制,不会覆盖你已有的同名文件,并在结尾打印各组件安装计数与后续步骤提示。调用方式因界面而异:Kiro IDE:在会话中直接输入/mle-reviewer,或由 Kiro 按上下文自动选择;Kiro CLI:在聊天会话中输入/agent swap选择mle-reviewer,或启动时指定kiro-cli --agent mle-reviewer。十、适用前提与限制该 Agent 的评审清单以Python 生态的 ML 项目为主要预设:诊断命令默认pytest/ruff/mypy,敏感数据扫描限定*.py、*.sql、*.ipynb;对于其他语言栈,需要替换等价的测试与静态检查命令;allowedTools仅含fs_read与shell,Agent 定位为只读评审,不代改代码——修复需由开发者或其他 Agent 执行;Agent 的模型由你在 Kiro 中的当前模型选择决定,评审深度可能与所选模型能力相关;评审命令(如git grep、pytest)要求在目标项目工作区内执行,且依赖仓库中已配置的测试与 lint 工具链;若项目未配置 CI 或测试,Start Here 第 1、4 步会退化为人工确认。总结.kiro/agents/mle-reviewer.md 的价值在于把ML 系统能否上生产这个模糊问题,拆解为一套可执行、可复核、可阻断的评审协议:五步启动流程确定了评审入口,五大评审域覆盖了数据契约、可复现训练、评估晋升、服务部署与监控回滚的完整生命周期,八条阻断项给出高频风险速查表,诊断命令提供可复制的取证手段,而结构化 Findings 加三档 Decision 块则让评审结论可以直接进入工程决策。配合 mle-workflow 技能 的做与 Kiro 安装体系 的分发,mle-reviewer是 ECC 在 Kiro 上落地 MLOps 纪律的评审侧支柱。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考