简介：本文围绕智能体框架的“自进化”能力展开评测型分析，拆解模型能力与框架工程的贡献边界。读者将获得一套可复用的评测框架：如何设计中立基线、如何划分可观测组件、如何用迭代轮次与消融实验归因性能变化，以及如何解读通过率、稳定性与成本指标，从而为自进化方案选型提供依据。
近一年来，智能体（Agent）在真实终端环境中的表现成为工程界关注的焦点。一个普遍共识正在形成：智能体完成复杂任务的能力，不只取决于底层模型本身的强弱，还在相当程度上取决于包裹在模型外层的执行框架——包括系统提示词、工具描述与实现、中间件、技能定义、子智能体配置、长期记忆等一整套“外骨骼”。业界将这类工程实践统称为 Harness Engineering（框架工程）。
围绕这一方向，出现了一类新的技术主张：不再由工程师凭直觉手工调优框架，而是让智能体在迭代循环中自动修改自身的框架配置，实现“自进化”。本文要评测的对象，正是这类智能体框架自进化机制——它能否在受控条件下稳定地带来能力提升，提升幅度如何归因，以及这种提升在什么条件下成立、在什么条件下会被高估。
本文适合以下读者：正在评估智能体框架方案的技术负责人、需要为 Coding Agent 类系统做架构选型的架构师、负责 Agent 平台稳定性与迭代效率的运维与平台工程师，以及希望建立内部评测规范的质量团队。本文不判断某一具体方案“好或不好”，而是提供一套可观察、可验证、可解释的评测逻辑，帮助读者结合自身业务规模、任务分布与维护成本做出判断。
需要说明的是，评测的目标不是给出单一排名，而是回答四个问题：自进化带来的增益是否真实；增益来自模型还是来自框架；增益是否可复现、可回滚；增益的代价（迭代成本、稳定性风险）是否可接受。
从工程视角看，自进化机制通常由三个角色协作构成，这一分工模式可作为评测的对象骨架：
评测时需要特别关注一个设计选择：初始框架的“洁净度”。如果初始框架已经堆满了人类经验（详尽的系统提示词、齐全的工具库、大量容错中间件），那么后续每一次改动带来的效果都难以归因——你无法区分提升来自进化循环，还是来自初始代码本身就写得好。因此，一个科学审慎的评测基线，往往从一个“白板”状态起步：只给执行角色最基础的工具能力，不含中间件、技能与子智能体。这一选择本身就是评测设计的一部分，而非实现细节。
与之相对，当前多数工程实践走的是相反路线：先把提示词写到极详、工具堆到极全、容错逻辑塞满，再在其上缝缝补补。两种路线都可用于评测，但基线不同则结论不可直接比较，这是读者解读任何自进化评测结果时的第一道门槛。
自进化能力的评测不能只看一个通过率数字。建议从以下维度建立框架，每个维度都对应可观察的证据。
| 维度 | 关注点 | 可观察证据 | 解读要点 |
|---|---|---|---|
| 能力增益 | 迭代后任务通过率变化 | 每轮迭代的通过率曲线 | 看趋势是否单调、是否早停 |
| 归因清晰度 | 增益来自模型还是框架 | 换模型后的同框架对比 | 同框架不同模型可分离两者贡献 |
| 组件可观测性 | 失败能否定位到具体组件 | 组件级失败分布 | 组件是否正交、是否解耦 |
| 可回滚性 | 每次变更是否可追溯 | 版本管理记录 | 变更粒度与回滚成本 |
| 稳定性 | 多轮运行是否一致 | 重复实验方差 | 方差大则增益可信度低 |
| 成本结构 | 迭代消耗与人力投入 | 迭代轮次、人工介入次数 | 增益是否值得代价 |
| 泛化性 | 跨任务分布是否成立 | 不同任务集的通过率 | 是否只对特定任务有效 |
能力增益是入口指标，但必须配合曲线看。单点提升容易受采样波动影响，连续多轮的单调上升才更具说服力；出现早停或震荡，则说明进化循环可能陷入局部最优或过拟合当前任务集。
归因清晰度是这类评测最容易被忽视、却最关键的一维。合理的做法是控制变量：固定框架版本，替换不同能力的底层模型，观察通过率变化；再固定模型，比较自进化框架与人工手写框架。只有两组对比都完成，才能说清“+N 个点”里有多少属于框架工程、多少属于模型本身。
组件可观测性决定了进化循环能否有效运转。可行做法是把框架拆成若干正交的文件级组件，例如系统提示词、工具描述、工具实现、中间件、技能、子智能体配置、长期记忆，每类组件一个独立文件、彼此解耦。这样当某任务失败时，可以精确定位到是哪一类组件的问题，而不是面对一整块难以解剖的提示词。所有修改通过版本管理记录，每次变更成为可追溯、可回滚的提交——这既是工程要求，也是评测要求：不可回滚的变更无法做消融实验。
稳定性要求重复实验。同一框架、同一任务集、同一模型，多次运行的通过率方差若偏大，则单次增益的数字意义有限。评测报告应给出重复次数与波动范围，而非只给一个点估计。
成本结构常被忽略。自进化需要多轮迭代，每轮都消耗执行、诊断与修改的算力与时间；若增益有限而迭代成本高，工程上未必划算。评测应记录达到目标增益所需轮次与人工介入次数。
泛化性用于检验增益是否只对评测任务集有效。建议准备一个与迭代集分布不同的留出任务集，观察增益是否保持。
在开始任何对比之前，需要固定以下前提，否则结论不可比：
建议按以下流程组织评测，可用伪代码示意记录逻辑：
for baseline in [白板基线, 人工手写基线, 自进化框架]:for model in [模型A, 模型B]:for seed in seeds:result = run(task_set, baseline, model, seed)record(pass_rate, cost, variance, component_failures)# 消融：固定模型，逐组件禁用自进化修改for component in [prompt, tool_desc, tool_impl, middleware, skill, subagent, memory]:result = run(task_set, framework_without(component), model, seed)record(delta_pass_rate)
具体方法包括：
对自进化类评测结果，建议按以下逻辑解读：
第一，看增益是否可分。若某方案报告从初始基线提升若干百分点，需追问：初始基线是否为白板状态；是否与人工手写框架做过同模型对比；换用更强模型后同框架是否继续提升。三者齐备，才能说明框架工程与模型能力各自的贡献。例如，若同一套自进化框架在较弱模型上取得一定提升、在更强模型上取得更大提升，说明框架与模型存在协同效应，而非框架单独作用。
第二，看增益的代价。达到该增益所需迭代轮次、单轮成本、是否出现性能回退，都应纳入判断。一个提升幅度可观但需要大量人工兜底的方案，其工程价值需打折。
第三，看结论边界。评测结论只在给定任务分布、给定模型版本、给定资源配额下成立。任务分布变化、模型升级、工具集调整都可能改变结论，因此评测报告应写明适用范围，而非给出普适结论。
第四，看可观测性是否支撑长期维护。组件是否正交、变更是否可回滚、失败能否定位，决定了这套机制在生产环境中能否持续迭代。评测时可通过“人为注入一个组件缺陷，看系统能否定位到该类组件”来验证这一能力。
适用场景：任务分布相对稳定、需要持续迭代框架的智能体平台；希望降低人工调优依赖、建立可复现迭代流程的工程团队；需要为框架改动建立归因机制的架构评审场景。
风险与限制：样本偏差（任务集不能代表真实分布）、环境差异（资源与网络波动影响通过率）、过拟合（进化循环针对评测集优化）、方差被低估（重复次数不足）、成本被低估（迭代算力与人力）。此外，自进化修改若缺乏审查，可能引入难以察觉的提示词漂移或工具描述歧义，需配合版本管理与回归测试。
基于上述评测逻辑，给出中立建议：优先选择组件正交、变更可追溯、支持消融实验的方案；在引入自进化机制前，先建立白板基线与人工手写基线两条参照线；把“换模型对比”和“组件消融”作为常规评测项固定下来；对增益数字保持条件化表述，将结论与任务分布、模型版本、资源预算绑定；在生产环境采用灰度发布与回滚预案，避免框架自动修改直接进入全量。
本文围绕智能体框架自进化机制，给出了从评测目标、评测对象、评测维度、评测环境、评测方法到结果解读的完整框架。核心判断可归纳为三点：增益必须可归因，即通过同框架换模型、同模型换框架的对照分离贡献；增益必须可回滚，即组件正交、变更版本化；增益必须条件化，即结论只在给定任务分布与资源约束下成立。对技术负责人而言，评测的价值不在于得到一个分数，而在于建立一套能持续回答“这次提升从哪来、值不值得、会不会退化”的工程方法。