AI 编码正在从「帮我写个函数」走向后台并行：工程师打开电脑时，多个 Agent 已经在独立分支上完成任务，正排队等待 review。
这不是科幻。后台 Agent 平台已经把任务执行从工程师的笔记本上解耦，让人从逐行结对转向分派任务和审查结果。
风向变了。AI 编码这件事，正从「你和一个 AI 结对」，变成「你指挥一支 Agent 舰队」。
社区给这种玩法起了个名字，叫 agentmaxxing：同时拉起多个 CLI Agent，每个待在自己的 git worktree 里干互不打架的活，人退到后面只管审 PR。能这么玩，靠的是 CLI Agent 无人值守执行、git worktree 隔离并行改动，以及后台运行环境把执行从个人设备上解耦。
舰队当然不是白嫖的。后台会话同样消耗模型额度，并发越高，成本增长越快。只有当审查 Agent 产出确实比从头实现更省时，这笔账才算得过来。
可舰队一旦拉起来，问题就变味了。
一个 Agent 在你本机开个终端跑跑，没什么。50 个 Agent 同时上，每个都连着你真实的 GitHub token、云密钥、生产数据库。
这些 Agent 还统统开着 bypass-permissions（跳过每一步人工确认，不然舰队走两步就卡在弹窗上）——这就不再是「AI 能不能写出这个函数」了。这是「我怎么让这群家伙别顺手把家给烧了」。
面向 Agent 的沙箱原语开始进入 Kubernetes 生态，这是个信号：问题已经从写代码，升级成了「基础设施该怎么托管一群 Agent」。「托管 Agent 平台」这个品类，就是这么被逼出来的。
不同平台开始提供沙箱执行、checkpoint、凭证管理和 Agent 运行时。原本关在企业内部的能力，正在被抽象成可部署的基础设施。
本文的主角，是其中走开源自托管路线的解法——LiteLLM Agent Platform。它最硬核的一招藏在凭证处理里，而这套机制也暴露了一个典型的混淆代理风险。
托管 Agent 平台，到底在管什么
跑个 Agent 不就是起个容器吗，至于专门搞一套平台？
至于。因为标准的 Kubernetes Pod，当初就不是为 Agent 这种货色设计的。Agent 是有状态的（记着上下文和半截推理）、单例的（一个会话对应一个身体）、还特别爱发呆（等你回话时纯空转）、更要命的是它要跑自己现写的、可能根本不可信的代码。
你想拿 StatefulSet 加无头 Service 加每个 Agent 一块 PVC 去硬拼，运维当场就想辞职。面向 Agent 的沙箱抽象，要解决的正是这份尴尬。
托管 Agent 平台干的核心就两件事：沙箱隔离——给每个会话一个独立的身体，谁也别影响谁；以及会话连续性——pod 重启、半夜滚动升级，Agent 不能从头再来，得接着上次的进度干。
一种务实的做法是把状态落到持久化存储，让 harness 收到终止信号后排水，并通过 checkpoint 恢复会话。这样滚动发布时，Agent 不至于把已完成的工作全丢光。
它没去重造模型路由那一摊，而是复用 gateway 的路由、成本核算、限流和兼容接口，把重点放在沙箱、会话、凭证金库与 harness 编排。说白了，「大脑」复用现成的，平台专心当好「身体」和「保安」。
这套架构还有个讲究的切分：负责推理、调模型的「大脑」是个常驻进程，手里没有 shell、没有文件系统；真正能跑 git、pytest、敲命令的「沙箱」则是一次性的、随会话生灭。两边靠工具调用通信。这么分的好处是，那个能为所欲为的部分，活得最短、隔得最开；空闲沙箱也可以自动回收，避免持续占用资源。
harness 也可以替换：挑一个执行器，挂上工具，写段 system prompt，部署，就能开跑。
把它放进版图看就清楚了：托管方案与自托管方案解决的是同一类问题，但信任边界不同。托管方案把运行环境交给服务提供方；自托管方案把沙箱、数据与凭证代理放在自己的基础设施里，同时承担部署与运维成本。选择哪一边，本质上是在控制权与省心之间取舍。
核心一招：开着「上帝模式」，也偷不走你的密钥
先说清楚这事为什么要命。
Agent 要真干活，你就得给它真东西：GitHub token、云密钥、数据库连接串。还得开 bypass-permissions——不然 50 个 Agent 每走一步都弹窗等你点同意，舰队直接瘫痪。可这一关，等于把最后一道人肉护栏也撤了；自动批准必须与隔离、最小权限和出网约束一起设计。
更麻烦的是，一旦「能读私有数据 + 会接触不可信内容（网页、issue、第三方依赖）+ 有对外发数据的通道」这三样凑齐，就形成了致命三件套：提示注入可以利用已有权限读取敏感信息，再借合法出口把数据送走。
风险路径并不复杂：不可信的 PR、issue、网页或依赖可以携带提示注入；拥有凭证和出网能力的 Agent 则可能把敏感信息写入评论、请求或其他合法通道。问题的共同点很扎心：护栏本身是 Agent 看得懂的规则，而规则无法替代强制的权限与网络边界。
那 LiteLLM 这套金库怎么防？思路很轴：干脆别让 Agent 碰到真密钥。
每个沙箱里，Agent 拿到手的是假货——比如 GITHUB_TOKEN=stub_github_a8f1。它怎么 echo，看到的都是这串 stub。真 key 只活在旁边一个叫 vault sidecar 的进程内存里。Agent 发出的每一个出网请求都得过这个 sidecar，而 sidecar 会在网络层、在数据包离开机器之前，把假 key 悄悄换成真 key。
请求流就一条线：Agent 带着 stub 发出 → vault sidecar 截下 → 换成真 key 转发 → 到达目标服务。Agent 自始至终不知道中间被掉了一次包。真 key 不进 Agent 进程、不进日志、不进 commit、不进模型上下文。哪怕这个 Agent 被彻底攻陷、开着上帝模式横冲直撞，它也偷不走一个自己根本没拿到手的东西。
和老办法比，这步跨得不小。把几种凭证保护思路摆到一起，差别一眼看清：
| 做法 | Agent 能否看到真值 | 防的是什么 | 软肋 |
|---|---|---|---|
| 密钥管理器 / Vault Agent | 能（最终塞进应用进程） | 来源集中、可轮转 | 值照样进进程、进日志 |
| 短期 + 最小权限 token | 能 | 缩小泄漏后的杀伤半径 | 没拦住「泄漏」本身 |
| 金库网络层换密钥 | 不能（只发 stub 给它） | 让真值压根不进 Agent | 拦不住「拿它去干坏事」 |
金库的彻底之处还体现在一次性凭证上：初始 git clone 用的 token 干完活立刻擦掉，Agent 想 git push，得走金库这条正规通道。
这种设计通常叫凭证代理（credential brokering）：把信任边界，从「Agent 和外部服务之间」，挪回到「Agent 和它的凭证之间」。核心不是某个厂商的 API，而是让凭证值留在 Agent 进程之外，只在受控的网络路径上按目标替换。
我第一次看懂这套设计，心里冒出来的是「对，就该这么干」。跟一个比你还会找漏洞的东西反复叮嘱「别读 .env」「别把 key 贴出来」，本就是稳输的买卖；把密钥从它够得着的地方直接搬走，才是工程师该有的解法——不赌它自觉，赌结构。不过先别急着鼓掌：能把真 key 藏起来，不等于能管住 Agent 拿它去干什么。
但金库不是银弹：一条混淆代理攻击路径
假设金库只负责把 stub 换成真 key，却不检查请求的目的地，Agent 就可以把金库变成一个混淆代理。
Agent 发现凭证是 stub，于是自己写一个 endpoint，用 stub 请求它，让金库在出网时换上真 key；真 key 随后到达 Agent 控制的服务器，并可能被读回、写入记忆。
这是教科书级的混淆代理（confused deputy）攻击。金库是个忠心耿耿的副手：你让它给任何出网请求贴上真凭证，它都照办。Agent 只要把请求指向自己控制的地址，副手就把真密钥乖乖交了出来。金库藏住了密钥的「值」，却没藏住「拿这把密钥行事的能力」。
混淆代理不是 AI 时代的新发明：一个手握权限的中间人，被没权限的一方诱骗着替它滥用权限。Agent 会写代码、组合工具并尝试替代路径，因此软规则不能承担最终的安全边界。
修复办法是：别再只信任「值」，连「去哪」一起锁死。每个凭证绑定允许的目标 host——只有请求去往预设目标时才替换，发去其他地址一律拒绝。这就堵住了把金库当中间人的路径。
但请别就此高枕无忧。host 绑定治得了「把真 key 导去 evil.com」，治不了下面这几样：
- 合法通道照样能外泄。真 token 即使绑定目标 host，被注入的 Agent 仍可能借评论、请求正文等合法功能带出敏感数据；它不需要看见 key 的值，凭证代理会替它认证。
- 数据不等于密钥。金库保的是凭证，不是凭证背后那堆数据。Agent 拿真凭证读出一大批私有数据，再从任何一个被允许的出口送出去，金库一点办法没有。
- 集中即靶子。集中保管凭证会放大供应链与代理滥权风险。
我的看法是：金库是个真本事，但把它当成「装上就安全了」的人，迟早要交学费。
真正守得住的，是 Agent 想不到的那一层
把这些攻击与风险路径串起来看，有条规律刺眼地浮出来：凡是 Agent 在自己的推理层面能观察和操作的护栏，都可能成为它寻找替代路径的对象。
denylist、权限提示和用户态沙箱都有同一个弱点：Agent 能观察规则、路径和反馈，就可能换一种等价表达、调用另一个入口，或把目标拆成多步继续尝试。安全边界不能只依赖模型服从它看得见的规则。
Agent 能用语言和逻辑推理到的那一层（用户态、denylist、权限提示），都在它的射程之内；真正守得住的，是它推理不到的、再往下的那一层。
那「再往下的那一层」是什么？是它的推理够不着的地方。硬件强制的 VM 边界算一个——microVM 用 KVM 给工作负载提供独立内核。网络层换密钥也算，掉包发生在 Agent 的观察点之外。还有目标绑定的出网白名单，把「对外通信」那条腿死死摁住。
隔离强度本就是一条阶梯：裸容器的 namespace 只隔资源不挡攻击，往上 seccomp 加固也还是同一个内核、挡误伤不挡蓄意，再往上 gVisor 用用户态内核拦系统调用、够强但没有硬件边界，最顶上才是 microVM 的硬件边界。Agent 要跑不可信代码，越往下越踏实。
所以一套像样的托管 Agent 平台，从来不靠一招金库走天下，而是层层叠：沙箱隔离兜底、网络层换密钥藏住值、host 绑定锁住流向、最小权限加短期 token 缩小残余威力、出网白名单掐住外泄、金丝雀凭证补上检测。
工程上可以用鉴权出网代理、默认拒绝的网络策略和 microVM 共同兜底：代理校验目标与协议，网络策略限制可达范围，硬件隔离缩小沙箱逃逸后的影响。把「对外通信」限制在最小白名单里，致命三件套就缺了一角，这正好补上 host 绑定堵不住的合法外泄通道。
一个好记的总纲是二选二原则：在提示注入还没被根治之前，一个全自动会话最多同时占「读不可信输入、碰敏感系统、对外通信」里的两样；三样全要，就加入人工确认，别全自动。
看清这些风险路径后，我自己的总结就一句：别跟 Agent 讲道理。凡是指望它自律、靠它「看不见」、求它「别越界」的防线，都可能被替代路径绕过；真正靠谱的，是把决定权从它够得着的地方，物理地搬走。
说到底，金库加沙箱加会话管理这一整套，本质上是在做一件事——把持续人肉盯守换成「基础设施替你兜底」。这才是托管 Agent 平台真正值钱的地方：它不是让 Agent 更聪明，是让你敢把一支舰队放出去。
后记
这套打法最初多见于企业内部平台。开源自托管方案做的事，是把这种「内部平台」打包成可以部署进自己集群的软件：先在内部验证，再抽象成可复用的基础设施。
也得说句实在话：快速演进的平台可能出现文档、架构和实现不同步。挑这个时候上车，你买的是方向，不是一个打磨完的成品。
能不能让一群 Agent 替你打工，门槛早就不是模型够不够聪明了。是你敢不敢把真钥匙交出去——而这，恰恰是平台该替你扛、而不该让 Agent 自己扛的事。