little-coder架构拆解27个pi扩展如何把冷启动上下文压缩到7k tokens【免费下载链接】little-coderA harness optimized to smaller LLMs项目地址: https://gitcode.com/gh_mirrors/li/little-coderlittle-coder 是一个面向本地小语言模型的 AI 编程 Agent 框架构建在 pi 运行时之上。它通过 27 个 pi 扩展 30 份技能文件把 Agent 的冷启动上下文从 20k tokens 压缩到约 7k tokens——省下来的每一分上下文都变成了 8GB 显存小模型上真实可用的推理空间。本文带你逐层拆解这套架构的设计思路。为什么小模型的上下文花不起对云端大模型来说上下文窗口动辄 20 万 tokens多塞点工具说明无所谓。但 little-coder 的目标场景是一台消费级笔记本一块 8GB 显存的显卡跑一个 9.7B~35B 的本地模型。此时上下文有三个致命约束窗口小本地服务通常只开 16K 上下文冷启动就吃掉 20k 的 Agent 直接溢出KV cache 昂贵本地推理缓存命中失败意味着整段历史重新计算一次全量重处理可能要等几十秒注意力稀释小模型对上下文尾部的权重更高冗长的系统提示会稀释它真正该看的指令。所以 little-coder 的第一设计原则就是第一个 prompt 之前花掉的 token是永远拿不回来的钱。官方扩展文档 docs/extensions.md 开篇就把这句话写进了设计哲学。整体架构pi 是地基扩展是全部little-coder 不 fork pi也不改它的 CLI——pi 是package.json里的一个普通依赖提供 Agent 循环、多供应商 API、TUI 和会话树只带 4 个内置工具read/write/edit/bash和约 1000 token 的系统提示。所有小模型适配机制全部做成pi 扩展住在.pi/extensions/目录下每个扩展是一个独立小目录开头都有注释解释为什么它存在。启动器 bin/little-coder.mjs 做了一件关键的事以--no-extensions启动 pi关闭自动发现再把自己打包的扩展集合逐一显式挂进去。加载的就是发布的那一套多一个不多、少一个不少。这就是冷启动稳定在 7k tokens 的根本原因——工作目录里的任何文件都无法在任务中途改变 Agent 行为。组成位置作用27 个 pi 扩展.pi/extensions/上下文预算、失败修复、长任务、安全门禁30 份技能文件skills/tools/、skills/knowledge/工具使用卡片 算法速查表按需注入系统提示AGENTS.md项目级指令pi 自动发现模型注册表models.json声明 llama.cpp / Ollama / LM Studio 供应商基准测试框架benchmarks/Polyglot / Terminal-Bench / GAIA 驱动27个扩展各司其职一张分类表扩展之间互不依赖按需挂在 pi 的生命周期事件上before_agent_start、tool_call、tool_result、turn_end等。按职责可以分成四组分组代表扩展解决的问题 上下文预算skill-inject、knowledge-inject、read-guard、context-watchdog、thinking-budget每回合只注入这一轮需要的指导防止撑爆窗口️ 失败修复output-parser、quality-monitor、write-guard、read-guard-edit小模型常输出畸形工具调用、空回复、死循环自动兜底 长任务能力subagentdispatch、plan-mode、shell-session、evidence-compact把冗长探索隔离出去主对话只留浓缩结论 基础设施llama-cpp-provider、benchmark-profiles、permission-gate、branding 等模型注册、权限白名单、界面与测试环境完整清单和版本演进见 CHANGELOG.md 与 docs/architecture.md后者还保留了 Python 时代的历史架构。三个最反直觉的压缩手法手法一指导内容绝不进系统提示而是贴在对话尾部这是项目最有含金量的一次重构。早期版本把工具技能卡片、算法速查表追加到系统提示末尾——直觉上最新的内容放最后很合理但系统提示位于每个请求的最前面它一变整个缓存前缀就失效llama.cpp 被迫重算全部历史。社区用户用cache-hunter抓到了120k token 历史无故重处理的铁证问题 #73。修复方案很优雅借助 pi 的before_agent_start钩子把这些内容作为一条消息追加到对话末尾。前面所有字节一字不动缓存前缀原样复用只处理新增的少量 token。而小模型恰好最重视上下文尾部——最后的要求不但没变弱反而更强了。实现就藏在 .pi/extensions/_shared/inject.ts 这个共享模块里配一个去重器与上一回合完全相同的卡片不再重复注入因为上一条还留在对话里。手法二按需注入三优先级选择算法30 份技能文件从不全量加载。.pi/extensions/skill-inject/ 每个回合按三个优先级挑 1~2 张工具卡片错误恢复上一步哪个工具失败了就推哪个的补救卡近期性最近两回合用过什么意图预测用户消息里的关键词如 find 命中 glob/grep 卡片。算法知识则用关键词打分单词命中记 1.0 分、双词命中记 2.0 分得分 ≥2.0 且预算内才入选。没有命中就是零注入——不为可能有用的知识预付 token。手法三把大挡在上下文外面读文件熔断.pi/extensions/read-guard/ 发现某次 Read 会把上下文撑爆时直接只留文件前 30 行并附一句用 grep 定位你要的部分的指令隔离子 Agentdispatch工具派生的 sub-coder 在独立会话里读代码、查资料只有简短报告进入主对话完整记录留在 UI 面板里压缩看门狗.pi/extensions/context-watchdog/ 在每个回合边界检查上下文占用越过窗口 80% 就主动触发 pi 的自动压缩——专治几十个连续工具调用直接把窗口打穿的场景压缩不丢证据evidence-compact 在自动压缩后提醒模型你的证据还在用 EvidenceList 取保住研究链。如何验证压缩是否生效看状态行的 CH 字段little-coder 的终端底部状态行是这套架构的仪表盘↑26k ↓5.4k R447k CH99.8% 9.3%/262k (auto) qwen3.6-35b-a3b • medium其中CH 是最近一次响应的 KV cache 命中率。跑长对话时如果 CH 掉下来说明服务器在重算本该复用的历史值得排查配合右侧的9.3%/262k当前上下文占窗口比例和(auto)自动压缩已启用新手也能一眼判断上下文预算健康与否。省下来的上下文换回了什么成绩压缩不是目的成绩才是。全部数据来自一台 8GB 显存的消费级笔记本零云端推理基准模型结果Aider Polyglot225 题Qwen3.5-9.7B45.56%同模型原生 Aider 仅 19.11%Aider Polyglot225 题Qwen3.6-35B-A3B78.67%Terminal-Bench v0.1.180 任务Qwen3.6-35B-A3B40.0%GAIA 验证集165 任务Qwen3.6-35B-A3B40.0%想加自己的扩展三条官方路径默认封闭的扩展集并非不可扩展docs/extensions.md 给了三层渐进方案放文件把自己的扩展丢进~/.config/little-coder/extensions/每次启动自动加载在捆绑集之后可覆盖内置行为指路径LITTLE_CODER_EXTRA_EXTENSIONS环境变量指向任意位置的扩展文件全开放加--with-pi-extensions让 pi 按原生方式发现生态扩展会提示你冷启动上下文不再固定。在 TUI 里跑/extensions可以随时查看实际加载了什么、来自哪里——这正是透明可验证设计哲学的体现。写在最后little-coder 给出的启示超越了工具本身脚手架与模型的匹配度往往比模型大小更能决定实际表现。当你能把一个 9.7B 模型的上下文每一分都花在刀刃上时它就能做出让 45% 解决率变成现实的事。如果你手头正好有一块 8GB 显卡和一个 Qwen 模型这大概就是目前最值得研究的本地编程 Agent 方案了。【免费下载链接】little-coderA harness optimized to smaller LLMs项目地址: https://gitcode.com/gh_mirrors/li/little-coder创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考