AgentRun 0.1.0-beta.4 릴리스 노트 / 새로운 기능

AgentRun 0.1.0-beta.4는 기존 AI 에이전트에 구조를 더하기 위해 설계된 워크플로우 언어입니다. 개발자는 이를 통해 반복 가능한 단계를 정의하고, Jev를 통한 집중적인 의사결정을 통합하며, 특정 기준이 충족되지 않을 때 에이전트 조사를 트리거할 수 있습니다. 이 시스템은 에이전트의 기존 도구, 권한 및 모델 액세스를 유지하면서 실행을 위한 공식적인 프레임워크를 제공하도록 설계되었습니다.

핵심 아키텍처 및 DSL

AgentRun DSL은 JSON 또는 Zod 계약이 포함된 TypeScript 빌더를 통해 워크플로우를 정의할 수 있게 합니다. 이러한 접근 방식은 입력 및 출력 유형이 추론되고 중간 상태 경로가 런타임에 확인되도록 보장합니다.

주요 아키텍처 특징은 다음과 같습니다:

• 노드 유형: 시스템은 call(도구 실행용) 및 judge(의사결정용)와 같은 특정 노드를 사용합니다.
• 제어 흐름: 워크플로우는 다른 워크플로우에 대한 중첩 호출, 작업의 병렬 매핑 및 제한된 루프를 지원합니다.
• 취소 및 복구: 프레임워크는 실행 권한 관리, 취소 및 상태 복구를 위한 호스트 통합을 제공합니다.
• 통합: 시스템은 실행 및 검증을 위한 @parcha/agentrun-dsl, 유형화된 결정을 위한 @parcha/agentrun-jev, 에이전트 러너 확장을 위한 @parcha/agentrun-pi의 세 가지 주요 패키지로 나뉩니다.

Jev 기반 의사결정

AgentRun은 Jev와 통합되어 "유형화된 결정(typed decisions)"을 구현합니다. 이를 통해 워크플로우는 신뢰도 임계값을 강제함으로써 단순한 LLM 프롬프트 그 이상으로 나아갈 수 있습니다. 예를 들어, 지원 워크플로우에서 결정 노드는 진행하기 전에 최소 0.8의 신뢰도 점수로 yes 답변을 요구할 수 있습니다. 신뢰도가 충족되지 않으면 워크플로우는 에이전트를 추가 조사 단계로 라우팅하거나 사람의 검토를 위해 작업을 에스컬레이션하도록 프로그래밍할 수 있습니다.

구현 및 사용 사례

지원 워크플로우 예시

일반적인 지원 시나리오에서 AgentRun은 검색 및 결정 노드 시퀀스를 관리합니다. 워크플로우는 도구를 사용하여 답변을 검색하고, Jev를 사용하여 답변이 목적에 적합한지 판단하며, 신뢰도 검사를 통과하지 못하면 에이전트가 추가 조사를 수행하도록 트리거합니다. 두 번째 검사도 실패하면 사례가 검토를 위해 에스컬레이션됩니다.

연구 워크플로우 예시

연구 데모는 하위 질문을 계획하고, 병렬로 조사하며, 증거를 선별하고, 최종 보고서를 종합하는 능력을 보여줍니다. 이는 증거 선택과 보고서 작성이 필요한 복잡한 다단계 추론 작업에 대한 시스템의 역량을 입증합니다.

Pi와의 통합

AgentRun은 Pi 환경(버전 0.87.0 이상)에 통합될 수 있습니다. @parcha/agentrun-pi 확장을 설치하면 사용자는 /agentrun demo와 같은 명령어를 사용하여 스크립트 예제를 로드하거나 /agentrun run을 사용하여 실행할 수 있습니다. Pi는 또한 자연어 지침을 제공하여 새로운 워크플로우를 구축하는 데 사용할 수 있으며, 에이전트는 이를 공식적인 AgentRun 워크플로우 정의로 변환합니다.

커뮤니티 관점 및 기술적 트레이드오프

이 프로젝트를 둘러싼 기술적 논의에서는 에이전트를 위한 워크플로우 엔진과 관련하여 몇 가지 고려 사항이 강조되었습니다:

"비용이나 노력 속성이 없는 엣지와 보상이 없는 종료 상태가 있는 그래프 워크플로우는 쓸모가 없습니다... 얼마 전 SDLC를 하니스 도구, 가중치가 있는 유한 상태 머신의 조합으로 표현하는 것에 대해 생각했습니다... 목표는 작업 큐를 하위 워크플로우로 모델링하고 가장 가치 있는 작업을 구현하는 것입니다." — @handle

다른 기여자들은 AgentRun이 전문화된 DSL을 제공하지만, 업계에는 이미 Temporal, Erandril 또는 Airflow와 같은 내구성 있는 워크플로우 솔루션이 존재한다고 언급했습니다. 다만 AgentRun의 구체적인 초점은 에이전트 루프와 유형화된 결정의 통합에 있습니다.

한 개발자는 워크플로우 정의에 대한 자신의 접근 방식은 사용자나 에이전트가 사용자 정의 DSL 없이도 기능을 이해할 수 있도록 TypeScript와 같은 "실제" 언어를 직접 사용하는 것을 선호하며, 코드의 AST(추상 구문 트리)에서 UI를 도출한다고 언급했습니다.