no-mistakes Agent Tuning 统一配置层internal/agentcfg解析模型与推理深度如何跨 Harness 归一化【免费下载链接】no-mistakesgit push no-mistakes项目地址: https://gitcode.com/GitHub_Trending/no/no-mistakes本篇技术指南围绕 no-mistakes 项目内部的Unified Agent Tuninginternal/agentcfg技能文档展开系统讲解它如何把「操作者想要什么模型、多深的推理」这一层与具体 agent CLI 的解耦开一个agent_configProfile 同时驱动 claude/copilot 的--effort、codex 的-m与-c model_reasoning_effort、grok 的--reasoning-effort、pi 的--thinking、opencode 的会话消息体以及 acpx 的--model。读完本文你将掌握这一层的设计动机、固定优先级规则、fail-closed 校验路径以及它如何与 eval 回放候选共享同一条映射链路。一、为什么需要一层 harness-neutral 的调优层在internal/agentcfg出现之前no-mistakes 的流水线只有agent_args_override这一个配置杠杆操作者必须记住每一种 agent CLI 自己的原生旗标而 eval 路径上还维护着第二份、且与流水线分叉的模型规则。internal/agentcfg包正是为消除这一重复而存在。该包在 internal/agentcfg/agentcfg.go 的包注释中明确了自己的边界它是「harness-neutral 的模型 / effort 表面surface」与「映射到各 harness 原生机制」的唯一所有者它是一个归一化层仅此而已从不启动进程、从不读取配置文件、不持有任何状态各 harness 的差异被收敛为「操作者说一次映射层按 harness 表达一次」。各 harness 的差异本质来自源码注释与映射表Harness原生表达方式claude / copilot--effort、--modelargv 旗标codex-m指定模型 -c model_reasoning_effort…TOML 式配置覆盖grok--reasoning-effort、--modelpi--thinking同一概念的不同叫法opencode无启动旗标模型与 variant 都承载于会话消息体session-message bodycursor /acp:target通过 acpx 的--model驱动no-mistakes 自身不直接说 ACP 协议rovodev / antigravity刻意声明为不可映射1.1 为什么 opencode 走「request」机制而不是 argvopencode serve会直接拒绝模型与 variant 旗标未知选项即报 usage 退出因此 opencode 的两个旋钮无法放进启动命令行只能随会话消息体携带。internal/agentcfg为此定义了三种机制agentcfg.goMechanismUnsupportedno-mistakes 没有已验证的方式为该 harness 设置该旋钮MechanismArgs把原生 CLI 旗标注入到已经构建好的 argv 中MechanismRequest值由适配器在自己的协议中携带如 opencode 的会话消息体而非 argv。1.2 为什么 rovodev 与 antigravity 被「拒绝」而不是「忽略」rovodev通过acli rovodev serve加 REST 会话 API 驱动其会话 API 不接受模型参数antigravity 的agyCLI 严格解析旗标。两者都没有 no-mistakes 可以设置的机制因此对它们的请求会被当作配置错误拒绝invalid agent_config.rovodev: agent rovodev cannot express model; …而不是发出一个被静默忽略的旗标。这是 fail-closed 原则的直接体现一个 run 绝不能报告它实际没有用过的模型或 effort。二、agent.NewWithOptions唯一的构造漏斗internal/agent包中的NewWithOptions是全部 agent 构造的唯一漏斗internal/agent/agent.go其职责有两层校验调用agentcfg.Validate(name, opts.Profile)fail-closed 地拒绝任何该 harness 无法表达的旋钮。配置文件加载时也会做同样的检查但这里保证包括 eval 回放和直接构造 Profile 的程序化调用方在内所有路径都经过同一道关卡——一个 run 永远不可能报告它没有实际使用的模型或 effort拼接通过agentcfg.NativeArgs(name, opts.Profile, extraArgs)生成映射后的 argv 片段并拼接在操作者原始agent_args_override参数之后if mapped : agentcfg.NativeArgs(name, opts.Profile, extraArgs); len(mapped) 0 { merged : append(merged, extraArgs...) // 原始 agent_args_override 在前 merged append(merged, mapped...) // 映射出的旗标在后 extraArgs merged }这意味着流水线路径cfg.AgentProfileFor与 eval 回放路径Candidate.Profile()到达每个 harness 的是同一条路径。技能文档特别强调绝不要在调用点重新推导模型或 effort 旗标——任何新需求都应进入agentcfg的映射表而不是在适配器或 eval 里另起炉灶。三、固定优先级agent_args_override永远赢优先级规则是固定且单向的agentcfg.go 包注释一条原始agent_args_override旗标若已原生钉住了某个旋钮则它永远优先映射值不再输出。这条规则解决了两个实际问题字节级兼容让所有早于agent_config的既有配置保持逐字节不变——为某个旋钮加一个agent_config条目绝不会改变该配置原本提供的参数见 docs/src/content/docs/reference/global-config.md 中的示例model被原始-m o3钉住时被忽略而未被钉住的effort: low照常生效避免同一个旋钮出现两次不同 harness 对重复参数的处理各不相同——first-wins、last-wins 甚至直接硬报错因此绝不能让 CLI 收到同一旋钮的两份值。「钉住pinned」的判定由flagPinned/codexConfigPinned实现agentcfg.goflagPinned同时匹配--flag value与--flagvalue两种拼写并覆盖该 harness 对同一旋钮的所有别名如 grok 的--model与-mcodexConfigPinned额外识别-c keyvalue、-ckeyvalue、--config keyvalue等形态且精确匹配键名——嵌套在无关选项值里的model文本不算钉住。同理agent_config与agent_args_override一样仅限全局配置在~/.no-mistakes/config.yaml中设置仓库内的.no-mistakes.yaml中的对应块会被忽略——因为它们决定的是「用你的凭据跑哪个模型」属于机器级而非仓库级决策。四、Effort 词表与校验宁可让 harness 拒绝也不让陈旧表误杀agentcfg.Effort是 harness-neutral 的推理深度旋钮词表是各受支持 harness 所接受等级的并集agentcfg.gominimal, low, medium, high, xhigh, max两个关键设计决策值得注意词表在配置加载时严格校验ParseEffort把拼写错误typo挡在配置加载阶段invalid effort xxx (valid: minimal, low, medium, high, xhigh, max)而不是等到运行时才发现刻意不按 harness 门控取值范围因为每个 CLI 发布都会漂移一张陈旧的「每个 harness 允许哪些级别」表反而会拒绝一个新合法级别——那比 harness 自己报告「不认识这个级别」更糟。各 harness 实际接受的范围记录在 docs/src/content/docs/reference/global-config.mdAgentmodel机制effort机制接受的 effort 级别claude--model--effortlow/medium/high/xhigh/maxcodex-m-c model_reasoning_effort…minimal/low/medium/highgrok--model--reasoning-effort取决于所选推理模型copilot--model--effortminimal/low/medium/high/xhigh/maxpi--model--thinkingminimal/low/medium/high/xhigh/maxopencode会话消息体model需provider/model形式会话消息体variant取决于 providercursor/acp:*acpx --model不可表达—rovodev/antigravity不可表达不可表达—注意 codex 的两个旋钮形态不同模型是真实旗标-m而推理深度是 TOML 配置覆盖codexConfigArgs渲染为-c model_reasoning_effort…引号是参数的一部分与 codex 对字符串配置值的文档拼写一致。opencode的模型必须使用provider/model形式例如openai/gpt-5因为其会话 API 把 provider 与 model 拆成两个独立字段。requireProviderModel在校验期就抓住裸gpt-5这种写法agentcfg.go避免它被静默丢弃SplitProviderModel同时被 eval 回放用来把带前缀的候选与「分开报告 model 与 provider」的适配器做身份比较。4.1 完整配置示例来自 internal/config/config.go 的全局配置示例# agent_config: 每个 agent 的模型与推理深度一种统一拼写 agent_config: codex: model: gpt-5.4 effort: low claude: model: sonnet effort: high opencode: model: openai/gpt-5 # agent_args_override: 额外原生 CLI 旗标仅限全局 # 这里出现的旗标总是胜过 agent_config 中的同一旋钮 agent_args_override: codex: - -m - gpt-5.4 - -c - service_tierpriority - -c - model_reasoning_effortlowparseAgentConfiginternal/config/config.go在加载时依次完成agent 名称合法性校验含cursor与acp:target动态目标、effort 词表校验、以及agentcfg.Validate的逐旋钮可表达性校验——任何一个不可映射的请求都会在加载时报错而不是在运行期被悄悄吞掉。五、eval 候选同一套映射同一个拼写eval 候选的拼写是agent,modelmodel[,effortlevel]docs/src/content/docs/reference/eval.mdno-mistakes eval run \ --cases diversified \ --candidate codex,modelgpt-5.4,effortlow \ --repeats 3几个关键约束直接来源于agentcfg的设计候选字段就是流水线agent_config暴露的同一组 harness-neutral 旋钮并通过同一个 per-harness 映射解析——候选能表达的正是真实 run 能表达的model必填让比较继承 harness 恰好解析到的默认模型是不可复现的effort可选取值为上文词表中的一项effort 属于候选身份的一部分codex,modelgpt-5.4,effortlow与codex,modelgpt-5.4,efforthigh被报告为两个候选而不是合并成一个早期agentmodel拼写已不再接受会得到迁移提示migration messagecursor/acp:target通过acpx --model钉住但不能携带effortrovodev与antigravity无任何机制直接被拒绝opencode必须用provider/model形式。5.1 回放不继承采集机的钉住配置capture 阶段由agentNeutralGlobalConfig剥离agent、agent_args_override、agent_config以及review_agents因此回放永远不会继承采集机器上的 harness 钉住——候选是唯一决定 harness 以什么身份运行的东西。5.2 服务身份比较集中在ServedMatchesRequested当 harness 报告它实际服务的模型时回放会与请求的候选做身份校验。不要在调用点直接比较适配器报告的模型而应集中使用agentcfg.ServedMatchesRequestedagentcfg.go比较只取模型 ID 的最后一个/之后的片段provider 元数据与前面的路径段一律忽略。例如候选请求为openai/grok-4.6Pi 报告 modelgrok-4.6、providerxai——这算匹配模型名不同则回放失败。因此应保留带 provider 限定的候选而不是降级为裸模型名的变通写法。面向用户的归一化语义与候选指引完整记录在 docs/src/content/docs/reference/eval.md。六、扩展新 harness 的正确姿势技能文档给出了一条明确的纪律新增 harness 要加在agentcfg而不是适配器或 eval 里。映射表harnessesagentcfg.go覆盖 claude、codex、grok、copilot、pi、opencode 六个有机制可用的原生 agentacpHarnessagentcfg.go覆盖所有 ACP 驱动的名字cursor一级别名与显式acp:target拼写模型走acpx --modeleffort 刻意不可映射。代码注释明确表中每个原生旗标都读自该 harness 自己的--help而非推断。对于不可映射的旋钮escapeHatchagentcfg.go会在报错信息中指向正确出路ACP 目标应把旗标烘进acp_registry_overrides.target因为 ACP 名称不是合法的agent_args_override键其他 agent 则在你的 CLI 构建接受该旗标时使用agent_args_override.name。七、回归防线技能文档点名的测试技能文档列出的回归测试正是理解这一层行为的活教材internal/agent/profile_test.go—— 构造漏斗对 Profile 的校验与拼接internal/config/config_agent_config_test.go——agent_config的 YAML 解析、校验与加载期报错internal/daemon/pipeline_agent_profile_test.go—— 守护进程流水线如何取得每个 agent 的 ProfileTestParseCandidate*—— 候选拼写含agentmodel迁移拒绝的解析TestReplayPinsCandidateModelAndEffortOnTheHarness—— 回放确实把候选的 model/effort 钉到了 harness 上TestCaptureStripsEveryHarnessPinFromThePinnedConfig—— capture 剥离全部 harness 钉住agent/agent_args_override/agent_configTestServedMatchesRequested—— 服务身份比较集中在ServedMatchesRequestedTestReplayPiModelIdentityComparison—— Pi 适配器场景下的模型身份比较。这些测试与internal/agentcfg包本身、internal/agent/agent.go 的NewWithOptions、internal/config/config.go 的解析逻辑相互印证构成了「配置加载期校验 构造期 fail-closed 回放期身份比对」三道防线。八、总结no-mistakes 的 agent 调优层用三个核心决策换来了一致的跨 harness 体验单点归一化internal/agentcfg是 model/effort 表面及其到各 harness 原生机制映射的唯一所有者NewWithOptions是所有路径的唯一漏斗杜绝了调用点各自为政的重复推导固定单向优先级原始agent_args_override原生钉住即赢保证既有配置字节不变、同一旋钮不重复下发agent_config与它一样仅限全局fail-closed 而非静默忽略不可映射的旋钮rovodev、antigravity 的全部旋钮ACP 目标的 effort在配置加载期或构造期即被拒绝open code 的裸模型名在校验期即被拦截——一个 run 永远不会报告它没有实际用过的模型或 efforteval 回放也因此能与真实 run 共享完全相同的候选语义。【免费下载链接】no-mistakesgit push no-mistakes项目地址: https://gitcode.com/GitHub_Trending/no/no-mistakes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
no-mistakes Agent Tuning 统一配置层（internal/agentcfg）解析：模型与推理深度如何跨 Harness 归一化
no-mistakes Agent Tuning 统一配置层internal/agentcfg解析模型与推理深度如何跨 Harness 归一化【免费下载链接】no-mistakesgit push no-mistakes项目地址: https://gitcode.com/GitHub_Trending/no/no-mistakes本篇技术指南围绕 no-mistakes 项目内部的Unified Agent Tuninginternal/agentcfg技能文档展开系统讲解它如何把「操作者想要什么模型、多深的推理」这一层与具体 agent CLI 的解耦开一个agent_configProfile 同时驱动 claude/copilot 的--effort、codex 的-m与-c model_reasoning_effort、grok 的--reasoning-effort、pi 的--thinking、opencode 的会话消息体以及 acpx 的--model。读完本文你将掌握这一层的设计动机、固定优先级规则、fail-closed 校验路径以及它如何与 eval 回放候选共享同一条映射链路。一、为什么需要一层 harness-neutral 的调优层在internal/agentcfg出现之前no-mistakes 的流水线只有agent_args_override这一个配置杠杆操作者必须记住每一种 agent CLI 自己的原生旗标而 eval 路径上还维护着第二份、且与流水线分叉的模型规则。internal/agentcfg包正是为消除这一重复而存在。该包在 internal/agentcfg/agentcfg.go 的包注释中明确了自己的边界它是「harness-neutral 的模型 / effort 表面surface」与「映射到各 harness 原生机制」的唯一所有者它是一个归一化层仅此而已从不启动进程、从不读取配置文件、不持有任何状态各 harness 的差异被收敛为「操作者说一次映射层按 harness 表达一次」。各 harness 的差异本质来自源码注释与映射表Harness原生表达方式claude / copilot--effort、--modelargv 旗标codex-m指定模型 -c model_reasoning_effort…TOML 式配置覆盖grok--reasoning-effort、--modelpi--thinking同一概念的不同叫法opencode无启动旗标模型与 variant 都承载于会话消息体session-message bodycursor /acp:target通过 acpx 的--model驱动no-mistakes 自身不直接说 ACP 协议rovodev / antigravity刻意声明为不可映射1.1 为什么 opencode 走「request」机制而不是 argvopencode serve会直接拒绝模型与 variant 旗标未知选项即报 usage 退出因此 opencode 的两个旋钮无法放进启动命令行只能随会话消息体携带。internal/agentcfg为此定义了三种机制agentcfg.goMechanismUnsupportedno-mistakes 没有已验证的方式为该 harness 设置该旋钮MechanismArgs把原生 CLI 旗标注入到已经构建好的 argv 中MechanismRequest值由适配器在自己的协议中携带如 opencode 的会话消息体而非 argv。1.2 为什么 rovodev 与 antigravity 被「拒绝」而不是「忽略」rovodev通过acli rovodev serve加 REST 会话 API 驱动其会话 API 不接受模型参数antigravity 的agyCLI 严格解析旗标。两者都没有 no-mistakes 可以设置的机制因此对它们的请求会被当作配置错误拒绝invalid agent_config.rovodev: agent rovodev cannot express model; …而不是发出一个被静默忽略的旗标。这是 fail-closed 原则的直接体现一个 run 绝不能报告它实际没有用过的模型或 effort。二、agent.NewWithOptions唯一的构造漏斗internal/agent包中的NewWithOptions是全部 agent 构造的唯一漏斗internal/agent/agent.go其职责有两层校验调用agentcfg.Validate(name, opts.Profile)fail-closed 地拒绝任何该 harness 无法表达的旋钮。配置文件加载时也会做同样的检查但这里保证包括 eval 回放和直接构造 Profile 的程序化调用方在内所有路径都经过同一道关卡——一个 run 永远不可能报告它没有实际使用的模型或 effort拼接通过agentcfg.NativeArgs(name, opts.Profile, extraArgs)生成映射后的 argv 片段并拼接在操作者原始agent_args_override参数之后if mapped : agentcfg.NativeArgs(name, opts.Profile, extraArgs); len(mapped) 0 { merged : append(merged, extraArgs...) // 原始 agent_args_override 在前 merged append(merged, mapped...) // 映射出的旗标在后 extraArgs merged }这意味着流水线路径cfg.AgentProfileFor与 eval 回放路径Candidate.Profile()到达每个 harness 的是同一条路径。技能文档特别强调绝不要在调用点重新推导模型或 effort 旗标——任何新需求都应进入agentcfg的映射表而不是在适配器或 eval 里另起炉灶。三、固定优先级agent_args_override永远赢优先级规则是固定且单向的agentcfg.go 包注释一条原始agent_args_override旗标若已原生钉住了某个旋钮则它永远优先映射值不再输出。这条规则解决了两个实际问题字节级兼容让所有早于agent_config的既有配置保持逐字节不变——为某个旋钮加一个agent_config条目绝不会改变该配置原本提供的参数见 docs/src/content/docs/reference/global-config.md 中的示例model被原始-m o3钉住时被忽略而未被钉住的effort: low照常生效避免同一个旋钮出现两次不同 harness 对重复参数的处理各不相同——first-wins、last-wins 甚至直接硬报错因此绝不能让 CLI 收到同一旋钮的两份值。「钉住pinned」的判定由flagPinned/codexConfigPinned实现agentcfg.goflagPinned同时匹配--flag value与--flagvalue两种拼写并覆盖该 harness 对同一旋钮的所有别名如 grok 的--model与-mcodexConfigPinned额外识别-c keyvalue、-ckeyvalue、--config keyvalue等形态且精确匹配键名——嵌套在无关选项值里的model文本不算钉住。同理agent_config与agent_args_override一样仅限全局配置在~/.no-mistakes/config.yaml中设置仓库内的.no-mistakes.yaml中的对应块会被忽略——因为它们决定的是「用你的凭据跑哪个模型」属于机器级而非仓库级决策。四、Effort 词表与校验宁可让 harness 拒绝也不让陈旧表误杀agentcfg.Effort是 harness-neutral 的推理深度旋钮词表是各受支持 harness 所接受等级的并集agentcfg.gominimal, low, medium, high, xhigh, max两个关键设计决策值得注意词表在配置加载时严格校验ParseEffort把拼写错误typo挡在配置加载阶段invalid effort xxx (valid: minimal, low, medium, high, xhigh, max)而不是等到运行时才发现刻意不按 harness 门控取值范围因为每个 CLI 发布都会漂移一张陈旧的「每个 harness 允许哪些级别」表反而会拒绝一个新合法级别——那比 harness 自己报告「不认识这个级别」更糟。各 harness 实际接受的范围记录在 docs/src/content/docs/reference/global-config.mdAgentmodel机制effort机制接受的 effort 级别claude--model--effortlow/medium/high/xhigh/maxcodex-m-c model_reasoning_effort…minimal/low/medium/highgrok--model--reasoning-effort取决于所选推理模型copilot--model--effortminimal/low/medium/high/xhigh/maxpi--model--thinkingminimal/low/medium/high/xhigh/maxopencode会话消息体model需provider/model形式会话消息体variant取决于 providercursor/acp:*acpx --model不可表达—rovodev/antigravity不可表达不可表达—注意 codex 的两个旋钮形态不同模型是真实旗标-m而推理深度是 TOML 配置覆盖codexConfigArgs渲染为-c model_reasoning_effort…引号是参数的一部分与 codex 对字符串配置值的文档拼写一致。opencode的模型必须使用provider/model形式例如openai/gpt-5因为其会话 API 把 provider 与 model 拆成两个独立字段。requireProviderModel在校验期就抓住裸gpt-5这种写法agentcfg.go避免它被静默丢弃SplitProviderModel同时被 eval 回放用来把带前缀的候选与「分开报告 model 与 provider」的适配器做身份比较。4.1 完整配置示例来自 internal/config/config.go 的全局配置示例# agent_config: 每个 agent 的模型与推理深度一种统一拼写 agent_config: codex: model: gpt-5.4 effort: low claude: model: sonnet effort: high opencode: model: openai/gpt-5 # agent_args_override: 额外原生 CLI 旗标仅限全局 # 这里出现的旗标总是胜过 agent_config 中的同一旋钮 agent_args_override: codex: - -m - gpt-5.4 - -c - service_tierpriority - -c - model_reasoning_effortlowparseAgentConfiginternal/config/config.go在加载时依次完成agent 名称合法性校验含cursor与acp:target动态目标、effort 词表校验、以及agentcfg.Validate的逐旋钮可表达性校验——任何一个不可映射的请求都会在加载时报错而不是在运行期被悄悄吞掉。五、eval 候选同一套映射同一个拼写eval 候选的拼写是agent,modelmodel[,effortlevel]docs/src/content/docs/reference/eval.mdno-mistakes eval run \ --cases diversified \ --candidate codex,modelgpt-5.4,effortlow \ --repeats 3几个关键约束直接来源于agentcfg的设计候选字段就是流水线agent_config暴露的同一组 harness-neutral 旋钮并通过同一个 per-harness 映射解析——候选能表达的正是真实 run 能表达的model必填让比较继承 harness 恰好解析到的默认模型是不可复现的effort可选取值为上文词表中的一项effort 属于候选身份的一部分codex,modelgpt-5.4,effortlow与codex,modelgpt-5.4,efforthigh被报告为两个候选而不是合并成一个早期agentmodel拼写已不再接受会得到迁移提示migration messagecursor/acp:target通过acpx --model钉住但不能携带effortrovodev与antigravity无任何机制直接被拒绝opencode必须用provider/model形式。5.1 回放不继承采集机的钉住配置capture 阶段由agentNeutralGlobalConfig剥离agent、agent_args_override、agent_config以及review_agents因此回放永远不会继承采集机器上的 harness 钉住——候选是唯一决定 harness 以什么身份运行的东西。5.2 服务身份比较集中在ServedMatchesRequested当 harness 报告它实际服务的模型时回放会与请求的候选做身份校验。不要在调用点直接比较适配器报告的模型而应集中使用agentcfg.ServedMatchesRequestedagentcfg.go比较只取模型 ID 的最后一个/之后的片段provider 元数据与前面的路径段一律忽略。例如候选请求为openai/grok-4.6Pi 报告 modelgrok-4.6、providerxai——这算匹配模型名不同则回放失败。因此应保留带 provider 限定的候选而不是降级为裸模型名的变通写法。面向用户的归一化语义与候选指引完整记录在 docs/src/content/docs/reference/eval.md。六、扩展新 harness 的正确姿势技能文档给出了一条明确的纪律新增 harness 要加在agentcfg而不是适配器或 eval 里。映射表harnessesagentcfg.go覆盖 claude、codex、grok、copilot、pi、opencode 六个有机制可用的原生 agentacpHarnessagentcfg.go覆盖所有 ACP 驱动的名字cursor一级别名与显式acp:target拼写模型走acpx --modeleffort 刻意不可映射。代码注释明确表中每个原生旗标都读自该 harness 自己的--help而非推断。对于不可映射的旋钮escapeHatchagentcfg.go会在报错信息中指向正确出路ACP 目标应把旗标烘进acp_registry_overrides.target因为 ACP 名称不是合法的agent_args_override键其他 agent 则在你的 CLI 构建接受该旗标时使用agent_args_override.name。七、回归防线技能文档点名的测试技能文档列出的回归测试正是理解这一层行为的活教材internal/agent/profile_test.go—— 构造漏斗对 Profile 的校验与拼接internal/config/config_agent_config_test.go——agent_config的 YAML 解析、校验与加载期报错internal/daemon/pipeline_agent_profile_test.go—— 守护进程流水线如何取得每个 agent 的 ProfileTestParseCandidate*—— 候选拼写含agentmodel迁移拒绝的解析TestReplayPinsCandidateModelAndEffortOnTheHarness—— 回放确实把候选的 model/effort 钉到了 harness 上TestCaptureStripsEveryHarnessPinFromThePinnedConfig—— capture 剥离全部 harness 钉住agent/agent_args_override/agent_configTestServedMatchesRequested—— 服务身份比较集中在ServedMatchesRequestedTestReplayPiModelIdentityComparison—— Pi 适配器场景下的模型身份比较。这些测试与internal/agentcfg包本身、internal/agent/agent.go 的NewWithOptions、internal/config/config.go 的解析逻辑相互印证构成了「配置加载期校验 构造期 fail-closed 回放期身份比对」三道防线。八、总结no-mistakes 的 agent 调优层用三个核心决策换来了一致的跨 harness 体验单点归一化internal/agentcfg是 model/effort 表面及其到各 harness 原生机制映射的唯一所有者NewWithOptions是所有路径的唯一漏斗杜绝了调用点各自为政的重复推导固定单向优先级原始agent_args_override原生钉住即赢保证既有配置字节不变、同一旋钮不重复下发agent_config与它一样仅限全局fail-closed 而非静默忽略不可映射的旋钮rovodev、antigravity 的全部旋钮ACP 目标的 effort在配置加载期或构造期即被拒绝open code 的裸模型名在校验期即被拦截——一个 run 永远不会报告它没有实际用过的模型或 efforteval 回放也因此能与真实 run 共享完全相同的候选语义。【免费下载链接】no-mistakesgit push no-mistakes项目地址: https://gitcode.com/GitHub_Trending/no/no-mistakes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
