【强烈推荐】AI智能体构建新思维：以业务价值为导向，实现自我优化闭环

原创于 2025-10-09 11:51:01 发布 · 641 阅读

CC 4.0 BY-SA版权

文章标签：

刚开始的时候，我们总是热衷于讨论和思考AI智能体如何构建，围绕这一目标进行设计思路和技术框架的选型，然后不断迭代打磨功能和性能。这，很重要，却不是唯一值得做的事情。于是，有人会说，找场景。嗯，这也的确很重要，场景落地代表的是AI智能体有用，不是技术的玩偶。

那么，我们再来思考两个问题：

AI智能体的最终用户，是谁？

他们是一群热衷于技术的人么？不全是，或者说，大部分都不是。他们需要这样的若干个工具来协助他们解决一些他们认为的复杂问题，可以不关注过程，但求结果符合预期。曾经遇到个坦诚的业务部门人员，“我们并不关心背后有多少个系统，但是你能告诉我这样做能对业务带来什么效果提升么”。

在这里插入图片描述

AI智能体的业务场景，是被创造的还是被发现的？

显然，大多数的业务场景都是本来就存在的，不是因为有了AI智能体而被创造的。所以，业务的本质和规则，并没有发生变化。只是我们多了一种新的技术实现手段，可以由点到线到面的来解决一些之前解决的不大好的问题，在原本已经遇到了效果天花板的地方找寻一些新的突破契机。

所以，更需要做的是，在可量化的评判AI智能体对业务本身带来的效果提升的同时，再让它具备自我优化的能力。为什么强调了自有优化，因为我真的很懒，并不想花大量时间去调优一个系统。所以，最好是它能自己玩一会儿。

因为，只有让真正的多数用户，业务型的人员感受到了这样做，对业务带来的价值，才能让用户愿意和AI智能体一起结伴前行，相互成就。没有用户深度参与的AI智能体，不是好AI智能体。

嗯，方向有了，接下来就是定目标了。为AI智能体的效果提升之路确定：

前进的目标

量化指标为尺提升业务效果。业务指标为主，技术指标为辅；客观指标为主，主观指标为辅。

前进的能力

以自动化为基础，尽可能减少人工参与的复杂度，构建起一个自我优化的循环体系。

先说目标，是为了提升业务效果。那么，自然是去问业务的，因为业务场景是一直都在那儿的。我们如今需要证明的是用了AI智能体能提升原本业务的效果。所以，原来的那些业务指标，依然有效。如果业务效果目标，达成了，自然是不用第一时间再去关注技术指标，从业务视角看是没有需要了。嗯，是的，我们通常容易在这里遇到的问题。如果是由人来完成业务效果提升的时候，大家对提升的度总是相对宽容。一旦转换成是通过AI智能体来提升时，自然而然的就对提升的度产生了更大的期待。我想，我们还是可以对AI智能体产生的效果再宽容一些，让它有更多的效果爬坡时间。另外，尽可能多的用客观指标，减少主观判断带来的影响。技术指标，它的意义，更多的还是在业务指标不能达成的时候，用于指引我们定位到能快速提升效果的资源项。除了智能体本身的一些常用指标项，还需要关注构建智能体的各项资源的指标，比如模型、知识库、工具、提示词、工作流和思维链。工具调用和提示词的优化，通常会被优先尝试；模型和知识库的瓶颈是被提到最多的，但其实花费的时间成本相比之下会高的多。

再说能力，构建起一个可以闭环驱动的自动化过程，用于发现“问题”、诊断“问题”、解决“问题”。之所以加引号，是因为我从不觉得，那是问题，其实都是效果优化路上的一个阶梯。明天比今天更好，今天就是问题么，当然不是。

如何发现

先让数据跑起来，再应采尽采的归集数据。然后经过指标计算，对各项指标进行评分量化，形成评价报告，方便进行评估。在这里，我倒是不纠结指标的数量和质量的，先转起来才更重要。而且，之前也提到了，更有意义的业务指标是原先就存在的，并不是因为有了智能体才被创造的。其余的，更精细的指标，留在效果优化的路上吧。面对着大量的明细数据的时候，数据特征会指引我们的。

如何诊断

评价报告有了，再结合我们的效果优化目标，自然可以找出偏离项。哦，当然，在这之前还得确定我们定义的目标没有那么的天马行空。把问题范围收窄到偏离度最大的几个指标项上，也就自然的找到了偏离对象，通常这个阶段已经能定位到了构建智能体的资源项的级别了。然后就是程序员们擅长的领域了，谁家的程序员还不会找问题了，如果真的有，就请出我们的专业测试团队。

问题分类上，我习惯分两类：数据类问题和功能类问题。

数据类问题：包括上下文的质量和知识库的知识质量。上下文和知识的情况类似，他们必然是下一个步骤的输入，输入歪了，输出自然也歪了。当然，这里是指的作为输入的上下文和知识没有经过别的二次加工。好的数据质量，可以极大地降低程序逻辑和算法的复杂度。当然，就是因为原始的数据质量不理想，技术才更体现价值。

功能类问题：指的是智能体运行过程中用到的各个资源项的功能好坏，例如输出的准确性、执行耗时等。特别提一下工具API的问题，在传统的应用体系里，上下游系统对接口，其实都是交给各自的程序员在开发过程中调试对齐的，所以是人来基本保障了工具接口的选择的合理性、输入的完整性和正确性、输出的正确获取。所以，程序员容忍和磨平了工具API的方法命名、输入输出命名的可读性之类的问题。而当我们把工具选择和调用，交给智能体之后，我们就不得不考虑大模型的语义理解能力和习惯了。因为，此处无人参与。模型、RAG、提示词这些项，可优化的空间现在应该已经不大了，能做的也已经被挖掘的差不多了。

如何解决

只要问题定义得足够清楚，问题的解决向来是水到渠成的。只是说，哪些问题是最需要被先解决的。结合预期目标来看，部分问题解决后，可能我已经达成了本轮的预期目标了，那么自然可以先放一放。其他问题的优化，那是下一个目标的事情了。而怎么判定问题得到了解决，在诊断结论和建议的指引下对智能体做出相应优化，再借助仿真回测的模拟验证和评价体系再次评分。

有目标、有能力、有体系，让AI智能体自己对自己进行效果优化升级。在自动化条件还不够成熟的环节，交给人工协同。跟随技术更新，逐步减少人工参与。

最后，我们去相信，AI智能体的落地效果还变得很好。

在这里插入图片描述