文章讨论了AI代理控制环(agent harness)的两种部署架构：在沙盒内运行或在沙盒外运行。作者指出这两种方式在安全性、故障模式和功能实现上存在差异，并强调多用户场景下的特殊挑战。文章倾向于支持将控制环置于沙盒外的方案，认为这更适合企业级多用户环境。

智能体控制框架应置于沙箱之外 | Mendral

作者：Andrea Luzzardi
发布日期：2026年4月10日
阅读时长：7分钟

核心观点

智能体控制框架（agent harness）是驱动大语言模型（LLM）运行的核心循环机制，负责提示发送、响应接收、工具调用及结果反馈等流程。文章探讨了该框架的两种部署架构及其优劣：

1. 沙箱内运行架构

• 控制循环与工作代码共处同一容器
• 工具调用（如bash、文件读写）在本地执行
• 适用于单用户场景（如开发者本地运行Claude Code）
• 优势：执行模型简单，可直接复用现有框架

2. 沙箱外运行架构

• 控制循环部署在后端服务器
• 通过API调用沙箱执行工具
• 适用于多用户协作场景（如团队共享智能体）
• 核心优势：
  • 凭证安全性：敏感信息（API密钥、数据库凭证）不进入沙箱
  • 资源动态管理：沙箱可随需启停，降低闲置成本
  • 故障恢复：沙箱崩溃不影响会话持续性
  • 多用户协同：通过数据库实现技能/记忆共享，避免分布式文件系统问题

关键技术解决方案

1. 持久化执行

• 采用Inngest框架实现长时间运行的会话状态保持
• 每个交互步骤设置检查点，支持服务重启后恢复

2. 沙箱生命周期管理

• 使用Blaxel技术实现25毫秒级快速唤醒
• 智能体闲置时自动挂起沙箱以节省资源

3. 虚拟化文件系统

• 通过路径路由机制（如/skills/、/memory/）实现透明化存储：
  • 工作区路径指向沙箱
  • 技能/记忆路径映射到Postgres数据库
• 保持LLM原有工具调用接口，避免模型适配问题

现存挑战

• bash工具逃逸：无法完全拦截通过bash直接访问虚拟路径的行为
• 一致性维护：多会话并发写入时采用"最后写入优先"策略，可能引发冲突
• 标准兼容性：需持续跟进Claude Code等参考实现的接口变更

作者背景

由Dagger和Docker前核心成员Sam Alba与Andrea Luzzardi创立，专注于构建自主诊断CI故障的AI运维团队解决方案。

（注：原文中的企业宣传内容、图片说明及页脚信息已根据主题相关性进行精简。）

以下是评论内容的总结，涵盖主要观点和论据：

1. 支持沙盒分层安全模型

部分评论认为需要多层沙盒来限制代理的不同行为，确保安全性。
- saltcured: "But shouldn't there really be another sandbox where the agentic tool calls execute? This is to contain the damage of the tool execution when it goes wrong."
- pamcake: "The agent harness needs different sandbox(es) with different privileges. Nothing here supports not containing its access."

2. 反对过度沙盒化，主张简化设计

另一部分观点认为过度沙盒化会限制代理的功能和效率，主张更简单的设计。
- trjordan: "The reason agents work is because they have access to stuff by default... I put the bare minimum into getting my dev instance into a state where I can develop."
- tptacek: "There are other models. Eschew the sandbox. Give the agent a computer, with all the trimmings, but keep that computer segregated from sensitive resources."

3. 对“harness”概念的争议

部分评论指出“harness”定义模糊，可能成为无实际意义的流行词。
- blcknight: "I am not sure anyone knows what a harness is at this point. I've heard 17 different definitions of it."
- jdw64: "Manus rebuilt its harness five times in six months... people have been trying to claim that concept."

4. 关于代理访问控制的讨论

评论中强调代理的访问控制是关键问题，需要明确权限范围。
- NJL3000: "What remains unsolved is what should an Agent reasonably have access to in what context and for how long."
- moron4hire: "The agent harness I’ve developed is incapable of accessing data its operator should not have... I just developed the same access controls I would have done for a human user."

5. 技术实现建议

部分评论提出具体的技术方案，如容器化、远程执行等。
- Koffiepoeder: "Basically a very dev-friendly, secure, 'kubernetes'-like solution for running remote agents."
- deevus: "I’ve been working on a sandboxing tool that uses Incus... The sandboxes created by MCP are generally ephemeral."

6. 对共享资源冲突的看法

部分评论认为共享资源冲突是设计问题，而非缺陷。
- vursekar: "Conflict resolution forces the need for a process to come to agreement on a common source of truth... Writing directly to a shared memory database seems like it would result in chaos."
- solidasparagus: "Why are two concurrent sessions updating the same memory key with different values? IMO it probably points to a fundamental flaw."

7. 对安全模型的质疑

部分评论认为当前的安全模型存在模糊性，需要更清晰的边界。
- MrDarcy: "If the harness is outside the sandbox then it’s just an ambiguous and confusing security model and boundary."
- zmmmmm: "I barely trust the harness more than the LLM... if your harness has an ability to do something the LLM can't, you have to assume the LLM will work out those conditions."

8. 对代理工具设计的批评

部分评论指出当前代理工具设计过于简单，缺乏细致的访问控制。
- moron4hire: "The idea of physically separating the agent harness and the artifacts... seems to be the wrong answer to the right problem."
- spankalee: "It's still assuming agents have CLIs. This is a very developer-centric concept of agents."

总结来看，评论围绕沙盒设计、代理访问控制、技术实现和安全模型展开，观点多样，既有支持分层安全的声音，也有主张简化设计的反对意见。同时，“harness”概念的模糊性和代理工具的设计问题也引发了广泛讨论。