还在凭感觉调Agent提示词？Anthropic把它变成了可评分实验
还在凭感觉调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/trending - Anthropic GitHub Organization: cwc-workshops
https://github.com/anthropics/cwc-workshops - cwc-workshops/eval-driven-agent-development README
https://github.com/anthropics/cwc-workshops/tree/main/eval-driven-agent-development