SymmACP는 Zed의 Agent Client Protocol을 확장해 프록시와 레이어링으로 조합 가능한 에이전트/도구 생태계를 만들자는 제안이다. 시간 인지, 퍼소나 주입, 비동기 작업, tangent 모드, 인터랙티브 워크스루, 더 똑똑한 도구 위임 등 사례로 동작 방식을 설명한다.
이 글은 SymmACP – Zed의 Agent Client Protocol(ACP)을 확장해 유닉스 파이프나 브라우저 확장처럼 AI 도구를 만들 수 있게 하자는 제안을 설명합니다. 더 나은 TUI가 필요하신가요? GitHub에서 멋진 슬래시 명령을 찾으셨나요? 다른 백엔드를 선호하시나요? SymmACP를 사용하면 이러한 조각들을 서로를 몰라도 섞어 쓰고 함께 작동하게 할 수 있습니다.
지금의 AI 도구 동작 방식과는 꽤 다릅니다. 오늘날에는 모든 것이 모놀리식이라 한 부분을 바꾸려면 전부를 처음부터 다시 만들어야 하죠. SymmACP는 계층화되고 상호 운용 가능한 방식으로 새로운 기능과 상호작용 모드를 확장할 수 있게 해줍니다. 이 글은 일련의 예시를 통해 SymmACP가 어떻게 동작할지 설명합니다.
지금 SymmACP는 생각 실험에 가깝습니다. 이 아이디어를 Zed 팀에 개략적으로 전달했고 흥미를 보였지만, 여기서 다루는 세부사항은 아직 더 논의해야 합니다. 제 계획은 Symposium에서 프로토타입을 시작하는 것입니다 — 여기서 이야기하는 아이디어가 흥미롭다면 Symposium Zulip에 합류해 함께 이야기해요!
“조합형 에이전트”라는 개념을 일련의 기능을 통해 설명해 보겠습니다. 기본적인 CLI 에이전트1 도구에서 시작하죠 — 대략 파일 읽기/쓰기와 bash 실행 같은 MCP 서버에 접근할 수 있는 채팅 루프입니다. 그런 다음 이 위에 여러 기능을 얹어 보겠습니다:
/tangent 모드처럼, 나중에 기록에서 제거되는 “장부 밖” 작업을 잠깐 하는 모드.이 모든 기능은 각각 별도 저장소로 개발된다는 점이 핵심입니다. 게다가 SymmACP만 말할 줄 안다면 어떤 베이스 도구에도 적용할 수 있습니다. 또한 TUI, 웹 프런트엔드, Zed나 IntelliJ의 내장 지원 등 다양한 프런트엔드와도 조합할 수 있죠. 꽤 멋집니다.
가능하다면 SymmACP(또는 그와 유사한 것)로 표준을 맞춰 각자 고유 도구를 따로 만드는 시대에서 서로의 아이디어를 이어받아 발전시키는 상호 운용 가능한 생태계로 가고 싶습니다.
SymmACP는 ACP에서 시작하므로, 먼저 ACP가 무엇인지 설명하죠. ACP는 CLI 에이전트를 추상화할 수 있게 해주는 아주 단순한 프로토콜입니다. 터미널을 통해 소통하는 대신, CLI 도구가 stdin/stdout을 통해 보내는 JSON-RPC 메시지로 프런트엔드와 통신한다고 상상해 보세요.
flowchart LR Editor <-.->|JSON-RPC via stdin/stdout| Agent[CLI Agent]
GUI에 무언가를 입력하면, 에디터는 입력한 내용을 담아 에이전트에게 JSON-RPC 메시지를 보냅니다. 에이전트는 텍스트와 이미지를 담은 메시지 스트림으로 응답합니다. 에이전트가 도구를 호출하기로 하면, 에디터에 JSON-RPC 메시지를 보내 권한을 요청할 수 있습니다. 에이전트가 완료되면, “이제 당신이 다른 것을 입력해도 돼요”라는 의미로 에디터에 “end turn” 메시지로 응답합니다.
sequenceDiagram participant E as Editor participant A as Agent participant T as Tool (MCP)
E->>A: prompt("Help me debug this code")
A->>E: request_permission("Read file main.rs")
E->>A: permission_granted
A->>T: read_file("main.rs")
T->>A: file_contents
A->>E: text_chunk("I can see the issue...")
A->>E: text_chunk("The problem is on line 42...")
A->>E: end_turn
첫 번째 기능으로 가봅시다. CLI 에이전트를 써 보신 분들은 아마 그들이 지금이 몇 시 — 심지어 몇 년도인지 — 도 모른다는 걸 느끼셨을 겁니다. 사소해 보이지만 실제로는 큰 실수를 유발할 수 있어요. 예컨대 어떤 정보가 구식이라는 걸 눈치채지 못할 수 있습니다. 또는 웹 검색 시 엉뚱한 연도를 찾습니다. 2025년인데도 CLI 에이전트가 “2024년의 API 업데이트”를 검색하는 걸 본 적이 있어요.
이를 고치기 위해 많은 CLI 에이전트는 프롬프트에 <current-date date="2025-10-08" time="HH:MM:SS"/> 같은 텍스트를 추가로 주입합니다. LLM에 필요한 컨텍스트를 주는 것이죠.
ACP로 어떻게 만들 수 있을까요? 해법은 “프록시”를 만드는 것입니다. 이 프록시는 원래의 ACP 서버를 감쌉니다:
flowchart LR Editor[Editor/VSCode] <-->|ACP| Proxy[Datetime Proxy] <-->|ACP| Agent[CLI Agent]
이 프록시는 전달받는 모든 “prompt” 메시지에 날짜와 시간을 덧붙여 전달합니다:
sequenceDiagram participant E as Editor participant P as Proxy participant A as Agent
E->>P: prompt("What day is it?")
P->>A: prompt("<current-date .../> What day is it?")
A->>P: text_chunk("It is 2025-10-08.")
P->>E: text_chunk("It is 2025-10-08.")
A->>P: end_turn
P->>E: end_turn
간단하죠? 물론 어떤 에디터, 어떤 ACP 도구와도 함께 쓸 수 있습니다.
ACP에서 자연스럽게 나오는 또 다른 기능은 퍼소나 주입입니다. 대부분의 에이전트는 다양한 방식으로 “컨텍스트”를 구성할 수 있게 해주는데, Claude Code는 이를 memory라고 부르죠. 유용하긴 한데, 저와 다른 분들이 느끼기에는 Claude의 “행동” — 이를테면 더 협업적으로 만들기 — 을 바꾸려면 이것만으로 충분치 않은 경우가 많습니다. 대화를 시작할 때부터 그 패턴을 강화해야 하거든요.
Symposium에서는 “yiasou” 프롬프트 (그리스어가 편치 않다면 “hi”도 됩니다 😛)를 대화의 첫 메시지로 실행하도록 되어 있습니다. 하지만 MCP 서버 입장에서는 사용자가 반드시 처음에 /symposium:hi 같은 걸로 대화를 시작하도록 “보장”할 방법이 없습니다. 물론 Symposium이 ACP 서버로 구현되어 있었다면, 충분히 가능했죠:
sequenceDiagram participant E as Editor participant P as Proxy participant A as Agent
E->>P: prompt("I'd like to work on my document")
P->>A: prompt("/symposium:hi")
A->>P: end_turn
P->>A: prompt("I'd like to work on my document")
A->>P: text_chunk("Sure! What document is that?")
P->>E: text_chunk("Sure! What document is that?")
A->>P: end_turn
P->>E: end_turn
일부는 “흠, 그게 hooks의 용도 아닌가요?”라고 생각하실 수 있습니다. 맞습니다, 훅으로도 비슷한 걸 할 수 있습니다. 하지만 두 가지 문제가 있죠. 첫째, 훅은 비표준이라 에이전트마다 방식이 제각각입니다.
둘째, 훅은 설계자가 상정한 범위로만 작동한다는 근본적인 한계가 있습니다. 훅은 도구가 제공하는 특정 위치에서만 걸 수 있고, 제어 범위도 도구가 허용하는 것에 국한됩니다. 다음 기능을 보면 제 말이 무슨 뜻인지 드러납니다. 제가 원하는 방식으로는, 훅으로 간단히 구현하기 어렵다고 알고 있어요.
다음은 장시간 실행되는 비동기 작업입니다. 이 기능은 현재 ACP의 능력을 넘어서는 “SymmACP” 확장 기능을 필요로 합니다.
현재는 서버가 MCP 도구를 호출하면 블로킹 방식으로 실행됩니다. 하지만 때로는 수행하는 작업이 길고 복잡합니다. 바람직한 것은 작업을 “시작”만 해두고 다시 다른 일을 하도록 돌아가는 것입니다. 작업이 완료되면, 사용자(와 에이전트)에게 알림이 오고요.
저는 “딥 리서치”에서 이런 상황을 자주 겪습니다. 뭔가 이해가 안 되는 지점에 막히면, 웹을 샅샅이 뒤지는 리서치 에이전트를 돌립니다. 보통은 같이 협업하던 에이전트에게 우리가 시도한 것, 부딪힌 장애물, 관련한 세부사항을 요약해 리서치 프롬프트를 만들어달라고 부탁합니다. 그런 다음 claude.ai나 Gemini Deep Research에 가서 그 프롬프트를 붙여 넣습니다. 그러면 5~10분 동안 돌아가고 마크다운 보고서를 만들어 주죠. 그 파일을 내려받아 제 에이전트에게 건넵니다. 이 과정이 문제를 해결하는 데 아주 자주 도움이 됩니다.2
이 리서치 흐름은 잘 작동하지만, 번거롭고 복사/붙여넣기를 필요로 합니다. 이상적으로는 MCP 도구가 알아서 검색을 수행한 뒤, 결과가 나오면 에이전트에게 넘겨 즉시 처리하게 만들고 싶습니다. 그동안에는 에이전트와 계속 작업을 이어가고 싶고요. 하지만 현재 도구 프로토콜에는, 제가 아는 한, 이런 비동기 알림을 보낼 메커니즘이 없습니다.
그렇다면 SymmACP에서는 어떻게 할까요? 현재 ACP를 다음 두 가지로 확장하고 싶습니다:
이렇게 하면 Research Proxy를 다음처럼 구현할 수 있습니다:
sequenceDiagram participant E as Editor participant P as Proxy participant A as Agent
E->>P: prompt("Why is Rust so great?")
P->>A: prompt("Why is Rust so great?")
A->>P: invoke tool("begin_research")
activate P
P->>A: ok
A->>P: "I'm looking into it!"
P->>E: "I'm looking into it!"
A->>P: end_turn
P->>E: end_turn
Note over E,A: 시간이 흐릅니다(5~10분). 사용자는 계속 작업을 이어갑니다...
Note over P: 백그라운드에서 리서치가 완료됩니다
P->>A: <research-complete/>
deactivate P
A->>P: "Research says Rust is fast"
P->>E: "Research says Rust is fast"
A->>P: end_turn
P->>E: end_turn
멋진 점은 프록시가 전체 흐름을 캡슐화한다는 것입니다. 프록시는 리서치를 수행하는 법을 알고, 리서치가 완료되면 각 참여자에게 알리는 것까지 관리합니다. (또한 이것은 제가 생략했던 한 가지 세부에 기대고 있습니다. 그건 )
다음으로 Q CLI의 /tangent 모드를 살펴보죠. 이 기능은 히스토리를 편집하는 간단하지만(그리고 유용한!) 예시입니다. /tangent를 처음 입력하면 Q CLI는 현재 상태를 저장합니다. 그다음은 평소처럼 계속 진행하다가, 다시 /tangent를 입력하면 그 지점의 상태로 복원됩니다. 이름에서 알 수 있듯, 메인 컨텍스트를 오염시키지 않고 곁다리 대화를 탐색할 수 있게 해줍니다.
SymmACP에서 tangent를 지원하는 기본 아이디어는 프록시가 (a) tangent 프롬프트를 가로채 시작 지점을 기억하고, (b) 대화를 평소처럼 진행시키며, (c) tangent를 끝낼 때가 오면 새 세션을 만들어 tangent가 시작되기 전까지의 히스토리를 재생하는 것입니다3.
거의 ACP만으로도 “tangent”를 구현할 수 있지만 완전히는 아닙니다. ACP에서는 에이전트가 항상 세션 히스토리의 소유자입니다. 에디터는 새 세션을 만들거나 지난 세션을 불러올 수 있습니다. 지난 세션을 불러올 때는 에이전트가 이벤트를 “재생”해 에디터가 GUI를 재구성할 수 있게 합니다. 하지만 _에디터_가 세션을 _에이전트_에게 “재생”하거나 구성할 방법은 없습니다. 에디터는 오직 프롬프트를 보내 에이전트가 응답하게 할 뿐입니다. 이번 경우에는 “내가 이렇게 말했고 네가 저렇게 답한” 상태로 새로운 채팅을 만들 수 있어야 초기 상태를 설정할 수 있습니다. 그래야 이전 세션의 메시지를 담은 새로운 세션을 쉽게 만들 수 있죠.
작동 방식은 아래와 같습니다:
sequenceDiagram participant E as Editor participant P as Proxy participant A as Agent
E->>P: prompt("Hi there!")
P->>A: prompt("Hi there!")
Note over E,A: 대화가 진행됩니다
E->>P: prompt("/tangent")
Note over P: 프록시가 대화 상태를 기록합니다
P->>E: end_turn
E->>P: prompt("btw, ...")
P->>A: prompt("btw, ...")
Note over E,A: 대화가 진행됩니다
E->>P: prompt("/tangent")
P->>A: new_session
P->>A: prompt("Hi there!")
Note over P,A: ...프록시가 대화를 재생합니다...
Symposium의 멋진 기능 중 하나가 인터랙티브 워크스루입니다. 이는 HTML 사이드바와 코드 내 인라인 코멘트로 구성됩니다:
현재는 꽤 즉흥적인 방식으로 구현되어 있습니다:
작동은 하지만, 거대한 골드버그 머신 같죠.
SymmACP에서는 이 전달 메커니즘을 프록시로 구조화하겠습니다. 현재와 마찬가지로, 프록시는 에이전트로부터 워크스루 마크다운을 받는 MCP 도구를 제공합니다. 그런 다음 사이드에 표시할 HTML과 코드에 삽입할 각종 코멘트로 변환합니다. 하지만 여기서부터가 다릅니다.
IPC로 그 내용을 보내는 대신, 프록시가 채팅과 함께 추가 정보를 전달할 수 있게 만들고 싶습니다. ACP는 다양한 capability를 제공하므로 비교적 쉽게 할 수 있지만, 저는 한 발 더 나가고 싶습니다.
저는 워크스루를 관리하는 프록시 레이어를 두고자 합니다. 앞서 본 것처럼 도구를 제공합니다. 그런데 한 가지가 더 있습니다. 단순한 채팅 히스토리 너머로, 추가 상태를 전달할 수 있다는 점입니다. 기본 대화 구조는 대략 다음과 같다고 생각합니다:
하지만 (a) 그 어느 것에나 메타데이터를 첨부할 수 있으면 좋겠고 — 예컨대 _대화 전체_나 특정 턴 (심지어 특정 프롬프트)에 관한 추가 문맥 — (b) 추가적인 이벤트 종류도 있으면 좋겠습니다. 예를 들어, 도구 승인 자체가 하나의 _이벤트_입니다. 워크스루를 표시하고 주석을 추가하는 것도 이벤트이고요.
제가 상상하는 SymmACP의 핵심 중 하나는 자신의 상태를 JSON으로 직렬화할 수 있는 능력입니다. SymmACP 참여자에게 세션 요약을 요청할 수 있습니다. 그러면 각 참여자는 자신이 위임한 구성요소들에게 요약을 요청해 받은 뒤, 자신만의 메타데이터를 덧붙입니다. 또한 요청을 _반대 방향_으로도 보낼 수 있습니다 — 예컨대 에이전트가 자신의 상태를 에디터에게 제시하고 보강을 요청하는 식입니다.
이렇게 하면, 워크스루 프록시는 대화 기록에 “현재 워크스루”와 “현재 적용된 코멘트” 같은 추가 메타데이터를 더할 수 있습니다. 그러면 _에디터_는 그 메타데이터를 알 수도 있고 모를 수도 있습니다. 모른다면 채팅에서 보이지 않겠죠. 어쩔 수 없습니다 — 혹은 HTML처럼 “우아한 강등(degrade gracefully)”을 지원할 수도 있습니다(예: 워크스루를 일반 “응답”으로도 제시하되, 아는 사람이 보면 다르게 해석해야 한다는 메타데이터를 덧붙임). 하지만 에디터가 그 메타데이터를 “안다면”, 특별히 해석해 패널에 워크스루를 띄우고 코드에 코멘트를 추가합니다.
이처럼 풍부해진 히스토리를 갖추면, SymmACP에서는 세션의 로드/저장/영속화 능력 _자체_도 하나의 확장으로 볼 수 있습니다. 즉, 프록시가 구현할 수 있는 기능이고, 베이스 프로토콜은 대화의 수행과 직렬화만 다루면 됩니다.
꽤 멋질 것 같아 오래 구상해 온 기능을 하나 더 스케치해 보겠습니다. MCP 도구가 너무 많으면 LLM이 혼란스러워진다는 건 잘 알려진 문제입니다. 산만해지죠. 이해할 만한 일입니다. 저라도 무언가를 해결하라고 수첩만 한 분량의 명령 목록을 받아들면 무시하고 말 겁니다.
하지만 사람은 어떻게 하죠? 전체 전화번호부를 보지 않습니다 — 더 짧은 카테고리 목록을 보고, 거기서 파고듭니다. 저는 파일 메뉴에 먼저 가서, 그 다음에 상세 목록을 보죠. 납작한 명령 목록이 아니라요.
현대 IDE가 “할 수 있는” 일은 수없이 많습니다. 참조 찾기, 정의 찾기, 타입 힌트, 리네임, 메서드 추출 등. 심지어 확장 기능이 자기들만의 명령을 제공할 수도 있어 목록은 열려 있습니다. 그 모든 걸 다 알지는 못하지만, IDE가 할 _종류_는 감으로 압니다 — 모델도 그럴 거라 생각합니다.
그렇다면 “IDE operation”이라는 단일 도구를 주고, 평범한 영어로 원하는 바를 묘사하게 하면 어떨까요? 예: ide_operation("find definition for the ProxyHandler that referes to HTTP proxies"). 음, 이건 꽤 대리인(delegate) 또는 서브 에이전트와 닮았습니다. 이제 그 요청을 해석할 두 번째 LLM이 필요하거든요 — 아마도 제안된 IDE 기능 목록과 상세를 탐색하는 방법을 제공해, 계획을 세우게 하거나(혹은 직접 도구를 실행하게 하거나) 해서 답을 찾게 해야 할 겁니다.
마침 MCP에는 도구가 이런 일을 하도록 해주는 기능이 있습니다 — 제 생각엔 이름이 좀 생뚱맞지만 — “샘플링(sampling)”입니다. MCP 도구에서 LLM으로 “콜백”을 할 수 있게 해줍니다. 하지만 제가 보기엔 구현한 곳이 거의 없습니다.4 게다가 샘플링은 한계가 있죠. SymmACP에서는 훨씬 더 흥미로운 일을 할 수 있다고 봅니다.
핵심은 ACP가 이미 하나의 에이전트가 여러 세션을 “동시에 제공”할 수 있게 해준다는 것입니다. 그러니 만약 제가 프록시 — 이를테면 MCP 도구 정의를 제공하는 프록시 — 를 갖고 있다면, 이를 사용해 새로운 세션을 시작할 수 있습니다. 여기에 위에서 말한 “히스토리 재생” 능력을 결합하면, 도구가 그 세션을 시작할 때 어떤 컨텍스트를 가져올지도 정밀하게 제어할 수 있습니다. 아주 멋지죠(이건 MCP 서버가 오늘날 겪는 어려움인데, 그들은 대화 히스토리에 접근할 수 없거든요).
sequenceDiagram participant E as Editor participant P as Proxy participant A as Agent
A->>P: ide_operation("...")
activate P
P->>A: new_session
activate P
activate A
P->>A: prompt("Using these primitive operations, suggest a way to do '...'")
A->>P: ...
A->>P: end_turn
deactivate P
deactivate A
Note over P: 계획을 수행함
P->>A: result from tool
deactivate P
정리하면, 이 글은 제가 SymmACP라고 부르는 ACP의 변형을 스케치했습니다. SymmACP는 ACP를 다음으로 확장합니다:
제 생각에 대부분은 ACP에 대한 소박한 확장이고, 새로운 capability를 추가하는 식으로 역호환되게 쉽게 구현할 수 있습니다. 하지만 이 모든 게 합쳐지면, 누구나 에이전트의 확장을 만들어 조합 가능한 방식으로 배포할 수 있게 됩니다. 저는 이 점이 무척 신납니다. 이것이야말로 제가 Symposium에서 이루고자 했던 바입니다.
물론 “큰 힘에는 큰 책임이 따른다”는 격언도 있습니다. 제가 이야기한 프록시와 ACP 레이어는 사실상 IDE 확장과 같습니다. 사용자가 할 수 있는 일을 사실상 무엇이든 대신할 수 있죠. 보안 우려가 뚜렷합니다. 다만 Microsoft의 Wassette 같은 접근이 핵심이라 봅니다 — 모든 것이 WASM으로 컴파일되고, 사용자가 특정 프록시가 실제로 무엇을 할 수 있는지 조절할 수 있는, “능력 기반(capability-based)” 프록시 레이어 개념이 있으면 정말 좋겠습니다.
저는 Symposium과 그 외 곳에서 이를 추진할 계획을 그려 나가려 합니다. 목표는 완전히 오픈이고 상호운용 가능한 클라이언트를 갖추는 것이며, 어떤 에이전트(로컬 에이전트 포함)를 기반으로 하든, 원하는 부분만 골라 쓸 수 있게 하는 것입니다. 러스트 개발을 지원하기 위한 맞춤 기능(예: 새 트레잇 솔버를 이용해 트레잇 오류를 설명/진단하는 것, 그리고 매크로 오류…)도 많이 만들겠지만, 워크스루, 협업형 상호작용 스타일 등 언어에 독립적인 기능도 함께 갖추고 싶습니다 — 그리고 다른 언어, 특히 Python과 TypeScript(왜냐하면 “새 삼위일체”)와 Swift, Kotlin(왜냐하면 모바일) 같은 언어를 위한 기능도 보고 싶어요. 이 비전이 마음에 든다면 Symposium Zulip에 오셔서 이야기 나눠요!
이 주제를 논의할 때 종종 받는 질문이 다른 여러 프로토콜과의 비교입니다. 관련 작업을 간단히 개관하고 제가 이해하는 장단점을 정리해 보겠습니다:
Model context protocol (MCP): 이 분야의 여왕. 에이전트가 사용할 도구, 프롬프트, 리소스를 제공하는 프로토콜입니다. 에이전트는 JSON 파라미터를 제공해 도구를 호출할 수 있습니다. 프롬프트는 사용자가 /나 @ 같은 특수 명령으로 호출하는 지름길로, 본질적으로 “사용자가 입력한 것처럼” 확장되는 매크로입니다(파라미터를 가질 수 있고 동적으로 구성될 수도 있습니다). _리소스_는 요청할 수 있는 데이터입니다. MCP 서버는 로컬일 수도 원격 호스팅일 수도 있습니다. 원격 MCP는 최근에야 가능해졌고, 특히 인증은 아직 제한적입니다.
Zed의 Agent Client Protocol (ACP): SymmACP의 기반. 에디터가 세션을 생성/관리하도록 합니다. 에디터가 로컬에서 실행되므로 로컬 세션에만 초점을 둡니다.
Google의 Agent-to-Agent Protocol (A2A)과 IBM의 Agent Communication Protocol (ACP)5: 제가 보기엔 구글의 “에이전트-대-에이전트” 프로토콜은 MCP와 OpenAPI의 혼합과 비슷합니다. 원격에서 실행 중인 에이전트에 핑을 보내 “에이전트 카드”를 받아올 수 있습니다. 거기에는 수행 가능한 작업, 인증 방법, 그 밖의 정보가 기술됩니다. MCP와 꽤 유사해 보이지만 원격 실행을 더 풍부하게 지원하고, 특히 웹훅으로 한동안 작업한 뒤 다시 콜백하는 식의 장기 커뮤니케이션을 지원합니다.
모두가 각자 방식으로 에이전트를 씁니다. 저는 Simon Willison의 “에이전트는 모델이 도구를 루프에서 사용하는 것”이라는 정의를 좋아합니다. “에이전틱 CLI 도구”는 그 정의에 부합한다고 느낍니다. 단지 루프의 일부가 사용자 입력을 읽는다는 점만 다르죠. “완전 자율” 에이전트는 에이전트의 부분집합이라고 생각합니다 — 많은 에이전트 프로세스는 도구 등을 통해 외부 세계와 상호작용합니다. 어떤 관점에서는, 에이전트가 “턴을 끝낸다”는 건 “다음 프롬프트를 주세요”라는 도구를 호출하는 것으로 볼 수도 있습니다.↩︎
리서치 보고서는 제가 환각을 피하는 데 큰 역할을 합니다. 언어 서버 프로토콜(LSP) 상세에 대해 의뢰했던 보고서 예시를 보실 수 있습니다. LSP에 대한 상세 지식이 필요한 일을 시작하려 한다면, 먼저 그 보고서를 읽어보라고 에이전트에게 요청할 겁니다.↩︎
다른 방법으로는: 세션 히스토리를 비우고 다시 구성하는 방법도 있습니다. 하지만 저는 주어진 세션은 변하지 않는다는 함수형 관점을 더 선호합니다.↩︎
Q CLI를 위한 구현을 시작했지만, 분산되었습니다 — 그리고 이유는 명백하듯, 점점 흥미를 잃어가고 있습니다.↩︎
맞습니다, 제대로 보셨습니다. 또 다른 ACP가 있습니다. 구글 검색하면 좀 헷갈리죠. =)↩︎