DeepSeek Harness là gì?

DeepSeek Harness được thiết kế để thực hiện một tác vụ cụ thể, chứ không chỉ đơn thuần là trả lời câu hỏi. Đây là một agent runtime mã nguồn mở, giúp kết nối mô hình với kho lưu trữ, terminal, các công cụ và lịch sử phiên làm việc của bạn. Khi được yêu cầu sửa lỗi, nó có thể tự động kiểm tra file, chỉnh sửa code, chạy các bài kiểm tra và phản hồi khi một lệnh thực thi thất bại - những việc mà một lần gọi mô hình đơn lẻ không thể tự mình thực hiện được.

Điểm đặc biệt nằm ở cơ chế vận hành bên dưới quy trình đó. DeepSeek Harness cung cấp các thành phần như model adapter, công cụ, phiên làm việc, môi trường sandbox và cả agent loop dưới dạng các plugin được điều phối bởi Cordis. Mô hình chỉ là một phần cấu thành nên agent, chứ không phải là toàn bộ sản phẩm.

Đây chưa phải là phần mềm hoàn thiện. Harness hiện vẫn đang trong giai đoạn thử nghiệm dành cho nhà phát triển (developer preview); các API có thể thay đổi giữa những bản phát hành, và thông báo an toàn của hệ thống cũng nêu rõ rằng nó chưa trải qua quy trình kiểm định bảo mật. Bài viết sẽ đề cập đến những hạn chế này, cũng như kiến ​​trúc hệ thống và những điểm khác biệt so với Claude Code, Codex và OpenCode.

DeepSeek Harness là gì?

DeepSeek Harness (viết tắt là dsh) là một agent harness mã nguồn mở từ DeepSeek AI phát triển theo giấy phép MIT. Nó đóng vai trò trung gian giữa mô hình ngôn ngữ và thế giới bên ngoài, cung cấp các công cụ, phiên làm việc, môi trường sandbox và cơ chế vòng lặp để duy trì tiến độ thực hiện tác vụ.

Cách định nghĩa của DeepSeek là: "Agent = Model + Harness". Mô hình đảm nhận việc suy luận và tạo nội dung, trong khi harness bao gồm mọi thành phần cho phép quá trình suy luận đó tác động lên hệ thống file thực tế và tiếp tục hoạt động mà không cần người dùng phải giải thích lại tác vụ ở mỗi bước.

Hệ thống này vận hành trên Cordis – một plugin framework đã có từ trước DeepSeek Harness. Cordis cho phép thay thế độc lập các thành phần này. 

Dựa trên cách định nghĩa này, dưới đây là hai quan niệm sai lầm phổ biến.

DeepSeek Harness không phải là một mô hình AI

Như đã đề cập, mô hình và môi trường runtime (runtime) là các lớp tách biệt. Sự phân tách này cho phép bạn thay đổi nhà cung cấp dịch vụ mà không cần thay đổi công cụ hay cấu hình phiên làm việc. Cùng một môi trường runtime có thể sử dụng dịch vụ của DeepSeek, Anthropic, OpenAI hoặc bất kỳ endpoint nào tương thích với OpenAI.

DeepSeek Harness không chỉ đơn thuần là trợ lý lập trình

Chế độ tiêu chuẩn (Standard) dễ tạo ra ấn tượng rằng đây là một trợ lý lập trình, nhưng đó chỉ là một trong số các cấu hình có thể có. Các chế độ Minimal (Tối giản) và Creator (Sáng tạo) sẽ thay đổi những gì agent có thể sử dụng. Việc xây dựng một cấu hình mới vẫn đòi hỏi công sức lập trình; các nhà phát triển có quyền truy cập trực tiếp vào những thành phần hệ thống.

Cách Cordis tổ chức các DeepSeek Harness plugin

Như đã nói, Cordis là plugin framework nằm bên dưới DeepSeek Harness. Nó cho phép mỗi thành phần yêu cầu một dịch vụ mà không bị ràng buộc vào code của một nhà cung cấp cụ thể nào.

Cordis bắt nguồn từ hệ sinh thái chatbot Koishi và được phát triển bởi lập trình viên có biệt danh Shigma; DeepSeek đã tiếp nhận và mở rộng nó. Các tác giả mô tả thiết kế này trong bài báo khoa học có tiêu đề "A Programming Paradigm for Spatiotemporal Composability" (Một mô hình lập trình cho khả năng kết hợp theo không gian và thời gian).

Những nền tảng cơ bản đó dẫn đến slogan chính của dự án cùng hai thuật ngữ đặc trưng của Cordis. Tên gọi nghe có vẻ mang tính học thuật, nhưng cơ chế hoạt động thực tế lại khá đơn giản.

"Mọi thứ đều là plugin"

Tài liệu kiến ​​trúc của DeepSeek nêu rõ rằng bạn có thể mở rộng dsh bằng cách gắn thêm một plugin mới bên cạnh các plugin hiện có. Các model adapter, công cụ, phiên làm việc, môi trường sandbox, hệ thống lưu trữ, cơ chế lập lịch, agent loop và giao diện người dùng (UI) đều là những plugin.

Nếu hiểu theo nghĩa đen hoàn toàn thì slogan này có phần hơi quá lời, bởi Cordis vẫn đóng vai trò nền tảng nằm bên dưới các plugin đó. Hệ thống thực hiện nạp và gỡ bỏ các plugin, kiểm tra những yêu cầu của chúng, đồng thời vận hành các sự kiện mà chúng sử dụng để giao tiếp với nhau. Cordis là thành phần bắt buộc, không phải là một phần tùy chọn.

Khả năng kết hợp theo không gian quản lý các plugin dependency

Một plugin sẽ khai báo các service mà nó cần mà không yêu cầu người dùng phải tự tay thiết lập trình tự khởi động. Nó sẽ kích hoạt khi các service đó hiện diện và ngừng hoạt động nếu một service bắt buộc bị mất đi. Các plugin dependency sẽ quyết định thời điểm nó có thể vận hành.

DeepSeek gọi đây là khả năng kết hợp theo không gian. Những dependency cho Cordis biết vị trí phù hợp của một thành phần, nhờ đó các nhà phát triển không cần phải tự tay sắp xếp thứ tự khởi động.

Khả năng kết hợp theo thời gian giúp đảo ngược các tác động của plugin

Cordis cũng theo dõi các đăng ký như trình lắng nghe sự kiện (event listener), các phần prompt và tool schema. Việc gỡ bỏ một plugin sẽ loại bỏ các tác động đó thay vì để lại những trình lắng nghe bị bỏ lại (orphaned listener). Cơ chế này không đảo ngược các hành động bên ngoài như lệnh shell; khả năng đảo ngược chỉ áp dụng cho những tác động mà Cordis trực tiếp theo dõi.

Kiến trúc DeepSeek Harness: Cách thức vận hành của runtime

Phiên bản đang chạy là một cây các plugin được xây dựng từ những thiết lập được nạp theo một trình tự nhất định. Các thiết lập này quyết định những thành phần nào sẽ hoạt động.

Các Cordis service cho phép những plugin tìm thấy nhau

Cordis cung cấp một danh mục dịch vụ dùng chung. Các plugin sử dụng những key cố định như ctx.tools, ctx.llm và ctx.sessions thay vì phải nhập code của một nhà cung cấp cụ thể. Một công cụ khi gọi ctx.llm không cần phải biết model adapter nào đang vận hành phía sau nó.

Các agent preset và runtime profile kiểm soát các lớp khác nhau

Nếu mọi thứ đều có thể thay thế được, thì vẫn cần một cơ chế quyết định những gì sẽ được nạp cho một lần chạy cụ thể; DeepSeek Harness giải quyết vấn đề này ở hai lớp mà đôi khi dễ bị nhầm lẫn với nhau.

Tóm tắt ngắn gọn: Một profile kiểm soát cách chương trình khởi động, trong khi thiết lập sẵn (preset) kiểm soát những gì agent có thể thực hiện. Nếu chỉ sử dụng ứng dụng web, bạn có thể bỏ qua hai phần nhỏ tiếp theo.

Runtime profile

Runtime profile (các template có sẵn bao gồm web, headless, sdk, sdk-minimal và acp) quyết định cách ứng dụng khởi chạy và những nhóm plugin Cordis nào được nạp khi khởi động. Hầu hết người dùng sẽ chỉ tương tác với lớp này thông qua lệnh dsh web hoặc các lệnh tương tự.

Agent preset

Agent preset (Standard, PTC, Minimal hoặc Creator) quyết định những gì một phiên làm việc đang hoạt động có thể sử dụng. Một file bản vá có thể thay đổi thiết lập sẵn mà không cần can thiệp vào nguồn của Harness.

Agent loop điều phối các lượt, bước và lệnh gọi công cụ

DeepSeek phân biệt giữa "bước" và "lượt". Một bước bao gồm một yêu cầu gửi tới mô hình cùng với các lệnh gọi công cụ đi kèm. Một lượt bao gồm không hoặc nhiều bước: Lượt bắt đầu trước khi đầu vào đầu tiên được tiếp nhận và kết thúc khi không còn tác vụ nào cần xử lý. Hầu hết các lượt thực hiện nhiều bước trước khi agent có thể đưa ra câu trả lời, tuy nhiên, một đầu vào bị từ chối sẽ kết thúc lượt ngay cả khi chưa thực hiện bước nào.

Các phiên làm việc sử dụng nhật ký sự kiện chỉ cho phép ghi thêm

Đây là phần quan trọng nhất. Phiên làm việc là một nhật ký chỉ ghi thêm các sự kiện đã được nhập, chứ không phải là một mảng các tin nhắn trò chuyện. Harness xây dựng lịch sử của mô hình từ nhật ký đó, và tài liệu về phiên làm việc yêu cầu bất kỳ thứ gì được gửi đến mô hình đều có thể được khôi phục từ đó.

Các chức năng tiếp tục, phân nhánh, tìm kiếm, phát lại và chế độ xem Trajectory đều được xây dựng trên luồng sự kiện đó.

Việc tạo lại lịch sử không phải là một quá trình chạy lại có tính xác định. Đầu ra của mô hình và trạng thái bên ngoài có thể khác nhau, nhưng nhật ký vẫn cung cấp một bản ghi có thể kiểm tra được về những gì đã xảy ra.

Cách DeepSeek Harness kiểm soát các công cụ và môi trường sandbox

Mô hình có thể yêu cầu sử dụng một công cụ dựa trên tên gọi, nhưng nó không thể tự mình thực thi công cụ đó. Có hai cơ chế kiểm soát riêng biệt nằm giữa yêu cầu của mô hình và việc thay đổi hệ thống file.

Quy trình thực thi công cụ

Lệnh gọi sẽ trải qua các bước: Kiểm tra chính sách, thực thi và xử lý kết quả. Mô hình là bên chọn công cụ, trong khi môi trường runtime mới là bên quyết định liệu công cụ đó có được chạy hay không và chạy như thế nào.

Môi trường sandbox so với cơ chế phê duyệt

• Phê duyệt là bước yêu cầu người dùng xác nhận một hành động.
• Sandbox giới hạn phạm vi và cách thức thực thi hành động đó.

DeepSeek tách biệt hai cơ chế này, mặc dù các thiết lập quyền preset thường gộp chung cả hai biện pháp kiểm soát - tương tự như cách môi trường runtime container tách biệt quyền của tiến trình khỏi các ranh giới thực thi.

Việc yêu cầu mô hình "chỉ đọc file" trong prompt hệ thống chỉ là một chỉ dẫn mà mô hình có thể tuân theo, chứ không phải là một ranh giới bắt buộc cứng như các hạn chế sandbox ở cấp độ hệ điều hành.

Kết luận

Câu nói đáng nhớ nhất ở phần mở đầu là: Mô hình đưa ra lý luận, nhưng môi trường runtime quyết định lý luận đó có thể đạt được và thực hiện được những gì. DeepSeek Harness cho phép chỉnh sửa môi trường runtime, từ model adapter và các công cụ đến kho lưu trữ phiên và agent loop.

Sự kiểm soát đó tạo ra chi phí. Việc thay thế nhiều hơn môi trường runtime đồng nghĩa với việc phải chịu trách nhiệm nhiều hơn về thiết lập, thay đổi phiên bản và ranh giới bảo mật của nó. Bản xem trước dành cho nhà phát triển với quyền truy cập shell không phải là thứ có thể cài đặt rồi quên đi.

Mọi thứ rất đơn giản: Hãy sử dụng DeepSeek Harness khi chính môi trường runtime là một phần của công việc. Nếu bạn chỉ cần chỉnh sửa kho lưu trữ, một agent lập trình sẵn có sẽ yêu cầu ít thao tác hơn.