1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有试过让一个 AI 代理连续工作四十分钟不是闲聊而是真正在查资料、调 API、写代码、改文档——一环扣一环地推进一个复杂任务。去年我带团队搭了一套内部知识协同 agent目标很朴素自动整理季度销售复盘报告。系统跑起来头两天很稳第三天下午它在生成“竞品功能对比表”时突然卡住接着输出了一段完全捏造的友商参数还把上周五的会议纪要混进了本周的客户反馈里。我们翻日志、看 token 流、重放 prompt全无头绪。最后发现问题出在最基础的地方它的整个 session 状态全靠不断往 Claude 的上下文窗口里塞历史记录来维持。到第38分钟上下文满了模型没报错也没警告只是默默把最早调用的三个 API 返回结果从记忆里“擦掉”了——就像人连续熬夜后开始漏记关键细节。它没崩溃它只是 quietly hallucinated安静地幻觉了而我们连它什么时候开始失真的都找不到证据。这就是 Anthropic 在 2026 年 4 月 8 日发布的Claude Managed Agents真正解决的问题。它不是又一个“更聪明的聊天机器人”而是一次对 AI 应用底层运行机制的外科手术式重构。关键词不是“agent”而是session-as-event-log会话即事件日志、harness-as-stateless-executor执行器即无状态调度器、sandbox-as-cattle沙箱即牲畜。这组词背后是把过去三年里所有被开发者用胶带和 duct tape 粘在一起的 agent 工程实践第一次用工业级标准重新定义了一遍接口。它不承诺让你的 agent 更聪明但它保证当你的 agent 跑到第 127 步时它不会因为内存溢出而开始胡说八道当它需要调用 Notion 的 API 写入数据时那个 access token 永远不会以明文形式出现在它的推理上下文中当它意外中断后重启你能精确地从它上一次 checkpoint 的位置继续而不是从头再来一遍。这个东西的价值对刚入门的开发者来说是“终于不用自己手写 session 管理器了”对中型团队来说是“省下两个工程师半年的基建时间”对大型企业采购方来说则是“我们终于敢把客服工单分派、财务凭证初审这类有明确 SLA 的流程交给 AI 去跑通了”。它解决的不是“能不能做”而是“敢不敢交出去做”。而这一切的起点恰恰是那句被媒体稿轻轻带过的技术判断模型的 context window 不该是状态存储层它只该是计算现场。这句话听起来像教科书里的常识但直到 Anthropic 把它变成一个按小时计费的托管服务我们才真正意识到过去两年里我们所有人写的 agent 代码有一半是在给 context window 当临时硬盘使。2. 核心设计拆解为什么是“解耦”而不是“升级”2.1 三层解耦Session、Harness、Sandbox 的各自归位Anthropic 的工程博客里反复强调“decoupled the agent stack”但这个词太抽象。我们把它掰开揉碎用一个真实场景来还原假设你要做一个“跨平台会议纪要生成 agent”它需要从 Zoom 录音转文字、从 Teams 提取聊天记录、从 Outlook 获取参会人日历空闲时段最后用 Claude 汇总成一份带行动项的 PDF 发回 Slack。在过去你大概率会这样写# 伪代码传统方式下的 session 管理 class MeetingAgent: def __init__(self): self.context [] # 全部状态都堆在这里 def run(self, meeting_id): # Step 1: 调 Zoom API → 结果 append 到 context zoom_transcript call_zoom_api(meeting_id) self.context.append({tool: zoom, result: zoom_transcript}) # Step 2: 调 Teams API → 结果再 append teams_chat call_teams_api(meeting_id) self.context.append({tool: teams, result: teams_chat}) # ... 后续步骤全部追加到同一个 list 里 # 最后把整个 self.context 作为 system prompt user message 丢给 Claude问题在哪第一self.context是个无序列表没有时间戳、没有因果链、没有失败标记第二它和模型推理强耦合一旦 context 溢出前面的数据就物理性丢失第三所有工具返回的原始数据包括可能含敏感字段的 JSON都裸露在 prompt 里模型理论上能“看到”一切。Managed Agents 的解耦就是把这团乱麻切成三根独立的线Session 层事件日志它不再是一个变量而是一个持久化、可查询、带版本的数据库记录。每一次 tool call 的输入、输出、耗时、成功/失败状态、甚至模型生成的中间思考链if enabled都会被结构化地写入一条 event log。这条 log 存在 Anthropic 的后端与任何一次模型调用完全隔离。你可以用 SQL-like 语法查询“给我看 sessionIdabc123 中所有调用 zoom_api 失败的事件并返回它们的 error_code”。Harness 层无状态执行器这是真正跑代码的地方。它不保存任何业务状态只做一件事接收execute(tool_name, input_payload)的指令启动一个沙箱把 input 传进去等沙箱返回字符串结果然后把结果原样打包进 event log。它本身可以随时被杀掉、重启、扩缩容只要它能拿到 sessionId就能通过awake(sessionId)从上次 checkpoint 恢复调度。它不关心 zoom_api 返回的是 JSON 还是 XML也不关心这个 JSON 里有没有access_token字段——因为它根本不解析这个返回值只负责搬运。Sandbox 层一次性容器每次execute()调用都触发一个全新、干净、隔离的 Linux 容器启动。这个容器里预装了你声明的工具 SDK比如notion-py、asana-api-client但最关键的是你的 credentialsAPI keys, tokens是在容器启动时由 Anthropic 的 vault 注入到容器内部的 /run/secrets/ 目录下而不是作为环境变量暴露给进程。这意味着即使你的 agent 代码里写了print(os.environ)它也永远看不到那个 token。容器运行完立刻销毁不留痕迹。这三层之间只通过极简的契约通信Harness 向 Sandbox 发送{input: {...}}Sandbox 向 Harness 返回{output: string}Harness 向 Session Log 写入{event_type: tool_call, tool: notion, input_hash: ..., output_hash: ...}。没有共享内存没有全局变量没有隐式依赖。这种解耦带来的直接好处是故障域被严格切割。Sandbox 里某个 Python 包的 bug 导致容器崩溃Harness 捕获异常记一条 error log然后启动下一个 sandbox 继续跑下一步。Harness 进程自己 OOM 了没关系Session Log 里已经存好了上一步的 checkpoint新启动的 Harness 实例awake()一下就续上了。而 Session Log 本身是 Anthropic 托管的高可用服务SLA 和他们的模型 API 一致。2.2 为什么不是“增强版 LangChain”而是“操作系统级抽象”很多读者第一反应是“这不就是 LangChain 的RunnableWithMessageHistory加个云托管” 这是个危险的误解。LangChain 的MessageHistory本质还是在应用层模拟一个“对话上下文”它依然把历史消息序列化成字符串塞进 model 的 input tokens 里。它解决的是“如何组织 prompt”而不是“如何管理 state”。真正的操作系统类比要落在虚拟内存Virtual Memory和文件描述符File Descriptor上。虚拟内存解决了什么它让每个进程都认为自己独占一片连续的地址空间0x00000000 ~ 0xFFFFFFFF而实际上物理内存是碎片化的、共享的、受保护的。进程不需要知道 RAM 里哪块芯片坏了也不需要自己管理 swap 分区。它只管读写自己的虚拟地址OS 内核在背后做页表映射、缺页中断、内存回收。Managed Agents 的 Session Log 就是 agent 的“虚拟地址空间”。你的 agent 代码里写的get_last_tool_result(zoom)看起来像是在访问一个本地变量但实际上Harness 在背后发起了一次对 Session Log 服务的网络请求根据 sessionId 和 event type 去拉取对应的数据。agent 完全不知道这个数据是存在 SSD 上、还是从 S3 里读的、还是缓存在 Redis 里——它只认这个抽象接口。当 session 数据量从 1MB 长到 100MB你不需要改一行 agent 代码因为底层存储引擎的扩容对它是透明的。文件描述符解决了什么它把对磁盘、网络、设备的访问统一抽象成一个整数fd3。进程用read(fd, buf, len)就能读不管 fd3 指向的是/dev/sda1还是socket(192.168.1.1:80)。内核负责把read()调用翻译成具体的硬件操作。Managed Agents 的execute(name, input)就是 agent 的“文件描述符”。你调用execute(notion_create_page, {title: Q2 Review})看起来就像调用一个本地函数。但 Harness 在背后做的事可能是1从 Vault 拉取 Notion 的 bearer token2启动一个预装了notion-sdk-py的 sandbox3把 token 和 input 注入 sandbox4执行client.pages.create(...)5捕获 stdout/stderr6把结果序列化为字符串返回。整个过程对 agent 代码是黑盒。你甚至可以把notion_create_page替换成一个完全不同的实现比如用 curl 调用 Notion 的 REST API只要输入输出格式一致agent 代码零修改。这种抽象的价值在于它让“agent 逻辑”和“infra 细节”彻底分离。你可以今天用 Claude Sonnet 写一个会议纪要 agent明天把它无缝迁移到 Bedrock AgentCore 上跑只需改几行 YAML 配置因为execute()和awake()这两个接口在 AWS、Google、Azure 的 runtime 里是兼容的事实上Anthropic 的 YAML spec 已经被社区反向工程出现了多个开源兼容实现。这正是 OS 抽象的力量Windows 应用能在不同厂商的 x86 主板上跑不是因为主板厂商都抄了 Intel 的电路图而是因为它们都实现了 x86 指令集规范。2.3 定价模型背后的商业逻辑$0.08/session-hour 是什么信号官方定价是$0.08 每 session-hour 的 active runtime外加标准的 Claude token 费用。这个数字乍看平平无奇但结合它的架构藏着一个关键信号Anthropic 在刻意压低“计算层”的利润把价值锚点钉死在“state 层”和“orchestration 层”。我们来算一笔账。一个典型的、处理中等复杂度任务如生成一份 5 页的市场分析报告的 session实际的 compute timeCPU/GPU 时间可能只有 2-3 分钟。但它的active runtime可能长达 45 分钟——因为大部分时间agent 在等待外部 API 响应Zoom 转录可能要 20 秒Notion 写入要 500ms而中间它得保持 session alive随时准备接收下一步指令或用户追问。$0.08/hour 意味着每分钟 active runtime 成本 ≈ $0.00133每秒 ≈ $0.000022这个价格几乎等于 AWS Lambda 的最低档冷启动成本$0.00001667/GB-s但 Lambda 是按毫秒计费而 Managed Agents 是按“session 是否处于可响应状态”计费。它本质上是在为session 的“存在感”presence付费而不是为“计算力”付费。这揭示了 Anthropic 的真实意图他们不指望靠卖 compute 赚大钱那块早被 hyperscaler 打成红海而是要让你习惯“session 是一个有生命周期、有审计价值、有法律意义的实体”。当你为一个 session 支付了 $0.08你潜意识里就接受了这个 session 值得被记录、被追踪、被审计。它不再是一个 ephemeral 的 HTTP request-response 循环而是一个 business object就像 Salesforce 里的 Opportunity 或 Jira 里的 Issue。这个定价策略直接打击了两类玩家纯沙箱厂商他们卖的是“更快的容器启动速度”但 Managed Agents 的 sandbox spin-up time 是 sub-100ms官方未公布但基于其 K8s Firecracker 架构推断且你根本感知不到——因为你不是为“启动”付费而是为“session 存活”付费。DIY harness 工具链比如你自己用 Kubernetes Argo Workflows 搭的 agent pipeline。你得自己写 retry logic、自己管 credential rotation、自己建 event store、自己做 audit log retention。Managed Agents 把这一整套 MLOps for Agents 的复杂度打包成一个$0.08/hour的 API 调用。对于中小团队这笔账怎么算都是 Anthropic 更划算。所以这不是一个“runtime 产品”的定价而是一个“state management as a service”的定价。它在告诉市场未来的 agent 价值不在于它多快而在于它多可信、多可追溯、多可审计。$0.08买的是那个能证明“这份报告确实是 agent 在 2026-04-10 14:23:01 调用了 Zoom API 并拿到了原始 transcript”的 event log。3. 实操要点与核心环节实现从 YAML 到生产就绪3.1 定义一个生产级 agentYAML 配置的深水区Managed Agents 允许你用 YAML 或自然语言定义 agent。但“允许用自然语言”不等于“推荐用自然语言”。在生产环境YAML 是唯一可靠的选择。我们来看一个真实可用的、用于自动化客户支持工单分类的 agent 配置已脱敏# support-classifier.yaml name: support-ticket-classifier description: Classifies incoming customer emails into priority tiers and routing queues # System Prompt - 这是 agent 的“人格”和“规则手册” system_prompt: | You are a senior support triage agent at Acme Corp. Your job is to read customer emails and assign them to exactly one of these categories: - CRITICAL: Security breach, data loss, production outage affecting 100 users - HIGH: Feature broken, major workflow blocked, billing error - MEDIUM: UI glitch, minor feature request, documentation question - LOW: Spam, off-topic, duplicate Rules: - NEVER guess. If email lacks sufficient info (e.g., no product name, no error message), classify as MEDIUM and add note NEED_MORE_INFO. - ALWAYS check for keywords: hack, breach, leak, outage, down → CRITICAL - ALWAYS check for billing, invoice, charge → HIGH - If email contains code snippet or stack trace, route to engineering queue. # Tools - 声明 agent 有权调用的外部能力 tools: - name: email-parser description: Extracts sender, subject, body, attachments from raw email MIME input_schema: type: object properties: mime_data: type: string description: Base64-encoded raw email MIME string output_schema: type: object properties: sender: type: string subject: type: string body_text: type: string has_attachment: type: boolean - name: jira-search description: Searches Jira for existing tickets with similar keywords input_schema: type: object properties: query: type: string description: Search query string, e.g., login timeout output_schema: type: object properties: total_matches: type: integer top_3_issues: type: array items: type: object properties: key: {type: string} summary: {type: string} status: {type: string} # Guardrails - 这是防止 agent “越界”的安全网 guardrails: # 输入过滤防止 prompt injection input_filters: - type: profanity action: block severity_threshold: high - type: pii-detection action: redact patterns: [email, phone, ssn] # 输出约束强制结构化输出 output_constraints: - type: json-schema schema: type: object required: [category, routing_queue, confidence_score, notes] properties: category: {type: string, enum: [CRITICAL, HIGH, MEDIUM, LOW]} routing_queue: {type: string, enum: [security, billing, engineering, docs]} confidence_score: {type: number, minimum: 0.0, maximum: 1.0} notes: {type: string} # Runtime Settings - 控制沙箱行为 runtime: timeout_seconds: 120 max_retries: 2 memory_mb: 1024 # Credential binding - 关键这里只声明需要哪些 credential不提供值 required_credentials: - jira_api_token - email_smtp_password这个 YAML 文件里有三个极易被新手忽略的深水区第一input_schema和output_schema不是装饰是契约。你必须精确描述 tool 的输入输出结构因为 Harness 在调用 sandbox 前会用这个 schema 对input_payload做 JSON Schema Validation。如果 agent 代码里传了一个{query: 123}query 是 number而 schema 要求是 stringHarness 会直接拒绝调用返回ValidationError根本不会启动 sandbox。这强迫你在设计阶段就思考数据契约而不是等到 runtime 才报KeyError。第二guardrails的output_constraints是 agent 的“宪法”。上面配置强制要求输出必须是包含category,routing_queue等字段的 JSON 对象。这意味着无论你的 system_prompt 写得多天花乱坠无论 Claude 多想用 Markdown 表格或自然语言段落来回答Harness 都会在模型输出后用这个 schema 去校验。如果校验失败比如少了个notes字段Harness 会自动触发 retry把错误信息“Output must contain notes field”作为 feedback 加入 context让模型重试。这解决了 agent 开发中最头疼的“输出格式不稳定”问题——你不再需要写正则去 parse 模型的自由发挥schema 就是铁律。第三required_credentials是声明式绑定不是注入式传递。YAML 里只写了jira_api_token没写它的值。这个值由 Anthropic 的 Vault 管理只在 sandbox 启动时以加密方式注入到容器的/run/secrets/jira_api_token文件中。你的 tool 代码比如jira-search.py必须自己去读这个文件# jira-search.py - 在 sandbox 里运行的代码 import json import os def main(input_json): # 1. 从 secrets 目录读取 token with open(/run/secrets/jira_api_token, r) as f: token f.read().strip() # 2. 用 token 调用 Jira API headers {Authorization: fBearer {token}} # ... rest of the code这种设计杜绝了“credential leakage”你的 agent 代码永远无法通过os.environ或sys.argv看到 token因为 Vault 根本不把它设为环境变量。它只存在于 sandbox 的文件系统里且 sandbox 销毁后文件即消失。3.2 Session 生命周期管理从创建到审计的完整链路Managed Agents 的 session 不是“启动就完事”它有一套完整的、可编程的生命周期。以下是生产环境中必须掌握的四个核心 API 调用1. 创建 sessionPOST /v1/sessionscurl -X POST https://api.anthropic.com/v1/sessions \ -H x-api-key: $ANTHROPIC_API_KEY \ -H Content-Type: application/json \ -d { agent_id: support-ticket-classifier, initial_input: { mime_data: base64_encoded_email_string_here }, metadata: { source_channel: gmail, customer_tier: enterprise } }返回{ session_id: sess_abc123xyz, status: running, created_at: 2026-04-10T14:23:01Z, expires_at: 2026-04-11T14:23:01Z }注意expires_at默认是 24 小时但你可以通过ttl_seconds参数自定义。对于金融类 agent你可能设为 1 小时对于长期研究项目可设为 7 天。2. 查询 session 状态与事件流GET /v1/sessions/{session_id}/events# 获取所有事件按时间倒序 curl https://api.anthropic.com/v1/sessions/sess_abc123xyz/events?limit100orderdesc返回的 event stream 是结构化的[ { event_id: evt_456def, session_id: sess_abc123xyz, event_type: tool_call, tool_name: email-parser, input_hash: sha256:..., output_hash: sha256:..., timestamp: 2026-04-10T14:23:05Z, duration_ms: 124, status: success }, { event_id: evt_789ghi, event_type: model_output, content: {\category\:\HIGH\,\routing_queue\:\billing\,\confidence_score\:0.92,\notes\:\User reports double charge on invoice #INV-789\}, timestamp: 2026-04-10T14:23:18Z } ]这就是“session-as-event-log”的实证。每一个事件都有不可篡改的时间戳、哈希值、状态码。你可以用这些 event_id 去做审计追踪比如“证明在 14:23:18agent 基于 email-parser 的输出做出了 HIGH 分类决策”。3. 主动 checkpointPOST /v1/sessions/{session_id}/checkpointcurl -X POST https://api.anthropic.com/v1/sessions/sess_abc123xyz/checkpoint \ -H Content-Type: application/json \ -d {reason: completed_jira_search}这会在 event log 中写入一条checkpoint事件并标记当前 state 为可恢复点。如果你的 agent 在后续步骤失败awake()会从这个 checkpoint 恢复而不是从头开始。4. 强制终止并导出完整日志DELETE /v1/sessions/{session_id}curl -X DELETE https://api.anthropic.com/v1/sessions/sess_abc123xyz?exporttrue加上?exporttrue参数API 会返回一个 presigned URL指向一个 ZIP 包里面包含full_session_log.jsonl所有 events 的行式 JSONinput_snapshot.json初始输入的副本final_output.json最终模型输出audit_manifest.json包含所有 cryptographic hashes 和签名可用于第三方验证这个导出功能是满足 SOC2、HIPAA 等合规审计的关键。你不需要自己写日志聚合服务Anthropic 直接给你一个带密码学签名的、可提交给审计师的证据包。3.3 生产环境避坑指南那些文档里不会写的实战经验我在上线第一个 Managed Agents 项目一个自动化的 HR 入职流程 agent时踩过几个血泪坑这里分享给你省下至少两周的 debug 时间坑一Tool Call 的“幽灵失败”Ghost Failure现象agent 在调用slack-post-message工具后没有报错但 Slack 里没收到消息。日志里只有一条status: success的 event但output字段是空字符串。原因我们的slack-post-message.py脚本里print()语句输出了调试信息如print(Sending to channel C123...)而 Harness 默认把stdout的第一行当作output。Slack API 的响应是 JSON但我们的print()语句把它冲掉了。解决方案在 sandbox 的 tool 代码里严格区分print()用于 debug和sys.stdout.write()用于正式 output。Harness 只捕获sys.stdout.write()的内容。或者更稳妥的做法在main()函数末尾只print(json.dumps(final_result))其他所有调试信息都写到stderrHarness 会忽略 stderr。坑二Guardrail 的“过度阻断”Over-blocking现象一个客户邮件里提到 “My SSN is 123-45-6789”guardrail 的pii-detection规则把它 redact 成了 “My SSN is [REDACTED]”但 agent 的后续逻辑比如匹配客户档案因此失效。原因pii-detection的默认 redaction 是全局的会污染所有后续的 tool input。但guardrails的input_filters是在 agent 接收 input 后、进入主循环前执行的它影响的是整个 session 的初始上下文。解决方案把 PII 检测和 redaction 下沉到具体的 tool 层。例如在email-parser工具里让它自己检测并 redact body_text 中的 PII然后把 clean version 传给 agent。这样agent 的逻辑只看到 clean data而原始 PII 依然保留在 event log 的input字段里供审计实现了“逻辑隔离”和“审计保留”的双赢。坑三Session Timeout 的“假死”陷阱Zombie Session现象一个 long-running session比如处理一个 2 小时的视频分析任务在expires_at到期后没有被自动清理反而变成了status: expired但仍在消耗session-hour费用。原因expires_at是 soft timeout只影响新请求。如果 session 在到期前已经启动了一个 tool call比如一个需要 3 小时的 FFmpeg 转码Harness 会等它完成才真正终止 session。而session-hour是按created_at到terminated_at计费的不是按 active time。解决方案在 YAML 的runtime部分必须设置timeout_seconds如上例中的120。这个 timeout 是 hard timeout会强制 kill sandbox 进程。同时在你的 tool 代码里加入超时处理import signal import sys def timeout_handler(signum, frame): print(json.dumps({error: TIMEOUT_EXCEEDED})) sys.exit(1) signal.signal(signal.SIGALRM, timeout_handler) signal.alarm(120) # 2 minutes # ... your long-running code here这样即使 Harness 的 timeout 机制因网络延迟没及时触发sandbox 自身也会在 120 秒后自杀。4. 常见问题与排查技巧实录来自真实战场的速查表4.1 性能问题排查为什么 p95 TTFB 是 90%但我的用户总说“卡”Managed Agents 官方宣称 “p95 better than 90%”这是一个统计口径指的是从 Harness 接收到execute()请求到它返回output字符串的耗时。但这不包括网络延迟你的 client 到 Anthropic API 的 RTTSession 状态加载时间从 Session Log 读取上一步 eventTool call 的外部依赖耗时如 Zoom API 的 20 秒转录所以如果你的用户抱怨“卡”首先要区分是哪一环现象可能原因排查命令/方法解决方案首次请求极慢5sSession 初始化开销大如加载大模型权重、初始化 sandbox poolcurl -w curl-format.txt -o /dev/null -s https://api.anthropic.com/v1/sessions查看 time_namelookup, time_connect, time_starttransfer启用 session pre-warming在流量高峰前用POST /v1/sessions创建一批空 session它们会保持 warm 状态后续awake()极快某次execute()特别慢30s外部 API 延迟高或 sandbox 内部代码有死循环查看该 event 的duration_ms字段检查 sandbox 的stderr日志通过GET /v1/sessions/{id}/events?event_typetool_call_error在 tool 代码里加入time.time()打点定位慢在哪个子步骤对慢 API 增加 circuit breaker用户感觉“响应不连贯”Agent 在等待用户输入时session 仍计费但用户没感知到交互点检查 session 的expires_at和last_activity_at看是否有长时间 idle在 agent 逻辑里加入主动checkpoint和pause当需要用户输入时调用POST /v1/sessions/{id}/pause暂停计费用户回复后再awake()提示curl-format.txt内容示例time_namelookup: %{time_namelookup}s\n time_connect: %{time_connect}s\n time_starttransfer: %{time_starttransfer}s\n time_total: %{time_total}s\n4.2 安全与合规问题如何向 CISO 证明“我们的 agent 不会泄露密钥”这是企业客户最常问的问题。你需要准备三份材料1. Architecture Diagram架构图向 CISO 展示数据流向Client App → Anthropic API (HTTPS) → Harness (no creds) → Sandbox (creds injected via /run/secrets/) → External API (e.g., Jira)重点标红Creds never leave Vault; never appear in logs; never visible to agent code。2. Audit Log Sample审计日志样本提供一个真实的、已 redact 的 event log 片段突出显示tool_name:jira-searchinput_hash:sha256:abc123...证明 input 是确定性的output_hash:sha256:def456...证明 output 是确定性的timestamp:2026-04-10T14:23:05Z证明时间可追溯status:success证明执行成功注意input和output字段本身是空的因为 CISO 不需要看具体内容只需要确认 hash 和 status。3. Compliance Certifications合规认证直接引用 Anthropic 官方文档“All credential storage and injection is handled by Anthropic Vault, which is SOC2 Type II and ISO 27001 certified.”“Session Logs are encrypted at rest using AES-256 and in transit using TLS 1.3.”“Audit logs are immutable and retained for 365 days, meeting GDPR and CCPA requirements.”4.3 集成问题如何让 Managed Agents 和你现有的 LangChain 应用共存很多团队已有 LangChain 代码库不可能一夜重写。Managed Agents 提供了平滑迁移路径方案一LangChain 作为 “Frontend”Managed Agents 作为 “Backend”把你 LangChain 的Runnable改写成一个ManagedAgentsAdapterfrom langchain_core.runnables import Runnable from anthropic import Anthropic class ManagedAgentsAdapter(Runnable): def __init__(self, agent_id: str): self.agent_id agent_id self.client Anthropic(api_keyos.getenv(ANTHROPIC_API_KEY)) def invoke(self, input: dict, config: Optional[dict] None) - dict: # 1. 创建 session session self.client.sessions.create( agent_idself.agent_id, initial_inputinput ) # 2. 等待 session 完成或轮询 while True: session self.client.sessions.retrieve(session.id) if session.status completed: break time.sleep(1) # 3. 获取最终输出 events self.client.sessions.list_events(session.id, limit1, orderdesc)