从 K8s 到 AI Agent:一种工程哲学的迁徙

文章目录

1. 一、K8s 的根选择 — 错误是常态
   1. 命令式的失败
   2. 声明式的答案
   3. 配套概念:level vs edge / 幂等
2. 二、旁路验证 — IaC → GitOps 殊途同归
   1. GitOps 的回归
3. 三、AI Agent — 同样的"分布式"问题
   1. Confident wrongness:AI 的常态错误
   2. 接入工具后的爆炸半径
4. 四、演化阶梯:Prompt → Spec → Context → Harness
   1. 4.1 Prompt Engineering — 模糊的声明
   2. 4.2 Spec Engineering — 显式的声明
   3. 4.3 Context Engineering — 信息环境
   4. 4.4 Harness Engineering — 完整的工程对象
5. 五、Verification — 当开发自测的偏见在 AI 身上重演
6. 六、Observability — K8s 易,Agent 难
7. 七、未来 — 第二次殊途同归
   1. 未来的方向
   2. K8s 经验就是 AI agent 的路线图
   3. 工程师角色的演化
8. 收尾
9. 引用 References

为什么"错误是常态"会主宰下一个十年的 AI 工程

---

你为什么不害怕 K8s 删掉一个 pod?

因为你知道它会重建。Pod 死了 10 秒,新的就起来——这件事在 K8s 集群里每天发生几千次,没人慌。

但你为什么害怕 AI agent 改一个文件?

因为你不知道它有没有改对、有没有破坏别的东西、有没有把"它觉得正确"的内容写进去。一次错误的写入,可能要花一个小时回滚。

这两件事看起来风马牛不相及,其实是同一个故事的两个时点。K8s 在过去十年解决的工程问题,AI agent 现在正在重新面对——而且解法的雏形,已经能在 K8s 的设计哲学里看到。

这篇文章想说一句话:看懂 K8s,你就看懂了 AI Agent 工程的未来 5 年路线图。这不是巧合,是同一种工程哲学在不同抽象层的必然演化。

---

一、K8s 的根选择 — 错误是常态

K8s 的设计哲学很多,但所有特性都能追溯到一个根选择:声明式。

而声明式的前提,是承认一件事——系统一定会出问题。

命令式的失败

想象你有 1 万个节点、10 万个 pod。你写一个脚本"启动这 10 万个 pod"。执行到一半,网络断了、几台机器挂了、几个容器启动失败。

接下来怎么办?

重跑会重复创建。从断点续跑要记录所有状态。人肉补救根本来不及。

这就是命令式的根本问题:你不能信任任何一次执行。规模越大、组件越多,这个不可信任度越高。Borg 团队在 Google 内部跑了 15 年容器集群,得出的核心教训就是这一句——错误是常态,不是异常[^borg][^bok]。

声明式的答案

声明式调换了思路:

我不告诉系统"怎么做",我只告诉它"要什么"。然后让系统自己不断 loop,趋近这个目标。

这就是 reconcile(协调/调谐)的概念。每个 K8s 控制器都是一个无限循环:

loop forever:
    desired = 期望状态(用户写的 yaml)
    actual  = 实际状态(集群里的真实情况)
    if desired != actual:
        采取行动让 actual 趋近 desired

举个具体例子。你只需要声明 replicas: 3——意思是"我要 3 个 pod 一直存在"。控制器的工作流程是这样的:

desired: [pod] [pod] [pod]      ← 你声明
               ↕ diff
actual:  [pod] [pod] [   ]      ← 真实(挂了一个)
               ↓
         controller 发现差异
               ↓
         create_pod()           ← 自动修
               ↓
actual:  [pod] [pod] [pod]      ← 收敛

不管发生什么——少了补、多了减、节点挂了 pod 自动迁移——最终一定收敛到 3 个 pod。这就是最终一致性。

配套概念:level vs edge / 幂等

为了让 reconcile 真正可靠,K8s 配套了两个数学保证:

level-triggered(电平触发)而非 edge-triggered(边沿触发):

• edge-triggered:状态变化时触发一次,处理完就走。错过就错过。
• level-triggered:持续观察当前状态,只要不对就一直处理,直到对为止。

K8s 选了 level-triggered——这意味着任何时候 controller 重启,都能从当前状态恢复 reconcile,不用记忆"上一次干到哪了"。

幂等性(idempotent)。同一个操作执行 1 次和 100 次结果一样。这是 reconcile 能放心重试的根本——失败了?重试就行,不会搞坏什么。

"错误是常态"不是被动接受,是主动设计。承认它,把它内置到系统的运行机制里——这是 K8s 给世界上的一课。

---

二、旁路验证 — IaC → GitOps 殊途同归

K8s 选了声明式,这个选择是孤例吗?不是。

同代的 Infrastructure as Code(IaC)——Terraform、Ansible、CloudFormation——也宣称自己是声明式。你写一份 .tf 文件描述要什么云资源,工具帮你创建。

但有一个关键差别:IaC 本质仍然是一次性 apply。

$ terraform apply
  ↓ 工具算 diff
  ↓ 执行变更
  ↓ 退出(结束)

之后:
  云资源被人手动改了 → Terraform 不知道
  Console 里删了实例   → state 漂移,无人 reconcile

IaC 是 edge-triggered。声明只在 apply 那一刻有效,之后系统自由漂移。

GitOps 的回归

后来发生了什么?

业界发现 K8s 的持续 reconcile 模式实在太香——能不能让 IaC 也这样?

于是 GitOps 出现[^gitops]:Git 作为唯一真相来源(single source of truth),Argo CD / Flux 这类工具持续 watch Git + 实际系统,漂移就修。

Git repo (声明式)
      │
      ▼
┌──────────────────┐
│  Argo CD / Flux  │ ← 持续 sync
└─────────┬────────┘
          │
          ▼
实际系统(K8s 集群 / 云资源)

这是 K8s 的 reconcile 哲学反向倒灌回了 IaC。

把这个时刻记下来:第一次殊途同归。声明式从 K8s 长出来,扩散到所有基础设施工具,最终把整个行业拉到了同一个范式。

这不是巧合。声明式 + reconcile 是处理"错误是常态的复杂系统"的唯一已知答案。任何不彻底声明式的工具,迟早都会被这个引力拽回去。

带着这个认识,我们走到第二个阵地。

---

三、AI Agent — 同样的"分布式"问题

AI Agent 看起来和 K8s 没关系。一个跑容器,一个跑大模型。但如果你问:AI agent 也是一个"错误是常态"的复杂系统吗?

答案是肯定的。它的"分布式"不是分布在多台机器上,是分布在每次 LLM 调用之间。每次调用都有随机性,每次调用都可能产生幻觉。

Confident wrongness:AI 的常态错误

最早用 AI 的时候,你大概都遇到过——它非常自信地给你一个自以为正确、其实错误的答案。

文档里没有的字段,它说有。
你给它的代码路径,它"读"了但其实没读。
metric 的 label 名,它根据"语感"猜了一个。

这些错误最危险的特征是:听起来都很合理。

接入工具后的爆炸半径

如果 AI 只是闲聊,confident wrongness 顶多让你笑笑。但当 AI agent 接入了写入工具——能改文件、跑命令、调 API——这件事性质就变了。

举一个真实案例。Agent 在 Alertmanager 配置里加了一个叫 alert_alias 的字段,声称是"标准的去重字段":

# 错误的配置(示意)
route:
  receiver: 'default'
  group_by: ['alertname']
  alert_alias: '{{ .CommonLabels.cluster }}'   # ← 这个字段在 Alertmanager 源码里根本不存在

配置推到线上后:

$ kubectl get pod -n monitoring | grep alertmanager
alertmanager-0   0/1   CrashLoopBackOff   3   47s

$ kubectl logs alertmanager-0 -n monitoring
level=error msg="error loading config"
err="field alert_alias not found in type config.Route"

整个 fleet 的告警路由瞬间瘫痪,需要紧急回滚。

Agent 不是在闲聊层面错了,是在写入层面错了。爆炸半径从一句胡话,变成了一次生产事故。

这就是为什么 AI Agent 进入生产环境如此谨慎,甚至在不少公司被推广后又被回退[^survey][^klarna]。

"错误是常态"在 AI 这一层,不仅成立,而且更刺眼。

那 AI agent 工程是怎么演化的?和 K8s 早期的故事像得惊人。

---

四、演化阶梯:Prompt → Spec → Context → Harness

我们正在经历一个清晰的阶梯式演化:

Harness Eng    [Spec + Boundary + Memory + Verify + Obs]
    ▲                              还在演化
Context Eng    [Spec + Memory + Skills]
    ▲                              缺边界 / 缺验证
Spec Eng       [显式终点 + Plan + Acceptance]
    ▲                              缺信息环境
CoT            [拆短任务]
    ▲                              spec 仍模糊
Prompt         [自然语言]
                                   起点

每一级都在补上一级的缺陷,逐步逼近"声明式 + reconcile"的完整范式。

4.1 Prompt Engineering — 模糊的声明

最早的形态:用户给一个 prompt,大模型朝着这个任务执行。

"帮我写一个登录函数。"

问题在哪?目标定义太模糊。结合 LLM 的随机性,产出质量飘忽。这是声明式的"原始版本"——有终点的概念,但终点没说清楚。

4.2 Spec Engineering — 显式的声明

第一次进步是 Chain of Thought(CoT)[^cot]——逼模型在回答前生成中间推理步骤。

CoT 本质上做了一件事:把一次长距离任务,拆成多个短距离子任务。每一步基于上一步的中间状态推进——这其实是在把"一次性映射"变成"reconcile 化推理"。每一个子步骤都是一次 mini reconcile。

但 CoT 还不够。CoT 是模型自己拆任务,不是用户写清楚目标。

于是 Spec Engineering 登场——用户显式定义终点:

• Plan(整体计划)
• Task 拆解(每一步)
• Acceptance criteria(怎么算完成)
• Negative constraints(不要做什么)
• Examples(成功长什么样)

Spec ↔ K8s 的 yaml。这是第一次直接对应。

但这里有一个 K8s 没有的根本问题:AI 数学上不收敛。

K8s controller 是确定性状态机——同样输入永远同样输出,数学上保证 monotonic 趋向 desired state。AI agent 不是。同一个 spec,agent 这次走对了,下次可能在解空间里乱晃,改了 A 破 B、修 B 破 A,陷入死循环。

光有 spec,救不了你。

4.3 Context Engineering — 信息环境

为什么 spec 不够?因为 LLM 自己的"工作记忆"也不可信。

这里要展开一个计算机科学的第一性原理:局部性(locality)。

任何用 cache 的系统都有局部性带来的好处和坏处:

• 好处:快(命中 cache 不用重新计算)
• 坏处:cache 可能过期、可能有偏见

LLM 的注意力机制[^attention]本质上也是一种 cache。它对当前上下文里的信息有强烈关注,对远端的信息注意力衰减。这意味着——

不管未来的大模型怎么设计,只要它有"上下文"概念,局部性问题就一定存在。这是第一性的,不会消失。

所以我们不能完全相信 LLM 自己 session 内的 context。需要做外部持久化——

• .md 文件:可读性数据(决策、知识、规范)
• .json 文件:结构化数据(配置、状态)

持久化 ↔ K8s 的 etcd。又一次直接对应。

加上领域知识——每个项目、每个领域、每个团队都有自己的 best practice 和 trade-off。这些不能每次让 LLM 重新发现,要沉淀成 skills 和 workflow。

Skills ↔ Helm chart / Operator。第三次对应。

4.4 Harness Engineering — 完整的工程对象

到这里,我们有了 spec(终点)、有了 context(信息环境)、有了 skills(领域知识)。够了吗?

还不够。Agent 还可能干一些爆炸半径很大的事情——你不能只告诉它"要去哪",还得告诉它**“不能怎么去”**。

这就是 boundary——边界设计。

K8s 在这件事上有完整答案:权限三层——

• AuthN(认证)— 你是谁
• AuthZ(RBAC)— 你能调什么 API
• Admission(准入控制)— 这次具体能不能干

AI agent 工程几乎是逐条复刻这套机制[^anthropic-agents]。最直观的对应是 hooks ↔ Admission webhook——同样是"动作前/后注入策略"的拦截点模式(Claude Code hooks 设计笔记)。看一下两者的实际配置:

Claude Code 的 hooks(settings.json):

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "command": "~/.claude/hooks/audit-pre.sh"
    }],
    "PostToolUse": [{
      "matcher": "Bash",
      "command": "~/.claude/hooks/audit-log.sh"
    }]
  }
}

K8s 的 ValidatingAdmissionPolicy(只看核心):

matchConstraints:
  resourceRules:
  - operations: ["CREATE", "UPDATE"]      # ← 何时拦截
    resources: ["deployments"]
validations:
- expression: "object.spec.replicas <= 10"   # ← 判断逻辑
  message: "replicas must not exceed 10"

结构惊人地像:都是"在某个动作发生时,跑一段判断逻辑,决定 allow / deny / mutate"。这不是巧合,是 harness 设计者直接借鉴了 K8s 的成熟范式。

把所有东西串起来,harness 是什么?

Harness 翻译过来是马具。

人骑马,需要一整套马具——缰绳、马鞍、马镫、嚼子。这些不是马的一部分,是人和马之间的工程。

_{(图:harness 实物 / 已存放于 /pics/harness.png)}

AI agent 工程也是一样。Harness 是人和 agent 之间的完整工程对象。

它的层次是:

┌─────────────────────────────────────────────────────┐
│ [Harness 层]            [K8s 对应]                  │
├─────────────────────────────────────────────────────┤
│ 6. Observability    ←  metrics / logs / events     │
│ 5. Verification     ←  (frontier — 还在演化)        │
│ 4. Memory & State   ←  etcd                        │
│ 3. Workflow         ←  Helm / Operator             │
│ 2. Boundary         ←  RBAC + Admission + SecCtx   │
│ 1. Spec             ←  yaml / CRD                  │
└─────────────────────────────────────────────────────┘

前 4 层都有相对成熟的对应。后 2 层是 frontier——这也是当前 AI agent 工程最薄弱、最值得投资的地方。

为什么 AI 不能完全替代程序员?

因为中间隔着这层 harness。写好 harness 本身就是一种工程——和 K8s 时代的"写 Operator"、IaC 时代的"写 Terraform module"是同一类工作,只是层次不同。

---

五、Verification — 当开发自测的偏见在 AI 身上重演

让 agent 跑测试是最直觉的 verification。但这里藏着一个老问题。

软件行业很早就发现:让开发自己写测试是有偏见的。

开发能想到的所有 corner case,他写代码时已经考虑了——所以他写出来的测试,基本只 cover 他已经考虑过的情况。真正的盲区,他自己看不见。

这就是为什么有专职测试工程师这个角色——他们带着完全不同的 context 和心态,会发现开发想不到的问题。

这个问题在 AI agent 身上完全重演,而且更严重。

让一个 agent 写代码 + 同一个 agent 写测试,你拿到的是一个充满 confirmation bias 的产物。Agent 相信自己生成的代码是对的,所以它写的测试只验证"这段代码能跑"——而不是"这段代码是否实际正确"。

解法是什么?

起一个干净 context 的另一个 agent——不带任何前置信息,做对抗性 review。这就是 red team 模式[^scalable-oversight]。

实际工具上,可能是另一个 codex / cursor / claude code 实例,可能是同一个模型起的独立 session。关键不是用什么模型,是 context 必须是干净的:

┌────────────────────┐         ┌────────────────────┐
│  主 Agent          │         │ Red Team Agent     │
│  (full context)    │         │ (clean context)    │
│                    │         │                    │
│  写代码            │         │  审视代码          │
│  写测试 ←─bias─┐   │         │  无前置假设        │
│                │   │         │  对抗性提问        │
└────────┬───────┴───┘         └─────────┬──────────┘
         │                               │
         └───────────┬───────────────────┘
                     ▼
             人审 (final gate)

Verification 的本质是用一个独立观察者审查另一个执行者。这个原则在传统软件工程里活了 30 年,在 AI agent 工程里依然成立——只是观察者从"另一个人"变成了"另一个 context 的 agent"。

---

六、Observability — K8s 易,Agent 难

K8s 的 observability 是一个已经解决的问题。原因很简单——K8s 的状态全是结构化数据。

• Metrics:Prometheus 抓取,数值型,可聚合可告警
• Logs:结构化 JSON,标签丰富,可索引
• Traces:span 之间有清晰因果关系
• Events:kubectl describe 直接看到发生了什么

整个 cloud-native 生态(Prometheus / Grafana / OpenTelemetry)就是建立在"K8s 状态可结构化观测"这个前提上。

AI agent 不一样。Agent 的"状态"是什么?

• LLM 的内心独白(完全黑箱)
• conversation context(部分可见)
• 文件系统(部分可见)
• 外部 API 调用(可见但散落)

你无法像 K8s 那样精确观测一个 agent loop 内部到底发生了什么。

两边的"事件"长什么样,直观对比一下:

# K8s metric — 结构化、可聚合、有 schema
http_requests_total{method="GET",route="/api/v1/pods",status="200"} 24891

# Agent audit log — 半结构化、含自然语言
{"timestamp":"2026-04-27T09:04:30Z",
 "tool":"Bash",
 "command":"kubectl get pod -n monitoring",
 "stdout":"alertmanager-0  0/1  CrashLoopBackOff  3  47s",
 "agent_reasoning":"用户报告告警瘫痪,先看 alertmanager pod 状态..."}

那怎么办?最低限度的解法:

1. 把所有 tool call 拉下来(谁调了什么、参数是什么、返回什么)
2. 把 agent reasoning 拉下来(它"为什么"做这个决定)
3. 把人的输入和 agent 的输出全保留
4. human in the loop 在关键节点强制人审

这是当前的 state of art——不能把 agent 当黑箱。哪怕只是把 log 都吐到一个文件里,起码人有据可查。

工具生态正在长出来:Claude Code 的 audit hooks、OpenAI 的 transcript export、OpenTelemetry GenAI 语义约定[^otel-genai]——但和 K8s 的成熟度相比,还差一个十年。

Observability 是 AI agent 工程的下一个 frontier。谁能先把这块做扎实,谁就拿到了 K8s 时代 Prometheus 那样的位置。

---

七、未来 — 第二次殊途同归

回到一开始那个词:殊途同归。

我们在第二节看到声明式哲学的第一次殊途同归——IaC 通过 GitOps 回到了 K8s 范式。

现在,我们正在见证第二次殊途同归:

K8s 时间线:
  2003 ─────── 2014 ─────── 2017 ─────── 2024
  Borg 内部    K8s 开源    GitOps        成熟生态
                           出现          (Prometheus / Argo / OPA)

Agent 时间线:
  2022 ─────── 2023 ─────── 2024 ─────── 2029?
  GPT-3.5     Tool use     Harness Eng   ?
                           出现          (?)

   └─── 同构演化,加速重演 ───┘

未来的方向

AI agent 工程接下来会发生什么?基于 K8s 的演化经验,可以做几个预测:

1. Spec 会脱离纯自然语言

当前的 spec 是中文/英文,有歧义,不可机器验证。未来会出现一种介于自然语言和代码之间的中间形态——可能像 K8s yaml 那样有 schema、可静态检查。Spec DSL 是 AI agent 工程的下一块金矿[^dspy]。

2. Observability 会结构化

不再是把 transcript 一股脑存下来,而是定义清晰的"agent metric"——任务成功率、收敛 step 数、tool 调用错误率。这就是 agent 时代的 Prometheus。

3. 收敛性会被理论化

当前 agent loop 不收敛是个未解决的数学问题。未来某种结合形式化方法 + LLM 的工具,可能给出"在某个 spec 下,agent 必收敛"的保证。这是 academic 还在拓荒的领域。

K8s 经验就是 AI agent 的路线图

更深的洞察是这个:

任何一个 K8s 早期解决过的问题,都会在 AI agent 层以新形态重演。

权限系统、配额管理、调度策略、滚动升级、operator 模式、service mesh、多租户——K8s 用十年走过的路,AI agent 工程会用 5 年加速重走一遍。解法可以直接借鉴。

这就是为什么"看懂 K8s,你就看懂 AI agent 的未来 5 年"——这不是修辞,是工程历史的重复结构。

工程师角色的演化

K8s 时代的运维没有消失,他们升级成了 Platform Engineer——从"调机器"变成"设计平台"。

AI agent 时代的程序员也不会消失,他们会升级成 Harness Engineer——从"写代码"变成"写 spec + 设计 harness + 设计 evaluation"。

完全同构。这是同一个故事的最新一章。

---

收尾

写到这里,核心的话已经说完了。

K8s 的根选择是承认"错误是常态",用声明式 + reconcile 把这件事内置进系统。这个选择长出了过去十年的基础设施革命,通过 GitOps 殊途同归地拉拢了所有 IaC 工具。

AI Agent 是这个范式的下一个阵地。从 Prompt Engineering 到 Spec、Context、Harness Engineering——每一步都在重走 K8s 的路,每一层都能找到对应。当前的 frontier 是 Verification 和 Observability,这是接下来 5 年最值得投资的两块。

如果你今天在做 AI agent 相关的工程,我有一个具体建议:

看看你 agent 工程的每个角落,然后问自己——K8s 在这个问题上是怎么解决的?

大多数时候,答案已经在那儿。你只需要把它翻译过来。

---

留一个开放问题:下一个十年,会不会有一种东西,让 harness engineering 也殊途同归到一个更新的范式?

那时候我们再聊。

---

引用 References

[^borg]: Verma, A. et al. “Large-scale cluster management at Google with Borg.” EuroSys (2015). https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/

[^bok]: Burns, B., Grant, B., Oppenheimer, D., Brewer, E., Wilkes, J. “Borg, Omega, and Kubernetes.” ACM Queue 14 (2016). https://queue.acm.org/detail.cfm?id=2898444

[^gitops]: Richardson, A. “GitOps - Operations by Pull Request.” Weaveworks (Aug 2017). https://medium.com/weaveworks/gitops-operations-by-pull-request-14e8b659b058

[^survey]: 《MLOps & AI Agent 在生产环境采用情况调研》(2026-03-30). https://github.com/shaorui0/context-infrastructure/blob/main/contexts/survey_sessions/mlops_ai_agent_dev_survey_20260330.md

[^klarna]: Klarna 在 2024 年大规模部署 AI 客服后的部分回退案例,业界广泛报道。详见个人调研: https://github.com/shaorui0/context-infrastructure/blob/main/contexts/survey_sessions/mlops_ai_agent_dev_survey_20260330.md

[^cot]: Wei, J. et al. “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models.” NeurIPS (2022). https://arxiv.org/abs/2201.11903

[^attention]: Vaswani, A. et al. “Attention Is All You Need.” NeurIPS (2017). https://arxiv.org/abs/1706.03762

[^anthropic-agents]: Schluntz, E. & Zhang, B. “Building Effective Agents.” Anthropic (Dec 2024). https://www.anthropic.com/research/building-effective-agents

[^scalable-oversight]: Anthropic. “Constitutional AI: Harmlessness from AI Feedback.” (2022). https://www.anthropic.com/research/constitutional-ai-harmlessness-from-ai-feedback (paper: https://arxiv.org/abs/2212.08073)

[^otel-genai]: OpenTelemetry. “Semantic conventions for generative AI systems.” https://opentelemetry.io/docs/specs/semconv/gen-ai/

[^dspy]: DSPy (Stanford NLP): https://github.com/stanfordnlp/dspy / https://dspy.ai/. Inspect (UK AI Security Institute): https://github.com/UKGovernmentBEIS/inspect_ai / https://inspect.aisi.org.uk/