Agents Building Agents

1. Dùng AI để build AI

Alfonso mở đầu bằng chủ đề của talk: agent building agent, tức là cách nhóm của anh tận dụng coding assistant và spec-driven development (SDD) để build những AI agent đáng tin cậy và an toàn. Dòng phụ trên slide mở đầu nói đúng điều đó: dùng coding agent và SDD để build AI agent reliable.

Slide tiêu đề Agents building Agents của Nearform — Slide tiêu đề: "Agents building Agents", với dòng phụ "Using Coding agents and SDD to build reliable AI agents".

Vài dòng về bản thân anh. Alfonso là tech lead tại Nearform, một công ty dịch vụ. Hiện anh làm trong một số dự án AI agentic của công ty, hỗ trợ nhiều nhóm áp dụng AI-native engineering (AINE), và là tác giả cuốn sách của O'Reilly "Learning AI-Native Software Engineering".

Slide About me của Alfonso Graziano — "About me": Alfonso Graziano, AI Tech Lead @ Nearform. Ba gạch đầu dòng: build AI agent, hỗ trợ các nhóm áp dụng AINE, và tác giả cuốn "Learning AI-Native Software Engineering".

Điều nhóm anh thấy trong ngành lúc này là ai cũng muốn có AI agent: cho workflow automation, cho search, cho mọi use case bạn có thể nghĩ ra. Nhưng AI agent đi kèm một cái giá đôi khi rất cao. Chúng hallucinate. Chúng mang tới cả một tập vấn đề hoàn toàn mới. Và tất nhiên, chúng non-deterministic.

Meme Family Guy: hàng dài người xếp trước cửa AI AGENT, cửa AUTOMATION vắng tanh — "Everyone wants AI Agents": trong meme, cửa "AUTOMATION" ghi reliability, ROI, scalability thì không ai vào, còn cửa "AI AGENT" ghi hallucinations, cost, hype thì có cả một hàng dài xếp hàng.

Hôm nay, anh sẽ cho thấy nhóm anh build và cải thiện AI agent theo cách lặp đi lặp lại như thế nào. Làm bằng cách nào? Như bạn có thể đoán: AI rất mạnh và rất giỏi build mọi loại phần mềm, mà AI agent cũng chỉ là một loại phần mềm. Vậy nên nhóm dùng AI để build AI.

Meme hai Spider-Man chỉ tay vào nhau, cả hai đều ghi AI — "How do we do that?": meme hai Spider-Man chỉ vào nhau, cả hai đều mang nhãn "AI". AI build AI.

Như anh vừa nói, có rất nhiều vấn đề, rất nhiều lớp vấn đề khác nhau khi build AI agent: non-determinism là một, rồi latency, cost, hallucination, và còn nhiều thứ nữa. Talk này cho thấy cách giải chúng, ít nhất là một phần, bằng cách tận dụng agent và quy trình lặp lại được mà nhóm đã phát triển qua thời gian trên các dự án của mình.

Slide The Problems with Building AI Agents — "The Problems with Building AI Agents ...and how to solve them partially, with other agents!": các vấn đề khi build AI agent, và cách giải một phần bằng chính những agent khác.

2. Agent là gì, nhìn từ first principles

Ôn lại thật nhanh: có thể nói một AI agent về cơ bản chỉ là một LLM, đóng vai bộ não của agent. LLM đó được nối với một loạt tool, có quyền truy cập một lượng context, và sống trong một agentic loop. Đó là cốt lõi.

Sơ đồ AI Agents: a refresher với Memory, Tools, Planning, Action — "AI Agents: a refresher": ở giữa là Agent. Phía trên là Memory, chia thành short-term memory và long-term memory. Bên trái là Tools: Calendar(), Calculator(), CodeInterpreter(), Search() và nhiều hơn nữa. Bên phải là Planning, với reflection, self-critics, chain of thoughts và subgoal decomposition. Phía dưới là Action.

Tất nhiên AI agent còn nhiều thứ hơn thế. Có cả mảng observability: làm sao đảm bảo agent đang làm đúng việc cần làm. Có cả mảng eval, sẽ bàn ngay sau đây. Nhưng nếu chỉ đi từ first principles, có thể nói agent là một LLM nằm trong một agentic loop, được nối với tool và có thể retrieve context. Chỉ vậy thôi.

3. Hai lớp vấn đề và Golden dataset

Talk phân tích hai lớp vấn đề. Lớp thứ nhất là kết quả kém trên eval (sẽ giải thích eval là gì ngay đây). Lớp thứ hai là kết quả kém trên live data. Đôi khi live data cũng giống những gì có trong eval, nhưng dữ liệu đến từ người dùng thật, với kỳ vọng thật vào hệ thống, có thể rộng hơn rất nhiều và đôi khi lộn xộn hơn rất nhiều.

Bắt đầu với failure mode đầu tiên: kết quả kém trên eval. Trước khi phân tích nó, Alfonso giới thiệu khái niệm Golden dataset. Về cơ bản, Golden dataset là một file hoặc một tập file mà nhóm xây dựng cùng với các subject matter expert (SME) khi build AI agent. File này định nghĩa input mà hệ thống sẽ nhận, và output kỳ vọng mà hệ thống phải trả về.

Bảng tính Golden dataset với hai cột input và output — "Bad performances on evals: the golden dataset". Một bảng tính hai cột. Ví dụ: câu hỏi về bài toán dừng (halting problem) có output là IMPOSSIBLE; "How old is Elon Musk?" và câu tính tài sản Jeff Bezos chia cho dân số Mỹ đều ra PERSONAL_INFO_REJECTED; câu xin lời khuyên chia 50.000 USD giữa cổ phiếu và trái phiếu ra FINANCIAL_ADVICE_REJECTED; quy đổi 250 USD sang EUR theo tỷ giá hôm nay ra REQUIRES_LIVE_RATE; còn các câu gọi Open-Meteo hoặc jsonplaceholder để lấy nhiệt độ, đếm user, đếm todo hay đếm post thì output là một con số (4.6, 25.7, 10, 45.0, 10).

Trong trường hợp đơn giản, như ví dụ bên phải slide, output kỳ vọng có thể chỉ là "impossible", một con số hay một đoạn text; nó có thể là rất nhiều thứ. Trong các kịch bản thực tế, output kỳ vọng có thể là, chẳng hạn: tôi kỳ vọng hệ thống gọi tool này, hoặc gọi tool này với tham số này, hoặc gọi các tool theo đúng chuỗi này. Vì có khi tôi muốn agent retrieve trước rồi mới update. Cách định nghĩa output khác nhau ở mỗi agent, còn mục tiêu chung là có một cách đảm bảo agent đang chạy đúng. Đó là lý do nhóm build Golden dataset.

Bạn có thể xem Golden dataset như một test suite, nhưng trong một kịch bản non-deterministic.

4. Scorer và một agent Hello World

Khi build Golden dataset, nhóm cũng phải build một scorer, hoặc một tập scorer. Scorer chạy qua Golden dataset cùng với LLM, và cuối cùng trả về một con số cho biết độ chính xác hiện tại của hệ thống. Nhờ con số đó, bạn có baseline, có thể tìm regression, và có thể tiếp tục cải thiện hệ thống theo thời gian.

Giờ giả sử có một agent Hello World rất đơn giản. Ở đây Alfonso dùng Mastra. Anh đặt tên nó là math agent, nhưng thật ra trong Golden dataset có nhiều loại câu hỏi khác nhau. Agent này có một cái tên, vài dòng instruction, và tất nhiên một model. Như bạn thấy, nó chưa có tool nào, đúng là mức tối thiểu tuyệt đối.

Code TypeScript của mathAgent viết bằng Mastra — "We have an hello world agent": file `src/mastra/agents/math-agent.ts` tạo một `Agent` từ `@mastra/core/agent`, với id `math-agent`, name "Math Agent" và model `openai/gpt-5-nano`. Instruction được trích ở khung bên dưới.

You are a math assistant.
Solve math problems and provide the numerical answer.
Keep responses short.
Never format numbers with commas
- use plain digits only (e.g. 7951600784616 not 7,951,600,784,616).
Always include the final numerical result clearly.

Nhóm cũng build một evaluator ngây thơ. Nhớ lại Golden dataset: chỉ có input và output. Evaluator này chỉ kiểm xem output của LLM có chứa output ground truth đang kỳ vọng hay không.

Code regexMatchScorer dùng createScorer của Mastra — "A naive evaluator": `regexMatchScorer` tạo bằng `createScorer` của `@mastra/core/evals`, mô tả là "Checks if the agent output contains the ground truth value via regex". Nó lấy câu trả lời của assistant, escape giá trị ground truth, dựng regex có word boundary `\b` ở hai đầu, trả 1 nếu khớp và 0 nếu không, kèm lý do "Output contains / does not contain expected value".

5. Pass rate 18% và ba failure mode

Dĩ nhiên, khi chạy eval suite ở đây, kết quả rất tệ: pass rate chỉ 18%. Và con số đó có được chỉ vì nhiều câu hỏi đủ đơn giản, như phép cộng, phép nhân, đến mức chính LLM đã có kiến thức đó trong training data, không cần truy cập context bên ngoài hay tool đặc biệt nào. Tức là 18% câu hỏi có thể trả lời bằng weights của LLM, phần còn lại thì không. Vậy cần một cách để thật sự nâng pass rate này lên.

Terminal kết quả eval: Passed 11, Failed 49, Pass rate 18.3% — "Results are very poor". Một case ví dụ là tính hệ số tương quan Pearson giữa hai dãy số, làm tròn chính xác 6 chữ số thập phân: ground truth -0.852484, agent trả -0.852605, score 0. Tổng kết: 60 item, 11 pass, 49 fail, pass rate 18.3%. Latency trung bình 8.77 giây, P50 4.97 giây, P90 20.60 giây, tối đa 42.55 giây.

Có vài failure mode có thể lường trước:

Agent thiếu đúng tool. Giả sử tôi kỳ vọng agent có thể lướt web, fetch trang web. Nếu tôi không trao cho nó những tool đó, mọi eval cần đến chúng sẽ fail thảm hại.
System prompt sai. System prompt về cơ bản chứa mọi instruction, mọi hành vi nên có và không nên có của agent. Trong rất nhiều trường hợp, phần lớn việc tối ưu chỉ là chỉnh system prompt, cập nhật nó để agent có đủ thông tin cần cho domain của bạn.
Context retrieval. Có thể agent không biết tìm thông tin ở đâu. Thường thì context retrieval được implement dưới dạng tool: có thể là một lượt search trong hệ thống RAG, có thể là fetch trên web, đủ kiểu như vậy. Nên phải trao cho agent đủ tool để nó retrieve được mọi context cần thiết, và tất nhiên theo cách an toàn.

Slide Some failure modes: No tools, Wrong system prompt, No context retrieval — "Some failure modes". No tools: hệ thống không có những tool cần để vận hành đúng, hoặc tool sai và/hoặc có bug. Wrong system prompt: system prompt không khớp với các rule thể hiện trong Golden dataset. No context retrieval: agent không fetch được context liên quan để trả lời đúng.

6. Autoresearch của Karpathy: coding agent tự cải thiện model

Câu hỏi đặt ra: một AI agent có thể cải thiện một AI agent khác một cách tự động, hoặc bán tự động, được không?

Slide Can an AI agent improve another agent autonomously? — "Can an AI agent improve another agent autonomously?"

Andrej Karpathy, một trong những nhà khoa học AI nổi tiếng nhất hành tinh lúc này, đã làm ra một thứ tên là autoresearch. Về cơ bản, autoresearch là một vòng lặp cập nhật code, cập nhật hyperparameter, cập nhật chính code Python của các thuật toán machine learning. Và nó cho thấy một coding agent chỉnh code của một thuật toán deep learning thật sự có thể cải thiện kết quả.

Trang GitHub của repo karpathy/autoresearch — "Karpathy's Autoresearch shows that this is possible": repo `karpathy/autoresearch` trên GitHub, phần About ghi "AI agents running research on single-GPU nanochat training automatically". Các file chính gồm `prepare.py`, `program.md`, `train.py` và `analysis.ipynb`.

Biểu đồ tiếp theo là đường loss. Mỗi chấm trên biểu đồ là một thí nghiệm hệ thống chạy bằng cách thay đổi một số tham số. Baseline có một mức accuracy nhất định, và càng chạy nhiều thí nghiệm thì accuracy càng cải thiện, nên tất nhiên loss giảm dần.

Biểu đồ Autoresearch Progress: 83 Experiments, 15 Kept Improvements — "How autoresearch works": biểu đồ "Autoresearch Progress: 83 Experiments, 15 Kept Improvements". Trục dọc là validation BPB (thấp hơn là tốt hơn), trục ngang là số thứ tự thí nghiệm. Đường bậc thang màu xanh là running best: đi từ baseline khoảng 0.998 xuống dưới 0.98, mỗi bậc là một thay đổi được giữ lại; các chấm mờ là thí nghiệm bị loại.

7. AutoAgent: cùng ý tưởng, áp cho AI agent

Vậy làm điều tương tự với AI agent, chứ không chỉ với model machine learning, được không? Câu trả lời là có. Alfonso build một thứ gọi là AutoAgent, cùng ý tưởng nhưng áp cho AI agent. Đây là một vòng lặp có thể chạy eval rồi cập nhật code của hệ thống, thử system prompt mới, tạo tool mới, làm mọi thứ một cách tự động, rồi kiểm lại xem mọi thứ đã tốt lên hay chưa.

Và nó chạy khá tốt. Đây là vài iteration trên chính agent ngây thơ vừa thấy ở trên. Như ở góc dưới bên trái, accuracy baseline là 18%, và hệ thống đẩy lên được tới 83% trong khoảng 10 iteration.

Biểu đồ Accuracy Improvements In The Agent Performances từ 18.3% lên 83.3% — "And it actually works!": biểu đồ accuracy theo iteration: baseline 18.3%, rồi 31.7%, 58.3%, 60.0%, 61.7%, 58.3%, 65.0%, 70.0%, 71.7% và 83.3%. Bảng "Iteration Summary" bên cạnh liệt kê từng hypothesis (001, 002, ...) với quyết định CONTINUE. Bên phải: "+10% on a Production agent".

Tất nhiên đây là một trường hợp rất ngây thơ, vì xuất phát điểm là một agent không có tool, không có gì cả, nên hệ thống cải thiện nó tương đối dễ. Nhưng nhóm cũng đã cải thiện một số eval thêm 10% trên một agent production vốn đã được con người tối ưu. Tức là coding agent đã tìm ra những cách cải thiện agent mà con người không tìm ra, và nhóm được thêm 10% trên một số benchmark nội bộ.

8. Core idea: Claude Code build agent, agent trả feedback

Vậy nó hoạt động thế nào? Alfonso đã hé lộ vài điểm, giờ đi vào chi tiết.

Slide How does it works? — "How does it works?": phần đi vào cơ chế.

Ý tưởng cốt lõi: có một coding agent, ở đây là Claude Code, nhưng cách này chạy được với nhiều coding agent khác nhau. Coding agent build agent, tức là viết code của target agent. Rồi target agent trả feedback lại cho Claude Code, hay bất kỳ coding tool nào bạn đang dùng, dưới dạng eval: "Ở đây tôi bị regression", hoặc "Những eval này giờ đã pass".

Slide The core idea: Claude builds the agent, the agent gives feedback — "The core idea": biểu tượng Claude ở bên trái, một robot ở bên phải. Mũi tên đi sang: "Claude builds the agent"; mũi tên quay về: "The agent gives feedback".

Claude Code cũng có thể đọc trace, gồm thinking trace hay toàn bộ trace của target agent, để xem có chỗ nào hỏng hay chạy không như kỳ vọng. Nhờ vậy nó tự cải thiện được.

Và tất nhiên có human in the loop. Con người thường tham gia ở khâu dựng cấu trúc agent ban đầu, và cung cấp cho coding agent càng nhiều context càng tốt: nó được làm gì, những file nào liên quan, nó không được làm gì. Ví dụ: sửa Golden dataset hoặc sửa scorer chỉ để eval pass là một ý tồi (Alfonso bật cười khi nói câu này), nên phải ép, phải dặn agent đừng làm vậy. Là con người, chúng ta có thể lái coding agent một chút để nó tối ưu target agent.

Slide The human in the loop: con người nối với cả Claude và agent — "The human in the loop": vẫn là vòng Claude build agent và agent trả feedback, nhưng giờ có thêm một nhân vật hoạt hình (áo in "Open Source Is Art") với mũi tên hai chiều nối tới cả Claude lẫn agent.

9. Bước 1 và 2: optimization job và vòng lặp

Quy trình gồm vài bước. Bước đầu tiên là tạo một optimization job. Việc này rất dễ: mọi thứ là markdown, và giờ ai cũng mê markdown. Trong file đó bạn định nghĩa objective, target repository, metric, và thực sự là mọi thứ. Có thể đưa vào file này bao nhiêu context tùy ý cho coding agent, để nó thật sự chạy được và cải thiện target agent.

Bước 1: một file markdown mô tả optimization job. Đây là nơi con người đổ context vào: mục tiêu, repo đích, metric, và những điều cấm (như không được sửa Golden dataset hay scorer).

Bước thứ hai là chạy vòng lặp. Đầu tiên chạy eval một lần để sinh baseline data, để hiểu cái gì đang chạy, cái gì không. Hệ thống sinh report đầu tiên, rồi mới chạy vòng lặp tối ưu.

Trong ví dụ trên slide, lần thử đầu tiên bị regression. Hệ thống làm việc bằng cách tạo một hypothesis, mỗi lần nhắm một lớp vấn đề. Nó cập nhật agent và chạy lại eval, rồi xem kết quả là regression, cải thiện, hay chuyện gì khác. Từ đó agent quyết định roll back thay đổi hay đi tiếp. Lần đầu bị regression nên roll back. Rồi thấy cải thiện 5%, tuyệt. Từ đó tạo hypothesis mới, lần này cải thiện 0%, tiếc thật. Nhưng agent theo dõi mọi hypothesis đã thử, nên nó tạo tiếp một hypothesis khác, và lần này được cải thiện 12%, cứ thế tiếp tục. Tất nhiên, số iteration muốn chạy là do mình định nghĩa.

Sơ đồ Step 2 run the loop với các nhánh regression và improvement — "Step 2: run the loop". Run evals, rồi create baseline data. Từ đó tỏa ra các nhánh, mỗi nhánh là chuỗi "create an hypothesis, change the agent, run the evals": hai nhánh regression, một nhánh cải thiện 5%. Từ nhánh 5% lại thử tiếp: một nhánh 0%, một nhánh 12%. Từ nhánh 12% đi tiếp ra nhánh 2% và một nhánh 0% khác. Ghi chú: "we define how many iterations we want to run".

10. Baseline data và baseline report

Cách tạo baseline data đơn giản: chạy eval một lần và sinh ra một tài liệu. Việc này cực kỳ hữu ích vì nó cho coding agent thông tin về trạng thái hiện tại của hệ thống.

Code hàm getBaselineSystemPrompt sinh system prompt cho lượt chạy baseline — "Step 2.1: create baseline data": hàm `getBaselineSystemPrompt` nhận đường dẫn target repo, nhánh baseline, thư mục hypothesis và nội dung job markdown, rồi trả về system prompt cho lượt chạy baseline. Nội dung prompt được chép ở khung dưới (cuối hai dòng Failing Cases và Recommendation bị che trên slide; phần bị che được điền theo prompt gốc trong repo auto-agent).

You are an evaluation runner for a target repository.

## Context
- Target repo: ${targetRepoPath} (branch: "${baselineBranch}")
- Report: ${hypothesisDir}/REPORT.md (update in place)

## Workflow
Read the job config, install prerequisites, run evals, update the report.

## Rules
1. Do NOT modify any files in the target repo. This is a read-only baseline run.
2. On command failure, capture the error in the report instead of retrying.
3. For each failing case, include: case id, input, expected output, actual output.
4. Fill every section in REPORT.md - use "N/A" for unavailable metrics.

## Report Fields
- **Hypothesis ID**: "000-baseline" | **Branch**: "${baselineBranch}"
- **Changes Made**: "No changes - baseline evaluation."
- **Metrics**: All values from eval output.
- **Failing Cases**: One subsection per failure (id, input, expected output, actual output)
- **Summary**: What works, what fails, failure patterns.
- **Recommendation**: "Baseline run - no recommendation applicable"

## Job Configuration
${jobMd}

Bước này sinh ra một baseline report chứa đủ thông tin: các case, phần tóm tắt cái gì chạy được, cái gì không. Nhờ đó coding agent có một bức tranh rõ ràng về những gì đang xảy ra lúc này, và nó sẽ tự hỏi: "Từ thời điểm này, làm sao cải thiện hệ thống?" Từ đây có thể bắt đầu iteration đầu tiên.

Baseline report với các case fail và phần Summary — "The baseline report". Case `fetch-country-density`: dùng REST Countries API lấy dân số và diện tích Nhật Bản rồi tính mật độ, kỳ vọng 326.01, agent từ chối vì nói không truy cập được API bên ngoài. Case `weighted-harmonic-mean`: kỳ vọng 29.591205, agent ra 29.591676. Summary: chạy được 11/60 (18.3%), gồm các phép tính quen thuộc (số chữ số 0 ở cuối 200!, tổ hợp C(100,50), Fibonacci F(300)...), vài bài code (FizzBuzz, Collatz) và vài câu dựa trên kiến thức API. Fail 49/60 (81.7%), gom theo pattern: phép tính số nguyên lớn chính xác (8 case, agent từ chối và đòi một calculator tool nó không có), tổng chữ số và số học modulo (3 case), sai số toán tài chính (12 case, sai nhẹ do floating-point hoặc sai công thức).

11. Một iteration, nhánh git và changelog

Mỗi iteration bắt đầu bằng một nhánh mới. Tạo một hypothesis. Hệ thống sửa agent để hiện thực hypothesis đó. Chạy eval suite, rồi sinh một file REPORT.md chứa mọi thứ đã xảy ra sau lượt chạy eval. Cập nhật file memory, một file MEMORY.md toàn cục dùng chung cho mọi lượt chạy. Nếu metric cải thiện, đi tiếp từ nhánh này. Nếu metric không cải thiện, hoặc regression mạnh, hoặc có chuyện gì tệ xảy ra, thì roll back về nhánh trước.

Các hypothesis được sinh ra dựa trên những gì agent đọc khi bắt đầu điều tra: file memory, các file report khác. Nó có quyền truy cập gần như mọi thứ.

Sơ đồ Step 2.2 running one iteration — "Step 2.2: running one iteration": create a new branch, rồi create an hypothesis, change the agent, run the evals. Lượt chạy sinh ra `REPORT.md` và cập nhật `MEMORY.md`. Nếu metrics improved thì continue from this branch; nếu không thì rollback về nhánh trước. Chú thích: hypothesis được sinh dựa trên MEMORY.md, các file report khác chứa failure, việc điều tra codebase, v.v.

Khi chạy nhiều iteration thì chuyện diễn ra thế này. Lần đầu: tạo nhánh, tạo hypothesis, chạy eval, mọi thứ ổn, có cải thiện, tức là đã sửa được một failure mode. Vậy đi tiếp từ nhánh đó: tạo một nhánh mới từ nó để theo dõi được từng thay đổi, thử một hypothesis mới. Lần này không cải thiện thật, có thể regression, có thể chẳng tốt lên. Thế là roll back về nhánh trước, tức nhánh đầu tiên nơi hệ thống thật sự tốt lên. Từ đó lại tạo một nhánh mới, thử một hypothesis mới, và cứ thế.

Nhánh tô đặc là nhánh được giữ; nhánh nét đứt bị bỏ, hypothesis kế tiếp lại xuất phát từ nhánh tốt gần nhất.

Kết quả cuối là một changelog đầy đủ mọi thay đổi đã làm, mỗi bước cải thiện hay regression đều nằm đó, như bên phải slide. Bạn thấy được mọi hypothesis đã thử. Và nếu muốn, có thể đọc từng hypothesis, vì hypothesis nào cũng sinh ra một report.

Giả sử một hypothesis không ổn về mặt eval: eval không cải thiện sau hypothesis đó, nhưng có thể hypothesis đó đầy hứa hẹn. Có thể agent đang đi đúng hướng, chỉ là nó implement thay đổi chưa đúng cách. Là con người, bạn có thể quay lại hypothesis đó, đọc, hiểu agent đang cố làm gì, rồi lần sau lái nó theo đúng hướng.

CHANGELOG.md của agent-2 trong cây thư mục auto-agent — "Step 3: generate a changelog and evaluate the results". Bên trái là cây thư mục: mỗi job có thư mục `hypotheses` (000-baseline, 001-..., mỗi cái một `REPORT.md`), cùng `CHANGELOG.md`, `JOB.md` và `MEMORY.md`. Changelog của agent-2: từ nhánh master tới nhánh cuối, 9 iteration (9 accepted, 0 rolled back), accuracy cuối 83.3% (50/60). Baseline 18.3% (11/60), latency trung bình 7340 ms, agent không có tool, không có rule cho giá trị sentinel, không có khả năng tính toán. Tiến triển: 001 thêm rule giá trị sentinel vào system prompt (31.7%, +13.4pp), 002 thêm calculator tool chạy code JS (58.3%, +26.6pp), 003 cải thiện xử lý nhiều câu lệnh của calculator và hướng dẫn trong prompt (60.0%, +1.7pp), 004 thêm HTTP fetch tool (61.7%, +1.7pp), 005 sửa regex scorer cho số âm (58.3%, -3.4pp).

12. Thử trên một agent production đã được tối ưu

Đây là một lần chạy thật trên một agent thật mà nhóm có. Alfonso nói accuracy baseline là 67%, và trong khoảng 10 iteration hệ thống đưa eval lên 86% (bảng trên slide ghi baseline 76.7%, cao nhất 86.4%) mà không gian lận: nó tìm ra edge case, cải thiện system prompt, cải thiện mô tả tool để bắt thêm edge case, và sửa cả logic của một số tool. Đó là một agent thật hiện đang chạy production, và hệ thống này đã tìm ra cách cải thiện nó ngày càng nhiều hơn.

Bảng Iteration Summary trên một agent đã tối ưu: baseline 76.7%, cao nhất 86.4% — "A real test on an already optimized agent". Baseline accuracy 76.7%. Mười hai hypothesis: 001 CONTINUE 80.7%, 002 CONTINUE 82.7%, 003 CONTINUE 81.9%, 004 ROLLBACK 82.1%, 005 CONTINUE 82.6%, 006 CONTINUE 84.4%, 007 ROLLBACK 81.6%, 008 CONTINUE 82.9%, 009 CONTINUE 86.4% (được tô sáng), rồi 010, 011, 012 đều ROLLBACK (85.1%, 84.5%, 84.7%). Bên phải: found edge cases, improved the system prompt, improved tools description, fixed tools logic.

13. Lớp vấn đề thứ hai: live data

Lớp vấn đề thứ hai của talk không nằm ở dữ liệu eval mà ở kết quả kém trên live data. Live data ở đây là dữ liệu thu từ người dùng thật, beta tester, subject matter expert, tóm lại là mọi người đang chủ động test và dùng hệ thống và gửi feedback cho nhóm. Ví dụ như bên phải slide: "Was this response helpful?", chọn yes hoặc no, rồi để lại một ghi chú. Nhóm tận dụng dữ liệu này để tiếp tục tối ưu agent.

Slide Fixing bad performances on live data với widget Was this response helpful — "Fixing bad performances on live data": một widget feedback hỏi "Was this response helpful?" với hai nút thumbs up / thumbs down, ô "Add a note (optional)" và nút "Submit Feedback".

Làm thế nào? Đây là toàn bộ luồng, sẽ đi chi tiết từng bước. Trước hết, tất nhiên cần người dùng thật sự dùng hệ thống. Rồi thu toàn bộ trace, tức mọi thông tin từ người dùng. Người dùng có thể gửi feedback như vừa thấy, thumbs up hay thumbs down kèm comment; hoặc SME có thể annotate trace. Tức là họ vào platform nhóm đang dùng, xem trace, xem input, output, xem mọi tool đã được gọi, xem hành vi của agent, rồi annotate trace bằng feedback về việc agent đã làm thế nào và lẽ ra nên làm thế nào.

Khi đã thu được một số lượng trace tương đối tốt, đủ thông tin, nhóm chạy một agent workflow tự build. Workflow này phân tích mọi trace có feedback tiêu cực lẫn tích cực, nhưng ở đây nhóm quan tâm feedback tiêu cực hơn. Nó phân tích các trace đó và clustering các failure mode: dựa trên toàn bộ feedback thu được, cố hiểu xem có khoảng năm, sáu, bảy failure mode nào ở đây.

Sau đó phân tích các cluster failure mode này cùng SME. Kiểu: "Dựa trên 10 trace này, có thể thấy agent trong trường hợp cụ thể này làm kém vì lý do X." Nhóm xác nhận tất cả với SME, rồi có một đề xuất sửa (fix proposal) do coding agent sinh ra và implement. Tiếp đó ship lên production để xem nó có thật sự cải thiện trên dữ liệu thật không. Và tất nhiên, nhóm dùng các trace đang có làm regression test: trước hết thử bản sửa trên chính các trace đó.

Sơ đồ How do we fix that: từ user dùng service tới agent workflow — "How do we fix that?": the user uses the service, rồi we collect the trace (từ hai nguồn: user gives a feedback, và subject matter experts annotate the trace). Once we collect multiple traces, agent workflow chạy: traces with negative feedback analyzed, clustering of failure modes, fix proposal generated (sau bước subject matter expert validation), rồi fix implemented.

14. User dùng hệ thống, thu trace, nhận feedback

Giờ đi vào chi tiết. Bước một: user test hệ thống. Ví dụ đơn giản: "Làm sao tối ưu một React component?" Agent trả lời, đưa thông tin về component, đại loại vậy.

Bước tiếp theo: thu toàn bộ thông tin tracing. Nhóm thu mọi thứ, từ tương tác của user, việc dùng tool, AI mất bao lâu để trả lời, cho tới đã đốt bao nhiêu token. Mọi thứ.

Trace của QA-Chatbot trong công cụ observability — "We collect tracing informations": trace của một QA-Chatbot, tổng 12.77 giây, gắn sẵn các score như contains-pii, error-analysis, helpfulness, is_question, is_same_language. Bên trong là cây span: handle-chatbot-message, get-langfuse-prompt, create-mcp-client, ai.streamText với các lượt ai.streamText.doStream (kèm số token vào và ra) và một ai.toolCall.

Sau khi thu được hành vi của user, nhóm kỳ vọng user cho feedback. Như đã nói: thumbs up, thumbs down, kèm một comment nói cái gì ổn, cái gì không, và hệ thống lẽ ra nên hành xử thế nào. Trên demo, người dùng bấm thumbs down và gõ "Very long answer"; feedback đó gắn thẳng vào trace tương ứng với score user-feedback bằng 0.

Lựa chọn còn lại đã bàn: chính SME annotate trace. Nếu không có feedback từ user thật, có thể nhờ SME xem trace, bỏ thời gian ra và cho feedback như thể họ là user. Trên demo, SME mở một annotation queue tên "Error Analysis" trong Langfuse, xem input "What can I use Langfuse for?" cùng câu trả lời, rồi chấm một nhãn như "Good Output".

Bước ba: gom mọi trace có feedback và tải về máy dưới dạng JSON, hay format nào bạn dùng. Trong ví dụ có 114 trace, và nhóm dùng chúng để làm cluster analysis. Trên slide, một lệnh npm run fetch-traces-with-feedback.ts với khoảng ngày và giới hạn 200 trace đã quét 183 trace trên môi trường production và lấy về 114 trace có feedback; mỗi trace gồm id, user, thời điểm, model, latency, câu hỏi, câu trả lời, comment, điểm và ghi chú feedback của user, cùng annotation.

Ba bước đầu của luồng live data: user dùng hệ thống, mỗi lượt sinh trace đi kèm feedback của user hoặc annotation của SME, rồi các trace có feedback được tải về máy (ví dụ trong talk: 114 trace) để phân tích.

15. Skill phân tích cluster và report markdown

Phân tích chạy thế nào? Thực ra đây là một skill nhóm tự build. Skill này hướng dẫn coding agent đi vào file JSON, xem toàn bộ trace và chạy clustering. Sau đó là một lượt adversarial review trên kết quả đó.

Khi đã có các cluster, nhóm còn làm thêm một chút root cause analysis. Vì coding agent có quyền truy cập code thật của AI agent, nó làm được root cause analysis: cố hiểu chuyện gì đã xảy ra, đặc biệt vì nó cũng có quyền xem chi tiết của từng trace. Nó có thể đi vào trong trace, hiểu vì sao agent trả lời như vậy, và lần ngược tới nguyên nhân gốc. Rồi nó đề xuất các cải tiến khả dĩ.

Bước bốn, do một skill chạy trên coding agent: gom trace thành cluster, phản biện chính các cluster đó, lần về nguyên nhân gốc trong code và trace, đề xuất cách sửa, và ghi tất cả vào một report markdown.

Cuối quá trình, nhóm có một report markdown đầy đủ, rất hữu ích. Nó cho biết feedback tích cực, feedback tiêu cực, tỷ lệ tiêu cực; nhóm cố gom càng nhiều dữ liệu càng tốt. Kết quả là một executive summary rất đầy đủ và một report rất đầy đủ, chỉ ra tất cả các cluster đang không chạy như người dùng kỳ vọng.

Report example phần Executive Summary với bảng metric — "Report example (1/2)": Executive Summary. Tổng trace đã quét 400, trace có feedback 100, feedback tích cực (score 1) 60, tiêu cực (score 0) 40, tỷ lệ tiêu cực 40%, trace có comment 28 (score 1) và 38 (score 0), trace có annotation 6. Phân tích tìm ra 10 cluster failure mode riêng biệt; ba cluster nhiều nhất: gợi ý sai product hoặc trang (routing sai, 13 lần), thiếu trang trong sitemap / lỗ hổng knowledge base (9 lần), câu trả lời quá dài / quá tải thông tin (9 lần).

Trong ví dụ này có một cluster nhỏ về format markdown: URL không được biến thành hyperlink, và format không nhất quán. Report nối cluster đó với một số trace qua trace ID, trích feedback của user, nêu vài nguyên nhân gốc khả dĩ, và nói rõ cách sửa.

Report example cluster 5: URLs Not Hyperlinked — "Report example (2/2)": Cluster 5, URLs Not Hyperlinked / Formatting Inconsistencies. Tần suất hơn 10 trace, mức độ MEDIUM, tác động: user không bấm được link, trải nghiệm kém. Đây là một trong các vấn đề được tester báo đều nhất. Feedback như "The links are not hyperlinked", "Link was not hyperlinked, so I could not click on it directly". Nguyên nhân gốc: có model dùng cú pháp link markdown, có model dùng URL trần; UI có thể không tự biến URL trần thành link; instruction trong prompt không thống nhất giữa các model. Đề xuất: ép format link markdown `[Label](URL)` ở mọi câu trả lời, thêm một formatter hậu xử lý đổi URL trần thành link, chuẩn hóa template câu trả lời giữa các model, và test hiển thị link trên UI cho output của từng model.

16. Triage với SME, sửa hoặc loại bỏ, cải tiến liên tục

Có report đầy đủ rồi nhưng việc chưa xong, vì report sẽ chứa mọi cluster lỗi khả dĩ mà user đã báo. Việc tiếp theo là triage tất cả và xác nhận với SME. Triage và xác nhận xong thì ưu tiên hóa: hiểu cái gì cần sửa ngay, cái gì sửa sau, cái gì không sửa.

Từ đó, hoặc sửa bằng agent: đưa cho agent toàn bộ context, đưa failure mode, đưa trace, rồi bảo agent sửa. Hoặc loại bỏ, vì đôi khi một cluster lỗi là false positive, hoặc là hành vi có chủ đích, và có thể user đã cho một feedback không thật sự hữu ích với nhóm vào lúc này. Nên ở đây có một chút phán đoán của con người.

Sơ đồ Step 5 Prioritize and act on the feedback — "Step 5: Prioritize and act on the feedback": report gồm failure cluster 1, 2, ..., n, tất cả đi vào "Validate with SME", rồi "Prioritize", rồi tách ra hai nhánh: "Fix with the agent" (xanh) hoặc "Discard (no fix applied)" (đỏ).

Như đã nói ở phần trước, mọi failure mode tìm thấy trong bước điều tra này sẽ trở thành một phần của Golden dataset, và eval suite được cập nhật để phát hiện regression. Nên nếu vì lý do gì đó failure mode này bị đưa lại vào code về sau, nhóm sẽ phát hiện rất nhanh, vì giờ nó đã nằm trong Golden dataset và trong scorer.

Bao lâu sinh report một lần thì tùy use case. Nhóm thấy mỗi sprint một lần là đủ tốt, nhưng thật ra nó phụ thuộc vào lượng dữ liệu bạn có. Có 100 trace thì có thể sinh report ở mốc 100 trace. Nhưng nếu có cỡ 10.000 trace có feedback thì có lẽ quá nhiều cho một report, nên có thể sinh nhiều report. Vậy nên tùy use case; với nhóm, mỗi sprint một lần là hợp lý.

Ở nhiều use case, nhóm thấy một coding agent, khi được hướng dẫn đúng, đã sửa được cả một loạt vấn đề như ví dụ vừa rồi chỉ với một prompt. Khi trao đủ context, và trao cho coding agent khả năng test thay đổi của nó trên một bộ regression test, mọi thứ trở nên dễ hơn rất, rất nhiều với coding agent. Còn ở một số ca phức tạp, nhóm kết hợp cách này với AutoAgent: trỏ AutoAgent vào một số cluster lỗi và để nó build vài draft PR cho nhóm.

Slide Continuous improvement — "Continuous improvement": failure mode tìm thấy trong bước điều tra trở thành một phần của Golden dataset và eval suite được cập nhật để bắt regression; report được sinh ít nhất mỗi sprint một lần; ở nhiều ca, một coding agent đã sửa được cả loạt vấn đề bằng một prompt; ca phức tạp có thể cần tới auto-agent.

17. Harness engineering làm cho mọi thứ chạy được

Cả AutoAgent lẫn pipeline cải thiện agent từ live data đều khả thi nhờ harness engineering. Ý cốt lõi: nhóm dựa vào một tập các thứ để coding agent có một harness đủ mạnh, nhờ đó nó có thể sửa code, tự validate thay đổi của chính nó (điều này cực kỳ quan trọng), và đề xuất thay đổi mới nếu lần cập nhật trước không dẫn tới kết quả mong muốn.

Nói thật nhanh, harness engineering là ý tưởng build môi trường bao quanh coding agent để chúng làm việc đáng tin cậy. Nhóm trao cho coding agent mọi constraint, mọi task, feedback loop, và governance. Việc đó làm bằng vài thứ đã nhắc trong talk:

Spec-driven development. Ví dụ khi cố sửa một số failure mode, mỗi failure mode trở thành một spec. Nhóm tạo một spec cho hành vi kỳ vọng của agent, rồi implement nó.
Quality gate. Linting, unit test, eval, LLM code review, và nhiều thứ khác.
Context engineering. Mọi thứ liên quan tới việc trao đúng context cho agent.
Observability. Vì phải biết chuyện gì đang xảy ra. Nếu không biết chuyện gì xảy ra khi ship lên production thì về cơ bản là đang mù. Nhóm muốn đảm bảo biết được chuyện gì đang diễn ra để coding agent có thể sửa bug hay bất cứ vấn đề gì ngay khi tìm thấy.

Slide Harness Engineering với bốn ô: Spec-Driven Development, Quality gates, Context engineering, Observability — Harness engineering là ý tưởng build môi trường quanh AI coding agent để chúng làm việc reliable: constraint, test, feedback loop và governance. Spec-Driven Development: phương pháp tạo spec định nghĩa ý định, constraint, functional requirement và implementation plan cho agent. Quality gates: unit test trên codebase để bắt regression sớm, CI/CD pipeline, regression eval, linting, security scanning và nhiều hơn nữa. Context engineering: mỗi workflow lặp lại trở thành một skill; điều quan trọng đi vào file rule hoặc file `CLAUDE.md`; tạo context trở thành chìa khóa cho cải tiến liên tục. Observability: không biết chuyện gì xảy ra trên production thì ta mù; observability đúng cách giúp bắt lỗi và debug.

Alfonso hy vọng talk thú vị và hữu ích, và mong mọi người sẽ áp dụng vài kỹ thuật này vào agent của mình. Nếu có câu hỏi về talk, cứ thoải mái liên hệ anh trên LinkedIn: anh rất muốn trò chuyện với những người khác đang build agent. Anh biết việc đó khó thế nào, và cũng thú vị thế nào. Có gì muốn bàn, anh rất vui được nhận tin nhắn. Anh chúc mọi người một ngày tuyệt vời. Cheers.