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 bad-case-to-dpogit 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/bad-case-to-dpo)<a href="https://agentmods.dev/skills/bojieli/ai-agent-book/bad-case-to-dpo"><img src="https://agentmods.dev/badge/skills/bojieli/ai-agent-book/bad-case-to-dpo/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/bad-case-to-dpo"><img src="https://agentmods.dev/badge/skills/bojieli/ai-agent-book/bad-case-to-dpo.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.00168 | $0.03438 |
| Opus 5.5 | $0.00067 | $0.01375 |
| Sonnet 5.5 | $0.00034 | $0.00688 |
| Haiku 4.5 | $0.00017 | $0.00344 |
Grade A, and why
bad-case-to-dpo 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 — 108 lines — stays where its author put it; the contents beside it link to each section on GitHub.
从问题案例到训练数据
何时使用
- 生产出现 bad case:用户纠正、点踩、事后审计发现失败轨迹,想把它变成后训练输入
- 判断某类失败该修 Harness/工具/tokenizer,还是值得投入训练
- 构造 DPO 偏好对、轨迹前缀回归任务、决策边界示范
- 决定一个失败案例该进 SFT 数据、DPO 偏好对、PRM 负标签还是 RLVP 惩罚规则
- 训练后验证修复效果,担心"修好一个、弄坏一片"
- 从运行轨迹中提取可学习信号,而不是只存一个总分
核心原则
- 归因到首个错误步骤,不是整条轨迹。 以 Coding Agent "过早结束"为例:读代码、改代码可能都没错,错的是"在缺乏证据时下结论"那一个决策边界。归因记录必须落到这一步,训练数据才能对着它构造。
- 失败轨迹不应直接当作正确的 SFT 示范。 它的正确用法是:构造偏好对、发现任务覆盖缺口,或补上诊断与修复后再加入训练。
- 判定必须靠模型写不了的机制。 "是否完成"要由隐藏测试、状态断言或外部终止钩子给出;测试必须读取真实文件或环境状态,不能只检查模型是否说了"已完成",否则模型会学会口头承诺验证而不真正验证。
- 边界集与保留集缺一不可。 边界集(任务未完成)看模型是否选择继续验证而非宣称完成;保留集(任务已完成)看模型是否仍能正常收尾。只盯边界集会把模型训练成永远不敢结束的过度矫正状态:每个任务都无限验证下去,延迟与成本崩溃。这是"改动不能破坏既有行为"在参数层面的版本。
- 训练与评估严格隔离。 训练集与评估集必须是不同的任务、不同的参数、不同的模板组合;参考解法、隐藏测试和验证器反馈不能泄露给模型。隔离规则应由单元测试强制检查,而不是靠人记得。
- 先排除非模型原因。 沿"文件原始字节 → 工具返回 → Harness 序列化 → 模型上下文 → 模型 token 输出 → 解码字符串 → JSON/tool-call 解析 → 工具匹配"逐层对比。只有模型收到的上下文与原始字符串完全一致、而模型输出是链路上首个出现差异的位置,才能标为模型能力问题。否则修工具/Harness/tokenizer,修完再看还剩多少。
- 小数据 DPO 必须混入通用任务数据。 案例数量少时,按小配比混入通用任务做 LoRA 微调,避免把"逢收尾必验证"学成新的过拟合,也降低灾难性遗忘风险。
- 学习信号必须带证据。 单一总分无法指出该改哪里。可供学习的评价至少包含:任务成功/部分成功/失败、每个维度各自的结论、每条结论对应的证据位置(哪一轮对话、哪一次工具调用)、失败的类型标签。验证器还应被允许在证据不足时拒绝评分——低置信度案例应排除在学习集之外,而不是当作事实固化。
实践模式
完整链路:失败归因 → 双集验证
① 采集与归因。 从用户纠正、点踩、事后审计三类生产信号收集失败轨迹,按错误分类定位首个错误步骤并记录错误类别。轨迹前缀回归任务就是从这个决策边界截取的。
② 分流:该不该训练。 先问 prompt、工具、代码约束、上下文管理能否解决;再沿字节链路排除工具/Harness/tokenizer 问题。都不要动权重时就不训练。
③ 选训练形态。 按第七章评估数据集的类型映射到第八章用法:
| 你手上的材料 | 训练用法 |
|---|---|
| 端到端回归任务(含验证器) | RL rollout 任务与可验证奖励(RLVR);拒绝采样(RFT)的采样池 |
| 轨迹前缀回归任务 | DPO 偏好对、决策边界的 SFT 示范、On-Policy Distillation 的教师状态 |
| 失败归因记录(首个错误步骤与错误类别) | 过程监督的负标签(PRM)、RLVP 路径惩罚的规则来源 |
| Rubric 多维评分与人工金标集 | 向量奖励的各维度、生成式奖励模型(GRM)的训练与校准数据 |
④ 截取轨迹前缀,构造偏好对。 在决策边界上截出"准备宣称完成"的轨迹前缀:rejected 是过早结束的错误行为,chosen 是"先运行测试、逐条核对验收条件,再下结论"的期望行为。chosen 由教师模型生成,再经规则验证器过滤(拒绝采样)。案例太少时用数据扩充(换任务类型、换缺失的验证项、换完成措辞)形成数百条偏好对。失败原因、适用条件和验证器应随样本保存,方便追溯和复查。
⑤ LoRA DPO 训练。 小配比混入通用任务数据防过拟合。参考配置:Qwen2.5-7B-Instruct + bf16 LoRA、4 epochs、学习率 3e-5、单卡约 24GB 显存。训练回执记录配置、数据哈希与时间戳。
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 · 108 lines · 168 tokens per session scan A 51f79ba176bb
bad-case-to-dpo 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 168 tokens to every session and 3,438 once invoked, about $0.0007 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
08-debug
Reproduce and fix a known bug, or find an unknown root cause by hypothesis validation. Use when the user wants to fix a bug, find why something breaks, or reopen a stuck investigation. Not for building a feature or reviewing a diff.
test-driven-development
TDD: enforce RED-GREEN-REFACTOR, tests before code.
prompt-evaluation-runner
Use when evaluating prompts, LLM outputs, red-team suites, or model behavior with local eval configs and safe provider/cost controls.
test-driven-development
A test-driven development guide. Test-driven development, or TDD, means writing a test first, confirming that it fails, then writing the smallest code that makes it pass and improving the result.
auto
Drive an autonomous execution arc end-to-end — compose brainstorm→spec→/prospect→plan→/prospect→TDD→/retrospect under the Rule 35 posture, decide objectively-validatable forks yourself, and stop only on a load-bearing fork or an ungranted approval. Modes: arc (default), execute (skip ideation), plan (stop at a…
promptfoo-evaluation
Configure and run Promptfoo evaluations, assertions, rubrics, and datasets when testing LLM prompts or comparing model behavior.