最近经常被读者问起：老于去哪了？

我，老于，一个自2015年MBA毕业后就从技术转为业务的BD，花了近六周的时间参与了由智谱牵头举办的黑客松：《第三届琶洲算法大赛-GLM法律行业大模型挑战赛道》。

经过艰苦的鏖战，老于最终从全国1388支参赛队伍中杀出，先以华北区第3名的成绩晋级复赛，再在强手如林的复赛中取得了全国第11名（B榜盲盒测试）的最终战绩。

虽未能PK过大厂（例如，腾讯）和名校（例如，清华），但老于的成绩也证明了，在大模型的依托下，普通人也可以在数周内构建不错的Agent。

关于比赛

本次比赛的主旨是在法律服务领域，基于智谱GLM-4大模型和相关业务API构建能回答法律问题的Agent，为法律人士提供专业的辅助咨询服务。

比赛涉及的法律问题或简或繁，简单问题只是查阅单表和数个字段，例如：

“广东鹏鼎律师事务所的电话邮箱地址分别是什么？”

而复杂问题则涉及跨多表查询、逻辑判断以及统计等操作，例如：

“(2020)吉0184民初5156号的被告是否为上市公司，如果是的话，他的股票代码和上市日期分别是？如果不是的话，统一社会信用代码是？该公司是否被限制高消费？如果是被限制高消费的涉案金额总额为？请保留一位小数点。”

从初赛到复赛，共四个轮次，每个轮次参赛队伍都要构建Agent以回答200道问题，最终正确率高者晋级。可以说整个比赛的设置非常接近于实战，且极富挑战性。

历经整个过程，对于如何构建更好的Agent，老于有八点心得。

八点心得

第一，API编排 vs Code/SQL生成。相较于Code/SQL的生成能力，企业客户会更看重Agent的API编排能力。在具备API资产的情况下，企业内和企业间的交流会更多地通过API，而非直写Code/SQL实现。而本次比赛的主要考量是Agent编排API回答自然语言问题的能力，也反映了大模型厂商对企业实际需求的理解。

图1：编排API回答自然语言问题

例如，在图1中，Agent需要能够编排并依次调用裁判文书信息、上市公司信息、企业工商注册信息和企业限高消费信息的API以回答较为复杂的问题。

第二，对Agent的要求是“又快又准”。比赛的盲盒测试要求Agent在1小时内回答200道问题，对Agent的运算速度和精度都有较高的要求。而这也与企业的实际场景契合，毕竟企业内绝大多数的信息检索场景相对简单（单表或有限多表/视图，有限的逻辑处理和统计需求），但对响应的速度和精度有近乎苛刻的要求。

第三，Plan ↑ Reflection↓。对速度和精度的高要求需要Agent能够在Plan阶段“一次搞定”，而非通过Reflection反复修正。为此，我们排除了Multi-Agents架构，而着重于保证Plan的准确性，并确保一旦Plan正确，Action必然正确（图2）：

图2: Agent的系统架构

为了达到上述目标，我们在架构中设计了两个环节：

1. Orchestration（编排），依据知识图谱，将自然语言问题编排为大模型友好的“指令序列”；

2. Question Rewrite（问题改写），“抹平”问题的缺陷，并依据知识图谱发现隐藏的实体关系。
   

最终，在所有正确回答的问题中，我们Agent的首轮正确率超过了90%。

第四，自然语言 -> API，NO！自然语言 -> 指令 -> API，YES！自然语言的复杂度和多样性降低了大模型Function Calling的精度，Agent需要将自然语言“格式化”为指令以提升API调用的准确性。例如，大模型可以将问题“广东鹏鼎律师事务所的电话邮箱地址分别是什么？”先转化为指令，再进行API调用（图3）：

图3: 自然语言问题->指令->API

相较于直接调用API，指令更具额外优势：

• API命名不可控，而指令的命名可以富含语义，有利于大模型进行问题分解；

• 简洁的指令消耗更少的Token，从而降低了大模型幻觉的几率，并且提升了Agent的响应速度；

• 指令和API的1:1对应关系能够确保“Plan正确，则Action正确”。

第五，自然语言问题是一个指令序列。正如图3所示，自然语言问题可以被大模型转化为一系列指令，即指令序列。如果我们用函数F(X)->Y代表指令，比赛中的问题则可以被描述为一个指令序列：

在比赛中，我们使用不同类型的指令构成指令序列（图4），指令间可以通过内存进行沟通。通过不断增加指令类型，Agent可以应对更复杂的问题。

图4: 指令类型

第六，大模型善于指令编排，前提是约束以知识图谱和Few-Shots。Plan的核心是编排指令，生成指令序列以回答问题。在比赛中，我们发现即便仅仅使用提示词工程，只要辅以正确的知识图谱和Few-Shots，大模型善于将问题编排为指令序列（图5）：

图5：基于知识图谱和Few-Shot的复杂指令编排

其中，知识图谱主要约束大模型的生成路径，而Few-Shots则提供了生成样式。同时，我们的Agent利用embedding search 针对不同类型问题动态加载Few-Shots，在节省Token的同时增加了指令序列生成的精度。鉴于指令和API的一一应对关系，指令的编排等同于API的编排。

第七，必要的问题改写。指令序列的生成和问题的问法息息相关，而Agent经常面临的挑战在于，问题未必会提到答案中所需的内容。这种情况下，Agent需要改写问题以“填坑”。类似于指令序列的生成，我们可以同样使用知识图谱和Few-Shots指导问题的改写。

而问题改写的另一好处就是能仰仗大模型“抹平”问题中的错误，例如，图7中，问题改写就修正了公司和字段名称重复的错误：

图7: 大模型的问题改写

第八，<SOS>/<EOS>提升Few-Shots的遵从性。使用Few-Shots 产生指令序列的挑战之一就是大模型的“不遵从”，包括：

• 格式上的不遵从，例如符号的错用；

• 内容上的不遵从，例如在指令序列之外增加无谓的解释和啰嗦的内容。

固然我们可以通过提示词要求大模型严格遵从输出要求，但更好的办法是使用<SOS>/<EOS>包裹Few-Shots以提升遵从性（图8）：

图8: 用SOS/EOS提升生成的遵从性

也许是因为大模型在训练之初就使用<SOS>/<EOS>标记训练数据的起终点，使用该标记后，99.99%的情况下，大模型能够遵从要求生成指令序列。