还在凭感觉调Agent提示词Anthropic把它变成了可评分实验摘要很多 Agent 项目调到后期都会陷入一个低效循环改一版 system prompt肉眼看几条样例觉得“好像更稳了”然后上线再等真实用户帮忙发现问题。今天 GitHub Trending 里出现了 Anthropic 组织下的 cwc-workshops 仓库。这个仓库不是一篇宏大宣言而是一组 Code with Claude workshop 材料。其中 eval-driven-agent-development 这个目录很值得技术研发读者关注它把 Agent 调优从“凭感觉改提示词”推进到“先建评测再迭代再看分数变化”。背景Agent 研发最大的问题不是不会调用模型现在多数团队已经会让 Agent 调工具、读文件、生成文档或执行代码。真正难的地方在后面你怎么证明这次改动更好如果没有评测体系Agent 迭代很容易变成三类问题单条 demo 很惊艳但换任务就不稳定prompt 越写越长却不知道哪段真的有效每次修一个问题又引入另一个退化。Anthropic 的这个 workshop 选择了一个具体任务让 Claude Managed Agent 生成 slide decks然后围绕这个任务建立 eval迭代 agent并观察评测暴露了什么问题。技术要点一先把任务集固定下来这个 workshop 的项目结构里有 tasks.json用来存放测试任务提示词。README 显示它提供了 5 个 task prompts输出会按任务落到 runs 目录。这一步看似普通但对 Agent 工程非常关键。没有固定任务集就没有可重复比较。今天看 A 任务明天看 B 任务任何“变好了”的判断都可能只是样本不同。研发落地时任务集不需要一开始很大但必须覆盖真实场景简单路径、边界输入、长上下文、多工具调用、失败恢复。先有一批稳定样本再谈迭代效率。技术要点二把输出渲染成可检查对象这个项目不是只看模型文本输出。它会通过 create-slides.ts 启动 Claude Managed Agent session 并下载 pptx然后用 render.ts 把 pptx 渲染成每页 JPG。这说明一个重要思路Agent 的结果应该转成可检查的产物而不是只停留在聊天记录里。对研发团队来说如果 Agent 负责写代码就要跑测试、跑 lint、检查 diff如果负责生成文档就要检查结构、链接、格式如果负责做数据分析就要检查 SQL、图表和结论是否一致。评测对象越贴近最终交付物评测越有意义。技术要点三用程序化指标 LLM 评审组合打分README 中列出的 src 目录包含 parse-pptx.ts、graders.ts 和 eval-runner.ts。说明这个 workshop 不是只让另一个模型“主观打分”而是把 PPTX 解析成结构化指标再配合 grader 定义和 LLM judge 进行评审。这对 Agent 评测很实用。纯程序化检查稳定、便宜、可复现但覆盖不了审美、表达和任务完成度纯 LLM judge 覆盖面广但可能有波动、成本和偏差。组合方式更接近工程现实能程序化的先程序化不能程序化的再交给模型评审。技术要点四每次改动都要和 baseline 比项目运行方式里有一个关键参数第一次可以用 --baseline 记录基线分数后续运行显示相对这个基线的变化。它还提供 show-baseline 查看已存基线。这正是 Agent 研发容易缺失的环节。很多团队只记录“最新效果”不记录“相对上一版到底提升了什么”。结果就是 prompt、工具和模型参数不断漂移最后没人说得清楚哪次改动产生了收益。一个成熟的 Agent 迭代流程至少应该记录任务集版本、agent 配置版本、模型版本、工具版本、评测分数、失败样例和人工备注。研发视角这比“多加一个Agent”更重要过去两年Agent 文章经常强调多 Agent、MCP、记忆、工具调用、长上下文。但如果没有 eval这些能力都很难进入稳定工程系统。原因很简单能力越多退化面越大。加记忆可能引入陈旧信息加工具可能引入副作用加多 Agent 可能引入协调成本加长 prompt 可能让关键约束被稀释。没有评测团队只能靠感觉判断复杂度是否值得。Anthropic 这个 workshop 的价值不在于 PPTX 生成本身而在于它展示了一条可复用路线任务集、产物渲染、结构解析、grader、LLM judge、baseline、delta。这个链路可以迁移到代码生成、报告生成、客服流程、数据分析 Agent 等场景。实践建议给你的 Agent 加一条评测流水线如果你正在维护 Agent 项目可以按下面顺序落地先收集 20 到 50 条真实任务分成核心、边界和回归三类。为每条任务定义期望产物而不是只写“回答要好”。能用程序检查的先程序检查例如 schema、文件数量、测试结果、引用链接、关键字段。对表达质量、任务完整度、推理一致性再引入 LLM judge。每次 prompt、工具、模型或上下文策略变化都跑同一批任务。保存 baseline 和失败样例不只看平均分也看退化案例。只有当分数、成本、延迟同时可接受时才把改动合入主流程。风险与限制需要注意的是cwc-workshops 仓库 README 明确说明这些是 workshop materials当前不维护也不接受贡献。因此它更适合作为工程方法参考而不是直接当生产模板照搬。另外LLM judge 本身也需要校准。研发团队不能因为用了模型评审就放弃人工抽检尤其是涉及安全、金融、医疗、合规或外部发布的 Agent 输出。结语如果说 Agent 的上半场是“让模型会做事”那下半场就是“证明它稳定地把事做好”。标题可以夸张一点但工程不能靠感觉。真正值得投入的不是再堆一个 Agent而是先给现有 Agent 装上一套评测和回归系统。你们现在调 Agent是靠人工抽查还是已经有 baseline 和自动评分如果有典型场景可以在评论区发出来我可以按“任务集-产物-指标-评审”这条链路帮你拆一下。参考来源GitHub Trending: anthropics/cwc-workshops 今日进入趋势列表https://github.com/trendingAnthropic GitHub Organization: cwc-workshopshttps://github.com/anthropics/cwc-workshopscwc-workshops/eval-driven-agent-development READMEhttps://github.com/anthropics/cwc-workshops/tree/main/eval-driven-agent-development