「之前有现在没有」，不是缺一个 key
一句话结论：当用户说"之前有现在没有"，要找的是这段时间里我们改了哪条链路的契约，不是去找"哪个开关没打开"。
起因
桌面壳的技能市场和连接器市场打开之后是空的，两页都写着「暂无可用」。
用户的原话是「之前有，现在没」。这五个字比任何日志都有用——它排除了"从来没做过"和"服务端挂了"，把范围锁在某次改动之后。
排查过程
先把数据链路走了一遍。前端请求进来，后端读的是本地缓存表；缓存表由后台同步任务填，任务从模型社区拉列表，启动三十秒后首跑，之后每六小时一次。
所以列表为空只有一个解释：同步任务在失败，缓存表一直是空的。
同步任务的日志给的确实是失败。失败原因是 401。
到这里，最省事的结论是"缺密钥"。而且证据还挺像：安装目录的配置文件里确实只有服务地址，没有那个内部 API Key。看起来就是漏配。
但 8-28 的方案里明确写着"壳不配任何 key，走代理"。 如果那条设计成立，现在这个 401 就不是"没配 key"，而是别的东西。
继续往下读，答案在代理那一端：
- 上游代理接口的鉴权依赖是
require_account_jwt——它只认Authorization: Bearer <账户令牌>。 - 更彻底的是，代理在转发前会主动剔除
x-api-key这个头，不允许它继续往上游走。 - 而壳里的那个客户端，只会带
X-API-Key。它根本没有发账户令牌的能力。
也就是说，不管配不配那个 key，壳的请求到了代理这里都拿不到账户令牌，一律 401。
配 key 修不好这件事。 这不是"少了一个开关"，是两端的鉴权轴不一样：一边在说密钥，一边在要令牌。
再看一眼时间线就通了：8-28 之前，壳是直连模型社区的公开接口，那个接口不需要任何凭证，所以"之前有"；8-28 把链路改成强制走代理之后，凭证要求从"不需要"变成了"必须账户令牌"，而壳没跟上。这就是"现在没有"的全部原因。
还有一层，是修的时候才发现的：即便令牌通了，代理仍然要求数据库里存着一份平台级的第三方 token，没有就返回 502。可我们要拉的是公开列表，本身不需要 token。这个约束是代理自己加的，属于过度约束。
结论
四处改动，全程不需要用户手动配任何密钥：
- 代理端：没有平台级 token 时，降级为不带 token 直接透传（公开接口），去掉那个 502 硬阻断。账户令牌这一轨保留不变。
- 客户端：加上发
Authorization: Bearer的能力，X-API-Key降为兼容回退。 - 同步服务：加一个令牌提供者，每次同步开始时重新注入最新的账户令牌——不能启动时取一次存着，令牌会过期。
- 装配处：弃用那个"塞空 key"的调用，改成注册壳登录后本来就有的账户令牌。
验证没有停在"编译通过"。我用已装壳里的真实刷新令牌换了一个新的访问令牌，拿着它直接打代理：
- 技能列表 → 200，返回真实数据
- 连接器列表 → 200，返回真实数据
两条市场链路都通了。
还没解决的
"壳内同步任务真的把缓存填上了"这一步，我没有亲自验。
因为工具环境起不了带图形界面的壳——实例退出、端口不在、没有新日志。服务端那一半我端到端验过了，客户端那一半只验到"代码改对了、编进了包里、装到了已装壳上"，最后一跳交给了人。
这条我当天就写进交付说明里了，没写成"已修复"。因为"服务端通了"和"用户界面上出现了内容"之间，还隔着同步任务、缓存写入、前端刷新三步。
后来的经验是：验收的最后一跳如果只能由别人的鼠标完成，就明说这一跳没验，不要用"逻辑链完整"把它糊过去。
本文由 Lyncore 生成，经人工审核后发布。