Link bài viết gốc： Cách xây dựng một AI agent: từ một prompt đến thiết lập production
Yarchi · X · @undefinedKi · 2026-10-10 21:25
Bài viết này được chia sẻ lại, bản quyền thuộc về tác giả gốc, toàn văn căn cứ theo link bài gốc
Coding agent của Stripe merge hơn 1.000 pull request mỗi tuần.
Tại Uber, hơn 70% pull request hiện nay đến từ agent.
Spotify đã merge hơn 2,5 triệu PR bảo trì tự động.
Không công ty nào trong số này sử dụng một AI agent đơn lẻ. Mỗi bên đều dùng một nhóm agent, mỗi agent được thiết kế riêng theo từng tác vụ: một model để review code, một model khác để điều tra sự cố hệ thống, và một model thứ ba để trả lời các câu hỏi về dữ liệu.
Tin tốt là họ đang chia sẻ về những điều này. Đội ngũ kỹ thuật tại Stripe, Uber, DoorDash, Shopify, Meta, Microsoft, Cloudflare và nhiều bên khác đã công bố thông tin về cách các agent của họ vận hành, bao gồm cả kiến trúc lẫn các chỉ số thực tế.
Tôi đã xem qua hơn 70 bài viết như vậy và phân loại chúng thành 10 kiểu thiết lập.
Với mỗi kiểu thiết lập, tôi đã chuẩn bị:
- Agent làm gì
- Nó được xây dựng như thế nào
- Ví dụ thực tế từ các công ty
- Bắt đầu từ đâu nếu bạn muốn tự xây dựng một cái cho riêng mình
Cuối bài là danh sách các repository chứa thiết lập agent có sẵn mà bạn có thể trực tiếp cài đặt.
Mọi agent được xây dựng như thế nào (How every agent is built)
Nếu bỏ qua các tính năng riêng biệt của từng thương hiệu, tất cả các agent được đề cập trong bài viết này về bản chất đều có chung một cốt lõi.
Hướng dẫn của OpenAI chia nó thành ba phần:
- Mô hình : LLM chịu trách nhiệm suy luận và ra quyết định
- Công cụ : các hàm và API mà nó có thể gọi
- chỉ thị liên quan nhất đến truy vấn của người dùng : các quy tắc về cách nó hành xử
Định nghĩa của Anthropic ngắn gọn hơn: Agent “thường chỉ là LLM sử dụng công cụ trong một vòng lặp dựa trên phản hồi từ môi trường.”
Model chỉ là phần nhỏ nhất. Thứ mà các công ty thực sự dành hàng tháng trời để xây dựng chính là mọi thứ bao quanh nó, tức phần harness:
- Vòng lặp : gọi model, chạy công cụ được yêu cầu, trả về kết quả, lặp lại
- Context và memory : những gì agent nhìn thấy trong lượt này, và những nội dung sẽ được giữ lại cho phiên tiếp theo
- Sandbox : một môi trường máy cô lập để chạy code mà không chạm vào bất kỳ hệ thống thực tế nào
- Truy cập công cụ : thường được triển khai qua MCP gateway, giúp xác định công cụ nào sẽ được dùng để thực thi từng tác vụ
- Guardrail : mặc định chỉ đọc, giới hạn chi tiêu, phê duyệt thủ công đối với các thao tác rủi ro
- xác minh : test, linter hoặc một agent thứ hai kiểm tra lại công việc trước khi bàn giao
Workflow hay agent (Workflow or agent)
Các hệ thống này được chia thành hai nhóm:
- workflow : model và công cụ chạy theo các luồng code được định nghĩa trước
- Agent : model tự quyết định các bước thực hiện và lệnh gọi công cụ
Trên thực tế, hầu hết các thiết lập production đều kết hợp cả hai. Stripe gọi đây là “bản thiết kế”: các bước cố định như lint và push, xen kẽ với các vòng lặp agent đòi hỏi khả năng phán đoán.
Năm mô hình (The five patterns)
Hầu như tất cả các thiết lập dưới đây đều được xây dựng dựa trên những mô hình này:
- Chuỗi prompt : mỗi bước xử lý kết quả của bước trước đó
- Định tuyến : phân loại dữ liệu đầu vào và chuyển đến bộ xử lý chuyên dụng
- song song hóa : chia nhỏ công việc thành nhiều phần, hoặc thực hiện cùng một tác vụ nhiều lần rồi so sánh kết quả
- Orchestrator / Worker : agent điều phối phân tách tác vụ, giao từng phần cho worker, rồi tổng hợp kết quả
- Evaluator / Optimizer : một agent tạo nội dung, agent còn lại phản biện và đánh giá, lặp lại như vậy cho đến khi kết quả được phê duyệt
Một agent hay nhiều agent (One agent or many)
Hãy bắt đầu bằng cách tối ưu hóa hiệu quả của một agent duy nhất trước. Chỉ cân nhắc chia tách chúng khi các chỉ dẫn trở nên quá lộn xộn hoặc các công cụ bắt đầu chồng chéo nhau.
Microsoft đã phải trả giá đắt cho bài học này. Phiên bản đầu tiên của Azure SRE agent có hơn 100 công cụ phạm vi hẹp và hơn 50 sub-agent chuyên biệt. Hệ thống liên tục gặp sự cố trong quá trình truyền dữ liệu giữa các thành phần. Theo chia sẻ của họ, bất kỳ chuỗi truyền tải nào vượt quá bốn bước gần như đều thất bại. Sau khi tái cấu trúc, cuối cùng họ chỉ giữ lại một vài agent đa năng và năm công cụ cốt lõi.
Vì vậy, quy tắc kinh nghiệm là: chỉ thêm agent thứ hai khi nó đảm nhận một công việc thực sự khác biệt, chẳng hạn như kiểm tra kết quả công việc của agent thứ nhất.
Setup 1: Background coding agent (Thiết lập 1: Agent lập trình chạy ngầm)
Vai trò của nó: Kỹ sư gửi tác vụ lên Slack hoặc tạo ticket, rời đi, và khi quay lại thì pull request đã sẵn sàng.
How it’s built: (Cách xây dựng:)
- Kích hoạt : tin nhắn Slack, ticket hoặc tác vụ định kỳ
- Sandbox : mỗi tác vụ được cấp một máy dev cô lập hoàn toàn mới, được pre-warm để khởi động chỉ trong vài giây
- workflow : kết hợp các bước cố định (kiểm tra code, push, tạo PR) với vòng lặp agent thực hiện viết code
- Bộ xác thực : tự động chạy kiểm tra định dạng, build và test trước khi bất kỳ PR nào được tạo
- Thủ công : chịu trách nhiệm review và merge, agent không bao giờ tự ý thực hiện
Who runs it: (Bên đang triển khai:)
Stripe, Minions. Hơn 1.000 PR được merge mỗi tuần, tất cả đều do agent viết từ đầu đến cuối. Mỗi lần chạy đều tuân theo “bản thiết kế” workflow được định nghĩa trong code, và lấy các công cụ cần thiết từ Toolshed (một MCP server nội bộ phục vụ hàng trăm agent truy cập).Nguồn: stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents
Spotify, Honk. Agent chỉ có thể xem code và gọi trình xác thực (validator). Stop hook sẽ kích hoạt mọi bước kiểm tra trước khi PR được mở. Sau đó, một LLM đóng vai trò giám khảo sẽ so sánh phần diff với tác vụ ban đầu; khoảng một phần tư số phiên bị từ chối do vượt quá phạm vi yêu cầu.Nguồn: engineering.atspotify.com/2025/12/feedback-loops-background-coding-agents-part-3
Shopify, River. Bạn gắn thẻ (@) river trong kênh Slack chung. Hiện tại cứ 8 PR được merge tại Shopify thì có một PR do nó đồng tác giả: 3.536 PR được đồng tác giả trong vòng 30 ngày.Nguồn: shopify.engineering/under-the-river
Bắt đầu từ đây: anthropics/claude-code-action . Nhắc đến @claude trong GitHub Issue hoặc PR, nó sẽ hoạt động trong GitHub Actions và mở PR giúp bạn.
Setup 2: Code review agent (Thiết lập 2: Agent review code)
Vai trò của nó: Review từng pull request trước khi con người xem xét, và chỉ giữ lại những nhận xét thực sự đáng đọc.
How it’s built: (Cách xây dựng:)
- Bộ điều phối : đọc diff và đánh giá mức độ rủi ro của nó
- Chuyên gia : các reviewer độc lập chịu trách nhiệm riêng về bảo mật, hiệu năng, chất lượng code và tài liệu, mỗi reviewer có prompt riêng
- xác minh : mọi phát hiện đều phải qua bước kiểm tra lần hai trước khi được đăng
- loại bỏ trùng lặp : các nhận xét trùng lặp được gộp thành một lượt review duy nhất
- Bao gồm : con người luôn có quyền ép merge (force merge)
Rủi ro càng cao, càng nhiều reviewer được huy động. Sửa lỗi chính tả thì không cần đến kiểm tra bảo mật.
Who runs it: (Bên đang triển khai:)
Cloudflare. Bộ điều phối chỉ định tối đa 7 reviewer chuyên trách tùy theo mức độ rủi ro. Trong vòng một tháng: đã thực hiện 131.246 lượt review trên 48.095 merge request, thời gian trung vị là 3 phút 39 giây, chi phí trung vị là $0,98. Các kỹ sư chỉ ghi đè quyết định của bot trên 0,6% số MR.Nguồn: blog.cloudflare.com/ai-code-review
DoorDash. Scout trưởng đánh dấu các khu vực đáng ngờ, hai reviewer chuyên gia kiểm tra chúng, và mỗi nhận xét đều phải trải qua giai đoạn phản biện trước khi đăng. Hơn 10.000 PR mỗi tuần. 60,2% các phát hiện mức độ nghiêm trọng cao dẫn đến thay đổi code, so với mức 46% từ công cụ của bên thứ ba trước đó của họ. Mỗi lượt review tốn khoảng $3.Nguồn: careersatdoordash.com/?p=15891
Uber, uReview. Ba generator tạo nhận xét, một chuyên gia đánh giá từng nhận xét để lọc bỏ các hạng mục giá trị thấp. 75% nhận xét được đánh giá là hữu ích, và hơn 65% thực sự được xử lý.Nguồn: uber.com/blog/ureview
Bắt đầu từ đây: garrytan/gstack với lệnh /review, hoặc obra/superpowers với kỹ năng review code.
Setup 3: Migration agent (Cấu hình 3: Migration agent)
Vai trò của nó: Đảm nhận một thay đổi lặp đi lặp lại cần thực hiện ở hàng nghìn vị trí (như thư viện test mới, API mới, gỡ bỏ flag hàm cũ) và áp dụng tất cả các thay đổi đó.
How it’s built: (Cách xây dựng:)
- tìm kiếm : Script hoặc công cụ tìm kiếm code liệt kê tất cả các file hoặc flag cần thay đổi
- phân phối : Mỗi file hoặc mỗi project tương ứng với một agent, chạy song song nhiều agent, mỗi agent nằm trong một Git worktree độc lập
- Cổng kiểm soát : Mỗi file phải vượt qua các bước kiểm tra cố định (test, lint, type check) và chỉ khi pass mới được đi tiếp
- Thử lại : Nếu / khi kiểm tra thất bại, thông báo lỗi cùng với thông tin cho lần thử tiếp theo sẽ được gửi ngược lại cho agent
- Thủ công : Review hàng loạt PR, sửa thủ công vài phần trăm nội dung còn lại
Chìa khóa nằm ở state machine. Agent không bao giờ tự quyết định khi nào hoàn thành, mà chính các bài test sẽ quyết định điều đó.
Who runs it: (Ai đang triển khai:)
Airbnb. Di chuyển khoảng 3.500 file test sang thư viện test mới. Mỗi file đều trải qua quy trình tái cấu trúc → test → lint → type check, nếu thất bại sẽ gửi phản hồi lỗi. 97% được hoàn thành tự động. Ước tính làm thủ công: 1,5 năm. Thực tế: 6 tuần.Nguồn: medium.com/airbnb-engineering/accelerating-large-scale-test-migration-with-llms-9565c208023b
Google. Sử dụng công cụ tìm kiếm code nội bộ để định vị từng vị trí, dùng Gemini đã được fine-tune để tạo diff, sau đó xác thực thông qua build và test. Trong một đợt migration ID, 80% thay đổi code được viết hoàn toàn bởi AI. Nâng cấp từ JUnit 3 lên 4: 5.359 file trong 3 tháng.Nguồn: arxiv.org/abs/2501.06972
DoorDash. Orchestrator chọn ra các feature flag lỗi thời và viết báo cáo để con người phê duyệt. Sau đó, mỗi repository có tối đa 4 agent dọn dẹp hoạt động trong các worktree song song. PR sẽ không được tạo cho đến khi test vượt qua và độ bao phủ dòng thay đổi đạt 95%. 45 trên tổng số 50 flag đã đạt trạng thái sẵn sàng merge, mỗi flag tiêu tốn $4,79 và 13,8 phút.Nguồn: careersatdoordash.com/blog/automating-feature-flag-cleanup-at-scale-with-a-multi-agent-llm-system
Bắt đầu từ đây: obra/superpowers trong dispatching-parallel-agents và using-git-worktrees kỹ năng.
Setup 4: On-call / SRE agent (On-call / SRE agent)
Chức năng： Tham gia xử lý sự cố ngay khoảnh khắc cảnh báo được kích hoạt, bắt đầu điều tra ngay khi con người vẫn còn đang mở laptop, và công bố các phát hiện của mình.
How it’s built: (Cách xây dựng:)
- Kích hoạt : Cảnh báo từ PagerDuty, Datadog hoặc kênh Slack xử lý sự cố
- Ưu tiên context : Trước khi model bắt đầu hoạt động, các kiểm tra tiền định sẽ kéo về thông tin các lần triển khai gần nhất, các thay đổi cấu hình, dashboard và các sự cố tương tự trong quá khứ
- Giả định : Điều tra song song nhiều nguyên nhân có thể xảy ra, mỗi nguyên nhân do một sub-agent riêng biệt phụ trách
- Quy tắc bằng chứng : Mỗi kết luận đều phải trỏ tới một truy vấn, dòng log hoặc biểu đồ cụ thể
- chỉ đọc : Agent có thể xem mọi thứ, nhưng không thể thay đổi bất kỳ điều gì
- Phê duyệt : Khởi động lại, rollback và khắc phục sự cố đều cần con người trực tiếp bấm nút xác nhận
Who runs it: (Ai đang triển khai:)
Microsoft, Azure SRE agent. Ban đầu có hơn 100 công cụ chuyên biệt và hơn 50 sub-agent, sau đó được tái cấu trúc xoay quanh một số ít agent đa năng có quyền truy cập CLI mở rộng và khả năng thực thi code (dùng để phân tích chỉ số). Trong 9 tháng, nó đã độc lập xử lý hơn 35.000 sự cố. Đối với một dịch vụ, thời gian giảm thiểu sự cố đã giảm từ mức trung bình 40,5 giờ của con người xuống còn 3 phút.Nguồn: techcommunity.microsoft.com/blog/appsonazureblog/context-engineering-lessons-from-building-azure-sre-agent/4481200
Ramp, OCA. Tham gia kênh sự cố, đăng bản cập nhật đầu tiên trong khoảng 5 phút và đăng báo cáo đầy đủ trong khoảng 13 phút. Chế độ chỉ đọc ở mọi nơi, các thao tác có tính phá hủy chỉ có thể thực hiện thông qua nút phê duyệt trên Slack. Trong bốn tuần, nó đã hỗ trợ xử lý 575 trong số 1.220 PR sửa lỗi sự cố, giảm 37% số lượng kỹ sư cần phải tham gia vào.Nguồn: builders.ramp.com/post/how-we-built-oca-our-ai-on-call-assistant
Meta. Mỗi kết luận đều phải trích dẫn truy vấn công cụ cụ thể và được kiến trúc hệ thống bắt buộc thực thi, do đó model không thể bịa đặt dữ liệu. Thời gian trung vị từ phát hiện đến giảm thiểu sự cố giảm từ 9,5 giờ xuống 3,8 giờ.Nguồn: atscaleconference.com/?p=1037753
Bắt đầu từ đây: Cookbook của OpenAI “ Xây dựng SRE agent phục vụ ứng phó sự cố ”. Rollback có kiểm soát phê duyệt, trạng thái điều tra được lưu trong thread Slack.
Setup 5: Security agent (Security agent)
Chức năng： Phân loại cảnh báo bảo mật, tìm kiếm lỗ hổng trong mã nguồn và soạn thảo phương án khắc phục, giúp đội ngũ bảo mật chỉ cần xử lý các vấn đề thực sự.
How it’s built: (Cách xây dựng:)
- Ưu tiên bằng chứng : Trước khi gọi bất kỳ model nào, code thông thường sẽ thu thập log, lưu lượng truy cập và context vào một package
- Chuyên gia : Các agent độc lập phân tích song song từ các góc độ khác nhau (traffic, context người dùng, thông tin tình báo về mối đe dọa)
- Hunter và Checker : Agent phát hiện vấn đề và agent xác thực vấn đề chạy trên các model khác nhau
- Kiểm tra trích dẫn trong code : Các phát hiện không có bằng chứng xác thực hỗ trợ sẽ bị loại bỏ
- Con người ra quyết định : Agent đưa ra đề xuất, PR được tạo dưới dạng bản nháp, con người phê duyệt biện pháp khắc phục
Who runs it: (Ai đang triển khai:)
Cloudflare. Vừa công bố trong tuần này. Trước khi bất kỳ model nào chạy, code sẽ xây dựng một gói bằng chứng có quản lý phiên bản. Bốn agent chuyên gia hoạt động song song, sau đó một agent tổng hợp sẽ soạn thông báo. Nó không thể tự ý lấy nội dung mới mà bắt buộc phải chọn từ bộ từ vựng đã được phê duyệt. Mỗi trích dẫn đều được code ứng dụng kiểm tra. Không có bằng chứng, không có kết luận.Nguồn: blog.cloudflare.com/agentic-security-operations
Figma. Một model chi phí thấp điều phối từng cảnh báo, một model mạnh hơn sử dụng Okta, Wiz và Panther để phân loại. Khi chuyên viên phân tích sửa lỗi cho nó, agent sẽ tự cập nhật tài liệu hướng dẫn của chính mình. PR của agent bị bắt buộc để ở chế độ draft. Kết quả: thời gian giải quyết nhanh hơn 71%, các cuộc gọi on-call giảm 20%.Nguồn: figma.com/blog/how-we-secure-figmas-internal-systems-with-agents
Shopify, Dispatch. Chia nhỏ mỗi ứng dụng thành nhiều phần, chạy song song các agent săn lỗ hổng trên từng phần, sau đó dùng các model khác nhau được chủ đích lựa chọn để xác minh phát hiện. Trong sáu tuần: phát hiện hơn 300 vấn đề trên hơn 80 ứng dụng, tương đương giá trị tiền thưởng bug bounty khoảng 400.000 USD. Một lần quét toàn diện tiêu tốn từ 50 đến 300 USD.Nguồn: shopify.engineering/building-an-agentic-harness-that-outlasts-the-model
Bắt đầu từ đây: trailofbits/skills , 42 plugin bảo mật từ Trail of Bits, dùng cho audit code, smart contract và reverse engineering.
Setup 6: Data analyst agent (Data analyst agent)
Chức năng： Bất kỳ ai trong công ty đều có thể đặt câu hỏi bằng ngôn ngữ tự nhiên thông thường (“Tại sao đơn hàng tuần trước ở Ohio lại giảm?”) và nhận được câu trả lời kèm theo truy vấn SQL.
How it’s built: (Cách xây dựng:)
- Tầng tri thức : Mô tả bảng dữ liệu, định nghĩa chỉ số, các truy vấn mẫu và quy tắc nghiệp vụ mà agent sẽ tìm kiếm trước tiên
- Truy xuất : Định vị đúng bảng trước khi viết bất kỳ câu lệnh SQL nào: model viết truy vấn, framework xác thực và thực thi truy vấn đó
- Quyền hạn : Truy vấn được thực thi bằng quyền truy cập của chính người dùng, vì vậy không ai có thể thấy dữ liệu mà họ không được phép xem
- Đánh giá : một tập hợp câu hỏi thực tế đã biết trước đáp án chính xác, được chạy lại sau mỗi lần thay đổi
- Phê duyệt : đối với các tác vụ phân tích nặng, agent sẽ trình bày kế hoạch trước và chờ sự đồng ý
Model ít quan trọng hơn bạn nghĩ. Phần lớn công việc nằm ở tầng tri thức.
Who runs it: (Ai đang triển khai:)
DoorDash, Vera. Bao phủ hơn 200.000 dataset. Các nguồn dữ liệu mới sẽ được giữ ở trạng thái đóng cho đến khi vượt qua ngưỡng đánh giá. Qua hơn 1.900 lượt đánh giá, tỷ lệ vượt qua tăng từ 43% lên 90%. Trên cùng một model, Vera đạt 2,60 điểm (thang điểm 3), trong khi Claude Code thông thường đạt 2,16 điểm, cho thấy framework đóng vai trò quyết định.Nguồn: careersatdoordash.com/blog/inside-vera-doordashs-data-agent
Notion, Data Scout. Ra mắt ngày 8 tháng 10. Các truy vấn chạy dưới thông tin xác thực Snowflake của riêng từng nhân viên. Định nghĩa được lưu trữ trong cơ sở dữ liệu Notion dùng chung, và agent chạy ban đêm có nhiệm vụ phát hiện các định nghĩa lỗi thời hoặc xung đột. Trong vòng hai tháng, số lượng yêu cầu gửi tới đội ngũ dữ liệu đã giảm khoảng 80%.Nguồn: notion.com/blog/how-we-built-a-personal-data-scientist-for-every-notion-employee
OpenAI. Agent dữ liệu nội bộ của họ xếp chồng 6 tầng context, từ tình hình sử dụng bảng cho đến tri thức tổ chức, đồng thời lưu lại memory mỗi khi người dùng sửa lỗi cho nó. Hệ thống phục vụ hơn 3.500 người dùng nội bộ trên hơn 600 PB dữ liệu.Nguồn: openai.com/index/inside-our-in-house-data-agent
Bắt đầu từ đây: anthropics/knowledge-work-plugins trong data plugin .
Setup 7: Customer support agent (Agent hỗ trợ khách hàng)
Chức năng： Trả lời câu hỏi của khách hàng và nhân viên hỗ trợ, giải quyết các vấn đề trong khả năng, và chuyển tiếp các vấn đề còn lại kèm theo context đã thu thập cho con người xử lý.
How it’s built: (Cách xây dựng:)
- Router : một model nhỏ và tiết kiệm chi phí sẽ đọc yêu cầu và quyết định điều hướng nó đi đâu
- Bậc thang chi phí : các truy vấn đơn giản chạy bằng code thông thường, câu hỏi thường gặp đi qua RAG, chỉ các trường hợp phức tạp mới chuyển đến agent hoàn chỉnh
- Chuyên gia : các sub-agent độc lập xử lý riêng việc hoàn tiền, tài khoản, giao hàng, mỗi sub-agent sở hữu công cụ riêng
- Guardrail : mỗi câu trả lời trước khi gửi đi đều được kiểm tra về chính sách, ảo giác và rò rỉ dữ liệu
- Giám khảo : mỗi ngày có một LLM chấm điểm các mẫu hội thoại thực tế
- Chuyển giao : leo thang lên cho con người xử lý khi độ tin cậy thấp hoặc thao tác tiềm ẩn rủi ro
Who runs it: (Ai đang triển khai:)
Lyft. Một meta-agent điều hướng yêu cầu tới các sub-agent, một số được xây dựng thủ công, một số được tạo dựa trên cấu hình JSON. Mỗi lượt hội thoại đều chạy kiểm tra an toàn, LLM judge sẽ rà soát các trace mẫu trong production. Thời gian xây dựng một agent hỗ trợ mới được rút ngắn từ khoảng 6 tháng xuống còn khoảng 2 tuần. Tỷ lệ giải quyết bằng AI tăng 16%.Nguồn: langchain.com/blog/lyft-built-a-self-serve-ai-agent-platform-for-customer-support-with-langgraph-and-langsmith
DoorDash. Hệ thống hỗ trợ tài xế giao hàng dựa trên RAG từ các ca đã giải quyết trước đây, sau đó có hai lớp guardrail và một LLM judge chấm điểm cho từng câu trả lời. Ảo giác giảm 90%, các vấn đề tuân thủ nghiêm trọng giảm 99%.Nguồn: careersatdoordash.com/blog/large-language-modules-based-dasher-support-automation
Coinbase, CEEcil. Một model nhỏ chọn hướng định tuyến, bộ xử lý tất định đưa ra câu trả lời trong vòng một đến hai giây, chỉ những câu hỏi mở mới được chuyển đến agent hoàn chỉnh. Nó có thể tạo PR để sửa lỗi nhưng không bao giờ tự merge chúng.Nguồn: coinbase.com/blog/ceecil-engineering-a-support-teammate-with-human-memory
Bắt đầu từ đây: customer-support-agent hướng dẫn bắt đầu nhanh, nằm tại anthropics/claude-quickstarts.
Setup 8: Research agent (Agent nghiên cứu)
Chức năng: Tiếp nhận một câu hỏi khái quát, đồng thời tìm kiếm trên hàng chục nguồn và trả về một báo cáo trong đó mỗi luận điểm đều kèm theo trích dẫn.
How it’s built: (Cách xây dựng:)
- Lead agent : lập kế hoạch nghiên cứu và lưu kế hoạch vào memory để duy trì xuyên suốt quá trình chạy dài
- Worker song song : các sub-agent, mỗi sub-agent tìm kiếm theo một góc nhìn trong context độc lập, sạch sẽ của riêng mình
- Nén : mỗi worker chỉ trả về một bản tóm tắt ngắn thay vì toàn bộ nội dung nó đã đọc
- Lượt trích dẫn : một agent riêng biệt ở bước cuối cùng sẽ khớp từng luận điểm với nguồn tương ứng
- Chi phí : đây là thiết lập tiêu tốn nhiều token nhất trong danh sách này, chỉ dùng cho các bài toán đáng để đầu tư chi phí
Who runs it: (Ai đang triển khai:)
Anthropic. Tính năng nghiên cứu trong Claude: một lead Opus sinh ra các sub-agent Sonnet để tìm kiếm song song, sau đó một agent trích dẫn sẽ hoàn thiện báo cáo. Trong các đánh giá nội bộ của họ, thiết lập này đạt hiệu quả cao hơn 90,2% so với một agent Opus đơn lẻ. Điểm trừ là: lượng token tiêu thụ gấp khoảng 15 lần so với đoạn chat thông thường, và riêng mức sử dụng token đã giải thích cho 80% sự khác biệt về hiệu năng.Nguồn: anthropic.com/engineering/multi-agent-research-system
Harvey. Rà soát hợp đồng pháp lý dựa trên playbook của công ty. Mỗi quy tắc tương ứng một sub-agent, hàng chục sub-agent chạy song song, mỗi sub-agent chỉnh sửa một nhánh tài liệu của riêng mình. Một bước điều phối tương tự như git sẽ merge các chỉnh sửa và báo cáo xung đột lên cấp trên. Chất lượng redlining tăng từ 53% lên 87%, đánh đổi bằng độ trễ tăng thêm 47%.Nguồn: harvey.ai/blog/rebuilding-playbook-review-as-a-multi-agent-system
Perplexity. Deep Research hiện chạy song song hàng nghìn bước truy xuất, model tự viết code để kết hợp các tìm kiếm của mình. Điểm BrowseComp tăng từ 40,7% lên 83,8%.Nguồn: perplexity.ai/hub/deep-research
Bắt đầu từ đây: assafelovic/gpt-researcher , gồm một planner, execution agent và một publisher chuyên viết báo cáo cuối cùng.
Setup 9: Knowledge agent (second brain) (Agent tri thức (bộ não thứ hai))
Chức năng: Nắm bắt những gì chuyên gia biết — những điều chưa từng được ghi chép lại — và cung cấp chúng cho mọi agent cũng như từng nhân viên mới.
How it’s built: (Cách xây dựng:)
- File tri thức : các ghi chú ngắn gọn, có cấu trúc (file quan trọng, quy tắc, pattern không hiển nhiên), thay vì những tài liệu khổng lồ
- Builder : agent đọc code, tài liệu và các quyết định trước đây để viết các ghi chú này
- Critic : các agent khác sẽ đánh giá ghi chú trước khi chúng được lưu
- Quy tắc memory : trừ khi có yếu tố xác nhận lại, nếu không các sự kiện sẽ hết hạn và các xung đột sẽ bị gắn cờ
- Tự cải tiến : khi câu trả lời sai, hệ thống tìm phần còn thiếu, phác thảo phương án khắc phục và kiểm thử lại với các trường hợp cũ trước khi lưu
Mục tiêu là một chiếc la bàn chứ không phải một cuốn bách khoa toàn thư. Meta giới hạn mỗi file ở mức khoảng 1.000 token.
Ai đang triển khai:
Meta, tri thức nội bộ. Hơn 50 agent (explorer, analyst, writer, critic) lập bản đồ hơn 4.100 file pipeline dữ liệu vào 59 file context. Độ bao phủ context của AI tăng từ khoảng 5% lên 100%, lượng tool call của agent trên mỗi tác vụ giảm 40%.Nguồn: engineering.fb.com/2026/04/06/developer-tools/how-meta-used-ai-to-map-tribal-knowledge-in-large-scale-data-pipelines
Meta, bộ não thứ hai của tổ chức. Hơn 200 file tri thức kết hợp cùng các "công thức" chỉ chứa phương pháp mà không chứa sự kiện cụ thể. Khi xảy ra sai sót, sub-agent sẽ soạn phương án sửa lỗi, một agent đối kháng sẽ rà soát lại và chạy thử nghiệm lại các ca cũ trước khi phát hành. Lượng token cho mỗi câu hỏi giảm khoảng 80%, công việc vốn mất nhiều ngày của chuyên gia được rút ngắn xuống còn vài phút.Nguồn: engineering.fb.com/2026/09/02/ml-applications/organizational-second-brain-ai-learns-from-experts
Notion, Lore. Memory chia sẻ được xây dựng cho các agent, dưới dạng năm database Notion liên kết với nhau. Trừ khi được củng cố, các dữ kiện sẽ hết hạn. Agent có memory đã vượt qua 102 trên 149 kịch bản kiểm thử, trong khi agent không có memory chỉ vượt qua 82 kịch bản.Nguồn: notion.com/blog/building-shared-memory-for-ai-agents-in-notion
Bắt đầu từ đây: /undefined-ui/second-brain-os
Setup 10: Scheduled automation agent (Agent tự động hóa theo lịch trình)
Chức năng của nó: Thức dậy theo lịch trình, kiểm tra các nguồn của bạn, chỉ thông báo cho bạn những gì đã thay đổi và những gì cần bạn can thiệp. Hoàn toàn không cần prompt.
How it’s built: (Cách xây dựng:)
- Lịch : một cron job khởi động một session hoàn toàn mới trong mỗi lần chạy
- Nguồn : quyền truy cập chỉ đọc (read-only), thông tin xác thực được lưu trong vault bên ngoài agent
- Dấu trang : agent ghi nhớ vị trí nó đã dừng lại ở từng nguồn, thay vì đọc nội dung của "24 giờ qua"
- Memory chia làm hai phần : các thiết lập ưu tiên do bạn viết, và trạng thái mà agent tự lưu giữ cho chính nó
- Xuất bản an toàn : kiểm tra xem báo cáo hôm nay đã tồn tại chưa, chỉ được tính là đã gửi sau khi phía đích xác nhận
- Ngân sách : giới hạn chi phí cho mỗi lần chạy, để vòng lặp bị kẹt không làm bạn "đốt tiền"
Ai đang vận hành:
Anthropic. “Tại Anthropic, tự động hóa agent đơn giản được sử dụng rất thường xuyên.” Bản tóm tắt hàng ngày tham khảo của họ chạy trên Managed Agents vào mỗi sáng ngày làm việc, đọc Slack và GitHub từ bookmark của từng nguồn, báo cáo các nguồn bị lỗi là không thể đọc thay vì coi đó là một ngày yên ắng, và mỗi lần chạy có giới hạn chi phí tối đa 5 USD.Nguồn: claude.dev/blog/building-effective-agent-automations
GitHub. Agent workflow được viết bằng Markdown và biên dịch thành GitHub Actions theo lịch trình hàng ngày. Mặc định ở chế độ chỉ đọc, chỉ ghi thông qua các "safe output" đã được phê duyệt, pull request không bao giờ được tự động merge. GitHub Next cho biết, họ "hầu như mỗi ngày đều phát hiện ra công dụng mới của agent workflow".Nguồn: github.blog/ai-and-ml/automate-repository-tasks-with-github-agentic-workflows
Microsoft. Azure SRE agent cũng có thể chạy theo các tác vụ định lịch. Cùng một agent đó đạt điểm đánh giá 4.5/5 đối với các tác vụ định lịch, nhưng chỉ đạt 1.7/5 khi xử lý sự cố thông qua các kế hoạch ứng phó diện rộng. Những công việc phạm vi hẹp, có tính lặp đi lặp lại mới chính là nơi agent tỏa sáng.Nguồn: techcommunity.microsoft.com/t5/apps-on-azure-blog/getting-the-best-out-of-azure-sre-agent/ba-p/4559745
Bắt đầu từ đây: managed-agents/daily-brief nằm tại anthropics/claude-quickstarts . Trong cùng thư mục đó còn có một ví dụ phân loại Sentry theo tác vụ định lịch.
What every setup has in common (Điểm chung của mọi setup)
Mười công việc khác nhau, mười công ty khác nhau, nhưng những quy tắc tương tự lại liên tục lặp lại:
- Checker độc lập. Agent thực thi công việc không bao giờ tự chấm điểm cho mình. Spotify sử dụng LLM judge, DoorDash áp dụng quy trình xác minh "phản bác nó", còn Shopify sử dụng một model hoàn toàn khác.
- Code đi trước model. Trước tiên hãy dùng code thông thường để lấy dữ liệu, chạy kiểm tra và thu thập bằng chứng. Model chỉ phụ trách phần đòi hỏi khả năng phán đoán.
- Mặc định chỉ đọc. Bất kỳ thao tác nào làm thay đổi thế giới thực đều phải qua con người: PR bản nháp, nút phê duyệt, ký duyệt kế hoạch.
- Mọi kết luận đều phải có bằng chứng. Mọi kết luận không có dòng log, câu query hoặc nguồn chứng minh hỗ trợ đều sẽ bị loại bỏ.
- Phân quyền tối thiểu cho mỗi tác vụ. Mỗi tác vụ chỉ nhận đúng các công cụ mà nó cần, không cấp thừa.
- Test case thực tế. Các sự cố, issue, PR trong quá khứ được replay sau mỗi lần thay đổi.
Áp dụng đúng sáu nguyên tắc này, bất kỳ setup nào ở trên cũng có thể đứng vững trước thử thách.
Where to start (Bắt đầu từ đâu)
Đừng xây dựng cả mười loại cùng một lúc. Hãy chọn cái phù hợp nhất với điều khiến bạn đau đầu nhất trong tuần này:
- Ngập trong hàng tá ticket nhỏ: background coding agent
- PR chờ nhiều ngày không ai review: code review agent
- Một thay đổi cần thực hiện ở 500 nơi: migration agent
- Bị đánh thức bởi cảnh báo: on-call agent
- Ngày nào cũng gặp các câu hỏi dữ liệu giống nhau: data analyst agent
- Ngày nào cũng gặp các thắc mắc khách hàng giống nhau: support agent
- Mỗi sáng phải kiểm tra năm công cụ: tự động hóa theo lịch trình
Hãy bắt đầu từ phạm vi hẹp, chế độ chỉ đọc, cộng thêm một checker. Mọi công ty trong bài viết này đều khởi đầu như vậy: một tác vụ nhàm chán, đo lường trước, rồi mới làm tiếp tác vụ sau.
Model là phần đơn giản nhất. Setup xoay quanh nó mới chính là mấu chốt để hệ thống vận hành trơn tru.
Học tương tác với AI (NotebookLM)
Ngoài đọc , bạn có thể nghe , xem và xem hoạ thông tin ở đầu bài. Bài này còn có bộ công cụ tương tác do AI tạo: Bài kiểm tra trắc nghiệm, Thẻ ghi nhớ, Sơ đồ tư duy, Bản trình bày và Báo cáo chuyên sâu.
Mở không gian học tương tác