为什么 Pickel-Agent 迟早要认真做 Sandbox
从实验性 Demo 走向可复用的 Agent Runtime，并支持受控的工具演化与代码自修改，沙箱环境是能力成立的底层基础设施，而非外挂的安全装饰。
当 Agent 系统的目标从调用工具的原型验证，转向支持自演化与代码自修改的 Runtime 时，沙箱（Sandbox）不再是可有可无的安全护栏，而是系统能力成立的前提。
在 Pickel-Agent 早期探索阶段，隔离机制仅限于基础的路径访问限制与工具权限白名单。这种设计足以避免显式的误操作，但在本质上仍未构建起真正隔离的系统边界。
在原型验证期，这种权衡是符合工程节奏的：过早引入严格的容器隔离、网络沙盒与凭证中介，会显著拖慢对核心机制（上下文组织、会话持久化、技能沉淀与调度逻辑）的迭代速度。
从本地原型走向 Agent Runtime
随着项目定位从本地实验脚本转向通用 Agent Runtime，系统边界问题开始成为首要约束。
作为 Runtime，系统需要提供标准化的 Agent 实例化接口与运行生命周期管理，必须明确回答以下工程问题：
- 实例默认暴露的系统调用与资源配额；
- Agent 与宿主操作系统之间的执行隔离度；
- 长期自治运行过程中的异常扩散半径；
- 实例故障后的上下文与环境回滚机制；
- 细粒度的权能（Authority）授予与审计模型。
在通用 Runtime 的视角下，隔离边界与状态管理构成了运行时的底层支柱。
超越外围增强：深入实现层的代码自修改
当前多数被称为“自进化”的 Agent，本质上停留在外围策略层：优化 System Prompt、沉淀使用偏好、归纳并注册新的 Skill 描述文件。这些增强并未触及系统底层的可执行代码结构。
更具实际潜力的方向是支持 Agent 在受控环境下修改自身的工具实现与运行时逻辑：
- 为 Agent 提供专用的代码修改与测试执行工具链；
- 赋予其独立的 Git 仓库与工作树（Worktree）分支管理权限；
- 允许在独立分支内修补工具定义、扩展运行时模块并运行回归测试；
- 通过外部 Supervisor 进程实现代码热重载或安全回退。
这种自修改能力使得 Agent 能够直接演化自身的能力结构，而非仅停留在提示词层面的经验记录。
权能中介与沙箱的本质
一旦系统涉及自身源码的修改与执行，系统风险将从“提示词越狱”直接上升为操作系统的不可逆破坏：源码被篡改、进程崩溃、凭证泄露或网络未授权写入。
此时，安全问题的本质在于权能（Authority）的组织与中介：
- 最小特权沙箱：将 Agent 运行在无特权的轻量容器或虚拟机（如 MicroVM）中，剥离直接访问宿主磁盘与本地网络的权限；
- 副作用中介代理：所有针对文件系统、外部 API、远程 Git 仓库的写入操作，均需通过宿主 Supervisor 的审计与门禁机制；
- 可销毁与可回滚环境：执行环境保持无状态或基于 Copy-on-Write 挂载，一旦测试失败或执行异常，可瞬间销毁并回滚至上一稳定快照。
沙箱的意义不仅是物理限制，而是为模型提供一个可以自由执行试错、具有确定边界与回滚能力的确定性空间。
总结
- 在原型验证阶段，延迟引入重度沙箱有利于快速探索核心机制；
- 当系统定位升级为 Runtime 并尝试触碰代码自修改时，隔离环境成为不可跳过的前提；
- 沙箱不只是防止恶意破坏的安全护栏，更是赋予 Agent 自主执行系统级变更、容忍错误尝试并确保可重现与可回滚的基础设施。