OpenCode、Pi 和 Goose：AI 代理栈的三个层次

我一直在尝试比较三个常被归为一类的开源 AI 代理工具，但我不认为它们处于栈的同一层：OpenCode、Pi、Goose。我目前的心智模型是：Pi 最接近代理内核/代理框架/代理工具包。Goose 最接近面向开发者的本地 AI 代理工作台和编排面。OpenCode 最接近编码优先的软件开发代理。这不是排名，而是层次区分。 Pi Pi 给人的感觉更像是一个用于构建、研究和扩展代理系统的基础，而不是一个成熟的终端用户编码助手。如果你关心以下方面，它会很有趣：代理运行时设计、工具调用、状态管理、提供商抽象、可复现的代理工作流、构建自己的代理工具。一个重要的细节是 Pi 对权限有明确要求。如果你需要更强的文件系统、进程、网络或凭证边界，你需要自己提供容器或沙箱层。因此，我会将 Pi 描述为一个代理框架和工具包，同时包含一个编码代理 CLI。 Goose Goose 给人的感觉比编码更广泛。我的印象是它正在演变为面向开发者的本地 AI 代理工作台：桌面、CLI、API、提供商、MCP 风格的扩展、文件、终端工作流和自动化。如果你想要一个本地环境来完成以下任务，它似乎很有用：编码、研究、写作、自动化、数据分析、工具使用、超越单纯编辑仓库的开发者工作流。如果说 Pi 更接近框架层，那么 Goose 更接近编排面。 OpenCode OpenCode 似乎最专注于软件开发本身。它更容易理解为一个编码优先的代理，用于仓库工作：探索代码库、计划更改、编辑文件、实现功能、运行开发任务、在软件项目内部工作。与 Pi 相比，它更像一个成熟的编码代理产品。与 Goose 相比，它不那么像通用的本地工作台，而更像一个专门的软件开发框架。 简短版本 我当前的模型是：Pi：代理内核/框架/工具包；Goose：本地 AI 代理工作台/编排面；OpenCode：编码优先的软件开发代理。换种说法：如果你想构建代理，研究 Pi；如果你想组织本地代理工作流，研究 Goose；如果你想要一个日常编码工作的代理，研究 OpenCode。 我仍然关心的实际问题有：哪一个在日常使用中人体工学最好？哪一个权限模型最清晰？哪一个与自定义 OpenAI 兼容端点配合最好？哪一个最容易配置多个提供商？哪一个在长时间多步骤任务中最可靠？哪一个失败时最透明？哪一个最容易扩展而不与框架对抗？好奇那些使用过其中两个或更多工具的人会如何比较它们。 披露：从 AIMOWAY 发布。我们正在研究 OpenAI 兼容的 /v1 API 访问，因此我们关心代理工具、提供商配置和自定义基础 URL 工作流。链接在评论中，遵循子版块规则。