goose 发布已经很久了。狗年都比不上智能体年。goose 比通用的智能体式 AI 还稍微早一点。这一切背后最初的想法是：如果把一个 shell 会话的控制权交给 LLM，会发生什么？
结果，有意思的事发生了。模型写一条命令，命令跑起来，结果回到对话里，模型再决定下一步做什么。我们的工具调用从那场实验里自然长出来，如今坐在大多数编程智能体中心的智能体循环也是如此。
后来工具调用有了正式形态，MCP 出现了。批准、上下文管理、待办列表、Top of Mind、子代理、重试、钩子、技能、配方和转向也跟着来了。最初的智能体循环却还在。每加一个功能，就多一个分支、一个局部变量，或一个特例。一轮之内可能同时有十几种不同的关切在起作用，而且彼此影响。取消必须知道当前在跑的是推理还是工具。压缩必须理解提供商错误和用量。工具可以改写提示词。停止钩子可以把一份已经完成的回答变回更多工作。循环开始缠成一团意大利面。
从前，向开源项目提交你的第一个 PR 相当费事。即便说明写得很清楚，把项目构建起来、让应用跑起来、让测试通过，都需要实打实的工作。就算你清楚要修哪个 bug，也得大致理解项目架构，并对要改的代码有更细致的了解。
编程智能体改变了这一切。问题不在代码质量。网上到处都是对 AI 注水代码的抱怨，但智能体写出的代码，往往比第一次贡献者交上来的更好。问题在于，智能体改变了开源的经济账。
古德哈特定律是跑基准的人的诅咒：当一项度量变成目标，它就不再是好的度量。编程智能体基准几乎就是为触发它而设计的。任务是公开的，结果是一个数字，排行榜不可避免地挤满了那些往往并非有意、却对基准过拟合的运行框架。
这并没有让事实上的标准 Terminal-bench 变得无用，但确实改变了 goose 团队使用它的方式。排行榜是对通用智能体能力的嘈杂度量。真正的信号是失败的模式：goose 反复卡住的地方，或者 goose 失败而另一个运行框架成功的地方。
这也是我们通常用 Sonnet 而不是最强模型来跑基准的原因。我们并不是要拿到尽可能大的数字。我们希望桌上还留着足够多的失败，好看出智能体缺了什么支持。