0. Tóm tắt (TL;DR)
Sau khi viết bài "Claude Code Mà Bạn Chưa Biết: Kiến trúc, Quản trị và Thực hành Kỹ thuật", tôi nhận ra hiểu biết của mình về các lớp nền tảng của Agent vẫn chưa đủ sâu. Kết hợp với kinh nghiệm đáng kể của nhóm trong việc triển khai các giải pháp kinh doanh dựa trên Agent, tôi thấy cần có một bài tổng quan có hệ thống. Vì vậy, tôi đã xem xét tài liệu, mã nguồn mở và code của chính mình để tổ chức bài viết này.
Bài viết tập trung vào các phần của kiến trúc Agent có tác động lớn nhất đến kết quả kỹ thuật, bao gồm luồng điều khiển, kỹ thuật ngữ cảnh, thiết kế công cụ, bộ nhớ, tổ chức đa Agent, đánh giá, theo dõi và bảo mật. Cuối cùng, chúng ta sẽ sử dụng triển khai OpenClaw để kết nối các nguyên tắc thiết kế này lại với nhau.
Trong quá trình tổng hợp, một số kết luận khác với giả định ban đầu của tôi: những cải tiến từ các mô hình đắt tiền hơn thường nhỏ hơn kỳ vọng; thay vào đó, chất lượng của Harness và các bài kiểm tra xác minh có tác động lớn hơn đến tỷ lệ thành công. Khi gỡ lỗi hành vi của Agent, hãy ưu tiên kiểm tra định nghĩa công cụ, vì hầu hết lỗi chọn công cụ đều bắt nguồn từ mô tả không chính xác. Hơn nữa, các vấn đề trong chính hệ thống đánh giá thường khó phát hiện hơn lỗi của Agent. Nếu bạn liên tục điều chỉnh code Agent mà không thành công, câu trả lời có thể nằm ở những lĩnh vực này.
1. Hoạt động Cơ bản của Vòng lặp Agent
Logic triển khai cốt lõi của một Vòng lặp Agent, khi được trừu tượng hóa, chỉ có chưa đến 20 dòng code:
1const messages: MessageParam[] = [{ role: "user", content: userInput }];23while (true) {4 const response = await client.messages.create({5 model: "claude-opus-4-6",6 max_tokens: 8096,7 tools: toolDefinitions,8 messages,9 });1011 if (response.stop_reason === "tool_use") {12 const toolResults = await Promise.all(13 response.content14 .filter((b) => b.type === "tool_use")15 .map(async (b) => ({16 type: "tool_result" as const,17 tool_use_id: b.id,18 content: await executeTool(b.name, b.input),19 }))20 );21 messages.push({ role: "assistant", content: response.content });22 messages.push({ role: "user", content: toolResults });23 } else {24 return response.content.find((b) => b.type === "text")?.text ?? "";25 }26}
Luồng điều khiển tương ứng như sau: một chu kỳ liên tục của Nhận thức -> Quyết định -> Hành động -> Phản hồi cho đến khi mô hình trả về văn bản thuần túy:
Đã thấy nhiều triển khai Agent và SDK chính thức, cấu trúc đều tương tự nhau. Bản thân vòng lặp khá ổn định. Từ một triển khai tối thiểu đến hỗ trợ sub-agent, nén ngữ cảnh và tải kỹ năng, vòng lặp chính hiếm khi thay đổi. Các khả năng mới thường được thêm vào bên ngoài vòng lặp hơn là sửa đổi bên trong nó.
Các khả năng mới được tích hợp chủ yếu theo ba cách: mở rộng bộ công cụ và trình xử lý, điều chỉnh cấu trúc system prompt, và ngoại hóa trạng thái ra file hoặc cơ sở dữ liệu. Phần thân vòng lặp không nên trở thành một máy trạng thái khổng lồ. Mô hình xử lý suy luận, trong khi các hệ thống bên ngoài xử lý trạng thái và ranh giới. Một khi sự phân công lao động này được thiết lập, logic vòng lặp cốt lõi hiếm khi cần điều chỉnh thường xuyên.
Sự khác biệt giữa Workflow và Agent là gì?
Anthropic đưa ra sự phân biệt trực tiếp: một hệ thống mà đường dẫn thực thi được viết sẵn trong code là Workflow; một hệ thống mà LLM tự động quyết định bước tiếp theo là Agent. Sự khác biệt cốt lõi là ai nắm quyền kiểm soát. Trong thực tế, nhiều sản phẩm được gắn nhãn Agent thực chất gần với Workflow hơn, nhưng không có cái nào vượt trội hơn cái nào. Điều quan trọng là tìm ra giải pháp phù hợp cho nhiệm vụ.
Nhìn vào một sơ đồ sẽ trực quan hơn:
Năm Mẫu Điều khiển Phổ biến
Hầu hết các hệ thống AI, khi được tháo rời, là sự kết hợp của năm mẫu này. Nhiều tình huống không cần đến toàn bộ quyền tự chủ của Agent; chỉ cần kết hợp một vài mẫu này là đủ. Vấn đề là thiết kế nào phù hợp với nhiệm vụ.
- Prompt Chaining (Xâu chuỗi Prompt): Các nhiệm vụ được chia thành các bước tuần tự, mỗi bước LLM xử lý đầu ra của bước trước. Có thể thêm các điểm kiểm tra code. Phù hợp cho các quy trình tuyến tính như dịch sau khi tạo hoặc viết nội dung thân bài sau dàn ý.
- Routing (Định tuyến): Phân loại đầu vào và chuyển hướng đến một quy trình chuyên biệt. Câu hỏi đơn giản đến mô hình nhẹ, câu hỏi phức tạp đến mô hình mạnh; truy vấn hỗ trợ kỹ thuật và thanh toán theo các logic khác nhau.
- Parallelization (Song song hóa): Hai biến thể: Sectioning (chia nhiệm vụ thành các nhiệm vụ con độc lập) và Voting (chạy cùng một nhiệm vụ nhiều lần để đạt được sự đồng thuận). Phù hợp cho các quyết định rủi ro cao hoặc nhu cầu đa góc nhìn.
- Orchestrator-Workers (Điều phối viên - Công nhân): Một LLM trung tâm tự động phân rã nhiệm vụ và ủy quyền cho các LLM công nhân, sau đó tổng hợp kết quả. Đây là nguyên mẫu cho công cụ spawn của nanobot và chế độ sub-agent của learn-claude-code.
- Evaluator-Optimizer (Đánh giá - Tối ưu hóa): Một bộ tạo tạo ra đầu ra, và một bộ đánh giá cung cấp phản hồi trong một vòng lặp cho đến khi đạt tiêu chuẩn. Phù hợp cho các nhiệm vụ như dịch thuật hoặc viết sáng tạo, nơi các tiêu chuẩn chất lượng khó xác định chính xác trong code.
Các mẫu này giải quyết cách xây dựng luồng điều khiển. Bây giờ hãy xem xét một câu hỏi thiên về kỹ thuật hơn: tại sao một hệ thống lại chạy ổn định?
2. Tại sao Harness lại Quan trọng hơn Mô hình
Harness đề cập đến cơ sở hạ tầng kiểm thử, xác minh và ràng buộc được xây dựng xung quanh một Agent. Một Harness bao gồm ít nhất bốn phần: đường cơ sở chấp nhận, ranh giới thực thi, tín hiệu phản hồi và phương pháp dự phòng.
Mặc dù mô hình rất quan trọng, nhưng các điều kiện kỹ thuật ngoại vi này thường quyết định liệu một hệ thống có chạy ổn định hay không. Nhận định này đúng nhất đối với các nhiệm vụ có khả năng xác minh cao như viết code, nhưng trong các nhiệm vụ xác minh yếu như nghiên cứu mở hoặc đàm phán nhiều vòng, giới hạn trên của mô hình vẫn quan trọng hơn.
Thực hành Phát triển Ưu tiên Agent của OpenAI
Ba kỹ sư đã viết một triệu dòng code trong năm tháng với gần 1.500 PR — nhanh gấp 10 lần so với phát triển truyền thống. Tốc độ này không chỉ nhờ sức mạnh của mô hình; mà còn nhờ các quyết định kỹ thuật đúng đắn:
- Nội dung Agent không thấy thì không tồn tại: Kiến thức phải tồn tại trong chính codebase. Tài liệu bên ngoài là vô hình đối với một Agent đang chạy. AGENTS.md được giữ ở ~100 dòng như một chỉ mục, với các chi tiết được chia vào các thư mục docs để tham khảo theo yêu cầu.
- Ràng buộc bằng code, đừng ghi chép chúng: Các chuẩn mực trong tài liệu dễ bị bỏ qua. Các ràng buộc được mã hóa thành Linter, hệ thống kiểu hoặc quy tắc CI là có thể thực thi được. Phân lớp kiến trúc được thực thi một cách cơ học bởi Linter tùy chỉnh, không phải đánh giá thủ công.
- Hoàn thành nhiệm vụ tự động từ đầu đến cuối: Từ xác minh trạng thái và tái tạo lỗi đến triển khai sửa lỗi và thúc đẩy xác minh ứng dụng, mở PR, xử lý đánh giá và hợp nhất — toàn bộ chuỗi không cần can thiệp của con người. Agent chủ động kiểm tra log, metrics và trace.
- Giảm thiểu xung đột hợp nhất: Xử lý các lỗi kiểm thử không liên tục bằng cách thử lại thay vì chặn tiến trình. Trong môi trường thông lượng cao, chi phí chờ đợi đánh giá thủ công thường cao hơn so với việc sửa các lỗi nhỏ. Kỷ luật viết code không biến mất; nó đã chuyển từ đánh giá thủ công sang các ràng buộc do máy thực thi.
Ứng dụng phân phối log, metrics và trace qua Vector đến lớp lưu trữ Victoria, tương ứng với các giao diện LogQL, PromQL và TraceQL. Codex truy vấn, tương quan và suy luận thông qua các giao diện này. Sau khi thay đổi, nó khởi động lại ứng dụng, chạy lại workloads và đưa kết quả trở lại Codex. UI Journeys cũng là đầu vào. Ngăn xếp quan sát này được tạo cho mỗi nhiệm vụ và bị phá hủy khi hoàn thành. Agent không chờ được thông báo về lỗi; nó truy vấn trạng thái hệ thống để xác minh các bản sửa lỗi.
Kết luận chính cho Harness là gì?
Sơ đồ sử dụng độ rõ ràng của nhiệm vụ và tự động hóa xác minh để chia các nhiệm vụ thành bốn trạng thái. Góc trên bên phải (mục tiêu rõ ràng, xác minh tự động) là vùng lý tưởng cho Agent. Góc trên bên trái (nhiệm vụ rõ ràng nhưng đánh giá thủ công) bị giới hạn bởi tốc độ đánh giá của con người. Góc dưới bên phải (phản hồi tự động nhưng mục tiêu mơ hồ) dẫn đến di chuyển hiệu quả theo hướng sai. Góc dưới bên trái (thiếu cả hai) khiến Agent trở nên vô dụng.
Công việc của Harness là đẩy các nhiệm vụ vào góc trên bên phải, đảm bảo đúng sai được đánh giá bằng các tiêu chuẩn có thể thực thi bằng máy, không phải bằng mắt người.
3. Tại sao Kỹ thuật Ngữ cảnh Quyết định Tính Ổn định
Độ phức tạp chú ý của Transformer là O(n²). Ngữ cảnh càng dài, các tín hiệu chính càng dễ bị pha loãng bởi nhiễu. Một chế độ lỗi phổ biến là "Context Rot" (Mục nát Ngữ cảnh), nơi nội dung không liên quan chiếm ưu thế trong ngữ cảnh, khiến chất lượng quyết định của Agent giảm sút. Nhiều vấn đề xuất hiện như sự bất lực của mô hình thực ra là do tổ chức ngữ cảnh kém.
Tại sao cần Phân lớp Ngữ cảnh?
Vấn đề thường không phải là cửa sổ không đủ dài, mà là mật độ thông tin sai. Việc tải các mục ít khi được sử dụng mỗi lần hoặc trộn lẫn các quy tắc ổn định với trạng thái động khiến mô hình khó nhận ra điều gì hữu ích.
Giải pháp là phân lớp thông tin theo tần suất và độ ổn định:
- Lớp Vĩnh viễn: Danh tính, quy ước dự án, điều cấm kỵ tuyệt đối. Nội dung phải giữ cho mọi phiên. Giữ ngắn gọn, cứng nhắc và có thể thực thi.
- Tải theo Yêu cầu: Kỹ năng và kiến thức miền. Giữ mô tả vĩnh viễn, nhưng chỉ tiêm nội dung đầy đủ khi được kích hoạt.
- Tiêm Thời gian chạy: Thông tin động như thời gian hiện tại, ID kênh, tùy chọn người dùng. Được tiêm mỗi vòng khi cần.
- Lớp Bộ nhớ: Kinh nghiệm xuyên phiên được ghi vào MEMORY.md. Không trực tiếp trong system prompt; chỉ đọc khi cần.
- Lớp Hệ thống: Hook hoặc quy tắc code cho logic xác định. Hoàn toàn nằm ngoài ngữ cảnh.
Đừng đặt logic xác định vào ngữ cảnh. Bất cứ điều gì có thể diễn đạt qua Hook, quy tắc code hoặc ràng buộc công cụ nên được xử lý bởi các hệ thống bên ngoài.
Ba Chiến lược Nén Phổ biến
- Sliding Window (Cửa sổ trượt): Loại bỏ các tin nhắn cũ. Chi phí thấp, nhưng mất ngữ cảnh ban đầu. Tốt cho các cuộc trò chuyện ngắn.
- LLM Summary (Tóm tắt LLM): Mô hình tạo bản tóm tắt. Chi phí trung bình, mất chi tiết nhưng giữ được quyết định. Tốt cho các nhiệm vụ dài.
- Tool Result Replacement (Thay thế Kết quả Công cụ): Thay thế đầu ra thô bằng các trình giữ chỗ. Chi phí thấp, tốt cho các nhiệm vụ sử dụng nhiều công cụ.
Cửa sổ trượt dễ nhất nhưng mất bối cảnh ban đầu. Tóm tắt LLM nâng cao sử dụng "branch summarization" (tóm tắt nhánh), bảo tồn rõ ràng các quyết định kiến trúc, nhiệm vụ chưa hoàn thành và các ràng buộc chính. Trong thay thế công cụ, micro_compact thay thế đầu ra công cụ cũ mỗi vòng, trong khi auto_compact được kích hoạt khi ngữ cảnh vượt quá một ngưỡng.
Prompt Caching để Giảm Chi phí Dư thừa
Suy luận LLM tính toán các cặp Key-Value cho mỗi token. Nếu một tiền tố khớp chính xác với một yêu cầu trước đó, nó sẽ được đọc từ bộ nhớ cache. Bộ nhớ cache yêu cầu khớp tiền tố chính xác. Thiết kế thân thiện với bộ nhớ cache tập trung vào tính ổn định: system prompt, định nghĩa công cụ và tài liệu dài là ổn định và phù hợp để lưu vào bộ nhớ cache. Thông tin động (thời gian, đầu vào, kết quả công cụ) nên được đặt ở cuối.
Điều này liên quan đến phân lớp ngữ cảnh. Lớp vĩnh viễn càng ổn định, tỷ lệ truy cập bộ nhớ cache càng cao và chi phí cận biên càng thấp. "Ngắn và ổn định" không chỉ để tiết kiệm token; nó bảo vệ bộ nhớ cache. Tải kỹ năng chậm cũng giúp ích bằng cách thêm nội dung sau tiền tố ổn định. Một điểm phản trực giác: một system prompt lớn ổn định có thể rẻ hơn một system prompt nhỏ thay đổi thường xuyên vì chiết khấu 90% cho các lần đọc tiếp theo lớn hơn chi phí ghi ban đầu.
Tại sao cần Tải Kỹ năng Theo Yêu cầu?
Kỹ năng là một mẫu hiệu quả: chỉ giữ chỉ mục trong system prompt, tải kiến thức đầy đủ khi cần.
1const systemPrompt = `2Kỹ năng có sẵn:3- deploy: Quy trình triển khai sản xuất đầy đủ4- code-review: Danh sách kiểm tra đánh giá code5- git-workflow: Chiến lược nhánh và chuẩn mực PR6`;78async function executeLoadSkill(name: string): Promise<string> {9 return fs.readFile(`./skills/${name}.md`, "utf-8");10}
Mô tả kỹ năng phải ngắn để tránh phình to token và nên đóng vai trò là điều kiện định tuyến. Giải thích khi nào sử dụng, khi nào KHÔNG sử dụng và đầu ra là gì. Sử dụng "Sử dụng khi / Không sử dụng khi" kèm ví dụ phủ định. Nhiều lỗi định tuyến là do ranh giới không rõ ràng, không phải khả năng của mô hình. System prompt nên làm rõ các quy tắc: quét available_skills trước mỗi phản hồi, tải SKILL.md cụ thể nếu khớp và chỉ tải một kỹ năng tại một thời điểm.
Dữ liệu rất rõ ràng: nếu không có ví dụ phủ định, độ chính xác giảm từ 73% xuống 53%; thêm chúng vào sẽ nâng lên 85% và giảm thời gian phản hồi 18,1%. Ví dụ phủ định là chìa khóa.
Bộ mô tả kỹ năng có hai cạm bẫy. Đầu tiên, số lượng từ: mô tả dài cho mọi kỹ năng sẽ cộng dồn. Thứ hai, độ chính xác: "giúp với backend" là quá mơ hồ. Bộ mô tả hiệu quả là điều kiện định tuyến, không phải giới thiệu tính năng. "Khi nào sử dụng tôi" quan trọng hơn "Tôi có thể làm gì".
Kiểm soát số lượng: chỉ giữ các kỹ năng tần suất cao trong prompt vĩnh viễn. Các kỹ năng tần suất thấp có thể được giới thiệu thủ công hoặc giữ dưới dạng tài liệu. Các phản mẫu điển hình bao gồm nhồi nhét hàng trăm dòng hướng dẫn sử dụng vào một kỹ năng hoặc một kỹ năng bao phủ quá nhiều nhiệm vụ riêng biệt (đánh giá, triển khai, gỡ lỗi).
Nén dễ mất gì nhất?
Vấn đề phổ biến nhất không phải là bản tóm tắt quá dài, mà là ưu tiên lưu giữ sai. LLM thường xóa thông tin có vẻ như có thể lấy lại được. Kết quả công cụ bị xóa đầu tiên, nhưng các quyết định kiến trúc liên quan và đường dẫn lỗi thường cũng biến mất theo. Xác định rõ ràng các ưu tiên lưu giữ trong CLAUDE.md:
1### Hướng dẫn Nén: Cách giữ lại thông tin chính2Ưu tiên:31. Quyết định kiến trúc (không tóm tắt)42. Các tệp đã sửa đổi và thay đổi chính53. Trạng thái xác minh (đạt/không đạt)64. TODOs chưa giải quyết và ghi chú rollback75. Kết quả công cụ (có thể xóa, chỉ giữ kết luận đạt/không đạt)
Một cạm bẫy khác: đừng thay đổi định danh. UUID, hash, IP và tên tệp phải được giữ nguyên chính xác. Một ký tự sai trong commit hash sẽ phá vỡ các lệnh gọi công cụ tiếp theo.
Tại sao Hệ thống Tệp là Giao diện Ngữ cảnh Tuyệt vời
Cursor gọi đây là "Dynamic Context Discovery" (Khám phá Ngữ cảnh Động): cung cấp ít hơn theo mặc định, đọc khi cần. Hệ thống tệp là giao diện tự nhiên. Các lệnh gọi công cụ thường trả về JSON khổng lồ; thay vì nhồi nhét nó vào ngữ cảnh, hãy ghi nó vào một tệp. Agent có thể sử dụng grep hoặc rg để đọc khi cần. Điều này giữ cho ngữ cảnh sạch sẽ và có thể đọc được bởi nhà phát triển.
Cursor đã xác minh điều này với các công cụ MCP: chúng đồng bộ hóa mô tả công cụ vào các thư mục. Agent chỉ thấy tên công cụ theo mặc định và truy vấn định nghĩa khi cần. Trong các thử nghiệm A/B, điều này đã giảm tổng mức tiêu thụ token xuống 46,9%.
Điều này cũng hiệu quả cho việc nén các nhiệm vụ dài. Thay vì loại bỏ lịch sử, hãy lưu toàn bộ nhật ký trò chuyện vào một tệp và tham chiếu đường dẫn trong bản tóm tắt. Nếu Agent cần chi tiết, nó có thể truy xuất từ tệp, làm cho việc nén trở thành một hoạt động mất mát nhưng có thể truy vết.
4. Thiết kế Công cụ Xác định Khả năng của Agent
Ngữ cảnh xác định mô hình thấy gì; công cụ xác định nó có thể làm gì. Chất lượng hơn số lượng. Chỉ 5 máy chủ MCP có thể tiêu tốn ~55.000 token trong các định nghĩa — gần 30% của một ngữ cảnh 200K trước khi cuộc trò chuyện bắt đầu. Quá nhiều công cụ làm loãng sự chú ý của mô hình.
Hầu hết các vấn đề về công cụ không phải là có quá ít, mà là chọn sai công cụ, mô tả khó hiểu hoặc trả về dữ liệu vô dụng.
Thiết kế Công cụ Phát triển Như thế nào
Thiết kế công cụ đã trải qua ba giai đoạn. Ban đầu, các API hiện có chỉ được bọc lại thành công cụ. Sau đó, người ta thấy rằng lỗi lựa chọn thường là do công cụ được thiết kế cho kỹ sư, không phải cho Agent.
Thế hệ 1: API Wrapping (Bọc API): Mỗi endpoint là một công cụ. Quá chi tiết; Agent phải phối hợp nhiều công cụ cho một mục tiêu.
Thế hệ 2: ACI (Agent-Computer Interface - Giao diện Agent-Máy tính): Công cụ tương ứng với mục tiêu của Agent, không phải API cấp thấp. Thay vì create_file và set_permissions, hãy cung cấp create_script(path, content, executable).
Thế hệ 3: Advanced Tool Use (Sử dụng Công cụ Nâng cao): Tối ưu hóa việc khám phá và gọi:
- Tool Search (Tìm kiếm Công cụ): Đừng nhồi nhét tất cả định nghĩa cùng một lúc. Agent tìm định nghĩa qua
search_tools. Khả năng lưu giữ ngữ cảnh đạt 95%. - Programmatic Tool Calling (Gọi Công cụ Theo Chương trình): Cho phép mô hình sử dụng code để điều phối nhiều lệnh gọi. Kết quả trung gian ở lại trong môi trường thực thi, không phải ngữ cảnh LLM. Token có thể giảm từ 150.000 xuống 2.000.
- Tool Use Examples (Ví dụ Sử dụng Công cụ): Mỗi công cụ có 1-5 ví dụ thực tế. JSON Schema mô tả các kiểu, nhưng ví dụ cho thấy cách sử dụng. Độ chính xác có thể tăng từ 72% lên 90%.
Nguyên tắc Thiết kế Công cụ ACI
Thiết kế công cụ ảnh hưởng trực tiếp đến Agent. Nó không chỉ là "có thể gọi được không", mà là "có thể tự sửa lỗi nếu gọi sai không?"
Thiết kế tồi có tham số mơ hồ và lỗi không thể sửa chữa. Thiết kế tốt sử dụng betaZodTool để ràng buộc định nghĩa và triển khai, sử dụng Zod cho các ràng buộc định dạng và đề xuất lỗi có cấu trúc:
1const updateTool = betaZodTool({2 name: "update_yuque_post",3 description: "Cập nhật nội dung bài viết Yuque; không dùng để tạo bài viết mới",4 inputSchema: z.object({5 post_id: z.string().describe("ID bài viết Yuque, chuỗi số như '12345678'"),6 title: z.string().optional().describe("Tiêu đề bài viết, bỏ qua nếu không thay đổi"),7 content_markdown: z.string().describe("Nội dung Markdown"),8 }),9 run: async (input) => {10 const post = await getPost(input.post_id);11 if (!post) throw new ToolError("ID bài viết không tồn tại", {12 error_code: "POST_NOT_FOUND",13 suggestion: "Gọi list_yuque_posts trước để lấy post_id hợp lệ",14 });15 return await updatePost(input.post_id, input.title, input.content_markdown);16 },17});
Thiết kế tồi chỉ nói nó làm gì, không nói khi nào sử dụng nó. Thiết kế ACI tốt có ranh giới rõ ràng và lỗi có cấu trúc, giúp Agent chọn đúng và sửa lỗi nhanh chóng. Gỡ lỗi công cụ trước; hầu hết lỗi nằm ở mô tả, không phải khả năng của mô hình.
Tại sao cần Cô lập Tin nhắn Công cụ?
Các framework tạo ra các sự kiện nội bộ (nén, thông báo). Chúng nên có trong lịch sử phiên nhưng không được gửi đến LLM, vì chúng lãng phí token và gây nhầm lẫn cho mô hình. Giải pháp là hai loại tin nhắn: AgentMessage cho lớp ứng dụng (với các trường tùy chỉnh) và Message tiêu chuẩn (user, assistant, tool_result) cho LLM.
5. Thiết kế Hệ thống Bộ nhớ
Agent thiếu tính liên tục thời gian tự nhiên. Ngữ cảnh bị xóa sau một phiên. Để đạt được tính nhất quán xuyên phiên, một lớp bộ nhớ phải được thiết kế như một cơ sở hạ tầng, không phải là một suy nghĩ sau.
Bốn Loại Bộ nhớ Sống ở Đâu?
Được phân loại theo vấn đề chúng giải quyết:
- Context Window (Bộ nhớ Làm việc): Thông tin tối thiểu cho nhiệm vụ hiện tại. Token có hạn; phải được quản lý.
- Skills (Bộ nhớ Thủ tục): Cách làm mọi việc (quy trình làm việc, chuẩn mực). Được tải theo yêu cầu.
- JSONL Session History (Bộ nhớ Tình tiết): Những gì đã xảy ra. Được lưu trữ vào đĩa; có thể tìm kiếm.
- MEMORY.md (Bộ nhớ Ngữ nghĩa): Các sự kiện ổn định do Agent ghi lại. Được tiêm vào system prompt.
Cách MEMORY.md và Skills Phối hợp
Cốt lõi là giữ các sự kiện quan trọng trong khi kiểm soát khối lượng nội dung.
Bộ nhớ 4 Lớp của ChatGPT: Cấu trúc đơn giản. Session Metadata (không được lưu trữ), User Memory (~33 sự kiện, được lưu trữ/tiêm), Conversation Summary (~15 bản tóm tắt gần đây, được lưu trữ), Current Session (cửa sổ trượt).
Truy xuất Lai của OpenClaw: Nhật ký hàng ngày (memory/YYYY-MM-DD.md), MEMORY.md cho các sự kiện được quản lý và memory_search sử dụng truy xuất lai (70% tương tự vector + 30% từ khóa). Đối với hầu hết các Agent, Markdown có cấu trúc + tìm kiếm từ khóa là đủ cho khả năng gỡ lỗi và chi phí.
Kích hoạt và Rollback Hợp nhất Bộ nhớ
Khi tokenUsage / maxTokens >= 0.5, kích hoạt hợp nhất. Tóm tắt tin nhắn, thêm vào MEMORY.md và cập nhật chỉ mục. Nếu thất bại, ghi tin nhắn thô vào kho lưu trữ. Quy trình phải có thể đảo ngược; di chuyển con trỏ, không xóa dữ liệu thô.
6. Tăng dần Quyền tự chủ của Agent
Quyền tự chủ đòi hỏi ba phần cơ sở hạ tầng: tiếp tục xuyên phiên, ràng buộc tiến độ trong phiên và I/O nền cho các tác vụ chậm.
Cách Tiếp tục Các Nhiệm vụ Dài Xuyên Phiên
Các nhiệm vụ dài thất bại khi phiên kết thúc trước khi hoàn thành. Một cách tiếp cận ổn định sử dụng Initializer Agent và Coding Agent. Initializer chạy một lần để tạo feature-list.json, init.sh và claude-progress.txt. Coding Agent sau đó chạy trong nhiều phiên, tiếp tục từ các tệp này, triển khai một tính năng, chạy kiểm thử và cập nhật tệp tiến độ. Điều này làm cho nhiệm vụ trở thành một trạng thái bên ngoài.
Giữ tiến độ trong các tệp, không phải ngữ cảnh. Sử dụng JSON cho cấu trúc. Nhiệm vụ chỉ hoàn thành khi tất cả các tính năng trong feature-list.json có passes: true.
Tại sao cần Ghi rõ Trạng thái Nhiệm vụ?
Nếu không có điểm neo bên ngoài, Agent sẽ trôi dạt hoặc kết thúc sớm. Ghi lại trạng thái như một đối tượng kiểm soát bên ngoài:
1{2 "tasks": [3 {"id": "1", "desc": "Đọc cấu hình", "status": "completed"},4 {"id": "2", "desc": "Sửa đổi schema", "status": "in_progress"}5 ]6}
Ràng buộc: chỉ một in_progress tại một thời điểm. Cập nhật trạng thái sau mỗi bước.
Tích hợp I/O Nền
I/O chậm (thao tác tệp, mạng) không nên chặn vòng lặp chính. Đặt các tiến trình con chậm trong các luồng nền và tiêm kết quả qua hàng đợi thông báo trước lần gọi LLM tiếp theo. Điều này dễ bảo trì hơn so với một runtime async phức tạp.
7. Tổ chức Hệ thống Đa Agent
Kỹ thuật hệ thống đa Agent là về sự cô lập và cộng tác.
Director Mode (Chế độ Giám đốc): Đồng bộ. Con người tương tác chặt chẽ với một Agent. Ngữ cảnh bị mất khi phiên kết thúc.
Coordinator Mode (Chế độ Điều phối viên): Ủy quyền không đồng bộ. Con người đặt mục tiêu, Agent làm việc song song, con người xem xét đầu ra. Đầu ra trở thành các tạo tác bền vững (PR, nhánh).
Một Orchestrator quản lý các sub-agent làm việc song song, giao tiếp qua các giao thức hộp thư đến JSONL và sử dụng Worktrees để cô lập.
Sub-Agent Tốt cho Việc Gì?
Tìm kiếm và thử-sai không nên làm ô nhiễm ngữ cảnh của Agent chính. Agent chính chỉ cần kết luận.
1const result = await runAgentLoop(task, { messages: [] });2return summarize(result); // Ngữ cảnh chính chỉ thấy dòng này
Tại sao viết Cộng tác như một Giao thức?
Cộng tác bằng ngôn ngữ tự nhiên thất bại khi Agent quên lời hứa. Sử dụng một giao thức có cấu trúc:
1{ request_id, from_agent, to_agent, content, status: 'pending', timestamp }
Sử dụng hộp thư đến JSONL chỉ nối thêm để phục hồi sau sự cố. Cô lập trước, sau đó mới cộng tác.
Ảo giác Khuếch đại trong Hệ thống Đa Agent
Lỗi lan truyền giữa các Agent. Xác thực chéo phá vỡ chuỗi này bằng cách có một Agent độc lập hoặc phản hồi bên ngoài (kiểm thử, trình biên dịch) đánh giá kết luận.
8. Cách Đánh giá Agent
Đánh giá yêu cầu các trường hợp kiểm thử, tiêu chuẩn chấm điểm và xác minh tự động.
Đánh giá một lượt truyền thống (Prompt -> Phản hồi) là không đủ. Đánh giá Agent yêu cầu công cụ và môi trường. Chấm điểm dựa trên những gì đã xảy ra trong môi trường, không chỉ dựa trên những gì Agent nói.
Các khái niệm chính: Task (Nhiệm vụ), Trial (Lần thử), Grader (Bộ chấm điểm). Transcript (Nhật ký thực thi) so với Outcome (Trạng thái cuối cùng). Bạn cần cả hai. Một Agent có thể nói "đã đặt vé" (transcript) nhưng không tạo được bản ghi trong cơ sở dữ liệu (outcome).
Trạng thái và Chỉ số Đánh giá
Nhiều đội vẫn dựa vào đánh giá thủ công hoặc bộ đánh giá LLM. Các chỉ số phổ biến: Pass@k (về mặt lý thuyết có làm được không?) và Pass^k (có ổn định cho sản xuất không?). Đừng trộn lẫn chúng.
Ba Loại Bộ Đánh Giá
- Bộ đánh giá mã: So khớp chuỗi, kiểm thử đơn vị. Độ chắc chắn cao nhất.
- Bộ đánh giá mô hình: LLM đánh giá dựa trên tiêu chí. Tốt cho chất lượng ngữ nghĩa.
- Bộ đánh giá con người: Đánh giá chuyên gia. Chậm nhưng thiết lập đường cơ sở.
Xây dựng Hệ thống Đánh giá từ Đầu
Bắt đầu với 20-50 trường hợp thất bại thực tế. Đảm bảo cách ly môi trường để các bài kiểm thử không làm nhiễu lẫn nhau. Bao gồm cả trường hợp tích cực và tiêu cực. Nếu hai chuyên gia không đồng ý về một trường hợp, thì tiêu chí chưa rõ ràng.
Sửa Hệ thống Đánh giá Trước khi Sửa Agent
Nếu điểm số giảm, hãy kiểm tra hệ thống đánh giá trước. Các vấn đề môi trường (giới hạn bộ nhớ, lỗi trong bộ đánh giá) trông giống như suy giảm mô hình.
9. Theo dõi Quy trình Thực thi
Nếu không có dấu vết, các lỗi không thể tái tạo. Các chỉ số APM (độ trễ, tỷ lệ lỗi) là không đủ; bạn cần chuỗi suy luận.
Cần Ghi lại Gì trong Một Dấu vết?
Toàn bộ prompt, tin nhắn nhiều vòng, lệnh gọi công cụ/đối số/kết quả trả về, chuỗi suy nghĩ, đầu ra cuối cùng, token và độ trễ.
Khả năng Quan sát Hai Lớp
- Lấy mẫu thủ công: Lấy mẫu dựa trên quy tắc các lỗi hoặc phản hồi tiêu cực để tìm ra các mẫu thất bại.
- Tự động đánh giá LLM: Bao phủ toàn bộ dấu vết sử dụng lớp thủ công làm đường cơ sở hiệu chuẩn.
Luồng Sự kiện làm Nền tảng
Phát ra các sự kiện tại tool_start, tool_end và turn_end. Các hệ thống hạ nguồn (nhật ký, giao diện người dùng, đánh giá) tiêu thụ các sự kiện này mà không thay đổi mã vòng lặp cốt lõi.
10. Triển khai Agent với OpenClaw
OpenClaw sử dụng năm lớp tách rời: Gateway, Bộ điều hợp kênh, Pi Agent (vòng lặp cốt lõi), Bộ công cụ (thiết kế ACI) và Ngữ cảnh/Bộ nhớ.
Tách rời Bus Tin nhắn
Một Bus Tin nhắn tách biệt các kênh khỏi Agent. Các kênh chỉ xử lý I/O; Agent chỉ xử lý xử lý.
Prompt Hệ thống theo Lớp
SOUL.md xác định danh tính và tiêu chuẩn hoàn thành. Các prompt được phân lớp: Thông tin runtime -> Danh tính -> Bộ nhớ -> Kỹ năng -> Tiêm động.
Ranh giới Bảo mật Trước tiên
Trước khi thêm tính năng, hãy thiết lập: Danh sách trắng người dùng, Cách ly không gian làm việc (kiểm tra đường dẫn) và Nhật ký kiểm toán.
Bảo vệ chống tiêm prompt: Coi nội dung bên ngoài là không đáng tin cậy. Sử dụng tách biệt nguồn-đích. Đừng cấp cho Agent các công cụ chúng không cần. Yêu cầu xác nhận rõ ràng từ con người cho các hành động nhạy cảm.
Dự phòng nhà cung cấp: Tự động chuyển đổi nhà cung cấp (Anthropic -> OpenAI) nếu một nhà cung cấp bị lỗi.
11. Các Phản mẫu Phổ biến
- Prompt hệ thống như một cơ sở kiến thức (quá dài).
- Sự lan rộng công cụ (Agent chọn sai công cụ).
- Thiếu vòng lặp xác minh.
- Hệ thống đa agent không có ranh giới.
- Không hợp nhất bộ nhớ (chất lượng giảm sau 20 vòng).
- Không có hệ thống đánh giá.
- Phức tạp đa agent sớm.
- Dựa vào kỳ vọng thay vì các ràng buộc cơ học.
12. Kết luận
- Lõi Agent là một vòng lặp ổn định; các tính năng mới nên được ngoại hóa.
- Harness quyết định sự hội tụ nhiều hơn mô hình.
- Kỹ thuật ngữ cảnh ngăn chặn 'Context Rot'.
- Thiết kế công cụ ACI tập trung vào mục tiêu và sửa lỗi.
- Bộ nhớ được phân lớp (Làm việc, Thủ tục, Tình tiết, Ngữ nghĩa).
- Các tác vụ dài dựa vào trạng thái và tệp ngoại hóa.
- Hệ thống đa agent cần giao thức và cách ly.
- Đánh giá Pass@k cho năng lực, Pass^k cho chất lượng.
- Theo dõi là điều kiện tiên quyết để gỡ lỗi.
- Agent ổn định dựa vào các chi tiết kỹ thuật như tách rời và ranh giới bảo mật.
