ken：用 Ken Thompson 工程哲学约束 AI 编码代理

GitHub 上出现了一款名为 ken 的开源工具，作者 Raj Nandan Sharma 将 Unix 创始人 Ken Thompson 的工程纪律——「先思考、再偷师、自底向上、用蛮力、跑通即真理、腐烂即重写」——固化为一套可执行的提示词与行为规则，让 AI 编码代理在动手前先遵循这套循环。ken 并非一个新模型，也不是某个主流框架的官方插件，而是面向 Claude Code、Cursor、Windsurf、Cline、Copilot、Gemini CLI、Codex、Grok 等支持 AGENTS.md 或插件机制的代理宿主的一套方法层。

核心方法论：六步循环 + 七条铁律

ken 把 Thompson 在 Unix 早期反复强调的原则转译成代理必须遵守的顺序：

• 先思考：动代码前先建立心智模型；
• 偷师而非发明：优先复用本仓库、stdlib 或经典算法；
• 自底向上：只写能逐行解释的原语，层级是沼泽；
• 蛮力优先：用最朴素的算法，直到测量证明它错；
• 跑通即真：能跑通的代码胜过一切讨论；
• 腐烂即重写：一个单元被打了三次补丁后，必须重写而非再补。

在此之上，ken 还内置若干「默认规则」：功能默认拒绝、接口宁少毋滥、不写纯翻译层、最小可信计算基础（用前先为依赖背书、不粘贴无法逐行解释的代码）、逐行读懂、改模型而非改症状、零仪式。每条规则在仓库的 PROVENANCE.md 中标注了 Thompson 原话出处，无法考证的归为「归属」。

基准测试：量化代理行为

ken 的作者认为，若声称自己「遵循某种方法」，就该用行为而非代码行数来衡量。基准 benchmarks/ 因此定义了五类可计分行为：

• rewrite：第三次补丁触发重写而非继续补；
• reuse：优先使用项目已有 helper；
• root cause：修复共享根因而非表面症状；
• vouch：为每个依赖背书；
• runnable check：留下可运行的检查。

行为门控与代理质量分级共同打分，并附一个「随时间维护」的回归基准，评估代理在多轮工单下的存活能力。

「重写规则」的实测对比

仓库中给出的一轮对照实验（run 20260826-203814）使用同一小型模型 haiku，对同一段被故意埋入腐烂的函数各跑 3 次：

• 关闭 ken 时，3/3 次都在函数末尾追加第四次补丁；
• 开启 ken 时，3/3 次都丢弃旧实现连同补丁注释一并重写。

整轮中，ken 在被植入腐烂的 6 个函数上重写了 6/6，去除 ken 时为 0/6；存活率（不引入新故障）两边均 8/9 平手。同批实验也暴露出 ken 自身的失败模式：当 bug 位于共享 helper 时，ken 仍倾向于只补工单指名的调用点，3/3 次忽略其他调用方，root cause 规则失守。每一轮的胜场与败场都沉淀在 benchmarks/results/。

部署与档位

ken 通过 Claude Code 插件市场安装：/plugin marketplace add rajnandan1/ken 后 /plugin install ken@ken。其他宿主见 docs/agent-portability.md，纯 MCP 宿主使用 ken-mcp/。插件提供三档强度：

• lite：按要求构建，标注所用 Thompson 招式；
• full（默认）：强制上述循环，蛮力至测量推翻；
• ultra：达尔文主义，重写优先、新增依赖需论证。

档位可通过 /ken default <level>、KEN_DEFAULT_MODE 环境变量或 ~/.config/ken/config.json 持久化，stop ken 或 /ken off 关闭。配套命令包括 /ken-review、/ken-audit、/ken-debt、/ken-gain 等，覆盖方法评审、仓库级审计、技术债收集与计分板。

边界与可信度提示

ken 的蛮力策略以正确性、输入校验、错误处理、安全、可访问性与用户要求为硬截止线——重写前必须逐行跟踪被改单元。安全相关的边界不会被工具推翻。但需注意：所有对比实验均由作者本人用同一小模型跑出，且为单一轮次结果；ken 的插件架构与基准脚手架派生自 Dietrich Gebert 的 ponytail（MIT）。总体而言，ken 提供了一种把「工程哲学」转译为「代理行为 + 可测基准」的轻量方案，适合希望约束代理修改习惯的团队试用，但要据此评判主流代理能力，仍需更大规模的独立复现。