Claude Code 两次 MCP 调用就找到共享契约：Bit Cloud 工程师实测依赖记录能否替代记忆文件
来源The New Stack查看原文
速览
- 空会话无记忆时，构建平台的依赖记录足以让 agent 找到共享契约
- Claude 仅用 read_scope 与 read_components 两次 MCP 调用完成系统发现
- 41 个测试通过、9 个新增筛选测试，改动被限制在应用层
- 记录止步于行为：路由一致性仍需人工核对与测试
- CI 中 MongoDB 集成测试可能被跳过，绿色构建不等于验证充分
- 记忆文件记录意图，依赖记录记录结构与版本，两者互补
- Nx 与 Sourcegraph 也通过 MCP 向 agent 提供图与代码导航
- 作者建议从第一个组件起就记录依赖，事后重建成本更高
- 该测试为演示项目，并发、迁移、恢复等工程工作尚未完成
The New Stack 刊出一位 Bit Cloud 工程师的实测：在一个空工作区、无对话历史、无本地代码的全新 Claude Code 会话中，仅凭构建平台记录的依赖元数据，Claude 通过两次 MCP 调用（read_scope 读取 bit-oss.support 范围、read_components 读取组件）就定位到四个组件的依赖关系，识别出 React 应用与 Express 服务共享同一版本的 ticket 实体，随后用 bit import 导入组件、实现客户端筛选，验证通过 41 个测试（含 9 个新增筛选测试），改动只停留在应用层，未触碰共享实体与服务。但记录止步于行为层：应用 API 文档里列出的 GET /tickets、POST /tickets、PATCH /tickets/:id、POST /tickets/:id/comments 等路由，没有任何机制与真实服务做一致性校验；MongoDB 集成测试在 CI 临时数据库起不来时会跳过，绿色构建并不代表这些测试真的跑过。作者据此提出：记忆文件（CLAUDE.md、AGENTS.md、auto-memory、Projects）记录的是人选择写下的意图，依赖记录记录的是版本创建时自动生成的结构，两者覆盖不同层面，最好配合使用。
关键事实
- 测试在空工作区、无对话历史、无本地代码的全新 Claude Code 会话中进行，提示词为『Add filtering by ticket status and assignee to the support console in bit-oss.support』
- Claude 先调用 read_scope 读取 bit-oss.support，返回四个组件及其依赖，再调用 read_components 读取应用、服务与 ticket 实体
- 四个组件为 React 应用、基于 MongoDB 的 Express 服务、共享 ticket 实体，以及把应用和服务放到同一网关后的平台组件，全部版本化在公开 scope bit-oss.support 中
- 应用与服务依赖同一版本的 ticket 实体，其类文档写明『shared between the support service and the agent-facing app』
- Claude 用 bit import 导入四个组件，在应用内实现客户端筛选，验证报告 41 个测试通过，其中 9 个为新增筛选测试
- 记录未能覆盖行为层：应用 API 文档列出的 GET /tickets、POST /tickets、PATCH /tickets/:id、POST /tickets/:id/comments 路由没有与真实服务做校验
本站视角
对国内做 Agent 与编码工具的团队来说，这篇实测的价值不在『Claude 很聪明』，而在于它把上下文供给拆成了两个可工程化的来源：记忆与依赖记录。记忆（CLAUDE.md、auto-memory、Projects）解决的是意图与决策，依赖记录解决的是结构与版本关系，后者由构建系统在版本创建时自动写入，不依赖任何人判断『这值得记一笔』，也不会随代码演进漂移。这对正在自建 MCP server 或组件平台的团队是可复制的路径：与其让 agent 每次重新读源码猜依赖，不如把依赖图作为一等公民通过 MCP 暴露出去。我们认为，这次测试最有说服力的细节不是两次调用，而是『知道什么被共享，也就知道什么不该动』——改动被限制在应用层，共享实体与服务未被触碰，这正是 agent 进入生产环境后最需要的边界感。但需要指出的是，作者本人是 Bit Cloud 工程师，测试对象就是自家平台，且项目为演示性质、使用预定义账号与公开签名密钥，并发控制、迁移、恢复流程均未完成，因此『两次 MCP 调用』的顺畅程度不宜直接外推到真实生产仓库。更值得警惕的是他自曝的两个盲区：API 文档列出的路由没有任何机制与真实服务校验，MongoDB 集成测试在 CI 临时数据库起不来时会静默跳过，绿色构建因此具有欺骗性。这意味着，依赖记录能告诉 agent 结构，却无法告诉它行为是否仍然一致；对用 CI 绿灯作为合并依据的团队，这是一条应当立刻自查的隐患。需要观察的是，Nx、Sourcegraph 与 Bit Cloud 这类把图或记录通过 MCP 喂给 agent 的做法，会不会成为编码 agent 的标配上下文层，以及当依赖记录与记忆文件冲突时，agent 该信谁——原文没有回答这个问题。
背景与影响
Claude Code 每次新会话都从零开始，agent 需要重新发现架构：哪个服务拥有数据、哪个前端调用它、两者共享哪个类型。目前主流解法是记忆：CLAUDE.md 与 AGENTS.md 指令、Claude 自动写入的 auto-memory 笔记，以及 9 月 17 日起在 Claude Code 云会话中 beta 的重新设计 Projects，后者支持跨线程共享记忆，能记住『发布改到周五』或『动计费服务前先找谁确认』这类决策。本文作者是 Bit Cloud 工程师，该公司平台通过 MCP 让编码 agent 参与构建、托管与部署，他测试的是另一类上下文来源：构建平台在创建组件每个版本时写下的依赖记录。这类记录随版本生成、属于该版本的一部分，不会与所描述的版本漂移，且 read_scope 返回的是各组件最新版本，因此 agent 读到的是当前状态。作者认为，记忆记录的是人选择写下的意图，依赖记录记录的是结构与含义，二者覆盖不同层面；Nx 通过 MCP 提供项目图、Sourcegraph 提供跨仓库代码搜索与导航，都做得不错，但他想要的是更窄的东西：每个组件一条在版本创建时写下、且当依赖另一端位于 agent 未索引之处时依然成立的记录。这意味着，随着 agent 越来越多直接接触生产环境，它们真正缺的不是执行能力，而是对即将修改的系统的视图，而这个视图在第二个组件出现之前构建成本最低。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。
