干货
推荐人：，学习者
简介
关于这个agere, 它是一个开源的属于agent方面的轻量级的框架。这个框架的主要特点就在于通用性强, 而且具有完全的可定制性。它是通过把复杂的流程进行拆解, 拆分成一系列独立的、小的步骤, 以此来简化构建那种具有复杂逻辑的agent的一个流程的。
agere这个词来源于拉丁语, 它其实是agent的一个词源所在, 人们常常把它翻译为行动或者是做这么一个意思, 它具备着驱动以及推动某件事儿发生的意思。
agere没有第三方依赖，使用
pip install agere这样的话, 就可以很轻松地把它给装好, 并且在随后去运用它。
agere将Job设定为基本任务节点类型, 同时还使用另外一种未被指明的形式作为补充。具体的做法是定义一个名为Job的类, 然后再结合函数或者方法去展开操作。通过这样一套流程来拆解agent的不同组成部分。这类节点支持重复使用。等到将来需要修改功能或者扩展新功能的时候整体过程会变得更加轻松便捷。
在某个特定的工作程序里, 大家有能力去提交一个全新的任务, 或者也可以执行调用操作, 至于在这个被调用的过程里, 情况也同样如此, 它既可以再去调用其他的相关项目, 同时呢也没任何障碍可以去提交一个新的工作任务。
Job和都属于任务节点类型, 也就是我们说的作业类节点, 这些任务节点构成树状结构, 用它可以跟踪任务之间的关系, 和运行状态, 在这些节点中, 你可以为其添加在不同时刻执行的触发器操作, 例如在任务开始时, 结束时, 遇错时, 或者被终止时等。
agere并不将节点和边进行完全的分离处理, 它采取的是所谓的边节点模式。在原来的那种情况之中, 任务被拆分开来变成节点以及边这两样东西, 并且节点跟边它们是各自独立存在的。而在agere当中, 任务虽然也是被拆分成了节点和边这样的成分, 但为了做出区别, 大家就把这种形式给叫做边节点。
所谓边节点, 说白了就是带着边的节点, 每个节点还有它后面跟着的那个边都放在一起了。节点和边各自独立的优点是数据结构会更加清晰。使用边作为节点的好处在于逻辑连接更加连贯顺畅, 因为在定义一个具体的节点时, 你也就顺便明确了后续所要连接的边是什么样的。
这就避免了在去连接边的时候, 还需要再去思考这个节点具体是做什么用的情况。如果不这么做, 很可能人已经忘记了, 甚至可能连节点代码里写的什么内容也要重新去查阅一遍。
使用边节点这一模式, 会在参数传递方面带来另外一种不同的地方。在那个框架里, 你必需去构造状态变量, 这个状态变量就是上下文变量。你需要使得它与每一个节点都保持相容。这意味着你要确保每一个节点都能够从该变量里面取出合适的信息。同时还需要能够恰当地去改变这些信息。这种做法在实际上会形成一种负担。
在agere里面, 因为节点数据和边数据是被放在一块儿处理的, 所以这个操作过程就让传输参数的设置变得更为直接, 同时也提供了更高的灵活性。你可以在进行调用的时候, 根据实际需要去传递任何样子的参数内容, 完全不需要受那种统一规定的变量形式的束缚来执行这项工作。
这种处理方式的好处不仅体现在能够方便地传递参数上面, 还有就是在去实现那些带条件的边的时候, 整个流程也会变得更加简单, 并且更加直截了当。
agere这个工具确实是挺灵活的, 你要是觉得那种用节点和边的模式看起来更清晰一些的话, 那你完全可以采取这种做法, 具体做法, 就是你只要把那些定义为完全的节点给设置好, 让它们之间不要连接边就可以了, 然后, 你就可以非常简单地去自定义实现各种不同添加边的操作方式, 这些操作方式可以通过使用某些手段来实现的, 你还可以根据自己的需求去高度自定义你那个边的类型, 比如你可以定义像简单边这种类型, 或者是条件边这种类型。
但是当你使用node加edge模式的时候, 你可能需要考虑到应该如何去传递参数这个问题, 这一般来说是通过使用被共享的上下文变量这样的手段来实现的, 情况就像中那样。
在agere里面, 这也是有不止一种实现方法的存在的，例如说你是能够借着“祖先节点链”这样的方式, 去访问到那个被共享的上级节点的, 可以把它想成是顶级节点, 你在那样的节点上面设置被共享的参数，借由这样一种方式来把信息进行传递。
在进行流程构建的时候, agere与在如下几个方面会存在差异:
一心多用：agere可以多个任务同时并行
审时度势：可以通过控制任务的不同时刻的不同状态
当对节点里头的不同状态进行连接处理的时候, 就属于节外生枝的现象存在其中, 具体来说就是把边这个实体去连接到某个节点的开始状态上去, 或者是连接到它的结束状态上面去也行的, 再或者是干脆连接到一个所谓的终止状态的环节之中去都可以的。
这也就是所谓的量体裁衣, 指的是在各个节点进行参数传递的这个环节变得更加灵活了, 其核心表现就在于每一个单独的节点都可以针对自己的情况去定制化地传入相应的参数。
当然, 它是一个很优秀的框架。这个框架也有非常多的优点。我就不再多说什么了。
当你在用agere来构建一个agent的时候, 它并不会让你少写很多代码。因为agere并没有提供很多内建的具体功能, 所以它主要是一个用于流程驱动的工具。
agere在强调自己通用性的同时, 并不限制你去使用任何的工具, 同时也不依赖于任何特定的接口或者形式, 正因如此, 所以它也没办法去封装那些具体的功能。
这里存在着一些具体的逻辑, 需要你自己去书写它们。用比较直白的说法来讲, 这就是由你来自行完成调用这个过程。这确实是一件蛮有意思的事情。它之所以如此, 原因在于它并不依赖任何现成的工具。它同样也不依赖于特定的接口或者是某种固定的形式。
因为它不与任何已经存在的开发工具发生耦合关系。正因有了这样的特点, 所以才使得它能够去主动调用任意的一个工具。你可以选择直接去操作来触发它的功能。你也可以选用系统所提供的那些具有语义化特征的插件来达到同样的目的功能。
它的通用性非常强, 所以它很容易和其他工具做协同, 也容易实现集成。它不依赖于第三方的库, 也是从这个方面考虑的。现在的ai技术发展得非常快。我就遇到过这样的情况, 更新了一个新功能的时候, 那边的几个依赖库更新得不同步, 结果导致我这边新的功能即使已经写完了, 也没法使用。
另一个原因是, 每一个工具都不可能面面俱到。我没有必要非要在我这里写一个别的工具中已经有的并且可能还更好更成熟的功能。我能写的比它更好吗? 同样的呢, 像别的哪些库它提供了很多的功能, 可那些功能也不见得每一个都是最好的。
所以我才去选择了那种灵活的接口能力, 并没有必要把自己给局限在某一种框架或者是工具上。你喜欢用的哪个库, 亦或是哪一些功能, 你都可以去进行使用的情况下的话, 就是能够让它们能够去组合不同工具里边的最优秀的那个功能, 这是我内心当中是希望如此这样的。
agere中的基本概念
接下来我们使用下面所提及的这一张图片, 来对agere这个体系当中之所包含的一些最基本的概念, 做一个非常简要的方面的介绍说明工作。
这个任务节点, 就是上图里那个Job, 它们全部都属于说是节点这个东西。所谓节点的用处, 那就是去追踪各个不同任务节点之间的父子关系是怎么样的, 还有它们的完成状态是什么样子。每一个具体的节点, 它就肯定会有一个父节点存在, 同时它也可以拥有零个或者更多的子节点。
这些各式各样的节点就拼成了一个树状结构。然后我们借助这个所谓的节点树, 就能够跟踪任务与任务之间到底存在着什么样的相关联系。比如说能够搞清楚一个具体任务它是谁的子任务, 另外它自己又开启了哪些子任务之类的事情。
当一个节点所做的工作已经全部都做完了, 并且这个节点下面所有的子节点也都全部完成之后, 这个节点本身才会转换成完成的状态。在图里面用灰色来表示节点已经完成了工作。每当每一个节点完成自己的工作的时候, 他就会去通知自己的上级节点, 意思就是告诉对方说我目前已经完成任务了。
Job
Job这个对象, 它是打包了一个具体的任务, 还有执行该任务所需的那些资源的东西。
它这就像一个是在跟上级去汇报一样, 说自己有个什么什么样的工作要去做, 具体要去干这些这样的事情, 需要的给它的资料也提供给你了, 然后跟你说得已经很清楚了是吧, 把这个工作进行转交给你去处理了, 至于其他的那些东西我就完全不会再管了, 大概就是这么个意思。
它其实算是一个函数, 或者说方法, 长得特别像协程函数, 只不过它会吐出一个对象出来, 这个被吐出来的东西, 别的任务节点能拿去调用, 也能直接用await这东西去等它, 整个这回事儿给人的感觉, 就像是在跟自己手下的人交代工作一样, 意思就是: 我这里有个活儿, 你去帮我把这事儿给办咯。
这个家伙是那个专门负责自动安排任务以及执行具体任务的节点位置, 而且在通常情况下, 它会成为所有那些相关节点里面的根节点情况, 当你已经定义完成了一定的Job工作内容的时候, 就把最开始的那个入口性质的工作事务交给它来操作处理, 它接着就能够帮助你进行自动化的组织协调相关工作任务的工作流程以及具体的执行过程。
除此之外, 还存在着一个至关重要的方面, 这就是在节点所经历的各个不同状态下, 我们能够触发彼此相异的回调函数。
比如当咱们去为一个节点处理任务之际, 如果在初始开始执行的那个节点处, 或者到了最后结束的那个节点处, 又或是在遇到错误的那个节点处, 亦或是遭遇终止的那个节点处, 咱们完全具备为其增添各自对应回调函数的可能性。
示例
假如我们想要构建一个最常规使用的GPT模型, 并且让该模型具备工具调用能力, 以形成聊天代理, 另外, 在这个聊天代理中, 我们希望GPT能够在调用工具的同时发出消息, 因为目前GPT自身只能够选择向用户发送消息, 或者选择调用工具, 这两者是不能够同时进行的。
我们可以采取以下这种做法, 第一个是定义一个用于发起一个新的对话的Job, 第二个是定义一个用来接收由GPT所回复内容的Job, 第三个则是把解析GPT回复消息的Job, 以及把用于显示发给用户消息的Job, 还有把执行函数调用的Job放在一起, 另外我们再为添加一个新的Job来让它在结束阶段去发起下一轮的对话, 最后再选用一个Job专门用来进行它的具体执行。
关于这个 agent 的流程图, 情况如下所示:
下面是它的运行过程的演示动画：
当你阅读完这一段话之后, 相信你对这档内容已经形成了一个初步的认知与了解。假若你对此表现出了进一步的兴趣, 非常欢迎你前往如下这个位置进行更加详尽的查阅:
：
文档页：
如果你们觉得这样的情形还算不错的话, 那么欢迎大家直接加入到行动中来, 或者也请提出属于你们自己的比较有价值的看法还有建议。
