제가 이 주장을 끝까지 고수할 의향이 있을지는 모르겠지만, 어쩌면 그다지 논란이 될 만한 의견도 아닐 수 있습니다만… 1. 대부분의 경우 에이전트는 워크플로를 찾는 메커니즘으로만 사용해야 합니다. True ASI는 모든 작업에 적합한 워크플로 생성기입니다. 2. 제 에이전트나 제 두뇌가 작업에 대한 좋은 워크플로(즉, 대략적으로 작동하는 일련의 단계)를 발견하면, 제가 거의 항상 원하는 것은 모호성을 처리하기 위해 ✨에이전트적인 요소✨를 약간 가미한 워크플로입니다(예: 노드가 에이전트일 수 있음). 그렇게 하면 안정성이 높아지고 저는 그게 좋거든요. 여러분도 아마 그럴 거예요. 3. 대부분의 문제는 워크플로로 표현할 수 있지만, 에이전트의 사용자 경험(UX)은 훨씬 더 좋습니다. 저는 "이것을 하고, 저것을 하고, 이것을 확인하고, 다시 저것으로 돌아가세요..."와 같이 자연어로 워크플로를 안내하기만 하면 됩니다. 4. 상담원 성능/안정성 향상의 상당 부분은 기본적으로 상담원들이 수행해야 할 단계를 명확히 하고 특정 작업을 순서대로 수행하는지 확인하는 "워크플로우화"를 통해 이루어집니다. 이를 "자신의 경험과 지식을 문제에 적용하는 것"이라고도 부를 수 있습니다. 기본적으로 이는 엄청나게 많은 유용한 경제적 작업이 무한정으로 정해져 있는 것이 아니라, 대략적으로 따라야 할 몇 가지 단계가 있으므로 문제를 그런 식으로 모델링해야 한다는 사실로 귀결됩니다. 에이전트는 진정으로 무한정으로 정해져 있는 문제를 처리하는 가장 좋은 방법이지만, 그렇더라도 문제에 대한 사전 정보가 있다면 워크플로에 반영해야 합니다. "근데 잠깐, 너 맨날 에이전트 얘기만 지껄이잖아?" 🤬 맞아요… 상담원들은 작고 범위가 명확한 작업을 처리하는 데 있어 정말 훌륭한 "연결 고리" 역할을 하죠. 상담원들이 잘 정의된 작은 작업들을 처리하는 데 탁월하고, 이제는 별도의 도움 없이도 중간 규모의 작업까지 훨씬 더 잘 처리한다는 점에는 우리 모두 동의할 거라고 생각해요. 저는 상담원들의 사용자 경험(UX)이 너무 좋아서 Opus 4.5를 매일 사용하고 있는데, 이게 바로 Opus 4.5를 비판하는 게 아니라 잘 작동하는 부분을 이야기하는 것뿐이에요. 상담원들은 워크플로우를 발견하는 데에도 탁월한 능력을 발휘합니다. 때로는 무엇이 효과적인지 정확히 모르는 경우가 있는데, 상담원들이 다양한 시도를 해보도록 하고, 그 데이터를 저장하고 분석하여 무엇이 효과적인지 찾아내고, 이를 바탕으로 더욱 체계적인 워크플로우를 구축할 수 있도록 도와줍니다. 좋아요, 그럼 푸념은 끝났네요. 주로 에이전트의 안정성이 워크플로우화와 어떻게 연결되는지, 그리고 그것이 에이전트를 구축하는 우리 모두에게 어떤 의미를 갖는지에 대한 관찰을 이야기한 거예요.
이전에 이 주제에 대해 글을 썼었는데, 아직 완전히 옳은 생각인지는 확신이 서지 않지만, 틀린 말보다는 맞는 말이 더 많은 것 같다는 생각이 듭니다. https://t.co/FGBWhXiJUz