AI 助手每次都失忆?给 Kiro Bot 轻轻加上跨会话记忆

用 ~4500 行 Python，在不修改 Agent 一行代码的前提下，给聊天 Bot 加上记忆持久化、任务编排和多项目管理。
——在飞书和 Discord 里操控 Kiro CLI 的实践指南

痛点：每次对话都从零开始

如果你用过 AI 编码助手的聊天 Bot，一定经历过这些场景：

午饭回来继续聊天，AI 已经忘了所有内容。 你说”继续刚才的任务”，它回答”我没有之前的上下文”。你只好把背景重新描述一遍。

在飞书里告诉它”我喜欢 pytest-asyncio strict 模式”，切到 Discord 又要说一遍。 不同平台、不同聊天窗口之间没有任何知识共享。

Bot 空闲几分钟后自动关闭，下次发消息要等冷启动。 而且冷启动后是一个全新的会话——之前的对话历史全部丢失。

没有定时任务能力。 你没法让 Bot 每天早上 9 点自动检查 CI 状态。

这些问题的根源是：大多数 Bot 网关是纯粹的消息管道——用户消息原样透传给 Agent，Agent 的回复原样转发给用户。没有记忆、没有会话恢复、没有后台任务。

我们的目标是：在不修改 Agent 一行代码的前提下，在网关层”轻轻”加上这些能力。

改造前 vs 改造后

Kiro CLI：为什么选它做后端 Agent

Kiro 是 AWS 推出的 AI 驱动的 IDE，Kiro CLI 是它的命令行版本——一个开箱即用的 AI 编码 Agent。

选择它作为后端的理由：
– 高性价比——包月订阅（$19/月起）是使用 Claude Opus 等先进模型最划算的途径之一，不按 token 计费
– 完整工具链——bash、文件读写、grep、glob、web 搜索、AWS CLI、代码智能（18 种语言）、子 Agent 委派
– 标准协议——ACP（JSON-RPC 2.0 over stdio），任何语言都能驱动
– 13+ 模型——从 Opus 4.7 到 Qwen3 Coder，全部包含在订阅内

kirocli-bot-gateway 就是在 Kiro CLI 之上构建的多平台 Bot 网关：

核心设计：透明代理 + 文件基记忆

透明代理模式

kiro-cli 完全不知道记忆系统的存在。网关把偏好/教训/历史拼接到用户消息前面，作为 session/prompt 的 content 发送：

kiro-cli 看到的只是一个很长的 prompt——它不知道前面那些是”记忆”，但它会遵循。这个模式的好处是：不需要修改 kiro-cli 的任何行为，也不受 kiro-cli 版本更新的影响。

这个思路适用于任何 Agent——只要你能控制发给它的 prompt，就能在外部加上记忆层。

两层记忆：全局偏好 + 项目隔离

核心矛盾：用户偏好是全局的（”我喜欢 dark mode”），但项目上下文是局部的（”这个项目用 FastAPI”）。

全部是 Markdown 文件——人类可读、可编辑、可 git 管理、零数据库依赖。

我们最初以为需要向量数据库做语义检索。后来发现：记忆总量约 5K-10K 字符，全量注入到 200K token 的上下文窗口中开销可忽略。简单的全量注入比复杂的检索系统更可靠。（灵感来自 OpenClaw 的”文件是真相来源”理念）

LLM 自动整合：用户不需要操心

手动 /remember 是最简单的记忆写入方式，但用户不会记得每次都用。

我们的做法：15 条消息后标记为”待整合”，等用户 60 秒没发消息后，用后台 kiro-cli 自动从对话中提取知识。

整合 prompt 要求 LLM 返回 JSON，包含偏好更新、项目更新、教训列表和每日摘要。关键设计：完整替换而非增量追加——LLM 能识别矛盾（”之前说喜欢 tabs，现在改用 spaces 了”）、合并重复、移除过时信息。增量追加只会让文件越来越大。

LLM 生成的内容不可预测，所以我们加了三层保护：.bak 备份（写前轮转）、5K 字符截断、50 条教训上限。

（灵感来自 ClaudeClaw 的 Bootstrap 首次引导和 SOUL.md 沟通原则）

其他亮点

每聊天独立 kiro-cli

5 个用户同时发消息 = 5 个 kiro-cli 进程并行推理。Semaphore(4) 限制并发冷启动，max_instances=10 + LRU 驱逐控制资源。

/project 多项目切换

同一聊天窗口中切换项目，每个项目有独立的 kiro-cli 和对话历史：

/project /projects/myapp     → 切换到 myapp
/project /projects/infra     → 切换到 infra（myapp 继续运行）
/project 1                   → 按序号切回

定时任务 + 心跳

/cron add "standup" "检查 CI 状态" --schedule "0 9 * * 1-5"

支持标准 5 字段 cron 表达式、Markdown job 文件、心跳巡检（没事回 HEARTBEAT_OK 不打扰）。（灵感来自 cc-connect 的 Cron + Heartbeat 设计）

任务编排

/task run "重构认证模块" → LLM 分解为带依赖图的步骤 → 拓扑排序 → 组内并行执行。

kiro-cli 命令透传

/compact、/usage、/tools、/mcp 等 kiro-cli 原生命令直接在聊天中使用。

经验教训

“我们最初以为需要向量数据库”

结果发现 5K 字符的 Markdown 文件全量注入就够了。200K token 的上下文窗口足够容纳所有记忆。简单方案往往比复杂方案更可靠——向量检索在记忆量达到几十 KB 时才有价值，但那时候更应该精简记忆。

“LLM 自动整合的效果远超预期”

它能识别”pytest strict 模式”和”pytest-asyncio strict mode”是同一件事，能发现”用户之前说喜欢 tabs，现在改用 spaces 了”并自动更新。这是人类手动 /remember 做不到的。

“透明代理是最正确的抽象”

kiro-cli 不知道记忆系统存在，不知道有定时任务，不知道有多项目管理。网关可以独立演进，不受 Agent 版本更新影响。这个模式适用于任何 Agent——不只是 Kiro CLI。

“文件优先不是偷懒，是设计选择”

JSON + Markdown 文件意味着：用户可以直接编辑 AI 的记忆、可以 git 管理、可以团队共享。没有 SQLite 锁、没有 Redis 连接、没有数据库迁移。原子写入（tmpfile + os.replace）+ .bak 备份确保崩溃安全。

“借鉴要有选择性”

我们研究了 OpenClaw、ClaudeClaw、cc-connect 等项目，加起来超过 50000 行代码。我们只借鉴了与”轻量级网关”定位匹配的设计。保持 ~4500 行是有意识的选择。

如果你也想给自己的 Agent Bot 加上记忆

这套方案不限于 Kiro CLI。核心模式可以复用到任何 Agent：

1. Prompt 前缀注入：只要你能控制发给 Agent 的 prompt，就能在前面拼接记忆上下文。不需要 Agent 支持任何特殊 API。

2. 文件基记忆：用 Markdown 文件存储偏好/教训/历史。人类可读、零依赖、可 git 管理。记忆量小于 10K 字符时，全量注入比向量检索更简单可靠。

3. LLM 自动整合：累积 N 条消息后，用 LLM 从对话中提取结构化知识。关键：要求 LLM 返回完整替换的文件内容（不是增量追加），让它负责去重和矛盾解决。

4. 安全写入：LLM 生成的内容不可预测。每次全量替换前备份（.bak），加文件大小上限和条目数上限。

5. 后台 Agent 实例：用一个持久的 Agent 进程做记忆整合和定时任务，不占用用户的聊天 Agent。

快速开始

git clone https://github.com/soldierxue/kirocli-bot-gateway
cd kirocli-bot-gateway
pip install -e .
cp .env.example .env
# 编辑 .env 填入飞书或 Discord 凭证
python main.py

详细配置请参考 README（中文版）。

未来方向

• Pre-compaction flush：上下文压缩前自动持久化重要信息
• 群聊记忆隔离：私聊和群聊使用不同的记忆作用域
• Web控制台：项目会产生很多文件和内容，通过浏览器查看所有工作台项目状态和信息

项目地址：https://github.com/soldierxue/kirocli-bot-gateway
欢迎 Star、Issue 和 PR。

致谢：本项目基于 @terrificdm 的 kirocli-bot-gateway 进行二次增强。感谢原作者构建了优秀的多平台网关基础架构，让我们能在此之上专注于记忆系统、任务编排和体验优化。

📢 免责声明：本文基于公开数据与行业观察进行分析，不构成投资建议，文中观点仅代表作者个人判断，不代表公司观点，欢迎理性讨论。

军见| 洞见科技，洞见职场，洞见自己；科技有深度，职场有方法，管理有温度，做长期有用的内容。

点赞 +「在看」，转发给你身边有需要的朋友。收不到推送？那是因为你只订阅，却没有加星标。