요약하자면(TL;DR): 저는 pi를 위한 작은 다중 에이전트 설정을 만들었습니다. 이는 확장이나 도구 없이 하나의 스킬과 하나의 Python 스크립트로 구성되어 있습니다. 사용자의 에이전트는 서브에이전트를 포그라운드에서 병렬로 시작하거나 백그라운드에서 시작할 수 있으며, 이를 기다리거나(wait), 방향을 지정하고(steer), 중단시키고(abort), 재개할 수 있습니다(resume). 백그라운드 작업은 메인 pi 세션이 종료되거나 강제 종료되어도 계속 실행됩니다. 새로운 pi 세션—심지어 원래의 메인 세션과 다른 경우라도—이 그 결과를 검색할 수 있습니다. 사용자의 에이전트가 위임하기로 결정할 때까지는 약 50 토큰의 컨텍스트 비용만 발생합니다.
리포지토리: https://github.com/milanglacier/pi-multi-agent-skill
다른 스킬처럼 npx skills로 설치하거나, github 리포지토리를 클론하여 ~/.pi/agent/skills에 심볼릭 링크를 걸어 설치할 수 있습니다. 또는 pi install을 통해 pi 패키지로도 설치할 수 있습니다.
기능:
- 거의 토큰 비용 없음. 에이전트가 위임하기 전까지는 스킬 설명만 컨텍스트에 포함되어 몇십 개의 토큰밖에 차지하지 않습니다. 위임 시 SKILL.md가 로드되며, 약 1.2k 토큰이 추가됩니다.
- Stdlib-only Python 3.9 이상. 확장이나 npm 패키지 등 설치할 것이 전혀 없습니다.
- 빠른 질문을 위한 포그라운드 실행과 긴 작업을 위한
--background 옵션을 제공합니다. 백그라운드 작업은 메인 에이전트가 종료되어도 계속 실행되며, 나중에 어떤 세션에서도 그 결과를 수집할 수 있습니다.
- 포그라운드 실행은 중첩의 모든 레벨에서 멈추면 중단됩니다.
- 작업을 방향 지정(steer), 중단(abort), 재개(resume)할 수 있으며, 무엇을 하고 있는지 목록화(list), 상태 확인(status), 미리 보기(peek) 할 수 있습니다.
- 서브에이전트는 사용자의 전체 pi 설정을 로드합니다: 확장, MCP 서버, 스킬 및 설정. 프로필은 시스템 프롬프트, 모델, 사고 수준 및 사용 가능한 도구를 설정합니다. 범용적인 목적의 Explore와 읽기 전용 Explore가 포함되어 있습니다. 프로필은 다른 서브에이전트 도구의 프로필과 동일합니다.
--fork는 현재 대화 내용을 서브에이전트에 제공합니다. Claude Code, Codex 또는 셸을 가진 모든 에이전트에서 작동합니다.
제가 여기까지 오게 된 과정:
몇 달 동안 tintinweb의 pi-subagents를 사용했는데, 정말 좋은 확장 프로그램입니다. UI가 멋지고 기능도 많으며 대부분의 경우 잘 작동합니다. 이를 만들어준 tintinweb과 커뮤니티에 제공하는 모든 것에 감사드립니다.
만족스럽다면 계속 사용하세요. 얼마 전의 pi 업그레이드가 저에게 두 가지 문제를 일으켰습니다. MCP 서버가 서브에이전트에서 로드되지 않았고, 서브에이전트가 부모의 사고 수준(thinking level)을 상속받지 못했습니다. 각각의 수정은 몇 줄만 필요했기 때문에, 저는 확장 기능을 포크하여 패치했습니다. 업스트림(Upstream) 수정 사항들은 시간이 걸렸지만, 이 게시물보다 2일 전에 도착하기도 했습니다. 그 버그들을 고치면서 저는 확장 기능을 더 면밀히 읽게 되었고, 이것이 얼마나 많은 컨텍스트를 사용하는지 알게 되었습니다. 약 두 달 전에는 동적 워크플로우 도구(dynamic workflow tool)가 추가되었습니다. 이를 사용하면 에이전트가 여러 서브에이전트를 오케스트레이션하는 JavaScript 스크립트를 작성합니다. 강력하지만 매우 복잡하며, 이 도구의 스키마와 지침은 약 6k 토큰을 소모합니다. 이 스키마는 워크플로우를 사용하든 안 하든 첫 메시지부터 모든 세션에 포함됩니다. 또한 선택적(opt-out)이므로, 설정을 찾아 비활성화할 때까지 비용을 지불하게 됩니다. 많은 사람들이 이것이 존재한다는 것을 모른다고 생각합니다. 워크플로우 도구를 끄면, 에이전트 도구는 여전히 약 3k 토큰을 소모하며, 이는 확장 기능의 기능과 함께 증가해 왔습니다. 저는 이 수치들을 확장 기능을 켜고 끄면서 세션을 시작하고 비교하여 확인했습니다. 그래서 저는 제 컨텍스트에서 제가 항상 상세한 JSON 스키마와 거의 사용하지 않는 옵션(예: worktree isolation)을 나열하는 전체 도구가 필요한지 스스로에게 물었습니다. 저의 대답은 '아니요'였습니다. pi는 이미 --mode rpc로 헤드리스(headless) 실행이 가능하며, 그 CLI 플래그들은 서브에이전트가 필요로 하는 것들, 즉 도구(tools), 확장 기능(extensions), 모델(model), 사고 수준(thinking level), 세션 재개(session resume)를 이미 포함하고 있습니다. 따라서 올바른 플래그로 pi를 시작하는 작은 CLI와 이를 사용하는 방법을 설명하는 스킬만으로 전용 도구를 대체할 수 있습니다. 또한 스킬은 단계별로 로드되지만, 도구는 그렇게 할 수 없습니다. 에이전트는 처음에는 스킬의 짧은 설명만 볼 수 있습니다. 그리고 위임(delegate)하기로 결정했을 때 주요 지침을 로드하고, 특이한 옵션이 필요할 때만 상세 참조를 읽습니다. 스티어링(Steering) 역시 도구가 필요하지 않습니다. 왜냐하면 그것은 실행 중인 pi 프로세스로 전송되는 단순한 RPC 메시지일 뿐이기 때문입니다.
pi-subagents와 비교한 토큰 비용: 서브에이전트 도구 및 주입된 시스템 프롬프트로 약 3k 토큰이 소요됩니다. 게다가 기본적으로 활성화되어 수동으로 비활성화해야 하는 동적 워크플로우 도구에 약 6k 토큰이 추가됩니다. 이 두 가지는 첫 메시지부터 모든 세션에서 발생하므로, 기본 설정만으로도 아무것도 요청하지 않았을 때 약 9k 토큰이 소요됩니다. 에이전트가 위임하기 전의 이 스킬은 오직 스킬 설명만 필요하며, 약 50토큰입니다. 에이전트가 위임한 후에는 SKILL.md가 로드되어 약 1.2k 토큰이 소요되며, 이는 완전한 다중 에이전트 사용에 충분합니다. 명령어 세부 정보, 프로필 형식, 수명 주기 및 문제 해결은 별도의 참조 파일에 있습니다. 에이전트는 필요할 때만 이를 읽습니다. 대부분의 세션에서는 위임하지 않으므로 거의 비용을 지불하지 않습니다. 위임하더라도 도구 스키마 자체보다 적게 소요됩니다. 공정하게 말하자면, 이것은 일대일 비교가 아닙니다. pi-subagents는 이 스킬보다 더 많은 것을 합니다. 그 도구에는 많은 옵션이 있으며, 각각의 옵션은 스키마에서 매개변수가 필요하고 시스템 프롬프트에 텍스트를 추가합니다. 이러한 토큰 비용의 일부는 이 스킬이 가지고 있지 않은 워크트리 격리(worktree isolation)와 같은 기능을 위한 것입니다. 저는 그러한 기능들이 다중 에이전트 작업에는 필요하지 않다고 생각합니다. 만약 제가 에이전트가 자체 워크트리에서 작업하기를 원한다면, 프롬프트에 (
저는 첫 주 동안 서브에이전트의 스크립트를 지켜봤고, 그 이후로는 거의 읽지 않았습니다. 저는 서브에이전트가 내게가 아니라 주로 메인 에이전트를 위한 최종 답변을 한다는 것을 깨달았습니다. 대신, 저는 제가 더 중요하게 생각하는 것들을 얻습니다. 각 서브에이전트는 CLI 플래그로 시작되는 실제 pi 프로세스이기 때문에, 일반적인 pi와 동일한 확장(extensions), MCP 서버, 스킬 및 설정을 로드합니다. 이 스크립트는 pi의 확장 API를 전혀 사용하지 않고, 변경 빈도가 훨씬 적은 CLI 플래그와 RPC만 사용하므로 pi 업그레이드가 거의 영향을 미치지 않습니다. 별도의 프로세스는 제가 가장 좋아하는 기능을 제공합니다: 메인 에이전트가 종료되어도 백그라운드 작업이 계속 진행되며, 새로운 세션에서 나중에 그 결과를 수집할 수 있습니다. 별도의 프로세스는 인-프로세스(in-process) 세션보다 더 많은 관리가 필요하며, 이 스크립트는 단순히 CLI 래퍼를 넘어섭니다. 왜냐하면 에이전트가 처리해야 할 부분을 대신 처리해주기 때문입니다. 예를 들어, pi는 종료 루틴을 실행하기 전에 stdout에 첫 번째 쓰기 실패가 발생하면 종료되고, 에이전트의 명령은 계속 실행된 채로 남겨둡니다. 따라서 각 작업은 pi가 종료할 때까지 출력을 계속 읽는 자체 러너(runner) 프로세스를 가집니다. 이 스크립트는 이런 경우를 위한 실제 테스트 스위트를 가지고 있지만, 아이디어는 단순합니다: pi를 시작하고, 프롬프트를 주고, steer 및 abort 메시지를 전달하며, 각 작업의 결과를 이름별로 저장하는 것입니다.
비목표(Non Goals). 이것들은 스킬을 작고 비대해지지 않게 유지하기 위한 의도적인 비목표들입니다. 각각은 사용자의 워크플로우에 맞춰 선택할 수 있는 별도의 확장이나 스킬이 더 좋습니다. 이는 pi 자체의 미니멀리즘과 유닉스 철학(Unix philosophy)을 따릅니다: 한 가지 일을 잘 수행하고 조합하는 것입니다.
메모리(Memory). 에이전트는 작업 간에 메모리를 공유하거나 유지하지 않습니다. 메모리 확장을 사용하거나, 에이전트가 인계 노트(handoff notes)를 작성하도록 하십시오.
스케줄링(Scheduling). cron 스타일이나 반복되는 에이전트는 없습니다. 명령을 실행하려면 cron, systemd 타이머 또는 스케줄러 확장(scheduler extension)을 사용하십시오.
작업트리(Worktrees). 에이전트는 git 작업트리 내에서 격리되지 않습니다. 단지 에이전트에게 작업트리를 사용할 것을 프롬프트만 하십시오.
동적 워크플로우(Dynamic workflows). 파이프라인, 게이트를 사용한 병렬 팬아웃(parallel fan-out with gates), 또는 단계와 같은 오케스트레이션(orchestration)을 위한 스크립팅 계층은 없습니다.
에이전트는 이미 일반 명령(plain commands)으로 작업을 시작하고, 기다리고, 연결할 수 있습니다. 결정론적 스크립트(deterministic scripts)의 경우 pi-dynamic-workflow와 같은 확장을 사용하세요. 명령어가 어떻게 생겼는지 보여드리겠습니다. 에이전트가 스스로 실행하지만, 터미널에서도 직접 실행할 수 있습니다:
Ask a read-only agent a quick question and wait for the answer
multi_agent.py run --profile Explore "Where is the retry policy defined?"
Start a review in the background, then collect the result later
multi_agent.py run --background --name review "Review the error handling in src/server/"
multi_agent.py wait review --timeout 120
Correct the running job, then give it a follow-up task when it is done
multi_agent.py steer review "Skip generated files"
multi_agent.py resume review "Now check the client side"
See all jobs and what they are doing
multi_agent.py list
직접 시도해 보시고, 어떤 것이 작동하는지, 무엇이 깨지는지 알려주시면 좋겠습니다.
제출자: /u/Florence-Equator [링크] [댓글]