Indie developer building games & open-source tools Sharing model impressions and opinions on AI Devin Ambassador @cognition
Joined July 2016
- Tweets16K
- Following992
- Followers8.2K
- Likes118K
Reminder you can customize the appearance of chatgpt on web and make it soothing
chatgpt.com/settings/appeara…
MCP 工具一多，Claude Code、Cursor 和我在做的 SSH 客户端 Hatoba 都走到了同一个思路，先只让模型看到工具名，用到了再去查参数。但查完之后怎么调，三家完全不一样
Claude Code 现在默认就延迟加载，不看工具多少。模型用 ToolSearch 搜到以后，真实的工具定义会被加载进来，之后直接按原名调用。这一步靠的是 Anthropic API 原生支持的 tool_reference
Cursor 最有意思，它明说考虑过 tool search，嫌把工具全丢进一个扁平索引太散就没用。做法是每个 MCP server 一个文件夹，工具描述同步成文件，让 agent 自己拿 rg 和 jq 去翻。他们 A/B 测出来总 token 少了 46.9%
Hatoba 就没这么潇洒了。要同时接 OpenAI、Anthropic、Gemini 好几家的模型，不是每家接口都有 tool_reference 这种东西，Chat Completions 一次最多 128 个工具，多一个直接 400。所以 MCP 工具定义超过上下文窗口的 10%，或者工具总数超过 128 个，就换成 search_tools 和 call_mcp_tool 两个固定工具，消息开头放一份工具名列表，搜到之后通过 call_mcp_tool 转调。参数和 schema 对不上就不跑，把 schema 原样甩回给模型。换来的好处是之后再怎么开关 server，工具列表都不变，prompt cache 一直能命中
10% 这个门槛刚好和 Claude Code 的 auto 模式一样。没到门槛时 Hatoba 还是把工具直接给模型。我觉得对只装一两个 MCP 的人来说，这比默认全延迟划算，毕竟在 Hatoba 里延迟以后，每个工具第一次用都得先搜一轮，调用还要多绕一层 call_mcp_tool
Claude Code 和 Codex 的 CLAUDE.md、AGENTS.md 其实都不在系统提示词里，是当成一条用户消息塞进对话的。这样系统提示词能一直是同一份，prompt cache 不会因为每个项目的指令不一样就失效。
中途改了怎么办，Codex 的做法挺聪明。前面那条原样留着，在后面追加一条新消息，开头一句 “These AGENTS.md instructions replace all previously provided AGENTS.md instructions.”，再把全文贴一遍。历史只增不改，缓存照样命中。Claude Code 就省事多了，会话开头读一次，文档里只说 /compact 之后会把根目录的 CLAUDE.md 重读一遍。
查这个是因为 Hatoba（我在做的 SSH 客户端，带 AI 助手）的自定义指令和主机备注是直接放在系统提示词里的，每次请求都重新拼。平时挺好，改完下一条就生效。问题在 AI 正跑着一长串工具调用的时候，你去设置里改指令，输入停 800ms 就自动保存，下一个请求可能就带着写了一半的指令出去了，每存一次整段缓存还得重算。
现在有两种改法。一种是每轮开始时把系统提示词固定下来，改完从下一条消息生效，代码改得最少，但模型不会知道规则换过。另一种是学 Codex 搬进消息里，缓存保住了，模型也看得见变化，代价是旧版本会在上下文里一直堆到下次 compact，用户自己写的规则也从系统提示词降成了用户消息。
还没想好选哪个，先开了个 issue 记着
KC retweeted
我刚发现 GitHub 上传的视频居然是存在 AWS S3 上的？？
随手复制了个视频链接，域名直接就是 github-production-user-asset…
微软自己的 GitHub，不用自家 Azure，每个月老老实实给 Bezos 交钱 笑死
Claude Code 和 Codex 的 CLAUDE.md、AGENTS.md 其实都不在系统提示词里，是当成一条用户消息塞进对话的。这样系统提示词能一直是同一份，prompt cache 不会因为每个项目的指令不一样就失效。
中途改了怎么办，Codex 的做法挺聪明。前面那条原样留着，在后面追加一条新消息，开头一句 “These AGENTS.md instructions replace all previously provided AGENTS.md instructions.”，再把全文贴一遍。历史只增不改，缓存照样命中。Claude Code 就省事多了，会话开头读一次，文档里只说 /compact 之后会把根目录的 CLAUDE.md 重读一遍。
查这个是因为 Hatoba（我在做的 SSH 客户端，带 AI 助手）的自定义指令和主机备注是直接放在系统提示词里的，每次请求都重新拼。平时挺好，改完下一条就生效。问题在 AI 正跑着一长串工具调用的时候，你去设置里改指令，输入停 800ms 就自动保存，下一个请求可能就带着写了一半的指令出去了，每存一次整段缓存还得重算。
现在有两种改法。一种是每轮开始时把系统提示词固定下来，改完从下一条消息生效，代码改得最少，但模型不会知道规则换过。另一种是学 Codex 搬进消息里，缓存保住了，模型也看得见变化，代价是旧版本会在上下文里一直堆到下次 compact，用户自己写的规则也从系统提示词降成了用户消息。
还没想好选哪个，先开了个 issue 记着
问 Hatoba 里的 AI 我现在有哪些 MCP，三次回答改口两次，每次还先道歉说上一条是错的
结果三次其实都对。我中途手动开关过 MCP，请求里的工具定义跟着变了，对话里却一个字没提。模型回头一看，自己刚说过有 Context7，现在工具列表里没有，那只能认定是自己瞎编的，于是道歉改口，我再一开，它又道歉改回来
顺手去翻了 Codex 的源码和 Claude Code 的 changelog，看它们怎么处理这种会变的列表。Codex 的 skill 列表压根不放在开头的 instructions 里，每一步跟上一步的快照比，变了才追加一条 developer 消息把整份列表重发，一个都不剩就直接告诉模型 No host skills are currently available。Claude Code 也是在对话里告诉模型有哪些 skill，变了只补发改动的那几个，压缩完再发一遍完整的。changelog 里还能看到它们修过好几次重复发列表的 bug，有一次直接把请求前缀改了，prompt cache 没命中
两家思路其实一样，系统提示词不动，会变的东西追加进消息，旧消息一个字不改。模型能看到状态是哪一刻变的，就不会回头怀疑自己，前缀不变，缓存也一直吃得上
Hatoba 这边先加了一条变更说明把这个修了，接下来 MCP 改成永远延迟加载，skill 列表也挪进消息里。少维护一条路径，真香
问 Hatoba 里的 AI 我现在有哪些 MCP，三次回答改口两次，每次还先道歉说上一条是错的
结果三次其实都对。我中途手动开关过 MCP，请求里的工具定义跟着变了，对话里却一个字没提。模型回头一看，自己刚说过有 Context7，现在工具列表里没有，那只能认定是自己瞎编的，于是道歉改口，我再一开，它又道歉改回来
顺手去翻了 Codex 的源码和 Claude Code 的 changelog，看它们怎么处理这种会变的列表。Codex 的 skill 列表压根不放在开头的 instructions 里，每一步跟上一步的快照比，变了才追加一条 developer 消息把整份列表重发，一个都不剩就直接告诉模型 No host skills are currently available。Claude Code 也是在对话里告诉模型有哪些 skill，变了只补发改动的那几个，压缩完再发一遍完整的。changelog 里还能看到它们修过好几次重复发列表的 bug，有一次直接把请求前缀改了，prompt cache 没命中
两家思路其实一样，系统提示词不动，会变的东西追加进消息，旧消息一个字不改。模型能看到状态是哪一刻变的，就不会回头怀疑自己，前缀不变，缓存也一直吃得上
Hatoba 这边先加了一条变更说明把这个修了，接下来 MCP 改成永远延迟加载，skill 列表也挪进消息里。少维护一条路径，真香
