Harmony Harness: Multi-Objective Self-Evolution of Agent Harnesses
Harmony Harness는 기능과 보안을 함께 평가하며 agent harness 전체를 진화시키고, 구성요소별 연산자와 과제별 workflow DAG로 실행을 구성합니다.
Paper: Weichen Yu; Lesly Miculicich; Bhavana Dalvi Mishra; Jiefeng Chen; Shuo Li; Matt Fredrikson; Tomas Pfister; Long T. Le (2026). "Harmony Harness: Multi-Objective Self-Evolution of Agent Harnesses". arXiv preprint, arXiv:2610.15150v1, 2026년 10월 10일, 41쪽. PDF · arXiv
Harmony Harness(HH)는 코드 생성 모델의 가중치를 다시 학습하는 대신, 모델 주변에서 작업을 지시하고 도구를 호출하며 결과를 검증하는 harness를 진화시킨다. 논문은 기능과 보안을 별개의 목적 함수로 탐색하고, 진화 과정에서 만든 도구·기술·제어 흐름을 실행 시점의 작업 계획에 조합한다. SecRepoBench와 BaxBench의 secure-pass@1 결과, 구성요소 절제, 교차 벤치마크 전이를 순서대로 살펴본다.
목차
1. 무엇을 측정하는가
보안 코드 생성에서는 코드가 테스트를 통과하는지와 취약점 공격에 안전한지를 함께 봐야 한다. 논문은 과제를 입력 x_n과 보안 평가에 쓰이는 정책 p_n으로 표현한다. solver는 x_n을 받아 코드를 만들고, p_n은 풀이 시점에 solver에게 공개되지 않는다. 기능 점수 F는 단위 테스트 통과 여부이고, 보안 점수 S는 산출물이 주어진 정책에 대해 안전한지를 나타낸다. 둘 다 성공이면 1, 아니면 0이다.
논문은 세 점수를 구분한다. f_func은 기능 성공률, f_sec은 보안 성공률, f_∧는 같은 실행 궤적에서 두 조건을 동시에 만족한 비율이다. 헤드라인인 secure-pass@1은 이 공동 성공률이다.
f_\wedge(H)=\frac{1}{M}\sum_{n=1}^{M}\mathbb{E}_{\tau\sim P_H(\cdot\mid x_n)}\left[F(\tau,x_n)S(\tau,p_n)\right].여기서 H는 harness이고, τ는 한 번의 풀이 궤적이다. 기능과 보안의 주변 성공률을 각각 높이는 것만으로는 같은 과제와 궤적에서 두 조건이 함께 성공한다고 보장할 수 없다. 그래서 논문은 탐색 중 두 marginal 점수를 이용해 실패한 성질을 진단하고, 최종 결과에서는 두 조건의 공동 성공률을 보고한다(Yu et al., 2026, §3).
보안 평가의 구체적인 성공 조건은 주어진 PoC(proof-of-concept) exploit을 무력화하는 것이다. 모든 취약점의 부재를 측정하는 지표는 아니다. 논문은 주변 성공률과 공동 성공률 사이의 Fréchet 경계를 제시하고, min(f_func,f_sec)−f∧를 gap으로 정의한다.
\max\{0,f_{\mathrm{func}}+f_{\mathrm{sec}}-1\}
\le f_\wedge \le \min\{f_{\mathrm{func}},f_{\mathrm{sec}}\}.2. harness를 목적별로 진화시키기
HH에서 진화 대상은 시스템 프롬프트만이 아니다. 도구 사용, agent loop, 검증 단계, orchestration을 포함한 harness 전체가 바뀔 수 있다. 평가에 쓰는 AgentHarness 인터페이스는 유지하고, 초기 harness H₀는 ReAct 방식의 최소 구성으로 시작한다.
탐색은 MOEA/D의 분해 방식을 따른다. 각 가중치 벡터 λ_i는 기능과 보안의 특정 균형을 나타내며, 그 하위 문제에 현재 후보인 incumbent H_i를 둔다. 현재까지 관측한 각 목적의 최고값을 이상점 z*로 갱신하고, 가중 Tchebycheff 점수로 이웃 후보를 비교한다.
\begin{aligned}
g^{te}(H\mid\lambda_i,z^*)&=\max_{j\in\{1,2\}}\lambda^i_j\left|z^*_j-\hat f_j(H)\right|,\\
z^*_j&=\max_H\hat f_j(H).
\end{aligned}새 자식이 평가되면 이웃의 incumbent보다 점수가 낮은 경우 그 자식을 넣는다. 이웃은 목적 가중치 사이의 거리로 정하며 교체 상한 설정은 n_r=2다. 자식 하나는 이웃 incumbent를 최대 두 개까지 교체한다. 각 자식은 보통 자신의 incumbent에서 생성된다. 부모와 실패 요약이 이전 세대와 같아 정체된 경우에는 이웃 중 해당 하위 문제 점수가 가장 좋은 후보를 부모로 삼을 수 있다. 논문은 이를 통해 목적별 후보 집단을 유지하면서 harness를 반복 개선한다(Yu et al., 2026, §4.1).
자식은 단일 부모에서 나오며 교차 연산은 사용하지 않는다. 부록의 SecRepoBench MOEA/D 단독 분석은 N=5, T=2, 3세대의 15개 자식을, BaxBench의 별도 front 분석은 N=6, 4세대의 24개 자식을 다룬다. 이 수치는 해당 보조 분석의 설정이다.
그림 1. Yu et al. (2026), Figure 1, p. 5. 목적 공간의 분해, 구성요소별 연산자에 의한 harness 진화, 실행 시점의 구성 과정을 보여준다.
탐색에서 자식을 비교하는 점수와 실제 배포할 harness를 고르는 규칙은 구별된다. U는 search split에서 평가한 자식 harness의 집합이다. 이 가운데 두 추정 점수의 낮은 값을 가장 크게 만드는 자식을 선택한다.
H^\dagger=\arg\max_{H\in U}\min\{\hat f_{\mathrm{func}}(H),\hat f_{\mathrm{sec}}(H)\}.이 선택은 search split의 평가 결과를 사용한다. 논문은 이를 고정된 이상점 (1,1)에서 두 목적에 같은 비중을 둔 Tchebycheff 기준으로 설명한다. 동률이면 더 이른 세대의 후보를 우선한다(Yu et al., 2026, §3).
3. 구성요소별 연산자와 동적 실행
진화 연산자는 세 구성요소에 적용된다. tools는 사용할 수 있는 도구와 그 동작을, skills는 재사용할 기술을, logic은 프롬프트·검증·제어 흐름·orchestration을 다룬다. 각 연산자는 모든 작업에 적용하는 general 또는 특정 환경에 적용하는 environment 범위로 지정된다. 진단, 변경 제안, 연산자 적용이 순서대로 이어질 수 있으며, 구성요소와 범위를 나누는 것은 탐색을 구조화하는 inductive bias다(Yu et al., 2026, §§4.2–4.3).
실행 시점에는 환경 정보와 과제 설명을 조건으로 composition planner가 workflow step의 방향성 비순환 그래프(DAG)를 만든다. DAG 노드는 workflow step이고, 연결은 실행 순서를 정한다. executor는 그래프를 검증한 뒤 위상 순서로 실행한다. 필요한 tools와 skills는 각 step이 불러온다. 따라서 진화 단계가 구성요소를 개선하고, composition 단계가 과제 실행을 위한 step 순서를 선택한다.
진단에는 목적별 통계와 컴파일 오류, 실패 테스트, crash trace 같은 실행 산출물이 들어간다. 연산자를 순차 체인으로 적용할 수 있으며, 중간 단계마다 성능을 평가하는 구조는 아니다. 변경 후 검증, 한 번의 repair, 실패 시 rollback 절차를 둔다. Scope별 디렉터리와 쓰기 허용 목록은 변경할 경로를 제한하며, generalize 연산자는 Promote·Demote·Derive로 구성요소의 범위를 조정한다.
추론 시에는 general 디렉터리와 활성 환경의 디렉터리를 불러온다. 구성 정책을 π_φ, 실행 구성을 C로 쓰면 다음과 같다.
\begin{aligned}
\mathcal A_{e,x}&=\pi_\phi(e,x,H^{gen},H^{env}_e),\\
H(e,x)&=\mathcal C(\mathcal A_{e,x}).
\end{aligned}4. 실험과 주 결과
주 실험은 SecRepoBench와 BaxBench에서 수행한다. 두 데이터셋 모두 탐색용 Search split과 held-out IN·OUT split으로 나뉜다. SecRepoBench는 각 30개, BaxBench는 각 28개 과제를 세 split에 배정한다. proposer와 solver는 Gemini 3.6 Flash를 사용한다. 기준선은 미진화 harness, 세 가지 meta-harness 설정, DGM 및 HH를 포함한다. 저자는 보고된 비율이 세 번의 독립 run 평균이라고 밝히며, 인프라 pull 실패나 timeout 과제는 해당 run의 집계에서 제외한다(Yu et al., 2026, §5).
그림 2. Yu et al. (2026), Figure 2, p. 8. SecRepoBench와 BaxBench에서 split별로 비교한 결과다.
아래 표의 값은 Table 9와 Table 10의 F&S 비율이며, 각 벤치마크의 세 split과 그 평균을 나란히 놓았다.
| 벤치마크 | 방법 | Search | Held-out IN | Held-out OUT | 평균 |
|---|---|---|---|---|---|
| SecRepoBench | Baseline | 46.7 | 50.0 | 36.7 | 44.4 |
| SecRepoBench | Meta-harness | 53.3 | 56.7 | 43.3 | 51.1 |
| SecRepoBench | Harmony Harness | 76.7 | 86.7 | 66.7 | 76.7 |
| BaxBench | Baseline | 42.9 | 42.9 | 42.9 | 42.9 |
| BaxBench | Meta-harness | 60.7 | 53.6 | 42.9 | 52.4 |
| BaxBench | Harmony Harness | 67.9 | 62.4 | 53.6 | 61.3 |
표 1. Table 9–10의 secure-pass@1(F&S), 퍼센트. 저자 보고 3회 평균이며, Meta-harness 행은 func&sec 설정이다.
논문 Table 1의 retained 지표는 공동 F&S가 아니라 보안 점수만을 사용한다. ΔOUT f_sec / Δevolve f_sec로, Search에서의 보안 증가분 가운데 held-out OUT에서 유지된 비율을 나타낸다. HH의 보고값은 SecRepoBench 55%, BaxBench 50%다(Yu et al., 2026, §5).
5. 절제와 실행 계획 비교
Table 2는 SecRepoBench evolve split에서 수용 규칙을 비교한다. 아래 조건은 factored evolving과 dynamic orchestration을 공유한다. Joint-weighted는 논문에서 세 α 설정을 한 행으로 보고한 값이다.
| 수용 방식 | Func (%) | Sec (%) | F&S (%) |
|---|---|---|---|
| HH | 76.7 | 93.3 | 76.7 |
| Sequential | 70.0 | 76.7 | 70.0 |
| Joint-weighted | 70.0 | 73.3 | 70.0 |
| Constrained | 70.0 | 60.0 | 60.0 |
| Separated | 60.0 | 60.0 | 53.3 |
| Prompt-merge | 66.7 | 60.0 | 50.0 |
Table 5는 SecRepoBench Search split에서 구성요소를 단계별로 더한 F&S 결과를 제시한다. Tchebycheff 방식의 합동 진화는 63.3%, factored evolving을 더하면 66.7%, 동적 orchestration까지 더하면 76.7%다. 별도의 held-out 비교인 Table 7에서는 monolithic 방식 35.0%, tools와 skills/logic을 함께 구성한 방식 58.3%, 전체 구성과 dynamic orchestration을 사용한 방식 76.7%다. 두 표는 서로 다른 평가 조건을 다룬다(Yu et al., 2026, Tables 5, 7).
Table 7은 목적 함수·예산·seed를 고정하고 진화할 구성 범위를 바꾼다. 결합 수치는 각각 30개 과제로 이루어진 held-out IN과 OUT의 비가중 평균이다.
| 비교 | 구성 | F&S |
|---|---|---|
| Table 5, Search | Joint Tchebycheff | 63.3 |
| Table 5, Search | + factored evolving | 66.7 |
| Table 5, Search | + dynamic orchestration | 76.7 |
| Table 7, held-out | Monolithic | 35.0 |
| Table 7, held-out | tools + skills/logic | 58.3 |
| Table 7, held-out | 전체 구성 + dynamic orchestration | 76.7 |
Table 6의 generalize 연산자 절제는 6개 과제 부분집합에서 수행된다. 논문은 이 결과를 작은 규모의 비교로 제시한다. 이에 비해 Table 8은 같은 진화 harness에서 고정 선형 실행과 동적 orchestration을 비교한다. F&S는 53.6%에서 64.3%로, 평균 workflow 노드는 5.0개에서 6.2개로, 평균 토큰은 58,230에서 63,064로 바뀐다. Table 8의 토큰 수는 해당 실행 비교에서 보고한 값이며, 진화 과정 전체 비용을 나타내지는 않는다(Yu et al., 2026, Tables 6, 8).
6. 전이와 CWEval
교차 벤치마크 전이에서는 한 벤치마크로 진화시킨 harness를 다른 벤치마크에 적용한다. Table 12의 평가는 target benchmark의 Search split에서 이루어지며 held-out 결과는 아니다.
그림 3. Yu et al. (2026), Figure 3, p. 10. 진화한 벤치마크와 평가한 벤치마크의 조합별 F&S 결과를 비교한다.
| 진화 → 평가 | 방법 | F&S |
|---|---|---|
| SecRepoBench → BaxBench | Target baseline | 42.9 |
| SecRepoBench → BaxBench | Harmony Harness | 57.1 |
| BaxBench → SecRepoBench | Target baseline | 46.7 |
| BaxBench → SecRepoBench | Harmony Harness | 70.0 |
또한 BaxBench에서 진화한 HH를 CWEval의 357개 사례에 적용한다. 비교 기준은 H0나 meta-harness가 아니라 Claude Code harness를 사용한 미진화 one-shot 모델이다. 아래 값은 모든 언어를 합친 Table 11 결과다.
| 방법 | Security | Functionality | F&S |
|---|---|---|---|
| 미진화 one-shot, Claude Code harness | 73.9 | 91.9 | 73.1 |
| Harmony Harness | 89.4 | 89.9 | 87.4 |
논문은 CWEval에서 기능 성공률이 다섯 언어 중 세 언어에서 낮아졌고, 전체 기능 점수가 2.0퍼센트포인트 하락했다고 보고한다(Yu et al., 2026, §5).
7. 논문이 밝힌 한계
저자들은 관측한 Pareto front가 좁고 두 목적이 함께 개선되는 경우가 많다고 쓴다. 실제로 기능과 보안이 충돌하는 조건에서의 평가를 향후 과제로 든다. 목적별 incumbent를 유지하는 구조가 행동 다양성을 자동으로 보장하지 않으며, 표준 코드 다양성 지표가 harness 동작을 충분히 반영하지 못할 수 있다고 인정한다(Yu et al., 2026, §§4.1, 6).
기능과 보안의 marginal 점수는 한 trajectory에서 두 성질이 동시에 나타나는지를 보장하지 않는다. 마찬가지로 tools·skills·logic과 general·environment로 나누는 방식도 구조적 편향이지, 의미상 완벽한 분류를 보장하지 않는다. Table 6의 generalize 비교는 6개 과제에 한정된다.
저자들은 raw error 출력을 proposer에게 제공한 변형이 Search split에서 보안 100%를 기록했지만 산출 코드가 안전하지 않았다고 설명한다. 정식 HH의 Search 보안 점수 93.3% 역시 단독으로 무게를 두지 않으며, held-out F&S 86.7%(IN)와 66.7%(OUT)를 근거로 든다. Search split에서 얻은 높은 보안 점수만으로 결과를 해석하지 말아야 한다고 명시한다. 다른 보안 코드 생성 벤치마크와 CWEval에서의 결과를 보고하지만, secure code generation 외의 agentic 영역으로 일반화되는지는 열린 문제로 남긴다. CWEval 기능 점수 하락도 함께 보고한다(Yu et al., 2026, §§5–6).
References
Yu, W., Miculicich, L., Dalvi Mishra, B., Chen, J., Li, S., Fredrikson, M., Pfister, T., & Le, L. T. (2026). Harmony Harness: Multi-objective self-evolution of agent harnesses [Preprint]. arXiv. https://arxiv.org/abs/2610.15150v1