人工智能AI 应用AI 评测RAG微调提示工程开发工具桌面应用【免费下载链接】KilnBuild, Evaluate, and Optimize AI Systems. Includes evals, RAG, agents, fine-tuning, synthetic data generation, dataset management, MCP, and more.项目地址https://gitcode.com/gh_mirrors/ki/Kiln点击查看免费下载导读Evals V2 Cleanup 是 Kiln 仓库中一个小而精的收尾项目它把 Evals V2 spec-fidelity review2026-06-23中筛出的八项缺陷编号 D14/D15/D27–D31/D35集中到一次架构级清理中其中六项是后端正确性修复、两项是结果展示面的 UI 缺口。本文以 architecture.md 为骨架结合 functional_spec.md、implementation_plan.md 以及仓库当前源码逐项拆解这些修复的动机、实现方式与验证门槛。读完本文你将理解 Kiln V2 评测体系中最关键的内部契约V2EvalResult是如何贯穿 8 个适配器与 5 个调用点的也能掌握这类评测基础设施正确性收尾项目的架构决策与评审流程。一、项目背景一次 spec-fidelity review 的八项收尾Evals V2 Cleanup 的定位十分明确它是一个holding project汇总性项目专门承接 Evals V2 规范一致性评审spec-fidelity review中重要但体量小的修复项——这些修复不足以各自立项但全部被标记为ship-blocker发布阻塞项其中 D27/D29 由 scosman 于 2026-06-24 从 post-ship 提升为 ship-blocker。详见 project_overview.md。八项决策一览ID面一句话描述D14后端eval_helpers.pyget_tool_calls()必须能读取真实的 OpenAI 格式 traceD15后端eval_helpers.pyget_assistant_messages()必须返回list[str]D27后端eval.pyexpected_tools在保存时必须非空D28后端eval.pyArgMatch的正则表达式在保存时必须可编译D29后端eval.pyreference_key在保存时要求min_length1D30后端eval.py无用模板检查必须是 AST 级别而非{{表面扫描D31后端 前端在运行结果中暴露 V2llm_judge的推理reasoningD35前端聚合视图在n_excluded 0时给出警告项目的关键设计约束有两点并行安全所有改动都不触碰评测创建容器eval create container属于另一个项目 Project 1因此与创建流程项目完全并行、无分支冲突唯一的交叉点是eval.py文件本身被两个项目共享但涉及的是不同的类。单一共享脊柱除了V2EvalResult契约迁移§1外其余各项彼此独立可任意顺序落地。架构文档因此没有拆分成组件级文档而是单篇架构文档并把 UI 设计折叠进来ui_design.md被跳过。决策来源记录在 DECISIONS.md逐项证据文件为confirm_K.mdD14/D15、confirm_J.mdD27–D30、confirm_H.mdD31、confirm_L.mdD35。二、后端脊柱V2EvalResult契约迁移§12.1 为什么需要一个模型对象而不是三元组迁移前的状况是每个 V2 适配器都实现evaluate(eval_input) - tuple[EvalScores, SkippedReason | None, str | None]的三元组返回而llm_judge适配器在 v2_eval_llm_judge.py 中拿到了run_output却丢弃了run_output.intermediate_outputs——即法官模型judge model的思维链chain-of-thought没有任何通道可以到达存储层。架构决策由 scosman 拍板是引入一个自文档化的 Pydantic 模型class V2EvalResult(BaseModel): Result of a single V2 eval evaluate() call. scores: EvalScores Field(default_factorydict) skipped_reason: SkippedReason | None None skipped_detail: str | None None intermediate_outputs: dict[str, str] | None None选模型而非元组的理由architecture.md §1.4自文档化字段名即契约可扩展后续想加logprobs、usage等字段时无需重新穿线所有调用点。这一点在当前源码中已经得到印证仓库中的 eval.py 里V2EvalResult已经多了一个文档写作时未出现的usage: Usage | None字段What the judgment itself cost, if it called a model…并且由EvalRun.eval_usage持久化——正是模型而非元组设计可扩展性的直接证据。2.2 生产者8 个适配器的evaluate()签名迁移抽象签名定义在 base_eval.pyabstractmethod async def evaluate(self, eval_input: EvalTaskInput) - V2EvalResult: ...各适配器的改写要点适配器变更v2_eval_llm_judge.pyreturn V2EvalResult(scoresscores, intermediate_outputsrun_output.intermediate_outputs)——停止丢弃run_output.intermediate_outputs原 165 行skip 路径返回V2EvalResult(skipped_reasonskip, skipped_detaildetail)v2_eval_code_eval.pyV2EvalResult(scores...)trust-skip 返回V2EvalResult(skipped_reason..., skipped_detail...)intermediate_outputs保持Nonev2_eval_tool_call_check.py、v2_eval_exact_match.py、v2_eval_contains.py、v2_eval_pattern_match.py、v2_eval_set_check.py、v2_eval_step_count_check.py机械化改写把已有的(scores, skip, detail)返回包进V2EvalResult(...)从当前源码看v2_eval_llm_judge.py的evaluate已完整落地这一契约L254-L260return V2EvalResult( scoresscores, intermediate_outputsrun_output.intermediate_outputs, # usage, not cumulative_usage: it already accumulates every call this # judgment made, and it is the one that carries latency. usagejudge_run.usage, )而 skip 路径缺引用键、模板渲染失败、引用未知变量等均返回V2EvalResult(skipped_reason..., skipped_detail...)intermediate_outputs为None——与文档仅 llm_judge 填充 intermediate_outputs其余 7 个保持 None的约定一致。2.3 消费者5 个调用点调用点 1BaseV2EvalBridge.run_evalbase_eval.py。签名- tuple[EvalScores, Dict[str,str] | None]不变但内部改为解构V2EvalResulteval_task_input EvalTaskInput.from_task_run(task_run) result await self.evaluate(eval_task_input) if result.skipped_reason is not None: raise ValueError( fV2 eval was skipped ({result.skipped_reason}): {result.skipped_detail} ) return result.scores, result.intermediate_outputs之前该路径返回(scores, None)现在 fresh-generation 路径也能携带推理结果。调用点 2eval_runner.py的_run_v2_job三路分支。三个 evaluate 分支from_eval_input、task_run_eval、默认eval_config_eval现在都解构result.*并构造EvalRun其中intermediate_outputs是新增的持久化字段。当前实现中三路分支统一汇聚到 eval_runner.py 的_persist_judgmentreturn await self._persist_score( job, scored_run_idtrace.id, scoresresult.scores, skipped_reasonresult.skipped_reason.value if result.skipped_reason else None, skipped_detailresult.skipped_detail, intermediate_outputsresult.intermediate_outputs, eval_usageresult.usage, )需要强调的是这是一次纯内部契约变更不涉及任何数据模型/存储迁移——EvalRun.intermediate_outputs字段早已存在类型正是dict[str, str] | None见 eval.py字段描述为 The intermediate outputs of the task (example, eval thinking)。调用点 3eval_api.py的test_v2_eval。读取result.scores/result.skipped_reason/result.skipped_detail/result.intermediate_outputs构建TestV2EvalResponse§6 详述。三、D14 / D15KilnEvalHelpers的 trace 导航修复§2KilnEvalHelperseval_helpers.py是一个纯标准库工具集Stdlib only — no Pydantic, no Kiln-model/DB/UI imports用户在自己编写的 code-eval 评分器scorer中显式导入使用from kiln_ai.adapters.eval.eval_helpers import KilnEvalHelpers官方提供的 code-eval 示例画廊example gallery依赖get_tool_calls因此这两个方法的正确性直接影响官方示例的可用性。3.1 真实的 trace 格式工具调用嵌套在 assistant 消息里Kiln 的 trace 遵循 OpenAI 约定。工具调用不是顶层条目而是嵌套在role: assistant消息内部{ role: assistant, content: null, tool_calls: [ {id: call_1, type: function, function: {name: search, arguments: {\q\: \cats\}}} ] }正确的提取逻辑已经存在于 v2_eval_tool_call_check.py 中——D14/D15 的做法就是复用这套逻辑提取function.name、JSON 解析function.arguments而不是另起炉灶。3.2 D14get_tool_calls修复修复前有缺陷过滤条件为role tool_call或type tool_call——这个形态在真实 trace 中永远不会出现因此对任何真实工具调用 trace 都会返回[]。测试之所以通过仅仅是因为 test_code_eval_samples.py 里用了合成的role: tool_calltrace——这正是用伪造数据喂测试导致缺陷发货的典型教训。修复后遍历role assistant消息把每个tool_calls条目展平为{name: function.name or , arguments: json.loads(function.arguments) → dict, {} on parse failure, id: tool_call.id or None}要点均来自 architecture.md §2.1 与当前源码 eval_helpers.pyname/arguments两个键是has_tool_call/count_tool_calls消费的保持这两个方法无需改动即可继续工作id是新增的用于对齐 spec §3.1 的{name, arguments, id}契约arguments永远是dictJSON 字符串解析失败JSONDecodeError/TypeError或解析结果非 dict 时回退为{}None/ 空 trace →[]对畸形数据永不抛异常非 dict 的function、缺失的name、无法解析的arguments都会产出{name: , arguments: {}, id: ...}。3.3 D15get_assistant_messages修复修复前类型错误返回list[dict]完整的 assistant 条目。修复后返回每个role assistant消息的内容字符串返回类型- list[str]staticmethod def get_assistant_messages(trace): if not trace: return [] return [ msg[content] for msg in trace if msg.get(role) assistant and isinstance(msg.get(content), str) ]content缺失或非字符串的 assistant 轮次例如纯工具调用轮次content: null会被省略。这是一个破坏性签名变更但符合文档化 spec 契约且没有任何已发布的示例画廊调用此方法因此安全。从当前 test_eval_helpers.py 看真实格式 fixtureassistant 嵌套tool_calls与content: null省略场景的测试均已在库中。3.4 硬性质量门槛§2.3 / §2.4这是本项目中最特殊的验收要求且是流程性风险而非代码性风险批准 D14/D15 之前必须手动对一条真实的、包含真实工具调用的 Kiln trace例如从一次实时的工具调用任务运行中捕获运行这两个方法确认get_tool_calls返回调用、get_assistant_messages返回内容字符串。Agent 手工编造的 fixture 不足以作为验收依据——因为最初的缺陷恰恰就是因为测试使用了伪造的 trace 形态而混过检查的。文档原文的表述值得记住Approval of D14/D15requires a manual runof both methods against areal Kiln trace containing actual tool calls… Agent-authored fixtures areinsufficient.四、D27–D30eval.py保存时校验器§3四个修复全部在 V2 的*Properties或EvalConfig的模板校验器上加构造时校验让脚枪在保存时失败而不是在运行时静默出错。它们与 Project 1 的set_check枚举工作共享 eval.py但触碰的是不同类冲突风险低。校验在EvalConfig/*Properties构造时执行因此同时拦截两条路径持久化保存路径以及test_v2_eval的瞬态配置路径后者也会构建EvalConfig。每个校验器都必须产出可供创建 UI 保存错误直接展示的用户可读ValueError。4.1 D28ArgMatch正则保存时编译位置ArgMatchmatch_mode regex时。行为加model_validator(modeafter)对re.compile(str(self.value))调用re.error时抛出ValueError(fInvalid regex value {self.value}: {e})镜像已有的PatternMatchProperties.validate_pattern模式。为什么阴险运行时re.search被try/except re.error包裹并返回False见v2_eval_tool_call_check.py——一个无效正则静默地永远不匹配用户毫无反馈。当前源码中ArgMatch的validate_regexeval.py与PatternMatchProperties.validate_patternL177-L191均已按此落地。注意exact/contains模式跳过编译边界情况 §7 明确要求。4.2 D30AST 级无用模板检查位置EvalConfig.validate_v2_templates_and_expressions的LlmJudgeProperties分支。现状有缺陷表面扫描——if {{ not in tmpl and {% not in tmpl: raise只能拦住零变量模板。绕过的漏洞{{ reference_data.expected_output }}含有{{因而通过检查但它只引用reference_data——渲染出的法官提示词与模型输出完全无关这个 eval 毫无意义。修复解析模板 AST 并检查顶层变量引用。渲染命名空间恰好是EvalTaskInput.model_dump(){final_message, trace, reference_data, task_input}。拒绝保存除非至少一个被引用的顶层变量属于{final_message, trace, task_input}即既不能只引用reference_data也不能零变量。实现jinja2.meta.find_undeclared_variables(_template_env.parse(prompt_template))返回顶层名称集合trace[0].content这类子路径仍会浮现顶层trace因此通过。错误消息必须解释模板从不读取模型输出并给出{{ final_message }}之类的建议。在此之前保留原有的compile_template_or_raise语法检查调用。当前实现位于 eval.py且MEANINGFUL {final_message, trace, task_input}的注释明确写着 reference_data deliberately excluded——与文档设计完全一致。4.3 D27expected_tools非空位置ToolCallCheckProperties.expected_tools。行为要求非空Field(min_length1)Pydantic v2或等价的model_validator空列表抛ValueError。为什么空列表在all/ordered/never模式下是空真vacuous pass在any模式下则必然失败——一个按模式静默永远通过/永远失败的检查。当前实现为expected_tools: list[ToolCallSpec] Field(min_length1)eval.py。4.4 D29reference_key的min_length1位置三处reference_key: str | None字段——ExactMatchProperties、ContainsProperties、SetCheckProperties。行为设置时必须非空。None仍然合法XOR 校验器允许reference_key与expected_value恰好一个为None只有空字符串是新被拒绝的。用min_length1加在字段上保留| None或使用校验器以不破坏既有 XOR 语义为准。为什么不是None因此今天能通过 XOR 检查然后在运行时永远 skip not in reference_data。当前三个类均实现为reference_key: str | None Field(defaultNone, min_length1)eval.py且各自的 XOR 校验器Exactly one of … must be set保持不动——边界情况 §7 明确None仍合法仅被拒。五、D31暴露 V2llm_judge推理§4、§55.1 后端捕获 持久化 暴露D31 的实质性改动在 v2_eval_llm_judge.pyjudge_run, run_output await adapter.invoke_returning_run_output(rendered_prompt)invoke_returning_run_output已经产出run_output.intermediate_outputs——SIMPLE_CHAIN_OF_THOUGHT法官会发出{chain_of_thought: ...}。现在把它传进V2EvalResult.intermediate_outputs§2.2 的代码已展示。skip / 必需变量缺失路径原 105-107 行携带None。后端链路_run_v2_job的三条 V2 分支统一经_persist_judgment持久化到EvalRun.intermediate_outputs。没有任何其他适配器产生推理code_eval的 stdout 捕获明确列为范围外Out of scope。5.2 前端运行结果页的View reasoning模态框线程化 prop在run_result/page.svelte的svelte:component上加intermediate_outputs{result.intermediate_outputs ?? null}EvalRun的 TS 类型上intermediate_outputs已存在V1 路径已在读取它。渲染器llm_judge_result.svelte加 prop 与一个Dialog实例镜像run_result/page.svelte中thinking_dialog的既有模式export let intermediate_outputs: Recordstring, string | null null $: reasoning intermediate_outputs?.reasoning || intermediate_outputs?.chain_of_thought || null let reasoning_dialog: Dialog | null null当reasoning存在时渲染一个小的View reasoning按钮text-xs链接样式与既有的text-gray-400配置块风格一致点击调用reasoning_dialog?.show()。Dialog titleJudge Reasoning内放div classfont-light text-sm whitespace-pre-wrap{reasoning}/div。从当前源码 llm_judge_result.svelte 看这套实现已完整落地reasoning 提取、两个渲染分支、Dialog bind:this模态。明确的设计约束code_eval_result.svelte及其他无推理的渲染器不做任何改动不重新启用 Thinking 列V1 列的逻辑保持原样不采用内联展开/折叠必须是模态框聚合/对比视图不展示推理它们显示跨多轮的均值单次推理不属于那里推理为空时法官未产出 chain-of-thought不显示任何推理入口skipped 运行时intermediate_outputs为None渲染器显示既有的 skip 徽章。5.3 测试面板边界test_v2_eval会在TestV2EvalResponse上返回intermediate_outputs后端。但 Test-Your-Judge 面板的推理 UI 属于 Project 1 的创建容器表面不在本项范围内——D31 只负责让数据可用。六、D35聚合视图的n_excluded(i) 指示器§7当部分数据集用例被跳过/排除时聚合分数会静默地低估覆盖率。D35 的目标就是让均值不被误读。6.1 触发与展示触发条件某个 run config或法官对比面上的某个法官的n_excluded 0。UI一个小的 info (i) 符号复用既有的InfoTooltip组件模式对比视图本已导入tooltip 文案为{n_excluded} of {n_used n_excluded} cases were skipped and are not reflected in this score.。按严重度着色skip 比率 n_excluded / (n_used n_excluded) 0%且≤ 20%→黄色warning 色 20%→红色error 色。与既有的percent_complete 1.0不完整警告缺跑相互独立——两者可同时出现描述的是不同条件。InfoTooltip的 SVG 用fillcurrentColor因此包裹它的text-warning/text-errorspan 会自动给 (i) 字形上色——无需改动组件本身。6.2 数据来源与展示面主面——对比视图run_config_comparison_table.svelten_excluded位于每个ScoreSummary中results[run_config_id][score_key].n_excluded且在一个 run config 的各 score key 间恒定在eval_api.py按 run config 设置。每行只读一次。当前源码L40-L48 的excluded_for_run_config辅助函数与 L232-L240 的渲染已按此实现。次面——法官对比视图RunConfigEvalResult.n_excludedeval_api.py已暴露若该表面渲染聚合每运行分数则应用同样的图标 tooltip 模式。6.3 范围决策pushback原始 spec 文案…required reference data missing、按SkippedReason细分暗示要做按原因的分类统计。但聚合 API 只暴露计数n_excluded且不同行可能因不同原因 skip。决策tooltip 只报告计数按原因的文案不在范围内单项 skip 原因已在eval_result_scores.svelte中逐条展示。暴露按原因聚合需要新的 API 工作——明确排除。数据流要点这是纯前端改动——数据已经通过 API 与生成的 TS schema 流转到位。七、API 契约与 schema 再生成§6端点 / 模型变更TestV2EvalResponseeval_api.py增加intermediate_outputs: dict[str, str] | None Noneevaluate()内部所有 V2 适配器返回V2EvalResult而非三元组§2没有新增 HTTP 路由、没有请求形态变更、没有数据模型/存储迁移。唯一的额外工作是为TestV2EvalResponse新字段重新生成 OpenAPI 客户端并提交使check_schema通过脚本位于 app/web_ui/src/lib/generate_schema.sh。从当前源码看TestV2EvalResponse已含intermediate_outputs与score_range_errors、tool_call_log等字段——schema 再生成环节已落地。八、测试策略与质量门槛§8、§9领域测试§1V2EvalResult既有 V2 适配器测试改为断言result.scores/result.skipped_reason/result.intermediate_outputstest_v2_dispatch_and_contract.py覆盖形态runner 测试断言EvalRun.intermediate_outputs对 llm_judge 持久化、对 code_eval 为None§2 D14/D15真实格式 fixtureassistant 嵌套tool_callsget_tool_calls返回[{name,arguments,id}]get_assistant_messages返回list[str]、省略content:null轮次批准前手动真实 trace 门槛§2.3更新test_eval_helpers.py与test_code_eval_samples.py§3 D27–D30逐校验器的接受/拒绝空expected_tools被拒坏正则ArgMatch被拒reference_key被拒但None被接受D30 的{{ reference_data.x }}独用模板与纯字面量模板被拒{{ final_message }}/{{ trace[0].content }}/{{ task_input }}被接受§4–6 D31llm_judgeevaluate()返回推理_run_v2_job持久化它test_v2_eval返回它web 测试llm_judge_result.svelte有推理时显示 View reasoning → 模态框无推理时隐藏§7 D35web 测试(i) 在n_excluded0时出现、为 0 时消失≤20%显示text-warning、20%显示text-error与不完整运行警告共存每个阶段 CR代码评审之前都要跑完整检查套件lint / format / type、py web 测试、schema、build。边界情况清单functional_spec.md §7同样值得直接引用D14 畸形tool_calls非 dictfunction、缺name、arguments无法解析 → 该调用仍产出{name: , arguments: {}, id: …}helper 对坏 trace 永不抛异常D14/D15 非 assistant / 混合 trace只考虑role assistant条目user/tool/system 忽略D15 content 形态content: null或列表型 content → 省略只返回字符串 contentD30 合法边界模板{{ task_input }}、{{ trace[0].content }}、{% if final_message %}…{% endif %}均通过仅{{ reference_data.x }}和纯字面量被拒D28 非 regexArgMatchexact/contains模式跳过编译D29NonevsNone仍合法XOR 控制仅新被拒D31 skipped 运行skipped_reason已设 →intermediate_outputs为None渲染器显示既有 skip 徽章D31 空推理法官无 chain-of-thought → 无 View reasoning 入口D35 零排除 / 严重度边界n_excluded 0→ 无图标比率恰好20%→ 黄 20%→ 红n_used 0 n_excluded 0→ 比率 100% → 红图标全 skip均值已为None/unknown。九、执行顺序与风险协调§9、§10执行规划为两个阶段implementation_plan.md当前两个阶段均已完成 ✅阶段 1 —— 后端脊柱 helpers 校验器V2EvalResult迁移§1 D14/D15§2 D27–D30§3 D31 后端捕获§4。全部在libs/core/ API 层互相兼容一个 CR 提交。阶段 2 —— 前端 API 表面TestV2EvalResponse字段 schema 再生成§6、D31 推理模态框§5、D35 (i) 指示器§7。一个 CR 提交。两阶段划分把手动真实 trace 门槛阶段 1与 UI 评审阶段 2分离保证每个 CR 可评审。若偏好单阶段合并也允许——实现计划默认建议两阶段。风险与协调要点Project 1 共享eval.py它的set_check枚举工作与 D27–D30 触碰不同的类/字段小心 rebase 即可冲突风险低。V2EvalResult迁移触碰的适配器文件不在 Project 1 范围。evaluate()签名变更面广8 个适配器 5 个调用点但机械——类型检查器ty会标记任何遗漏的调用点可以依赖它兜底。手动 trace 门槛是流程风险而非代码风险绝不能用合成 fixture 批准 D14/D15。十、总结这类评测基础设施收尾项目的可复用方法论回顾 Evals V2 Cleanup能提炼出几条对任何 AI 评测系统都适用的工程原则契约先行、模型优于元组V2EvalResult把(scores, skip_reason, skip_detail)的隐性三元组升级为自文档化模型换来的是后续usage等字段零成本扩展——正如仓库源码所示。用真实数据形状约束测试D14/D15 的教训是合成 fixture 会掩盖真实 trace 形态的缺陷对应的对策是批准前必须手动跑真实 trace这一硬性流程门槛。错误要在保存时暴露而不是运行时静默D27–D30 的全部动机都是把正则编译错误、空expected_tools、空reference_key、无意义模板这类脚枪前移到保存时刻其中 D30 用jinja2.meta.find_undeclared_variables做 AST 级检查而非{{表面扫描堵住了reference_data独用模板的旁路。聚合视图必须披露数据覆盖度D35 用分色 (i) 图标提示n_excluded避免均值被静默误读同时克制地只报计数、不做按原因聚合。小修复也要独立评审与分阶段即使每项都是外科手术式改动也要通过两阶段 CR、完整检查套件和明确的范围外清单Out of scope来控制质量与并行安全。如果你正在维护自己的评测系统可以直接参照本项目的做法先梳理内部的 evaluate 契约与数据流适配器 → runner → API → 前端渲染器再对照真实 trace 形状逐个修正数据解析最后用保存时校验器把配置错误挡在运行之前。赞分享人工智能AI 应用AI 评测RAG微调提示工程开发工具桌面应用【免费下载链接】KilnBuild, Evaluate, and Optimize AI Systems. Includes evals, RAG, agents, fine-tuning, synthetic data generation, dataset management, MCP, and more.项目地址https://gitcode.com/gh_mirrors/ki/Kiln点击查看免费下载相关推荐Kiln Evals V2 扩展性契约封闭类型目录、code_eval 逃生舱与四条插件架构缝隙Kiln Evals V2 扩展性契约封闭类型目录、code_eval 逃生舱与四条插件架构缝隙 Kiln 的 Evals V2 采用封闭目录 code人工智能AI 应用AI 评测RAG微调提示工程开发工具桌面应用MLOpsKiln Evals V2 数据模型全解析Eval、EvalConfig、EvalInput 与 EvalRun 的架构设计Kiln Evals V2 数据模型全解析Eval、EvalConfig、EvalInput 与 EvalRun 的架构设计 导读 本文以 Kiln 开源仓库人工智能AI 应用AI 评测RAG微调提示工程开发工具桌面应用MLOpsKiln Evals V2 架构全解数据模型、两级 Adapter 分发与 V1/V2 共存设计Kiln Evals V2 架构全解数据模型、两级 Adapter 分发与 V1/V2 共存设计 Kiln Evals V2 是一套在 libs/core/k人工智能AI 应用AI 评测RAG微调提示工程开发工具桌面应用MLOps上一篇Z80开源硅克隆揭秘4位ALU与16位寄存器堆的终极设计下一篇DeepChat窗口状态持久化electron-window-state实现原理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考