1. 項(xiàng)目緣起當(dāng)AI智能體涌入Kubernetes我們?nèi)绷耸裁醋罱肽晡宜诘膱F(tuán)隊(duì)一直在探索如何將各類AI智能體Agent安全、高效地部署到Kubernetes集群中。從簡(jiǎn)單的任務(wù)調(diào)度器到復(fù)雜的多步推理工作流我們嘗試了各種框架和模式。但很快一個(gè)比“如何運(yùn)行”更根本的問(wèn)題浮出水面在一個(gè)動(dòng)態(tài)、多租戶的K8s環(huán)境里我們?nèi)绾沃馈罢l(shuí)”在運(yùn)行如何信任它以及當(dāng)我們需要調(diào)用某個(gè)特定能力的智能體時(shí)又該如何精準(zhǔn)地找到它這聽(tīng)起來(lái)像是服務(wù)發(fā)現(xiàn)Service Discovery和身份認(rèn)證Identity的老問(wèn)題但AI智能體帶來(lái)了全新的挑戰(zhàn)。傳統(tǒng)的K8s Service通過(guò)標(biāo)簽Label選擇器來(lái)暴露一組Pod其核心假設(shè)是后端實(shí)例是相對(duì)靜態(tài)、功能同質(zhì)的。而AI智能體往往是有狀態(tài)的、能力異構(gòu)的、生命周期多變的。一個(gè)負(fù)責(zé)代碼審查的Agent和一個(gè)負(fù)責(zé)日志分析的Agent雖然都是Pod但它們的“身份”遠(yuǎn)不止一個(gè)IP地址或服務(wù)名那么簡(jiǎn)單。這個(gè)身份需要包含其能力描述、所屬項(xiàng)目、版本、甚至其訓(xùn)練數(shù)據(jù)的哈?；蚰Ｐ椭讣y以便調(diào)用方能夠驗(yàn)證其可信度。更棘手的是治理Governance。當(dāng)成百上千個(gè)由不同團(tuán)隊(duì)、甚至不同供應(yīng)商開(kāi)發(fā)的AI智能體在集群中共存時(shí)如何審計(jì)它們的調(diào)用鏈如何實(shí)施基于能力的訪問(wèn)控制比如只有經(jīng)過(guò)安全審計(jì)的“金融數(shù)據(jù)查詢Agent”才能訪問(wèn)生產(chǎn)數(shù)據(jù)庫(kù)如何確保一個(gè)聲稱是“最新版翻譯Agent”的Pod沒(méi)有被惡意替換或篡改現(xiàn)有的K8s原生資源如Service、ConfigMap、乃至新興的ServiceEntryIstio都無(wú)法完整地承載這些元數(shù)據(jù)和安全訴求。我們需要的不是一個(gè)簡(jiǎn)單的服務(wù)注冊(cè)中心而是一個(gè)面向AI智能體的、可驗(yàn)證的信任層。這就是我們啟動(dòng)“Agent Name Service”ANS概念驗(yàn)證項(xiàng)目的核心動(dòng)機(jī)。它不是一個(gè)要替代現(xiàn)有系統(tǒng)的龐然大物而是一個(gè)輕量的、增量的信任層旨在為Kubernetes中的AI智能體生態(tài)補(bǔ)上最關(guān)鍵的一塊拼圖。2. ANS核心架構(gòu)一個(gè)基于聲明式身份的信任三角ANS的設(shè)計(jì)哲學(xué)非常明確輕量、聲明式、可驗(yàn)證。我們不希望引入一個(gè)中心化的、沉重的控制平面而是充分利用Kubernetes已有的擴(kuò)展能力和聲明式API的理念。整個(gè)系統(tǒng)的核心圍繞著三個(gè)關(guān)鍵概念構(gòu)建我稱之為“信任三角”身份聲明Identity Claim、信任錨點(diǎn)Trust Anchor和發(fā)現(xiàn)端點(diǎn)Discovery Endpoint。2.1 身份聲明從Pod到“可信智能體”在K8s里一個(gè)Pod最基本的身份是它的名稱和命名空間。但這對(duì)于智能體來(lái)說(shuō)遠(yuǎn)遠(yuǎn)不夠。ANS引入了一個(gè)新的自定義資源定義CRDAgentIdentity。apiVersion: ans.acme.corp/v1alpha1 kind: AgentIdentity metadata: name: code-review-agent-v1 namespace: platform-team spec: # 核心身份描述 agentRef: kind: Deployment name: code-review-agent namespace: platform-team capabilities: - name: code_review version: 1.2.0 description: Static analysis and security vulnerability detection for Python/Go code. inputSchema: {...} # OpenAPI Schema 片段 outputSchema: {...} # 可驗(yàn)證的憑證 verifiableCredentials: - type: ModelIntegrity issuer: internal-model-registry.acme.corp claim: sha256:abc123... # 容器鏡像中模型文件的哈希 proof: jwt:eyJ... # 由簽發(fā)者簽名的JWT - type: SecurityAudit issuer: security-team.acme.corp claim: passed_penetration_test_v2 validUntil: 2024-12-31T23:59:59Z # 治理元數(shù)據(jù) owner: platform-engineeringacme.corp project: devsecops-automation lifecycleStage: production這個(gè)AgentIdentity資源就是智能體的“身份證”。它不直接控制Pod的創(chuàng)建而是通過(guò)agentRef關(guān)聯(lián)到實(shí)際的工作負(fù)載Deployment、StatefulSet等。capabilities字段是關(guān)鍵它用結(jié)構(gòu)化的方式描述了智能體能做什么這比K8s Label的鍵值對(duì)更豐富、更機(jī)器可讀。verifiableCredentials是信任的基石它允許外部權(quán)威機(jī)構(gòu)如內(nèi)部模型倉(cāng)庫(kù)、安全團(tuán)隊(duì)為智能體的特定屬性如模型完整性、安全審計(jì)狀態(tài)背書(shū)并生成密碼學(xué)證明。為什么選擇CRD而不是Annotation我們最初考慮過(guò)用Pod Annotation來(lái)存儲(chǔ)這些信息。但CRD提供了更強(qiáng)的類型安全、獨(dú)立的生命周期管理智能體身份可以在Pod重建后依然存在、以及更便捷的查詢能力通過(guò)K8s API。更重要的是它符合K8s的“資源即狀態(tài)”哲學(xué)。2.2 信任錨點(diǎn)如何建立和傳遞信任有了身份聲明接下來(lái)要解決“誰(shuí)說(shuō)了算”的問(wèn)題。在零信任架構(gòu)中我們不能默認(rèn)信任集群內(nèi)的任何實(shí)體。ANS的信任模型基于公鑰基礎(chǔ)設(shè)施PKI的簡(jiǎn)化變體。根信任錨Root Trust Anchor在集群初始化時(shí)由集群管理員部署一個(gè)包含公鑰的ConfigMap或者更佳實(shí)踐是使用K8s的CertificateSigningRequest(CSR) API關(guān)聯(lián)一個(gè)外部證書(shū)頒發(fā)機(jī)構(gòu)CA。這個(gè)錨點(diǎn)對(duì)所有AgentIdentity中verifiableCredentials的簽發(fā)者issuer進(jìn)行認(rèn)證。憑證簽發(fā)者Credential Issuers像“內(nèi)部模型倉(cāng)庫(kù)”、“安全團(tuán)隊(duì)”這些實(shí)體它們需要向根信任錨證明自己的身份并獲得簽發(fā)特定類型憑證的權(quán)限。在PoC中我們通過(guò)為這些服務(wù)配置特定的ServiceAccount并綁定相應(yīng)的RBAC角色來(lái)實(shí)現(xiàn)其行為記錄可通過(guò)K8s審計(jì)日志追蹤。憑證驗(yàn)證鏈當(dāng)一個(gè)服務(wù)消費(fèi)者需要調(diào)用某個(gè)智能體時(shí)它從ANS發(fā)現(xiàn)端點(diǎn)獲取到目標(biāo)AgentIdentity。消費(fèi)者并不需要完全理解所有憑證它只需要驗(yàn)證兩點(diǎn)第一憑證的簽發(fā)者issuer是否在它信任的列表中這個(gè)列表可以來(lái)自根信任錨第二憑證的簽名proof是否有效。這個(gè)過(guò)程可以在消費(fèi)者端離線完成無(wú)需每次都查詢中心化的授權(quán)服務(wù)。這個(gè)設(shè)計(jì)的巧妙之處在于解耦。安全團(tuán)隊(duì)只負(fù)責(zé)簽發(fā)“安全審計(jì)通過(guò)”的憑證模型倉(cāng)庫(kù)只負(fù)責(zé)簽發(fā)“模型哈希一致”的憑證。智能體的所有者負(fù)責(zé)將這些憑證收集起來(lái)聲明在自己的AgentIdentity中。而智能體的消費(fèi)者則可以根據(jù)自己的安全策略決定需要哪些憑證才能建立信任例如“對(duì)于處理PII數(shù)據(jù)的智能體必須同時(shí)具備‘安全審計(jì)’和‘?dāng)?shù)據(jù)加密認(rèn)證’兩張憑證”。2.3 發(fā)現(xiàn)端點(diǎn)超越Kubernetes Service的智能查找傳統(tǒng)的服務(wù)發(fā)現(xiàn)kubectl get svc或DNS查詢返回的是IP和端口。ANS的發(fā)現(xiàn)端點(diǎn)一個(gè)簡(jiǎn)單的HTTP/gRPC服務(wù)返回的是富語(yǔ)義的智能體身份信息。發(fā)現(xiàn)端點(diǎn)提供兩種主要查詢模式精確發(fā)現(xiàn)通過(guò)唯一的AgentIdentity名稱進(jìn)行查詢。這適用于已知確切身份的調(diào)用場(chǎng)景。能力發(fā)現(xiàn)這是更強(qiáng)大的功能。消費(fèi)者可以提交一個(gè)“能力需求清單”進(jìn)行查詢。{ requiredCapabilities: [ {name: sentiment_analysis, minVersion: 2.0.0}, {name: chinese_language} ], requiredCredentials: [ {type: ModelIntegrity, issuer: trusted-model-hub}, {type: DataPrivacy, level: gdpr_compliant} ] }發(fā)現(xiàn)端點(diǎn)會(huì)掃描所有AgentIdentity找出同時(shí)滿足能力要求和憑證要求的智能體并返回它們的訪問(wèn)端點(diǎn)通常是關(guān)聯(lián)的K8s Service地址和完整的身份信息。這個(gè)發(fā)現(xiàn)端點(diǎn)本身是無(wú)狀態(tài)的它通過(guò)監(jiān)聽(tīng)K8s API Server實(shí)時(shí)索引集群內(nèi)所有的AgentIdentity資源。它的高可用可以通過(guò)簡(jiǎn)單的Deployment多副本來(lái)實(shí)現(xiàn)。為了性能我們可以在內(nèi)存中維護(hù)一個(gè)索引按能力和憑證類型進(jìn)行倒排使得即使面對(duì)上千個(gè)智能體查詢也能在毫秒級(jí)返回。3. 在Kubernetes中的集成與實(shí)踐從概念到運(yùn)行設(shè)計(jì)理念再美好也需要落地。接下來(lái)我將詳細(xì)拆解如何將一個(gè)現(xiàn)有的AI智能體工作負(fù)載接入ANS體系并展示一個(gè)完整的互操作流程。3.1 準(zhǔn)備工作部署ANS控制平面組件ANS的控制平面非常精簡(jiǎn)主要由三部分組成ANS Operator這是一個(gè)標(biāo)準(zhǔn)的K8s Operator負(fù)責(zé)管理AgentIdentityCRD并確保其狀態(tài)與關(guān)聯(lián)的工作負(fù)載一致例如當(dāng)對(duì)應(yīng)的Deployment被刪除時(shí)清理孤立的AgentIdentity。使用Operator Framework如Kubebuilder開(kāi)發(fā)部署為一個(gè)Deployment。發(fā)現(xiàn)端點(diǎn)服務(wù)Discovery Endpoint Service如前所述一個(gè)提供查詢API的服務(wù)。我們選擇用Go編寫(xiě)利用client-go庫(kù)監(jiān)聽(tīng)AgentIdentity資源的變化。它通過(guò)ClusterIP Service暴露。信任錨點(diǎn)配置我們選擇使用K8s的ValidatingWebhookConfiguration和自簽證書(shū)作為一個(gè)輕量級(jí)的起點(diǎn)。為簡(jiǎn)化PoC我們預(yù)先將受信任的簽發(fā)者公鑰以ConfigMap形式掛載到發(fā)現(xiàn)端點(diǎn)和關(guān)鍵消費(fèi)者Pod中。部署清單大致如下# 1. 安裝CRD kubectl apply -f deploy/crd/agentidentity.yaml # 2. 部署ANS Operator和RBAC配置 kubectl apply -f deploy/operator.yaml # 3. 部署發(fā)現(xiàn)端點(diǎn) kubectl apply -f deploy/discovery-service.yaml # 4. 配置信任錨示例將一個(gè)已知公鑰存入ConfigMap kubectl create configmap ans-trust-anchors --from-filepublic-key.pem./keys/trusted-issuer.pub3.2 為你的AI智能體申領(lǐng)“身份證”假設(shè)我們有一個(gè)已部署的“代碼安全掃描智能體”其Deployment名為code-scanner。接入ANS分為三步第一步由智能體所有者創(chuàng)建AgentIdentity。# code-scanner-identity.yaml apiVersion: ans.acme.corp/v1alpha1 kind: AgentIdentity metadata: name: prod-code-scanner namespace: ai-agents spec: agentRef: kind: Deployment name: code-scanner namespace: ai-agents capabilities: - name: static_analysis version: 3.1.0 description: Detects security vulnerabilities (SQLi, XSS, etc.) in Java and Python code. inputSchema: type: object properties: repositoryUrl: type: string branch: type: string required: [repositoryUrl] verifiableCredentials: # 假設(shè)我們已經(jīng)從內(nèi)部安全掃描服務(wù)獲取了一個(gè)簽名的JWT憑證 - type: SecurityScan issuer: internal-security-scanner.svc.cluster.local claim: severity_critical_zero proof: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9... # 實(shí)際的JWT令牌 owner: appsec-teamacme.corp應(yīng)用這個(gè)YAML文件kubectl apply -f code-scanner-identity.yaml。ANS Operator會(huì)驗(yàn)證agentRef引用的Deployment是否存在并將該AgentIdentity標(biāo)記為Bound狀態(tài)。第二步獲取可驗(yàn)證的憑證關(guān)鍵步驟。這是建立信任的核心。在我們的PoC中我們模擬了一個(gè)“內(nèi)部安全掃描服務(wù)”。該服務(wù)有一個(gè)獨(dú)立的Pod其ServiceAccount被授權(quán)使用特定的簽名密鑰。智能體部署后流水線可以調(diào)用這個(gè)掃描服務(wù)的API對(duì)智能體的容器鏡像進(jìn)行掃描。掃描通過(guò)后該服務(wù)會(huì)簽發(fā)一個(gè)包含掃描結(jié)果如severity_critical_zero并附有數(shù)字簽名的JWT令牌。這個(gè)令牌就是verifiableCredentials中的proof。第三步更新Service以供發(fā)現(xiàn)。這步是可選的但建議操作。為了能讓發(fā)現(xiàn)端點(diǎn)將AgentIdentity解析為可訪問(wèn)的網(wǎng)絡(luò)端點(diǎn)最佳實(shí)踐是確保智能體工作負(fù)載有一個(gè)同名的K8s Service。ANS發(fā)現(xiàn)端點(diǎn)會(huì)默認(rèn)嘗試查找agentRef.name這個(gè)Service。如果Service名稱不同可以在AgentIdentity的status字段或通過(guò)注解來(lái)指定。3.3 消費(fèi)者如何發(fā)現(xiàn)并調(diào)用一個(gè)可信智能體現(xiàn)在另一個(gè)團(tuán)隊(duì)想要在CI流水線中集成代碼安全掃描。他們不需要知道智能體具體部署在哪里只需要找到一個(gè)可信的、具備該能力的智能體。第一步查詢發(fā)現(xiàn)端點(diǎn)。消費(fèi)者Pod或外部服務(wù)可以向集群內(nèi)的發(fā)現(xiàn)端點(diǎn)發(fā)起查詢# 通過(guò)能力查找 curl -X POST http://ans-discovery.ai-system.svc.cluster.local/discover \ -H Content-Type: application/json \ -d { requiredCapabilities: [{name: static_analysis, minVersion: 3.0.0}], requiredCredentials: [{type: SecurityScan}] }第二步處理發(fā)現(xiàn)結(jié)果。發(fā)現(xiàn)端點(diǎn)會(huì)返回一個(gè)JSON數(shù)組包含匹配的智能體身份和訪問(wèn)信息[ { identity: { name: prod-code-scanner, namespace: ai-agents, capabilities: [...], verifiableCredentials: [...] }, endpoint: http://code-scanner.ai-agents.svc.cluster.local:8080, verified: true // 表示發(fā)現(xiàn)端點(diǎn)已初步驗(yàn)證憑證簽名 } ]注意發(fā)現(xiàn)端點(diǎn)返回的verified: true僅代表它驗(yàn)證了憑證的簽名有效性。消費(fèi)者必須根據(jù)自身的安全策略對(duì)憑證的具體聲明claim進(jìn)行二次校驗(yàn)。例如安全策略可能要求SecurityScan憑證的claim必須是最近7天內(nèi)簽發(fā)的。第三步執(zhí)行調(diào)用與驗(yàn)證。消費(fèi)者可以選擇verified為true且評(píng)分最高的智能體未來(lái)可以加入健康狀態(tài)、負(fù)載等指標(biāo)。在發(fā)起實(shí)際業(yè)務(wù)請(qǐng)求前一個(gè)嚴(yán)謹(jǐn)?shù)南M(fèi)者應(yīng)該從返回的verifiableCredentials中提取出JWT令牌proof。使用本地配置的、來(lái)自信任錨點(diǎn)的公鑰驗(yàn)證JWT的簽名確保憑證未被篡改。檢查JWT中的聲明如issuer,claim,exp是否符合自己的策略要求。只有全部驗(yàn)證通過(guò)消費(fèi)者才向endpoint發(fā)起業(yè)務(wù)請(qǐng)求。這個(gè)過(guò)程雖然增加了少量開(kāi)銷但實(shí)現(xiàn)了去中心化的、基于密碼學(xué)的信任驗(yàn)證避免了將所有信任決策依賴于一個(gè)中心化的網(wǎng)關(guān)。4. 深入治理策略引擎與可觀測(cè)性增強(qiáng)ANS提供的身份層為更高級(jí)別的治理奠定了數(shù)據(jù)基礎(chǔ)。在PoC中我們探索了兩個(gè)關(guān)鍵的治理擴(kuò)展動(dòng)態(tài)策略執(zhí)行和增強(qiáng)的可觀測(cè)性。4.1 基于OPA/Gatekeeper的策略執(zhí)行開(kāi)放策略代理OPA和它的K8s原生項(xiàng)目Gatekeeper是定義和執(zhí)行集群策略的事實(shí)標(biāo)準(zhǔn)。結(jié)合ANS的AgentIdentity我們可以實(shí)現(xiàn)精細(xì)化的治理規(guī)則。例如我們可以定義一個(gè)Gatekeeper約束模板Constraint Template禁止任何沒(méi)有有效“數(shù)據(jù)隱私憑證”的智能體被掛載含有敏感數(shù)據(jù)的卷# 約束模板require-data-credential-for-sensitive-volume apiVersion: templates.gatekeeper.io/v1beta1 kind: ConstraintTemplate metadata: name: requiredatacredentialforsensitivevolume spec: crd: spec: names: kind: RequireDataCredentialForSensitiveVolume targets: - target: admission.k8s.gatekeeper.sh rego: | package requiredatacredentialforsensitivevolume violation[{msg: msg}] { # 1. 檢查Pod是否掛載了標(biāo)記為敏感的卷 input.review.object.kind Pod volume : input.review.object.spec.volumes[_] volume.secret ! null volume.secret.secretName prod-database-credentials # 示例敏感密鑰 # 2. 查找Pod對(duì)應(yīng)的AgentIdentity通過(guò)標(biāo)簽或所有者引用 identity : data.inventory.namespace[namespace][“agentidentities.ans.acme.corp/v1alpha1”][name] # 3. 檢查Identity中是否包含所需的憑證 not cred : identity.spec.verifiableCredentials[_] cred.type DataPrivacy cred.issuer compliance-team.acme.corp # 4. 如果不滿足則生成違規(guī)信息 msg : sprintf(Pod %v uses sensitive volume but its AgentIdentity lacks required DataPrivacy credential, [input.review.object.metadata.name]) }然后創(chuàng)建一個(gè)約束實(shí)例apiVersion: constraints.gatekeeper.io/v1beta1 kind: RequireDataCredentialForSensitiveVolume metadata: name: require-data-cred-for-db-secret spec: match: namespaces: [ai-agents]當(dāng)有人嘗試部署一個(gè)掛載了prod-database-credentialsSecret但未關(guān)聯(lián)合規(guī)AgentIdentity的Pod時(shí)Gatekeeper會(huì)在準(zhǔn)入階段直接拒絕該請(qǐng)求。這實(shí)現(xiàn)了“基于身份的治理”策略的觸發(fā)條件從簡(jiǎn)單的資源屬性升級(jí)到了智能體可驗(yàn)證的信用屬性。4.2 可觀測(cè)性在鏈路追蹤中注入身份信息在微服務(wù)架構(gòu)中分布式追蹤如Jaeger、Zipkin通過(guò)TraceID將一次請(qǐng)求的多個(gè)服務(wù)調(diào)用串聯(lián)起來(lái)。對(duì)于AI智能體調(diào)用鏈我們同樣需要這種可見(jiàn)性并且希望看到更豐富的身份信息。ANS可以與OpenTelemetry這樣的可觀測(cè)性框架集成。在每個(gè)智能體的Pod中注入一個(gè)OpenTelemetry Sidecar或直接在應(yīng)用代碼中集成SDK。在創(chuàng)建Span代表一個(gè)工作單元時(shí)除了常規(guī)的標(biāo)簽還可以將AgentIdentity中的關(guān)鍵信息添加進(jìn)去例如agent.identity.name:prod-code-scanneragent.capability:static_analysis3.1.0agent.credential.security_scan:passed這樣在追蹤UI中查看一個(gè)CI流水線的調(diào)用鏈時(shí)你不僅能看到它調(diào)用了service-a和service-b還能清晰地看到它調(diào)用了**“具備安全掃描憑證的生產(chǎn)環(huán)境代碼掃描智能體v3.1.0”**。當(dāng)出現(xiàn)問(wèn)題時(shí)例如掃描結(jié)果異常你可以快速定位到具體是哪個(gè)版本的哪個(gè)智能體并查驗(yàn)其憑證狀態(tài)極大提升了排查效率。這個(gè)集成的價(jià)值在于將運(yùn)維數(shù)據(jù)追蹤、日志與安全/信任數(shù)據(jù)身份、憑證關(guān)聯(lián)了起來(lái)為故障診斷、合規(guī)審計(jì)和安全事件調(diào)查提供了統(tǒng)一的上下文。5. 概念驗(yàn)證的挑戰(zhàn)、取舍與未來(lái)演進(jìn)在構(gòu)建這個(gè)PoC的過(guò)程中我們遇到了不少預(yù)料之中和預(yù)料之外的挑戰(zhàn)也做出了一些關(guān)鍵取舍。挑戰(zhàn)一憑證的生命周期管理。verifiableCredentials中的JWT令牌會(huì)有過(guò)期時(shí)間。如何自動(dòng)輪換我們的方案是引入一個(gè)“憑證續(xù)訂器”Credential Renewer作為DaemonSet運(yùn)行。它監(jiān)視所有AgentIdentity在憑證過(guò)期前調(diào)用相應(yīng)的憑證簽發(fā)者服務(wù)申請(qǐng)新的令牌并更新AgentIdentity資源。這要求簽發(fā)者服務(wù)提供續(xù)訂API并且更新操作需要被RBAC嚴(yán)格控制。挑戰(zhàn)二性能與規(guī)模。發(fā)現(xiàn)端點(diǎn)的內(nèi)存索引在智能體數(shù)量極大數(shù)萬(wàn)時(shí)可能成為瓶頸。下一步演進(jìn)方向是引入分片索引或使用外部鍵值存儲(chǔ)如etcd的直接前綴查詢。此外消費(fèi)者端的JWT驗(yàn)證雖輕量但在超高頻調(diào)用場(chǎng)景下可以考慮使用短期緩存的驗(yàn)證結(jié)果。挑戰(zhàn)三跨集群與混合云場(chǎng)景。PoC聚焦于單個(gè)K8s集群。但在現(xiàn)實(shí)中智能體可能分布在多個(gè)集群、甚至云廠商之間。ANS的架構(gòu)可以擴(kuò)展每個(gè)集群部署自己的ANS實(shí)例管理本集群的AgentIdentity。然后通過(guò)一個(gè)全局的、更上層的“聯(lián)邦發(fā)現(xiàn)服務(wù)”來(lái)聚合各集群的目錄。信任錨點(diǎn)也需要升級(jí)可能需要一個(gè)全局的、多集群認(rèn)可的根CA體系。關(guān)鍵取舍深度集成 vs. 外部系統(tǒng)。我們?cè)懻撌欠裰苯邮褂肧PIFFE/SPIRE作為身份基礎(chǔ)。SPIFFE提供了強(qiáng)大的、標(biāo)準(zhǔn)化的身份框架。但考慮到AI智能體身份信息的豐富性能力描述、治理元數(shù)據(jù)和我們需要深度集成K8s資源模型最終決定基于CRD自建一層。ANS可以看作是SPIFFE在AI智能體領(lǐng)域的一個(gè)“特化實(shí)現(xiàn)”未來(lái)完全有可能將AgentIdentity的verifiableCredentials與SPIFFE Verifiable Identity Document (SVID) 進(jìn)行映射或融合。未來(lái)演進(jìn)方向標(biāo)準(zhǔn)化能力描述capabilities字段的Schema可以嘗試對(duì)齊諸如MLflow Model Registry、OpenAI Function Calling等生態(tài)的標(biāo)準(zhǔn)促進(jìn)互操作性。智能體市場(chǎng)與調(diào)度結(jié)合能力發(fā)現(xiàn)可以構(gòu)建一個(gè)集群內(nèi)的“智能體市場(chǎng)”。更高級(jí)的調(diào)度器可以根據(jù)任務(wù)需求“需要圖像識(shí)別和中文NLP”自動(dòng)選擇并調(diào)度滿足條件且可信的智能體實(shí)例。策略即代碼的深化將更多的治理邏輯如訪問(wèn)控制、資源配額、成本歸屬與AgentIdentity綁定實(shí)現(xiàn)真正的“身份驅(qū)動(dòng)治理”。這個(gè)ANS的PoC項(xiàng)目讓我們深刻認(rèn)識(shí)到在云原生AI時(shí)代身份是新的邊界。Kubernetes提供了卓越的“計(jì)算調(diào)度層”而我們需要一個(gè)與之匹配的“智能體信任層”來(lái)管理其中的主體。ANS的探索只是一個(gè)開(kāi)始它的核心價(jià)值在于提出了一種基于聲明式、可驗(yàn)證身份的治理范式這或許能為未來(lái)多智能體系統(tǒng)的安全協(xié)作打下第一塊基石。