Mental model ban đầu sai ở đâu?#

Khi nhìn một coding agent tìm được đúng đoạn code, mình chỉ thấy đầu vào và đầu ra:

"Tìm chỗ request context được attach vào middleware"
                  ↓
"Nó nằm ở src/http/middleware/requestContext.ts"

Phần bị che mất là rất nhiều bước ở giữa. Agent có thể thử tìm tên file, grep một khái niệm gần nghĩa, đọc vài kết quả, thấy một symbol mới, search theo symbol đó, rồi lần sang caller.

Execution path thật gần với flow này hơn:

flowchart TB
    accTitle: Luồng agentic search của ba coding harness
    accDescr: Model tạo truy vấn, gọi công cụ lexical của Pi, OpenCode hoặc Codex, đọc bằng chứng rồi lặp lại cho tới khi đủ thông tin để trả lời.

    Q["Câu hỏi của user"] --> M["Model chọn query và phạm vi"]
    M --> H{"Harness đang dùng"}
    H --> P["Pi: rg, fd, read"]
    H --> O["OpenCode: grep, glob, read"]
    H --> C["Codex: shell, rg, git, sed"]
    P --> E["Tool output / evidence"]
    O --> E
    C --> E
    E --> R["Model đọc, nối quan hệ, đổi query"]
    R -->|"Chưa đủ"| M
    R -->|"Đủ bằng chứng"| A["Final answer"]

rg không tự biết “retry lỗi tạm thời” tương đương với transientFailure. Model đoán mối liên hệ đó, search từ khóa mới và kiểm tra kết quả. Vì vậy, khi nói về “search algorithm” của coding agent, mình phải tách ít nhất hai lớp:

1. Search primitive: rg, fd, glob, fuzzy matcher, read file và các giới hạn output.
2. Agentic search policy: model chọn query nào, đọc file nào, có search song song không, khi nào reformulate và khi nào dừng.

Nếu trộn hai lớp này lại, mình rất dễ ghi công cho ripgrep trong khi thứ tạo ra khác biệt thật sự lại là cách model sử dụng ripgrep.

Pi: công cụ đơn giản, policy nằm gần như hoàn toàn ở model#

Pi là harness có triết lý khá thẳng. Search content của nó dựa trên rg; tìm file dựa trên fd; đọc bằng chứng bằng read.

Built-in grep gọi ripgrep với JSON output, line number, hidden files và ignore rules thông thường. Mặc định nó lấy tối đa 100 matches, giới hạn mỗi dòng và chặn tổng output ở khoảng 50 KiB. Built-in find dùng fd, trả path tương đối và mặc định tối đa 1.000 kết quả.

Có một nuance khá quan trọng: Pi có sẵn grep, find, ls, nhưng default agent session lại chỉ bật read, bash, edit, write. Nghĩa là trong flow mặc định, model thường tự viết lệnh shell như rg, find, git thay vì nhất thiết đi qua structured search tool.

Trong benchmark core, mình chủ động giới hạn Pi về read,grep,find,ls. Mục tiêu là đo search chứ không đo khả năng chỉnh sửa file, đồng thời giữ corpus không bị mutate.

OpenCode: structured search rõ nhất trong ba harness#

OpenCode đưa search primitives thành các tool có schema khá rõ:

• grep dùng ripgrep cho content search.
• glob dùng rg --files để tìm path.
• read lấy nội dung file, directory, image hoặc PDF và giới hạn text ở 2.000 dòng hay 50 KiB.

grep và glob đều cap khoảng 100 kết quả. grep có thể đi qua hidden files nếu ignore rules cho phép; glob thì không tự biến một typo thành filename gần đúng. Nếu model search req-contxt nhưng file tên requestContext.ts, glob không có phép màu semantic nào để sửa giúp.

Model phải thử pattern khác, search theo symbol hoặc chuyển sang một chiến thuật khác.

Codex: shell-first, để model tự compose chiến thuật#

Codex đi theo hướng shell-first rõ nhất.

Model instruction khuyến khích dùng rg cho content search và rg --files cho file search. Codex cũng package ripgrep trong các release. Tool exec_command cho phép model tự ghép nhiều primitive vào cùng một command:

rg -n "verifySignedSession" src \
  && sed -n '1,180p' src/auth/tokenVerifier.ts

Đây vừa là điểm mạnh vừa là thứ làm benchmark khó đọc hơn. Một tool event của Codex có thể chứa nhiều lần search/read, trong khi một event của Pi hay OpenCode thường gần với một atomic tool call hơn.

Vì vậy không thể nhìn “Codex dùng ít tool calls hơn” rồi kết luận ngay nó search hiệu quả hơn. Đơn vị đo không giống nhau.

Đặt ba harness cạnh nhau#

Điểm chung lớn nhất không phải ripgrep. Điểm chung là vòng lặp:

model đoán query → lexical search → đọc evidence → reformulate → search tiếp

Đó mới là “agentic search algorithm” đáng nghiên cứu.

Benchmark: cùng model, cùng corpus, không chấm bằng văn hay#

Đọc source cho mình biết harness có thể làm gì. Nhưng agent có thực sự tìm đúng evidence hay không thì phải chạy.

Mình dựng một lab với ba nguyên tắc:

1. Giữ model cố định: cả ba yêu cầu gpt-5.6-terra, reasoning medium, qua ChatGPT OAuth.
2. Pin runtime: Pi 0.84.1, OpenCode 1.18.16, Codex 0.147.0.
3. Không chấm final answer một mình: muốn được điểm, file/symbol/term phải xuất hiện trong câu trả lời và trong successful tool evidence.

Model parity gate chạy trước để chắc cả ba client chấp nhận explicit model/reasoning và không client nào tự fallback. Sau đó là:

• 24 smoke runs: 8 cases × 3 harnesses × 1 trial.
• 72 scored runs: 8 cases × 3 harnesses × 3 trials.

Tám cases gồm:

• exact literal search;
• typo-heavy filename search;
• ignore rules với .gitignore và .ignore;
• cross-file execution flow trong TypeScript;
• concept search khi câu hỏi và code dùng vocabulary khác nhau;
• root/nested instruction discovery;
• HTTP routing flow trong Go Chi;
• overflow regression trong Apache Commons Lang.

Corpus trải trên TypeScript fixture có ground truth, Go và Java. Mỗi run lưu manifest, raw normalized JSONL, tool evidence, final answer, latency, process exit và before/after corpus digest.

Kết quả 72 runs#

Nhìn bảng này, phản xạ đầu tiên có thể là tuyên bố Pi thắng. Nhưng với ba trials cho mỗi cell thì nói vậy hơi nhanh.

Đây là kết quả của một fixed benchmark với một model, một reasoning level, một bộ prompt và một cấu hình tool cụ thể. Chênh lệch nhỏ có thể đổi khi model snapshot, corpus hoặc tool profile thay đổi.

Có vài observation đáng tin hơn chuyện xếp hạng:

Những gì benchmark này chưa chứng minh#

Mình muốn đặt caveat ngay cạnh kết quả, vì bỏ nó ra thì bảng điểm rất dễ bị dùng sai.

• Ba trials mỗi cell chưa đủ để tuyên bố sản phẩm nào “tốt nhất”.
• Tool event không phải đơn vị cost chung giữa ba harness.
• OpenCode và Codex chấp nhận explicit model selection nhưng không echo provider-effective model trong JSONL; server-side aliasing vẫn không quan sát độc lập được.
• Pi và Codex read-only mode không phải strict corpus-only sandbox. Lab dùng public corpus và canary, không dùng private code hay secret.
• Web search, MCP ranking, LSP, file picker và multi-agent fanout chưa nằm trong core score này.
• Benchmark đo grounded recall và execution order; nó chưa đo đầy đủ precision, độ dễ đọc hay chất lượng engineering judgment của final answer.

Vì vậy kết luận hợp lý không phải là “Pi thắng Codex 0.037 điểm”. Kết luận hợp lý là:

Trên cùng model và corpus, cả ba harness đều tìm code tốt bằng lexical primitives cộng với agentic query planning. Khác biệt lớn nằm ở tool interface, context policy và cách model compose vòng tìm kiếm.

Chốt lại Part 1#

Sau khi đọc source và chạy benchmark, mental model mình giữ lại là:

• Pi: primitive mỏng, rõ ràng; model gánh phần lớn search policy.
• OpenCode: structured agent tools rõ nhất; picker, LSP và child-agent là các lớp tách biệt.
• Codex: shell-first; model tự compose rg, git, sed và có thể gom nhiều thao tác vào một call.
• Cả ba: semantic relevance chủ yếu đến từ model đang lập kế hoạch và reformulate, không phải local vector index.

Ở Part 2, mình sẽ đi sâu hơn vào chính vòng lặp đó: model chọn query đầu tiên ra sao, lúc nào search song song có lợi, compaction làm mất evidence thế nào, và subagent fanout có thực sự tăng recall hay chỉ tăng token bill.

Nếu chỉ nhớ một câu từ Part 1 thì là câu này:

Đừng hỏi coding agent “dùng search engine gì” trước. Hãy hỏi model được phép nhìn thấy tool nào, output bị cắt ở đâu, context nào được nạp vào và evidence nào thật sự đi đến final answer.