状态：大纲 核心论点 当前 multi-agent 框架用角色拟物（PM/Engineer/QA/Reviewer）建模协作，掩盖了真正的工程约束。正确的抽象是四个控制论原语：Spec、Loop、Hook、Fork。每个原语在 K8s 中都有精确的对应物，因为 K8s 花了二十年解决的就是同一类问题。 大纲 1. 角色抽象的问题 当前框架的拟物设计（skeuomorphism）：用人类组织角色降低认知负担 PM agent 和 Engineer agent 的本质区别不是「一个写需求一个写代码」，而是对 context…
状态：大纲 核心论点 约束 agent 行为有两条路径：命令式（规定步骤顺序）和声明式（定义终态条件）。命令式约束容易被绕过，声明式约束让 agent 自己找路径收敛。K8s 的核心设计哲学（Desired State YAML > kubectl imperative）在 agent 约束设计中同样适用。集群分级是声明式约束的实例：按 failure cost 分级，hook 根据等级做语义门控。 大纲 1. 命令式约束的局限 「coding 之后必须 compile，compile 之后必须 test」 像 checklist 一样规定步骤…
状态：大纲 核心论点 Audit log 只记录 what 不记录 why 是一个老问题。INTENT convention 用 bash 注释嵌入推理，零工具开销。这个设计是被约束逼出来的：Claude Code 的 hooks 无法访问 conversation context，所以推理必须嵌入命令本身。约束驱动设计（constraint-driven design）本身值得展开。 大纲 1. 问题：Audit Log 的 Why 缺失 传统 audit log 记录了谁、在什么时间、对什么资源、做了什么操作 缺失的是…
状态：大纲 核心论点 避免 prompt engineering 的方式不是写更好的 prompt，而是把 prompt 中的质量约束抽取到 Spec 里持久化。Prompt 退化为触发器（「帮我做 X」），Spec 承载所有的过程约束和质量定义。好的 Skill 不是限制过程步骤，而是定义产出的终态属性。Skill 是 prompt engineering 的退出路径。 大纲 1. 问题：两种 Prompt 的差距 Prompt 1：「帮我实现 xx」 Prompt 2：「帮我实现 xx，验证编译通过且功能正确，收敛时写一个 .sh 验证」…
状态：大纲 核心论点 设计 oncall triage agent 时，第一步不是接 MCP、不是调 Grafana API，而是定义证据格式。结构化 triage trace 的 schema 决定了产出质量的上限，工具集成只是填充 schema 的手段。手段可以换，格式不能乱。 大纲 1. 叙事 vs 结构 人类 incident case 是叙事体：「凌晨 3 点收到告警，先看了 dashboard……」 Agent 需要结构化 trace：Signal → Routing → Decision Trace → Evidence Chain →…
状态：大纲 核心论点 四原语（Spec/Loop/Hook/Fork）从三个完全独立的来源收敛到同一组结论。这种交叉验证本身是一个方法论观察：当不同路径独立到达相同抽象时，这些抽象大概率是结构性的而非偶然的。同时，这个收敛也指向一个实践判断：框架选择的重要性在下降，Harness 的 Policy Runtime 和 Stateful Workflow 两层才是持久投资方向。 大纲 1. 三个独立来源 OpenAI Codex 的设计选择 Docs as system of record（不是 prompt，是文件） Review…
状态：大纲 核心论点 Agent 的知识不是一坨 prompt 塞进去就行。Skills / Facets / Knowledge 是三种不同抽象层次的知识，对应不同的加载策略和变更频率。这个分层不是分类学上的洁癖，是被两个实际力驱动的：context window 预算管理和维护责任分离。从四原语的视角看，Skills 是 Spec 组件，Facets 是 Loop 的方法论，Knowledge 是 Loop 执行时的领域数据。Blog 08（Prompt to Skill）讲了「Skill 是持久化的 Spec」，本篇回答它的…
状态：大纲 核心论点 Agent 之间的通信应该通过持久化文件，不是共享 session。文件是 git-tracked、可 diff、可 audit、异步的；session 是 volatile、不可 inspect、时间耦合、不可恢复的。这是 Unix 哲学在 agent 时代的自然延伸。Plan file 的三重身份（执行计划 + RBAC 策略 + audit log）是这个原则的极端体现。 大纲 1. 共享 Session 的脆弱性 当前主流 multi-agent 模式：agent 之间共享 conversation context…
状态：大纲 核心论点 Oncall agent 慢，常被归因为「LLM 推理慢」或「工具调用多」。但真实原因是一个设计选择：debug tree 把 investigation 建模成了序贯过程。这个序贯不全是真的，其中前半段（事实基座收集）本质上是独立可并行的。Deep Research Workflow 的 Phase 2 并行 fan-out 是同构解法。把 investigation 的前半段从「先 routing 再查」改成「先并行铺开事实基座再 routing」，能在不牺牲正确性的前提下把 wall-clock 时间压缩一个量级。 大纲…
状态：大纲 核心论点 Agent eval 不是测试，是度量系统设计。传统软件的 eval 是 assert equal，agent 的 eval 更像 SRE 的 SLI/SLO 框架。但有一个关键区别：SLI/SLO 的故障模式是已知的（延迟、错误率），agent 的故障模式需要先发现再定义。这让 agent eval 更接近 chaos engineering + SLO 的组合。背后的经济学基础是 cost inversion：生成便宜验证贵。 大纲 1. Cost Inversion（成本倒置） 传统软件：写代码贵、跑测试便宜 AI…