先说赛道：Agent 行为调教
2026 年 Coding Agent 的竞争已经不只是「模型谁更聪明」了。当 Claude Code、Codex、Gemini CLI 这些工具的能力差距逐渐缩小，真正拉开体验差距的是Agent 的行为模式——它接到任务后是直接开写，还是会先思考？它倾向于写 200 行还是 20 行？它会不会过度工程化？
这个赛道目前有三类玩家：
- 工程纪律派（Superpowers、ECC）—— 给 Agent 套上完整的方法论：设计先行、TDD、子 Agent 驱动、代码审查。解决的是「Agent 不守规矩」的问题
- 极简压缩派（Caveman、Ponytail）—— 让 Agent 少说话、少写代码。解决的是「Agent 啰嗦」的问题
- 记忆增强派（claude-mem、codebase-memory-mcp）—— 让 Agent 跨 session 记住上下文。解决的是「Agent 健忘」的问题
Ponytail 属于极简压缩派，但它的思路跟 Caveman 有本质区别。
Caveman vs Ponytail：同一个赛道，完全不同的做法
Caveman 的做法很直白：告诉 Agent「像原始人一样说话，少用 token」。效果确实有——token 消耗降了，但问题是它只管「说」不管「做」。Agent 可能用很简洁的语言跟你对话，但该装的依赖一个不少，该写的代码一行不减。
Ponytail 不是让 Agent 少说话，而是让 Agent 在写代码之前先过一道 7 级阶梯：
1. 这东西真的需要存在吗？ → 不需要：跳过（YAGNI） 2. 代码库里已经有了吗？ → 有的话：复用，别重写 3. 标准库能做吗？ → 能的话：用标准库 4. 原生平台特性能做吗？ → 能的话：用原生特性 5. 已安装的依赖能做吗？ → 能的话：用已有依赖 6. 一行能搞定吗？ → 能的话：就写一行 7. 以上都不行？ → 那就写最少能跑通的代码这个阶梯跑在 Agent 理解问题之后，不是不让它思考，而是让它在想清楚之后选择最懒的解决方案。
举个具体例子
你跟 Agent 说「我需要一个日期选择器」。没装 Ponytail 的 Agent（以 Claude Code 为例）会这么做：
// Agent 的典型反应 npm install flatpickr // 然后写一个 React wrapper 组件 // 然后加 CSS 样式 // 然后处理时区 // 然后加国际化 // 产出：~400 行代码 + 一个新依赖装了 Ponytail 之后，Agent 的阶梯在第 4 级就停了——浏览器原生就有
<input type="date">：<!-- ponytail: browser has one --> <input type="date">一行。不需要依赖。不需要 wrapper。不需要样式。浏览器自己处理国际化和时区。
同样，你让它做一个颜色选择器。普通 Agent 可能会装 react-color 写 287 行代码，Ponytail 让它用
<input type="color">，23 行搞定。实测数据：不吹不黑
作者做了一个相当严谨的 benchmark：用 Claude Code（Haiku 4.5）在真实的 FastAPI + React 项目上执行 12 个 feature 任务，对比有无 Ponytail 的差异，每个任务跑 4 次取中位数。
指标 Ponytail Caveman "YAGNI+一行"提示词 代码行数 -54% -20% -33% Token 消耗 -22% +7% -14% 费用 -20% +3% -21% 耗时 -27% +2% -30% 安全性 100% 100% 95% 几个值得注意的点：
- Ponytail 是唯一一个四项指标全降、安全性不掉的方案。Caveman 加了简洁提示词但 token 反而涨了 7%（因为 Agent 用了更多思考 token）；"YAGNI+一行"的安全性从 100% 掉到了 95%
- -54% 是平均值，具体任务差异很大。日期选择器从 404 行降到 23 行（-94%），但本身就简洁的代码几乎没有变化
- 作者坦诚地说：在 GPT-5.5 这种推理模型上，Ponytail 可能反而增加成本，因为模型会花更多 thinking token 去纠结选哪个阶梯
安装方式
Ponytail 支持 16 个 Agent 平台，每个平台的安装方式不同：
# Claude Code（最简单）
/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail
# OpenAI Codex
codex plugin marketplace add DietrichGebert/ponytail
# Hermes Agent
hermes plugins install DietrichGebert/ponytail --enable
# Gemini CLI
gemini extensions install https://github.com/DietrichGebert/ponytail
# OpenCode — 在 opencode.json 里加：
{ "plugin": ["@dietrichgebert/ponytail"] }
# Cursor / Windsurf / Cline — 复制规则文件到项目目录
# 详见 README 的 Agent portability 文档安装后默认是 full 模式，每个 session 自动激活。可以通过环境变量 PONYTAIL_DEFAULT_MODE 或配置文件 ~/.config/ponytail/config.json 切换模式。
四种模式：lite / full / ultra / off
| 模式 | 行为 | 适合场景 |
|---|---|---|
lite | 只在明显过度工程化时干预 | 大型项目，不想太激进 |
full | 每次写代码前跑完整阶梯 | 默认，大多数场景适用 |
ultra | 最严格，连注释和变量名都压缩 | "这个代码库惹到你了"（作者原话） |
off | 关闭 | 需要大量代码时临时关闭 |
还有几个有用的命令：
/ponytail-review— 审查当前 diff，给出「可以删掉」的清单/ponytail-audit— 审查整个仓库的过度工程化/ponytail-debt— 把你推迟的快捷方式整理成账本
我的真实体验
我在 Hermes Agent 上装了 Ponytail，用 full 模式跑了几天，说说实际感受：
好的方面：
- Agent 确实会先停下来想「这个东西需不需要写」，而不是接到需求就冲。这个行为变化比代码行数减少更有价值
- 对前端组件特别有效——Agent 不再动不动就装一个 npm 包，而是先考虑原生 HTML 能不能解决
- 代码审查功能
/ponytail-review挺好用，能帮你发现已经写好的代码里哪些是多余的
不好的方面：
- 有些场景它会过度精简。我让 Agent 写一个带验证的表单组件，它想用原生 HTML validation 搞定，但我的场景需要自定义验证逻辑和实时错误提示。最后我得手动关掉 Ponytail 再跑一遍
- 对后端逻辑的帮助没前端大。数据库查询、API 路由这些本来就不容易「过度工程化」，阶梯的前几级很少能触发
ultra模式过于激进，变量名缩写到看不懂的程度，不建议日常用- 跟 Superpowers 有冲突——Superpowers 要求 Agent 写详细的设计文档和任务计划，Ponytail 要求精简。两个一起装会打架
什么时候该用，什么时候不该用
用 Ponytail 的场景：
- 前端 UI 开发——Agent 特别容易在 UI 组件上过度工程化，Ponytail 的阶梯在「原生平台特性」这一级就能拦住大部分
- 快速原型——不需要完美架构，需要快速出活
- 成本敏感——按 token 计费的场景，20% 的节省是实打实的
- 代码审查——用
/ponytail-review扫一遍已有代码，找出可以精简的地方
别用 Ponytail 的场景：
- 复杂业务逻辑——需要详细的错误处理、边界检查、状态管理，精简不是目标
- 已经在用 Superpowers——两套规则会冲突，选一个
- 推理模型（GPT-5.5 级别）——thinking token 的增加可能抵消代码精简带来的节省
谁在做
Ponytail 由 Dietrich Gebert 开发，2026 年 6 月 12 日开源，不到一个月 7 万 Star，增长速度非常快。项目有详细的 benchmark 数据和可复现的测试方法，这在同类项目里很少见。
作者在 README 里的文案也很有意思——整个项目的调性就是「懒」。连 README 都说「That was it. He'd be proud. He won't say it.」
总结
Ponytail 的核心洞察很简单：Agent 写太多代码不是因为能力不够，是因为没有「够了」的意识。给它一个阶梯，让它在每个级别都先问自己「真的需要写这么多吗」，结果就是代码更少、成本更低、速度更快。
它不是万能的——复杂的业务逻辑该写多少还是得写多少，跟 Superpowers 之类的工程纪律框架也存在路线冲突。但如果你的 Agent 经常在 UI 组件、工具函数这些地方过度工程化，Ponytail 是目前最轻量、最有效的解决方案。
项目地址：github.com/DietrichGebert/ponytail
Benchmark 数据：benchmarks/
官网：ponytail.dev