北京
一次支付系统的发布出了问题，线上结算功能直接崩溃。我部署的AI事件代理立刻检测到了失败请求，并精准地将问题关联到刚上线的版本。它给出的建议完全正确：回滚支付服务。
即便如此，我还是坚决拒绝把Kubernetes凭证直接交给它。这个矛盾催生了我为SigNoz黑客马拉松打造的项目——MANDATE。它本质上是一个架设在AI代理与能改变真实系统状态的工具之间的授权层。在这个架构里，SigNoz的角色早已超越了事后追踪，它能检测事件、为决策提供有边界的证据、完整记录审批与执行路径，并最终验证系统是否真的恢复了。
对于普通的AI代理追踪，信息往往是：跑了哪个模型、调用了什么工具、耗时多久、消耗了多少Token。但要让一个能自主采取行动的代理真正可被信任，我需要另一套答案：谁赋予了这个代理权限？它被允许接触哪些工具和资源？是什么实时证据支撑了它的行动？既定策略是允许、拒绝还是暂挂等待审批？操作员最终批准的具体指令参数是什么？以及最关键的一步，这个动作在生产环境中真的生效了吗？
MANDATE的设计哲学就是把这些决策过程从模型的黑箱里剥离出来。代理可以去提议一个看似合理的下一步，但一道确定性的网关会接手一切。它根据一个经过签名的授权令牌和完全由操作员掌控的配置，来推导身份、划定资源范围、评估风险、框定预算、判定所需证据级别并最终执行审批策略。这套参考技术栈的核心是一道基于Python和FastAPI构建的网关，配合Next.js开发的操作员控制台，通过Slack进行审批交互，后端跑在一个Kind Kubernetes集群上。可观测性则由OpenTelemetry与自托管的SigNoz实例承担，整套环境通过Foundry自动供给。代理只能通过MCP协议或REST接口接入，而敏感的Kubernetes凭证和SigNoz服务账号密钥自始至终只停留在网关侧，没有越界的可能。
我用来测试的场景极其精简：一个结算服务去调用支付服务。一次受控的发布将支付服务的部署镜像换成了一个有回归缺陷的版本，结算失败量应声暴涨。SigNoz里设置了一条原生的指标告警，紧盯五分钟内的结算失败率。同时，另一条基于追踪链的规则专门侦测一个名为mandate.release.deploy的Span，并捕获其中mandate.release.regressed为true的标记。这让我同时拿到了客户侧的真实影响和清晰的技术发布标记，而不是逼着代理去对着红色曲线图瞎猜。
一旦服务或发布告警被触发，SigNoz会向MANDATE网关发送一个Webhook。事件协调器会持有一个短期有效的根授权令牌入场，随即委派一个仅有只读权限的子级去进行侦查。这个调查员能去检查支付服务的部署状态，也能在限定时间内查询一份被严格划定范围的事件证据包，但它绝无可能继承任何新的工具权限，更别说直接去碰集群了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
