每做一个新系统，账号、登录、组织、角色、权限，这层都得从头再搭一遍。几周的活，每个项目重写一遍，坑也重踩一遍。偏偏这层还特别不容错，一个小 bug 就可能变成一次安全事故。
base-servers 想把这层做一次、做对，以后直接调就行。
但光是这样它不值得存在。Auth0、Keycloak 早就把 SSO 和统一身份给你了。它值不值得，全看另一件事：2026 年大家都在往系统里塞 AI agent，可没人把"从一开始就拿 agent 当正经主体"的身份和权限底座打包好。传统身份系统里只有两种东西，一种是活人，一种是一把死的 API Key。agent 卡在中间，它有自己的身份，但它是替人做事的。你现在让 agent 干活，基本等于给它塞一把万能钥匙：权限太大、拿了就永久有效、出了事还收不回来。
我赌的就是这个空位。下面是造它的路上几个我想记下来的岔路口。
那个几乎不花钱的赌
野心很容易失控。"agent 的身份、属性、权限，agent 之间怎么通信"，听着就想去做一张很大的 agent 通信网。我没做。
我只做了一件很便宜的事：把"主体"从人和机器两类，扩成人、服务、agent 三类，再把"某个 agent 替某个人做事"这种受托关系当成一个正经概念。这几乎只是改了几张表的形状，但它让 base-servers 从第一天起就是"人和 agent 共用的底座"，而不是"给人做的系统，回头再给 agent 打补丁"。
赌注就在这儿：几乎不花额外的钱，去占一个正在起量、又还没人占的位子。至于 agent 通信网那种大工程，我只保证一件事，地基能撑住它以后长出来，但现在绝不做。
形态：自托管，不做 SaaS 也不做 SDK
第一个要定的是形态。三个选择：托管 SaaS（像 Auth0）、自托管服务（像 Keycloak）、代码库或 SDK（像 better-auth）。
代码库第一个被我砍掉。它绑语言、绑数据库。一个用 Go、一个用 Python 的系统没法共用同一个库，这跟我想要的"任何系统都能调"直接打架。
SaaS 我没一上来就做。那意味着第一天就得背上计费、多租户隔离、SLA、合规一整套包袱，价值还没证明，先扛重成本。
最后选了自托管服务，但给自己加了一条：架构上从第一天就得能长成 SaaS，也就是无状态、能多租户。这样我自己的项目现在就能用，以后真想开托管版，是加一层，不是推倒重来。说白了就是拿"晚点再赚钱"，换"现在能用、以后不返工"。
造还是买
接下来是我最想讲的一个判断：哪些自己造，哪些别造。
自己写 OAuth2、OIDC，自己实现令牌加密，这是安全雷区，也是重复造轮子。我给自己定过一条规矩，先搜再造，这一步正好用上。
我的决定是：拿一个成熟的开源身份引擎当发动机，我只造别人没造好的那部分，也就是 agent 的委托层、统一的对外 API、还有模块化的打包方式。中间隔一层适配器，不被哪一家绑死。
想清楚这个我才敢下手：令牌怎么加密不是护城河，那是通用件，谁做都一样；真正的护城河是"天生为 agent 设计"和"一套好用的统一接口"。想明白这点，造还是买就不纠结了，通用件买来站上面，省下的力气全砸在那层没人做好的东西上。
引擎我横着比了几个主流开源方案，最后挑了一个当默认。原因很实在：它同时压中我最在意的两点，license 干净、能外发，以及 agent 委托里最难、最容易出安全问题、本来得我自己造的那几件事，它现成就有。代价是它偏重，自托管吃点内存。我算过账：规模小的时候每月也就贵十来块钱、差一台机器的档；规模一大，钱都花在数据库和流量上了，引擎那点内存根本是零头。而且它藏在适配器后面，调用方压根不知道里面是谁，这份"重"只压在我运维这一侧，不外泄。拿一点运维上的重量，换掉自己重造几个安全雷区，这买卖划算。
别让人整颗吞下去
还有一条我定得比较早。
我本来把所有基础服务按依赖关系画成一颗洋葱：内核（身份、组织、权限），外面是安全、触达、商业化、数据。画完我问自己一句：是不是所有业务都需要每一层？
不是。B2C 的消费 app 根本没有"组织"这个概念；纯内部系统不收费，要"计费"干嘛。要是做成"想用就得整颗吞下去"，这东西会重到没人愿意接。
所以定了：一个极小的强制内核，外面一圈可选、可分档的模块，用什么开什么。连同一层里面都能降级，比如权限，可以只用"谁拥有、谁能改"这种归属级，也可以上角色，以后还能上更细的关系图授权。别逼人买他不需要的东西，这一条直接决定了它能不能被广泛接进去。
一次拆弹：我差点把船期押在别人还没稳的东西上
不是每个决定我都一次想对。讲一个我差点搞砸的。
一开始我把"完整的 agent 委托流"设成了 v1 不能退的硬指标，里面还包括一个"实时撤销"：权限一撤，几秒内全网失效。
后来找人来 pressure-test，被问出一个我自己没看清的问题：我把两件风险完全不同的事捆在了一起。
一件是"委托语义"，签一张很窄的令牌，保证 agent 的权限永远不超过授权它的人。这是我自己的代码，完全可控。另一件是"实时撤销"，它是传输层的一道加固，依赖引擎里一个还在实验、默认关着的特性，这我控不了。我等于把 v1 的船期押在了别人还没稳的路线图上。自找的。
拆弹的办法是留行为、换机制。用户要的其实是那个体感：撤了几秒内失效。这个用短有效期加一张黑名单今天就能做到，效果一样。那个更漂亮但不可控的机制，下放到 v1.1，适配器留同一个接口，以后无痛升级。
这事给我留下的教训很朴素：分清哪些我能控、哪些控不了，别把交付绑在后者上。
现在到哪了，和几句交底
说点实在的，免得这篇读着像在吹。
现在真正跑通、而且拿真容器（不是 mock）端到端测过的，是地基那层：三类主体的建立和读取，组织和权限的骨架。压轴那块，也就是完整的 agent 委托，还在路线图上，没造。整个东西是 alpha，离生产可用还有距离。我不打算把它说成"一个做好的 agent 权限平台"，它现在是"想清楚了、地基搭好了、赌注押下了"的一个东西。
再交个底：这个赌能不能兑现，靠的不是架构漂亮，是执行。得让"接 base-servers"明显比"自己攒一套"轻，轻到别人懒得自己造。agent 身份这个窗口正热，早一步、而且贴着标准走，是我唯一的时间优势。
最后一件该说的：这层东西传统上是一支后端团队干几周的活。我是个产品人，不是后端工程师，这套地基基本是一天、重度借着 AI 搭起来的。我不觉得这是该藏的事。恰恰相反，值钱的从来不是那点速度，是上面这几个岔路口我怎么选的。AI 把"做出来"压得很便宜之后，剩下能拉开差距的就是判断。这个项目，算我拿自己验了一遍这句话。