v0.14.0 xuất xưởng một xếp chồng công việc performance mà, gộp lại, làm cho Hermes Agent có cảm giác như một chương trình khác. Ba tiêu đề từ release notes:
- •~19 giây cắt khỏi cold start. Trải khắp import graph, các check doctor, lần tra cứu model catalog, welcome banner.
- •
browser_consolenhanh hơn 180×. Một kết nối CDP thường trực thay vì mở session DevTools mới mỗi call. - •Prompt cache Claude xuyên session, một tiếng.
/newkhông làm mất prefix cache ấm của bạn nữa.
Không cái nào trong số này là "viết lại từ đầu". Mỗi cái là một chuỗi PR nhỏ, định vị được, nhắm vào các hot path cụ thể. Bài này là phần mổ xẻ PR-theo-PR — cái gì chậm, cái gì đổi, và bài học cho bất kỳ ai viết agent.
Điểm khởi đầu
Nếu bạn chạy hermes đầu tháng 5/2026, đường cold start trông thế này:
- 1.Trình thông dịch Python khởi động (~100 ms)
- 2.
import hermeskích hoạt phần còn lại của import graph (~5–10 s) - 3.Plugin discovery của
hermesquét các plugin đã cài (~2–3 s) - 4.
hermes doctorchạy các probe kết nối API tuần tự (~3–5 s) - 5.Skills index load, thường lấy lại từ network (~2–4 s)
- 6.Welcome banner render (~1 s)
- 7.Prompt xuất hiện
Đó là 15–25 giây trước khi bạn có thể gõ. Đủ lâu để phá flow. Đợt sóng performance v0.14.0 đánh từng bước.
Đợt sóng cold start (10+ PR)
Cache skill + lazy import adapter (#22138)
Chiến thắng đơn lẻ lớn nhất. Hai thay đổi song song:
- 1.Skills index được cache vào đĩa. Hành vi cũ: mỗi lần gọi
hermesđọc lại thư mục skill và chạy index nhẹ. Hành vi mới: index sống trong một file cache; chỉ dựng lại khi thư mục đổi (check mtime). - 2.SDK adapter nặng chuyển sang lazy. Trước: import
hermeskích hoạt import SDK Feishu, SDK WhatsApp, mọi provider voice/TTS, mọi SDK image-gen. Giờ: từng cái hoãn lại đến lần dùng đầu. Nếu bạn không bao giờ dùng Feishu, SDK Feishu không bao giờ load.
Cả hai thay đổi nằm trong #22138 và tỉa được ~5–8 giây. Mẫu lazy-import là người hùng không được ca tụng — nó được áp dụng cơ giới khắp codebase nhưng không hiện ra như một PR kịch tính duy nhất.
Bỏ qua plugin discovery háu đói trên các subcommand đã biết (#22120)
Nếu bạn chạy hermes config set X Y, bạn không cần plugin discovery. Tương tự cho hermes tools, hermes model, hermes doctor. Dispatcher giờ làm tắt mạch plugin discovery khi lệnh là built-in đã biết. ~2 giây tiết kiệm trên phần lớn các lần gọi CLI.
models.dev cache-first lookup (#22808)
Hermes đập vào models.dev để có model catalog chính thức. Trước v0.14.0, mỗi lần khởi động hermes thực hiện cuộc gọi HTTP. Giờ: đọc từ cache đĩa trước; chỉ refetch khi cũ (>24 h). Cache hit là ~5 ms thay vì ~200–500 ms (network roundtrip).
Probe kết nối API song song trong hermes doctor (#22766)
hermes doctor kiểm "tôi có với tới Nous Portal, OpenRouter, Anthropic, OpenAI được không" theo tuần tự. Giờ: asyncio.gather chúng, bỏ probing IMDS (instance metadata service) đã từng timeout trên các máy không-cloud. ~3–5 giây cắt khỏi doctor trong trường hợp điển hình.
chat -q bỏ qua welcome banner (#22904)
Nếu bạn ở chế độ truy vấn đơn (hermes chat -q "what's the time"), welcome banner là nhiễu. v0.14.0 bỏ qua render. ~1 giây trả về cho các trường hợp dùng script / tự động hóa.
Hoãn import xuyên graph
Một cái đuôi dài các PR, mỗi cái hoãn một import nặng:
- •
google-cloudtrong adaptergoogle_chat— chỉ load khi google chat được dùng lần đầu (#22681) - •
QQAdapter,YuanbaoAdapter— hoãn ở cấp module qua PEP 562 (#22790) - •
httpxtrong adapter teams — chỉ vào lần gọi webhook đầu tiên (#22831) - •
fal_client— chỉ vào lần sinh ảnh đầu tiên (#22859)
Mỗi PR nhỏ. Gộp lại là thêm 2–4 giây.
Cache auth Nous + load .env (#25341)
Màn All-Platforms của hermes tools từng chạy các probe auth theo từng nền tảng đồng bộ. Cái đó tụt từ 14 giây xuống dưới 1,5 giây khi cache hạ cánh. Màn vẫn hoạt động y vậy; chỉ là không đốt 14 giây thời gian mạng mỗi lần gọi.
Kết quả ròng
Cộng các thắng lợi và bạn có 19 giây tiêu đề. Không cái nào đơn lẻ kịch tính; gộp lại, chương trình cảm giác phản hồi nhanh.
Câu chuyện 180× của browser_console (#23226)
Tool browser trong Hermes dùng Chrome DevTools Protocol (CDP) để lái một Chrome headless. Trước v0.14.0, mỗi lần đánh giá browser_console làm thế này:
- 1.Mở một CDP WebSocket mới tới Chrome
- 2.Chờ handshake (~1–2 s)
- 3.Gửi JavaScript để đánh giá
- 4.Đọc kết quả
- 5.Đóng WebSocket
Cho một chuỗi đánh giá — ví dụ agent kiểm trang từng bước — đây là ~1,5 s mỗi đánh giá. Một workflow "nhìn trang này và kể cho tôi" điển hình chậm đau đớn.
Thay đổi của v0.14.0: một WebSocket thường trực mỗi supervisor, chia sẻ qua mọi cuộc gọi tool browser. Handshake CDP xảy ra một lần mỗi session; các đánh giá sau bỏ qua hoàn toàn bước 1–2 và chỉ gửi payload.
Kết quả: latency mỗi call tụt từ ~1,5 s xuống ~8 ms. Tức là ~180×.
Bài học có tính tổng quát. Bất cứ chỗ nào agent của bạn thực hiện N cuộc gọi tool và mỗi cái mở một kết nối mới: với khối lượng nhịp chat, connection pooling thắng song song. Toàn bộ công việc nằm ở setup kết nối, không phải ở chính việc.
Prompt cache Claude xuyên session, một tiếng (#23828, #25434, #24778)
Prompt cache của Claude (tính năng API Anthropic) cho phép bạn đánh dấu một khối context là cache được. Các request tiếp theo trong TTL — trước đây là 5 phút — tái sử dụng prefix đã cache với chi phí và độ trễ thấp hơn nhiều.
Trước v0.14.0, Hermes dùng cái này trong session: system prompt + skill đang hoạt động được cache, hit trong cùng cuộc trò chuyện nhanh hơn và rẻ hơn. Nhưng khi bạn chạy /new, cache bị vô hiệu hóa, và cuộc trò chuyện tiếp theo bắt đầu lạnh.
Công việc của v0.14.0, trải qua ba PR, mở rộng TTL cache lên một giờ và làm khóa cache sống sót /new. Câu trả lời đầu tiên trong một session tươi hưởng lợi từ cache ấm từ session trước. Cho người nhiều cuộc trò chuyện ngắn một ngày, đây là chiến thắng có nghĩa về chi phí lẫn latency.
Cache cũng phủ nhánh memory review nền (#25434) — tiến trình định kỳ xem lại và củng cố file memory của bạn giờ đập vào cùng prompt cache thay vì trả giá đầy đủ mỗi lần lặp.
Một perf fix bổ trợ trong vùng này: khóa prompt cache dùng timestamp chỉ đến ngày nên cache không vỡ vì múi giờ. Logging round-trip gateway-DB ồn ào hoàn thiện mặt quan sát.
Các tool đã phơi các thắng lợi ra
Các tác giả tìm các hot path cụ thể này thế nào? Hai câu trả lời:
- •Profiling cold start trên cài đặt thực. Họ chạy
hermesdưới đồng hồ và theo dõi import nào lâu nhất. Rồi đi từng cái một. - •Báo cáo user "Hermes chậm". Việc màn All-Platforms của
hermes toolschậm là một bug report cụ thể; khi nó phơi ra, fix là trực tiếp.
Không có ma thuật. Các thắng lợi tìm được với python -X importtime, cProfile, và lắng nghe người ta phàn nàn.
Bài học cho bất kỳ ai viết agent
Nếu bạn đang dựng agent, đợt sóng performance của v0.14.0 khái quát hóa thành vài quy tắc:
- 1.Đừng import cái bạn không dùng. Lazy-import mỗi adapter và provider SDK. Import graph là cold start của bạn.
- 2.Cache mọi thứ ổn định. Skills index, model catalog, auth token. Refetch chỉ khi biết là cũ.
- 3.Pool kết nối. Nếu bạn gọi một API hay một CDP server hơn một lần mỗi session, giữ kết nối.
- 4.Chạy các probe độc lập song song. Check doctor, healthcheck, bất cứ thứ gì mà thứ tự không quan trọng.
- 5.Đừng render UI bạn không cần. Welcome banner, output trang trí — bỏ qua trong các đường không tương tác.
Không cái nào mới. Đây là sách hướng dẫn performance tiêu chuẩn cho mọi CLI. Cái thú vị về v0.14.0 là họ áp dụng cả cuốn sách trong một cửa sổ phát hành và kết quả cảm nhận được ngay khi người dùng cập nhật.
Nếu Hermes của bạn cảm thấy giòn vỡ đầu tháng 5, v0.14.0 là bản phát hành mà đường lạnh biến mất.