Thiết kế agent vẫn còn khó

 (lucumr.pocoo.org)
20 điểm bởi GN⁺ 2025-11-23 | 1 bình luận | Chia sẻ qua WhatsApp
  • Quá trình xây dựng agent vẫn phức tạp, và các lớp trừu tượng của SDK thường bị phá vỡ ở giai đoạn sử dụng công cụ thực tế
  • Quản lý cache khác nhau giữa các nền tảng, nên quản lý thủ công có tính dự đoán và hiệu quả hơn; cách dùng điểm cache tường minh của Anthropic SDK được ưa chuộng
  • Vòng lặp tăng cường (reinforcement loop) đóng vai trò then chốt trong theo dõi trạng thái công việc và khôi phục sau thất bại; cần cô lập lỗi riêng để tránh làm vòng lặp sụp đổ
  • Quản lý trạng thái dùng chung cần một cấu trúc phân cấp giống hệ thống tệp, được dùng làm nền tảng trao đổi dữ liệu giữa các công cụ thực thi mã và suy luận
  • Công cụ đầu ra và lựa chọn mô hình vẫn đầy khó khăn; các mô hình Haiku, Sonnet và Gemini tiếp tục là những lựa chọn chính, cho thấy độ phức tạp của thiết kế agent vẫn còn nguyên

Lựa chọn SDK cho agent

  • Khi xây dựng agent, cần chọn giữa việc dùng trực tiếp SDK gốc như OpenAI, Anthropic hay dùng lớp trừu tượng cấp cao như Vercel AI SDK hoặc Pydantic
    • Tác giả cho biết trước đây từng chỉ dùng provider abstraction của Vercel AI SDK, nhưng hiện tại sẽ không lặp lại lựa chọn đó
  • Khác biệt giữa các mô hình quá lớn, nên cần tự xây dựng lớp trừu tượng agent, và lớp trừu tượng của các SDK hiện có không phù hợp
    • Có những khác biệt tinh vi ở kiểm soát cache, yêu cầu reinforcement, prompt công cụ, v.v.
  • Vercel SDK gặp vấn đề ở xử lý công cụ phía provider
    • Có trường hợp công cụ tìm kiếm web của Anthropic làm hỏng lịch sử tin nhắn
    • Khi dùng trực tiếp Anthropic SDK, việc quản lý cache và thông báo lỗi rõ ràng hơn
  • Kết luận là hiện tại cách tiếp cận dùng trực tiếp SDK mà không qua lớp trừu tượng được đánh giá có lợi hơn

Bài học về quản lý cache

  • Cách tiếp cận cache khác nhau theo từng nền tảng; Anthropic tính phí cho cache và yêu cầu quản lý tường minh
    • Quản lý thủ công được ưa chuộng vì giúp chi phí và mức độ tận dụng cache dễ dự đoán hơn
  • Cache tường minh cho phép thực thi phân nhánh hội thoại hoặc chỉnh sửa ngữ cảnh
    • Có thể đặt nhiều điểm cache sau system prompt, ở phần đầu hội thoại, v.v.
  • Để duy trì cache, system prompt và lựa chọn công cụ phải tĩnh; thông tin động như thời gian được truyền trong các tin nhắn phía sau
  • Tận dụng mạnh vòng lặp reinforcement cùng với cache để tăng khả năng dự đoán chi phí và quyền kiểm soát

Reinforcement bên trong vòng lặp agent

  • Khi thực thi công cụ, ngoài việc trả về kết quả đơn thuần còn có thể bơm lại vào vòng lặp các thông tin như mục tiêu, trạng thái công việc, nguyên nhân thất bại
  • Các công cụ tự tăng cường (self-reinforcement) như công cụ todo write của Claude Code giúp vòng lặp tiến triển tốt hơn
  • Khi môi trường thay đổi hoặc đến lúc khôi phục sau lỗi, có thể chèn thông tin thay đổi trạng thái để đảm bảo độ ổn định của vòng lặp
    • Ví dụ: khi thử lại dựa trên dữ liệu đã hỏng, có thể chèn thông điệp để quay lại bước trước đó

Cô lập lỗi (Isolate Failures)

  • Những tác vụ được dự đoán sẽ thất bại lặp đi lặp lại nên được tách ra chạy bằng subagent; chỉ báo cáo kết quả thành công về vòng lặp cấp trên
    • Tóm tắt các lần thử thất bại có thể dùng làm tư liệu học cho tác vụ tiếp theo
  • Trong Anthropic SDK, có thể dùng tính năng chỉnh sửa ngữ cảnh (context editing) để loại bỏ bản ghi thất bại
    • Không giữ lại toàn bộ thông tin lỗi mà chỉ để lại phần cần thiết
    • Tuy nhiên, chỉnh sửa ngữ cảnh có thể làm mất hiệu lực cache và khiến chi phí tăng lên

Subagent và hệ thống tệp dùng chung

  • Phần lớn agent hoạt động theo kiểu thực thi mã và tạo sinh, nên cần một kho dữ liệu dùng chung
    • Để làm điều này, người ta dùng hệ thống tệp ảo (VFS)
  • Các công cụ khác nhau như tạo ảnh, nén, suy luận phải chia sẻ cùng đường dẫn tệp
    • Các công cụ ExecuteCode và RunInference phải có thể truy cập cùng một hệ thống tệp
  • Cấu trúc này là yếu tố thiết yếu để loại bỏ nút thắt trao đổi dữ liệu và xử lý các tác vụ liên tiếp trong vòng lặp

Công cụ đầu ra (Output Tool)

  • Agent không hoạt động như một phiên chat mà theo vòng lặp tin nhắn nội bộ riêng tư; việc giao tiếp với bên ngoài được thực hiện qua công cụ đầu ra
    • Công cụ đầu ra phụ trách giao tiếp bên ngoài như gửi email
  • Khó kiểm soát giọng điệu và văn phong của công cụ đầu ra; khi dùng LLM phụ trợ (Gemini 2.5 Flash), chất lượng giảm và độ trễ tăng
    • Công cụ cấp dưới không có đủ ngữ cảnh nên tạo ra kết quả thiếu chính xác
  • Nếu khi kết thúc vòng lặp mà công cụ đầu ra chưa được gọi, có thể chèn thông điệp reinforcement để thúc đẩy việc gọi công cụ này

Lựa chọn mô hình

  • Haiku và Sonnet có hiệu năng gọi công cụ tốt nên được dùng làm mô hình chính cho vòng lặp
  • Gemini 2.5 phù hợp để tóm tắt tài liệu lớn, xử lý PDF và trích xuất thông tin từ hình ảnh
    • Mô hình Sonnet có nhược điểm là thường xuyên vướng bộ lọc an toàn
  • Các mô hình dòng GPT không cho thấy nhiều kết quả nổi bật trong vòng lặp chính
  • Không thể đánh giá tổng chi phí chỉ bằng chi phí token
    • Mô hình gọi công cụ tốt hơn có thể hoàn thành cùng tác vụ với ít token hơn

Kiểm thử và đánh giá (Evals)

  • Tự động hóa kiểm thử và đánh giá agent được chỉ ra là vấn đề khó nhất
    • Khác với prompt, không thể chỉ đánh giá đơn giản từ hệ thống bên ngoài
    • Cần khả năng quan sát (observability) hoặc đo đạc/ghi nhận (instrumentation) dựa trên dữ liệu thực thi thực tế
  • Tác giả nói rằng đến nay vẫn chưa tìm được phương pháp đánh giá thực sự thỏa đáng

Cập nhật về coding agent

  • Không có nhiều thay đổi lớn liên quan đến coding agent
    • Gần đây tác giả đang thử nghiệm agent Amp và đánh giá cao cấu trúc tương tác giữa Oracle subagent và vòng lặp chính
  • Amp và Claude Code tạo cảm giác là những thiết kế hướng tới nhà phát triển, do chính những người thực sự dùng công cụ của họ tạo ra

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-11-23
Ý kiến trên Hacker News

  • Tôi đã khởi nghiệp trong lĩnh vực này khoảng 2 năm trước. Hiện công ty đang vận hành tốt
    Điều tôi học được trong 2 năm qua là, nhiều kỹ thuật thực chất chỉ là tối ưu hóa tạm thời để bù đắp cho các giới hạn hiện tại của LLM. Công nghệ phát triển quá nhanh nên vấn đề của hôm nay có thể biến mất vào ngày mai
    Trước đây, khi AWS chưa có tính năng mã hóa đĩa, đội của tôi đã mất 3 tháng để tự triển khai, rồi ngay sau đó AWS phát hành mã hóa tiêu chuẩn chỉ cần bấm một nút. Cuối cùng đó là một sự lãng phí thời gian
    Vì vậy điều tôi rút ra là, đôi khi không làm gì mới là lựa chọn tốt nhất

    • Tôi nghĩ đây là góc nhìn cốt lõi. Dạo này đồng nghiệp trong công ty mở workshop AI rồi nói rằng họ đã “phát minh” ra các pattern mới, nhưng phần lớn chỉ sang tuần sau là lỗi thời
      Thời kỳ học pattern như một ngôn ngữ chung kiểu trước đây đã kết thúc, giờ chu kỳ bán rã của pattern AI chỉ khoảng một tuần. Thậm chí nếu hỏi 10 chuyên gia “agent” là gì thì sẽ nhận được 10 câu trả lời khác nhau
    • Nhìn vào tốc độ phát triển của AI, có thể chỉ cần chờ đủ lâu thì cuối cùng mọi thứ sẽ quy về dùng trực tiếp OpenAI
    • Tôi tò mò không biết công ty có đang có lãi, doanh thu vượt chi phí vận hành hay không. Tôi vẫn thấy khó tin rằng có thể kiếm tiền thực sự từ agent. Muốn biết bí quyết là gì
    • Biết lúc nào nên ‘không làm gì’ liên quan đến khả năng đánh giá vấn đề mà nhóm đang xử lý là cốt lõi hay chỉ là vấn đề ngoại vi
    • Đồng ý. Bây giờ chờ đợi cũng có thể là một chiến lược. Nhưng nếu chờ quá lâu thì cũng có thể rơi vào cái bẫy là không làm gì cả cho tới khi AGI xuất hiện

  • Trong 2 năm qua tôi đã dùng nhiều agent SDK, và khi tự xây thì thấy nó phức tạp hơn tưởng tượng rất nhiều
    Claude Code SDK (nay là Agent SDK) rất tốt nhưng vẫn chưa tách hoàn toàn khỏi sự gắn kết với Claude Code. Ví dụ skills phải được đặt trực tiếp trên filesystem
    SDK của OpenAI cho phép tự động theo dõi và đánh giá trên dashboard nhờ tích hợp chặt với nền tảng, nhưng khó tích hợp model bên thứ ba
    Google Agent Kit thì vẫn chưa có SDK cho Typescript, còn Mastra thì phải dựng server nên khá bất tiện
    Hiện tôi đang thử SmythOS SDK, vì nó cho phép tự do hơn trong việc chọn nhà cung cấp model và định nghĩa kiến trúc
    Tôi tò mò không biết cấu trúc hiện tại đang dùng là Agent → SubAgents → SubSubAgents, hay kiểu Planner-Executor

    • Phần lớn SDK trở thành ác mộng ngay khi bạn vượt qua tính năng cơ bản. Vì vậy tôi dùng thư viện client OpenRouter và tự triển khai
      Lượng code tăng lên nhưng mô hình tinh thần lại đơn giản nên dễ hiểu hơn nhiều. Tôi chạy vòng lặp theo kiểu ReAct, lặp lại reasoning và gọi tool
      Cuối cùng thì ngay cả không có SDK bạn vẫn có thể tự triển khai agent handoff hay workflow
    • Tôi nghĩ thuật ngữ ‘sub-agent’ gần như vô dụng. Xét cho cùng nó chỉ là một dạng trừu tượng hóa của việc gọi công cụ, và bên ngoài vòng lặp chính thì chỉ hợp đồng đầu vào/đầu ra đơn giản mới là quan trọng
    • Có người nói Claude Code chỉ hỗ trợ model của Anthropic, nhưng nếu dùng Claude Code Router thì vẫn có thể tích hợp model khác
    • Tôi đang dùng bản Go của Google ADK. Dù còn non nhưng tôi hài lòng vì khả năng xây workflow và tương thích giữa các vendor khá tốt
    • Tôi cũng đã dùng Strands Agents SDK của AWS, nó hỗ trợ API của các vendor lớn ngay cả không cần Bedrock, và thiết kế API rất linh hoạt (tôi là nhân viên AWS nhưng đây là ý kiến cá nhân)

  • Tôi muốn chia sẻ vài nguyên tắc thiết kế agent mà chúng tôi đã học được

    1. Nếu có nhiều tác vụ sinh mã thì Claude Code / Agent SDK là hiệu quả nhất
    2. Rủi ro lớn hơn phụ thuộc vendor là làm ra một sản phẩm còn tệ hơn ChatGPT
    3. Claude Code có khả năng tự nhận thức rất tốt, nên khi hỏi về chính nó thì trả lời ngay và khá chính xác
    4. Nếu cho agent một máy tính thật thì nó mạnh hơn rất nhiều. Chúng tôi dùng e2b.dev, nhưng Modal cũng tốt
      Tham khảo thêm, công ty chúng tôi là Definite, một nền tảng dữ liệu được vận hành bởi AI data engineer giống như Heroku
    • Claude sáng tạo hơn, nhưng trong codebase phức tạp nó đôi khi trả lời bịa và còn reward hacking. Trong những trường hợp như vậy Codex ổn định hơn
    • Tôi nghĩ vấn đề là có quá nhiều sản phẩm được phát hành với chất lượng còn kém cả giao diện web ChatGPT
    • Thay vì nhất thiết phải tự xây hệ thống agent, tốt hơn là tận dụng công cụ hoàn thiện như Claude Code và tập trung vào việc tạo ra giá trị thật
    • Tất nhiên, tư duy “cứ giao hết cho big tech” cũng nguy hiểm. Quá trình tự xây, tự học và chia sẻ vẫn rất quan trọng. Tôi cũng đang tiến bộ rất nhanh với ADK và extension VS Code

  • Tôi đã xây agent trong vài năm nay, và điều đúng đắn nhất tôi làm là tự xây framework
    Nhiều lớp trừu tượng mã nguồn mở trở nên không thể duy trì khi SDK thay đổi, và cuối cùng sẽ sụp đổ

    • Tôi cũng nghĩ vậy. Cốt lõi của agent là I/O có cấu trúc, đăng ký công cụ và vòng lặp gọi công cụ, cùng với ủy quyền giữa các agent
      Tôi đã tạo OpusAgents dựa trên PydanticAI; nó đơn giản hơn MCP server nhưng vẫn là một framework mã nguồn mở có khả năng mở rộng
    • Với tư cách là tác giả bài viết, tôi đồng ý. Tôi đã tổng hợp suy nghĩ liên quan trong bài này
    • Khi làm chatbot hỗ trợ khách hàng, chúng tôi cũng đã áp dụng kiến trúc dựa trên chatroom thay vì cấu trúc cũ. Frontend chỉ đơn giản ném message vào, còn backend thì mở rộng chức năng dần dần
    • Tuy nhiên, tự xây một framework hoàn chỉnh là một công việc rất lớn. Về dài hạn, có khả năng các nền tảng agent sẽ được chuẩn hóa giống như game engine

  • Dạo này tình hình đang lặp lại sự lạm dụng trừu tượng hóa và độ phức tạp như thời kỳ đầu của LangChain/RAG
    Cuối cùng thì cứ xem agent như một cấu trúc REPL đơn giản (Read, Eval, Print, Loop) là được.
    Phiên bản nhẹ tôi tự triển khai theo ý tưởng này ổn định hơn nhiều so với các SDK nặng nề

    • Nhưng trong các use case thực sự phức tạp thì vẫn cần subagent chuyên biệt và cấu trúc chia sẻ dữ liệu. Chỉ vòng lặp đơn giản thôi thì sẽ có giới hạn

  • Kiểm thử và đánh giá (evals) của agent là bài toán khó nhất.
    Nếu đánh giá bằng hệ thống bên ngoài thì đầu vào quá nhiều, lại còn phải quan sát dữ liệu trong lúc chạy
    Tôi vẫn chưa chắc cách tiếp cận nào là hiệu quả

    • Tôi lo rằng phần lớn việc triển khai AI agent hiện nay đều dựa vào cảm giác mà không có kiểm thử chính thức
    • Nếu xem tài liệu đánh giá của Google ADK, họ cũng nói rằng vì kết quả khác nhau ở mỗi lần chạy nên rất khó đặt ra tiêu chí pass/fail. Cuối cùng lại dùng một LLM khác để đánh giá

  • Ngay cả những phần cơ bản trong phát triển agent cũng thiếu guideline rõ ràng
    Ví dụ trong xử lý kiểu đầu vào/đầu ra của function tool, khi truyền ID dạng số thì xảy ra lỗi tuần tự hóa hoặc mất độ chính xác
    Cuối cùng tôi phải giải quyết bằng cách đổi sang string
    Nếu nhìn vào tài liệu của OpenAI (liên kết) và issue của Google ADK (liên kết),
    họ nói rằng “kết quả phải là string” nhưng ví dụ thực tế lại trả về dict hoặc số. Sự không nhất quán này gây ra nhầm lẫn

  • Tôi đang dùng sản phẩm của một công ty làm agentic coding nào đó (không nêu tên)
    Họ lo hết mọi thứ như phát hành model, đánh giá, quản lý sub-agent, billing, còn tôi chỉ cần tập trung vào công việc nên rất hài lòng

    • Có lẽ đó là Amp của Sourcegraph. Ban đầu còn thô nhưng giờ mức độ hoàn thiện khá cao

  • Trong 2 tháng qua tôi đã triển khai nhiều agent cho các loại tác vụ khác nhau. Ban đầu tôi dùng Claude Code nhưng vì phụ thuộc vendor và giới hạn sử dụng nên đã tự tạo runtime
    Hiện tại chỉ hỗ trợ OpenAI, nhưng được thiết kế để có thể thêm Claude hay Gemini sau này
    Tôi đã open source nên có thể tham khảo tại đây → agent-composer

  • Mẹo của tôi rất đơn giản: đừng dùng SDK, hãy tự viết vòng lặp while và xử lý JSON
    Chỉ khi tự kiểm soát context size và lỗi thì bạn mới tạo được agent thật sự linh hoạt