沙箱底层机制
一轮源码级的沙箱引擎调研沉淀。从隔离、缺页、逃逸讲到资源、存储、镜像、网络、调度，最后收敛到一个判断：七个选型角度其实是「共享不共享内核」这一个决策的七个投影。
共 14 篇
01 给 AI Agent 选沙箱：先决定是否共享内核 启动、资源、存储、网络和调度看似是不同问题，背后首先取决于是否与宿主机共享内核。先做隔离决策，再比较其他指标。 02 沙箱系列（二）：缺页如何支撑快照与 CoW 缺页异常把内存访问变成可拦截事件，CoW、快照懒加载与按需映射因此能够延迟复制和恢复成本。 03 沙箱系列（三）：三类逃逸对应三类防线 沙箱逃逸分别来自过度配置、运行时组件漏洞和共享内核漏洞；不能用同一种加固措施概括。 04 沙箱系列（四）：声明式控制面保存的是期望状态 CRD 定义 Sandbox 的期望状态，Controller 持续对比现实并收敛；可靠性来自重复 Reconcile，而不是一次创建命令。 05 沙箱系列（五）：Wasm、eBPF 与 GPU 需要三种独立判断 Wasm 用能力接口限制宿主访问，eBPF 通过加载前验证获得内核执行权，GPU 则依赖设备与驱动隔离；三者不能套用同一种沙箱模型。 06 Agent Runtime 落地：稳定边界在会话与执行合同 沙箱引擎负责隔离与资源，Agent Runtime 负责会话、工具和恢复；统一 Facade 应建立在多 Runtime 需求上，而不是提前抽象单一引擎。 07 沙箱系列（六）：「2 核 4G」对应两种资源模型 容器通过 cgroup 实施可调整的共享限额，microVM 在启动时定义虚拟硬件；相同规格具有不同保证与弹性。 08 沙箱系列（七）：Warm Pool 与持久挂载存在身份矛盾 Warm Pool 要在用户到来前创建实例，持久挂载却需要先知道用户与 Workspace；两者不能同时作为无条件前置步骤。 09 沙箱系列（八）：镜像分层是不是引擎的原生能力 OCI 在文件级原生分层，Firecracker 只接收完整块设备，Kata 则分开提供系统镜像与容器内容；三者的复用成本不同。 10 沙箱系列（九）：域名级出口控制属于协议层 容器、gVisor 与 microVM 都不能仅靠隔离引擎表达域名白名单；连接时只剩 IP，需要代理或域名感知策略维护域名与连接的绑定。 11 沙箱系列（十）：强隔离会同时增加调度与观测成本 microVM 依赖 KVM、块设备与本地快照，无法像普通容器一样任意放置；Guest 内外还需要两条观测链。 12 沙箱系列（十一）：七个工程角度源于同一个隔离决定 隔离、启动、资源、存储、镜像、网络与调度不是独立参数；是否共享宿主内核会沿整条实现链产生后续约束。 13 AgentENV 案例：训练环境为什么选择 microVM 与快照 Agentic RL 需要大量同起点、可分叉且隔离的环境；AgentENV 用 Firecracker、快照与远端块存储组合解决这一约束。 14 沙箱系列（十三）：整机分叉的成本由后续写入决定 从运行中 VM 创建多个分支，本质是快照恢复加内存与磁盘 CoW；创建可以很快，长期成本取决于每个分支的脏页和身份重建。
Agent 工程
怎么设计一个 agent 服务。从 loop 内部机制、工具边界、状态持久化，讲到上下文工程、评估、安全、规划模式、可观测与记忆分层。贯穿全系列的判据只有一条：模型只能看到本次请求塞给它的内容，其余必然在 harness。
共 16 篇
01 Agent 工程（一）：模型之外，都是 Harness 的职责 模型只处理本次输入，记忆、工具执行、重试、权限和恢复都发生在外部。理解这条边界，才能判断 Agent 功能应该写在哪里。 02 Agent 工程（二）：专用工具是在给 Harness 建立可管控边界 是否把一个动作设计成专用工具，取决于 Harness 是否需要识别、拦截、审计或调度它，而不是这个动作能否用 bash 完成。 03 Agent 工程（三）：Checkpoint 是执行历史，不是状态备份 Checkpoint 必须记录状态之间的因果关系，才能区分安全续跑与可能重复副作用的重放。 04 Agent 工程（四）：只追加存储如何保住 Checkpoint 因果链 Checkpoint 采用只追加记录，是为了保留父子关系、并发顺序和恢复证据；代价是存储增长与版本迁移。 05 Agent 工程（五）：上下文工程是在分配注意力预算 上下文不是越完整越好；每条指令和材料都会与已有信息竞争，应根据违反代价、命中率和获取成本决定是否进入。 06 Agent 工程（六）：Prompt Cache 优化的是稳定前缀 Prompt Cache 按前缀复用计算；稳定内容必须靠前，动态工具、时间戳和非确定序列化会让后续缓存静默失效。 07 Agent 工程（七）：Agent 可靠性的上限取决于目标能否验证 Harness 无法直接理解“完成”，但可以把语义目标转换为退出码、产物校验和评分标准，并据此检测停滞与拒绝错误完成。 08 Agent 工程（八）：评估集用于防回归，不用于证明质量 Agent 评估是带噪声的测量；固定样本适合比较改动前后，系统质量仍需由业务结果、线上数据和人工校准共同定义。 09 Agent 工程（九）：Prompt Injection 的防线是能力边界 指令与数据进入同一模型通道后，注入无法仅靠文本检测根治；更可靠的策略是限制凭据、工具与网络能力。 10 Agent 工程（十）：规划的核心决策是何时重新观察 ReAct、Plan-and-Execute 和 ReWOO 的主要差异，可以归结为执行一步后是否需要回到模型观察结果并重新决策。 11 Agent 工程（十一）：一次运行应当记录为因果树 Agent 包含模型、工具、子任务和重试分支；只有保留父子关系的 Trace，才能解释一次运行为何变慢、失败或偏离目标。 12 Agent 工程（十二）：记忆应统一接口，而不是统一存储 工作、情景、语义和程序记忆具有不同生命周期与检索方式；统一召回接口可以降低使用成本，但不应抹平存储差异。 13 Agent 工程（十三）：用故障合同比较 Agent 架构 功能清单只能说明系统具有什么，故障场景才能说明架构是否可靠。用四个生产问题比较两类 Agent 架构，并给出我的演进判断。 14 Agent 工程（十四）：Harness 是逻辑架构，不是部署单元 Harness 描述围绕 Agent Loop 的职责和合同，不规定部署拓扑；Runtime、Memory、Tool、Sandbox 与状态服务可以独立演化。 15 Agent 工程（十五）：恢复旧 Run 前必须固定执行合同 Checkpoint 只记录执行位置；跨版本恢复还需要不可变的 AgentVersion、完整的 RunRecord、显式 Migration 与副作用 Reconcile。 16 Agent 工程（十六）：多副本执行需要四种秩序标识 消息重复、状态乱序、旧 Owner 回写与稀缺资源重复分配是四类故障，必须分别使用 event_id、status_version、owner_epoch 和 Resource Token。
AgentScope 源码调研
沿着 AgentScope 源码分析服务端会话、工具执行与模型协议适配等关键模块，关注实现证据、职责边界，以及可以迁移到其他 Agent 系统的工程判断。
共 12 篇
01 AgentScope 源码调研（一）：Session 为什么不能依赖原进程 服务端会话要跨重启、跨副本继续运行，必须把状态、工作区和唤醒机制移出进程。本文从 AgentScope 源码提炼这条边界。 02 AgentScope 源码调研（二）：工具 Schema 为什么不是执行边界 AgentScope 用 Schema 向模型描述工具，却由函数签名、状态注入和执行器决定真实行为；两层不能合并判断。 03 AgentScope 源码调研（三）：Formatter 稳定的是内部消息语义 AgentScope 先统一 Msg 与 ContentBlock，再由 Formatter 适配模型协议；抽象价值在于阻止供应商差异进入 Agent Loop。 04 AgentScope 源码调研（四）：锁只决定谁能执行 Session Lock 回收执行资格，Checkpoint 保存停留位置，Tool 状态说明外部动作进度；三者共同决定恢复路径。 05 AgentScope 源码调研（五）：Event 如何归并为可恢复消息 AgentScope 先把流式 Event 归并到稳定 AssistantMsg，再发布与持久化快照，使刷新和同轮恢复不必重放完整事件。 06 AgentScope 源码调研（六）：Session 与 Message 为什么分开存储 Session 是当前状态快照，Message 是按会话增长的有序集合；StorageBase 统一业务语义，但不抹平数据模型差异。 07 AgentScope 源码调研（七）：锁之外还需要可验证的执行所有权 Session Lock 控制准入，但旧 Worker 恢复后仍可能写入；Owner Epoch 与 Store Fence 才能让各写入面拒绝过期执行者。 08 AgentScope 源码调研（八）：SSE 重连只恢复观察 浏览器断线不应重新运行 Agent；共享事件流、单调游标和消息快照共同恢复客户端观察位置。 09 AgentScope 源码调研（九）：工具可见不等于执行授权 Tool Visibility 只限制模型候选动作；可信执行还需要 Policy、HITL、受控 Executor 与独立 Verifier。 10 AgentScope 源码调研（十）：Memory 不等于历史消息 AgentState 保持当前执行连续，Long-term Memory Middleware 跨会话检索与写回；两者生命周期和治理要求不同。 11 AgentScope 源码调研（十一）：Memory 不能由模型直接判定生效 模型可以从对话中提取记忆候选，但来源、可信度、作用域和有效期必须由确定性 Policy 裁决。 12 AgentScope 源码调研（十二）：Memory 召回先做权限过滤 向量分数只表示语义相关；Memory 检索必须先限定租户与用户，再判断可信度、有效期和本轮使用价值。
Agent Sandbox 工程实践
从状态收敛、动作恢复、隔离选型与冷启动优化出发，分析 Agent Sandbox 控制面如何把底层机制组织成可恢复、可运营的平台能力。
共 5 篇
01 Agent Sandbox 工程实践（一）：Sandbox 消失后为什么不能直接重建 控制面看到 Sandbox 不存在时，仍需结合任务与外部动作状态判断恢复、失败还是等待确认。资源存在性不能替代业务语义。 02 Agent Sandbox 工程实践（二）：创建成功必须拆成四个边界 从业务请求到 Pod 与 execd，创建链路经历多次语义转换；Accepted、Provisioned、Connected 和 Agent Ready 不能共用一个成功状态。 03 Agent Sandbox 工程实践（三）：总创建耗时无法定位性能问题 Ready Latency 只能描述用户等待，必须拆分队列、资源创建、调度、容器启动和健康检查，才能形成可治理 SLO。 04 Agent Sandbox 工程实践（四）：Command 超时不等于 Sandbox 回收 Command timeout 只应终止本次执行的进程集合；Sandbox 回收处理整个运行载体，PID 1 则负责容器内的进程生命周期。 05 Agent Sandbox 工程实践（五）：进程终止不等于文件回滚 Signal 只能终止进程，不能撤销已经发生的文件写入；可恢复的 Sandbox 必须同时设计写入提交协议、挂载边界与完整性校验。