课程章节介绍
同学们，我们这节课来讲测试你的智能体。
好，在完成所有的设置之后，你肯定想看看，它到底能不能运行，对吧？所以这一步叫做测试你的代理。
具体怎么做呢？很简单。你可以找到界面上那个预览按钮，点一下。有的时候可能需要刷新一下。然后，在你和代理对话的那个文本框里，输入一个带有新产品名称的提示。
还记得吗？举个例子，你可以问它：“告诉我有关Iron Grip Rescue Fuel的信息”。
这时候，关键点来了。你期望看到什么？你的代理不应该愣住，也不应该去网上瞎找。它应该回复你在知识库里准备好的，关于那个旧产品——也就是“手部和角质层护理油”的信息。
你为什么会这么自信？因为我们在创建指示里做了转换，这是它应该完成的逻辑，把新名字映射到我们已有的旧知识上。
那么，怎么确保它真的懂了，而且没有浪费资源呢？你可以在交互摘要里验证一下。去仔细看看执行过程，你会发现那个关键的 GetNewProductName 操作，在整个对话流程中，只运行了一次。这就对了，非常高效。
这个小小的测试范例，其实向我们展示了几种非常关键的代理脚本设计模式。大家一定要记住：
第一种模式，叫做“在推理之前获取数据”。你看，代理在张嘴回答你之前，它先悄悄地跑去查了一下这个产品的新名字到底是什么，对吧？拿到准确事实，再说话。
第二种模式，是“使用条件，让操作只运行一次”。通过条件判断，我们确保了翻译这步工作只做一次，而不是一个提问里面反复查询，避免了重复操作。
第三种，是“高效地使用带有默认值的变量”。万一查询失败，或者新名字为空，怎么办？我们有兜底的默认值，这就保证了程序的健壮性。
最后一种，也是常被忽略的一种，就是“用已知的失败案例去验证”。我们故意用一个新的、大模型不知道的名字去测试，就是要确保你的解决方案是真的在起作用，而不仅仅是因为大语言模型凭借着它的公共知识猜到了答案。你得证明，是你的逻辑链条在驱动它，而不是外面的通用知识。
好了，同学们，记住这几种模式，以后你们设计任何复杂的代理时，一定会用到。我们接着看下一个部分。