SRE Agent 设计笔记 02：四个控制论原语

发表于 更新于 分类于

状态：大纲

核心论点

当前 multi-agent 框架用角色拟物（PM/Engineer/QA/Reviewer）建模协作，掩盖了真正的工程约束。正确的抽象是四个控制论原语：Spec、Loop、Hook、Fork。每个原语在 K8s 中都有精确的对应物，因为 K8s 花了二十年解决的就是同一类问题。

大纲

1. 角色抽象的问题

  • 当前框架的拟物设计（skeuomorphism）：用人类组织角色降低认知负担
  • PM agent 和 Engineer agent 的本质区别不是「一个写需求一个写代码」，而是对 context 隔离、验证独立性和状态持久化的需求不同

2. Spec（声明式意图）

  • 持久化的终态描述，可 diff、可校验、context 压缩后可恢复
  • Memory 不够用：best-effort、无 schema、无法校验
  • K8s 类比：Desired State YAML
  • 当前实现：workflow_autonomous_execution 的非结构化 plan file；下一步 = 机器可验证结构

3. Loop（收敛循环）

  • 不是「重复执行」，是反馈驱动的收敛
  • 关键前提：终止条件必须机器可验证
  • 验证链：文件存在 → 编译通过 → 测试通过 → sandbox 验证 → 可部署
  • 每一步把「AI 说完成了」转化为「机器确认正确了」
  • K8s 类比：Reconciliation Loop

4. Hook（准入控制）

  • 三种类型：Audit（记录）、Deny（阻断）、HITL（人工介入）
  • Red-team/challenge 是 Hook 变体（ValidatingWebhook）
  • 触发时机：spec 定义阶段 + 完成阶段各一次
  • K8s 类比：Admission Controller + OPA

5. Fork（上下文隔离）

  • 常见误解：Fork = 线程（并行加速）。实际：Fork = 进程隔离 + 显式 IPC 开销
  • 四种隔离理由及优先级：
    1. Independence-bound（review/test 必须独立，否则验证无效）—— 展开为两个子条件，两个都满足才算真 Fork：
      • Commitment isolation：下游 agent 不能知道上游 agent 已经表态过什么，只能看 spec。一旦「我刚说过这样写是对的」被传递下去，agent 会用自我一致性去维护上游主张——比 attention 污染和 preference 污染都顽固。实现原则：handoff artifact 只携带 spec，不携带 rationale/justification。
      • Terminal state opposition：下游 agent 的成功标准必须和上游对立。dev 的 terminal = 「通过验收」，test 的 terminal = 「找到反例」。共享「done」就是假 Fork——dev 判完成的那一刻 test 也判完成，Fork 沦为算力浪费。
    2. Attention-bound（context 太杂导致注意力衰减）
    3. Capacity-bound（单 context 装不下）
    4. Latency-bound（可并行加速）
  • 不满足四条中任何一条 → 不要 Fork
  • K8s 类比：Pod isolation + namespace + resource limits

为什么不是 role fork

Conway 反演：Conway 定律说组织结构塑造系统架构；对 agent 而言，prompt/harness 塑造行为。把人类 org 的 PM/Engineer/QA 角色搬进 agent 分工，是把组织 artifact 误当技术抽象——人类需要角色是因为一个人记不全、沟通慢、有政治问题；agent 没有这些约束。

换个视角：「reviewer agent」的价值 80% 来自「这个 agent 没经历过开发过程」（context freshness），20% 来自「它被设定成 reviewer」persona。Fork 的主轴是时间（context 重置），不是身份（角色扮演）。

机械条件化：不需要「PM Agent 类 / Dev Agent 类」这种概念工程，只需要两个机械属性——fresh context + opposing terminal state。满足这两条，用同一个 base agent 跑两次即是真 Fork；不满足，哪怕起名叫「独立审查专家 agent」，也只是换皮的假 Fork。

6. 实证：七角色 → 三隔离

用腾讯 JiKu Launcher 的七角色做拆解：

  • PM → 编排逻辑，不是独立 context
  • 需求分析 + 设计 → spec 撰写的前后半段
  • 门控 → Hook
  • 开发 → 需要 Fork（attention-bound）
  • 代码审查 → 需要 Fork（independence-bound）
  • 测试 → 需要 Fork（independence-bound）

七个角色 agent = 1 编排 + 1 spec context + 1 hook + 3 Fork。真正驱动 Fork 的是 3 个，不是 7 个。

7. 组合：完整控制循环

1
Spec 定义终态 → Fork 按隔离需求拆分 → Loop 驱动每个子任务收敛 → Hook 在关键节点做准入 → Loop 检查整体收敛

Skill（领域知识）是 Loop 内部的工具，不是第五个原语。类比 K8s Operator。

8. 交叉验证（可选展开或拆到 topic 9）

三个独立来源收敛到同一组原语：OpenAI Codex、腾讯 JiKu Launcher、本文的控制论推导。

涵盖的 Topic

  • Topic 2: 四原语 (Spec/Loop/Hook/Fork)
  • 部分 Topic 15: 交叉验证（三个来源收敛）

源文件引用

  • contexts/thought_review/agentic_control_theory_primitives_20260413.md — 主源文件，四原语完整推导，K8s 映射表，七角色拆解，开放问题
  • contexts/thought_review/agent_sre_production_systems_synthesis_20260330.md — Agent as Code 三层 spec 架构（Identity/Capability/Constraint）
  • rules/skills/bestpractice_agent_harness_architecture.md — Harness 三层模型（Policy Runtime / Stateful Workflow / Orchestrator）与四原语的映射