참조 가이드

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

이 포괄적인 참조에서 상담사 프레임워크의 모든 구성요소에 관한 자세한 정보를 빠르게 찾을 수 있습니다.

폴더 구조

에이전트를 빌드하려면 에이전트의 이름을 따서 지정하고 다음 파일 중 적어도 하나를 포함하는 에이전트 폴더를 만듭니다.

• agent.py: 에이전트의 기본 파일입니다. 전역 변수 root_agent 아래에 루트 에이전트를 정의해야 합니다.
• __init__.py: Python 모듈 파일입니다. Agent 클래스를 가져오는 from agents import Agent 줄이 하나 이상 포함되어야 합니다.

원하는 경우 다음 파일을 추가하는 것이 좋습니다.

• requirements.txt: 에이전트의 Python 요구사항 파일입니다.
• README.md: 에이전트의 README 파일입니다. 에이전트를 설정하고 실행하는 안내가 포함되어야 합니다.

최소한의 agent.py

에이전트 빌드는 Agent 클래스의 인스턴스를 만드는 것으로 시작합니다. 최소한의 상담사에는 다음 속성이 있어야 합니다.

• name: 에이전트의 이름입니다.
• model: 사용할 LLM 모델의 이름입니다.
• instruction: 상담사를 위한 자연어 안내입니다.

예를 들면 다음과 같습니다.

from agents import Agent

root_agent = Agent(
    model='gemini-1.5-flash',
    name='root_agent',
    instruction="Be polite and answer all users' questions.",
)

최소한의 에이전트를 만들려면 _empty_agent 폴더를 복사하고 agent.py 파일을 수정하면 됩니다.

속성

name

  name: str

에이전트 이름입니다.

• 식별자

  • 이름은 식별자 이름 지정 규칙을 따라야 합니다.
  • 문자열에 영숫자 문자 (a~z) 및 (0~9) 또는 밑줄 (_)만 포함된 경우 유효한 식별자로 간주됩니다. 유효한 식별자는 숫자로 시작하거나 공백을 포함할 수 없습니다.

• 고유

  • 이름은 전체 상담사 트리에서 고유해야 합니다.

• 루트 상담사

  • 루트 에이전트의 변수 이름은 root_agent여야 하지만 루트 에이전트의 더 의미 있는 이름 속성을 설정할 수 있습니다.

모델

  model: str

사용할 LLM 모델의 이름입니다.

• LLM 에이전트에 필요

  • model 속성은 LLM 에이전트에만 필요합니다.
  • Sequential, Loop 또는 기타 LLM 이외의 에이전트의 경우 모델 속성을 설정할 필요가 없습니다.

• 상위 상담사

  • 모델 속성은 생략할 수 있습니다. 이 경우 상위 / 조상 에이전트의 모델 속성이 사용됩니다.

• 형식

  • 모델 이름 형식은 LLM 공급업체에 따라 다릅니다.
  • Gemini의 경우 gemini-1.5-flash 또는 gemini-2.0-flash-exp처럼 보입니다.
  • Vertex의 Anthropic의 경우 claude-3-5-sonnet-v2@20241022와 같습니다.
  • 프레임워크의 설계는 모든 모델 공급업체를 허용하지만 현재 Vertex에서는 Gemini 및 Anthropic만 지원합니다.

안내

  instruction: str | InstructionProvider

에이전트의 자연어 안내입니다.

• LLM 에이전트에 필요

  • 이 안내는 LLM 상담사에게만 필요합니다.
  • Sequential, Loop 또는 기타 LLM 이외의 에이전트의 경우 명령어 속성을 설정할 필요가 없습니다.

• 데이터 유형

  • 명령어는 문자열일 수 있습니다.
  • 이 명령어는 호출 가능한 InstructionProvider일 수도 있습니다.

• InstructionProvider

  • InstructionProvider는 Callable[[InvocationContext], str]로 정의됩니다.
  • 호출 컨텍스트를 기반으로 명령어를 동적으로 생성하는 함수를 제공할 수 있습니다.

• 상태

  • 명령어는 문자열 템플릿이므로 {var} 문법을 사용하여 명령어에 동적 값을 삽입할 수 있습니다.

  var

  는 var라는 상태 변수의 값을 삽입하는 데 사용됩니다.

  artifact.var

  는 var라는 아티팩트의 텍스트 콘텐츠를 삽입하는 데 사용됩니다.
  • 상태 변수 또는 아티팩트가 없으면 상담사가 오류를 발생시킵니다. 오류를 무시하려면 변수 이름에 ?를 추가하면 됩니다(예: {var?}).

• 가이드라인

  • 먼저 에이전트가 누구인지, 무엇을 할 수 있고 무엇을 할 수 없는지 설명합니다.
  • 마크다운 형식을 사용하여 인간과 모델 모두에게 가이드라인을 더 쉽게 읽을 수 있도록 할 수 있습니다.
  • 상담사가 여러 작업을 할 수 있는 경우 작업 목록을 제공하고 각 작업에 대해 별도의 섹션을 만듭니다.
  • 태스크에 여러 단계가 있는 경우 단계 목록과 각 단계에 대한 자세한 안내를 제공합니다.
  • 상담사가 도구를 사용할 수 있는 경우 tools 속성 아래에 도구를 나열합니다. 도구 정의에는 도구 사용 방법에 관한 안내가 있지만, 언제 사용해야 하는지에 관한 자세한 안내는 에이전트 안내에 추가하여 성능을 개선할 수 있습니다.
  • 멀티 에이전트 시스템의 경우 다른 에이전트에게 전달해야 하는 시점을 설명합니다.
  • 안내에 입력과 예상 출력의 예시를 포함할 수 있으며 examples 속성을 사용하여 예시를 제공할 수도 있습니다.
  • 지침을 자세하고 구체적으로 제공합니다. 상담사를 교육 과정을 거치는 신입 직원으로 대합니다.
  • 항상 따라야 하는 규칙에 관한 안내는 사용하지 마세요. 모델은 본질적으로 어느 정도의 자유도를 가지며 실수를 할 수 있습니다. 도구와 콜백을 사용하여 엄격한 규칙을 적용합니다.

description

  description: str

이 에이전트가 할 수 있는 작업을 설명합니다. 이 설명은 시스템 안내의 일부로 모델에 전송되므로 다음과 같은 작업을 할 수 있습니다.

1. 에이전트는 설명에 따라 자체 기능을 이해합니다.

2. 상담사는 다른 상담사가 할 수 있는 작업을 파악하고 설명에 따라 트랜스퍼 여부를 결정합니다.

global_instruction

  global_instruction: str | InstructionProvider

전체 상담사 트리에 대한 전역 안내입니다.

안내는 특정 상담사에게 해야 할 작업과 방법을 알려주지만 전역 안내는 전체 상담사 트리의 모든 상담사에게 적용됩니다.

전역 명령어의 사용은 데이터 유형, InstructionProvider 지원, 상태 변수 및 아티팩트에 액세스하는 기능을 비롯하여 명령어 속성과 유사합니다.

• 식별 및 동작
  • 전역 안내는 특정 상담사의 특정 작업을 실행하는 방법이 아니라 전체 상담사 트리의 ID 및 동작/표준을 설정하는 데 사용합니다.

generate_content_config

  generate_content_config: google.genai.types.GenerateContentConfig

상담사의 추가 모델 구성입니다. 이는 모델에 대한 요청에 병합됩니다.

프레임워크에서 관리하므로 이 필드에 설정하면 안 되는 속성이 몇 가지 있습니다. - tools - system_instruction - response_schema

예

  examples: list[Example] | BaseExampleProvider

상담사의 퓨샷 예시입니다. 연구에 따르면 샘플이 적은 예시를 제공하면 상담사의 성능을 개선할 수 있습니다.

• 정적 예시
  • 정적 예시 목록을 제공할 수 있습니다. 예는 다음과 같이 정의됩니다. 여기서 input는 입력 콘텐츠이고 output는 예상 출력 콘텐츠입니다.

class Example(BaseModel):
  input: types.Content
  output: list[types.Content]

• 출력 목록

  • 출력은 Content 목록일 수 있습니다.
  • 따라서 콘텐츠 시퀀스를 예상 출력으로 정의할 수 있습니다. 예를 들어 모델은 먼저 함수를 호출한 다음 텍스트를 생성해야 합니다.

• BaseExampleProvider

  • BaseExampleProvider 클래스의 인스턴스를 제공할 수도 있습니다.
  • BaseExampleProvider 클래스에는 get_examples(query: str) 메서드가 있으며 Example 목록을 반환합니다.
  • BaseExampleProvider를 사용하면 쿼리를 기반으로 예시를 동적으로 생성할 수 있습니다.

greeting_prompt

  greeting_prompt: str

인사말 메시지를 생성하기 위해 모델에 전송할 프롬프트를 설정할 수 있습니다. 인사말 프롬프트는 빈 세션과 빈 사용자 입력으로 상담사를 호출할 때 사용됩니다.

계획

  planning: bool

planning를 True로 설정하면 에이전트의 계획 모드가 사용 설정됩니다. 계획 모드에서 상담사는 먼저 사용자 쿼리를 해결할 계획을 생성한 다음 계획을 단계별로 실행합니다.

code_executor

  code_executor: BaseCodeExecutor

빌드한 상담사는 코드를 작성하고 코드를 실행하여 문제를 해결할 수 있습니다.

코드 실행을 사용 설정하는 방법에는 두 가지가 있습니다.

1. 일부 모델은 코드를 직접 실행할 수 있습니다. 예를 들어 실시간 모드의 Gemini 2.0 모델은 별도의 코드 실행 도구 없이 코드를 자동으로 생성하고 실행합니다.

2. code_executor 속성을 BaseCodeExecutor 클래스의 인스턴스로 설정하여 코드 실행을 사용 설정할 수 있습니다. 현재 Vertex AI에서 코드를 실행하는 데 사용할 수 있는 VertexCodeExecutor 및 UnsafeLocalCodeExecutor (LLM에서 생성된 코드는 심각한 손상을 줄 수 있으므로 프로토타이핑에만 UnsafeLocalCodeExecutor 사용) 클래스가 있습니다. 향후 더 많은 코드 실행자가 추가될 예정입니다.

input_schema

  input_schema: type[BaseModel]

Pydantic 모델을 input_schema로 지정하면 에이전트가 입력 스키마를 적용합니다. 입력 콘텐츠는 스키마를 준수하는 JSON 문자열이어야 합니다.

output_schema

  output_schema: type[BaseModel]

Pydantic 모델을 output_schema로 지정하면 에이전트가 출력 스키마를 적용합니다. 출력 콘텐츠는 항상 스키마를 준수하는 JSON 문자열입니다.

output_key

  output_key: str

에이전트는 output_key 속성에서 지정한 이름으로 상태 변수에 출력을 저장합니다.

include_contents

  include_contents: Literal['default', 'none']

상담사는 기본적으로 세션 기록 (채팅 기록)의 콘텐츠를 포함합니다. include_contents 속성을 none로 설정하여 이 동작을 사용 중지할 수 있습니다. 이 경우 특정 상담사에게 채팅 기록이 표시되지 않습니다. 상담사가 채팅 기록을 알 필요가 없는 경우에 유용합니다.

도구

도구를 사용할 수 있는 기능은 에이전트를 단순한 모델과 구분합니다. 도구를 복잡하고 다재다능하게 사용하는 능력이 인간의 고유한 특성으로 간주되는 것처럼 말입니다.

에이전트 프레임워크에서는 tools 속성을 통해 에이전트에 도구를 제공합니다. tools 속성은 도구 목록이며 각 도구는 다음과 같을 수 있습니다.

• Python 함수
• BaseTool 클래스를 구현하는 클래스입니다.

Python 함수 도구

Python 함수를 도구로 정의할 수 있습니다.

• 매개변수

  • 함수에는 매개변수가 여러 개 있을 수 있습니다.
  • 각 매개변수는 JSON 직렬화가 가능한 유형이면 어떤 유형이든 될 수 있습니다.
  • 매개변수에 기본값을 설정하지 마세요. 모델에서 지원되지 않습니다.

• 반환 유형

  • 반환 유형은 사전이어야 합니다.
  • 사전이 아닌 항목을 반환하면 프레임워크에서 단일 키 result를 사용하여 사전으로 래핑합니다.
  • 반환 값을 설명하는 데 노력하세요. 예를 들어 숫자 오류 코드를 반환하는 대신 사람이 읽을 수 있는 오류 메시지가 포함된 error_message: str를 반환합니다. 이 반환 값은 코드가 실행하기 위한 것이 아니라 모델이 읽고 이해하기 위한 것입니다.
  • 모델이 작업의 일반적인 상태를 이해할 수 있도록 status 키를 사용하여 success, error, pending 등을 나타내는 것이 좋습니다.

• 도움말 문자열

  • 함수의 문자열 문서는 도구 설명으로 사용되고 모델에 전송됩니다. 따라서 docstring이 더 나을수록 모델이 도구를 더 잘 사용할 수 있습니다.

• 단순성

  • 함수를 정의하는 데는 많은 자유가 있지만 모델이 더 정확하게 사용할 수 있도록 간단하고 쉽게 유지해야 합니다.
  • 매개변수가 적을수록 좋습니다.
  • 커스텀 클래스 대신 간단한 데이터 유형(예: str, int)을 최대한 사용합니다.
  • 함수 이름과 매개변수가 매우 중요합니다. do_stuff()라는 함수가 있는 경우 모델에 이 함수가 항공편을 취소하는 데 사용된다고 알리더라도 모델이 이 함수를 사용하지 않을 수 있습니다.
  • 복잡한 함수를 더 작은 함수로 분리합니다. 예를 들어 update_profile(profile: Profile)를 update_name(name: str), update_age(age: int) 등으로 분리합니다.

• 안내의 참조

  • 이름을 사용하여 안내에서 도구를 참조할 수 있습니다.
  • 함수의 이름과 문서 문구가 충분히 자세하다면 안내에 도구를 사용할 때만 집중할 수 있습니다.
  • 다양한 반환 값을 처리하는 방법을 상담사에게 안내합니다. 예를 들어 도구에서 오류 메시지를 반환하면 상담사가 포기하거나 다시 시도하거나 추가 정보를 요청해야 하나요?
  • 도구는 순차적으로 사용할 수 있으며 한 도구가 다른 도구의 출력에 종속될 수 있습니다. 안내에서 시퀀스를 설명합니다.

도구 정보

도구 함수에서 특수 매개변수 tool_context: ToolContext를 추가하여 도구가 호출되는 컨텍스트에 관한 추가 정보를 가져올 수 있습니다.

ToolContext 클래스는 agents.types 모듈에 있으며 다음과 같은 속성이 있습니다.

• function_call_event_id: str
  • 도구 호출이 트리거된 이벤트의 ID입니다.
• function_call_id: str
  • 함수 호출의 ID입니다.
• state: State
  • 상태 변수를 읽고 업데이트하는 사전과 유사한 객체입니다.
• actions: EventActions
  • 도구에서 실행할 수 있는 추가 작업

EventActions 클래스는 agents.events 모듈에 있으며 도구가 추가 작업을 실행할 수 있도록 하는 다음 속성이 있습니다.

• skip_summarization: bool
  • true로 설정하면 프레임워크는 도구가 호출되는 이벤트의 요약 단계를 건너뜁니다.
• transfer_to_agent: str
  • 설정된 경우 프레임워크는 transfer_to_agent 속성으로 지정된 이름으로 에이전트로 전송합니다.
• escalate: bool
  • 이 속성을 true로 설정하면 상담사가 쿼리를 상위 상담사에게 에스컬레이션합니다. LoopFlow 내 하위 상담사의 에스컬레이션은 루프의 종료를 의미합니다.

AsyncFunctionTool

AsyncFunctionTool은 FunctionTool의 서브클래스입니다. 완료하는 데 시간이 오래 걸리는 도구용으로 설계되었습니다.

AsyncFunctionTool을 만들려면 일반 Python 함수를 정의하고 AsyncFunctionTool 클래스로 래핑해야 합니다. 다음과 같습니다. AsyncFunctionTool(func=your_function)

AsyncFunctionTool은 여전히 Python 함수를 호출하므로 시간이 오래 걸릴 수 있는 작업을 시작할 수 있습니다. 중간 결과를 모델에 반환하여 모델에 태스크가 아직 완료되지 않았음을 알릴 수 있습니다. status: 'pending', progress: 20, estimated_completion_time: '...'와 같은 정보를 추가하면 모델이 사용자에게 의미 있는 응답을 제공하는 데 도움이 됩니다.

나중에 작업이 완료되면 새 FunctionResponse를 사용하여 상담사를 호출하여 최종 결과를 제공할 수 있습니다. 이때 에이전트는 사용자에게 최종 응답을 생성합니다.

AgentTool

AgentTool을 사용하면 다른 상담사를 호출하여 작업을 실행할 수 있습니다. 이는 Python 함수를 만들고 함수 인수로 다른 에이전트를 호출하고 해당 에이전트의 응답을 함수의 반환 값으로 사용하는 것과 같습니다.

AgentTool은 하위 상담사와 다릅니다.

• 상담사 A가 상담사 B를 AgentTool로 호출하면 상담사 B의 답변이 상담사 A에게 전달되고 상담사 A는 답변을 요약하여 사용자에게 응답을 생성합니다. 이후 사용자 입력은 상담사 A가 계속 응답합니다.
• 상담사 A가 상담사 B를 하위 상담사로 호출하면 사용자에게 응답할 책임이 완전히 상담사 B에게 이전됩니다. 상담사 A는 더 이상 화면에 표시되지 않습니다. 이 경우 향후 사용자 입력은 상담사 B가 응답합니다.

에이전트를 도구로 사용하려면 AgentTool 클래스를 사용하여 에이전트를 래핑하면 됩니다. 예를 들면 tools=[AgentTool(agent=agent_b)]입니다.

AgentTool에는 동작을 맞춤설정하는 다음과 같은 속성이 있습니다.

• skip_summarization
  • true로 설정하면 프레임워크는 LLM 호출을 건너뛰어 도구 에이전트의 응답을 요약합니다.

콜백

콜백 유형

콜백을 정의하여 에이전트의 동작을 추가로 맞춤설정할 수 있습니다. 다음 두 가지 유형의 콜백을 지원합니다.

• BeforeCallbacks는 상담사가 작업을 실행하기 전에 호출됩니다. 작업을 수정하거나, 건너뛰거나, 추가 작업을 실행할 수 있습니다.
• AfterCallbacks는 상담사가 작업을 실행한 후에 호출됩니다. 이 콜백을 사용하여 작업의 결과를 수정하거나 추가 작업을 실행할 수 있습니다.

지원되는 작업

다음 작업에는 BeforeCallbacks 및 AfterCallbacks가 있습니다.

• 상담사에게 전화를 겁니다.
• LLM 호출
• 도구 호출

콜백 목록

따라서 다음과 같은 6개의 콜백이 있으며 모두 Agent 클래스의 속성입니다.

before_agent_callback

def before_agent_callback(invocation_context: InvocationContext) -> Content | None

• 호출에는 여러 개의 상담사 호출이 포함될 수 있습니다. 따라서 이 콜백은 여러 번 호출될 수 있습니다.
• 이 콜백에서 Content를 반환하면 에이전트가 현재 에이전트 호출을 건너뛰고 반환된 Content를 응답으로 사용합니다.

after_agent_callback

def after_agent_callback(invocation_context: InvocationContext) -> Content | None

• 호출에는 여러 개의 상담사 호출이 포함될 수 있습니다. 따라서 이 콜백은 여러 번 호출될 수 있습니다.
• 이 콜백에서 Content를 반환하면 상담사는 반환된 Content를 자체 응답 뒤에 추가합니다.

before_model_callback

def before_model_callback(
    invocation_context: InvocationContext,
    llm_request: LlmRequest) -> LlmResponse | None

• 상담사 호출에는 여러 LLM 호출이 포함될 수 있습니다. 따라서 이 콜백은 여러 번 호출될 수 있습니다.
• 이 콜백에서 LlmResponse를 반환하면 에이전트는 반환된 LlmResponse를 응답으로 사용하고 모델 호출을 건너뜁니다.

before_model_callback

def after_model_callback(
    invocation_context: InvocationContext,
    llm_response: LlmResponse) -> LlmResponse | None

• 상담사 호출에는 여러 LLM 호출이 포함될 수 있습니다. 따라서 이 콜백은 여러 번 호출될 수 있습니다.
• 이 콜백에서 LlmResponse를 반환하면 에이전트는 모델에서 생성된 응답 대신 반환된 LlmResponse를 응답으로 사용합니다.

before_tool_callback

def before_tool_callback(
    invocation_context: InvocationContext,
    tool: BaseTool,
    args: dict[str, Any],
    tool_context: ToolContext) -> dict | None

• 모델 호출에는 여러 도구 호출이 포함될 수 있습니다. 따라서 이 콜백은 여러 번 호출될 수 있습니다.
• 이 콜백에서 dict를 반환하면 에이전트는 반환된 dict를 응답으로 사용하고 도구 호출을 건너뜁니다.

after_tool_callback

def after_tool_callback(
    invocation_context: InvocationContext,
    tool: BaseTool,
    args: dict[str, Any],
    tool_context: ToolContext,
    response: dict) -> dict | None

• 모델 호출에는 여러 도구 호출이 포함될 수 있습니다. 따라서 이 콜백은 여러 번 호출될 수 있습니다.
• 이 콜백에서 dict를 반환하면 에이전트는 도구에서 생성한 응답 대신 반환된 dict를 응답으로 사용합니다.

세션

에이전트를 빌드할 때 세션 객체를 직접 조작할 필요는 없습니다. 프레임워크가 세션 객체를 대신 관리합니다. 하지만 세션의 정의와 작동 방식을 이해하는 것이 좋습니다.

상담사 프레임워크의 세션에는 두 가지 주요 구성요소가 있습니다.

• 이벤트: 이벤트 목록입니다.
• 상태: 상태 변수의 사전과 유사한 객체입니다.

이벤트

이벤트는 이벤트 객체의 간단한 목록입니다. 사용자와 상담사 간의 채팅 기록 또는 여러 상담사 간의 채팅 기록이라고 생각하면 됩니다. 사용자 또는 모델의 단어뿐만 아니라 도구 호출, 도구의 응답, 다른 상담사 호출 등 상담사가 실행하는 모든 작업도 기록합니다.

이벤트 목록은 추가 전용 목록입니다. 목록에 일정만 추가할 수 있으며 일정을 삭제하거나 수정할 수는 없습니다. 이벤트가 발생하면 변경할 방법이 없습니다. 시스템이 간단하고 언제든지 특정 시간으로 돌아가 시스템의 정확한 스냅샷을 볼 수 있도록 하기 위해 이렇게 설계했습니다.

주

상태는 모든 상태 변수가 포함된 사전과 유사한 객체입니다. 다음 위치에서 액세스할 수 있습니다.

• 명령어에서 {var} 문법을 사용하여 var라는 상태 변수의 값을 삽입할 수 있습니다.
• 콜백에서 invocation_context.state['key']를 사용하여 상태 변수에 액세스할 수 있습니다. invocation_context.state['key'] = value를 사용하여 상태 변수를 업데이트할 수도 있습니다.
• 도구에서 tool_context.state['key']를 사용하여 상태 변수에 액세스할 수 있습니다. tool_context.state['key'] = value를 사용하여 상태 변수를 업데이트할 수도 있습니다.

상태는 특정 세션과 연결됩니다. 따라서 이 세션의 맥락에서 유용한 정보를 저장하는 데 이상적인 장소입니다.

상태는 에이전트 트리의 모든 에이전트에서 액세스할 수 있으므로 에이전트 간에 통신하는 데 이상적입니다. 한 에이전트가 작업을 실행하고 그 결과를 상태에 저장할 수 있으며, 그러면 다른 에이전트가 상태에서 결과를 읽고 작업을 계속할 수 있습니다.

아티팩트

모델이나 도구에서 이미지, 동영상, 문서 또는 기타 형식의 파일을 만들면 아티팩트로 저장할 수 있습니다. 아티팩트는 특정 세션과 연결된 파일로, 상담사 또는 자체 코드에서 액세스할 수 있습니다.

사용 사례

• 상담사가 사용자와 협력하여 파일을 만들거나 수정하는 경우 예를 들어 사용자가 이미지를 생성하고 수정하는 데 도움이 되는 상담사를 들 수 있습니다.
• 상담사가 파일 관련 질문에 답변하거나 사용자의 안내에 따라 파일을 수정하도록 하려는 경우

실적 이점

대용량 파일을 처리하는 또 다른 방법은 채팅 기록에 바이트로 저장하는 것입니다. 그러나 이 접근 방식에는 몇 가지 단점이 있습니다.

• 세션 기록이 느려집니다.
• 채팅 기록에서 파일을 가져오기 어렵습니다.
• 대화가 이러한 파일과 관련이 없더라도 모든 요청에 대해 바이트가 모델로 전송됩니다.

아티팩트 액세스

아티팩트에 액세스하는 방법에는 다음과 같은 몇 가지가 있습니다.

• 이 안내에서는 {artifact.var} 문법을 사용하여 var라는 아티팩트의 텍스트 콘텐츠를 삽입할 수 있습니다. 바이너리 아티팩트는 아직 지원되지 않습니다.
• 콜백에서 invocation_context.get_artifact('key')를 사용하여 아티팩트에 액세스할 수 있습니다. invocation_context.set_artifact('key', value)를 사용하여 아티팩트를 업데이트할 수 있습니다.
• 도구에서 tool_context.get_artifact('key')를 사용하여 아티팩트에 액세스할 수 있습니다. tool_context.set_artifact('key', value)를 사용하여 아티팩트를 업데이트할 수 있습니다.

멀티 에이전트 시스템

단일 에이전트와 목록 도구를 사용하면 복잡한 시스템을 빌드하는 데 큰 도움이 됩니다. 하지만 로직을 여러 에이전트로 분리하면 전체 시스템의 성능과 유지보수성을 개선할 수 있는 경우도 있습니다.

다음과 같은 경우에는 여러 상담사를 사용하는 것이 좋습니다.

• 에이전트의 안내가 너무 길어져 각 작업에 여러 작업과 단계가 있는 경우
• 실행할 더 결정론적인 워크플로가 있는 경우 예를 들어 조사 상담사의 경우 항상 계획을 생성한 다음 계획을 실행한 후 결과를 요약합니다.

계층적 상담사 트리

  children: list[BaseAgent]

계층적 에이전트 트리를 만들어 멀티 에이전트 시스템을 빌드합니다. 루트 에이전트는 시스템의 진입점이며 구성 방식에 따라 다른 에이전트를 호출할 수 있습니다.

한 에이전트는 여러 하위 에이전트를 보유할 수 있습니다. 하위 상담사도 자체 하위 상담사를 보유할 수 있습니다. 상담사 트리는 임의로 깊어질 수 있지만 성능상의 이유로 더 얕은 트리를 사용하는 것이 좋습니다.

에이전트 트리를 만들려면 다른 에이전트를 상위 에이전트의 하위 요소로 배치합니다.

흐름

  flow: str | BaseFlow | FlowCallable

상담사는 사용자 쿼리를 수신하면 쿼리를 직접 처리하거나 다른 상담사에게 쿼리를 전달할 수 있습니다. 이는 flow 속성에 의해 정의됩니다.

사전 정의된 흐름이 몇 가지 있으며 자체 흐름을 정의할 수도 있습니다.

• sequential: 에이전트가 하위 에이전트를 차례로 하나씩 호출합니다.
• loop: 에이전트가 하위 에이전트를 루프로 호출합니다. 하위 에이전트 중 하나가 tool_context.actions.escalate를 True로 설정할 때까지
• single: LLM 기반 흐름입니다. 에이전트는 LLM을 호출하여 사용자 쿼리에 응답하고 필요한 경우 도구를 호출합니다.
• auto: LLM 기반 흐름입니다. 에이전트는 LLM을 호출하여 사용자 쿼리에 답변하고 필요한 경우 도구를 호출합니다. 자식, 형제, 상위 요소로 쿼리를 전송할 수도 있습니다.
• 맞춤 흐름: BaseFlow 클래스를 구현하여 자체 흐름을 정의하거나 인터페이스에 따라 Python 함수를 정의하면 됩니다.