Artifact và skill

Các tool này biến công việc của một lượt thành thứ lâu dài — một artifactArtifactArtifactTệp agent tạo cho bạn trong cuộc trò chuyện — tài liệu, bảng tính, slide hay ứng dụng nhỏ — mà bạn có thể mở, tải về và chia sẻ.Mở trong Thuật ngữ — và định hình cách agent làm việc: nạp chỉ dẫn của một skillSkillSkillBộ hướng dẫn dùng lại được mà agent nạp khi công việc cần, ví dụ viết báo cáo theo mẫu của công ty.Mở trong Thuật ngữ, đặt câu hỏi làm rõCâu hỏi làm rõClarificationCâu hỏi agent đặt cho bạn giữa lượt, kèm gợi ý trả lời và ô để tự nhập. Trả lời sẽ tiếp tục đúng lượt đó.Mở trong Thuật ngữ và giữ một danh sách việc hiển thị được.

Quy tắc chính

1. Artifact dành cho đầu ra dùng lại được. Văn bản trả lời ở lại trong cuộc trò chuyện.
2. Tệp trực quan được kiểm tra trước khi lưu. Lần lưu mang checksum của đúng bản đã kiểm tra.
3. Skill không cấp tool. Nạp skill là đọc chỉ dẫn; danh sách tool đã chốt trước khi vòng lặp bắt đầu.
4. Câu hỏi làm rõ tạm dừng cùng một tác vụ. Câu trả lời quay về như kết quả của tool.
5. Danh sách việc không phải tệp. update_tasks gửi cả danh sách mỗi lần.

Artifact

Artifact là đầu ra đáng kể, dùng lại được, mà người dùng sẽ mở lại hoặc tải xuống. Chủ sở hữu được xác định từ lượt. Sửa phiên bản là chỗ duy nhất mô hình cung cấp mã định danh — lấy từ kết quả của lần tạo và được backend đối chiếu với tổ chức của người gọi; mã sai là một lỗi bình thường.

Lần ghi trả về mã và phiên bản, và màn hình chat hiển thị thẻ artifact ngay tại điểm đó trong lượt. Một lượt có thể hiển thị nhiều artifact, và bản sửa sau xuất hiện lại đúng nơi nó được tạo. Đọc và các phiên bản khác mở trong bảng bên.

Sáu loại

Loại	Nội dung
Văn bản (DOCUMENT)	Markdown
Code (CODE)	Tệp mã nguồn
Bản xem web (WEB_PREVIEW)	Một tài liệu HTML hoàn chỉnh
Tệp (FILE)	Một tệp đã lưu, và với bộ slide thì kèm HTML đã dựng nó
Biểu đồ (CHART)	Một chuỗi dữ liệu và các dòng của nó
Sơ đồ (DIAGRAM)	Mermaid (ưu tiên), hoặc các nút có vị trí và đường nối

Định dạng được khai báo một lần và dùng chung cho tool tạo và tool sửa.

Tạo và sửa

• Với văn bản, code, biểu đồ và sơ đồ, create_artifact và rewrite_artifact nhận đúng một trong content nội tuyến hoặc path trong workspace. Nội dung đã có trong workspace được lưu theo đường dẫn, giữ nguyên UTF-8 mà không cần mô hình chép lại.
• Viết lại theo đường dẫn cần expectedVersion. Lần viết lại nêu phiên bản khác bản đã lưu bị từ chối kèm số phiên bản đã lưu — trước đây lời từ chối chỉ nói “phiên bản đã đổi” khiến mô hình lưu một artifact thứ hai thay vì phiên bản mới.
• Thay đổi nhỏ dùng chỉnh sửa qua update_artifact.
• Lưu .pptx mà không nêu HTML đã dựng nó bị từ chối ngay khi lần gọi còn đang được viết, nên mô hình biết thiếu gì trong cùng bước.
• Tiến trình trong chat phân biệt lúc chuẩn bị lần gọi với lúc lưu tham số đã hoàn chỉnh.

Kiểm tra → checksum → lưu

In ra PDF

print_pdf chuyển một tệp HTML trong workspace thành PDF đặt cạnh nó:

1. Backend mở HTML trong cùng khung sandbox mà bước kiểm tra dùng và để script chạy xong.
2. Mỗi canvas được thay bằng ảnh của những gì nó vẽ, và script bị gỡ.
3. Bản chụp đó được nạp vào một trang tắt JavaScript rồi in — Chromium chỉ phân trang tài liệu cấp cao nhất.

Quy tắc @page của chính tài liệu thắng khổ giấy được yêu cầu và lề mặc định 16 mm. PDF ở lại workspace; mô hình nhận đường dẫn, số trang và lỗi runtime. print_pdf không tạo artifact: PDF được lưu như mọi tệp trực quan — kiểm tra mọi trang, rồi lưu theo đường dẫn.

Duyệt trực quan artifact

measure_layout, inspect_artifact và print_pdf đi kèm các tool artifact sẵn có mà không cần gắn skill hay đăng ký riêng.

measure_layout dàn trang HTML trong trình duyệt của backend và trả hình học cùng thuộc tính hiển thị của các phần tử khớp selector, cộng các kiểm tra cắt xén và ngắt từ mà bộ kiểm tra chạy. Nó không render ảnh và không lưu gì — đó là cách một bài trình bày có toạ độ trước khi có tệp nào.

inspect_artifact đọc byte của tệp với tư cách người sở hữu lượt, sau khi kiểm tra quyền dùng tool, và trả về:

• ảnh trang Office và PDF thật, điểm ảnh của tệp ảnh, hoặc các đoạn văn bản;
• ảnh chụp HTML ở hai kích thước — chiều rộng desktop và chiều rộng điện thoại;
• với định dạng nhị phân không biết, siêu dữ liệu và ghi chú rõ rằng việc kiểm tra trực quan bị hạn chế.

Kích thước ảnh

• Trang cao hơn một lần chụp đọc được sẽ trả về nhiều khung đánh số thay vì một ảnh dài; quá bốn khung, một chiều rộng dừng lại và báo còn lại bao nhiêu. Ảnh có cạnh dài quá khoảng 1.600 điểm ảnh bị thu nhỏ trước khi mô hình xem, làm chữ thân bài chỉ còn vài điểm ảnh — vì vậy trang dài được chia nhỏ.
• Trang PDF hoặc Office được render cho trình xem ở chiều rộng 2.000 điểm ảnh (trang A4 khi đó cao gần 2.800), và bản cho mô hình nằm gọn trong 2.000 ở cạnh dài nhất.
• Khi một yêu cầu mang hơn 20 ảnh, nhà cung cấp từ chối mọi ảnh lớn hơn và từ chối cả lần gọi. Cách các ảnh cũ được giải phóng mô tả ở Vòng lặp agent.

Quy tắc duyệt

• Artifact FILE và WEB_PREVIEW là tệp workspace không có nội dung riêng, nên mỗi lần tạo, viết lại hay vá HTML đều cần kiểm tra đúng đường dẫn và checksum, mọi trang trả về, và một quyết định sau đó của mô hình.
• Tệp mới hoặc HTML đã đổi cần kiểm tra lại. Lỗi bố cục hoặc runtime được báo sẽ chặn việc lưu.
• Ảnh vẫn là ảnh qua bước xử lý kết quả để mô hình duyệt; văn bản bên cạnh được rút gọn như mọi kết quả. Sau đó portal chỉ giữ kích thước của mỗi ảnh thay cho điểm ảnh.
• Trang của byte không đổi được tính qua các lượt: lượt lưu một PDF 37 trang mà lượt trước đã kiểm tra chỉ cần kiểm tra các trang còn thiếu. Lỗi không được chuyển tiếp — mỗi lần kiểm tra đều kiểm tra lại byte.
• Một lần kiểm tra render tối đa 10 trang. Lần lưu đòi mọi trang của byte sắp lưu, và dựng lại tạo byte mới — nên bộ chín slide sửa một dòng phải kiểm tra lại toàn bộ (ba trang mỗi lần gọi nghĩa là ba vòng mô hình so với một giây render).

Điều này chứng minh bằng chứng render đã đến mô hình trước khi nó quyết định lưu — không chứng minh mọi đánh giá trực quan đều đúng. Dịch vụ render được mô tả ở Triển khai.

Trình nạp skill

Prompt mang một câu cho mỗi skill được gắn; trình nạp nhận một tên và trả về nội dung skill. Cả hai đều nói phải quyết định về skill trước khi trả lời, và nạp skill là đọc chỉ dẫn — nên skill chi phối mọi câu trả lời được nạp cả khi chỉ là lời chào.

• Backend tự suy ra lại các tên được chấp nhận từ lượt. Tên ngoài danh sách — của agent khác, tổ chức khác, hay không tồn tại — bị từ chối như thể không có, và lời từ chối là lỗi chứ không phải câu trả lời rỗng.
• Nạp skill không cấp tool nào.
• Mỗi lần nạp, bị từ chối hay không, đều để lại một bước trace nêu tên skill.
• Tệp riêng của skill có thể được gắn vào lần chạy code — xem Workspace và code.

Skill nào agent gắn được chọn khi tạo agent.

Câu hỏi làm rõ

Gọi tool câu hỏi làm rõ sẽ tạo một ngắt: vòng lặp dừng và lượt ghi lại một lần tạm dừng. Lần gọi sau trả lời ngắt đó, và tool trả về các câu trả lời. Cách lưu và tiếp tục sau tạm dừng nằm ở Thực thi agent.

Quy tắc	Chi tiết
Trước khi hỏi	Xem cuộc trò chuyện, bộ nhớ và các tool đang có; nêu giả định khi điểm mơ hồ không làm đổi câu trả lời
Câu trả lời	Đưa ra các lựa chọn; câu hỏi mở là phương án dự phòng khi không liệt kê được
Dòng dẫn	Nói câu trả lời dẫn tới đâu; bỏ khi nó đúng với mọi lựa chọn hoặc lựa chọn đã tự nói rõ
Đề xuất	Tối đa một, kèm căn cứ — schema từ chối hai
Trả lời tự gõ	Có sẵn trừ khi các lựa chọn đã bao quát hết
Từ chối trả lời	Luôn có
Mã câu hỏi	Do runtime gán

Những gì bạn thấy được mô tả ở Phê duyệt và câu hỏi.

Danh sách việc

Danh sách việc không phải tệp. Agent gọi update_tasks với cả danh sách mỗi lần.

• Tối đa 20 việc, mỗi việc có tiêu đề và trạng thái: pending, in progress hoặc completed. Tối đa một việc in progress.
• Danh sách rỗng sẽ xoá nó — cách agent bỏ việc bạn không còn cần.
• Tool chạy trong runtime và không gọi route nào của portal. Nó giữ danh sách trong phần còn lại của lượt.
• Nó trả về số việc đã xong, bước cần đánh dấu tiếp, và các việc đổi trạng thái kể từ lần gọi trước — chính là nội dung dòng trace hiển thị.
• Bản ghi giữ mọi lần gọi; lần gọi thành công gần nhất là danh sách hiển thị phía trên ô nhập tin nhắn.
• Agent gửi cập nhật trong cùng tin nhắn với lần gọi bắt đầu hoặc hoàn thành một việc, vì mỗi tin nhắn tốn một lần gọi mô hình.

Lập kế hoạch cho việc lớn

Mức lập kế hoạch tuỳ yêu cầu: câu hỏi trả lời bằng một hai lần tra cứu thì không cần; việc rõ ràng ba đến năm bước có danh sách việc; việc lớn hoặc mơ hồ có bản đặc tả, rồi kế hoạch, rồi danh sách việc.

Danh sách chưa xong

• Trước khi lượt kết thúc. Nếu lượt đã gọi update_tasks và còn việc chưa completed, runtime cho mô hình thêm một lần gọi để cập nhật danh sách và nói còn lại gì. Việc này xảy ra một lần mỗi lượt, sau khi mọi tin nhắn bạn viết trong lần gọi cuối đã được trả lời. Lượt chỉ thừa hưởng danh sách thì không động đến nó, và nếu dừng vì ngân sách trong lần gọi thêm đó, lượt vẫn được ghi là đã trả lời.
• Khi lượt tiếp theo mở ra. Nếu danh sách gần nhất còn việc chưa xong, nó được mang trong tin nhắn riêng của lượt, cạnh đồng hồ, để system prompt đã cache giữ nguyên byte. Portal đọc nó từ lần gọi update_tasks thành công mới nhất trong bản ghi; lượt được tiếp tục đọc từ lịch sử nó khôi phục.

Bên dưới

Liên quan