인공지능 에이전트를 생산에 전달하는 15 가지 원칙 - Stop Prompting, Start Engineering: 15 Principles to Deliver Your AI Agent to Production

Introduction

처음에는 API를 통해 ChatGPT와 의사 소통을 시도하고 몇 줄의 맥락을 던지며 전혀 응답한다는 것에 놀라게됩니다.

이것이 바로 에이전트가 태어나는 방법이다.

지난 1 년 동안 스크립트와 포장기에서 에이전트를 모으고 실험하고 팅링하고 더 깨끗하고 지속 가능한 방법을 찾고 있다면 -이 기사는 당신을위한 것입니다.나는 쿨 아이디어를 생산 준비 솔루션으로 바꾸기위한 핵심 원칙의 집합을 점차적으로 분해했습니다.

이것은 선언문이 아닙니다.이것을 실용적인 속임수 시트로 생각하십시오 - 에이전트를 모래 상자에서 생산에 이끌어 낼 수있는 엔지니어링 원칙의 집합 : 간단한 API 포장부터 안정적이고 제어 가능하며 확장 가능한 시스템에 이르기까지.

Disclaimer

에서이 기사(효율적 인 에이전트를 구축) Anthropic는 에이전트를 LLM이 역동적으로 자신의 프로세스와 도구 사용을 지시하고 작업을 수행하는 방법에 대한 통제력을 유지하는 시스템으로 정의합니다. LLM과 도구가 사전 정의 된 코드 경로를 통해 조정되는 시스템은 Workflows라고합니다.

이 텍스트에서, 에이전트 = 에이전트 시스템, 안정성과 제어를 위해 나는 더 자주 워크플로우를 향해 기울일 것입니다. 나는 가까운 장래에 진화의 1-2 회 더있을 것이고 진정한 에이전트는 보편적 일 것입니다.

1. Design the Foundation

에이전트의 초기 버전은 일반적으로 빨리 합쳐집니다 : 몇 가지 기능, 몇 가지 인스턴스 - 그리고 헤이, 그것은 작동합니다.

에이전트의 초기 버전은 일반적으로 빨리 합쳐집니다 : 몇 가지 기능, 몇 가지 인스턴스 - 그리고 헤이, 그것은 작동합니다.

“If it works, why make it complicated?”

처음에는 모든 것이보이는에이전트는 응답하고, 코드를 실행하고, 합리적으로 행동합니다.그러나 모델을 변경하거나, 시스템을 다시 시작하거나, 새로운 인터페이스를 삽입하면 갑자기 불안정하고, 예측할 수 없으며, 디버그하기 어렵습니다.

그리고 종종 근본적인 원인은 논리나 인스턴스가 아니라 훨씬 이전에 있습니다 : 메모리 관리, 하드 코드 된 직원, 세션을 재개 할 수있는 방법이 없거나 단일 단단한 입력 포인트.

이 섹션은 당신이 견고한 기초를 구축하는 데 도움이되는 네 가지 핵심 원칙을 살펴 봅니다 - 다른 모든 것이 안전하게 성장할 수있는 기초.

1. Keep State Outside

Problem:

1. 에이전트가 중단되면 (사고, 타임 아웃, 무엇이든) 정확히 그가 멈춘 곳을 픽업 할 수 있어야합니다.
2. 재생 가능성은 제한되어 있습니다.당신은 정확하게 일어난 일을 재생할 수있는 방법이 필요합니다 - 테스트, 디버깅 및 기타 이러한 즐거움을 위해.

이것은 엄격히 문제가 아니지만 여전히 :

3. 조만간 당신은 에이전트의 논리를 병행하고 싶을 것입니다.어쩌면 그것은 대화 중간에 여러 옵션을 비교해야합니다 (“이 중 어느 것이 더 좋습니까?”). 어쩌면 당신은 그것을 분할하고 싶어.

(메모리는 완전히 별도의 문제입니다 - 우리는 곧 그것에 도달 할 것입니다.)

Solution:  Move state outside에이전트 - 데이터베이스, 캐시, 스토리지 레이어 - 심지어 JSON 파일이 할 것입니다.

Checklist:

• 에이전트는 모든 단계에서 시작할 수 있으며, 세션 식별자(session_id)와 외부 상태(예를 들어, 데이터베이스 또는 JSON 파일에 저장된 단계)만 있을 수 있습니다.
• 테스트 케이스: 중단된 에이전트는 컨텍스트를 잃지 않으며, 재시작 후 결과는 동일합니다.
• 상태는 기능을 잃지 않고 언제든지 serializable
• 대화의 중간에 여러 인스턴스에 상태를 동시에 제공할 수 있습니다.You can feed the state to multiple instances in parallel in the middle of a dialogue.

2. Make Knowledge External

Problem: LLM은 기억하지 않습니다. 심지어 단일 세션 내에서 모델은 이미 설명 한 것을 잊어 버리고 단계를 혼합하고 대화의 스레드를 잃거나 거기에 없었던 세부 사항을 "충전"하기 시작할 수 있습니다.그리고 시간이 지남에 따라 맥락 창이 점점 커지고 새로운 가능성으로 우리를 기쁘게합니다.LinkedIn은 사람들이 새 모델 버전에 맞는 책이나 YouTube 비디오의 몇 시간을 비교하는 게시물이 가득합니다.그러나 여전히 LLM은 기억하지 않으며 준비해야합니다.

특히 만약 :

• 대화는 길다
• 문서가 넓은
• instructions are complex
• 그리고 토큰은 여전히 무한하지 않다.

컨텍스트 윈도우 (8k, 16k, 128k)의 증가에도 불구하고 문제가 남아 있습니다.

• "중간에 잃어버린" - 모델은 시작과 끝에 더 많은 관심을 기울입니다 (그리고 중간에서 세부 사항을 풀 수 있습니다)
• 비용 - 더 많은 토큰 = 더 많은 돈;
• 그리고 그것은 여전히 적합하지 않습니다.그것은 손실, 왜곡, 또는 환각이있을 것이라는 것을 의미합니다.Transformers가 사각형 복잡성 (O(n2))의 자기주의에 작동하는 한,이 제한은 우리와 함께있을 것입니다.

Solution:클래식 컴퓨팅 시스템과 마찬가지로 "작업 메모리"와 "스토리지"를 분리하여 에이전트는 외부 메모리와 함께 작동할 수 있어야 한다: 모델 외부의 지식을 저장, 검색, 요약하고 업데이트한다.

Approaches

Memory Buffer

쇼핑 최신k messages. Take for quick prototyping.

+간단하고 빠르고 짧은 작업에 충분합니다.

-중요한 정보를 잃고, 규모를 확대하지 않으며, "어제"를 기억하지 못합니다.

Summarization Memory

역사를 더 잘 어울리기 위해

+토큰 절약, 메모리 확장

-왜곡, 뉘앙스의 손실, 다중 단계 압축의 오류

RAG (Retrieval-Augmented Generation)

외부 데이터베이스에서 지식을 추출합니다. 대부분의 시간 당신은 여기에있을 것입니다.

+스케일러, 신선한, 검증

-복잡한 설정, 복구 품질에 민감한, 지연

Knowledge Graphs

항상 우아하고 섹시하며 어렵게, 당신은 어쨌든 RAG를 할 것입니다.

+논리, 설명 가능성, 안정성

-입학의 높은 장벽, LLM 통합의 복잡성

Checklist:

• 모든 대화 기록은 한 곳에서 액세스할 수 있습니다 (프롬프트 외부)
• 지식 소스는 기록되고 재사용될 수 있다.
• 컨텍스트 창을 초과하는 위험없이 역사 스케일

3. Model as a Config

Problem:LLM은 빠르게 진화하고 있습니다; Google, Anthropic, OpenAI 등은 지속적으로 업데이트를 발표하고 서로 다른 벤치마크를 통해 경쟁합니다.이 엔지니어로서 우리를위한 축제입니다.우리의 에이전트는 더 나은 (또는 반대로, 더 저렴한) 모델로 쉽게 전환 할 수 있어야합니다.

Solution:

1. model_id 구성 구현: 사용되는 모델을 지정하기 위해 구성 파일 또는 환경 변수에서 model_id 매개 변수를 사용합니다.Use a model_id parameter in configuration files or environment variables to specify the model being used.
2. Abstract Interfaces: 통합된 API를 통해 모델과 상호 작용하는 인터페이스 또는 wrapper 클래스를 만들 수 있습니다.
3. 중간 소프트웨어 솔루션을 적용하십시오 (조심스럽게 - 우리는 조금 나중에 프레임 워크에 대해 이야기 할 것입니다)

Checklist:

• 모델 교체는 코드의 나머지 부분에 영향을 미치지 않으며 에이전트 기능, 오케스트레이션, 메모리 또는 도구에 영향을 미치지 않습니다.
• 새로운 모델을 추가하는 데는 구성만 필요하며, 선택적으로 어댑터(새로운 모델을 필요한 인터페이스로 가져오는 간단한 레이어)가 필요합니다.
• 모델을 쉽고 빠르게 전환할 수 있습니다. 이상적으로 - 최소한 모든 모델 - 모델 가족 내에서 전환

4. One Agent, Many Interfaces: Be Where the Users Are

Problem:처음에는 에이전트가 하나의 커뮤니케이션 인터페이스 (예를 들어, UI)만을 가질 예정이라 할지라도 Slack, WhatsApp, 또는, 나는 그것을 말하는 것을 감히, SMS를 통해 상호 작용을 추가함으로써 사용자에게 더 많은 유연성과 편의를 제공하고 싶을 것입니다. API는 CLI로 변할 수 있습니다 (또는 디버깅을 위해 하나를 원할 것입니다). 처음부터 디자인에 이것을 구축하십시오.

Solution: Creating a unified input contract: 모든 채널에 대한 보편적 인 인터페이스로 봉사하는 API 또는 다른 메커니즘을 개발합니다.Store channel interaction logic separately.

Checklist:

• Agent is callable from CLI, API, UI

• All input goes through a single endpoint/parser/schema

• All interfaces use the same input format

• No channel contains business logic

• Adding a new channel = only an adapter, no changes to core

  
  

  

  
  

2) 에이전트 행동의 정의

단 하나의 작업이 있지만 모든 것이 간단하지만, AI 전도자들의 게시물처럼, 도구, 의사 결정 논리 및 여러 단계를 추가하면 에이전트가 혼란에 빠집니다.

단 하나의 작업이 있지만 모든 것이 간단하지만, AI 전도자들의 게시물처럼, 도구, 의사 결정 논리 및 여러 단계를 추가하면 에이전트가 혼란에 빠집니다.

그것은 추적을 잃고, 오류에 대해 무엇을해야하는지 알지 못하고, 올바른 도구를 호출하는 것을 잊어 버리고, "좋아, 모든 것이 거기에 기록 된 것처럼 보인다"는 로그로 다시 혼자 남아 있습니다.

이를 방지하기 위해서는 에이전트가 명확한behavioral model: 그것은 무엇을하고, 어떤 도구를 가지고 있으며, 누가 결정을 내리고, 인간이 어떻게 개입하고, 뭔가 잘못 될 때 무엇을해야합니까?

이 섹션은 "모델이 어떻게 든 그것을 파악할 것"을 희망하는 대신 에이전트에게 일관된 행동 전략을 제공하는 데 도움이되는 원칙을 다룹니다.

5. Design for Tool Use

Problem:이 점은 명백한 것처럼 보일 수 있지만 "Plain Prompting + Raw LLM output parsing"에 구축 된 에이전트를 만날 수 있습니다.이것은 무작위 문자열을 끌고 최선을 희망하여 복잡한 메커니즘을 제어하려고 노력하는 것과 같습니다.

• 연약함: LLM 응답 문법의 가장 작은 변화 (단어가 추가되고 문구 순서가 변경됨)는 전체 분석을 깨뜨릴 수 있습니다.이 결과는 귀하의 분석 코드와 모델의 예측 불가능성 사이의 지속적인 "무기 경주"로 이어집니다.
• 인간에게 명백하게 보이는 것은 분석가에게 퍼즐이 될 수 있습니다. "John Smith을 호출하십시오"—당신의 데이터베이스에 있는 세 명의 John Smith 중 누가 있습니까?
• 유지 보수 복잡성: 파싱 코드가 커지고 혼란스럽고 디버그하기 어렵습니다.모든 새로운 에이전트 "능력"은 새로운 파싱 규칙을 작성해야합니다.
• 제한된 기능: 모델이 여러 도구를 신뢰할 수 있게 호출하거나 간단한 텍스트 출력을 통해 복잡한 데이터 구조를 전달하는 것은 어렵습니다.

Solution:모델은 JSON(또는 다른 구조화된 형식)을 반환합니다.The model returns JSON (or another structured format)—the system executes.

여기서 핵심 아이디어는 책임을 버리는 것이다.해석하기사용자 의도 및선택하기LLM에 대한 도구, 여전히 할당하는 동안실행그 의도에서 그시스템명확하게 정의된 인터페이스를 통해

다행히도, 실제로 모든 공급자 (OpenAI, Google, Anthropic, 또는 당신이 선호하는 누군가)는 소위"function calling"또는 엄격하게 정의된 JSON 형식으로 출력을 생성할 수 있습니다.

이것이 어떻게 작동하는지 정리하기 위해 :

1. 도구 설명: 당신은 이름, 설명, 매개 변수와 JSON Schema로 함수를 정의합니다.Description is critically important - the model relies on it.
2. LLM로 전환 : 각 호출에서 모델은 도구 스키마와 함께 인스턴트를 받습니다.
3. Model output: Instead of text, the model returns JSON with:
   • name of the function to call
   • arguments—parameters according to schema
4. 실행: 코드는 JSON을 검증하고 매개 변수를 포함한 적절한 함수를 호출합니다.
5. 모델 응답 (선택 사항): 실행 결과는 최종 응답 생성을 위해 LLM로 돌려줍니다.

Important:도구 설명은 또한 촉구입니다.Unclear description = 잘못된 기능 선택.

What to do without function calling?

If the model doesn't support tool calls or you want to avoid them for some reason:

• 설문지에 JSON을 반환하도록 모델에게 요청하십시오.Be sure to specify the format; you can add examples.
• 응답을 분석하고 Pydantic과 같은 무언가로 검증하십시오.이 접근법의 진정한 팬이 있습니다.

Checklist:

• 응답은 엄격하게 공식화되어 있습니다 (예를 들어, JSON)
• Schemas are used (JSON Schema or Pydantic)
• 기능 호출 전에 적용되는 검증
• 생성 오류가 파열을 일으키지 않습니다 (format error handling exists)
• LLM = function choice, execution = code

6. Own the Control Flow

Problem:일반적으로 에이전트는 "대화"로 작동합니다 - 처음에는 사용자가 말하고, 다음에는 에이전트가 응답합니다.이것은 핑 폰을하는 것과 같습니다 : 히트 응답.

Such an agent cannot:

• 요청없이 스스로 무언가를하십시오.
• 동시에 행동하는 행동
• 사전에 계획하는 단계
• 여러 단계를 연속적으로 수행
• 진행 상황을 확인하고 실패한 단계로 돌아갑니다.

대신 에이전트는 자신의 "실행 흐름"을 관리해야합니다 - 다음으로 무엇을하고 어떻게 할 것인지 결정합니다.이 작업 스케줄러와 같습니다 : 에이전트는해야 할 일을보고 순서대로 단계를 수행합니다.

This means the agent:

• decides when to do something on its own
• can take steps one after another
• 실패한 단계를 회복할 수 있다
• 작업 사이를 전환할 수 있다
• 직접적인 요청 없이도 작동할 수 있습니다.

Solution:LLM이 모든 논리를 통제하도록 허용하는 대신, 우리는control flow모델은 단계 내에서만 도움을 주거나 다음 단계를 제안합니다.이것은 "쓰기 인스턴스"에서 "쓰기 인스턴스"로의 전환입니다engineering a system통제된 행동으로

세 가지 인기있는 접근법을 살펴보자 :

1. FSM (Finite State Machines)

• 그것은 무엇입니까: 작업은 국가와 명확한 전환으로 분할됩니다.
• LLM : 다음 단계를 결정하거나 국가 내에서 행동합니다.
• 장점 : 단순성, 예측 가능성, 선형 시나리오에 적합합니다.
• 도구: StateFlow, YAML 구성, 상태 패턴

2. DAG (Directed Graphs)

• What it is: Non-linear or parallel tasks as a graph: nodes are actions, edges are dependencies.
• LLM : 노드 또는 계획 건설에 도움이 될 수 있습니다.
• 장점 : 유연성, 병렬성, 시각화 가능
• 도구: LangGraph, Trellis, LLMCompiler, 사용자 지정 DAG 차트.

3. Planner + Executor

• 그것은 무엇입니까: LLM은 계획, 코드 또는 다른 에이전트가 그것을 실행합니다.
• LLM : "큰"한 계획, "작은"한 계획을 실행합니다.
• 장점 : 걱정의 분리, 비용 통제, 확장성.
• 도구 : LangChain Plan-and-Execute

Why this matters:

• Increases controllability, reliability, scalability.
• 다양한 모델을 결합하고 실행을 가속화 할 수 있습니다.
• 작업 흐름이 시각화되고 테스트가 가능합니다.Task flow becomes visualizable and testable.

Checklist:

• 명시적인 전환을 가진 FSM, DAG 또는 시나리오를 사용
• 모델은 무엇을 할지 결정하지만 흐름을 제어하지 않습니다.
• 행동은 시각화되고 테스트될 수 있다.
• 오류 처리는 흐름에 내장됩니다.Error handling is built into the flow

7. Include the Human in the Loop

Problem:비록 에이전트가 구조화 된 도구를 사용하고 명확한 제어 흐름을 가지고 있더라도, 현실 세계에서 LLM 에이전트의 완전한 자율성은 여전히 꿈 (또는 상황에 따라 악몽)입니다.

Main risks of full autonomy:

• 영구적인 실수: 에이전트는 심각한 결과를 초래하는 행동을 수행할 수 있습니다 (데이터를 삭제, 중요한 클라이언트에 잘못된 메시지를 보내고, 로봇 반란을 시작).
• 준수 위반: 에이전트가 실수로 내부 규정, 법적 요구 사항을 위반하거나 사용자의 감정을 상하게 할 수 있습니다 (그것이 계획이 아니라면이 점을 무시하십시오).
• 합리성과 윤리의 부족 : LLM은 사회적 뉘앙스를 놓치거나 "일반적인 합리성"에 반해서 행동 할 수 있습니다.
• 사용자 신뢰의 상실: 에이전트가 자주 실수를하면 사용자는 그에 대한 신뢰를 멈출 것입니다.
• 감사 및 책임 복잡성 : 자율 에이전트가 "스크류"할 때 누가 탓합니까?

Solution: 탄소 기반 생명 형태의 전략적 소환중요한 단계에서 인간을 의사 결정 과정에 통합하십시오.

HITL Implementation Options

1. Approval Flow

• When: action is critical, expensive, irreversible
• 방법: 에이전트가 제안을 작성하고 확인을 기다립니다.

2. Confidence-aware Routing

• 언제 : 모델은 불확실하다
• How:
  • self-assessment (logits, LLM-as-a-judge, P(IK))
  • escalation when confidence falls below threshold

3. Human-as-a-Tool

• 언제: 불충분한 데이터 또는 불확실한 요청 형식
• 방법: 에이전트가 설명을 요청합니다 (예를 들어, CrewAI의 HumanTool)

4. Fallback Escalation

• 언제: 반복되는 오류 또는 해결할 수 없는 상황
• 방법: 작업은 컨텍스트와 함께 운영자에게 전달됩니다.How: task is passed to operator with context

5. RLHF (Human Feedback)

• 언제 : 모델 개선을 위해
• 방법 : 인간은 응답을 평가하고, 그들은 훈련에 들어갑니다.

Checklist:

• 승인을 요구하는 행동은 정의된다.
• 신뢰 평가를 위한 메커니즘이 있다.
• 에이전트는 인간에게 질문할 수 있습니다.
• 비판적인 행동은 확인이 필요하다
• 응답을 입력하기 위한 인터페이스가 있습니다.There is an interface for inputting responses

8. Compact Errors into Context

Problem:오류가 발생할 때 많은 시스템의 표준 행동은 오류를 보고하고 멈추는 것이거나 오류를 보고하는 것입니다.자율적으로 작업을 해결해야하는 에이전트를 위해 이것은 정확히 최선의 행동 모델이 아닙니다.

우리는 무엇을 직면 할 것인가 :

• Brittleness: Any failure in an external tool or unexpected LLM response can stop the entire process or lead it astray.
• 비효율성: 지속적인 재시작 및 수동 개입은 시간과 자원을 소모합니다.
• 배울 수 없음 (넓은 의미에서): 에이전트가 맥락에서 자신의 실수를 "보지 못한다면, 그것은 그들을 고치거나 행동을 조정하려고 할 수 없습니다.
• 환상이 또다시

Solution:오류는 메모리 또는 메모리에 포함되어 있습니다.이 아이디어는 어떤 종류의 "자기 치유"를 구현하려고하는 것입니다.

거친 흐름 :

• 오류를 이해하는
• Self-correction:
  • Self-correction mechanisms: Error Detection, Reflection, Retry Logic, Retry with changes (Agent can modify request parameters, rephrase the task, or try a different tool)
  • Impact of reflection type: More detailed error information (instructions, explanations) usually leads to better self-correction results. Even simple knowledge of previous errors improves performance.
  • Internal Self-Correction: Training LLMs for self-correction by introducing errors and their fixes into training data.
• Request human help: If self-correction fails, the agent escalates the problem to a human (see Principle 7).

Checklist:

• 이전 단계의 오류가 컨텍스트에 저장됩니다.
• 리트리 논리 존재
• Fallback/human escalation은 반복적인 실패를 위해 사용됩니다.

9. Break Complexity into Agents

Problem:LLM의 핵심 제한 (그 컨텍스트 창 일)으로 돌아가지만 다른 각도에서이 문제를 살펴보자 작업이 크고 복잡할수록 더 많은 단계가 걸릴 것이며, 이는 더 긴 컨텍스트 창을 의미합니다. 컨텍스트가 성장함에 따라 LLM은 초점을 잃거나 잃을 가능성이 높습니다. 3-10 단계, 아마도 최대 20 단계로 특정 도메인에 에이전트를 집중함으로써 우리는 관리 가능한 컨텍스트 창과 높은 LLM 성능을 유지합니다.

Solution:특정 작업을 대상으로 작은 에이전트를 사용합니다.One agent = one task; orchestration from above.

Benefits of small, focused agents:

• 관리 가능한 맥락 : 더 작은 맥락 창은 더 나은 LLM 성능을 의미합니다.
• 명확한 책임: 각 에이전트는 잘 정의된 범위와 목적을 가지고 있습니다.
• 더 나은 신뢰성: 복잡한 작업 흐름에서 잃을 가능성이 적습니다.
• 더 간단한 테스트: 특정 기능을 테스트하고 검증하는 것이 더 쉽습니다.
• Improved debugging: Easier to identify and fix problems when they arise

불행히도, 논리 조각이 이미 여러 에이전트로 분할 할 정도로 크면 이해하기위한 명확한 heuristic이 없습니다. 나는이 텍스트를 읽는 동안 LLM이 실험실에서 어딘가에서 더 똑똑해졌다는 것을 확신합니다.그리고 그들은 점점 더 잘되고있다.이 경계를 공식화하려는 모든 시도는 처음부터 유죄가됩니다.예, 작업이 작아질수록 더 간단하지만, 더 커질수록 더 나은 잠재력이 실현됩니다. 올바른 직감은 경험으로만 올 것입니다.그러나 확실하지 않습니다.

Checklist:

• Scenario is built from microservice calls

• Agents can be restarted and tested separately

• Agent = minimal autonomous logic. You can explain what it does in 1-2 sentences.

  
  

  

  
  

제3장 통제 모델의 상호 작용

모델은 세대를 처리합니다.다른 모든 것은 당신에게 달려 있습니다.

모델은 세대를 처리합니다.다른 모든 것은 당신에게 달려 있습니다.

당신이 요청을 어떻게 표현했는지, 당신이 어떤 맥락에서 전달했는지, 당신이 어떤 지시를 주었는지 -이 모든 것이 결과가 일관되거나 "창조적 인"지 여부를 결정합니다.

LLM은 마음을 읽지 않습니다.그들은 토큰을 읽습니다.

즉, 모든 입력 오류는 출력 버그로 변합니다 - 즉시 눈에 띄지 않습니다.

This section is about not letting everything drift: prompts = code, explicit context management, constraining the model within boundaries. We don't hope that the LLM will "figure it out on its own."

10. Treat Prompts as Code

Problem:특히 ML 또는 SE 배경이없는 사람들 사이에서 매우 일반적인 패턴은 코드에 직접 프롬프트를 저장하는 것입니다.

이 접근 방식은 몇 가지 유지 보수 및 확장 어려움을 초래합니다 :

• 탐색, 이해 및 수정은 프로젝트의 복잡성과 인스턴트 수가 증가함에 따라 복잡해집니다.
• 명시적인 버전화가 없으면 빠른 진화, 변경 이유를 추적하고 성능 악화의 경우 이전의 안정적인 버전으로 돌아가기가 매우 어렵습니다.
• 효율적이지 않은 개선 및 디버깅 프로세스: 객관적 인 측정 및 테스트가없는 신속한 최적화는 불안정한 결과를 가진 주관적이고 노동 집중적인 프로세스가됩니다.
• 다른 팀 구성원의 인식은 (특히) 미래의 당신을 포함하여 복잡해집니다.

Solution:이 맥락에서 프롬프트는 코드와 크게 다르지 않으며 동일한 기본적인 엔지니어링 관행이 적용되어야합니다.

This implies:

• 특수 파일(예: .txt, .md, .yaml, .json) 또는 심지어 템플릿 관리 시스템(예: Jinja2, Handlebars, 또는 BAML과 같은 특수 도구)을 사용하여 별도로 그리고 체계적으로 저장합니다.
• A/B 테스트는 다른 버전과 함께 할 수 있습니다.You can even do A/B tests with different versions after this.
• Testing. You heard that right.
  • This could be something like unit tests, where you compare LLM responses to specific inputs against reference answers or expected characteristics depending on the prompt
  • Evaluation datasets
  • Format compliance checks and presence/absence of key elements - For example, if a prompt should return JSON, the test can validate its structure
  • Even LLM-as-a-judge if your project and design justify it.

우리는 원칙 14에서 테스트에 대해 더 자세히 이야기 할 것입니다.

Checklist:

• 프롬프트는 비즈니스 논리와 분리된 별도의 파일에 저장됩니다.
• DIFF가 있고 역사가 바뀐다
• 테스트가 사용됩니다 (필요한 경우)
• (선택 사항) 코드 검토의 일환으로 빠른 검토는 어떻습니까?

11.Context 엔지니어링

Problem:우리는 이미 LLM의 "잊혀지기"에 대해 논의했으며, 부분적으로 이것을 외부 메모리에 역사를 전송하고 다른 작업을 위해 다른 에이전트를 사용함으로써 해결했습니다.하지만 그게 전부는 아닙니다.

Standard formats aren't always optimal:롤 콘텐츠에 대한 간단한 메시지 목록 (system/user/assistant) format is the baseline, but it can be token-heavy, not informative enough, or poor at conveying the complex state of your agent.

대부분의 LLM 클라이언트는 표준 메시지 형식을 사용합니다(표준 메시지 형식)role‘사용자’, ‘사용자’, ‘사용자’content그리고 때때로tool_calls밭이 있음)

이것이 "대부분의 경우에 훌륭하게 작동하지만"maximum efficiency(토큰과 모델의 관심 측면에서) 우리는 컨텍스트 형성에 더 창의적으로 접근 할 수 있습니다.

Solution:그것을 엔지니어링하기 위해 LLM에 전달 된 전체 정보 패키지의 창조를 취급하기 위해"Context Engineering."이것은 의미 :

1. 완전한 통제 : 어떤 정보가 LLM의 컨텍스트 창에 들어가는지, 어떤 형태, 볼륨 및 순서에 대한 완전한 소유권을 차지합니다.
2. 사용자 정의 형식을 만드는 방법: 표준 메시지 목록에만 국한되지 않습니다. 본인의 작업 최적화 된 컨텍스트를 표현하는 방법을 개발합니다. 예를 들어 XML 같은 구조를 사용하여 다양한 유형의 정보 (메시지, 도구 호출, 그 결과, 오류 등)를 하나 또는 여러 메시지로 밀접하게 포장하는 것을 고려할 수 있습니다.
3. 전체적인 접근 방식: 컨텍스트를 단순히 대화 기록으로 보는 것이 아니라 모델이 필요로 할 수있는 모든 것의 합계로 보는 것입니다 : 즉각적인 인스턴트, 지침, RAG 시스템의 데이터, 도구 호출의 역사, 에이전트의 상태, 다른 상호 작용의 메모리, 원하는 출력 형식에 대한 지침조차도.

(Instead of a checklist) How do you know when this makes sense?

당신이 다음 중 하나에 관심이 있다면:

• 정보 밀도: 최소한의 소음으로 최대의 의미.
• 비용 효율성: 우리가 낮은 가격에 비교할 수있는 품질을 얻을 수있는 토큰의 수를 줄입니다.
• 잘못된 행동을 개선했다.
• 민감한 정보의 포함을 처리하고, 그것을 제어하고, 그것을 필터링하고, 모든 것을 끝내고, 고전적인 "미안하지만, 나는 단지 작은 큰 언어 모델 모델"응답을 제거합니다.

12. Constrain the Chaos: Secure Inputs, Guarded Actions, and Grounded Outputs

Problem:우리는 이미 안정성의 이름으로 많은 일을 해왔지만 아무것도 실버 볼이 아닙니다.이것은 가장 중요한 잠재적 인 문제를 개별적으로 살펴보고 명시적으로 "보험"을 취할 가치가 있다는 것을 의미합니다.

이 원칙에서 우리는 생각합니다 :

• 가능한 프롬프트 주입.당신의 에이전트가 사용자와 직접 통신하는 경우, 당신은 입력으로 제공되는 것을 제어해야합니다.사용자의 유형에 따라, 당신은 당신의 흐름을 깨고 에이전트가 초기 목표를 무시하고, 잘못된 정보를 제공하고, 유해한 행동을 수행하거나, 악성 콘텐츠를 생성하려는 누군가를 얻을 수 있습니다.
• 위의 이유로, 또는 "머리 속의 목소리"로 인해, 에이전트는 사용자의 개인 데이터, 기업 비밀 등과 같은 중요한 정보를 공개할 수 있습니다.
• 독성 또는 악성 콘텐츠 생성.이것이 디자인에 의한 경우, 이 점을 무시하십시오.
• 정보가 없을 때 물건을 만드는 것.영원한 고통.
• 기계의 상승, 기억하십시오?하지만 진지하게, 그 논리 과정에서, 에이전트는 매우 비 비정상적인 솔루션에 도달 할 수 있습니다, 모든 정상적인 행동의 범위 내에있을 것입니다.

LLM 에이전트의 보안 및 토대는 단일 조치가 아니라 상호 작용의 전체 생애주기를 다루는 다층 보호 시스템 ( "방어 깊이")입니다.위협은 다양하며 단일 보호 방법은 유일한 치료법이 아닙니다.

Solution:우리는 여러 층의 방어 시스템에 헌신해야하며, 모든 구석 사례와 잠재적 인 시나리오를 생각하고 명확하게 다루어야하며, 어떤 일이 일어날지에 대한 명확한 대응을해야합니다.

기본 설정에서, 당신은 고려해야합니다 :

1. Secure Inputs.

   1. Check for known attack-indicator phrases (e.g., "ignore all previous instructions"). It sometimes makes sense to combat potential obfuscation.
   2. Try to determine the user's intent separately. You can use another LLM for this, to analyze the input for the current one.
   3. Control input from external sources, even if they are your own tools.

2. Guarded Actions. Control the privileges of both the agent and its tools (granting the minimum necessary), clearly define and limit the list of available tools, validate parameters at the input to tools, and enable Principle #7 (Human in the Loop).

3. Output Moderation. Design a system of checks for what the model outputs, especially if it goes directly to the user. These can be checks for relevance (ensuring the model uses what's in the RAG and doesn't just make things up) as well as checks for general appropriateness. There are also ready-made solutions (e.g., the OpenAI Moderation API).

그러나 최종 시스템은 당신의 작업과 위험 평가에 달려 있습니다.검사 목록에서, 우리는 몇 가지 옵션을 스케치하려고합니다.

Checklist:

• User input validation is in place.

• For tasks requiring factual information, the data within the RAG is used.

• The prompt for the LLM in a RAG system explicitly instructs the model to base its answer on the retrieved context.

• LLM output filtering is implemented to prevent PII (Personally Identifiable Information) leakage.

• The response includes a link or reference to the source.

• LLM output moderation for undesirable content is implemented.

• The agent and its tools operate following the principle of least privilege.

• The agent's actions are monitored, with HITL (Human-in-the-Loop) for critical operations.

  
  

  

  
  

IV. Keep It Alive

"Kinda works"라는 에이전트는 지연된 효과가 있는 버그입니다.

"Kinda works"라는 에이전트는 지연된 효과가 있는 버그입니다.

프로드에서, 모든 것이 한 번에 깨지는 것은 아닙니다.그리고 당신은 그것에 대해 즉시 알 수 없습니다.

이 섹션은 엔지니어링 습관에 관한 것입니다.seeing what's happening그리고checking that everything is still working로그, 추적, 테스트 - 당신이 잠을 자거나 다음 에이전트를 개발할 때조차도 에이전트의 행동을 투명하고 신뢰할 수있는 모든 것입니다.

13. Trace Everything

Problem:개발, 테스트, 변경 또는 정상 작동 중에 이것은 피할 수 없으며, 현재는 어느 정도 정상입니다. 이것은 당신이 오류가 무엇인지 이해하고 문제를 복제하고 해결하려고 몇 시간을 보내고 시간을 보내는 것이라는 것을 의미합니다. 나는이 시점에 당신이 이미 원칙 #1 (국가 외부 유지) 및 #8 (문제에 컴팩트 오류)를 구현했다고 생각하고 싶습니다. 대부분의 경우, 그것은 당신의 삶을 훨씬 더 간단하게하기에 충분합니다.

그럼에도 불구하고 (특히 지금 당장 그들을 괴롭히지 않기로 결정했다면), 이 원칙을 준수함으로써 사전에 디버깅에 대해 생각하고 미래에 시간과 신경을 절약하는 것이 매우 합리적입니다.

Solution:요청에서 행동으로 전체 경로를 로그하십시오. 이미 개별 구성 요소에 대한 로그를 가지고 있더라도 전체 체인을 추적하는 것은 어려울 수 있습니다. 심지어 당신이 퍼즐이나 레고의 큰 팬이라면 어떤 시점에서 재미가 없어질 것입니다.

Why it's needed:

• 디버깅 - 일들이 잘못되었는지 빨리 찾으십시오.이 원칙이 존재하는 이유입니다.
• 분석 - 포장점이 어디에 있는지 그리고 어떻게 개선할 수 있는지 알아보십시오.
• 품질 평가 - 변화가 행동에 어떻게 영향을 미치는지 알아보십시오.
• 재생 가능성 - 단계를 정확하게 재구성할 수 있습니다.
• 감사 - 모든 에이전트 의사 결정 및 행동의 로그.

기본적인 "남자의 세트"는 이렇게 보입니다 :

• 입력: 초기 사용자 요청, 이전 단계에서 얻은 매개 변수.
• 에이전트 상태: 단계를 실행하기 전에 에이전트의 주요 상태 변수.
• 프롬프트: LLM에 보낸 프롬프트의 전체 텍스트, 시스템 지침, 대화 역사, 검색된 RAG 컨텍스트, 도구 설명 등을 포함합니다.
• LLM 출력 : 모든 분석 또는 처리 전에 LLM의 완전하고 원시적인 응답.
• 도구 호출: LLM이 도구를 호출하기로 결정한 경우 - 도구의 이름과 호출 된 정확한 매개 변수 (구축 된 출력에 따라).
• 도구 결과: 도구가 반환한 응답, 성공적인 결과와 오류 메시지를 포함합니다.The response that the tool returned, including both successful results and error messages.
• 에이전트의 결정: 에이전트가 LLM의 응답이나 도구의 결과를 바탕으로 한 결정 (예를 들어, 어떤 다음 단계를 수행해야 하는지, 어떤 응답을 사용자에게 제공해야 하는지).
• 메타데이터 : 단계 실행 시간, LLM 모델, 호출 비용 (가능한 경우), 코드 / 프롬프트 버전.

Note:기존 추적 도구를 살펴보십시오; 특정 조건에서, 그들은 당신의 삶을 훨씬 더 쉽게 만들 것입니다. LangSmith, 예를 들어, 통화 체인, 인스턴스, 응답 및 도구 사용에 대한 상세한 시각화를 제공합니다. 당신은 또한 Arize, Weights & Biases, OpenTelemetry 등과 같은 도구를 당신의 필요에 맞출 수 있습니다.

Checklist:

• 모든 에이전트 단계가 로그인됩니다 (당신의 버전의 "신부 세트").
• 단계는 session_id 및 step_id로 연결됩니다.
• 전체 체인을 볼 수 있는 인터페이스가 있습니다.
• LLM에 보낸 프롬프트는 언제든지 재생할 수 있습니다.

14. Test Before You Ship

Problem:이 시점에서, 당신은 아마도 어떤 종류의 실질적으로 완성 된 솔루션을 가지고있다.그것은 작동, 어쩌면 당신이 원하는 방식으로도.그것을 배송하십시오?그러나 우리는 어떻게 그것을 보장합니까?유지하기작동? 심지어 다음 소규모 업데이트 후에도?예, 나는 테스트의 주제로 우리를 이끌고있다.

분명히, LLM 시스템의 업데이트는 다른 모든 것과 마찬가지로 - 응용 프로그램 코드의 변경, 미세 조정 또는 RAG를위한 데이터 세트에 대한 업데이트, 기초 LLM의 새로운 버전, 또는 심지어 작은 인스턴트 조정 - 종종 기존 논리와 예기치 않은, 때로는 악화 된, 에이전트 행동에 의도하지 않은 부작용을 초래합니다.

• 모델 드라이브.당신은 아무것도하지 않았지만 성능은 시간이 지남에 따라 떨어졌습니다.아마도 공급자가 모델을 업데이트했을 수도 있고, 아마도 입력 데이터의 성격이 바뀌었을 수도 있습니다 (데이터 드라이브) - 어제 작동한 것이 오늘 작동하지 않을 수도 있습니다.
• Prompt의 작은 변화조차도 확립 된 논리를 깨고 출력을 왜곡시킬 수 있습니다.
• LLM의 비 결정: 당신이 알고 있듯이, 많은 LLM은 비 결정적입니다 (특히 온도 > 0), 즉 각 호출에서 동일한 입력에 다른 응답을 생성 할 것입니다.
• 첫 번째 원칙을 구현하면 오류를 복제하고 디버깅하는 데 어려움이 있습니다.It will be easier for you if you have implemented the first principle, but reproducing a specific error for debugging can be difficult even with fixed data and states.
• 복잡한 시스템에서 단일 요소(모델이나 프롬프트와 같은)를 업데이트하면 APIs, 데이터베이스, 도구 등의 체인을 통과시킬 수 있으며 다른 곳에서 행동 변화로 이어질 수 있습니다.
• 환각을

그러나 우리는 이미 명백한 코드 논리를 확인하는 데 중점을 둔 전통적인 테스트가 이러한 문제를 완전히 덮을 수 없다는 것을 이해합니다.

Solution:우리는 클래식 및 도메인 특정 솔루션을 결합하여 많은 것을 다루는 복잡하고 포괄적 인 접근 방식을 개발해야합니다.This solution should address the following aspects:

• 멀티 레벨 테스트: 시스템의 다양한 측면을 대상으로 하는 다른 테스트 유형의 조합: 개별 기능 및 인스턴스에 대한 낮은 레벨 유닛 테스트에서부터 에이전트의 엔드-테인드 워크플로와 사용자 상호 작용을 검증하는 복잡한 시나리오까지.
• LLM 행동 및 품질에 초점을 맞추십시오 : 테스트는 기능적 정확성뿐만 아니라 관련성, 정확성, 일관성, 유해하거나 편견 된 내용의 부재 및 지침 및 주어진 스타일에 대한 준수와 같은 LLM 응답의 질적 특성을 평가해야합니다.
• 다양한 입력 예제와 참조 (또는 수용 가능한 범위) 출력을 포함하는 "골든 데이터 세트"를 포함하는 회귀 및 품질 테스트.Regression and quality tests that include "golden datasets" containing diverse input examples and reference (or acceptable ranges of) outputs.
• Automation and integration into CI/CD.
• 인간-in-the-loop 평가 : LLM-eval의 특정 단계는 측정 측정을 위해 인간을 포함하고 복잡한 또는 중요한 사례를 검토해야합니다.
• 빠른 개발 및 테스트에 대한 반복적 접근 방식: 프롬프트 엔지니어링은 실행 전에 각 버전의 프롬프트가 철저하게 테스트되고 평가되는 반복적 인 과정으로 취급되어야합니다.
• Testing at different levels of abstraction:
  • Component testing: Individual modules (parsers, validators, API calls) and their integration.
  • Prompt testing: Isolated testing of prompts on various inputs.
  • Chain/Agent testing: Verifying the logic and interaction of components within an agent.
  • End-to-end system testing: Evaluating the completion of full user tasks.

Checklist:

• Logic is broken down into modules: functions, prompts, APIs—everything is tested separately and in combination.

• Response quality is checked against benchmark data, evaluating meaning, style, and correctness.

• Scenarios cover typical and edge cases: from normal dialogues to failures and provocative inputs.

• The agent must not fail due to noise, erroneous input, or prompt injections—all of this is tested.

• Any updates are run through CI and monitored in prod—the agent's behavior must not change unnoticed.

  

Principle 15: Own the Execution Path

이것은 메타 원칙이며 위에 나열된 모든 원칙을 통해 실행됩니다.This is a meta-principle; it runs through all those listed above.

다행히도 오늘날 우리는 모든 작업을위한 수십 가지 도구와 프레임 워크가 있습니다.이것은 훌륭하고 편리하며 함정입니다.

거의 항상, 준비된 솔루션을 선택하는 것은trade-off당신은 속도와 쉬운 시작을 얻을,하지만 당신은 잃는다.flexibility, control, and, potentially, security.

이것은 특히 관리하는 것이 중요 한 에이전트 개발에서 중요합니다 :

• LLM의 예측 불가능성,
• 전환과 자기 교정에 대한 복잡한 논리,
• 시스템의 적응과 진화에 대한 준비가되어 있으며, 핵심 작업이 변하지 않더라도.

Frameworks 가져오기inversion of control: 그들은 에이전트가 어떻게 작동해야 하는지 결정합니다.이것은 프로토 타입을 단순화하지만 장기 개발을 복잡하게 할 수 있습니다.

위에서 설명한 많은 원칙은 옥상 솔루션을 사용하여 구현될 수 있으며, 이것은 종종 정당화됩니다.explicit implementation of the core logic takes a comparable amount of time비교할 수 없을 정도로 더 많은transparency, manageability, and adaptability.

반대의 극단 또한 존재한다-over-engineering, 모든 것을 처음부터 쓰고 싶은 욕망.이 또한 실수입니다.

This is why the key is balance. The engineer chooses for themselves: where it's reasonable to rely on a framework, and where it's important to maintain control. And they make this decision consciously, understanding the cost and consequences.

당신은 기억해야합니다 : 업계는 여전히 형태를 취하고있다.현재 표준이 나타나기 전에 많은 도구가 만들어졌습니다.내일, 그들은 오래된 될 수 있습니다 -하지만 오늘날 당신의 건축에 구운 제한은 남아있을 것입니다.

Conclusion

OK, 우리는 경험이 보여주는 15 가지 원칙을 통해 "그것은 살아있다!"의 초기 흥분을 당신의 LLM 에이전트가 실제 조건에서 안정적이고 예측 가능한 유용한 방식으로 작동할 것이라는 확신으로 바니다.

당신은 그것을 당신의 프로젝트에 적용하는 것이 의미 있는지 확인하기 위해 그들 각각을 고려해야합니다.In the end, it is your project, your task, and your creation.

Key takeaways to carry with you:

1. 엔지니어링 접근법은 핵심입니다 : LLM의 "마법"에 의존하지 마십시오 구조, 예측 가능성, 관리 가능성 및 테스트 가능성은 당신의 가장 친한 친구입니다.
2. LLM은 강력한 구성 요소이지만 여전히 단지 하나의 구성 요소입니다 : LLM을 시스템의 매우 똑똑하지만 그럼에도 불구하고 단일 구성 요소로 취급하십시오.
3. 이터레이션과 피드백은 성공의 열쇠입니다 : 첫 번째 시도에서 완벽한 에이전트를 만드는 것은 드문 일입니다.실험, 측정, 오류 분석 및 지속적인 개선을 위해 준비하십시오 - 에이전트 자체와 개발 프로세스 모두.
4. 커뮤니티 및 개방성 : LLM 에이전트의 분야는 빠르게 진화하고 있습니다. 새로운 연구, 도구 및 최선의 관행을 모니터링하고 자신의 경험을 공유하십시오.

나는 당신이 여기서 뭔가 새롭고 유용한 것을 발견했기를 바랍니다, 그리고 어쩌면 당신은 심지어 당신의 다음 에이전트를 설계하는 동안 이것에 다시 올 수 있습니다.