내 코딩 에이전트는 작업이 아닌 세션을 기억했다
코딩 에이전트는 스레드를 유지하면서도 여전히 건망증이 있는 것처럼 느껴질 수 있습니다.
CliGate를 구축하는 동안 이 문제에 직면했습니다. 세션 연속성은 해결했지만, 반복되는 작업은 여전히 느렸습니다.
에이전트는 대화는 기억했지만, 작업은 기억하지 못했습니다.
세션 연속성은 한 가지 문제를 해결합니다. 다음과 같은 후속 명령을 가능하게 합니다:
- 계속해
- 이 파일에도 똑같이 해줘
- 다시 시도해줘
- 에러를 설명해줘
이는 흐름(flow) 측면에서 중요합니다. 하지만 며칠 뒤에 워크플로우를 반복할 때는 한계가 있습니다.
에이전트가 어떤 버튼이 작동하는지 또는 어떤 단계가 막다른 길인지 학습한다면, 단일 오픈 세션만으로는 충분하지 않습니다. 에이전트는 지난 실행을 성공하게 만들었던 것이 무엇인지 회상할 수 있어야 합니다.
첫 번째 실행이 가장 비용이 많이 듭니다. 에이전트가 다음과 같은 미세한 세부 사항을 발견하는 시점이기 때문입니다:
- 특정 메뉴에 동작이 숨겨져 있음
- 에디터가 iframe임
- 프로젝트에 특정 응답 스타일이 필요함
- 환경 URL이 운영 환경과 다름
수정 전에는 이러한 세부 사항들이 그저 가공되지 않은 로그에 불과했습니다. 에이전트에게 히스토리는 있었지만, 재사용 가능한 메모리는 없었습니다. 매번 똑같은 사실을 다시 발견해야 했습니다. 그것은 지능이 아닙니다. 똑같은 비용을 두 번 지불하는 것일 뿐입니다.
잘못된 접근 방식은 더 많은 히스토리를 저장하고 모델이 이를 사용하기를 바라는 것입니다. 이는 노이즈를 생성합니다.
저는 더 작고 재사용 가능한 레이어가 필요했습니다. 모든 것을 저장하는 방식에서 다음과 같은 것들을 저장하는 방식으로 전환했습니다:
- 절차: 최적의 단계 및 알려진 막다른 길
- 사실: URL, 규칙 또는 설정
- 지침: 작업이 수행되기를 원하는 방식
- 참조: 문서가 있는 위치
이것이 시스템을 바꾸었습니다. 거대한 대화 기록을 읽는 대신, 어시스턴트는 파일 기반 메모리 레이어를 사용합니다.
인터페이스가 바뀌고 버튼 위치가 이동하기 때문에 완벽한 재현(replay)을 원하지는 않았습니다. 대신 다음과 같은 루프를 원했습니다:
- 이전의 최적 절차 회상
- 먼저 시도
- 각 단계 검증
- 실패 시 다시 탐색으로 복귀
- 성공 후 메모리 업데이트
또한 상시 규칙(standing rules)을 세션 히스토리와 분리했습니다. "운영 데이터를 건드리지 마라"와 같은 규칙은 대화 문맥이 아닙니다. 그것은 운영 규칙입니다. 이를 분리하면 어시스턴트의 동작을 예측할 수 있게 됩니다.
결과적으로 반복 작업이 짧아졌습니다. 어시스턴트는 빈 전술적 모델로 시작하지 않기 때문에 더 빠르게 움직입니다.
코딩 에이전트를 구축한다면, 스레드와 학습을 혼동하지 마십시오.
- 세션은 연속성을 도와줍니다.
- 메모리는 반복되는 작업을 도와줍니다.
세션은 대화를 유지하고, 메모리 레이어는 학습 내용을 유지합니다.
귀하의 시스템은 스레드를 기억하고 있습니까, 아니면 성공적인 절차를 기억하고 있습니까?
Source: https://dev.to/