Pydantic AI HTTP tool injection: client, token và test giả

Pydantic AI HTTP tool injection là cách đưa client HTTP, địa chỉ API và thông tin xác thực vào các tool đọc web của agent qua hệ thống dependency của Pydantic AI. Tool không phải tự tạo client hay đọc biến toàn cục. Cách này làm tool dễ test và dễ thay nguồn. Nó không tự bảo vệ token: token vẫn có thể lọt vào log hay vào chính tin nhắn gửi cho mô hình nếu viết sai một dòng. ProxyVN chạy pydantic-ai-slim 2.65.0 ngày 03/11/2026 với một API cục bộ có xác thực, đếm từng chỗ token xuất hiện trong log và trong lịch sử tin nhắn.

Pydantic AI HTTP tool injection: mục tiêu và phạm vi không lặp

Phần đầu chốt bài toán, đầu ra và ranh giới với bài Pydantic đã có.

Bài toán

Một agent tra cứu sản phẩm cần gọi API nội bộ có token. Cách viết vội là tạo httpx client ngay trong tool và đọc token từ biến môi trường. Chạy được, nhưng mỗi lần gọi tool tạo một client mới, test phải chạm mạng thật, và không có cách nào thay API bằng bản giả.

Dependency injection giải quyết cả ba: client tạo một lần, truyền vào agent khi chạy, test thì truyền client giả. Câu hỏi bài trả lời là làm sao để làm đúng, và token có an toàn không.

Đầu ra nghiệm thu

Đầu ra gồm ba thứ. Một là tool trả dữ liệu có kiểu, ở đây là model Product với sku, tên, giá số nguyên, tiền tệ, còn hàng. Hai là bộ test dùng dependency giả, không gọi mạng. Ba là phép kiểm token không xuất hiện trong tool output, trong lịch sử tin nhắn và trong tệp log.

Phân biệt với Pydantic validation

Bài Pydantic chuẩn hóa dữ liệu crawl dùng thư viện Pydantic để kiểm và chuẩn hóa item sau khi crawl. Pydantic AI là framework agent riêng, do cùng nhóm phát triển, dùng Pydantic cho kiểu dữ liệu. Bài này nói về dependency của agent, không viết lại model chuẩn hóa item. Hai thứ có thể dùng cùng nhau: model Product của tool trong bài có thể chính là model đã viết để chuẩn hóa dữ liệu crawl, dùng lại mà không cần định nghĩa hai lần.

Không dùng LLM thật

Lab không gọi mô hình thương mại. Pydantic AI có FunctionModel, một model giả mà mình tự viết hàm quyết định lượt nào gọi tool nào. Nhờ vậy mọi lần chạy đều cho cùng chuỗi lời gọi tool, và kết quả chỉ phản ánh cơ chế dependency.

Nguồn kiểm chứng

Khái niệm đối chiếu với trang Dependencies trong tài liệu Pydantic AI. Lab dùng pydantic-ai-slim 2.65.0, pydantic 2.14.2 và httpx 0.28.1 cài từ PyPI.

Ai nên đọc

Người viết agent bằng Pydantic AI có tool gọi API. Người viết test cho agent và đang phải dựng máy chủ thật để test. Người lo token API lọt vào nơi không nên có, như log hệ thống hay nhà cung cấp mô hình.

Inject client HTTP và credential vào tool đọc web qua dependency của Pydantic AI HTTP tool injection

Phần này giải thích dependency trong Pydantic AI là gì.

deps_type và RunContext

ctx.deps

Khi tạo Agent, khai báo deps_type là kiểu của dependency. Khi chạy, truyền đối tượng thật qua tham số deps của run. Bên trong tool, tham số đầu tiên là RunContext, và ctx.deps chính là đối tượng đó. Pydantic AI không quan tâm bên trong deps có gì, nó chỉ chuyền đối tượng tới tool.

Tài liệu khuyên dùng dataclass để gom nhiều thứ vào một dependency, ví dụ khóa API và client HTTP. Ví dụ trong tài liệu dùng đúng cặp này.

Vì sao không để tool tự tạo client

Tool tự tạo client thì mỗi lần gọi mở kết nối mới, không tái dùng pool, chậm hơn và tốn tài nguyên. Quan trọng hơn, cấu hình như timeout, proxy, header bị chôn trong tool, đổi một chỗ phải sửa nhiều tool. Đưa client vào deps thì cấu hình nằm ở một nơi, nơi tạo client.

Token nên nằm trong client, không nằm trong tool

Lab đặt token vào header mặc định của httpx.AsyncClient khi tạo. Tool không bao giờ thấy token, chỉ gọi client.get. Cách này giảm số chỗ token có thể bị in ra nhầm. Nếu deps có trường token riêng để tool tự ghép, mỗi tool là một chỗ có thể lỡ tay.

Dependency đồng bộ hay bất đồng bộ

Tài liệu Pydantic AI ghi dependency có thể dùng trong cả hàm đồng bộ lẫn bất đồng bộ. Tool async dùng httpx.AsyncClient, tool thường dùng httpx.Client. Lab chọn async vì agent.run là bất đồng bộ và tool gọi mạng hưởng lợi từ việc không chặn vòng lặp sự kiện.

Không trộn hai loại trong cùng một deps nếu không cần. Một tool đồng bộ gọi client bất đồng bộ sẽ không chạy được, còn ngược lại thì phải bọc thêm lớp chuyển đổi.

Instructions cũng đọc được deps

Ngoài tool, hàm instructions của agent cũng nhận RunContext và đọc được deps. Có thể dùng để đưa vào lời dặn mô hình những thông tin như tên cửa hàng hay đơn vị tiền tệ của nguồn đang dùng. Đừng đưa token hay địa chỉ nội bộ vào instructions, vì instructions đi thẳng tới mô hình.

Vòng đời client

Client tạo bằng async with ở chỗ gọi agent. Khi khối async with kết thúc, client đóng, kết nối được giải phóng. Agent và tool không đóng client, vì chúng không sở hữu nó. Lab thử truyền một client đã đóng: tool báo RuntimeError: Cannot send a request, as the client has been closed, và lần chạy dừng.

Lỗi đó rõ ràng, nhưng chỉ xuất hiện khi tool thật sự được gọi. Agent có nhiều tool ít dùng có thể chạy nhiều ngày rồi mới gặp.

Định nghĩa deps dataclass có HTTP client và cấu hình nguồn cho Pydantic AI HTTP tool injection

Phần này mô tả mã của lab.

API cục bộ

Máy chủ http.server ở 127.0.0.1 cổng 9891 trả JSON sản phẩm tại /products/sku. Nó chấp nhận token qua header Authorization dạng Bearer, hoặc qua tham số token trên URL. Sai token trả 401. SKU MLN-404 trả 404, SKU ERR trả 500. Mỗi request được ghi vào nhật ký kèm kết quả xác thực.

Dataclass Deps

@dataclass
class Deps:
    http: httpx.AsyncClient
    base_url: str
    token_in_query: bool = False

Deps có client, địa chỉ gốc của API và một cờ dành riêng cho lab để thử cách truyền token qua URL. Trong ứng dụng thật, cờ này không nên tồn tại.

Model đầu ra của tool

class Product(BaseModel):
    sku: str
    name: str
    price: int
    currency: str
    in_stock: bool

API trả giá dạng chuỗi 1250000 và số tồn kho 7. Tool chuyển giá sang số nguyên và tồn kho sang in_stock dạng đúng sai. Model đi ra là thứ mô hình nhận được, đã sạch và có kiểu.

Nhiều nguồn trong một deps

Agent tra cứu thường cần nhiều nguồn: API sản phẩm, API tồn kho, trang tin. Mỗi nguồn một client riêng với header và timeout riêng, cùng nằm trong một Deps. Tool nào dùng nguồn nào thì đọc client đó. Token của nguồn này không bao giờ đi tới nguồn khác vì nằm trong header của client khác.

Đặt tên trường theo nguồn, như catalog_http và stock_http, thay vì http1 và http2. Đọc tool là biết nó gọi đâu.

Timeout đặt ở client

Lab tạo client với timeout 5 giây. Mọi tool dùng client đều kế thừa timeout này. Nếu một nguồn chậm hơn hẳn, tạo client riêng cho nó với timeout dài hơn, đừng sửa từng lời gọi trong tool. Tham số tool_timeout của Agent là một lớp chặn khác ở tầng agent, không thay timeout của HTTP.

Agent không gắn model cố định

Agent được tạo với deps_type là Deps và retries là 1, không chỉ định model. Model được gắn lúc chạy bằng override. Cách này cho phép cùng một agent chạy với model thật trong ứng dụng và FunctionModel trong test.

Cấu hình nguồn nằm ở deps

base_url nằm trong deps chứ không viết cứng trong tool. Đổi từ API staging sang production, hay từ API thật sang địa chỉ test, chỉ cần đổi deps. Lab dùng cùng tool với ba địa chỉ: API cục bộ, một đường dẫn khác trên API cục bộ, và https://api.example.test cho client giả.

Truy cập dependency trong tool đọc web có typed output với Pydantic AI HTTP tool injection

Phần này là tool và cách điều khiển nó bằng FunctionModel.

Tool get_product

@agent.tool
async def get_product(ctx: RunContext[Deps], sku: str) -> Product:
    r = await ctx.deps.http.get(f"{ctx.deps.base_url}/products/{sku}")
    if r.status_code == 404:
        raise ModelRetry(f"Khong co SKU {sku}")
    if r.is_error:
        raise ModelRetry(f"Nguon tra {r.status_code} cho SKU {sku}")
    d = r.json()
    return Product(sku=d["sku"], name=d["name"], price=int(d["price"]),
                   currency=d["currency"], in_stock=d["stock"] > 0)

Tool đọc client và địa chỉ từ ctx.deps. Kiểu trả về khai báo là Product, Pydantic AI dùng chú thích này để mô tả tool cho mô hình. 404 được trả lại cho mô hình qua ModelRetry với câu ngắn, để mô hình biết SKU không tồn tại.

FunctionModel thay mô hình

def fm(messages, info):
    n = sum(1 for m in messages for p in m.parts if isinstance(p, (ToolReturnPart, RetryPromptPart)))
    if n < len(skus):
        return ModelResponse(parts=[ToolCallPart("get_product", {"sku": skus[n]})])
    return ModelResponse(parts=[TextPart("xong")])

Hàm đếm số kết quả tool đã có trong tin nhắn, gọi tool với SKU tiếp theo, hết SKU thì trả lời xong. Đây là mô hình giả cho kết quả xác định, không có token nào tới nhà cung cấp mô hình.

Kết quả với API thật

Lượt đầu gọi MLN-A1 và MLN-404. Tool trả Product với sku MLN-A1, tên Máy lọc nước A1, giá 1250000 kiểu số, VND, in_stock True. SKU MLN-404 trả về câu Khong co SKU MLN-404 cho mô hình. Nhật ký máy chủ ghi hai request, cả hai xác thực thành công qua header.

Kiểu được kiểm khi trả về

Nếu API trả giá dạng chữ không đổi được sang số, dòng int ném lỗi trong tool. Lỗi xảy ra ở ranh giới dữ liệu, trước khi tới mô hình. Mô hình không bao giờ nhận được một Product sai kiểu, điều quan trọng khi bước sau là so giá hay ghi vào cơ sở dữ liệu.

retries và ModelRetry

Agent trong lab tạo với retries bằng 1. Mỗi lần tool raise ModelRetry, Pydantic AI gửi thông báo lại cho mô hình như một kết quả tool, để mô hình sửa tham số và gọi lại. Số lần cho phép thử lại có giới hạn, vượt quá thì lần chạy dừng với lỗi.

ModelRetry dành cho lỗi mà mô hình sửa được, như SKU không tồn tại hay tham số sai định dạng. Lỗi mà mô hình không sửa được, như máy chủ 500, nên được xử lý bằng thử lại ở tầng HTTP trước, rồi mới báo cho mô hình một câu ngắn nếu vẫn lỗi.

Thử lại ở tầng HTTP

httpx có tham số retries trong transport để thử lại lỗi kết nối. Lỗi 5xx thì phải tự viết vòng thử lại hoặc dùng thư viện riêng. Đặt logic này trong một hàm bọc client ở chỗ tạo deps, để tool chỉ thấy kết quả cuối. Mỗi lần thử lại ở tầng này không tốn lượt của mô hình, rẻ hơn nhiều so với ModelRetry.

Banner của thư viện

Lần chạy đầu, pydantic-ai 2.65.0 in một banner lớn ra terminal, gợi ý bật observability. Banner biến mất khi đặt biến môi trường PYDANTIC_AI_NO_BANNER bằng 1, như chính banner hướng dẫn. Trong job chạy tự động, nên đặt biến này để log gọn.

Override dependency bằng client giả trong test với Pydantic AI HTTP tool injection

Phần này là lợi ích lớn nhất của dependency injection.

MockTransport của httpx

MockTransport

def handler(req: httpx.Request):
    if req.headers.get("authorization") != "Bearer test-token":
        return httpx.Response(401, json={"error": "unauthorized"})
    return httpx.Response(200, json={"sku": req.url.path.split("/")[-1], "name": "Gia lap",
                                     "price": "990000", "currency": "VND", "stock": 0})
 
async with httpx.AsyncClient(transport=httpx.MockTransport(handler),
                             headers={"Authorization": "Bearer test-token"}) as c:
    with agent.override(model=script(["SP-1", "SP-2"])):
        await agent.run("Lay thong tin san pham", deps=Deps(c, "https://api.example.test"))

httpx có sẵn MockTransport: mọi request đi tới hàm handler thay vì mạng. Client giả có cùng kiểu với client thật nên Deps nhận nó bình thường. Tool không biết mình đang chạy trong test.

Không cần mock thư viện

Một số người test agent bằng cách vá hàm httpx.AsyncClient.get bằng thư viện mock. Cách đó gắn test vào chi tiết cài đặt: đổi get thành request là test hỏng. MockTransport nằm ở tầng vận chuyển, tool gọi hàm nào của client cũng đi qua handler. Test vì thế bền hơn khi tool được viết lại.

Kết quả với client giả

Agent gọi SP-1 và SP-2. Tool trả hai Product tên Gia lap, giá 990000, in_stock False vì stock bằng 0. handler ghi nhận đúng hai URL https://api.example.test/products/SP-1 và SP-2. Không có request nào ra mạng, không cần máy chủ chạy.

Test được những gì

Với client giả, test kiểm được tool ghép URL đúng, gửi header đúng, chuyển kiểu đúng, xử lý 404 và 401 đúng. Test cũng kiểm được hành vi khi API trả dữ liệu lạ, như giá rỗng hay trường thiếu, chỉ bằng cách đổi handler. Những tình huống này rất khó dựng với API thật.

Khẳng định số request trong test

Danh sách calls mà handler ghi lại là bằng chứng cho test. Sau mỗi lần chạy, khẳng định số phần tử và nội dung URL. Một thay đổi vô tình làm tool gọi API hai lần cho mỗi SKU sẽ bị bắt ngay, trước khi nó làm tăng gấp đôi hóa đơn API thật.

Token giả dễ nhận ra

Test dùng token dạng test-token, khác hẳn token thật. Lab dùng token giả cho API cục bộ có dạng tk_live kèm chuỗi hex để giống token thật, dễ tìm trong log. Khi kiểm rò rỉ, tìm đúng chuỗi đó. Không bao giờ dùng token thật trong test, kể cả token của môi trường staging.

override cho cả model và deps

Agent.override nhận cả model lẫn deps. Tài liệu Pydantic AI mô tả override deps để test mã ứng dụng gọi agent ở tầng sâu, khi test không truyền deps trực tiếp được. Lab dùng override cho model và truyền deps qua run, vì gọi agent trực tiếp.

Dựng tình huống lỗi bằng handler

handler có thể trả 500, trả JSON thiếu trường, trả chậm bằng cách ném lỗi timeout của httpx. Mỗi tình huống một test. Lab dùng máy chủ thật cho tình huống 500 để quan sát thông báo lỗi thật của httpx, nhưng trong bộ test thường ngày, handler là đủ và chạy nhanh hơn nhiều.

Một test đáng có là API trả 401. Tool khi đó không nên ModelRetry, vì mô hình không sửa được token. Nó nên ném lỗi rõ ràng để người vận hành biết token hết hạn.

Test không phụ thuộc thứ tự

Mỗi test tạo client giả riêng với handler riêng. Không chia sẻ trạng thái giữa các test. Với agent có nhiều tool, mỗi tool có thể có handler riêng theo đường dẫn, gom trong một hàm handler phân nhánh theo req.url.path.

Kiểm token không vào tool output hoặc log và đóng client đúng vòng đời trong Pydantic AI HTTP tool injection

Đây là phần quan trọng nhất về bảo mật.

Bảng kết quả kiểm token

Token lọt ở đâu

Bảng: Bảng kết quả kiểm token

Kịch bản	Token trong tin nhắn	Token trong app.log
Token trong header, tool trả Product hoặc ModelRetry ngắn	Không	Không
Token trong tham số URL, request thành công	Không	Có, do logger httpx
Token trong URL, 500, không bắt lỗi	Có, trong thông báo ngoại lệ	Có
Token trong URL, 500, ModelRetry với nguyên văn ngoại lệ	Có, gửi cho mô hình	Có
Token trong URL, 500, ModelRetry với câu tự viết	Không	Có, do logger httpx

Logger của httpx ghi cả URL

Lab bật logging ở mức DEBUG ra tệp app.log. Logger httpx ghi mỗi request một dòng dạng HTTP Request: GET kèm URL đầy đủ và mã trạng thái. Khi token nằm trong tham số URL, dòng log chứa nguyên token, ví dụ token=tk_live_9f3a7c21e8. Khi token nằm trong header, dòng log không có token.

Đây là lý do mạnh nhất để không bao giờ đặt token trên URL. Log hệ thống thường được gom về một nơi mà nhiều người đọc được. Nếu API đối tác chỉ hỗ trợ token qua URL, hạ mức log của logger httpx ngay từ khi khởi động ứng dụng và thêm bộ lọc che chuỗi token. Đồng thời đề nghị đối tác hỗ trợ header Authorization.

Thông báo lỗi của httpx chứa URL

Với SKU ERR, máy chủ trả 500. raise_for_status ném HTTPStatusError với thông báo Server error 500 Internal Server Error for url, kèm URL đầy đủ. Nếu tool không bắt lỗi, ngoại lệ đi ra khỏi agent với nguyên URL, và bất cứ chỗ nào ghi ngoại lệ đều ghi luôn token.

ModelRetry nguyên văn gửi token cho mô hình

Cách bắt lỗi phổ biến là raise ModelRetry với str của ngoại lệ, để mô hình biết lỗi gì. Lab cho thấy cách này đưa nguyên URL có token vào ToolReturnPart, tức là vào tin nhắn gửi cho mô hình ở lượt sau. Với mô hình thật, token rời khỏi hệ thống của mình và đi tới nhà cung cấp mô hình.

Cách an toàn là tự viết câu báo lỗi chỉ gồm mã trạng thái và tham số nghiệp vụ, như Nguon tra 500 cho SKU ERR. Lab xác nhận lịch sử tin nhắn khi đó không chứa token.

Vì sao log ở mức INFO vẫn nguy hiểm

Nhiều người nghĩ chỉ log DEBUG mới chi tiết. Dòng HTTP Request của httpx được ghi ở mức INFO, tức là xuất hiện trong cấu hình log phổ biến của nhiều ứng dụng. Thư viện khác như urllib3 cũng có thói quen ghi URL. URL vì thế không bao giờ là chỗ an toàn cho bí mật, bất kể mức log.

Kiểm bằng tìm chuỗi

Phép kiểm trong lab đơn giản: chuyển toàn bộ lịch sử tin nhắn ra JSON bằng all_messages_json, tìm chuỗi token. Làm tương tự với tệp log. Đưa phép kiểm này vào test tự động với một token giả có dạng dễ nhận ra. Bất kỳ thay đổi nào làm token lọt ra sẽ làm test đỏ.

Observability có thể ghi tham số tool

Pydantic AI tích hợp OpenTelemetry và Logfire để theo dõi từng lời gọi mô hình và tool. Công cụ theo dõi thường ghi tham số và kết quả tool. Nếu tham số hay kết quả có dữ liệu nhạy cảm, nó sẽ nằm trong hệ thống theo dõi. Với thiết kế token trong header của client, tham số tool chỉ có SKU, không có gì nhạy cảm.

Trước khi bật theo dõi trên production, chạy phép tìm chuỗi token trên dữ liệu theo dõi giống như trên log.

Token hết hạn

Token có hạn ngắn cần được làm mới. Đặt logic làm mới vào client, qua một lớp xác thực tùy biến của httpx, thay vì để tool kiểm tra hạn. Tool vẫn chỉ gọi client.get, client tự gắn token còn hạn. Lab không thử phần này, nhưng cấu trúc deps không cần đổi gì để thêm vào.

Đóng client đúng chỗ

Client tạo bằng async with ở tầng gọi agent, sống đúng bằng thời gian cần. Với ứng dụng web, client nên tạo một lần khi ứng dụng khởi động và đóng khi tắt, truyền cùng một client vào mọi lần chạy agent. Tạo client mới cho mỗi yêu cầu thì mất lợi ích của pool kết nối.

Đầu ra nghiệm thu: tool trả dữ liệu có kiểu, dependency giả khi test và log không lộ token với Pydantic AI HTTP tool injection

Phần cuối gom lại bộ bàn giao và vai trò của proxy.

So với cách viết không có deps

Cùng tool viết theo kiểu tự tạo client và đọc token từ biến môi trường cũng chạy được với API cục bộ. Nhưng để test nó không chạm mạng, phải vá module httpx hay dựng máy chủ giả. Với deps, test chỉ cần một handler vài dòng. Khoảng cách này lớn dần theo số tool và số nguồn của agent.

Bộ bàn giao

Bộ bàn giao gồm dataclass Deps, tool có kiểu trả về rõ ràng, hàm tạo client thật với token trong header, bộ test dùng MockTransport và FunctionModel, và phép kiểm token trên tin nhắn và log. Kèm phiên bản pydantic-ai, pydantic và httpx đã dùng.

Giới hạn của lab

Lab dùng FunctionModel, không dùng mô hình thật. Hành vi của mô hình thật khi nhận ModelRetry, như có gọi lại tool không và gọi bao nhiêu lần, chưa được thử. Lab chỉ thử httpx, chưa thử thư viện HTTP khác. Logging bật ở mức DEBUG, ứng dụng thật thường để INFO, nhưng dòng log request của httpx cũng xuất hiện ở INFO.

Dữ liệu nhạy cảm trong output

Token không phải thứ duy nhất cần giữ. Nếu API trả về email khách hàng, số điện thoại hay địa chỉ, và tool trả nguyên JSON cho mô hình, những dữ liệu đó đi tới nhà cung cấp mô hình. Model Product của lab chỉ giữ năm trường cần thiết. Kiểu trả về hẹp là cách tự nhiên để không gửi thừa dữ liệu.

Nhiều lần chạy chia sẻ một client

Ứng dụng phục vụ nhiều người dùng chạy agent song song. Một AsyncClient dùng chung cho mọi lần chạy là an toàn với httpx và tận dụng pool kết nối. Điều không nên chia sẻ là token theo người dùng: nếu mỗi người dùng có token riêng, mỗi lần chạy cần deps riêng với client hoặc header riêng.

Lọc log như lớp bảo vệ thứ hai

Ngoài việc không đặt token trên URL, có thể thêm bộ lọc logging thay chuỗi token bằng dấu sao trước khi ghi. Bộ lọc là lưới an toàn, không thay được thiết kế đúng. Cũng nên hạ mức log của httpx xuống WARNING ở môi trường production nếu không cần từng dòng request.

Khi nào cần proxy với Pydantic AI HTTP tool injection

Proxy là cấu hình của client, nên nó thuộc về chỗ tạo client, không thuộc về tool. httpx nhận tham số proxy khi tạo AsyncClient. Đổi proxy chỉ cần đổi deps, tool giữ nguyên, đúng tinh thần của dependency injection.

Proxy cần khi agent chạy trong mạng chỉ ra ngoài qua proxy, hoặc khi API nguồn chỉ cho phép một IP cố định. Chuỗi proxy có mật khẩu cũng là một dạng bí mật: đừng ghép nó vào URL ghi log, đừng đưa nó vào tin nhắn. Cách dùng proxy với httpx có trong bài httpx proxy, còn bài proxy cho AI agent tự động bàn việc chọn loại proxy cho agent. Khi cần IP tĩnh tại Việt Nam để API đối tác đưa vào danh sách cho phép, anh em có thể mua proxy tĩnh Việt Nam tại trang chủ ProxyVN.

Checklist Pydantic AI HTTP tool injection

Checklist deps

• Gom client, địa chỉ nguồn vào một dataclass Deps.
• Token nằm trong header mặc định của client, không trên URL.
• Tool khai báo kiểu trả về là model Pydantic.
• Báo lỗi cho mô hình bằng câu tự viết, không dùng nguyên văn ngoại lệ.
• Test bằng MockTransport và FunctionModel, không chạm mạng.
• Tìm chuỗi token giả trong tin nhắn và log trong test.
• Tạo và đóng client ở tầng sở hữu nó.
• Proxy cấu hình ở client, không ở tool.

Câu hỏi thường gặp về Pydantic AI HTTP tool injection

Dependency trong Pydantic AI là gì?

Là đối tượng truyền qua tham số deps khi chạy agent, tool đọc bằng ctx.deps. Thường là một dataclass chứa client và cấu hình.

Làm sao test agent không gọi mạng?

Truyền httpx client dùng MockTransport vào deps và dùng FunctionModel thay mô hình thật.

Token có thể lọt ra đâu?

Lab thấy hai chỗ: log của httpx khi token nằm trên URL, và tin nhắn gửi mô hình khi bọc lỗi bằng nguyên văn ngoại lệ.

Có nên để tool tự tạo client không?

Không nên. Client nên tạo một lần, cấu hình ở một nơi, truyền vào qua deps.

Truyền client đã đóng thì sao?

Tool báo RuntimeError Cannot send a request, as the client has been closed khi được gọi.

Proxy đặt ở đâu?

Ở chỗ tạo httpx client, qua tham số proxy. Tool không cần biết.

Pydantic AI HTTP tool injection và những điều cần nhớ

Pydantic AI HTTP tool injection giúp tool đọc web dễ test và dễ đổi nguồn: lab ngày 03/11/2026 chạy cùng tool với API thật và MockTransport mà không sửa dòng nào. Nhưng token đặt trên URL lọt vào log httpx, và ModelRetry nguyên văn gửi token cho mô hình. Giữ token trong header, tự viết câu báo lỗi. Cần IP tĩnh cho Pydantic AI HTTP tool injection, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.