- seakee2026-08-17
前面其实在评论区提过几次 CPAMP 2.0，最近也一直在整理 2.0 的架构和后续方向，现在整体方案基本确定了，所以单独开个帖子和大家同步一下。
CPAMP 从最开始其实只是一个 CPA 的管理面板，后面慢慢加了请求监控、用量统计、账号巡检、Provider、凭证管理、额度管理等等东西。
功能越来越多以后，现在这种 CPA + CPAMP 两套服务独立部署、CPAMP 再通过 Management API 管理 CPA 的方式，很多地方已经开始限制后续功能继续往下做了。
所以 2.0 准备直接把这个问题解决掉。
2.0 最大的变化：CPA 会直接作为 CPAMP 的网关内核
目前使用 CPAMP 完整版，需要同时运行：
- CPA
- CPAMP
2.0 会把 CPA 直接作为网关内核集成进 CPAMP。
但是这里不是简单把两个项目代码揉到一起。
内部还是会拆成两个独立 runtime：
- CPA Runtime：负责真正的 API 请求、Provider、账号调度这些网关能力
- CPAMP Runtime：负责管理、监控、统计、配置、巡检这些能力
对于普通用户来说，最终就是一个 CPAMP，不需要再单独部署和维护两个容器。
CPA 还是 CPA，只是 CPAMP 可以直接管理自己的 CPA Runtime 了。
从 1.x 升级不会要求重新配置
这个也是我现在比较优先考虑的问题。
2.0 第一次启动会有一个迁移向导，现有 CPAMP 用户可以直接迁移原来的配置和数据。
目前计划会有两个选择：
1. 使用 CPAMP 内置 CPA Runtime
这个会是默认推荐的方式。
现有 CPA 配置迁移进来以后，以后 CPA 和 CPAMP 就作为一个整体维护。
2. 继续连接外部 CPA
如果现在有比较复杂的部署方式，或者暂时不想迁移，也可以继续使用原来的 CPA。
所以不会出现升级 2.0 以后必须重新折腾一遍部署的问题。
API 流量也会真正进入 CPAMP 的整体架构
现在 CPAMP 本质上还是 CPA 的旁路管理服务。
到了 2.0 以后，因为 CPA Runtime 已经属于 CPAMP 本身，很多之前不好做或者做起来比较别扭的事情就可以真正做了。
比如：
- API Key 更完整的管理
- 每个 Key 的 Token / 费用限制
- 请求级别的安全控制
- 自定义 API 前缀
- 自定义管理面板前缀
- 异常请求检测和拦截
- 更完整的通知能力
- Runtime 状态和故障诊断
还有之前很多佬提过的一些安全相关功能，也会在这个架构下面重新考虑。
这些目前都属于 2.0 的方向，不代表首个 2.0 版本会一次全部做完。
架构先搭好，功能后面慢慢补。
2.0 也会顺便把现在的一些历史债清掉
CPAMP 一路从一个 management.html 慢慢加到现在，代码里面其实已经积累不少历史包袱了 Image: ^-^
2.0 会趁这个机会重新整理：
- 前后端彻底分离
- Manager Server 模块重新拆分
- CPA / CPAMP Runtime 边界
- 配置和数据结构
- 请求链路
- 安全边界
- management.html 这个大一体彻底退出主架构
这部分用户可能看不到特别明显的功能变化，但是对后面长期维护比较重要。
不然继续在现在架构上不停往上叠功能，我感觉迟早要把自己埋进去 Image: ^-^
还有一个边界提前说一下
CPAMP 2.0 不会往 New API / Sub2API 那种公共 API 分发平台方向发展。
CPAMP 最主要的定位还是：
个人使用 + 自托管 + 小团队有限共享。
可以做 API Key，可以限制额度，也可以给家里、朋友或者小团队使用。
但是不会去做复杂的多租户、充值、计费、套餐、代理商这些商业运营系统。
这些东西一旦做进去，项目的复杂度和长期维护成本会直接变成另外一个级别。
这个边界目前不会变。
1.x 不会马上停止维护
2.0 开发期间 1.x 还是当前稳定主线。
Bug、CPA 兼容、安全问题这些该修还是会继续修。
我也不会为了赶 2.0 把一个还不能正常迁移和使用的版本直接丢出来。
等 Runtime、迁移和基础链路稳定以后，才会开始让 1.x 用户正式迁移。
CPAMP 从最开始做到现在，很多功能其实都是 Linux Do 上面的佬提出来，然后一点一点加进去的。
有些需求最后做了，有些需求因为架构或者项目边界没有做，也有不少 PR 和 issue 帮我发现了之前根本没考虑到的问题。
所以 2.0 现在虽然大的方向已经确定了，但具体功能还是可以继续讨论。
大家有什么觉得 “如果 CPA 真正内置以后，这个功能就应该有了” 的，可以继续在下面提。
我再看看能不能给自己多挖几个坑 Image: ^-^
也再次感谢各位佬对 CPAMP 这么长时间的支持，以及优秀的建议与提议。
项目地址：
github.com
GitHub - seakee/CPA-Manager-Plus: A self-hosted CPA / CLIProxyAPI management panel...
A self-hosted CPA / CLIProxyAPI management panel and AI gateway observability dashboard for requests, usage, cost, quota, failures, and account health.
主楼 - 忒2026-08-17
大佬真牛掰，2.0确实解决了几个痛点问题。期待早日发布
- Starry47852026-08-17
如果这样的话 那佬要怎么及时跟进最新的 cpa 版本是个比较大的问题 ^-^
- seakee2026-08-17
CPAMP 可以管理内置 CPA 的整个生命周期，可以设置自动更新或者手动更新，CPAMP 本身也会使用现在的策略，及时的更新对 CPA 的适配，CPA 维护者也会第一时间告知我们版本变化的。
- 2咚个隆咚锵22026-08-17
如果我没记错的话，先是CPA把管理端拆出去了专注做转发，现在这是管理端要把CPA再绑回去，那你还能跟得上CPA的更新速度吗？有时候真是觉得世界是个草台班子。
- xcafe2026-08-17
希望可以内置一些伪装header参数，现在有些站为了防止二次分发，只允许在codex、cc客户端使用，但是CPA只是个人使用，不想频繁切换配置文件，尤其是codex的配置文件，简直是灾难级别。cc的配置文件只需要改url和key，codex里面好多MCP之类的配置。
- seakee2026-08-17
但是这里不是简单把两个项目代码揉到一起。
内部还是会拆成两个独立 runtime：
- CPA Runtime：负责真正的 API 请求、Provider、账号调度这些网关能力
- CPAMP Runtime：负责管理、监控、统计、配置、巡检这些能力
对于普通用户来说，最终就是一个 CPAMP，不需要再单独部署和维护两个容器。
CPA 还是 CPA，只是 CPAMP 可以直接管理自己的 CPA Runtime 了。
内置 CPA，然后管理 CPA 的生命周期，不是在 CPA 的基础上二开。这样为了解决分开部署产生的很多连接问题。
- seakee2026-08-17
这个应该不需要吧，CPA 现在是会透传客户端信息的，只要使用 Codex，那么上游看到的就是 Codex 的请求
- co1dsand2026-08-17
cy期待一手，cpamp一直在用，支持佬
- VanDu2026-08-17
建议层主好好看看楼主的表述，我没看到哪里说要把 CPA 绑回去的设定了，边界很明确的，是为了解决部署的真实问题而做的一些调整
- Aluozzz2026-08-17
一直在用CPAMP,感谢佬提供的轮子。期待2.0
- CK2026-08-17
使用了佬的项目和强大啊，但是合并我认为还是要继续兼容外部连接CPA，因为CPA我看几乎是天天有更新呢 ^-^
- seakee2026-08-17
2. 继续连接外部 CPA
如果现在有比较复杂的部署方式，或者暂时不想迁移，也可以继续使用原来的 CPA。
所以不会出现升级 2.0 以后必须重新折腾一遍部署的问题。
肯定兼容的呀，使用内置 CPA 是一种方式，外置也是一种方式。当前设计是为了解决之前反馈好久的部署连接问题 ^-^
在和 CPA 的维护者们讨论后，一直觉得提供内置 CPA 会很大程度上解决很多分开部署连接问题，但也不会放弃原先直接连接外部 CPA 的方式的。
- testG2026-08-17
cpa的插件应该能够稳定使用，并且能够访问cpa内部的一些东西做到一些目前cpamp不能做到的事，我觉得做个插件放到cpa里面然后链接到cpamp也行？因为cpa更新太频繁了。我现在一直在用cpamp，做的确实很好，但是也希望增加一些cpa没有的管理功能，比如认证文件的分组，key的分组这些东西，佬继续加油，cpamp确实很好用，我喜欢 ^-^
- alizoed2026-08-17
- undefined2026-08-17
挺期待的，现在cpamp还没用。
cpa本身的插件api有点不够用，想自己弄插件都不咋好弄。
比如我想弄个插件在某个渠道连续抽风时弹个系统提醒，
但直接拿不到base-url，要实现就稍微有点折腾，
比如要自己读配置，然后做对应之类的。。
估计cpa那边是安全考虑。
- seakee2026-08-17
5h/7d/1m 这些已经在详细的计划列表中了
- seakee2026-08-17
插件这个我其实已经有类似的规划，不过定位会比较窄，主要是处理一些必须在 CPA 内部才能完成的能力，不会把 CPAMP 和 CPA 的主要通信都建立在插件上。
CPA 更新快这个我觉得和插件关系不大，插件本身也一样需要做版本兼容。如果比较追求 CPA 最新版本，2.0 到时候可以直接把 CPA 更新策略设置成自动更新；比较在意稳定性的话就用经过适配的版本。
认证文件分组、Key 分组这些我记下了，不过功能还是得看实际使用场景和优先级，不一定会单纯为了“分组”去做。如果后面和 Key 策略、路由、额度这些能力能结合起来，价值会更大一些。
- watermelon-linuxdo2026-08-17
想询问一下佬有没有打算做上游路由控制相关功能，例如某只API key只能用[[email protected]](https://feedbbs.com/cdn-cgi/l/email-protection)这只上游帐号(认证文件)，不能用[[email protected]](https://feedbbs.com/cdn-cgi/l/email-protection)
- leeiemeng2026-08-17
那这样就太好了，非常期待，目前一直用的cpam