当前位置：首页 > news >正文

Agent运行时基础设施：会话、执行器与沙箱的三层解耦

news 2026/6/25 15:08:56

1. 这不是新赛道，而是基础设施层的“操作系统时刻”

上周二，Anthropic正式开放了Claude Managed Agents的公测。新闻稿里写得漂亮：十倍提速、Notion和Asana已接入、沙箱执行、会话快照、凭证托管——一整套面向开发者的“开箱即用”能力。技术博客里更进一步，把这套架构比作90年代操作系统的诞生：会话（Session）是持久化事件日志，脱离模型上下文独立存在；执行器（Harness）是无状态的轻量调用层，只负责发execute(name, input)并收字符串；沙箱（Sandbox）是按需拉起、用完即焚的“牛”，而非需要精心养护的“宠物”。实测数据也扎实：p50首token延迟下降约60%，p95稳定性优于90%。

但如果你真在去年亲手搭过一个跑四五十分钟的多步检索型Agent，你看到“session-as-event-log”这七个字时，手指会下意识停顿半秒——不是因为惊艳，而是因为太熟悉那种窒息感。我们当时把所有中间结果、工具返回、用户反馈全塞进模型上下文里滚动维护。第38分钟，上下文撞上窗口上限，模型没报错，也没中断，它只是悄悄抹掉了最早调用的三个API响应，然后基于残缺记忆开始编造后续步骤。整个会话没崩溃，却彻底失真。更糟的是，没有日志、没有回放、没有断点续传。你只能看着监控面板上一条平滑下降的token消耗曲线，默默重启任务，再花40分钟重走一遍老路。

Anthropic这次做的，本质上就是把我们团队那周连夜重写的外部状态层，封装成YAML可配、API可调、计费可拆的托管服务。它不解决“Agent该做什么”，只确保“做过的每一步都留痕、能追溯、可恢复”。这不是从零发明轮子，而是把行业里反复踩坑后形成的共识工程化、产品化。它背后真正值得细品的，是那个被反复验证却极少被公开讨论的底层事实：当Agent运行时间超过20分钟、工具调用超过5次、上下文交互超过10轮时，“把状态塞进prompt”这个做法，就从权宜之计变成了系统性风险源。Anthropic没创造新范式，它只是把大家心照不宣的“正确答案”，做成了一件可购买、可集成、可审计的商品。

提示：别被“Managed Agents”这个名称带偏。它不是另一个LLM应用框架，也不是升级版的LangChain。它是运行时基础设施（Runtime Infrastructure）——就像Linux内核之于应用程序，Kubernetes之于微服务。你不会说“我用Linux写了个CRM”，同样，未来也不会有公司宣称“我们基于Managed Agents构建了智能客服”。它会像数据库连接池或HTTP网关一样，沉默地嵌在技术栈底部，只在它失效时才被感知。

这个判断的关键依据，藏在定价模型里：$0.08/小时的活跃会话时长费，叠加标准Claude token费用。注意，是“活跃会话时长”，不是“调用次数”，不是“token数”，而是“这个会话实例在内存中保持可响应状态的时间”。这意味着Anthropic在赌两件事：第一，长时序Agent将成为主流工作流（否则没人愿为闲置会话付费）；第二，状态持久化与隔离的成本，必须由使用者按实际占用分摊（否则无法覆盖沙箱生命周期管理的开销）。这个定价本身，就是对行业演进节奏最诚实的投票。

2. 架构解剖：三层分离如何终结“上下文暴政”

Anthropic的架构文档里反复强调“decoupling”，但这个词容易被理解成抽象概念。实际上，它对应着三个具体、可触摸、且彼此物理隔离的组件。我把它们拆开揉碎，结合我们团队去年重构时的真实代码片段，告诉你每一层到底在解决什么问题、为什么非这样不可。

2.1 Session层：从“内存快照”到“事件数据库”

传统Agent框架里，Session本质是内存里的一个Python dict或JSON对象，里面存着history: [...], tools_used: [...], user_context: {...}。每次模型推理前，框架把它序列化成prompt的一部分；每次工具调用后，再反序列化更新。这种设计在单轮问答中毫无问题，但一旦进入多跳任务，就会暴露三个致命缺陷：

容量硬顶：Claude 3.5 Sonnet上下文窗口是200K tokens，但实际可用空间远小于此。光是系统提示+历史对话+工具描述就可能吃掉120K，留给中间结果的空间不足80K。而一次SQL查询返回的表格数据，轻松突破50K tokens。
更新成本高：每次工具调用后，框架必须重新拼接整个prompt，包括所有历史消息、当前工具结果、新的系统指令。这个过程CPU密集，且随历史长度线性增长。我们实测过，当history超过150条消息时，拼接耗时从20ms飙升至320ms。
不可审计：所有状态变更都发生在内存里，没有原子性记录。如果某次工具调用失败，你无法知道是网络超时、凭证错误，还是模型误判了调用参数——因为失败前后的state快照根本没被保存。

Managed Agents的Session层彻底绕开了这些问题。它把每一次状态变更，都转化为一条结构化事件（Event），写入外部持久化存储（据内部技术分享，底层是经过定制的TimescaleDB，支持毫秒级时间范围查询）。每条Event包含：

event_id: UUID
session_id: 全局唯一会话标识
timestamp: 精确到微秒的时间戳
event_type: "tool_call_start", "tool_call_success", "model_output", "user_input", "guardrail_violation"等
payload: JSON格式有效载荷，如工具调用参数、返回结果摘要、模型输出token数等

关键在于，模型推理时，Harness层只向Session层发起一个轻量查询：get_events_since(session_id, last_checkpoint_timestamp)。这个查询返回的不是原始数据，而是经过压缩的事件摘要流（例如，对一次10MB的API响应，只返回{"tool": "search_docs", "result_size_bytes": 10485760, "summary": "Found 3 relevant PDFs..."}）。模型看到的永远是可控大小的上下文，而完整数据躺在数据库里，随时可查、可导出、可分析。

注意：这个设计直接导致了一个反直觉结论——Managed Agents的“上下文窗口利用率”反而比自建方案更低。因为我们不再需要把原始数据塞进去，只保留决策线索。实测显示，在同等复杂度任务下，Managed Agents的平均prompt长度比我们旧方案减少63%，这正是性能提升的核心来源。

2.2 Harness层：无状态执行器的“冷启动”哲学

Harness是整个架构里最反常识的一环。它被定义为“stateless executor”，意思是它自身不持有任何会话状态，甚至不缓存模型权重。每次收到execute(name, input)请求，它只做三件事：

从Session层拉取最新事件摘要；
加载指定版本的Claude模型（通过Anthropic私有镜像仓库）；
执行一次完整的推理循环，生成工具调用指令或最终回复。

这个设计牺牲了“热加载”带来的毫秒级延迟优势，却换来了四个关键收益：

故障隔离：Harness进程崩溃？没关系。下一个请求会触发全新进程启动，awake(sessionId)自动从Session层恢复上下文。我们旧系统曾因一次内存泄漏导致整个Agent服务不可用，而Managed Agents的Harness崩溃只会让单个会话暂停几秒。
版本灰度：你可以为不同session_id配置不同的Claude版本（如claude-3-5-sonnet-20241022vsclaude-3-5-sonnet-20241215），无需重启服务。这对A/B测试模型迭代效果至关重要。
资源弹性：Harness不绑定CPU核心。当会话并发量激增时，Anthropic后台自动扩缩容Harness实例，而你的代码逻辑完全无感。
安全边界：Harness进程启动时，只获得最小权限的临时令牌（JWT），用于访问Session层和沙箱调度API。它永远无法读取你的AWS密钥或数据库密码——那些东西只存在于Credential Vault里，且只在沙箱启动时单向注入。

我们曾尝试在自建系统里模拟Harness的无状态性，但很快发现代价巨大：每次推理都要加载20GB模型权重，冷启动耗时超过8秒。Anthropic的解决方案是预热+分片：他们的GPU集群常驻着多个模型分片（shard），Harness只需加载对应分片的轻量路由模块，真正的权重加载由专用推理服务完成。这解释了为什么他们敢承诺p95稳定性——底层是硬件级的冗余设计，而非软件层的妥协。

2.3 Sandbox层：“沙箱即牲畜”的运维革命

“Sandbox as cattle, not pets”这句话在技术圈流传已久，但真正落地的不多。Managed Agents的沙箱实现，把这句话变成了可量化的SLA：每个沙箱生命周期严格控制在15分钟以内，无论是否活跃。超时后，整个容器被强制销毁，磁盘被覆写，内存被清空。下次需要时，从干净镜像重新拉起。

这个看似激进的设计，解决了生产环境里最棘手的三个问题：

凭证泄露防护：沙箱启动时，Credential Vault会生成一次性、短时效（默认5分钟）、限域（仅允许访问指定S3 bucket）的临时凭证，并通过安全通道注入容器。模型永远看不到明文密钥，沙箱内任何进程也无法将凭证导出到外部。我们旧系统曾因一个调试日志打印了环境变量，导致测试环境密钥意外上传到GitHub。
资源争抢隔离：每个沙箱独占CPU核、内存页、网络端口。一次失控的while True: time.sleep(0.1)循环，只会拖垮单个沙箱，绝不会影响其他会话。这让我们敢于在同一个Agent里并行执行10个不同工具调用，而不用担心某个慢查询拖垮整个服务。
依赖冲突消解：不同客户、不同Agent可以使用完全冲突的Python包版本（如pandas==1.5.3vspandas==2.2.0）。沙箱镜像里固化了所有依赖，启动即锁定。我们曾为兼容一个老版金融计算库，不得不给整个Agent服务降级NumPy，而Managed Agents允许每个工具调用使用独立环境。

实操心得：不要试图在沙箱里做“长期任务”。它的设计哲学是“快进快出”。如果你需要处理一个耗时30分钟的视频转码，正确做法是：Harness调用沙箱执行start_transcode_job(video_url)，沙箱立即返回job_id；Harness将job_id写入Session事件；后续由独立的异步Worker监听Session事件，轮询job状态并写回。沙箱只负责“发起”，不负责“等待”。

3. 实操落地：从YAML定义到生产部署的完整链路

理论讲完，现在进入最硬核的部分：如何真正用起来？我以一个真实的销售线索评分Agent为例，带你走完从零到上线的每一步。这个Agent需要：1）从Salesforce拉取新线索；2）调用Clearbit API enrich公司信息；3）用Claude分析官网内容并打分；4）将结果写回Salesforce。整个流程平均耗时18分钟，峰值上下文达140K tokens。

3.1 Agent定义：YAML不是配置，而是契约

Managed Agents要求你用YAML定义Agent行为，这看起来像配置文件，实则是与Anthropic平台签订的“执行契约”。以下是我们为销售线索Agent编写的sales-qualifier.yaml核心片段：

# sales-qualifier.yaml name: "sales-qualifier-v2" description: "Scores new leads based on firmographic and web content analysis" system_prompt: | You are a senior sales development representative at Acme Corp. Your task is to score leads on a scale of 1-100 based on: - Company size (from Clearbit data) - Technology stack (from website analysis) - Content relevance (does their blog mention our keywords?) Always output JSON with keys: score, confidence, reasoning, next_steps. tools: - name: "fetch_salesforce_leads" description: "Fetches unqualified leads from Salesforce, returns lead_id, company_name, website" input_schema: type: "object" properties: limit: type: "integer" default: 5 credential: "salesforce_prod" sandbox: image: "acme/sf-connector:1.2" timeout_seconds: 30 - name: "enrich_company" description: "Calls Clearbit API to get company details" input_schema: type: "object" properties: domain: type: "string" credential: "clearbit_api_key" sandbox: image: "acme/clearbit-enricher:0.9" timeout_seconds: 45 - name: "analyze_website" description: "Downloads homepage, extracts text, analyzes for tech keywords" input_schema: type: "object" properties: url: type: "string" credential: "none" # No credentials needed for public web scraping sandbox: image: "acme/web-analyzer:2.1" timeout_seconds: 120 guardrails: - type: "output_format" config: schema: | { "score": {"type": "integer", "minimum": 1, "maximum": 100}, "confidence": {"type": "number", "minimum": 0.0, "maximum": 1.0}, "reasoning": {"type": "string"}, "next_steps": {"type": "array", "items": {"type": "string"}} } - type: "content_filter" config: blocked_categories: ["hate_speech", "violence", "adult_content"] runtime: max_session_duration_hours: 2 checkpoint_interval_minutes: 5

这个YAML文件里藏着几个关键设计决策：

credential字段不是密钥，而是Vault别名：salesforce_prod指向Credential Vault里一个名为salesforce_prod的凭证集，包含OAuth token、instance URL等。Anthropic平台在沙箱启动时，自动将这些凭证注入容器，且注入后立即从内存中擦除。
sandbox.image是Docker镜像URI：我们提前将所有工具依赖打包成轻量镜像（acme/sf-connector:1.2只有83MB，不含Python runtime，只含Salesforce SDK和必要证书）。镜像推送到Anthropic私有Registry后，YAML里直接引用。
timeout_seconds是沙箱级超时：不同于HTTP超时，这是容器进程的硬性截止时间。超时后，Anthropic强制发送SIGKILL，确保不会出现“僵尸沙箱”。
checkpoint_interval_minutes定义了事件快照频率：每5分钟，Harness自动将当前Session状态写入事件日志。这保证了即使发生意外中断，最多丢失5分钟进度。

提示：YAML里的system_prompt长度建议控制在2000字符以内。过长的系统提示会挤占事件摘要空间。把业务规则细节（如“科技栈匹配度权重占40%”）写进Guardrail或工具代码里，而非Prompt。

3.2 本地开发与沙箱调试：告别“黑盒式”调试

Managed Agents最大的体验升级，是提供了完整的本地沙箱调试能力。你不需要等部署到Anthropic平台才能验证工具逻辑。Anthropic CLI工具链支持：

沙箱镜像本地运行：

# 在本地启动一个与生产环境完全一致的沙箱 anthropic sandbox run --image acme/sf-connector:1.2 \ --env SF_INSTANCE_URL=https://acme.my.salesforce.com \ --env SF_ACCESS_TOKEN=xxx \ --input '{"limit": 3}'

这会启动一个Docker容器，执行你的工具代码，并输出JSON结果。所有环境变量、输入格式、超时机制都与线上一致。

事件日志本地回放：

# 导出线上某个会话的事件流，供本地分析 anthropic session export --session-id sess_abc123 > /tmp/sess_abc123.jsonl # 用Python脚本逐条解析事件，定位问题 python analyze_events.py /tmp/sess_abc123.jsonl

Harness模拟器：
```
# 模拟Harness调用流程，不启动真实模型 anthropic harness simulate \ --agent-yaml sales-qualifier.yaml \ --session-id sess_dev_test \ --mock-model-output '{"score": 87, "confidence": 0.92}'
```
这个命令会模拟整个Harness生命周期：拉取事件、加载工具、调用沙箱、写入新事件，但跳过实际模型推理，用你提供的Mock输出替代。这是单元测试的最佳搭档。

我们团队现在的工作流是：所有工具代码先在本地沙箱验证→用Harness模拟器测试多步流程→最后才提交YAML到Anthropic平台。这个流程把90%的bug拦截在本地，上线成功率从过去的65%提升到98%。

3.3 生产部署与监控：从“看日志”到“看事件流”

部署到生产环境只需一行命令：

anthropic agent deploy --yaml sales-qualifier.yaml --environment prod

但真正的挑战在部署之后。Managed Agents的监控体系彻底重构了我们的可观测性实践：

会话健康度看板：不再盯着CPU、内存、HTTP 5xx，而是看三个核心指标：
- session_p95_duration_minutes：95%的会话完成时间。我们设定告警阈值为25分钟（业务SLA是20分钟）。
- sandbox_failure_rate_percent：沙箱启动失败率。超过0.5%即告警，通常意味着镜像拉取失败或凭证配置错误。
- guardrail_violation_rate_percent：Guardrail触发率。持续高于5%说明系统提示或Guardrail配置需要优化。
事件流钻取：点击任意会话ID，进入时间轴视图。你能看到：
- 每个事件的精确时间戳（微秒级）
- 事件类型图标（蓝色=工具调用，绿色=模型输出，红色=Guardrail触发）
- 点击事件可展开完整payload，包括沙箱stdout/stderr
- 可对比两个会话的事件流，快速定位差异（如A会话在enrich_company后触发了content_filter，B会话没有）
凭证审计追踪：Credential Vault提供完整审计日志，记录每次凭证注入的时间、沙箱ID、调用工具名。当安全团队问“Clearbit密钥最近一次被谁在什么场景下使用”，你能在3秒内给出答案。

实操心得：不要依赖“模型输出是否成功”来判断会话健康。我们曾遇到一个案例：模型输出JSON格式正确，但score字段始终为0。排查发现是analyze_website沙箱的robots.txt解析逻辑有bug，导致官网文本提取为空，模型基于空内容打分。事件流里清晰显示了enrich_company成功（返回了公司规模），但analyze_website返回了空字符串，这才是根因。事件流让你从“结果导向”转向“过程导向”调试。

4. 竞争格局与生存策略：为什么Runtime层注定走向“零价化”

Anthropic的Managed Agents发布当天，我同步打开了AWS、Google Cloud和Azure的控制台。这个动作不是为了比较功能，而是确认一个预判：这不是一场新品发布会，而是一场基础设施层的“价格战”前哨战。让我们把镜头拉远，看看整个Agent Runtime市场的地形图。

4.1 三大云厂商的“免费捆绑”攻势

AWS Bedrock AgentCore：2025年11月GA，比Anthropic早5个月。其核心策略是“深度捆绑”：AgentCore不单独计费，而是作为Bedrock模型调用的免费附加服务。你每调用1M tokens的Claude，就自动获得1小时的AgentCore会话时长。更狠的是，它支持在同一个会话里混合调用Claude、Llama 3、Cohere——只要你用Bedrock的统一API。这意味着，一个正在评估多模型的客户，天然倾向选择AgentCore，因为切换成本为零。
Google Vertex AI Agent Builder：2026年1月GA，主打“企业级治理”。它把Agent注册中心（Agent Registry）直接集成到Apigee API网关里。每个Agent发布即生成标准REST API，自动继承Apigee的流量控制、配额管理、审计日志。对于已有Apigee采购的企业，AgentBuilder的边际成本近乎为零。
Azure AI Foundry：2026年2月GA，走“生态整合”路线。它原生支持AutoGen、Semantic Kernel、LangChain三种框架，且允许开发者将本地训练的微调模型（如LoRA适配器）直接挂载为Agent工具。微软把AI Foundry包装成“Azure AI Stack”的一部分，客户采购Azure OpenAI服务时，Foundry自动激活。

这三家的共同点是什么？它们都不靠Runtime本身赚钱，而是把它当作云服务的“钩子”（Hook）。AWS用它拉动Bedrock用量，Google用它巩固Apigee护城河，微软用它加速Azure AI adoption。它们的定价模型只有一个隐含公式：Runtime Cost = 0 - (Cloud Spend You're Already Making)。

提示：Anthropic的$0.08/小时定价，在小规模POC阶段很有竞争力。但当你的月会话时长达到10万小时（相当于50个并发Agent持续运行24/7），年成本是$96,000。而同等规模下，AWS AgentCore的实际成本是$0（因为你已为Bedrock支付了足够多的token费用），Google和Azure也类似。这就是为什么文章标题说“Layer That’s Already Going to Zero”——不是指价格归零，而是指其独立商业价值正被云厂商的综合账单吞噬。

4.2 开源势力的“性能碾压”与“协议争夺”

如果说云厂商在打“价格战”，开源社区就在打“性能战”和“标准战”。2025年Q4以来，两个项目突然加速：

Daytona Agent Runtime：由前VS Code团队工程师创立，2025年2月宣布转型AI Agent基础设施。其核心创新是“Sub-millisecond Sandbox Spin-up”——利用eBPF和轻量级unikernel技术，将沙箱启动时间压到87ms。这意味着，一个需要调用10个工具的Agent，总沙箱开销从传统方案的3-5秒，降到不到1秒。2026年2月，它完成2400万美元A轮融资，估值达1.2亿美元。
Kubernetes SIG Agent-Sandbox：2025年12月，K8s官方SIG（Special Interest Group）正式发布agent-sandbox项目。它不是一个完整Runtime，而是一套CRD（Custom Resource Definition）和Operator，让你能在现有K8s集群上声明式地管理Agent沙箱。它不绑定任何模型，不提供Session层，只做一件事：安全、可靠、可审计地运行沙箱。这等于把Runtime的“底盘”标准化了。

这两股力量正在形成合力：Daytona提供极致性能的沙箱实现，K8s SIG提供跨云、跨厂商的部署标准。它们共同的目标，是让Agent Runtime变成像kubectl一样的基础设施——你不会为kubectl付费，但你会为运行它的云资源付费。

4.3 生存指南：避开“Runtime陷阱”，抢占“上层价值”

面对这场注定 commoditize 的基础设施战争，创业者和工程师的破局点在哪里？我的经验是，死死盯住三个“Runtime之上”的价值洼地：

4.3.1 Trace Store：谁掌握事件流，谁就掌握Agent的“司法证据”

当Agent能自主调用API、修改数据库、发送邮件时，它的每一次操作都可能产生法律效力。一个销售Agent误将“拒绝合作”标记为“高意向”，导致销售团队浪费两周跟进，责任在谁？是模型？是Prompt？还是沙箱里的工具代码？

目前，所有Runtime（包括Managed Agents）都生成事件流，但没有一个平台提供跨Runtime的Trace Portability。你从Anthropic迁移到AWS，事件格式、字段语义、时间戳精度全都不一样。Braintrust、Arize、LangSmith这三家观测平台，正在疯狂争夺这个“司法证据库”的标准制定权。

Brainstore（Braintrust）：专为AI事件设计的OLAP数据库，支持PB级日志的亚秒级聚合查询。它的杀手锏是event_diff()函数，能一键对比两个会话的事件流差异。
Phoenix（Arize）：Apache 2.0开源，提供免费的事件存储和基础分析。它的商业版卖的是“合规报告生成器”，能自动生成符合SOC2、HIPAA要求的审计报告。
LangSmith：LangChain生态的“默认选项”。它不追求性能，但胜在无缝集成——只要你的Agent用LangChain写，LangSmith就能自动捕获所有事件，无需额外埋点。

实操心得：在项目启动第一天，就把Trace Store接入进来。我们用LangSmith作为默认采集器，同时将关键事件（如tool_call_success）双写到自建PostgreSQL。这样既享受生态便利，又保有数据主权。当某天需要向法务部门证明“Agent从未访问过用户身份证号”，你能在5分钟内导出完整证据链。

4.3.2 Governance Layer：从“技术护栏”到“采购审批清单”

企业采购不会为“沙箱启动快”买单，但会为“这个Agent能做什么、谁批准了、出了问题怎么追责”付费。OWASP Agentic Top 10的发布，标志着Agentic Security正式进入企业采购流程。

Policy-as-Code：AWS AgentCore的Policy Controls GA，允许你用YAML定义：“禁止Agent调用任何DELETEHTTP方法”、“禁止访问prod-db以外的数据库”、“所有send_email调用必须包含approval_required: true字段”。这不再是代码里的if-else，而是可版本控制、可审计、可纳入CI/CD的策略。
Approval Workflow：Salesforce Agentforce的ARR爆发式增长，核心在于它把Agent和Salesforce的Approval Process深度绑定。一个财务Agent要发起付款，必须先触发Salesforce审批流，经CFO批准后，Agent才获得临时支付令牌。这把技术决策变成了组织流程。
Risk Scoring：新兴的Governance平台（如Giskard）开始提供“Agent Risk Score”，基于事件流实时计算：调用敏感API的频率、修改生产数据的次数、Guardrail触发率等，生成一个0-100的风险分。采购部门可以直接把这个分数写进SLA。

4.3.3 Vertical Marketplaces：当Agent变成“可采购的SaaS”

最后，也是最确定的趋势：企业愿意为垂直场景的Agent付费，而不是为通用Runtime付费。Salesforce Agentforce的8亿美元ARR，不是来自卖“Agent Builder”，而是来自卖“Sales Development Agent”、“Contract Review Agent”、“Lead Scoring Agent”这些打包好的、开箱即用的垂直Agent。

这些垂直Agent的成功要素很清晰：