2024Q1对自主探索能力Agent设计的思考

本文写作于2024.3.10，由于时效性较强，如果您阅读时已经过了很久，请考虑在专栏中寻找该主题的最新文章。

0、前言

本文主要是讨论大家所期望的能够自主决策、有学习能力的Agent的策略架构的实现思路。本专栏之前有过在这方面讨论的文章：

目前我在这方面的思考已经与前文已经有了一些明显的不同。我尽量在本文内给读者一个完整的描述，不必依赖对于前文的阅读。不过前文中也有一些细节点的讨论仍然可以参考，有兴趣的读者可以去补。

（之前使用了序号进行标识，但我目前已经觉得这方面的认知是会不断变化的，过去的内容大概率会被未来推翻，序号没有意义，时间版本号才是有意义的。）

1、本文讨论的智能Agent的能力目标

现在挂名Agent的方案和框架已经太多，但距离人们期待的Agent的能力目标还有很大距离。本文试图讨论“下一代”Agent的策略架构设计，当然这仍然并非“全能Agent”。所以先在这里明确本文讨论的目标。

大家对Agent的期望能力的表述有不少方式，但我觉得很多表述都不够精确，或者说对于实践没有指导性。所以本文会从更加具体和有指导性的方式尝试定义Agent的能力。简单来说，本文目标的Agent能力分为以下三点：

• 【A】信息和经验的记忆能力

• 记忆成功的标准是能够在未来成功使用。

• 【B】面对新问题时的解决过程探索能力

• 【C*】从过去失败的经验中提升的能力

这其中【C】是比较难的，实际上如果有相对好的【A】和【B】能力就已经很有用了，所以对于该阶段的Agent来说，【C】是一种高阶的可选能力。

2、知识的分类 与 知识的表达方式

知识是一个相对模糊的描述，本文将其分为几类：信息性知识、经验性知识与预判模型。虽然它们的界限仍然模糊，至少能帮助一些思考，（而我目前也没有更准确的表达方式）。

信息性知识是相对容易处理的对象，能够相对直接的被原始LLM所处理，信息性知识的提取、记忆、召回等的实现相对容易，这条线的部分功能大致对应到目前的RAG方案上。（不过现有的RAG方案还没有能够完整地实现这方面的所有功能。）本文的写作目标并非讨论这条线，所以这里从略。

经验性知识则是对应于人或专家完成具体任务的知识，这里又可以模糊地分为成功经验和失败经验，为了简单起见以下主要以成功经验为主进行讨论，在下一节会对失败经验进行讨论。目前来看成功经验性知识在Agent系统中最好的表达方式是：workflow+workflow中的节点实现。

最后是预判模型，在Agent中对应于：对于没有成功经验的新问题中不同方案/路径的可行性的预判。对于人来说，这个预判模型包括直觉与严格或不严格的多步思考。

2.1、成功经验的具象化表达——workflow

对于经验在Agent中表达方式，一些读者可能有不同的选择，但我目前认为workflow是比较好的成功经验表达方式。

本文所讨论的workflow是指一个明确的计算图，并且其中所有的节点都是有明确定义并可（高概率）执行的。这里的workflow未必是一个线性流，可以是任意有向无环图或可执行程序的方式，也可以把一些其他workflow作为其中的子节点，这里的关键在于【明确可执行】。目前这方面的名字还没有达成普遍的共识，有些人可能会把这称为SOP或其他。

不“足够明确”的workflow可以作为Agent中经验的表达方式么？也许可以，但我目前没有看到好的处理这种不够明确的workflow的方式，导致这方面在落地上出现困难。以XAgent的双层循环为例，外层循环就可以看成是为用户任务生成了一个不足够明确的workflow，但这个workflow在每步执行的时候就会遇到很多问题。我也并不看好逐步细分的方式去执行这种模糊的workflow。当然并不是说不完整的分解就没有价值，但本文只是把明确定义的才叫做workflow。

需要强调的是，workflow上的节点也是至关重要的。打一个精确的比方：

• workflow流程界面和标准相当于Python语言的语法和基本类型定义

• 具体的workflow实例相当于解决具体问题的Python程序

• 原子节点是Python生态中的各种库提供的函数。

• workflow中应该尽量包含失败的应对，特别是外部专家输入的workflow。Agent内部生成的经过犯错迭代后的workflow最好也应该这样。这些失败的应对过程对应到python中的错误检查和处理分支。

有兴趣的读者可以沿此思考。

2.2、细化Agent的能力表述

经过以上的铺垫之后，对Agent能力描述进行细化：

• 【A】信息和经验的 记忆/明确表达 能力

• 【A.2.1】外部人工成功经验性知识的存储能力，和在明确指定下的执行能力。实现难度：中低。

• 【A.2.2】外部输入的经验性知识修改等明确要求的更新能力。实现难度：中低。

• 【A.1】信息性知识的处理、记忆、检索能力。实现难度：中低。

• 【A.2】外部经验的记忆能力

• 【A.3】成功经验性知识的（大概率）自动应用能力。实现难度：中。

• 【B】新问题解决方案的探索与学习能力

• 【B.2.1】探索过程中成功经验的存储能力。实现难度：低。

• 【B.2.2】在执行过程中能够利用过去经验归因到具体环节的失败（与成功）经验的能力。实现难度：中高。

• 【B.1.1】在可行执行空间中进行自主（树状）探索的能力。实现难度：中低。

• 【B.1.2】对于不完整的局面状态进行评估的能力，即 预判模型。实现难度：中高。

• 【B.1】新问题的探索能力

• 【B.2】过去经验的学习能力

• 【B.3】外部输入的不足够明确的经验性知识修改要求的更新能力。实现难度：中高。

• 【C*】从失败经验中获得提升的能力

• 【C.1】将失败原因归因到具体环节的能力，并能寻找潜在的更优方案。实现难度：高。

• 【C.2】失败经验的记忆能力，具体环节失败经验的记忆能力。实现难度：中。

以上的难度分级说明：

• 难度低：指目前能够【熟练】进行RAG类方案的【定制化调优】的团队的能力所相对熟悉的范围和相对容易（1人月内）能够完成的范围。

• 难度中低及以上：任君想象。

这里的【B】和【C】类能力的拆分方式并非唯一的，这里只是写了一种我目前认为更可能的方式。

2.3、经验表达的其他方式的可能性

经验的表达方式未必要用workflow，只要能够完成【A】【B】【C】中各个需求的实现方案对于经验的表达和记忆的需求都可以。这是一个很关键的基础设施，会影响到整个Agent策略的各个方面。

我目前也没有第二种答案，我也期待有不同想法的读者能够来与我交流。

2.4、关于workflow的执行

回顾前面的信息：

• workflow和其中的节点都是明确定义，（大概率）可执行的。

• workflow未必是线性的，一般情况下是一个有向无环的计算依赖图。

• workflow可以成为其他workflow中的节点，实现嵌套。

• workflow包括一定程度内的失败处理流程

一个简单的实现是把workflow当成DSL中的函数，在执行workflow中的子workflow时，就相当于进入了子函数。

但这里要提醒的是：这个单线程执行的约束是不必要的。每个workflow都应该被视为可以执行的单元，workflow之间只靠输入和输出消息进行通讯。当一个workflow依赖另一个workflow的输出时，它可以就在那里等待，也可以做更复杂的预测和投机执行等。从这个角度上来说，这个workflow有点类似于mini-agent。（事实上我也不喜欢Agent这个叫法，从实现的角度上来说一个Agent一般只是一组workflow的包装而已。但在这里可能更容易让读者理解我的意思）

允许workflow之间独立执行有几个优势：

• 可以解耦没有依赖的操作，实现并行，缩短整体的执行流程。

• 允许每个workflow进行流式的输入和输出，实现流式处理。

• （在允许子workflow可以使用多个输入启动多个session实例的情况下），可以配合预测式投机执行workflow实现以计算成本换执行时间缩短，追求极致的低延迟。

我建议不要设计长生命周期的workflow，每个子workflow session应该只完成一个子任务，子任务完成后就结束。其他同样的子任务应该启动新的子workflow session实例。

3、对新问题的自主探索能力

3.1、自主决策 与 RL（强化学习）

在算法方面有些视野的读者看了上一节【B】和【C】的分解就能发现这是RL的一种视角。但这些读者在此之前思考如何实现“自主决策”时，未必会觉得这个事跟RL有强关联，这也是目前整个社区没有达成共识的一点。而我目前对此的判断是，自主决策能力需要以一个RL的视角去设计，从多步任务的失败中学习的能力更是完全依赖RL的经验。

这里的RL视角并不是说套用某种具体的狭义RL算法，例如“以A*算法的思路来构建【B】能力”在我来看也算是按照RL的视角去实现。从简单如A*，到复杂如AlphaZero，能够迁移到该问题上的思路其实没有特别大的差异，对于不熟悉RL的同学可以从A*开始熟悉。

无论是人还是Agent，面对全新的场景时都需要某种探索过程。当整个Agent面对的任务涉及多段决策和延迟反馈时，就更加符合RL所设定的场景了。想要实现自主探索和决策、从失败经验中学习，在不了解RL已有工作的情况下就是闭门造车，RL在这方面已经有了不少思考可供借鉴。不要蒙眼从零思考轮子应该是什么形状，RL领域的答案已经放在那里了。

3.2、现有方案的评论

我在谈复杂Agent策略框架的设计（2） 中就已经提过，（截止到2023.12月）有一些知名度的Agent策略框架目前都没有成功率可接受的自主探索能力。

以本文的视角来说：

• 狭义的简单Multi Agent方案只能在一个讨论路径上进行探索，虽然它可以在整个探索空间上从一个路径跳到另一个路径上，但由于目前LLM对于超长上下文的处理能力孱弱，导致整体方案在复杂问题上的成功率并不好。而且由于整体是单线程的探索，速度也很慢。

• ToT、GoT、XoT等框架虽然看起来类似于树状探索的感觉，但目前都没有成功率可被接受的方案实现。基本还是在学术界的第一轮占坑阶段。

XoT其实已经是按照RL的思路设计的一种方案了，但我认为它做的很一般。读者在补充了RL的知识后，自己独立设计最适合自己场景的方案就好了。

3.3、暴力计算 + 缩减探索空间 + 复用历史成功经验

无论是对于人还是对于Agent，面对全新或者是部分新的问题，都需要不少的思考探索量。如我在 谈为什么效率场景LLM应用没有爆发 中所说的，这方面的起步价可能是至少100次的成功率96+%的LLM调用。我觉得：如果是对Agent全新的问题，别说100次，就是1000次可能都不嫌多。

当然这种暴力探索不是办法，人也是通过逐步分解问题来进行探索的，所以以一个层次化探索的方式来做是更好的。在这个过程中也需要尽量能够复用Agent经验库中可用的子workflow，缩减探索空间降低求解难度，并能够利用之前的成功经验以减少探索成本，这才是更可行的。只是稍微偏离已有经验场景的问题可以靠这种方式解决。

对于那种完全新的领域或复杂的新问题的场景，跟用AI辅助科学推理是类似的，也许正确的期待应该是：提交任务后跑几个小时甚至几天的准备，并且中间还要做一些支持人工观察和干预的UI设计。

无论是调用了0.1k次LLM还是10k次LLM，探索的成功经验都是很宝贵的。即使不考虑推理费用成本，用户肯定也不希望下次等待很长时间进行探索。已有探索的成功经验应该要被记忆下来并能够改善未来的请求。

从未来复用概率的角度来说，直接存储一个大的workflow被复用的价值一般是低于将其分解为多个子workflow和层次性调用它们的大workflow的。未来面对的问题的解决方案未必是与这次完全一致，但子问题的解决方案被服用的概率要大的多。

仅把之前的成功经验作为参考来执行的话，要做好随时可能脱离历史成功路径重新进入空白探索的准备。除此之外，分解到子workflow的另一个好处是降低了【C.1】的难度，即“如何把整体workflow或者整个业务session上的多段workflow的执行失败归因到具体环节”的难度。

3.4、预测模型

在上面探索中，如果完全没有对于可行方向的预判能力，则会陷入到连A*都不如的状态，要么类似于Dijkstra算法的广度优先，要么类似于随机深度探索。

但如何普适地开发一个较好的预测模型还缺乏最佳实践。

好在这方面的baseline方案并不难做，就是直接让LLM估计当前状态/方案与目标的关系就行。只是这个结果不太精确，但好过没有。

需要提醒的是，由于很多分支/方案的选择并非非黑即白的对错问题，而是一个不同分支/方案之间的成功概率比较问题。所以一般并不是仅仅记录失败记录，而是要综合记录每个分支/方案的成功概率或潜在收益。

4、从失败经验中获得提升的能力

一个容易被人忽视的问题是，失败经验的处理不能像成功经验那样可以“简单加入到待学习的数据中就行了”。因为LLM学习的数据默认都作为正样本，即希望模型的表现跟这些样本一样。让模型的表现更像错误的经验是南辕北辙。即使告诉模型不要这样，基于相关性学习的LLM也没有太多能直接给出更好方案的能力。

所以相对于成功经验的学习，失败经验的学习还需要：

• 从失败经验中发现大概率错误的环节，并在尽量未来避免它

• 能够回避错误环节的前提是能找到更好的方式

• 从过去的成功和失败的经验中学习到不同方案的成功率高低。

4.1、单次Agent执行用户请求的场景

单次用户请求中的失败可以分为2种情况：

• Agent从经验库中找到一个历史经验并进行执行，但过程中遇到workflow没有处理的失败情况。

• 由于没有匹配的历史经验，或者任务在workflow执行过程中出现新情况脱离workflow，或在workflow中遇到失败等导致进入新空间探索后，在探索过程中遇到的尝试失败情况。

前者是相对容易定位的，至少失败发生点是知道的。

而后者在探索过程中的失败有些可能是探索的某步本身生成的有问题，也可能是整个思路都有问题。

最好的方式是在这个探索过程中对这种探索失败的经验进行增量学习，并在继续的探索中优化预测模型。但目前一般人能想到的实现一般都不包含这点，这导致在巨大的全新的探索空间中可能会导致探索效率很低。但这种探索过程中的持续学习的能力也并不容易做。

4.2、业务Session中多轮Agent交互且延迟反馈的场景

可能不少读者不好想象什么样的场景才需要这种从失败中提升的能力，下面我举一个具体的场景：

考虑一个全自动销售Agent场景，潜在客户通过电话或者IM的方式与Agent进行沟通，销售Agent每步选择它认为最好的话术引导用户实现最终购买下单。在过程中Agent很难直接地知晓自己的每次回答是否是合适的，只有在最后才能得到用户是否下单的延迟反馈。这里Agent的每次对话生成都对应到上一节中的一次执行，所以这是一个跨越了多次Agent调用的场景。

然后问题来了：如何实现一个能够从过去失败历史中自我提升，优化话术和内部流程的销售Agent？

如果我们期望的是一个全自动的能够根据历史失败经验自动提升的Agent，那么它基本上需要某种RL类的方案来实现这种多步骤决策且延迟反馈场景的优化。而且很明显简单套用已有RL算法是不够的，或者说是极为低效的，应该结合语义信息来从失败经验的对话中进行分析来把失败可能性定位到更少的可疑环节上。毕竟如果不输入领域知识（人类的语义理解），RL算法的样本利用率低的可怜。

可能我们1年内还看不到能够可靠的解决这个问题的Agent策略方案。换句话说，业务上多步交互且延迟反馈场景上的失败经验自动学习的Agent以现在来看在1年内很难实验。1年之后需要再重新评估这个的可能性。商业决策上不要依赖这点。

但从这个实际场景上来说，我们还算有一些人机协作共同提升的方案，就是通过Agent帮助人大幅提升对于失败case的分析效率，人工定位到哪些潜在环节，并对这些环节进行尝试优化，结果就是新的workflow，然后投入到系统中与旧的workflow的效果进行AB实验来确认是否有提升。即使如此，这个系统的复杂度估计都让现在LLM应用层开发者听起来头大。

5、总结

5.1、非共识观点回顾

概括一下本文的几个非共识观点，供读者查漏补缺：

• 经验的表达方式是可执行的workflow，workflow的执行方式可以是独立的、流式输入输出的

• 新问题探索需要很大的计算量，探索架构要以RL的视角来设计。为了让尽量减少探索的计算量，需要认真设计子workflow和层次化的问题分解。挑战这条线的读者建议去熟悉RL。

• 从失败经验中自动学习很难，真的很难。挑战这条线的读者【应该】先修RL。

5.2、实现可能性展望

即使不包含【C】能力，大家期望的【A+B】能力目前都还没有普适且成功率可接受的方案。

我目前对具体的方案也没有很清晰的想象，但相对于2023.12时候的完全茫然，现在感觉至少已经有了一个很粗糙的形象。我在此时写作本文也是希望能够给大家同步这个阶段性的思考，推动社区能够更快的达到一个可用的方案。

我估计到2024年底，也许我们能够看到一个符合期望的方案，我目前感觉可能性是30-40%吧。

5.3、LLM能力提升有哪些影响

今年的LLM能力是会快速提升的。至少我觉得在可能在2024年底前发布GPT-5发布之前，LLM的更新更多在于提升单次LLM执行结果符合用户期望的符合期望率。

但在本文讨论的问题上似乎很难有期待，我们能期待LLM API供应商直接出一个高级API完成这个事情么？放眼全球所有的LLM API供应商（包括OpenAI），能推出的上层能力到现在也就是Assistant API而已。搞这个？想多了。先把我之前文章说的一些更容易的LLM API feature做了再说吧。

交流与合作

如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请私信联系，见 联系方式。

希望留言可以到知乎对应文章下留言。

本文于2024.3.10首发于微信公众号与知乎。

知乎链接 https://zhuanlan.zhihu.com/p/686241906