1. 项目概述当Kubernetes遇见Agentic AI如果你和我一样在Kubernetes上折腾过AI应用那你肯定经历过这种场景想部署一个能自主处理工单的客服Agent或者一个能自动分析日志、诊断集群问题的AI助手。结果发现这远不止是写个Pod清单那么简单。你得考虑Agent的生命周期管理、技能Tools的隔离与安全、多个Agent之间的协作与记忆共享还得确保这一切能水平扩展、多租户隔离。传统的K8s工作负载Deployment, Job设计之初就没考虑过这种“有大脑、会思考、能协作”的智能体。于是我们往往陷入用胶水代码缝合各种组件的泥潭安全性和可观测性都成了大问题。这就是Sympozium要解决的痛点。它不是一个简单的AI SDK或框架而是一个原生于Kubernetes的Agentic AI操作系统。它的核心哲学非常激进也异常清晰每一个智能体Agent都是一个临时的Pod每一项策略都是一个CRD每一次执行都是一个Job。这意味着你将用管理Kubernetes原生资源如Deployment, Service的思维和工具kubectl, Helm, ArgoCD来管理你的AI智能体舰队。这听起来可能有点抽象但想象一下你不再需要为每个AI Agent编写复杂的部署和编排逻辑而是通过声明式的YAML文件定义“谁”Persona、“能做什么”Skill、“何时做”Schedule以及“如何协作”Workflow剩下的交给Sympozium控制器去调度、隔离和执行。这个项目出自k8sgpt和llmfit的创造者之手其基因里就带着强烈的“Kubernetes原生”和“生产就绪”的烙印。它瞄准了两大核心场景一是编排多智能体工作流用于客服、代码审查、数据管道等业务领域二是让智能体来诊断、扩缩容和修复你的基础设施本身实现真正的“自愈”集群。更重要的是它从设计上就追求多租户、水平扩展和安全。在AI应用安全日益受到重视的今天Sympozium通过将每个技能Skill运行在独立的Sidecar容器中并赋予其最小权限的RBAC实现了“技能沙箱化”这从根本上降低了AI执行外部工具如读写文件、调用API所带来的风险。2. 核心架构与设计理念拆解2.1 为什么是Kubernetes原生在深入细节之前我们必须理解Sympozium“Kubernetes原生”这一选择的深层逻辑。当前市面上的AI Agent框架大多运行在应用层它们提供SDK来定义Agent和Tool但基础设施管理资源调度、网络隔离、持久化存储的重担仍然留给了开发者。Sympozium反其道而行之将Agent直接映射为K8s最核心的抽象——Pod。这样做有几个颠覆性的优势资源与调度标准化Pod是K8s调度和资源管理的原子单位。Sympozium Agent天然继承K8s的Resource Quota、LimitRange、优先级/抢占、节点亲和性等成熟机制。你想限制某个客服Agent团队最多使用4核8G内存直接配ResourceQuota就行。你想让推理密集型的Agent运行在带GPU的节点上用NodeSelector或Taint/Toleration轻松实现。安全模型继承K8s拥有业界最细粒度的安全控制体系。Sympozium的每个Persona角色Pod以及每个Skill Sidecar都可以拥有独立的ServiceAccount并绑定精确的RBAC角色。这意味着“代码审查Agent”只能访问代码仓库相关的Secret“集群诊断Agent”只能拥有get、listPod和Event的权限实现了真正的权限最小化。可观测性统一所有Agent的日志stdout/stderr自动由K8s收集可通过集群的日志方案如LokiPromtail统一处理。MetricsCPU、内存、自定义指标也自然地融入Prometheus体系。调试一个出错的Agent你用的还是熟悉的kubectl logs和kubectl describe pod命令。运维模式一致你的运维团队不需要学习一套新的AI Agent运维工具。部署用Helm/ArgoCD配置用ConfigMap/Secret网络策略用NetworkPolicy服务暴露用Ingress/Service。Sympozium只是扩展了K8s的API而非另起炉灶。注意这种深度集成也意味着Sympozium的学习曲线与你的Kubernetes熟练度强相关。如果你对K8s的CRD、Operator、ServiceAccount等概念不熟可能需要先补课。但长远来看这对于需要在生产环境规模化运行AI Agent的团队来说是必经之路Sympozium帮你把这条路铺平了。2.2 核心概念映射从AI世界到K8s世界Sympozium建立了一套清晰的概念体系将AI Agent领域的术语精准地映射到Kubernetes资源上。理解这套映射是掌握它的关键。Persona角色这是AI Agent的“人格”或“角色定义”比如“客服专员”、“运维专家”、“代码审查员”。在Sympozium中一个Persona对应一个自定义资源CRD。这个CRD定义了该Agent使用的基础模型如gpt-4、系统提示词System Prompt、温度Temperature等推理参数以及它所关联的技能Skills和记忆Memory。创建Persona CR并不会立即创建Pod它只是一个“蓝图”。AgentRun这是触发Agent执行的具体“任务”或“运行实例”。它也是一个CRD。当你向一个Persona发起一次对话或任务时Sympozium控制器会创建一个AgentRun资源。控制器监听到这个资源后会根据对应的Persona蓝图动态生成并启动一个具体的Pod。这个Pod就是Agent本次执行的物理载体。执行完成后Pod会被清理除非配置了调试保留但AgentRun的记录会保留用于审计和追溯。这完美对应了“每一次执行都是一个Job”的理念。Skill技能Agent的能力单元比如“搜索网络”、“读写数据库”、“调用API”。Sympozium将每个Skill都运行在一个独立的Sidecar容器中。这是其安全设计的精髓。当Persona Pod启动时其所需的Skill Sidecar会一并启动。Agent通过进程间通信IPC或本地网络与Sidecar交互。Skill执行完毕后其Sidecar容器可以被垃圾回收。每个Sidecar可以配置独立的ServiceAccount和SecurityContext实现了技能级别的安全隔离。Ensemble组合这是Sympozium中更高层次的抽象类似于Helm Chart。一个Ensemble是一个打包好的、可部署的“智能体团队”或“解决方案”。例如一个“智能客服中心”Ensemble可能包含“工单分类Persona”、“问题解答Persona”、“升级处理Persona”以及它们之间定义好的工作流Workflow和共享记忆Memory。通过sympozium install安装的预置套件就是Ensemble。这极大地简化了复杂多Agent系统的部署。Memory记忆分为会话记忆Conversation Memory和持久记忆Persistent Memory。持久记忆是Ensemble级别的基于SQLite FTS5构建并存储在PersistentVolumePV上。这意味着不同Persona之间可以安全地共享和查询历史信息且记忆在Pod重启后不丢失。Channel通道Agent与外部世界如Slack、Telegram通信的接口。每个Channel对应一个独立的K8s Deployment后端使用NATS JetStream进行可靠的消息流处理。这确保了消息的持久化和有序性。2.3 安全与隔离多租户与沙箱化设计安全是Sympozium的基石。“Safe by design”体现在其架构的方方面面。技能沙箱Skill Sandboxing这是第一道防线。每个Skill在独立的Sidecar中运行其进程、文件系统、网络命名空间与主Agent容器隔离。即使某个Skill例如一个执行任意代码的Tool被恶意提示词利用而“越狱”它也被限制在自己的Sidecar监狱里无法直接访问主Agent的内存或其他Skill的数据。基于RBAC的最小权限每个Persona Pod和Skill Sidecar都可以配置独立的Kubernetes ServiceAccount。你可以为“只读诊断”Persona绑定一个仅能get、listPod和Node的ClusterRole为“文件处理”Skill绑定一个只能访问特定PVC的Role。权限在K8s层面被严格约束。Agent沙箱Agent Sandbox这是更底层的、内核级的隔离选项。Sympozium集成了Kubernetes SIG的agent-sandbox项目可以为Persona Pod提供gVisor或Kata Containers运行时。这意味着Agent的整个Pod运行在一个轻量级虚拟机或内核隔离的沙箱中与宿主机内核完全隔离提供了类似云函数的安全级别。这对于运行来自不受信任来源的第三方Agent或技能至关重要。网络策略NetworkPolicy你可以通过K8s NetworkPolicy精确控制Persona Pod、Skill Sidecar以及外部服务如向量数据库、LLM API端点之间的网络流量。例如可以禁止客服Agent Pod直接访问生产数据库所有数据必须通过特定的、有严格白名单的Skill Sidecar代理。MCP服务器的访问控制对于通过Model Context Protocol集成的外部工具服务器Sympozium支持自动发现和允许/拒绝列表过滤防止Agent意外调用危险或未授权的工具。这种层层嵌套的隔离模型使得在Sympozium上运行不受完全信任的AI Agent成为可能为多团队、多项目多租户共享同一个K8s集群来运行各自的AI工作负载提供了坚实的安全基础。3. 从零开始部署与初体验实操理论说得再多不如亲手跑起来。我们从一个干净的Kubernetes集群开始完整走一遍Sympozium的安装、部署第一个Ensemble并启动一个交互式Agent。3.1 环境准备与安装假设你已经有一个正在运行的Kubernetes集群可以是Minikube、Kind、K3s或云厂商的托管集群。Sympozium提供了极其简单的安装方式。方法一使用CLI快速安装推荐初学者Sympozium的CLI工具是管理整个平台的核心。首先我们在本地机器上安装它。对于macOS用户使用Homebrew是最快的方式brew tap sympozium-ai/sympozium brew install sympozium对于Linux用户或者macOS上未安装Homebrew的情况可以使用一键安装脚本curl -fsSL https://deploy.sympozium.ai/install.sh | sh这个脚本会自动检测系统架构下载最新的sympozium CLI二进制文件并放置到/usr/local/bin目录下可能需要sudo权限。安装完成后运行sympozium version验证安装是否成功。接下来我们用一条命令将Sympozium的控制平面部署到你的集群中sympozium install这个命令背后做了很多事情向你的K8s集群安装一系列CRDCustom Resource Definitions定义了Persona、AgentRun、Ensemble等资源类型。部署Sympozium控制器Deployment它负责监听这些CRD的变更并采取相应行动。部署一些内置的Ensemble例如一个基础的对话示例。创建必要的ServiceAccount、ClusterRole、ClusterRoleBinding等RBAC资源。部署一个基于NATS的消息系统用于内部通信。实操心得第一次运行sympozium install时建议先加上--dry-run标志查看它会创建哪些资源。在生产环境你可能希望通过GitOps如ArgoCD来管理这些资源的部署以实现版本控制和审计。sympozium install生成的清单可以通过sympozium install --output yaml命令导出。方法二使用Helm进行高级部署对于需要更多定制化控制的生产环境Helm是更合适的选择。Sympozium的Helm Chart提供了完整的配置项。首先Sympozium的Webhook用于校验CRD需要TLS证书因此我们需要先安装cert-managerkubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.17.1/cert-manager.yaml # 等待cert-manager的Pod全部变为Running状态 kubectl wait --forconditionReady pods --all -n cert-manager --timeout300s然后添加Sympozium的Helm仓库并安装helm repo add sympozium https://deploy.sympozium.ai/charts helm repo update helm install my-sympozium sympozium/sympozium --namespace sympozium-system --create-namespace你可以通过--values参数指定一个YAML文件来覆盖默认配置例如修改镜像拉取策略、资源限制、或者启用Agent沙箱功能。所有的配置选项都在项目的charts/sympozium/values.yaml文件中定义。3.2 启动TUI并激活第一个AgentSympozium提供了一个非常酷的终端用户界面TUI让你可以直观地管理和交互。在安装完成后直接运行sympozium一个全屏的TUI应用会启动。使用方向键导航你会看到几个主要标签页如Personas、Ensembles、AgentRuns、Memories等。进入Personas标签页。这里列出了当前已定义的Persona蓝图。初始状态下可能只有一个基础的assistantPersona来自内置的示例Ensemble。选中这个Persona按下Enter键。这相当于“启用”或“加载”了这个Persona使其准备好接收任务。此时你可以切换到Chat或类似的标签页具体名称取决于TUI版本会看到一个对话界面。输入“Hello, who are you?”然后按回车。背后发生了什么当你按下回车发送消息时TUI会帮你创建一个AgentRun资源。Sympozium控制器监听到这个资源的创建立刻执行以下操作根据assistantPersona的配置生成一个Pod的模板。这个Pod包含主容器运行Agent核心逻辑和可能定义的Skill Sidecar。调度并创建这个Pod。Pod内的Agent开始运行加载模型根据配置可能是调用OpenAI API或者是本地Ollama服务处理你的输入“Hello, who are you?”。Agent生成回复并将结果写回AgentRun资源的状态Status字段。TUI持续监听这个AgentRun状态的变化一旦检测到有回复就将其显示在对话界面上。对话结束后可能根据超时设置Pod会被清理删除但AgentRun记录会保留。整个过程你都没有直接操作kubectl但所有活动都通过K8s资源清晰地记录和管控。你可以打开另一个终端运行kubectl get pods -w就能亲眼看到Pod被创建、运行、然后消失的生命周期。3.3 访问Web仪表板如果你更喜欢图形化界面Sympozium也提供了Web UI。在另一个终端运行sympozium serve这个命令会在本地启动一个端口转发通常是http://localhost:8080将集群内的Sympozium Web UI服务暴露出来。用浏览器打开该地址你会看到一个功能更丰富的仪表板可以可视化工作流画布、查看资源关系图、管理记忆库等。4. 核心功能深度解析与配置实战4.1 定义你的第一个Persona从YAML开始虽然TUI很方便但声明式配置才是Kubernetes的精髓。让我们手动创建一个自定义的Persona。创建一个名为reviewer-persona.yaml的文件apiVersion: agent.sympozium.ai/v1alpha1 kind: Persona metadata: name: code-reviewer namespace: default # Persona是命名空间级别的资源 spec: # 模型配置这里使用本地部署的Ollama model: provider: ollama endpoint: http://ollama-service.default.svc.cluster.local:11434 # 集群内Ollama服务地址 model: codellama:7b # 指定模型 temperature: 0.2 # 低温度让代码审查更确定性 maxTokens: 2048 # 系统提示词定义Agent的角色和能力 systemPrompt: | You are an expert senior software engineer specializing in code review. Your task is to analyze provided code snippets for: 1. **Security vulnerabilities** (e.g., SQL injection, XSS, insecure deserialization). 2. **Performance issues** (e.g., N1 queries, inefficient algorithms, memory leaks). 3. **Code smells and best practices** (e.g., DRY violations, poor naming, lack of error handling). 4. **Architectural alignment** with stated project patterns. Provide concise, actionable feedback. For each issue, state the problem, its potential impact, and a suggested fix with code example if applicable. Be direct and professional. # 关联的技能Tools。这些技能会以Sidecar形式注入Pod。 skills: - name: fetch-code # 技能名称 skillRef: name: git-fetcher # 引用集群中已定义的Skill CRD namespace: sympozium-system # 通常内置技能在这个命名空间 config: # 传递给该技能的配置 repo: https://github.com/your-org/your-repo.git branch: main # 记忆配置 memory: persistentMemory: # 使用持久化记忆 ensemble: my-dev-team-ensemble # 所属的Ensemble用于共享记忆 accessMode: read-write # 对该记忆库的访问模式应用这个配置kubectl apply -f reviewer-persona.yaml。现在你就拥有了一个名为code-reviewer的代码审查专家Agent蓝图。它使用本地的CodeLlama模型具备从Git仓库拉取代码的技能并且可以读写my-dev-team-ensemble这个团队的共享记忆库。注意事项skills中引用的git-fetcher需要预先存在。它可能是一个内置的Skill也可能是你需要自定义部署的。Skill本身也是一个CRD定义了容器镜像、命令、环境变量以及所需的RBAC权限。在部署自定义Skill时务必严格遵循最小权限原则。4.2 创建工作流Workflow让Agent协作起来单个Agent能力有限真正的力量来自协作。Sympozium支持定义复杂的工作流让多个Persona按顺序或并行执行任务。工作流是通过在Ensemble或特定的工作流CRD中定义stages来实现的。假设我们有一个“需求分析 - 编码 - 审查”的简单工作流。我们可以创建一个workflow.yamlapiVersion: workflow.sympozium.ai/v1alpha1 kind: Workflow metadata: name: feature-development-pipeline spec: stages: - name: analyze-requirement personaRef: name: product-analyst namespace: default input: “{{ .Trigger.Input }}“ # 输入来自工作流触发器的参数 outputTo: next # 输出传递给下一阶段 - name: implement-code personaRef: name: developer namespace: default dependsOn: [“analyze-requirement”] # 依赖于上一阶段 input: “{{ .Stages.analyze-requirement.Output }}“ # 输入是产品分析师的输出 outputTo: next - name: review-code personaRef: name: code-reviewer # 使用我们刚才创建的Persona namespace: default dependsOn: [“implement-code”] input: “{{ .Stages.implement-code.Output }}“ outputTo: memory # 将最终审查结果存入共享记忆 memoryConfig: ensemble: my-dev-team-ensemble key: “review-{{ .ExecutionID }}“这个工作流定义了一个三阶段的管道。触发后例如通过API、Chat或Cron产品分析师先解读需求开发者根据分析结果编写代码最后代码审查员对产出的代码进行审查并将结果保存到共享记忆库中。每个阶段都是一个独立的AgentRun由Sympozium控制器按依赖关系顺序创建和执行。4.3 配置持久化记忆与技能侧车持久化记忆Persistent Memory是Ensemble级别的SQLite数据库。要启用它你需要在Ensemble的定义中声明一个PVC模板。以下是一个Ensemble CR的片段示例apiVersion: ensemble.sympozium.ai/v1alpha1 kind: Ensemble metadata: name: my-dev-team-ensemble spec: memory: persistent: enabled: true volumeClaimTemplate: # 定义PVC用于存储SQLite文件 spec: accessModes: [“ReadWriteOnce”] resources: requests: storage: 10Gi storageClassName: “standard” # 根据你的集群配置修改部署这个Ensemble后Sympozium会创建一个PVC。所有属于这个Ensemble的Persona只要在其配置中声明了accessMode: read-write或read-only就能挂载这个PVC访问同一个SQLite数据库实现跨会话、跨Agent的记忆共享。技能侧车Skill Sidecar的定义是Sympozium安全模型的核心。一个Skill CRD看起来像这样apiVersion: skill.sympozium.ai/v1alpha1 kind: Skill metadata: name: safe-shell-executor spec: container: image: “sympozium/skill-shell:latest” command: [“/bin/safe-executor”] env: - name: ALLOWED_COMMANDS value: “ls,cat,grep,find” securityContext: # 严格的安全上下文 runAsNonRoot: true runAsUser: 1000 allowPrivilegeEscalation: false readOnlyRootFilesystem: true rbac: rules: # 最小化的K8s RBAC权限 - apiGroups: [“”] resources: [“pods”, “configmaps”] verbs: [“get”, “list”] # 只能读不能创建或删除当这个Skill被一个Persona引用时Sympozium控制器会在创建Persona Pod时将这个容器定义作为Sidecar注入。主Agent容器通过本地Socket或HTTP与这个Sidecar通信发出执行命令的请求。Sidecar会根据ALLOWED_COMMANDS环境变量进行白名单校验只允许执行预定义的几个安全命令。即使Agent被诱导尝试执行rm -rf /也会在Sidecar层被拒绝。5. 生产环境部署考量与故障排查5.1 高可用与水平扩展配置Sympozium的控制平面控制器本身是无状态的可以轻松实现高可用。在Helm Chart的values.yaml中你可以进行如下配置controller: replicaCount: 3 # 部署多个控制器副本 autoscaling: enabled: true minReplicas: 2 maxReplicas: 10 targetCPUUtilizationPercentage: 70 targetMemoryUtilizationPercentage: 80 # 消息总线NATS JetStream也需要高可用 nats: jetstream: enabled: true replicaCount: 3 storage: size: 50Gi storageClassName: “ssd”对于Agent工作节点即运行Persona Pod的节点你需要根据AI工作负载的特性来规划节点池。例如可以创建带有GPU标签的节点池然后在Persona或Ensemble的配置中通过nodeSelector或tolerations将需要GPU推理的Agent调度到这些节点上。5.2 监控与日志收集由于Agent以Pod形式运行你可以无缝集成现有的K8s监控栈。指标监控Sympozium控制器暴露Prometheus指标。确保你的Prometheus配置了抓取这些指标。同时监控Persona Pod的资源使用情况CPU、内存、GPU特别是当使用本地大模型时内存消耗是关键指标。日志收集所有Pod控制器、Persona、Sidecar的日志都输出到标准输出和错误。使用Fluent Bit、Fluentd或Promtail等日志代理将日志收集到中央存储如Loki或Elasticsearch中。为不同Ensemble或团队的日志添加标签如ensemblemy-team便于过滤和查询。分布式追踪对于复杂的工作流考虑集成OpenTelemetry来追踪一个请求在不同Persona和Skill间的流转路径这对于性能分析和故障定位至关重要。5.3 常见问题与排查实录在实际部署和运行中你可能会遇到以下典型问题。这里分享我的排查思路和解决方法。问题1Persona Pod一直处于Pending状态。排查步骤kubectl describe pod persona-pod-name查看Events部分。最常见的原因是资源不足Insufficient cpu/memory/gpu或节点选择器/容忍度不匹配node(s) didn‘t match Pod’s node selector/affinity。kubectl get events --field-selector involvedObject.namepersona-pod-name获取更详细的事件。检查PersistentVolumeClaim如果Persona使用了持久化记忆是否绑定成功kubectl get pvc。解决方案如果是资源不足调整Persona的资源请求resources.requests/limits或为集群添加更多节点。如果是节点选择问题检查Persona或Ensemble配置中的nodeSelector、affinity是否正确或为目标节点打上正确的标签。问题2AgentRun创建成功但状态一直卡在“Running”或失败。排查步骤kubectl logs persona-pod-name -c agent查看主Agent容器的日志。这里通常会有模型调用失败、Skill连接超时等错误信息。kubectl logs persona-pod-name -c skill-sidecar-name查看具体Skill Sidecar的日志。可能Skill镜像拉取失败、内部执行错误或权限不足。检查AgentRun资源的状态和事件kubectl describe agentrun agentrun-name。解决方案模型连接失败确认model.endpoint配置的LLM服务如Ollama、OpenAI API代理在Pod网络内可访问且API密钥如有已正确通过Secret配置。Skill执行错误检查Skill的容器镜像是否存在、能否拉取。检查Skill配置中的环境变量、命令是否正确。检查Skill Sidecar的RBAC权限是否足够。内存不足如果使用本地大模型Pod可能因OOM被杀。增加Pod的内存限制或换用更小的模型。问题3工作流Workflow在某个阶段停滞不前。排查步骤kubectl get workflow workflow-name -o yaml查看工作流资源的整体状态找到当前卡住的stage。查看该阶段对应的AgentRun资源kubectl describe agentrun stage-agentrun-name。按照问题2的步骤排查该AgentRun对应的Pod和日志。检查工作流定义中的dependsOn字段确认依赖的前置阶段是否已成功完成succeeded状态。解决方案修复前置阶段AgentRun的问题。检查工作流阶段之间的输入输出传递input字段中的模板{{ .Stages.xxx.Output }}是否正确数据格式是否符合下一个Persona的预期。问题4TUI或Web UI无法连接。排查步骤确认sympozium serve命令的端口转发是否成功建立检查命令行有无错误。kubectl get svc -n sympozium-system确认Sympozium的UI Service是否存在且类型正确通常是ClusterIP。kubectl get pods -n sympozium-system -l app.kubernetes.io/nameui确认UI Pod是否运行正常。解决方案如果是端口冲突使用sympozium serve --port 9090指定其他端口。重启sympozium serve命令或重新安装控制平面。5.4 安全加固建议网络策略为每个Ensemble或命名空间定义严格的NetworkPolicy默认拒绝所有入站和出站流量然后只开放必要的端口如Pod到LLM API端点、到向量数据库的端口。Pod安全标准在命名空间级别启用Pod Security Admission强制Persona Pod使用restricted标准非root用户运行、禁止特权升级等。镜像扫描将Sympozium官方镜像及自定义的Skill镜像纳入CI/CD流水线使用Trivy、Grype等工具进行漏洞扫描。Secret管理LLM API密钥、数据库密码等敏感信息务必通过Kubernetes Secret管理并以环境变量或卷挂载的方式注入Pod切勿硬编码在Persona YAML中。审计启用Kubernetes审计日志记录对所有Sympozium CRDPersona, AgentRun, Ensemble等的创建、更新、删除操作便于安全审计和问题追溯。6. 进阶集成本地模型与自定义技能开发6.1 集成Ollama运行本地大模型使用云上LLM API虽然方便但成本、延迟和数据隐私是考量因素。Sympozium完美支持集成本地部署的模型如通过Ollama。首先在你的K8s集群中部署Ollama。可以创建一个简单的Deployment和Service# ollama-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: ollama spec: replicas: 1 selector: matchLabels: app: ollama template: metadata: labels: app: ollama spec: containers: - name: ollama image: ollama/ollama:latest ports: - containerPort: 11434 resources: requests: memory: “16Gi” # 根据模型大小调整 cpu: “4” limits: memory: “24Gi” cpu: “8” volumeMounts: - name: ollama-data mountPath: /root/.ollama volumes: - name: ollama-data persistentVolumeClaim: claimName: ollama-pvc --- apiVersion: v1 kind: Service metadata: name: ollama-service spec: selector: app: ollama ports: - port: 11434 targetPort: 11434然后在集群内拉取你需要的模型例如CodeLlamakubectl exec deploy/ollama -- ollama pull codellama:7b。最后在Persona配置中将model.provider设置为ollamamodel.endpoint指向集群内的服务地址http://ollama-service.default.svc.cluster.local:11434即可。这样你的Agent将完全在集群内部进行推理数据不出集群且没有API调用费用。6.2 开发一个自定义技能Skill假设我们需要一个能查询内部员工目录的技能。首先我们需要编写这个技能的逻辑。Sympozium Skill本质上是一个能通过特定接口如HTTP、gRPC与主Agent通信的独立服务。我们可以用Python写一个简单的HTTP服务skill_employee_lookup.pyfrom http.server import HTTPServer, BaseHTTPRequestHandler import json import sqlite3 import os class SkillHandler(BaseHTTPRequestHandler): def do_POST(self): content_length int(self.headers[‘Content-Length’]) post_data self.rfile.read(content_length) request json.loads(post_data) # 从请求中获取查询参数 employee_name request.get(‘name’, ‘’) # 这里应该是连接真实数据库此处用模拟数据 employee_info self.lookup_employee(employee_name) response { “success”: True, “data”: employee_info, “metadata”: {“source”: “internal-directory”} } self.send_response(200) self.send_header(‘Content-Type’, ‘application/json’) self.end_headers() self.wfile.write(json.dumps(response).encode()) def lookup_employee(self, name): # 模拟数据库查询 mock_db {“Alice”: {“department”: “Engineering”, “email”: “alicecompany.com”}} return mock_db.get(name, {“error”: “Employee not found”}) if __name__ ‘__main__’: port int(os.getenv(‘SKILL_PORT’, ‘8080’)) server HTTPServer((‘0.0.0.0’, port), SkillHandler) server.serve_forever()然后将其打包为Docker镜像并推送到镜像仓库。接着定义对应的Skill CRDapiVersion: skill.sympozium.ai/v1alpha1 kind: Skill metadata: name: employee-directory-lookup spec: container: image: “your-registry/employee-lookup-skill:latest” ports: - containerPort: 8080 name: http env: - name: SKILL_PORT value: “8080” resources: requests: memory: “128Mi” cpu: “100m” # 定义技能接口告诉Sympozium如何调用它 interface: type: http port: 8080 path: “/” method: POST将这个Skill CRD部署到集群。现在任何Persona都可以在它的spec.skills列表中引用employee-directory-lookup。当该Persona被实例化时这个技能容器会作为Sidecar启动。主Agent在需要查询员工信息时会按照interface的定义向localhost:8080发送一个HTTP POST请求技能容器处理请求并返回结果。整个过程对主Agent透明且技能容器的任何故障都不会导致主Agent崩溃。通过这种方式你可以将任何内部系统、API或工具封装成安全的、可复用的Skill极大地扩展了Agent的能力边界同时保持了系统的模块化和安全性。