Yapay Zekâ Asistanlarınızın Araçları da Karar Verebilir.

Bir LLM‘ye araçlar vererek onu bir ajansa dönüştürüyoruz.

Araçlar ajansın bir şeyi araştırmasına, API çağırmasına ve eyleme geçmesine olanak tanır. Bildiğiniz prosedür: ajans muhakeme eder, araçlar uygular.

Genellikle her aracı küçük bir işlemi yerine getirmek üzere tasarlarız.

Büyük bir göreve karşı ajans genellikle bunu bir döngü içinde çözmek zorundadır: önce bir aracı çağırır, sonuca göre ne yapması gerektiğine karar verir, belki başka bir aracı çağırır.

Ama mesele şu: bu ara kararların çoğu o kadar da zor değil. Sık sık ajans, son aracın döndürdüğü sonuca göre açık sonraki adımı seçer. Yine de bu kararı kendisi vermek zorundadır ve her bir gidiş-dönüş başka bir LLM çağrısıdır; bu da işe zaman ve maliyet ekler.

O halde tüm bir işi tek bir araç çağrısıyla teslim edebilirsek?

Bir karar modeliyle evet, bu mümkün! Ve işte nasıl yapıldığı.

Özünde, akışı karar modelinin yönlendirmesini sağlarız: araç içinde bir eylem seçer ve geri döneni inceler. Sonuca göre bir sonraki hamleyi belirler. Bu döngü, ajansa geri verebilecek kadar kanıt elde edene kadar sürer.

Karar modelleri hızlı ve ucuz kararlar almak için eğitildiğinden, rutin adımlar artık zaman ve maliyetin çok daha küçük bir kısmıyla halledilebilir. Ajans gerçekten yalnızca bir araç çağrısı yapar ve muhakemesini gerektiği yerde yoğunlaştırabilir.

İşte yeni prosedür: ajans işi devreder, araç adımları yönetir.

Karar modeli, ajansın çağrdığı bir aracın içine gömüldüğü için buna karar-modeli-bir-araç-olarak deseni diyoruz.

Bu yazıda bu deseni somutlaştıracağız. Bir müşteri-hizmet ajansı kurma örneği üzerinden gideceğiz; bu ajans geciken bir siparişi soruşturacak ve müşterinin teslimat süresini karşılayacak bir yol bulacak. Ajansa içinde bir karar modeli barındıran bir sipariş-uzmanı aracı vereceğiz.

Bu kararları araca taşımak değer mi? Gelin birlikte görelim.

1. Kurmak İstediğimiz Ajans

Müşterinin ajansımıza şu isteği gönderdiğini varsayalım:

Siparişim ORD-1042 hâlâ sevk edilmedi ve pazartesi, 23 Ekim’e kadar buna ihtiyacım var. Ne olduğunu öğrenebilir ve zamanında elimize ulaşması için bir yol bulabilir misiniz?

Saplanması gereken iki konu var: siparişin neden geciktiği ve başka bir sevkiyat seçeneğinin bu son tarihe uyup uymayacağı. Ajanın soruşturması ve sonraki adımları önermesi gerekir.

1.1 Ajanın ne sorgulayabilir?

Bu çalışma örneği için, destek ajanının erişimi olabilen işlemleri temsil eden altı Python fonksiyonunu kullanacağız:

• get_order_details(): Sipariş durumu, ürün, varış yeri, depo ve takip kimliklerini sağlar;

• get_tracking_events(): Taşıyıcı olayları ve varsa teslimat tahmini içerir;

• get_fulfillment_notes(): Gecikmeyi açıklayabilecek depo notları;

• get_alternative_inventory(): Aynı ürünün diğer depolardaki stok durumu;

• get_shipping_options(): Teslimat tahminleri, ek ücretler ve sevkiyat kesin süreleri;

• get_fulfillment_policy(): Siparişi yönlendirme ve sevkiyat ek ücretlerini kaldırma kuralları.

Bu fonksiyonlar yalnızca, özenle hazırladığım küçük, sentetik bir veri setinden bilgi alır.

Şimdi, geleneksel bir ajan kuruyorsak, ne yapardık?

Bu altı fonksiyonu araç olarak sunarız, değil mi? Bu kesinlikle işe yarayabilir.

Ancak ajanın soruşturmanın her adımını yönetmesi mi gerekli?

1.2 Ajanı tek bir araçla mı donatırız?

Önce tipik bir soruşturmanın neleri içerdiğine bakalım.

Gecikmiş bir sipariş için ajan şöyle ilerleyebilir: siparişi kontrol et → depo notlarını oku → başka yerde stok ara → sevkiyat seçeneklerini karşılaştır → yönlendirme politikasını kontrol et. Başka bir sipariş farklı bir yol izleyebilir.

Ancak sorgulamalar arasında ne olduğuna dikkatle bakın. Her seferinde ajan aynı türde bir soruyu yanıtlıyor:

Sorun ve şimdiye kadar toplanan kanıtlar verildiğinde, bir sonraki sorgulama ne olmalı, yoksa bu yeterli mi?

Bu nedenle soruşturma aslında ardışık bir dizi karar niteliğindedir. Her biri, şimdiye kadar edinilen bilgiler ışığında, mevcut seçeneklerden birini belirler.

Olayı tam olarak buna göre tasarlanmış bir karar modeli vardır: belirli bir bağlam alır, ardından seçeneklerden birini seçer.

Karar modeli bu seçimleri yapabiliyorsa, ajanın tek tek yapması gerekmez. Ajan, sipariş numarası ve bir soru iletilir; araç bu girdiye dayanarak hangi sorgulamaları çalıştıracağına karar verir.

Bu sayede ajan gerçekten yalnızca basit bir arayüz görür ve büyük dil modelinin (LLM) yapması gereken işi—isteği anlama ve yanıtı yazma—üstlenir. Araç arasındaki adımları yönetir.

1.3 Parçaların birbiriyle uyumu

Uzman aracın içinde, her karar noktasında Python, mevcut fonksiyonları ve argümanlarını ayrı ayrı seçenekler olarak, şimdiye kadar toplanan kanıtları ise bağlam olarak hazırlar. Ardından model, bir eylem tanımlayıcısı döndürerek hangi fonksiyonun çalıştırılacağına karar verir. Python karşılık gelen fonksiyonu çağırır ve sonucunu kanıt havuzuna ekler. Bundan sonra Python bir sonraki kararı ister.

Aynı zamanda done (tamamlandı) ve blocked (engellendi) seçeneklerini de dahil ederiz; böylece model yeterli kanıtı biriktirdiğinde işi tamamlayabilir veya mevcut işlemler soruyu çözemediğinde durabilir.

Bu tüm döngü, OpenAI Agents SDK tarafından yönetilen sıradan bir araç çağrısı içinde çalışır. Bu araca order_specialist() adını veririz ve ajanın aracı olarak kaydederiz.

Dikkat edilmesi gereken bir konu var: ajanın bu arka plan işlem fonksiyonlarına doğrudan erişimi yoktur ve söz konusu fonksiyonları çağıramaz. Yalnızca bir aracı, yani order_specialist()’yi görür ve bunu bir sipariş numarası ile bir soru ile çağırabilir. Araç yanıt verdiğinde ajan, toplanan kanıtları kullanarak müşteriye yanıt verir.

Tam etkileşimin nasıl göründüğü şöyle:

Şekil 1. Araç olarak karar modeli örüntüsü. (Diyagram, yazarın)

2. Uzman Aracı İnşa Etmek

Mevcut vaka çalışmamız için karar modeli olarak Azure üzerinde Decision-1’i, LLM ajanını yapılandırmak için ise OpenAI Agents SDK’yı kullanacağız. Ayrıca OpenRouter üzerinden diğer karar modellerinin nasıl çağrılacağını da kısaca göstereceğiz.

Tamamlanmış uygulamayı buradan bulabilirsiniz.

2.1 Soruşturma döngüsüyle başla

Agent order_specialist() çağırduğunda, aşağıdaki döngüyü çalıştırırız:

python

while

True

actions

available_actions(order_id, evidence)

choice, _

=

choose_decision(

http, question, evidence, actions

if

choice

in

{

“done”

“blocked”

}:

return

{

“question”

: question,

“status”

: choice,

“evidence”

list

(evidence),

}

function, arguments

=

actions[choice]

result

=

function(

**

arguments)

evidence.append({

“name”

: function.

__name__

“arguments”

: arguments,

“result”

: result,

})

Yukarıdaki kod parçasında önce kullanılabilir eylemleri hazırlar, ardından karar modelinden soruna ve şimdiye kadar toplanan kanıtlara dayanarak bir seçim yapmasını isteriz. Her eylem tanımlayıcısı bir Python fonksiyonu ve o fonksiyonun argümanlarına karşılık gelir; bu nedenle actions[choice], seçilen sorgulamayı gerçekleştirmek için gereken her şeyi sağlar.

Yürütmeden sonra sonucu kanıtlara ekleriz. Ardından tekrarlarız. Böylece sonraki karar, az önce edindiğimiz bilgiler erişebilir.

Kanıtlar yeterli olduğunda model done seçeneğini de seçebilir. Ya da kullanılabilir işlemler sorunu çözemediğinde model blocked seçeneğini seçebilir. Her iki durumda da döngü sonlanır ve toplanan kayıtları agent’a geri döndürür.

O halde actions içine ne giriyor?

Mevcut_actions() yardımcımız, şu anda erişilebilir bilgileri kullanarak sorgulamaları hazırlar. Başlangıçta sipariş ID’sini bildiğimiz için sipariş detayları, depo notları ve politika sorgulamasını sunabiliriz. Sipariş detayları öğe tanımlayıcısını ortaya çıkardığında, bir stok sorgulaması erişilebilir hale gelir. Depo tanımlayıcıları ve varış yerine sahip olduğumuzda ise sevkiyat sorgulamaları gelir.

Aynı zamanda, daha önce tamamlanmış olan özdeş sorgulamaları kaldırırız. Kanıtlar büyüdükçe, seçimler de onunla birlikte değişir.

2.2 Karar modelinin seçim yapmasına izin ver

Hazırlanan olası eylemlerle, artık bunları karar modelinin önüne koyup bir seçim yapmasını isteyebiliriz. Burada Decision-1’i Azure üzerinden kullanacağız.

İlk olarak, her eylemi bir açıklamaya çeviririz:

choices = {
key: (
f”{function.__name__}({json.dumps(arguments)}): ”
f”{function.__doc__}”
)
for key, (function, arguments) in actions.items()
}

Anhtarlar eylem tanımlayıcılarıdır. Eylemin açıklaması fonksiyon adını, argümanlarını ve docstring’ini içerir. Örneğin, bir sevkiyat sorgulaması şöyle görünecektir:

get_shipping_options({“warehouse_id”: “WEST”, “destination”: “CH-8000”}):

Read shipping estimates, incremental charges, and dispatch cutoff.

Yukarıda belirtildiği gibi, iki durdurma seçeneğini de ekleriz:

choices[“done”] = (
“Return the observed evidence: ”
“it answers the delegated question.”
)

choices[“blocked”] = (
“Return the observed evidence: ”
“available operations cannot answer the question.”
)

Şimdi isteği birleştirebiliriz:

body = {
“model”: “Decision-1”,
“state”: {
“question”: question,
“as_of”:

AS_OF

“evidence”

: evidence,

},

“questions”

: {

“action”

: {

“type”

“choice”

“instructions”

: (

“Bu devredilen soru için bir sonraki faydalı işlemi seçin: “

” +

question

+

” Gözlemlenen kayıtları kullanın ve eksik kanıtları toplayın. “

“Kanıt soruyu yanıtladığında done (tamam) seçin, “

“veya gerekli bir gerçeği elde edebilecek kullanılabilir bir işlem yoksa “

“blocked (tıkandı) seçin.”

),

“criteria”

: choices,

}

},

}

Bu örnekte karar için bağlamı state (durum) tutar. Teslimat süresinin söz konusu olması nedeniyle AS_OF’u, örneğimizdeki güncel zamanı dahil ederiz.

questions altında, action adında bir choice (seçim) sorusu tanımlarız. Its criteria (kriterleri), az önce hazırladığımız seçenekleri içerir. Instructions (yönergeler) bölümü modele görev amacını açıklar.

Bu payload’ı Azure uç noktasına göndeririz:

python

response

=

await

http.post(

AZURE_ENDPOINT

+

“/providers/microsoft/v1/systemone”

json

=

body,

headers

=

{

“api-key”

: os.environ[

“AZURE_API_KEY”

]},

response.raise_for_status()

result

=

response.json()

choice

=

result[

“answers”

][

“action”

][

“choice”

]

yanıt bize seçilen işlem tanımlayıcısını verir. Ardından Python, karşılık gelen fonksiyonu çalıştırır ya da model bir durdurma seçeneğini seçirse kanıtı döndürür.

Böylece dahili bir karar döngüsü yürüten zeki bir araç edinmiş olduk.

2.3 Bonus: Karar için başka bir model deneme

Azure tek seçenek değil. Karar modellerine OpenRouter üzerinden de erişebiliriz; buna GPT-6 Luna Decisions da dahildir:

python

body[

“model”

]

=

“openai/gpt-6-luna-decisions”

response

=

await

http.post(

“https://openrouter.ai/api/alpha/decisions”

json

=

body,

headers

=

{

“Authorization”

“Bearer “

+

os.environ[

“OPENROUTER_API_KEY”

],

},

)

response.raise_for_status()

result

=

response.json()

choice

=

result[

“answers”

][

“action”

][

“choice”

]

Jev’i denemek için yalnızca model tanımlayıcısını typesafe/jev-1.14 olarak değiştirin.

2.4 Aracıya aracıyı verin

Sıradaki adımda, aracıyı bir LLM aracı için kullanılabilir hale getiriyoruz.

order_specialist() fonksiyonunu OpenAI Agents SDK’nın @function_tool dekorörüyle ortaya çıkarıyoruz. Arayüzü şöyle görünüyor:

python

@function_tool

async

def

order_specialist

(

context: RunContextWrapper[

dict

],

order_id:

str

question:

str

) ->

dict

“””Bir sipariş destek sorusunu yanıtlamak için kaynak kayıtları toplayın.

Args:

order_id: Müşterinin sipariş tanımlayıcısı.

question: İlgili müşteri kısıtlamalarını da içeren, sipariş destek kayıtlarından yanıtlanacak soru.

“””

evidence

=

context.context[

“evidence”

]

# Yukarıdaki HTTP bağlantısı ve soruşturma döngüsü.

Aracı, order_id ve question değerlerini sağlar. Docstring, aracıya aracının ne yaptığını ve bu argümanların ne anlama geldiğini söyler.

O halde, soruşturma sırasında kanıtları nasıl saklayabilir ve aracın kararlarını kaydedebiliriz? İşte amacımız budur: context.

Diğer iki argümanın aksine, bağlam LLM yerine SDK tarafından sağlanır. Kayıtları sakladığımız bir Python sözlüğü taşır. RunContextWrapper[dict], o sözlüğün SDK sarmalayıcısıdır ve context.context üzerinden erişiriz.

Aracıyı çalıştıran LLM için Azure üzerinde GPT-6-Luna’yı orta düzey akıl yürütme çabasıyla kullanacağız:

python

from

openai

import

AsyncOpenAI

from

agents

import

Agent, ModelSettings, OpenAIResponsesModel

from

openai.types.shared

import

Reasoning

model

=

OpenAIResponsesModel(

model

=

“gpt-6-luna”

openai_client

=

AsyncOpenAI(

api_key

=

“AZURE_API_KEY”

base_url

=

“https://YOUR_RESOURCE.openai.azure.com/openai/v1/”

),

)

settings

=

ModelSettings(

parallel_tool_calls

=

False

reasoning

=

Reasoning(

effort

=

“medium”

),

)

Ardından aracıya aşağıdaki talimatları veriyoruz:

python

INSTRUCTIONS

=

(

“You are an order-support assistant. “

“Help the customer using the available tools. “

“Base your answer on returned records. “

“Treat shipping dates as estimates, and “

“describe actions that have not been performed as proposals. “

f

“The current fictional time is

{AS_OF}

.”

)

Şimdi aracıyı karar modeli aracımızla yapılandırabiliriz:

python

hybrid_agent

=

Agent(

name

=

“Order support with a decision-model tool”

instructions

=

INSTRUCTIONS

model

=

model,

model_settings

=

settings,

tools

=

[order_specialist],

)

Ajansın yalnızca bir araca erişimi olduğunu unutmayın. Aracın içindeki karar modeli soruşturmayı yönetir.

Şimdi ajansı çalıştırmaya hazırız.

···

3. Ajansı Çalıştır

Ajansı çalıştırmak için:

python

from

agents

import

Runner

hybrid_context

=

{

“evidence”

: [],

“decisions”

: []}

hybrid_result

=

await

Runner.run(

hybrid_agent,

context

=

hybrid_context,

)

Aracımızdaki context parametresini hatırlıyor musunuz? Sözlüğü burada başlatıp ajans çalıştırmasına aktarıyoruz. Araç, retrieved kayıtları evidence içine, dahili seçimleri ve ölçümleri ise decisions içine kaydeder.

Bu çalıştırmada ajansın soruşturmayı tamamladığını görebiliyorum: siparişin neden geciktiğini açıklıyor ve aynı teslimat seçeneğini tespit ediyor.

Bu süreç içinde Luna, siparişteki gecikmeyi araştırmak ve Cuma teslimatını karşılayacak seçenekleri bulmak için order_specialist’i bir kez çağırdı. Araç içinde, Decision-1 done seçmeden önce beş arka plan işlemini seçti:

markdown

get_order_details(“ORD-1042”)

get_fulfillment_notes(“ORD-1042”)

get_alternative_inventory(“LAMP-01”)

get_shipping_options(“WEST”, “CH-8000”)

get_shipping_options(“REMOTE”, “CH-8000”)

done

Tüm çalıştırma 8.9 saniye sürdü.

Şimdi şunu soruyor olabilirsiniz: Bu kararları araca taşıarak aslında ne kadar kazandık? Gelin bunu görelim.

Burada, arka plan işlevlerimize doğrudan erişimi olan başka bir ajans yapılandırdım. Luna modeli, talimatlar ve ayarlar dahil her şey aynı kaldı:

python

llm_agent

=

Agent(

name

=

“Backend araçları ile sipariş desteği”

instructions

=

INSTRUCTIONS

model

=

model,

model_settings

=

settings,

tools

=

[

function_tool(get_order_details),

function_tool(get_tracking_events),

function_tool(get_fulfillment_notes),

function_tool(get_alternative_inventory),

function_tool(get_shipping_options),

function_tool(get_fulfillment_policy),

],

)

Paralel araç çağrıları hâlâ devre dışı olduğu için bu ajan, her adımda tek bir arka uç işlemi seçiyor. Ardından aynı isteği ona tekrar veriyoruz:

python

llm_result

=

await

)

Bu ajan da soruşturmayı tamamlayarak aynı temel öneriye ulaştı, ancak altı kez Luna çağrısı yaptı ve 25,4 saniye aldı. Dolayısıyla, araç-olarak-model karar verme kurulumumuz 2,85 kat daha hızlı çalıştı ve 24,7% daha düşük model maliyeti sundu.

···

4. Son Düşünceler

Çoğu ajan aracı tek bir işlemi sarar ve çoğu zaman bu doğru tercih olur.

Ama ajan aynı birkaç işlemi sürekli birbirine bağladıkça, bunların tamamen o döngüde olması gerekip gerekmediğini sormak için iyi bir zaman gelir.

Bizim durumumuzda, bu rutin kararları araç içine taşımak çalışmayı neredeyse üç kat hızlandırdı ve yaklaşık çeyrek oranında ucuzlattı; ajan yine de aynı öneriye ulaştı.

Sonuç: ajanınız her kararı vermek zorunda değil. Bazıları onun araçlarının içinde yaşayabilir.