Agent cần bộ công cụ nền tảng như thế nào

Thấy mọi người đang bàn về vấn đề bộ công cụ Agent — có phải chỉ cần cung cấp một shell là xong? Sau khi làm holon mới phát hiện, thực ra không đơn giản như vậy.
Đọc: tại sao từ bỏ Read/Glob, toàn dùng shell
Bộ công cụ của holon đã qua vài phiên bản, cuối cùng đã bỏ các công cụ chuyên dụng như Read (đọc file), Glob (tìm kiếm theo mẫu) do Claude Code cung cấp, tất cả việc đọc và tìm kiếm đều thực hiện qua shell. Điều này phù hợp với hướng đi của Codex — lệnh thực thi của Codex là ExecCommand, đọc file thì dùng cat, tìm mã nguồn thì dùng rg, không còn định nghĩa riêng từng công cụ "đọc" nữa.
Lý do đơn giản: shell là "ngôn ngữ lập trình" quen thuộc nhất với LLM. Thay vì để mô hình học các tham số ý nghĩa của công cụ Read do bạn định nghĩa, tốt hơn là để nó viết trực tiếp các lệnh shell đã được huấn luyện hàng chục tỷ lần. Mỗi công cụ riêng thêm vào, nhận thức của mô hình lại thêm một tầng gánh nặng; còn giao diện shell, mô hình đã đủ thành thạo rồi.
Nhưng dùng toàn shell có một cái giá: bị cắt ngắn đầu ra. Framework để tránh giá trị trả về của shell quá dài làm tràn ngập ngữ cảnh, sẽ giới hạn đầu ra của mỗi lệnh. Agent dùng cat để đọc một file lớn, có thể chỉ lấy được nửa đầu, phần còn lại nằm trong file artifact, phải dùng cat nhiều lần nữa mới đọc hết. Công cụ Read của Claude Code có ngưỡng nén cao hơn shell chung, đọc file lớn một lần là xong, ít phải đi lại nhiều lần. Về bản chất là sự đánh đổi: giảm số lượng công cụ định nghĩa để giảm gánh nặng nhận thức, nhưng công cụ chuyên dụng hiệu quả hơn trong các trường hợp biên giới.
Viết: từ sed đến ApplyPatch, và các vấn đề của công cụ ngữ pháp tự do
Nhưng thao tác viết không thể hoàn toàn dùng shell.
Nếu để Agent chỉ dùng sed để chỉnh sửa, sẽ thấy rất khó xử lý các trường hợp phức tạp như tìm kiếm nhiều dòng — xuống dòng, thoát ký tự, thụt lề, bất kỳ lỗi nào cũng có thể làm thất bại chỉnh sửa. Vì vậy nhiều hệ thống cung cấp công cụ chỉnh sửa như Replace String, cho phép Agent truyền một đoạn old_string lớn để khớp chính xác và thay thế thành new_string. Dù có vẻ cồng kềnh, nhưng an toàn hơn sed nhiều.
Codex còn đi xa hơn, sáng tạo ra công cụ ApplyPatch của riêng mình, cho phép Agent trực tiếp sinh ra patch, xử lý hàng loạt chỉnh sửa trong một lần. holon cũng lấy ý tưởng này làm nền tảng.
Nhưng khi triển khai lại gặp một vấn đề: Codex dùng một bộ định dạng patch đơn giản do OpenAI tự định nghĩa, kết hợp với một cơ chế đặc biệt gọi là free grammar tool để giải quyết vấn đề truyền định dạng.
Tại sao phải tạo ra một cơ chế mới? Vì định nghĩa công cụ chuẩn của LLM là tool(args) dạng JSON. Nếu truyền patch dưới dạng chuỗi JSON, sẽ gặp nhiều vấn đề thoát ký tự — xuống dòng phải biến thành \n, dấu nháy phải thêm \\, thụt lề cũng phải cẩn thận. Viết patch dễ mắc lỗi, thêm một lớp thoát JSON nữa, xác suất sai tăng gấp đôi. Ý tưởng của free grammar tool là đưa trực tiếp nội dung gốc của patch làm input của tool, không qua mã hóa JSON, mô hình viết gì thì đó. Giảm đáng kể tỷ lệ lỗi khi mô hình sinh patch.
Hiện tại, cơ chế này chỉ được hỗ trợ qua API của OpenAI Codex. holon muốn tương thích nhiều nhà cung cấp mô hình, không thể chỉ dựa vào cơ chế này.
Vì vậy, cách của holon là: dựa vào mô hình để chèn các định nghĩa ApplyPatch khác nhau. Với các mô hình hỗ trợ free grammar, dùng định dạng patch gốc; còn các mô hình khác thì nhận định dạng diff của git. Tôi nghĩ sau hàng tỷ lần huấn luyện trên GitHub, LLM đã khá thành thạo định dạng diff của git. Thực tế, kết quả khá khả quan — dù vẫn hay sai, nhưng phần lớn đều sửa được đúng, và theo thời gian dữ liệu huấn luyện tích lũy, khả năng này sẽ càng ngày càng tốt hơn. Tuy nhiên, tôi vẫn khuyên các nhà phát triển mô hình nên hỗ trợ free grammar tool, vì đây là nhu cầu thực sự trong các tình huống viết mã của Agent.
Điều phối: lệnh dài hạn và trừu tượng hóa nhiệm vụ
Vấn đề thứ ba là lệnh shell của Agent không nhất thiết phải kết thúc nhanh — khởi động server dev, chạy test, build dự án, đều có thể kéo dài rất lâu, thậm chí không bao giờ thoát. Các framework Agent ban đầu xử lý rất thô sơ: hoặc đồng bộ chặn đứng chính nó, hoặc tất cả lệnh đều đưa vào nền, dẫn đến Agent lặp lại thực thi cùng một lệnh nhiều lần.
Hiện nay, giới công nghệ dần đi đến thống nhất: không cho phép Agent tự quyết "trước/ sau" — vì việc này Agent không đủ độ chính xác. Cách tốt hơn là đặt giới hạn thời gian, lệnh quá hạn sẽ tự chuyển sang chế độ nền, hoàn toàn minh bạch với Agent. Agent không cần dự đoán lệnh đó có nên chuyển nền hay không, runtime tự xử lý.
Nhưng việc tự chuyển nền chỉ là bước đầu. Sau khi chuyển nền, các vấn đề thực tế mới nổi lên — và hiện tại, chưa có tiêu chuẩn chung cho chúng.
Đầu tiên là đọc output như thế nào. Nhiệm vụ chạy nền có thể vẫn đang chạy hoặc đã kết thúc, output có thể rất lớn. Nhưng các API của các nhà cung cấp không thống nhất về ý nghĩa — có cái dùng polling, có cái dùng push sự kiện.
Tiếp theo là làm thế nào để dừng nhiệm vụ. Các nhà cung cấp đều có cơ chế hủy, nhưng hủy có phải là kill ngay lập tức hay là thoát nhẹ nhàng, phần output đã sinh ra có cần giữ lại không?
Cuối cùng là ai sẽ gọi thức tỉnh Agent. Sau khi Agent gửi nhiệm vụ vào nền rồi ngủ, khi nhiệm vụ kết thúc, ai sẽ gọi nó dậy? Điều này yêu cầu runtime và Agent phải phối hợp chặt chẽ, không thể chỉ là công cụ độc lập.
Ba vấn đề này — đọc output, dừng nhiệm vụ, gọi thức tỉnh Agent — hợp lại chính là quản lý vòng đời của nhiệm vụ nền. Các nhà đều đã làm được "chạy nền", nhưng chưa có giải pháp tiêu chuẩn, có thể là bước then chốt trong sự phát triển của chuỗi công cụ Agent trong tương lai.
Chưa đến mức dùng một mô hình sẵn có một cách máy móc
Vì vậy, quay lại câu hỏi ban đầu: shell có thể giải quyết 80%, nhưng 20% còn lại — độ chính xác chỉnh sửa, định dạng patch phù hợp khả năng của mô hình, và điều phối các nhiệm vụ dài hạn — lại quyết định xem Agent có thể chuyển từ demo thành hệ thống thực sự khả dụng hay không.
Bộ công cụ không chỉ đơn thuần "đóng gói một shell", mà còn phức tạp hơn nhiều, chưa đến mức mọi người có thể vô tư áp dụng một mô hình sẵn có. Đó cũng là lý do tại sao Codex và Claude Code đưa ra các câu trả lời khác nhau về các vấn đề nền tảng này, và holon lại dựa trên các tình huống của riêng mình để đưa ra các lựa chọn khác nhau, còn nhiều điểm có thể khám phá và cải tiến.