Vì sao bạn nên tự tay tạo một agent

• Agent LLM là một cấu trúc kỹ thuật mà thay vì chỉ hiểu như một khái niệm, bạn nên tự triển khai để thực sự cảm nhận được nguyên lý vận hành
• Chỉ với vài chục dòng mã Python, có thể tạo một agent hội thoại bằng OpenAI Responses API; khi bổ sung khả năng gọi công cụ (tool call), agent có thể hành động một cách tự chủ
• Cốt lõi của agent là vòng lặp gọi lặp lại với LLM không có trạng thái, trong đó bạn tự quản lý ngữ cảnh hội thoại (context) để hiện thực hóa các cuộc trò chuyện nhiều lượt
• Context Engineering là một vấn đề ở cấp độ bài toán lập trình thực tế, đòi hỏi thiết kế tối ưu đầu vào, đầu ra và mô tả công cụ trong giới hạn token
• Thiết kế agent hiện nay là một không gian vấn đề kỹ thuật phần mềm mở, nơi cả lập trình viên cá nhân cũng có thể thử nghiệm các cách tiếp cận mới

---

Sự đơn giản của việc viết agent

• Agent LLM có thể được triển khai chỉ với OpenAI Responses API mà không cần cấu hình phức tạp
  • Trong mã ví dụ, danh sách context được dùng để lưu cuộc đối thoại giữa người dùng và mô hình, rồi được gọi lặp lại để tạo phản hồi hội thoại giống ChatGPT
• Có thể mô phỏng cuộc trò chuyện đa nhân cách bằng cách tạo hai context với “tính cách tốt” và “tính cách xấu”
  • LLM không có trạng thái, và tính liên tục của hội thoại được duy trì bằng mảng chuỗi (context) do người dùng quản lý
• Chỉ với cấu trúc đơn giản này cũng có thể thực hiện hội thoại nhiều lượt, đồng thời tự mình trải nghiệm nguyên lý hoạt động của LLM

Tích hợp công cụ (tool) và hoạt động tự chủ

• Có thể đăng ký hàm ping như một công cụ cho agent để thêm khả năng kiểm tra trạng thái kết nối mạng
  • OpenAI API yêu cầu định nghĩa công cụ dưới dạng JSON; khi LLM yêu cầu gọi công cụ nếu cần, mã Python sẽ thực thi rồi gửi lại kết quả
• Ngay cả khi không có chỉ thị tường minh, LLM vẫn tự động ping nhiều host (google.com, www.google.com, 8.8.8.8)
  • Điều này cho thấy chỉ cần có “quyền sử dụng công cụ”, LLM cũng có thể đưa ra phán đoán tự chủ
• Toàn bộ vòng lặp chỉ đơn giản là “yêu cầu gọi công cụ → thực thi → trả kết quả”, nên có thể hiện thực hành vi agent tự chủ mà không cần logic điều khiển phức tạp

Ứng dụng thực tế và phê bình MCP

• Mã ví dụ tuy đơn giản, nhưng nếu kết hợp thêm công cụ bổ sung (như traceroute) hoặc lưu context dựa trên SQLite thì có thể mở rộng theo hướng thực dụng
• MCP (Multi-Context Protocol) chỉ là giao diện plugin của Claude Code hay Cursor, chứ không phải công nghệ bắt buộc
  • Nếu trực tiếp làm việc với API, vẫn có thể hiện thực cùng chức năng mà không cần MCP
• MCP chỉ hữu ích trong môi trường không có quyền kiểm soát mã; ngược lại, nó còn có thể hạn chế tính linh hoạt của kiến trúc agent
• Bảo mật LLM là vấn đề phức tạp, nhưng vẫn có thể thiết kế cấu trúc an toàn thông qua tách biệt context và giới hạn công cụ

Tầm quan trọng của context engineering

• “Prompt engineering” là một khái niệm bị thổi phồng, nhưng context engineering là một bài toán lập trình thực sự
  • Số token trong cửa sổ ngữ cảnh là hữu hạn, và đầu vào, đầu ra, mô tả công cụ đều chiếm không gian
  • Khi vượt qua giới hạn này, chất lượng phản hồi của mô hình sẽ trở nên thiếu ổn định
• Một cách giải quyết là tạo sub-agent với các context và công cụ khác nhau, rồi thiết kế để chúng tóm tắt và trao đổi với nhau
  • Cấu trúc như vậy có thể được mở rộng thành nhiều thử nghiệm khác nhau như mạng agent dạng cây hoặc nén dựa trên tóm tắt thời gian thực
• Ngay cả những ý tưởng phức tạp cũng có mức độ đơn giản đủ để triển khai trong vòng 30 phút

Bài toán kỹ thuật mở và giá trị của thử nghiệm

• Hiện nay rất nhiều startup đang phát triển agent để phát hiện lỗ hổng, và lập trình viên cá nhân cũng có thể thực hiện các thử nghiệm tương tự
• Thiết kế agent bao gồm những bài toán kỹ thuật chưa được giải quyết như sau
  • Cân bằng giữa tính phi định và lập trình có cấu trúc
  • Kiểm chứng thực tế (ground truth) và ngăn vòng lặp kết thúc quá sớm
  • Định dạng trao đổi dữ liệu giữa các agent nhiều tầng (JSON, SQL, Markdown, v.v.)
  • Phân bổ token và kiểm soát chi phí
• Đây không phải là những vấn đề chỉ có thể nghiên cứu ở quy mô lớn, mà là lĩnh vực có thể khám phá bằng các thử nghiệm ở cấp độ cá nhân, với mỗi vòng lặp chỉ mất vài chục phút để thử
• Kết luận lại, trải nghiệm tự tay tạo agent chính là điểm khởi đầu để hiểu công nghệ LLM

[GN⁺]

Ý kiến Hacker News

• Có quá nhiều thứ muốn làm. Tôi muốn tự ráp CPU từ cổng NAND trên breadboard, cũng muốn thử làm CDN bằng Rust nhưng không có đủ thời gian
  Thay vào đó, tôi đã làm thử một LLM theo tutorial của Karpathy, và cảm thấy việc thử nghiệm từng chút một như vậy khá ổn

  • Cảm giác như một đường cong không có điểm kết thúc. Trước đây tôi từng ráp một máy tính 8-bit trên breadboard, còn lần này lại mê huấn luyện bay (PPL)
    Mỗi khi nghĩ rằng “giờ là xong rồi”, tôi lại có cảm giác vạch đích ngày càng xa hơn. Cuối cùng thì những người như chúng ta có lẽ là kiểu người không bao giờ thật sự thỏa mãn
  • Phần đầu của bài viết gốc giải thích việc này có thể làm dễ đến mức nào. Đó chính là ý chính của bài

• Ví dụ dùng GPT-5, nhưng giao diện truy vấn thì đã ở mức chuẩn công nghiệp rồi
  Chẳng hạn, nếu kết nối OpenRouter.ai thì có thể dễ dàng đổi model và nhà cung cấp ngay trong lúc chạy
  Họ cũng có model miễn phí (ví dụ: DeepSeek), tuy chậm và bị giới hạn. Dù vậy, vẫn rất tuyệt để thử nghiệm

• Vài tháng trước tôi đã tự làm một agent bằng Ruby. Thật sự rất vui
  Logic cốt lõi chỉ có đúng bốn dòng, và về mặt khái niệm thì đơn giản đến đáng ngạc nhiên

  until mission_accomplished? or given_up? or killed?
    determine_next_command_and_inputs
    run_next_command
  end
  

• Hai năm trước tôi từng làm một agent chỉ với 25 dòng PHP; lúc đó còn chưa có cả tool calling, nhưng nó vẫn hoạt động khá tốt
  Với tôi, LLM giống như các công cụ thao tác văn bản UNIX kiểu sed hay awk — bạn đưa đầu vào và lệnh, rồi nó trả ra đầu ra
  Ghép nhiều lời gọi LLM theo kiểu này, rồi thêm vòng lặp hoặc phân nhánh, là có thể tạo ra một hệ thống khá mạnh
  Mã liên quan: hubcap, llm

  • Tôi thực sự rất thích hubcap. Ít mã nhưng kết quả rất ấn tượng
    Tôi đã nhận được rất nhiều cảm hứng từ bài viết của Simon Willison

• Tôi đặc biệt đồng cảm với phần tự làm một phương án thay thế cho Claude Code. Việc tạo ra một agent lập trình tự cải thiện gần như là một trải nghiệm ma thuật
  Có thể tự do đổi model, và nếu dùng model nhanh như Cerebras thì sẽ thấy khác biệt rất lớn ngay cả trong các công cụ gọi hàm tương tác
  Nếu thêm bộ nhớ, nhận dạng giọng nói, v.v. thì hiệu quả còn cao hơn nhiều. Có thể làm trong vài phút và thật sự rất vui

  • Tôi tò mò không biết bạn dùng model nhận dạng giọng nói nào. Whisper thì chậm và không chính xác, còn model audio của GPT thì thường xuyên từ chối phản hồi
    Model của Google thì chất lượng thấp, còn model của Mistral thì nhanh nhưng đôi khi lại phản ứng với cả văn bản
    Vì vậy đôi lúc nó ghi lại lời tôi nói thành kiểu dòng ý thức của chính LLM
  • Tôi rất thích cách nói “build your own lightsaber”
    Ban đầu tôi làm nó để hiểu cấu trúc bên trong, nhưng rồi thấy nó đơn giản hơn tưởng tượng nên giờ tôi đang tự thêm những tính năng mình muốn
    Có thể thêm tính năng nhanh hơn cả sản phẩm do cả một đội làm. Agent có cấu trúc đơn giản đến đáng kinh ngạc
  • Tôi không biết nếu muốn nhập môn thì nên bắt đầu từ đâu. Đây cũng là lần đầu tôi nghe đến Cerebras. Hiện tại tôi chỉ dùng Copilot trong VS Code
    Không rõ cái đó có dựa trên model cục bộ hay không
  • Cerebras giờ đã cung cấp glm 4.6. Vẫn nhanh khủng khiếp, mà giờ còn thông minh hơn nhiều

• Đọc bài này khiến tôi muốn làm lại triết lý Unix — công cụ làm tốt một việc
  Không chỉ giúp agent đơn giản hơn mà còn tăng tính bảo mật

  • Năm 2021 tôi từng làm một agent để kiểm tra kết nối mạng, và nếu giao cho agent các công cụ cơ bản như ping, dig, traceroute thì nó cho kết quả khá ổn
    Dù không hoàn hảo bằng hệ thống telemetry do con người tự xây, nhưng vẫn có thể đạt mức hữu dụng 90% dễ dàng hơn nhiều
  • Cũng có thể hình dung ra một bộ công cụ giới hạn mục đích được đưa trực tiếp cho con người sử dụng
  • Muốn làm tốt một việc thì lại cần nhiều công cụ hơn, và cùng với đó là năng lực hiểu ngữ cảnh lớn hơn
    Có lẽ kích thước lý tưởng của LLM nằm ở đâu đó giữa, nhỉnh hơn các công cụ Unix truyền thống một chút

• Tôi băn khoăn liệu có nhất thiết phải tự làm agent không?
  Trong bối cảnh mọi nhà cung cấp AI đều đang lỗ, tôi hoài nghi về việc liệu có thể có một mô hình doanh thu bền vững hay không

  • Tự làm thử sẽ giúp bạn hiểu bằng trực giác cách agent hoạt động và các giới hạn của nó. Đó mới là điểm chính
  • Đây đơn giản là một bài viết về việc thử công nghệ cho vui. Không liên quan gì đến kiếm tiền
    Lý luận này cũng giống như lấy việc Astral đang lỗ làm lý do để không dùng Python
  • Không phải công ty AI nào cũng đang thua lỗ
    Họ cần vốn vì chi phí huấn luyện model tiếp theo rất lớn, chứ giai đoạn suy luận thì có lợi nhuận
  • Bạn cũng có thể tự trở thành nhà cung cấp AI
  • Bình luận này tạo cảm giác có chút mệt mỏi cảm xúc. Tôi tự hỏi có phải bạn là một lập trình viên nhiều năm kinh nghiệm không

• Phần về context engineering đặc biệt chạm đúng điều tôi đang nghĩ
  Tôi đang làm một trợ lý cá nhân, và nó có trí nhớ, theo dõi công việc, khả năng giải quyết vấn đề nhiều hơn một agent thông thường
  Tôi thiết kế để nhiều agent trò chuyện với nhau nhằm giải quyết vấn đề, và agent đầu tiên đóng vai trò giám sát quản lý công việc
  Càng đi sâu vào quá trình này, nó càng trở thành một bài toán kỹ thuật hơn
  Tôi có viết chi tiết trong bài blog của mình

  • Nghe đúng là một dự án rất tuyệt

• Ai cũng thích làm agent nhưng lại ghét debug
  Ban đầu nó chạy tốt như ma thuật, nhưng rồi dần dần các lỗi mang tính xác suất tích tụ lại khiến việc tái hiện trở nên khó khăn
  Mỗi bước mất 0,5 giây, nên để kiểm tra xem nó sai ở đâu thì phải chờ 10–20 phút

  • Vì vậy tôi đã làm một công cụ chạy song song, để có thể chạy hàng trăm lần với mã đã sửa
    đồng thời chạy lại các kịch bản cũ để xác minh rằng không có gì bị hỏng

• Tôi đã làm thử một MCP dựa trên đoạn mã được cung cấp: gurddy-mcp.fly.dev
  Có thể xem mã nguồn trong repository GitHub