Agent Runtime Design

Agent runtime 设计的持续观察集。各条相互独立，但都指向同一个判断：协议层设计决定 agent 行为质量。

否决边界（veto boundary）——多 Agent 协作不是指令传话。Orchestrator 拆解任务、分配意图，但每个接收方 Agent 需要明确的否决边界：什么情况下可以拒绝上游指令、什么情况下必须执行。没有否决边界的编排在错误传播时没有刹车。（note）

自然语言作为工具状态（natural language tool state）——agent 生成 bash 时写注释、用 && echo ok || echo failed 把 exit code 翻译成文字，看似冗余，实际是把状态转成模型最容易消费的表达。设计 tool use 时可以让 tool input 承载 intent 描述、tool output 返回自然语言状态，而不是只有裸数据。（note）

tool_result 的角色设计（tool call role design）——Claude 把 tool_result 放进 role: user 不是混乱：这里的 "user" 承载的是 client / environment 递回的外部观察，不是真人发言。Codex / Responses API 则把工具调用与结果建模为独立事件。两种协议形状对上下文操作（裁剪、重放、缓存）的影响不同。（note）

Context System 的六层职责（context system layering）——把「上下文」当一个整体喂给模型是复杂性失控的起点。责任分层：System Prompt 只放稳定身份、少量不可越界的边界和输出协议（不放临时状态和 bad case 例外）；Dynamic Context 放本轮已确认的事实、状态与允许空间；State/Code/Engine 承担状态转移和确定性裁决；Tool/Retrieval 按需取外部事实并标注来源与新鲜度（不一次性灌入所有可能相关内容）；LLM 只负责理解真实对话、处理模糊性、自然表达（不反复猜系统已知的确定事实）；Frontend/Guard 承担用户确认与动作执行这道最后闸门（高风险动作不寄托在一句 Prompt 上）。表达形式对应承担不同复杂性：boolean 是闸门、enum 是轨道、schema 是结构边界、自然语言负责开放世界——判断标准是一条规则能否容忍概率性执行。（source）

对话空气（conversational air）——结构化的反向极端是把模型「饿死」：全部变成 boolean/enum/短字段后，模型不知道用户已经等了很久、上一轮问过同样的问题、这句该承接抱怨还是确认，产出「每个字段都对但像陌生人」的回复。删掉「这次带父母一起，不想太赶」这类原话，结构正确的行程可以体验糟糕。原则：让确定性信息不再伪装成需要理解的散文，同时保留模型理解真实对话所需的语境——不是自然语言越少越好，而是没有归属的隐式规则越少越好。与「自然语言作为工具状态」互为边界条件：状态可以翻译成语言，语境不能压缩成字段。（source）

时延即答案质量（latency as answer quality）——实时 agent 存在很窄的用户决策窗口：建议在决定形成前出现是助力，之后出现只是打断。实测案例：给实时客服 Copilot 加 RAG，离线指标全面变好，端到端时延 ~2.6s→~5.5s，上线采纳率归零——模型没变笨、内容没变差、系统没报错，产品失败。推论：能力（如检索）不必常驻实时关键路径，可以退到离线资产、few-shot 或非实时流程；评测必须把端到端时延和真实采纳放进同一张图，且同时看三个尺度——组件与契约、端到端链路、线上产品结果。单节点正确只能证明单节点正确，不能替整套 harness 作证。（source）

工程实践端的对照样本是 agent-iteration-harness：当迭代进入多轮，runtime 设计问题（谁看什么上下文、谁有权否决、退化怎么被拦住）会以效果波动的形式暴露出来。