1. 长会话里 AI 提交为什么总像“金鱼脑”如果你用 AI 助手做过跨文件重构大概率遇到过这个场景一个会话里改了六七个文件涉及接口层、业务层、配置层三四个互相关联的功能点聊了快两个小时。最后你说“帮我提交一下”它给出的 commit message 是update index.js或者只描述了最近五分钟改的那几行。问题不在模型笨而在于上下文窗口是易失的。长会话里早期讨论的设计意图、半小时前处理的边界情况会随着对话推进被稀释甚至挤出有效注意力范围。等到执行git push那一刻AI 手里只剩“最近几条消息”的短期记忆于是提交说明自然只覆盖了尾巴上的改动。更麻烦的是这种丢失是静默的。它不会报错只会给你一份看起来能提交、实际上丢失了全部设计脉络的 Git 历史。等你回头git log想追溯“这个模块当时为什么这么改”发现记录里只有一句fix bug。我试过在提示词里反复强调“提交前先总结全部改动”效果不稳定——模型会答应但执行时依然可能跳过。真正可靠的做法是把“记录修改意图”和“提交前必须回顾”变成工具层面的强制约束而不是靠模型自觉。这就是 MCP Git Server 要解决的问题它给 AI 换上一颗持久化的记忆外挂并用一道审核闸门卡住提交动作。本文交付一套可复制的 MCP Git Server 配置骨架包含持久化修改意图记录save_changes与强制审核闭环get_pending_changes前置校验的完整落地步骤并给出验证动作让你在本地快速确认闭环真的生效。2. 前置准备TaoToken 与 MCP 运行环境MCP Git Server 本身是一个本地进程负责把 Git 操作和修改意图记录暴露成 MCP 工具给 AI 调用。但 AI 侧要能稳定驱动这些工具、在长会话里保持工具调用的一致性模型接入层需要足够稳。这里我用 TaoToken 作为模型接入入口它的 API 兼容主流协议配置成本低适合和 MCP 这类工具链配合。先把接入信息准备好。TaoToken 官网地址是https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 基址是https://taotoken.net/api这个不加 UTM。你需要先在控制台创建一个 API Key后续在 MCP 客户端里配置模型时会用到。控制台入口https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewriteAPI Keys 管理页https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite如果你用的是 Claude Code 这类编码 Agent可以参考它的接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite。Claude Code 专用接入说明在https://taotoken.net/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentClaudeCodeAnthropicutm_campaignrewrite。环境侧需要两样东西Node.js建议 18 以上因为要跑npx和一个已经初始化过的 Git 仓库。确认一下node -v git --version git rev-parse --is-inside-work-tree最后一条返回true就说明当前目录是 Git 仓库。如果不是先git init并至少做一次初始提交否则后续git_push没有可推送的分支。注意MCP Git Server 操作的是你本地的真实仓库配置前建议在一个测试仓库里先跑通闭环确认行为符合预期后再切到主项目。3. 可复制配置MCP Git Server 骨架与持久化参数MCP Git Server 的安装方式很直接npm install -g liangshanli/mcp-server-git它的核心机制是三个工具串成的闭环save_changes负责把“改了哪些文件、为什么改”写进持久化文件get_pending_changes负责读取这些记录并激活推送权限git_push在执行前会校验权限没经过get_pending_changes就直接拦截。持久化落在两个文件上默认都在./.setting目录pending-changes.json存待处理的修改意图记录push-history.json存最近推送历史。这两个文件是物理落盘的会话重启、编辑器关闭都不会丢这正是“持久化”的关键——AI 的记忆不再依赖对话窗口是否还开着。下面是一份可直接粘贴的 MCP 客户端配置以 Cursor / VS Code 的mcpServers结构为例{ mcpServers: { git-server: { command: npx, args: [liangshanli/mcp-server-git], env: { PROJECT_PATH: D:/projects/my-repo, LOCAL_BRANCH: main, REMOTE_BRANCH: main, REPO_NAME: myrepo, TOOL_PREFIX: my, LANGUAGE: zh-CN, MCP_LOG_DIR: ./.setting, MCP_CHANGES_FILE: pending-changes.json, MCP_PUSH_HISTORY_FILE: push-history.json } } } }关键环境变量对照如下变量名作用示例PROJECT_PATHGit 仓库绝对路径D:/projects/my-repoLOCAL_BRANCH本地分支名mainREMOTE_BRANCH远程分支名mainREPO_NAME仓库唯一标识用于隔离日志目录myrepoTOOL_PREFIX工具名前缀多项目隔离用myLANGUAGE交互语言zh-CNMCP_CHANGES_FILE待处理修改记录文件名pending-changes.json配了TOOL_PREFIX: my之后工具名会变成my_save_changes、my_get_pending_changes、my_git_push。多项目场景下给每个仓库配不同的REPO_NAME和TOOL_PREFIX日志和记录文件就会落在各自的.setting子目录里记忆互不干扰。{ mcpServers: { frontend: { command: npx, args: [liangshanli/mcp-server-git], env: { PROJECT_PATH: D:/work/frontend, REPO_NAME: frontend, TOOL_PREFIX: web, LOCAL_BRANCH: main, REMOTE_BRANCH: main } }, backend: { command: npx, args: [liangshanli/mcp-server-git], env: { PROJECT_PATH: D:/work/backend, REPO_NAME: backend, TOOL_PREFIX: api, LOCAL_BRANCH: develop, REMOTE_BRANCH: develop } } } }这样 AI 就拥有两套独立技能组web_save_changes/web_git_push针对前端api_save_changes/api_git_push针对后端各自维护独立的pending-changes.json。4. 验证闭环从 save_changes 到被拦截的 git_push配置写完后重启 MCP 客户端让服务加载新配置。然后按下面的顺序验证闭环是否真的生效。第一步让 AI 做一次小改动然后显式要求它调用save_changes。比如改一个文件后在对话里说请调用 my_save_changes记录本次修改的文件路径和修改意图。调用成功后去仓库目录检查持久化文件cat ./.setting/pending-changes.json你应该能看到类似这样的结构包含文件列表和意图描述[ { files: [src/service/user.js], intent: 重构用户查询逻辑增加空值兜底, timestamp: 2025-01-01T10:00:00Z } ]第二步故意跳过审核直接让 AI 调用my_git_push。如果闭环生效这次调用应该被拦截返回类似“请先调用 get_pending_changes 审查修改记录”的提示。这一步是验证的核心——它证明推送权限确实被get_pending_changes卡住了而不是靠模型自觉。第三步让 AI 调用my_get_pending_changes请调用 my_get_pending_changes读取并总结所有待处理的修改记录。这一步会返回之前保存的全部意图记录同时激活推送权限。此时再调用my_git_push它才会真正执行git add .、git commit并推送。观察生成的 commit message应该覆盖了pending-changes.json里记录的全部改动而不是只描述最后一次修改。第四步推送完成后检查历史记录文件cat ./.setting/push-history.json里面会记录最近几次推送用于防止 AI 重复提交相同逻辑。同时mcp-git.log里会有完整的操作日志方便复盘 AI 每一步调用了什么工具、传了什么参数。如果你在验证时想单独测试模型对工具调用的理解可以用模型对话页快速试一轮https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodelutm_campaignrewrite。长期跑编码 Agent 的话Coding Plan 更适合持续会话场景https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite。5. 本篇常见错排查报错一git_push一直提示需要先审查但明明调过get_pending_changes。检查TOOL_PREFIX是否一致。如果你配了TOOL_PREFIX: my但 AI 调用的是不带前缀的get_pending_changes那它操作的是另一个工具实例权限状态不互通。确认 AI 调用的是my_get_pending_changes和my_git_push这一对。报错二pending-changes.json是空的save_changes 好像没写进去。先确认MCP_LOG_DIR指向的目录存在且可写。默认./.setting是相对于 MCP 进程工作目录的不同客户端启动进程的 cwd 可能不同。建议在MCP_LOG_DIR里写绝对路径比如D:/projects/my-repo/.setting避免路径歧义。报错三多项目下日志串了前端记录跑到后端目录里。这是REPO_NAME没配或配重了。每个仓库实例必须有唯一的REPO_NAME日志和记录文件会按它隔离。检查两个实例的REPO_NAME是否不同。报错四推送成功但 commit message 还是只写了最后一次改动。说明 AI 虽然调了get_pending_changes但没有把返回的记录纳入 commit message 生成。这属于提示词层面的约束可以在系统提示里加一句“生成 commit message 时必须覆盖 get_pending_changes 返回的全部记录逐条对应。”工具保证了“必须回顾”但“回顾后怎么写”仍需要提示词配合。报错五npx启动超时或找不到包。确认 Node 版本在 18 以上并且全局安装成功npm ls -g liangshanli/mcp-server-git。如果网络环境需要走代理在 MCP 配置的env里补上HTTPS_PROXY等变量MCP Git Server 支持标准代理协议。6. 把闭环用成习惯接入与长期编码建议闭环跑通之后真正决定效果的是使用习惯。建议在系统提示里固化两条约束一是“每完成一个独立小功能或修复一个 Bug立即调用 save_changes列出文件并简述意图禁止累积大量变动不记录”二是“推送前必须先 get_pending_changes 完整读取并总结全部记录再生成 commit message”。这样做的价值在于save_changes把 AI 的临时记忆实时固化到磁盘get_pending_changes在提交前强制它重新加载这些记忆。即使会话持续数小时、上下文被稀释落盘的意图记录依然完整。中途如果觉得记录和实际代码有偏差可以让 AI 再调一次get_pending_changes做中场复盘对齐状态。接入层如果还没配好先去 API Keys 页创建密钥https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite具体接入参数看文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite。需要长时间跑编码 Agent、让闭环在多个会话间持续生效的用 Coding Plan 更合适https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite。最后提醒一个实操细节pending-changes.json和push-history.json建议加进.gitignore它们是本地协作状态不该被提交进仓库。验证闭环时先在一个测试仓库跑一遍确认拦截和放行都符合预期再切到主项目避免第一次就在重要仓库上试错。