Ein Junior-Kreditsachbearbeiter, der sich allein um die Datenaufnahme, Risikoprüfung und endgültigen Entscheidungen kümmert, ist anfällig für Fehler, weil die Rolle zu viel auf einmal erfordert. Die gleiche Schwäche tritt bei monolithischen KI-Agenten auf, die komplexe, mehrstufige Arbeitsabläufe ausführen sollen. Sie verlieren den Kontext, überspringen Schritte und liefern unsichere Argumente, was zu unzuverlässigen Ergebnissen führt.
Ein stärkerer Ansatz besteht darin, die KI als beaufsichtigtes Workforce von Spezialisten zu strukturieren, das für Ordnung und Verantwortlichkeit sorgt. Dies spiegelt die Zusammenarbeit von Experten wider und führt zu konsistenteren, überprüfbaren Entscheidungen in wichtigen Bereichen wie der Kreditvergabe. In diesem Artikel bauen wir ein solches koordiniertes System auf, nicht als einzelner überarbeiteter Agent, sondern als diszipliniertes Workforce.
Was ist ein Supervisor Agent?
Ein Supervisor-Agent ist kein besonderer Agent mehr, sondern der Organisator eines Groups anderer Agenten, die an einer Aufgabe arbeiten. Betrachten Sie es als Ihren Abteilungsleiter KI Arbeitskräfte.
Zu seinen Hauptaufgaben gehören:
- Aufgabenzerlegung und Delegation: Der Vorgesetzte nimmt eine eingehende Anfrage entgegen und zerlegt sie in logische Unteraufgaben, die dann an den entsprechenden spezialisierten Agenten weitergeleitet werden.
- Workflow-Orchestrierung: Die Reihenfolge der Operationen ist streng. Im Fall unserer Kreditprüfung bedeutet das den Abruf von Daten, die Überprüfung der Richtlinien und erst danach eine Empfehlung.
- Qualitätskontrolle: Es prüft vor dem nächsten Schritt die Leistung jedes Employee-Agenten, um festzustellen, ob sie dem erforderlichen Normal entspricht.
- Ergebnissynthese: Sobald alle Arbeiteragenten fertig sind, nimmt der Vorgesetzte die Ergebnisse der Arbeiter und fasst sie zusammen, um ein endgültiges, kohärentes Ergebnis zu erzielen.
Das Ergebnis dieses Musters sind robustere, skalierbarere und einfacher zu debuggende Systeme. Den Agenten wird eine Aufgabe zugewiesen, was ihre Logik vereinfacht und ihre Leistungsstabilität erhöht.
Praktisch: Kreditprüfungen mit einem Vorgesetzten automatisieren
Das System zur ersten Überprüfung der Automatisierung von Kreditanträgen wird derzeit aufgebaut. Unser Ziel ist es, den Personalausweis eines Bewerbers zu erfassen, ihn im Hinblick auf die Risikorichtlinien des Unternehmens zu bewerten und ihn zu einer konkreten Maßnahme zu beraten.
Unser KI-Workforce besteht aus:
- Fallaufnahmebeauftragter: Spezialist an der Rezeption. Es sammelt die Finanzinformationen des Antragstellers und erstellt eine Zusammenfassung.
- Risikorichtlinien-Checker-Agent: Der Analytiker. Es gleicht die Informationen des Antragstellers mit einer Reihe vorab festgelegter Kreditvergabekriterien ab.
- Kreditentscheidungsagent: Der Entscheider. Es nimmt die Erkenntnisse auf und schlägt eine endgültige Vorgehensweise vor, beispielsweise die Genehmigung oder Ablehnung des Kredits.
- Der Betreuer: Der Vorgesetzte, der den gesamten Arbeitsablauf übernimmt und dafür sorgt, dass jeder Agent etwas in der richtigen Reihenfolge tut.
Lassen Sie uns dieses Finanzteam aufbauen.
Schritt 1: Abhängigkeiten installieren
Unser System wird auf LangChain, LangGraph und OpenAI basieren. LangGraph ist eine Bibliothek, die zur Erstellung zustandsbehafteter Multi-Agent-Workflows entwickelt wurde.
!uv pip set up langchain==1.2.4 langchain-openai langchain-community==0.4.1 langgraph==1.0.6 Schritt 2: API-Schlüssel und Umgebung konfigurieren
Richten Sie Ihren OpenAI-API-Schlüssel ein, um unsere Sprachmodelle zu betreiben. In der Zelle unten werden Sie aufgefordert, Ihren Schlüssel sicher einzugeben.
import os
import getpass
# OpenAI API Key (for chat & embeddings)
if not os.environ.get("OPENAI_API_KEY"):
os.environ("OPENAI_API_KEY") = getpass.getpass(
"Enter your OpenAI API key (https://platform.openai.com/account/api-keys):n"
)Schritt 3: Importe
Die Definition des Zustands, der Instruments und Agenten erfordert mehrere Elemente unserer Bibliotheken.
from typing import Annotated, Literal
from typing_extensions import TypedDict
from langgraph.graph.message import add_messages
from langgraph.graph import StateGraph, START, END
from langchain_openai import ChatOpenAI
from langgraph.varieties import Command
from langchain_core.instruments import software
from langchain_core.messages import HumanMessage, SystemMessage, AIMessage
from langchain.brokers import create_agent
from IPython.show import show, MarkdownSchritt 4: Die Geschäftslogik – Datensätze
Wir werden unser System mit einfachen In-Reminiscence-Daten betreiben, die eine Darstellung von Risikorichtlinien, Kreditempfehlungen und Antragstellerdatensätzen darstellen. Dies macht unser Beispiel in sich geschlossen und einfach zu befolgen.
risk_policies = (
{
"loan_type": "Dwelling Mortgage",
"risk_category": "Low Danger",
"required_conditions": (
"credit_score >= 750",
"stable_income >= 3 years",
"debt_to_income_ratio < 30%"
),
"notes": "Eligible for greatest rates of interest and fast-track approval."
},
{
"loan_type": "Dwelling Mortgage",
"risk_category": "Medium Danger",
"required_conditions": (
"credit_score >= 680",
"stable_income >= 2 years",
"debt_to_income_ratio < 40%"
),
"notes": "Might require collateral or greater rate of interest."
},
{
"loan_type": "Private Mortgage",
"risk_category": "Medium Danger",
"required_conditions": (
"credit_score >= 650",
"stable_income >= 2 years"
),
"notes": "Guide verification beneficial for revenue consistency."
},
{
"loan_type": "Auto Mortgage",
"risk_category": "Low Danger",
"required_conditions": (
"credit_score >= 700",
"stable_income >= 2 years"
),
"notes": "Car acts as secured collateral."
}
)
loan_recommendations = (
{
"risk_category": "Low Danger",
"next_step": "Auto approve mortgage with commonplace or greatest rate of interest."
},
{
"risk_category": "Medium Danger",
"next_step": "Approve with adjusted rate of interest or require collateral."
},
{
"risk_category": "Excessive Danger",
"next_step": "Reject or request guarantor and extra paperwork."
}
)
applicant_records = (
{
"applicant_id": "A101",
"age": 30,
"employment_type": "Salaried",
"annual_income": 1200000,
"credit_score": 780,
"debt_to_income_ratio": 25,
"loan_type": "Dwelling Mortgage",
"requested_amount": 4500000,
"notes": "Working in MNC for five years. No missed EMI historical past."
},
{
"applicant_id": "A102",
"age": 42,
"employment_type": "Self Employed",
"annual_income": 900000,
"credit_score": 690,
"debt_to_income_ratio": 38,
"loan_type": "Dwelling Mortgage",
"requested_amount": 3500000,
"notes": "Enterprise revenue fluctuates however secure final 2 years."
},
{
"applicant_id": "A103",
"age": 27,
"employment_type": "Salaried",
"annual_income": 600000,
"credit_score": 640,
"debt_to_income_ratio": 45,
"loan_type": "Private Mortgage",
"requested_amount": 500000,
"notes": "Latest job change. Bank card utilization excessive."
}
)Schritt 5: Erstellen der Instruments für unsere Agenten
Jeder Agent benötigt Geräte, um mit unseren Daten zu kommunizieren. Sie sind schlicht Python Funktionen, die mit dem Python-Dekorationstool geschmückt sind; die von der aufgerufen werden LLM wenn man ihn auffordert, bestimmte Dinge zu tun.
llm = ChatOpenAI(
mannequin="gpt-4.1-mini",
temperature=0.0,
timeout=None
)
@software
def fetch_applicant_record(applicant_id: str) -> dict:
"""
Fetches and summarizes an applicant monetary report based mostly on the given applicant ID.
Returns a human-readable abstract together with revenue, credit score rating, mortgage sort,
debt ratio, and monetary notes.
Args:
applicant_id (str): The distinctive identifier for the applicant.
Returns:
dict: {
"applicant_summary": str
}
"""
for report in applicant_records:
if report("applicant_id") == applicant_id:
abstract = (
"Right here is the applicant monetary abstract report:n"
f"Applicant ID: {report('applicant_id')}n"
f"Age: {report('age')}n"
f"Employment Sort: {report('employment_type')}n"
f"Annual Revenue: {report('annual_income')}n"
f"Credit score Rating: {report('credit_score')}n"
f"Debt-to-Revenue Ratio: {report('debt_to_income_ratio')}n"
f"Mortgage Sort Requested: {report('loan_type')}n"
f"Requested Quantity: {report('requested_amount')}n"
f"Monetary Notes: {report('notes')}"
)
return {"applicant_summary": abstract}
return {"error": "Applicant report not discovered."}
@software
def match_risk_policy(loan_type: str, risk_category: str) -> dict:
"""
Match a given mortgage sort and threat class to essentially the most related threat coverage rule.
Args:
loan_type (str): The mortgage product being requested.
risk_category (str): The evaluated applicant threat class.
Returns:
dict: A abstract of one of the best matching coverage if discovered, or a message indicating no match.
"""
context = "n".be part of((
f"{i+1}. Mortgage Sort: {p('loan_type')}, Danger Class: {p('risk_category')}, "
f"Required Circumstances: {p('required_conditions')}, Notes: {p('notes')}"
for i, p in enumerate(risk_policies)
))
immediate = f"""You're a monetary threat reviewer assessing whether or not a mortgage request aligns with present lending threat insurance policies.
Directions:
- Analyze the mortgage sort and applicant threat class.
- Examine towards the checklist of offered threat coverage guidelines.
- Choose the coverage that most closely fits the case contemplating mortgage sort and threat degree.
- If none match, reply: "No applicable threat coverage discovered for this case."
- If a match is discovered, summarize the matching coverage clearly together with any required monetary situations or caveats.
Mortgage Case:
- Mortgage Sort: {loan_type}
- Danger Class: {risk_category}
Out there Danger Insurance policies:
{context}
"""
end result = llm.invoke(immediate).textual content
return {"matched_policy": end result}
@software
def check_policy_validity(
financial_indicators: checklist(str),
required_conditions: checklist(str),
notes: str
) -> dict:
"""
Decide whether or not the applicant monetary profile satisfies coverage eligibility standards.
Args:
financial_indicators (checklist(str)): Monetary indicators derived from applicant report.
required_conditions (checklist(str)): Circumstances required by matched coverage.
notes (str): Further monetary or employment context.
Returns:
dict: A string explaining whether or not the mortgage request is financially justified.
"""
immediate = f"""You're validating a mortgage request based mostly on documented monetary indicators and coverage standards.
Directions:
- Assess whether or not the applicant monetary indicators and notes fulfill the required coverage situations.
- Think about monetary context nuances.
- Present a reasoned judgment if the mortgage is financially justified.
- If not certified, clarify precisely which standards are unmet.
Enter:
- Applicant Monetary Indicators: {financial_indicators}
- Required Coverage Circumstances: {required_conditions}
- Monetary Notes: {notes}
"""
end result = llm.invoke(immediate).textual content
return {"validity_result": end result}
@software
def recommend_loan_action(risk_category: str) -> dict:
"""
Advocate subsequent lending step based mostly on applicant threat class.
Args:
risk_category (str): The evaluated applicant threat degree.
Returns:
dict: Lending advice string or fallback if no match discovered.
"""
choices = "n".be part of((
f"{i+1}. Danger Class: {r('risk_category')}, Advice: {r('next_step')}"
for i, r in enumerate(loan_recommendations)
))
immediate = f"""You're a monetary lending resolution assistant suggesting subsequent steps for a given applicant threat class.
Directions:
- Analyze the offered threat class.
- Select the closest match from recognized lending suggestions.
- Clarify why the match is acceptable.
- If no appropriate advice exists, return: "No lending advice discovered for this threat class."
Danger Class Offered:
{risk_category}
Out there Lending Suggestions:
{choices}
"""
end result = llm.invoke(immediate).textual content
return {"advice": end result}
Schritt 6: Implementierung der Subagenten (der Arbeiter)
Wir stellen jetzt unsere drei Spezialagenten zusammen. Jedem Agenten steht eine äußerst eng gefasste Systemaufforderung zur Verfügung, die ihm sowohl erklärt, was er tun soll und auf welche Instruments er zugreifen darf, als auch, wie er seine Ausgabe strukturieren soll.
case_intake_agent = create_agent(
mannequin=llm,
instruments=(fetch_applicant_record),
system_prompt=r"""
You're a Monetary Case Consumption Specialist.
THIS IS A RULED TASK. FOLLOW THE STEPS IN ORDER. DO NOT SKIP STEPS.
--- MANDATORY EXECUTION RULES ---
- You MUST name the `fetch_applicant_record` software earlier than writing ANY evaluation or abstract.
- For those who don't have applicant information from the software, you MUST cease and say: "Applicant information not out there."
- Do NOT hallucinate, infer, or invent monetary info past what's offered.
- Inference is allowed ONLY when logically derived from monetary notes.
--- STEP 1: DATA ACQUISITION (REQUIRED) ---
Name `fetch_applicant_record` and browse:
- Monetary indicators
- Monetary profile / threat context
- Mortgage request
- Monetary notes
It's possible you'll NOT proceed with out this step.
--- STEP 2: FINANCIAL ANALYSIS ---
Utilizing ONLY the retrieved information:
1. Summarize the applicant monetary case.
2. Establish express monetary indicators.
3. Establish inferred monetary dangers (label as "inferred").
4. Derive rationale for why the mortgage could have been requested.
--- STEP 3: VALIDATION CHECK ---
Earlier than finalizing, affirm:
- No monetary info had been added past software output.
- Inferences are financially affordable.
- Abstract is impartial and review-ready.
--- FINAL OUTPUT FORMAT (STRICT) ---
Sub-Agent Title: Case Consumption Agent
Monetary Abstract:
- ...
Key Monetary Indicators:
- Specific:
- ...
- Inferred:
- ...
Monetary Rationale for Mortgage Request:
- ...
If any part can't be accomplished because of lacking information, state that explicitly.
"""
)
lending_decision_agent = create_agent(
mannequin=llm,
instruments=(recommend_loan_action),
system_prompt=r"""
You're a Lending Choice Advice Specialist.
YOU MUST RESPECT PRIOR AGENT DECISIONS.
--- NON-NEGOTIABLE RULES ---
- You MUST learn Consumption Agent and Danger Coverage Checker outputs first.
- You MUST NOT override or contradict the Danger Coverage Checker.
- You MUST clearly state whether or not mortgage request was:
- Accepted
- Not Accepted
- Not Validated
--- STEP 1: CONTEXT REVIEW ---
Establish:
- Confirmed monetary profile / threat class
- Coverage resolution consequence
- Key monetary dangers and constraints
--- STEP 2: DECISION-AWARE PLANNING ---
IF mortgage request APPROVED:
- Advocate subsequent lending execution steps.
IF mortgage request NOT APPROVED:
- Do NOT suggest approval.
- Counsel ONLY:
- Further monetary documentation
- Danger mitigation steps
- Monetary profile enchancment strategies
- Monitoring or reassessment steps
IF coverage NOT FOUND:
- Advocate cautious subsequent steps and documentation enchancment.
--- STEP 3: SAFETY CHECK ---
Earlier than finalizing:
- Guarantee advice doesn't contradict coverage consequence.
- Guarantee all strategies are financially affordable.
--- FINAL OUTPUT FORMAT (STRICT) ---
Sub-Agent Title: Lending Choice Agent
Coverage Standing:
- Accepted / Not Accepted / Not Discovered
Lending Suggestions:
- ...
Rationale:
- ...
Notes for Reviewer:
- ...
Keep away from speculative monetary approvals.
Keep away from recommending approval if coverage validation failed.
"""
)
risk_policy_checker_agent = create_agent(
mannequin=llm,
instruments=(match_risk_policy, check_policy_validity),
system_prompt=r"""
You're a Lending Danger Coverage Evaluation Specialist.
THIS TASK HAS HARD CONSTRAINTS. FOLLOW THEM EXACTLY.
--- MANDATORY RULES ---
- You MUST base choices solely on:
1. Consumption abstract content material
2. Retrieved threat coverage guidelines
- You MUST NOT approve or reject with out a coverage examine try.
- If no coverage exists, you MUST explicitly state that.
- Do NOT infer coverage eligibility standards.
--- STEP 1: POLICY IDENTIFICATION (REQUIRED) ---
Use `match_risk_policy` to determine essentially the most related coverage for:
- The requested mortgage sort
- The evaluated threat class
If no coverage is discovered:
- STOP additional validation
- Clearly state that no relevant coverage exists
--- STEP 2: CRITERIA EXTRACTION ---
If a coverage is discovered:
- Extract REQUIRED monetary situations precisely as said
- Do NOT paraphrase eligibility standards
--- STEP 3: VALIDATION CHECK (REQUIRED) ---
Use `check_policy_validity` with:
- Applicant monetary indicators
- Coverage required situations
- Consumption monetary notes
--- STEP 4: REASONED DECISION ---
Based mostly ONLY on validation end result:
- If standards met → justify approval
- If standards not met → clarify why
- If inadequate information → state insufficiency
--- FINAL OUTPUT FORMAT (STRICT) ---
Sub-Agent Title: Danger Coverage Checker Agent
Danger Coverage Recognized:
- Title:
- Supply (if out there):
Required Coverage Circumstances:
- ...
Applicant Proof:
- ...
Coverage Validation Consequence:
- Met / Not Met / Inadequate Knowledge
Monetary Justification:
- ...
Do NOT suggest lending actions right here.
Do NOT assume approval until standards are met.
"""
)Schritt 7: Der Mastermind – Implementierung des Supervisor-Agenten
Dies ist der Kern unseres Methods. Seine Konstituierung erfolgt durch den Vorgesetzten. Es legt die strenge Reihenfolge des Arbeitsablaufs und die Qualitätsprüfungen fest, die es an der Ausgabe jedes Agenten durchführen muss, bevor es fortfährt.
class State(TypedDict):
messages: Annotated(checklist, add_messages)
members = (
"case_intake_agent",
"risk_policy_checker_agent",
"lending_decision_agent"
)
SUPERVISOR_PROMPT = f"""
You're a Mortgage Evaluation Supervisor Agent.
You're managing a STRICT, ORDERED mortgage threat assessment workflow
between the next brokers:
{members}
--- WORKFLOW ORDER (MANDATORY) ---
1. case_intake_agent
2. risk_policy_checker_agent
3. lending_decision_agent
4. FINISH
You MUST comply with this order. No agent could also be skipped.
--- YOUR RESPONSIBILITIES ---
1. Learn all messages to this point rigorously.
2. Decide which brokers have already executed.
3. Examine the MOST RECENT output of every executed agent.
4. Determine which agent MUST act subsequent based mostly on completeness and order.
--- COMPLETENESS REQUIREMENTS ---
Earlier than shifting to the following agent, confirm the earlier agent’s output incorporates:
case_intake_agent output MUST embody:
- "Monetary Abstract"
- "Key Monetary Indicators"
- "Monetary Rationale"
risk_policy_checker_agent output MUST embody:
- "Coverage Validation Consequence"
- "Monetary Justification"
- Both a coverage match OR express assertion no coverage exists
lending_decision_agent output MUST embody:
- "Coverage Standing"
- "Lending Suggestions"
- Clear approval / non-approval standing
--- ROUTING RULES ---
- If an agent has NOT run but → path to that agent.
- If an agent ran however required sections lacking → route SAME agent once more.
- ONLY return FINISH if all three brokers accomplished accurately.
- NEVER return FINISH early.
--- RESPONSE FORMAT ---
Return ONLY one in all:
{members + ("FINISH")}
"""
FINAL_RESPONSE_PROMPT = """
You're the Mortgage Evaluation Supervisor Agent.
Analyze ALL prior agent outputs rigorously.
--- CRITICAL DECISION RULE ---
Your Ultimate Choice MUST be based mostly PURELY on the output of the
lending_decision_agent.
- If lending_decision_agent signifies mortgage APPROVED
→ Ultimate Choice = APPROVED
- If lending_decision_agent signifies NOT APPROVED or NEEDS INFO
→ Ultimate Choice = NEEDS REVIEW
--- OUTPUT FORMAT (STRICT) ---
- Agent Title: Mortgage Evaluation Supervisor Agent
- Ultimate Choice: APPROVED or NEEDS REVIEW
- Choice Reasoning: Based mostly on lending_decision_agent output
- Lending advice or different steps: From lending_decision_agent
"""
class Router(TypedDict):
subsequent: Literal(
"case_intake_agent",
"risk_policy_checker_agent",
"lending_decision_agent",
"FINISH"
)
def supervisor_node(state: State) -> Command(
Literal(
"case_intake_agent",
"risk_policy_checker_agent",
"lending_decision_agent",
"__end__"
)
):
messages = (SystemMessage(content material=SUPERVISOR_PROMPT)) + state("messages")
response = llm.with_structured_output(Router).invoke(messages)
goto = response("subsequent")
if goto == "FINISH":
goto = END
messages = (SystemMessage(content material=FINAL_RESPONSE_PROMPT)) + state("messages")
response = llm.invoke(messages)
return Command(
goto=goto,
replace={
"messages": (
AIMessage(
content material=response.textual content,
identify="supervisor"
)
),
"subsequent": goto
}
)
return Command(goto=goto, replace={"subsequent": goto})Schritt 8: Definieren der Knotenfunktionen
Hier müssen die Knotenfunktionen definiert werden, die die Rolle von Laggraph-Knoten übernehmen.
def case_intake_node(state: State) -> Command(Literal("supervisor")):
end result = case_intake_agent.invoke(state)
return Command(
replace={
"messages": (
AIMessage(
content material=end result("messages")(-1).textual content,
identify="case_intake_agent"
)
)
},
goto="supervisor"
)
def risk_policy_checker_node(state: State) -> Command(Literal("supervisor")):
end result = risk_policy_checker_agent.invoke(state)
return Command(
replace={
"messages": (
AIMessage(
content material=end result("messages")(-1).textual content,
identify="risk_policy_checker_agent"
)
)
},
goto="supervisor"
)
def lending_decision_node(state: State) -> Command(Literal("supervisor")):
end result = lending_decision_agent.invoke(state)
return Command(
replace={
"messages": (
AIMessage(
content material=end result("messages")(-1).textual content,
identify="lending_decision_agent"
)
)
},
goto="supervisor"
)
Schritt 9: Erstellen und Visualisieren des Diagramms
Nachdem wir nun unsere Knoten definiert haben, können wir das Workflow-Diagramm erstellen. Der Einstiegspunkt, die Knoten jedes Agenten und bedingte Kanten, die den Arbeitsablauf abhängig von der Entscheidung des Vorgesetzten steuern, werden definiert.
graph_builder = StateGraph(State)
graph_builder.add_edge(START, "supervisor")
graph_builder.add_node("supervisor", supervisor_node)
graph_builder.add_node("case_intake_agent", case_intake_node)
graph_builder.add_node("risk_policy_checker_agent", risk_policy_checker_node)
graph_builder.add_node("lending_decision_agent", lending_decision_node)
loan_multi_agent = graph_builder.compile()
loan_multi_agentSie können das Diagramm visualisieren, wenn Sie über die richtigen Bibliotheken verfügen, wir werden es jedoch weiterhin ausführen.
Schritt 10: Ausführen des Methods
Nun zum Second der Wahrheit. Wir bewerben uns als Bewerber in unserem System und folgen dem Vorgesetzten bei der Organisation des Überprüfungsprozesses. Zuvor laden wir eine Hilfsfunktion zum Formatieren der Ausgabe herunter.
# This utility file is just not important to the logic however helps format the streaming output properly.
!gdown 1dSyjcjlFoZpYEqv4P9Oi0-kU2gIoolMB
from agent_utils import format_message
def call_agent_system(agent, immediate, verbose=False):
occasions = agent.stream(
{"messages": (("consumer", immediate))},
{"recursion_limit": 25},
stream_mode="values"
)
for occasion in occasions:
if verbose:
format_message(occasion("messages")(-1))
# Show the ultimate response from the agent as Markdown
print("nnFinal Response:n")
if occasion("messages")(-1).textual content:
show(Markdown(occasion("messages")(-1).textual content))
else:
print(occasion("messages")(-1).content material)
# Return the general occasion messages for non-obligatory downstream use
return occasion("messages")
immediate = "Evaluation applicant A101 for mortgage approval justification."
call_agent_system(loan_multi_agent, immediate, verbose=True)Ausgabeanalyse:
Wenn Sie dies ausführen, wird eine Schritt-für-Schritt-Ausführungsverfolgung angezeigt:
- Vorgesetzter (zum Caseintakeagent): Der Vorgesetzte leitet den Prozess ein, indem er die Aufgabe an den Aufnahmebeauftragten weiterleitet.
- caseintakeagent Ausgabe: Dabei handelt es sich um einen Agenten, der sein Device ausführt, um die Unterlagen des Antragstellers A101 abzurufen und eine saubere Finanzübersicht zu erstellen.
- Supervisor -> RiskPolicyCheckerAgent: Der Vorgesetzte bemerkt, dass die Aufnahme erfolgt ist und leitet die Aufgabe an den Richtlinienprüfer weiter.
- Ausgabe von riskpolicycheckeragent: Der Versicherungsagent wird feststellen, dass es sich bei A101 um eine Police mit geringem Risiko handelt, die alle Profilanforderungen an ein Eigenheimdarlehen erfüllt.
- Supervisor -> Kreditentscheidungsagent: Der Vorgesetzte stiftet nun den obersten Entscheidungsträger an.
- lendingdecisionagent Ausgabe: Dieser Agent empfiehlt eine automatische Genehmigung in der Kategorie „Geringes Risiko“.
- Betreuer -> ENDE: Wenn der Vorgesetzte erreicht BEENDENbehandelt es den letzten Employee als abgeschlossen und erstellt eine kumulative Zusammenfassung.
Das Endprodukt wird eine intestine geschriebene Nachricht sein, frei von jeglichem Schmutz wie:
Colab-Notizbuch: Mastering Supervisor Brokers.ipynb
Abschluss
Mithilfe eines Supervisor-Agenten haben wir einen komplizierten Geschäftsprozess in einen vorhersehbaren, robusten und überprüfbaren Arbeitsablauf umgewandelt. Sogar ein Agent, der versucht, Datenabruf, Risikoanalyse und Entscheidungsfindung gleichzeitig durchzuführen, würde eine viel kompliziertere Eingabeaufforderung benötigen und wäre viel wahrscheinlicher, einen Fehler zu machen.
Das Supervisor-Muster bietet ein starkes mentales Modell und einen architektonischen Ansatz für die Entwicklung fortschrittlicher KI-Systeme. Es ermöglicht Ihnen, Komplexität zu dekonstruieren, eindeutige Verantwortung zuzuweisen und intelligente und automatisierte Arbeitsabläufe zu erstellen, die der Effektivität eines intestine koordinierten menschlichen Groups ähneln. Die zweite Möglichkeit, eine monolithische Herausforderung anzugehen, besteht darin, das nächste Mal nicht nur einen Agenten, sondern ein Workforce zusammenzustellen und immer einen Vorgesetzten zu haben.
Häufig gestellte Fragen
A. Zuverlässigkeit und Modularität sind die Hauptstärken. Das Gesamtsystem lässt sich einfacher erstellen, debuggen und warten, da eine komplexe Aufgabe in kleinere Schritte unterteilt wird, die von spezialisierten Agenten bearbeitet werden, was zu vorhersehbareren und konsistenteren Ergebnissen führt.
A. Ja. Bei diesem Setup weist der Supervisor eine Aufgabe demselben Agenten neu zu, wenn die Ausgabe unvollständig ist. Fortgeschrittenere Vorgesetzte können noch weiter gehen, indem sie eine Fehlerkorrekturlogik hinzufügen oder eine zweite Meinung von einem anderen Agenten einholen.
A. Während es bei komplexen Arbeitsabläufen glänzt, bewältigt dieses Muster auch mäßig komplexe Aufgaben mit nur zwei oder drei Schritten effektiv. Es wendet eine logische Reihenfolge an und macht den Argumentationsprozess der KI deutlich transparenter und überprüfbarer.
Harsh Mishra ist ein KI/ML-Ingenieur, der mehr Zeit damit verbringt, mit großen Sprachmodellen zu sprechen als mit echten Menschen. Leidenschaftlich für GenAI, NLP und die intelligentere Entwicklung von Maschinen (damit sie ihn noch nicht ersetzen). Wenn er nicht gerade Modelle optimiert, optimiert er wahrscheinlich seinen Kaffeekonsum. 🚀☕
Melden Sie sich an, um weiterzulesen und von Experten kuratierte Inhalte zu genießen.