Viết lại nền móng của tác tử: Tái cấu trúc Orkas từ gốc

Khi một sản phẩm tác tử AI trưởng thành, thứ tốn kém nhất không phải tính năng — mà là nền tảng. Bài viết này trình bày đợt tái cấu trúc từ gốc mà Orkas thực hiện trong dòng phiên bản 1.0 — đại tu toàn bộ việc gọi mô hình, vòng lặp tác tử, điều phối đa tác tử và hệ sinh thái công cụ — cùng những đánh đổi đằng sau mỗi quyết định.

Tóm tắt ngắn gọn Mục đích của việc viết lại Kết quả là ứng dụng bạn có thể cài đặt ngay hôm nay: mã nguồn mở theo giấy phép MIT, ưu tiên cục bộ và chạy bằng khóa nhà cung cấp của riêng bạn nếu muốn.

Tải Orkas — miễn phí

Vì sao phải đụng đến nền tảng

Orkas là một không gian làm việc tác tử AI trên máy tính, ưu tiên cục bộ: mọi công việc của tác tử chạy trong một tiến trình trên chính máy người dùng, dữ liệu nằm cục bộ và đồng bộ đám mây đầu cuối diễn ra theo yêu cầu. Các tính năng tăng lên nhanh chóng ở những phiên bản đầu — thư viện kỹ năng, cơ sở tri thức, trình kết nối, đa tác tử theo kiểu trò chuyện nhóm — nhưng càng tiến xa, chúng tôi càng thấy rõ: nút thắt thực sự không nằm ở một tính năng riêng lẻ nào, mà ở ba vấn đề "cấp nền tảng".

Nếu lớp gọi mô hình đi theo lối mòn hội thoại, nó sẽ bị trói buộc bởi một chuỗi giả định sai. Gọi một mô hình lớn như thể đó là "trò chuyện một câu hỏi, một câu trả lời" ngầm mang theo hàng loạt mặc định hợp lý cho trò chuyện nhưng không phù hợp với tác tử: giới hạn token đầu ra cố định, gọi công cụ tuần tự, thời gian chờ ẩn, một nhà cung cấp duy nhất được gắn cứng. Tác tử là một luồng chạy dài với hàng chục lượt liên tiếp, thường xuyên chạm giới hạn cửa sổ ngữ cảnh, cần đọc tệp song song và có thể bị người dùng ngắt bất cứ lúc nào — từng mặc định đó đều sẽ gây rắc rối khi vận hành thực tế. Tệ hơn, những năng lực giá trị nhất của tác tử trên máy tính — thao tác tệp chi tiết, tìm kiếm cục bộ, chạy shell, thực thi song song với nhiều tác tử thực thi, giải quyết tác vụ dài hạn — lại chính là những năng lực bị lớp giả định này chặn lại.
Việc điều phối là "lập kế hoạch tĩnh". Phiên bản đầu là một bộ máy kế hoạch/DAG: trước tiên yêu cầu mô hình chia tác vụ thành đồ thị kế hoạch, rồi để bộ thực thi phân công theo đồ thị. Nghe có vẻ gọn gàng, nhưng thực tế của tác tử rất linh động — đọc một tệp có thể cho thấy cần đổi hướng, và kết quả của một tác vụ con quyết định bước tiếp theo giao cho ai. Cố định quyết định trong một đồ thị tạo sẵn đồng nghĩa với việc mỗi lần "kế hoạch không theo kịp thực tế" đều phải vá trong bộ thực thi.
Hệ sinh thái là một danh mục đóng. Kỹ năng chỉ có thể đến từ chợ chính thức, trình kết nối là danh mục được mã hóa cứng, còn các công cụ tác tử bên ngoài đã có trên máy người dùng hoàn toàn là hộp đen đối với Orkas. Người dùng muốn cắm thêm dự án bên thứ ba, máy chủ MCP của riêng mình, hoặc để tác tử đã có trên máy gọi ngược vào kỹ năng và cơ sở tri thức của Orkas — về mặt kiến trúc, tất cả đều không thể.

Luận điểm của đợt tái cấu trúc này rất đơn giản: đưa nền tảng của tác tử trở lại trong tay chúng tôi. Cụ thể, nó được triển khai thành bốn hướng xuyên suốt đan xen — môi trường thực thi tự xây dựng trong tiến trình, lớp mô hình không phụ thuộc nhà cung cấp, điều phối trò chuyện nhóm động và chuyển từ danh mục đóng sang nền tảng chủ mở. Hãy lần lượt xem từng phần.

1. Đưa bộ năng lực tác tử lập trình đầy đủ lên máy tính

Máy tính là sân nhà của tác tử — ở đây có hệ thống tệp thực, shell thực và chuỗi công cụ cục bộ thực. Một trợ lý chỉ biết trò chuyện đang lãng phí môi trường này; thứ thực sự tận dụng được lợi thế của máy tính là một bộ năng lực tác tử lập trình đầy đủ: đọc và ghi tệp đến từng phạm vi ký tự, tìm kiếm xuyên tệp, chạy bash và công cụ hệ thống, khởi chạy nhiều tác tử thực thi song song và khả năng giải quyết vấn đề dài hạn để tiếp tục chạy hàng chục lượt cho đến khi một tác vụ phức tạp thực sự hoàn thành.

Sản phẩm cốt lõi của đợt tái cấu trúc tồn tại chính để đưa bộ năng lực này vào ngay trong tiến trình của Orkas — một môi trường thực thi tác tử độc lập, có thể nạp động và chạy trong tiến trình (được gọi là core-agent trong mã). Đây không phải một lớp bọc trò chuyện nữa; đó là bộ máy tác tử do chính Orkas kiểm soát.

Quyết định kiến trúc then chốt là tách nó thành hai lớp:

Lớp bộ máy (gói độc lập): cơ chế tác tử thuần túy — vòng lặp gọi công cụ, sự kiện truyền trực tiếp, nén ngữ cảnh, phân loại lỗi và thử lại, lớp trừu tượng nhà cung cấp, môi trường cô lập, quét kỹ năng, bộ nhớ, tự tiến hóa. Nó không biết gì về bất kỳ nghiệp vụ nào của Orkas: không đọc thư mục dữ liệu nghiệp vụ, không hiểu định dạng tệp hội thoại và không bao giờ chạm đến IPC.
Lớp bộ chuyển tiếp (bên trong tiến trình chính): kết nối bộ máy với Orkas — lưu bền vững phiên, luân chuyển nhà cung cấp, quyền công cụ, sổ đăng ký kỹ năng, trình kết nối, cơ sở tri thức và các công cụ tạo nội dung. Nó chuyển các sự kiện gốc của bộ máy thành định dạng sự kiện riêng của Orkas, để lớp nghiệp vụ luôn chỉ thấy một giao diện ổn định.

Ranh giới giữa bộ máy và bộ chuyển tiếp này là gốc rễ của mọi tính linh hoạt phía sau. Bộ máy có thể được kiểm thử và phát triển độc lập; lớp bộ chuyển tiếp có thể an toàn tiếp nhận độ phức tạp riêng của Orkas (luân chuyển, thời gian chờ, môi trường cô lập, quyền hạn) mà không làm lẫn lộn bộ máy. Buổi đánh giá kiến trúc của nhóm đã đúc kết trong một câu: đây là độ phức tạp có lý do chính đáng — đừng gộp nó lại.

Bộ năng lực thực sự gồm những gì

Nắm môi trường thực thi trong tay không phải để phô trương; mà để tác tử thực sự có thể "xắn tay làm việc" trên máy tính. Bộ năng lực chia thành khoảng bốn nhóm:

Thao tác tệp chi tiết và tìm kiếm cục bộ. read_file hỗ trợ đọc theo phạm vi ký tự và tự động trích xuất văn bản từ tài liệu PDF / Office; edit_file thay thế chính xác "chuỗi cũ → chuỗi mới" và yêu cầu đọc trước mọi lần ghi; write_file ghi sản phẩm đầu ra xuống tệp và lưu lại thông tin về nó; stat_file kiểm tra kích thước; search_files tìm theo tên/mẫu glob, grep_files tìm nội dung xuyên tệp. Nhóm này giúp tác tử "đào sâu mã, sửa tệp" trong một không gian làm việc thực như kỹ sư, thay vì chỉ có thể tiếp nhận và xuất ra nguyên khối.
Bash và công cụ hệ thống. Bộ thực thi shell trong môi trường cô lập, có chế độ chạy nền (tác vụ dài tách khỏi lượt hiện tại, nhật ký được ghi vào tệp) và cơ chế kiểm soát theo mức rủi ro cho các thao tác nguy hiểm. Phần lớn sức mạnh của tác tử trên máy tính đến chính từ khả năng trực tiếp điều khiển chuỗi công cụ hệ thống.
Nhiều tác tử thực thi song song. Trong một lượt, các công cụ độc lập chỉ đọc chạy đồng thời; ở cấp tác vụ, tác tử chỉ huy cũng có thể phân tách các tác vụ con độc lập cho nhiều tác tử thực thi song song (xem Phần 3). Song song hóa ở những nơi an toàn là chìa khóa để rút "tác vụ dài hạn" xuống thời gian thực tế chấp nhận được.
Suy luận dài hạn và giải quyết tác vụ. Một vòng lặp có thể chạy hàng chục lượt liên tiếp, tự quản lý ngữ cảnh, phục hồi sau lỗi và không bao giờ mắc kẹt lặp đi lặp lại tại chỗ — đó là ranh giới giữa "hoàn thành một công việc phức tạp" và "trả lời một câu hỏi".

Cách đưa hệ thống lên mức sẵn sàng vận hành thực tế về mặt kỹ thuật

“Tự viết vòng lặp” nghe như tự chuốc rắc rối, và quả thực phải trả chi phí bảo trì. Nhưng đổi lại là khả năng kiểm soát chi tiết toàn bộ vòng đời của tác tử. Khả năng kiểm soát ấy không hề trừu tượng — đó là một loạt cải tiến cụ thể, mỗi cải tiến quyết định liệu một năng lực kể trên có “trụ vững” khi vận hành thực tế hay không:

Cửa sổ ngữ cảnh thực tế + chỉ nén khi đạt 80%. Bộ máy đọc cửa sổ ngữ cảnh của từng mô hình với kích thước thực tế (kể cả các mô hình có cửa sổ một triệu token) và chỉ kích hoạt nén khi mức sử dụng đạt 80% — thay vì thận trọng bắt đầu ở 60% rồi bỏ đi 40% ngữ cảnh hữu ích. Ngoài ra còn có cơ chế bảo vệ “nén không mang lại lợi ích”: nếu phần đuôi được giữ lại đã lấp đầy cửa sổ (chẳng hạn một kết quả đọc tệp rất lớn nằm ở cuối), việc nén không thể giải phóng thêm gì, nên hệ thống chỉ ghi cảnh báo rồi bỏ qua, tuyệt đối không gọi tóm tắt một cách lãng phí. Một tác vụ kéo dài có thể “nhớ những gì đã diễn ra” hay không phụ thuộc hoàn toàn vào điều này.
Chạy song song các công cụ chỉ đọc liền kề. Khi mô hình gọi các công cụ đọc tệp, tìm kiếm tệp và tra cứu web — nhiều công cụ chỉ đọc độc lập — trong cùng một lượt, bộ máy gom những công cụ liền kề có thể chạy song song thành một nhóm để thực thi đồng thời; công cụ ghi là ranh giới tự nhiên và vẫn giữ thứ tự đã khai báo. Các lệnh gọi công cụ cùng kết quả được ghi nhận nghiêm ngặt theo thứ tự khai báo, nên việc chạy đồng thời không bao giờ phá vỡ giao thức. Các công cụ chỉ đọc phổ biến nhất được chuyển ngay từ tuần tự sang song song, và thời gian thực thi thực tế của cả nhóm giảm rõ rệt.
Đọc trước khi ghi + kiểm soát đồng thời lạc quan. Trước khi sửa một tệp, bạn phải đọc tệp đó; bộ máy ghi lại trạng thái gốc của tệp đã đọc và kiểm tra xem trạng thái ấy có thay đổi vào thời điểm chỉnh sửa hay không. Khi các tác tử thực thi song song cùng sửa một tệp, bên không ghi được sẽ nhận lỗi “đã lỗi thời” rõ ràng thay vì âm thầm ghi đè thay đổi của nhau. Khi nhiều tác tử thực thi hoạt động song song trong cùng một không gian làm việc, cơ chế bảo vệ này là không thể thiếu.
Tiếp nhận ngay thông tin chen ngang khi đang chạy. Khi người dùng thêm một dòng trong lúc tác tử đang làm dở, bộ máy đưa tin nhắn đang chờ đó vào đầu vào của lượt hiện tại tại ranh giới vòng lặp công cụ, thay vì chờ khởi chạy một lượt riêng. Nhờ vậy, việc “điều chỉnh hướng khi đang chạy” trở thành một tương tác tự nhiên.
Phát hiện vòng lặp. Khi cùng một lệnh gọi công cụ lặp lại liên tiếp, bộ máy trước tiên nhắc nhở (ở lần thứ 3), rồi buộc dừng (ở lần thứ 5); bất kỳ chữ ký lệnh gọi nào khác đi đều đặt lại bộ đếm — những biến thể hợp lệ như phân trang hoặc thăm dò trạng thái sẽ không bị nhận nhầm. Khi mô hình mắc kẹt, nó không còn âm thầm đốt token.
Bỏ giới hạn cứng cho đầu ra của lượt chính. Đầu ra của lượt chính không còn bị ép vào một giới hạn quá nhỏ, nên báo cáo dài và các chỉnh sửa lớn không bị âm thầm cắt cụt; các lệnh gọi phụ trợ (nén, tự suy xét) vẫn thận trọng dùng giới hạn nhỏ.

Có một chi tiết rất “bản địa” đáng nhắc đến: ước tính token cho văn bản trộn tiếng Trung và tiếng Anh. Cách ước tính chung có thể đếm thiếu token của một cuộc trò chuyện thuần tiếng Trung từ hai đến ba lần; bộ máy xử lý ký tự tiếng Trung và tiếng Anh khác nhau theo nhóm ký tự, nhờ đó ngưỡng nén mới đáng tin cậy. Đây là kiểu vấn đề mà một SDK dùng chung sẽ không tính hộ bạn.

Gộp lại, những cải tiến này trả lời câu hỏi “tại sao không dùng luôn một SDK có sẵn”: bởi những năng lực mạnh nhất của tác tử trên máy tính lại nằm ngay trong lớp mà SDK không cho phép tiếp cận; để đưa chúng lên mức sẵn sàng vận hành thực tế, bạn phải tự nắm vòng lặp.

2. Giữ mô hình luôn trực tuyến: lớp bọc nhà cung cấp nhiều tầng

Mục tiêu của lớp mô hình gói trong một câu: dù một khóa, một nhà cung cấp hay một mạng gặp trục trặc gì, lượt trò chuyện này của người dùng vẫn phải tiếp tục nếu còn cách. Để làm được điều đó, lớp bộ điều hợp xếp thêm một số lớp bọc trên lớp trừu tượng nhà cung cấp của bộ máy — luân chuyển, tạm nghỉ, đăng ký và thích ứng bên ngoài.

Thiết kế quan trọng nhất là bộ luân chuyển nằm dưới bộ thực thi. Bộ máy ghi tin nhắn của người dùng vào phiên được lưu bền vững trước khi gọi bất kỳ nhà cung cấp nào; nếu thử lại hoặc luân chuyển ở cấp bộ máy, bạn sẽ phải gửi lại tin nhắn người dùng hoặc viết cả cơ chế hoàn tác phiên. Đặt bộ luân chuyển bên dưới bộ máy giúp tin nhắn người dùng được ghi đúng một lần, còn việc “thử lại với ứng viên khác” hoàn toàn không ảnh hưởng đến trạng thái phiên.

Cách phán đoán của bộ luân chuyển cũng có chừng mực, lấy mốc sự kiện nội dung đầu tiên:

Nếu xảy ra lỗi trước khi mô hình phát ra bất kỳ nội dung thực chất nào (văn bản hoặc lệnh gọi công cụ) — có thể an toàn chuyển sang ứng viên tiếp theo;
Khi sự kiện nội dung đầu tiên đã được phát ra — ngừng luân chuyển và để lỗi truyền lên trên, vì mô hình có thể đã thực hiện trọn một lượt, và làm lại sẽ lặp lại các tác động phụ.

Phân loại lỗi quyết định “luân chuyển, không luân chuyển hay thử lại”. Các lỗi cấp tài khoản như xác thực thất bại, không đủ số dư, giới hạn tốc độ, thuê bao hết hạn — đánh dấu tạm nghỉ rồi luân chuyển; các lỗi mạng tạm thời như kết nối bị đặt lại — không tạm nghỉ, thử lại ngay tại chỗ vài lần theo cách không lưu trạng thái; còn yêu cầu sai định dạng, lỗi chính sách nội dung và lỗi máy chủ 5xx — vốn vẫn thất bại như vậy với khóa khác — được truyền thẳng lên mà không luân chuyển. Thời gian tạm nghỉ là một tín hiệu kéo dài mười phút, chỉ nằm trong tiến trình, không lưu bền vững : đây chỉ là tín hiệu ngắn hạn, không đáng ghi xuống đĩa sau mỗi lần lỗi, và lúc khởi động lại tiến trình chính là thời điểm thích hợp để thăm dò lại.

Về “danh sách” nhà cung cấp, đợt tái cấu trúc quy ba loại nguồn về một lớp trừu tượng thống nhất:

LLM do Orkas quản lý: một proxy phía máy chủ, dùng được ngay sau khi đăng nhập, với máy chủ định tuyến giữa các mô hình văn bản và hình ảnh;
Dùng khóa của riêng bạn: các nhà cung cấp mô hình lớn phổ biến theo chuẩn thông dụng;
Bộ điều hợp kết nối trực tiếp bên ngoài: một nhóm mô hình cần kết nối trực tiếp hoặc có cơ chế tính phí riêng, được điều chỉnh thủ công để dùng chung giao diện nhà cung cấp.

Với các lớp phía trên, tất cả chỉ hiện ra dưới dạng một cặp ổn định (provider, model) — việc luân chuyển, tạm nghỉ và thích ứng bên ngoài đều được ẩn trong lớp bộ điều hợp.

3. Điều phối bằng trò chuyện nhóm: từ DAG kế hoạch tĩnh đến chỉ huy trực tiếp trong vòng lặp

Đây là phần đòi hỏi “đổi hẳn cách nghĩ” nhiều nhất trong đợt tái cấu trúc.

Mô hình cũ là lập kế hoạch tĩnh: mô hình tạo kế hoạch/DAG trước, rồi bộ thực thi chạy theo đồ thị. Mô hình mới bỏ hoàn toàn đồ thị đó và thay bằng cơ chế điều phối trò chuyện nhóm động, có chỉ huy trực tiếp trong vòng lặp.

Hình ảnh ví von của cơ chế này là một phòng trò chuyện nhóm:

Trong đó, Commander là người chủ trì phòng, không phải một lớp trung gian vô hình;
Các tác tử thực thi là thành viên bình đẳng, được đối xử như thành phần chính thức trong phòng;
Mọi tương tác đều là tin nhắn bất đồng bộ, được đưa vào hàng đợi qua một bus thông điệp duy nhất (không có đường riêng để phân nhánh thực thi song song).

Lệnh “phân công” của chỉ huy không phải là một @somebody được viết trong văn xuôi — việc LLM viết @AgentA trong nội dung chỉ là markdown học từ dữ liệu huấn luyện, không đáng tin cậy. Tín hiệu phân công thực sự là một lệnh gọi công cụ có cấu trúc, và sau tái cấu trúc, nó được quy về ba hành động có ngữ nghĩa rõ ràng:

dispatch_to — giao cho một tác tử thực hiện đến khi hoàn tất rồi trả kết quả về để chỉ huy tổng hợp. Nhiều tác vụ độc lập có thể được phân ra chạy đồng thời.
run_worker — một tác vụ con do chính chỉ huy phụ trách, với kết quả được trả về đồng bộ; tác tử thực thi ẩn danh là “cánh tay” của chỉ huy (người dùng không nhìn thấy), còn tác tử thực thi có tên là chuyên gia hiển thị rõ ràng.
hand_off_to — chuyển cuộc trò chuyện cho tác tử; chỉ huy rút lui, và tác tử trả lời trực tiếp người dùng mà không có bước tổng hợp thêm trong lượt này.

Vì sao là trò chuyện nhóm thay vì bộ điều phối hay cây tác tử con

Tổ chức hệ thống đa tác tử thành trò chuyện nhóm mang lại một số lợi ích mà bộ điều phối hoặc cây tác tử con truyền thống không có:

Phân vùng theo quyền xem. Mỗi tin nhắn chỉ được thêm vào phần lịch sử của “những ai có thể xem nó”. Khi một tác tử thực thi khởi động, nó chỉ phát lại phần lịch sử của chính mình, nên đầu ra lớn của tác tử khác không làm nhiễu ngữ cảnh của nó. Chỉ huy nhìn thấy mọi thứ.
Trạng thái tối thiểu. Trạng thái cốt lõi của toàn bộ cơ chế điều phối chỉ gồm “ai đang giữ lượt nói” và một sổ theo dõi tác vụ gọn nhẹ. Không có DAG, không có máy trạng thái phức tạp.
Tự nhiên hỗ trợ phát lại và đồng bộ. Tin nhắn được sắp xếp tự nhiên theo dấu thời gian, nên việc tải lại và đồng bộ giữa các thiết bị đều dựa trực tiếp vào luồng tin nhắn. Phía di động thực hiện điều khiển từ xa chính nhờ luồng này — mọi hoạt động tính toán của tác tử đều chạy trên máy tính, còn thiết bị di động chỉ hiển thị bản phản chiếu, không cần giao thức điều phối riêng.

Đánh giá kiến trúc của nhóm cũng rất thẳng thắn về điểm này: bus trò chuyện nhóm cộng với chỉ huy trực tiếp trong vòng lặp chính là hình thái đa tác tử của Orkas; xếp thêm một đường phân công tác tử con song song trong tiến trình sẽ vi phạm nguyên tắc bất biến “chỉ có một đường phân công qua trò chuyện nhóm”.

Điểm mới trong phiên bản này: bàn giao tương tác

Thành phần mới nhất theo hướng này là bàn giao tác tử tương tác.

Vấn đề rất cụ thể: một tác tử kiểu “gia sư” hướng dẫn người dùng trong một lượt, người dùng muốn tiếp tục hỏi, nhưng hệ thống lại buộc trả lượt nói về cho chỉ huy, khiến người dùng phải gọi lại bằng@ tác tử đó ở từng dòng.

Giải pháp là quyền giữ lượt nói do máy chủ quyết định + người nhận do mô hình chọn:

Quyền giữ lượt nói trở thành một trường trạng thái được lưu bền vững qua các lần tải lại, và tận dụng sự kiện thay đổi trạng thái hiện có để tự động đồng bộ đến mọi phía — không cần loại sự kiện mới.
Sau khi chỉ huy dùng hand_off_to để giao lượt nói cho một tác tử tương tác, các tin nhắn tiếp theo của người dùng “không có@” sẽ được gửi thẳng đến tác tử đó, cho đến khi tác tử tự trả quyền điều khiển hoặc người dùng gọi lại chỉ huy.
Tác tử trả quyền điều khiển bằng dấu <handback /> ; bộ phân tích kiểm tra nghiêm ngặt để khớp chính xác (nhờ vậy một chuỗi <handback tình cờ xuất hiện trong văn xuôi không bị hiểu nhầm là bàn giao).
Nếu khi trả quyền điều khiển vẫn còn tác vụ chưa hoàn tất trong sổ theo dõi, chỉ huy sẽ tiếp nhận từ sổ đó và tiếp tục.

Đi kèm còn có một cải tiến trải nghiệm — các bong bóng vòng lặp của chỉ huy. Vòng lặp “phân công → đọc kết quả → phân công tiếp” của chỉ huy trong một lượt trước đây bị gộp thành một bong bóng, và khi tải lại còn có thể nhảy sai thứ tự xuống cuối. Đợt tái cấu trúc chia một lượt thành nhiều đoạn tại mỗi ranh giới phân công hiển thị, mỗi đoạn là một tin nhắn độc lập có dấu thời gian tăng dần — lần đầu tiên người dùng có thể thấy chỉ huy “lặp qua các bước điều phối”, và thứ tự khi tải lại cũng chính xác.

Cuối cùng là hai cơ chế bảo vệ xuyên suốt: hủy nhóm là đường dừng duy nhất cho mọi tác nhân (ngay khi người dùng nhấn Dừng, tín hiệu hủy được kích hoạt cho mọi tác tử thực thi, kể cả tác tử con ẩn danh nhờ cơ chế đối chiếu dự phòng); và cơ chế đã nhắc ở trên ngắt để điều hướng, đưa lời chen ngang của người dùng khi đang chạy vào lượt hiện tại.

4. Từ danh mục khép kín đến nền tảng tiếp nhận mở

Nếu ba hướng xuyên suốt đầu tiên tập trung củng cố nền móng, thì hướng này là mở tung mọi cánh cửa — biến Orkas từ một danh mục khép kín thành nền tảng tiếp nhận mở — đồng thời giữ nguyên ranh giới bảo mật, không nhượng bộ dù chỉ một chút.

Đợt tái cấu trúc đã tháo gỡ có hệ thống một số nút thắt “khép kín”:

Gói bên ngoài. Người dùng cung cấp địa chỉ kho mã, và Orkas lưu trữ gói đó cục bộ bằng cách sao chép nguyên trạng vào một thư mục — không chuẩn hóa, không viết lại, không đồng bộ lên đám mây (vì có các thư mục phụ thuộc bên thứ ba). Một công cụ dòng lệnh độc lập quản lý vòng đời cài đặt/cập nhật/khởi động-dừng, quét xem gói có “dạng kỹ năng” (chứa tệp mô tả kỹ năng) hay “dạng CLI” (chứa điểm vào thực thi), rồi ghi siêu dữ liệu vào một sổ đăng ký nằm ngoài thư mục gói (để các lần cập nhật bằng pull sau này không bao giờ xung đột). Việc cài đặt phần phụ thuộc đi qua quy trình xác nhận hai bước “hỏi một lần, ghi nhớ”; các điểm vào thực thi được tạo shim và đưa vào PATH của công cụ bash, để mô hình gọi trực tiếp những CLI bên thứ ba này.
Nạp kỹ năng từ nhiều thư mục gốc. Điểm vào duy nhất để thực thi kỹ năng đã chuyển từ chỉ nhận hai thư mục gốc sang bốn tầng — tùy chỉnh / chợ kỹ năng / gói bên ngoài / toàn cục — được phân giải theo độ ưu tiên; các tập lệnh trong gói bên ngoài ưu tiên môi trường phụ thuộc đi kèm chính gói đó. Đây là nút thắt có nguy cơ gây lỗi hồi quy cao nhất, và được bảo vệ bằng một ma trận dữ liệu kiểm thử đầy đủ.
Liên thông kỹ năng toàn cục. Orkas đọc trực tiếp từ các thư mục kỹ năng toàn cục mà những công cụ tác tử khác trên máy người dùng đã duy trì, tạo khả năng liên thông ở cấp kỹ năng — kỹ năng người dùng tích lũy ở một nơi cũng dùng được trong Orkas. Việc người dùng đặt kỹ năng vào những thư mục đó tự nó đã là sự cho phép, nên tính năng được bật mặc định và vẫn có công tắc tổng. Những mô tả kỹ năng bên thứ ba này là bề mặt chèn chỉ dẫn không đáng tin cậy, nên chúng đi qua bộ nạp “tầng mở”, chỉ hiển thị với chỉ huy và về mặt cấu trúc không thể lọt vào danh sách kỹ năng được phép của một tác tử.
MCP do người dùng cấu hình. Trình kết nối không còn là danh mục được mã hóa cứng. Người dùng có thể thêm bất kỳ máy chủ MCP nào — dạng HTTP từ xa (rủi ro thấp) hoặc dạng tiến trình con cục bộ (rủi ro cao). Chính biểu mẫu là nơi thể hiện sự đồng ý (lệnh người dùng tự gõ được hiển thị nguyên văn), toàn bộ cấu hình truyền tải (kể cả thông tin bí mật) được đưa vào kho lưu trữ mã hóa, và các phiên bản tùy chỉnh luôn mang tiền tố cố định để không bao giờ mạo danh trình kết nối chính thức trong danh mục.
Cầu nối ngược: để các tác tử bên ngoài trên máy cũng nhận biết được Orkas. Đây là phần thú vị nhất. Các công cụ tác tử bên ngoài đã có trên máy người dùng trước đây là một hộp đen đối với Orkas; giờ đây, khi Orkas phân công cho chúng, hệ thống chèn một kênh cầu nối cho phép chúng theo chiều ngược lại liệt kê/đọc/chạy kỹ năng của Orkas, gọi trình kết nối và tìm kiếm cơ sở tri thức. Cầu nối chạy qua kênh liên tiến trình cục bộ (không mở cổng mạng), được xác thực bằng thông tin xác thực dùng một lần, riêng biệt cho mỗi lần chạy và bị hủy ngay khi lần chạy kết thúc. Mọi lệnh gọi trình kết nối gây tác động ra bên ngoài đều đi qua hộp thoại xác nhận của người dùng — không phán đoán đọc/ghi theo kinh nghiệm dựa trên tên công cụ (vốn dễ quá lỏng lẻo), mà xác nhận một lần cho mỗi cặp (tác tử, trình kết nối), kèm tùy chọn “luôn cho phép”.
Cách tiếp cận lập trình cho các nhu cầu ít gặp. Cây quyết định của chỉ huy có thêm một nhánh: khi không có tác tử/kỹ năng/trình kết nối phù hợp, đánh giá khả năng giải quyết trực tiếp bằng bash cùng một tập lệnh ngắn, thực hiện ngay trong lượt này, kiểm chứng đầu ra và có thể đề nghị đúc kết thành kỹ năng tùy chỉnh. Đi kèm là thực thi bash nền (tác vụ dài tách khỏi lượt hiện tại, nhật ký được ghi vào tệp) và các thư mục do người dùng cấp quyền.

Mở nhưng vẫn kiểm soát

Điều đáng lo nhất khi mở tung cửa là gió lùa. Nguyên tắc của đợt tái cấu trúc này là: không đụng đến bất kỳ điểm kiểm soát khởi chạy nào của “hành động nguy hiểm”. MCP chỉ khởi chạy từ đúng một nơi, kỹ năng chỉ thực thi qua đúng một bộ thực thi, và bash chỉ đi qua đúng một bộ thực thi trong hộp cát. Trên đó còn có nhiều lớp bảo vệ chiều sâu:

Thao tác tệp luôn đi qua hộp cát đường dẫn (không gian làm việc + tệp đính kèm hiện tại + thư mục người dùng cấp quyền rõ ràng), trong khi các thư mục thông tin xác thực, thư mục hệ thống và thư mục riêng của Orkas không thể được cấp quyền;
Lệnh bash nguy hiểm (rò rỉ dữ liệu, xóa phá hủy, nâng quyền, đường dẫn nhạy cảm) sẽ kích hoạt xác nhận quyền, với lựa chọn “chỉ lần này / trong lần chạy này / từ chối”, và nhật ký chỉ ghi loại cùng độ dài — không bao giờ ghi nội dung lệnh;
Việc cài đặt gói bên ngoài mặc định chặn khi không an toàn và từ chối hoàn toàn các gói chứa liên kết tượng trưng (để ngăn việc dùng liên kết đó đưa tệp nhạy cảm ngoài hộp cát vào phạm vi đọc), còn nguồn sao chép bị giới hạn theo danh sách giao thức được phép;
Mọi cấu hình truyền tải/thông tin bí mật có chứa thông tin xác thực đều được mã hóa khi lưu trữ, và thông tin xác thực cầu nối được cách ly theo từng lần chạy;
Bản phân phối mã nguồn mở / được lưu trữ loại bỏ các năng lực độc quyền của ứng dụng chủ bằng quy tắc cắt bỏ.

Gói trong một câu: mỗi hành động rõ ràng của người dùng (cài đặt / cấp quyền / gửi biểu mẫu / nhấn xác nhận) là bằng chứng đồng ý, và mỗi sự đồng ý chỉ có hiệu lực trong đúng ranh giới tương ứng.

5. Thông minh hơn qua các phiên: bộ nhớ và tự tiến hóa

Đợt đại tu nền tảng cũng làm lại hai hệ thống con giúp “tác tử càng dùng càng thông minh”, cả hai đều theo cùng một nguyên tắc kỹ thuật — tắt mặc định, có giới hạn, có thể quan sát.

Bộ nhớ xuyên phiên dùng truy xuất kết hợp: tìm kiếm ngữ nghĩa bằng vector + tìm kiếm từ khóa (BM25), hợp nhất bằng RRF (hợp nhất thứ hạng nghịch đảo) để tránh phụ thuộc vào một kênh có thể thất bại; dữ liệu được lưu cục bộ (kèm chỉ mục toàn văn). Bộ nhớ có hai loại — ghi chú riêng của tác tử và hồ sơ sở thích người dùng — mỗi loại có giới hạn ký tự, được quét nguy cơ chèn chỉ dẫn trước khi ghi, rồi được chốt cố định và chèn vào chỉ dẫn hệ thống ở đầu mỗi lượt. Toàn bộ hệ thống bộ nhớ chỉ phục vụ việc giúp tác tử hiểu người dùng hiện tại tốt hơn; dữ liệu luôn ở cục bộ, và người dùng có thể xem, sửa, xuất bất cứ lúc nào trong phần cài đặt.

Tự phát triển là một thư viện kỹ năng riêng của tác tử (được lưu tách biệt với thư viện kỹ năng dùng chung của nền tảng) cộng thêm một lớp tự suy xét về cách tư duy. Bộ máy quyết định có tự suy xét hay không dựa trên một tập tín hiệu có trọng số: người dùng sửa sai (trọng số cao nhất), khắc phục một lỗi đáng kể, độ phức tạp của tác vụ, điểm yếu đã biết bị kích hoạt hoặc được vượt qua, kỹ năng không hiệu quả... việc tự suy xét chỉ khởi động khi tổng tín hiệu có trọng số vượt ngưỡng. Bản thân việc tự suy xét là một tác vụ định kỳ chạy nền (khoảng một vòng mỗi 12 giờ, thời gian tạm nghỉ vài giờ, cơ chế dự phòng sau nhiều ngày), dùng một mô hình nhỏ chi phí thấp để đọc bản tóm tắt hoạt động gần đây rồi quyết định có tạo/vá kỹ năng và cập nhật “hồ sơ năng lực” của tác tử hay không.

Điểm an toàn quan trọng nhất: tự tiến hóa chỉ được bật cho các phiên đã được gắn rõ ràng với một tác tử — phiên chỉ huy mặc định không tiến hóa. Hoạt động tự suy xét có giới hạn token kép (số lượng + tổng cộng), lỗi của một tác tử không chặn các tác tử khác, và chi phí mỗi lần chạy được giữ cực thấp. Làm tác tử thông minh hơn, nhưng không để nó vượt ngoài tầm kiểm soát.

Triết lý kỹ thuật: độ phức tạp có lý do — đừng đơn giản hóa đến mức loại bỏ nó

Nhóm đã tiến hành nhiều vòng đánh giá kiến trúc trong quá trình tái cấu trúc, và một kết luận liên tục xuất hiện, đáng được tách riêng: phân biệt “sự phình to về tổ chức” với “độ phức tạp có lý do”, và chỉ xử lý cái trước.

Nhiều chiến lược hợp nhất của bộ máy đồng bộ, vòng lặp tác tử tự xây, lớp bọc nhà cung cấp nhiều tầng, ranh giới điều khiển từ xa trên di động — tất cả trông phức tạp, nhưng mỗi lớp đều có lý do tồn tại (nhất quán sau cùng giữa nhiều thiết bị, tích hợp sâu, luân chuyển nhiều khóa, ranh giới phía thiết bị do sản phẩm xác định). Cưỡng ép “đơn giản hóa” chúng chỉ làm mất dữ liệu và khiến phân lớp trở nên mập mờ.
Những thứ thực sự cần xử lý là các “mô-đun ôm đồm” và phần trùng lặp cục bộ: tách các hàm thuần không trạng thái ra khỏi bus trò chuyện nhóm cồng kềnh (lắp ghép chỉ dẫn, công cụ của chỉ huy, lượt CLI), và gom mẫu “hộp thoại xác nhận” bị lặp nhiều lần thành một thành phần dùng chung.

Cơ sở cho cách phán đoán này là một tập nguyên tắc cứng được ghi trong tài liệu ràng buộc của dự án: ranh giới (một tiến trình duy nhất, IPC là đường duy nhất, môi trường thực thi chỉ được nạp động), phân lớp (hướng phụ thuộc của từng lớp), nguồn dữ liệu chuẩn duy nhất (danh mục, hệ phân loại dữ liệu đo lường, miền), và yêu cầu bắt buộc “kiểm tra chỉ dẫn” với mọi bản ghi thay đổi có liên quan đến chỉ dẫn. Điều giúp đại tu nền móng mà không làm hệ thống sụp đổ không phải một thiết kế tài tình nào — mà là việc liên tục giữ vững những nguyên tắc bất biến này.

Lời kết

Kết hợp bốn hướng xuyên suốt, đợt tái cấu trúc từ gốc này thay cho Orkas một nền tảng tác tử tự chủ, không phụ thuộc nhà cung cấp, điều phối động, mở ra bên ngoài và có khả năng tự tiến hóa:

Một môi trường thực thi ngay trong tiến trình với hai lớp bộ máy/bộ điều hợp, đưa trọn bộ thế mạnh của tác tử lập trình — thao tác tệp, tìm kiếm cục bộ, công cụ hệ thống, nhiều tác tử thực thi song song, giải quyết tác vụ dài hạn — lên máy tính một cách nguyên bản và đưa từng năng lực lên mức sẵn sàng vận hành thực tế;
Một lớp mô hình nhiều tầng duy trì cuộc trò chuyện qua các biến động về khóa/nhà cung cấp/mạng trong khả năng tối đa;
Một cơ chế điều phối đa tác tử theo kiểu trò chuyện nhóm, có chỉ huy trực tiếp trong vòng lặp, thay “lập kế hoạch tĩnh” bằng “quyết định động”, và lần đầu tiên khiến việc bàn giao giữa các tác tử trở nên tự nhiên;
Một hệ sinh thái chuyển từ danh mục khép kín sang nền tảng tiếp nhận mở, khai thông gói bên ngoài, kỹ năng toàn cục, MCP tùy chỉnh và cầu nối ngược — trong khi các điểm kiểm soát khởi chạy vẫn giữ nguyên;
Cùng bộ nhớ và khả năng tự tiến hóa được tắt mặc định, có giới hạn và có thể quan sát.

Tính năng có thể được thêm từng cái một, nhưng nền móng chỉ đáng được đại tu nghiêm túc một lần. Khi đã xong, mọi thứ xây trên đó đều nhanh hơn — và đó chính là kết quả mà đợt tái cấu trúc này hướng tới.