회사 하네스를 어떻게 만들나요?
우리는 LangChain 내부 에이전트를 마케팅, 영업, 엔지니어링 부서에 구축했으며, 이로 인해 각 팀의 작업 방식이 완전히 바뀌었습니다. 이를 제대로 구현하는 것은 쉽지 않았습니다. 우리는 멀티플레이어 하네스와 관련된 문제들을 해결하는 데 많은 시간을 보냈고, 모든 팀은 동일한 핵심 원리에 도달했습니다:
- 사람들이 이미 일하는 곳에 존재합니다(우리에게는 Slack입니다)
- 누가 요청하는지 알고, 어떤 사람에게는 서비스를 제공하며 자신만의 정체성을 유지하고, 다른 사람에게는 그렇지 않게 행동합니다
- 그것은 메모리를 가지고 있으며, 전역적으로 또는 사용자 수준에서 제한됩니다
- 코드는 샌드박스에서 실행되며, 인증이 필요한 서비스에 요청을 보낼 수 있습니다
- 대부분의 실행은 누군가에 의해 명시적으로 호출되기보다는 예약되어 있음 ( ambient 에이전트!!
감사합니다 @caspar_br 이 블로그에 대한 도움을 받으려면
LangChain 내부 에이전트
이 논의를 바탕으로, LangChain에 있는 세 가지 주요 에이전트에 대한 간단한 개요를 살펴보겠습니다:
GTM 에이전트: GTM 활동을 지원하는 능동적이고 항상 활성화된 에이전트입니다. 이메일과 새로운 자격이 있는 리드를 모니터링하고 응답하며, 매일 간단한 보고를 보내고, 계정 관련 질문에 답변할 수 있으며, 외부로의 연락을 진행할 수도 있습니다.
OpenSWE: 우리의 엔지니어링 에이전트는 PR 작업 및 초안 작성에 참여할 수 있으며, 모든 PR에 대한 코드 리뷰도 수행합니다.
콘텐츠 스튜디오: 우리의 마케팅 에이전트로서, 우리의 스타일과 포지셔닝에 대한 이해를 바탕으로 자산(블로그, 이미지, 파워포인트, 동영상)을 작성할 수 있습니다.
이 모든 에이전트는 동일한 방식으로 구축됩니다. 우리는 이것이 회사용 하네스를 구축하는 일반적인 방법이라고 생각합니다.
문제: 사용자 경험
우리의 모든 에이전트는 사람들이 이미 일하는 곳에 위치해 있으며, 우리에게는 Slack입니다. 각 에이전트는 자체적인 Slack 앱를 가지고 있어서 채널에서 DM을 보내거나 태그를 걸 수 있습니다. 채널에서 이러한 에이전트와 함께 작업하는 한 가지 장점은 다른 사람들이 사람들이 이를 어떻게 사용하는지 볼 수 있다는 것입니다.
우리가 추가한 좋은 기능 중 하나는 Slack에서 대화를 따로 분리하는 개념입니다. 종종 훌륭한 대화가 이루어지고 있으면 에이전트에게 의견을 물어보거나 특정 작업을 하도록 요청하고 싶습니다. 하지만 그 에이전트가 그 스레드에 참여하면 인간적인 대화가 더럽혀지고 주의가 분산됩니다. 그래서 에이전트들이 채널 내에서 자체 스레드로 따로 분리할 수 있는 쉬운 방법을 추가했습니다.
일부 사용자 경험은 슬랙에서 하지 않는 것이 가장 좋습니다. 예를 들어, GTM 에이전트가 제가 보내길 원하는 이메일을 검토할 때는 슬랙에서 한 번만 처리하는 것이 괜찮지만, 대량의 메시지가 쌓여 있을 경우 슬랙 메시지를 통해 그런 것들을 추적하는 것은 전혀 즐거운 경험이 아닙니다. 그러한 경험들에 대해 우리는 맞춤형 UI를 개발하게 되었습니다.
문제: 정체성
우리가 해결한 가장 복잡하고 어려운 문제는 정체성이었습니다. 구체적으로는, 이러한 에이전트가 행동을 취할 때 누구를 대신하여 그 행동을 하는가 하는 것이죠.
업계에서는 이를 처리하는 주요 방법이 두 가지가 있습니다:
- On-behalf-of: 에이전트는 에이전트를 호출한 사용자의 대신 행동합니다
- 고정된 자격 증명: 에이전트가 누구에게 호출되든지 사용하는 고정된 자격 증명 집합이 있습니다(예: 서비스 계정).
이것이 우리가 각 에이전트에 대해 처리한 방식입니다 (문서: Managed Deep Agents에 ID 추가, 연결 관리):
OpenSWE:
- 메시지를 보낼 때, 그것은 당신을 대신하여 행동합니다(예: 당신의 GitHub 계정으로 PR을 열어줍니다).
- 백그라운드에서 실행될 때(예: 코드 리뷰 에이전트로서)는 자신의 정체성(GitHub 앱)을 가지고 작동합니다.
GTM 에이전트:
- 일부 도구(예: Salesforce 접근)에서는 고정된 ID를 사용하므로 모든 사람이 로그인해야 하는 것은 아닙니다.
- 이미지 에이전트를 호출하는 사용자를 대신하여 작동하는 일부 도구(예: 이메일)가 있습니다. 이러한 도구는 DM에서만 사용 가능합니다. 공유 채널에서는 사용할 수 없습니다.
콘텐츠 스튜디오:
- Notion과 같은 몇 가지 도구가 있어서 이 에이전트를 호출하는 사용자의 대신 작업을 수행합니다.
- 특정 도구(예: 트위터)에서는 고정된 자격 증명 세트를 사용하며, 이 경우는 우리 회사의 트위터 계정에 해당합니다. 하지만 방문자 목록에 등재된 사용자만이 특정 작업을 수행할 수 있습니다. 예를 들어 모든 사람이 트위터에 게시할 수 있는 것은 아닙니다(그들은 읽기/작성만 가능할 수 있습니다).
문제: 메모리
모든 에이전트는 두 단계의 메모리를 가지고 있습니다:
- 글로벌 메모리: 모든 사용자에게 적용되는 메모리
- 사용자 메모리: 특정 사용자에게만 적용되는 메모리
에이전트들은 어떤 사실들을 어떤 기억 수준에 저장할지 결정한다.
이곳은 아마 지금까지 가장 잘 연구되지 않은 지역일 것입니다 - 우리는 여기서 많은 일을 해야 합니다!
문제: 코드 실행
우리의 세 에이전트 모두 코드를 작성하고 실행할 수 있으며, 작업을 완료하기 위해 종종 그렇게 해야 합니다. 그들은 모두 샌드박스 외부에서 실행하는 패턴을 따르지만, 샌드박스에 연결하여 그 안에서 코드를 실행합니다. 각각은 다른 종속성과 함께 약간 다른 기본 이미지를 가지고 있습니다. OpenSWE(코딩과 관련된 에이전트)는 어떤 기본 이미지를 시작하는지에 대해 똑똑하며, 이는 채널/사용자에 따라 다릅니다. 모든 에이전트는 비밀 프록시를 LangSmith Sandboxes에서 활용하여, 샌드박스 내부에서 안전하고 보안적인 방식으로 서비스에 연결할 수 있습니다. (자세한 내용은 Managed Deep Agents에 샌드박스를 추가하기를 참조하세요.)
문제: 예정된 실행
대부분의 실행은 사용자가 직접 시작하는 것이 아니라, 이벤트에 의해 백그라운드에서 예약되거나 트리거됩니다.
이 중 일부는 에이전트의 개발자가 설정합니다. 예를 들어, OpenSWE는 PR을 듣고 새로운 PR이 생성될 때 그를 검토합니다.
다른 경우들은 사용자가 에이전트에게 그렇게 하도록 요청함으로써 설정됩니다. 예를 들어, 저는 GTM 에이전트에게 일일 요약을 보내도록 요청했고, 에이전트는 자체적으로 cron를 만들어 그렇게 했습니다.
모든 것은 관리되는 깊은 에이전트를 기반으로 구축됩니다
이 모든 에이전트는 관리형 깊은 에이전트를 기반으로 구축되며, 이는 오픈소스 깊은 에이전트 인프라 위에 구축됩니다. 이를 통해 채널, 크론, 샌드박스, 메모리, 신원과 같은 모든 문제를 해결할 수 있는 인프라가 제공되며, 필요에 따라 에이전트의 동작을 맞춤화할 수 있는 충분한 유연성도 제공됩니다. 오늘 빠른 시작을 통해 직접 시도해 보세요!