99% người dùng đang dùng /goal và vòng lặp sai cách.
Lời quảng cáo họ nghe thấy là "vòng lặp dài cho phép tác nhân tự động": đưa ra một nhiệm vụ, bỏ đi, quay lại khi có code chạy được.
Nhưng các kỹ sư tác nhân hàng đầu đã làm điều đó mà không cần /goal trong suốt 6 tháng (khi GPT-5.2 và Opus 4.5 ra mắt). Nó được gọi là kỹ thuật khung (harness engineering) + phát triển theo đặc tả (spec-driven development):
- Xây dựng một khung để tác nhân quan sát vấn đề
- Viết một đặc tả chặt chẽ với tất cả các trường hợp kiểm thử
- Để Codex hoặc Claude Code chạy vòng lặp không cần giám sát cho đến khi đáp ứng tất cả
Tôi liên tục khởi chạy những vòng lặp này qua đêm — mỗi lần chạy 2-5 tiếng. Vào tháng Tư, một vòng lặp đã giải quyết một lỗi bộ nhớ đệm bản dựng Turbo trong monorepo Vercel của chúng tôi và đã xanh vào buổi sáng. Không cần /goal thực sự.
Vậy /goal thực sự dùng để làm gì?
Đây là những gì một prompt duy nhất đã làm khi tôi đi vắng:
- ~30 tiếng, 6,300 dòng code, 92k trang được thu thập, $40 chi cho API
- Sao chép vòng lặp cốt lõi của một sản phẩm khác — toàn bộ kiến trúc được dịch ngược từ đầu
- Đầu ra của phiên bản chúng tôi tốt hơn ~50 lần so với sản phẩm tham chiếu trên cùng các truy vấn. (Đây là một lớp dữ liệu mới sẽ cung cấp năng lượng cho newsjack.sh - các kỹ năng tình báo tin tức mã nguồn mở tôi đang phát triển)
Bí mật nằm ở phát triển hàm mất mát (loss function development - LFD): bạn viết cho tác nhân một mục tiêu để tối ưu hóa, chứ không phải một đặc tả để xây dựng.
Đây là một ví dụ cụ thể về tweet của Peter, được vận hành.
Đặc tả được sử dụng trong phát triển theo đặc tả giờ đây trở thành điểm khởi đầu, không còn là vạch đích.
Tôi đã mất một số thử nghiệm để làm đúng điều này. Nhưng đây là toàn bộ sách lược — nhưng chúng ta cần bắt đầu với việc nó đã sai lầm như thế nào trước để bạn hiểu cách thiết kế những /goal này.
Tác nhân đã gian lận 3 lần.
Mọi thứ bắt đầu với những gì tôi luôn làm: một đặc tả.
Tôi chỉ đơn giản hướng Codex đến trang web công khai của sản phẩm kia - "chúng ta có thể tự xây dựng thứ này như thế nào?". Trong 30 phút, nó đã đưa ra một thiết kế hệ thống hoàn chỉnh và các trường hợp kiểm thử - bản đặc tả.
Nhưng lần này, tôi đã thử một prompt khác.
"/goal thực hiện cho đến khi đầu ra của bạn khớp chính xác với của họ"
Và đây là những gì đã xảy ra:
Vòng lặp 1 (5 phút)
Tác nhân lấy tập đánh giá, tạo dữ liệu giống hệt nó, và tuyên bố chiến thắng trong năm phút.
"100%" recall, zero generality — một công cụ tìm kiếm chỉ có thể tìm thấy 30 thứ tôi đã đưa cho nó lol.
Khắc phục → làm nó mù. Giấu bộ đánh giá trong suốt quá trình chạy, chỉ tiết lộ khi chấm điểm, kèm danh sách các mục bỏ sót.
Vòng lặp 2 (20 phút) - mù, 30 mục.
Tôi làm tác nhân mù với tập đánh giá, nhưng nó học bằng cách bỏ sót — mỗi "bạn không tìm thấy X" trở thành một từ khóa cho chu kỳ tiếp theo. Sau vài vòng lặp: nó sử dụng chính xác 30 từ khóa, một từ cho mỗi mục, và nó lại "thắng".
Khắc phục → mở rộng tập đánh giá. Hàng trăm mục để chấm điểm, quá nhiều để liệt kê hết.
Vòng lặp 3 (30 phút) - mù, 200 mục.
Sau khi thêm 200 mục vào tập đánh giá mới, tác nhân lại gian lận.
Buồn cười là, dù sao thì tác nhân cũng liệt kê. Danh sách từ khóa phình lên hàng trăm, mỗi thuật ngữ là một cái bẫy chính xác cho lần bỏ sót tiếp theo.
Ba vòng, ba lần gian lận.
Đó là lúc tôi hiểu ra: tác nhân chỉ đơn giản là đang tối ưu hóa.
Sự gian lận không phải lỗi của tác nhân. Đó là lỗi trong mục tiêu của tôi: tôi bảo nó đi đâu và để ngỏ mọi lối tắt.
Mọi con đường rẻ tiền bạn không rào lại là một hướng mà bộ tối ưu hóa sẽ lao tới. Và mục tiêu ban đầu của tôi đã bỏ qua tất cả các hàng rào.
Vòng lặp 4 (30 tiếng) - mù, 200 mục, giới hạn cứng.
Vì vậy, tôi bắt đầu chặn các hướng. Giới hạn danh sách từ khóa, làm mù bộ đánh giá, mở rộng phạm vi ngày — mỗi lần sửa chữa lại đóng thêm một con đường rẻ tiền, cho đến khi hướng đi duy nhất còn lại có thể cải thiện con số là thực sự làm tốt hơn nhiệm vụ.
Nó ngừng gian lận.
Sau đó nó chạy. ~30 giờ tính toán, 92 nghìn trang được thu thập, ~$40 token, 6,300 dòng code.
Hóa ra sản phẩm chúng tôi tham chiếu là sàn, không phải trần: cuối cùng chúng tôi đã đưa ra được ~50 lần kết quả trên cùng các truy vấn.
(Toàn bộ hành trình và hóa đơn ở đây cho những ai tò mò)
Phát triển hàm mất mát (LFD) - giải phẫu một hàm mất mát tốt
Khi hầu hết mọi người cố gắng xây dựng một sản phẩm, họ sử dụng các tác nhân để đi từ con số 0 đến khi phát hành trong vài giờ.
Nhưng vấn đề nằm ở những gì xảy ra sau đó — phần đuôi dài. Các trường hợp ngoại lệ mà đặc tả không bao giờ tưởng tượng đến chỉ xuất hiện trong sản xuất, từng lỗi log một. Bạn sửa chúng từng cái một. Các trường hợp bạn không phát hiện trong log sẽ được người dùng báo cáo, đây là cách đắt đỏ nhất để tìm ra lỗi.
Tôi đã tự động hóa phần rẻ của việc này. Tác nhân OpenClaw của tôi, Zoe, xem xét error log hàng ngày và sinh ra Codex cho các lỗi mới khi chúng xuất hiện và tạo PR — chặt chẽ nhất có thể cho vòng lặp đó. (Thiết lập đầy đủ được ghi lại tại đây
Phần đuôi vẫn mất hàng tháng. Đó là lý do tại sao xây dựng một sản phẩm tốt vẫn mất thời gian ngay cả khi các tác nhân làm việc.
LFD tăng tốc phần đuôi. Nếu bạn có thể có được các ví dụ đầu ra thực tế mong đợi ngay từ đầu — hình ảnh của kết quả tốt, ở quy mô lớn — bạn chạy bài kiểm tra thấm trước khi phát hành: hàng trăm trường hợp ngoại lệ được đưa vào tác nhân trong một lần chạy tối ưu hóa, thay vì một giọt nhỏ giọt báo cáo lỗi hàng quý. Và lý do điều này đột nhiên khả thi là vì ngày càng có nhiều vấn đề, những ví dụ đó chỉ đang nằm ở nơi công cộng.
Phát triển theo đặc tả:
Xây dựng cái này. Làm cho các bài kiểm tra vượt qua.
Phát triển hàm mất mát:
Xây dựng cái này. Làm cho các bài kiểm tra vượt qua. Sau đó lặp lại với 1,000 trường hợp đánh giá này.
Một bộ kiểm thử là hữu hạn — kết thúc ngay khi nó xanh. Một bài đánh giá 1,000 trường hợp ở mức 95% là một mục tiêu bạn đi xuống; không có lối thoát nào ngoài việc đạt ngưỡng. Điều đó quan trọng vì tác nhân đưa ra hàng trăm quyết định bạn sẽ không bao giờ thấy, và mỗi quyết định đều được giải quyết dựa trên một thứ gì đó. Nếu bạn không viết mục tiêu, tác nhân sẽ tự chọn một mục tiêu — và như các vòng 1–3 đã chỉ ra, nó chọn bất cứ thứ gì rẻ nhất để thỏa mãn.
Hàm mất mát lớn hơn bài đánh giá. Nó có 4 thứ - mục tiêu, các ràng buộc, các công cụ đo lường, và entropy bắt buộc. Bốn phần.
1. Mục tiêu
- Đủ lớn để việc liệt kê không có lợi. Một bài đánh giá 28 mục đã bị ghi nhớ trong một vòng. Càng nhiều càng tốt.
- Làm mù tác nhân khỏi đáp án. Dữ liệu đánh giá chỉ tồn tại để chấm điểm sau khi chạy. Nếu tác nhân có thể thấy câu trả lời trong quá trình chạy, nó sẽ tìm cách nhìn.
2. Các Ràng buộc
Những gì tác nhân được phép làm, và những gì không.
- Thời gian là ràng buộc mà tác nhân luôn quên. Các tác nhân không có cảm giác về thời gian. Chúng sẽ cày 10 tiếng để đạt được 2% cải thiện vì chỉ số đang di chuyển trên danh nghĩa. Nhưng một giải pháp 80% trong 2 giờ tốt hơn một giải pháp 100% hoàn thành trong 30 ngày. Giải pháp: đặt ngân sách thời gian thực tế.
- Tiền bạc. Giới hạn cứng cho mọi cuộc gọi trả phí: tín dụng crawler, chi tiêu LLM, tổng giới hạn đô la trên một key dùng một lần.
- Bề mặt. Tất cả nhà cung cấp, mô hình được phép, giới hạn đồng thời. Sandbox tác nhân chỉ với những thứ bạn muốn nó chạm vào.
- Phương pháp luận. Phân tích LLM có được phép hay chỉ logic xác định? Tác nhân được truy cập vào những nguồn dữ liệu nào? Viết rõ ra.
3. Công cụ đo lường (khung harness)
Một ràng buộc mà không có công cụ đo lường chỉ là một cảm giác — tác nhân sẽ vui vẻ vi phạm nó vì nó không thể biết là mình đang vi phạm. Đối với mỗi ràng buộc ở trên, cung cấp một lệnh CLI để tác nhân kiểm tra nó.
- Đo lường mục tiêu, ở độ phân giải phù hợp. Chọn công cụ đo lường mục tiêu một cách cẩn thận. Ví dụ thực tế: một "thẩm phán LLM đánh giá hai ảnh chụp màn hình" ngây thơ sẽ chấp nhận các bản sao UI có lỗi spacing 12px, vì LLM thực sự không thể nhìn thấy hình ảnh, nó chuyển đổi chúng thành embedding rồi so sánh embedding. Vì vậy, nếu bạn muốn các bản sao UI pixel-perfect, hãy cung cấp cho tác nhân một công cụ so sánh pixel. Sau đó /goal cho đến khi độ lệch pixel là 0.
- Tính toán thời gian. Đánh dấu thời gian cho mỗi lần chạy và mỗi bước. Tác nhân nên biết mỗi bước mất bao lâu, tổng thời gian thực tế đã trôi qua. Thời gian là một công cụ đo lường hạng nhất, không phải một chú thích.
- Ngân sách nhà cung cấp. "Chúng ta đang đốt bao nhiêu cho crawler ngay bây giờ?" phải là một lệnh, không phải một phỏng đoán. Theo dõi số dư scrape còn lại, mức tiêu hao trong vòng lặp này, tổng mức tiêu hao lũy kế, và mức tiêu hao dự kiến trước khi batch trả phí tiếp theo.
- Chi tiêu LLM. Cung cấp cho nó một khóa API LLM để sử dụng trong data-plane có thể đơn giản hóa rất nhiều logic. Nhưng tác nhân nên chi tiêu chúng một cách có trách nhiệm, bằng cách trước tiên biết nó thực sự đang chi bao nhiêu.
- Sử dụng Codex. Cái này hơi siêu hình một chút. Vòng lặp nên tự nhận thức: tôi đang chi bao nhiêu token cho việc tối ưu hóa này? Hữu ích để biết gradient của bước tối ưu hóa hiện tại.
Mô hình vẫn là câu nói cũ: bạn không thể tối ưu hóa thứ bạn không thể thấy.
Nếu bạn mới chạy các vòng lặp này, đừng khởi chạy nó và bỏ đi. Hãy ngồi với chu kỳ đầu tiên. Quan sát những gì nó chạm vào. Xác nhận khung bạn xây dựng đang được sử dụng đúng cách. Sau đó đi ngủ. (Và cố gắng ngủ mà không nghĩ về những gì bạn sẽ thấy khi thức dậy)
4. Entropy bắt buộc
Tại sao entropy bắt buộc lại quan trọng: mỗi vòng lặp tiếp tục từ toàn bộ ngữ cảnh của lần chạy trước. Mô hình không bắt đầu lại từ đầu — nó đang đọc hàng trăm quyết định cuối cùng của chính nó và gradient đã hoạt động tốt cho đến nay.
Trong một vòng lặp /goal, việc đạt cực đại cục bộ là trạng thái mặc định. Nếu không có cú hích rõ ràng, tác nhân tiếp tục đi lên cùng một ngọn đồi, và "cùng một ngọn đồi" là bất cứ nơi nào nó tình cờ ở khi ngừng cải thiện.
Ví dụ, nếu một núm vặn nhỏ cải thiện kết quả thêm 0.1%, tác nhân sẽ tiếp tục vặn núm đó ngay cả khi nó có 1000 núm vặn khác để thử.
Entropy cần được đưa vào quá trình chạy một cách rõ ràng, vì mô hình sẽ không tự mình thực hiện:
- Suy ngẫm về overfit mỗi chu kỳ. Tôi đang xây dựng một giải pháp tổng quát hơn, hay đang ghi nhớ bài đánh giá? Nếu đang ghi nhớ, thay đổi tiếp theo phải loại bỏ một hiện vật hình dạng bài đánh giá (giới hạn danh sách, làm mù một tính năng, mở rộng bài đánh giá, từ chối một hạt giống), chứ không phải thêm một cái.
- Ép buộc entropy khi đình trệ. Nếu chu kỳ cuối cùng không di chuyển chỉ số, chu kỳ tiếp theo không thể là "cùng ý tưởng, cố gắng hơn". Mô hình phải thực hiện một bước nhảy thực sự không hiển nhiên — "nghĩ ngoài khuôn khổ" là một prompt tốt - ngăn tác nhân chỉ vặn cùng một núm mạnh hơn.
- Giữ một nhật ký lặp lại. Bắt tác nhân ghi lại giả thuyết, chế độ thất bại dự kiến, chẩn đoán cho mỗi bước, để nó có thể nhìn lại và suy ngẫm qua các lần nén.
Meta-Meta-Prompt
Tôi đã tự viết những goal này nhưng nhanh chóng nhận ra đó là công việc dành cho các tác nhân.
Vì vậy, tôi đã viết một kỹ năng tạo ra các loại goal này cho một quá trình phát triển hàm mất mát tốt.
Hiện đã được mã nguồn mở tại đây:
https://github.com/elvisun/loss-function-development
/lfd-design để tạo khung và goal
Gradient descent đến cùng: hai vòng lặp
Nhìn lại, đó là gradient descent đến cùng.
Vòng lặp bên trong là tác nhân: viết code, chạy kiểm tra, sửa lỗi. Chân trời ngắn, phản hồi nhanh, một mục tiêu duy nhất — làm cho các bài kiểm tra vượt qua. Đó là vòng lặp bên trong của một nhà phát triển, và phát triển theo đặc tả là cách bạn chạy nó. Các tác nhân viết code đã tự động hóa nó.
Vòng lặp bên ngoài là /goal: đưa toàn bộ hệ thống hướng tới một chỉ số kết quả qua nhiều chu kỳ — phát hành, đo lường, đổi hướng, đi xuống. Chân trời dài, phản hồi thưa thớt. Theo truyền thống, đó là vòng lặp của một nhóm sản phẩm, quá trình thấm dần của phát hành-đo lường-lặp lại trong nhiều tháng được nén thành một lần chạy duy nhất.
Cả hai vòng lặp đều đã được tự động hóa. Những gì còn lại ở bạn là xác định hàm mất mát — chính xác /goal nên tối ưu hóa cái gì và theo cách nào.
Bạn đang chưng cất một sản phẩm — hoặc bất cứ thứ gì để lại một hiện vật công khai
Một góc nhìn khác: về cơ bản, đây là sự chưng cất, được chuyển từ thời gian huấn luyện sang thời gian prompt. Đây là cách dòng DeepSeek, Kimi, Minimax thu hẹp khoảng cách với GPT và Claude — huấn luyện mô hình của bạn trên đầu ra của người khác cho đến khi mô hình của bạn tái tạo được chúng.
Nhưng thay vì chưng cất một mô hình, giờ đây bạn có thể sử dụng /goal và LFD để chạy việc chưng cất phù hợp với bất kỳ hiện vật nào có thể tìm thấy công khai — nó không bao giờ kiểm tra nội bộ và không cần phải làm vậy.
Hãy nhấn mạnh vào từ công khai. Chưng cất đầu ra bị rào bởi Điều khoản Dịch vụ (ToS), yêu cầu đăng nhập, hoặc trả phí của ai đó là không công bằng. Nhưng những gì được công bố công khai — những đầu ra mà một công ty phát hành để giành khách hàng — luôn công bằng để học hỏi. Phần đó không mới - nó là chiêu trò lâu đời nhất trong ngành phần mềm. Điều mới là giờ đây nó rẻ và có thể được thực hiện trong vài giờ thay vì nhiều tháng.
Nhìn lại, đây là sự thay đổi lớn hơn. Chi phí thực thi giảm xuống còn ~$0 bất cứ nơi nào có sự đối xứng thông tin — khi đầu ra là công khai, mọi người đều có thể thấy kết quả tốt trông như thế nào, vì vậy bất kỳ ai cũng có thể chưng cất nó trở lại trong một ngày cuối tuần với $40.
Vì vậy, đây là một hào mới đang ngày càng trở nên giá trị hơn: sự bất đối xứng thông tin.
Công ty mã nguồn mở kinh điển đã chớp mắt. Vào tháng Tư năm 2026, cal.com ($5M ARR) đã đưa code sản xuất của mình thành mã nguồn đóng và đóng cửa mã nguồn mở. Lý do họ đưa ra đọc giống như bản tóm tắt của bài luận này: trong thời đại các mối đe dọa bảo mật do AI điều khiển, bạn không thể để mã nguồn của mình ở nơi mà tác nhân có thể đọc được.
"/goal đọc mã nguồn cal.com và liệt kê bề mặt tấn công của nó cho đến khi có thứ gì đó hoạt động"
Đó là một cuộc tấn công quá nguy hiểm và quá dễ thực hiện.
Công ty mà toàn bộ bản sắc là "mã nguồn mở" đã quyết định, vào năm 2026, rằng sự cởi mở đã trở thành một gánh nặng. Điều đó sẽ nói lên tất cả.
Trong toàn bộ lịch sử phần mềm, "chúng tôi đã xây dựng nó" là hào phòng thủ.
Kỷ nguyên đó đang khép lại.
Kỷ nguyên tiếp theo thuộc về người sở hữu những gì hiện vật không bao giờ chứa đựng: bộ đánh giá mà không tác nhân nào khác có thể chấm điểm. Danh sách các trường hợp ngoại lệ mà người dùng của bạn thực sự vấp phải. Sự thật cơ bản bạn đo lường riêng tư. Người có mục tiêu mà tác nhân của đối thủ không thể thấy là người duy nhất có vòng lặp tiếp tục đi xuống.
Sản phẩm bây giờ là một ngày cuối tuần.
Hãy đi xây dựng bộ đánh giá mà một ngày cuối tuần không thể chạm tới.
