Tuần trước tôi đọc về một AI thiết kế vắc-xin chống lại các loại coronavirus mà chúng ta chưa từng gặp phải (ScienceDaily). Cambridge đã tiến hành thử nghiệm lâm sàng đầu tiên trên người, và 39 tình nguyện viên đã nhận kháng nguyên.
Thật điên rồ khi nghĩ rằng một thuật toán đã phân tích toàn bộ họ gen của một loại virus và tạo ra khả năng bảo vệ chống lại các chủng vẫn đang lưu hành ở động vật và chờ cơ hội lây sang người. Nhưng khi tôi yêu cầu nó lấy bản tóm tắt mới nhất từ một danh sách tài liệu, nó có thể mất gần hai phút để mở sai tệp trong kho dữ liệu của tôi chỉ để đưa ra một bản tóm tắt từ ba tháng trước.
Và tôi biết Cambridge sử dụng một AI được huấn luyện tùy chỉnh, nhưng điều tôi muốn cho bạn thấy là khoảng cách giữa những gì AI có thể làm và những gì thiết lập cho phép nó làm mới là yếu tố quyết định sự thành bại trong quy trình làm việc và năng suất của bạn.
Tôi chưa bao giờ cố tình xây dựng cấu trúc hỗ trợ, cho đến gần đây. Nó tự động tích tụ xung quanh tác nhân một cách tình cờ, hết thư mục này đến thư mục khác, cho đến khi tác nhân lạc lối trong mớ hỗn độn mà chính tôi tạo ra.
Vì vậy, tôi đã dành một ngày để đo thời gian cho mọi lần thất bại, và một mô hình đã hiện ra. Trong số này, tôi sẽ chỉ cho bạn lý do tại sao tác nhân của bạn cứ vấp ngã với những thứ dễ dàng trong khi thế giới gọi nó là thiên tài, và cách khắc phục để đưa nó trở lại làm việc cho bạn.
Trong bài viết này:
- Cấu trúc thư mục đã làm tác nhân của tôi thất bại vì các thư mục được sắp xếp theo cách tôi nghĩ, không phải theo cách tác nhân điều hướng
- Một tệp index ở thư mục gốc của mọi thư mục chính đã biến các tìm kiếm chậm thành các lần đọc ba mươi giây
- Cấu trúc hỗ trợ vô hình xung quanh tác nhân quan trọng hơn khả năng của chính tác nhân, và đây là cách xây dựng nó
- Một bài kiểm tra chẩn đoán bạn có thể chạy trong năm phút để xem liệu cấu trúc thư mục có phải là vấn đề thực sự hay không
Cấu trúc mà tác nhân của bạn không thể thấy
Tôi đã sắp xếp kho dữ liệu của mình theo cách mà hầu hết mọi người làm. Bài báo, nghiên cứu, tài sản, tài liệu chiến lược, mỗi loại có một thư mục riêng. Cấu trúc đó có vẻ gọn gàng vì tôi suy nghĩ theo loại nội dung. Các thư mục tương ứng với các danh mục của tôi và tôi không bao giờ phải nghĩ xem nên tìm ở đâu. Bản nháp là bài báo, ghi chú là nghiên cứu, hệ thống phân loại hoạt động tự động.
Nhưng một tác nhân không suy nghĩ theo danh mục. Khi tôi yêu cầu Hermes lên kế hoạch ra mắt sản phẩm, nhiệm vụ đó sẽ lấy dữ liệu từ ghi chú chiến lược, hướng dẫn thương hiệu và các lần ra mắt trước đó nằm rải rác trong các thư mục khác nhau.
Những phần ngữ cảnh đó nằm ở những nơi khác nhau trong cấu trúc phân loại nội dung của tôi. Tác nhân của tôi phải tìm kiếm khắp nơi mỗi lần, mà không biết bản nháp nào là hiện tại so với bản nào đã lưu trữ, hoặc ghi chú nghiên cứu nào là từ tháng này so với sáu tháng trước.
Tổ chức theo loại nội dung hoạt động hoàn hảo cho con người. Bạn đã dành cả cuộc đời để phân loại mọi thứ theo danh mục, và bộ não của bạn tự động thực hiện việc tham chiếu chéo. Thật tự nhiên khi kỳ vọng AI cũng hoạt động tương tự, nhưng thực tế, một tác nhân phải thực hiện việc tham chiếu chéo đó một cách thủ công, và đó là lúc cấu trúc bị phá vỡ.
Cấu trúc xung quanh tác nhân của bạn đóng vai trò quan trọng hơn khả năng của chính tác nhân.
Khi tôi nhìn thấy mô hình, nguyên nhân đã rõ ràng: Tôi đã xây dựng kho dữ liệu của mình cho một bộ não con người có thể nhớ mọi thứ ở đâu, sau đó giao nó cho một tác nhân phải tìm kiếm từ đầu mỗi lần, và điều đó đã phơi bày vấn đề thực sự bên dưới mớ hỗn độn thư mục.
Một người tìm kiếm cần một bản đồ, bởi vì nếu không có nó, tác nhân sẽ đi trong bóng tối và coi mọi tệp tin như thể nó có thể là câu trả lời.
Khả năng bị lãng phí vào việc gì
Hermes liên tục mở một loạt tệp trước khi tìm đúng tệp, hoặc lấy một phiên bản đã lưu trữ trong khi tệp hiện tại ở nơi khác. Tệ hơn, nó sẽ hỏi nên dùng tệp nào khi câu trả lời lẽ ra phải rõ ràng từ ngữ cảnh. Điều này xảy ra với mọi mô hình tôi sử dụng, bao gồm Opus, GPT 5.5, Qwen và GLM.
Mô hình cứ lặp đi lặp lại, và tôi mắc kẹt khi xem cùng những tìm kiếm chậm chạp diễn ra hết nhiệm vụ này đến nhiệm vụ khác.
Mặc dù tác nhân của tôi đủ khả năng để tìm mọi thứ, nhưng cấu trúc thư mục đã trở thành nút thắt cổ chai chính trước khi nó có thể bắt đầu công việc thực sự.
Tôi đã chạm đến điểm giới hạn vào ngày tôi đo thời gian cho những lần thất bại. Tôi theo dõi xem Hermes đã mở bao nhiêu tệp trước khi đến được tệp đúng, và mất bao lâu để đến đó. Năm tác vụ phổ biến trông như thế này trước khi tôi thay đổi bất cứ điều gì.
Trước khi tôi thay đổi bất cứ điều gì:
- Tìm bản tóm tắt bài báo hiện tại: 7 tệp đã mở, 2:00 để đến tệp đúng;
- Tìm định nghĩa màu thương hiệu: 5 tệp đã mở, mất 1:12;
- Tra cứu hàng đợi bài báo để lập kế hoạch: 4 tệp đã mở, mất 0:48;
- Tìm các bài báo trước đây về cùng chủ đề: 6 tệp đã mở, mất 1:36;
- Lấy chiến lược quảng bá cho một lần ra mắt: 3 tệp đã mở, mất 0:34.
Một thử nghiệm sơ bộ, vì vậy hãy coi các con số chính xác chỉ mang tính định hướng.
Mọi tác vụ đều đi qua nhiều thư mục. Hầu hết chúng đều mở các phiên bản đã lưu trữ trước khi tìm thấy các phiên bản đang hoạt động. Tác nhân của tôi đang đốt cháy khả năng vào việc điều hướng thay vì làm công việc của nó. Một kế hoạch ra mắt cần ba tệp nằm trong ba thư mục khác nhau, và tôi đã thấy nó thực hiện ba lần thử sai trước khi tìm đúng.
Một tác nhân viết bài báo, viết mã và lập kế hoạch không nên dành phần lớn thời gian để tìm kiếm mọi thứ.
Cái lồng nhỏ nhất có hiệu quả
Một thư mục cho một phạm vi, được đánh số để sắp xếp thứ tự, với một INDEX.md ở thư mục gốc để ánh xạ mọi thứ. Đó là toàn bộ cách khắc phục, và chi tiết nằm trong ba quy tắc hoạt động cùng nhau.
INDEX.md ở thư mục gốc của mỗi thư mục chính là một bản đồ. Nó liệt kê mọi thư mục con và tệp chuẩn, cùng với nơi tác nhân của tôi nên bắt đầu. Tác nhân của tôi đọc cái này trước và biết bên trong có gì trước khi chạm vào bất cứ thứ gì khác. Hãy nghĩ về nó như một cổng phê duyệt mềm, nơi tác nhân không được phép bắt đầu công việc cho đến khi nó biết mình đang làm việc với cái gì.
Cấu trúc thư mục thương hiệu của tôi trông như thế này sau khi tổ chức lại.
105.Brand/2├── INDEX.md3├── 01.Brand System/4├── 02.Editorial Strategy/5├── 03.Promotion/6├── 04.Public Deliverables/7├── 05.Operating Plan/8└── 06.Archived/
Cấu trúc này tổ chức theo phạm vi thay vì loại nội dung. Mỗi phạm vi có thư mục riêng, vì vậy công việc thương hiệu ở cùng với công việc thương hiệu và chiến lược ở cùng với chiến lược. Tác nhân của tôi không vượt ranh giới để tìm kiếm thứ không thuộc về nơi đó.
Các số trên thư mục làm cho thứ tự đọc trở nên rõ ràng thay vì dựa vào sắp xếp theo bảng chữ cái. 01. Brand System được đọc trước 02. Editorial Strategy. Tác nhân của tôi không phải đoán. Các số bên trong thư mục cũng làm điều tương tự cho các tệp, vì vậy tác nhân của tôi biết 01. Articles là điểm bắt đầu trước 02. Previous Articles.
Tôi đặt tên thư mục với số đầu vì nó cũng dễ nhớ hơn cho tôi.
Đây là cách toàn bộ stack Hermes 30$ của tôi dễ dàng di chuyển qua hàng tá thư mục mà tác nhân của tôi không bao giờ bị lạc.
Những thứ đã lưu trữ nằm trong 06.Archived, nơi các bản tóm tắt cũ và kế hoạch đã nghỉ hưu chờ đợi. Tác nhân của tôi biết không tìm ở đó trừ khi tôi yêu cầu cụ thể về ngữ cảnh lịch sử. Sự tách biệt đó là thứ giữ cho các thư mục đang hoạt động sạch sẽ và các tìm kiếm nhanh chóng.
Khi tác nhân của tôi được yêu cầu không vượt qua ranh giới đó theo mặc định, mọi tác vụ bên trong các thư mục đang hoạt động đều chạy nhanh hơn.
INDEX.md của tôi trông như thế này.
1# Chỉ mục Thương hiệu23Thư mục này chứa hệ thống thương hiệu hiện tại.45## Bản đồ Thư mục67| Thư mục | Mục đích | Cập nhật |8|---|---:|---:|9| `01.Brand System/` | Nhận diện thương hiệu, phạm vi chủ đề, tông giọng | 2026-06-11 |10| `02.Editorial Strategy/` | Định hướng bài báo, quy tắc tiêu đề, hàng đợi | 2026-06-11 |11| `03.Promotion/` | Chiến lược ra mắt, phân phối, công cụ | 2026-06-11 |1213## Các Tệp Chuẩn1415| Tệp | Mục đích |16|---|---|17| `01.Brand System/01. Brand System.md` | Nhận diện thương hiệu, màu sắc, kiểu chữ |18| `02.Editorial Strategy/01. Articles.md` | Hàng đợi bài báo, quy tắc tiêu đề |1920## Nơi Bắt Đầu2122- Bắt đầu với `01.Brand System/04. Direction.md` để biết sứ mệnh23- Sử dụng `02.Editorial Strategy/01. Articles.md` để chọn bài báo
INDEX.md đã trải qua ba phiên bản. Phiên bản đầu tiên của tôi liệt kê mọi tệp tin bên trong thư mục thương hiệu và dài tới bốn mươi dòng. Về mặt kỹ thuật, nó hoàn chỉnh nhưng tác nhân của tôi phải phân tích nó mỗi lần và độ dài đó tự nó đã là một chi phí. Phiên bản thứ hai của tôi quá ngắn, khoảng mười lăm dòng, và tác nhân của tôi vẫn đặt những câu hỏi mà tôi chưa trả lời. Phiên bản thứ ba này chỉ liệt kê các thư mục con và tệp chuẩn, với một phần "Nơi Bắt Đầu" ngắn cho tác nhân của tôi biết điểm bắt đầu của nó.
Khi tôi yêu cầu tác nhân của mình lấy chiến lược quảng bá cho một lần ra mắt, nó đọc 05.Brand/INDEX.md, mở 03.Promotion/01. Promotion Strategy.md, và bắt đầu làm việc. Thời gian sau khi tổ chức lại trông như thế này.
Sau khi tổ chức lại:
- Tìm bản tóm tắt bài báo hiện tại: 1 tệp đã mở, 0:10
- Tìm định nghĩa màu thương hiệu: 3 tệp đã mở, 0:22
- Tra cứu hàng đợi bài báo để lập kế hoạch: 1 tệp đã mở, 0:10
- Tìm các bài báo trước đây về cùng chủ đề: 2 tệp đã mở, 0:18
- Lấy chiến lược quảng bá cho một lần ra mắt: 1 tệp đã mở, 0:12
Tác vụ chậm nhất giảm từ 2 phút xuống còn 26 giây, và các lần chạy nhanh nhất chỉ mất khoảng 10 giây. Tác nhân của tôi mở INDEX.md, đi theo điểm bắt đầu cần thiết, và bắt đầu làm việc mà không lang thang. Không có khả năng nào thay đổi ở phía tác nhân của tôi. Cấu trúc thư mục đã ngừng lãng phí hầu hết nó trước khi tác vụ thậm chí bắt đầu.
Cấu trúc thư mục là một cái lồng tôi xây dựng để hạn chế cách tác nhân của tôi di chuyển mà không hạn chế những gì tác nhân của tôi có thể làm. Bên trong cái lồng, tác nhân của tôi chạy tự do. Nếu không có nó, Hermes có xu hướng đi lang thang và tôi phải lãng phí thời gian để chỉ nó vào đúng tệp.
Việc chuyển sang Hermes cho phép tôi xây dựng loại hệ thống đó trên các tệp, nhà cung cấp và bộ nhớ cùng một lúc, và mô hình INDEX.md là phần nhỏ nhất tạo ra sự khác biệt lớn nhất hàng ngày.
Mọi cái lồng đều có khóa
Sai lầm đầu tiên của tôi là thêm INDEX.md vào mọi thư mục con. Quá nhiều bản đồ có nghĩa là tác nhân của tôi dành thời gian đọc các chỉ mục thay vì làm việc. Tôi chỉ giữ INDEX.md ở thư mục gốc của các thư mục chính như Brand và Editorial Strategy, nơi có đủ thư mục con để cần một bản đồ. Bên trong một thư mục con nhỏ với bốn hoặc năm tệp, Hermes điều hướng trực tiếp mà không cần bất kỳ bản đồ nào.
Hãy nhớ rằng việc đánh số trở nên tẻ nhạt khi bạn thêm các thư mục mới. Tôi phải quyết định vị trí của một thư mục mới trong chuỗi, và đôi khi tôi thêm nó vào cuối thay vì đánh số lại mọi thứ. Điều đó không sao cả. Các con số không cần phải hoàn hảo miễn là chúng có tính định hướng. Các thư mục được sắp xếp hoàn hảo không phải là mục tiêu, và coi chúng như vậy sẽ biến một giải pháp thực tế thành một dự án làm đẹp.
Một sai lầm lớn hơn là xây dựng cấu trúc trước khi tác nhân của bạn có dấu hiệu nhầm lẫn. Hầu hết mọi người thiết kế quá mức thiết lập tác nhân của họ vì họ nghĩ nó cần cơ sở hạ tầng phù hợp.
Quy tắc hiện tại của tôi tuân theo cùng một nguyên tắc đằng sau việc chọn MCPs so với CLIs so với công cụ của riêng bạn. Nó sử dụng giao diện nhỏ nhất để hoàn thành công việc. Chỉ thêm cấu trúc khi tác nhân của bạn bị lạc, và chỉ thêm đủ cấu trúc để khắc phục vấn đề cụ thể đó.
Một thất bại khác tôi gặp phải là lồng cấu trúc bên trong cấu trúc. Tôi đã thêm các thư mục con bên trong các thư mục con để phân loại mọi thứ một cách hoàn hảo, điều này đã biến một hệ thống phân cấp hai cấp thành một hệ thống năm cấp. Sau đó, tác nhân của tôi phải đọc nhiều tệp INDEX và phân tích nhiều chuỗi số để đến được một tệp duy nhất. Tôi đã thu gọn các cấp bổ sung đó trở lại thành các thư mục con phẳng và việc điều hướng lại nhanh chóng.
Độ sâu là kẻ thù của việc tra cứu tệp nhanh, và hầu hết các lần tổ chức lại đều thêm độ sâu vì nghĩ đó là sự chính xác.
Đo lường trước khi tổ chức lại
Trước khi chạm vào bất kỳ thư mục nào, hãy chạy thử nghiệm này trên ba tác vụ thực tế mà tác nhân của bạn xử lý thường xuyên nhất. Đo thời gian cho mỗi tác vụ, và ghi lại số lượng tệp nó mở trước khi tìm đúng tệp. Theo dõi tần suất nó chọn sai tệp hoặc dừng lại để hỏi bạn nên dùng tệp nào.
Bất kỳ tác vụ nào khiến tác nhân của bạn mất hơn ba mươi giây hoặc mở ba tệp sai trở lên đều chỉ ra một thư mục đằng sau tác vụ đó bị hỏng.
Chọn một thất bại xảy ra thường xuyên nhất. Mở thư mục đó và viết một INDEX.md liệt kê mọi thư mục con và tệp quan trọng, cùng với nơi tác nhân của bạn nên bắt đầu. Lưu nó. Chạy lại tác vụ tương tự.
Nếu tác nhân của bạn tìm đúng tệp trong vòng dưới ba mươi giây, cách khắc phục đã hiệu quả và bây giờ bạn đã biết mô hình. Áp dụng nó cho thư mục bị hỏng tiếp theo. Nếu nó vẫn thất bại, vấn đề có khả năng là đánh số hoặc quy tắc một-phạm-vi-mỗi-thư-mục, và đó là hai điều tiếp theo cần khắc phục.
Bắt đầu với một thư mục lãng phí nhiều thời gian nhất, sửa nó, và chuyển sang thư mục tiếp theo chỉ khi bạn đã sẵn sàng.
Nơi các thanh vẫn còn cong
Nội dung đã lưu trữ đôi khi vẫn được tham chiếu khi tôi cần một bản tóm tắt cũ để lấy ngữ cảnh. Tác nhân của tôi phải biết tìm trong 06.Archived thay vì các thư mục đang hoạt động, và tôi đề cập điều này trong INDEX.md để nó biết nơi tài liệu lịch sử tồn tại. Nếu không có ghi chú đó, tác nhân của tôi cho rằng nội dung đã lưu trữ không tồn tại.
Ngoài ra, Obsidian Sync đôi khi tạo ra các vấn đề khi nó không đồng bộ kịp trên các thiết bị. Nếu tôi cập nhật một tệp trên máy tính xách tay của mình nhưng phiên bản cũ vẫn nằm trên VPS của tôi, Hermes tải phiên bản trên VPS và coi nó như nguồn sự thật hiện tại. Đó là vấn đề đồng bộ hơn là vấn đề cấu trúc thư mục, nhưng nó xuất hiện bên trong hệ thống thư mục vì tác nhân chỉ thấy các tệp trước mặt nó.
Việc đánh số bị phá vỡ khi bạn có quá nhiều thư mục đến mức chuỗi số trở nên vô nghĩa. Quá mười hoặc mười hai mục được đánh số ở một cấp, các con số bắt đầu trở nên tùy tiện.
Tôi cố gắng giữ các danh mục chính dưới ngưỡng đó và lồng cấu trúc sâu hơn bên trong thay vì mở rộng cấp trên cùng.
Đổi tên là một nguồn ma sát khác. Khi tôi tổ chức lại, đôi khi tôi đổi tên các thư mục để phù hợp hơn với mục đích của chúng, và bất kỳ tham chiếu INDEX.md nào đến tên cũ đều bị hỏng cho đến khi tôi cập nhật nó. Bây giờ tôi cố gắng đặt tên thư mục một lần và để yên, bởi vì một cái tên hơi khó xử còn rẻ hơn một tham chiếu bị hỏng.
Cấu trúc này hoạt động tốt nhất cho các quy trình làm việc nặng về nội dung và nặng về lập kế hoạch. Các thiết lập thuần mã hoặc nặng về dữ liệu có thể cần các nguyên tắc tổ chức hoàn toàn khác, và mô hình INDEX.md không giải quyết mọi vấn đề điều hướng.
Mọi thứ tôi đã viết trong bài viết này đều bắt nguồn từ một bản năng. Làm chủ lớp quan trọng. Tôi đã xây dựng stack của mình để không có công ty nào kiểm soát các công cụ của tôi. Tôi đã xây dựng kho dữ liệu của mình để không có mớ hỗn độn nào kiểm soát tác nhân của tôi. Cùng một nguyên tắc từ nhà cung cấp đến thư mục đến bất cứ điều gì tiếp theo.
Khả năng trở nên rẻ khi cấu trúc hỗ trợ xung quanh nó bị hỏng. Hãy xây dựng cấu trúc hỗ trợ, và khả năng sẽ tự lo liệu. Một tệp index và vài con số trước tên thư mục của bạn là sự khác biệt giữa một tác nhân lang thang và một tác nhân làm việc.
Nếu bài viết này hữu ích - hãy theo dõi @wandermist để biết thêm nội dung như thế này!
