AI Mạnh Hơn, Tool Call Tệ Hơn: Nghịch Lý Claude Opus 4.8 & Sonnet 5

Hai model mới nhất của Anthropic — Opus 4.8 và Sonnet 5 — đều là những bước nhảy về năng lực agentic. Nhưng có một vấn đề kỳ lạ: chúng gọi edit tool tệ hơn model cũ.

Armin Ronacher, người tạo ra Flask và Jinja2, vừa phát hiện điều này trong dự án mã nguồn mở Pi. Anh đã dành 2 ngày debug, và phân tích của anh đáng để mọi developer đang build AI agent phải đọc.

Chuyện Gì Đã Xảy Ra?

Sự việc bắt đầu từ issue #6278 trên repo Pi. Khi dùng Opus 4.8 gọi edit tool của Pi, model liên tục thêm các trường tự phát minh vào object edits[]. Petr Baudis, maintainer Pi, đo được khoảng 20% edit tool calls bị hỏng trong một số phiên.

Điều đáng nói: không phải Haiku hay model nhỏ gây ra lỗi này. Opus 4.8 và Sonnet 5 — hai model mạnh nhất, đắt nhất của Anthropic — mới là thủ phạm. Các model cũ hơn như Opus 4.5 không hề gặp vấn đề tương tự.

Trong bài viết trên blog cá nhân, Ronacher thừa nhận: "Tôi từng khá chắc chúng ta đang đi đúng hướng khi các model ngày càng thích ứng tốt với bất kỳ tool schema nào, miễn là hướng dẫn đủ tốt. Giờ tôi bắt đầu lo ngược lại."

Model Phát Minh Ra Những Gì?

Danh sách key tự phát minh vừa hài hước vừa đáng lo ngại:

• type, id, kind, unique — key chung chung quen thuộc
• requireUnique, matchCase, forceMatchCount — nghe hợp lý, nhưng không tồn tại
• in_file, children, notes, cost — hoàn toàn ngẫu nhiên
• oldText2, newText2, oldText_2, newText_2 — như thể model "nghĩ" cần thêm phần tử
• event.0.additionalProperties — key lồng sâu, y hệt từ JSON schema validator

Điều bực nhất: nội dung oldText và newText trong các lần gọi hỏng chính xác từng byte. Model làm đúng phần khó — viết nội dung edit — rồi nhồi thêm rác vào cuối JSON object khiến schema validation từ chối.

Cơ Chế Tool Calling Của LLM

Đây là phần quan trọng nhất cho developer đang build agent.

Tool calls không phải phép màu. Model nhận transcript, system prompt và danh sách tool. Server nhồi tất cả thành một prompt lớn với marker token đặc biệt. Model sinh output, parser trích xuất tool call. Có 2 cách đảm bảo output hợp lệ:

Cách 1: Sinh tự do, validate sau. Model viết JSON tự do, parser validate. Sai schema → trả lỗi, model thử lại.

Cách 2: Constrained decoding. Sampler chặn token vi phạm schema ngay lúc sinh. Schema chỉ cho phép oldText và newText → sampler không bao giờ sinh ra in_file hay type.

Mỗi cách có trade-off. Constrained decoding đảm bảo output hợp lệ, nhưng có thể giảm chất lượng vì model bị ép vào tập token hẹp. Sinh tự do linh hoạt hơn nhưng dễ gây lỗi schema.

Giả Thuyết Chính: Post-Training Trên Claude Code

Ronacher đưa ra một lý giải thuyết phục: đây không phải regression ngẫu nhiên, mà là hệ quả của post-training.

Model Anthropic cũ được huấn luyện trên tập tool đa dạng, không có harness nào làm "mục tiêu." Model mới (Opus 4.8, Sonnet 5) nhiều khả năng được post-train trong môi trường của Claude Code — một closed-source harness có edit tool riêng với shape khác hẳn Pi.

Điểm mấu chốt: Claude Code client cực kỳ bao dung với tool calls. Ronacher reverse-engineer từ mã minified và tìm thấy:

• Retry paths cho tool calls hỏng
• Parameter aliases (old_str → old_string, path → file_path)
• Type coercions ngầm
• Unicode repair cho chuỗi hỏng
• Silent filtering — bỏ qua key lạ mà không báo lỗi

Hệ quả: harness của Anthropic không bao giờ phạt model khi thêm key dư thừa. Nếu reinforcement learning chạy trong môi trường này, model không nhận "gradient" nào trừng phạt việc sinh key sai. Task vẫn thành công, reward vẫn được cấp.

Model càng ngày càng chuyên biệt hóa cho một tool ecology cụ thể, nhưng mất khả năng thích ứng với schema lạ.

Điều Này Có Ý Nghĩa Gì Với Developer?

Nếu bạn đang build AI agent với custom tools, ba hàm ý sau là cụ thể:

1. Strict Mode Không Phải Xa Xỉ

Anthropic API có strict mode cho tool definition — chặn key lạ ngay từ decoder. Vấn đề: nhiều harness (kể cả Claude Code) không dùng nó vì strict mode áp giới hạn độ phức tạp lên tool definition, có thể khiến API request bị từ chối. Nhưng với custom tool schema đơn giản, bật strict mode là cách bảo vệ rẻ nhất.

2. Closed-Source Harness = Rủi Ro Ngầm

Claude Code là closed-source. Bạn không biết nó parse tool calls ra sao, nó tha thứ những gì, và model đã được train để khai thác những điểm tha thứ đó thế nào. Nếu bạn build harness riêng, model có thể đang "chống lại" schema của bạn vì post-training đã dạy nó một shape khác.

3. OpenAI Đi Hướng Khác

Với Harmony format, OpenAI nhúng marker <|constrain|>json vào chính transcript để báo hiệu "phần này là JSON, constrained sampling." Họ còn hỗ trợ LARK grammar cho custom tools. Đây là giải pháp kiến trúc cho chính xác vấn đề Ronacher mô tả — và là hướng Anthropic chưa công khai giải quyết.

Takeaways

• Opus 4.8 và Sonnet 5 gọi edit tool sai schema ~20% trong một số phiên — model cũ không bị
• Nguyên nhân: post-training trong harness "bao dung" khiến model không bị phạt khi sinh key thừa
• Strict mode trên Anthropic API giải quyết triệt để — nhưng bị giới hạn bởi complexity cap
• OpenAI Harmony format giải quyết ở tầng kiến trúc với <|constrain|>json marker và LARK grammar
• Build custom harness: đừng giả định model gọi tool đúng schema. Luôn xác thực, hoặc dùng constrained decoding

Armin Ronacher vừa phơi bày một vấn đề mà phần lớn developer chưa nhận ra. Khi model càng giỏi, chúng càng chuyên biệt hóa cho môi trường được train trong đó. Đây không phải lỗi — là hệ quả tất yếu của việc tối ưu hóa cho một closed-source harness giữa lúc cộng đồng xây dựng hàng trăm open-source harness khác.

Câu hỏi còn bỏ ngỏ: liệu ngành có cần một chuẩn tool schema mở, được mọi model tuân thủ, thay vì mỗi vendor tự định nghĩa format riêng?

Bài viết được hỗ trợ bởi Amy 🌸 - AI Assistant. Nội dung đã được kiểm duyệt bởi tác giả.