Tìm kiếm
40 kết quả cho “vòng lặp agent”. Tìm không phân biệt dấu.
- Coding agent trong engineering (migrate, viết lại, chạy song song, quyền hạn) Chủ đề Thành viên
Từ 2026 các công ty bắt đầu giao cho coding agent những việc trước đây là dự án nhiều tuần: migrate hàng trăm module hay dataset, dọn feature flag, viết lại cả framework hay app. Agent viết nhanh, nhưng ba thứ không tự…
- Engineering Multi-Agent AI Teams That Build and Test Themselves Bài tóm tắt · Salesforce · 2026
…ỗi khởi động, soft failure chạy bình thường mà kết quả sai, vòng lặp vô hạn, hỏng trạng thái); tối đa 2 lần sửa và 3 USD , quá thì dừng và chuyển người. Vì sao - Theo Salesforce: t…
- How we built our multi-agent research system Bài tóm tắt · Anthropic · 2025
…à quyết định kinh tế. Liên quan - (hạ tầng chạy agent, tách vòng lặp khỏi sandbox) · - ·…
- Coding Is No Longer the Constraint: Scaling Developer Experience to Teams and Agents Bài tóm tắt · Spotify · 2026
…stack và lint/chuẩn tự động là hạ tầng cho agent: cùng một vòng phản hồi phục vụ người lẫn máy. - Agent đặt giữa hệ điều phối có sẵn (chọn đích, theo dõi PR) và cổng kiểm có sẵn (…
- Infrastructure patterns for agentic applications Bài tóm tắt · Render · 2026
…t là gắn độ tin cậy của ứng dụng vào thời gian chạy của một vòng lặp không tất định. Thay đổi chính - Mẫu 1: tách lần chạy khỏi request. Request chỉ tạo bản ghi run bền, đẩy việc v…
- Making Navigations Instant in v0 Bài tóm tắt · Vercel · 2026
…của Next.js 16.3 (), và theo Vercel, một coding agent chạy vòng lặp làm phần lớn việc sửa. Thay đổi chính - Prerender cho app động: trước đây chỉ có hai công cụ (tĩnh/PPR, hoặc ch…
- Automating Feature-Flag Cleanup at Scale with a Multi-Agent LLM System Bài tóm tắt · DoorDash · 2026
…mặc định trong code đã khớp production). Bài học cho SWE - Vòng đời feature flag cần cả bước xoá; xoá đúng cần dữ liệu vận hành (trạng thái rollout), không chỉ code. - Agent sửa c…
- Scaling Managed Agents: Decoupling the brain from the hands Bài tóm tắt · Anthropic · 2026
…hành ba thành phần có trạng thái riêng. Bối cảnh - Harness (vòng lặp gọi model và chuyển tool call tới hạ tầng) chứa giả định về những gì model chưa tự làm được, và giả định đó cũ…
- AutoCog — Generate Cog configuration with GPT-4 Bài tóm tắt · Replicate · 2023
…y để đóng gói repo ML, theo kiểu Auto-GPT. Thay đổi chính - Vòng lặp: xếp file repo theo độ liên quan, nhét vừa context window (bài ghi 8096 token) vào GPT-4, sinh hai file, chạy c…
- Sitar-agent: Building a reliable dynamic configuration sidecar at scale Bài tóm tắt · Airbnb · 2026
…t bằng Java, Python, Go, TypeScript, Ruby. Thay đổi chính - Vòng đời giao config: commit vào Sitar Service (version, changelog, ACL) → Snapshot Service mỗi giờ đóng gói toàn bộ con…
- Helix: The internal tool powering our Shopify app's native migration Bài tóm tắt · Shopify · 2026
…có sẵn; cần công cụ và rào chắn. Thay đổi chính - Không kỳ vọng lần đầu đúng. Thay vì gom hết thông tin thành đặc tả, làm cả màn hình một lần rồi trao một diff khổng lồ, Helix dựn…
- Halving the Time: How Uber Eats Rebuilt Its Search Pipeline Bài tóm tắt · Uber · 2026
…ampaign, pacing) vào bộ nhớ ứng dụng thay vì gọi DB, bỏ các vòng serialize thừa giữa thành phần, lọc trường không dùng trước khi gửi: tổng khoảng 130 ms. - Tinh chỉnh hạ tầng (khoả…
- How we rebuilt Next.js with AI in one week Bài tóm tắt · Cloudflare · 2026
…thống nhất kiến trúc với Claude (OpenCode) thành kế hoạch; vòng lặp "giao task → AI viết code và test → chạy test → qua thì merge, không thì đưa lỗi cho AI"; agent review PR và ag…
- Safeguarding Dynamic Configuration Changes at Scale Bài tóm tắt · Airbnb · 2026
…thay đổi xấu gây hồi quy hoặc incident. Thay đổi chính - Kỳ vọng với nền tảng config (theo Airbnb): trải nghiệm liền mạch định nghĩa → review → test → rollout; mọi thay đổi được ki…
- Tự động hoá vận hành và auto-remediation Chủ đề Thành viên
Khi số máy, shard, pod tăng lên hàng nghìn, lỗi "hiếm" (một node chết, một đĩa hỏng, một replica trễ) thành chuyện hằng ngày, và thao tác tay không còn theo kịp: Stripe có hàng trăm lần shard suy giảm mỗi năm, mỗi lần…
- Bảo mật hạ tầng và quản lý secret Chủ đề Thành viên
Khi hệ thống lớn lên, số credential (mật khẩu DB, API key, SSH key, token, cookie phiên) tăng theo số service, pipeline, nhà cung cấp, và chúng rải vào code, cấu hình, hệ build, log. Các nguồn trong wiki cho thấy kẻ tấn…
- Monolith và microservices — đi và quay lại Chủ đề Thành viên
Lúc nào nên tách hệ thống thành nhiều service, và cái giá của việc đó là gì? Các nguồn hiện có cho thấy đây không phải đường một chiều.
- Xác thực và phân quyền (authn/authz) Chủ đề Thành viên
Ở monolith, mỗi dữ liệu thường chỉ có một đường vào, nên kiểm tra quyền nằm ngay đó: một hàm hasaccess?, một API mỗi resource. Khi hệ thống tách thành nhiều service, nhiều client, nhiều loại token, cả hai nửa đều vỡ:
- Event-driven, message queue và Kafka Chủ đề Thành viên
Khi một hệ có nhiều bên cần biết "có gì vừa xảy ra" (đơn hàng đổi trạng thái, tin đăng được sửa, ticket được cập nhật), synchronous call từng bên một làm producer phải biết mọi consumer, và một consumer chậm kéo chậm cả…
- Hot partition và thundering herd Chủ đề Thành viên
Chia dữ liệu và tải ra nhiều máy chỉ hiệu quả khi tải chia đều. Thực tế tải lệch: một khách hàng khổng lồ, một kênh có @everyone, một bài của người nổi tiếng. Có hai dạng hay gặp:
- Nền tảng nội bộ cho service (đường ray chung) Chủ đề Thành viên
Tách hệ thống thành nhiều phần (service, hoặc component trong một monolith) giải được bài toán tổ chức. Nhưng nếu mỗi team tự làm RPC, retry, log, metric, contract theo cách riêng, thì ta chỉ đổi một kiểu hỗn loạn lấy…
- Migration không downtime Chủ đề Thành viên
Hệ thống đang chạy thật (gọi xe, chat, thiết kế) không được dừng, nhưng phải đổi ngôn ngữ, database hoặc hạ tầng bên dưới.
- Deploy và release an toàn Chủ đề Thành viên
Phần lớn incident bắt đầu bằng một thay đổi: code mới, cấu hình mới, hạ tầng mới. Khi hệ thống và tổ chức lớn lên, câu hỏi là làm sao đưa thay đổi lên production thường xuyên mà vẫn giới hạn được thiệt hại khi có lỗi.
- Quản lý fleet và migrate code hàng loạt Chủ đề Thành viên
Khi số component (repo, service, pipeline, thư viện) tăng nhanh hơn số kỹ sư, chi phí của mỗi thay đổi xuyên suốt (nâng thư viện, vá bảo mật, đổi API nội bộ, khai tử dataset) tỉ lệ với số component chứ không với độ khó…
- Độ tin cậy và multi-region Chủ đề Thành viên
Thay đổi kiến trúc lớn thường không đến từ kế hoạch mà từ một incident đau đớn. Khi đã chạy nhiều vùng, nhiều giả định của hệ thống một vùng không còn đúng.
- Observability và monitoring Chủ đề Thành viên
Lúc đầu, monitoring là vài dashboard và một công cụ cài sẵn; log đọc thẳng từ máy. Khi hệ lớn lên, chính hệ quan sát thành một hệ phân tán có bài toán riêng:
- Incident và postmortem Chủ đề Thành viên
Nhiều bước ngoặt kiến trúc trong wiki bắt đầu từ một incident: Netflix lên cloud sau 3 ngày không gửi được DVD, Twitter viết lại hệ thống sau World Cup 2010, Instagram đi nhiều data center sau trận bão 2012. Trang này…
- CI và build ở quy mô lớn Chủ đề Thành viên
Lúc nhỏ, CI là "mỗi commit chạy hết build và test". Khi codebase và số commit tăng, chạy hết trở thành bất khả (Stripe 2026: chạy tuần tự mất bốn tháng), và thời gian chờ của một thay đổi không còn chỉ là thời gian…
- Tách compute khỏi storage Chủ đề Thành viên
Hệ có trạng thái kiểu cổ điển (database, broker Kafka, fileserver Git) đặt dữ liệu bền trên đĩa của chính máy xử lý. Máy đó vừa là compute vừa là storage, nên:
- Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định) Chủ đề Thành viên
Lỗi trong hệ phân tán là chắc chắn (máy chết, zone mất, dependency chậm, cấu hình sai), nhưng phần lớn lỗi nằm ở những tổ hợp hiếm mà test chức năng không chạm tới. Bài toán là chủ động gây lỗi để biết hệ thống phản ứng…
- Kiến trúc frontend Chủ đề Thành viên
Frontend bắt đầu là vài trang render ở server; lớn lên thành ứng dụng có trạng thái, nhiều team cùng sửa, và mỗi tính năng thêm vào là thêm byte phải tải. Ba trục lặp lại trong các nguồn: render ở đâu (server, client,…
- Chi phí hạ tầng và build vs buy Chủ đề Thành viên
Khi còn nhỏ, chi phí hạ tầng là chuyện phụ và cloud là lựa chọn hiển nhiên. Khi lớn lên, hoá đơn có thể chiếm phần lớn giá vốn. Hai câu hỏi xuất hiện: tối ưu chi phí trên nền đang có thế nào, và khi nào nên tự xây (hoặc…
- Thử nghiệm A/B và nền tảng experimentation Chủ đề Thành viên
Khi nhiều team cùng thay đổi một sản phẩm, "ship rồi xem metric" không còn trả lời được thay đổi nào gây ra gì. Thí nghiệm có đối chứng trả lời được, nhưng ở quy mô lớn nó thành một hệ thống: gán người dùng vào biến thể…
- Xử lý incident và on-call Chủ đề Thành viên
Khi hệ còn nhỏ, vài người biết hết mọi thứ; có lỗi thì người thấy đầu tiên sửa luôn. Khi có hàng trăm service và hàng trăm engineer, câu hỏi đổi khác:
- Failover, replica và dự phòng dữ liệu Chủ đề Thành viên
Mọi hệ có trạng thái đều giữ nhiều bản (replica) để một máy chết không làm mất dịch vụ. Khó không nằm ở việc có bản sao mà ở lúc chuyển sang bản sao:
- Distributed transaction và nhất quán xuyên service Chủ đề Thành viên
Với một DB quan hệ, BEGIN … COMMIT lo hết. Khi dữ liệu bị chia (shard, tách service, thêm Redis bên cạnh Postgres), một thao tác nghiệp vụ chạm nhiều nơi, và câu hỏi khó nhất trở thành "timeout rồi, việc đó đã xảy ra…
- Vercel Công ty Thành viên
Công ty làm framework Next.js (mã nguồn mở) và nền tảng chạy nó; nhận định về sản phẩm của chính họ trong các nguồn đều là "theo Vercel". Câu chuyện chia hai nửa. Về framework: Next.js bắt đầu bằng router theo file và…
- Pipeline dữ liệu và analytics Chủ đề Thành viên
Lúc đầu, báo cáo chạy thẳng trên DB production. Đến một lúc truy vấn phân tích làm chậm giao dịch, dữ liệu cần gộp từ nhiều nguồn, và có thêm người dùng mới (analyst, ML, khách hàng xem dashboard). Khi đó cần một data…
- Salesforce Công ty Thành viên
Cloud Atlas là kho dữ liệu định danh toàn cầu phía sau phần lớn việc xác thực của Salesforce, mục tiêu five nines. Năm 2026 họ bỏ rate limit theo từng instance (sai khi autoscale, không thấy tổng tải của khách) và tránh…
- Uber Công ty Thành viên
Một vòng đủ: monolith → microservices → tổ chức lại microservices. Năm 2012–2013 Uber có hai monolith; khi lên hàng trăm kỹ sư thì tách. Lý do chủ yếu là tổ chức. Năm 2015 họ có 500+ service và phải chuẩn hoá contract…