你的 AI Agents 应该获得与微服务相同的运维待遇

Source: Dev.to

请提供您希望翻译的正文内容，我将为您翻译成简体中文。

几个月前…

我在查看我们团队实际上是如何在生产环境中运行 AI 代理的：

• 一个是运行在某人笔记本电脑上 tmux 会话中的 Python 脚本。
• 另一个是没有超时设置的 cron job。
• 第三个没有 成本限制——它在一个周末里因为卡在循环中，悄悄消耗了 $800 的 API 调用费用。

这些做法在微服务中根本行不通。我们绝不会发布没有健康检查、没有资源限制、也没有办法回滚的服务。但因为代理似乎与众不同，它们却被放行了。它们是 AI，而不是“真实”的基础设施。

我认为这并不是一个足够充分的理由。

实际上，代理只是工作负载

把 LLM 部分剥离后，代理就是一个长期运行的进程，它：

• 消耗资源
• 拥有健康状态
• 需要扩展
• 需要配置管理

这不过是一个服务而已。Kubernetes 已经会管理服务。

缺失的环节是让 Kubernetes 了解代理到底是什么——不是 CPU 和内存的层面，而是 模型、系统提示和工具访问 的层面。

于是我构建了一个正好实现此功能的 Kubernetes Operator：agentops-operator.

实际效果是这样的

你定义代理的方式与定义 Deployment 完全相同：

apiVersion: agentops.agentops.io/v1alpha1
kind: AgentDeployment
metadata:
  name: research-agent
spec:
  replicas: 3
  model: claude-sonnet-4-20250514
  systemPrompt: |
    You are a research agent. Gather and summarise information
    accurately. Always cite your sources.
  limits:
    maxTokensPerCall: 8000
    maxConcurrentTasks: 5
    timeoutSeconds: 120

kubectl apply -f research-agent.yaml
kubectl get agdep
# NAME           MODEL                      REPLICAS   READY   AGE
# research-agent claude-sonnet-4-20250514   3          3       45s

三个由 Kubernetes 管理的代理 Pod。将其扩容到 10 个：

kubectl patch agdep research-agent --type=merge -p '{"spec":{"replicas":10}}'

GitOps、RBAC、命名空间、kubectl ……全部无需修改即可工作，因为代理现在只是 Kubernetes 资源。

我最自豪的部分：语义健康检查

标准的存活探针只检查进程是否响应 HTTP。这对 Web 服务器来说没问题，但 LLM 可能“活着”却输出一堆胡言乱语。

agentops-operator 增加了一种 语义 探针类型——一次二次 LLM 调用，用来验证代理是否真的在正常工作：

livenessProbe:
  type: semantic
  intervalSeconds: 60
  validatorPrompt: "Reply with exactly one word: HEALTHY"

如果代理未通过该检查，Pod 将被从路由中移除，直至恢复。其语义与其他任何失败的健康检查相同，只是健康检查 理解 了对 LLM 来说“健康”意味着什么。

你永远不会意外删除的 Token 限制

这就是导致 $800 问题的根源。解决办法：限制写在基础设施层，而不是应用代码里。

limits:
  maxTokensPerCall: 8000
  maxConcurrentTasks: 5
  timeoutSeconds: 120

Operator 会把这些限制作为环境变量注入到它创建的每个代理 Pod 中。开发者无法通过编辑错误的文件将其删除，错误配置的提示也不会导致无限循环耗尽你的信用卡额度。

回滚错误的系统提示

1. 修改提示 → 提交 PR → 合并 → kubectl apply。
2. 回滚 → git revert → kubectl apply。

谁在何时改了哪个提示 的完整历史都保存在 Git 中，和其他基础设施变更一样。这听起来很显而易见，直到你必须追溯上周二某个代理行为异常的原因，而没人记得当时改了什么。

无需胶水代码的多代理流水线

你可以声明式地将代理串联起来：

apiVersion: agentops.agentops.io/v1alpha1
kind: AgentPipeline
metadata:
  name: research-then-summarize
spec:
  input:
    topic: "AI in healthcare"
  steps:
    - name: research
      agentDeployment: research-agent
      inputs:
        prompt: "Research this topic: {{ .pipeline.input.topic }}"
    - name: summarize
      agentDeployment: summarizer-agent
      dependsOn: [research]
      inputs:
        prompt: "Summarize these findings: {{ .steps.research.output }}"
  output: "{{ .steps.summarize.output }}"

Operator 负责处理队列，等待每一步完成，将输出传递给下一步，并更新流水线状态。看到 kubectl get agpipe -w 从 Running 变为 Succeeded，而两个独立的 LLM 正在各自工作，这种感觉有点超现实。

试一试

先决条件: Docker, kind, kubectl, Go 1.25+

git clone https://github.com/agentops-io/agentops-operator.git
cd agentops-operator
make dev ANTHROPIC_API_KEY=sk-ant-...

那条命令：

1. 创建一个 kind 集群
2. 构建两个 Docker 镜像
3. 在集群内部署 Redis 和 operator
4. 设置 API‑key 密钥

完成后，部署一个代理：

kubectl apply -f config/samples/agentops_v1alpha1_agentdeployment.yaml
kubectl get agdep -w

提交任务

# Add a task to the Redis stream
kubectl exec -it -n agent-infra redis-0 -- \
  redis-cli XADD agent-tasks '*' prompt "What is the capital of France? One sentence."

# Read the result
kubectl exec -it -n agent-infra redis-0 -- \
  redis-cli XREAD COUNT 10 STREAMS agent-tasks-results 0
# => "The capital of France is Paris."

祝你玩得开心，将 AI 代理转化为一流的 Kubernetes 资源！

诚实的警示

这是 v0.0.1，单人贡献者，早期 alpha 版。有些尚未完成的事项：

• 并行流水线步骤 – 目前即使步骤之间没有依赖，它们也会顺序执行。
• 基于队列深度的 KEDA 自动伸缩 – CPU 对于代理工作负载来说是错误的信号；队列深度才是正确的，但尚未实现。
• 目前仅支持 Anthropic – 已为 OpenAI/Gemini 提供了供应商接口，但尚未实现具体实现。

我写下这些是因为我认为这个问题真实且值得解决，而不是因为解决方案已经完成。

如果这些听起来很熟悉——在 tmux 会话中运行的代理、没有成本控制、通过 SSH 登录机器部署提示更改——我真诚地想了解你是如何处理的。如果你想贡献代码，请参阅 CONTRIBUTING.md 了解设置方法。

• GitHub:
• Docs: