- Tác giả Mario đã phát triển
Pi, mộtagentmã hóa tối giản và có khả năng tự sửa đổi, do thất vọng với các công cụ AI hiện có nhưClaude CodevàOpenCodevì chúng kém tin cậy, thiếu khả năng quan sát và mở rộng, đồng thời quản lýcontextkém hiệu quả. Piđược thiết kế để thích ứng với quy trình làm việc của nhà phát triển thông qua một lõi cơ bản, hệ thốngextensionmạnh mẽ và khả nănghot reload, cho phépagenttự sửa đổi và được tùy chỉnh hoàn toàn.- Tác giả cảnh báo rằng các
agent AI("clankers") đang phá hủy các dự ánmã nguồn mởbằng cách tạo ra mã chất lượng thấp và sự phức tạp không cần thiết, học hỏi từ các mã nguồn cũ và tạo ra cácabstractionlồng ghép mà không có sự kiểm soát của con người, dẫn đến "độ phức tạp cấp doanh nghiệp" một cách nhanh chóng.
Building pi in a World of Slop — Mario Zechner
- Vấn đề với công cụ AI hiện tại: Các công cụ phát triển
agent AIban đầu nhưClaude Codegặp các vấn đề như thiếu ổn định, quản lýcontextkém (agent kiểm soát context thay vì người dùng), thiếu khả năng quan sát và khả năng mở rộng hạn chế. - Bài học từ
Terminal Bench: Cácbenchmarkcho thấy cácharness agentđơn giản nhất (chỉ cung cấptoolgửikeystroketớitmux) thường đạt hiệu suất cao nhất, gợi ý rằngcoding agentsvẫn đang trong giai đoạn thử nghiệm và hình thức đơn giản có thể hiệu quả hơn. - Nhu cầu
Agentcó thể điều chỉnh: Cần có nhữngagentcó thể tự sửa đổi và thích nghi với quy trình làm việc của người dùng (tunable agents) thay vì buộc người dùng phải tuân theo cách củaagent. - Thiết kế
Pitối giản và mở rộng:Piđược xây dựng với một lõi tối thiểu (lớp trừu tượngAI,agent core,framework,coding agent) và chỉ bốntoolcơ bản (read,write,edit,bash), nhưng được thiết kế siêu mở rộng thông qua cácextension. - Cơ chế tự tùy chỉnh qua
extension:Pisử dụng cácTypeScript modulelàmextensionđể thêm chức năng, định nghĩatooltùy chỉnh, lắng nghe sự kiện và kiểm soát hoàn toàn hoạt động củaagent, cho phépagenttự sửa đổi dựa trên tài liệu và ví dụ mã. - Tận dụng hệ sinh thái hiện có: Thay vì tạo ra các "marketplace" mới,
Pikhuyến khích sử dụng cácpackage managerhiện có nhưnpmhoặcGitHubđể tìm kiếm và chia sẻ cácextension. - Lợi ích của
Hot Reload: Khả nănghot reloadcho phép nhà phát triểnextensionlặp lại nhanh chóng và xem ngay các thay đổi trong phiên làm việc, cải thiện đáng kể tốc độ phát triển. - Nguy cơ từ
Agent AItrongMã nguồn mở: Cácagent AI("clankers") tạo ra cácpull requestvàissuerác rưởi, làm quá tải người duy trì dự ánmã nguồn mởvà làm giảm chất lượngcodebasebằng cách chèn sự phức tạp không cần thiết và mã lặp lại học được từ dữ liệu huấn luyện chất lượng thấp.
Agent— Tác nhân (AI)Context Handling— Xử lý ngữ cảnhExtensibility— Khả năng mở rộngHarness— Khung điều khiển/Công cụ quản lý tác nhânBenchmark— Đánh giá hiệu suấtOpen Source Software (OSS)— Phần mềm mã nguồn mởExtension— Tiện ích mở rộngHot Reload— Tải lại nóngClanker— (Từ lóng) Tác nhân AI phá hoại/gây rácEnterprise-grade complexity— Độ phức tạp cấp doanh nghiệp
Giới thiệu
Tôi là Mario, tôi xây dựng Pi trong một thế giới hỗn độn và đây là một chiến lược, một bi kịch trong ba hồi. Chỉ để nói nhanh về điều này: một số người trên internet đã trả tiền cho tôi để đặt quảng cáo trên áo của tôi và tất cả số tiền đó sẽ được quyên góp cho một tổ chức từ thiện. Vâng, cảm ơn mọi người.
Hồi 1: Xây dựng Pi
Động lực xây dựng Pi
Thuở ban đầu, có Claude Code và nó rất tốt, phải không? Tất cả chúng ta đều bị cuốn hút bởi nó và ngừng ngủ. Tôi không chắc có gì trước đó không, nhưng Claude Code là thứ khiến tôi hứng thú nhất. Và trước khi nói tất cả những điều này, tôi yêu đội ngũ Claude. Họ là những người tài năng, xuất sắc và có tốc độ phát triển cực cao, vì vậy họ cũng đã tạo ra toàn bộ trò chơi này – xin gửi lời khen ngợi lớn đến họ. Vậy đây không phải là một lời chỉ trích nữa, đây chỉ là tôi, một ông già, kể cho bạn nghe lý do tại sao tôi ngừng sử dụng Claude Code và tự xây dựng thứ của riêng mình.
Vào khoảng tháng 4 năm 2025, tôi bắt đầu sử dụng Claude Code, nhờ Peter, vì anh ấy nói với chúng tôi rằng các tác nhân đang hoạt động. Và hồi đó, nó đơn giản, dễ đoán và phù hợp với quy trình làm việc của tôi. Nhưng cuối cùng, tôi nghĩ rằng token madness đã xâm chiếm họ, đội ngũ lớn hơn và họ bắt đầu dog fooding (tự dùng sản phẩm của mình) và xây dựng rất nhiều tính năng mà tôi không cần – điều này không sao cả, tôi có thể bỏ qua chúng. Nhưng cùng với tốc độ và nhiều tính năng hơn, đi kèm với nhiều lỗi hơn. Và điều đó thật tệ, vì tôi từng làm việc tại các công trường xây dựng, và nếu cái búa của tôi hỏng mỗi ngày, tôi sẽ rất tức giận. Tương tự, nếu các development tool của tôi hỏng mỗi ngày, tôi cũng sẽ tức giận.
Vì vậy, có một trò đùa dai dẳng này, và đây là Tariq nói với chúng tôi rằng Claude Code giờ đây là một game engine, và đây là Mitchell từ Ghost giải thích chi tiết cho chúng tôi: "Không, không phải vậy." Và cuối cùng họ đã sửa lỗi nhấp nháy, nhưng sau đó những thứ khác lại hỏng, và tôi nghĩ họ đang ở bản thứ ba của TUI renderer (công cụ kết xuất giao diện người dùng văn bản). Vâng, nhưng đó chỉ là triệu chứng. Vấn đề thực sự là context của tôi không phải là context của tôi. Claude Code là thứ kiểm soát context của tôi. Và sau lưng tôi, Claude Code làm những điều với context.
Vì vậy, có vấn đề về hệ thống, nó thay đổi trên mỗi bản phát hành, bao gồm cả các định nghĩa tool. Họ sẽ loại bỏ tool, sửa đổi tool. Điều đó không tốt. Họ sẽ chèn các system reminders (lời nhắc hệ thống) vào phần lớn nội dung context của bạn ở một vị trí không phù hợp, nói với mô hình: "Đây là một số thông tin, nó có thể hoặc không liên quan đến những gì bạn đang làm." Nó thực sự nói rằng nó có thể hoặc không liên quan đến những gì bạn đang làm. Và điều đó đã làm mô hình bị nhầm lẫn và làm hỏng các quy trình làm việc của tôi.
Trên hết, không có khả năng quan sát (observability) nào cả vì đó là cách TUI được xây dựng, và tôi thích biết tác nhân của mình đang làm gì. Không có lựa chọn mô hình nào, điều này rõ ràng. Đó là harness (công cụ điều khiển) Anthropic gốc nên họ muốn bạn sử dụng Claude, phải không? Và hầu như không có khả năng mở rộng nào. Một số bạn có thể đã viết một số hook cho Claude Code, nhưng tôi nói cho bạn biết, có một số hook và độ sâu của những hook đó rất nông cạn. Mỗi khi một hook được kích hoạt, điều thực sự xảy ra là một quy trình mới được tạo ra. Về cơ bản, lệnh bạn đã chỉ định cho tool được thực thi, và tôi không thấy điều đó hiệu quả một cách cụ thể.
Tìm kiếm giải pháp thay thế
Vì vậy, tôi lùi lại một bước và tìm kiếm các lựa chọn thay thế. Tôi muốn đặc biệt nhắc đến AMP và FactoryTried. Chúng là Porsche và Lamborghini của các harness agent mã hóa. Nếu bạn có thể chi trả, hãy sử dụng chúng. Chúng đang ở tiền tuyến, chúng thực sự tốt và các đội ngũ của chúng thật tuyệt vời. Ngoài ra còn có một loạt các lựa chọn khác.
Tôi có kinh nghiệm trong OSS (mã nguồn mở) nên đương nhiên tôi bị thu hút bởi OpenCode. Một lần nữa, đội ngũ xuất sắc, tốc độ thực thi siêu nhanh và họ không bán cho bạn hype (sự thổi phồng), họ bán cho bạn những tool hoạt động tốt trong hầu hết các trường hợp.
Phân tích OpenCode
Tôi bắt đầu tìm hiểu sâu về OpenCode, quay trở lại vấn đề context handling vì đó là phần quan trọng nhất đối với tôi. Và tôi đã tìm thấy một số điều như: trong một số điều kiện nhất định, OpenCode sẽ chỉ cắt bớt đầu ra tool sau một lượng mã thông báo (token) tối thiểu cụ thể, và về cơ bản, điều đó làm hỏng mô hình.
Ngoài ra còn có hỗ trợ LSP server, có nghĩa là mỗi khi mô hình của bạn gọi edit tool, OpenCode sẽ truy cập LSP server khác đã được kết nối, hỏi xem có lỗi nào không và nếu có, nó sẽ kiểm tra điều đó như một phần của kết quả edit tool. Điều này rất tệ, hãy nghĩ về cách bạn chỉnh sửa mã. Bạn không viết một dòng mã, kiểm tra lỗi, viết dòng tiếp theo, kiểm tra lỗi. Bạn không làm vậy, bạn hoàn thành công việc của mình và sau đó bạn kiểm tra lỗi. Điều này đã làm mô hình bị nhầm lẫn.
Có một số điều khác như lưu trữ các tin nhắn riêng lẻ của một phiên trong một tệp JSON. Mỗi tin nhắn là một tệp JSON trên đĩa. Có một điều này, và điều này xảy ra với tất cả chúng ta, không có ý chỉ trích, nhưng thật không hay nếu theo mặc định, một server khởi động, các CORS header được đặt theo cách mà bất kỳ trang web nào mà trình duyệt OpenCode của bạn có thể truy cập giờ đây đều có thể truy cập server OpenCode của bạn.
Tiêu chuẩn và kết quả đánh giá
Hoàn toàn không liên quan đến tất cả những điều này, tôi bắt đầu tìm hiểu các benchmark (đánh giá hiệu suất) cho các harness agent mã hóa và tìm thấy Terminal Bench, một benchmark khá tốt, xét mọi khía cạnh. Và điều thú vị là nó là thứ tối giản nhất bạn có thể nghĩ đến. Tất cả những gì nó cung cấp cho mô hình là một tool để gửi các keystroke (phím bấm) đến một phiên tmux và đọc đầu ra của phiên tmux. Không có file tool, không có sub agent, không có bất kỳ thứ gì như vậy. Và nó là một trong những harness hoạt động tốt nhất trong bảng xếp hạng (leaderboard). Đây là bảng xếp hạng từ tháng 12 năm 2025. Bất kể model family (họ mô hình) nào, Terminal luôn đạt điểm cao hơn, thậm chí chủ yếu cao hơn cả harness gốc của mô hình đó.
Vậy điều đó nói lên điều gì với chúng ta? Hai luận điểm chính là: chúng ta đang ở trong giai đoạn thử nghiệm (fuck around and find out phase) của coding agents và hình thức hiện tại không phải là hình thức cuối cùng của chúng, đúng không?
Hai luận điểm chính
Luận điểm thứ hai là: chúng ta cần những cách tốt hơn để thử nghiệm. Và đối với tôi, điều đó có nghĩa là các tác nhân có thể tự sửa đổi, có thể điều chỉnh (tunable agents), những thứ mà bản thân tác nhân có thể sửa đổi và tôi có thể sửa đổi tùy theo quy trình làm việc của mình.
Giới thiệu Pi: Tác nhân tự điều chỉnh
Vì vậy, tôi đã loại bỏ tất cả mọi thứ, xây dựng một lõi tối thiểu nhưng làm cho nó siêu mở rộng và khiến tác nhân có thể tự sửa đổi. Với một số tiện nghi nhỏ, nó không hoàn toàn thô sơ. Vậy đó là Pi. Nó là một tác nhân thích nghi với quy trình làm việc của bạn thay vì ngược lại.
Nó đi kèm với bốn gói:
- Gói
AIvề cơ bản chỉ là một lớp trừu tượng trên các nhà cung cấp vàcontext handlinggiữa các nhà cung cấp. - Một
agent core, chỉ là một vòng lặpwhilevàtool calling. - Tôi xuất thân từ phát triển trò chơi nên tôi đã xây dựng một
framework(khung làm việc) thực sự không nhấp nháy quá nhiều. - Và bản thân
coding agent.
Đây là system prompt của Pi. Chỉ có vậy. Cuối cùng, ngành công nghiệp đã tạo ra một tiêu chuẩn mới gọi là skills, về cơ bản chỉ là các tệp Markdown. Vì vậy, chúng tôi cũng đã thêm điều đó và nó cần được đưa vào system prompt. Do đó, chúng tôi miễn cưỡng phải thêm một vài dòng nữa.
Cơ chế tự tùy chỉnh và khả năng mở rộng của Pi
Và cuối cùng, đây là điều kỳ diệu giúp Pi có khả năng tự sửa đổi. Chúng tôi đã xuất bản tài liệu, được tôi và một tác nhân biên soạn thủ công, cùng với các ví dụ mã về extension (tiện ích mở rộng). Tất cả những gì chúng tôi cần làm để tác nhân tự sửa đổi là nói với nó: "Đây là tài liệu. Đây là một số mã cho bạn thấy cách tự sửa đổi bằng cách viết extension."
Nó đi kèm với bốn tool. Chỉ có vậy. Read, write, edit, bash. Đây là các định nghĩa tool. Đừng đọc văn bản, chỉ nhìn vào kích thước. Thế thôi. Đây là những gì xảy ra khi bạn bắt đầu một phiên mới trong một trong những tool này.
Vấn đề là, các mô hình thực sự được đào tạo bằng học tăng cường (reinforcement trained) đến mức chúng không biết coding agent là gì. Bởi vì các coding agent harness về cơ bản là những gì chúng được đào tạo khi chúng được post-trained. Bạn không cần 10.000 mã thông báo để nói với chúng rằng bạn là một coding agent. Chúng biết điều đó vì giờ đây chúng là coding agents.
Pi cũng có rất nhiều mặc định vì nhu cầu bảo mật của tôi khác với bạn. Và tôi không nghĩ một hộp thoại nhỏ bật lên mỗi khi bạn gọi bash, yêu cầu bạn phê duyệt, là một cơ chế bảo mật thông minh. Thay vào đó, tôi cung cấp cho bạn nhiều lựa chọn đến mức bạn có thể xây dựng bất cứ thứ gì phù hợp với nhu cầu bảo mật cụ thể của mình.
Ngoài ra còn có những thứ không được tích hợp sẵn. Tôi là một kẻ ngoại đạo vì đây là cách tôi làm. Nhưng nếu bạn không thích điều đó, thì bạn chỉ cần yêu cầu Pi xây dựng cho bạn hỗ trợ sub agent ở plan mode hoặc hỗ trợ MCP, bất cứ điều gì bạn cần.
Vì vậy, trách nhiệm đi kèm với một số table stakes (yếu tố cơ bản) và sau đó là bản thân các extension. Các extension chỉ đơn giản là các TypeScript module. Trong trường hợp đơn giản nhất, một tệp TypeScript trên đĩa, bạn chỉ đường cho Pi đến đó. Đây là một extension được tải như một phần của harness. Và với điều đó, bạn về cơ bản có một extension API cho phép bạn kết nối vào mọi thứ và định nghĩa những thứ mà harness sẽ hiển thị cho mô hình. Và điều đó bao gồm các tool / phím tắt lệnh. Bạn có thể lắng nghe bất kỳ loại sự kiện nào và phản ứng, sau đó lưu trạng thái trong phiên mà tùy chọn được cung cấp cho tác nhân hoặc được lưu trữ ở đó cho các tool phân tích phiên như một phần của các quy trình làm việc tổ chức. Bạn có thể thực hiện compaction tùy chỉnh, các nhà cung cấp tùy chỉnh và kiểm soát hoàn toàn các tool. Bạn có thể sửa đổi mọi thứ trong Pi. Và sau đó bạn có thể gói tất cả lại và đưa lên npm hoặc trên GitHub vì tôi nghĩ nếu chúng ta không cần phát minh lại một loạt các kho chứa khác gọi là marketplace, chúng ta đã có các package manager (trình quản lý gói).
Và tất cả đều hot reload (tải lại nóng). Vì vậy, nếu bạn phát triển một extension cho Pi, bạn thực hiện trong phiên và bạn hot reload các thay đổi và thấy ngay các hiệu ứng của nó, điều này rất tuyệt vời. Và đó cũng là những thứ trong phát triển trò chơi. Trong phát triển trò chơi, bạn muốn tốc độ lặp lại rất cao, rất thấp. Và điều đó thật tuyệt.
Ví dụ về các tiện ích mở rộng của Pi
Một vài ví dụ. Claude hoặc Anthropic có /bytheway, cho phép bạn nói chuyện với tác nhân khi nó đang thực hiện nhiệm vụ chính của mình. Tôi đã đăng lời nhắc (prompt) nhỏ này lên Twitter một cách đùa cợt và ai đó đã xây dựng nó trong năm phút với nhiều tính năng hơn. Và họ không cần phải fork hoặc clone Pi. Họ chỉ để tác nhân viết extension dựa trên lời nhắc.
Đây là Nico, một trong những người viết extension sung mãn nhất. Tôi không biết chuyện quái gì đang xảy ra ở đây. Đó là một phòng trò chuyện cho tất cả các tác nhân Pi của anh ấy và chúng nói chuyện với nhau. Tôi sẽ không bao giờ sử dụng cái này, nhưng tất cả đều là tùy chỉnh, bao gồm cả UI (giao diện người dùng). Hoặc bạn có thể chơi game Nest. Hoặc bạn có thể chơi Doom. Và còn một loạt các ví dụ khác mà tôi sẽ không nói đến.
Vậy làm thế nào để xây dựng một Pi extension? Bạn không cần phải làm. Bạn yêu cầu Pi xây dựng nó cho bạn dựa trên các thông số kỹ thuật của bạn. Và sau đó bạn chỉ cần lặp lại với nó và hot reload trong phiên. Chúng ta sẽ bỏ qua ví dụ đó.
Tìm kiếm và chia sẻ tiện ích mở rộng
Và nếu bạn không thích tự xây dựng mọi thứ – và tôi hy vọng bạn thích tự xây dựng mọi thứ – nhưng nếu không, bạn có thể tìm trên npm hoặc tìm kiếm nhỏ của chúng tôi. Và sau đó bạn có thể tìm thấy giao diện trên npm để tìm các bản vá cho sub agents, MCP, v.v.
Triết lý và hiệu suất của Pi
Vậy nó có thực sự hoạt động không? Vâng, đây là bảng xếp hạng Terminal Bench từ tháng 10 trước khi Pi có bản vá. Tôi đã thêm nó cho việc Peter's class thingy. Nó có sáu lượt chơi. Nhưng tất cả những điều này thực ra không phải về Pi. Nếu bạn muốn đọc nó, về cơ bản tôi muốn bạn kiểm soát các tool và quy trình làm việc của mình. Vì vậy, hãy tự xây dựng lấy. Và nếu bạn muốn biết thêm về Pi và OpenClaw, hãy đến buổi nói chuyện này.
Hồi 2: Mã nguồn mở trong kỷ nguyên của "Clanker"
Tác động của tác nhân AI đến dự án mã nguồn mở
Và rồi Peter đã làm việc đó, anh ấy đặt Pi vào bên trong OpenClaw. Đó là một "vòi bạch tuộc" (tentacle), có nghĩa là dự án mã nguồn mở của tôi trở thành mục tiêu của rất nhiều OpenClaw instances mà người dùng của chúng không hề hay biết.
Vậy đây là hồi hai: OSS trong kỷ nguyên của clankers. Clankers đang phá hủy OSS. Đây là Seal Raw, đã đóng issue và pull request tracker. Đây là tracker của OpenClaw. Đây là của tôi. Một nửa trong số đó là các OpenClaw instances đăng rác rưởi.
Chống lại các "Clanker"
Vì vậy, tôi bắt đầu nổi giận với clankers. Nếu bạn gửi một pull request, nó sẽ tự động bị đóng với một bình luận yêu cầu bạn vui lòng viết một issue tử tế bằng giọng điệu con người, không còn là một màn hình đầy văn bản nữa. Và nếu tôi thấy điều đó, phải không, "trông tốt đối với tôi" và tên tài khoản của bạn sẽ được đưa vào một tệp trong kho lưu trữ (repository) và lần tới khi bạn gửi một pull request, nó sẽ được chấp nhận. Clankers không đọc bình luận đó. Chúng không quay lại một khi đã đăng một pull request. Vì vậy đó là một bộ lọc hoàn hảo.
Câu chuyện về Mitchell và Vouch
Mitchell cuối cùng đã biến thành Vouch. Đây là một clanker.
Tình hình sử dụng tác nhân AI hiện tại và những hệ quả
Tôi đã gắn nhãn cho các vấn đề. Nếu bạn tương tác với open-claw, các vấn đề của bạn sẽ bị giảm ưu tiên. Tôi cũng xây dựng các tool để nhúng các vấn đề và nội dung pull request vào không gian 3D, giúp tôi nhìn thấy các cụm vấn đề. Tôi cũng đã phát minh ra "kỳ nghỉ OSS" – chỉ cần đóng theo dõi bất cứ khi nào tôi muốn, nhờ đó tôi có lại cuộc sống của mình. Vậy, điều này có hiệu quả không? Có, phần nào.
Điều này dẫn tôi đến màn ba: Hãy chậm lại đi. Mọi thứ đều hỏng bét. Và rồi, khi mọi người nói rằng sản phẩm của chúng ta đã được xây dựng 100% bởi các tác nhân. Vâng, chúng ta biết rằng giờ đây nó rất tệ. Xin chúc mừng. Và tôi đang nghe điều này từ các đồng nghiệp của mình, và điều này hoàn toàn không lành mạnh.
Những rủi ro khi làm việc với tác nhân AI
Vậy đây là cách chúng ta không nên làm việc với các tác nhân và lý do, ít nhất là theo ý kiến của tôi. Tôi đã viết điều này trên blog của mình cách đây một thời gian. Nhưng ý chính là, chúng ta có rất nhiều tác nhân đang hoạt động mà bạn không biết rằng về cơ bản chúng không thể gỡ cài đặt được. Các phần mềm độc hại (malware) và Anthropic đã xây dựng một trình biên dịch C. Nó có vẻ hoạt động, nhưng thực tế lại không. Và chúng ta đang hy vọng thế hệ mô hình tiếp theo sẽ khắc phục được nó. Và đây là Cursor đang xây dựng một trình duyệt. Và cái đó cũng rất tệ hại. Nhưng thế hệ tiếp theo sẽ khắc phục nó. Và Saz đã chết. Phần mềm sẽ trở nên lỗi thời trong sáu tháng. Và bà tôi vừa tự xây dựng cho mình một Spotify với open-claw của bà ấy. Thôi nào mọi người!
Vậy, các tác nhân thực chất đang kết hợp những "boo-boo" (là từ tôi dùng để chỉ lỗi) với việc học nối tiếp, không có nút thắt cổ chai và nỗi đau trì hoãn. Nỗi đau trì hoãn đó là dành cho bạn. Hãy xem cơ sở mã của bạn với một người, một tác nhân và mười tác nhân. Bạn có thể xem xét bao nhiêu mã do tác nhân tạo ra? Đây là cùng một cơ sở mã được biểu thị bằng số lượng "boo-boo" mỗi ngày. Bạn nghĩ mình sẽ tìm thấy bao nhiêu "boo-boo" trong số đó? Sau đó bạn nói, "Ồ, tôi có một tác nhân đánh giá." Hãy để tôi giới thiệu cho bạn thế giới tuyệt vời của Ouroboros (rắn tự ăn đuôi). Nó không hoạt động. Nó chỉ bắt được một số vấn đề. Vấn đề là các tác nhân là những "thương nhân" của sự phức tạp đã học được.
Chúng học sự phức tạp đó từ đâu? Từ internet. Có gì trên internet? Toàn bộ mã nguồn cũ rích của chúng ta. Có một vài viên ngọc quý trên internet, những hệ thống được thiết kế thực sự tốt. Nhưng 90% mã nguồn trên internet là rác rưởi cũ kỹ của chúng ta. Đó là những gì các mô hình học được. Và mọi quyết định của một tác nhân đều mang tính cục bộ. Đặc biệt nếu cơ sở mã quá lớn đến mức không vừa với cửa sổ ngữ cảnh của nó. Và nếu bạn để nó hoạt động tự do, thêm các tầng trừu tượng (abstractions) ở khắp mọi nơi mà chúng lại lồng ghép vào nhau. Thế là có rất nhiều tầng trừu tượng và sự trùng lặp, và cả khả năng tương thích ngược (backwards compatibility). Ai đã thấy điều đó trong kết quả đầu ra của tác nhân của họ? Nó thật khó chịu, hoặc là "phòng thủ sâu" (defense in depth) không cần thiết. Vậy đó, bạn sẽ nhận được sự phức tạp cấp độ doanh nghiệp (enterprise-grade complexity) chỉ trong hai tuần, với chỉ hai người và mười tác nhân. Xin chúc mừng.
Và rồi bạn nói, "Nhưng spec chi tiết của tôi thì sao?" Vâng, chắc chắn rồi. Bạn có biết chúng ta gọi một spec đủ chi tiết là gì không? Nó là một chương trình. Vậy nếu bạn để trống các phần trong spec của mình, bạn nghĩ điều gì sẽ xảy ra? Mô hình sẽ điền vào chỗ trống bằng cách nào? Và bằng cái gì? Nó sẽ điền vào bằng những thứ rác rưởi mà nó học được trên internet từ mã cũ của chúng ta. Đó là rác rưởi tái diễn.
Con người so với tác nhân trong chất lượng mã nguồn
Và rồi bạn nói, "Nhưng con người thì sao..." Vâng, con người là những sinh vật kinh khủng, dễ mắc lỗi, nhưng họ có thể học hỏi. Và họ là những nút thắt cổ chai. Chỉ có bấy nhiêu "boo-boo" họ có thể thêm vào cơ sở mã của bạn hàng ngày. Và con người cảm nhận được nỗi đau. Đây là một đặc tính rất thú vị vì con người ghét nỗi đau. Và một khi có quá nhiều nỗi đau, con người có một loạt lựa chọn: Họ có thể nghỉ việc. Họ có thể đổ lỗi cho người khác và bắt họ sửa lỗi. Hoặc mọi người lên kế hoạch để bắt đầu refactoring nhằm dọn dẹp cơ sở mã rác rưởi. Các tác nhân sẽ vui vẻ tiếp tục thêm rác vào cơ sở mã của bạn.
Và giờ đây, các tác nhân của bạn và các hệ thống bộ nhớ siêu phức tạp cũng sẽ không cứu được bạn. Các tác nhân không học theo cách chúng ta học. Những người thân yêu nhất của tôi, tôi thậm chí còn không đọc mã nguồn nữa. Chúc mừng. Có điều gì đó bị hỏng và người dùng của bạn đang la ó. Vậy bạn sẽ gọi ai? Không phải chính bạn, vì bạn chưa đọc mã nguồn. Vì vậy, bạn đang dựa vào các tác nhân của mình, nhưng chúng cũng bị quá tải vì cơ sở mã quá lớn đến mức hoàn toàn không có cơ hội để chúng có được tất cả ngữ cảnh cần thiết để khắc phục vấn đề. Và các cửa sổ ngữ cảnh dài là một hack (giải pháp tạm bợ), như hầu hết các bạn sẽ nhận ra trong năm nay khi mọi người chuyển sang cửa sổ ngữ cảnh một triệu mã thông báo. Và tìm kiếm theo tác nhân cũng thất bại. Vì vậy, tác nhân vá lỗi cục bộ và làm hỏng mọi thứ trên phạm vi toàn cầu. Nếu bạn thấy điều này trong cơ sở mã của mình, bạn tiêu đời rồi. Bạn không thể điều chỉnh cơ sở mã của mình nữa, và cả các kiểm thử cũng không, vì các tác nhân của bạn đã viết các kiểm thử đó. Vậy thì, hết game.
Cách tiếp cận tốt hơn: Phân công nhiệm vụ có phạm vi rõ ràng cho tác nhân
Vậy đây là cách tôi nghĩ chúng ta nên làm việc. Có một loạt các đặc tính cho các tác vụ tác nhân tốt. Điều đó có nghĩa là phạm vi. Nếu bạn có thể giới hạn phạm vi theo cách mà tác nhân được đảm bảo tìm thấy tất cả những gì nó cần để hoàn thành công việc tốt, bạn đã xong. Điều đó có nghĩa là phân mô đun cơ sở mã của bạn. Nếu bạn có thể cung cấp cho nó một hàm để đánh giá mức độ hoàn thành công việc của nó, thì càng tốt. Hill climbing, tất cả các nghiên cứu. Bất cứ thứ gì không quan trọng, hãy để nó xử lý; những thứ nhàm chán, hãy để nó xử lý; các trường hợp tái hiện lỗi của người dùng, vốn thường chỉ có thông tin một phần. Hoàn hảo. Tôi không còn dành thời gian làm những việc đó nữa. Hoặc nếu bạn không có người bên cạnh, hãy 'mô phỏng gỡ lỗi với con vịt cao su' (rubber duck). Vậy, có rất nhiều tác vụ bạn có thể sử dụng chúng để tiết kiệm thời gian. Cuối cùng, bạn đánh giá. Bạn chọn những gì hợp lý (hầu hết không hợp lý), và sau đó hoàn thiện.
Kết luận: Chậm lại và giữ tư duy phản biện
Slide cuối cùng của tôi, đại khái là vậy. Hãy chậm lại. Tìm hiểu xem bạn đang xây dựng cái gì và tại sao, đừng chỉ xây dựng vì tác nhân của bạn có thể làm được điều đó bây giờ. Thật ngu ngốc. Học cách nói không. Đây là khả năng quý giá nhất của bạn lúc này. Ít tính năng hơn, nhưng là những tính năng quan trọng, và sau đó sử dụng các tác nhân của bạn để trau chuốt chúng. Và hãy quan tâm đến người dùng mới, không phải mong muốn tối đa hóa mã thông báo của bạn. Không thể có một lượng mã được tạo ra vô hạn mà bạn cần phải xem xét. Và đối với mã không quan trọng, cứ thoải mái để tác nhân tạo ra một cách nhanh chóng. Mã quan trọng: hãy đọc mọi dòng code. Xem bài phát biểu chính (keynote) sau tôi để biết thêm thông tin về điều đó. Vậy làm thế nào bạn biết cái gì là quan trọng? Có ai đoán được không? Chà, bạn đọc cái mã đó. Nếu bạn làm bất cứ điều gì quan trọng, hãy tự viết bằng tay. Bạn có thể sử dụng một client để giúp bạn, nhưng đừng để nó đưa ra quyết định thay bạn bởi vì chúng ta đã biết tất cả các quyết định mà nó đưa ra đều học được từ internet. Và chính sự ma sát đó là thứ xây dựng sự hiểu biết về hệ thống trong đầu bạn, điều này rất quan trọng. Và đó cũng là nơi bạn học hỏi những điều mới. Và tất cả những điều này đòi hỏi kỷ luật và ý chí, và tất cả những điều này vẫn đòi hỏi con người. Cảm ơn.
TL;DR
- Tác giả Mario đã phát triển
Pi, mộtagentmã hóa tối giản và có khả năng tự sửa đổi, do thất vọng với các công cụ AI hiện có nhưClaude CodevàOpenCodevì chúng kém tin cậy, thiếu khả năng quan sát và mở rộng, đồng thời quản lýcontextkém hiệu quả. Piđược thiết kế để thích ứng với quy trình làm việc của nhà phát triển thông qua một lõi cơ bản, hệ thốngextensionmạnh mẽ và khả nănghot reload, cho phépagenttự sửa đổi và được tùy chỉnh hoàn toàn.- Tác giả cảnh báo rằng các
agent AI("clankers") đang phá hủy các dự ánmã nguồn mởbằng cách tạo ra mã chất lượng thấp và sự phức tạp không cần thiết, học hỏi từ các mã nguồn cũ và tạo ra cácabstractionlồng ghép mà không có sự kiểm soát của con người, dẫn đến "độ phức tạp cấp doanh nghiệp" một cách nhanh chóng.
Điểm chính
- Vấn đề với công cụ AI hiện tại: Các công cụ phát triển
agent AIban đầu nhưClaude Codegặp các vấn đề như thiếu ổn định, quản lýcontextkém (agent kiểm soát context thay vì người dùng), thiếu khả năng quan sát và khả năng mở rộng hạn chế. - Bài học từ
Terminal Bench: Cácbenchmarkcho thấy cácharness agentđơn giản nhất (chỉ cung cấptoolgửikeystroketớitmux) thường đạt hiệu suất cao nhất, gợi ý rằngcoding agentsvẫn đang trong giai đoạn thử nghiệm và hình thức đơn giản có thể hiệu quả hơn. - Nhu cầu
Agentcó thể điều chỉnh: Cần có nhữngagentcó thể tự sửa đổi và thích nghi với quy trình làm việc của người dùng (tunable agents) thay vì buộc người dùng phải tuân theo cách củaagent. - Thiết kế
Pitối giản và mở rộng:Piđược xây dựng với một lõi tối thiểu (lớp trừu tượngAI,agent core,framework,coding agent) và chỉ bốntoolcơ bản (read,write,edit,bash), nhưng được thiết kế siêu mở rộng thông qua cácextension. - Cơ chế tự tùy chỉnh qua
extension:Pisử dụng cácTypeScript modulelàmextensionđể thêm chức năng, định nghĩatooltùy chỉnh, lắng nghe sự kiện và kiểm soát hoàn toàn hoạt động củaagent, cho phépagenttự sửa đổi dựa trên tài liệu và ví dụ mã. - Tận dụng hệ sinh thái hiện có: Thay vì tạo ra các "marketplace" mới,
Pikhuyến khích sử dụng cácpackage managerhiện có nhưnpmhoặcGitHubđể tìm kiếm và chia sẻ cácextension. - Lợi ích của
Hot Reload: Khả nănghot reloadcho phép nhà phát triểnextensionlặp lại nhanh chóng và xem ngay các thay đổi trong phiên làm việc, cải thiện đáng kể tốc độ phát triển. - Nguy cơ từ
Agent AItrongMã nguồn mở: Cácagent AI("clankers") tạo ra cácpull requestvàissuerác rưởi, làm quá tải người duy trì dự ánmã nguồn mởvà làm giảm chất lượngcodebasebằng cách chèn sự phức tạp không cần thiết và mã lặp lại học được từ dữ liệu huấn luyện chất lượng thấp.
Từ vựng
Agent— Tác nhân (AI)Context Handling— Xử lý ngữ cảnhExtensibility— Khả năng mở rộngHarness— Khung điều khiển/Công cụ quản lý tác nhânBenchmark— Đánh giá hiệu suấtOpen Source Software (OSS)— Phần mềm mã nguồn mởExtension— Tiện ích mở rộngHot Reload— Tải lại nóngClanker— (Từ lóng) Tác nhân AI phá hoại/gây rácEnterprise-grade complexity— Độ phức tạp cấp doanh nghiệp
Nội dung chi tiết
Giới thiệu
Tôi là Mario, tôi xây dựng Pi trong một thế giới hỗn độn và đây là một chiến lược, một bi kịch trong ba hồi. Chỉ để nói nhanh về điều này: một số người trên internet đã trả tiền cho tôi để đặt quảng cáo trên áo của tôi và tất cả số tiền đó sẽ được quyên góp cho một tổ chức từ thiện. Vâng, cảm ơn mọi người.
Hồi 1: Xây dựng Pi
Động lực xây dựng Pi
Thuở ban đầu, có Claude Code và nó rất tốt, phải không? Tất cả chúng ta đều bị cuốn hút bởi nó và ngừng ngủ. Tôi không chắc có gì trước đó không, nhưng Claude Code là thứ khiến tôi hứng thú nhất. Và trước khi nói tất cả những điều này, tôi yêu đội ngũ Claude. Họ là những người tài năng, xuất sắc và có tốc độ phát triển cực cao, vì vậy họ cũng đã tạo ra toàn bộ trò chơi này – xin gửi lời khen ngợi lớn đến họ. Vậy đây không phải là một lời chỉ trích nữa, đây chỉ là tôi, một ông già, kể cho bạn nghe lý do tại sao tôi ngừng sử dụng Claude Code và tự xây dựng thứ của riêng mình.
Vào khoảng tháng 4 năm 2025, tôi bắt đầu sử dụng Claude Code, nhờ Peter, vì anh ấy nói với chúng tôi rằng các tác nhân đang hoạt động. Và hồi đó, nó đơn giản, dễ đoán và phù hợp với quy trình làm việc của tôi. Nhưng cuối cùng, tôi nghĩ rằng token madness đã xâm chiếm họ, đội ngũ lớn hơn và họ bắt đầu dog fooding (tự dùng sản phẩm của mình) và xây dựng rất nhiều tính năng mà tôi không cần – điều này không sao cả, tôi có thể bỏ qua chúng. Nhưng cùng với tốc độ và nhiều tính năng hơn, đi kèm với nhiều lỗi hơn. Và điều đó thật tệ, vì tôi từng làm việc tại các công trường xây dựng, và nếu cái búa của tôi hỏng mỗi ngày, tôi sẽ rất tức giận. Tương tự, nếu các development tool của tôi hỏng mỗi ngày, tôi cũng sẽ tức giận.
Vì vậy, có một trò đùa dai dẳng này, và đây là Tariq nói với chúng tôi rằng Claude Code giờ đây là một game engine, và đây là Mitchell từ Ghost giải thích chi tiết cho chúng tôi: "Không, không phải vậy." Và cuối cùng họ đã sửa lỗi nhấp nháy, nhưng sau đó những thứ khác lại hỏng, và tôi nghĩ họ đang ở bản thứ ba của TUI renderer (công cụ kết xuất giao diện người dùng văn bản). Vâng, nhưng đó chỉ là triệu chứng. Vấn đề thực sự là context của tôi không phải là context của tôi. Claude Code là thứ kiểm soát context của tôi. Và sau lưng tôi, Claude Code làm những điều với context.
Vì vậy, có vấn đề về hệ thống, nó thay đổi trên mỗi bản phát hành, bao gồm cả các định nghĩa tool. Họ sẽ loại bỏ tool, sửa đổi tool. Điều đó không tốt. Họ sẽ chèn các system reminders (lời nhắc hệ thống) vào phần lớn nội dung context của bạn ở một vị trí không phù hợp, nói với mô hình: "Đây là một số thông tin, nó có thể hoặc không liên quan đến những gì bạn đang làm." Nó thực sự nói rằng nó có thể hoặc không liên quan đến những gì bạn đang làm. Và điều đó đã làm mô hình bị nhầm lẫn và làm hỏng các quy trình làm việc của tôi.
Trên hết, không có khả năng quan sát (observability) nào cả vì đó là cách TUI được xây dựng, và tôi thích biết tác nhân của mình đang làm gì. Không có lựa chọn mô hình nào, điều này rõ ràng. Đó là harness (công cụ điều khiển) Anthropic gốc nên họ muốn bạn sử dụng Claude, phải không? Và hầu như không có khả năng mở rộng nào. Một số bạn có thể đã viết một số hook cho Claude Code, nhưng tôi nói cho bạn biết, có một số hook và độ sâu của những hook đó rất nông cạn. Mỗi khi một hook được kích hoạt, điều thực sự xảy ra là một quy trình mới được tạo ra. Về cơ bản, lệnh bạn đã chỉ định cho tool được thực thi, và tôi không thấy điều đó hiệu quả một cách cụ thể.
Tìm kiếm giải pháp thay thế
Vì vậy, tôi lùi lại một bước và tìm kiếm các lựa chọn thay thế. Tôi muốn đặc biệt nhắc đến AMP và FactoryTried. Chúng là Porsche và Lamborghini của các harness agent mã hóa. Nếu bạn có thể chi trả, hãy sử dụng chúng. Chúng đang ở tiền tuyến, chúng thực sự tốt và các đội ngũ của chúng thật tuyệt vời. Ngoài ra còn có một loạt các lựa chọn khác.
Tôi có kinh nghiệm trong OSS (mã nguồn mở) nên đương nhiên tôi bị thu hút bởi OpenCode. Một lần nữa, đội ngũ xuất sắc, tốc độ thực thi siêu nhanh và họ không bán cho bạn hype (sự thổi phồng), họ bán cho bạn những tool hoạt động tốt trong hầu hết các trường hợp.
Phân tích OpenCode
Tôi bắt đầu tìm hiểu sâu về OpenCode, quay trở lại vấn đề context handling vì đó là phần quan trọng nhất đối với tôi. Và tôi đã tìm thấy một số điều như: trong một số điều kiện nhất định, OpenCode sẽ chỉ cắt bớt đầu ra tool sau một lượng mã thông báo (token) tối thiểu cụ thể, và về cơ bản, điều đó làm hỏng mô hình.
Ngoài ra còn có hỗ trợ LSP server, có nghĩa là mỗi khi mô hình của bạn gọi edit tool, OpenCode sẽ truy cập LSP server khác đã được kết nối, hỏi xem có lỗi nào không và nếu có, nó sẽ kiểm tra điều đó như một phần của kết quả edit tool. Điều này rất tệ, hãy nghĩ về cách bạn chỉnh sửa mã. Bạn không viết một dòng mã, kiểm tra lỗi, viết dòng tiếp theo, kiểm tra lỗi. Bạn không làm vậy, bạn hoàn thành công việc của mình và sau đó bạn kiểm tra lỗi. Điều này đã làm mô hình bị nhầm lẫn.
Có một số điều khác như lưu trữ các tin nhắn riêng lẻ của một phiên trong một tệp JSON. Mỗi tin nhắn là một tệp JSON trên đĩa. Có một điều này, và điều này xảy ra với tất cả chúng ta, không có ý chỉ trích, nhưng thật không hay nếu theo mặc định, một server khởi động, các CORS header được đặt theo cách mà bất kỳ trang web nào mà trình duyệt OpenCode của bạn có thể truy cập giờ đây đều có thể truy cập server OpenCode của bạn.
Tiêu chuẩn và kết quả đánh giá
Hoàn toàn không liên quan đến tất cả những điều này, tôi bắt đầu tìm hiểu các benchmark (đánh giá hiệu suất) cho các harness agent mã hóa và tìm thấy Terminal Bench, một benchmark khá tốt, xét mọi khía cạnh. Và điều thú vị là nó là thứ tối giản nhất bạn có thể nghĩ đến. Tất cả những gì nó cung cấp cho mô hình là một tool để gửi các keystroke (phím bấm) đến một phiên tmux và đọc đầu ra của phiên tmux. Không có file tool, không có sub agent, không có bất kỳ thứ gì như vậy. Và nó là một trong những harness hoạt động tốt nhất trong bảng xếp hạng (leaderboard). Đây là bảng xếp hạng từ tháng 12 năm 2025. Bất kể model family (họ mô hình) nào, Terminal luôn đạt điểm cao hơn, thậm chí chủ yếu cao hơn cả harness gốc của mô hình đó.
Vậy điều đó nói lên điều gì với chúng ta? Hai luận điểm chính là: chúng ta đang ở trong giai đoạn thử nghiệm (fuck around and find out phase) của coding agents và hình thức hiện tại không phải là hình thức cuối cùng của chúng, đúng không?
Hai luận điểm chính
Luận điểm thứ hai là: chúng ta cần những cách tốt hơn để thử nghiệm. Và đối với tôi, điều đó có nghĩa là các tác nhân có thể tự sửa đổi, có thể điều chỉnh (tunable agents), những thứ mà bản thân tác nhân có thể sửa đổi và tôi có thể sửa đổi tùy theo quy trình làm việc của mình.
Giới thiệu Pi: Tác nhân tự điều chỉnh
Vì vậy, tôi đã loại bỏ tất cả mọi thứ, xây dựng một lõi tối thiểu nhưng làm cho nó siêu mở rộng và khiến tác nhân có thể tự sửa đổi. Với một số tiện nghi nhỏ, nó không hoàn toàn thô sơ. Vậy đó là Pi. Nó là một tác nhân thích nghi với quy trình làm việc của bạn thay vì ngược lại.
Nó đi kèm với bốn gói:
- Gói
AIvề cơ bản chỉ là một lớp trừu tượng trên các nhà cung cấp vàcontext handlinggiữa các nhà cung cấp. - Một
agent core, chỉ là một vòng lặpwhilevàtool calling. - Tôi xuất thân từ phát triển trò chơi nên tôi đã xây dựng một
framework(khung làm việc) thực sự không nhấp nháy quá nhiều. - Và bản thân
coding agent.
Đây là system prompt của Pi. Chỉ có vậy. Cuối cùng, ngành công nghiệp đã tạo ra một tiêu chuẩn mới gọi là skills, về cơ bản chỉ là các tệp Markdown. Vì vậy, chúng tôi cũng đã thêm điều đó và nó cần được đưa vào system prompt. Do đó, chúng tôi miễn cưỡng phải thêm một vài dòng nữa.
Cơ chế tự tùy chỉnh và khả năng mở rộng của Pi
Và cuối cùng, đây là điều kỳ diệu giúp Pi có khả năng tự sửa đổi. Chúng tôi đã xuất bản tài liệu, được tôi và một tác nhân biên soạn thủ công, cùng với các ví dụ mã về extension (tiện ích mở rộng). Tất cả những gì chúng tôi cần làm để tác nhân tự sửa đổi là nói với nó: "Đây là tài liệu. Đây là một số mã cho bạn thấy cách tự sửa đổi bằng cách viết extension."
Nó đi kèm với bốn tool. Chỉ có vậy. Read, write, edit, bash. Đây là các định nghĩa tool. Đừng đọc văn bản, chỉ nhìn vào kích thước. Thế thôi. Đây là những gì xảy ra khi bạn bắt đầu một phiên mới trong một trong những tool này.
Vấn đề là, các mô hình thực sự được đào tạo bằng học tăng cường (reinforcement trained) đến mức chúng không biết coding agent là gì. Bởi vì các coding agent harness về cơ bản là những gì chúng được đào tạo khi chúng được post-trained. Bạn không cần 10.000 mã thông báo để nói với chúng rằng bạn là một coding agent. Chúng biết điều đó vì giờ đây chúng là coding agents.
Pi cũng có rất nhiều mặc định vì nhu cầu bảo mật của tôi khác với bạn. Và tôi không nghĩ một hộp thoại nhỏ bật lên mỗi khi bạn gọi bash, yêu cầu bạn phê duyệt, là một cơ chế bảo mật thông minh. Thay vào đó, tôi cung cấp cho bạn nhiều lựa chọn đến mức bạn có thể xây dựng bất cứ thứ gì phù hợp với nhu cầu bảo mật cụ thể của mình.
Ngoài ra còn có những thứ không được tích hợp sẵn. Tôi là một kẻ ngoại đạo vì đây là cách tôi làm. Nhưng nếu bạn không thích điều đó, thì bạn chỉ cần yêu cầu Pi xây dựng cho bạn hỗ trợ sub agent ở plan mode hoặc hỗ trợ MCP, bất cứ điều gì bạn cần.
Vì vậy, trách nhiệm đi kèm với một số table stakes (yếu tố cơ bản) và sau đó là bản thân các extension. Các extension chỉ đơn giản là các TypeScript module. Trong trường hợp đơn giản nhất, một tệp TypeScript trên đĩa, bạn chỉ đường cho Pi đến đó. Đây là một extension được tải như một phần của harness. Và với điều đó, bạn về cơ bản có một extension API cho phép bạn kết nối vào mọi thứ và định nghĩa những thứ mà harness sẽ hiển thị cho mô hình. Và điều đó bao gồm các tool / phím tắt lệnh. Bạn có thể lắng nghe bất kỳ loại sự kiện nào và phản ứng, sau đó lưu trạng thái trong phiên mà tùy chọn được cung cấp cho tác nhân hoặc được lưu trữ ở đó cho các tool phân tích phiên như một phần của các quy trình làm việc tổ chức. Bạn có thể thực hiện compaction tùy chỉnh, các nhà cung cấp tùy chỉnh và kiểm soát hoàn toàn các tool. Bạn có thể sửa đổi mọi thứ trong Pi. Và sau đó bạn có thể gói tất cả lại và đưa lên npm hoặc trên GitHub vì tôi nghĩ nếu chúng ta không cần phát minh lại một loạt các kho chứa khác gọi là marketplace, chúng ta đã có các package manager (trình quản lý gói).
Và tất cả đều hot reload (tải lại nóng). Vì vậy, nếu bạn phát triển một extension cho Pi, bạn thực hiện trong phiên và bạn hot reload các thay đổi và thấy ngay các hiệu ứng của nó, điều này rất tuyệt vời. Và đó cũng là những thứ trong phát triển trò chơi. Trong phát triển trò chơi, bạn muốn tốc độ lặp lại rất cao, rất thấp. Và điều đó thật tuyệt.
Ví dụ về các tiện ích mở rộng của Pi
Một vài ví dụ. Claude hoặc Anthropic có /bytheway, cho phép bạn nói chuyện với tác nhân khi nó đang thực hiện nhiệm vụ chính của mình. Tôi đã đăng lời nhắc (prompt) nhỏ này lên Twitter một cách đùa cợt và ai đó đã xây dựng nó trong năm phút với nhiều tính năng hơn. Và họ không cần phải fork hoặc clone Pi. Họ chỉ để tác nhân viết extension dựa trên lời nhắc.
Đây là Nico, một trong những người viết extension sung mãn nhất. Tôi không biết chuyện quái gì đang xảy ra ở đây. Đó là một phòng trò chuyện cho tất cả các tác nhân Pi của anh ấy và chúng nói chuyện với nhau. Tôi sẽ không bao giờ sử dụng cái này, nhưng tất cả đều là tùy chỉnh, bao gồm cả UI (giao diện người dùng). Hoặc bạn có thể chơi game Nest. Hoặc bạn có thể chơi Doom. Và còn một loạt các ví dụ khác mà tôi sẽ không nói đến.
Vậy làm thế nào để xây dựng một Pi extension? Bạn không cần phải làm. Bạn yêu cầu Pi xây dựng nó cho bạn dựa trên các thông số kỹ thuật của bạn. Và sau đó bạn chỉ cần lặp lại với nó và hot reload trong phiên. Chúng ta sẽ bỏ qua ví dụ đó.
Tìm kiếm và chia sẻ tiện ích mở rộng
Và nếu bạn không thích tự xây dựng mọi thứ – và tôi hy vọng bạn thích tự xây dựng mọi thứ – nhưng nếu không, bạn có thể tìm trên npm hoặc tìm kiếm nhỏ của chúng tôi. Và sau đó bạn có thể tìm thấy giao diện trên npm để tìm các bản vá cho sub agents, MCP, v.v.
Triết lý và hiệu suất của Pi
Vậy nó có thực sự hoạt động không? Vâng, đây là bảng xếp hạng Terminal Bench từ tháng 10 trước khi Pi có bản vá. Tôi đã thêm nó cho việc Peter's class thingy. Nó có sáu lượt chơi. Nhưng tất cả những điều này thực ra không phải về Pi. Nếu bạn muốn đọc nó, về cơ bản tôi muốn bạn kiểm soát các tool và quy trình làm việc của mình. Vì vậy, hãy tự xây dựng lấy. Và nếu bạn muốn biết thêm về Pi và OpenClaw, hãy đến buổi nói chuyện này.
Hồi 2: Mã nguồn mở trong kỷ nguyên của "Clanker"
Tác động của tác nhân AI đến dự án mã nguồn mở
Và rồi Peter đã làm việc đó, anh ấy đặt Pi vào bên trong OpenClaw. Đó là một "vòi bạch tuộc" (tentacle), có nghĩa là dự án mã nguồn mở của tôi trở thành mục tiêu của rất nhiều OpenClaw instances mà người dùng của chúng không hề hay biết.
Vậy đây là hồi hai: OSS trong kỷ nguyên của clankers. Clankers đang phá hủy OSS. Đây là Seal Raw, đã đóng issue và pull request tracker. Đây là tracker của OpenClaw. Đây là của tôi. Một nửa trong số đó là các OpenClaw instances đăng rác rưởi.
Chống lại các "Clanker"
Vì vậy, tôi bắt đầu nổi giận với clankers. Nếu bạn gửi một pull request, nó sẽ tự động bị đóng với một bình luận yêu cầu bạn vui lòng viết một issue tử tế bằng giọng điệu con người, không còn là một màn hình đầy văn bản nữa. Và nếu tôi thấy điều đó, phải không, "trông tốt đối với tôi" và tên tài khoản của bạn sẽ được đưa vào một tệp trong kho lưu trữ (repository) và lần tới khi bạn gửi một pull request, nó sẽ được chấp nhận. Clankers không đọc bình luận đó. Chúng không quay lại một khi đã đăng một pull request. Vì vậy đó là một bộ lọc hoàn hảo.
Câu chuyện về Mitchell và Vouch
Mitchell cuối cùng đã biến thành Vouch. Đây là một clanker.
Tình hình sử dụng tác nhân AI hiện tại và những hệ quả
Tôi đã gắn nhãn cho các vấn đề. Nếu bạn tương tác với open-claw, các vấn đề của bạn sẽ bị giảm ưu tiên. Tôi cũng xây dựng các tool để nhúng các vấn đề và nội dung pull request vào không gian 3D, giúp tôi nhìn thấy các cụm vấn đề. Tôi cũng đã phát minh ra "kỳ nghỉ OSS" – chỉ cần đóng theo dõi bất cứ khi nào tôi muốn, nhờ đó tôi có lại cuộc sống của mình. Vậy, điều này có hiệu quả không? Có, phần nào.
Điều này dẫn tôi đến màn ba: Hãy chậm lại đi. Mọi thứ đều hỏng bét. Và rồi, khi mọi người nói rằng sản phẩm của chúng ta đã được xây dựng 100% bởi các tác nhân. Vâng, chúng ta biết rằng giờ đây nó rất tệ. Xin chúc mừng. Và tôi đang nghe điều này từ các đồng nghiệp của mình, và điều này hoàn toàn không lành mạnh.
Những rủi ro khi làm việc với tác nhân AI
Vậy đây là cách chúng ta không nên làm việc với các tác nhân và lý do, ít nhất là theo ý kiến của tôi. Tôi đã viết điều này trên blog của mình cách đây một thời gian. Nhưng ý chính là, chúng ta có rất nhiều tác nhân đang hoạt động mà bạn không biết rằng về cơ bản chúng không thể gỡ cài đặt được. Các phần mềm độc hại (malware) và Anthropic đã xây dựng một trình biên dịch C. Nó có vẻ hoạt động, nhưng thực tế lại không. Và chúng ta đang hy vọng thế hệ mô hình tiếp theo sẽ khắc phục được nó. Và đây là Cursor đang xây dựng một trình duyệt. Và cái đó cũng rất tệ hại. Nhưng thế hệ tiếp theo sẽ khắc phục nó. Và Saz đã chết. Phần mềm sẽ trở nên lỗi thời trong sáu tháng. Và bà tôi vừa tự xây dựng cho mình một Spotify với open-claw của bà ấy. Thôi nào mọi người!
Vậy, các tác nhân thực chất đang kết hợp những "boo-boo" (là từ tôi dùng để chỉ lỗi) với việc học nối tiếp, không có nút thắt cổ chai và nỗi đau trì hoãn. Nỗi đau trì hoãn đó là dành cho bạn. Hãy xem cơ sở mã của bạn với một người, một tác nhân và mười tác nhân. Bạn có thể xem xét bao nhiêu mã do tác nhân tạo ra? Đây là cùng một cơ sở mã được biểu thị bằng số lượng "boo-boo" mỗi ngày. Bạn nghĩ mình sẽ tìm thấy bao nhiêu "boo-boo" trong số đó? Sau đó bạn nói, "Ồ, tôi có một tác nhân đánh giá." Hãy để tôi giới thiệu cho bạn thế giới tuyệt vời của Ouroboros (rắn tự ăn đuôi). Nó không hoạt động. Nó chỉ bắt được một số vấn đề. Vấn đề là các tác nhân là những "thương nhân" của sự phức tạp đã học được.
Chúng học sự phức tạp đó từ đâu? Từ internet. Có gì trên internet? Toàn bộ mã nguồn cũ rích của chúng ta. Có một vài viên ngọc quý trên internet, những hệ thống được thiết kế thực sự tốt. Nhưng 90% mã nguồn trên internet là rác rưởi cũ kỹ của chúng ta. Đó là những gì các mô hình học được. Và mọi quyết định của một tác nhân đều mang tính cục bộ. Đặc biệt nếu cơ sở mã quá lớn đến mức không vừa với cửa sổ ngữ cảnh của nó. Và nếu bạn để nó hoạt động tự do, thêm các tầng trừu tượng (abstractions) ở khắp mọi nơi mà chúng lại lồng ghép vào nhau. Thế là có rất nhiều tầng trừu tượng và sự trùng lặp, và cả khả năng tương thích ngược (backwards compatibility). Ai đã thấy điều đó trong kết quả đầu ra của tác nhân của họ? Nó thật khó chịu, hoặc là "phòng thủ sâu" (defense in depth) không cần thiết. Vậy đó, bạn sẽ nhận được sự phức tạp cấp độ doanh nghiệp (enterprise-grade complexity) chỉ trong hai tuần, với chỉ hai người và mười tác nhân. Xin chúc mừng.
Và rồi bạn nói, "Nhưng spec chi tiết của tôi thì sao?" Vâng, chắc chắn rồi. Bạn có biết chúng ta gọi một spec đủ chi tiết là gì không? Nó là một chương trình. Vậy nếu bạn để trống các phần trong spec của mình, bạn nghĩ điều gì sẽ xảy ra? Mô hình sẽ điền vào chỗ trống bằng cách nào? Và bằng cái gì? Nó sẽ điền vào bằng những thứ rác rưởi mà nó học được trên internet từ mã cũ của chúng ta. Đó là rác rưởi tái diễn.
Con người so với tác nhân trong chất lượng mã nguồn
Và rồi bạn nói, "Nhưng con người thì sao..." Vâng, con người là những sinh vật kinh khủng, dễ mắc lỗi, nhưng họ có thể học hỏi. Và họ là những nút thắt cổ chai. Chỉ có bấy nhiêu "boo-boo" họ có thể thêm vào cơ sở mã của bạn hàng ngày. Và con người cảm nhận được nỗi đau. Đây là một đặc tính rất thú vị vì con người ghét nỗi đau. Và một khi có quá nhiều nỗi đau, con người có một loạt lựa chọn: Họ có thể nghỉ việc. Họ có thể đổ lỗi cho người khác và bắt họ sửa lỗi. Hoặc mọi người lên kế hoạch để bắt đầu refactoring nhằm dọn dẹp cơ sở mã rác rưởi. Các tác nhân sẽ vui vẻ tiếp tục thêm rác vào cơ sở mã của bạn.
Và giờ đây, các tác nhân của bạn và các hệ thống bộ nhớ siêu phức tạp cũng sẽ không cứu được bạn. Các tác nhân không học theo cách chúng ta học. Những người thân yêu nhất của tôi, tôi thậm chí còn không đọc mã nguồn nữa. Chúc mừng. Có điều gì đó bị hỏng và người dùng của bạn đang la ó. Vậy bạn sẽ gọi ai? Không phải chính bạn, vì bạn chưa đọc mã nguồn. Vì vậy, bạn đang dựa vào các tác nhân của mình, nhưng chúng cũng bị quá tải vì cơ sở mã quá lớn đến mức hoàn toàn không có cơ hội để chúng có được tất cả ngữ cảnh cần thiết để khắc phục vấn đề. Và các cửa sổ ngữ cảnh dài là một hack (giải pháp tạm bợ), như hầu hết các bạn sẽ nhận ra trong năm nay khi mọi người chuyển sang cửa sổ ngữ cảnh một triệu mã thông báo. Và tìm kiếm theo tác nhân cũng thất bại. Vì vậy, tác nhân vá lỗi cục bộ và làm hỏng mọi thứ trên phạm vi toàn cầu. Nếu bạn thấy điều này trong cơ sở mã của mình, bạn tiêu đời rồi. Bạn không thể điều chỉnh cơ sở mã của mình nữa, và cả các kiểm thử cũng không, vì các tác nhân của bạn đã viết các kiểm thử đó. Vậy thì, hết game.
Cách tiếp cận tốt hơn: Phân công nhiệm vụ có phạm vi rõ ràng cho tác nhân
Vậy đây là cách tôi nghĩ chúng ta nên làm việc. Có một loạt các đặc tính cho các tác vụ tác nhân tốt. Điều đó có nghĩa là phạm vi. Nếu bạn có thể giới hạn phạm vi theo cách mà tác nhân được đảm bảo tìm thấy tất cả những gì nó cần để hoàn thành công việc tốt, bạn đã xong. Điều đó có nghĩa là phân mô đun cơ sở mã của bạn. Nếu bạn có thể cung cấp cho nó một hàm để đánh giá mức độ hoàn thành công việc của nó, thì càng tốt. Hill climbing, tất cả các nghiên cứu. Bất cứ thứ gì không quan trọng, hãy để nó xử lý; những thứ nhàm chán, hãy để nó xử lý; các trường hợp tái hiện lỗi của người dùng, vốn thường chỉ có thông tin một phần. Hoàn hảo. Tôi không còn dành thời gian làm những việc đó nữa. Hoặc nếu bạn không có người bên cạnh, hãy 'mô phỏng gỡ lỗi với con vịt cao su' (rubber duck). Vậy, có rất nhiều tác vụ bạn có thể sử dụng chúng để tiết kiệm thời gian. Cuối cùng, bạn đánh giá. Bạn chọn những gì hợp lý (hầu hết không hợp lý), và sau đó hoàn thiện.
Kết luận: Chậm lại và giữ tư duy phản biện
Slide cuối cùng của tôi, đại khái là vậy. Hãy chậm lại. Tìm hiểu xem bạn đang xây dựng cái gì và tại sao, đừng chỉ xây dựng vì tác nhân của bạn có thể làm được điều đó bây giờ. Thật ngu ngốc. Học cách nói không. Đây là khả năng quý giá nhất của bạn lúc này. Ít tính năng hơn, nhưng là những tính năng quan trọng, và sau đó sử dụng các tác nhân của bạn để trau chuốt chúng. Và hãy quan tâm đến người dùng mới, không phải mong muốn tối đa hóa mã thông báo của bạn. Không thể có một lượng mã được tạo ra vô hạn mà bạn cần phải xem xét. Và đối với mã không quan trọng, cứ thoải mái để tác nhân tạo ra một cách nhanh chóng. Mã quan trọng: hãy đọc mọi dòng code. Xem bài phát biểu chính (keynote) sau tôi để biết thêm thông tin về điều đó. Vậy làm thế nào bạn biết cái gì là quan trọng? Có ai đoán được không? Chà, bạn đọc cái mã đó. Nếu bạn làm bất cứ điều gì quan trọng, hãy tự viết bằng tay. Bạn có thể sử dụng một client để giúp bạn, nhưng đừng để nó đưa ra quyết định thay bạn bởi vì chúng ta đã biết tất cả các quyết định mà nó đưa ra đều học được từ internet. Và chính sự ma sát đó là thứ xây dựng sự hiểu biết về hệ thống trong đầu bạn, điều này rất quan trọng. Và đó cũng là nơi bạn học hỏi những điều mới. Và tất cả những điều này đòi hỏi kỷ luật và ý chí, và tất cả những điều này vẫn đòi hỏi con người. Cảm ơn.