Công cụ mới để xây dựng agent
(openai.com)- OpenAI công bố Responses API, các công cụ tích hợp sẵn, Agents SDK và công cụ quan sát nhằm giúp việc phát triển agent dùng cho production trở nên dễ dàng hơn
- Responses API kết hợp sự đơn giản của Chat Completions API với khả năng sử dụng công cụ của Assistants API, cho phép xử lý tìm kiếm web, tìm kiếm tệp và sử dụng máy tính trong một luồng duy nhất
- Với các tích hợp mới, OpenAI khuyến nghị dùng Responses API; Assistants API sẽ bước vào quá trình ngừng cung cấp, với mục tiêu kết thúc vào giữa năm 2026 sau khi đạt mức tương đương về tính năng
- Các công cụ tích hợp sẵn hỗ trợ thông tin web mới nhất, tìm kiếm trong tài liệu quy mô lớn và tự động hóa tác vụ máy tính dựa trên chuột/bàn phím, nhưng với computer use, đặc biệt trong môi trường không phải trình duyệt, nên có sự giám sát của con người
- Nhà phát triển có thể kết hợp API, công cụ, SDK, tính năng truy vết và đánh giá trên một nền tảng để xây dựng, triển khai và tối ưu hóa agent
Các thành phần mới để phát triển agent
- OpenAI xem agent là hệ thống độc lập thực hiện công việc thay mặt người dùng
- Trong năm qua, suy luận nâng cao, tương tác đa phương thức và các kỹ thuật an toàn mới đã được đưa vào, tạo nền tảng để xử lý các tác vụ phức tạp gồm nhiều bước
- Khách hàng gặp khó khăn khi chuyển các năng lực này thành agent sẵn sàng cho production
- Cần lặp lại prompt trên phạm vi rộng
- Phải tự xây dựng logic điều phối tùy chỉnh
- Thiếu đủ khả năng quan sát và hỗ trợ tích hợp sẵn
- Các thành phần được công bố lần này gồm
- Responses API: kết hợp sự đơn giản của Chat Completions API với khả năng sử dụng công cụ của Assistants API
- Công cụ tích hợp sẵn: web search, file search, computer use
- Agents SDK: điều phối workflow một agent và đa agent
- Công cụ quan sát: theo dõi và kiểm tra quá trình chạy workflow của agent
Responses API
- Responses API là đơn vị API nền tảng mới để tạo agent bằng các công cụ tích hợp sẵn của OpenAI
- Kết hợp sự đơn giản của Chat Completions với khả năng sử dụng công cụ của Assistants API
- Trong một lần gọi Responses API, có thể dùng nhiều công cụ và nhiều lượt model để xử lý các tác vụ phức tạp hơn
- Các công cụ được hỗ trợ ban đầu gồm
- Tìm kiếm web
- Tìm kiếm tệp
- Sử dụng máy tính
- Cũng bao gồm các cải tiến về khả năng sử dụng
- Thiết kế thống nhất dựa trên item
- Đa hình đơn giản hơn
- Sự kiện streaming trực quan
- Helper SDK như
response.output_text
- Được thiết kế cho nhà phát triển muốn kết hợp model OpenAI và công cụ tích hợp sẵn vào ứng dụng mà không phải tích hợp riêng nhiều API hay nhà cung cấp bên ngoài
- Khi lưu dữ liệu trên OpenAI, việc đánh giá hiệu năng agent trở nên dễ dàng hơn nhờ tính năng truy vết và đánh giá
- Theo mặc định, OpenAI không dùng dữ liệu kinh doanh để huấn luyện model, và điều này vẫn áp dụng ngay cả khi dữ liệu được lưu trên OpenAI
- Tất cả nhà phát triển có thể sử dụng từ hôm nay, không có phí riêng; token và công cụ được tính theo mức giá tiêu chuẩn trên trang giá
- Tài liệu bắt đầu có tại Responses API quickstart guide
Quan hệ với các API hiện có
- Chat Completions API sẽ tiếp tục được hỗ trợ với vai trò API được áp dụng rộng rãi nhất của OpenAI
- Nhà phát triển không cần công cụ tích hợp sẵn có thể tiếp tục sử dụng
- Các model mới cho những tính năng không phụ thuộc vào công cụ tích hợp sẵn hoặc nhiều lần gọi model vẫn sẽ tiếp tục được phát hành trên Chat Completions
- Responses API là siêu tập hợp của Chat Completions và cung cấp cùng hiệu năng, nên OpenAI khuyến nghị Responses API cho các tích hợp mới
- Phản hồi beta của Assistants API đã được phản ánh vào Responses API, giúp API này linh hoạt hơn, nhanh hơn và dễ dùng hơn
- OpenAI đang tiến tới đạt mức tương đương đầy đủ về tính năng giữa Assistants API và Responses API, bao gồm đối tượng kiểu Assistant, đối tượng kiểu Thread và công cụ Code Interpreter
- Khi hoàn tất tương đương tính năng, OpenAI dự kiến công bố chính thức việc ngừng Assistants API
- Thời điểm kết thúc mục tiêu là giữa năm 2026
- Khi công bố ngừng cung cấp, OpenAI sẽ cung cấp hướng dẫn migration để có thể giữ dữ liệu và chuyển ứng dụng
- Trước khi có công bố ngừng chính thức, Assistants API vẫn sẽ tiếp tục được cung cấp các model mới
- OpenAI xem Responses API là hướng đi tương lai để xây dựng agent trên OpenAI
Công cụ tích hợp sẵn của Responses API
-
Tìm kiếm web
- Nhà phát triển có thể nhận câu trả lời nhanh và cập nhật từ web kèm trích dẫn nguồn rõ ràng
- Trong Responses API, tìm kiếm web được cung cấp như một công cụ khi dùng
gpt-4ovàgpt-4o-mini, và có thể dùng cùng các công cụ khác hoặc function calling - Các trường hợp sử dụng trong thử nghiệm ban đầu là những ứng dụng cần thông tin web mới nhất, như trợ lý mua sắm, agent nghiên cứu và agent đặt chuyến du lịch
- Hebbia dùng công cụ tìm kiếm web để giúp các công ty quản lý tài sản, quỹ tư nhân và công ty tín dụng, cũng như chuyên viên pháp lý nhanh chóng trích xuất insight có thể hành động từ các tập dữ liệu công khai và riêng tư quy mô lớn
- Tìm kiếm web trong API dựa trên cùng model được dùng cho ChatGPT search
- Trên SimpleQA, GPT‑4o search preview đạt độ chính xác 90%, GPT‑4o mini search preview đạt 88%
- Phản hồi tìm kiếm web của API bao gồm liên kết đến nguồn như bài báo và bài blog
- Website hoặc nhà xuất bản có thể chọn để được hiển thị trong tìm kiếm web của API
- Công cụ tìm kiếm web được cung cấp dưới dạng preview cho mọi nhà phát triển trong Responses API
- Trong Chat Completions API, có thể truy cập trực tiếp các model tìm kiếm qua
gpt-4o-search-preview,gpt-4o-mini-search-preview - Giá bắt đầu từ 30 USD cho mỗi 1.000 truy vấn với GPT‑4o search và 25 USD cho mỗi 1.000 truy vấn với 4o-mini search
-
Tìm kiếm tệp
- Công cụ file search được cải tiến giúp dễ dàng tìm thông tin liên quan trong tài liệu quy mô lớn
- Hỗ trợ nhiều định dạng tệp, tối ưu hóa truy vấn, lọc metadata và reranking tùy chỉnh
- Trong Responses API, có thể tích hợp chỉ với vài dòng code
- Các trường hợp sử dụng gồm
- Agent hỗ trợ khách hàng truy cập FAQ
- Trợ lý pháp lý nhanh chóng tham chiếu các vụ việc trước đây cho chuyên gia đủ điều kiện
- Agent lập trình tra cứu tài liệu kỹ thuật
- Navan dùng file search trong agent du lịch dựa trên AI để nhanh chóng cung cấp câu trả lời chính xác từ tài liệu knowledge base như chính sách công tác của công ty
- Với tối ưu hóa truy vấn và reranking tích hợp sẵn, có thể xây dựng pipeline RAG mà không cần tinh chỉnh hoặc cấu hình bổ sung
- Nếu có vector store riêng cho từng nhóm người dùng, có thể cung cấp câu trả lời phù hợp với thiết lập tài khoản và vai trò người dùng
- file search hiện có cho mọi nhà phát triển trong Responses API
- Giá sử dụng là 2,50 USD cho mỗi 1.000 truy vấn; lưu trữ tệp là 0,10 USD mỗi GB mỗi ngày, miễn phí 1GB đầu tiên
- Vẫn tiếp tục được cung cấp trong Assistants API
- Đối tượng Vector Store API được bổ sung endpoint tìm kiếm mới, cho phép truy vấn trực tiếp dữ liệu để sử dụng trong các ứng dụng và API khác
-
Sử dụng máy tính
- Công cụ computer use là tính năng để tạo agent thực hiện tác vụ trên máy tính trong Responses API
- Công cụ này được vận hành bởi Computer-Using Agent(CUA) model, model đã tạo nên Operator
- Model research preview đạt kết quả benchmark như sau
- OSWorld: 38,1% trên tổng thể tác vụ sử dụng máy tính
- WebArena: 58,1%
- WebVoyager: 87% trên tương tác dựa trên web
- Công cụ computer use tích hợp sẵn ghi lại các thao tác chuột và bàn phím do model tạo ra
- Nhà phát triển có thể chuyển các thao tác này thành lệnh có thể chạy trong môi trường của mình để tự động hóa tác vụ sử dụng máy tính
- Các trường hợp sử dụng là tự động hóa workflow dựa trên trình duyệt, như kiểm thử chất lượng ứng dụng web và nhập dữ liệu giữa các hệ thống legacy
- Unify dùng công cụ computer use trong hệ thống tăng trưởng doanh thu, nơi agent thực hiện nhận diện ý định, nghiên cứu tài khoản và tiếp cận người mua
- Agent cũng có thể tận dụng thông tin vốn không thể truy cập qua API
- Ví dụ, một công ty quản lý bất động sản có thể dùng bản đồ trực tuyến để xác minh liệu quy mô bất động sản của một doanh nghiệp có được mở rộng hay không
- Luminai tích hợp công cụ computer use để tự động hóa các workflow vận hành phức tạp cho doanh nghiệp lớn có hệ thống legacy không có API và dữ liệu chuẩn hóa
- Trong một pilot tại một tổ chức dịch vụ cộng đồng lớn, họ đã tự động hóa quy trình xử lý đơn và đăng ký người dùng chỉ trong vài ngày
- RPA truyền thống khó đạt được cùng tác vụ này dù đã thử trong nhiều tháng
- Trước khi phát hành CUA cho Operator, OpenAI đã thực hiện kiểm thử an toàn và red team rộng rãi trên ba lĩnh vực: lạm dụng, lỗi model và rủi ro frontier
- Để xử lý rủi ro khi tính năng Operator được mở rộng sang hệ điều hành cục bộ thông qua CUA trong API, OpenAI cũng đã tiến hành đánh giá an toàn và red team bổ sung
- Các biện pháp giảm thiểu cho nhà phát triển cũng được bổ sung
- Kiểm tra an toàn để phòng thủ prompt injection
- Prompt xác nhận cho các tác vụ nhạy cảm
- Công cụ giúp cách ly môi trường
- Phát hiện nâng cao đối với các vi phạm chính sách tiềm tàng
- Dù các biện pháp giảm thiểu giúp giảm rủi ro, model vẫn có thể mắc lỗi ngoài ý muốn, đặc biệt trong môi trường không phải trình duyệt
- Hiệu năng OSWorld 38,1% cho thấy khả năng tự động hóa tác vụ hệ điều hành chưa đạt độ tin cậy cao, và trong trường hợp này nên có sự giám sát của con người
- Chi tiết về công tác an toàn riêng cho API có trong system card đã cập nhật
Agents SDK và điều phối workflow
- Agent không chỉ cần logic cốt lõi và quyền truy cập công cụ, mà còn cần điều phối workflow
- Agents SDK mã nguồn mở mới giúp đơn giản hóa việc điều phối workflow đa agent
- Được cải tiến so với SDK thử nghiệm Swarm công bố năm ngoái
- Các tính năng chính gồm
- Agents: LLM dễ cấu hình với chỉ dẫn rõ ràng và công cụ tích hợp sẵn
- Handoffs: chuyển giao quyền điều khiển giữa các agent một cách thông minh
- Guardrails: kiểm tra an toàn có thể cấu hình để xác thực đầu vào và đầu ra
- Tracing & Observability: trực quan hóa truy vết quá trình chạy agent để hỗ trợ debug và tối ưu hóa hiệu năng
- Các trường hợp sử dụng thực tế có thể áp dụng gồm tự động hóa hỗ trợ khách hàng, nghiên cứu nhiều bước, tạo nội dung, review code và tìm kiếm lead bán hàng
- Coinbase dùng Agents SDK để nhanh chóng prototype và triển khai AgentKit, cho phép AI agent tương tác với ví tiền mã hóa và hoạt động on-chain
- Chỉ trong vài giờ, họ đã tích hợp các action tùy chỉnh của Developer Platform SDK vào một agent hoạt động đầy đủ
- Kiến trúc đơn giản hóa của AgentKit giúp việc thêm action agent mới trở nên đơn giản hơn
- Box trong vài ngày đã tạo agent sử dụng tìm kiếm web và Agents SDK, cho phép tìm kiếm, hỏi đáp và trích xuất insight từ dữ liệu phi cấu trúc nội bộ của Box và các nguồn internet công khai
- Khách hàng doanh nghiệp có thể tìm kiếm không chỉ thông tin mới nhất mà cả dữ liệu độc quyền nội bộ theo cách tuân thủ quyền nội bộ và chính sách bảo mật
- Ví dụ, một công ty dịch vụ tài chính có thể tạo agent tùy chỉnh kết hợp phân tích thị trường nội bộ lưu trong Box với tin tức và dữ liệu kinh tế thời gian thực trên web
- Agents SDK hoạt động với Responses API và Chat Completions API
- Cũng có thể dùng với model của nhà cung cấp khác nếu họ cung cấp endpoint API kiểu Chat Completions
- Có thể tích hợp ngay vào codebase Python; hỗ trợ Node.js sẽ sớm được cung cấp
- Trong thiết kế Agents SDK, OpenAI lấy cảm hứng từ công việc của Pydantic, Griffe và MkDocs
- OpenAI dự định tiếp tục xây dựng Agents SDK như một framework mã nguồn mở để cộng đồng có thể mở rộng cách tiếp cận này
Hướng mở rộng nền tảng agent
- OpenAI cho rằng agent sẽ sớm trở thành thành phần cốt lõi của lực lượng lao động và nâng cao đáng kể năng suất trên nhiều ngành
- Khi nhu cầu của doanh nghiệp trong việc sử dụng AI cho các tác vụ phức tạp tăng lên, OpenAI tập trung cung cấp các thành phần giúp nhà phát triển và doanh nghiệp tạo ra hệ thống tự chủ có tác động thực tế
- Lần công bố này là các thành phần đầu tiên nhằm giúp xây dựng, triển khai và mở rộng AI agent đáng tin cậy, hiệu năng cao dễ dàng hơn
- Khi năng lực model phát triển theo hướng agent hơn, OpenAI dự định tiếp tục đầu tư vào tích hợp sâu hơn trên toàn bộ API và các công cụ mới giúp triển khai, đánh giá và tối ưu hóa agent production
- Mục tiêu là cung cấp trải nghiệm nền tảng liền mạch để tạo agent có thể hỗ trợ nhiều tác vụ trong mọi ngành
1 bình luận
Ý kiến trên Hacker News
Không rõ những biến động API kiểu này sẽ giúp được bao nhiêu cho các nhà phát triển muốn gắn OpenAI vào sản phẩm thật
Các máy trạng thái do nhà cung cấp quản lý để xử lý hội thoại, tin nhắn, truyền prompt, v.v. cuối cùng với nhu cầu của tôi đều thiếu, giả định quá mức, hoặc gây cản trở
Cuối cùng tôi vẫn dùng Chat Completions API chỉ bật structured output, và ngay trong đó vẫn làm đủ việc như dùng công cụ, hội thoại đệ quy, RAG, v.v.
Tôi không thấy đáng để giao việc quản lý trạng thái “agent” của mình cho bên thứ ba; để những thứ này ở local thì tự chủ hơn nhiều
Cốt lõi chỉ là đưa một chuỗi literal nào đó vào hộp đen rồi nhận lại một chuỗi mới, tốt nhất là theo định dạng đã yêu cầu như JSON
Nếu tập trung vào góc nhìn rằng mỗi lần là ghép đúng chuỗi phù hợp, phần còn lại sẽ biến mất; việc này trở thành tạo ra các chuỗi có cấu trúc cao từ trạng thái nghiệp vụ trong cơ sở dữ liệu
Về bản chất gần như giống server-side rendering trang web bằng PHP, khác biệt thật sự chỉ là cách cung cấp
Tôi vẫn chưa tìm được framework agent nào bổ sung đúng những thứ tôi cần lên trên một lời gọi sinh có cấu trúc đơn giản
Phần lớn yêu cầu LLM nên là “nhập prompt, xuất có cấu trúc”, và điều đó cũng hợp với triết lý Unix: làm tốt một việc
Framework agent còn quá sớm, chỉ là một lớp trừu tượng hóa gói một tập các mẫu thiết kế chưa phổ biến
Chỉ nên tạo trừu tượng khi rõ ràng mọi người đều đang phát minh lại bánh xe; với agent thì không có bánh xe nào cần phát minh, tất cả chỉ là các lời gọi mô hình ngôn ngữ đơn giản
Tôi hay nói rằng “mô hình ngôn ngữ nên là phần nhàm chán nhất trong code”
Phần lớn thời gian nên dành cho việc xây dựng phần mềm và công cụ thật sự, còn LLM chỉ nên là một thành phần nhỏ của phần mềm
Theo gu của tôi, framework agent làm sự hiện diện của mô hình ngôn ngữ trong codebase trở nên quá lớn
Ngay cả trừu tượng function calling của OpenAI cũng hallucinate tham số và schema, còn bản thân JSON Schema thì quá dài dòng; chỉ cần phức tạp hơn một chút so với 5 lời gọi hàm rất đơn giản là sụp hẳn
Trông như chồng thêm lên trên một trừu tượng hộp đen vốn đã hỏng, và không mấy hữu ích cho ứng dụng thực tế
Có thể hữu ích để nhanh chóng làm các ứng dụng proof-of-concept nhỏ
Phải khá ngây thơ mới xây công ty trên các API kiểu này
LLM sẽ trở thành hàng hóa phổ thông, và OpenAI buộc phải chống lại số phận đó nếu muốn biện minh cho định giá công ty và quy mô đầu tư liên tục cần có
Nếu đã xây trên Assistant API, hãy hiểu gợi ý đó và sở hữu sản phẩm của mình, đừng chỉ viết lại sang Responses API
LLM ngày nay tốt hơn nên được bọc trong một hộp đen
Là do đoạn: “Khi dùng Chat Completions, mô hình luôn lấy thông tin từ web trước khi phản hồi. Nếu muốn các mô hình như gpt-4o và gpt-4o-mini chỉ gọi web_search_preview như một công cụ khi cần, hãy chuyển sang Responses API”
Việc port sang Responses API mới không đơn giản, và chúng tôi đã có sẵn history, RAG, cùng những thứ cần cho assistant
Tôi đã phát triển nhiều agent chỉ với function calling và structured output, và chạy production hơn 1 năm rồi
Trước đây chúng tôi còn không gọi chúng là agent
Lần này có vẻ nhắm tới những người vốn đã dùng framework agent cùng với OpenAI API
Có một thread Twitter hay, trong đó người thiết kế API mới giải thích bối cảnh đằng sau nhiều quyết định thiết kế: https://twitter.com/athyuttamre/status/1899541471532867821
Cũng có liên kết thay thế cho những ai chưa đăng nhập Twitter: https://nitter.net/athyuttamre/status/1899541471532867821
Những nỗ lực về agent AI kiểu này có vẻ đã lệch ngay từ cốt lõi
Vì chúng cố thay thế con người trong các hệ thống hiện có thay vì tạo ra một cách làm mới
Về căn bản là thiển cận, vì kinh tế, đời sống, mọi thứ rốt cuộc đều xoay quanh tương tác giữa người với người
Cách tiếp cận agent AI hiện nay giống như một biến thể của câu đùa “AI kéo một câu thành email dài và nghe hợp lý, rồi AI phía nhận lại tóm tắt email dài đó thành một câu”
Tôi hiểu giá trị của việc tự động hóa các tác vụ trong hệ thống hiện có, nhưng cơ hội thật sự nằm ở việc loại bỏ phần lớn các hệ thống hiện có
Con người cũng không tệ đến thế
Tôi tự hỏi liệu việc dùng AI tạo UI cho con người rồi lại để AI thao tác UI đó có thật sự là con đường tiến lên hay không
Bạn dùng bao nhiêu chiếc giỏ đan từ cành cây bẻ bằng tay?
Lịch sử cho thấy thứ gì tự động hóa được thì sẽ được tự động hóa, và thứ gì có thể làm rẻ hơn hoặc nhanh hơn thì cũng sẽ đi theo hướng đó
Ví dụ trong hệ sinh thái B2B SaaS, dùng như một trải nghiệm người dùng phụ trợ để người dùng nâng cao trong tổ chức có thể macro hóa các tác vụ cấu hình khách hàng và quản lý dự án
Nếu trừu tượng, ngữ cảnh và tập người dùng được giới hạn tốt, việc sử dụng công cụ có thể khá ổn định
Thiếu sót đáng chú ý: Model Context Protocol
https://www.anthropic.com/news/model-context-protocol
Agent luôn cần một dạng giao thức giao tiếp nào đó, và thế giới các framework kiểu agent là một biển logo, nên sẽ khó nếu không có chuẩn mở
Hiện tôi đang ở Comet, cũng đã trực tiếp làm phần triển khai MCP và đóng góp cho Agent SDK dưới dạng tích hợp native cùng cải thiện test suite
https://github.com/comet-ml/opik-mcp
https://github.com/openai/openai-agents-python/pull/91
Tích hợp gần đây đã được phát hành ngay trong ngày đầu tiên
https://www.comet.com/docs/opik/tracing/integrations/openai_...
Tôi nghĩ trọng tâm mà OpenAI đang hướng tới là đem lại sự đơn giản cho lập trình viên thông qua các thành phần dễ dùng
Tôi sẽ không nói về chiến lược hay giá cả, nhưng từ góc nhìn lập trình viên, khi nhìn lần đầu, cách tiếp cận module đơn giản và không rườm rà của SDK khá mới mẻ
Cái này không phải loại tổng quát, mà là để dùng các lời gọi công cụ mcp.run với mô hình OpenAI
Dù vậy, việc không hỗ trợ trực tiếp MCP gần như là một trong những động thái thiếu thân thiện nhất với lập trình viên, và nếu là OpenAI thì cũng không bất ngờ
Nếu được bổ sung thì sẽ rất tuyệt
Trước câu hỏi “Agents SDK có hỗ trợ kết nối MCP không? Có thể dễ dàng cấp công cụ cho một agent cụ thể thông qua kết nối client-server MCP không?”, câu trả lời là “vì bạn có thể định nghĩa bất kỳ công cụ nào mình muốn, nên có thể triển khai công cụ MCP bằng function calling”
Tóm lại, bạn phải tự làm một chút công việc đi dây
Issue liên quan: https://github.com/openai/openai-agents-python/issues/23
Tôi là swyx
Tôi đã có thời gian xem trước toàn bộ API mới và hỏi nhóm API/DX các câu hỏi thường gặp
https://latent.space/p/openai-agents-platform
Điểm cốt lõi thú vị là giờ response mặc định được lưu miễn phí, vậy liệu có thể lạm dụng Responses API như một cơ sở dữ liệu hay không
Cũng có những câu hỏi mà người trên HN có lẽ sẽ thích
Các siêu tham số của tìm kiếm web, tức là cách điều chỉnh độ sâu và độ rộng của tìm kiếm khi tự làm DIY Deep Research
Khi OAI nay cung cấp sẵn RAG và reranking như một phần của Responses API, thì khi nào nên tự xây RAG
Cá nhân tôi nghĩ ai đó nên benchmark hiệu năng RAG của Files API. Ấn tượng của cộng đồng dường như chưa được cập nhật nhiều kể từ lần ra mắt đầu tiên của Assistants API
Khác biệt giữa Agents SDK và OAI Swarm đại khái là kiểu dữ liệu, tracing, và LLM có thể hoán đổi
Tôi cũng tò mò liệu fine-tuning
search-previewvàcomputer-use-previewcó được gộp vào GPT5 hay không0 - https://ai.pydantic.dev/
Một trong những lý do chính để tự làm các công cụ tìm kiếm AI như vậy là có toàn quyền kiểm soát độ sâu và độ rộng, đồng thời cũng có thể tùy biến loader theo dữ liệu hoặc trang web mong muốn
Hiện tìm kiếm web không minh bạch về việc trang nào không có toàn văn và trang nào chỉ dùng snippet
Có cả computer use và tìm kiếm web cùng lúc chắc chắn rất mạnh. Về bản chất, nó giống Deep Research của OpenAI
Bài thuyết trình không công bố giá
Rất có khả năng là vì họ biết nó sẽ rất đắt
Tìm kiếm web [0]: GPT‑4o search và 4o-mini search lần lượt là $30, $25 cho mỗi 1.000 truy vấn
Tìm kiếm tệp [1]: $2,50 cho mỗi 1.000 truy vấn, lưu trữ tệp là $0,10/GB/ngày, miễn phí 1GB đầu tiên
Công cụ sử dụng máy tính (mô hình computer-use-preview) [2]: $3 cho mỗi 1 triệu token đầu vào, $12 cho mỗi 1 triệu token đầu ra
[0] https://platform.openai.com/docs/pricing#web-search
[1] https://platform.openai.com/docs/pricing#built-in-tools
[2] https://platform.openai.com/docs/pricing#latest-models
Không rõ API này tốt hơn https://www.anthropic.com/news/model-context-protocol ở điểm nào
Động cơ có vẻ giống “làm sao kiếm được nhiều tiền hơn” hơn là “làm sao hữu ích hơn cho người dùng”
Tôi thích đấy, một nước đi táo bạo
Đến lúc những người chậm chạp ở Google cuối cùng cũng bắt kịp thì có khi đã quá muộn với Google
Tôi cũng đã viết một script tìm kiếm web và hoạt động khá tốt. Dùng vercel ai sdk [1]
[0] - https://brave.com/search/api/
[1] - https://gist.github.com/bramses/41e90b27d156590154bcefd4119f...
Tôi đã tự làm một phiên bản đơn giản và mạnh hơn nhiều so với Responses API, và nó hoạt động với mọi nhà cung cấp LLM
https://github.com/Anilturaga/aiide
Trông hay đấy, có vẻ thật sự rất ổn
Có câu “chúng tôi dự định chính thức công bố việc ngừng hỗ trợ Assistant API, với mốc kết thúc mục tiêu là giữa năm 2026”
Responses API mới là một bước đi đúng hướng, thậm chí có cả chức năng “handoff” tích hợp
Tuy nhiên với các use case dạng agent thì vẫn cảm thấy còn hơi hạn chế, và còn thiếu guardrail·logic máy trạng thái chính thức
Họ nói “mục tiêu là cung cấp trải nghiệm nền tảng mượt mà để nhà phát triển có thể xây dựng agent”, nên sẽ rất thú vị xem họ sẽ chuyển sang nền tảng này như thế nào
Có lẽ trong vài tháng nữa chúng ta sẽ thấy control flow dựa trên graph
Hiện giờ cũng có vô số giải pháp open source, nhưng đa số còn thiếu sót hoặc thêm vào sự mơ hồ và phức tạp không cần thiết
Có thể tạo luồng dạng agent bằng cách kết hợp gọi công cụ và phản hồi JSON, nhưng vẫn thiếu thành phần cấp cao mà chưa ai giải quyết đúng cách
Sự tiến bộ của Computer Use được nhắc đến ở đây khá ấn tượng, nên tôi tự hỏi liệu nó đã đủ trưởng thành để dùng cho usability testing chưa
Nói chung, nếu một UI khiến AI khó điều hướng thì có khả năng nó cũng tương đối khó với con người, và liệu có thể xem đó là tín hiệu rằng nó cần được đơn giản hóa hoặc cải thiện theo cách nào đó không?
Cách LLM tương tác với UI và cách con người dùng UI rất khác nhau
Agents SDK được liên kết đang hiện 404
Nhân tiện, MindRoot có thứ dùng task API tương tự một phần với Responses và File Search: https://github.com/runvnc/mindroot/blob/main/api.md
Cái này có thể kết hợp với công cụ query_kb của plugin mr_kb, và vì cho phép tìm kiếm nhiều KB nên thực tế có thể còn tốt hơn File Search
Ai muốn giúp chương trình của tôi, làm plugin hoặc gửi PR thì cứ thoải mái liên hệ qua GitHub, email, Discord/Telegram(runvnc)
Có thể là do đã đăng nhập