SRE Agent 设计笔记 06：Agent 通信介质是文件，不是 Session

发表于 分类于

状态：大纲

核心论点

Agent 之间的通信应该通过持久化文件，不是共享 session。文件是 git-tracked、可 diff、可 audit、异步的；session 是 volatile、不可 inspect、时间耦合、不可恢复的。这是 Unix 哲学在 agent 时代的自然延伸。Plan file 的三重身份（执行计划 + RBAC 策略 + audit log）是这个原则的极端体现。

大纲

1. 共享 Session 的脆弱性

  • 当前主流 multi-agent 模式：agent 之间共享 conversation context
  • 四个问题：
    • Volatile：context 被压缩后信息丢失
    • 不可 inspect：无法从外部观察 agent 之间传递了什么
    • 时间耦合：必须在同一 session 内完成交互
    • 不可恢复：session 中断后无法从断点继续

2. 文件作为通信介质

  • 文件的特性：git-tracked、可 diff、可 audit、异步、可恢复
  • Unix 哲学：程序之间通过 stdin/stdout/文件通信，不共享内存
  • K8s 类比：所有状态通过 API server（etcd）持久化，controller 之间不直接通信
  • Agent 的 interfaces 是文件 + 目录约定，不是 session context

3. Plan File 的三重身份

一个文件同时承担三个角色：

  • 执行计划：进度追踪（哪些 step 完成了、哪些还没做）
  • RBAC 策略：scope gate 读 plan file 做权限判断（agent 的操作是否在 plan 声明的 scope 内）
  • Audit log：执行结果追加到底部（可追溯）

为什么三重身份能统一到一个文件：它们共享同一个核心需求——在 context window 压缩后仍可恢复。文件不会被压缩，context 会。

4. Spec 的文件化

  • Spec（终态定义）必须是文件，不是 prompt 里的一句话
  • Prompt 在 context 压缩时可能丢细节
  • 文件支持版本控制：spec 的变更历史可追溯
  • 文件支持 diff：两个版本的 spec 之间有什么变化一目了然

5. 实践中的文件通信模式

以 oncall triage agent 为例：

  • Worker 的产出写入 structured trace 文件
  • Verifier 读 trace 文件做审计
  • Orchestrator 读 Verifier 结果决定下一步
  • 不需要共享 session，不需要实时消息
  • 每一步的中间状态都可追溯

6. 和 Agent as Code 的关系

三层 spec 架构（Identity / Capability / Constraint），每层都是文件：

  • Layer 1 (Identity): SOUL.md, COMMUNICATION.md, USER.md
  • Layer 2 (Capability): skills/*.md, plan files
  • Layer 3 (Constraint): hooks, gating rules, RBAC

Spec 是 source of truth，prompt 是编译产物。

涵盖的 Topic

  • Topic 12: Agent 通信介质是文件不是 session
  • Topic 11: Plan file 三重身份

源文件引用

  • contexts/thought_review/agentic_control_theory_primitives_20260413.md — 「Agent Communication: Files > Sessions」完整论证
  • contexts/thought_review/agent_sre_production_systems_synthesis_20260330.md — Plan file 三重身份，Agent as Code 三层 spec 架构，四阶段演化路径
  • contexts/thought_review/agentic_ai_controllability_design_20260329.md — Plan file 作为 central pivot 的设计