Agent 开发的 K8s 式范式：声明 desired state 后持续收敛

是什么 一条纯观点推文。作者提出当前 PR 开发是“面向事件”的流程驱动（提 PR → CI → review → 改码 → 再 review），而 Agent 时代更像 Kubernetes 的“面向状态”：人只声明 desired state（bug 不复现、p99 回归 <2%、测试全通过），Agent 持续 reconcile，直到 current state == desired state，写代码的终点从 git push 变成 kubectl apply -f spec.yaml。

核心洞察 借 K8s 声明式 API 与控制循环的成熟隐喻，重新划分人机分工：人类的价值从“编写并推动变更”上移到“定义不变量与验收标准”，而评审、修复、回归守门等收敛过程交给 Agent 自主迭代。这个隐喻把“Agent 写代码”从模糊的自动化口号，落实为可操作的工程契约——规格即代码、验收即状态、收敛即交付。

关键洞察

1. 开发范式的升级方向是从流程编排转向目标声明；
2. SLO（如 p99 阈值）与测试可以充当机器可判定的收敛判据；
3. 开发者角色向“spec 作者 + 状态审计者”演进。

边界与风险 纯观点，无实现与数据支撑。desired state 很难完备：隐藏 bug、安全约束、代码可维护性难以编码进 spec；量化的收敛判据容易被“指标作弊”（reward hacking）钻空子；收敛不等于正确，声明式理想与现实工程之间仍有大量空白待解。