대부분의 에이전트 팀은 하네스를 직접 구축하지 않는다. 그냥 하나를 채택한다. LangChain, LangGraph, OpenAI Agents SDK, Anthropic SDK, CrewAI, AutoGen, 루프, 도구, 메모리, 오케스트레이션까지 모두 한 번의 결정으로 선반에서 집어든다. 하네스는 그냥 임포트하는 프레임워크일 뿐이다. 내부에 맞지 않는 부분이 있으면 포크하거나, 싸우거나, 우회해서 해결한다.
나는 그 형태가 잘못되었다고 생각한다. 그리고 그것이 모든 장기 운영 에이전트 팀이 결국 하네스를 처음부터 다시 작성하게 되는 이유다. 하네스는 하나의 덩어리가 아니다. 주변 생태계가 이들을 구성할 방법을 제공하지 않기 때문에, 열 가지 혹은 열두 가지의 서로 다른 것들이 묶여 있는 것에 불과하다. Pi agent 패키지들은 올바른 방향으로 가고 있지만, 여전히 "또 다른 서비스를 추가하고 다른 모든 서비스와 통합하라"는 패러다임 안에 머물러 있다. iii 엔진은 모든 워커를 동일하게 취급하고 통합 로직을 완전히 제거한다. 공급자 라우터, 자격 증명 저장소, 정책 엔진, 승인 게이트, 모델 카탈로그, 세션 저장소, 예산 추적기, 호출 후 훅 팬아웃, 내구성 있는 턴 루프는 모두 독립적인 관심사다. 이 모든 것은 큐, HTTP/API 서버, 스트리밍, 심지어 브라우저 워커와도 상호 운용이 가능하다. 이것들을 하나의 블록으로 제공하는 프레임워크는 당신이 굳이 하지 않아도 될 트레이드오프를 강요하는 것이다.
iii의 기본 베팅은 이것들이 하나의 블록이 되어서는 안 된다는 것이다. 공유 엔진 위에서 각각 교체 가능하고, 독립적으로 버전 관리되며, 모든 다른 워커도 사용하는 단일 프리미티브(트리거, iii.trigger())로 연결된 워커 집합이 있어야 한다. 하네스는 설치 가능한 워커들의 스택이 되고, "직접 구축한다"는 것은 "프레임워크를 포크한다"는 의미가 아니라 "몇 개의 워커를 교체한다"는 의미가 된다.
이 글은 그것이 실제로 어떻게 보이는지 단계별로 설명한다. 오늘날 iii 에이전트 턴을 구동하는 완전한 스택, 각 계층이 왜 독립적인 워커인지, 그리고 각각을 어떻게 교체하는지에 대한 내용이다.
에이전트 하네스가 수행해야 하는 15가지 작업
프로덕션 에이전트 하네스를 그 책임으로 환원하면 대략 다음과 같은 목록이 나온다:
- 클라이언트로부터 턴 요청을 받아 영구 저장한다.
- 호출되는 모델 공급자에 대한 자격 증명을 확인한다.
- 선택된 모델이 실제로 무엇을 할 수 있는지 확인한다(비전, 도구, 스트리밍, 컨텍스트 윈도우).
- 턴별 상태 머신을 구동한다: 프로비저닝, 스트리밍 어시스턴트, 도구 실행, 조종, 종료.
- 각 함수의 요청 형식, 오류 코드, 사용법을 설명하는 스킬 본문을 로드하고 제공한다.
- 시스템 프롬프트, 모드 단락, 아이덴티티 전문, 작업 디렉토리, 기본 스킬 부록을 조합한다.
- 모델이 토큰을 생성할 때마다 클라이언트로 스트리밍한다.
- 모든 도구 호출(그냥 함수다)을 실행 전에 정책에 대해 검사한다.
- 사람의 결정이 필요한 도구 호출을 일시 중단하고, 응답을 올바른 턴으로 라우팅한다.
- 작업 공간 또는 에이전트별 예산에 대한 LLM 사용량을 추적한다.
- 도구 호출 전후에 훅을 실행한다(로깅, 수정, 사용자 정의 부작용).
- 세션을 분기 트리로 영구 저장하여 포크와 재개가 작동하도록 한다.
- 컨텍스트 윈도우가 가득 차면 세션 기록을 압축한다.
- UI가 구독하는 이벤트 스트림을 내보낸다.
- 모든 에이전트 회사 구축에서 누락된 부분. 모든 단계에 걸쳐 하나의 OpenTelemetry 추적을 전달하여 디버깅할 수 있게 한다.
모든 진지한 에이전트 하네스는 이 중 대부분을 구현한다. 비싼 것들은 모두 구현한다. 싼 것들은 구석을 잘라내고 나중에 프로덕션에 도달했을 때 다시 구축한다. 프레임워크는 이것들을 모놀리스로 묶어 각각 하나의 버전만 제공한다. 마지막 부분이 당신에게 비용을 발생시킨다. 1년 후에 당신이 원하는 정책 엔진이 프레임워크가 제공하는 정책 엔진이 아니라는 것을 알게 되고, 그것을 교체하는 것은 하네스를 교체하는 것을 의미하기 때문이다.
iii 하네스는 위의 13가지 작업 각각을 workers.iii.dev 레지스트리의 별도 워커로 제공한다. 각 워커는 동일한 WebSocket 프로토콜을 사용한다. 각 워커는 동일한 엔진 버스에서 함수와 트리거를 등록한다. 각 워커는 SDK가 있는 모든 언어로 iii worker add 가능하고, 교체 가능하며, 작성 가능하다.
워커별 스택
다음은 iii-hq/workers 모노레포의 실제 프로덕션 스택이며, 각 워커의 작업은 한 줄로 설명된다. 전체 번들은 github.com/iii-hq/workers/harness에서 제공된다:
11개의 워커. 하나의 엔진. 각 워커는 게시된 버전에 있다. 각 워커는 독립 실행형 프로세스(개발 시 pnpm dev:<워커>, 릴리스 바이너리로 iii worker add <특정-워커>)로 또는 함께 실행되는 복합 진입점의 일부로 실행 가능하다.
이것이 중요한 이유: 해당 테이블의 모든 상자는 누군가가 당신에게 다른 워커를 제공할 수 있는 지점이며, 나머지는 그대로 유지할 수 있다. 정적 모델 카탈로그가 마음에 들지 않는가? models::list를 등록하고 라이브 API에서 읽어오는 워커를 연결하라. 파일 기반 자격 증명이 마음에 들지 않는가? auth::get_token을 등록하고 비밀 관리자에서 읽어오는 워커를 연결하라. 다르게 분기되는 워크플로우를 위해 다른 턴 FSM을 원하는가? turn-orchestrator를 교체하라. 모든 종속 호출은 run::start를 호출하고 동일한 버스를 통해 turn_state를 읽으므로 나머지 스택은 변경되지 않는다.
루프가 실제로 실행되는 방식
하나의 턴의 형태는 다음과 같으며, 워커가 실행되는 순서대로 설명된다.
브라우저/CLI/챗이 {session_id, message_id, payload}와 함께 harness::trigger를 통해 턴을 POST한다. 하네스 메타-워커는 payload를 run::start로 전달한다. 이 홉은 OpenTelemetry 스팬 래퍼가 세션 및 메시지 ID를 baggage로 시드하여 스택의 모든 워커에 걸친 모든 중첩된 iii.trigger 호출로 전파되도록 하기 위해 존재한다. 반대편의 트레이스 트리는 하나의 연결된 그래프이다.
run::start는 turn-orchestrator에 도착한다. 실행 요청을 영구 저장하고, iii 상태의 session/<sid>/turn_state에 초기 TurnStateRecord를 시드한 후 즉시 반환한다. 실제 작업은 turn-step FIFO에 대한 게시에 의해 깨어나는 내구성 있는 상태별 머신 내부에서 발생한다.
두 가지 종료 상태는 stopped(finishSession()을 통한 정상 종료)와 failed(예상치 못한 핸들러 throw가 여기로 라우팅되어 큐를 승인하여 재시도를 중단하고, message_complete{stop_reason:'error'}와 agent_end를 표시하여 UI에 이유를 표시함)이다. 종료는 턴 종료 경로에서 호출되는 인라인 finishSession() 포트로, 별도의 큐에 넣는 단계가 아니다.
provisioning은 세 가지 작업을 수행한다. 실행에 격리된 실행이 필요한 경우 iii-sandbox microVM을 부팅한다. system_default_skills(기본값 ["iii://iii-directory/index"])의 모든 네임스페이스에 대해 directory::skills::download를 호출하여 iii-directory가 실행 시작 시 사용하는 스킬 본문을 사전 캐싱하도록 한다. 또한 시스템 프롬프트를 세 가지 계층으로 조합한다: run_request.mode(plan, ask 또는 agent)에서 선택된 모드 단락, 모델에게 agent_trigger 규칙과 directory::skills::get 온디맨드 발견 패턴을 가르치는 iii 아이덴티티 전문, 그리고 에이전트가 부팅할 때 사용하는 기본 스킬의 추가된 인덱스. 호출자는 run::start에 system_prompt를 전달하여 전체 프롬프트를 재정의할 수 있으며, 그렇지 않으면 오케스트레이터가 빌드한다. 함수 스키마는 라이브 엔진 카탈로그에서 가져온다.
assistant_streaming은 실행의 provider 필드와 일치하는 공급자 워커에서 provider::<name>::stream을 호출한다. 공급자 워커는 auth::get_token(auth-credentials)을 통해 자격 증명을 가져오고, 모델의 SSE 응답을 iii 채널로 스트리밍하며, 오케스트레이터는 해당 채널을 소비하여 UI 팬아웃을 위해 agent::events에 message_update 이벤트를 내보낸다. 채널 생성 및 읽기 루프는 provider-stream.ts의 풀 기반 MessagePump 뒤에 있으므로 스트리밍 상태는 전환에 집중된 상태를 유지한다.
어시스턴트가 도구 호출을 반환하면, FSM은 function_execute 상태로 진입한다. 모든 도구 호출은 오케스트레이터의 단일 병목 지점인 dispatchWithHook을 통과한다. consultBefore는 5초 타임아웃으로 policy::check_permissions를 직접 호출한다. 정책 워커(기본 스택에서는 하네스 메타-워커)는 iii-permissions.yaml을 읽고, 호출의 function_id를 규칙 집합과 일치시킨 후 세 가지 결과 중 하나를 반환한다:
allow: 디스패치 진행, 오케스트레이터는 대상 함수를 트리거하고 결과를 기록한다.deny: 디스패치가DenialEnvelope으로 단락되고, 결과는 거부 기록이 된다.needs_approval: 개별 호출은 턴의awaiting_approval목록에 대기한다. 나머지 배치는 계속 디스패치된다. 턴은 하나 이상의 항목이 보류 중인 경우에만function_awaiting_approval로 전환된다.
승인 깨움은 반응형이며 공유된다. 오케스트레이터는 approvals 범위에 정확히 하나의 turn::on_approval 상태 트리거를 등록한다. 콘솔이 approval::resolve를 호출하면, approval-gate 워커는 approvals/<sid>/<cid> = {decision, reason}을 iii 상태에 기록한다. 이 쓰기는 turn::on_approval을 발생시키고, 영향을 받는 세션을 진행시킨다. function_awaiting_approval은 방금 도착한 결정만 읽고, 각각이 도착할 때마다 디스패치하며(allow는 사전 승인된 디스패치가 되고, deny 또는 aborted는 합성 거부가 됨), awaiting_approval[]이 비어 있으면 진행한다. 호출별 재개 함수를 등록할 필요가 없다. 보류 중인 승인을 복구하기 위한 시작 재스캔도 필요 없다. 하나의 트리거가 모든 세션을 처리한다.
구조상 fail-closed: 정책 워커에 연결할 수 없거나 5초 타임아웃이 발생하면 consultBefore는 gate_unavailable 인벨롭으로 호출을 거부한다. iii::durable::publish 자체가 오류를 발생시킨 경우, 훅 팬아웃은 publish_failed: true를 반환하고 오케스트레이터는 이를 거부로 처리한다.
이 형태에서 몇 가지 대기 시간 개선 효과가 나타난다. 함수 호출 후 훅은 해당 토픽에 등록된 내구성 있는 구독자가 없을 때 구독자-존재 캐시를 통해 publish_collect를 단락시켜 실행된 함수 호출당 약 500ms를 제거한다. tearing_down은 finishSession()에 인라인되어 턴당 하나의 내구성 있는 큐 홉을 제거한다. context-compaction은 오케스트레이터가 턴 경계에서 내보내는 전용 agent::turn_end 스트림을 구독하므로, 컴팩터 웨이크업은 이벤트당이 아닌 턴당으로 발생한다. session-create 팬아웃 상태 트리거는 범위별로만 게이트를 적용하고 프로세스 내에서 일치시키므로, 이전의 쓰기별 harness::session::is_create_event RPC는 사라졌다.
배치가 완료된 후, steering_check는 계속할지(continue), 중지할지(stop), 아니면 최대 턴에 도달했는지(max_turns) 결정한다. continue인 경우 assistant_streaming으로 루프백한다. stop 또는 max인 경우 finishSession()이 인라인으로 실행된다: agent_end를 내보내고, 샌드박스를 해제하고, stopped 상태로 전환한다.
전체 실행 동안, 참여하는 모든 워커는 iii.session.id, iii.message.id, iii.function.id로 태그된 OTel 스팬을 내보낸다. 이러한 태그는 엔진의 engine::traces::group_by가 트레이스 UI에서 "Group by Session" / "Group by Message" / "Group by Function"을 채우기 위해 읽는 값이다. 계측은 자동으로 이루어진다: src/runtime/worker.ts는 모든 registerFunction을 Proxy로 래핑하므로 개별 워커 코드가 스팬을 추가하는 것을 기억할 필요가 없다.
직접 구축하기
흥미로운 점은 위의 워커 중 어느 것도 특별하지 않다는 것이다. 각 워커는 엔진에 WebSocket을 열고, 일부 함수와 트리거를 등록하고 실행하는 프로세스일 뿐이다. 계약은 모든 애플리케이션 워커가 사용하는 계약과 동일하다. 하네스는 비즈니스 로직과 동일한 프리미티브 위에 구축된다.
즉, "자체 하네스 구축"은 "워커 작성"과 동일한 작업으로 분해된다. 교체하려는 계층을 선택하고, 버스에 동일한 함수를 등록하는 워커를 작성하고, iii worker add하면 나머지 스택이 당신의 워커를 사용하기 시작한다.
위의 워커 테이블에는 나타나지 않지만 하네스 동작에 중요한 두 가지 계층이 있다. 스킬은 각 워커가 자신의 함수가 수행하는 작업을 알리는 방법이다. 모든 워커는 iii://<워커>/<함수>에 스킬을 게시할 수 있으며, 에이전트는 해당 함수를 처음 호출하기 전에 directory::skills::get을 통해 이 스킬을 가져온다. 시스템 프롬프트는 턴별로 모드 단락, iii 아이덴티티 전문, 실행 시 구성된 기본 스킬 본문에서 조합된다. 둘 다 버스 기반이다: 스킬은 iii-directory 워커가 제공하고, 시스템 프롬프트는 turn-orchestrator가 조합한다. 둘 다 교체 가능하다.
다섯 가지 구체적인 예시.
모델 카탈로그를 라이브 API로 교체. models::list, models::get, models::supports를 등록하는 워커를 작성하라. N분마다 공급자의 카탈로그 엔드포인트에서 가져와 캐싱하도록 한다. 게시하라. iii worker add your-org/dynamic-models-catalog를 실행하라. 정적 models-catalog 워커를 중지하라. turn-orchestrator는 차이를 전혀 인식하지 못한다. iii.trigger('models::list')를 호출하면 엔진은 가장 최근에 해당 함수 ID를 등록한 워커로 라우팅한다.
새로운 공급자 추가. provider-kimi와 provider-lmstudio의 형태는 이미 이를 입증한다. 각각은 provider::<name>::stream과 provider::<name>::complete를 등록하고, 업스트림 API의 SSE 스트림을 iii 채널로 소비하며, budget::record를 통해 llm-budget에 모델 사용량을 기록하는 하나의 워커다. 다섯 번째 공급자를 추가하는 것은 하나의 폴더에 iii.worker.yaml 하나와 register.ts 하나를 작성하는 것과 같다. 레지스트리에 게시하거나 로컬로 유지하라. turn-orchestrator는 실행의 provider 필드로 공급자를 선택하며, 새 공급자는 워커가 연결되는 즉시 사용 가능해진다.
개인 아티팩트 저장소에서 스킬 제공. directory::skills::get과 directory::skills::list를 등록하는 워커를 작성하고, 내부 문서 시스템 또는 개인 S3 버킷을 백엔드로 사용하라. 기본 iii-directory 워커를 연결 해제하거나 이름을 바꾸라. 오케스트레이터의 부트스트랩은 네임스페이스별로 directory::skills::download를 호출하며, 당신의 워커가 응답한다. 에이전트의 "새 함수를 호출하기 전에 함수별 스킬 가져오기" 패턴은 와이어 형태가 동일하므로 변경 없이 계속 작동한다.
시스템 프롬프트를 완전히 재정의. run::start는 선택적 system_prompt 필드를 허용한다. 이를 전달하면 오케스트레이터는 사용자의 문자열을 그대로 사용하고, 모드 단락 + 아이덴티티 전문 + 스킬 부록 조합을 건너뛴다. 수정 없이 하네스가 존중해야 하는 기존 프롬프트 에셋이 있을 때 유용하다. 부트스트랩에서 스킬 다운로드는 계속 실행되므로, 사용자 정의 프롬프트를 사용하더라도 에이전트는 directory::skills::get 온디맨드 발견을 유지한다.
승인 게이트 UI 표면 교체. 기본 approval-gate 워커는 approval::resolve를 등록한다. 와이어 스키마는 하나의 함수 호출이다:
핸들러는 approvals/<sid>/<cid> = {decision, reason}을 iii 상태에 영구 저장한다. 오케스트레이터의 단일 turn::on_approval 상태 트리거는 이 쓰기를 선택하고 올바른 세션을 깨운다. 콘솔 대신 Slack에서 승인을 처리하려면, /approve <id> 및 /deny <id> 슬래시 명령을 수신한 다음 올바른 페이로드로 approval::resolve를 호출하는 Slack 워커를 작성하라. 오케스트레이터는 차이를 전혀 인식하지 못한다. 전체 approval-gate 워커는 변경되지 않은 상태로 유지된다. 새 워커를 추가했을 뿐, 기존 워커를 교체한 것은 아니다.
다른 정책 엔진(OPA, Cedar, 자체 DSL)을 원한다면, policy::check_permissions를 등록하고 { decision, rule_id?, matched_constraint? }를 반환하는 워커를 작성하라. 기본 정책 워커(하네스 메타-워커 내부에 래핑되어 있으므로 해당 핸들러를 비활성화하거나 축소된 메타-워커를 실행)를 연결 해제하라. turn-orchestrator의 consultBefore는 차이를 인식하지 못한다. 동일한 5초 타임아웃, 동일한 fail-closed 의미 체계, 동일한 와이어 형태를 가진다.
이 예시들의 요점은 특정 교체 방법이 아니다. 그것은 작업의 형태이다. iii 스택의 모든 하네스 계층은 버스상의 하나 또는 두 개의 함수 ID를 통해 접근할 수 있다. 계층을 교체하는 것은 해당 ID를 등록하는 워커를 작성하는 것이다. 시스템의 나머지 부분은 그대로 유지된다.
하네스는 갈림길이 아니라 슬라이더다
고전적인 하네스 논쟁은 얇음(thin) 대 두꺼움(thick)으로 프레임을 구성한다. Anthropic의 얇은 루프 대 LangGraph의 명시적 DAG. 이 프레임은 당신이 한쪽을 선택하고 그와 함께 살아야 한다고 가정한다.
하네스가 동일한 버스의 워커로 구성되면, 얇음 대 두꺼움은 단순히 설치한 워커의 수에 불과하다. 얇은 하네스는 turn-orchestrator + provider-anthropic + auth-credentials + 최소한의 harness meta-worker로 구성된다. 그것뿐이다. 승인, 예산, 정책 엔진, 훅 팬아웃이 없다. 무엇이든 실행하라. 모델을 신뢰하라. 자율 연구 에이전트, 실험 루프, 내부용 무엇이든 유용하다.
두꺼운 하네스는 13개의 모든 워커 + context-compaction + 사용자 정의 정책 워커 + 사용자 정의 approval-gate + Slack 통합 승인 표면 + 작업 공간별 상한을 적용하는 예산 워커로 구성된다. 모든 도구 호출을 감사 가능하게 하고 모든 모델 지출이 재무 대시보드에 집계되어야 하는 고객 워크플로우를 실행하는 에이전트에 유용하다.
얇음과 두꺼움 사이의 아키텍처적 거리는 재작성이 아니라 구성 변경에 불과하다. 동일한 와이어 프로토콜, 동일한 트레이스 형태, 동일한 관찰 가능성 스토리. 슬라이더는 config.yaml에서 워커를 추가 및 제거하여 움직인다. 다른 모든 것은 유지된다.
이는 단일 워커 내부에도 적용된다. turn-orchestrator는 방금 FSM을 11개 상태에서 7개로 축소하고, 호출별 turn::approval_resume::<sid>/<cid> 메커니즘을 approvals 범위에 대한 하나의 반응형 turn::on_approval 상태 트리거로 대체하고, tearing_down을 finishSession() 포트에 인라인하는 리팩터링을 출시했다. 스택의 다른 모든 워커(approval-gate, session, llm-budget, providers, models-catalog, auth-credentials, hook-fanout, context-compaction)는 변경되지 않았다. approval::resolve 와이어 형태는 움직이지 않았다. 계약은 유지되었다. 이것이 구성이 제공하는 속성이다: 한 워커의 주요 내부 재작성은 자체 포함된 변경 사항이며, 모든 이웃이 버스 수준의 함수 ID를 통해 통신하기 때문이다.
이것이 프레임워크 모델이 제공할 수 없는 부분이다. 프레임워크는 당신을 위해 슬라이더의 위치를 선택하고 당신을 가둔다. 워커 모델은 슬라이더를 당신의 손에 남겨둔다.
이것이 실제로 의미하는 바
프레임워크 위에서 에이전트를 실행하면서 대부분의 팀이 규모 확장 시 부딪히는 동일한 경계 문제를 경험하고 있다면, 해결책은 아마도 "자체 프레임워크로 하네스를 다시 작성하는 것"이 아닐 것이다. 정책 엔진이 필요한 만큼 확장되지 않는다. 승인 UI가 프레임워크의 채팅 표면에 연결되어 있다. 자격 증명 저장소가 비밀 관리자와 통신할 수 없다. 예산 추적기가 트레이스가 볼 수 없는 사이드카 데이터베이스에 있다. 해결책은 하네스가 처음부터 분해된 기반으로 전환하는 것이다.
이 주장을 가장 빨리 체감하는 방법은 github.com/iii-hq/workers를 클론하고, pnpm install, pnpm build를 실행한 다음 복합 진입점을 실행하는 것이다. iii 엔진을 가리키는 14개 워커로 구성된 전체 하네스를 얻을 수 있다. 부트 목록에서 항목을 제거하여 모든 워커를 비활성화할 수 있다. 동일한 함수 ID를 등록하는 대체 워커를 작성하여 모든 워커를 교체할 수 있다. 훅 토픽에 구독자를 추가하여 모든 워커를 확장할 수 있다. hook-fanout::publish_collect는 모든 iii 훅이 기반으로 하는 일반적인 기능이다.
문서는 iii.dev/docs에서 확인할 수 있다. 엔진은 github.com/iii-hq/iii에 있다. 워커 레지스트리는 workers.iii.dev에 있다. 하네스 번들은 github.com/iii-hq/workers/harness에 있다.
베팅
하네스는 설치하는 것이 아니다. 하네스는 에이전트가 내구성 있고 안전하며 관찰 가능하게 실행되기 위해 시스템이 수행해야 하는 작업 집합이다. 프레임워크 시대는 그 아래에 이를 구성할 방법을 제공하는 것이 없었기 때문에 이러한 작업을 함께 묶었다.
iii의 베팅은 하나의 프리미티브, 즉 WebSocket을 통해 엔진에 연결하고 함수와 트리거를 등록하는 워커가 이러한 각 작업을 개별적으로 흡수할 만큼 작으며, 결과 스택이 모든 계층이 독립적으로 교체 가능하기 때문에 어떤 프레임워크보다 더 유용하다는 것이다.
당신은 iii 하네스를 채택하지 않는다. 당신이 원하는 워커를 설치하고, 필요한 워커를 작성하며, 결국 시스템과 정확히 일치하는 형태의 하네스를 갖게 된다. 모든 계층에서 동일한 프로토콜. 모든 호출에 걸쳐 동일한 트레이스. 레지스트리에서 가져온 부분과 직접 게시한 부분 모두에 대해 동일한 iii worker add.
기반이 올바른 형태일 때 "자체 에이전트 하네스 구축"이 의미하는 바가 이것이다. 워커를 선택하라. 누락된 것을 작성하라. 구성하라. 하네스는 구성 그 자체다.
현대 세계에 필요한 완벽한 에이전트 하네스를 함께 구축해 보세요: discord.gg/iiidev
iii는 오픈 소스입니다. iii.dev/docs에서 시작하세요. 하네스 워커는 github.com/iii-hq/workers에, 엔진은 github.com/iii-hq/iii에 있습니다.
— Mike Piccolo, Founder & CEO @iiidevs
