Keen Code

嗨，Product Hunt！很高兴向大家介绍 Keen Code，一个用 Go 写的开源 CLI 编程智能体。

我从二月份开始独立开发这个副业项目，也借这个机会探索了上下文效率和智能体驱动开发。

Keen Code 与同类产品有三个不同之处：

1. 由智能体构建

Keen Code 完全是用最先进的编程智能体从零搭建的。我的角色是充当人类协调者：写提示词和需求，然后审核智能体产出的设计和代码。

为了保持透明，repo 里有一个 ai-interactions 文件夹，里面包含提示词和输出文档。更多信息：https://mochow13.github.io/keen-...

2. 轮次记忆

为了避免在多轮循环中塞满上下文窗口，Keen 会在每轮结束后丢弃原始的 tool 输入和输出。取而代之的是提炼后的“轮次记忆”：一个简单的确定性 Go 结构体，传入下一轮。

详情：https://mochow13.github.io/keen-...

3. 技能驱动的 MCP 服务器

Keen 不会一开始就把庞大的 MCP 服务器 schema 加载到上下文中，而是将 MCP tools 抽象成本地 markdown 格式的 Skills。仅在 LLM 在运行时请求某个具体 tool 时，才去检索对应的 JSON schema。

细节：https://mochow13.github.io/keen-...

我一直在用 Keen 开发 Keen 本身，也用在其他项目里。期待大家的提问、反馈、建议和评价。我会长期持续改进这个项目。

先谢过！

构建一个能自主管理上下文窗口的 CLI 智能体确实是个难题。我们在长时间运行的后台任务中也遇到过类似的取舍——要保持相关上下文又不超 token 预算，就得仔细做分块。当智能体的工作集在任务中途增长时，你的淘汰策略是什么？是优先考虑近期内容，还是语义相关性？

我们在用智能体工作流时发现，很多人把“缩小上下文大小”和“提升上下文质量”当成同一个问题，其实它们完全不是一回事。

你觉得 Keen Code 最大的收益来自压缩、检索，还是帮智能体在更长的会话中保持对代码库更一致的心智模型？

听起来挺有意思，但你不担心竞争吗？现在 AI 编程工具已经很多了，而且每天都有新的冒出来。

上下文效率这个角度让我很感兴趣——延迟加载 MCP Skills 而不是提前加载 schemas，这个架构选择相当聪明，大多数 CLI 智能体都没这么做。我也是个独立开发者，正在附近发布产品（Sensemaker，一个从思考到写作的工具）。你描述的“由智能体构建、人类协调”的工作流，几乎就是我发布 MVP 的方式。好奇问一下：当智能体中途偏离规范时，你是怎么处理的？repo 里的提示词/设计追踪够用来纠正方向吗，还是需要其他护栏？

以技能驱动的MCP方法是我注意到的部分。我见过的每个多工具智能体设置都是把整个schema一次性塞进上下文，然后奇怪为什么三轮之后性能就断崖下跌。按需加载模型在运行时实际需要的内容，事后看来很明显，但几乎没人这样做。另外，把完整的提示链放在repo里也很尊重……这对任何想了解智能体驱动开发在实际中如何运作的人来说真的很有用。祝贺发布，并且独自完成这件事可不简单。