🏠 home › concepts › agent-runtime-architecture
tags
[AI, Agent, 架构, 工程, Claude Code]
created
2026-04-15
updated
2026-04-27
sources
[raw/notes/claude-code-architecture-wuyue-2026.md, raw/notes/huxuan-vibe-coding-games-2026.md, raw/notes/founder-park-creao-organizational-pivot-2026.md, raw/notes/zhang-tielei-amphiflow-agent-workflow-fusion-2026-04-25.md]

定义

一个成熟 Agent 系统的复杂度分层模型，从 Claude Code 51 万行 TypeScript 源码中提炼。核心洞见：Agent 系统一复杂就散架，不是因为模型不够强，而是复杂度被放错了位置。 每种复杂度应该只在一个地方"爆炸"，而不是平均撒到全系统。

"真正成熟的 Agent 系统，不是'模型更会做事'，而是'组织能把模型做事这件事，稳定地接进交付链路里'。"

七层模型

┌─────────────────────────────────────┐
│  7. 扩展层（MCP / Skills / Plugins）  │ ← 平台增长
├─────────────────────────────────────┤
│  6. 任务系统（Task Runtime）          │ ← 并发与持续执行
├─────────────────────────────────────┤
│  5. 权限系统（Permission System）     │ ← 风险治理
├─────────────────────────────────────┤
│  4. 工具运行时（Tool Runtime）        │ ← 行动制度化
├─────────────────────────────────────┤
│  3. 查询循环（Query Loop）            │ ← 连续运行
├─────────────────────────────────────┤
│  2. REPL / UI 编排                   │ ← 人机协作
├─────────────────────────────────────┤
│  1. 入口与启动链路                    │ ← 执行边界
└─────────────────────────────────────┘
层 核心职责 承接的复杂度
1. 启动层 入口分流→进程初始化→会话准备 模式边界、权限定型、宿主选择
2. REPL 汇总能力面 + 归并事件流 人机协作、运行时可观察性
3. Query Loop 一次请求变成一段连续运行 上下文治理、失败恢复、工具回灌
4. Tool Runtime 把工具调用变成受控 syscall 校验、并发、进度、错误归一化、结果回填
5. Permission 可解释的四层决策链 规则→自动判定→交互→执行隔离
6. Task 统一任务抽象覆盖所有执行形态 生命周期、状态、回流、上下文隔离
7. 扩展层 外部多样性→内部少数对象 动态能力面、平台增长

三条主干链路

七层不是简单堆叠，而是收敛为三条链路：

控制链（怎么想/怎么续跑）
    启动层 → REPL → Query Loop

执行链（怎么动/怎么受约束）
    Tool Runtime → Permission → Sandbox

任务链（怎么并发/怎么持续/怎么回流）
    Task Runtime → 生命周期管理 → 结果回流主会话

扩展层不是第四条链路，而是给三条主链持续注入能力。

关键架构判断

1. 启动层：先定边界，再发起推理

"凡是会影响执行边界的东西，尽量都在第一轮请求前定型。"

2. Query Loop：不是 API 调用，是状态机

普通实现：拿历史消息调一次模型，拿到结果就结束。Claude Code：一次 agent turn 是一段会被压缩、恢复、工具回灌、预算和中断反复改写的运行。

state = {
  messages, toolUseContext,
  autoCompactTracking, maxOutputTokensRecoveryCount,
  turnCount, pendingToolUseSummary, transition
}

while (true) {
  prefetchMemoryAndSkills()
  messages = applyBudget → snipAndCompact
  assistant = streamModel(messages)
  if (!hasToolUse) return finishTurn()
  toolResult = runToolUse()
  messages = writeBack(messages, assistant, toolResult)
}

四类 runtime 机制： - 上下文治理：snip → microcompact → collapse → autocompact（五层压缩管线） - 失败恢复：reactive compact / max output recovery / fallback model - 工具结果回灌：结构化为 user message 重新进入消息流 - 预取优化：memory/skill discovery 藏在流式和工具执行空隙（memory 写入边界见 auto-memory，整合机制见 auto-dream）

3. Tool Runtime：从函数调用到受控 syscall

// 普通实现
type Tool = (input: unknown) => Promise<string>

// Claude Code
interface Tool {
  name: string
  inputSchema: Schema
  canRunInParallel: boolean
  validate(input): ValidationResult
  execute(input, context): AsyncIterable<ToolEvent>
  toModelResult(output): StructuredResult
}

差别不在写法，在系统观。后者意味着 runtime 知道这个动作该怎么被约束、观测、并发和回灌。

四段式执行：解析 tool → schema 校验 → permission 决策 → 执行 + 归一化。连"权限拒绝"都包装成标准 tool_result 回到主循环——主循环不需要知道是"执行成功"还是"权限拒绝"，只需要知道"收到了结构化结果，可以继续推理"。

4. Permission：可解释的决策链，非确认框

type PermissionDecision =
  | { behavior: 'allow'; updatedInput?; decisionReason? }
  | { behavior: 'ask'; message; suggestions?; blockedPath?; pendingClassifierCheck? }
  | { behavior: 'deny'; message; decisionReason }

四层拆分：规则层（匹配允许/拒绝/待确认）→ 运行时判定层（classifier/hooks 自动决策）→ 交互层（真需要才打断用户）→ 执行隔离层（sandbox 压实文件/网络/命令边界）。

核心区分：逻辑上允不允许 vs 进程层面到底能做到什么。

5. 多 Agent = 统一任务抽象，非 prompt 分工

// 普通实现
spawnAgent(prompt): Promise<string>

// Claude Code
interface Task {
  id: string
  status: 'pending' | 'running' | 'blocked' | 'done' | 'failed'
  progress: ProgressState
  output: StructuredOutput[]
  notifications: Notification[]
  cancel(): void
  resume(): void
}

子 Agent 先是任务对象，才是智能体。主会话后台化、本地 subagent、进程内 teammate、remote agent 全部映射到同一套任务语义。前台和后台的差别不在 agent 逻辑，在调度和可见性。

6. 扩展层：外部热闹，内部收敛

原则：动态能力面，稳定内部对象。 外部来源可以很多样，但 UI、permission、query loop、task system 只需要理解少数内部对象。

五条核心原则

  1. 先定义执行边界，再发起第一轮推理
  2. 连续运行阶段，query loop 必须升级成 runtime
  3. 工具一旦碰副作用，工具层必须制度化
  4. 权限系统的核心不是确认框，而是可解释的执行链
  5. 多 Agent 的前提不是 prompt 分工，而是统一任务抽象

与 Harness Engineering 的关系

这篇分析是 harness-engineering 的源码级验证。Harness Engineering 提出"Agent = Model + Harness"的宏观判断，七层三链模型展开了 Harness 内部的具体架构。

Harness 概念 七层对应
五层上下文压缩管线 Layer 3 Query Loop
Cache 经济学 Layer 3 预取/预算
工具设计哲学 Layer 4 Tool Runtime
Fail-closed 安全默认值 Layer 5 Permission
多 Agent 是能力分区 Layer 6 Task System
生态护城河 Layer 7 扩展层收敛

反向印证：vibe coding 平台缺 Layer 4-6 的症状

腾讯研究院 2026-04 vibe coding 游戏开发者访谈（→ vibe-coding-creator-motives）给七层模型补了一份反向证据——普通 vibe coding 平台只有 Layer 1-3 能力，Layer 4-6 缺失就是开发者实际感受到的卡点：

七层 vibe coding 平台缺失症状
Layer 4（Tool Runtime） "AI 写单个系统很强，但多系统串联协同时顾此失彼" — 没有统一 syscall 抽象，工具间状态不归一化
Layer 5（Permission） 80% 时间在 debug "你把上一个功能改坏了" — 没有 fail-closed 默认，回滚靠人
Layer 6（Task System） "做完了，然后呢？不知道如何推进" — 没有任务对象的状态/进度/回流，单次会话之外无持续运行

这是七层模型"复杂度该集中在哪儿、不该撒到全系统"判断的运行时数据——把 Layer 4-6 责任放到普通用户的 prompt 上，结果就是普通用户 6% 完成率。专业团队（CREAO 见 ai-first-engineering）有架构师补齐这几层，所以能跑出 99% AI 代码 + 每天 8 次部署的对比结果。

CREAO 实证：三层 Memory 管理 + Sandbox 隔离 <5s

CREAO 在 2026-04 Founder Park 访谈中披露内部 Agent runtime 实现细节，给七层模型补了一份独立第二样本（Claude Code 是第一样本）。

三层 Memory 管理（对应 Layer 3 prefetchMemoryAndSkills）

Thread 内：
    Context 接近模型 Context Window 上限时压缩
    → 模型对 Thread 总结
    → 应该记住的存到文件系统

跨 Thread：
    每次用户请求结束后【独立服务】用模型判断有无值得长期记录内容
    → 用户决定 / 个人信息
    → 存储 + 与之前 Memory 去重

新 Thread 启动：
    把和当前用户请求最相关的【前 15 条历史 Memory】提前加载到上下文

关键设计点： - 跨 Thread 提取走独立服务——这是 harness-engineering "Side Query" 原则的具体应用，与 Layer 3 中"memory/skill discovery 藏在流式和工具执行空隙"对应 - 新 Thread 加载 top-15 是与 sentino-memex "<500 active gists 时全量返回" 思路的另一极——CREAO 用 top-N 排序裁剪，Memex 用 4 级 TTL + 阈值控制总量。两条路径都是回避向量检索（auto-memory / auto-dream 主张同向） - 与 auto-dream 整合 / auto-memory 写入边界互补——CREAO 的三层覆盖了"压缩 / 提取 / 注入"完整生命周期

对七层模型的补强：Layer 3 prefetchMemoryAndSkills 不是单一动作，是三段流水线——压缩 / 跨 Thread 提取 / 新 Thread 注入 top-N，每段独立优化点不同。

Sandbox 启动时间从 10-20s 优化到 <5s（对应 Layer 5 Permission 执行隔离层）

CREAO 早期直接用 claude-agent-sdk / Claude Code 但启动时间 10-20s 不可接受，自建架构深度优化到 <5s。

"这件事只有充分了解自己整套架构才能做到——OpenClaw 这种开源框架要面向各种环境无法对特定场景做性能优化。"

Agent 之间运行环境必须隔离，否则 A agent 装 3 个工具包 B agent 启动时改其中一个属性 = A 工具不稳定 → 无限调优循环。

对 Layer 5 的具体含义：执行隔离不只是安全约束（Permission 视角），也是性能约束（避免 agent 间环境干扰导致的"无限调优循环"）。沙盒启动延迟是 voice-presence 视角"对话节奏"的工程瓶颈——5s vs 20s 在多 turn 对话中累积差异巨大。

对 Sentino 的启示：与 sentino-agent 评估 claude-agent-sdk 后选择自建 Agent Loop 同向同源——CREAO 也是评估后选择自建以追求性能。这是行业第二个独立样本支持 Sentino 自建决策。

对 Sentino 的启示

Sentino Standalone Agent 架构（→ sentino-agent）可以从七层模型中借鉴：

相关概念