能力演进 · aibuddy Docs

运行信号与生产变更必须分层

任务轨迹、用户反馈和交付结果只能说明“发生了什么”，不能直接说明“应当修改什么”。同一次失败可能来自上下文缺失、知识过期、工具异常、权限限制或模型判断；如果把轨迹直接追加到全局 Prompt，偶发问题就会变成长期规则。

aibuddy 没有设置一个可以任意改写自身的“学习器”。系统先按作用域选择更新面，再由该更新面的状态机决定内容何时对后续任务生效。这样可以保留变更对象、影响范围和发布动作，而不是把所有经验混入一段不断膨胀的提示词。

更新面	适用内容	生效边界
用户记忆	单个用户的稳定偏好、身份与纠正	写入用户作用域；人工内容优先于自动内容
知识库	有来源的事实、资料和文档结构	重新摄取后回到 `pending`；仅 `ready` 文档可被 Agent 检索
Skill	可按需加载的流程、规范和参考材料	显式上传后更新修订号，并使元数据缓存失效
Prompt	某个 Agent 的角色、边界和默认行为	草稿发布后才能激活；激活版本写入 Agent 的运行指令
程序与工具	必须确定执行或验证的跨任务规则	通过工程发布进入所有相关运行路径

选择原则是：优先使用作用域最小、验证方式最明确的更新面。缺少一份内部资料时，应更新知识库；一项检查可以确定执行时，应放入程序或工具；只有稳定的行为约束才适合进入 Prompt。

记忆是当前唯一会在普通任务结束后自动产生内容的更新面，但自动写入前后都有限制：

调用前门控：系统先用确定性线索判断最近对话是否可能包含偏好、身份、长期项目或明确纠正；没有线索时不调用提取模型。
有限窗口判断：提取器只读取最近三组用户与助手消息，并要求内容同时满足“关于用户、下周仍成立、无法从文件或外部系统重新取得”。
显式写入互斥：如果 Agent 在当前轮已经调用 memory_save、memory_update 或 memory_delete，后台提取会跳过，避免两个写入路径相互覆盖。
写入前协调：低显著性候选被丢弃；同类型内容通过字符二元组相似度归并；等价内容不重复写入；自动来源永远不能覆盖人工记忆。
非阻塞执行：提取在后台运行，失败会记录而不会改变当前任务的完成结果。

这里的自动化目标不是尽可能多地保存，而是在不干扰主任务的前提下，维护少量可解释、可复用的用户信息。

知识库更新不会直接替换 Agent 正在使用的可见资料。导入或重新摄取时，系统先规范化 Markdown、重新解析标题目录，并把文档状态设为 pending。内容已经可以供管理端检查，但只有审核为 ready 后才会进入 Agent 的知识地图和检索范围。

重新摄取还会立即清除与旧正文对应的摘要。新摘要是非阻塞增强：生成缓慢或失败不会撤销正文写入；写回前再次读取文档，可以避免迟到结果覆盖审核者已经填写的摘要。正文、派生目录、摘要与发布状态因此具有明确的更新顺序。

两者都承载可复用行为，但生命周期不同：

	Skill	Prompt
变更方式	上传完整文件树并校验根目录 `SKILL.md`、frontmatter 与路径	为指定 Agent 创建新的草稿版本
运行可见性	上传后递增 `.version`，清理元数据缓存；Agent 可看到修订号并重新加载	只有 `published` 版本可以激活，激活内容同步到 `agent.instructions`
不可变边界	当前实现替换同名内容；修订号不是历史快照	已发布正文不能原地修改，活动版本不能直接删除
当前缺口	尚无内置的历史内容比较与回滚	尚未接入自动评估、灰度发布与自动回滚

这种差异是有意保留的：Skill 更接近可部署的能力包，Prompt 更接近 Agent 的配置发布。文档不把修订号等同于版本仓库，也不把“可激活”表述成“已经通过效果验证”。

单条回复的正向、负向或撤销反馈会与消息和任务关联保存，可与轨迹、步骤状态、用量和交付物共同分析。当前实现不会因为一次差评自动修改记忆、Prompt、Skill 或工具。

要形成系统级演进闭环，还需要把这些信号沉淀为固定样本，并建立候选变更、基线对比、发布观察和回滚之间的关联。aibuddy 已具备分层证据和多种受控更新面，但自动归因、跨版本评估、灰度发布与统一回滚仍是明确的工程边界。