OpenHarness — 에이전트에게 손, 눈, 기억, 권한을 붙이는 오픈소스 Agent Harness

한 줄 요약: OpenHarness는 LLM을 “대화 모델”에서 “실행 가능한 에이전트”로 바꾸기 위한 Python 기반 경량 하네스다. 도구 호출, 스킬, 메모리, 권한 제어, 멀티 에이전트 조율, 개인 에이전트 ohmo를 하나의 실행 환경으로 묶는다.

그림: OpenHarness 프로젝트의 공식 로고. 이 리포트에서는 OpenHarness를 단순 CLI가 아니라 에이전트 실행 계층, 즉 Agent Harness로 해석한다.

분석 기준

이 글은 2026-05-29 기준으로 GitHub 저장소의 README.md, docs/SHOWCASE.md, CHANGELOG.md, pyproject.toml, src/openharness/, ohmo/, frontend/terminal/, assets/를 중심으로 분석했다.

공개 Wiki는 별도 문서 콘텐츠가 확인되지 않았고, Discussions는 분석 시점에 본문 자료를 안정적으로 확인할 수 없었다.

따라서 본문은 README, 소스 코드 구조, 패키지 설정, 공식 이미지 자산에 근거한다.

Quick Links

구분	링크
GitHub Repository	https://github.com/HKUDS/OpenHarness
README	https://github.com/HKUDS/OpenHarness/blob/main/README.md
Showcase 문서	https://github.com/HKUDS/OpenHarness/blob/main/docs/SHOWCASE.md
Changelog	https://github.com/HKUDS/OpenHarness/blob/main/CHANGELOG.md
Contributing	https://github.com/HKUDS/OpenHarness/blob/main/CONTRIBUTING.md
Assets / Demo 이미지	https://github.com/HKUDS/OpenHarness/tree/main/assets
License	https://github.com/HKUDS/OpenHarness/blob/main/LICENSE
논문	저장소에서 공식 논문 링크는 확인되지 않음

Image & Asset Map

저장 파일	본문 배치	설명하는 기능
`figures/아키텍처_흐름.png`	Architecture	모델 사고, 하네스 실행, 작업 완료까지의 큰 실행 흐름
`figures/하네스_구성_요소.png`	Architecture	Harness를 구성하는 Tools, Knowledge, Observation, Action, Permissions의 역할
`figures/에이전트_루프.png`	Key Features	모델이 도구 호출을 반복하며 결과를 받아 다음 행동을 결정하는 Agent Loop
`figures/툴킷.png`	Key Features	파일, 셸, 웹, MCP, 작업 관리 등 도구 실행 계층
`figures/컨텍스트_메모리.png`	Key Features	프로젝트 지식, 세션 컨텍스트, 메모리 유지 구조
`figures/거버넌스_권한.png`	Key Features	권한 모드, 경로 규칙, 승인 대화상자, 훅 기반 통제
`figures/스웜_협업.png`	Key Features	서브에이전트, 백그라운드 태스크, 팀 단위 작업 위임
`figures/오모_개인_에이전트.png`	Key Features	Slack, Telegram, Discord, Feishu 등 채널 기반 개인 에이전트 ohmo
`figures/터미널_랜딩_화면.png`	Usage & Setup	OpenHarness 터미널 진입 화면
`figures/터미널_입력_데모.gif`	Usage & Setup	CLI 입력 데모 GIF

Key Features

1. Agent Loop: 모델이 생각하고, 하네스가 실행하고, 결과가 다시 모델로 들어간다

OpenHarness의 핵심은 “한 번 답변하고 끝나는 챗봇”이 아니라, 모델이 작업을 나누고 도구를 호출하고 결과를 관찰한 뒤 다음 행동을 결정하는 반복 루프다.

소스 구조상 이 루프는 src/openharness/engine/query_engine.py, src/openharness/engine/query.py, src/openharness/engine/stream_events.py 주변에 집중되어 있다.

실행 흐름은 다음처럼 이해할 수 있다.

사용자가 CLI, TUI, 또는 ohmo 채널을 통해 요청을 입력한다.
QueryEngine이 현재 세션, 시스템 프롬프트, 프로젝트 컨텍스트, 사용 가능한 도구 목록을 구성한다.
모델이 일반 텍스트 또는 tool_use 형태의 호출을 스트리밍한다.
하네스가 도구 호출을 검증하고 권한을 확인한 뒤 실행한다.
도구 결과가 다시 모델 컨텍스트에 들어가고, 모델은 다음 행동을 결정한다.
더 이상 도구 호출이 필요 없으면 최종 응답을 반환한다.

그림: OpenHarness의 Agent Loop. 모델은 작업 의도를 생성하지만, 실제 파일 읽기, 셸 실행, 웹 검색, MCP 호출, 태스크 위임은 하네스가 담당한다.

이 설계의 장점은 모델 제공자가 바뀌어도 실행 구조가 유지된다는 점이다. Anthropic 호환 API, OpenAI 호환 API, Claude/Codex 구독, Copilot 계열을 같은 “도구 사용 루프” 안으로 넣을 수 있다.

2. Harness Toolkit: 43개 이상의 도구를 모델 호출 가능한 인터페이스로 노출

OpenHarness의 도구 계층은 src/openharness/tools/에 모여 있다.

저장소에는 bash, read, write, edit, grep, glob, web_fetch, web_search, mcp, task, agent, team, notebook, todo, plan, worktree 등 다양한 도구 구현이 포함되어 있다.

도구 설계는 단순한 함수 호출 묶음이 아니다. BaseTool은 다음 요소를 요구한다.

도구 이름과 설명
Pydantic 기반 입력 스키마
비동기 실행 함수
읽기 전용 여부
모델 API에 전달할 JSON Schema 변환

즉, 도구는 “모델이 호출할 수 있는 안전한 명령 객체”에 가깝다.

이 때문에 새로운 도메인 도구를 추가할 때도 입력 검증, 권한 검사, 이벤트 스트리밍, 실행 결과 반환을 일관되게 다룰 수 있다.

그림: OpenHarness Toolkit. 파일 시스템, 셸, 검색, 웹, MCP, 작업 관리 도구가 하나의 실행 레지스트리로 묶인다.

개발자 입장에서 중요한 점은 이 도구 계층이 “에이전트의 손” 역할을 한다는 것이다.

모델은 계획과 판단을 담당하고, 하네스는 실제 조작 가능한 외부 세계를 제한된 인터페이스로 노출한다.

3. Context & Memory: 프로젝트 지식과 세션 기억을 분리해서 관리

OpenHarness는 단발성 프롬프트보다 장기 작업에 초점을 둔다.

README 기준으로 CLAUDE.md 탐색, 자동 컨텍스트 압축, MEMORY.md, 세션 resume 같은 기능을 제공한다.

소스 구조에서도 memory, state, prompts, personalization 디렉터리가 별도로 존재한다.

이 구조는 다음과 같이 나뉜다.

Project Context: 저장소별 규칙, 개발 지침, 도메인 지식
Session Context: 현재 대화와 도구 실행 결과
Durable Memory: 반복적으로 사용할 사용자 선호나 장기 작업 상태
Auto Compaction: 컨텍스트가 길어질 때 요약 또는 압축을 통해 루프를 계속 유지

그림: Context & Memory. 프로젝트 지식, 세션 상태, 장기 메모리가 모델 호출 전에 조립되어 에이전트의 작업 맥락을 만든다.

이 기능은 특히 코드베이스 리팩터링, 장기 실험 자동화, 문서화 작업에서 중요하다.

에이전트가 매번 처음부터 저장소를 다시 읽지 않고, 이전 작업의 결론과 프로젝트 규칙을 누적할 수 있기 때문이다.

4. Governance & Permissions: 에이전트 실행을 허용 가능한 범위 안에 묶는다

Agent Harness에서 가장 민감한 지점은 “모델이 무엇을 실행할 수 있는가”이다.

OpenHarness는 권한 모드, 경로 단위 규칙, 금지 명령, 승인 대화상자, 훅을 통해 실행 범위를 제어한다.

대표적인 권한 모드는 다음처럼 해석할 수 있다.

모드	의미	적합한 상황
Default	쓰기/실행 전 사용자 확인	일반 개발 작업
Auto	대부분의 실행을 자동 승인	격리된 샌드박스 환경
Plan Mode	쓰기 작업 차단, 계획 중심	대규모 리팩터링 검토

경로 단위 규칙도 중요하다.

예를 들어 /etc/* 같은 시스템 영역, 운영 DB 마이그레이션 파일, 임상 데이터 경로, 비밀키 파일은 하네스 차원에서 차단해야 한다.

그림: Governance & Permissions. 모델 요청이 곧바로 실행되지 않고, 권한 정책과 훅을 거쳐 허용 여부가 결정된다.

이 레이어는 의료 AI나 자율 에이전트 개발에서 특히 중요하다.

“모델이 좋은 의도를 가졌는가”보다 “실행 가능한 행동이 안전 정책을 통과했는가”가 더 검증 가능한 기준이기 때문이다.

5. Swarm Coordination: 한 에이전트가 모든 일을 하지 않고 작업을 위임한다

OpenHarness는 단일 에이전트 루프뿐 아니라 서브에이전트, 태스크, 팀 기반 작업 흐름도 지원한다. src/openharness/swarm/, src/openharness/tasks/, src/openharness/coordinator/와 도구 계층의 agent, task, team 관련 구현이 이 방향성을 보여준다.

멀티 에이전트 조율의 핵심은 역할 분리다.

메인 에이전트: 목표 정의, 작업 분해, 결과 통합
서브에이전트: 특정 파일 분석, 테스트 실패 원인 조사, 문서 초안 작성
백그라운드 태스크: 오래 걸리는 검색, 테스트, 리포트 생성
코디네이터: 작업 상태 추적, 위임 결과 취합

그림: Swarm Coordination. OpenHarness는 태스크 위임, 서브에이전트 실행, 백그라운드 작업 관리를 Agent Harness 내부 기능으로 다룬다.

다만 이 영역은 항상 과도한 자율성의 위험을 동반한다.

실제 운영 환경에서는 태스크별 권한 범위, 결과 검증, 실행 로그, 승인 정책을 함께 설계해야 한다.

6. ohmo: 채팅 앱 위에서 장기 작업을 수행하는 개인 에이전트

OpenHarness 위에는 개인 에이전트 ohmo가 함께 제공된다.

README는 ohmo를 “또 다른 챗봇”이 아니라, Feishu, Slack, Telegram, Discord에서 대화하며 브랜치를 만들고, 코드를 작성하고, 테스트를 실행하고, PR을 여는 개인 AI 에이전트로 설명한다.

소스 구조상 ohmo/에는 다음 구성요소가 있다.

gateway/: 외부 채팅 채널과 연결되는 진입점
runtime.py: ohmo 실행 환경
workspace.py: ~/.ohmo 기반 작업 공간 관리
session_storage.py: 세션 저장
memory.py: 개인 에이전트 메모리
group_registry.py: 그룹/채널 단위 관리

그림: ohmo. OpenHarness의 하네스 기능을 개인 비서형 에이전트로 확장한 구성으로, 채팅 앱을 작업 인터페이스로 사용한다.

흥미로운 부분은 ohmo가 별도 API 키를 강제하기보다 기존 Claude Code 또는 Codex 구독을 활용하는 방향을 제시한다는 점이다.

즉, OpenHarness는 “모델 API 제품”이라기보다 “에이전트 실행 런타임”에 가깝다.

7. Provider Compatibility & Headless Automation: CLI, JSON, stream-json, dry-run

OpenHarness는 대화형 터미널만을 목표로 하지 않는다.

README는 oh -p, --output-format json, --output-format stream-json, --dry-run 같은 비대화형 사용 방식을 제공한다.

이 기능은 CI/CD, 내부 자동화, 평가 스크립트에 중요하다. 예를 들어 다음과 같은 작업이 가능하다.

저장소 분석 결과를 JSON으로 받아 파이프라인에 넘기기
실시간 이벤트를 stream-json으로 받아 대시보드에 표시하기
--dry-run으로 설정, 인증, 도구, MCP, 스킬 로딩 문제를 사전에 점검하기
서로 다른 모델 제공자를 같은 작업에 적용해 비교하기

그림: OpenHarness 터미널 랜딩 화면. CLI는 대화형 에이전트 실행과 headless 자동화를 모두 지원한다.

그림: CLI 입력 데모. 블로그 플랫폼이 GIF를 지원하지 않는 경우 figures/터미널_입력_데모.png를 대체 이미지로 사용할 수 있다.

Tech Stack

런타임 및 패키지

영역	기술
패키지명	`openharness-ai`
패키지 버전	`0.1.9` (`pyproject.toml` 기준)
Python	`>=3.10`
빌드 시스템	`hatchling`
라이선스	MIT
CLI 엔트리포인트	`openharness`, `oh`, `openh`, `ohmo`
코드 스타일	Ruff target `py311`, line length 100
타입 검사	MyPy `python_version=3.11`, strict mode

Python 주요 의존성

목적	주요 패키지
모델 API	`anthropic>=0.40.0`, `openai>=1.0.0`
CLI/TUI	`rich>=13.0.0`, `prompt-toolkit>=3.0.0`, `textual>=0.80.0`, `typer>=0.12.0`, `questionary>=2.0.1`
스키마/설정	`pydantic>=2.0.0`, `pyyaml>=6.0`
네트워크	`httpx>=0.27.0`, `websockets>=12.0`
MCP	`mcp>=1.0.0`
파일/작업 감시	`watchfiles>=0.20.0`, `croniter>=2.0.0`, `pyperclip>=1.9.0`
채팅 채널	`slack-sdk>=3.0.0`, `python-telegram-bot>=21.0.0`, `discord.py>=2.0.0`, `lark-oapi>=1.5.0`
테스트/개발	`pytest>=8.0.0`, `pytest-asyncio>=0.23.0`, `pytest-cov>=5.0.0`, `pexpect>=4.9.0`, `ruff>=0.5.0`, `mypy>=1.10.0`

Terminal Frontend

frontend/terminal/은 React와 Ink를 사용한 터미널 UI 패키지다.

영역	기술
UI	`react^18.3.1`, `ink^5.1.0`
입력	`ink-text-input^6.0.0`
Markdown 처리	`marked^18.0.0`
TypeScript 실행	`tsx^4.19.2`
TypeScript	`typescript^5.7.3`
Node 타입	`@types/node^22.13.10`

소스 코드 구조 요약

OpenHarness/
├─ src/openharness/
│  ├─ engine/          # QueryEngine, streaming loop, cost tracking
│  ├─ tools/           # bash/file/search/web/MCP/task/team 등 도구 구현
│  ├─ permissions/     # 권한 모드, 경로 규칙, 실행 승인
│  ├─ hooks/           # 실행 전후 훅
│  ├─ skills/          # 스킬 로더, 레지스트리, bundled skills
│  ├─ plugins/         # 플러그인 로더, 스키마, 설치기
│  ├─ memory/          # 세션/장기 메모리
│  ├─ mcp/             # MCP 서버 연동
│  ├─ swarm/           # 멀티 에이전트/스웜 조율
│  ├─ tasks/           # 백그라운드 태스크
│  ├─ ui/              # Python-side UI 구성
│  └─ cli.py           # CLI 진입점
├─ ohmo/               # 개인 에이전트 런타임과 채팅 게이트웨이
├─ frontend/terminal/  # React/Ink 터미널 프론트엔드
├─ docs/               # Showcase 등 문서
├─ assets/             # 공식 이미지/GIF 자산
└─ pyproject.toml      # 패키지, 의존성, 엔트리포인트 설정

Architecture

그림: OpenHarness의 큰 아키텍처 흐름. 모델은 사고와 의사결정을 맡고, 하네스는 도구 실행, 권한 확인, 결과 반환을 담당한다.

OpenHarness는 “모델 = 에이전트, 코드 = 하네스”라는 관점으로 설계되어 있다. 모델 자체가 모든 능력을 가진 것이 아니라, 하네스가 모델에게 다음 능력을 붙여준다.

그림: Harness를 이루는 구성요소. Tools, Knowledge, Observation, Action, Permissions가 결합되어 실행 가능한 Agent Harness가 된다.

1. 입력 계층

사용자 입력은 다음 경로로 들어올 수 있다.

oh CLI
Windows용 openh CLI
React/Ink 기반 터미널 UI
oh -p headless 실행
ohmo의 Feishu, Slack, Telegram, Discord 게이트웨이

입력은 설정 프로필, 인증 정보, 모델 제공자, 시스템 프롬프트, 프로젝트 컨텍스트와 함께 QueryEngine으로 전달된다.

2. 컨텍스트 조립 계층

QueryEngine은 모델 호출 전에 다음 요소를 조립한다.

대화 메시지
시스템 프롬프트
프로젝트 지침 파일
세션 메모리
장기 메모리
활성화된 스킬
사용 가능한 도구 스키마
권한/훅/플러그인 설정

이 조립 단계가 중요하다.

Agent Harness의 품질은 모델 성능뿐 아니라 “모델에게 어떤 상황, 어떤 도구, 어떤 금지사항을 제공하는가”에 의해 결정된다.

3. 모델 호출 계층

OpenHarness는 Anthropic 호환 API와 OpenAI 호환 API를 모두 고려한다.

또한 Claude 구독, Codex 구독, Copilot, Moonshot/Kimi, GLM, MiniMax, NVIDIA NIM 같은 제공자 흐름을 README에서 언급한다.

모델 호출은 스트리밍 이벤트로 처리되며, 텍스트 응답과 도구 호출이 섞여 나올 수 있다.

도구 호출이 발생하면 하네스는 이를 즉시 실행 루프로 넘긴다.

4. 도구 실행 계층

도구 실행은 다음 흐름을 따른다.

model tool_use
  → ToolRegistry에서 도구 조회
  → Pydantic 입력 스키마 검증
  → PermissionChecker로 실행 가능 여부 확인
  → pre-tool hooks 실행
  → 실제 도구 실행
  → post-tool hooks / 결과 이벤트 처리
  → tool_result를 모델 컨텍스트에 추가

여러 도구 호출은 병렬 실행될 수 있으며, 하나의 도구 실패가 다른 도구 실행 전체를 중단하지 않도록 설계되어 있다.

이 구조는 파일 검색, 코드 수정, 테스트 실행, 웹 검색처럼 독립적인 작업이 섞이는 에이전트 워크플로에서 유리하다.

5. 권한과 거버넌스 계층

권한 계층은 OpenHarness 아키텍처에서 별도 모듈로 분리되어 있다.

이는 단순한 UI 확인창이 아니라, 하네스의 보안 경계다.

실제 운영에서는 다음 정책을 함께 설계하는 것이 바람직하다.

읽기 전용 도구와 쓰기 도구 분리
경로 단위 allow/deny 규칙
금지 명령 패턴
민감 데이터 경로 차단
프로젝트별 권한 프로필
승인 이벤트 로그
샌드박스 실행 또는 컨테이너 실행

6. 메모리와 압축 계층

장기 세션에서는 컨텍스트 길이가 빠르게 커진다.

OpenHarness는 세션 메모리와 자동 압축을 통해 루프가 계속 진행될 수 있게 한다.

특히 코드베이스 분석, 긴 리팩터링, 반복 테스트처럼 컨텍스트가 누적되는 작업에서 중요하다.

7. ohmo 확장 계층

ohmo는 OpenHarness의 런타임을 개인 에이전트 사용성으로 확장한다.

CLI를 직접 열지 않아도 채팅 앱에서 작업을 지시하고, ohmo가 워크스페이스와 브랜치, 세션 상태를 관리한다.

즉, ohmo는 OpenHarness의 “채팅 기반 작업 운영 계층”에 가깝다.

Usage & Setup

1. 설치

Linux / macOS / WSL

# one-click install
curl -fsSL https://raw.githubusercontent.com/HKUDS/OpenHarness/main/scripts/install.sh | bash

# or via pip
pip install openharness-ai

Windows PowerShell

# one-click install
iex (Invoke-WebRequest -Uri 'https://raw.githubusercontent.com/HKUDS/OpenHarness/main/scripts/install.ps1')

# or via pip
pip install openharness-ai

Windows PowerShell에서는 oh가 기본 Out-Host alias와 충돌할 수 있으므로 README는 openh 사용을 권장한다.

2. 초기 설정

oh setup
# Windows PowerShell:
openh setup

이 단계에서 모델 제공자, 인증 방식, 프로필을 선택한다.

3. 대화형 실행

oh
# Windows PowerShell:
openh

그림: OpenHarness 대화형 터미널 화면. 사용자는 CLI에서 모델과 대화하고, 모델은 필요할 때 도구를 호출한다.

4. 비대화형 실행

# 단일 프롬프트를 stdout으로 출력
oh -p "Explain this codebase"

# JSON 출력
oh -p "List all functions in main.py" --output-format json

# 실시간 이벤트 스트리밍
oh -p "Fix the bug" --output-format stream-json

이 모드는 CI/CD, 배치 자동화, 내부 평가 스크립트에 적합하다.

5. dry-run으로 실행 전 점검

# 모델과 도구를 실제 실행하지 않고 설정 문제 확인
oh --dry-run -p "Check this repository"

dry-run은 인증, 프롬프트, 스킬, 명령, 도구, MCP 연결 문제를 사전에 파악하는 데 유용하다.

6. ohmo 개인 에이전트 설정

ohmo init             # ~/.ohmo workspace 초기화
ohmo config           # 채널과 provider 설정
ohmo gateway start    # 채팅 앱 게이트웨이 시작

지원 채널은 README 기준으로 Feishu, Slack, Telegram, Discord가 언급된다.

7. 개발자 환경

git clone https://github.com/HKUDS/OpenHarness.git
cd OpenHarness
uv sync --extra dev
uv run pytest -q

README는 테스트 예시로 전체 unit/integration, CLI flag E2E, Harness feature E2E, React TUI E2E, real skills/plugins E2E를 제시한다.

Personal Insights

1. 의료 AI 관점: 모델 성능보다 “행동 통제 계층”이 중요하다

의료 AI에서 OpenHarness가 흥미로운 이유는 진단 모델 자체보다 하네스의 구조 때문이다.

실제 임상 환경에서 에이전트는 다음 작업을 하게 될 가능성이 있다.

임상 문서 요약
EMR 질의
검사 결과 해석 보조
임상 지침 검색
연구 프로토콜 문서화
환자군 필터링
내부 지식베이스 검색

이때 핵심은 모델이 똑똑한가보다, 모델이 어떤 데이터에 접근하고 어떤 행동을 할 수 있는가다.

OpenHarness의 권한 모드, 경로 규칙, 훅, 도구 스키마 구조는 의료 AI 시스템에서 필요한 실행 경계를 설계하는 출발점이 될 수 있다.

다만 그대로 의료 환경에 투입할 수 있다는 뜻은 아니다.

실제 적용에는 PHI/PII 처리, 접근 통제, 감사 로그, 사용자 역할 기반 권한, Human-in-the-loop 승인, 임상 검증, 규제 준수, 모델 출력 책임 경계가 별도로 필요하다.

기술적 제안: 의료용 OpenHarness를 만든다면 모든 외부 도구를 직접 노출하지 말고, FHIR/OMOP/내부 지식베이스용 read-only MCP 서버를 만들고, 쓰기 작업은 승인 큐를 거치게 하는 구성이 안전하다.

2. Bioinformatics 관점: 재현 가능한 파이프라인 에이전트의 기반이 될 수 있다

Bioinformatics 작업은 LLM 에이전트와 잘 맞는 부분이 많다.

예를 들어 다음 작업은 자연어 지시와 도구 실행이 결합되어야 한다.

FASTQ QC 리포트 해석
alignment 파이프라인 구성
variant calling 로그 분석
Nextflow/Snakemake 워크플로 수정
Jupyter notebook 결과 요약
논문 기반 분석 파라미터 업데이트
반복적인 파일 검색과 결과 테이블 정리

OpenHarness는 bash, 파일 읽기/쓰기, 검색, 노트북 도구, 태스크 도구, 메모리, 스킬을 갖추고 있어 이런 작업을 에이전트 루프로 묶을 수 있다.

특히 프로젝트별 .openharness/skills, .agents/skills, .claude/skills 같은 스킬 디렉터리를 활용하면 연구실 표준 운영 절차(SOP), 분석 규칙, 데이터 경로 규칙을 모델 컨텍스트에 넣을 수 있다.

하지만 Bioinformatics에서는 재현성이 핵심이다.

에이전트가 “그럴듯한 명령어”를 실행하는 것만으로는 부족하다.

필수 보강 요소는 다음과 같다.

conda/uv/Docker/Singularity 환경 고정
레퍼런스 genome 버전 명시
입력 데이터 checksum 관리
실행 로그와 파라미터 기록
결과 파일 provenance 추적
dry-run과 plan mode 기반 사전 검토
민감 데이터 경로에 대한 path rule 적용

기술적 제안: OpenHarness를 Bioinformatics에 적용한다면 nextflow_runner, snakemake_runner, multiqc_reader, vcf_summary, pubmed_search, dataset_manifest_checker 같은 도메인 도구를 추가하고, 모든 destructive command를 plan mode 또는 승인 기반으로 묶는 것이 좋다.

3. Autonomous Agent 관점: 범용 자율성보다 “검사 가능한 자율성”을 지향한다

OpenHarness의 강점은 자율성을 크게 외치는 것이 아니라, 자율성을 구성요소로 나눠 보여준다는 점이다.

모델 호출
도구 스키마
도구 실행
권한 검사
훅
메모리
스킬
플러그인
MCP
태스크 위임
멀티 에이전트 조율

이 분해는 Autonomous Agent 개발에서 매우 중요하다.

문제가 발생했을 때 “모델이 이상했다”로 끝내지 않고, 어떤 도구 입력이 만들어졌는지, 권한 검사가 왜 통과했는지, 어떤 훅이 실행됐는지, 어떤 메모리가 다음 호출에 영향을 줬는지 분석할 수 있기 때문이다.

특히 stream-json 출력과 dry-run은 에이전트 평가 시스템과 잘 맞는다.

모델의 최종 답변만 보는 대신, 중간 이벤트와 도구 호출을 평가 대상으로 삼을 수 있다.

기술적 제안: OpenHarness를 에이전트 연구 플랫폼으로 쓴다면 다음 벤치마크를 직접 붙여볼 만하다.

도구 호출 정확도
권한 정책 위반률
실패한 도구 호출 복구율
장기 세션 메모리 유지율
멀티 에이전트 위임 품질
비용 대비 작업 성공률
dry-run 경고와 실제 실패의 상관관계

장점과 한계

장점

구조가 관찰 가능하다. 모델 호출, 도구 실행, 권한 검사, 메모리, 훅이 분리되어 있어 분석과 확장이 쉽다.
도구 계층이 풍부하다. 파일, 셸, 검색, 웹, MCP, 태스크, 팀 도구가 기본 포함되어 있다.
Claude-style 생태계와 호환성을 의식한다. skills, plugins, CLAUDE.md 계열 관례를 활용할 수 있다.
headless 자동화에 적합하다. JSON, stream-json, dry-run이 있어 CI/CD나 평가 파이프라인과 연결하기 쉽다.
ohmo가 실제 사용 인터페이스를 제공한다. 채팅 앱에서 장기 작업을 지시하는 개인 에이전트 흐름이 포함되어 있다.

한계 및 주의점

공개 Wiki/Discussion 기반의 운영 지식은 제한적으로 확인됐다.
현재 분석은 README, docs, CHANGELOG, 소스 구조 중심이다.
의료·바이오 실사용에는 별도 안전 계층이 필요하다.
OpenHarness 자체가 규제 준수나 임상 검증을 제공하는 것은 아니다.
멀티 에이전트 기능은 강력하지만 정책 설계가 필수다.
서브에이전트와 백그라운드 태스크는 권한 범위가 명확해야 한다.
Provider별 동작 차이를 테스트해야 한다.
Anthropic/OpenAI/Copilot/Codex 호환 흐름은 유용하지만, tool call 포맷과 reasoning 옵션 차이가 작업 품질에 영향을 줄 수 있다.
자율 실행은 샌드박스에서 시작해야 한다.
특히 bash, 파일 쓰기, PR 생성, 외부 채널 게이트웨이는 운영 전 별도 격리가 필요하다.

결론

OpenHarness는 단순한 AI 코딩 CLI라기보다, LLM 기반 에이전트를 실제 도구와 연결하기 위한 Agent Harness reference implementation에 가깝다.

README에서 강조하는 도구 사용, 스킬, 메모리, 권한, 스웜, ohmo는 모두 “모델이 직접 세상을 조작하는 것이 아니라, 하네스가 검증 가능한 경로로 실행을 중개한다”는 하나의 설계 철학으로 묶인다.

의료 AI와 Bioinformatics에서는 이 구조가 특히 의미 있다.

모델의 추론 능력보다 더 중요한 것은 데이터 접근, 실행 권한, 기록, 검증, 재현성을 통제하는 계층이기 때문이다.

OpenHarness는 그 계층을 연구하고 확장하기 좋은 출발점이다.

자율 에이전트 개발 관점에서도 OpenHarness의 가치는 분명하다.

에이전트를 마법처럼 보이게 하는 대신, 도구, 권한, 메모리, 이벤트, 태스크로 분해해서 관찰하고 개선할 수 있게 만든다.

앞으로의 과제는 이 구조를 더 강한 샌드박스, 평가 벤치마크, 도메인별 안전 정책, 검증 가능한 멀티 에이전트 프로토콜로 확장하는 것이다.

'AI 생성 글 정리 > tech_github' 카테고리의 다른 글

Twenty — AI 시대를 겨냥한 오픈소스 CRM 플랫폼 (0)	2026.05.29
Crawl4AI — LLM 친화형 웹 크롤러·스크래퍼 분석 리포트 (0)	2026.05.29
MarkItDown — LLM을 위한 범용 파일→Markdown 변환 엔진 (0)	2026.05.27
Understand Anything — 코드베이스를 “배우는” 인터랙티브 지식 그래프로 바꾸는 멀티 에이전트 플러그인 (0)	2026.05.27
llmfit — 로컬 하드웨어에서 “실제로 잘 도는” LLM을 찾아주는 Rust 기반 모델 피팅 도구 (0)	2026.05.27