LLM 에이전트 자세히¶

LLM과 에이전트가 큰 그림이었다면, 여기는 툴콜 한 번의 실제 모습입니다.

툴콜 해부¶

모델은 툴 스키마(이름·설명·JSON 파라미터)를 받습니다:

{ "name": "drive",
  "description": "로봇을 주행시킨다.",
  "parameters": { "speed": "number 0..1", "seconds": "number" } }

행동을 결정하면 구조화된 호출을 내놓고 — drive(speed=0.3, seconds=2) — 런타임이 실행하고, 결과 텍스트가 대화에 되돌아옵니다. 마치 세계가 말한 것처럼. 모델은 그걸 읽고 이어갑니다.

설명이 곧 프롬프트다. 모델은 설명을 읽고 툴을 고릅니다 — 설명이 두루뭉술하면 잘못 부르거나 못 부릅니다. 하는 일 그대로 이름 짓고 설명하세요.
결과가 에이전트의 유일한 감각이다. 짧고 정보 밀도 높은 결과를 반환하세요 ("0.5m 이동, 0.3m 앞 장애물") — 로그 폭포는 신호를 익사시킵니다.
에러도 정상 입력이다. 좋은 에이전트는 에러를 읽고 적응하고, 좋은 툴은 죽는 대신 읽을 수 있는 에러 텍스트를 반환합니다.
순서가 보장된다. 한 턴의 호출들은 차례로 실행됩니다 — "주행하고 나서 촬영"을 한 번에 요청해도 안전합니다.

대화 자체가 에이전트의 기억입니다: 이전 결과, 내 정정, 자기 계획. 상시 규칙은 (항상 존재하는) instructions가 (스크롤로 밀려나는) 채팅 요청을 이기는 이유이고, 채팅을 비우면 행동이 리셋되는 이유입니다.