Hầu hết các nhóm agent đều không tự xây dựng một bộ khung (harness). Họ áp dụng một bộ khung có sẵn. LangChain, LangGraph, OpenAI Agents SDK, Anthropic SDK, CrewAI, AutoGen, vòng lặp, công cụ, bộ nhớ và cơ chế điều phối đều được chọn có sẵn như một quyết định duy nhất. Bộ khung là một framework bạn import vào. Nếu có thứ gì đó bên trong không phù hợp, bạn fork nó, đấu tranh với nó, hoặc tìm cách vượt qua nó.
Tôi nghĩ cách tiếp cận đó là sai lầm, và đó là lý do tại sao mọi nhóm agent vận hành lâu dài cuối cùng đều phải viết lại bộ khung của họ từ đầu. Bộ khung không phải là một thứ duy nhất. Nó là mười hoặc mười hai thứ khác nhau được gói gọn lại với nhau vì hệ sinh thái xung quanh không cho bạn cách để kết hợp chúng. Các gói Pi agent đang đi đúng hướng, nhưng chúng vẫn nằm trong mô hình "Thêm một dịch vụ khác và tích hợp nó với tất cả các dịch vụ khác". Công cụ iii xử lý tất cả các worker như nhau và loại bỏ hoàn toàn logic tích hợp. Bộ định tuyến nhà cung cấp, kho lưu trữ thông tin xác thực, công cụ chính sách, cổng phê duyệt, danh mục mô hình, bộ nhớ phiên, trình theo dõi ngân sách, bộ khuếch tán hook sau cuộc gọi và vòng lặp turn bền bỉ là những mối quan tâm độc lập. Tất cả những thứ này đều có thể tương tác với hàng đợi, máy chủ HTTP/API, phát trực tuyến, thậm chí cả worker trên trình duyệt của bạn. Một framework vận chuyển chúng như một khối duy nhất đang bán cho bạn một sự đánh đổi mà lẽ ra bạn không cần phải thực hiện.
Giả định cốt lõi đằng sau iii là chúng không nên là một khối duy nhất. Cần có một tập hợp các worker trên một công cụ chia sẻ, mỗi worker có thể thay thế, mỗi worker có phiên bản độc lập, mỗi worker được kết nối bằng một nguyên thủy duy nhất: một trigger (iii.trigger()) mà mọi worker khác cũng sử dụng. Bộ khung trở thành một chồng các worker có thể cài đặt, và "tự xây dựng bộ khung của riêng bạn" không còn có nghĩa là "fork một framework". Nó có nghĩa là "hoán đổi một vài worker".
Bài viết này sẽ trình bày chi tiết về điều đó thực sự trông như thế nào. Toàn bộ stack điều khiển một lượt tương tác (turn) của agent iii hiện tại, tại sao mỗi lớp lại là một worker riêng của nó và cách bạn thay thế bất kỳ worker nào trong số chúng.
15 nhiệm vụ mà một bộ khung agent phải thực hiện
Nếu bạn tách bộ khung agent sản xuất ra thành các trách nhiệm của nó, bạn sẽ có một danh sách trông giống như thế này:
- Chấp nhận một yêu cầu turn từ client và lưu trữ nó
- Giải quyết thông tin xác thực cho bất kỳ nhà cung cấp mô hình nào được gọi
- Tra cứu những gì mô hình đã chọn thực sự có thể làm (tầm nhìn, công cụ, phát trực tuyến, cửa sổ ngữ cảnh)
- Điều khiển máy trạng thái cho mỗi turn, cung cấp, phát trợ lý, chạy công cụ, điều hướng, dọn dẹp
- Tải và phục vụ các thân kỹ năng (skill bodies) mô tả hình dạng yêu cầu, mã lỗi và ghi chú sử dụng của từng chức năng
- Lắp ráp prompt hệ thống, đoạn chế độ (mode paragraph), phần mở đầu nhận dạng (identity preamble), thư mục làm việc (working directory) và phụ lục kỹ năng mặc định (default skills appendix)
- Phát trực tiếp các token về client khi mô hình tạo ra chúng
- Kiểm tra mọi lệnh gọi công cụ (chỉ là một hàm) dựa trên chính sách trước khi nó chạy
- Tạm dừng các lệnh gọi công cụ cần quyết định của con người và định tuyến câu trả lời trở lại đúng turn
- Theo dõi chi tiêu LLM so với ngân sách cho mỗi workspace hoặc mỗi agent
- Chạy các hook trước và sau khi gọi công cụ (ghi log, chỉnh sửa, tác dụng phụ tùy chỉnh)
- Lưu trữ phiên dưới dạng cây phân nhánh để fork và tiếp tục hoạt động
- Thu gọn lịch sử phiên khi cửa sổ ngữ cảnh đầy lên
- Phát ra một luồng sự kiện mà giao diện người dùng (UI) đăng ký theo dõi
- Mảnh ghép còn thiếu từ mọi công ty xây dựng agent mà tôi thấy. Mang một OpenTelemetry trace qua mọi bước để bạn có thể gỡ lỗi nó
Mọi bộ khung agent nghiêm túc đều thực hiện hầu hết những việc này. Những cái đắt tiền thực hiện tất cả. Những cái rẻ tiền cắt góc và sau đó xây dựng lại các góc đó khi chúng gặp sản xuất. Các framework đóng gói chúng thành một khối nguyên khối và vận chuyển một phiên bản của mỗi thứ. Phần cuối cùng đó là phần khiến bạn tốn kém, bởi vì sau một năm, bạn phát hiện ra rằng công cụ chính sách bạn muốn không phải là công cụ chính sách mà framework vận chuyển, và việc thay thế nó đồng nghĩa với việc thay thế toàn bộ bộ khung.
Bộ khung iii vận chuyển mỗi một trong mười ba nhiệm vụ đó như một worker riêng biệt trên registry workers.iii.dev. Mỗi worker nói cùng một giao thức WebSocket. Mỗi worker đăng ký các hàm và trigger trên cùng một bus công cụ. Mỗi worker đều có thể thêm vào bằng iii worker add, có thể hoán đổi và có thể viết bằng bất kỳ ngôn ngữ nào có SDK.
Stack, theo từng worker
Đây là stack sản xuất thực tế từ monorepo iii-hq/workers, với nhiệm vụ của mỗi worker trong một dòng. Toàn bộ gói được vận chuyển tại github.com/iii-hq/workers/harness:
Mười một worker. Một công cụ. Mỗi worker có một phiên bản đã được phát hành. Mỗi worker có thể chạy độc lập như một tiến trình riêng (pnpm dev:<worker> trong môi trường dev, iii worker add <specific-worker> dưới dạng nhị phân phát hành) hoặc là một phần của điểm vào tổng hợp (composite entry point) khởi động chúng cùng nhau.
Lý do điều này quan trọng: mỗi ô trong bảng đó là một nơi mà ai đó có thể đưa cho bạn một worker khác và bạn giữ nguyên phần còn lại. Không thích danh mục mô hình tĩnh? Cắm vào một worker đăng ký models::list và đọc từ một API trực tiếp. Không thích thông tin xác thực dựa trên tệp? Cắm vào một worker đăng ký auth::get_token và đọc từ một trình quản lý bí mật (secrets manager). Muốn một FSM turn khác cho một quy trình làm việc phân nhánh khác? Thay thế turn-orchestrator, mọi worker phụ thuộc gọi run::start và đọc turn_state qua cùng một bus, vì vậy phần còn lại của stack không thay đổi.
Vòng lặp thực sự chạy như thế nào
Hình dạng của một turn trông như thế này, đi qua các worker theo thứ tự chúng được kích hoạt.
Một trình duyệt/CLI/chat POST một turn thông qua harness::trigger với {session_id, message_id, payload}. Worker meta (harness meta-worker) chuyển tiếp payload đến run::start. Bước nhảy đó tồn tại để trình bao bọc OpenTelemetry span có thể gieo (seed) session ID và message ID dưới dạng baggage, được truyền đến mọi lệnh gọi iii.trigger lồng nhau trên mọi worker trong stack. Cây trace ở phía bên kia là một đồ thị được kết nối.
run::start đến turn-orchestrator. Nó lưu trữ yêu cầu chạy, gieo bản ghi TurnStateRecord ban đầu vào trạng thái iii tại session/<sid>/turn_state, và trả về ngay lập tức. Công việc thực tế diễn ra bên trong máy trạng thái bền bỉ cho mỗi turn, được đánh thức bởi các bài đăng lên FIFO turn-step.
Hai trạng thái cuối là stopped (thoát sạch qua finishSession()) và failed (một lỗi ném ra từ trình xử lý không mong muốn sẽ kết thúc ở đây, xác nhận hàng đợi để nó ngừng thử lại, và hiển thị message_complete{stop_reason:'error'} cùng agent_end để UI hiển thị lý do). Dọn dẹp (teardown) là một cổng finishSession() nội tuyến được gọi từ bất kỳ đường dẫn kết thúc turn nào, không phải là một bước xếp hàng riêng biệt.
provisioning thực hiện ba việc. Nó khởi động một microVM iii-sandbox nếu lần chạy cần thực thi biệt lập. Nó gọi directory::skills::download cho mọi namespace trong system_default_skills (mặc định ["iii://iii-directory/index"]) để iii-directory lưu vào bộ nhớ đệm trước các thân kỹ năng mà lần chạy bắt đầu. Và nó lắp ráp prompt hệ thống thành ba lớp: một đoạn chế độ được chọn từ run_request.mode (plan, ask, hoặc agent), phần mở đầu nhận dạng iii dạy cho mô hình quy ước agent_trigger và mô hình khám phá theo yêu cầu directory::skills::get, và một chỉ mục được thêm vào của các kỹ năng mặc định mà agent khởi động cùng. Người gọi có thể ghi đè toàn bộ prompt bằng cách truyền system_prompt trên run::start; nếu không, turn-orchestrator sẽ xây dựng nó. Lược đồ hàm (Function schemas) đến từ danh mục công cụ trực tiếp.
assistant_streaming gọi provider::<name>::stream trên bất kỳ worker nhà cung cấp nào phù hợp với trường provider của lần chạy. Worker nhà cung cấp kéo thông tin xác thực qua auth::get_token (auth-credentials), phát trực tiếp phản hồi SSE của mô hình vào một kênh iii, và turn-orchestrator rút cạn kênh đó, phát ra các sự kiện message_update trên agent::events để phân phối đến UI. Việc tạo kênh và vòng lặp đọc nằm đằng sau một MessagePump dựa trên pull trong provider-stream.ts, để trạng thái phát trực tiếp tập trung vào các chuyển đổi.
Khi trợ lý trả về các lệnh gọi công cụ, FSM进入到 function_execute. Mọi lệnh gọi công cụ đều đi qua dispatchWithHook, điểm kiểm soát duy nhất trong turn-orchestrator. consultBefore gọi policy::check_permissions trực tiếp với thời gian chờ 5 giây. Worker chính sách (worker meta, trong stack mặc định) đọc iii-permissions.yaml, khớp function_id của lệnh gọi với tập hợp quy tắc, và trả về một trong ba kết quả:
allow: việc gửi đi tiếp tục;turn-orchestratorkích hoạt hàm đích và ghi kết quảdeny: việc gửi đi bị cắt ngắn với mộtDenialEnvelope, kết quả trở thành một bản ghi từ chốineeds_approval: lệnh gọi riêng lẻ được đưa vào danh sáchawaiting_approvalcủa turn. Phần còn lại của lô tiếp tục được gửi đi. Turn chuyển sangfunction_awaiting_approvalchỉ khi có một hoặc nhiều mục đang chờ xử lý.
Sự đánh thức phê duyệt (approval wake) là phản ứng và được chia sẻ. turn-orchestrator đăng ký chính xác một state trigger turn::on_approval trên scope approvals. Khi console gọi approval::resolve, worker approval-gate ghi approvals/<sid>/<cid> = {decision, reason} vào trạng thái iii. Việc ghi đó kích hoạt turn::on_approval, giúp phiên bị ảnh hưởng tiến triển. function_awaiting_approval chỉ đọc các quyết định vừa được đưa ra, gửi đi từng cái khi nó đến (allow trở thành một dispatch được phê duyệt trước, deny hoặc aborted trở thành một từ chối tổng hợp), và tiến triển khi awaiting_approval[] trống. Không có hàm tiếp tục cho mỗi lần gọi nào cần đăng ký. Không cần quét lại khi khởi động để khôi phục các phê duyệt đang chờ xử lý. Một trigger bao phủ mọi phiên.
Fail-closed theo thiết kế: nếu worker chính sách không thể truy cập hoặc hết thời gian chờ 5 giây, consultBefore từ chối lệnh gọi với một phong bì gate_unavailable. Nếu iii::durable::publish tự nó gặp lỗi, hook fanout trả về publish_failed: true và turn-orchestrator coi nó như một lệnh deny.
Một vài lợi thế về độ trễ xuất hiện từ hình dạng này. Hook sau khi gọi hàm after-function-call rút ngắn publish_collect thông qua bộ đệm subscriber-presence khi không có người đăng ký bền bỉ nào cho chủ đề, loại bỏ khoảng 500ms cho mỗi lần gọi hàm được thực thi. tearing_down được nội tuyến hóa vào finishSession(), loại bỏ một bước nhảy hàng đợi bền bỉ cho mỗi turn. context-compaction đăng ký một luồng agent::turn_end chuyên dụng mà turn-orchestrator phát ra tại ranh giới turn, do đó, các lần đánh thức bộ thu gọn diễn ra theo từng turn thay vì từng sự kiện. State trigger fanout session-create chỉ kiểm tra theo scope và khớp trong tiến trình, do đó, RPC harness::session::is_create_event trước đây cho mỗi lần ghi đã biến mất.
Sau khi lô hoàn thành, steering_check quyết định có tiếp tục, dừng lại hay đạt max_turns. Nếu tiếp tục, quay vòng lại assistant_streaming. Nếu dừng hoặc đạt max, finishSession() chạy nội tuyến: phát ra agent_end, giải phóng sandbox, chuyển sang trạng thái stopped.
Trong suốt toàn bộ quá trình chạy, mọi worker tham gia đều phát ra các span OTel được gắn thẻ bằng iii.session.id, iii.message.id và iii.function.id. Những thẻ này là những gì engine::traces::group_by của công cụ đọc để điền vào "Group by Session" / "Group by Message" / "Group by Function" trong giao diện traces. Tính năng instrumentation là tự động: src/runtime/worker.ts bao bọc mọi registerFunction trong một Proxy để không có worker nào phải nhớ thêm span.
Tự xây dựng bộ khung của riêng bạn
Phần thú vị là không có worker nào ở trên là đặc biệt. Mỗi worker là một tiến trình mở một WebSocket đến công cụ, đăng ký một số hàm và trigger, và chạy. Hợp đồng cũng giống như hợp đồng mà mọi worker ứng dụng sử dụng. Bộ khung được xây dựng trên cùng một nguyên thủy mà logic kinh doanh của bạn được xây dựng trên đó.
Điều đó có nghĩa là "tự xây dựng bộ khung của riêng bạn" được phân rã thành cùng một thao tác như "viết bất kỳ worker nào". Bạn chọn lớp bạn muốn thay thế, bạn viết một worker đăng ký các hàm tương tự trên bus, bạn dùng iii worker add để thêm nó, và phần còn lại của stack bắt đầu sử dụng worker của bạn.
Hai lớp không xuất hiện trong bảng worker ở trên nhưng lại quan trọng đối với cách hoạt động của bộ khung. Kỹ năng (Skills) là cách mỗi worker quảng cáo các hàm của nó làm gì. Mọi worker có thể xuất bản một kỹ năng tại iii://<worker>/<function> mà agent tìm nạp qua directory::skills::get trước khi gọi hàm đó lần đầu tiên. Prompt hệ thống được lắp ráp cho mỗi turn từ một đoạn chế độ, phần mở đầu nhận dạng iii và các thân kỹ năng mặc định mà lần chạy được cấu hình. Cả hai đều do bus điều khiển: kỹ năng được phục vụ bởi worker iii-directory, prompt hệ thống được lắp ráp bởi turn-orchestrator. Cả hai đều có thể thay thế được.
Năm ví dụ cụ thể.
Thay thế danh mục mô hình bằng API trực tiếp. Viết một worker đăng ký models::list, models::get, models::supports. Yêu cầu nó tìm nạp từ endpoint danh mục của nhà cung cấp bạn sau mỗi N phút và lưu vào bộ nhớ đệm. Xuất bản nó. iii worker add your-org/dynamic-models-catalog. Dừng worker models-catalog tĩnh. turn-orchestrator không bao giờ biết sự khác biệt. Nó gọi iii.trigger('models::list') và công cụ định tuyến đến bất kỳ worker nào đã đăng ký id hàm đó gần đây nhất.
Thêm một nhà cung cấp mới. Hình dạng của provider-kimi và provider-lmstudio đã chứng minh điều này. Mỗi worker là một worker đăng ký provider::<name>::stream và provider::<name>::complete, rút cạn một luồng SSE từ API thượng nguồn vào một kênh iii và ghi mức sử dụng mô hình của nó vào llm-budget qua budget::record. Việc thêm một nhà cung cấp thứ năm là viết một thư mục với một iii.worker.yaml và một register.ts. Xuất bản lên registry hoặc giữ nó ở local. turn-orchestrator chọn nhà cung cấp theo trường provider của lần chạy; các nhà cung cấp mới sẽ khả dụng ngay khi worker kết nối.
Phục vụ kỹ năng từ một kho lưu trữ artifact riêng tư. Viết một worker đăng ký directory::skills::get và directory::skills::list, được hỗ trợ bởi hệ thống tài liệu nội bộ của bạn hoặc một bucket S3 riêng tư. Ngắt kết nối hoặc đổi tên worker iii-directory mặc định. Quá trình khởi động của turn-orchestrator gọi directory::skills::download cho mỗi namespace; worker của bạn trả lời. Mô hình "tìm nạp kỹ năng cho mỗi hàm trước khi gọi một hàm mới" của agent tiếp tục hoạt động không thay đổi vì hình dạng dây (wire shape) là giống nhau.
Ghi đè toàn bộ prompt hệ thống. run::start chấp nhận một trường system_prompt tùy chọn. Truyền nó và turn-orchestrator sử dụng chuỗi của bạn nguyên văn, bỏ qua việc lắp ráp đoạn chế độ + phần mở đầu nhận dạng + phụ lục kỹ năng. Hữu ích khi bạn có một tài sản prompt (prompt asset) hiện có mà bạn muốn bộ khung tôn trọng mà không sửa đổi. Tải xuống kỹ năng (Skill download) vẫn chạy trong quá trình khởi động, vì vậy agent vẫn giữ khả năng khám phá theo yêu cầu directory::skills::get ngay cả với prompt tùy chỉnh.
Thay thế bề mặt UI cổng phê duyệt. Worker approval-gate mặc định đăng ký approval::resolve. Lược đồ dây (Wire schema) là một lệnh gọi hàm:
Trình xử lý lưu trữ approvals/<sid>/<cid> = {decision, reason} vào trạng thái iii. State trigger duy nhất turn::on_approval của turn-orchestrator nhận lệnh ghi đó và đánh thức đúng phiên. Nếu bạn muốn điều khiển phê duyệt từ Slack thay vì console, hãy viết một worker Slack lắng nghe các lệnh gạch chéo /approve <id> và /deny <id>, sau đó gọi approval::resolve với payload chính xác. turn-orchestrator không bao giờ biết sự khác biệt. Toàn bộ worker approval-gate vẫn không thay đổi. Bạn đã thêm một worker mới; bạn không thay thế worker hiện có.
Nếu bạn muốn một công cụ chính sách khác (OPA, Cedar, DSL của riêng bạn), hãy viết một worker đăng ký policy::check_permissions và trả về { decision, rule_id?, matched_constraint? }. Ngắt kết nối worker chính sách mặc định (được bọc bên trong worker meta, vì vậy bạn sẽ vô hiệu hóa trình xử lý đó hoặc chạy một worker meta đã được tinh giản). consultBefore của turn-orchestrator không biết sự khác biệt. Cùng thời gian chờ 5 giây, cùng ngữ nghĩa fail-closed, cùng hình dạng dây.
Mục đích của những ví dụ này không phải là các sự thay thế cụ thể. Đó là hình dạng của thao tác. Mọi lớp bộ khung trong stack iii đều có thể truy cập được thông qua một hoặc hai id hàm trên bus. Thay thế một lớp là viết một worker đăng ký các id đó. Phần còn lại của hệ thống vẫn giữ nguyên.
Bộ khung là một thanh trượt, không phải một ngã rẽ
Cuộc tranh luận cổ điển về bộ khung tự đóng khung thành mỏng (thin) so với dày (thick). Vòng lặp mỏng của Anthropic so với DAG rõ ràng của LangGraph. Sự đóng khung đó cho rằng bạn chọn một bên và sống với nó.
Khi bộ khung được cấu thành từ các worker trên cùng một bus, mỏng so với dày chỉ là một số đếm xem bạn cài đặt bao nhiêu worker. Một bộ khung mỏng là turn-orchestrator cộng provider-anthropic cộng auth-credentials cộng một worker meta tối thiểu. Chỉ vậy thôi. Không phê duyệt, không ngân sách, không công cụ chính sách, không khuếch tán hook. Chạy bất cứ thứ gì. Tin tưởng mô hình. Hữu ích cho các agent nghiên cứu tự động, vòng lặp thử nghiệm, bất cứ thứ gì nội bộ.
Một bộ khung dày là tất cả mười ba worker cộng context-compaction cộng một worker chính sách tùy chỉnh cộng một approval-gate tùy chỉnh cộng một bề mặt phê duyệt tích hợp Slack cộng worker ngân sách thực thi giới hạn cho mỗi workspace. Hữu ích cho một agent chạy các quy trình làm việc của khách hàng, nơi mọi lệnh gọi công cụ cần phải kiểm tra được và mọi chi tiêu mô hình phải được tổng hợp lên bảng điều khiển tài chính.
Khoảng cách kiến trúc giữa mỏng và dày không phải là một lần viết lại. Nó là một thay đổi cấu hình. Cùng một giao thức dây, cùng một hình dạng trace, cùng một câu chuyện quan sát. Thanh trượt di chuyển bằng cách thêm và xóa các worker khỏi config.yaml của bạn. Mọi thứ khác vẫn giữ nguyên.
Nó cũng áp dụng bên trong một worker duy nhất. turn-orchestrator vừa phát hành một bản refactor thu gọn FSM của nó từ mười một trạng thái xuống còn bảy, xóa bỏ cơ chế turn::approval_resume::<sid>/<cid> cho mỗi lần gọi để chuyển sang một state trigger phản ứng duy nhất turn::on_approval trên scope approvals, và nội tuyến hóa tearing_down vào một cổng finishSession(). Mọi worker khác trong stack (approval-gate, session, llm-budget, providers, models-catalog, auth-credentials, hook-fanout, context-compaction) vẫn không thay đổi. Hình dạng dây của approval::resolve không di chuyển. Các hợp đồng vẫn được giữ vững. Đó là thuộc tính mà sự cấu thành mang lại cho bạn: một sự viết lại nội bộ lớn của một worker là một thay đổi khép kín vì mọi worker lân cận giao tiếp với nó thông qua các id hàm ở cấp bus.
Đây là phần mà mô hình framework không thể cung cấp cho bạn. Một framework chọn một vị trí trên thanh trượt cho bạn và khóa bạn vào đó. Mô hình worker để lại thanh trượt trong tay bạn.
Điều này có nghĩa là gì trong thực tế
Nếu bạn đã chạy một agent trên nền tảng của một framework và cảm thấy các vấn đề về ranh giới giống như hầu hết các nhóm gặp phải khi mở rộng quy mô, câu trả lời có lẽ không phải là "viết lại bộ khung trong framework của riêng chúng ta". Công cụ chính sách không mở rộng theo cách bạn cần. Giao diện phê duyệt được gắn vào bề mặt trò chuyện của framework. Kho lưu trữ thông tin xác thực không thể nói chuyện với trình quản lý bí mật của bạn. Trình theo dõi ngân sách nằm trong một cơ sở dữ liệu sidecar mà trace không thể thấy. Câu trả lời là chuyển sang một nền tảng (substrate) nơi bộ khung được phân rã ngay từ đầu.
Cách nhanh nhất để cảm nhận lập luận này là clone github.com/iii-hq/workers, pnpm install, pnpm build, và chạy điểm vào tổng hợp (composite entry point). Bạn sẽ có bộ khung đầy đủ mười bốn worker được trỏ đến một công cụ iii. Bạn có thể vô hiệu hóa bất kỳ worker nào bằng cách xóa mục nhập của nó khỏi danh sách khởi động. Bạn có thể hoán đổi bất kỳ worker nào bằng cách viết một worker thay thế đăng ký cùng các id hàm. Bạn có thể mở rộng bất kỳ worker nào bằng cách thêm một người đăng ký vào các chủ đề hook của nó. hook-fanout::publish_collect là generic mà mọi hook iii đều xây dựng trên đó.
Tài liệu nằm tại iii.dev/docs. Công cụ nằm tại github.com/iii-hq/iii. Registry worker nằm tại workers.iii.dev. Gói bộ khung nằm tại github.com/iii-hq/workers/harness.
Giả định cốt lõi
Một bộ khung không phải là thứ bạn cài đặt. Một bộ khung là một tập hợp các công việc mà hệ thống của bạn phải thực hiện để một agent chạy một cách bền bỉ, an toàn và có thể quan sát được. Kỷ nguyên framework đã gói gọn các công việc đó lại với nhau vì không có gì bên dưới cung cấp cho bạn một cách để kết hợp chúng.
Giả định cốt lõi của iii là một nguyên thủy duy nhất: một worker kết nối với công cụ qua WebSocket và đăng ký các hàm và trigger, đủ nhỏ để tiếp nhận riêng rẽ từng công việc trong số đó, và rằng stack kết quả hữu ích hơn bất kỳ framework nào vì mọi lớp đều có thể thay thế độc lập.
Bạn không chấp nhận bộ khung iii. Bạn cài đặt các worker bạn muốn, viết những worker bạn cần, và kết thúc với một bộ khung có hình dạng chính xác như hệ thống của bạn. Cùng một giao thức trên mọi lớp. Cùng một trace xuyên suốt mọi lệnh gọi. Cùng một iii worker add cho các phần bạn lấy từ registry cũng như cho các phần bạn tự xuất bản.
Đó là "tự xây dựng bộ khung agent của riêng bạn" trông như thế nào khi nền tảng có hình dạng phù hợp. Chọn các worker. Viết những worker còn thiếu. Kết hợp. Bộ khung là sự kết hợp.
Hãy tham gia cùng chúng tôi trong việc xây dựng bộ khung agent hoàn hảo mà thế giới hiện đại cần: discord.gg/iiidev
iii là mã nguồn mở. Bắt đầu tại iii.dev/docs. Các worker bộ khung tại github.com/iii-hq/workers và công cụ tại github.com/iii-hq/iii.
— Mike Piccolo, Nhà sáng lập & Giám đốc điều hành @iiidevs
