Pi 1.0 và Pi Durable: từ coding agent tối giản đến nền tảng AI chạy dài hạn

Một coding agent sửa được lỗi trong terminal chưa chắc đã là nền tảng phù hợp để vận hành một trợ lý nhiều ngày, phục vụ cả nhóm và tiếp tục công việc sau khi container bị khởi động lại. Đó là sự phân biệt mà Earendil đưa ra khi công bố Pi 1.0 cùng Pi Durable: một bên củng cố công cụ lập trình tương tác; bên kia mở ra một runtime thử nghiệm cho ứng dụng agent chạy dài hạn.[1][2]

Điểm đáng chú ý không phải một mô hình AI mới, mà là harness — lớp phần mềm tổ chức việc gọi mô hình, chạy công cụ, lưu hội thoại và quản lý trạng thái. Theo cách Earendil định nghĩa, harness kết hợp storage với bộ máy thực thi một hoặc nhiều hội thoại LLM, cùng các công cụ và môi trường mà công cụ sử dụng.[2]

Phạm vi bài viết: Tổng hợp và phân tích tài liệu chính thức được đọc ngày 01/10/2026. Đây không phải báo cáo benchmark hay kiểm thử triển khai Pi Durable của AIDaLat. Những ví dụ ứng dụng dưới đây là đề xuất kiến trúc, không phải tính năng đã tích hợp sẵn trên website.

1. Pi 1.0 là gì?

Pi là một agent harness tối giản, thường được dùng như coding agent trong terminal. Người dùng có thể điều chỉnh nó bằng extension, skill, prompt template và theme, thay vì phải tuân theo một quy trình cố định do sản phẩm áp đặt.[5]

Trong thông báo 1.0, Earendil mô tả Pi là phần mềm đã được cải thiện và làm cứng qua nhiều tháng phản hồi từ cộng đồng, đạt mức ổn định để cá nhân và doanh nghiệp dựa vào. Đây là tuyên bố của bên phát triển, không phải chứng nhận độc lập về độ tin cậy.[1]

Pi cung cấp bốn cách sử dụng: giao diện terminal tương tác, chế độ print/JSON cho script, RPC qua stdin/stdout và SDK để nhúng vào ứng dụng.[5] Vì vậy, gọi Pi là “một CLI viết code” không sai, nhưng chưa đầy đủ: nó cũng cung cấp các điểm tích hợp để xây dựng workflow riêng.

Những bổ sung đáng chú ý của bản 1.0

Thông báo chính thức liệt kê các thay đổi sau:[1]

Codemode: hỗ trợ MCP native và làm việc với các loại mô hình ngoài LLM hội thoại, chẳng hạn mô hình phân loại và tạo ảnh.
Virtual models qua extension: cho phép mở rộng cách biểu diễn và điều phối mô hình.
Deferred tool loading: bổ sung khả năng nạp công cụ trì hoãn.
Cache warming cho mô hình Anthropic.
System message giữa hội thoại: thay đổi prompt và công cụ có nhận biết transcript.
Theme TUI mới, với chế độ toàn màn hình mặc định.

Đáng chú ý, triết lý tối giản không có nghĩa Pi bất biến. Nhóm phát triển cho biết họ chỉ đưa một khả năng vào lõi sau khi cân nhắc giá trị thực tế so với độ phức tạp mà nó tạo ra.[1]

2. Từ “No MCP” đến Codemode: Pi đã đổi hướng thế nào?

Đây là điểm dễ gây nhầm nếu chỉ đọc các bài giới thiệu cũ. Trang chủ Pi được truy xuất trong quá trình viết vẫn có mục “No MCP”, hướng người dùng tới CLI hoặc extension. Nhưng thông báo Pi 1.0 và bài giải thích riêng của Earendil xác nhận MCP nay đã được hỗ trợ trong lõi thông qua Codemode.[5][1][4]

Với nội dung về bản 1.0, bài viết này ưu tiên thông báo phát hành và phần giải thích kỹ thuật mới, đồng thời giữ lại sự không nhất quán trên trang chủ để độc giả biết khi đối chiếu nguồn.

Codemode được mô tả là một sandbox JavaScript nằm ở phía harness, dùng để phối hợp các lời gọi công cụ. Thay vì chỉ trả từng kết quả về cho LLM, agent có thể viết mã kết hợp công cụ, xử lý dữ liệu và điều khiển thứ tự thực thi. Trạng thái của Codemode được quản lý trong session transcript, không chỉ dựa vào filesystem.[4]

Theo Earendil, việc tích hợp MCP gắn với những nhu cầu rộng hơn: công cụ có metadata phù hợp, khả năng khám phá công cụ và dữ liệu trả về có cấu trúc. Nhóm vẫn phê bình các MCP server chủ yếu trả văn bản và khó kết hợp với nhau; họ không coi việc thêm MCP là đã giải quyết xong bài toán orchestration.[4]

Góc nhìn AIDaLat: Đây là bước chuyển từ tranh luận “CLI hay MCP” sang câu hỏi thiết thực hơn: agent có thể tìm đúng công cụ và xử lý kết quả hiệu quả hay không? Giá trị của giao thức nằm ở cách harness sử dụng nó, không chỉ ở số lượng kết nối.

3. Pi Durable không phải Pi 1.0 chạy trên cloud

Earendil nhấn mạnh Pi Durable không thay thế Pi coding agent. Đây là framework để xây dựng các ứng dụng agent nói chung, chia sẻ một phần mã và triết lý tối giản, dễ tùy biến với Pi; mục tiêu là hỗ trợ hội thoại và tác vụ dài hạn, nhiều bề mặt tương tác và nhiều người cùng điều khiển.[2]

Pi coding agent vẫn tập trung vào tình huống một người điều khiển agent trong terminal trên máy cục bộ hoặc máy từ xa. Nếu tiến trình chết, người dùng xem lại và yêu cầu tiếp tục. Pi Durable đưa việc quản lý vòng đời và khôi phục vào runtime.[2]

Tiêu chí	Pi 1.0	Pi Durable
Vai trò chính	Coding agent và harness tương tác	Framework xây dựng ứng dụng agent dài hạn
Trạng thái công bố	Bản ổn định theo Earendil	Thử nghiệm, API có thể thay đổi
Điểm xuất phát	Terminal, người dùng trực tiếp điều khiển	Conversation, task, storage và trạng thái ứng dụng
Khi tiến trình chết	Người dùng xem lại và yêu cầu tiếp tục	Mở lại storage, tìm task chưa hoàn tất và khôi phục theo checkpoint
Phối hợp người dùng	Trải nghiệm coding agent	Nhiều client theo dõi, gửi tiếp lời nhắn và steer cùng hội thoại
Quan hệ giữa hai sản phẩm	Tiếp tục phát triển độc lập	Không thay thế Pi; bài học có thể quay lại coding agent

Các khác biệt trên được tổng hợp từ thông báo phát hành và bài giới thiệu Pi Durable.[1][2]

4. Bên trong Pi Durable: điều gì khiến agent “bền” hơn?

Checkpoint cho từng bước, không chỉ lưu lịch sử chat

Trong Pi Durable, các hoạt động như gọi mô hình, chạy công cụ và compaction được tổ chức thành task. Task lưu checkpoint trước khi chuyển bước; tiến trình mới có thể mở cùng storage, tìm việc chưa hoàn tất và tiếp tục từ checkpoint đã lưu.[2]

Nếu một request tới mô hình bị cắt ngang, runtime gửi lại request; phần trả lời dang dở vẫn nằm trong transcript với dấu hiệu bị hủy. Nếu tool bị ngắt, quyết định chạy lại phụ thuộc vào việc tool có được khai báo an toàn để replay hay không.[2]

Điều này quan trọng vì “tiếp tục một hội thoại” và “khôi phục đúng công việc đang làm” là hai bài toán khác nhau. Transcript giúp hiểu quá khứ; checkpoint giúp runtime biết bước nào cần được xử lý tiếp.

Tách nơi điều phối khỏi nơi chạy công cụ

Pi Durable có các storage backend memory, SQLite và JSONL, đồng thời cung cấp bộ kiểm tra tương thích cho backend tự viết. Execution environment cũng có interface riêng: harness có thể ở một máy trong khi công cụ thực thi trên máy khác; từng hội thoại có thể dùng môi trường làm việc khác nhau.[2]

Bản SQLite chỉ giữ working set trong RAM, gồm transcript đang hoạt động, task đang chạy và submission đang chờ. Dữ liệu khác nằm trên đĩa tới khi cần đọc; context được compaction khi tiến gần giới hạn của mô hình.[2]

Tách biệt này gợi mở kiến trúc một lớp điều phối trung tâm kết nối nhiều sandbox. Tuy nhiên, đó là hướng xây dựng ứng dụng, không phải lời khẳng định mọi backend hoặc sandbox đã có sẵn.

Hội thoại dài, phân nhánh và nhiều client

Một harness có thể chạy nhiều conversation đồng thời. Conversation mới có thể fork từ một điểm trong transcript của conversation cha và nhìn thấy lịch sử tới điểm đó mà không phải sao chép toàn bộ. Ví dụ Earendil đưa ra là một kênh Slack và các thread tách nhánh từ tin nhắn trong kênh.[2]

Compaction chạy như một task nền, tóm tắt phần lịch sử cũ trước khi context vượt giới hạn; các tin nhắn gốc vẫn được lưu trong storage. “Hội thoại dài” vì thế không đồng nghĩa mô hình luôn đọc nguyên vẹn mọi tin nhắn từ đầu.[2]

Nhiều client có thể nhận trạng thái hiện tại rồi theo dõi các thay đổi: transcript, nội dung đang stream, công cụ đang chạy, tin nhắn chờ và usage. Client tham gia muộn hoặc kết nối lại bắt đầu từ trạng thái hiện tại; người dùng có thể steer agent đang làm việc.[2]

Trạng thái ứng dụng và extension cũng tham gia cơ chế durability

Todo, kế hoạch hoặc ticket có thể được biểu diễn bằng document JSON có kiểu, lưu cạnh transcript và cập nhật trong cùng atomic commit. Mục tiêu là tránh tình trạng hội thoại đã ghi một thay đổi nhưng trạng thái ứng dụng lại chưa phản ánh thay đổi đó.[2]

Extension có thể đóng gói system prompt, tool, hook và task. Registry có thể thay extension khi agent đang chạy: tool call đã bắt đầu hoàn thành bằng mã cũ, còn lần gọi tiếp theo sử dụng mã mới.[2]

Góc nhìn AIDaLat: Khả năng này hấp dẫn với ứng dụng vận hành lâu dài, nhưng cũng đòi hỏi nhà phát triển quản lý phiên bản, tương thích dữ liệu và quyền hạn cẩn thận. Thay mã trong lúc chạy không tự động loại bỏ rủi ro thay đổi hành vi.

5. “Durable” không có nghĩa bất tử hay exactly-once cho mọi hành động

Đây là phần cần đọc trước khi thử nghiệm production.

Thứ nhất, requestId chống submission trùng không bảo đảm mọi side effect chỉ xảy ra một lần. Earendil mô tả submission có requestId là exactly-once: client retry nhận lại submission ban đầu. Nhưng tool có thể được replay hoặc báo bị ngắt tùy chính sách; ví dụ thanh toán trong tài liệu vẫn dùng khóa idempotency ở hệ thống thanh toán.[2]

Với các hành động như đăng bài, gửi email, deploy hoặc chuyển tiền, ứng dụng nên dùng khóa idempotency, lưu ID kết quả từ dịch vụ ngoài và đối chiếu trạng thái trước khi retry. Đây là khuyến nghị thiết kế của AIDaLat, không phải cơ chế tự động được bảo đảm cho mọi tool.

Thứ hai, process crash khác mất điện hoặc hỏng host. README của storage SQLite Node ghi adapter sử dụng WAL với synchronous = NORMAL: commit đã được xác nhận sống sót qua process crash, nhưng các commit mới nhất có thể mất khi có sự cố nguồn điện hoặc host. Với JSONL, tùy chọn fsync mặc định là false.[3]

Thứ ba, một storage có một owner ghi. README quy định một owner phải tuần tự hóa ghi cho SQLite hoặc JSONL; không hỗ trợ cấp phát ID xuyên tiến trình, và JSONL không có cross-process locking. Nhiều client cùng theo dõi không đồng nghĩa nhiều tiến trình được tự do ghi chung một storage.[3]

Thứ tư, Cloudflare Durable Objects không phải Cloudflare D1. SQLite core có thể dùng adapter cho môi trường đồng bộ như Bun hoặc Durable Objects. D1 là API bất đồng bộ từ xa nên không thể trực tiếp triển khai facade đồng bộ đó; muốn dùng D1 cần một Storage backend riêng.[3]

Cuối cùng, Pi Durable vẫn experimental. Earendil cảnh báo API có thể tiếp tục thay đổi.[2] README được đọc cho bài còn tập trung nhiều vào contract và adapter storage, trong khi bài giới thiệu mô tả runtime rộng hơn.[3][2] Khi xây dựng, nên đối chiếu đúng phiên bản package và ví dụ tương ứng, không coi mã trên nhánh main là hợp đồng bất biến.

6. Ứng dụng thực tế: chọn Pi nào?

Chọn Pi 1.0 nếu mục tiêu chính là một coding agent trong terminal, có thể nhúng vào script hoặc ứng dụng và tùy biến bằng extension.[1][5]

Đánh giá Pi Durable nếu ứng dụng cần sống lâu hơn một phiên tương tác, khôi phục task sau restart, quản lý trạng thái gắn với hội thoại hoặc cho nhiều người cùng theo dõi và điều hướng agent.[2]

Với một tòa soạn AI như AIDaLat, một hướng thử nghiệm hợp lý là workflow nghiên cứu và biên tập:

Tạo conversation cho mỗi đề tài.
Giao các task đọc nguồn, trích dữ kiện và soạn bản nháp.
Lưu trạng thái biên tập cùng hồ sơ nguồn bằng document.
Cho biên tập viên tham gia để yêu cầu bổ sung hoặc đổi góc tiếp cận.
Giữ bước xuất bản dưới cơ chế phê duyệt và chống đăng trùng.

Đây là kịch bản kiến trúc đề xuất, chưa phải pipeline đã được AIDaLat triển khai hay kiểm chứng trên Pi Durable. Khả năng phục hồi chỉ có ý nghĩa nếu đi cùng lưu trữ bền, quản lý quyền công cụ và kiểm soát tác động bên ngoài.

7. Cách bắt đầu

Trang Pi cung cấp cách cài coding agent qua npm:[5]

npm install -g --ignore-scripts @earendil-works/pi-coding-agent

Để thêm các package phục vụ xây dựng với Pi Durable vào một dự án Node/TypeScript, thông báo chính thức hướng dẫn:[1][2]

npm install @earendil-works/pi-durable @earendil-works/pi-ai @earendil-works/chord

Cài package không đồng nghĩa đã có một dịch vụ agent hoàn chỉnh. Với Durable, hãy bắt đầu từ README, ví dụ trong repository và một thử nghiệm nhỏ: task đọc dữ liệu, lưu trạng thái, dừng tiến trình rồi mở lại storage. Chỉ sau đó mới cân nhắc tool có side effect, sandbox và tích hợp nhiều người dùng.

Hai sản phẩm được Earendil công bố dưới giấy phép MIT.[1] Giấy phép mã nguồn không có nghĩa việc gọi mô hình hay vận hành hạ tầng là miễn phí.

Kết luận

Pi 1.0 và Pi Durable giải quyết hai nhu cầu liên quan nhưng khác nhau: một công cụ tương tác ổn định hơn cho developer, và một runtime thử nghiệm để xây dựng ứng dụng agent có vòng đời dài hơn terminal.[1][2]

Với AIDaLat, điểm đáng theo dõi nhất là sự dịch chuyển từ “agent gọi được bao nhiêu công cụ” sang “agent quản lý công việc, trạng thái và khôi phục ra sao”. Pi Durable đưa ra các primitive đáng nghiên cứu cho hướng đó; các giới hạn storage, replay và API experimental vẫn là điều kiện bắt buộc phải cân nhắc trước khi vận hành thật.[2][3]

Nói ngắn gọn: Pi 1.0 giúp bạn làm việc với agent; Pi Durable giúp bạn xây một ứng dụng sống lâu cùng agent.

Đọc thêm trên AIDaLat: Xây dựng AI Agent với Astro và Cloudflare.

Sources

[1] https://earendil.com/posts/pi-1-0 [2] https://earendil.com/posts/pi-durable [3] https://raw.githubusercontent.com/earendil-works/pi/main/packages/durable/README.md [4] https://earendil.com/posts/you-said-no-mcp [5] https://pi.dev