Ponytail 是一个由单个作者维护的仓库，里面没有传统意义上的业务代码，主要是给编码 Agent 使用的指令文件。它在九天内获得超过 44,000 个 GitHub stars，原因很直接：它试图让编码 Agent 停止过度构建，只完成真正需要的工作。
项目曾宣称可以减少 80% 到 94% 的代码量。但贡献者指出，这个数字来自有问题的基线。维护者随后重新设计了基准测试，让 Agent 在更接近真实工作的环境中运行，最终公布的降幅为 54%。这个过程的价值，不只是得到一个更低的数字，而是展示了 Agent 项目应该如何面对可复现性和测量偏差。
代码量不是效率的完整答案
对于编码 Agent，生成的代码越少，通常意味着更少的维护面、更低的审查成本，以及更小的引入缺陷的机会。但“少写代码”本身不能直接等同于“完成得更好”。
一个基准测试至少需要回答几个问题：
- Agent 是否完成了同一个需求？
- 测试是否通过，行为是否正确？
- 它是否被允许读取仓库、运行命令和修改多个文件？
- 统计的是新增行数、总行数，还是最终差异？
- 基线是否使用了同样的模型、上下文和工具权限？
如果对照组只是人工编写的一个极小示例，而 Ponytail 的结果来自不同任务或不同执行条件，那么“减少 94%”就不能代表真实的工程收益。它最多说明两组文本的大小不同。
真正的 Agentic Run 应该测什么
摘要中提到，维护者后来将基准测试重建为一次真实的 agentic run。这个变化很关键：Agent 不应只被要求生成一段孤立代码，而应该在明确的任务、工具和验收标准下完成工作。
可以把一次运行抽象成以下输入：
benchmark:
task: "为 CLI 增加 --json 输出，并保持默认文本输出兼容"
repository: "./sample-project"
agent:
model: "configured-model"
tools:
- read_file
- write_file
- run_command
acceptance:
- "默认命令的现有测试继续通过"
- "使用 --json 时输出合法 JSON"
- "不修改无关文件"
metrics:
- tests_passed
- changed_files
- added_lines
- removed_lines
- execution_time_seconds
这个配置只是一个可改造的实践示例，不是 Ponytail 的官方格式。重点在于让每次运行都拥有固定任务、固定验收条件和固定指标。否则，后续数字无法和早期结果公平比较。
一个最小的命令行评估流程可以这样写：
#!/usr/bin/env bash
set -euo pipefail
repo="${1:-./sample-project}"
cd "$repo"
before=$(git rev-parse HEAD)
start=$(date +%s)
# 在这里调用编码 Agent，让它只处理预先定义的任务。
agent-cli run \
--task-file ../task.md \
--workspace . \
--allow "read,write,exec"
# 用测试结果验证行为，而不是只统计生成文本的长度。
pytest -q
end=$(date +%s)
changed_files=$(git diff --name-only "$before" | wc -l | tr -d ' ')
added_lines=$(git diff --numstat "$before" | awk '{a += $1} END {print a + 0}')
removed_lines=$(git diff --numstat "$before" | awk '{d += $2} END {print d + 0}')
printf '{"tests_passed":true,"changed_files":%s,"added_lines":%s,"removed_lines":%s,"execution_time_seconds":%s}\n' \
"$changed_files" "$added_lines" "$removed_lines" "$((end - start))"
运行前需要把 agent-cli 替换成实际使用的 Agent 工具，并准备 task.md。例如：
只实现任务描述中的功能。先检查现有实现和测试，再进行最小修改。
完成后运行相关测试。不要为了重构、格式化或预防尚未提出的需求而修改无关文件。
这里的“最小修改”不是让 Agent 盲目追求更少的字符，而是把范围约束在需求和验收标准之内。
Ponytail 案例的工程启示
Ponytail 的传播速度说明，Agent 指令本身已经成为一种可被独立分享和评估的工程资产。一个不包含大量源代码的仓库，也可以通过改变 Agent 的决策边界，影响它如何理解需求、何时停止以及是否进行不必要的扩展。
但高关注度也会放大基准测试的问题。一个醒目的百分比很容易成为项目的主要记忆点，甚至在测量方法被修正后仍然继续传播。因此，Agent 项目发布性能结论时，最好同时公开以下内容：
- 原始任务和完整提示词；
- 使用的模型、版本和工具权限；
- 基线实现以及选择理由；
- 成功率和失败样本；
- 代码变更量的计算方式；
- 独立贡献者如何复现结果。
“54%”并不意味着所有项目都能减少一半代码。它只是在更新后的测量方法下，得到一个比原始说法更保守、更可信的结果。实际收益仍会受到仓库规模、测试质量、任务类型和模型能力的影响。
采用前的检查清单
如果团队准备把类似 Ponytail 的指令集加入编码 Agent，可以先做一个小规模对照实验：选择几项真实但边界清晰的任务，让同一个模型在相同工具权限下分别使用默认指令和新增指令，然后比较测试通过率、变更文件数、有效代码变更和返工次数。
不要只看新增行数。一个删除了大量代码但破坏兼容性的补丁，显然不比一个多写几行但测试完整的补丁更优秀。更稳妥的结论应当是：在通过验收的前提下，Agent 是否减少了不必要的工作。
Ponytail 最值得借鉴的地方，最终不是某个百分比，而是维护者在受到质疑后重做基准并公开修正结果。对于快速发展的 Agent 工具，这是比漂亮的初始数字更可靠的工程习惯。