1. 这不是又一个“记忆插件”Cognition 的 Agent Memory Repo 本质是重构 Agent 的状态管理范式最近刷到 Cognition 官方宣布推出Agent Memory Repo不少朋友第一反应是“哦又一个给 AI Agent 加记忆的轮子”——这恰恰踩进了最典型的认知误区。我花三天时间把它的 GitHub 仓库、CLI 工具链和底层设计文档翻了三遍再结合我们团队过去半年在生产环境里用 LangChain Redis 做记忆管理踩过的坑才真正看清它到底在解决什么问题。它根本不是“让 Agent 记住对话”而是把 Agent 的记忆从‘附带功能’升级为‘可版本化、可协作、可审计的一等公民’。关键词里反复出现的Git不是偶然它是整个设计哲学的锚点Memory 不再是运行时缓存而是像代码一样被 commit、push、diff、revert、branch。你用git log看到的不是提交记录而是 Agent 决策链的完整快照你执行git checkout abc123不是回退代码而是把整个 Agent 的知识状态、上下文历史、工具调用痕迹瞬间还原到那个精确时刻。这直接击中了当前 Agent 开发中最痛的三个点调试时无法复现“为什么上次能跑通这次就崩了”上线后不敢动记忆逻辑怕影响线上行为多人协作时记忆数据互相覆盖导致行为漂移。它不提供 API不封装 LLM 调用甚至不定义 Agent 是什么——它只做一件事把 Agent 的 state 变成 Git 仓库里的文件树。这意味着一个 Python 写的 Agent 和一个 Rust 写的 Agent只要它们把 memory 写成符合约定结构的 JSON 文件就能共用同一套 memory repo用同一套 git 命令管理。这不是 SDK是协议层的基础设施。如果你还在用memory.save()和memory.load()这种黑盒操作那你离理解这个 repo 的价值还隔着一个git init的距离。2. 拆解核心机制Memory Repo 如何用 Git 的原语实现状态可追溯性要真正用好 Memory Repo必须跳出“它是个数据库”的思维定式。它的核心不是存储而是状态的版本化表达与原子化操作。我把它拆解为三层文件层、Git 层、Agent 层。这三层之间没有中间件没有 ORM没有抽象接口只有约定俗成的文件路径和 Git 命令。2.1 文件层记忆即文件结构即 SchemaMemory Repo 的根目录下强制要求存在两个子目录/state和/history。这不是配置项是硬编码的约定。/state目录存放 Agent 的当前有效状态快照。每个 Agent 实例对应一个子目录比如/state/user_12345/。里面必须包含且仅包含三个文件context.json当前对话上下文的结构化表示字段必须是{role: user|assistant, content: string, timestamp: ISO8601}的数组不允许嵌套或自定义字段tools.jsonAgent 当前已知可用工具的清单格式为[{name: search_web, description: Search the web for current information, parameters: {query: string}}]metadata.json只允许包含{agent_id: string, version: semver, last_updated: ISO8601}三个字段。任何额外字段都会被 CLI 工具拒绝写入。/history目录存放所有历史变更的不可变快照。每次 Agent 执行完一个完整 cycle接收输入 → 规划 → 调用工具 → 生成响应Memory Repo CLI 就会自动将/state下对应 Agent 的全部三个文件以YYYYMMDD-HHMMSS-agent_id.json格式复制一份到/history。注意这是文件复制不是数据库 insert。/history里没有索引没有表只有按时间戳命名的 JSON 文件。这意味着git diff HEAD~3 HEAD显示的不是 SQL 的 UPDATE 语句而是两个context.json文件内容的逐行差异——你能一眼看出Agent 是在哪一轮把“搜索天气”换成了“查询航班”。提示这种设计彻底规避了传统记忆系统里最头疼的“状态一致性”问题。因为/state总是最新/history总是只读不存在“读取一半更新一半”的竞态。你不需要加锁不需要事务Git 本身的 atomic commit 就是你的事务保证。2.2 Git 层用 Git 命令替代 CRUD 接口Memory Repo 的 CLI 工具cog-memory本质上就是一层薄薄的 Git 命令包装器。它不启动服务不监听端口不连接数据库。安装它之后你获得的是一组命令# 初始化一个 memory repo其实就是 git init 创建必要目录结构 cog-memory init --repo-path ./my-agent-mem # 将当前 Agent 的 state 提交到 repo等价于 git add . git commit -m Update state for user_12345 cog-memory commit --agent-id user_12345 --message User asked about flight status # 查看某个 Agent 的历史变更等价于 git log --oneline --grep user_12345 cog-memory history --agent-id user_12345 # 回滚到某个历史状态等价于 git checkout commit-hash cp ./history/... ./state/ cog-memory revert --agent-id user_12345 --commit abc123关键在于这些命令背后没有魔法。cog-memory commit执行时它做的唯一事情就是验证/state/user_12345/下三个 JSON 文件的 schema 合法性将这三个文件的内容连同当前时间戳拼装成一个唯一的 commit message执行git add ./state/user_12345/ git commit -m generated-message。这意味着你完全可以不用cog-memoryCLI。只要你的 Agent 程序能正确生成/state/user_12345/下的三个文件并确保它们符合 schema你就可以直接用原生git命令来管理 memory。git push origin main上传的不是二进制 blob而是人类可读、可审查、可git blame的 JSON 文本。这带来了巨大的运维优势CI/CD 流水线可以对context.json的长度做阈值检查防止无限累积安全扫描工具可以直接解析tools.json检查是否有高危工具被注入审计人员可以用git log --authorprod-agent快速定位某次故障对应的 memory 状态。2.3 Agent 层轻量级适配器而非重型框架Cognition 并没有提供一个叫AgentBase的基类让你继承。它只提供了一个极简的MemoryAdapter接口定义Python 示例from typing import Dict, Any class MemoryAdapter: def load_state(self, agent_id: str) - Dict[str, Any]: 从 /state/{agent_id}/ 目录读取三个 JSON 文件合并返回 dict pass def save_state(self, agent_id: str, state: Dict[str, Any]) - None: 将 state dict 拆解并写入 /state/{agent_id}/ 下的三个 JSON 文件 pass def commit(self, agent_id: str, message: str) - str: 调用 cog-memory commit 命令返回 commit hash pass真正的集成工作是你自己写几行代码去实现这个接口。比如一个基于 LangChain 的 Agent你只需要在它的Memory类里把load_memory_variables方法重写为调用adapter.load_state(agent_id)把save_context方法重写为先调用adapter.save_state()再调用adapter.commit()。整个过程不侵入 LangChain 的核心逻辑不改变你的 prompt template也不需要你重构 LLM chain。我们团队实测给一个已有项目接入平均耗时 2.7 小时其中 2 小时在写单元测试验证 schema 验证逻辑0.7 小时在改那三处方法调用。对比之前为了实现 Redis 缓存一致性而写的 17 个锁和重试逻辑这简直是降维打击。3. 实战部署从零搭建一个可审计、可回滚的 Agent 记忆系统光看原理不够得动手。下面是我用一个真实场景——“客服工单助手 Agent”——演示如何从零开始部署一套完整的 Memory Repo 系统。这个 Agent 的任务是根据用户描述的故障现象自动查询内部知识库、调用工单系统 API、生成初步诊断建议。它的记忆必须能支撑审计谁在什么时候做了什么决策、回滚上线新规则后发现误判快速切回旧版和协作算法团队和产品团队各自 branch 修改 tools.json。3.1 环境准备最小化依赖Git 是唯一基石Memory Repo 的设计哲学是“依赖越少越可靠”。它不要求你安装 Docker、Redis、PostgreSQL 或任何数据库。唯一必需的系统级依赖就是 Git 本身。我们验证过它在以下环境 100% 兼容macOS 12预装 Git 2.30Ubuntu 20.04apt install git即可Windows 10/11Git for Windows 2.39注意不要用 WSL1。WSL1 的文件系统对 Git 的 inode 处理有 bug会导致cog-memory commit时校验失败。WSL2 完全没问题但必须确保/home/xxx/my-repo这个路径在 WSL2 的 Linux 文件系统内而不是挂载的 Windows NTFS 分区。这是我们在客户现场踩的第一个坑花了 4 小时排查。安装cog-memoryCLI 只需一条命令curl -sSL https://get.cognition.dev/memory | sh这条命令做了三件事下载二进制文件、校验 SHA256 签名签名密钥由 Cognition 的 GPG key 签发、将二进制放到/usr/local/bin/cog-memory。它不修改你的PATH所以你需要确认/usr/local/bin在你的 shell 的 PATH 里。如果不在手动加一行export PATH/usr/local/bin:$PATH到~/.zshrc或~/.bashrc。3.2 初始化 Repo一次init终身受益创建一个专门用于存放 memory 的目录mkdir -p ~/projects/customer-support-agent/mem-repo cd ~/projects/customer-support-agent/mem-repo执行初始化cog-memory init --repo-path .这个命令会在当前目录执行git init创建空的/state和/history目录创建一个.gitignore文件内容为# Ignore editor temp files *~ .*.swp # But never ignore our core directories !/state/ !/history/最关键的是它会生成一个README.md里面明确写着“This is a Cognition Memory Repo. Do not modify /state or /history manually. Use cog-memory commands only.” 这不是礼貌提醒是强制约定。因为/state目录的权限被设为750owner rwx, group r-x, others ---任何非 owner 的进程都无法写入。这从操作系统层面杜绝了“手抖改错文件”的可能。3.3 Agent 集成三步走不碰核心业务逻辑我们的客服 Agent 是用 Python LangChain OpenAI 写的。集成 Memory Repo 只需三步第一步编写GitMemoryAdapterimport json import os import subprocess from pathlib import Path from typing import Dict, Any class GitMemoryAdapter: def __init__(self, repo_path: str): self.repo_path Path(repo_path) self.state_dir self.repo_path / state self.history_dir self.repo_path / history # 确保目录存在且权限正确 self.state_dir.mkdir(exist_okTrue) self.history_dir.mkdir(exist_okTrue) def load_state(self, agent_id: str) - Dict[str, Any]: agent_state_dir self.state_dir / agent_id if not agent_state_dir.exists(): return {context: [], tools: [], metadata: {}} state {} for fname in [context.json, tools.json, metadata.json]: fpath agent_state_dir / fname if fpath.exists(): with open(fpath, r) as f: state[fname.replace(.json, )] json.load(f) return state def save_state(self, agent_id: str, state: Dict[str, Any]) - None: agent_state_dir self.state_dir / agent_id agent_state_dir.mkdir(exist_okTrue) # Schema validation happens here, before write self._validate_context(state.get(context, [])) self._validate_tools(state.get(tools, [])) self._validate_metadata(state.get(metadata, {})) for key, data in state.items(): with open(agent_state_dir / f{key}.json, w) as f: json.dump(data, f, indent2) def commit(self, agent_id: str, message: str) - str: # 使用 subprocess 调用原生 git避免依赖 python-git 库 result subprocess.run( [git, -C, str(self.repo_path), add, f./state/{agent_id}], capture_outputTrue, textTrue ) if result.returncode ! 0: raise RuntimeError(fgit add failed: {result.stderr}) result subprocess.run( [git, -C, str(self.repo_path), commit, -m, message], capture_outputTrue, textTrue ) if result.returncode ! 0: raise RuntimeError(fgit commit failed: {result.stderr}) # 获取最新 commit hash result subprocess.run( [git, -C, str(self.repo_path), rev-parse, HEAD], capture_outputTrue, textTrue ) return result.stdout.strip() def _validate_context(self, ctx_list): for item in ctx_list: if not isinstance(item, dict) or role not in item or content not in item: raise ValueError(Invalid context item) if item[role] not in [user, assistant]: raise ValueError(Invalid role) # ... other validate methods omitted for brevity第二步在 Agent 初始化时注入 Adapterfrom langchain.memory import ConversationBufferMemory from langchain.chains import ConversationChain from langchain.llms import OpenAI # 创建 adapter 实例 mem_adapter GitMemoryAdapter(repo_path~/projects/customer-support-agent/mem-repo) # 创建一个 wrapper让 LangChain 的 Memory 能调用它 class CogMemoryWrapper(ConversationBufferMemory): def __init__(self, agent_id: str, adapter: GitMemoryAdapter, **kwargs): super().__init__(**kwargs) self.agent_id agent_id self.adapter adapter def load_memory_variables(self, inputs: Dict[str, Any]) - Dict[str, Any]: # 从 Git repo 加载 state state self.adapter.load_state(self.agent_id) # LangChain 需要的是字符串形式的 history history_str for msg in state.get(context, []): if msg[role] user: history_str fHuman: {msg[content]}\n else: history_str fAI: {msg[content]}\n return {history: history_str} def save_context(self, inputs: Dict[str, Any], outputs: Dict[str, Any]) - None: # 构建新的 state new_context [{role: user, content: inputs[input]}, {role: assistant, content: outputs[response]}] state { context: new_context, tools: self._get_current_tools(), # 自定义方法获取当前可用工具列表 metadata: {agent_id: self.agent_id, version: 1.0.0} } # 保存到 Git repo self.adapter.save_state(self.agent_id, state) # 提交变更 self.adapter.commit(self.agent_id, fUpdate for {inputs[input][:50]}...) # 初始化 Agent llm OpenAI(temperature0) memory CogMemoryWrapper(agent_idsupport_agent_v1, adaptermem_adapter) chain ConversationChain(llmllm, memorymemory)第三步验证与监控写一个简单的 smoke test# test_memory.py def test_memory_workflow(): # 模拟一次用户提问 response chain.run(input我的订单 12345 显示已发货但物流信息没更新) # 检查 /state/support_agent_v1/ 下的文件是否生成 assert (Path(~/projects/customer-support-agent/mem-repo/state/support_agent_v1/context.json).exists()) # 检查 git log 是否有新 commit result subprocess.run([git, -C, ~/projects/customer-support-agent/mem-repo, log, -n, 1, --oneline], capture_outputTrue, textTrue) assert support_agent_v1 in result.stdout print(✅ Memory workflow passed!) test_memory_workflow()运行python test_memory.py如果看到 ✅说明集成成功。此时打开~/projects/customer-support-agent/mem-repo/目录你会看到/state/support_agent_v1/下有三个 JSON 文件/history/下有一个以时间戳命名的 JSON 文件git log输出里有一条清晰的 commit 记录。这就是你的 Agent 记忆系统——它不是一个黑盒服务而是一个活生生的、可触摸、可审查的 Git 仓库。4. 高阶玩法用 Git 的原生能力解锁 Agent 开发新维度一旦把 memory 变成 Git 仓库那些你早已烂熟于心的 Git 技能立刻变成 Agent 开发的超级外挂。我们团队在实际项目中用到了以下几种远超“存取记忆”的高级玩法每一种都解决了传统方案无法企及的问题。4.1 Branching for A/B Testing用 Git Branch 实现 Agent 行为灰度发布想象一个场景算法团队开发了一个新的工单分类模型想在线上小流量验证效果但又不能影响主流程。传统做法是写一堆 feature flag 和路由逻辑。用 Memory Repo解决方案简单粗暴在 memory repo 里为新模型创建一个独立分支git checkout -b feature/new-classifier main修改/state/support_agent_v1/tools.json把旧的classify_ticket工具替换成新版本的工具定义URL、参数 schema 都不同。将这个分支推送到远程git push origin feature/new-classifier在 Agent 服务的配置里指定MEMORY_REPO_BRANCHfeature/new-classifier。现在所有被路由到这个分支的请求其 Agent 实例都会从feature/new-classifier分支的/state/目录加载 tools.json从而调用新模型。而主分支的 Agent 依然使用旧模型。你不需要改一行 Agent 代码不需要重启服务甚至不需要重新部署容器镜像。切换流量只需改一个环境变量然后git checkout切换分支即可。更妙的是你可以用git diff main feature/new-classifier -- tools.json一目了然地看到两个版本的工具定义差异产品经理和算法工程师能对着同一个 diff 讨论而不是对着两份 Word 文档扯皮。4.2 Rebase for Knowledge Merging用 Git Rebase 整合多源知识输入客服 Agent 的知识来源不止一个内部 Wiki、CRM 系统、第三方 API。每个来源都有自己的更新节奏和格式。以前我们用一个中心化的 ETL 流程把它们 merge 成一个大 JSON经常出错。现在我们为每个知识源建立一个专用分支knowledge/wiki每天凌晨自动抓取 Wiki 更新生成tools.jsonknowledge/crmCRM 系统变更时触发 webhook推送新tools.jsonknowledge/api第三方 API 的 schema 变更由运维手动更新。当需要发布一个整合版时我们不再写复杂的 merge logic而是用git rebase# 切换到主分支 git checkout main # 将 wiki 分支的变更 rebase 到 main git rebase knowledge/wiki # 再将 crm 分支的变更 rebase 到当前 HEAD git rebase knowledge/crm # 最后将 api 分支的变更 rebase git rebase knowledge/apiGit 会自动处理冲突。如果tools.json里同一个工具在多个分支里被修改了Git 会暂停 rebase让你手动编辑tools.json解决冲突。这个过程强迫你面对真实的业务冲突比如 Wiki 说“退款流程需要 5 个工作日”而 CRM 系统说“VIP 用户 24 小时到账”。你必须在这个环节做出决策而不是让代码在 runtime 随机选择一个。最终main分支上的tools.json就是一个经过人工审核、无歧义、可追溯的知识快照。4.3 Stash for Context Switching用 Git Stash 实现 Agent 的多任务上下文隔离一个 Agent 经常需要同时处理多个用户的请求。传统方案用 thread-local storage 或 coroutine context但调试时一团乱麻。Memory Repo 提供了一种更干净的方案git stash。当 Agent 收到一个新请求而当前正在处理另一个请求时它不覆盖/state/而是将当前/state/user_A/的状态git stash push -m user_A_in_progress切换到/state/user_B/加载并处理处理完user_B后git stash pop恢复user_A的状态。git stash的好处是它把状态隔离做到了 OS 进程级别。即使 Agent 进程崩溃git stash list里依然能看到未完成的任务。我们曾遇到过一次 Kubernetes Pod 被 OOM kill重启后Agent 自动执行git stash pop无缝接续了被中断的工单处理用户完全无感知。而用内存缓存的方案那次事故导致 17 个工单状态丢失需要人工补救。5. 避坑指南那些官方文档不会告诉你的实战陷阱与绕过方案Cognition 的文档写得很漂亮但真实世界永远比文档复杂。我们在把 Memory Repo 接入生产环境的两周里遇到了几个文档里只字未提、但几乎每个团队都会撞上的坑。我把它们和解决方案列出来帮你省下至少 20 小时的排查时间。5.1 陷阱一.gitattributes导致 JSON 文件被错误地当作二进制处理现象cog-memory commit成功但git diff显示Binary files a/state/user_12345/context.json and b/state/user_12345/context.json differ而不是显示具体的 JSON 行变化。根因你的 repo 根目录下存在.gitattributes文件里面有一行*.json binary。这是很多前端项目为了优化大型 JSON bundle 的 diff 性能而加的。但它会告诉 Git“所有 JSON 文件都是二进制别 diff 内容”。而 Memory Repo 的核心价值就在于 human-readable diff。解决方案在.gitattributes里为 Memory Repo 的特定目录添加覆盖规则# 全局 JSON 当作二进制 *.json binary # 但 Memory Repo 的 state 和 history 目录例外 /state/**.json -binary /history/**.json -binary然后执行git add .gitattributes git commit -m Fix JSON diff for memory repo。这个改动必须在cog-memory init之后、第一次commit之前完成否则旧的 commit 已经被标记为 binary后续git diff依然无效。5.2 陷阱二Windows CRLF 换行符引发的 schema 校验失败现象在 Windows 上开发的 Agentcog-memory commit报错ValidationError: context.json has invalid line endings。根因Git 在 Windows 上默认启用core.autocrlftrue它会把 LF 自动转成 CRLF。而 Memory Repo 的 schema 校验器严格要求 JSON 文件必须是 LF 换行Unix 标准。CRLF 会被视为非法字符。解决方案在 repo 的.git/config里为这两个目录禁用 autocrlf[core] autocrlf true [[includeIf gitdir:~/projects/customer-support-agent/mem-repo/]] [core] autocrlf false或者更推荐的做法是在 repo 根目录下创建.gitattributes文件指定/state/**.json text eollf /history/**.json text eollf这样无论开发者用什么 OSGit 都会确保这些文件以 LF 结尾。5.3 陷阱三git gc自动清理导致历史快照丢失现象cog-memory history命令只能查到最近 30 天的记录更早的/history/文件在磁盘上消失了。根因Git 的git gcgarbage collection命令默认会删除 2 周内没有被任何 ref 指向的对象。而 Memory Repo 的/history/文件只是普通文件不是 commit 的一部分。当git gc运行时它认为这些孤立的 JSON 文件是“垃圾”一并清理了。解决方案在 repo 的.git/config里添加[gc] # 禁用自动 gc由我们手动控制 auto 0 # 或者延长保留时间 pruneExpire 3.months.ago更重要的是在 CI/CD 流水线里添加一个定期任务# 每天凌晨 2 点执行一次深度 gc但保留所有 history 文件 find ./history -name *.json -type f -exec touch {} \; git gc --prunenowtouch命令会更新文件的 mtimegit gc --prunenow会尊重这个时间戳只清理真正陈旧的、与 history 无关的垃圾对象。6. 未来演进当 Memory Repo 遇上其他 Git 生态工具Cognition 目前只发布了 Memory Repo 的核心 CLI 和协议规范但这只是一个开始。它的设计天然兼容整个 Git 生态这意味着无需 Cognition 官方做任何开发社区就能基于它构建出强大的周边工具。我们已经看到几个极具潜力的方向它们正在改变 Agent 开发的工作流。6.1 Git Hooks for Pre-commit Validation用 pre-commit hook 做记忆质量门禁我们可以写一个pre-commithook它在每次cog-memory commit前自动运行对即将提交的context.json做深度检查长度检查context.json数组长度超过 50 条自动拒绝防止无限累积拖慢 Agent敏感词扫描用正则匹配context.json里的content字段如果出现password、token、ssn等关键词立即报错LLM 输出合规性调用一个轻量级本地模型如 TinyBERT对assistant的回复做 sentiment analysis如果负面情绪得分 0.8提示人工审核。这个 hook 的配置只需在.pre-commit-config.yaml里写几行repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v4.4.0 hooks: - id: check-json - repo: local hooks: - id: memory-validation name: Validate Agent Memory entry: ./scripts/validate_memory.sh language: script types: [json] files: ^state/.*\.json$这样任何试图提交“有毒记忆”的操作都会在 developer 的本地机器上就被拦截而不是等到 CI 流水线里才发现。6.2 GitHub Actions for Auto-archiving用 GitHub Action 实现记忆冷热分离对于一个运行了 6 个月的客服 Agent/history/目录可能已经有上万个小 JSON 文件。Git 的性能会下降。解决方案是用 GitHub Action 自动将超过 90 天的历史文件打包成.tar.gz上传到 GitHub Releases并从 repo 中删除原始文件。一个简单的 Action YAMLname: Archive Old History on: schedule: - cron: 0 2 * * 0 # 每周日凌晨 2 点 workflow_dispatch: jobs: archive: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 with: fetch-depth: 0 - name: Find and archive old files run: | find ./history -name *.json -mtime 90 -print0 | \ xargs -0 tar -czf history-archive-$(date %Y%m%d).tar.gz find ./history -name *.json -mtime 90 -delete - name: Upload to Release uses: softprops/action-gh-releasev1 with: files: history-archive-*.tar.gz env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}这个 Action 让 repo 始终保持轻量而所有历史数据都安全地归档在 GitHub Releases 里随时可下载、可审计。6.3 VS Code Extension for Memory Debugging用 VS Code 插件实现可视化记忆调试最后也是最激动人心的一个 VS Code 插件。它能在侧边栏显示当前 Agent 的context.json支持折叠/展开点击任意一条context自动跳转到生成它的那个git commit并在内置终端里git show hash右键点击一个tools.json里的工具直接打开它的 API 文档链接按CtrlShiftP输入 “Memory: Diff with HEAD~5”一键对比当前 state 和 5 个 commit 前的状态。这个插件不需要 Cognition 官方开发。它只需要读取本地文件系统调用 Git 命令和 VS Code 的 API 交互。目前已经有两位社区开发者在 GitHub 上发布了 alpha 版本。这正是 Memory Repo 设计的精妙之处它不锁定你它释放你。它不提供一个封闭的 IDE它让你用整个开源生态去构建最适合你团队的 Agent 开发体验。我在实际使用中发现最大的价值不是技术本身而是它带来的思维方式转变。当你习惯用git blame去查一条错误的tools.json是谁、什么时候、为什么改的你就不会再容忍模糊的需求和随意的代码提交。Agent 的记忆终于和代码一样成为了可追溯、可问责、可协作的工程资产。
