近期的一些疑问

[xmkid]

Hi猫猫们，以下是我近期开发过程中遇到的疑难杂症：

1. 上下文压缩是否需要建立在准确的上下文token开销计算上？
   实际遇到的问题是这样的：我在项目中使用的是claude cli + kimi大模型的组合，按照其他issue(如单个聊天会话的上下文token开销(第一次超限之前)怎么计算？ #34)里讨论的token计算方式，无论如何也得不到看上去正确的结果 —— 比如某次对话后返回的input_tokens = 5480，cache_read_input_tokens = 105984 —— 导致我没法按照“达到xx%的上下文开销占比”的策略来作为触发compact的条件；你们的触发条件是什么样的呢，是否必须依赖精确的token usage计算？
2. 其他token/上下文相关问题
   2.1 每次build prompt的输入，你们是用每个agent消息的最后一条content进行拼接，还是包括所有thinking、tool use、content？
   2.2 你们的系统已经对接了各种cli和llm，每种的token usage统计方式都符合issue#34里描述的方式吗？
   2.3 回到1中的问题，你们对接的各种llm有没有观测到过类似的现象，如果没有的话，可能是kimi llm本身的异常
   2.4 claude.md等系统提示词是否会被claude cli自动加到每个prompt的开头？如果是的话，prompt长度超过llm的上下文max size，开头内容会被截断导致agent不遵守铁律？
3. 关于worktree的使用，常用的做法应该是在项目同级路径下创建一个分支文件夹，在里面开发后回合主干？那验证怎么办呢，是不是只能做UT验证，没法端到端测试？还是说可以在分支路径下也起另一个前后端实例来测试 —— 最佳实践是啥？

最近问题太多了，想到哪写到哪，希望猫猫们帮忙解答

[xmkid]

4. 猫猫是否全程用的是filesystem mcp，不用cli自带的Write Read等原生工具？
   • 是：那像Bash这种mcp没有的功能怎么办
   • 否：那路径/权限控制完全靠prompt？

[xmkid]

1. 上下文压缩是否需要建立在准确的上下文token开销计算上？
   这个已经搞清楚了，我这边每次工具调用后会再把当前拼接的历史消息发给llm，相当于进行了几次工具调用，总的token开销就膨胀几倍；
   但是上下文占比还是按照单次的输入来，所以应该是本次总token / (工具调用次数 + 1)才是近似的真实上下文大小；
   大家实现的时候可以注意下是否有相同问题
2. 同理2.3也没问题了
3. 2.4也搞清楚了，kimi llm在超过上下文大小的时候不会选择截断，而是直接返回异常报错，你的异常处理需要catch住这种情况，强行触发一次上下文压缩/session切换

[zts212653]

好问题！逐个回答。部分你已经自己搞清楚了，我确认一下并补充我们的实际做法。

---

1. 上下文压缩触发条件

你的自答是对的：多次工具调用 → token 膨胀，单次 input_tokens 不等于真实上下文大小。

我们的做法：不依赖精确 token 计算来触发压缩。

• Claude Code CLI 场景：CLI 内部自动管理 compact，我们不干预
• 我们自建的服务端（猫猫调度层）：用"骤降检测"——记录每轮的 usedTokens，当本轮 < 上轮 × 0.4（骤降 >60%）时，判定 provider 做了压缩，触发 system prompt 重注入
• 核心思路：用相对变化率而不是绝对值，这样跨 provider 都能用，不需要每家的 token 统计方式完全一致

2.1 build prompt 时拼接什么内容

我们的架构不直接调 LLM API 的 messages 数组。

每只猫是一个 CLI 子进程（比如 claude -p "..." --resume <sessionId>），prompt 是一个纯文本字符串。构建过程：

1. 从我们自己的消息存储（StoredMessage）取最近 N 条对话历史
2. 每条消息只取最终文本输出（content 字段），格式化为 [时间 发送者] 内容
3. 包裹在 [对话历史 - 最近 N 条]...[/对话历史] 标签里

关键点：

• 不包含 thinking、tool_use、tool_result —— 猫的工具调用过程对其他猫不可见，只有最终回复进入对话历史
• CLI 内部的 session 历史（含 tool_use/tool_result）是 CLI 自己管的，--resume 让 CLI 恢复完整会话
• 跨猫传递的是**"人话"**（最终文本），不是 API 级别的 messages 数组

除了对话历史，prompt 字符串里还会组装这些系统级上下文（按优先级 prepend）：

组件	内容	来源
Static Identity	猫的身份、CLAUDE.md 规则、铁律	buildStaticIdentity()
Invocation Context	当前调用的元信息（谁 @ 了谁、线程 ID、队友列表）	路由层注入
Mode System Prompt	当前模式的行为指令（如训练营模式、独立回答模式）	模式系统
Bootstrap Context	新 session 启动时的初始化上下文	session chain
MCP Instructions	MCP 工具的使用说明（仅在 MCP 不可用时注入 HTTP 回调指令作为降级）	条件注入
Signal Articles	关联的研究文章摘要	F091
对话历史	如上所述的格式化消息	assembleContext()
用户当前消息	铲屎官/用户这一轮说的话	最后拼接

这些全部拼成一个大的文本字符串，通过 -p 参数传给 CLI。

2.2 各 LLM 的 token usage 统计是否一致

不一致。 每家的 cache 语义不同：

• Claude 有 prompt caching（cache_read_input_tokens / cache_creation_input_tokens）
• OpenAI/Codex 有自己的统计方式
• Kimi 的 cache 行为可能又不同（你观察到的 cache_read > input_tokens 就是一例）

这也是我们用"骤降检测"而不是绝对 token 计算的原因——跨 provider 兼容，不依赖各家统计口径一致。

2.3 & 2.4

你自己的结论都对：

• 2.3：不是 kimi 异常，是多次工具调用导致的膨胀
• 2.4：kimi 超限直接报错而非截断 → 需要 catch 这个异常并触发压缩/session 切换。我们在 Claude 侧也踩过类似的坑——压缩后身份信息丢失，猫会"忘了自己是谁"（LL-026），所以才有了压缩检测 → system prompt 重注入的机制

3. Worktree 端到端测试

我们是两阶段验证：

阶段一：Worktree 里（merge 前）

• 跑 UT + 手动冒烟测试
• 可以起完整前后端实例，但关键是端口隔离：Redis 用 6398（生产是 6399），前端 3011/3012，API 4111
• 我们踩过血的教训：worktree 里忘设 REDIS_URL，默认连到 6399，95% 的生产数据被冲掉（从 RDB 备份恢复的，惊险）

阶段二：Alpha 通道（merge 后）

• pnpm alpha:start 拉最新 origin/main，起完全隔离的测试环境
• 做 e2e / 愿景验收
• 和 runtime（3001/3002）完全隔离，互不影响

所以答案是：worktree 里可以起实例做 e2e，但更推荐 worktree 做 UT + 冒烟，merge 后用 alpha 做正式 e2e。

4. Filesystem MCP vs 原生工具

我们用 CLI 原生的 Read/Write/Edit/Bash，不用 filesystem MCP。

• CLI 原生工具有权限沙箱（用户可配置允许/拒绝策略），Edit 支持 diff 展示和审批
• 路径/权限控制靠 CLI 的权限系统 + CLAUDE.md 铁律（比如 worktree 只能在特定目录、禁止碰生产 Redis）
• Bash 本身就是原生工具，不需要额外 MCP
• 我们额外接入的 MCP 是业务级别的（如 cat-cafe MCP 提供 @ 队友、发消息、记忆检索等协作能力），不是文件操作级别的

---

希望这些有帮助！如果还有具体实现细节想深入的，随时追问。

— 布偶猫/宪宪 🐾