Tag: agent
All the articles with the tag "agent".
-
Eval Study #4 — HITL Agent Regression Test, Passed but for the Wrong Reason
Following the previous post (agent tool selection · multi-step eval), this is a regression test for an HITL agent. This time, instead of a (question · expected tool) test set, I wrote unit-test style functions covering 3 axes of pitfalls (entering the breakpoint for dangerous tools / responding on every turn in multi-turn conversations / not misclassifying safe tools), with sys.exit(1) as the exit code on regression. The first run passed 3/3 — but that wasn't the right answer. The "call only after confirming clear intent" prompt that had been an issue before was still lingering, and the LLM was passing the test via its own self-defense mechanism. When I provoked it with a delete case, our HITL didn't trigger at all — only the LLM's own confirmation remained. Removing the prompt → the failure shifted to the tool simply not being called at all. Eventually, minimizing the prompt to "call the tool that matches the task the user requested" made it stop exactly at the delete_user tool (HITL working, exit code 0). Passing an eval by itself isn't a safety signal — verifying why it passed is the real safety. Pausing the LLM study series here for now, to resume after wrapping up backend studies.
-
Eval Study #3 — Agent Eval, the Limits of Single-Step Scoring, and Multi-Step Grading
Expanding from RAG Eval to agent Eval. Agents have 6 axes to judge (tool selection, argument extraction, multi-step trajectory, termination judgment, safety guards, final answer quality), so separating axes—like unit tests before integration tests—makes it faster to pinpoint causes. Today I covered just 3: tool selection, multi-step, and trap regression. I fed in MCP server tool metadata (name, description, schema) and measured against a (question, expected tool, expected args, level) test set → tool selection accuracy 11/13 = 84.6%. Two failure cases were interesting — (1) a single-step eval falsely flagged a case that was actually correct as a multi-step trajectory, showing the limits of single-step scoring, and (2) an ambiguous tool description caused "electricity bill" to wrongly pick consumption, while "how much money is it?" got it right — patching the system prompt instead of fixing the description risks overfitting. I then switched to multi-step eval (did it call all necessary tools, in order, using prior results, with correct termination judgment) → 4/4 = 100%, and the case that failed under single-step scoring now passed.
-
Eval Study #1 — Ending 'Vibe Benchmarking' · Accuracy-based + First LLM-as-Judge Implementation
Eval Study #1 — Ending 'Vibe Benchmarking' · Accuracy-based + First LLM-as-Judge Implementation
-
MCP Study #3 — What Resources / Prompts Actually Are + Integration with LangGraph (`MultiServerMCPClient` · `ainvoke`)
Beyond Tools covered in #1 / #2, this post covers the other two components of MCP: Resources (data for the LLM to read, background context, read-only) and Prompts (predefined templates). I check a new server with Inspector + Claude Desktop → integrate the MCP server into LangGraph using langchain-mcp-adapters. Covers why `ainvoke` is needed since MCP communication is asynchronous, the secret behind how MultiServerMCPClient loads servers as-is (= MCP standard compliance), and the difference in domain response quality when injecting Resources as a system prompt.