[Feature]: 为 Local Agent 引入沙箱执行环境，隔离 Agent 代码执行权限

[huanghuoguoguo]

背景

这个 issue 只聚焦一件事：当 LangBot 允许 agent 执行代码时，这个执行能力不应该直接落在宿主机上，而应该被放进一个真正的沙箱里。

当前 LangBot 对“可执行扩展”的信任边界，实际上可以分成三层：

1. LangBot 核心代码：由项目维护者控制，默认可信
2. 插件：有上架、审核、生态约束，属于半可信扩展
3. agent 生成并执行的本地代码：默认不可信

这里讨论的重点是第三层。

当 local agent 获得更强的工具能力后，它很自然会出现下面这些行为：

• 生成 Bash / Python / Node 代码
• 把代码写入工作目录后执行
• 安装依赖、下载数据、运行测试
• 多轮迭代地修改代码并再次执行

从产品能力上看，这些能力很有价值；但从执行模型上看，这类代码本质上属于 不可信代码执行。

如果继续沿用普通子进程模型直接在宿主机执行，就意味着：

• agent 生成的代码默认继承宿主机文件系统可见性
• agent 生成的代码默认继承宿主机环境变量与凭证可见性
• 网络访问、资源占用、工作目录访问边界都不清晰
• 一旦 agent 误操作或生成危险命令，风险会直接落到运行 LangBot 的机器上

这不是“权限提示是否友好”的问题，而是 执行边界本身缺失 的问题。

为什么需要沙箱

如果 LangBot 要赋予 agent 执行代码的能力，那么就需要同时赋予系统一个清晰的能力边界：

• agent 可以执行代码
• 但代码只能在受限环境里执行
• 不能直接获得宿主机权限

也就是说，这里的核心诉求不是“让 agent 能执行更多代码”，而是：

让 agent 的代码执行能力，天然带着隔离、限制和可观测性。

引入沙箱的价值主要在于：

• 隔离宿主机：避免 agent 生成的代码直接接触 LangBot 主进程所在环境
• 限制权限：把文件系统、网络、环境变量、资源使用都收进明确边界
• 降低风险：把错误命令、恶意命令、异常依赖安装的影响控制在沙箱内
• 统一执行模型：以后凡是 agent 驱动的本地代码执行，都通过同一个受限入口
• 提升可观测性：退出码、日志、超时、资源超限都能被系统感知和处理

这个 issue 关注什么

这个 issue 不讨论 marketplace、Skill 规范、MCP 适配或多代理编排，也不讨论产品路线拆分。

这里只讨论一个明确目标：

为 Local Agent 引入一个真正的沙箱执行环境，使 agent 执行代码时不再直接运行在宿主机上。

更具体一点，可以理解成：

• LangBot 可以向 agent 暴露一个受限的代码执行工具
• agent 发起的 Bash / Python / Node 执行都必须走沙箱
• 代码写入、命令执行、依赖安装、运行测试等操作都发生在沙箱内
• 当沙箱不可用时，系统应拒绝执行，而不是静默回退到宿主机

设计原则

如果要把这件事做好，至少需要满足这些原则：

• 默认拒绝：文件、网络、环境变量、资源都按最小权限放行
• 统一入口：agent 的本地代码执行必须统一经过沙箱
• fail closed：沙箱不可用时拒绝执行，不回退到宿主机
• 执行可观测：日志、退出码、超时、资源限制命中都可以被 LangBot 感知
• 错误可理解：不能把底层运行时原始错误直接抛给用户或 LLM
• 请求隔离：不同请求的执行环境默认隔离，避免相互污染

为什么这件事值得单独立项

因为一旦 agent 被赋予代码执行能力，这就不再只是“工具调用增强”，而是 LangBot 正式进入了 本地不可信代码执行 的问题域。

这类问题如果一开始没有明确沙箱边界，后面通常只会不断追加补丁：

• 某个命令太危险，补一个黑名单
• 某个目录不该访问，再补一个路径限制
• 某次依赖安装影响宿主环境，再补一个临时规约

这种做法短期看起来快，长期通常会把执行模型做成一组零散补丁，而不是清晰边界。

因此，这个 issue 的核心判断是：

如果要给 agent 执行代码的权力，就应该同时给它一个真正的沙箱。

结论

建议为 Local Agent 引入独立的沙箱执行环境，让 agent 的代码执行能力天然运行在隔离边界内，而不是直接落到宿主机。

这件事本质上是在补 LangBot 的执行安全边界，不是锦上添花，而是 agent 代码执行能力走向可用之前必须正视的问题。