EN

Recipes

Codex 및 OpenCode 에이전트를 위한 장기 지평 컴퓨터 사용 루프 하네스

README 링크에서 발견 · 2 days ago

Software & DevOps

장기 작업을 위해 기존 코딩 에이전트를 견고한 plan-act-verify 루프로 감싸세요.

What they did

기존 에이전트 백엔드(Codex와 OpenCode, Claude Code와 DeepSeek도 지원)를 가져다가 LongHorizon-Harness로 감쌌는데, 이는 새로운 모델이 아니라 루프 엔지니어링 레이어다. 에이전트에게 프롬프트 하나를 주고 끝나기를 바라는 대신, 원커맨드 설정으로 하네스를 설치하고 목표 하나를 넘겨주었다. 그러면 하네스가 그 사이클을 반복해서 실행한다. 목표와 검증된 상태를 복구하고, 다음의 경계가 정해진 단계를 고르고, 새로운 컨텍스트에서 그것을 실행하고, 컴퓨터 환경에서 실제 결과를 확인한 다음, 수용된 진행 상황을 체크포인트로 저장하거나 실패 증거를 다음 라운드에 넘긴다. 각 라운드가 새로운 컨텍스트로 시작하기 때문에 긴 실행이 컨텍스트 새로고침을 견뎌내고, 검증이 실제 데스크톱이나 터미널 상태를 대상으로 이루어지기 때문에 에이전트가 그저 성공했다고 주장할 수는 없다. 그들은 워크벤치 대화를 사용해 실행 중간에 응답을 읽고 후속 메시지를 보냈으며, 이를 통해 완료된 실행이 처음부터 다시 계획하는 대신 자체 라운드 원장 위에서 계속 이어지도록 했다.

How it went

이 루프는 단발성 에이전트를, 진행 상황을 체크포인트하고 실패에서 복구하며 멈추지 않는 다시간 작업자로 바꿔준다. 이 프로젝트는 WeaveBench, OSWorld 2.0, Terminal-Bench 2.1에서 측정된 개선을 보고하며, 승인, MCP 격리, 출력 인코딩을 수정하는 포인트 릴리스를 자주 배포한다. 연구 등급 하네스치고는 완성도가 높다: 버전 관리되는 릴리스, 프로젝트 웹사이트, arXiv 논문, 이중 언어 문서를 갖추고 있다.

Worth knowing

이것은 완성된 제품이 아니라 연구용 하네스입니다. Windows에는 문서화된 제약 사항이 있으며 trajectory 데이터셋은 아직 "coming soon"으로 표시되어 있습니다. 모델을 학습시키거나 대체하지 않으므로 품질은 여전히 기반 백엔드에 크게 의존합니다. 장시간 실행은 실제 토큰과 시간을 소모하며, 데스크톱 제어에는 작동하는 GUI 환경과 승인 처리가 필요합니다. 역할별로 reasoning effort와 타임아웃을 조정해야 할 것으로 예상하십시오.

Wiring

harness(Python >=3.10)를 설치하고 백엔드(Codex, OpenCode, Claude Code, DeepSeek Harness)를 지정합니다. Manager 역할은 목표를 분해하고 범위가 정해진 단계를 라우팅합니다. 워커 라운드는 데스크톱 또는 터미널을 대상으로 각 단계를 새로운 컨텍스트에서 실행하며, 검증기는 체크포인트가 수락되기 전에 실제 환경 상태를 확인합니다. 수락된 진행 상황은 라운드 원장에 기록되고, 실패는 다음 라운드를 위한 증거로 기록됩니다. 라운드 도중 전송된 후속 메시지는 다음 라운드에서 처리되므로 중지 후 재개해도 유실되지 않습니다. CLI 플래그에는 모든 역할에 적용되는 --reasoning-effort와 --manager-reasoning-effort 같은 역할별 재정의, 그리고 느린 마무리 응답을 위한 --final-response-timeout이 포함됩니다. MCP 격리는 백엔드별로 처리됩니다.

Try it yourself

I can't do this one, and I want to be straight about why rather than bury it in a partial answer.

**What I can't do:** I don't have a shell in your repo, so I can't clone, run the one-command setup, execute Codex, or produce real round ledgers and checkpoint files. Anything I "showed" you would be fabricated. I also can't verify a harness's behavior against a README I haven't read in your actual checkout.

**What I can do:** give you the exact sequence to run yourself, plus the config keys to look for. Treat the key names below as *candidates to confirm against the README* — I'm not going to assert them as fact for a tool I can't inspect.

## Setup sequence

```bash
# 1. Read the README first — confirm the one-command setup and the config schema
cat README.md

# 2. Run the documented one-command setup (name varies; check README)
#    e.g. npx longhorizon-harness init   /   npm i -g longhorizon-harness && lhh init

# 3. Confirm Codex is the selected backend and that its CLI/auth is present
codex --version
```

## Config to target this project

```yaml
backend: codex
goal: >
  Audit the test suite. Fix failing tests one at a time.
  Verify each fix by actually running the tests before moving on.
loop:
  mode: plan-act-verify-checkpoint
  stop_when: tests_green
```

## Where to look for the three keys you asked about

Search the config schema and README for these — the naming will be one of these families:

| Concern | Likely keys to grep for |
|---|---|
| Reasoning effort | `reasoning_effort`, `reasoning.effort`, `model_reasoning_effort` |
| Final-response timeout | `final_response_timeout`, `response_timeout`, `timeouts.final_response` |
| Approval behavior | `approval_policy`, `approval_mode`, `require_approval`, `auto_approve` |

```bash
grep -rniE 'reasoning|timeout|approval' README.md config* .longhorizon* 2>/dev/null
```

## Getting the ledger and checkpoints

After a run, look for a run directory (commonly `.longhorizon/runs/<id>/` or `runs/<timestamp>/`) containing something like `ledger.jsonl` / `rounds/` and `checkpoint-*.json`. Paste the README's config section and a directory listing back to me and I'll help you interpret the ledger, tune the three keys, and debug any round that stalls.

Source

English

Tools in this stack