Agent每次接新任务都像新人第一天入职？带你告别“一次性智能”

关注腾讯云开发者，一手技术干货提前解锁👇

代码能告诉我们系统现在怎样工作，却很少解释它背后的演进过程。 一个看似普通的改动背后，可能已经排除过几种方案：某个组件为什么没有复用，某个接口为什么保留旧实现，某条看起来多余的限制究竟防过什么问题。这些判断形成于需求讨论、代码评审，以及工程师与 Agent 的共同探索，却未必会在后续任务沿用。功能最终上线，这些判断很容易停留在当时的上下文里。 下一次类似任务到来，新的 Coding Agent 可以重新读懂代码，却仍要从头恢复这些背景。Forge Memory 就从这个问题开始：怎样让一次任务形成的工程判断，真正进入下一次任务？ 本文复盘我们如何围绕这个问题，一步步把工程判断变成项目知识，再让这些知识进入真实的 AI Coding 工作流。

关于 Forge

Forge 是我们团队围绕 AI Coding 任务构建的一套工程化执行框架，把需求约束、代码探索、实现修改、测试验证以及任务后的知识沉淀组织进同一条任务闭环。OpenSpec 负责明确一次任务要做什么，Harness 负责让 Agent 在工程上下文与执行约束下完成任务，Memory 则负责把一次任务中形成的有效工程判断带入后续任务。

今天的 AI Coding 已经能够在一次任务中完成相当复杂的工作：理解需求、探索代码、提出方案、修改实现，再根据测试和 Review 继续修正。Forge Memory 关心的是任务结束以后方案的比较、边界判断、失败经验和取舍条件，诸如此类的思考过程以及结论怎样留下来？下一次任务又怎样在合适的时机找到并使用它们？

保存对话、整理文档、建设检索和扩大上下文都是在帮助项目保留与获取信息，也是知识能够工作的基础。Forge Memory 在此之上处理知识资格：哪些任务经验值得长期保留，哪些已有知识适合进入当前任务，以及它们被使用后怎样接受代码、验证结果和团队成员的持续校正。

01

一次任务形成的工程判断，怎样进入下一次任务

工程判断并不是在任务结束的一刻突然消失。它从形成到再次使用，需要跨过三个不同的断点：代码能否表达选择理由，任务经验能否成为长期知识，已经保存的知识能否在正确的任务中真正影响判断。

1.1 工程判断跨任务流动的三个断点

最终代码难以完整表达选择理由，一次任务形成的判断未必进入长期知识，已经保存的知识也未必会在正确的任务中被找到和采用。三个断点对应三类不同的设计问题。

断点一：代码留下了结果，理由慢慢消失

第一个断点发生在代码与理由之间。Agent 可以重新读取调用链，却很难从最终实现还原曾经比较过的方案、被排除的路径和选择成立的条件。代码回答“现在是什么”，不总能回答“为什么如此、什么变化会使它不再成立”。软件架构知识研究把设计理由随实现演进而消失称为 knowledge vaporization [5]。

测试也有类似边界。它能证明某个行为在给定条件下成立，却通常不会解释团队为什么选择这条依赖方向，或哪个替代方案曾因维护成本被放弃。理由如果只存在于 Review 和对话里，时间久了就只能靠参与者回忆。

断点二：任务交付了，经验没有进入下一次任务

第二个断点发生在任务之间。一次任务可能已经确认了接口边界、故障根因或验证路径，但这些判断常常只存在于对话、Code Review 和参与者记忆里。任务结束后，代码被提交，经验却没有成为下一位开发者和下一个 Agent 可以共同访问的工程资产。

这和新同学接手一个老项目很像。代码都在，文档也不一定少，但他仍会不断问：“为什么这里没有按常见写法做？”熟悉项目的人往往知道答案：也许这段实现背后是为了兼容历史技术债务；也许上游系统只能这样配合；也许更漂亮的重构能省几行代码，却会同时触碰五条已经稳定运行的链路。新人可以通过踩坑、Code Review 甚至一次次追问慢慢补齐这些背景；Agent 的困难在于，每个新任务都可能重新从“新人第一天”开始。

因此，项目知识把过去依赖老成员口传的判断依据，变成新人和 Agent 都能在需要时找到的工程上下文；当前代码继续提供实现事实和验证基础。

这个断点不能靠“把所有对话永久保存”解决。任务过程里有大量试探、临时输出和只对当时环境成立的细节。它们适合保留为轨迹，却不都值得升级为长期知识。系统还需要区分结果、经验和噪声。

断点三：知识保存了，却没有真正进入决策

第三个断点发生在保存与使用之间。即使团队把任务总结写进 Wiki 或文件，后续任务也未必知道它存在、是否仍然正确、适用于哪里，以及应该怎样影响当前方案。个人使用 AI 时，使用者还能靠自己的记忆补足；多人协作中，知识的生产者、使用者和人工审阅者往往不是同一个人，任务还会跨越会话、分支和 Coding 工具。“某个 Agent 曾经知道”不等于“团队下一次仍然能够使用”。

更长的上下文扩大了 Agent 可以接触的信息范围，接下来仍要解决信息如何被选择和使用。Lost in the Middle 表明，相关信息在长输入中的位置会显著影响模型的利用效果 [1]。即使一条知识被系统选中，Agent 也可能没有打开正文，或者读到了却没有改变任何判断。

三个断点连起来以后，问题才清楚：系统要保存的不是越多越好。它需要识别有价值的经验，把它放到正确的任务里使用，再用当前代码、任务结果和人工审阅意见继续校正。

1.2 Forge Memory 的四个建设目标

Forge Memory 位于上下文工程、长期记忆、代码仓库探索与工程知识治理的交叉位置。上下文工程控制当前任务读什么，代码检索与图谱帮助恢复当前实现及其结构关系，长期记忆维持跨任务连续性，知识治理处理来源、冲突和责任。Forge Memory 把这些能力连接到工程任务闭环中：任务里的设计理由、适用边界和失败经验被组织成可审阅、可追溯的项目知识，通过读取准入进入相关任务，并在使用后通过沉淀准入，结合当前代码和验证结果继续校正。

围绕这条生命周期，Forge Memory 形成了四个相互制约的建设目标：连续性、准确性、安全性和复利性。

连续性：让上一次判断成为下一次输入

连续性让经过验证的工程判断跨过任务边界。新的任务可以先知道项目曾经遇到过什么、哪些边界已经确认、哪些问题仍然没有答案，无需依赖整段聊天才能恢复背景。

这种连续性还要跨越成员和工具。知识生产者、后来的使用者和最终审阅者可能不是同一个人，下一次任务也可能发生在新的会话、分支或 Coding 工具中。只有当知识脱离单次对话，又保留来源和适用范围，它才真正成为项目资产。

准确性：把有限上下文留给真正相关的内容

知识长期存在，不代表每次任务都应该读取。项目对象越来越多以后，全量塞入上下文只会把噪声和成本一起带进来。读取侧需要先根据任务、模块、文件和概念缩小范围，再由 Agent 判断当前是否适用。

一次推荐只是任务开始时的候选。Agent 探索代码后会获得新线索，阅读范围应当随之调整。准确性关注关键知识能否在需要它的时候进入任务。

安全性：控制错误知识的影响

写入长期知识的门槛应当高于写一段任务总结。同义内容需要合并，局部经验不能被写成全局原则，证据尚未闭合的冲突也不能直接覆盖旧结论。

读取侧同样要防止失效知识继续影响实现。过期的知识不再默认推荐，高风险约束需要人工确认；知识被召回以后，还要回到当前代码和验证结果检查。漏掉一条知识会增加探索成本，一条错误规则长期生效则可能持续把任务带向错误方向。

复利性：成熟经验最终进入工程系统

有些知识仍需要 Agent 阅读和判断，比如设计理由和架构模型；另一些结论经过反复验证后，已经可以直接交给规则或工具执行。这时继续让模型每次重新理解并不划算。

稳定约束可以进入代码检查和结构规范，操作手册可以下沉为可调用能力或工具，关键边界可以进入测试。知识对象保留它们从哪里来、为什么成立，工程机制负责稳定执行。项目经验因此不只被反复阅读，也会逐步改变项目本身。

这四类价值互相牵制。为了连续性而什么都保存，会伤害准确性；为了召回更多而放松门槛，会伤害安全性；知识永远停留在文档里，又很难形成复利。Forge Memory 后面的知识建模、准入和验证设计，都是在这些拉扯中形成的。

02

从任务记录到知识运行时：Forge Memory 的建设路径

2.1 阶段一：先让任务经验留下来

最初的假设很简单：会话结束后别什么都丢。于是我们用 Daily 日志让任务中的观察和候选经验低成本留下来——每天追加、不限格式、不需要预先分类。

这一步解决了"留下来"，但很快暴露了三个问题：

• 事实与猜测混在一起。同一份记录里可能同时出现确认的代码事实、临时推断和待验证线索。后来的任务无法区分哪些结论已经站住了。
• 没有稳定身份。一个判断如果分三次补充，只能追加三段文字，无法落回同一条知识进行修正。
• 只能增长，不能收敛。记录越来越多，后续任务在里面找有用信息的成本也越来越高。

长期记忆研究对这个困境有直接的解释：长期记忆的难点从来不只是保存和召回，还包括更新、拒绝和遗忘 [9][10]。旧结论可能被新证据推翻，也可能只是在新的范围内不再适用；缺少长期价值的内容如果持续累积，会让后续筛选和审阅的成本不断升高。Daily 日志恰好把这三件事全部回避了——它没有机制区分"该留"和"该忘"。

问题从"怎么保存"转向了"什么东西有资格长期影响后续任务"。

2.2 阶段二：从"记录"转向"知识对象"

这是第一个架构转折。我们不再问"怎么多保存一些"，而是问"一条信息要带哪些属性，后续任务才敢用它"。

答案是：稳定身份让后续任务能够修正同一条知识，而不是反复追加；适用范围限制结论被带到哪里；证据记录判断的来路；状态区分草稿、活跃和已归档；修正历史保留每一次变更。

于是知识从"日志里的一段话"变成了带结构的独立对象，存放在独立的知识空间里。具体字段如何表达，第三章展开；这里只说明它们为什么必须出现。

软件架构知识研究长期关注一类相似的损耗：代码保留了设计结果，选择理由却会随着演进逐渐消失 [5]。ADR 的实践也说明，方案、理由和后果需要独立记录，才能在后续变更中被重新审视 [6]。GitHub Copilot Memory 和 Claude Code Memory 目前解决的是跨会话或项目范围的记忆持久化 [3][4]，但工程知识还多一层要求：它需要说明适用于哪些模块、依据什么证据、条件变化后如何修正。这些要求推动了知识对象的结构设计。

这也让冷启动多了一道门槛。初始化时可以先创建知识槽位，但文件存在只说明项目预留了位置，随后仍要根据真实代码补齐内容、通过结构检查后才能进入索引。

2.3 阶段三：从"有知识库"到"双向准入"

知识对象解决了单条知识的质量问题，但对象越来越多以后，两个对称问题同时出现：

• 读取侧：存得越来越多，不等于当前任务都该读。全量塞入上下文只会把噪声和成本一起带进来。
• 写入侧：一次任务有新经验，不等于都应该写进去。低价值经验会增加后续筛选成本，重复内容会造成同一判断出现多个版本。

长上下文研究也说明，知识并不是放得越多越好：相关信息在长输入中的位置会影响模型的利用效果 [1]；Anthropic 对上下文工程的总结也把重点放在高信号信息的选择和按需取用上 [2]。扩大上下文只能提高"可能看见"的上限，任务仍要决定哪些内容值得出现在有限的注意力范围内。

于是出现两道准入门：读取准入先选择可能相关的知识，再由 Agent 结合当前代码判断适用性；沉淀准入则在开发与验证结束后，判断新经验应该被拒绝、合并、新建，还是交由人工复核。沉淀结果又成为下一次任务的候选输入。

两道门的具体判断逻辑——读取侧的分层推荐、写入侧的几种决策——留给第四章展开。这里的关键决策是：系统需要两道门，而不是一道。只有读取准入，知识库会膨胀到难以维护；只有写入准入，好知识也可能淹没在无关推荐里。

2.4 阶段四：从 Agent 自律到职责分层

最初我们把规则写进 Prompt 和 Skill，让 Agent 自己遵守：该读什么、该怎么写、结构应该长什么样。

真实任务很快暴露了问题：

• 对象 ID 分配、文件路径选择、字段校验、状态迁移——这些有明确规则的机械动作，如果每次都靠模型自由输出，错误既频繁又难排查。
• "这条经验是否值得保留""两段知识是否在说同一件事"——这些判断需要项目上下文，写不成确定性规则。
• 会限制后续方案的强约束、证据未闭合的冲突，让 AI 单方面决定风险太高，需要人来确认。

MemGPT 区分长期存储与当前可访问内容 [7]，CoALA 把记忆、结构化动作和决策循环放进同一认知架构 [8]。这些工作给了我们一个直接的参照：持久知识、当前任务上下文和执行动作承担不同职责，可以协作，但边界应该明确。

于是职责被拆成三层：AI 做语义判断，确定性执行层做机械动作，人处理高风险团队事实。混在一起时每一层的错误都很难定位，拆开以后失败点才容易追溯。

几轮演进背后，其实对应着几类已有研究反复讨论的问题。Forge Memory 没有直接复制其中某一种方案。真实任务暴露问题，研究帮助我们理解问题的边界，最终才逐步收敛出对应的工程设计。

2.5 最终形成的整体架构

经过前面几轮收敛，Forge Memory 形成了下面这组责任边界。

项目仓库保存任务协议、当前代码和验证结果；知识数据边界保存任务线索、知识对象与派生索引。AI 负责知识的理解、判断与持续维护，确定性执行层负责路由、写入与校验，Git 与人工审阅承担高风险团队事实的确认责任。

各部分各管一件事：

• 项目仓库保存当前能够运行和验证的事实——代码、测试、任务协议。它回答“系统现在怎样工作”；
• 知识空间保存代码难以表达的工程判断——适用边界、设计理由、排障经验和修正历史。稳定的 ID 与索引让这些经验能够跨任务被找到、更新和纠正；
• AI 是知识的理解者和维护者：判断什么与当前任务相关、什么值得保留，并根据新的代码事实和任务结果持续更新、合并、纠正或淘汰已有知识；
• 确定性执行层是 AI 维护知识空间的工具层：提供读取、路由、校验、写入、索引更新和状态迁移等确定性能力，把语义判断转换成可执行、可检查的结构操作；
• Git 与人工审阅承担治理责任：高风险约束和团队级事实需要经过人工确认，才能进入默认推荐或长期生效。

通过分层，代码事实与知识空间承担不同的职责：代码事实描述系统现在如何工作，知识空间记录团队为什么这样做、遇到过什么问题，以及下一次应该如何判断。AI 持续连接两类信息，并随着任务推进维护知识空间，使已有经验能够跟随代码和项目状态一起演进。

03

什么样的信息可以成为项目知识

3.1 一个知识对象需要记录什么

如果只保存一段自由文本，人当然可以读懂，但它还不足以成为能够长期使用的项目知识。随着任务和知识对象持续增加，系统至少还需要回答几个问题：它为什么存在、适用于哪里、依据是什么、希望改变未来任务的什么行为，以及什么变化会让它失效。

Forge Memory 因此没有把知识对象做成一段更长的任务总结，而是把它拆成两个互补的部分：头部字段负责路由与治理，正文负责表达真正需要被理解和复用的工程判断。

头部字段让一条知识能够被稳定定位和持续治理。稳定 ID 让后续任务能够修正同一个对象；适用范围限制结论被带到哪里；关联文件和摘要为检索提供信号；证据与变更来源保留判断从哪里形成；状态和索引资格则决定它当前是否应该继续参与消费。它们共同解决的是：这条知识能不能被找到、该不该被读，以及后续如何被更新和纠正。

知识对象的结构化字段只承担路由与治理，真正需要 Agent 理解的工程判断仍然保留在 Markdown 正文中，并根据知识角色采用不同结构。以一条决策理由为例，正文会回答当时面对什么问题、最终选择了什么、为什么这样选择、接受了哪些代价，以及什么变化出现后应该重新评估。

实际落盘仍然是一份普通 Markdown，只是在文件头保留少量机器可读信息：

id: D001
type: decision
knowledge_role: rationale
summary: 协议标签继续使用当前解析器，不跨分包复用另一套富文本实现
scope: protocol-label
related_files:
  - pkgAsync/components/protocol-label/parseProtocolHtml

3.2 先决定是否进入长期知识，再决定如何影响 Agent

最早的知识文件更像传统项目文档：系统做什么、接口怎样组织的、代码如何实现的等等，全放在一份说明里。内容看起来完整，Agent 接到任务后其实仍要回到代码确认字段、调用链和异常分支。另外，代码一旦变化，这份说明立马过期失效，这反而会变成对 Agent 的干扰 —— 我们想保存的是项目经验，却不小心造了一份实现副本。

于是我们开始反过来约束知识正文：代码已经能回答的内容尽量都交给代码，知识只保留那些会影响下一次任务判断，但却又很难从当前实现中直接读出来的信息。比如，为什么选择这个方案、哪些边界已经验证过、哪些坑是已经踩过的、排查问题时哪些值得优先探索，以及什么情况下需要重新评估已有结论等等。

定义下来发现，几种不同用途的内容不能都放在一个正文里。有的内容是需要帮 Agent 找到入口，有的是告诉它正常路径怎么走，有的是划定边界不让它越线。把它们拆开之后，"知识类型"决定这条经验归属哪里（是短期记忆 daily，还是长期知识 knowledge）而"知识角色"决定 Agent 读到它以后拿来做什么：

3.3 从阅读入口到系统理解：导航知识与模型知识

Agent 接到任务后，首先需要建立一条清晰的阅读路径。项目里的代码入口、目录关系、关键模块和阅读顺序通常相对稳定，这些信息适合被整理为导航知识。它的作用是帮助 Agent 快速缩小探索范围，知道应该先看哪些文件、哪些目录之间存在关联、哪些位置值得优先确认。拿到这些坐标后，Agent 再回到当前代码中核对具体实现，让导航知识负责“带路”，让代码继续承担最新事实的来源。

当然，找到入口之后，任务有时需要进入更深一层的理解。一个系统的关键逻辑往往分散在多个模块和文件中，单独阅读某个文件只能看到局部，很难快速形成完整的系统认识。模型知识负责组织这些跨文件、跨模块的稳定关系，例如架构边界、模块职责、依赖方向、核心链路、异常处理策略，以及不同部分之间如何协同。它为 Agent 提供的是一张相对稳定的“系统模型”，让后续阅读不再只是逐文件确认细节，而是在已有整体结构的基础上理解当前实现发生了什么变化。

导航知识回答“从哪里开始读”，模型知识回答“这些代码共同表达什么”。前者帮助 Agent 建立阅读路径，后者帮助 Agent 建立系统理解。两者配合后，Agent 可以先获得方向，再形成整体认识，最后回到当前代码确认具体事实。

3.4 从执行步骤到故障定位：操作手册与诊断知识

有些任务的价值来自复用一条已经走通的路径。发布服务、迁移接口、接入组件等工作，通常都带有项目特有的前置条件、执行顺序和验证方式。操作手册负责沉淀这些稳定流程，让 Agent 知道什么情况下可以使用、开始前需要满足哪些条件、应该按照什么顺序推进，以及每一步完成后如何确认结果。它保存的是经过实践验证、能够在同一项目中重复执行的工作方法，使 Agent 在面对相似任务时可以直接沿已有路径推进，同时根据当前代码完成具体实现。

异常任务需要的是另一种知识结构。Agent 此时拿到的通常只是一个现象，需要从观测信号逐步缩小问题范围。诊断知识围绕这条排查过程组织信息：有哪些现象值得观察，可能对应哪些假设，每个假设应该怎样验证，最终根因是什么，修复以后又需要回归哪些位置。随着问题被定位和解决，真正值得留下来的并不只是某一次故障的答案，还包括这次排查过程中建立起来的信号、判断依据和分叉路径。下一次出现相似现象时，Agent 可以沿这些线索更快接近根因，同时结合当前环境重新验证结论。

操作手册回答“这类任务通常怎样完成”，诊断知识回答“出现异常后应该怎样找到原因”。前者帮助 Agent 复用稳定的执行路径，后者帮助它复用已经验证过的排查方法。两者分别覆盖正常执行和异常处理，让项目经验不仅能够告诉 Agent 怎么做，也能在事情没有按预期发生时继续提供方向。

3.5 从方案取舍到候选边界：决策理由与约束规则

很多工程经验发生在代码之外。一个方案最终被采用，往往经过了多种选择的比较，也伴随着性能、复杂度、依赖关系、维护成本等方面的取舍。决策理由负责保存这部分上下文，包括当时面对的问题、考虑过哪些方案、最终为什么这样选择、接受了哪些代价，以及什么变化会触发重新评估。架构决策记录的实践同样强调决策背景、备选方案与后果 [6]。这些信息让 Agent 在后来再次遇到相似选择时，可以理解当前设计形成的原因，并判断原有结论是否仍然适用于新的条件。

有些工程判断经过长期实践后，会进一步形成明确的实现边界。约束规则负责表达这些已经确认、需要在后续任务中持续遵守的限制，例如模块之间允许怎样依赖、哪些数据不能越过边界、哪些方案需要额外审批。它会直接影响 Agent 生成和筛选候选方案，因此需要比一般知识更清楚地说明适用范围、依据、例外条件和重新审视的触发点。随着架构和业务变化，约束本身也需要持续维护；新的事实可能扩大它的适用范围，也可能让原有规则失效。

决策理由回答“当时为什么这样选”，约束规则回答“当前哪些选择可以继续进入讨论”。前者保留方案背后的权衡过程，帮助 Agent 理解和重新评估已有决定；后者把已经确认的边界带入后续任务，在方案形成阶段就影响 Agent 的选择空间。两者共同保存工程决策，只是一个侧重理解过去的判断，一个进一步作用于下一次任务的候选范围。

到这里，一条项目经验已经有了稳定身份、治理字段和明确角色。不过知识能够被保存下来，并不代表它会在下一次任务里自动发挥作用。接下来真正需要解决的是：任务开始时哪些知识应该进入上下文，任务结束后新的经验又如何改变长期知识。

04

知识怎样进入任务，经验怎样沉淀下来

我们把这层机制称为知识运行时（Knowledge Runtime）：它把长期层的资产接进任务，也把任务里形成的新经验接回长期层，两个方向都在回答同一个问题——什么东西有资格穿越"任务/知识库"这道边界。这道边界拆成两扇门：

• 读取准入决定长期层里的哪些内容有资格进入当前任务的视野；
• 沉淀准入决定当前任务里形成的哪些结论有资格改变长期层。

两扇门的分工是这样的：AI 负责语义判断——这条知识是否与当前任务真正相关，应该展开哪条正文，新经验有没有长期价值，与已有对象是同一个判断还是需要新建；确定性执行层负责机械边界——资格过滤、相关性信号计算、推荐数量、写入路径、身份和索引；人工审阅接管无法安全自动解决的高风险事实。

4.1 先看知识地图，再逐步打开正文

我们最开始的直觉是"每次任务把知识目录整个读一遍"。当知识对象只有十几条时，这种做法很直接；当规模持续增长，全量读取会同时带进无关内容、过期风险和上下文预算的挤压。Anthropic 把上下文工程的目标概括为寻找足以提高目标行为概率的最小高信号信息集 [2]，这与我们后来形成的判断一致：读取的重点不是能读多少，而是这次任务真正需要哪些。

读取准入的第一道判断不是相关性，而是消费资格。一条候选对象即便主题与任务高度相关，也不一定应该进入 Agent 视野：未完成的骨架不进入正常推荐，明确停用的知识退出正常消费，结构不完整的对象不能作为有效知识，未经人工确认的约束规则在确认前不会成为默认边界。这些资格判断是纯确定性的一段代码，AI 不参与。约束规则单独走一条更严格的资格链，是因为它和其他五种角色影响 Agent 的方式不同：导航知识和模型知识主要影响 Agent 的探索路径与系统理解，进入任务后仍会接受当前代码核对；约束规则则会更早地缩小候选方案空间，一旦错误生效，可能让合理方案从讨论开始就被排除。

通过资格门以后，系统再依据当前任务已经暴露出的文件、模块、符号、概念和摘要关键词等事实信号缩小范围，达到相关性门槛的对象进入有限的推荐候选，其余保留在知识目录中等待任务途中继续下钻。角色只在候选相关性接近时帮助稳定排序，不替代文件、模块和概念等当前任务事实。一条知识如果没有获得正向相关性证据，不会仅仅因为角色重要就被塞进推荐集合。这一点与前一段的资格判断合起来，构成了整个读取准入的骨架：

扁平的知识目录先经过资格门剔除骨架、停用和结构不合规的对象；任务同时获得一份轻量的知识地图，建立"项目里有哪些知识"的整体视野；与此并行，确定性执行层根据当前任务已经暴露出的文件、模块和概念等事实信号，从有消费资格的知识对象中缩小出有限候选；只有其中被判断为对当前决策重要的少量对象，才由记忆子流程展开正文，并把"这条知识意味着什么"提炼回主任务。

随着代码探索暴露出新的模块、文件、符号或概念，读取准入会重新计算候选。每次读取相互独立，不依赖上一轮调用状态。核心是：先决定值得读什么，再决定正文说了什么。

4.2 读到知识以后，仍然要回到当前代码

准入通过之后，Agent 才开始"消费"知识。这一步的细节，是知识运行时与普通检索增强最实质的区别所在。

第一件事，是知识怎样真正进入主任务。这里要做的是避免把整篇正文塞回主 Agent 的上下文：一是浪费预算，二是主 Agent 并不需要理解知识对象的内部协议，它需要的是这条历史判断对当前任务意味着什么。记忆读取因此发生在一个独立子流程里——记忆子流程在自己的上下文中打开正文，判断这条知识是否与当前任务真正相关，再把提炼后的知识作用返回主 Agent。主 Agent 收到的不是"某模块隔离知识的第 3 段"，而是一句更接近工程判断的表述，例如：“在采用跨模块复用之前，先重新确认当前依赖边界。”

第二件事，是历史判断为什么必须重新验证。知识对象的写入时间总是早于当前任务，代码可能已经动过，模块关系可能已经变化，一条曾经成立的模型知识可能已经不再准确。长期知识保存的是过去某次任务里被证据支撑过的判断，代码才是当前项目的实际状态；二者不一致时以代码为准。长期知识保存过去的判断依据，当前代码负责证明它今天是否仍然成立。

这也是 "读了不等于用了" 的原因。Agent 打开了正文，不代表它必须采纳；Agent 明确表示"这条判断在本次任务中已经不成立"，其实也可以认为是一次有价值的消费。当然，这类反驳本身不会直接修改长期知识 —— 读取准入只读不写。只有本次任务进一步拿到足够验证证据，并在收尾时通过沉淀准入，它才可能修正原对象。允许反驳但让反驳留下证据，才让下一次任务能读到修正过的判断，从而不会继续读到已经失效的旧结论。

4.3 任务结束后，什么值得留下来

一次任务结束时，工作产物大致是三种：代码改动、执行过程中的观察，以及 Agent 在这个过程中形成的、可能对未来有用的判断。前两种由需求规范与工程执行框架负责；第三种，是沉淀准入关心的对象。

沉淀准入默认不写入。一次任务有新发现，不代表长期知识应该增加。判断一条候选是否有资格改变长期知识，按顺序问五个问题：

1. 这是不是未来还会再次遇到的判断？
2. 有没有当前代码或任务结果作为证据？
3. 离开这次任务以后，它还能独立成立吗？
4. 是否已经完整到足以让下一次任务理解？
5. 长期知识里是不是已经存在同一个判断？

这五个问题共同得到三个结果，优先级固定：

• 没有长期价值，或事实可以从当前代码低成本恢复 → 不沉淀；
• 长期层里已经存在同一判断的对象 → 更新已有知识；
• 出现了独立的新判断，且证据、边界、失效条件都足够完整 → 新建知识。

也就是：能不增加就不增加，能修正已有对象就不再创建一个新版本。 大多数任务的绝大部分候选会停在不沉淀 —— 修复拼写、执行已有操作手册、验证代码中显而易见的事实，都不应该因为任务完成就制造长期知识；剩下的一部分会走到更新，把新证据、新的适用场景或更精确的边界追加到已有对象；只有跨过全部五个问题的独立新判断，才以新建形式扩大长期层。

冲突顺带处理。新证据与已有判断撞车时，系统不会急着让新内容覆盖旧结论：方向一致就补充，新证据明确推翻旧结论就修正，证据还不足就暂不修改；如果冲突涉及已经确认的约束规则，或者系统无法安全判断哪一方应当覆盖，就停止自动修改并转交人工确认。这四种处理共享同一个前提——新证据本身要先通过前面的独立门与完整门，才有资格进入冲突讨论；证据不足但主题相关的观察不会启动冲突流程，直接停在不沉淀。

一条约束在项目里生效之后，会持续影响 Agent 的方案空间。如果它可以被下一次任务里的一个反例悄悄推翻，等于把改变项目边界的权力交给了 AI。AI 可以提出新的约束候选，但候选不会因为被写入就自动成为项目规则。只有经过人工确认，它才具备默认影响后续方案的资格；已经确认的约束受到新证据挑战时，也不能被 AI 静默改写。

如果证据尚不足以安全改变长期知识，这一次可以什么都不修改，只在返回结果里暴露尚未解决的冲突；只有确实需要保留原始线索时，才显式记录任务现场信息，等到证据成熟时再由后续任务重新走一次沉淀准入。

4.4 一条知识怎样完成一次跨任务循环

任务开始时先看到知识地图，缩小候选并读取少量正文；记忆子流程提炼出对当前任务的作用，主 Agent 结合当前代码执行与验证；任务结束后判断这次经验是否形成长期知识，结果可能是不沉淀、更新已有知识、新建知识或转人工确认，最后进入下一次任务的候选范围。链路中的四类角色——主 Agent、记忆子流程、确定性执行层、人工审阅——各自只做能稳定完成的那一部分。

到这里，Forge Memory 已经完成了从读取、使用、验证到再次沉淀的闭环。新的问题也随之出现：怎样让这套能力稳定进入 AI Coding 的执行过程，同时保持主 Agent 的上下文轻量、职责清晰。

05

把项目知识变成 Harness 的一项轻量能力

5.1 Harness 的上下文取舍

早期为了让 Agent 正确使用项目知识，我们是这样做的：把什么时候读、怎么筛选、怎么展开正文、什么值得沉淀、怎么处理与已有知识的冲突、怎么写入对象，一条一条写进主 Agent 的规则。这样做能让 Agent 看起来"懂"项目知识，代价是每接一个能力都要把它的完整流程翻译一份进主 Agent。能力越完整，需要写进去的内部知识也越多。主 Agent 于是开始花越来越多的认知成本去理解"如何使用项目知识"，而这些内容与它当下正在解决的需求、正在阅读的代码、正在跑的验证并没有直接关系。规则挤占的不只是 token，还有 Agent 对当前任务的整体判断力——它读到的越多，越难分辨这些内部规则和当前具体决策的相对权重。

主 Agent 的注意力应该主要留给需求、代码和验证。随着 Memory 的规则持续增加，我们开始重新考虑一个更基础的问题：主 Agent 使用一项复杂能力时，究竟需要知道多少？

答案是：尽可能少。主 Agent 只需要知道什么时候调用这项能力，以及返回结果对当前任务意味着什么；知识读取、筛选和沉淀的完整规则留在能力内部，不再默认占用主任务的上下文。

5.2 一个入口，在独立上下文中完成完整流程

主 Agent 的能力地图里，项目记忆只保留一个入口。日常任务主要在两个阶段使用它：任务开始时读取可能影响判断的项目经验，任务结束时评估是否形成值得长期保留的新经验。真正需要调用时，知识读取、判断和沉淀流程才在独立上下文中展开；调用结束后，完整过程留在能力内部，精简结果回到主任务。

返回结果主要有三类：

• 对当前任务的知识作用：哪些历史判断与当前任务有关，以及它们可能怎样影响接下来的探索、方案或验证。
• 本次任务的沉淀结果：是否形成值得长期保留的新经验，以及最终是不沉淀、更新已有知识还是新建知识。
• 需要进一步确认的问题：无法安全自动解决的冲突或不确定点，明确交回主任务，由 Agent 继续澄清或交给人工审阅。

这样，主 Agent 接收的是已经提炼过的结论和影响，知识正文、筛选过程和沉淀规则都留在调用期间。它可以继续把主要注意力放在当前需求、代码和验证上。

对 Forge 来说，这也是 Harness 的一个重要作用：它不只是给 Agent 增加规则和工具，更是在组织这些能力以什么方式、在什么时机进入任务。项目记忆因此能够作为一项按需能力持续参与 AI Coding，而不必把完整的知识协议长期留在主任务里。

06

真实任务里，项目知识真的改变了 Agent 吗

回到真实开发，过去留下的判断有没有真正进入下一次任务？它是否改变了 Agent 的探索、让一些已经解决的问题不必重新讨论；又是否在复杂任务开始时能有项目内已经形成的工程判断？只有这些变化能够在真实任务轨迹里被观察到，才能说项目知识真正改变了 Agent 的行为。

6.1 过去经验怎样改变 Agent 的下一步

有经验的开发者遇到一个熟悉的项目问题时，通常不会从现象开始把整条链路重新翻一遍。他可能记得这里过去做过一次架构调整，某个异常曾经和一段特殊的兜底逻辑有关，或者某类数据其实要经过另一条链路。即使还不知道这次是不是同一个问题，这些过去的经验也会自然变成之后几个优先验证的方向。这些经验会影响 Agent 一开始先读哪些代码、沿哪条链路追下去。

如果只有当前需求和代码，就没有这层项目经验。面对同样的现象，它当然也可以通过搜索和逐层阅读最终找到相关实现，但更容易从页面、数据、调用链、异常处理等多个方向同时展开，再一点点排除不相关的路径。问题最后可能同样解决，只是前面又付出了一遍项目探索成本。

而记忆补上的正是这一段缺失的经验。任务开始后，Agent 读到了一条与当前现象相关的已有知识，其中保存了过去确认过的一段架构行为和异常边界。

它没有告诉 Agent 根因是什么，而是让 Agent 很早就意识到：当前现象可能和一条已有链路有关，这个方向值得先确认。于是后面的探索不再是从所有可能位置平铺开来，而是先沿着这条历史经验检查当前实现，再根据代码里的新事实继续收窄范围。历史知识最终并没有直接命中根因，但它让 Agent 更早排除了一个宽泛的解释，并把注意力转向真正值得继续检查的局部路径。

这种帮助更接近一个熟悉项目的开发者给出的提醒：

“我记得这里以前有过一层特殊设计，先看看是不是从这里出来的。”

它肯定不能替代问题排查，也不保证第一次判断就是答案，却让 Agent 不必每次都像第一次进入项目一样，从完整链路重新建立所有可能性。

6.2 方案设计不需要每次都从白纸开始

长期参与项目的开发者通常已经知道，哪些问题以前讨论过，哪些能力已经存在，哪些方案背后有不得不保留的约束。接到新任务以后，他首先做的往往不是重新设计，而是先判断：这次真正新增的问题是什么、有哪些风险和边界、对已有模块有没有什么影响等等。

Agent 如果只有当前需求和代码，这部分历史并不会天然存在。同样地，Agent 当然可以重新阅读实现、搜索调用关系，再逐步得出相同结论，但在此之前，一些已经解决过的问题也很容易重新进入方案探讨当中。

在这次方案调整中，Agent 在探索开始前恢复了几条过去已经确认过的工程判断。其中既包括已有的复用方式，也包括现有流程和调用链上的约束。

这些知识不会告诉 Agent 最终应该选哪套方案，但会提前划出一部分已经明确的边界。后续探索因此不是重新围绕“整个问题应该怎样设计”，而是先继承项目里已经成立的部分，再把注意力放到这一次仍然没有被覆盖的问题上。

面对一个看起来需要新增能力的需求，知识提前恢复了两项已有事实：项目里已经存在可以复用的能力，同时已有接口也形成了明确的调用方式。

对熟悉项目的人来说，这其实是很自然的判断：“这个能力以前已经做过，先确认能不能直接复用。”但没有项目知识的 Agent，并不知道这段历史。它往往需要重新找到接口、实现和调用方，确认项目现在到底具备什么能力，之后才能判断是不是还需要新增设计。

知识补上的就是这一步。让 Agent 从项目已经知道的地方开始思考。

因此，这类任务里省下来的不只是几次搜索。更重要的是，过去已经付出过的设计、比较和验证成本，不会因为任务结束就自动归零。新的方案可以从已有判断继续向前，而不是每次都重新回到白纸上。

6.3 给复杂任务带来的项目上下文

任务一旦跨过多个模块，真正费时间的往往就不只是“找到相关代码”了。

一个长期维护项目的开发者接到这类任务时，脑子里通常已经有一张不完整但很有用的项目地图。他知道某类改动不只涉及眼前的接口，还要沿着协议、依赖和下游链路继续检查；知道某个能力表面上可以直接调用，实际上项目里已经约定了另一条接入路径；也知道一些看起来可以重新设计的地方，背后其实有过去留下来的兼容和工程约束。

这些关系未必集中写在某一份设计文档里，却会随着一次次开发逐渐变成项目成员的共同经验。

没有知识的 Agent 不具备这部分历史。它当然可以搜索代码，也可以逐个理解相关模块，但面对一个跨模块任务，往往需要先从当前实现重新拼出这些关系：这里为什么这样调用、改完这一层还会影响哪里、哪些现有路径可以复用、哪些边界最好不要轻易改变。复杂度越高，这段“重新认识项目”的成本就越明显。

对于复杂任务，已有知识可以在代码探索开始前恢复与当前任务有关的项目背景。它们来自不同位置，分别记录了已有的协议约定、调用方式以及过去形成的一些工程边界。

单独看其中任何一条，都不足以告诉 Agent 应该怎样完成这次任务。真正有价值的是，它们被放到当前任务里以后，重新拼出了一部分只有熟悉项目的人才会天然带着的上下文。同时，也把几条原本需要重新探索才能发现的关系带回了当前任务。

Agent 因此可以带着这些关系进入代码：先确认过去的判断今天是否仍然成立，再沿着已经知道的关联检查真正发生变化的部分，而不是先从一个入口向外扩散，把整个调用链重新认识一遍。

对于表面上只指向一个入口的任务，知识也可以提前恢复几个更重要的背景以及调用关系：真正的契约应该去哪里确认，现有调用遵循什么方式，以及这个入口还和哪些已有关系连在一起，帮助 Agent 确定后续探索方向。

这种帮助很像一个长期维护该项目的开发者在任务开始前告诉你：

“这个版本是在这个模块，但以前这几块是连着设计的，改之前最好一起对一下。”

所以复杂任务里被复用的，不只是某一条具体经验。更重要的是，过去任务已经建立起来的模块关系、工程边界和判断路径，可以成为下一次探索的起点。

Agent 仍然需要回到当前代码确认事实，但它不必每次都先重新认识一遍项目。

6.4 整体效果

在不同的任务中，知识发挥作用的方式也不同：有时只是让 Agent 更早知道该去哪里看，有时把已经做过的方案判断重新带回任务，也有时帮助它在复杂改动开始前恢复一部分项目上下文。

约 70% 的任务中，可以从执行轨迹里看到项目知识被实际读取，并继续影响了后面的探索、方案或实现判断；在探索排查类任务中，也能观察到历史经验帮助 Agent 更早收窄排查范围。

另外，知识进入任务，并没有让 Agent 更依赖历史结论。相反，历史知识更像是在探索开始前提供了一层项目经验，而最终判断仍然需要回到最新的代码里重新确认。

如果沿着任务结束后的结果继续看，读取和沉淀也不是一一对应：近 30% 任务最终明确判断无需产生新的长期知识；40% 以上的任务在完成验证后形成了已有知识的更新或新的知识对象，形成完整“读取—使用—验证—沉淀”过程的任务同样在四成以上。

这意味着知识库并不是随着每次任务机械增长。有些任务只复用了过去经验，有些任务修正或补充了已有判断，也有一部分任务虽然受到了知识的帮助，最后仍然什么都不需要留下。

这种差异其实和真实开发挺接近的：经验有用，不等于每一次工作都值得变成新的经验。

除了“有没有发生作用”，我们还进一步复盘了知识对探索路径的影响。

如果没有这些已经沉淀下来的项目经验，Agent 还需要额外完成代码入口定位、重新梳理调用关系、历史方案确认或排查范围收敛。按照真实任务轨迹进行反向复盘，这部分探索路径通常可以缩短一半以上。

整体看这些任务，知识的作用也并不局限于代码检索。代码查询更需要一个正确的阅读入口，故障排查需要缩小假设空间，方案设计需要恢复已有决策和约束，功能实现则更依赖已有架构与工程边界。不同任务消费的知识不同，但它们减少的其实是同一类成本：已经在这个项目里探索、比较和验证过的事情，不必因为换了一次任务，就全部重新发现。

这也是目前这些真实任务记录能够支持的最直接结论。Forge Memory 没有让 Agent 跳过探索和验证，而是让探索有了项目历史，让新的判断可以从过去已经确认过的位置继续向前。

07

从项目知识到工程知识基础设施

Forge Memory 已经完成了一条项目知识的完整链路：工程判断从任务中形成，被整理成长期知识，在后续任务中重新进入上下文，并随着新的代码和验证结果持续校正。

这条链路目前主要服务 Coding Agent，也首先发生在一个项目内部。但当它真正运行起来以后，我们开始看到更大的可能：Agent 在工程任务中需要持续消费的，不只有项目经验；同一支团队维护多个系统时，知识也需要跨越项目边界，被更多任务和角色使用。

从项目知识出发，Forge Memory 实际上打开了一个更大的问题：不同类型的工程知识，怎样以适合自己的方式进入任务，并逐渐形成团队可以持续积累的知识体系？

7.1 项目知识进入任务的完整链路

把这条链路展开，可以看到项目知识从保存、运行到消费的五种职责。

这条链路看起来是一条从 Git 到 Coding Agent 的调用路径，实际上包含五种不同职责：Git 保存知识来源，Knowledge 定义项目知识资产，Knowledge Runtime 决定知识怎样进入任务并接受校正，CLI 提供访问入口，Coding Agent 则在真实任务中消费这些知识。

这条项目知识链路成立以后，同样的思路还可以继续延伸到 Agent 在工程任务中使用的其他长期资产。除了 Knowledge，它还可能需要执行 Skill、查阅 Document，或者通过 CodeGraph 查询代码结构与关系。

7.2 面向多种资产的工程知识架构

沿着 Forge Memory 这条链路，可以把 Forge 的知识体系进一步拆成来源、资产、运行时、访问入口和消费者五层。每一层承担不同职责，也可以独立扩展新的能力。

来源层：知识从哪里来

知识的物理来源。当前项目知识主要来自 Git。未来随着团队知识和平台化资产增加，来源还可以扩展到独立知识仓库、Database 或其他系统。这一层只负责回答“内容在哪里、怎样取得”，不决定知识对象本身的语义。因此 Git、Database 或未来的服务化存储，可以不断变化，而不需要把这些差异一直暴露给上层 Runtime。

知识资产层：取得以后，它究竟是什么

来源之上需要一个稳定的资产边界。当前 Forge Memory 处理的是 Knowledge：项目里的工程判断、设计理由、约束、操作经验和诊断知识。但工程 Agent 所需要的长期上下文并不只有这一种。未来同一套知识体系还可能容纳 Skill、Document、CodeGraph 等其他资产。它们的内容结构和使用方式并不相同，因此不应该强行全部变成 Knowledge Object；更合适的方式，是在同一个知识包边界下保留不同资产类型。

这一层负责定义：这是什么资产，它的身份和版本是什么，它来自哪里，以及消费者怎样稳定地引用它。它描述的是资产本身，而不是资产应该怎样被执行。

资产运行时：不同资产怎样真正进入任务

再往上一层，是资产的运行时。不同知识形态往往需要不同的使用方式。Knowledge 需要判断相关性、读取正文、结合当前事实验证，并在任务结束后决定是否更新；Skill 更接近可执行能力；Document 可能主要负责检索和引用；CodeGraph 则强调代码结构与关系查询。因此这里可以继续形成不同运行时：

• Knowledge Runtime
• Skill Runtime
• Document Runtime
• CodeGraph Runtime
• …

当前 Forge Memory 就位于这一层的 Knowledge Runtime。它解决的是 Knowledge 这种资产怎样在任务中运行，而不会包办所有资产类型。

Access Layer：消费者通过什么方式进入

运行时之上是访问层。本地 Coding Agent 可以直接通过 CLI 调用；当知识开始服务更多项目和角色以后，还可以继续出现 MCP、HTTP API、Web UI 等入口。它们是不同消费者进入同一套资产能力的方式。

把 Access 单独拆出来以后，同一份团队知识既可以被 IDE Agent 使用，也可以被 Web 产品或其他系统消费，而不需要重新复制一套知识内容。

Consumer：最终是谁在使用知识

最上面才是消费者。今天最主要的是 Coding Agent，因此前面的所有设计首先围绕工程任务展开。但当知识的适用范围扩大以后，同一类资产还可能被工程师、产品、设计以及其他 Agent 使用。不同消费者需要的上下文和呈现方式可以不同，但它们不应该因此拥有互相割裂的知识副本。

这样拆分以后，纵向上，每一种资产都有从来源到消费的完整路径；横向上，每一层又可以独立扩展新的来源、资产、运行方式、入口和消费者。

当不同资产都拥有清晰的来源、定义、运行方式和访问入口，它们就可以在保持自身差异的同时，共同服务不同项目和消费者。这套架构也因此从项目知识，开始走向团队知识体系。

7.3 下一步思考

一条项目经验可以在反复验证以后成为团队共识；知识可以离开最初的 Git 目录，通过稳定的资产边界继续被分发；成熟的判断还可以进一步进入规则、测试、Schema、Skill 和工具，让原本需要人反复记住的经验变成工程系统本身的一部分。

于是，更接近目标的形态，是一套能够让工程知识产生、流动、被使用、被验证，并在足够成熟后进入更稳定的工程机制的基础设施。

对于 AI Coding 来说，这件事可能比单纯增加一次上下文、一次检索或者一次更强的 Prompt 更重要。

模型会继续变强，Agent 也会越来越擅长阅读代码、调用工具和完成任务。但只要每一次任务仍然从当前代码和通用能力重新开始，团队过去已经付出过的工程判断成本就仍然会不断丢失。

真正能够持续积累的系统，应该让 Agent 不只是“会做这一次”，而是让项目在一次次任务之后，越来越知道自己为什么会变成今天这样，也越来越知道下一次应该从哪里继续。

Forge Memory 从其中最小的一条链路开始：让一次任务形成的工程判断，进入下一次任务。当这条链路稳定运行，它所验证的便不只是跨任务记忆，而是一种更普遍的工程知识架构：知识能够拥有清晰的资产边界和运行机制，并在不同项目、角色与系统之间持续流动、接受验证和不断演化。

这也是工程知识从零散经验走向长期基础设施的起点。

References

[1] N. F. Liu, K. Lin, J. Hewitt, A. Paranjape, M. Bevilacqua, F. Petroni, and P. Liang, “Lost in the Middle: How Language Models Use Long Contexts,” Transactions of the Association for Computational Linguistics, vol. 12, pp. 157–173, 2024. [Online]. Available: https://aclanthology.org/2024.tacl-1.9/

[2] Anthropic, “Effective Context Engineering for AI Agents,” 2025. [Online]. Available: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

[3] GitHub, “About GitHub Copilot Memory,” GitHub Docs. [Online]. Available: https://docs.github.com/en/copilot/concepts/agents/copilot-memory

[4] Anthropic, “Manage Claude’s Memory,” Claude Code Docs. [Online]. Available: https://code.claude.com/docs/en/memory

[5] R. Capilla, A. Jansen, A. Tang, P. Avgeriou, and M. A. Babar, “10 Years of Software Architecture Knowledge Management: Practice and Future,” Journal of Systems and Software, vol. 116, pp. 191–205, 2016.

[6] B. Ahmeti, M. Linder, R. Groner, and R. Wohlrab, “Architecture Decision Records in Practice: An Action Research Study,” Zenodo, 2024. [Online]. Available: https://zenodo.org/records/11635100

[7] C. Packer, S. Wooders, K. Lin, V. Fang, S. G. Patil, I. Stoica, and J. E. Gonzalez, “MemGPT: Towards LLMs as Operating Systems,” arXiv:2310.08560, 2023. [Online]. Available: https://arxiv.org/abs/2310.08560

[8] T. R. Sumers, S. Yao, K. Narasimhan, and T. L. Griffiths, “Cognitive Architectures for Language Agents,” Transactions on Machine Learning Research, 2024. [Online]. Available: https://arxiv.org/abs/2309.02427

[9] D. Wu, H. Wang, W. Yu, Y. Zhang, K.-W. Chang, and D. Yu, “LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory,” in Proc. ICLR, 2025. [Online]. Available: https://arxiv.org/abs/2410.10813

[10] M. N. Uddin, K. Shubham, E. Blanco, C. Baral, and G. Wang, “From Recall to Forgetting: Benchmarking Long-Term Memory for Personalized Agents,” in Findings of ACL, 2026. [Online]. Available: https://arxiv.org/abs/2604.20006

-End-

原创作者｜田倬月