← AI-Hands-on AI agent protocols · Part 2 of 7Giao thức AI agent · Phần 2/7

Turning a hard-coded reply into a real reasoning agentBiến câu trả lời cứng thành một agent suy luận thật

A protocol that only echoes hard-coded text is not an agent, it is a script. This walkthrough upgrades the basic A2A server to Google ADK and Gemini, and switches the transport to JSON-RPC 2.0 along the way.

Một giao thức chỉ trả về text cứng có sẵn thì không phải là agent, đó là một đoạn script. Video này nâng cấp server A2A cơ bản lên Google ADK và Gemini, đồng thời đổi giao thức truyền tải sang JSON-RPC 2.0.

Video demo: an LlmAgent backed by Gemini answers through a session-aware Runner.

Video demo: một LlmAgent chạy trên Gemini trả lời qua một Runner có quản lý phiên làm việc.

English

What problem does this solve?

Part 1's server answered every question the same fixed way — useful for learning the protocol, useless for a real product. The moment a business wants an agent to actually reason about a request, the server side needs a language model behind it, and the transport needs to be sturdy enough for production traffic.

This is the step most teams underestimate: swapping in an LLM is easy, but doing it without losing conversation context between calls is the part that actually matters. This walkthrough continues studying the open-source theailanguage/a2a_samples reference implementation.

How the mechanism works

Google ADK splits the agent into two pieces. LlmAgent is the "soul" — the model choice and the system instruction. Runner is the "body" — it manages sessions and memory, so a follow-up question can reference what was asked before instead of starting from zero every time.

On the transport side, the plain REST calls from part 1 are replaced with JSON-RPC 2.0, a stricter contract that's common in service-to-service and multi-agent architectures. When the server receives a request, it hands the message to the Runner, which runs the LLM asynchronously and marks the task completed once Gemini responds.

Trade-offs and alternatives

The benefit is a genuinely reasoning agent that remembers context across a session, not a stateless echo. The trade-off is added latency and cost — every call now involves a real model inference, and the session store has to be managed somewhere (in-memory here, which does not survive a server restart).

An alternative some teams try first is keeping the client responsible for re-sending the full conversation history on every call. That avoids server-side session state, but it pushes complexity and token cost onto every caller instead of solving it once, centrally.

Conclusion

The pattern worth remembering: separate "what the model should do" (the LlmAgent) from "how state is kept between calls" (the Runner). That separation is what turns a one-shot completion API into something that behaves like a conversation.

Tiếng Việt

Vấn đề gì đang được giải quyết?

Server ở phần 1 trả lời mọi câu hỏi theo đúng một cách cố định — hữu ích để học giao thức, nhưng vô dụng cho một sản phẩm thật. Ngay khi doanh nghiệp muốn agent thực sự suy luận về yêu cầu, phía server cần có một mô hình ngôn ngữ đứng sau, và giao thức truyền tải cần đủ chắc chắn cho lưu lượng sản xuất thật.

Đây là bước nhiều đội hay đánh giá thấp: gắn một LLM vào thì dễ, nhưng làm sao không mất ngữ cảnh hội thoại giữa các lượt gọi mới là phần thực sự quan trọng. Video này tiếp tục nghiên cứu bản triển khai tham chiếu mã nguồn mở theailanguage/a2a_samples.

Cơ chế hoạt động ra sao?

Google ADK tách agent thành hai phần. LlmAgent là "linh hồn" — lựa chọn mô hình và chỉ dẫn hệ thống. Runner là "cơ thể" — quản lý phiên làm việc và bộ nhớ, để một câu hỏi tiếp theo có thể tham chiếu điều đã hỏi trước đó thay vì bắt đầu lại từ số 0 mỗi lần.

Về phía truyền tải, các lệnh gọi REST thuần ở phần 1 được thay bằng JSON-RPC 2.0, một hợp đồng chặt chẽ hơn, thường gặp trong kiến trúc dịch vụ-tới-dịch vụ và đa agent. Khi server nhận yêu cầu, nó chuyển tin nhắn cho Runner, Runner chạy LLM bất đồng bộ rồi đánh dấu tác vụ completed khi Gemini trả lời xong.

Đánh đổi và các hướng khác

Cái được là một agent suy luận thật, nhớ ngữ cảnh xuyên suốt một phiên, chứ không phải một bộ lặp lại vô trạng thái. Cái đánh đổi là độ trễ và chi phí tăng lên — mỗi lệnh gọi giờ đều gọi mô hình thật, và nơi lưu phiên phải được quản lý (ở đây là trong bộ nhớ, sẽ mất khi server khởi động lại).

Một hướng khác một số đội thử trước là để client tự gửi lại toàn bộ lịch sử hội thoại mỗi lần gọi. Cách đó tránh được trạng thái phiên phía server, nhưng lại đẩy độ phức tạp và chi phí token sang mọi bên gọi thay vì giải quyết một lần, tập trung.

Kết luận

Mẫu hình đáng nhớ: tách "mô hình nên làm gì" (LlmAgent) khỏi "trạng thái được giữ giữa các lượt gọi ra sao" (Runner). Sự tách bạch đó biến một API hoàn thành một lần thành thứ hoạt động như một cuộc hội thoại thật.