“我们有哪些交易对手？”

核对完快速体验准备的演示数据后，我把上一篇结尾留下的问题，直接发进了 fx-agent 的对话里。它是个数字分身助手，这次由它连接 Fusion2，查询其中的交易对手记录。

上一篇，我是一个页面一个页面翻着核对的。这次，我想从对话里拿到那份名单。

先问：把业务问题直接交给它

这次，我想查的是当前系统里的交易对手名单。

我没有在问题后面补接口名称，没有写数据库语句，也没有附上技术命令。发出去的，就是开头那句业务问题。

它返回了 12 家交易对手，同时提醒我：这些是快速体验准备的演示数据，不是真实业务中的对手名单。

我问的是“有哪些”，它给出了名单，也交代了这份名单的性质。这次经历发生在测试环境，返回的正是供快速体验使用的记录。

到这里，我已经拿到了要查的内容。但我又打开了这次查询的执行轨迹，回看它做过什么。

再看：名单之前，有一段查询过程

我以为它只管给答案。实际是，它先告诉我这个答案是什么性质——演示数据；执行轨迹又让我看见，这个答案是怎么来的。

轨迹中，它先查看当前有哪些技能，再阅读交易对手查询相关的技能说明。这些说明是它执行这类任务时参考的操作说明。

随后，它通过后端只读查询通道向 Fusion2 获取数据，再把查询结果整理成回答。这次读取的是已有记录，没有提交创建或修改动作。

这几项动作连起来，回答的来源就具体了：名单背后，有一次向 Fusion2 发起的实际查询。

我提问时没有交代技术步骤，回看时却能看到它为这次查询做过的动作。从查看技能、阅读说明，到获取数据、整理回答，这条轨迹把提问和结果连了起来。

这次体验涉及的 ETRM 体系中，Fusion2 和 Xray 相互关联，但本次交易对手查询的实际取数对象是 Fusion2。轨迹让我把答案的来源落到了具体系统上。

不过，看到了查询过程，还要回到系统记录，核对返回的名单。

再查：把回答与系统记录对上

接着，我把回答中的名单与 Fusion2 中的记录作了核对。

系统中对应的演示名单也是 12 家，回答里的名单与系统记录对应。这次核对同时对上了数量和记录内容。

这与上一篇做的事有一点区别。上一篇，我核对的是快速体验究竟准备了什么；这一篇，我核对的是对话返回的答案，是否对应系统里已有的记录。

所以，这次拿到回答后，我能确认的内容很具体：返回了哪些交易对手，数量是否与系统记录一致，以及这些记录属于演示数据，还是实际业务数据。

执行轨迹和系统记录各自补上了一部分信息。轨迹让我看到它向哪里查询、做了哪些动作；系统记录让我核对实际返回的内容。回答中的提醒，则明确了这份名单的演示性质。

我最初只是想把上一篇翻过的名单问出来。到这一步，我拿到了结果，也找到了核对这份结果的依据。

最后：这次问题有了答案

这次，我在对话里提出问题，它完成查询并整理了名单。我还能回看执行轨迹，并确认回答与 Fusion2 中的演示记录对应。

我看到的是：这次回答有实际查询作为依据，名单和数量都与系统记录对上了，数据的性质也在回答中说清了。

查询是在读取已有数据。下一篇，我想单独试试：如果要创建一个自己的测试业务对象，又会经历什么过程？