引言

使用LLM时，上下文始终是一个绕不过去的话题。上下文本质上来说可以看作是LLM的短期记忆，能够提供当前对话场景等关键信息。当然，与图灵机终究不可能有无限长的纸带一样，LLM也不可能保存无限长的上下文。虽然如今大多数LLM的上下文长度已经增长到了大多数人都够用的情况，但对于许多上下文高依赖的任务，例如小说续写、角色扮演对话、大型任务模拟(没错！说的就是你，游戏模拟)，还是远远不够的。

另外一个相对不那么重要(存疑)的一点就是，大多数API都是按照tokens计费的，因此携带大量上下文的对话也自然会对钱包的伤害更高了。

此时再考虑到上下文保存的对话格式实际上是不那么信息密集的数据格式，于是以此为着力点，我们在本文中探讨一下上下文压缩的可能性。

引言

本博客是上一期博客的续集，也是这一系列最重要的一部分。本文主要会介绍两个概念：格式化输出和链式提示，这两个技巧融合在一起将有非常强大的效果，原本难以约束的LLM也会在它们的指引下如训练有素的军队一般能轻松应对任何实际场景。

不过也有一点遗憾：这一期的概念解释起来非常简单，但真正要在代码中实现却很复杂。我本来想在APaI中实现格式化输出与链式提示功能，但随即就很快意识到这样做的改动不止一星半点，加上时间有限，所以暂时只能先在这篇博客上"纸上谈兵"了。

另外再次声明，我所写下的这些大多数都是我自己偶然间获得的灵感，在先前我并没有查阅太多相关的资料，也不确定是否有人已有了这一方面的研究与成果，而我写下的这些又是否是在"误人子弟"。因此最好带有批判性地来阅读，能让读者产生自己的启发自然最好，嗯。

引言

最近关于大语言模型(LLM)有了一些灵感，于是写成此博客，预计会是一个包含三篇文章的系列。

最近越发开始依赖LLM，现在想来真是有些后怕。当然使用LLM的过程中也难免会有令自己不满意的时候，此时往往还需要自己动手调整。比方说先前为了能在命令行便捷清爽地调用API而二次重构的APaI项目，或者就只好自己反复实验找出更优的提示词(Prompt)。

此时就不得不提到最近新兴的一个研究方向：提示工程(Prompt Engineering)，主要关注于提示词开发与优化。这里推荐一个介绍提示工程的网站提示工程指南 | Prompt Engineering Guide，虽说我也只是在写这篇博客时才读了一部分，但依旧觉得受益匪浅，尤其是对抗性提示一节。

而这篇博客主要介绍的是提示工程中让我相见恨晚的元提示词(Meta Prompt)。

很快啊，在经历了短短的……（看一眼日期）短短的五天之后，我们的第三篇开发日志就出来了。当然啦，坏消息是这学期的大项目竟然来得这么早，另外就是这周一直高强度存疑地搞这个项目实在是有些腻了，毕竟咱还有许多堆积的其他事情要做，因此之后的更新速度可能会放慢一些。

闲话少叙，本次的主题也已经在标题上展示出来了——日程，主要的作用就是设定智能体一些比较规律的行为，例如工作睡觉等等。虽然智能体完全可以只参照自己当前的状态选择应该做什么，但一些合理的指引是必要的，除了能增强真实性外，也能给每个角色以独有的特点。

当然，可以看到一直到现在我们都只是在捣鼓一些“配件”，到时候这个小镇到底能不能运行起来，以及其中的智能体到底够不够智能，还是有待观察的。之后一期日志会实现活动，再下一期应该就要开始正式的模拟了，不然感觉现在做的这些都有些虚→_→

幸运的是，学期刚开始的我似乎是干劲十足（其实主要是因为无事可做），于是Rusty Town的第二篇开发日志也很快写了出来，本次日志主要实现了Character类，即角色部分，以及角色间人际关系的实现。完成这两个部分后，我们将得以获取并修改角色状态，以及维持一个不断变动的人际关系表来影响角色可能做出的决策。当然，只实现这两个部分是远远不够的，毕竟Character也即智能体在这个项目中始终处于核心地位，而另外的部分也将会在之后的日志中逐渐完善。

话不多说，我们直接开始(。・ω・。)