十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Codewhale Workflow 外部记忆(External Memory)设计边界:基于 v0.9.0 Cutline 的层划分、可见性与权限原则

Codewhale Workflow 外部记忆(External Memory)设计边界:基于 v0.9.0 Cutline 的层划分、可见性与权限原则 Codewhale Workflow 外部记忆External Memory设计边界基于 v0.9.0 Cutline 的层划分、可见性与权限原则【免费下载链接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.项目地址: https://gitcode.com/GitHub_Trending/de/Codewhale本文解读 CodeWhale 开源仓库中的设计文档 docs/rfcs/WORKFLOW_EXTERNAL_MEMORY.md。该 RFC 回答了一个关键架构问题当 Workflow工作流系统演化到 v0.9.0 之后跨长时运行的外部记忆External Memory应该如何被引入。它是一份设计边界design boundary而非运行时实现——先划定什么该做、什么绝不该做再谈代码。读完本文你将理解外部记忆为何必须保持可选与显式、它与现有 User Memory / Repo Search / RLM Memo / TraceStore / Cached-main 五条记忆与回放层的边界划分、可见性与权限的硬性要求以及未来实现应遵循的落地路线。文档定位原则优先的 Cutline文档自注为Principle-only cutline状态标注日期 2026-07-15并在 v0.9.0 依然有效。它开宗明义地划清了已经存在与仅被提议的边界仓库中已经存在用户记忆/memory命令与remember工具以及 RLM 会话见 docs/MEMORY.md、docs/ARCHITECTURE.md仅被提议、尚未进入代码树层边界表格中出现的 TraceStore、ARMH/RLM memo store、cached-main overlay 等机制名称。这一点提醒读者本文引用到的多数分层表格属于未来的演进路线图真正的落地必须逐个经过设计与评审而不是一蹴而就。把原则与现状区分开是理解该 RFC 的前提。核心决策外部记忆必须可选、显式、可审计RFC 的Decision章节给出 v0.9.0 之后不可动摇的底线外部记忆应保持可选optional与显式explicit。CodeWhale 的正常运行不能依赖它Workflow 不得为长时运行静默开启外部记忆。在此基础上未来版本中外部记忆只能以三种形态出现显式的工作流节点explicit workflow node——其输入、输出、作用域与权限都在类型化的 Workflow IR 中可见可选的插件或技能skill驱动的工具——由用户刻意启用有文档记录的实验documented experiment——其状态可被检查、清空与导出。同时它被明确排除在三种角色之外不能是隐藏的上下文基底hidden context substrate不能是仓库搜索的替代品不能是每次工作流运行的默认后备存储。为什么显式节点是一个硬约束类型化 IR 佐证输入、输出、作用域与权限在类型化 Workflow IR 中可见这一要求并非空话。Workflow 引擎的核心 crate crates/workflow/src/lib.rs 维护着 Rust 侧的类型化 IR 边界其 crate 注释明确写道运行时工具暴露、worktree 应用、回放与模型执行只有在取消与证据evidence语义被证明之后才允许叠加在其上见crates/workflow/src/lib.rs顶部文档注释。WorkflowSpec携带nodes: VecWorkflowNodeWorkflowNode枚举统一建模顺序、分支、循环、展开等各类节点并有专门的校验函数把关节点形态。也就是说如果未来要引入外部记忆就必须先把它提升为一等公民的 IR 节点让validate_workflow_nodes之类的校验路径能看到它的存在——这与隐藏检索hidden retrieval藏在普通 prompt 背后的形态针锋相对。同样的思路也体现在实验性搜索模块 crates/workflow/src/experimental_search.rs 中它自称是authoring and freeze boundary而非新的运行时或调度器并强调 worker 自报结果永远不会被提升为硬门禁证据——防止把不可审计的隐式通道悄悄变成系统默认行为。层边界六层记忆与回放如何分工RFC 的核心是一张层边界表把外部记忆与既有/规划中的记忆和回放层彻底剥离开。这张表是全文的骨架逐层说明如下保留原始英文层名以便对照源码层作用域v0.9.0 之后的规则User memory用户记忆由/memory呈现的小型持久化用户偏好与事实可选开启、归用户所有、不作为工作流证据Repo search / codemap仓库搜索/代码地图从仓库派生的结构与搜索结果可由工作区重建不是记忆日志ARMH/RLM memo会话内记忆会话内工作记忆与精确上下文记忆化命中/未命中遥测可见不构成持久回放证据TraceStore记录工作流、分支、叶子与控制结果确定性回放的来源回放期间不做实时模型调用Cached-main overlay缓存主分支覆盖层经评审与回放后沉淀的经验可检查、可回退绝不改写 Git mainExternal memory外部记忆常规上下文之外的本地或插件支撑的大数据仅限显式节点/插件必须可见且可清空/导出User memory今日唯一的记忆实现表格中的 User memory 是仓库中真实存在的部分。系统文档 docs/MEMORY.md 说明自 v0.9.4 起原生记忆存储native memory store是唯一的记忆系统——以 Markdown 文件为持久源、由 SQLite FTS5 做全文索引完全离线按仓库 git origin 的哈希划分作用域。启用方式环境变量DEEPSEEK_MEMORYon真值1/on/true/yes/y/enabled或在~/.codewhale/config.toml写入[memory] enabled true目录布局~/.codewhale/memory/global/MEMORY.md全局workspace/id/MEMORY.md仓库级 可重建的index.sqlite3FTS5 缓存注入策略启用后系统提示词携带**有边界、带出处provenance**的记忆块最多 32 条 / 12,000 字符global 当前 workspace并明确标记为不可信用户数据而非第二指令层更深层检索通过memory_search/memory_get工具完成写入方式#前缀的 composer 输入、/memory native remember子命令、以及模型侧自动化的remember工具JSON schema 见 docs/MEMORY.md。这与 RFC 中 User memory 的定位完全一致Opt-in、用户所有、不作为工作流证据。它服务于跨会话的偏好与约定如本仓库用 4 空格缩进而不是被 Workflow 当作隐含证据源。ARMH/RLM memo可见的命中/未命中遥测表格要求 ARMH/RLM memo会话内工作记忆与精确上下文记忆化提供可见的命中/未命中遥测且不构成持久回放证据。可见遥测在 IR 中已有对应数据结构crates/workflow/src/lib.rs中的WorkflowMemoUsage携带armh_hits、armh_misses、armh_saved_estimated_tokens以及 provider prompt-cache 的命中/未命中计数见crates/workflow/src/lib.rs的WorkflowMemoUsage定义与add_assign聚合逻辑。这些字段随LeafResult一起被记录使得某个叶子节点是否真的从记忆化中获益可以量化——这正是 RFC 反复强调的可解释性在数据结构层面的落地。另一方面RLM 会话persistent Recursive Language Model REPL 会话今天已经存在于仓库中docs/ARCHITECTURE.md 将其描述为沙箱化 Python REPL支持语义化辅助调用与var_handle输出。RFC 的 status 注记特意澄清目前树中只有 user memory 与 RLM 会话ARMH/RLM memo store 本身仍是提案。TraceStore确定性回放的证据源TraceStore 的规则是记录工作流、分支、叶子与控制结果作为确定性回放的来源回放期间不进行实时模型调用。尽管 TraceStore 尚未进入代码树但其回放契约在 crates/workflow/src/replay.rs 已有扎实的雏形WorkflowReplayTrace由trace_id、leaf_recordsReplayLeafRecord叶子输入哈希 结果与control_recordsReplayControlRecord控制节点结果与生成节点组成WorkflowReplayExecutor以这些记录为输入重放执行关键选项ReplayOptions { allow_live_replay: bool }默认关闭见crates/workflow/src/replay.rs即默认不允许实时live回放——与 RFC回放期间不做实时模型调用互为表里回放应当只依据已记录的证据复现结果而不是重新烧钱调用模型。Cached-main overlay可回退、绝不写 main该层承载经评审与回放后沉淀的经验/教训但要求可检查、可回退、绝不改写 Git main。它把经验沉淀与真实仓库状态彻底隔离任何从运行中提炼出的改进都要先落在这个可逆的 overlay 上经人工/门禁评审后再走正常合入路径。外部记忆行尾的新层外部记忆在表中是独立一行作用域为常规上下文之外的本地或插件支撑的大数据v0.9.0 之后的规则是仅限显式节点/插件必须可见且可清空/导出。把这一行放在表格末尾语义很清楚它是将来要加的第七层而不是对既有六层的暗中替换。可见性要求把记忆做成活动的上下文层而非直觉RFC 给出任何未来外部记忆实现都必须对外展示的六项信息何时处于激活状态由哪个工作流节点或插件拥有它状态存储在哪里它能读取哪些仓库或运行作用域它是否被纳入回放、导出或晋升promotion证据如何检查、清空、固定pin与导出它。原文接着给出了一个判定准则值得原样保留UI 应把外部记忆当作一个活动的上下文层来对待而不是当作看不见的模型直觉。如果一次运行无法解释某条事实为何来自外部记忆那么这个功能就没有准备好作为默认使用。这条解释性原则是全文档最具操作性的验收标准任何记忆引入只要无法在运行结束时间答这条事实从哪来就应视为不成熟。它与前文 IR 中的memo_usage遥测、TraceStore 的ReplayLeafRecord输入哈希是一脉相承的——CodeWhale 的记忆哲学是用出处与可观测性取代黑盒直觉。权限与隐私继承最严格的相关作用域外部记忆必须默认采用最严格的适用作用域RFC 列出四条硬约束不得跨越仓库/工作区边界除非获得显式批准——对应 docs/MEMORY.md 中已有实现的隐私设计workspace 记忆以 git origin 的哈希为 key一个仓库的笔记不会泄漏进另一个仓库的 prompt项目本地配置不得静默启用宽泛的外部记忆读取——防止仓库内一个.toml就把用户本机大范围数据卷进上下文回放必须把外部记忆输入记录为证据或将回放标记为不可用/已分叉diverged——这与 replay.rs 中依据输入哈希 记录结果重放的模型一致证据链缺失时宁可声明回放不可用也不能用猜测补齐导出必须让外部记忆的引用可见但默认不得倾倒私有的原始状态——即导出引用、遮蔽原始数据。推迟的工作与落地顺序RFC 明确列出 v0.9.0 cutline 范围内不做的五件事防止范围蔓延默认开启的 Aleph 风格记忆对所有 Workflow 运行从外部记忆自动晋升进 cached-main overlay在普通 prompt 背后做隐藏检索托管式或共享式外部记忆服务把外部记忆当作 TraceStore 回放的替代品。最后RFC 给出了明确的未来实施顺序建议未来的实现应先从一个只读的类型化工作流节点与一个mock 回放夹具mock replay fixture开始然后再加入任何插件支撑或实时检索路径。这条路线与 Workflow crate 的现状高度吻合目前 crates/workflow/src/lib.rs 中已经存在以 mock 叶子结果leaf_outcomes映射等驱动执行器的测试脚手架而 crates/workflow/src/replay.rs 提供了类型化的 trace/record 结构——两者共同构成先只读节点、先 mock、再谈真实检索的天然试验台。此外相关演进在根 CHANGELOG.md 的 v0.9.0 阶段记录中亦可见端倪例如叶子/控制节点结果记录朝向 TraceStore 契约的方向以及外部记忆保持可选、显式、可见、可清空/导出而不是成为隐藏的默认上下文基底的表述。总结WORKFLOW_EXTERNAL_MEMORY这份 RFC 的独特价值在于它用最小的篇幅划定了一条最清晰的架构红线记忆要分层User Memory 管用户偏好、Repo Search 管可重建事实、ARMH/RLM Memo 管会话内记忆化带命中遥测、TraceStore 管确定性回放、Cached-main 管可逆经验沉淀——各司其职互不越界外部记忆要显式只能是类型化 IR 节点、用户刻意启用的插件/技能工具、或有完整可观测性的实验一切要可审计激活状态、属主、存储位置、作用域、证据参与、检查/清空/导出路径缺一不可数据要守界跨仓库需批准、本地配置不得静默放权、回放证据链断裂即声明不可用、导出不泄私密原始态。对于希望参与 CodeWhale 演进Issues / PRs 欢迎的开发者这份文档给出了进入门槛最低的起点在真实代码库中先建立只读节点与 mock 回放验证再谈任何插件或实时检索。对使用者而言它也意味着一个稳定的承诺——无论未来记忆能力如何扩展默认的、显式的、可解释的 CodeWhale 运行方式不会因为新增记忆层而悄悄改变。【免费下载链接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.项目地址: https://gitcode.com/GitHub_Trending/de/Codewhale创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表