[!info] related notes

• 所属 MOC: agent-evals-moc、agent-moc
• 组合评测: agent-configuration-interaction-effects
• 运行溯源: agent-configuration-and-execution-provenance

Agent 配置组合

一句话定义

本文把 Agent 配置组合定义为作为整体被评测、批准和追踪的行为配置单元。它把会共同决定 Agent 行为的模型、Prompt、工具能力、推理模式、阈值与策略绑定成一个明确版本，而不是分别假设每个组件合格就能推出整体合格。

为什么需要这个概念

Agent 的行为不是由单一模型决定，而更接近：

Behavior = f(model, prompt, tools, reasoning mode, thresholds, policies, runtime settings)

因此：

Component 合格 ≠ Configuration 合格。

模型 A 在 Prompt v7 上稳定，不代表它在 Prompt v8 上仍稳定；某个 policy 单独合理，也不代表它和新的 reasoning mode 组合后没有副作用。

核心不变量

• 整体评测：上线证据绑定到一个完整 configuration，而不是只绑定模型名或 Prompt 版本。
• 版本不可变：已经完成评测的 configuration 应视为 immutable artifact；任何会改变行为的字段变化都产生新版本。
• 部署路由分离：canary 百分比、用户分流、流量权重属于 mutable deployment routing，不应偷偷修改 configuration 本体。
• 结果可归因：eval、trace、生产指标都应记录 configuration_id/version，并保留实际执行信息；单有配置版本不能证明实际使用的模型、工具和数据与批准条件一致。

最小例子

config-007
├─ model: Model A
├─ prompt: diagnosis-v8
├─ reasoning: preferred
├─ tools: evidence-search-v2
├─ safety-policy: safety-v5
└─ thresholds: diagnosis-thresholds-v3

如果把 model 换成 Model B，即使其余字段完全不变，也应得到新的 configuration identity，并重新验证关键行为。

与部署配置的边界

一个 deployment 可以把：

90% → config-007
10% → config-008

路由策略可以随发布过程调整，但 config-007 与 config-008 本身不应在原地变异。这样 rollback、replay、审计和配置比较才有稳定锚点。

配置身份与实际执行

以上名称与字段是治理模型示例，不表示某个项目已实现这套 schema。模型别名可能被供应商更新，工具与检索源也可能变化；稳定配置应尽量引用可解析的版本或内容摘要。实际 provider、fallback、工具结果与知识快照另由 执行溯源 记录。

配置是比较行为的锚点，不保证相同配置、不同输入或不同运行会产生相同输出。

常见误解

• “模型通过 benchmark 就能替换”：benchmark 只能证明模型在某些条件下表现合格，不等于目标 configuration 已通过。
• “Prompt 只改了几句话，不算新配置”：只要可能改变行为，就应产生新的可追踪版本。
• “deployment version 就是 configuration version”：前者回答流量被路由到哪里，后者回答实际行为逻辑是什么，两者应分开。