文章目录一、从 v1.0 到 v2.0一次方向性的重新思考二、记忆功能不做 RAG做「读小说」式的记忆整合2.1 RAG 为什么不够好2.2 换个思路从「检索」到「回忆」2.3 艾宾浩斯遗忘曲线记忆需要「遗忘」机制2.4 记忆注入的优先级链三、计划模式澄清 → 计划 → 执行的三段式工作流3.1 同类工具的实践对比3.2 AinoWork 的设计AI 自主选择深度3.3 「弱限制」设计哲学的实战验证四、避坑指南五、总结常见问题AinoWork v2.0 不是一个功能堆叠版本而是一次方向性的重新思考。本文从 Harness 工程的弹性设计出发拆解「记忆」和「计划模式」两个核心功能的实现思路——不做 RAG、不写死流程而是用更灵活的方式让模型能力真正发挥出来。一、从 v1.0 到 v2.0一次方向性的重新思考v1.0 做的事情很朴素把 Hermes-Agent 从 CLI 搬上 Web加上 Docker 沙箱和多用户 RBAC让一个原本只能单人命令行使用的 AI Agent 变成团队可用的效率工具。这个目标基本达成了——一条命令部署开箱即用每个 Agent 拥有独立的 Docker 容器作为工位。但 v1.0 发布后我意识到一个问题把 Agent 搬上 Web 只是第一步真正的挑战在于 Harness 层的工程深度。什么是 Harness简单说就是模型和用户之间的中间层——它决定模型能看到什么上下文、以什么方式接收指令、在什么约束下执行任务。Harness 工程是基于模型能力的衍生工程这意味着一个核心矛盾真正好的 Harness 设计不是选一边站而是在同一个系统里同时容纳这两种策略。就像给 AI 的工位——你不会给实习生和架构师完全相同的工具配置但他们应该在同一个办公室里工作。带着这个思路v2.0 选择了「记忆」和「计划模式」两个方向来深化 Harness 工程。这两个方向不是随手选的——它们是 Harness 工程中最能体现差异化能力的两个环节也是我从长期 AI Coding 实践经验中提炼出的有效模式。二、记忆功能不做 RAG做「读小说」式的记忆整合提起记忆功能技术圈的第一反应往往是上 RAG检索增强生成。分片、Embedding、向量检索、调召回率——这套流水线已经被讨论了无数次。但经过一段时间的探索和实验我发现 RAG 在记忆场景下存在两个难以逾越的问题。2.1 RAG 为什么不够好第一个问题语义鸿沟。向量模型和生成模型之间存在天然的理解差异。Embedding 认为语义相近的片段LLM 可能认为毫无关联反之亦然。这不是调优召回率能解决的问题——两个模型的语义空间本质上不对齐。即使你把 Top-K 从 5 调到 20多召回的片段可能只是看起来相关的噪音。第二个问题片段式理解的危害。分片检索天然丢失了上下文。一段记忆被切成三块每块单独看语义都没问题但拼回去的理解却是歪的——就像一个故事被剪成碎片随机排列你得到的不是一个完整叙事而是一堆孤立的、可能互相矛盾的陈述。2.2 换个思路从「检索」到「回忆」试想一下当你在读一本 100 万字的小说不可能一次性读完甚至要读好几天。那么当隔天重新拿起这本书时你是怎么召回前文的你不是把全书切成 512-token 的片段再向量检索。你是在大脑里快速过一遍上次发生了什么关键人物是谁核心矛盾是什么形成几个压缩过的心理锚点然后继续往下读。AinoWork v2.0 的 Auto-Memory 就是按这个思路设计的每次发起新对话时用一个 LLM 把所有记忆文件重新整理成一份结构化摘要注入系统提示词。不做检索做回忆。具体实现上Auto-Memory 是一个双层整合系统全局整合层每次新对话启动时检查是否有记忆文件被创建或修改。如果有变更change-gated而非 time-gated按重要性从高到低分批发送给一个专用的整合模型temperature0.3max_tokens2048合并为一份不超过 8,000 字符的结构化摘要按 Preferences、Conventions、Environment、Decisions 四个主题组织写入AUTO-MEMORY.md。项目级提取层在项目会话中每 N 轮默认 10 轮分析对话记录提取项目相关的知识技术栈偏好、架构决策、环境配置等写入项目作用域的AUTO-MEMORY.md。一个值得注意的设计整合是 change-gated 而不是 time-gated 的。如果用户没有写入新记忆就不会触发 LLM 调用——这意味着 LLM 成本与实际写入活动成正比而不是随时间累积。2.3 艾宾浩斯遗忘曲线记忆需要「遗忘」机制一个反直觉的设计好的记忆系统不是记住越多越好。无关记忆挤占上下文窗口就是噪音。v2.0 引入了一个基于艾宾浩斯遗忘曲线的衰减引擎每条记忆拥有importance_score0-1和decay_factor默认 0.9即每天衰减 10%重要性随时间递减new_score importance_score × decay_factor^days_since_access当记忆被检索通过memory_search读取重要性自动 boost ×1.05模拟间隔重复强化上限 1.0当日被访问的记忆不衰减三个关键阈值控制整个生命周期阈值默认值含义注入阈值injection0.2低于此分数的记忆不注入系统提示词归档阈值archive0.05低于此分数的记忆进入归档候选连续归档周期3 次连续 N 次低于归档阈值才真正归档以默认参数计算一条初始重要性 1.0 的记忆如果从未被访问大约30 天后会降到 0.05 以下再经过 3 个衰减周期确认后进入archive/目录。2.4 记忆注入的优先级链系统提示词中记忆的注入遵循一条明确的优先级链这套链路的设计要点当 AUTO MEMORY 可用时它替代而非叠加 PERSISTENT MEMORY。两者不会同时注入——因为 AUTO MEMORY 本身已经是从 PERSISTENT MEMORY 中提炼出的精华同时注入反而是冗余。此外整合是变化驱动的——没有新写入就不触发 LLM 调用成本与写入活动成正比。三、计划模式澄清 → 计划 → 执行的三段式工作流计划模式是人与模型之间沟通的重要机制。它承担着几个核心职责「澄清事实」、「对齐见解」、「让工作流可视」、「尽可能完整地执行一个任务」。在模型尚未完全能自主做事之前这些可控性显然是非常重要的。3.1 同类工具的实践对比在讨论 AinoWork 的实现之前先看看市面上几种典型的计划模式设计工具实现方式特点推测Hermes-Agent 原生Plan 作为 Skill通过增强用户消息实现单一职责——“写 plan.md不干别的”源码可见简单直接Trae Solo拆分为/Spec和/Plan两个指令独立的 Loop 工作流编程场景优化的提示词推测内置指令 独立流程Claude Code内置计划文件追踪当前会话与计划文件绑定态状态追踪 可见性措施系统提示词 增强用户消息推测双层注入 独立 LoopAinoWork v2.0连续多轮对话形式澄清/计划/执行三阶段AI 自主选择工作流深度弱限制提示词消息增强 状态机 plan_id 跨轮持久化每种实现都在回答同一个问题如何在不限制模型能力的前提下让人类参与到决策过程中3.2 AinoWork 的设计AI 自主选择深度v2.0 的计划模式引入了三个工作流深度由 AI 根据任务复杂度自主选择核心实现上计划模式的关键设计决策有四个1. 消息增强而非系统提示词修改。PlanModeExecutor读取当前 round 的spec_state和spec_file_path构建阶段适配的消息增强文本以volatile_context_override的方式前置到用户消息之前——而不是去改系统提示词。这意味着计划模式的引导信息与用户的原始消息在同一个通道里到达模型模型的注意力分配更自然。2. plan_id 跨轮持久化。进入计划模式时生成plan-{12位hex}的唯一 ID同一会话内的后续轮次继承这个 ID。所有产物spec.md、plan.md、相关文件都在.aino/plans/{plan_id}/目录下。取消计划时清空plan_id下次进入生成新的。3. 弱限制提示词。这是全文最核心的设计理念。计划模式的提示词不写你必须先做 X 再做 Y而是不设负面工具约束“trust the LLM’s judgment”不强制的模式声明“autonomous assessment, not a rule”丰富的计划编写指导“makes planning engaging rather than something the LLM wants to skip”自然的暂停点“the user will review” 而非 “STOP and WAIT”4. 三段式用户消息增强。根据当前阶段注入不同的上下文阶段spec_state增强内容初始评估null首次进入Plan Mode 介绍 三种工作流深度说明 计划编写指导需求澄清已有spec.md但未确认SPEC 完善引导 代码库研究方法提示计划生成spec_readyspec.md已确认“读 SPEC → 写 plan.md → 等用户确认”执行plan.md 已确认按计划逐项执行3.3 「弱限制」设计哲学的实战验证从源码中可以看到build_spec_phase_context()的三个分支总共不到 100 行提示词。对比一些商业产品动辄数百行的 system prompt 模板v2.0 选择了克制。这个选择的依据是2026 年的主流模型已经足够强了。当模型能自主推理、自主探索代码库、自主判断复杂度时Harness 的职责不是告诉模型每一步该做什么而是告诉模型当前处于什么阶段、有哪些选项可用然后信任模型的判断。但弱限制不等于没限制。三段式设计本身就是一个温和的约束框架——模型知道自己在澄清阶段应该多提问、在计划阶段应该写 plan.md、在执行阶段应该按计划行事。这些约束足够轻量不会压制强模型的能力但对于弱模型来说又提供了足够的结构引导。这正是文章开头提到的 Harness 弹性设计在实践中的体现。四、避坑指南以下是在设计和实现记忆系统、计划模式时踩过的坑。每个坑背后都是一个被推翻的假设。避坑 1RAG 分片大小是伪命题在尝试 RAG 方案时我花了不少时间调 chunk size——256、512、1024 token 都试过。最终发现无论怎么切语义碎片化的问题都不会消失。根因不在分片策略在于向量检索和 LLM 语义理解之间的架构性 mismatchEmbedding 衡量的是文本表面相似度而 LLM 需要的是上下文关联性——这两者之间的鸿沟无法通过调参弥合。如果你发现记忆系统总是差点意思别纠结分片参数了考虑换架构。避坑 2记忆不遗忘等于噪音一开始设计记忆系统时很容易陷入存越多越好的陷阱。但实际跑起来后发现30 天前某次临时调试的配置和当前项目毫无关系却依然占据着系统提示词的 token 配额。没有遗忘机制的记忆系统最终会退化为一个什么都有、什么都找不到的垃圾堆。引入艾宾浩斯衰减后注入提示词的记忆条目从平均 40 条降到了 15 条左右——少了一半但每条都跟当前上下文相关。避坑 3定时触发不如变更触发最初的 Auto-Memory 设计是每 24 小时运行一次整合。很快发现这很蠢用户可能一周不写新记忆却每天白白消耗一次 LLM 调用。改为 change-gated——只在 MemoryRecord 有实际变更时才触发整合——LLM 成本直接跟写入活动挂钩零写入就是零成本。这对个人开发者和小团队尤为重要毕竟不是每个项目都需要每天回忆。避坑 4阶段控制放在 system prompt 里效果很差早期把计划模式的阶段信息“你处于澄清阶段”放在系统提示词中。结果发现当用户消息很长时——比如贴了一大段代码或日志——模型几乎完全忽略了阶段信息。推测原因是 system prompt 在注意力机制中属于背景而用户消息是前景。改为消息增强——把阶段上下文直接 prepend 到用户消息前面——模型对当前阶段的感知准确率提升非常明显。这个教训可以推广不是所有给模型的指令都适合放 system prompt——跟当前任务直接相关的阶段性引导放在消息里更有效。避坑 5弱限制不是零限制在追求最小干预时我一度把计划模式的提示词减到几乎只剩一句话你处于计划模式请制定计划。“结果弱模型完全不知道该干什么——它既可能直接执行跳过计划也可能陷入无限的分析循环。后来才意识到弱限制不等于零限制。三段式设计澄清 → 计划 → 执行本身就是一种温和的约束框架——它不告诉模型每一步该做什么但明确告诉模型你现在处于什么阶段、有哪些选项”。这个层级的引导对强模型来说几乎感觉不到束缚对弱模型来说却是能正常工作的底线。五、总结AinoWork v2.0 不是一次功能堆叠而是一次对 Harness 工程深度的重新思考。从把 Agent 搬上 Web到让 Agent 拥有真正的记忆和计划能力本质上是在回答一个问题当模型越来越强人类应该以什么姿势与 AI 协作记忆功能放弃 RAG 而选择读小说式的整合模式计划模式放弃强限制而选择弱限制的三段式——这两个选择背后的逻辑是一致的Harness 的职责不是替代模型思考而是为模型创造一个能充分施展的「工位」。下一步我会继续观察不同模型在弱限制计划模式下的表现差异以及艾宾浩斯衰减参数在不同使用场景下的最优配置。如果你对 Harness 工程设计有想法或踩过类似的坑欢迎交流。常见问题Q不做 RAG 做回忆是不是意味着放弃了精确检索A这是一个需要正视的取舍。RAG 的优势在于找到包含关键词 X 的那段话——精确、可复现。但记忆场景的核心需求往往不是找到那段话而是在当下时刻我需要知道什么。整合模式牺牲了精确检索的确定性换来了跨文件关联理解和冗余消除——比如三份记忆分别记录了同一台服务器的不同配置细节RAG 会返回三个片段让你自己拼整合模型会直接给你一句服务器配置xxx位于 yyy。如果你的场景是知识库问答RAG 仍然更好如果你的场景是让 Agent 在每次对话开始时建立对用户和项目的整体认知整合模式更合适。两者不互斥可以在不同层级配合使用。Q用 LLM 做记忆整合成本会不会失控A这是我最开始也担心的。实际跑下来两个设计让成本很可控一是 change-gated——不写新记忆就不触发不是按时间累积的固定开销二是整合模型可以独立配置一个便宜的小模型比如 GPT-4o-mini 或 DeepSeek-V3不需要用主对话模型。几百条记忆文件整合一次的成本通常在几美分级别。对个人开发者来说一天写几次记忆一个月花不了一美元。Q艾宾浩斯衰减参数怎么定0.9 的衰减因子有什么依据A说实话0.9 这个值不是从论文里推导出来的是从使用习惯反推的。以默认参数算一条记忆从创建到归档大约 30 天——这大致对应一个开发迭代周期。一个 sprint 结束后上个 sprint 的临时调试笔记确实应该降温了。boost 因子 1.05 设得比较保守是为了防止一次偶然的检索就把无关记忆永久钉在活跃区。这些参数最终应该开放给用户调整因为不同场景日常开发 vs 学术研究 vs 运维巡检的记忆保质期差别很大。Q为什么选择消息增强而不是 system prompt 来做阶段控制A这个问题在避坑 4 里详细展开了补充一点设计层面的考量system prompt 每轮对话都会被模型重新处理如果你频繁修改 system prompt比如每轮切换阶段状态会破坏 prompt caching大幅增加首 token 延迟和成本。而消息增强是 per-round 的自然行为不影响缓存策略。另外从模型行为观察来看prepend 到用户消息前的内容在注意力分布中明显比 system prompt 末段更重——这可能跟大多数模型的训练数据分布有关。Q弱限制的设计在弱模型上真的能正常工作吗A诚实地说——取决于多弱。对于当前主流的云端模型GPT-4o、Claude Sonnet、DeepSeek-V3 等弱限制完全够用甚至比强限制表现更好——因为模型有足够的判断力来利用自由度。对于早期的开源小模型7B 以下三段式结构本身提供的基本框架“你在澄清阶段多提问”也勉强能跑但偶尔会出现跳过计划直接执行的情况。有意思的是同样弱限制的提示词在不同模型上的越界方式各不相同——有的过于保守反复确认有的过于激进跳步——这本身就反映了模型的性格差异。在模型能力快速提升的 2026 年我个人倾向于押注弱限制方向给模型留余地比替模型做决定保质期更长。AinoWork 是开源·可私有化的团队 AI 工作台。给 AI 一个工位而不只是一个对话框。GitHubhttps://github.com/oinone/ainoworkGiteehttps://gitee.com/oinone/ainowork你在设计 AI 应用的记忆系统时用的是 RAG 还是其他方案计划模式在你的工作流中扮演什么角色欢迎在评论区分享你的实践和踩坑经验。
AinoWork v2.0：AI 记忆与计划模式的 Harness 工程实践
文章目录一、从 v1.0 到 v2.0一次方向性的重新思考二、记忆功能不做 RAG做「读小说」式的记忆整合2.1 RAG 为什么不够好2.2 换个思路从「检索」到「回忆」2.3 艾宾浩斯遗忘曲线记忆需要「遗忘」机制2.4 记忆注入的优先级链三、计划模式澄清 → 计划 → 执行的三段式工作流3.1 同类工具的实践对比3.2 AinoWork 的设计AI 自主选择深度3.3 「弱限制」设计哲学的实战验证四、避坑指南五、总结常见问题AinoWork v2.0 不是一个功能堆叠版本而是一次方向性的重新思考。本文从 Harness 工程的弹性设计出发拆解「记忆」和「计划模式」两个核心功能的实现思路——不做 RAG、不写死流程而是用更灵活的方式让模型能力真正发挥出来。一、从 v1.0 到 v2.0一次方向性的重新思考v1.0 做的事情很朴素把 Hermes-Agent 从 CLI 搬上 Web加上 Docker 沙箱和多用户 RBAC让一个原本只能单人命令行使用的 AI Agent 变成团队可用的效率工具。这个目标基本达成了——一条命令部署开箱即用每个 Agent 拥有独立的 Docker 容器作为工位。但 v1.0 发布后我意识到一个问题把 Agent 搬上 Web 只是第一步真正的挑战在于 Harness 层的工程深度。什么是 Harness简单说就是模型和用户之间的中间层——它决定模型能看到什么上下文、以什么方式接收指令、在什么约束下执行任务。Harness 工程是基于模型能力的衍生工程这意味着一个核心矛盾真正好的 Harness 设计不是选一边站而是在同一个系统里同时容纳这两种策略。就像给 AI 的工位——你不会给实习生和架构师完全相同的工具配置但他们应该在同一个办公室里工作。带着这个思路v2.0 选择了「记忆」和「计划模式」两个方向来深化 Harness 工程。这两个方向不是随手选的——它们是 Harness 工程中最能体现差异化能力的两个环节也是我从长期 AI Coding 实践经验中提炼出的有效模式。二、记忆功能不做 RAG做「读小说」式的记忆整合提起记忆功能技术圈的第一反应往往是上 RAG检索增强生成。分片、Embedding、向量检索、调召回率——这套流水线已经被讨论了无数次。但经过一段时间的探索和实验我发现 RAG 在记忆场景下存在两个难以逾越的问题。2.1 RAG 为什么不够好第一个问题语义鸿沟。向量模型和生成模型之间存在天然的理解差异。Embedding 认为语义相近的片段LLM 可能认为毫无关联反之亦然。这不是调优召回率能解决的问题——两个模型的语义空间本质上不对齐。即使你把 Top-K 从 5 调到 20多召回的片段可能只是看起来相关的噪音。第二个问题片段式理解的危害。分片检索天然丢失了上下文。一段记忆被切成三块每块单独看语义都没问题但拼回去的理解却是歪的——就像一个故事被剪成碎片随机排列你得到的不是一个完整叙事而是一堆孤立的、可能互相矛盾的陈述。2.2 换个思路从「检索」到「回忆」试想一下当你在读一本 100 万字的小说不可能一次性读完甚至要读好几天。那么当隔天重新拿起这本书时你是怎么召回前文的你不是把全书切成 512-token 的片段再向量检索。你是在大脑里快速过一遍上次发生了什么关键人物是谁核心矛盾是什么形成几个压缩过的心理锚点然后继续往下读。AinoWork v2.0 的 Auto-Memory 就是按这个思路设计的每次发起新对话时用一个 LLM 把所有记忆文件重新整理成一份结构化摘要注入系统提示词。不做检索做回忆。具体实现上Auto-Memory 是一个双层整合系统全局整合层每次新对话启动时检查是否有记忆文件被创建或修改。如果有变更change-gated而非 time-gated按重要性从高到低分批发送给一个专用的整合模型temperature0.3max_tokens2048合并为一份不超过 8,000 字符的结构化摘要按 Preferences、Conventions、Environment、Decisions 四个主题组织写入AUTO-MEMORY.md。项目级提取层在项目会话中每 N 轮默认 10 轮分析对话记录提取项目相关的知识技术栈偏好、架构决策、环境配置等写入项目作用域的AUTO-MEMORY.md。一个值得注意的设计整合是 change-gated 而不是 time-gated 的。如果用户没有写入新记忆就不会触发 LLM 调用——这意味着 LLM 成本与实际写入活动成正比而不是随时间累积。2.3 艾宾浩斯遗忘曲线记忆需要「遗忘」机制一个反直觉的设计好的记忆系统不是记住越多越好。无关记忆挤占上下文窗口就是噪音。v2.0 引入了一个基于艾宾浩斯遗忘曲线的衰减引擎每条记忆拥有importance_score0-1和decay_factor默认 0.9即每天衰减 10%重要性随时间递减new_score importance_score × decay_factor^days_since_access当记忆被检索通过memory_search读取重要性自动 boost ×1.05模拟间隔重复强化上限 1.0当日被访问的记忆不衰减三个关键阈值控制整个生命周期阈值默认值含义注入阈值injection0.2低于此分数的记忆不注入系统提示词归档阈值archive0.05低于此分数的记忆进入归档候选连续归档周期3 次连续 N 次低于归档阈值才真正归档以默认参数计算一条初始重要性 1.0 的记忆如果从未被访问大约30 天后会降到 0.05 以下再经过 3 个衰减周期确认后进入archive/目录。2.4 记忆注入的优先级链系统提示词中记忆的注入遵循一条明确的优先级链这套链路的设计要点当 AUTO MEMORY 可用时它替代而非叠加 PERSISTENT MEMORY。两者不会同时注入——因为 AUTO MEMORY 本身已经是从 PERSISTENT MEMORY 中提炼出的精华同时注入反而是冗余。此外整合是变化驱动的——没有新写入就不触发 LLM 调用成本与写入活动成正比。三、计划模式澄清 → 计划 → 执行的三段式工作流计划模式是人与模型之间沟通的重要机制。它承担着几个核心职责「澄清事实」、「对齐见解」、「让工作流可视」、「尽可能完整地执行一个任务」。在模型尚未完全能自主做事之前这些可控性显然是非常重要的。3.1 同类工具的实践对比在讨论 AinoWork 的实现之前先看看市面上几种典型的计划模式设计工具实现方式特点推测Hermes-Agent 原生Plan 作为 Skill通过增强用户消息实现单一职责——“写 plan.md不干别的”源码可见简单直接Trae Solo拆分为/Spec和/Plan两个指令独立的 Loop 工作流编程场景优化的提示词推测内置指令 独立流程Claude Code内置计划文件追踪当前会话与计划文件绑定态状态追踪 可见性措施系统提示词 增强用户消息推测双层注入 独立 LoopAinoWork v2.0连续多轮对话形式澄清/计划/执行三阶段AI 自主选择工作流深度弱限制提示词消息增强 状态机 plan_id 跨轮持久化每种实现都在回答同一个问题如何在不限制模型能力的前提下让人类参与到决策过程中3.2 AinoWork 的设计AI 自主选择深度v2.0 的计划模式引入了三个工作流深度由 AI 根据任务复杂度自主选择核心实现上计划模式的关键设计决策有四个1. 消息增强而非系统提示词修改。PlanModeExecutor读取当前 round 的spec_state和spec_file_path构建阶段适配的消息增强文本以volatile_context_override的方式前置到用户消息之前——而不是去改系统提示词。这意味着计划模式的引导信息与用户的原始消息在同一个通道里到达模型模型的注意力分配更自然。2. plan_id 跨轮持久化。进入计划模式时生成plan-{12位hex}的唯一 ID同一会话内的后续轮次继承这个 ID。所有产物spec.md、plan.md、相关文件都在.aino/plans/{plan_id}/目录下。取消计划时清空plan_id下次进入生成新的。3. 弱限制提示词。这是全文最核心的设计理念。计划模式的提示词不写你必须先做 X 再做 Y而是不设负面工具约束“trust the LLM’s judgment”不强制的模式声明“autonomous assessment, not a rule”丰富的计划编写指导“makes planning engaging rather than something the LLM wants to skip”自然的暂停点“the user will review” 而非 “STOP and WAIT”4. 三段式用户消息增强。根据当前阶段注入不同的上下文阶段spec_state增强内容初始评估null首次进入Plan Mode 介绍 三种工作流深度说明 计划编写指导需求澄清已有spec.md但未确认SPEC 完善引导 代码库研究方法提示计划生成spec_readyspec.md已确认“读 SPEC → 写 plan.md → 等用户确认”执行plan.md 已确认按计划逐项执行3.3 「弱限制」设计哲学的实战验证从源码中可以看到build_spec_phase_context()的三个分支总共不到 100 行提示词。对比一些商业产品动辄数百行的 system prompt 模板v2.0 选择了克制。这个选择的依据是2026 年的主流模型已经足够强了。当模型能自主推理、自主探索代码库、自主判断复杂度时Harness 的职责不是告诉模型每一步该做什么而是告诉模型当前处于什么阶段、有哪些选项可用然后信任模型的判断。但弱限制不等于没限制。三段式设计本身就是一个温和的约束框架——模型知道自己在澄清阶段应该多提问、在计划阶段应该写 plan.md、在执行阶段应该按计划行事。这些约束足够轻量不会压制强模型的能力但对于弱模型来说又提供了足够的结构引导。这正是文章开头提到的 Harness 弹性设计在实践中的体现。四、避坑指南以下是在设计和实现记忆系统、计划模式时踩过的坑。每个坑背后都是一个被推翻的假设。避坑 1RAG 分片大小是伪命题在尝试 RAG 方案时我花了不少时间调 chunk size——256、512、1024 token 都试过。最终发现无论怎么切语义碎片化的问题都不会消失。根因不在分片策略在于向量检索和 LLM 语义理解之间的架构性 mismatchEmbedding 衡量的是文本表面相似度而 LLM 需要的是上下文关联性——这两者之间的鸿沟无法通过调参弥合。如果你发现记忆系统总是差点意思别纠结分片参数了考虑换架构。避坑 2记忆不遗忘等于噪音一开始设计记忆系统时很容易陷入存越多越好的陷阱。但实际跑起来后发现30 天前某次临时调试的配置和当前项目毫无关系却依然占据着系统提示词的 token 配额。没有遗忘机制的记忆系统最终会退化为一个什么都有、什么都找不到的垃圾堆。引入艾宾浩斯衰减后注入提示词的记忆条目从平均 40 条降到了 15 条左右——少了一半但每条都跟当前上下文相关。避坑 3定时触发不如变更触发最初的 Auto-Memory 设计是每 24 小时运行一次整合。很快发现这很蠢用户可能一周不写新记忆却每天白白消耗一次 LLM 调用。改为 change-gated——只在 MemoryRecord 有实际变更时才触发整合——LLM 成本直接跟写入活动挂钩零写入就是零成本。这对个人开发者和小团队尤为重要毕竟不是每个项目都需要每天回忆。避坑 4阶段控制放在 system prompt 里效果很差早期把计划模式的阶段信息“你处于澄清阶段”放在系统提示词中。结果发现当用户消息很长时——比如贴了一大段代码或日志——模型几乎完全忽略了阶段信息。推测原因是 system prompt 在注意力机制中属于背景而用户消息是前景。改为消息增强——把阶段上下文直接 prepend 到用户消息前面——模型对当前阶段的感知准确率提升非常明显。这个教训可以推广不是所有给模型的指令都适合放 system prompt——跟当前任务直接相关的阶段性引导放在消息里更有效。避坑 5弱限制不是零限制在追求最小干预时我一度把计划模式的提示词减到几乎只剩一句话你处于计划模式请制定计划。“结果弱模型完全不知道该干什么——它既可能直接执行跳过计划也可能陷入无限的分析循环。后来才意识到弱限制不等于零限制。三段式设计澄清 → 计划 → 执行本身就是一种温和的约束框架——它不告诉模型每一步该做什么但明确告诉模型你现在处于什么阶段、有哪些选项”。这个层级的引导对强模型来说几乎感觉不到束缚对弱模型来说却是能正常工作的底线。五、总结AinoWork v2.0 不是一次功能堆叠而是一次对 Harness 工程深度的重新思考。从把 Agent 搬上 Web到让 Agent 拥有真正的记忆和计划能力本质上是在回答一个问题当模型越来越强人类应该以什么姿势与 AI 协作记忆功能放弃 RAG 而选择读小说式的整合模式计划模式放弃强限制而选择弱限制的三段式——这两个选择背后的逻辑是一致的Harness 的职责不是替代模型思考而是为模型创造一个能充分施展的「工位」。下一步我会继续观察不同模型在弱限制计划模式下的表现差异以及艾宾浩斯衰减参数在不同使用场景下的最优配置。如果你对 Harness 工程设计有想法或踩过类似的坑欢迎交流。常见问题Q不做 RAG 做回忆是不是意味着放弃了精确检索A这是一个需要正视的取舍。RAG 的优势在于找到包含关键词 X 的那段话——精确、可复现。但记忆场景的核心需求往往不是找到那段话而是在当下时刻我需要知道什么。整合模式牺牲了精确检索的确定性换来了跨文件关联理解和冗余消除——比如三份记忆分别记录了同一台服务器的不同配置细节RAG 会返回三个片段让你自己拼整合模型会直接给你一句服务器配置xxx位于 yyy。如果你的场景是知识库问答RAG 仍然更好如果你的场景是让 Agent 在每次对话开始时建立对用户和项目的整体认知整合模式更合适。两者不互斥可以在不同层级配合使用。Q用 LLM 做记忆整合成本会不会失控A这是我最开始也担心的。实际跑下来两个设计让成本很可控一是 change-gated——不写新记忆就不触发不是按时间累积的固定开销二是整合模型可以独立配置一个便宜的小模型比如 GPT-4o-mini 或 DeepSeek-V3不需要用主对话模型。几百条记忆文件整合一次的成本通常在几美分级别。对个人开发者来说一天写几次记忆一个月花不了一美元。Q艾宾浩斯衰减参数怎么定0.9 的衰减因子有什么依据A说实话0.9 这个值不是从论文里推导出来的是从使用习惯反推的。以默认参数算一条记忆从创建到归档大约 30 天——这大致对应一个开发迭代周期。一个 sprint 结束后上个 sprint 的临时调试笔记确实应该降温了。boost 因子 1.05 设得比较保守是为了防止一次偶然的检索就把无关记忆永久钉在活跃区。这些参数最终应该开放给用户调整因为不同场景日常开发 vs 学术研究 vs 运维巡检的记忆保质期差别很大。Q为什么选择消息增强而不是 system prompt 来做阶段控制A这个问题在避坑 4 里详细展开了补充一点设计层面的考量system prompt 每轮对话都会被模型重新处理如果你频繁修改 system prompt比如每轮切换阶段状态会破坏 prompt caching大幅增加首 token 延迟和成本。而消息增强是 per-round 的自然行为不影响缓存策略。另外从模型行为观察来看prepend 到用户消息前的内容在注意力分布中明显比 system prompt 末段更重——这可能跟大多数模型的训练数据分布有关。Q弱限制的设计在弱模型上真的能正常工作吗A诚实地说——取决于多弱。对于当前主流的云端模型GPT-4o、Claude Sonnet、DeepSeek-V3 等弱限制完全够用甚至比强限制表现更好——因为模型有足够的判断力来利用自由度。对于早期的开源小模型7B 以下三段式结构本身提供的基本框架“你在澄清阶段多提问”也勉强能跑但偶尔会出现跳过计划直接执行的情况。有意思的是同样弱限制的提示词在不同模型上的越界方式各不相同——有的过于保守反复确认有的过于激进跳步——这本身就反映了模型的性格差异。在模型能力快速提升的 2026 年我个人倾向于押注弱限制方向给模型留余地比替模型做决定保质期更长。AinoWork 是开源·可私有化的团队 AI 工作台。给 AI 一个工位而不只是一个对话框。GitHubhttps://github.com/oinone/ainoworkGiteehttps://gitee.com/oinone/ainowork你在设计 AI 应用的记忆系统时用的是 RAG 还是其他方案计划模式在你的工作流中扮演什么角色欢迎在评论区分享你的实践和踩坑经验。
