always-accompany
把陪伴、聊天、写代码和办公放进同一套记忆与上下文框架里。
- Star 数
- ★ 459
- 最近更新
- 2 个月前
- License
- AGPL-3.0
- 主语言
- JavaScript
- FA 评分
- 37/100 · 缺口较多
30 秒速览
- 可在哪里用
- 兼容但需适配
- 开始前需要
- 典型场景
- 长期角色扮演用户：想把 SillyTavern 的角色卡、预设和世界书直接导入，并希望在长对话中由系统自动召回旧事，而不是只靠全文塞进上下文。
- 主要局限
- 作者自述绝大多数功能由单人约三个月完成、随后约一个月做算法优化，项目结构、基础功能与边界处理可能不稳定或不完整，各模块成熟度不一。
这个 Agent 能做什么，适合哪些场景？
always-accompany 是一个自托管的 AI + Agent 项目，核心思路是围绕上下文与注意力机制做长期记忆。它用可编辑的 Data 结构化表加 hot/warm/cold 三层 JSON/Markdown 文件承载长期素材，再由自研的 P1 前置记忆召回路在每轮回复前挑出相关片段交给主 AI。产品面提供 Chat（含角色扮演）、Code（IDE 式三栏工作流）、Work 和 Smart 四种主模式，每种模式有自己的记忆表、私有目录与 P1 路由。后端跑在 Deno 上，前端是原生 JavaScript/ESM，通过 Shells、Plugins、Service Generators 组织能力，数据默认存在本地。扩展面包括 MCP、可写 JS/Python 的用户插件、Live2D 桌面陪伴、本地语音转写以及九个平台的 Bot 外壳；作者说明多数功能由单人约三个月完成，模块成熟度不一。
启动后由 run.bat / run.sh 拉起 Deno 服务，在 http://localhost:1314 打开 Web 界面；绑定 AI 服务的 URL、API key 和模型即可对话。每轮回复前，P1 走 Node0–4 链路：Node0 收集当前输入、近期用户消息与当前模式 Data，Node1 做分词、词性、时间、专名和短语锚点，Node2 用 SWOW / ConceptNet / Cilin / ATOMIC 等做关联扩展，Node3 用 BLQ、NB300、WordNet 做多证据筛选，Node4 回到 Data、hot/warm/cold 和模式记录，用 BM25、时间、层级、Top、重要性等信号排序，输出 recalledRecords、directionWords 和 trace。Code 模式下它能读写项目文件、执行命令、维护任务列表；上下文管理按消息、文件读取、工具结果和系统注入统计用量，默认清理只是打 _hidden 标记，记录留在磁盘可恢复。此外还有 MCP 工具接入、六套权限模板（L0–L5）加逐工具规则、Live2D/图片桌面陪伴与屏幕感知、MOSS-Transcribe-Diarize 本地语音转写，以及 Discord、Telegram、Slack、LINE、飞书、钉钉、微信、企业微信、X 的 Bot 外壳。
- 长期角色扮演用户：想把 SillyTavern 的角色卡、预设和世界书直接导入，并希望在长对话中由系统自动召回旧事，而不是只靠全文塞进上下文。
- 独立开发者：在大中型代码库上让 AI 读调用链和 Markdown 笔记，需要按文件读取粒度清理上下文，避免压缩后重读全部内容。
- 需要多场景隔离的人：同一张角色卡下想用 Code、Work、Chat 各自的记忆表与私有目录，避免新项目被旧项目记忆锚定。
- 想深挖提示词的用户：希望逐条编辑角色定义、预设、INJ 条目、注入角色与位置、条件触发规则和工具指引。
- 桌面陪伴需求者：想要 Live2D 或图片形象、屏幕感知与主动评论，并接受本地部署和自备模型。
- 自建多平台 Bot 的运维者：已有 Discord/Telegram/飞书等平台 token 或 webhook，想复用同一套记忆框架。
如何安装或部署这个 Agent？
先准备一个可用的 AI API（服务地址、密钥、模型名）。克隆仓库后运行平台对应的启动脚本，脚本会在缺少 Deno 时自动下载运行时，并在依赖不全时完成安装：
git clone https://github.com/beilusaiying/always-accompany.git
cd always-accompany
run.bat # Windowschmod +x run.sh && ./run.sh # Linux / macOS首次启动较慢，需要下载运行时依赖并初始化本地数据，等完整页面出现后再操作。若浏览器未自动打开，手动访问 http://localhost:1314 。可选功能（语音、桌面陪伴）有各自的首次下载或环境要求；P1 本地检索服务实测峰值内存约 2 GiB，可以整体关闭。
如何使用这个 Agent？
在引导页选择界面语言，然后填写服务 URL、API key 和模型并保存，选择或导入角色卡即可开始对话。深入配置项包括 P1 参数、提示注入位置、Code / Work 模式、插件与权限模板。
1. 引导页 → 选择界面语言
2. 绑定 AI 服务 → 填服务 URL / API key / 模型 → 保存
3. 选择或导入角色卡 → 开始聊天
4. 需要改行为时 → 编辑角色定义、预设、INJ 条目、注入位置与条件
5. 需要改权限时 → 选 L0–L5 模板，再按工具与路径细化 deny / ask / allowMCP 工具通过粘贴 JSON 接入，命令型服务器还需要通过 owner、环境变量白名单等安全闸门。应用内自带 Wiki，也有在线版本可查。
这个 Agent 有哪些优点和局限？
- 记忆素材以普通 JSON/Markdown 文件存在本地，Data 表与 hot/warm/cold 三层都可直接查看和手工修正，而非黑箱向量库。
- 上下文清理做到文件读取粒度且可逆：默认只打 _hidden 标记、记录留在磁盘，AI 也能用 <contextClean> 请求清理，并有最小 token 阈值避免反复打断提示词缓存。
- P1 提供白盒诊断面板，能看到输入单元、各节点候选与淘汰原因、索引状态和最终来源，便于区分“没匹配到”与“链路坏了”。
- 提示词主条目（角色定义、预设、INJ、模式指令、记忆数据槽、工具指引）在界面内可编辑内容、顺序、启用状态、角色与注入位置。
- 插件与模式解耦：内置 23 个插件目录，用户插件可用 JS、Python 或独立程序编写，核心能力走中间转发站路由。
- 同时覆盖 IDE 式编码、办公与角色扮演三条线，并共用一套记忆与权限体系，不必在多个工具间搬上下文。
- 作者自述绝大多数功能由单人约三个月完成、随后约一个月做算法优化，项目结构、基础功能与边界处理可能不稳定或不完整，各模块成熟度不一。
- 首次启动要下载 Deno 运行时与依赖并初始化本地数据，P1 本地检索实测峰值内存约 2 GiB，对低配机器是实际负担。
- AIRP 与 Chat 提示词仍在打磨，当前侧重生产力场景，陪伴向调优尚未补全。
- 九个平台的 Bot 只是外壳，每个平台仍要自行准备 token、webhook 或第三方桥接，语音仅做转写、不含 AI 语音播放。
- 语义向量检索（beilu-vectordb）默认关闭，需自行配置 embedding 端点才能启用，且与 P1 是互补关系而非二选一。
- 项目已声明不再新增插件与功能面，后续重心是瘦核、降耦合与插件协议，使用者要预期接口变动。
这个 Agent 与同类方案有什么区别？
README 明确把 SillyTavern 作为角色扮演与提示词生态的先驱和格式来源，也提到 fount 是其早期参考框架；此外还引用了 OpenAI Codex 与 Claude Code 的相关 issue 来说明上下文膨胀问题。这些是参照对象而非直接竞品对比，仓库未提供同口径的横向评测数据。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| always-accompany 当前 | 37 · 缺口较多 | — | ★ 459 | 2 个月前 | JavaScript | — |
| Remnic 智能体记忆 | 85 · 表现良好 | 命令行工具免费 + 模型费 | ★ 231 | 今天 | TypeScript | ChatGPT · Codex · Claude Code · OpenAI API |
| PowerContext | 55 · 缺口较多 | 命令行工具免费 | ★ 1.5k | 今天 | Python | Codex · Claude Code |
| Late | 50 · 缺口较多 | 命令行工具免费 + 模型费 | ★ 455 | 2 天前 | Go | OpenAI API |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
README 描述了 L0–L5 权限模板、按工具/路径的 deny/ask/allow、命令黑名单与 MCP 安全门，属于对最小权限与用户确认的声明；但可见源码仅为 P1 测试 stub，无法核实这些门是否真正实现，故 least_privilege 与 user_confirmation 仅给 1。数据流透明性方面 README 承认内容会发往所选远程 AI/嵌入服务，但未给出具体字段级说明，给 1。敏感数据处理（API key、token）仅在安装说明中提及，无存储/加密证据，给 1。依赖安全：package.json 依赖众多且含 pdf-parse 1.1.1 等固定旧版本，无锁文件或审计证据，给 0。外部效应与回滚：README 提到回收站/备份链与 _hidden 可恢复清理，属声明，无代码佐证，各给 1。来源归属：README 明确致谢 fount、SillyTavern 及数据资源，LICENSE 为完整 AGPL-3.0，给 2。
自一致性：README 自述项目仅三个月开发、结构不稳定、模块成熟度不一，且承认旧文档 21 节点描述已过时，说明文档与实现存在漂移，给 1。依赖可用性：依赖数量庞大且含多个私有/小众包（@steve02081504/*、als-registry 0.0.0），无锁文件，可用性无法静态确认，给 1。失败消息：可见 stub 仅返回 trace 标记，无错误处理或用户可读失败信息证据，给 0。
受众与场景：README 覆盖聊天/角色扮演、编码、办公、桌面陪伴、Bot 等，场景描述充分，给 2。能力边界：虽声明“实际可用性取决于模式、配置、模型”，但大量功能以“已存在”方式罗列，边界界定偏弱，给 1。触发精度：P1 召回与条件注入有描述，但无阈值/触发规则的可验证细节，给 1。环境适配：依赖 Deno、可选 Python 服务、Electron、约 2GiB 内存的 P1 服务，环境要求较重且仅粗略说明，给 1。
信息架构：README 结构清晰，含快速开始、功能概览、架构、路线图，给 2。安装说明：给出 clone + run.bat/run.sh 与首次启动说明，给 2。命名稳定性：README 自承结构将重构、功能迁往插件层，命名与结构稳定性存疑，给 1。示例与 FAQ：有截图与快速开始，但无 FAQ 或可运行示例，给 1。已知限制：开发说明明确列出不稳定、边缘情况未完善，给 2。许可证：完整 AGPL-3.0 文本且 package.json 一致，给 2。版本与变更日志：package.json 有 1.0.3，但无 CHANGELOG，给 1。维护责任：单一作者、未验证发布者，维护承诺仅为路线图表述，给 1。
输出可用性：仅有截图与描述，无实际输出样例或可验证产物，给 1。边际价值：解决长上下文记忆与注意力问题有明确动机与引用，但相对既有方案（SillyTavern、fount）的增量价值未被证据支撑，给 1。成本收益：README 自述 P1 峰值内存约 2GiB、需外部 API 付费，成本较高而收益未量化，给 1。
主张可追溯：README 引用 Issue、论文与社区讨论，部分主张可追溯，但核心算法（BLQ、NB300）无公开细节，给 1。跨源佐证：仅 README 与 package.json 相互印证版本与依赖，功能主张无代码或测试佐证，给 1。事实与推断分离：README 多处区分“已存在”与“方向”，并承认论文不直接证明本项目更优，态度较诚实，但仍有大量未标注的推断性表述，给 1。
- 源码中未见：依赖安全审查安装前固定版本并做一次依赖扫描（如 npm audit、pip-audit）；优先放在容器里运行。
- 仓库可见源码仅为 P1 测试 stub，README 中的权限、回滚、MCP 安全门等安全主张无法静态核实，部署前需自行审计。
- 依赖数量庞大且含小众/私有包与固定旧版本（如 pdf-parse 1.1.1），无锁文件，存在供应链与可用性风险。
- 项目自述开发周期短、结构不稳定并计划重构，接口与命名可能变化，不宜用于生产关键路径。
- P1 本地检索服务峰值内存约 2GiB，且需绑定外部付费 AI API，成本需提前评估。
- 发布者身份未经 FollowAgents 验证，维护责任与更新路径不明确。
最近版本
来自该项目 GitHub Releases 的最新发布记录，说明为上游原文摘录，未经本站改写或测试。
-
v1.0 v1.0.1
发布说明摘录
更新日志 本文件记录面向用户的发行变化。内部调查、个人路径、测试账号与密钥不进入公开更新日志。 1.0.1 — 2026-08-04 基础可用性 - 修正 AI 服务源首次保存、配置应用与重新读取链，避免已保存后仍提示未配置。 - 收紧聊天消息删除与回档后的索引传导，避免前端继续提交已经失效的位置。 - 补齐部件配置应用、生命周期取消、失败回滚与熔断边界，减少波动时的重复加载和状态假成功。 - 修正多窗口文件工作区与可信会话的绑定链，保留主窗口自动绑定和额外窗口显式绑定。 首次使用与配置 - 新用户默认提供“新的开始”角色卡，并增加语言选择与启动加载状态。 - AI 未配置时的入口改为直接引导到完整设置；子模式未绑定 API 时给出独立提示。 - 子模式默认采用严格后处理、不预填充、1,000,000 上下文和 30,000 最大输出；用户仍可修改。 P1、YonBan 与 CLI - 同步 P1 自驱动运行时、资源目录与诊断展示，补充启动波动、有限重试和宿主退出联动。 - 同步 YonBan IDE、扩展端与本体通信链，以及 CLI、文件、检查点和命令工具。 - 保留公共发布所需的 P1 资源、YonBan 和 CLI 依赖；运行时生成物与用户状态不进入仓库。 更新与数据保护 …在 GitHub 查看 ↗