Alife 技术概述（黑红剧本）

• 标题：Deepseek harness 吹的这套，我的小桌宠早就有了
• 封面：全插件框架 + 完整上下文 + 创造模式，但不是 Deepseek harness（图标），而是 Alife（图标）

开头

Deepseek harness 很牛逼啊，看到很多媒体都在夸，说是上限最高最革命性的 AI Agent。我看的也是特别激动，但不是激动他，而是我发现他和我自己的桌宠 Agent 有着很多极其相似的设计理念，这些功能甚至成了他放在主页上的卖点。但是他是功成名就的 Deepseek 官方出品 Agent，而我的只是一个默默无闻的个人小桌宠，这种感受大伙能懂吗？

所以今天我也想宣传宣传我的桌宠 Agent 框架。真的不是吹牛逼，这些设计方向本身也是我非常想要的功能，Deepseek 这波真的非常对我胃口，实际上做这些之前，我本身也很惊讶，为什么这些显而易见的功能居然没有人去做？这也是为什么，我做了自己的桌宠 Agent。

我准备从与 Deepseek harness 的共同点和作为桌宠方向的特化点，两个方向来介绍一下我的 Agent。我也会向大家介绍这些设计点的原因和优势，看完这期视频，你甚至可以开始手炉自己的桌宠 Agent 了，因为你要踩的坑我都帮你踩完了。

共同点

让我们看看 Deepseek harness 宣传什么？

{打开网页 https://www.deepseek.com/harness/en/}

1. Everything is a plugin：万物皆框架
2. Every run is traceable：一切有迹可循
3. Multiple runtime modes：丰富运行模式（这里面其他模式其实没啥，最关键的是多了个创造模式）

那么现在来看看我的桌宠框架，真的，全都撞上了。

万物皆框架

{浏览Alife.Client项目}

首先是全插件框架，Alife 也是一样的，框架内核只有基本的 llm 运行环境。

{浏览Alife.Demo项目}

这些是我平时做黑盒交互测试的项目，看看这些 Demo 项目，所有功能都是可插拔自由组装的，而且这还额外暴露一件事，就是 Alife 的内核和UI外壳是分离的，因此我很容易的就可以实现其 cli、gui、mcp 三个交互版本，这也为第三条铺了路。

{打开Alife角色界面}

而且 Alife 的全插件框架更加彻底，Deepseek Harness 中还在将工具作为插件框架的一部分，但 Alife 中连函数调用都是可以自定义。实际上 Alife 框架中与业务逻辑相关的只有最根本的两个操作：文本的收和发。

一切有迹可循

接着是一切有迹可循，实际上就是完全暴露上下文和函数执行过程。

{切换到角色完整背景界面}

看看这个完整背景，所有的人设、提示词、记忆、聊天记录都存在这了，你可以非常清楚的看到所有文本传输内容，并且实时编辑他们。

{切换到对话看板界面}

接着是来看看执行过程，我特意没有使用常规 AIAgent 框架，就为了方便完全的暴露和控制执行过程。

{让 AI 演示通过 alife-mcp 创建角色并与之对话}

创造模式

接着我们来看看创造模式，实际上刚刚已经演示了其中的一部分功能，就是 Alife 已经实现了通过对外暴露的 MCP 完全控制自身的功能。这个 MCP 在 Alife 内也是完全可以使用的，刚刚他就是通过这个 MCP 创建了新角色并与之对话。而这也不过是他的功能之一。

{展示插件市场和插件环境页面}

Alife 通过专门设计的插件框架，支持完全的热编译热重载，以及错误隔离，这意味 AI 一边运行一边改造自己，成为了一种真实能力。

{让 AI 写一个简单投骰子功能}

这个案例不过是框架简单功能的一种运用。由于是全插件框架，因此插件本身对框架干涉的能力非常强大，过滤对话、替换功能、干涉上下文，一切都可以，因为各种官方功能也都是用插件实现的。

总结

回过头再看这三点，实际上这并不是什么特别设计的框架，而是为了满足软件设计模式，最终一定导向的结果：模块化使得软件走向全插件框架，全插件框架意味着内核本身要暴露足够多的接口，于是上下文和执行过程被完全监管；插件成了功能开发重心，为了加快开发速度，自然会产出插件开发文档以及一系列热重载异常隔离等功能，于是创造模式成了顺手的事；功能全成了插件，但正常的业务流程还得跑，但因为都是插件又不能写死，于是依赖注入就成了必选项（这点没有写在首页，但 Deepseek Harness 和 Alife 都是利用这种机制来串联功能的）

说句有点嚣张的话：为什么 Alife 和 Deepseek Harness 为什么会如此相似？不是因为借鉴、蹭热度，而是因为强的本就千篇一律。

但换句话说，正因如此，这种框架设计真的不难，但确实又没人做就是了。想想面试的时候，真的大把计算机专业的学生不懂设计模式，哪怕会死记硬背，也不会灵活运用。每每这种时候我就更加好奇，大厂里那些上班的人们，究竟是啥样的。

特化点

说完了共同点，我在给大伙介绍一下，Alife 框架针对桌宠需求又做了哪些功能特化：

• 稳定长期记忆
• 全能场景适配
• 低廉使用开销
• 实时交互策略

稳定长期记忆

在无限的上下文输入中，保持稳定记忆与低廉的开销。

编程办公 Agent 不需要考虑长期使用的问题，都是一个窗口专注于一个短期任务，而且使用偏商务，也不用太在意花销问题。但桌宠 Agent 不一样，桌宠 Agent 需要考虑常年累月，挂机上好几年的情况，而且用户大多都是普通学生党，没什么收入来源。为此 Alife 做了哪些呢？

记忆策略

先和大家补充一下关于缓存命中的知识，你每次给 AI 发消息，发的那次都是非缓存命中的，所以发消息的内容越多缓存命中越低。而缓存命中则是，你或AI的消息发出后保存在上下文中的次数，所以复用大量上下文的情况下，再进行小而高频的交互（很类似桌宠的交互模式），命中率就会非常高，而缓存命中是非常省钱的。但反过来说，如果上下文中，有一个字变动，那么那条消息和后面的所有消息，全部都会被认为是新发的消息，无法触发命中，而产生大量的未命中缓存输入，这个就非常贵了。

然后让我们看看现有的记忆系统：

1. 最基础的记忆方式是上下文快满时进行总结压缩。

   这个是很多编程 Agent 在用的，但这种信息损失特别大，也完全无法进行积累记忆。都不能称之为长期记忆系统，但这种对上下文完全无干扰，这也是为什么编程 Agent 通常命中率都超高的原因，因为对话时基本没输入，全是输出和老上下文，非常省钱。

2. 主流的记忆系统通常是使用一个专门的记忆 Agent，定期对对话内容进行摘要存储，然后在对话开始或期间通过向量搜索或二次判断来随机召回存储的记忆。

   这种是很多陪伴向 Agent 在用的。实现起来非常复杂，但看着牛逼实际效果非常差而且贵。首先单独的记忆 Agent 意味着需要双倍的token开销，其次实时召回记忆意味着输入内容变多，未命中缓存率增高，而且召回的记忆质量也很差。

   首先负责摘要的 Agent 就很不靠谱，分不清重点，记录又有误差，接着向量搜索听着很美好，但实测就会发现和二游抽卡没多大区别，纯纯随机找话题。而且这种记忆系统依旧阻挡不了上下文的增长，等上下文要满的时候咋办？重新开启新会话，对话内容瞬间重置，没有连贯性，而且所有工具提示词等又得重新注入，又是一笔巨大的token开销。纯纯陷阱。

而 Alife 则采用了一套全新的长期记忆策略：动态上下文，分级压缩，索引存储，当事人记忆。（事后我调查发现，这套实际上和 Claude 的记忆系统有很多相似点，足以证明其真的的很好用）

记忆存储方式

1. 向量存储不好用，直接去掉，就存摘要。（实际上 Alife 还是会存向量，但真的图一乐，属于当初被骗了）
2. 记忆 Agent 不好用，去掉，直接当事人压缩。
3. 记忆残缺、召回不好用，那直接把记忆全存上下文里。

从最简单的角度来理解，实际上就是将所有东西都存在上下文，这样不就是真正的稳定记忆了吗。

但是这可能吗，有限的上下文怎么能容纳无限的输入呢？那我要问问你了，凭什么你那16G内存条可以运行上百G的游戏的呢？所以存储这件事，操作系统早就已经告诉我们怎么做了。

存储虚拟页表（用摘要索引代替完整内容），用多级存储结构按需存储，实现小内存读写大磁盘。

{展示完整背景的记忆分级结构}

记忆压缩方式

接着谈谈压缩方式，简单来说就是总结概要，但光这个也有些使用窍门：

• 当事人压缩：

总结内容就得获知原始内容，但为什么要交给一个外人呢？外人没有上下文，大量的原始内容输入非常烧token，而且外人没有人设，根本理解不了当事人的内心想法，这很蠢这种方法。直接让当前对话的 AI 自我总结不好吗？最懂自己的肯定是自己啊，而且复用上下文，完全没有额外 token 开销。

（写文的时候我忽然想到，可能不是哪些记忆系统不想做，而是框架本身让他们根本没有修改上下文的能力，被迫只能从对话观众的角度去处理记忆。只能说全插件框架还是太先进了）

• 结构化压缩：

如果直接让 AI 总结内容，他大概率写小作文，而且分不清主次，所以压缩提示词要特别写。但也不要写太多，因为记忆压缩频率高，提示词太多会严重降低缓存命中。那么记忆的压缩的关键点是什么？其实就是“结构化”三个字，这样ai自然就会将文本量精简，而且有条理的挨个列出每个内容，这是非常适合作为记忆摘要的文本格式。

动态上下文管理

为了实现 Alife 特殊的分级记忆存储方式，就需要实现动态上下文管理：

Alife 永远复用同一个上下文，并将其分区为：

• 提示词区
• 记忆区
• 对话区

提示词区域基本可以认为是永远不变的，由于 Alife 根本不会重开会话，所以提示词只需注入一次，没有 token 浪费。（而且事实上，llm 的系统提示词只能放在开头设置，后面设置是不生效的，此外还有动态提示词功能，这个后面说）

记忆区就是用于实现分级记忆存档的地方，Alife 只在上下文中存储原始内容的摘要和索引（AI 可以通过索引或搜索按需召回，当然 AI 根本不会召回，所以更加佐证把记忆直接存在上下文是正确的设计了），每轮压缩的记忆存在等级概念，通过合并同级存档的方式，记忆本身也是可以多次压缩的，显然等级越高的记忆越在早期，也越难触发压缩。于是记忆区内部也呈现了一种分区思想：“越早期越被多次压缩还留存的记忆越珍贵，也越不会被修改，缓存命中率高；越新的记忆越容易被压缩，所以错误可以及时修正，非重要记忆会不断淡化，而且因为身处低位，破坏的缓存命中也少”

对话区则是和 AI 的正常对话记录。Alife 始终会保持一定的对话区，因为此区域可以作为 AI 说话的参考，是保持人设统一非常关键的设定。如果用前面哪些重开会话只靠预设提示词的方法，用着用者，就会有说话方式忽然转变的情况，使用体验非常差。而且此区域配合稳定的长期记忆还带来了一个意想不到的功能，就是 Alife 可以完全不依赖人设提示词，人设是可以在使用中自然形成的，真正的实现了养宠物的感觉。

{配图-上下文分区，记忆区分级}

总结

Alife 的记忆压缩真的很简单，就是第一种记忆方式的 Plus 增强版，当正常对话满 100 句了，我就会直接和 AI 说，待会要压缩的了，然后她产生摘要，我再拿这个摘要加上一个时间索引插入到记忆区，同时清理掉被总结的内容。如果记忆区的同级存档多了也是同样的，产生摘要再转化为高一级存档。

关于记忆存档的二次压缩，这里还有个两个小巧思：

1. 压缩总是以333…的方式压缩，因为这个系数最接近自然底数，是当数字总数固定时，乘数最高的方法。
2. 压缩总是会留一个同级存档，这是为了避免记忆一次性全部坍缩，导致性情大变的情况。

全能场景适配

说是桌宠 Agent，但从实际使用来看，桌宠 Agent 被要求几乎全。仅仅一个杵在那的卖萌小人，已经无法满足用户需求了。大伙都想要的是那种，科幻电影般的，又要能日常陪伴，又要能写代码的全能桌宠，这可比光编程的 Agent 的要求高多了。当然论专业肯定还是专门编程特化的 Agent 强，但桌宠做到全能够用，也不是不行。关键就在于功能注入上的特殊实现。

首先给大伙介绍一下 AI 的注意力机制，东西都放入到上下文后，AI 并不是能一直稳定记住其中的每一条内容的，具体而言有如下两种特点：

1. 位置影响：规则所在文本位置的不同，对 AI 的影响力也不同，其中开头较强，结尾最强，中间偏弱。
2. 数量影响：影响力权重是全文分配的，因此限制的提示词越多，每条提示词的影响力就越少。

{需要配图-注意力机制}

所以由于数量影响的原因，实际上提示词越多，AI 不仅可能不会更全能，反而会更不听话。再加上位置影响的原因，如果你希望 AI 去调用一个早期注入的功能，他可能也并不会用。反过来如果按需注入，则能有效利用 AI 的注意力机制，让他办事效果更好，比如 Skill 就是对机制的一种利用方式。而 Alife 在此之上，对整个工具环境也实现了按需加载。

{需要配图-太多的提示词导致 AI 混乱}

这对设计一个全能桌宠很重要，如果一开始就把所有办公和娱乐工具都注入上下文，token 开销就会非常大，而且导致样样不精。实际上桌宠办公都是突发性的，所以按需加载就变的非常适合。

Alife 默认只会完全注入基础的交互能力类工具，对于特殊工具仅注入简介和入口激活函数。当 AI 明确自己去激活了这些功能时，才会将相关工具和提示词完全暴露给 AI。这些提示词会作为用户内容直接发送，不会破坏缓存命中，也因此他会参与记忆压缩的流程。但压缩后由于对话区的存在，实际上 AI 依旧可以正常使用工具，然后系统检测到工具调用，又会自动重新注入，所以干扰很小，而且由于稳定多级记忆的存在，AI 会自己不断提炼这些隐式工具的使用方法，实现一种正循环，使 AI 立即进入一种专业的办公状态。（真的，全是伏笔啊）

（这个就叫隐式功能）

{展示隐式功能}

低廉使用开销

既然是长期使用，那也要考虑可持续发展，接下来我给大伙介绍一下，Alife 中的省钱小妙招：

• 特制的上下文管理系统
• 特制的记忆系统
• 特制的工具系统

这三个已经在上文提过了，不再赘述

{打开 Alife 桌宠实例，给大伙挨个演示说明}

• 按需思考

  既然可以按需注入工具，自然也可以按需思考，这和隐式工具正好相辅相成。没有使用隐式功能时，说明是日常对话模式，环境简单出错影响小，不开思考也可以用，这还带来的如下好处：

  • 减少长期输出 token
  • 提高交互回复速度
  • 更听话稳定容易破甲

  然后只有当遇到报错、或开启隐式功能，再进行思考，进入专业的工作模式，次数用户交互减少，能力精度要求增加，正好适合开启思考。

• 精简提示词

  完全人工手搓测试的提示词，这点也很重要。现在 AI 发达了，很多人就开始完全的让 AI 去生成文档提示词这些，然而 AI 不仅错误率高而且啰嗦找不到重点，写出来的提示词那是又臭又长。谁懂啊，原本注释都懒得写的同事，忽然摇身一变都成“小说家”了要。

  Alife 的提示词完全手搓不啰嗦，而且故意去掉了描述信息，尽可能确保函数名就能让 AI 立即工具作用，仅实测后确实需要补充的地方，添加注释文本。真的效果挺好，一下子就减少了大量冗余 token 开销。这实际上也不是我想的，而且本来人工编程的时代，就有很多编码规范，要求名称代替注释的风格，以及精简代码和提高可读性。

• 离散注入

  除了人设记忆这些打基础的提示词外，还有一类提示词，比如纠错，回复约束等。如果 AI 足够聪明，这些原本是不需要的，但实际上 AI 经常犯错。那咋办，在人设里增加提示词？实测效果非常差，由于注意力机制，放进去的提示词影响力很小，而且有些错误 AI 确实没法规避（这个在程序上做了处理，Alife 的特色函数调用真的也很值得一说）。所以最好的方法，也是按需注入，仅当 AI 犯错时自动提示，此时为了延续上文，AI 纠错的概率会非常大，这对每句附加的提示词也是如此，完全可以做成间隔几句再注入一次，这种就完全够用了，而且更节省 token，避免了长期提示词冗余和非缓存输入的数量。

• 非线性激活

  桌宠活动还有一个重要的点是主动行为，这个实现很简单，发个消息给 AI 让他活动就好。但这个发消息的时机也要注意，首先用户交互时肯定是不需要的，闲置时也不需要一直发送，因为交互本身也符合时间局部性原理，交互总是存在突发性，交互后短时间容易再此交互，反之如果长时间没有交互，那用户通常是有事或休息去了，此时让 AI 主动交互，不仅无效还可能反作用。因此 Alife 使用非线性唤起方式，当 AI 交互后，他会短时间提高交互频率；反之如果用户不回应，那么主动唤起时间就会延长，乃至几小时才唤起一次，这样长期挂机的开销就会变的非常小，同时也不影响玩耍时的互动感。

• 精选本地模型

  作者太抠太懒了，不想找免费 API（同理用户应该也不会配，毕竟很多人 Github 都没法上），就直接配了很多本地模型来实现功能，狠狠榨取用户电脑（开玩笑的，实际上开销也不大，各种量化后功能全开也才 2G），我觉得这也是省钱很关键的一个地方，很多非发烧友，其实本地模型就完全够用了，而且不折腾。如果需要扩展，插件内也预留了接口，或者直接完全自己写一个，让需要的用户也可以去折腾，因为模型接入也是完全插件化的（全插件框架还是太先进了）。

实时交互策略

• 非事务性交互

  编程 Agent 都是事务性交互方式，你给 AI 一个任务，他就会持续去中，等到任务完成，才可以和他进一步交互，期间延迟会非常大。而桌宠讲究实时交互，哪怕 AI 在做事，也应当可以和 AI 进行正常交互。

  {配图-事务性交互，一一对应，类似SSL握手}

  对于此需求，有一种解法是使用子代理，但自己的宠物做，和外包给一个陌生人做，效果能一样的？当爹当妈的，肯定是希望看着自己的孩子成长做事啊，而且这种子代理的方式导致桌宠和任务执行细节完全脱轨，带入感非常差。最好的方法还是用同一个 AI，但依然能让他实时交互。这个难吗？不难啊，现在中的人不就如此吗，一边干活一边唠嗑是很常见的事。

  所以 Alife 对于交互这件事，不采用事务驱动，而是选择类似游戏引擎的触发驱动，这使得 AI 的输入输出不再需要和特定任务绑定。AI 回应你（此处的你代表框架中的每一个功能）仅仅是因为他看到了你的消息，你看到 AI 的回应也仅仅是看到了他说的话。在 Alife 里 AI 不是一个工具，不是你按下按钮然后灯亮了，而是一切都处于双方自愿自主的行为。

  {配图-游戏引擎中子弹、枪、靶子都是独立个体，通过物理事件交互}

  所以 Alife 实现了实时交互，任何人都可以随时并行的向 AI 发送消息，然后可以通过事件监听他的回应，但没有人可以独自霸占他。工具反馈的给 AI 的结果也仅仅是推送给他的，而不是他必须回复的命令。（当然，如果需要依然可以霸占会话，但这不是 Alife 功能的主流做法）

• 流式函数执行

  为了实现自己的交互策略，Alife 从一开始就没使用底层 Agent 框架提供的那套交互机制，而是自己实现，这也诞生了一套特殊的Xml函数调用模式。真的，Xml 作为函数调用比 JsonRpc 优秀太多了：

  1. 语法上更简单易读，不仅方便人类调试观察，而且使得 AI 不要预训练也能正确调用，token 开销上也更低。
  2. Xml 的参数填写在开头标签，内容文本连续，子标签按层展开，天生就适合流式解析，格式出错也很容易补偿。

  正因此 Alife 成功将语音合成等功能成功流式化，实现了 AI 边输出边解析，不等 AI 说完全部内容，函数功能就已经跑起来了。而且可以随时打断，因为 xml 被打断了也很容易修正格式，关键参数也开头就提供了。（我真的感觉 JsonRpc 是 AI 标准设计的一处败笔）

  {展示 JsonRpc 和 Xml}

• 并行函数调用与记忆压缩

  由于 AI 和功能不再绑定，因此多个功能并行执行就成了一种可能，对此 Alife 还专门实现了多线程访问机制。最明显的是记忆压缩功能，当 llm 输出完文本后，此时 AI 往往还在说话摆动作，但同时记忆功能就已经开始工作了，当 AI 说完话，记忆压缩也正好完成，显著降低的工具执行延迟。

  {展示压缩与语音并行}

  对此具体到工具上也有很多实现小细节，比如：

  • 记忆压缩由于增加了随机扰动，避免连续压缩导致过长的等待时间。因为回复慢，也肯定比不回复好，后者会让用户以为程序故障。
  • 语音合成特意在xml标签关闭时不等待最后一个语音片段，使得语言合成和接下来的其他工具可以重叠执行。

• 按需思考（这个上文说了，仅需要时思考，降低延迟）

可以说正是实现上的各种小巧思与小细节，让 Alife 在和其他陪伴向 Agent 的对比中，显得非常与众不同。说句自夸的话，我认为 Alife 是目前最优秀的桌宠 Agent。