Công cụ Go CLI này viết truyện dài 500 chương chỉ với một câu: Kiến trúc Multi-Agent đột phá

ainovel-cli là một dự án mã nguồn mở viết bằng ngôn ngữ Go, sở hữu kiến trúc đa tác nhân (multi-agent) nghiêm túc nhất mà tôi từng thấy cho đến nay trong lĩnh vực viết văn bản dài bằng AI.

Tại sao vấn đề này lại quan trọng ngay lúc này?

Hiện nay, mọi người đều đang xây dựng công cụ viết AI. Tuy nhiên, hầu hết chúng chỉ là những trình bao bọc (wrapper) đơn giản với chức năng "tiếp tục đoạn văn". Chúng thường sụp đổ sau chương ba, quên tên nhân vật ở chương bảy và biến thành một mớ văn bản hỗn loạn vào chương hai mươi. Dường như chưa ai thực sự giải quyết triệt để bài toán kỹ thuật về tính nhất quán (coherence) trong dài hạn — cho đến khi có thể là dự án này.

ainovel-cli là một dự án Go với 71 sao (stars) trên GitHub, âm thầm ra mắt một động cơ tạo tiểu thuyết đa tác nhân. Triết lý thiết kế của nó xứng đáng được bạn quan tâm, ngay cả khi bạn chưa bao giờ viết một từ văn bản hư cấu nào. Các quyết định kiến trúc tại đây là một bài học thực tế về cách xây dựng các pipeline LLM đáng tin cậy và chạy lâu dài.

Công cụ này thực sự làm được những gì?

Bạn cung cấp cho nó một câu duy nhất. Nó sẽ tạo ra một cuốn tiểu thuyết hoàn chỉnh. Đó là lời hứa hẹn. Nhưng điểm thú vị nằm ở cách nó ngăn chặn quá trình này bị sụp đổ.

Bốn tác nhân chuyên biệt sẽ chia sẻ công việc:

• Coordinator: Điều phối mọi thứ.
• Architect: Xử lý tiền đề, dàn ý, tệp nhân vật và quy tắc thế giới.
• Writer: Tự chủ lập kế hoạch, nháp, tự xem xét và hoàn thành mỗi chương.
• Editor: Đánh giá cốt truyện dựa trên bảy chiều chất lượng.

Mỗi tác nhân có một bộ công cụ bị hạn chế — Writer nhận các lệnh như plan_chapter, draft_chapter, check_consistency, commit_chapter. Editor nhận read_chapter, save_review, save_arc_summary. Không ai làm tất cả mọi việc, điều này có nghĩa là không ai bị tràn ngữ cảnh (context overflow) khi cố gắng xử lý quá nhiều thông tin.

Quy trình biên tập bảy chiều của dự án này thực sự đầy tham vọng: tính nhất quán của bối cảnh, hành vi nhân vật, nhịp độ, tính mạch lạc của câu chuyện, sự gợi ý trước (foreshadowing), điểm neo và chất lượng thẩm mỹ — trong đó thẩm mỹ lại được chia nhỏ thành kết cấu mô tả, kỹ thuật tường thuật, sự khác biệt trong hội thoại, chất lượng từ vựng và sự cộng hưởng cảm xúc. Mọi lời phê bình đều phải trích dẫn văn bản gốc làm bằng chứng. Đây không phải là biên tập dựa trên cảm tính.

Kiến trúc kỹ thuật đáng để học hỏi

Viên ngọc quý thực sự ở đây là sự tách biệt giữa Scaffolding và Harness, được ghi lại trong phần kiến trúc của file README. Hầu hết các khung tác nhân (agent frameworks) hiện nay đều lẫn lộn giữa thiết lập và thời gian chạy. Dự án này tách biệt chúng một cách rõ ràng:

• Scaffolding (Giàn giáo): Lựa chọn mô hình, lắp ráp prompt, ràng buộc công cụ và kết nối các tác nhân con diễn ra trước khi quá trình chạy bắt đầu.
• Harness (Dây đai/Bộ điều khiển): Khi đã chạy, lớp chủ sở hữu sẽ quản lý các chuyển đổi trạng thái, khôi phục điểm kiểm tra (checkpoint recovery), các gói bàn giao (handoff), cổng xem xét và tính nhất quán khi cam kết (commit).

Điều quan trọng cần lưu ý: LLM không bao giờ kiểm soát luồng điều khiển. Trạng thái được điều khiển bởi các tệp tín hiệu (signal files). Máy trạng thái Phase tuân theo quy tắc tiến về phía trước nghiêm ngặt (init → premise → outline → writing → complete) mà không có quay ngược lại (backtracking). Lớp Flow xử lý các chuyển đổi trong quá trình viết (viết → xem xét → viết lại → tinh chỉnh → điều hướng). Đây là sự điều phối xác định (deterministic orchestration) trên nền tảng tạo ra không xác định — chính xác là sự tách biệt đúng đắn cần thiết.

Khôi phục điểm kiểm tra ở cấp chương (chapter-level checkpoint recovery) là điều tối thiểu trong các pipeline sản xuất nhưng gần như không công cụ mã nguồn mở nào tích hợp điều này. Tại đây, dù bạn bấm Ctrl+C, gặp sự cố hay mất mạng, mọi thứ đều sẽ tiếp tục từ chương đã cam kết gần nhất, bao phủ tất cả năm giai đoạn: lập kế hoạch, viết, xem xét, viết lại và can thiệp của người dùng.

Việc lập kế hoạch cốt truyện dạng cuộn (rolling arc planning) cũng rất thông minh. Thay vì lên kế hoạch cho 500 chương ngay từ đầu (điều tạo ra những dàn ý rỗng tuếch), Architect chỉ lập kế hoạch khung sườn cho 2 cung truyện đầu tiên và các chương chi tiết cho cung truyện 1. Các cung truyện tiếp theo sẽ được mở rộng một cách lười biếng (lazy), dựa trên tóm tắt save_arc_summary và trạng thái snapshot của nhân vật. Việc lập kế hoạch cho tương lai xa vẫn thực tế vì nó được tạo ra khi cần thiết, không phải khi nó còn mang tính suy đoán.

Về quản lý ngữ cảnh, công cụ novel_context tải một gói có cấu trúc cho mỗi chương: các tóm tắt trước đó, dòng thời gian, các chủ đề gợi ý đang hoạt động, trạng thái nhân vật, quy tắc phong cách, dự báo chương tiếp theo và các chương lịch sử được đề xuất dựa trên mức độ liên quan trên bốn chiều — gợi ý, sự xuất hiện của nhân vật, thay đổi trạng thái và mối quan hệ. Chiến lược thích ứng sẽ tự động chuyển đổi giữa ngữ cảnh đầy đủ, cửa sổ trượt và tóm tắt phân cấp dựa trên tổng số chương, đây là câu trả lời kỹ thuật chính xác cho bài toán 500 chương.

Tất cả trạng thái đều nằm trong các tệp JSON và Markdown. Không có cơ sở dữ liệu nào. writerRestorePack và các gói bàn giao được tuần tự hóa giữa các lần gọi tác nhân. Lớp lưu trữ có thể kiểm toán và dễ di chuyển, điều này rất quan trọng khi bạn đang gỡ lỗi một cuốn tiểu thuyết đã dài 200 chương.

Những hạn chế thực tế: Ai KHÔNG NÊN sử dụng điều này?

Hãy thẳng thắn về những gì công cụ này không phải là.

Dự án hiện mới chỉ có 71 sao và chưa có thẻ phát hành ổn định nào. Thư mục docs/ chỉ rõ rằng các tài liệu như runtime-and-recovery.md, writing-pipeline.md và diagnostics.md được đánh dấu là "đề xuất bổ sung trong tương lai". Bạn đang làm việc với một dự án non trẻ và tài liệu chưa hoàn chỉnh. Kiến trúc có đầy tính suy ngẫm nhưng sổ tay vận hành thì chưa có.

Nó ưu tiên tiếng Trung. README, bình luận và các prompt mặc định đều bằng tiếng Trung. Công cụ có thể viết tiểu thuyết tiếng Anh — các LLM nền tảng là đa ngôn ngữ — nhưng nếu bạn cần gỡ lỗi hành vi của prompt hoặc điều chỉnh trình biên tập bảy chiều, bạn sẽ phải đọc mã nguồn tiếng Trung. Đây thực sự là một trở ngại cho những người không nói tiếng Trung.

Chi phí API sẽ rất lớn. Một cuốn tiểu thuyết 500 chương với các vòng lặp xem xét đa tác nhân, kiểm tra tính nhất quán tự động và tóm tắt cốt truyện sẽ tiêu tốn một lượng token đáng kể. Không có công cụ ước tính chi phí nào hiển thị trong tài liệu. Hãy cân đối ngân sách trước khi bắt đầu chạy.

Go không phải là Python. Nếu bạn muốn phân nhánh (fork) và tùy chỉnh hành vi của tác nhân hoặc thay thế bằng prompt của riêng bạn, bạn sẽ phải viết code Go. Điều này ổn thôi, nhưng cộng đồng những người đam mê tùy biến AI lại thiên về Python nhiều hơn. Bề mặt đóng góp sẽ hẹp hơn.

Không có tùy chọn lưu trữ trên đám mây. Đây là một CLI bạn chạy cục bộ. Nếu bạn muốn tạo tiểu thuyết không đồng bộ trong nền hoặc tích hợp nó vào một ứng dụng web, bạn phải tự xây dựng cơ sở hạ tầng đó.

Kết luận

Dự án này xứng đáng có nhiều sao hơn mức hiện tại. Kiến trúc Novel Harness — mặt phẳng điều khiển xác định trên các tác nhân không xác định, máy trạng thái phase chỉ tiến về phía trước, lập kế hoạch cốt truyện dạng lười và khôi phục ở cấp chương — giải quyết các vấn đề thực tế quan trọng vượt xa việc chỉ tạo tiểu thuyết. Bất kỳ nhà phát triển nào đang xây dựng quy trình làm việc LLM chạy dài (pipeline tạo mã, tác nhân nghiên cứu, tổng hợp tài liệu) đều nên đọc codebase này.

Để tạo tiểu thuyết thực tế: nếu bạn biết tiếng Trung và thoải mái khi gỡ lỗi một dự án Go non trẻ, đây là nỗ lực mã nguồn mở nghiêm túc nhất về truyện hư cấu dài dạng AI mà tôi từng gặp. Việc lập kế hoạch cốt truyện dạng cuộn và quy trình biên tập bảy chiều riêng biệt đã đưa nó vượt xa bất kỳ thứ gì trong hệ sinh thái Python.

Nếu bạn là một nhà phát triển đang nghiên cứu các mẫu kiến trúc đa tác nhân, hãy clone nó về anyway. Sự tách biệt Scaffolding/Harness và luồng điều khiển dựa trên tệp tín hiệu là những ý tưởng đáng để mang sang dự án tiếp theo của bạn bất kể bạn đang xây dựng cái gì.

LLM không bao giờ kiểm soát luồng điều khiển — trạng thái được điều khiển bởi các tệp tín hiệu, đó chính xác là sự tách biệt đúng đắn giữa điều phối xác định và tạo ra không xác định.