新人问："这个接口为什么要用回调而不是同步？"以前只有老员工知道答案。如果 Agent 也能回答呢？
新人上手慢，从来不是因为不会写代码
做了几年技术 TL，带过的新人不少。我发现一个规律：上手慢的新人，几乎都不是编码能力不行。能招进来的，基本功都不差。
卡住他们的是那些"没人告诉你的事"：
- 为什么这个模块的命名风格和其他模块不一样？（三年前从另一个团队接手过来的历史包袱）
- 为什么这里有个 3 秒的延迟？（下游系统有并发限制，当初踩过坑）
- 为什么这个接口不返回全量数据而是分页？（去年双十一出过内存打爆的 P0）
- 为什么这段代码看起来"不合理"却没人改？（核心链路，改的风险远大于收益）
这些知识不在文档里，不在 Wiki 上，不在任何你能搜到的地方。它们在老员工的脑子里，在技术评审的讨论中，在已经关闭的 Issue 和归档的会议纪要中。
新人想了解这些，只能靠问人。老员工永远在忙。
我们做的事情，就是把这些"为什么"沉淀到系统里，让 Agent 也能回答。
把"为什么"沉淀下来
通过结构化的记忆系统，Agent 交互过程中产生的知识可以被沉淀下来。对新人来说：
需求决策有据可查。为什么用户画像模块选了标签体系而不是向量模型？当时讨论了什么、否定了哪些方案、最终选了哪个？这些信息在技术评审时可能只是口头讨论，但如果团队用 Agent 辅助过讨论、整理过会议纪要，系统就会把决策作为原子事实提取出来，聚合到对应的实体卡片中。
技术方案有迹可循。为什么缓存选了 Redis Cluster 而不是 Codis？为什么消息队列选了 RocketMQ 而不是 Kafka？选型背后的考量——性能数据、运维成本、团队熟悉度——都会被记录和关联。
改造历史有因可溯。某个模块为什么从单体拆成微服务？拆分中遇到了什么问题？做了哪些妥协？这些故事往往只存在于当事人的记忆中。通过持续积累，它们变成可检索的知识。
三层记忆架构怎么服务新人
这个三层架构在新人入职场景中的应用比较有代表性。
原子事实层。每一个"为什么"都是一个原子事实。"订单接口使用回调模式是因为支付系统响应时间不可控（2023年8月技术决策）"——带时间戳、置信度和来源标记。新人不需要知道决策细节，只需要知道"这是经过讨论的，不是随便写的"。
实体卡片层。新人要了解"支付模块"时，Agent 直接调出支付模块的实体卡片——技术选型、设计约束、历史改造、已知问题，全在里面。一份自动生成的、持续更新的技术 brief。
记忆图谱层。新人最容易踩的坑是"改了一个地方炸了三个地方"。图谱展示了模块间的依赖关系。新人要改某个接口，Agent 可以提醒："这个接口有三个下游消费方，其中一个是实时链路，建议先和 XX 团队确认。"
一个新人的一天
下面这个场景是理想化的，但能说明方向。
上午 9:00，新人入职，配好开发环境，装上 Coding Agent（已接入知识记忆系统）。
上午 10:00，接到第一个任务——修一个低优先级的 Bug。对着代码看了一会儿，发现一段"看起来多余"的逻辑。问 Agent："这段代码的 if 判断为什么要有？看起来没意义。"
Agent 回答："这个判断是 2024 年 3 月添加的，原因是上游系统在某些边界条件下会传入 null 值，导致过一次线上故障。相关 Issue 编号 #2847。建议保留。"
新人没删那段代码。一个潜在的线上事故被避免了。
下午 2:00，新人开始理解项目结构。问 Agent："为什么我们有两个看起来很像是工具类？能合并吗？"
Agent 回答："OrderUtils和TradeUtils看着功能重叠，但它们分别属于订单域和交易域。团队在 2024 年 Q2 的架构评审中决定保持分离，原因是两个域的演进节奏不同，合并会增加耦合风险。"
下午 4:00，新人提交了第一个 PR。Reviewer 发现他用了HashMap而不是团队约定的LinkedHashMap。被指出来之后，新人问 Agent："为什么要求用 LinkedHashMap？"
Agent 回答："团队约定使用 LinkedHashMap 是因为部分业务逻辑依赖插入顺序。2023 年 11 月确定这个约定，起因是一次 HashMap 无序迭代导致的线上 Bug。详见编码规范文档第 3.2 节。"
新人记住了。下次不会再犯。
说实话，上面的场景是最佳情况。实际使用中，Agent 回答的准确度和知识的积累程度直接相关。如果项目刚开始接入，知识库里什么都没有，Agent 的表现不会比一个什么都不懂的新人好多少。这个方案需要时间来"养"——用得越久，效果越好。
对团队意味着什么
从 TL 的角度看，变化比较明显。
新人上手周期有望缩短。以前要两周，大量时间花在"问人"和"等人回答"上。Agent 能回答一部分"为什么"类问题，新人可以更多地自主探索。当然，"80% 的问题"这个说法偏乐观了，实际比例取决于知识的覆盖度。
老员工时间释放出来了。不用反复回答同样的问题。知识已经沉淀在系统中，Agent 负责传递。
知识流失风险降低。核心成员离职不再等于"项目知识断档"。他们在职时通过 Agent 积累的知识，离职后依然可用。
不只是冷启动
有人会说：知识需要时间积累，新人第一天什么都没有。
目前支持两种启动方式。热启动：导入已有的设计文档、API 文档、技术方案、历史会议纪要。Agent 第一天就有基本的知识储备。冷启动：从零开始，每次团队和 Agent 的交互都在沉淀知识。
建议两者结合——先把核心文档导进去建立基础认知，日常使用中继续补充那些"只有老员工知道"的隐性知识。
目前这套知识记忆能力集成在 RDS ContextDB 中。接入一条命令：
curl -fsSL 'https://context-database-client.oss-cn-hangzhou.aliyuncs.com/install.sh' | bash -s -- --agent <agent> --api-key <api-key>支持 Qoder、Claude Code、Codex、OpenClaw、OpenCode、Hermes、QoderWork 等主流 Agent。
过去，团队知识靠口口相传。效率低，容易丢，因人而异。用系统来沉淀和传递知识，是一个值得探索的方向。
新人入职第一天就能问"为什么"，得到基本准确的答案。这听起来是小事。但带过团队的人知道，光是这一点能省多少时间。当然，不要指望它能完全替代老员工的指导——有些判断力和经验是系统里沉淀不了的。
参考链接
- RDS ContextDB 快速入门 | 产品页
