Một Content Writer tập gọi API bằng Craft Agents

Bản thân là một Content Writer mới, mình dùng AI nhiều nhất để tìm ý, hỏi nhanh một vấn đề hoặc gỡ một đoạn viết đang bị bí. Còn API? Trong đầu mình, đó vẫn là phần việc của developer: phải tìm đúng đường dẫn, đọc documentation, nhìn JSON và biết đặt API key ở đâu.

Điểm thay đổi khi thử Craft Agents là mình có thể mô tả mục tiêu bằng ngôn ngữ bình thường. Agent hỗ trợ tìm tài liệu, giải thích các trường cấu hình và thêm Source. Thay vì tốn thời gian như mình từng hình dung, quy trình này thậm chí còn nhanh hơn khá nhiều và giúp mình bước qua rào cản ban đầu một cách nhẹ nhàng.

Các Source mình đã thêm và mức độ trải nghiệm?

Lưu ý: Danh sách đã thêm không đồng nghĩa toàn bộ workflow đã được kiểm thử.

Giao diện Craft Agents hiển thị các Source API đã được thêm.
“Đây là lúc mình bắt đầu nhìn Source như những kết nối chuyên biệt phía sau Craft Agents.”

Khoảnh khắc làm mình thay đổi cách nhìn về AI là khi Craft Agents không chỉ trả lời câu hỏi từ tri thức có sẵn, mà còn kết nối đến các dịch vụ chuyên biệt để lấy dữ liệu thời gian thực và xử lý tự động. Trong bài viết này, mình sẽ chia sẻ 2 Case Study thực tế mà mình đã trực tiếp trải nghiệm:

1. Open-Meteo Air Quality API: Giải câu hỏi thực tế "Mình có thể đi tham quan kinh thành Huế vào ngày mai không? Thời tiết và chất lượng không khí ngày mai thế nào?" bằng dữ liệu US AQI, PM2.5, PM10 và UV index theo khung giờ tại Đại Nội Huế.
2. Exa Search + Firecrawl + Google Sheets: Tự động hóa nghiên cứu 20 công ty đại chúng nộp báo cáo SEC năm 2026, trích xuất EIN và xuất báo cáo chuẩn hóa lên Google Sheets. Lần chạy mất khoảng 15 phút; so với quy trình thủ công ước tính, mức tiết kiệm tương đương khoảng 96%–98%.

Mình chỉ kể lại hai lần thử thật, rồi cùng bạn bắt đầu bằng một API read-only, không cần key.
Mục tiêu của bài viết không phải để biến bạn thành một lập trình viên, mà giúp bạn thấy rõ khả năng mở rộng của AI Agent khi kết nối API — và biết cách tự kiểm chứng kết quả trước khi đưa vào công việc thực tế.

Cách mình dùng thử API đầu tiên: Tra cứu thời tiết ở Huế

Cách thêm Source mới khiến mình vừa lạ vừa thích

Thay vì tự đi tìm endpoint và cấu hình từ đầu, mình mô tả kết nối muốn có.

Connected

Trước đây, mình nghĩ thêm một API là chuỗi thao tác khá khô: tìm đúng trang tài liệu, lấy endpoint, đọc từng field rồi tự cấu hình. Nếu dịch vụ cần credential (thông tin xác thực), mình còn phải hiểu key và quyền truy cập nên đặt ở đâu. Chỉ nhìn danh sách việc đó thôi là mình đã muốn để sau.

Với Craft Agents, điểm lạ nhất là mình có thể bắt đầu bằng một cuộc trò chuyện. Mình nói tên dịch vụ muốn kết nối và việc mình định làm. Agent hỗ trợ tìm API, giải thích thông tin còn thiếu rồi thêm Source. Với API public, không cần key như Open-Meteo Air Quality, trải nghiệm của mình gần như là: gọi tên API, chờ Agent xử lý, sau đó thử một yêu cầu nhỏ.

Mình vẫn muốn giữ nhận xét cân bằng. Người đã quen API có thể thấy hội thoại và thời gian chờ chậm hơn việc tự sửa config. Với mình, nó nhanh và dễ tiếp cận hơn vì không phải tự giải hết bài toán kỹ thuật từ đầu.

Craft Agents không ưu tiên người mới rồi bỏ quên người cũ. Nó chuyển phần khó từ “mình phải gõ cấu hình thế nào?” sang “mình muốn đạt mục tiêu gì, cần cấp quyền nào và kết quả có đúng không?”. Phần khó không biến mất; nó được đặt vào chỗ mình hiểu và kiểm soát được hơn.

API giống như quầy dịch vụ: nhận yêu cầu và trả kết quả

Có lúc mình gọi đây là khoảnh khắc chạm trán “trợ lý của trợ lý”. Cách nói đó đúng với cảm giác của mình, nhưng chưa chính xác về mặt kỹ thuật. Một API thường không tự suy nghĩ. Nó cung cấp dữ liệu hoặc thực hiện một hành động theo quy tắc đã định.

Cách hình dung dễ nhất với mình là một đội dịch vụ chuyên môn phía sau Craft Agents:

• Craft Agents hiểu mục tiêu và điều phối việc cần làm.
• Source là kết nối đã được thiết lập với một dịch vụ hoặc nguồn dữ liệu.
• API cung cấp dữ liệu hay khả năng chuyên biệt.
• Tool là hành động cụ thể Craft Agents có thể gọi thông qua Source.
  

Open-Meteo: Đây là một cú chắc tay cho người mới đầu tiên với API read-only

Mình đã kiểm chứng thử với app dự báo thời tiết thường dùng trên điện thoại và kết quả tương đồng.

Vì sao API này là 'nước đi chắc tay' nhất cho người mới bắt đầu?

Open-Meteo Air Quality cho mình một bước đúng đầu tiên khá rõ: không phải đăng ký tài khoản, tạo credential, làm OAuth hay cấp quyền ghi. Mình chọn Source, mô tả địa điểm, thời gian và chỉ số cần lấy; Craft Agents xử lý request rồi trình bày kết quả thành bảng.

Điểm tiện nhất không nằm ở một con số cụ thể. Nó nằm ở việc mình có thể đi từ câu hỏi đời thường đến dữ liệu có timestamp và đơn vị mà không phải tự dựng request. API đủ đơn giản để thử ngay, nhưng kết quả vẫn hữu ích cho một quyết định hằng ngày.

Thử một workflow khó hơn với Exa, Firecrawl và Google Sheets

Lần thử thứ hai phức tạp hơn:

Yêu cầu và bối cảnh

• Mục tiêu: Tìm 20 công ty đại chúng xuất hiện trong SEC EDGAR Daily Master Index ngày 03/08/2026, có Form 10-Q chứa EIN và website chính thức có phản hồi để kiểm tra.
• Tổng hợp: Đối chiếu thông tin chính thống và xuất kết quả rõ ràng theo hàng/cột lên Google Sheet.
• Source APIs kết hợp: Exa Search (Tìm kiếm chuyên sâu ngữ nghĩa), Firecrawl (Crawl & trích xuất nội dung website), Google Sheets (Tự động ghi & tổng hợp dữ liệu báo cáo).
  

Prompt gồm tiêu chí nguồn, field và cách bàn giao kết quả.

Báo cáo và kết quả hoàn thành

• Link Google Sheet: Mở Google Sheet – 20 Public Companies, SEC 2026 & Public EIN
• Nội dung dữ liệu (20 công ty × 25 trường dữ liệu):
  • Tên pháp lý, Ticker, Sàn giao dịch.
  • EIN doanh nghiệp, CIK.
  • Bang thành lập, Địa chỉ, Điện thoại, Ngành/SIC.
  • Website chính thức & kết quả kiểm tra HTTP status.
  • Kỳ báo cáo, Ngày nộp, Accession number, Hồ sơ SEC chứa EIN.
  • Cổng tra cứu SOS & Ghi chú mức độ xác minh.
• Kết quả xác minh:
  • 20/20 EIN xuất hiện trực tiếp trên hồ sơ SEC Form 10-Q/10-K chính thức.
  • 20 CIK và EIN duy nhất, không thiếu hay trùng lặp dữ liệu.
  • 14 website trả HTTP 200; 6 website chính thức phản hồi HTTP 403 do cơ chế chống bot.

Lưu ý pháp lý: Form 10-Q và Form 10-K là báo cáo định kỳ gửi SEC, không phải tờ khai thuế IRS. EIN trong bảng là mã số thuế doanh nghiệp, không phải SSN hoặc ITIN cá nhân.

Thời gian được tiết kiệm ở đâu?

Con số 96%–98% giúp hình dung quy mô tiết kiệm, nhưng không phải benchmark đã bấm giờ cho cả hai phương pháp. Mốc thủ công gồm 17–29 phút cho từng công ty, cộng 45–90 phút thiết lập bảng và QA; thời gian thực tế còn tùy kinh nghiệm, tốc độ website và mức độ kiểm chứng - nhưng mình chắc chắn với điều này.

Thời gian giảm xuyên suốt chuỗi công việc: tìm hồ sơ, đọc trang, kiểm tra website, chuẩn hóa field và ghi báo cáo. Phần mình vẫn phải làm là rà các record quan trọng, hiểu rằng HTTP 403 không đồng nghĩa website ngừng hoạt động (mình đã kiểm chứng bằng tay), rồi xác nhận nguồn trước khi công bố. Agent xử lý phần lặp lại; mình giữ phần phán đoán biên tập.

Điều khiến mình bất ngờ hơn cả tỷ lệ là kết quả được đưa thẳng vào Google Sheets, gọn và trực quan như một báo cáo để tiếp tục review.

API cho mình câu trả lời đáng tin, kiểm tra lại để tin cho chắc

Qua hai case study thực tế với Exa, Firecrawl, Google Sheets và Open-Meteo Air Quality API, mình thấy phần khó không chỉ là làm cho API trả dữ liệu. Phần quan trọng hơn là biết kết quả đó có nghĩa gì và có thể dùng tới đâu. Trước khi đưa output vào content, mình kiểm tra năm bước này.

Tin API, nhưng kiểm tra nhanh trước khi dùng

1. Nguồn
   Dữ liệu đến từ đâu? Ưu tiên nguồn chính thức hoặc có nguồn gốc rõ ràng.

2. Ý nghĩa
   Con số và từng trường thực sự nói gì? Không tự đoán phần còn thiếu.

3. Thời gian và đơn vị
   Dữ liệu thuộc thời điểm nào, múi giờ và đơn vị gì?

4. Có an toàn để sử dụng?
   Kiểm tra quyền đăng lại và loại bỏ thông tin nhạy cảm trước khi chia sẻ.

5. Quyền của Agent
   Agent có thể đọc hay thay đổi những gì? Chỉ cấp quyền thật sự cần thiết.

Read-only access

Người mới không cần học sâu code mới được thử API. Nhưng mình vẫn phải hiểu dữ liệu đang yêu cầu và chịu trách nhiệm với cách sử dụng output. Fact-check không phải phần phụ ở cuối bài; nó là một bước của workflow.

Một phản hồi HTTP 403 cũng không đủ để nói website không hoạt động; nó chỉ cho biết request đó bị từ chối. Checklist này không làm workflow nhanh hơn, nhưng giúp mình không đánh đổi độ tin cậy để lấy một bảng báo cáo đẹp.

Những điều mình học được sau hai lần thử API

Sau hai case và một lần tự đối chiếu dữ liệu, mình rút ra năm điều:

• Không biết nhiều code vẫn có thể bắt đầu. Mình chưa cần học hết REST, headers hay JSON schema để thử API read-only, nhưng vẫn phải hiểu dữ liệu đang yêu cầu.
• Hội thoại giảm rào cản chứ không xóa kỹ thuật. Với mình, nói mục tiêu dễ hơn tự config; với người có kinh nghiệm, chờ Agent có thể chậm hơn thao tác trực tiếp.
• Source đã test quan trọng hơn Source đã thêm. Chỉ output thật mới cho biết kết nối, field và permission có đúng hay không.
• API làm tốt phần lặp lại. Tìm nguồn, đọc trang, chuẩn hóa field và ghi Google Sheets là những bước khiến mình cảm thấy tiết kiệm công sức rõ nhất. Tiêu chí và quyết định dùng kết quả vẫn thuộc về mình.
• Nên bắt đầu từ nhiệm vụ, không phải tên công cụ. Một yêu cầu nhỏ, ít field và dễ kiểm chứng giúp mình hiểu workflow tốt hơn việc thêm cả chục API rồi không biết thử gì.

Chọn API nhỏ, test output thật: Tự tin tuyên bố "xong xuôi!"

Mấy lần tự tay thử nghiệm làm cho cách mình nhìn Craft Agents khác hẳn lúc đầu. Nó không còn là cái khung chat để mình gõ câu hỏi rồi ngồi chờ nhận vài đoạn chữ trả lời nữa. Khi gắn đúng API, Agent tự truy cập vào các dịch vụ bên ngoài, bốc dữ liệu về rồi xếp thành bảng ngay ngắn theo đúng ý mình.

Mô tả nhu cầu bằng ngôn ngữ tự nhiên giúp dân làm content bớt ngợp hẳn vì không phải tự đọc docs hay mò gõ config thủ công. Nhưng nói thật, API vẫn là API. Mấy thứ như endpoint, quyền truy cập hay dữ liệu trả về đúng hay sai thì mình vẫn phải soi kỹ chứ không tự biến mất được. Danh sách gắn sẵn cả chục Source nhìn oách vậy thôi, chứ từng workflow chưa chạy ra kết quả thật thì chưa thể tính là xong.

Nếu bạn cũng không rành code như mình, cứ bắt đầu bằng một API thiệt nhẹ: chọn cái nào public, read-only (chỉ đọc dữ liệu) kiểu Open-Meteo Air Quality API. Yêu cầu một dòng ngắn, thấy dữ liệu hiện ra chuẩn là... xong!

Sự tự tin không nằm ở mấy câu quảng cáo kiểu "không cần biết code". Với mình, nó nằm ở chỗ mình biết rõ mình đang cần gì, Agent đang lấy dữ liệu ở đâu và mình tự kiểm tra lại được kết quả đó trước khi xài.

"...Và khi đã soi xong output thật mà mọi thứ chuẩn đét, bạn hoàn toàn có thể tự tin thốt lên một câu chuẩn bài dân chơi Dota 2: It’s in the bag!"

Bước tiếp theo: tìm hiểu MCP cùng Craft Agents

Hành trình này chỉ mới bắt đầu. Trong bài viết tiếp theo, mình sẽ tìm hiểu về MCP (Model Context Protocol) trong Craft Agents — nhất là cách Agent được cấp quyền để làm việc với các ứng dụng bên ngoài.

Thay vì chỉ dừng lại ở lý thuyết có thể search nhanh và nhiều trên google, mình dự định tự thiết lập và kiểm tra một vài workflow đơn giản. Mình sẽ ghi lại quá trình thực hành một cách thật thà - không giấu dốt: điều gì hoạt động, điều gì chưa như mong đợi, mình còn vướng ở đâu và đã rút ra được bài học gì.

Mục tiêu của mình không phải là nhanh chóng chứng minh rằng bản thân đã hiểu AI, mà là từng bước xây dựng sự hiểu biết dựa trên những gì đã thực sự thử nghiệm. Càng tìm hiểu, mình càng nhận ra rằng việc trao thêm khả năng cho Agent cũng cần đi cùng với hiểu biết rõ ràng về quyền truy cập, luồng dữ liệu và giới hạn kiểm soát.

Nếu bạn cũng đang tìm hiểu MCP và muốn đồng hành trong hành trình này, bạn có thể đăng ký newsletter của Sonjj.com. Mình chưa muốn hứa trước một lịch xuất bản cụ thể, nhưng sẽ tiếp tục chia sẻ khi đã tự mình kiểm chứng và có đủ bằng chứng rõ ràng.

Xin chào và hẹn gặp lại các bạn.