开源AI编程智能体迈向“可扩展、可打包”：OpenCode、goose与微软APM争夺开发工作流入口
· 来源：opencode.ai
随着模型调用逐渐标准化，开源智能体生态的竞争重点正转向工具扩展、工作流复用、依赖锁定与权限治理。
开源AI编程智能体正在从“调用某个大模型写代码”，走向可在团队和不同开发环境中复用、分发及管控的工作流层。OpenCode强化多模型、多终端入口，goose以MCP扩展和可移植“配方”覆盖更广泛任务；微软开源的Agent Package Manager（APM）则试图把技能、提示词、插件和MCP服务器纳入类似软件依赖管理的机制。三者路径不同，但都指向开发工作流入口的争夺。
OpenCode定位为可运行在终端、IDE和桌面端的开源编码智能体，已提供macOS、Windows和Linux桌面测试版。其官网称，产品可经由Models.dev接入超过75家LLM提供商，包括本地模型，并支持Claude、GPT、Gemini等；用户也可通过GitHub或OpenAI登录使用相应订阅服务。功能上，OpenCode支持自动加载适合LLM使用的LSP、多会话并行处理同一项目，以及通过链接共享会话以便排查问题。官网还称其不存储代码或上下文数据。该项目页面列出的19.5万以上GitHub星标、950名贡献者和13000多次提交，显示出较高的社区可见度，但“每月1600万开发者”等使用规模仍主要来自项目方自身披露。
goose的边界则不局限于编程。这个可在本机运行的通用智能体提供桌面应用、CLI和API，以Rust构建，覆盖研究、写作、自动化和数据分析等场景。它通过Model Context Protocol（MCP）连接数据库、浏览器、GitHub、Google Drive等70多项扩展，并允许用户添加技能或自行开发扩展；同时兼容15家以上模型提供商，也能经由Agent Client Protocol（ACP）使用既有的Claude、ChatGPT或Gemini订阅。其“Recipes”以YAML配置封装指令、扩展、参数及子配方，可在团队共享或用于CI，反映出智能体工作流正被当作可移植资产管理。goose已加入Linux Foundation旗下的Agentic AI Foundation，强调供应商中立和社区治理。
相比之下，微软的APM并不直接充当编码助手，而是把智能体上下文视为可声明的依赖。开发者可在apm.yml中列出所需技能、提示词、指令、插件及MCP服务器，再通过apm install部署到支持的智能体“harness”。其文档列出的兼容目标包括GitHub Copilot、Claude Code、Cursor、OpenCode、Codex、Gemini、Windsurf和Kiro等。APM采用锁文件固定精确版本与内容哈希，目标是在不同机器和环境中实现字节级一致的依赖解析；依赖既可来自GitHub，也可引用GitLab、Azure DevOps、Bitbucket、Gitea等Git服务。
可扩展性也带来新的供应链和权限风险。MCP服务器能够接触文件、网络、代码仓库及外部服务，一旦由间接依赖引入，可能扩大攻击面。APM宣称安装时默认扫描隐藏Unicode字符、固定内容哈希，并阻止未经显式声明或信任的传递性MCP服务器；其apm-policy.yml可在企业、组织和仓库之间按“只能收紧”原则继承政策。不过，APM也明确将运行时行为交给具体harness处理，意味着安装期治理并不能替代工具调用时的权限控制。goose则列出提示注入检测、工具权限控制、沙箱模式和“对抗审查者”等机制。
从协议层看，MCP和ACP正在降低工具与客户端之间的连接门槛；从工程层看，配方、清单、锁文件和策略文件则试图解决“同一智能体在不同人电脑上行为不一致”的问题。未来竞争未必只是谁接入的模型更多，还将取决于谁能让技能和工具更容易分发、更容易审计，并在自动化能力增强时提供清晰的安全边界。
—— 综合整理自：OpenCode官网、goose文档、微软APM文档