OpenAgentPack 开源：让云端 Agent 像代码一样可管理、可迁移

作者：袁坤（丹坤）

你花了几周，调好一个行业研究 Agent。

它会按你的框架读访谈记录和市场资料，判断信源，调用工具，再输出一份结论先行的报告。你给它一句任务，它已经知道该查什么、怎么组织、哪些结论需要证据支撑。

直到有一天，你换了电脑、换了账号，或者进入一家新公司。

原来的 Agent 留在旧平台：Prompt 在一个页面，MCP 在另一处，Skill、知识文件和运行配置散在各处；密钥也只存在旧环境里。你带走的，可能只有截图、零散文件和一段很难复述清楚的经验。

真正难带走的不是一次对话，而是那套已经被你调顺的工作流。

这正是我们开源OpenAgentPack的原因。

项目地址： GitHub - OpenAgentPack

github.com/modelstudio…

把 Agent 打包，带回 Git

一个能完成真实工作的云端 Agent，远不止一段 Prompt。

它还包括模型、运行环境、工具、Skill、MCP、知识文件、凭据引用、Memory 和任务调度。这些共同决定了它能做什么、如何做、能否稳定复现。

OpenAgentPack 用一份agents.yaml描述这套工作流，并用 Git 保存其演进：

agents.yaml → validate → plan → apply

例如，一个研究 Agent 的关键组成可以放在同一个项目里：

skills:industry-research:source:./skills/industry-research/agents:researcher:instructions:./prompts/researcher.mdenvironment:devskills: [industry-research]

换到新环境时，不需要靠记忆重新点击控制台。你可以校验声明、预览变化，再部署到新的云端 Agent 平台：

agentsvalidateagents planagents apply

这不是把所有平台说成完全一样。不同 Provider 的能力确实不同。OpenAgentPack 会明确标识某项能力是native、emulated还是unsupported，让你知道哪些核心工作流可以复现、哪里需要调整，而不是等到迁移后才发现差异。

不是存一份文件，而是让工作流重新跑起来

“把 Prompt、MCP 和 Skill 放进 Git”，当然是第一步。

但 Git 保存的是配方；你仍然需要知道这份配方会怎样影响云端的真实 Agent：哪些资源会创建、哪些会更新、哪些会删除，依赖是否齐全，新的配置能不能真正把任务完成。

OpenAgentPack 的plan会比较三种状态：

1. Config：agents.yaml中希望得到的 Agent；
2. State：已管理资源与远端 ID、内容哈希的映射；
3. Remote：Provider 上真实存在的资源。

因此，在执行前就能看到即将发生的create、update和delete。没有变化的资源不会重复更新；控制台里的手工改动也可以被识别为 Drift。

这让“带走 Agent”不只是备份，而是一次可预览、可追踪的复现。

再跑一次，确认它仍然好用

基础设施部署正确，不等于 Agent 的效果仍然正确。

OpenAgentPack 自带本地 Playground。运行agents playground后，它会读取同一份agents.yaml，让你选择已声明的 Agent，发起真实的云端 Session，观察工具调用和产物。

还是那个研究 Agent：上传访谈记录和市场调研 PDF，再交给它一个熟悉的任务。

帮我把这些访谈记录和市场调研笔记整理成一份结构清晰的行业研究报告，要求结论先行、数据驱动。

你可以直接检查它是否读到了正确资料、调用了预期工具、是否仍按你的框架输出结果。

可以把它理解为：agents.yaml是图纸，plan和apply是施工，Playground 是验收。图纸能带走，验收也能在新环境重做。

从“我的 Agent”到“团队的工作方法”

当一个人能带走自己调好的 Agent，团队才能真正开始积累。

一位资深研究员沉淀的，不只是某次报告，而是信源判断、分析框架、工具使用方式和交付标准。把它们放进 Git 后：

1. 研究框架升级，可以通过 Pull Request 讨论和审查；
2. 工具、MCP 和权限扩大，有明确的变更记录；
3. 效果下降，可以回到一个已验证的版本；
4. 新同事可以复用经过验证的 Agent，而不是从零搭建；
5. 团队需要换账号、换环境或评估新 Provider 时，核心工作流仍在自己手里。

同样的方式也适用于日报周报、竞品追踪、内容生产、客服质检、数据分析和合规审阅。

如果这套工作流需要持续运行，也可以把 Agent、初始任务和调度方式一同声明为 Deployment：

deployments:daily-report:agent:reporterschedule:expression:"0 9 * * *"timezone:Asia/Shanghaiinitial_events:-type:user.messagecontent:"汇总昨天的项目进展，按模板生成日报。"

Agent 可以继续通过钉钉等 IM Channel 进入团队熟悉的入口；但它背后的角色、知识、工具和环境不再是一个只能在控制台里猜测的黑盒。

五分钟，把一个 Agent 带回 Git

OpenAgentPack 目前处于 Beta 阶段，1.0前公开 API 和agents.yamlSchema 仍可能调整。建议从你正在使用的一个测试 Agent 开始。

准备 Node.js 22 或更高版本，以及任一已支持 Provider 的凭据：

npm install -g@openagentpack/climkdirmy-agents && cdmy-agentsagents init

然后检查并预览你的第一个声明：

agentsvalidateagents plan

确认后部署，并运行一次真实任务：

agentsapplyagents session run"介绍一下你能做什么"--agent assistant

也可以启动本地 Playground：

agentsplayground

快速开始：github.com/modelstudio…

可运行示例：github.com/modelstudio…

Provider 能力矩阵：github.com/modelstudio…

把工作流留在自己手里

模型会变，账号和电脑会变，团队与平台也可能会变。

但你调教出的研究方法、工作流程和判断标准，不应该只活在某个控制台或某个个人环境里。

OpenAgentPack 想做的事情很具体：把云端 Agent 带回 Git，让它能被复现、验证、协作迭代，并在需要时保有迁移的选择。

相关链接：

[1]把一个 Agent 带回 Git：Star OpenAgentPack

github.com/modelstudio…

[2]提交 Issue

github.com/modelstudio…

[3]参与贡献

github.com/modelstudio…