Tóm tắt các điểm chính
- DeepSeek Harness (viết tắt dsh) là một agent harness mã nguồn mở từ DeepSeek AI theo giấy phép MIT, đứng giữa một mô hình ngôn ngữ và thế giới bên ngoài.
- Cordis, framework plugin nền tảng bên dưới, cho phép thay thế độc lập model adapter, tool, session store, sandbox và vòng lặp agent.
- Session được lưu dưới dạng một log sự kiện chỉ thêm (append-only), hỗ trợ resume, fork, tìm kiếm, replay và view Trajectory.
- Bốn chế độ Standard, PTC, Minimal và Creator thay đổi tool nào agent có thể dùng và cách agent tiếp cận chúng.
- Khác biệt chính so với Claude Code, Codex và OpenCode: DeepSeek Harness cho phép thay thế các thành phần runtime cấp thấp mà ba công cụ kia giữ cố định.
- Giới hạn chính: vẫn ở giai đoạn developer preview, chưa qua kiểm toán bảo mật, và API có thể thay đổi giữa các bản phát hành.
DeepSeek Harness là gì?
DeepSeek Harness, viết tắt dsh, là một agent harness mã nguồn mở từ DeepSeek AI theo giấy phép MIT. Nó đứng giữa một mô hình ngôn ngữ và thế giới bên ngoài, cung cấp tool, session, sandbox và vòng lặp giữ cho một tác vụ tiếp tục vận hành.
Cách DeepSeek tự mô tả là “Agent = Model + Harness”. Mô hình xử lý reasoning và tạo sinh. Harness là tất cả những gì cho phép quá trình reasoning đó hành động trên một filesystem thực tế và tiếp tục mà không cần giải thích lại tác vụ mỗi lượt.
Harness chạy trên Cordis, một framework plugin có trước cả DeepSeek Harness, cho phép các cấu hình thay thế các thành phần này độc lập với nhau.
Hai hiểu lầm phổ biến cần làm rõ:
- DeepSeek Harness không phải một mô hình AI. Mô hình và runtime là hai lớp tách biệt, cho phép đổi nhà cung cấp mà không cần đổi cấu hình tool hay session. Cùng một runtime có thể dùng DeepSeek, Anthropic, OpenAI, hoặc bất kỳ endpoint tương thích OpenAI nào.
- DeepSeek Harness không chỉ là một trợ lý coding. Chế độ Standard tạo cảm giác đó, nhưng đây chỉ là một cấu hình. Chế độ Minimal và Creator thay đổi những gì agent có thể dùng, dù xây một cấu hình mới vẫn đòi hỏi công sức kỹ thuật.
Cordis tổ chức các plugin của DeepSeek Harness như thế nào?
Cordis là framework plugin nằm bên dưới DeepSeek Harness, cho phép mỗi thành phần yêu cầu một dịch vụ mà không gắn chặt vào code của một nhà cung cấp cụ thể. Cordis xuất phát từ hệ sinh thái chatbot Koishi, được xây bởi một nhà phát triển có tên Shigma, DeepSeek phân phối và mở rộng thêm.
“Mọi thứ đều là plugin.”
Tài liệu kiến trúc của DeepSeek cho biết có thể mở rộng dsh bằng cách gắn thêm một plugin cạnh các plugin khác. Model adapter, tool, session, sandbox, storage, lịch trình, vòng lặp agent, và cả UI đều là plugin. Nhưng hiểu theo nghĩa đen thì khẩu hiệu này hơi quá: Cordis vẫn nằm bên dưới các plugin, chịu trách nhiệm load và gỡ chúng, kiểm tra thứ chúng cần, và chạy các sự kiện để chúng giao tiếp với nhau. Cordis là bắt buộc, không phải một mảnh tùy chọn khác.
Spatial composability quản lý phụ thuộc giữa các plugin.
Một plugin khai báo dịch vụ nó cần mà không yêu cầu một chuỗi khởi động viết tay. Nó kích hoạt khi các dịch vụ đó tồn tại và ngừng hoạt động nếu một dịch vụ bắt buộc biến mất. Phụ thuộc quyết định khi nào nó có thể chạy, và DeepSeek gọi đây là spatial composability, giúp nhà phát triển không phải sắp xếp thứ tự khởi động thủ công.
Temporal composability tháo gỡ tác động của plugin.
Cordis theo dõi các đăng ký như event listener, phần prompt và schema tool. Gỡ bỏ một plugin sẽ gỡ bỏ luôn các tác động đó thay vì để lại các listener mồ côi. Điều này không hoàn tác một hành động bên ngoài như một lệnh shell, tính có thể đảo ngược chỉ áp dụng cho các tác động Cordis theo dõi.
Kiến trúc DeepSeek Harness kết nối với nhau ra sao?
Một instance đang chạy là một cây plugin được xây từ các cấu hình load theo một thứ tự nhất định, quyết định thành phần nào đang hoạt động.
Dịch vụ Cordis giúp các plugin tìm thấy nhau.
Cordis cung cấp một danh bạ dịch vụ dùng chung. Các plugin dùng key ổn định như ctx.tools, ctx.llm và ctx.sessions thay vì import code của một nhà cung cấp cụ thể. Một tool gọi ctx.llm không cần biết model adapter nào đứng phía sau.
Preset agent và profile runtime kiểm soát hai lớp khác nhau.
Nếu mọi thứ đều có thể thay thế, vẫn cần thứ gì đó quyết định cái gì được gắn vào cho một lượt chạy cụ thể, và DeepSeek Harness trả lời điều đó ở hai lớp dễ nhầm lẫn:
- Runtime profile (web, headless, sdk, sdk-minimal, và acp là các mẫu có sẵn) quyết định cách ứng dụng khởi động và các gói plugin Cordis nào được chồng lên lúc boot. Phần lớn người dùng chỉ chạm đến lớp này khi chạy lệnh dsh web hoặc tương tự.
- Agent preset (Standard, PTC, Minimal, hoặc Creator) quyết định một phiên đang hoạt động có thể dùng gì. Một file patch có thể đổi preset mà không cần đụng vào mã nguồn của Harness.
Vòng lặp agent điều phối lượt, bước và tool call.
DeepSeek phân biệt một bước (step) với một lượt (turn). Một bước là một request mô hình cộng các tool call của nó. Một lượt gồm không hoặc nhiều bước: mở ra trước khi input đầu tiên được nhận, và đóng lại khi không còn gì cần thực hiện. Phần lớn các lượt chạy nhiều bước trước khi agent có thể trả lời, nhưng một input bị từ chối sẽ đóng một lượt không tốn bước nào.
Session dùng một log sự kiện chỉ thêm.
Đây là phần đáng chú ý nhất. Một session là một log sự kiện có kiểu, chỉ thêm, không phải một mảng tin nhắn chat. Harness xây lịch sử mô hình từ chính log đó, và tài liệu session yêu cầu bất cứ thứ gì gửi cho mô hình phải khôi phục được từ đó. Resume, fork, tìm kiếm, replay và view Trajectory đều xây trên luồng sự kiện này. Tái tạo lại lịch sử không phải một lượt chạy lại tất định, output mô hình và trạng thái bên ngoài có thể khác đi, nhưng log vẫn cung cấp một bản ghi có thể kiểm tra được về những gì đã xảy ra.
DeepSeek Harness kiểm soát tool và sandbox qua hai lớp riêng biệt.
Một mô hình có thể yêu cầu một tool theo tên, nhưng không được chạy nó trực tiếp:
- Pipeline thực thi tool: lệnh gọi đi qua kiểm tra chính sách, thực thi, rồi xử lý kết quả. Mô hình chọn tool, còn runtime quyết định có chạy hay không và chạy như thế nào.
- Sandbox so với phê duyệt: phê duyệt hỏi liệu người dùng có nên xác nhận một hành động hay không, còn sandbox giới hạn nơi và cách hành động đó thực thi. DeepSeek giữ hai cái này tách biệt, dù các preset quyền hạn gộp cả hai control lại.
Đáng lưu ý: nói với một mô hình trong system prompt “chỉ đọc file” là một gợi ý mô hình có thể tuân theo, không phải một ranh giới bắt buộc theo cách một giới hạn sandbox cấp hệ điều hành làm được.
Bốn chế độ của DeepSeek Harness khác nhau ra sao?
DeepSeek Harness cung cấp bốn chế độ, không chế độ nào xếp trên chế độ nào, đây là bốn câu trả lời cho câu hỏi “nên lộ ra bao nhiêu phần runtime cho phiên này”, và lựa chọn đúng phụ thuộc vào tác vụ cụ thể.
Chế độ Standard
là mức nền tảng đa dụng, gồm: chỉnh sửa file, truy cập shell, tìm kiếm file và web, skill, lập kế hoạch, mục tiêu, subagent, và workflow. Với công việc repository thông thường, đây là điểm khởi đầu hợp lý.
Chế độ PTC
giữ gần như toàn bộ bộ công cụ của Standard nhưng thay đổi cách mô hình tiếp cận chúng. Thay vì yêu cầu từng tool riêng lẻ qua nhiều bước mô hình, mô hình viết một chương trình dựa trên một SDK được tạo sẵn, chương trình đó có thể gọi nhiều tool qua run_code. Mọi lệnh gọi vẫn đi qua cùng kiểm tra chính sách, nên PTC thay đổi cách mô hình trình bày kế hoạch, không thay đổi những gì được phép làm. Trang sản phẩm vẫn dùng nhãn “Code mode”, nhưng bản phát hành chính thức mới hơn đã đổi tên thành PTC mode trong khi vẫn giữ được các bản ghi hội thoại cũ.
Chế độ Minimal
rút gọn môi trường xuống còn hai tool: một shell bền vững và một trình chỉnh sửa file kiểu string-replace. DeepSeek dùng chế độ này cho benchmark mô hình, vì kết quả test phần nào phụ thuộc vào harness của mô hình, không chỉ vào trọng số.
Chế độ Creator
cho phép nhà phát triển kiểm tra runtime và test plugin Cordis trong bộ nhớ, dùng để xây dựng preset, không nên gọi đây là “tự cải thiện” theo nghĩa sâu hơn.
DeepSeek Harness khác biệt gì so với các framework agent khác?
DeepSeek Harness khác nhiều framework agent ở chỗ biến các phần cấp thấp của runtime thành có thể thay thế. Có thể thay đổi cách agent vận hành, không chỉ tool mà nó có thể gọi. Log sự kiện cũng khiến một lượt chạy trở thành thứ nhà phát triển có thể kiểm tra, thay vì chỉ đọc như một transcript chat. Chế độ Minimal và Creator sau đó cho phép kiểm tra runtime từ hai hướng ngược nhau.
DeepSeek Harness so với Claude Code, Codex và OpenCode
Một danh sách tính năng sẽ bỏ lỡ trọng tâm. Mỗi đối thủ đều hỗ trợ mở rộng, câu hỏi hữu ích là phần nào nhà phát triển có thể thay đổi.
So với Claude Code: Claude Code hỗ trợ hướng dẫn dự án, skill, hook, MCP, subagent và Agent SDK, nhưng giữ vòng lặp tích hợp sẵn cố định. DeepSeek Harness cho phép thay thế vòng lặp, model adapter và lớp storage qua cấu hình.
So với Codex: cần so sánh cẩn thận hơn vì CLI và App Server của Codex cũng mã nguồn mở. Codex cung cấp một agent harness mà nhà phát triển mở rộng qua các điểm vào đã tài liệu hóa. DeepSeek Harness được xây quanh việc thay đổi chính runtime. Hai bên cung cấp mức độ kiểm soát khác nhau.
So với OpenCode: OpenCode vốn đã mã nguồn mở, hoạt động với nhiều nhà cung cấp mô hình, dùng kiến trúc client-server. Có thể cấu hình tool, quyền hạn, session và nhà cung cấp. Plugin của OpenCode mở rộng một lõi server cố định, trong khi DeepSeek còn biến cả vòng lặp và session store thành có thể thay thế.
Khi nào nên dùng DeepSeek Harness?
Việc thay thế các thành phần runtime không tự nó hữu ích. Quyền kiểm soát bổ sung chỉ quan trọng khi nó giải quyết một vấn đề đã tồn tại:
- Khi bản thân runtime là một phần của dự án. Nếu đang chỉnh sửa model adapter, vòng lặp agent, storage, hoặc hành vi session, chứ không chỉ xây dựng trên nền một agent có sẵn, đây là lựa chọn phù hợp trực tiếp hơn.
- Khi so sánh mô hình trong một môi trường có kiểm soát. Dùng cùng một runtime giữ nguyên phần lớn bài test khi đổi mô hình, dù các mô hình vẫn có thể khác nhau về cách dùng tool và phong cách reasoning.
- Khi việc debug một lượt chạy phức tạp quan trọng. Log sự kiện session và view Trajectory giúp tái tạo lại những gì mô hình đã thấy và tool nào đã chạy dễ dàng hơn.
- Khi đang test nội bộ của agent. Chế độ Creator và Cordis dành cho nhà phát triển nghiên cứu cách agent được lắp ráp, hơn là người chỉ cần code ứng dụng viết sẵn.
Có thể không cần thiết cho các lệnh gọi mô hình đơn giản hoặc cho các đội muốn một coding agent làm sẵn mà không cần đụng vào nội bộ.
DeepSeek Harness có những giới hạn nào?
Vẫn là developer preview. Repository của DeepSeek nói rõ sẽ có các thay đổi phá vỡ tương thích. Điều này đã xảy ra: việc đổi tên Code thành PTC đi kèm thay đổi API session và loại bỏ một tùy chọn storage SQLite. Nên ghim phiên bản, bỏ qua bước này và hy vọng cấu hình ổn định không phải một kế hoạch tốt.
Nhiều kiểm soát hơn cũng đồng nghĩa nhiều phức tạp hơn. Việc biến nhiều phần runtime hơn thành có thể thay thế cũng cho nhà phát triển nhiều thứ phải học hơn: phụ thuộc plugin, cấu hình, khác biệt nhà cung cấp, và tương thích phiên bản. Đây là sự đánh đổi thông thường giữa tiện lợi và kiểm soát.
DeepSeek Harness có phải chạy cục bộ không? DeepSeek Harness lưu nội dung session, bản ghi tool và cấu hình cục bộ theo mặc định, theo tuyên bố xử lý dữ liệu của dự án. Có thể tắt các báo cáo ẩn danh về cấu hình và danh sách dự án. Nhưng một nhà cung cấp mô hình bên ngoài, tool web, MCP server, hoặc plugin vẫn có thể gửi dữ liệu ra ngoài máy theo chính sách riêng của nó. “Ưu tiên cục bộ” không bao phủ mọi dịch vụ được kết nối.
Chạy agent mang lại rủi ro bảo mật. Một runtime có thể chỉnh sửa file, chạy lệnh và load plugin bên thứ ba có thể gây thiệt hại thực sự. Thông báo an toàn của DeepSeek nói rằng dự án chưa qua kiểm toán bảo mật. Sandbox, phê duyệt và kiểm soát quyền hạn giảm rủi ro nhưng không đảm bảo cô lập hoàn toàn. Chạy phần mềm trên máy riêng không loại bỏ rủi ro này, nên dùng quyền hạn giới hạn và một môi trường dùng-rồi-bỏ cho công việc không tin cậy, và cẩn thận với nội dung có thể chứa chỉ dẫn ẩn.
Vì sao hành vi của agent phụ thuộc vào nhiều hơn là chỉ mô hình?
Hành vi agent phụ thuộc vào cả runtime lẫn mô hình, quay lại đúng công thức “Agent = Model + Harness”, và sự phân chia này áp dụng cho các agent LLM nói chung, không riêng DeepSeek.
Những gì một mô hình có thể tạo ra phụ thuộc vào trọng số của nó. Những gì một agent thực sự làm còn phụ thuộc vào ngữ cảnh nào đến được với mô hình, hành động nào nó được phép thực hiện, và việc thực thi bị ràng buộc chặt đến đâu. Không điều nào trong số đó nằm trong trọng số.
DeepSeek Harness cho thấy rõ lớp bao quanh đó bằng cách tách nó thành các phần có tên gọi mà nhà phát triển có thể thay thế. Chế độ Minimal cho thấy vì sao điều này quan trọng vượt ra ngoài DeepSeek: một điểm số benchmark phần nào phản ánh harness dùng để test, không chỉ mô hình. Harness không khiến một mô hình thông minh hơn, nó thay đổi bối cảnh nơi mô hình vận hành.
Kết luận
Câu mở đầu vẫn đáng nhớ nhất: mô hình reasoning, nhưng runtime quyết định quá trình reasoning đó có thể chạm tới và làm được gì. DeepSeek Harness biến runtime đó thành có thể chỉnh sửa, từ model adapter và tool đến session store và vòng lặp agent.
Quyền kiểm soát đó đi kèm chi phí. Thay thế nhiều phần runtime hơn nghĩa là phải tự 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. Một bản developer preview có quyền truy cập shell không phải thứ nên cài đặt rồi bỏ quên.
Nên dùng DeepSeek Harness khi bản thân runtime là một phần của công việc. Nếu chỉ cần chỉnh sửa repository, một coding agent làm sẵn đòi hỏi ít công sức hơn.
Câu hỏi thường gặp
DeepSeek Harness có phải cùng một thứ với một mô hình DeepSeek không?
Không, mô hình và runtime là hai thứ tách biệt. Harness không bao gồm trọng số mô hình hay tự chạy inference, mà gửi request đến DeepSeek, Anthropic, OpenAI, hoặc một mô hình cục bộ.
DeepSeek Harness có miễn phí không?
Bản thân phần mềm cấp phép MIT.
PTC mode thực sự viết tắt cho gì?
Ghi chú phát hành chính thức của DeepSeek dùng “PTC mode” mà không giải thích rõ nghĩa đầy đủ, dù hành vi khớp với “programmatic tool calling”. Nên coi đây là một định nghĩa tạm thời, chưa phải một từ viết tắt đã xác nhận, cho đến khi DeepSeek nói rõ.
Có thể tin tưởng DeepSeek Harness với một repository quan trọng không?
Một số giới hạn vẫn áp dụng. Với một repository quan trọng, nên làm việc trên một bản sao hoặc branch riêng, giữ thông tin đăng nhập sản xuất ngoài môi trường, và review từng plugin trước khi load.
“Mọi thứ đều là plugin” có nghĩa là có thể biến nó thành bất kỳ loại agent nào không?
Không, nếu không có công sức kỹ thuật thực sự. Thay thế model adapter hay vòng lặp agent vẫn đòi hỏi một plugin tuân theo đúng hợp đồng dịch vụ. Hệ thống plugin mang lại quyền truy cập vào nhiều phần hơn, chứ không khiến công việc biến mất.
