我们想和你一起，让 Agent 的优化有据可循

Before you disturb the system in any way, watch how it behaves.

观其行，究其理，而后改之。

------多内拉·梅多斯，《Dancing With Systems（与系统共舞）》 $1$

楔子

今天，我们会在"老纪的技术唠嗑局"里，开设一个新的系列专题，名字叫做 Data In The Loop。

这个系列专题，来自一个很实际的愿望：当你花时间调试一个 Agent，应该能够看清楚自己究竟改好了什么，也能够把这一次的经验带到下一次开发和优化里。

看到 Agent 自己查资料、调用工具、完成任务，很容易让人兴奋。但等它开始处理真实工作，我们又会多一份顾虑：这次的答案可靠吗？换个问法能让它做得更好吗？出了问题，有没有办法查清楚？

调试要花时间，运行要消耗资源，我们做这个系列，是想和大家把这些问题聊清楚：哪些记录值得看，怎样判断一次修改有没有帮助。希望你读完后能带走一种分析方法，然后回到手头的任务里去试上一试。

这个系列，会从观测和评测谈起，沿着开发、测试、部署和实际使用，讨论运行数据怎样帮助团队判断下一步应该进行哪些优化。同时，我们也在把这些想法做成工具，希望能够和大家一起使用。

欢迎大家关注 OceanBase 社区公众号"老纪的技术唠嗑局"。在这里，我们会持续为大家更新与 #AI 和 #Data 相关的技术内容~

先从 Agent 的一个错误的回答聊起

假设你在老板的指示下，折腾了几天，终于开发出了一个企业知识助手 Agent。

用户问它："最新版本的产品里，某个功能应该怎么配置？"

Agent 很快给出了步骤，还附上了资料链接。然后用户照着操作时，却发现配置不生效：因为引用的文档对应的是旧版本的产品。

你可以再加一句提示词，提醒它注意版本。可在动手提醒之前，你大概也想知道：Agent 究竟是压根没拿到新资料，还是拿到了却没选对？以及用户指定的版本，有没有真的保留在上下文里？

因为，不同的情况，会引导你对 Agent 做出不同的修改和优化。

观测的价值，在这个时刻就变得具体了。

你能沿着一次任务，查看工具原始返回了什么、模型实际收到了什么、哪些要求在传递过程中丢失了。 如果检索只返回旧资料，就应该先检查检索条件；如果新旧资料都在，就应该继续看上下文怎么组织。

开发者由此就会有一个可以验证的修改方向。业务同事也能参与：指出资料适用哪个版本，说明什么样的回答才可以交给用户。

开发者特别在意这种变化。面对 Agent 的一次失败，大家应该坐下来读同一份记录，先把问题说清楚，然后再决定下一步该怎么改。

在思考怎样理解和改进 Agent 时，我们参考了很多 LangChain $2$ 团队的讨论。

LangChain 提供 Agent 开发框架与观测评测工具，它的联合创始人 Harrison Chase 也写过一个名为 In the Loop 的专栏。在其中一篇讨论代码与运行轨迹关系的文章 $3$ 中，他提出了：代码帮助我们理解应用如何设计，轨迹则记录 Agent 在具体条件下做了什么。

这和刚才的排查思路是相通的：读过上下文的处理逻辑之后，我们还要沿着运行记录，检查资料是如何一步一步地被检索出和传到模型面前的。

为何把 "Data" 放在专题的名字里？

下次改提示词、换模型时，能不能直接复用这次排查留下的线索？

你刚刚排查完那个错误，知道了正确配置，也终于知道了问题可能出在哪一步。

如果这些信息只留在聊天记录和几张截图里，下次遇到相近的问题，仍然可能需要再次从头开始排查。

要留住这份经验，可以把问题对应的运行、当时使用的资料、业务同事的判断、具体改动和验证结果，放在同一个任务下面。

下一次改提示词时，你就有一个案例可以用于测试；换模型时，可以来测试旧问题有没有重现；新同事接手时，也能读到当初为什么需要这么改。

这就是我们想讨论的 Data In The Loop：让运行记录、评测结果和人的反馈，继续参与下一轮开发。

Agent 执行任务时，可能多次调用模型和工具。我们这里说的 Loop，关注的是团队怎样在一轮轮工作中改进它：从运行中找出问题，提出修改，用样本验证，再从真实使用中接收反馈。

这就需要把记录存下来、查得到，再把它与资料版本、反馈和验证结果关联起来。数据库的存储、查询和关联能力，可以帮助我们把调试经验带到后面的测试和协作里，让曾经花在排查上的时间，在以后继续派上用场。

让这一轮的经验，融入下一轮开发

要让运行中的经验持续帮助开发，我们还需要看清这些工作在整个流程中的位置。

LangChain 在讨论 Agent 的工程实践时，用 ADLC（Agent Development Lifecycle，智能体开发生命周期）来组织这个流程。在相关介绍 $4$ 中，它将流程概括为 Build、Test、Deploy、Monitor：构建、测试、部署和持续监测。测试从发布前就开始，实际使用带来的反馈再进入后续开发。