AI Agent: Design Principles and Engineering Practice is an open-source book that explains how AI agents combine language models, context, and tools, with accompanying experiments and code. It is intended for readers studying the principles and engineering of AI agents, from fundamentals through production use. The catalogue skills support coding-agent work related to the book's subject matter.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add bojieli/ai-agent-book --skill agent-evaluationgit clone --depth 1 https://github.com/bojieli/ai-agent-bookWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/bojieli/ai-agent-book/agent-evaluation)<a href="https://agentmods.dev/skills/bojieli/ai-agent-book/agent-evaluation"><img src="https://agentmods.dev/badge/skills/bojieli/ai-agent-book/agent-evaluation/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/bojieli/ai-agent-book/agent-evaluation"><img src="https://agentmods.dev/badge/skills/bojieli/ai-agent-book/agent-evaluation.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00133 | $0.04679 |
| Opus 5.5 | $0.00053 | $0.01872 |
| Sonnet 5.5 | $0.00027 | $0.00936 |
| Haiku 4.5 | $0.00013 | $0.00468 |
Grade A, and why
agent-evaluation scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 22d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 130 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Agent 评估体系
何时使用
- 为 Agent 系统建立第一套评估,或审查现有评估是否可信
- 选模型、换模型前需要数据依据(新模型公开分高,不代表在你的任务上更好,甚至可能回退)
- 评估分数下降,要判断是 Agent 退化还是评测系统本身出了问题
- 需要把"成功率下降"这类笼统结论拆成可着手修复的具体问题
- 为生产 Agent 建设内部评估基础设施:消融实验、AB 测试、特性开关、提示词回归
- 设计可观测性与生产轨迹回流,让评估集随产品持续演化
核心原则
- 评估的对象是"模型 + Harness"组合体,不是模型本身。 同一模型在不同 Harness 下表现悬殊;表现不佳时先怀疑 Harness,再怀疑模型。
- 用模型替换实验(model swap)区分两类问题:固定 Harness 只换模型,分数不涨 → 瓶颈在 Harness;分数随模型能力大幅波动 → 瓶颈在模型能力。消融实验则是关闭 Harness 组件、定位内部哪个部件重要,两者互补,别混用。
- 先检查评测系统,再动 Agent。 分数下降先排查:运行环境资源不足导致的随机失败、验证器 bug 把对的判错、用例与生产脱节——这些在数字上与模型退化一模一样,只有回放完整轨迹能区分。
- 指标口径由业务场景决定。 同一个 0.8,对退款客服意味着每五名用户一人拿不到退款,对漏洞挖掘已属可观。报告必须写清 k 的口径:同一任务的 k 次独立采样,还是生产流水线连续 k 个任务。
- 凡是能写成程序化断言的检查就用断言,LLM 评判只用于确实无法机械判定的维度。确定性验证更便宜、更可复现,适合长期进 CI。
- 分差要超过噪声、在配对分析中成立、并且能够复现,才值得据此切换模型或发布改动。
- 一轮证据只支持与它规模相称的下一步。 子集 4/4 不能写成系统整体 100%,完整复测通过前不部署。
实践模式
1. 指标设计:Pass@k / Best@k / Pass^k
- Pass@k(k 次至少一次通过)与 Best@k(连续得分取最好)衡量能力上限,适合科研发现、漏洞挖掘、开放式创作——人类会从 k 条候选轨迹里挑出最好的那条。
- Pass^k(连续 k 次全部通过,且不触发安全、合规、幻觉等一票否决项)衡量业务可靠性,适合支付、退款、权限变更、生产部署。两者关系:Pass@k = 1-(1-p)^k,Pass^k = p^k。
- p=0.6、k=5 时:Pass@5 ≈ 99%,Pass^5 ≈ 7.8%——前一个数字回答"能不能偶尔创造奇迹",后一个才回答"能否稳定交付"。
- 会产生副作用的操作不能"重试直到成功":应在沙盒或可回滚环境中采样,每一次失败都记入可靠性指标。
2. 评估环境五要素
- 数据集:初始状态、给 Agent 的输入、给模拟器的行为规范与验收标准,打包为一条记录即一个用例。
- 环境状态:必须可重置(
initialization_actions即重置脚本);真实性(变化符合业务逻辑)与可控性(每次回到同一起点)兼得。 - 工具接口:两侧工具均为原子操作;抽象层次过高(如一个"解决用户问题"工具)会使评估退化为对单次函数调用的考察,规划与推理被工具本身吸收。
- 评分标准:分层检查项 + 明确的聚合规则(如
reward_basis)。 - 执行协议:终止信号、轮数上限、模拟用户耐心耗尽主动结束(沟通效率过低本身即计为失败)。
- 按任务形态选环境类型:单轮问答用无状态单轮环境;搜索+综合用多轮工具环境;改数据库验状态用有状态环境;跑代码查输出用沙盒环境。并行采样与轨迹缓存是标配;工具失败应返回清晰错误信息而非单一失败标志,让 Agent 能据此调整策略。
3. 验证方式谱系与自动化评估
- 横轴是可机械验证程度:确定性断言 → 检查项清单 → Rubric + LLM-as-a-Judge → 配对比较。向右移动不意味着放弃左侧。
- 确定性验证只能判对错、不给原因;生产系统最需要的恰恰是"错在哪、下一步改什么"。开放式任务(报告、投诉、创意)无唯一终态、人工评估不可规模化,才上 LLM 评判。
- Rubric 四准则:基于专家指导(捕捉核心事实与推理步骤,而非语言流畅度);全面覆盖(事实、逻辑、完整性、安全性,且明确 Pitfall);按重要性加权(必要/重要/可选/陷阱,支持一票否决,如幻觉出现总分归零);评价标准自包含(禁"展示深刻理解",改为"引用了至少两个权威理论并准确解释")。
- 每个维度给客观可验证的评分档次、具体示例与边界案例;显式防范奖励作弊(幻觉、讨好用户、关键词堆砌、回避棘手问题)。
- 长度偏差防范:Rubric 显式惩罚冗长、规定同类任务长度上限;配对比较前把候选长度控制到相近;定期审计评分与长度的相关性——高分几乎总伴随长回答即已被带偏。
- 同源模型问题:Agent 与评判模型同家族时,Agent 会学会利用评判模型的偏好与盲点(古德哈特定律:度量成为优化目标后就不再是好度量)。换不同家族模型评判,并让 Rubric 随分歧持续迭代。
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 22d ago First seen · 130 lines · 133 tokens per session scan A 04712fc85be9
agent-evaluation is a skill published in the GitHub repository bojieli/ai-agent-book (54,406 stars, last pushed 7d ago), licensed Apache-2.0. It adds 133 tokens to every session and 4,679 once invoked, about $0.0005 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-24.
Other skills, from other repositories
01-acceptance-qa
Validate a reviewed candidate's observable behavior against its acceptance criteria and record short named videos as reviewer evidence. Use when acceptance criteria exist and a browser-observable journey needs proof it holds. Do NOT use for diff review, unit or integration tests, or application fixes.
06-test
Write and iterate developer-side tests until they pass, or validate a user journey end to end in the browser during implementation. Use when the user wants to add coverage, find what's untested, or walk a flow while building it. Do NOT use for independent acceptance QA or reviewer evidence, auditing test health, or…
test-cases
Generate test cases from a Jira ticket's acceptance criteria. Produces e2e test scenarios (steps and expected results, no code) and a unit test checklist for developers. Test cases map back to requirements for traceability. Use when: "write test cases", "generate tests", "e2e tests for PROJ-789", "test cases for this…
e2e-pom
Build and maintain Page Object Models by live element discovery — never by guessing selectors. Build mode pairs with the user: derives the element inventory from test cases, proves every locator against the running app, and confirms with highlighted screenshots before anything enters the POM. Heal mode runs…
e2e-setup
Set up Playwright e2e automation tailored to this team and app. Probes the running app (auth mechanism, API surface, spec availability), interviews with recommendations instead of open questions, scaffolds the playwright/ folder, and records every decision in playwright/AUTOMATION.md for the other e2e skills to read.…
verify-fix
Re-test a bug fix after a developer resolves it. Pulls the original bug from Jira, re-executes the repro steps in the browser, checks for regressions, and updates the bug status. The final step in the SDT workflow before a ticket moves to Done. Use when: "verify fix", "retest", "is this fixed?", "check BUG-123"…