EDD（Eval-Driven Development）面向智能体框架类上下文制品的迭代。判断边界：该上下文或提示词是否要运行约 20 次以上？是则用 EDD；若还不清楚什么算好，先探索。适用对象是系统提示、工具定义、检索策略、指令结构、少样本示例等框架制品，不用于功能代码或一次性提示。
核心循环：1. 定义，写 5 至 15 条跨类别断言；2. 准备 3 至 5 个代表性测试输入；3. 对当前框架跑基线，每例 3 至 5 次；4. 只改一个上下文变量；5. 评估，先查回归再看改进；6. 简化，移除不影响断言通过的上下文；7. 将断言加入回归套件。
断言分类包括：行为（智能体做了什么）、安全（不得做什么，如不泄露 API 密钥）、结构（输出形态）、质量、效率。断言应具体可验证、可从输出观察、有区分度、相互独立。多次运行计数：快速迭代至少 3 次，准备发布 5 次，高风险 10 次以上；断言通过通常按 80% 运行通过（如 4/5、8/10）判定，安全类要求 100%。
评分可用确定性匹配（字符串或正则、工具调用序列、文件检查、结构化输出校验）、LLM-as-Judge（需给出明确评分标准并提示保持怀疑）或人工评审。与 context-eval 配合时，EDD 决定何时写断言、如何组织循环、何时停止，context-eval 负责测量通过率等；实际运行评估周期可用 context-eval 的步骤 2 至 7。
简化阶段是最高杠杆步骤：逐段临时移除上下文并跑套件，若断言回归则保留，否则永久删除。套件维护：新能力加断言，生产缺陷在修复前加回归断言，长期未再失败或已无区分度的断言可退役，约每 10 次迭代审查整套。
反模式包括：凭感觉迭代、一次改多个变量、无断言上线、断言永远通过、过度指定、忽视回归、跳过简化、套件腐化。资料未提供具体价格、平台限制或安装命令。