2 điểm bởi GN⁺ 1 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Một mô hình mới đang xuất hiện, nơi các tác nhân AI tự vận hành trong nhiều ngày đến nhiều tuần thay vì chỉ trong một phiên chat đơn lẻ, di chuyển qua nhiều cửa sổ ngữ cảnh và sandbox, phục hồi sau lỗi và tiếp tục từ điểm bị gián đoạn
  • Các tác nhân hiện tại vấp phải những giới hạn cấu trúc của một phiên đơn lẻ như cạn cửa sổ ngữ cảnh, quá tự tin vào tự đánh giá, và tái đưa vào các sửa đổi trước đó
  • Các công ty lớn như Anthropic, Google, Cursor đang hội tụ về kiến trúc tách biệt vòng lặp mô hình·sandbox thực thi·log phiên
  • Thách thức cốt lõi của tác nhân chạy dài hạn là quản lý trạng thái bền vững, tự kiểm chứng, nén ngữ cảnh, và bài viết đưa ra năm mẫu thiết kế để giải quyết
  • Thay vì chính mô hình, lớp trạng thái·phiên·handoff có cấu trúc bao quanh mô hình mới là khu vực đầu tư then chốt tạo ra khác biệt về năng suất thực tế

Ba ý nghĩa của "chạy dài hạn"

  • Long-horizon reasoning: khả năng lập kế hoạch và thực thi qua nhiều bước phụ thuộc lẫn nhau, chủ yếu là vấn đề chất lượng mô hình. Theo chỉ số time horizon của METR, thời lượng công việc mà các mô hình frontier có thể hoàn thành với độ tin cậy 50% đã tăng gấp đôi khoảng mỗi 7 tháng kể từ năm 2019; nếu xu hướng này tiếp tục, đến năm 2028 có thể hoàn thành công việc tính theo ngày, và đến năm 2034 là công việc tính theo năm
  • Long-running execution: cấu trúc trong đó tiến trình tác nhân chạy từ nhiều giờ đến nhiều ngày, và mô hình có thể được gọi hàng nghìn lần, chủ yếu là vấn đề thiết kế harness
  • Persistent agency: dạng mà tác nhân duy trì danh tính vượt ra ngoài một tác vụ đơn lẻ, tích lũy bộ nhớ và học các sở thích người dùng. Memory Bank của Google là ví dụ tiêu biểu
  • Các tác nhân sản xuất thực tế thường kết hợp cả ba, nhưng bài toán kỹ thuật và cách giải của từng loại là khác nhau

Vì sao tác nhân chạy dài hạn quan trọng

  • Tác nhân chạy 10 phút chỉ phù hợp cho trả lời câu hỏi hoặc sửa lỗi nhỏ, nhưng tác nhân chạy 10 giờ có thể phát triển trọn vẹn một tính năng, hoàn tất các migration bị tồn đọng suốt 6 quý, hoặc thực hiện nghiên cứu ở cấp độ chuyên viên phân tích junior
  • Trong công bố về Claude Sonnet, Anthropic đã tiết lộ trường hợp coding tự trị hơn 30 giờ theo bài kiểm tra nội bộ, tạo ra một ứng dụng kiểu Slack với quy mô 11.000 dòng chỉ trong một lần chạy
  • Trong Project Vend, một instance Claude đã vận hành doanh nghiệp máy bán hàng tự động tại văn phòng trong một tháng thực tế, phụ trách quản lý tồn kho, định giá và liên lạc với nhà cung cấp. Giai đoạn đầu tạo ra các ví dụ thất bại có ý nghĩa, và giai đoạn hai đã cải thiện đáng kể
    • Điểm mấu chốt không phải lợi nhuận, mà là quan sát các vấn đề về tính nhất quán phát sinh khi tác nhân duy trì danh tính theo tuần thay vì theo lượt

Ba bức tường mà mọi tác nhân chạy dài hạn đều va phải

  • Ngữ cảnh hữu hạn: ngay cả cửa sổ 1M token rồi cũng sẽ cạn, và trước khi đầy cửa sổ thì context rot (suy giảm dần hiệu năng mô hình) đã xuất hiện. Việc chạy 24 giờ hiện chưa phù hợp với bất kỳ roadmap cửa sổ ngữ cảnh nào
  • Thiếu trạng thái bền vững: phiên mới bắt đầu từ trạng thái trắng. Anthropic ví điều này như một kỹ sư vào ca mà hoàn toàn không biết điều gì đã xảy ra ở ca trước
  • Thiếu tự kiểm chứng: khi mô hình tự đánh giá công việc của mình, nó liên tục có thiên lệch tích cực. Với câu hỏi "Đã xong chưa?", nó trả lời "có" thường xuyên hơn thực tế; nếu không có tín hiệu xác minh riêng, nó có thể nộp kết quả với sự tự tin tuyệt đối dù mới hoàn thành khoảng 30%

Vòng lặp Ralph: cách triển khai đơn giản cho tác nhân chạy dài hạn dành cho người làm thực tế

  • Ralph loop (kỹ thuật Ralph Wiggum) là mẫu tác nhân chạy dài hạn dành cho người thực hành do Geoffrey Huntley và Ryan Carson phổ biến, với triển khai tham chiếu chỉ gồm một script bash
  • Trình tự hoạt động: chọn tác vụ chưa hoàn thành (prd.json) → dựng prompt từ tác vụ·ngữ cảnh·ghi chú → gọi tác nhân → chạy test → ghi kết quả vào progress.txt → cập nhật danh sách tác vụ → lặp lại
  • Nguyên lý cốt lõi: bản thân tác nhân bị mất trí nhớ nhưng hệ thống tệp giữ lại ký ức. prd.json đóng vai trò kế hoạch, progress.txt là sổ tay phòng thí nghiệm, và AGENTS.md là sổ quy tắc cuốn chiếu
  • Compound Product của Ryan Carson xâu chuỗi nhiều loop theo dạng loop phân tích (đọc báo cáo hằng ngày) → loop lập kế hoạch (tạo PRD) → loop thực thi (viết code), đây là phiên bản mã nguồn mở của cấu trúc ba lớp planner-generator-evaluator mà Anthropic cũng đi tới một cách độc lập
  • Chỉ với script bash và file JSON có thể dựng một tác nhân chạy dài hạn hoạt động qua đêm. Điều Google và Anthropic sản phẩm hóa là biến mẫu này thành thứ có thể phục hồi, an toàn và quan sát được

Anthropic: từ harness sang tách Brain/Hands/Session

  • Cách tiếp cận đầu tiên (cấu trúc harness): harness 2 tác nhân cho phát triển full-stack tự trị. Initializer agent thiết lập môi trường ban đầu của dự án, mở rộng prompt thành feature-list.json, và viết script khởi động (init.sh). Coding agent thức dậy lặp đi lặp lại để xử lý theo từng tính năng, chạy test, ghi claude-progress.txt, rồi commit
    • Quy tắc test ratchet: "Không được phép xóa hoặc sửa test" — nhằm ngăn lỗi phổ biến khi tác nhân xóa test đang fail để khiến mọi thứ pass
    • Ở bản mở rộng của InfoQ, cấu trúc này phát triển thành bộ ba planner, generator, evaluator. Lý do việc tách phần sinh và phần đánh giá quan trọng là vì mô hình quá dễ dãi khi tự chấm công việc của mình
  • Cách tiếp cận thứ hai (tách Brain/Hands/Session): kiến trúc của Claude Managed Agents (ra mắt vào đầu tháng 4 năm 2026)
    • Brain: mô hình và vòng lặp harness
    • Hands: môi trường thực thi tạm thời được sandbox hóa nơi các công cụ thực sự chạy
    • Session: log sự kiện chỉ-ghi-thêm (append-only) của toàn bộ suy nghĩ, lời gọi công cụ và quan sát
  • Cách đóng khung cốt lõi của Anthropic: "mọi thành phần trong harness đều mã hóa các giả định về thứ mà mô hình không thể tự làm"; nếu gắn chặt với nhau thì khi giả định lỗi thời phải thay cả hệ thống, còn khi tách ra thì harness trở nên stateless và sandbox có thể được xem như cattle (vật phẩm tiêu hao)
  • Container mới có thể gọi wake(sessionId) để tái dựng trạng thái từ log. time-to-first-token giảm khoảng 60% ở p50 và hơn 90% ở p95 — nhờ có thể bắt đầu suy luận trước khi sandbox sẵn sàng
  • Khái niệm session-event-log là phần bị đánh giá thấp nhất. Đây là chìa khóa khiến tác nhân chạy dài hạn có thể phục hồi. Không có nó, lỗi container đồng nghĩa lỗi phiên
  • Stack cho tính toán khoa học: CLAUDE.md (kế hoạch sống mà tác nhân học và chỉnh sửa), CHANGELOG.md (sổ tay thí nghiệm có thể di chuyển), tmux + SLURM + git (lớp thực thi·điều phối), Ralph loop (xác nhận lại khi có tuyên bố hoàn thành)
    • Trường hợp tiêu biểu: Claude Opus đã xây dựng Boltzmann solver trong nhiều ngày, đạt sai số dưới 1% so với triển khai tham chiếu CLASS. Nén khối lượng công việc vốn cần nhiều tháng đến nhiều năm của nhà nghiên cứu

Cursor: cấu trúc Planner, Worker, Judge

  • Quá trình mở rộng coding tự trị dài hạn của Cursor trải qua ba vòng lặp thiết kế
    • Lần thứ nhất (điều phối phẳng): các tác nhân ngang hàng ghi vào file dùng chung bằng lock → phát sinh nút thắt, tác nhân trở nên né rủi ro và dẫn tới churning (cứ lặp lại mà không commit)
    • Lần thứ hai (kiểm soát đồng thời lạc quan): gỡ được nút thắt nhưng chưa giải quyết được bài toán điều phối
    • Lần thứ ba (production hiện tại): Planner (khám phá codebase·tạo tác vụ, có thể spawn đệ quy sub-planner), Worker (thực thi tập trung, làm việc độc lập không cần điều phối lẫn nhau), Judge (phán định vòng lặp đã hoàn tất hay chưa và quyết định khởi động lại)
  • Phát hiện then chốt: "một phần đáng kinh ngạc của hành vi hệ thống bị chi phối bởi prompt hơn là harness hay mô hình"
  • Ghép mô hình-vai trò cũng là một phần của bề mặt thiết kế: các mô hình GPT tốt hơn Opus trong các tác vụ tự trị kéo dài. Opus có xu hướng dừng sớm và chọn đường tắt. Cùng một tác vụ, vai trò khác nhau, mô hình khác nhau
  • Composer 2 (mô hình coding frontier độc quyền) và background cloud agent: các tác vụ dài hạn chạy trên hạ tầng đám mây của Anysphere thay vì máy cục bộ. Refactor 8 giờ và migration trên toàn bộ codebase vẫn tiếp tục ngay cả khi đóng laptop
    • Có thể bắt đầu cục bộ rồi chuyển lên cloud nếu ước tính mất hơn 30 phút, sau đó kết nối lại từ thiết bị di động
    • Mỗi tác nhân chạy trong một git worktree cô lập và được hợp nhất qua PR
  • Cấu trúc cuối cùng tương tự Anthropic: tách vai trò, duy trì phiên, đặt judge cạnh worker, và các tác vụ dài hạn được điều phối dựa trên git trong sandbox cloud

Google: tác nhân chạy dài hạn của Agent Platform

  • Tại Cloud Next '26, Google hợp nhất Vertex AI thành Gemini Enterprise Agent Platform, biến tác nhân chạy dài hạn từ ý tưởng thành sản phẩm chính thức có SLA rõ ràng
  • Agent Runtime: hỗ trợ "tự vận hành trong nhiều ngày", cold start dưới một giây, cấp phát sandbox theo nhu cầu. Ví dụ use case: chuỗi prospecting bán hàng kéo dài một tuần
  • Agent Sessions: lưu bền lịch sử hội thoại và sự kiện. Có thể ánh xạ session ID tùy chỉnh với bản ghi CRM hoặc DB để lưu trạng thái tác nhân cùng với trạng thái kinh doanh
  • Agent Memory Bank: lớp bộ nhớ dài hạn đã GA tại thời điểm Next '26. Có thể tuyển chọn ký ức từ phiên, scope theo user ID và cung cấp API tìm kiếm. Trong trường hợp của Payhawk, tác nhân dùng Memory Bank đã rút ngắn hơn 50% thời gian nộp chi phí
  • Agent Sandbox (thực thi code tăng cường), Agent-to-Agent Orchestration, Agent Registry, Agent Identity, Agent Gateway, Agent Observability, Agent Simulation... bao phủ gần như mọi mối quan tâm cần thiết để vận hành production. Bao gồm cả ID được mã hóa và audit log mà doanh nghiệp cần
  • Về mặt kiến trúc, đây là cùng một cấu trúc với việc Anthropic tách brain/hands/session nhưng được sản phẩm hóa ở quy mô nền tảng, đi kèm ADK (bộ công cụ phát triển code-first) và Agent Studio (công cụ trực quan). Điều trước đây phải tự xây trong 3 năm nay đã trở thành câu hỏi "mượn phiên bản tách brain/hands/session nào"

Năm mẫu cho tác nhân chạy dài hạn trong production

  • Checkpoint-and-resume: lỗi nhiều ngày phổ biến nhất là mất ngữ cảnh. Nếu xử lý 200 tài liệu rồi lỗi ở tài liệu thứ 201 thì không có checkpoint sẽ phải chạy lại từ đầu. Hãy xem tác nhân như một tiến trình server dài hạn: ghi trạng thái trung gian xuống đĩa, checkpoint sau mỗi N đơn vị công việc, và phục hồi khi lỗi. Điểm then chốt là chọn granularity checkpoint phù hợp (không phải mỗi bước nhưng cũng không phải chỉ ở cuối)
  • Delegated approval (human-in-the-loop): cách triển khai cũ là serialize trạng thái ra JSON → webhook → chờ phản hồi, nhưng sẽ gặp vấn đề trạng thái stale và thông báo bị chìm. Trong runtime dài hạn, tác nhân có thể tạm dừng mà vẫn giữ nguyên chuỗi suy luận, working memory, lịch sử công cụ và toàn bộ hành động đang chờ. Trong thời gian con người xem xét, không tiêu tốn compute, rồi tiếp tục với độ trễ dưới một giây. Mission Control của Google đóng vai trò hộp thư cho việc này
  • Memory-layered context: tác nhân chạy 7 ngày cần nhiều hơn trạng thái phiên. Memory Bank (bộ nhớ dài hạn được tuyển chọn) + Memory Profiles (tra cứu độ trễ thấp). Chế độ lỗi trong production là memory drift — tác nhân học các đường tắt thủ tục từ tương tác phi cấu trúc rồi áp dụng rộng khắp. Cần quản trị bộ nhớ như một microservice. Agent Identity (quyền đọc/ghi), Agent Registry (theo dõi phiên bản tác nhân), Agent Gateway (áp chính sách)
  • Ambient processing: tác nhân phản ứng với sự kiện từ stream Pub/Sub hoặc bảng BigQuery mà không trò chuyện trực tiếp với con người (kiểm duyệt nội dung, phát hiện bất thường, phân loại inbox). Nếu không hardcode chính sách trong tác nhân mà định nghĩa ở Gateway, có thể áp thay đổi chính sách cho hàng trăm tác nhân mà không cần redeploy
  • Fleet orchestration: trong hệ thống thực tế, không phải một tác nhân đơn lẻ mà là một coordinator phân việc con cho các chuyên gia (Lead Researcher Agent, Scoring Agent, Outreach Agent). Mỗi chuyên gia có Identity riêng (Outreach Agent không thể truy cập dữ liệu tài chính dùng cho Scoring), chính sách riêng và mục Registry riêng. ADK xử lý việc này theo cách khai báo bằng workflow dựa trên đồ thị
  • Các mẫu có thể kết hợp. Ví dụ một hệ thống compliance: checkpointing cho xử lý tài liệu + delegated approval ở cổng review + memory layering cho tri thức giữa các phiên + fleet orchestration cho điều phối chuyên gia

Cách xây dựng trong thực tế

  • Nhà phát triển muốn công việc coding dài hạn trong repo riêng: dùng Claude Code, Antigravity, Cursor, Codex... Quản lý AGENTS.md như checklist của phi công (ngắn gọn, chỉ gồm các mục rút ra từ thất bại thực tế). Thêm hook typecheck và lint, tạo file kế hoạch trước khi bắt đầu, và khi tác nhân tuyên bố hoàn tất thì xác nhận lại bằng Ralph loop. Với các tác vụ kéo dài nhiều giờ hoặc qua đêm, chạy trong worktree để vẫn tiếp tục khi đóng laptop, và commit theo từng đơn vị công việc có ý nghĩa. Đây là con đường đòn bẩy cao nhất với đa số mọi người
  • Xây sản phẩm tác nhân được host: đừng tự xây runtime nếu không cần, hãy chọn managed. Hiện có 3 lựa chọn thực tế: Google Agent Platform (Agent Engine + Memory Bank + Sessions), Claude Managed Agents, hoặc self-host trên ADK·Claude Agent SDK·Codex SDK. Managed mặc định cung cấp tách brain/hands/session, khả năng quan sát, identity và audit trail. Self-host cho quyền kiểm soát và khả năng dùng mô hình đặc thù
  • Công việc tự trị·vận hành (monitoring, research, operations): cần persistence kiểu Memory Bank. ADK + Memory Bank + Cloud Run + Cloud Scheduler là stack gọn gàng nhất cho bài toán "chạy tác nhân mỗi N giờ, tích lũy trạng thái, cảnh báo khi vượt ngưỡng"

Những thực hành cốt lõi bất kể đi theo con đường nào

  • Viết rõ điều kiện hoàn thành trước khi khởi động tác nhân: đây là đòn bẩy lớn nhất trong vận hành dài hạn. Viết tiêu chí hoàn thành rõ ràng, có thể kiểm thử, trong một file ngoài → ngăn tác nhân tự định nghĩa lại "hoàn thành" trong lúc chạy
  • Tách evaluator và generator: tự chấm điểm là chế độ lỗi cốt lõi. Pipeline planner/worker/judge hoặc cặp generator/evaluator không phải phong cách mà là mẫu kiến trúc thực sự. Ngay cả cùng một mô hình cũng phải tách vai trò và prompt
  • Đầu tư vào session log chứ không phải prompt: log sự kiện chỉ-ghi-thêm giúp tác nhân có thể phục hồi, debug và audit. Nếu bạn không thể tái dựng 24 giờ hoạt động vừa qua của tác nhân từ persistent storage, thì đó chỉ là một shell script dài hạn gọi LLM
  • Xem nén và reset ngữ cảnh là công dân hạng nhất: Anthropic nhận thấy chỉ nén bằng tóm tắt là không đủ cho tác vụ rất dài; harness cần tháo rời hoàn toàn phiên và tái dựng từ file handoff có cấu trúc. Về bản chất, điều này giống hệt cách onboarding một kỹ sư mới

Các giới hạn thực tế hiện nay

  • Chi phí: chạy 24 giờ bằng các mô hình frontier rất tốn kém. Nếu không có ngân sách, circuit breaker và hard cap cho chi tiêu công cụ, chỉ một buổi chiều cũng có thể đốt sạch ngân sách API của cả tuần
  • Bảo mật: tác nhân chạy dài hạn có API key, quyền truy cập cloud và quyền chạy lệnh shell có bề mặt tấn công rộng hơn nhiều so với một phiên chat. Vì vậy mẫu tách brain/hands rất quan trọng — cần giữ cho sandbox nơi code do mô hình sinh ra được thực thi không thể truy cập credential
  • Alignment drift: qua nhiều cửa sổ ngữ cảnh, tác nhân bị trôi dần. Mục tiêu ban đầu bị tóm tắt rồi tóm tắt lại, làm giảm độ trung thành. Hook và judge tồn tại để phòng thủ điều này, và đây là nguyên nhân phổ biến nhất khiến tác nhân làm những việc không được yêu cầu
  • Xác minh: audit 24 giờ hoạt động tự trị là bài toán về thời gian thực của con người. Khả năng quan sát và các đầu ra có cấu trúc (PR, commit, briefing, lần chạy test) là cách làm cho việc đó trở nên tractable
  • Vai trò của con người: việc định nghĩa công việc đủ chính xác để tác nhân có thể chạy trong cả ngày còn khó hơn việc tự làm công việc đó. Kỹ năng đang tăng giá trị không phải viết code mà là viết spec có thể sống sót khi tiếp xúc với các tác nhân tự vận hành

Hướng đi sắp tới

  • Google, Anthropic và Cursor đang hội tụ về cùng một cấu trúc: tách vòng lặp mô hình·sandbox thực thi·log phiên, tách lập kế hoạch·sinh·đánh giá, tích hợp sẵn nén·hook·reset ngữ cảnh, và cung cấp bộ nhớ như một dịch vụ managed
  • Khác biệt chủ yếu là ở bề mặt: Google Agent Platform là stack doanh nghiệp (tích hợp sẵn identity·audit trail), Claude Managed Agents là "phiên bản được host của harness Anthropic", còn background agent của Cursor là "coding dài hạn được đẩy từ IDE lên cloud"
  • Trong 1 năm tới, bài toán khó hơn không nằm ở từng lớp riêng lẻ mà ở điều phối phía trên: vận hành nhiều tác nhân dài hạn trên codebase dùng chung, tác nhân tự đọc trace của chính mình rồi vá harness của mình, và harness lắp ghép công cụ cùng ngữ cảnh theo kiểu JIT (just-in-time) phù hợp với tác vụ
  • Mô hình vẫn là cốt lõi, nhưng khoảng cách giữa cửa sổ chat và tác nhân có thể chạy qua đêm chủ yếu nằm ở trạng thái, phiên và handoff có cấu trúc, và đây là khu vực đáng đầu tư thời gian học nhất hiện nay

1 bình luận

 

Tôi bắt đầu dùng hermes để giải quyết vấn đề này, và thấy cũng không tệ lắm haha