Zed, Xanadu의 꿈을 되살리다: 에이전트 시대를 위한 영구적 문서 시스템

흥미롭다. 이 글과 Delta에 대해 본 다른 글들은 그 경계 지대에 존재하는 것 같다. 저자가 아직 같은 통찰을 갖지 못한 사람에게 전달하기 어려운 훌륭한 통찰을 가졌는지, 아니면 단순히 약간 미쳐버렸는지 구분하기 어려운 그런 영역 말이다.

Nelson을 읽을 때도 비슷한 느낌을 받는다(그의 아이디어에 대해 잠시 생각해 본 후, 나는 그것이 대부분 천재적이고 약간의 광기만 섞여 있다고 확신하게 되었다).

Delta가 어떻게 될지는 지켜봐야 한다.

덧붙이자면, 제목에 대한 나의 첫 반응은 '아니, Xanadu에는 에이전트가 빠져 있지 않아'였다.

하지만 저자가 어디로 가는지 알 것 같고, 에이전트가 하이퍼텍스트 아이디어를 촉진할 수 있는 새로운 도구가 될 수 있다는 데 동의하는 것 같다. Xanadu는 아닐지 모르지만, 더 실용적이고 덜 마법적인 다른 장소 - 하지만 지금보다는 조금 더 마법적인 장소일 것이다.

그리고 그것은 우리가 직장에서 시작한 실험과도 약간 교차한다. 우리의 소규모 웹사이트를 WordPress에서 11ty(https://11ty.dev)와 frontmatter cms(https://frontmatter.codes) 및 AI/LLM을 결합한 정적 사이트로 마이그레이션하는 실험이다(우리는 이미 애플리케이션 개발에 TypeScript를 많이 사용하고 있다).

AI는 우리 사이트의 정적 페이지 버전을 만들고 11ty에 적응하는 데 도움을 준다.

아이디어는 간단한 push-to-deploy 설정으로, 우리의 비즈니스 담당자들이 VS Code에서 AI의 도움을 받아 11ty와 git을 직접 사용하여 변경, 검토, 게시를 할 수 있게 하는 것이다.

언덕은 ...

이것은 각 분기점에 하나의 에이전트가 있는 것처럼 들리는데, 각 에이전트는 이전 에이전트와 동일한 모델과 아키텍처를 실행할 수도 있고 아닐 수도 있으며, 서로를 지속적으로 크롤링하거나 단순히 서로를 호출하기 위한 프로토콜이 필요하다.

하지만 그러면 수백만 개의 에이전트가 docuverse 웹을 구성하게 되고, 모든 에이전트가 서로를 알아야 하며 모든 연결과 각각의 데이터베이스 저장소가 필요하다.

글쎄, 존재하는 링크와 생성된 링크만 있으면 된다.

한 단락이 하나의 노드에 존재할 수 있고, 그 노드는 다른 노드들의 집합일 수도 있고, 각 문장이나 각 단어가 다른 노드를 가리킬 수도 있는데, 각 모델은 얼마나 많은 것을 알고 있으며 데이터베이스에 무엇을 유지하는가?

다음 노드에 대한 포인터는 반드시 지속적이거나 버전 관리되는 것은 아니며, 그것이 연결하는 각 노드에도 동일하게 적용된다.

한 단락에는 수천 개 이상의 출처와 참조가 있을 수 있고, 각 출처는 버전 관리가 필요하며 버전에 따라 이전 또는 이후 버전의 다른 노드를 가리킬 수 있다.

단락의 적절한 버전은 이를 알아야 하거나, 에이전트가 있는 모든 노드가 지속적이고 합리적이며 상호 운용 가능할 것이라고 기대해야 한다.

하지만 그 전제 위에 구축하면 현실 세계에서는 작동하지 않을 것이다.

docuverse를 소수의 데이터 저장소와 그 공간적 우주를 이해하는 에이전트로 제한하지 않는 한 말이다. 그것은 일종의 인트라넷 형태이다.

제가 스스로 훈련시키는 가장 좋아하는 LLM 냄새 중 하나는 저자가 겉보기에 서로 관련이 없는 두 아이디어를 설득력 있거나 참신한 무언가로 얼마나 잘 묶는지입니다. 종합이 더 야심 차고 제가 덜 감명받을수록 그것이 적어도 부분적으로 LLM의 작업일 가능성이 더 높다고 가정합니다.

이전에, "Jimi Hendrix Was a Systems Engineer" <https://spectrum.ieee.org/jimi-hendrix-systems-engineer>

Ummet Ozcan - Xanadu: https://www.youtube.com/watch?v=9uMtnH7cABg

그가 에이전트를 기다리고 있다고 생각하지 않습니다.