小议 agent Harness 设计上的 tradeoff
内容提要
文章探讨了Agent架构从编码场景向通用工作场景演进的趋势，认为基于沙箱的“Agent in the sandbox”设计将被淘汰，未来应转向服务端多租户的“Server side agent”架构。文章分析了Anthropic提出的Session、Tools、Sandbox和Orchestration四层抽象，并讨论了轻量级Runtime替代完整Linux系统、Session状态管理、上下文工程及离线评估等关键挑战。
延伸解读
从“宠物”到“牲畜”：架构演进的必然性
文章借用Anthropic的“宠物vs牲畜”比喻，指出将整个Agent运行环境绑定在单一容器中的设计（Agent in the sandbox）存在致命缺陷：容器故障会导致会话丢失，且难以调试。随着Agent从编码走向通用工作场景，这种为单用户设计的架构将无法满足多租户、高可用和可维护性的需求，因此向服务端多租户架构演进成为必然。
轻量级Runtime：替代完整Linux的探索
文章提出一个关键观察：大多数对沙箱的调用并不需要完整的Linux系统。因此，可以在沙箱之上提供更轻量的JS runtime来处理常见请求，仅在必要时回退到完整的microvm。更激进的设计甚至可以直接去掉操作系统VM，因为JS在多数场景下能替代Bash，且生态丰富。这一思路有助于降低资源消耗、提升响应速度，但需权衡模型对Bash的熟练度与JS的适用性。
Session管理的复杂性：上下文工程是核心
Session是服务端Agent最复杂的部分，涉及多租户状态管理。文章以Codex的上下文管理为例，说明其通过注册大量工具（如history、notes）和system reminder机制，实现动态策略选择。然而，不同模型对system reminder的支持存在差异，甚至同一模型不同版本也有变化，这增加了切换模型时的工程复杂度。因此，将Session与其他模块彻底解耦可能为时过早，应用开发者需谨慎设计。
离线评估的挑战：多租户下的可复现性
在Agent in the sandbox设计中，评估相对容易，因为Agent可独立运行在沙箱中。但转向服务端多租户架构后，如何保证评估环境与线上一致、工具调用可复现且可重复执行，成为设计难点。这要求合理的抽象与设计，以支持离线自动化评估，否则难以验证Agent在真实场景中的表现。
Q&A
Agent架构从编码场景向通用工作场景演进时，为什么说基于沙箱的“Agent in the sandbox”设计会被淘汰？
因为这种设计将每个用户会话绑定在一个独立的容器中，导致基础设施上的“宠物”问题：容器故障会导致会话丢失，且难以调试。此外，通用工作场景需要支持多租户和云端执行，而沙箱设计无法满足这些需求。
Anthropic提出的Agent架构四层抽象是什么？
Anthropic提出的四层抽象是：Session（会话）、Tools（工具，包括MCP）、Sandbox（沙箱）和Orchestration（编排）。
在Server side agent架构中，Sandbox的作用是什么？为什么说它可以是无状态的？
Sandbox被当作无状态的执行环境，所有状态都保存在Session中。如果用户请求不使用bash或python等工具，就不需要Sandbox。此外，大多数对Sandbox的调用不需要完整的Linux系统，可以用更轻量的JS runtime处理，只有必要时才回退到完整的microvm。
为什么说Session是Server side agent中最复杂的部分？
因为Session需要支持多租户的状态管理，而上下文工程是Agent唯一重要的事情，需要复杂的策略和实验。例如，compaction策略就很复杂，不同模型对system reminder的处理也有差异，切换模型时还需要考虑是否要切换机制，工程实现很复杂。
Agent in the sandbox和Server side agent在评估（evaluation）上有什么不同？
Agent in the sandbox中，Agent运行在独立沙箱中，评估相对容易，可以本地运行。而Server side agent自带多租户设计，需要保证评估对象与线上harness一致，并设计合理的抽象来支持离线自动化评估，且工具调用需在可复现环境中多次执行，这对设计提出了更高要求。
文章提到的更激进的Sandbox设计思路是什么？
更激进的设计是直接去掉完整的操作系统VM，只提供一个轻量的JS runtime。因为大多数bash对操作系统的操作，JS都可以做到，甚至可能做得更好，且JS生态丰富，模型对JS的训练也很充分。
