DeepSeek công khai mã nguồn Super-agent prototype ngày 31/10 và bản public vẫn chưa tự làm việc như bản nội bộ

README.md của repo deepseek-ai/dsh-superagent-prototype mở đầu bằng câu “Research prototype for reference only, not an official DeepSeek product”. Repo được tạo ngày 31/10/2026 lúc 09:32:46 UTC, tới 14:22 UTC ngày 01/11/2026 thì ghi 5.813 sao cùng 550 fork.

Nhiều người đọc tít báo rồi tưởng bản public đã tự làm việc như bản nội bộ, trong khi mặc định nó chỉ ghi lại ý định làm việc. Bài này tách bạch ba lớp rồi mới bàn thử hay chờ.

Repo deepseek-ai/dsh-superagent-prototype, research prototype, không phải sản phẩm chính thức của DeepSeek, mặc định là observe, tức là chỉ ghi lại những việc nó sẽ nhận, chứ chưa làm gì.

DeepSeek vừa đưa mã nguồn gì lên GitHub vào tối 31/10

Tối 31/10/2026 theo giờ Bắc Kinh, team Harness đăng bài thiết kế lên WeChat, và cùng ngày repo public xuất hiện, hai sự kiện này hay bị đọc như một tin duy nhất dù chúng là hai thứ khác nhau.

Repo public gồm những gì và giấy phép MIT cho phép tới đâu

Repo deepseek-ai/dsh-superagent-prototype công khai, branch chính là main, có 1 commit lúc tạo, commit hiện tại là 6337fc823ce20251c8de8085948165c81aaa701e, với 0 release và 0 tag, giấy phép MIT.

Trong repo có các thư mục docs, examples, locale, prompts, scripts, skills, src, tests, kèm file README.md, SETUP.md, package.json, và một bài phân tích đếm 111 file trong src và 65 file trong tests, gói TypeScript v0.1.0 theo MarkTechPost.

Tài liệu đi kèm chạy từ 000 Philosophy, 001 Domain model, 002 Authorization, 003 Execution, 004 Prompts, 005 Panel, 006 Deployment, 007 Architecture tới 008 Cookbook, đọc theo thứ tự, mỗi tài liệu chỉ dựa vào những tài liệu trước nó.

Giấy phép MIT cho phép dùng, sao chép, sửa, phân phối, cấp phép lại và bán, kèm điều kiện giữ lại thông báo bản quyền và giấy phép, code được cung cấp không bảo hành.

Repo tải về thì không mất tiền bản quyền, nhưng chạy nó thì tốn thật: tiền gọi model, tiền máy phải bật liên tục, và giờ người ngồi rà soát.

Mình thì hay nhìn đường đi của số sao hơn là nhìn một con số đứng yên, vì số này trôi theo giờ, anh em ạ.

Trước mốc 14:22 UTC ngày 01/11, repo ghi khoảng 2.046 sao và 172 fork lúc khoảng 22:10 UTC ngày 31/10, rồi 3.433 sao lúc khoảng 04:20 UTC ngày 01/11, và 4.117 sao cùng 379 fork lúc khoảng 07:20 UTC ngày 01/11, theo các bài phân tích dẫn lại.

Vì sao README phải mở đầu bằng cảnh báo prototype

README mở đầu bằng ba câu đã đối chiếu trực tiếp, từ câu “Research prototype for reference only, not an official DeepSeek product”, tới câu “Some designs discussed in the article are directions for future development and are not implemented in this prototype”.

Câu thứ ba là câu triết lý “take as little human attention as possible, and give as much value as possible”.

Giới hạn ghi trong đó là repo chưa production-ready, có thể còn bug, phong cách code chưa đồng đều, nên cần rà soát và chỉnh lại trước khi dùng. Phần lớn kỹ thuật lại do coding agent làm ra, nên anh em vọc thử thì nhớ đọc kỹ cảnh báo này trước đã nhé.

Bản public làm được gì trong đúng một repo

Theo README đọc trực tiếp thì đây là coding agent chủ động cho đúng một repo GitHub, đóng gói thành bundle cho DeepSeek Harness, nghe GitHub và, nếu có cấu hình, nghe thêm Feishu.

Khi người được phép nhờ việc thì nó mở work item, làm trong session và thư mục riêng, trả lời ở cuộc trò chuyện gốc, ví dụ bằng pull request.

Web panel chỉ liệt kê việc cần con người, nên anh em đừng tưởng đây là trợ lý đa năng cho mọi việc văn phòng, vì phạm vi của nó chỉ có một repo và một bundle thôi.

Bài thiết kế, bản nội bộ và bản public là ba thứ khác nhau

Mục này gỡ từng lớp ra, vì gộp ba lớp thành một là hiểu lầm bền nhất, và mỗi lớp lại có trạng thái code khác nhau.

Bài thiết kế viết gì và phần nào vẫn chỉ là hướng tương lai

Bài thiết kế “Exploring Super-agent Design: Towards a More Autonomous Agent System” đăng tối 31/10/2026 theo giờ Bắc Kinh, nêu bốn tính chất mục tiêu, là continuous, efficient, proactive và persistent, và chính README cũng ghi một số ý trong bài thiết kế chỉ là hướng tương lai, chưa có trong prototype.

Bài thiết kế tự nêu các vấn đề mở, như khi nào cần chia Router thành nhiều instance, Worker nói chuyện trực tiếp với nhau ra sao, bộ nhớ dài hạn cho agent chạy nhiều tháng, cách hiển thị task khi session bị giấu, tới bảo mật credential khi cloud loop bị xâm nhập qua breach máy chủ hoặc prompt injection.

Hai ví dụ trong bài thiết kế cũng đáng nhớ, một là nhóm chat đồng ý A rồi đổi sang B trong comment pull request, agent phải nhận ra đây là cùng một việc rồi đổi hướng, hai là bug dấu ngã hiển thị thành gạch ngang mà agent đã mở pull request sửa trong lúc nhóm vẫn đang bàn.

Hai ví dụ này chỉ là minh họa trong bài thiết kế, còn bản public ngoài đời thì vẫn cần kiểm chứng thêm.

Bài thiết kế còn có câu, theo SCMP dẫn lại, “Single-task limits depend on model capabilities, while multitask limits depend on human attention”, tức nút thắt đa nhiệm nằm ở sự chú ý của con người khi phải ôm nhiều việc cùng lúc.

Bản nội bộ đã chạy ra sao trong team DeepSeek

Theo bài thiết kế thì bản nội bộ đã chạy liên tục trong team DeepSeek, tự tái hiện bug từ group chat, trả lời code review và góp phần làm Harness, và đây chính là phần báo chí hay lấy để mô tả bản public, dù bản public không có cùng phạm vi đó.

Thông tin này đến từ bài thiết kế và báo dẫn lại, anh em chưa mở code public ra đối chiếu được phần này, nên đọc tới đây thì cứ giữ một dấu hỏi trong đầu đã, vội tin hết thì dễ bị tít báo dắt đi lắm.

Bản public hẹp hơn ở những điểm nào

Bản public chỉ là bundle hẹp cho một repo, nghe GitHub và Feishu tùy chọn, mặc định không tự làm việc chưa ai nhờ, khác hẳn bản nội bộ chạy liên tục và nghe cả group chat rộng hơn.

Luồng làm việc trong prototype đi theo thứ tự Source sinh event, Eval quyết định event có phải việc mới hay không, rồi Ticket là đơn vị việc được phép, kèm Mandate bất biến ghi phiên bản policy, phạm vi, rule khớp và danh tính người nhờ, nên Ticket vì vậy giống một phiếu việc đã đóng dấu phạm vi, muốn thêm việc thì phải mở phiếu mới.

Về vận hành, session chính chạy preset dsh-superagent-router với ít công cụ hơn, Worker chạy dsh-superagent-worker, lệnh shell chuyển sang nền sau 5 giây, và việc nền tối đa 30 phút sau mỗi turn rồi bị kết thúc.

Mặc định có 3 worker slot cộng 1 slot dự trữ cho follow-up của con người, state nằm trong một file SQLite, và GitHub source poll repo mỗi phút theo mặc định.

Agent xác nhận request một lần, im lặng trong lúc làm, chỉ lên tiếng lại khi có kết quả, cần quyết định hoặc làm không xong, và hỏi một câu một lần ở dạng có cấu trúc.

Mọi message GitHub mặc định mở đầu bằng dòng nói rõ người gửi là agent tự động, để người đọc khỏi tưởng mình đang chat với một đồng nghiệp thật.

Chữ chủ động trong bản public thật ra là chủ động có điều kiện

Agent trong bản public chỉ làm khi team đã viết rule trước và chọn đúng chế độ, và cách team viết rule mới là phần đáng học.

Team phải viết rule thế nào thì agent mới được tự nhận việc

Cơ chế bắt đầu từ việc team viết rule trước, mô tả việc nào được phép tự nhận, rồi để agent ở chế độ ghi lại một thời gian để đọc xem nó sẽ nhận việc nào, sau đó mới quyết định có bật chế độ tự làm hay không.

Mình hay ví quy trình này như giao cho nhân viên mới một cuốn sổ quy tắc, cho thử việc ở chế độ chỉ ghi chép, rồi mới giao việc thật.

Rule cùng prompt trong prototype thì viết ra được, version được và kiểm tra được từng dòng, nên team nhỏ mà viết rule càng rõ thì agent im lặng càng đáng tin.

Ba chế độ off, observe và auto khác nhau ra sao

Chế độ off chỉ xử lý request trực tiếp, chế độ observe là mặc định, chỉ ghi lại việc nó sẽ nhận mà không làm gì, chế độ auto thì nếu đánh giá đạt, agent sẽ bắt đầu làm, và SETUP.md cũng đặt giá trị mặc định accept là observe.

Lộ trình thử đúng theo tài liệu là bắt đầu ở observe, đọc log xem agent sẽ nhận việc nào, rồi mới cân nhắc auto.

Vì sao agent im lặng lại là một tính năng

Triết lý repo nằm trong câu nguyên văn “take as little human attention as possible, and give as much value as possible”, và cách diễn giải của mình là mỗi message, mỗi thông báo, mỗi dòng panel đều tốn sự chú ý của ai đó, nên phải đáng giá hơn cái giá đó thì mới được phép xuất hiện.

Mình thì hay ví sự chú ý như tiền trong ví, mỗi lần agent lên tiếng là một lần rút ví, nên phải đáng tiền thì mới rút.

Câu chốt trong tài liệu triết lý, theo i-scoop dẫn lại, là “the right help at the right time, and nothing at any other time”, tức im lặng đúng lúc là thiết kế có chủ ý, anh em ạ.

i-scoop cũng đề xuất thêm một chỉ số cho team nhỏ áp dụng ngay mà khỏi cần chạy prototype, là số lần bị ngắt trên mỗi việc hoàn thành, vì agent làm nhiều mà cứ lôi con người ra khỏi việc đang làm thì chưa tiết kiệm thời gian, nó chuyển chi phí sang người phải giám sát nó.

Router và Worker chia việc thế nào và vì sao sự chú ý lại là ngân sách

Câu trả lời nằm ở hai tầng Router và Worker cùng cách chúng quản lý context như một ngân sách có hạn.

Router thường trực làm gì và Worker làm từng việc ra sao

Kiến trúc trong bài thiết kế có hai tầng Router và Worker, trong đó Router thường trực lo giao tiếp và chia việc, giữ context chung, có thể chạy model nhẹ hơn và không cần Bash, còn Worker là session riêng cho một việc, có đủ công cụ và thường chạy model mạnh nhất, và Worker thì không nói chuyện trực tiếp với người dùng mà báo cáo lại cho Router.

Trigger là event bán cấu trúc từ môi trường, từ message group chat, email và nhắc lịch, comment code review tới kết quả CI, và lọc thì có hai tầng, Fast Path bằng rule theo nguồn, group và danh sách cho phép, Slow Path bằng model đánh giá theo policy.

Thread là chuỗi event liên tiếp trong cùng pull request, topic chat hoặc chuỗi email, còn Subscription nhiều-nhiều nghĩa là hai Worker cùng chạm vào một pull request thì cả hai đều nhận event mới và tự phát hiện xung đột, không cần nhắn trực tiếp cho nhau.

Context được quản lý như một ngân sách có hạn

Quản lý context kiểu cache gồm Inline đưa thông tin có thể cần vào thẳng context, ví dụ 50 ký tự đầu của message, Spill cắt phần vượt ngân sách và để lại con trỏ để đọc thêm, và Chain of Recall gắn ID của object liên quan vào nội dung được đưa vào để model lần theo từng hop.

Trả lời theo kênh thì chat IM giữ dưới 100 từ mỗi lần trả lời, GitHub và email nhận bản giao có cấu trúc, mô tả pull request theo quy ước dự án, ghi bối cảnh, thay đổi và kiểm chứng.

Vòng lặp async thì lệnh dài chuyển thành start() và stop(), gọi xong trả về Started ngay, kết quả quay lại thành event mới, model có thể dừng lệnh chạy quá lâu.

Cơ chế này đã có trong Harness nhưng mặc định chưa bật, nên anh em đừng gán nó cho prototype như một tính năng đã bật sẵn nhé.

Tách compute, state và môi trường cùng Watchdog

Ở lớp bài thiết kế, compute, state và môi trường được tách ra, vì vòng lặp chạy trong container cloud không trạng thái, session nằm trong database, còn máy local chỉ chạy daemon nhẹ, không giữ session.

BYOM cho phép máy dev có thay đổi chưa commit và credential local nối vào trực tiếp, còn Watchdog là session độc lập lo lỗi hạ tầng và khôi phục state.

Con số 12,4 phút và 15,7 phút chỉ đo thời gian điều phối, chưa đo chất lượng code

Con số hay được trích nhất lại là con số dễ đọc sai nhất, vì nó đo thời gian điều phối trong một thử nghiệm tổng hợp do chính team tự làm.

Thử nghiệm tổng hợp được dựng ra sao

Mỗi lượt chạy có khoảng 300 message, khoảng 20 yêu cầu việc thật, còn lại là tán gẫu, follow-up và message CI, và mỗi cấu hình chạy 5 lần.

Thời gian message và thời lượng việc thu nhỏ còn 1/4, độ trễ gọi model là thật, việc code thật thay bằng tool chỉ tốn thời gian, và tác giả tự gọi kết quả là tham khảo sơ bộ, nên anh em đọc số thì nhớ kèm chữ tham khảo sơ bộ này theo luôn nhé.

Bốn cấu hình cho ra con số nào và cái giá token là bao nhiêu

Số do team tự báo thì Super-agent cho p50 12,4 phút, p95 15,7 phút, cache-read 23,23 triệu token mỗi lượt, trong khi Super-agent không có direct delivery cho p50 12,6 phút, p95 15,5 phút, cache-read 31,77 triệu token.

Bỏ direct delivery thì số quyết định của Router tăng khoảng 30% và cache-read tăng khoảng 37%, từ 23,23 triệu lên 31,77 triệu.

Hai cấu hình session đơn kèm subagent thì khác hẳn, prompt trung tính cho p50 20,4 phút, p95 29,5 phút, cache-read 6,05 triệu token, và trong 5 lượt thì model không gọi subagent lần nào.

Còn prompt khuyến khích ủy quyền cho p50 13,8 phút, p95 29,0 phút, cache-read 10,82 triệu token, ủy quyền trong 4 trên 5 lượt, lượt còn lại model tự làm vì cho rằng việc nhỏ, tạo ra đuôi dài ở p95.

Thử tải Router riêng, dùng model thật cho Router và model giả cho Worker, thì tần suất Trigger từ khoảng 1 lên khoảng 40 mỗi phút, batch trung bình từ 1,0 lên 2,8, độ trễ mỗi request từ 2,5 giây lên 3,9 giây, thời gian suy luận chia đều cho mỗi quyết định từ 6,4 giây xuống 1,6 giây.

Team kết luận một Router thường trực là đủ ở quy mô team hiện tại, chưa cần chia ngang.

Đọc theo hóa đơn trong thử nghiệm này thì nhanh và ổn định hơn phải trả bằng token, 23,23 triệu cache-read so với 6,05 triệu và 10,82 triệu của hai baseline, nên anh em nhìn đồng hồ xong thì nhớ nhìn thêm hóa đơn token cuối tháng, kẻo tới lúc đó mới giật mình thì đã muộn rồi.

Vì sao không được đọc thành nhanh hơn Claude Code

Tất cả số trên đều do team tự báo, chưa có kiểm chứng độc lập, chưa đo chất lượng code, chưa đo tỉ lệ pull request được merge, và chưa so với Claude Code hay Codex.

Vì vậy con số này chỉ có nghĩa là nhanh hơn trong thử nghiệm tổng hợp của chính team, và chưa đủ để kết luận nhanh hơn Claude Code, nên anh em đừng mang số này đi tranh luận như một benchmark độc lập nhé.

Muốn thử thì chuẩn bị gì theo SETUP.md và thử an toàn ra sao

Độc giả dev sẽ muốn vọc ngay, còn độc giả văn phòng không code thì nên dừng ở mức đọc hiểu.

SETUP.md bắt coding agent hỏi từng câu một

Quy trình do coding agent dẫn dắt, hỏi từng câu một, mỗi câu dưới 300 từ, kèm đáp án khuyên dùng mà operator có thể chấp nhận bằng một từ, và một câu giải thích vì sao câu hỏi đó quan trọng.

Trong lúc hỏi thì agent không thực thi, thu đủ đáp án rồi gửi một bản kế hoạch dưới 300 từ, và chỉ chạy sau khi operator xác nhận.

SETUP.md cũng dặn không bao giờ hỏi secret trong chat, và bước cần tay operator như tạo tài khoản, đăng nhập CLI hoặc nhập app secret thì gom vào một message với đúng lệnh cần chạy trong terminal của họ, nên anh em đừng ngạc nhiên khi thấy agent hỏi dồn một lần rồi im luôn nhé.

9 câu hỏi theo thứ tự là nguồn lấy request, repo dạng owner/name, tài khoản agent, chat Feishu nếu có, ai được phép nhờ việc trên GitHub, ai được phép nhờ trong Feishu, checkout ở đâu, commit ghi tên ai, và có bật auto-merge hay không.

Điều kiện tiên quyết là Node.js từ 22.19 trở lên hoặc 24 trở lên, pnpm, git từ 2.32 trở lên, tmux, Python từ 3.8 trở lên, và GitHub CLI từ 2.48 trở lên, còn thiếu cái nào thì thành mục trong kế hoạch, chứ không thành câu hỏi mới.

Giá trị mặc định và bước operator tự làm

Giá trị mặc định không hỏi thì có profile superagent là bản sao profile Web của DSH, tách khỏi profile làm việc thường ngày, cổng 3082, state ở <home>/.dsh/state/superagent dạng đường dẫn tuyệt đối, và kiểm tra mỗi giờ từ profile của operator để sửa dsh-superagent khi nó không chạy.

Các mặc định còn lại là tiền tố branch agent/, accept observe, rule và prompt mặc định, còn với Feishu thì bot chỉ đọc mention và bật direct message, và theo các bài phân tích triển khai thì repo chỉ hỗ trợ github.com.

Bước xác minh cuối là scripts/dsh-superagent status trả về 0 và không còn vấn đề setup, cách thử là comment @<tài khoản agent> <yêu cầu> trên issue, Ticket hiện trên panel trong khoảng một phút, và anh em làm đúng tới bước này thì mới tính là setup xong nhé.

Một chi tiết nữa chỉ ở mức theo bài phân tích, chưa đối chiếu trực tiếp trong SETUP.md, là cần Harness 0.2.1-alpha.2 trở lên, nên mình ghi đúng mức này thôi, anh em đừng đọc nó thành yêu cầu chính thức trong SETUP.md nhé.

Checklist thử an toàn và bước nào dễ làm sai nhất

Checklist chốt thì đi theo từng lớp an toàn, từ repo dùng một lần, không secret, không dữ liệu khách hàng, tới tài khoản hệ điều hành riêng chỉ giữ credential của agent, tài khoản GitHub riêng không bao giờ là tài khoản cá nhân, và quyền repo chỉ đúng một repo.

Danh sách cho phép thật ngắn, bắt đầu ở chế độ observe, rà soát từng pull request như của người lạ, và không dùng agent để tạo khối lượng.

Bước dễ làm sai nhất là dùng tài khoản cá nhân làm tài khoản agent và bật auto-merge quá sớm khi chưa có branch protection, và SETUP.md khuyên danh sách cho phép trên GitHub lúc đầu chỉ có đúng login của operator, nên anh em cứ làm đúng đoạn này trước đã.

Còn anh em văn phòng không code thì dừng ở mức đọc hiểu, chưa nên cài nếu không có người rành đi cùng, vì chi phí thật còn có tiền gọi model theo provider, máy phải luôn bật để agent nghe event, và giờ rà soát pull request nữa cơ.

Bối cảnh CVE-2026-82533 thì càng đáng nhớ, vì điểm CVSS 9,4, ảnh hưởng Harness từ 0.1.1-rc.2 trở về trước, và công bố ngày 08/09/2026.

Cơ chế là giao diện web local tin header Host do client gửi và không yêu cầu xác thực, agent trong sandbox có thể gọi giao diện đó để chuyển session sang chế độ danger-full-access, tắt sandbox và tắt prompt duyệt.

Bản sửa đầu tiên là 0.1.2-alpha.1 ngày 27/08, bản npm đầu tiên có sửa là 0.1.2-alpha.2 ngày 30/08, rồi 0.1.2-rc.1 ngày 03/09, và không có báo cáo khai thác thực tế nào trong các nguồn đã đọc.

Cộng đồng hào hứng, cộng đồng dè chừng, và điểm nào đáng giữ lại

Người đọc repo đầu tiên chia làm hai phe, một phe đọc repo như hệ thống luôn bật, một phe thì hạ nhiệt ngay.

Phe hào hứng đọc repo như hệ thống luôn bật

Theo bài phân tích dẫn lại thì thread Reddit r/singularity về repo đã vượt 440 vote trong một buổi sáng, và bài đăng giới thiệu repo như kiến trúc của agent luôn bật của DeepSeek.

Số vote 440 là theo bài phân tích dẫn lại, chưa đọc trực tiếp thread Reddit, và README cũng không dùng cụm luôn bật mà dùng từ proactive kèm điều kiện chặt, nên đây là hiểu lầm cần sửa.

Theo bài phân tích Trending on Weibo thì tin này lên hạng 5 trên bảng Baidu trong một ngày, câu hỏi trên Zhihu so sánh thiết kế này với framework agent mà các lab phương Tây đã demo suốt năm.

Nhận xét kèm theo là các lab Trung Quốc trước nay đua benchmark model, DeepSeek giờ đua scaffolding, tức phần ống nối biến model giỏi thành đồng nghiệp.

Coheser thì cho rằng ba lý do khiến dev hào hứng là code thật sự mở, không tốn phí bản quyền để thử, và kiến trúc dễ đọc, đọc được từng lớp thay vì hộp đen.

Mình đồng tình ở vế kiến trúc dễ đọc, còn mã nguồn mở thì chuyển trách nhiệm sang người dùng, vì người dùng vẫn phải tự vet code, tự cấu hình sandbox và tự review từng thay đổi.

Medium AIFix thì thực dụng hơn, cho rằng Super-agent hợp với team nhỏ và solo builder đã dùng GitHub và quen dòng lệnh, còn team chỉ muốn AI trả lời email khách hàng thì nên tìm tool khác, và bài này cũng từ chối kết luận cái nào tốt hơn vì repo chưa có benchmark chính thức.

Phe dè chừng và câu hỏi về độ tin cậy

Theo bài phân tích dẫn lại thì comment vote cao nhất trên Reddit r/singularity cho rằng agent này khá bình thường, điểm nổi bật không nằm ở việc nó làm, mà nằm ở việc nó được thiết kế để ít làm phiền đến mức nào.

Mình đồng tình vì đúng luận điểm của tài liệu triết lý, nhưng chỉ tóm tắt ý vì chưa đọc trực tiếp thread.

Một comment khác trên cùng thread, qua bài phân tích, gọi repo này là một GitHub bot đơn giản, và mình chỉ đồng tình một nửa, vì phần bot thì quen thuộc thật, đọc issue và mở pull request thì agent nào cũng làm.

Còn phần rulebook viết ra, version được và kiểm tra được từng dòng thì hiếm bot nào có đủ, và đó đúng là điểm Pillitteri khen có điều kiện.

Hacker News thì bàn về Harness nói chung, chứ chưa có thread riêng cho Super-agent trong kết quả search, một số người khen khả năng quan sát toàn bộ prompt, response và tool call, người khác thì hỏi thẳng nó làm được gì mà harness khác làm được, rồi nhắc Pi hay OpenCode cũng làm được nhiều việc tương tự.

Bình luận Trung Quốc, qua i-scoop, thì sắc hơn, rằng bài thiết kế nói ít về việc bộ lọc event sai bao nhiêu lần, và Worker có quyền làm nhưng chưa có ngân sách hay giám sát, một loạt pull request dở sẽ ngốn đúng thứ sự chú ý mà hệ thống này muốn tiết kiệm.

Mình đồng tình hoàn toàn, vì chưa có số liệu tỉ lệ lọc sai nên mình cũng không bịa con số nào ở đây.

i-scoop thì gợi ý đếm số lần bị ngắt trên mỗi việc hoàn thành thay vì đếm tính năng, để team nhỏ đo đúng cái giá của sự chú ý.

Tin gọi vốn khoảng 100 tỉ nhân dân tệ xuất hiện trước Super-agent gần mười ngày

Đặt tin gọi vốn ở cuối là có chủ ý, vì nó xuất hiện trước Super-agent gần mười ngày.

Bloomberg ngày 22/10 nói gì và ai chưa xác nhận

Bloomberg ngày 22/10/2026 lúc 02:17 UTC, dẫn nguồn thạo tin, nói DeepSeek huy động khoảng 100 tỉ nhân dân tệ, tương đương khoảng 15 tỉ USD, Tencent và CATL nằm trong nhóm nhà đầu tư lớn nhất.

Reuters cùng ngày nói vòng gọi vốn đang hoàn tất trong vài ngày tới và điều khoản vẫn có thể đổi, và DeepSeek, Tencent và CATL đều chưa xác nhận trong các nguồn đã đọc.

IPO và bối cảnh cạnh tranh chỉ dừng ở mức có thể

IPO chỉ ở mức có thể, cụ thể là Reuters tháng 09 nói DeepSeek thuê CITIC Securities chuẩn bị cho khả năng niêm yết trên sàn STAR Thượng Hải.

Thời điểm có thể là cuối 2026 nộp hồ sơ và đầu 2027 lên sàn, tất cả vẫn là có thể, chưa có ngày, quy mô hay định giá chào bán nào được chốt.

Kết luận

Câu hỏi còn lại là team của anh em có viết nổi rule đủ rõ và rà soát nổi từng pull request không.

Lời khuyên chốt cũng phân theo nhóm độc giả, từ dev thì thử trên repo dùng một lần, tài khoản riêng, observe trước, rà soát từng pull request, tới dân văn phòng không code thì dừng ở mức đọc hiểu và chờ bản ổn định hơn.

Không ai nên chạy trên repo chính, repo khách hàng hoặc repo có secret.

Bloomberg báo ngày 22/10 khoảng 100 tỉ nhân dân tệ, chưa được DeepSeek, Tencent hay CATL xác nhận, và khoản này không gắn với Super-agent.

Mình vẫn muốn nghe anh em tranh luận bằng trải nghiệm thật nếu đã thử ở observe.

Nguồn tham khảo

• Repo Super-agent: github.com/deepseek-ai/dsh-superagent-prototype
• Hướng dẫn cài đặt SETUP.md: github.com/deepseek-ai/dsh-superagent-prototype/blob/main/SETUP.md
• Bài thiết kế qua SCMP: scmp.com
• Kiến trúc qua AgentsPulse: agentspulse.github.io
• Phân tích triển khai qua i-scoop: i-scoop.eu
• Tin gọi vốn qua Bloomberg, dẫn lại bởi Cellcog: cellcog.ai
• Lỗ hổng CVE qua PointGuardAI: pointguardai.com