1. 这不是新赛道，而是 runtime 层的“操作系统时刻”正在重演
我第一次在生产环境里跑一个需要连续交互 30 分钟以上的 AI agent，是在 2025 年初。当时用的是自建 LangGraph + FastAPI + Redis 状态后端的方案。系统上线第三天，销售团队反馈：一个客户资料自动归档流程，在执行到第 7 步时突然把前 4 步的结果全丢了，最后生成的 PDF 里连客户公司名都错了。我们翻日志、查 Redis、重放 trace——全无异常。直到我把整个 session 的 context token 数打出来，才发现：它在第 28 分钟时悄悄越过了 Claude-3.5-sonnet 的 200K 上限，模型没报错，只是默默截断了最老的 3 个 tool call 历史，然后基于残缺上下文继续推理。没有崩溃，没有告警，只有静默的失效。那一次，我们花了 17 小时重建状态层，把所有中间结果存进 PostgreSQL，用 event sourcing 模式重写 session 管理逻辑。
Anthropic 在 4 月 8 日发布的 Claude Managed Agents ，本质上就是把我们当年踩坑后连夜重写的那一整套 state management + sandbox isolation + credential vaulting + trace persistence，封装成一个开箱即用的托管服务。它不解决“agent 能不能思考”这个根本问题，它解决的是“agent 思考完之后，能不能活下来、被看见、不闯祸”。关键词不是“agent”，而是 Managed —— 管理态，是运行时基础设施的工业化表达。
你不需要懂 Kubernetes，也不用配置 Istio 的 mTLS；你只需要写一段 YAML，定义 system prompt、允许调用的 tools（比如 Notion API、Asana webhook）、以及几条 guardrails（比如“禁止访问 /admin 路径”、“输出必须含中文摘要”），Anthropic 就给你一个带持久化 session、隔离沙箱、自动凭证轮换、全链路可审计的运行环境。它的 p50 首 token 延迟下降 60%，p95 改善超 90%，这些数字背后不是模型变快了，而是 runtime 层去掉了所有“不该由模型承担的负担”：状态不再挤在 context window 里，工具调用不再裸奔在容器网络中，凭证不再以 env var 形式暴露给 LLM 的 prompt 工程师。
这和 1990 年代 Linux 内核把硬件抽象成统一的文件描述符（/dev/ttyS0, /dev/sda）一样，Anthropic 把 agent 生命周期抽象成了三个稳定接口： Session（事件日志） 、 Harness（无状态执行器） 、 Sandbox（按需牲畜化环境） 。Session 不再是内存里的一段 JSON，而是一条写入 durable log store 的 append-only 流；Harness 不再维护任何本地状态，收到 awake(sessionId) 就从 log 中 replay 最后 checkpoint，然后调用 execute(toolName, input) ；Sandbox 更是彻底 cattle 化——每次 tool call 都启一个全新 microVM，用完即焚，连磁盘都是只读挂载。这种分层，让 model update 和 runtime update 完全解耦：明天 Claude-4 上线，你不用改一行 agent 代码，只要 Anthropic 更新 Harness 实现即可。
所以，这不是“Anthropic 又出了个新模型”，这是 runtime 层开始进入“操作系统化”阶段的明确信号。就像当年没人会说“Linux 是个新应用”，大家说的是“现在终于能用统一接口操作硬盘和串口了”。Managed Agents 的真正价值，不在于它多快多聪明，而在于它让 agent 开发者第一次可以像写 Python 脚本一样写 agent：关注业务逻辑，而不是进程生命周期管理。
2. 核心设计拆解：为什么是 Session-as-Event-Log，而不是 Context-as-Storage？
2.1 传统 agent 架构的致命伤：context window 是个脆弱的“内存堆栈”
绝大多数开源 agent 框架（LangChain、LlamaIndex、CrewAI）默认把 session state 存在 LLM 的 context window 里。这看似简单，实则埋下三重隐患：
第一是 容量硬顶 。即使你用 200K context 的模型，实际可用空间远低于此：system prompt 占 2K，tool schema 描述占 5K，历史对话占 10K，等你走到第 15 步，剩余空间可能只剩 30K，而一次数据库查询返回的 JSON 就可能超 50K。此时框架通常有两种处理：要么 truncate 最老的 turn（LangChain 的 ConversationBufferWindowMemory ），要么丢弃部分 tool output（LlamaIndex 的 ChatEngine ）。无论哪种，都导致后续推理基于错误前提。
第二是 不可调试性 。当 agent 出错，你只能看到最终输出和最后一段 prompt。中间哪次 tool call 返回了脏数据？哪次 guardrail 规则被绕过？哪次 retry 导致了状态不一致？全无记录。我们曾遇到一个 bug：agent 在 Slack 里回复“已创建 Jira ticket”，但后台查不到 ticket。最后发现是某次 HTTP timeout 后，框架重试时把原始 payload 里的 assignee_id 字段覆盖成了空字符串，而这个细节从未出现在任何日志里。
第三是 不可迁移性 。session 一旦绑定到某个 model instance，就无法跨模型、跨版本、跨 provider 迁移。你想把一个运行了 2 小时的客服对话从 Claude 切到 Gemini？不可能。因为 Gemini 的 context 格式、tool calling 协议、stop sequence 全不同，你得重写整个 history replay 逻辑。
提示：不要迷信“大 context 就能解决一切”。200K 不等于 200K 有效信息。实测显示，当 context 中 tool output 超过 30% 时，模型对最新指令的遵循率下降 42%（数据来自 Anthropic 2025 Q4 内部 benchmark）。这不是算力问题，是注意力机制的固有缺陷。
2.2 Anthropic 的解法：Session 作为独立、可查询、可回溯的事件流
Managed Agents 的核心创新，是把 session 从“模型上下文的一部分”，变成“独立于模型的事件日志（event log）”。具体实现包含四个关键设计：
1. 事件驱动的 session lifecycle
每个 session 初始化时，Anthropic 为其分配一个全局唯一 sessionId ，并创建一条 append-only 的 WAL（Write-Ahead Log）。所有 agent 行为都被序列化为结构化事件：
{
"eventId": "evt_abc123",
"sessionId": "sess_xyz789",
"timestamp": "2026-04-08T14:22:31.123Z",
"eventType": "tool_call_start",
"toolName": "notion_search_pages",
"input": {"query": "Q4 sales report", "database_id": "db_456"}
}
这个 log 存储在 Anthropic 自研的 durable storage layer（非用户可见），保证 ACID 特性。这意味着：即使 Harness 进程崩溃，只要 log 已落盘， awake(sessionId) 就能精确恢复到崩溃前最后一个完整事件点。
2. Harness 的彻底无状态化
Harness 是一个极简的 Go 二进制程序，只做三件事：
- 接收
awake(sessionId)请求，从 log 中加载最近 checkpoint（通常是上一次tool_call_end事件） - 解析当前事件对应的
system prompt + tool schema + latest user message，拼成标准 prompt - 调用
execute(toolName, input)，将结果写入 log 并返回
它不缓存任何 session 数据，不维护 connection pool，不持有 database handle。你可以把它想象成一个“prompt 编译器 + tool 调度器”，所有状态都在 log 里。这使得 Harness 可以水平无限扩展，且升级零停机——新版本上线后，旧 session 自动由新 Harness 处理。
3. Sandbox 的 cattle 化与 credential 隔离 </
477
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
