AI 에이전트 생태계에서 아직 부족한 점은 무엇이라고 생각하시나요?

지루하게 들릴지 모르겠지만, 정책 훅이 포함된 재현 가능한 실행 원장이 필요하다고 봅니다.

데모에서는 보통 가시성(observability)이 트레이싱을 의미하지만, 운영 환경에서는 질문이 더 실무적입니다:

• 어떤 사용자/요청이 이 실행을 유발했는가?
• 어떤 모델, 프롬프트 버전, 도구 스키마, 메모리 스냅샷, 검색 결과, 설정 버전이 사용되었는가?
• 재시도와 실패한 도구 호출을 포함해 각 단계의 비용은 얼마인가?
• 어떤 정책이 해당 동작을 허용했고, 무엇이 차단했을 것인가?
• 동일한 실행을 다시 재현할 수 있는가?

정말 깊이 있는 분석이네요. 특히 가시성, 거버넌스, 비용 추적, 평가를 별개의 문제로 다루지 않고 재현 가능한 실행 원장을 공통 기반으로 사용한다는 아이디어가 인상적입니다.

드라이런/재현 모드가 눈에 띄네요. 프롬프트를 반복 수정하거나 모델을 교체할 때 팀에서 끊임없이 사용할 기능 같습니다.

혹시 이런 걸 내부적으로 직접 구축하셨나요, 아니면 기존 도구들이 이런 아키텍처를 지원했으면 하는 건가요?

또한, 어디...

방금 네가 나열한 것들 전부 observability tools(예: langsmith)로 다 가능한 것들임

진단 도구

마커 접근 방식은 영리하네요. 본질적으로 우리가 '구조적 트레이스 컨텍스트'라고 부르는 것을 만들고 계신 건데, 그렇게 간단한 것으로 가치를 얻었다는 사실 자체가 이 문제가 얼마나 해결되지 않았는지를 잘 보여줍니다.

멀티 머신 문제는 정확히 우리가 Cartha에서 작업 중인 내용입니다. 우리는 OTel과는 다른 접근 방식을 취했습니다. 인프라 계층에서 계측하는 대신 에이전트 계층에 위치하죠. 에이전트 코드에 세 줄만 추가하면 모든 실행이 완전한 구조적 트레이스를 갖게 됩니다: 에이전트가 무엇을 하려고 했는지...