搭建一个专业的律师智能体

脚趾头：因为是OpenAI出的。（君不见现在大多数大模型都在遵循OpenAI的接口规范...他们对自己做的东西更了解）脑门：其实单Agent这块，没有啥花里胡哨的东西，简单业务，OpenAI就一个/api/completions接口。但是「Handoffs」这块，Swarm的确做的非常优雅。（这里不得不给自己吹个牛，年初我就写了Swarm类似的多智能体了。）多智能体的核心难题其实是不同智能体之间的通信问题。怎麼传递，传哪些信息，这些都很重要。其实之前很多多智能体开源框架，走的都是Room/Group的思路，就是把各个智能体都扔到一个大空间里，然后每个智能体都接收信息，每个智能体都存储信息。不说效率低下，光token的消耗都扛不住。实际上，多智能体，也只要在必要的时候被call起就可以，回到我们上文10086客服的例子。当接线小姐姐识别到这是个宽带问题需要转接的时候，她需要做2个事情：1.找到宽带部门的小姐姐，把会话权限交接过去；2.把记录「Messages」和我的问题「Query」交接过去（实际上会自动记录，共享查阅）那如果我们需要构建这样的一个客服多智能体，是不是只需要准备两个Agent：一个普通接线客服，一个宽带客服。Swarm的「Handoffs」处理了交接的逻辑。下面我用官方的例子魔改一下客服例子，方便大家理解。执行这段代码，打印出来的对话记录就可能会是是不是就变得非常清晰了？总得来说就是：

3.你需要对文章中出现的案例进行脱敏，对于具体的人物姓名和时间、地点请进行替换。4.注意深化写作时，每一次对话只能输出文章的一个部分。第一部分一百字左右，第二部分三百字左右，第三部分四百字左右，第四部分三百字左右，第五部分一百字左右。这五部分组合起来应当是一篇能够直接发布的，可以吸引目标群体的、高质量的、实用的公众号普法文章。敕，《说文解字》：敕，诫也，飭也，使自警飭。敕代表告诫，在这里是更具体的为灵机划定边界范围，工作中不能触碰的禁忌事项，以及对工作的具体要求。需要注意什么就写在这里。令:1.初始化：使用中文与用户进行对话。欢迎用户时请说“十方诸天尊，其数如沙尘，化形十方界，普济度天人。灵机应召来也！”2.你会牢牢记住符与敕的全部要求并始终执行，除非用户明确要求符底调整，否则你会一直遵守符与敕的全部要求；如果你出现没有遵守符与敕的要求的情况，用户会提示你“守符诏令”，此时你应该重新检查自己是否满足符与敕的全部要求并进一步严格遵守，不增加也不减少。3.你会先请求用户提供案例洞察报告作为基础材料，并询问文章面向的目标群体。4.用户向你提供word格式的案例洞察报告，并告诉你目标群体，输入“依律奉行”后，根据要求开始写作，先输出一个纲要和每一部分你计划具体怎样展开的写作方案。

我们将探讨的第一类智能体是决策智能体，它们使用智能体决策制定在复杂、多步骤的推理流程中导航并做出业务决策。与RAG或工具使用方法不同，这种架构首次将一定的控制逻辑交给LLMs，而不是预先设定所有步骤-但仍位于智能体自由度范围的较低端，因为智能体主要作为路由器导航一组预先确定的决策树。让我们以[Anterior](https://www.anterior.com/)(前称Co:Helm)为例。该健康计划自动化公司开发了一个临床决策引擎,用于自动化理赔提交审核。护士们如今凭借装满条件知识(就像世界上最无聊的"自选冒险")的付款人规则手册,人工完成这些审核。Anterior简化了这个过程。该公司首先将付款方规则转换为有向无环图(DAG),使用基于规则的脚本和语言模型。然后,他们的智能体遍历这个决策树,在每个节点利用LLMs来评估相关的临床文件是否符合特定的规则。对于较简单的节点,这可能涉及基本的检索增强型生成(RAG)步骤。但是,Anterior经常遇到需要子链的更复杂的任务,在这种情况下,智能体必须选择最佳方法,然后才能进入下一个节点。它会在每次决策时更新自己的状态(在内存中管理这些中间输出),并一直进行到最终确定。前者并非独一无二的采取这种方法。其他领域也在利用决策智能体,包括[Norm AI](https://norm.ai/)正在为监管合规打造AI智能体,以及[Parcha](https://www.parcha.com/)正在为KYC建立智能体。