1. 这不是新赛道，是 runtime 层的“操作系统时刻”来了

你有没有试过让一个 AI 代理连续工作四十分钟？不是闲聊，而是真正在查资料、调 API、写代码、改文档——一环扣一环地推进一个复杂任务。去年我带团队跑一个客户侧的合规审计代理，它要从二十多个内部系统拉日志、比对策略版本、生成风险矩阵，再自动起草整改建议。前38分钟一切丝滑，第39分钟，它突然开始胡说八道：把上一步刚确认的数据库连接状态说成“已断开”，把刚成功调用的审计API返回的200状态码硬生生编成500错误，最后甚至凭空生成了一份根本不存在的漏洞报告。我们翻遍日志，没报错；检查模型输出，token流完整；重放请求，结果却不一样。问题出在哪？不是模型崩了，不是代码错了，而是它的“记忆”被悄悄吃掉了——上下文窗口满了，老的工具调用结果被无声无息地挤出去，模型在残缺的历史上继续推理，像一个忘了自己刚说过什么的人，越说越离谱。

这就是 Anthropic 在4月8日发布的 Claude Managed Agents 真正解决的那个痛点。它不是又一个“更聪明的聊天机器人”，而是一次对 AI 应用底层运行时（runtime）的重新定义。关键词里那个“Towards AI - Medium”不是平台标签，它恰恰点出了这件事的本质：这是一篇写给整个 AI 工程师群体的技术备忘录，不是新闻稿，不是产品通稿，是告诉你“现在该换操作系统了”的现场通报。Managed Agents 的核心，是把过去被塞进模型上下文里、随风飘散的“状态”，变成一个独立、持久、可查询、可回溯的“事件日志”。Session 不再是模型上下文里一段随时可能被覆盖的文本，而是一个存在数据库里的、带时间戳和因果链的结构化记录。Harness（执行器）也不再是绑死在某个进程里的逻辑，而是一个无状态的、按需唤起的“快递员”，只负责接收指令、调用沙盒、把结果塞回日志。沙盒本身，更是彻底成了“牛”——用完即焚，绝不留痕，连凭证都进不了它的内存。

这个设计背后，是血泪教训换来的工程直觉。我们当年重建状态层时，花了整整一周才把 session state 从 context window 里剥离出来，接入 Redis 做持久化，再加一层 WAL（Write-Ahead Log）保证事件顺序。Anthropic 把这套模式直接产品化了，还加上了 credential vault 隔离、checkpointed session 恢复、queryable trace 这些生产环境刚需。它贵吗？$0.08/小时的 active runtime，听起来不便宜。但比起你花三天调试一个因上下文溢出而静默失败的代理、比起你为一次凭证泄露事故付出的合规代价、比起你因为无法复现客户投诉而丢失的信任——这笔钱，是买确定性，不是买功能。它面向的不是想试试 AI 的产品经理，而是每天要为线上代理 SLA 签字的 SRE，是负责审计 AI 系统行为的合规官，是手握几十个 agent 流水线、需要统一治理入口的平台工程师。如果你还在用 LangChain 的 ConversationBufferMemory 或者自己拼接 messages 数组来管理长周期对话，那你不是在开发，你是在给未来的故障埋雷。Managed Agents 的发布，不是 Anthropic 在开辟蓝海，而是告诉所有人：runtime 这层，已经到了必须标准化、必须隔离、必须可审计的时候了。它不性感，但它真实，它沉重，它关乎交付。

2. 核心架构拆解：为什么是“Session-as-Event-Log”，而不是“Session-as-Context”

2.1 Session：从易失缓存到持久化事件总线

传统 LLM 应用的 session 管理，本质上是一种“寄生式”设计。它把所有状态——用户初始提问、中间工具调用结果、模型思考过程、最终输出——一股脑塞进模型的上下文窗口（context window）。这个窗口就像一个狭小的、没有索引的记事本，内容越多，旧信息越容易被新内容覆盖。当一个代理需要执行多步操作时，比如“先查天气，再根据温度推荐穿搭，最后搜索附近符合风格的店铺”，每一步的输入和输出都占据宝贵 token。四十分钟后，最初的天气查询结果早已被挤出视野，模型在缺失关键前提的情况下，只能靠概率瞎猜后续步骤。这不是模型能力不足，而是架构设计上的根本缺陷：它把 状态存储 （State Storage）和 计算执行 （Computation Execution）这两个本应分离的职责，强行耦合在同一个脆弱的、容量受限的载体上。

Anthropic 的 “Session-as-Event-Log” 模式，是对这一耦合的彻底解构。它引入了一个独立于模型之外的、专门用于记录和存储 session 全生命周期的持久化服务。每一次交互，无论大小，都被原子化为一个结构化的事件（Event），写入这个日志。这个日志不是简单的文本追加，而是一个具备以下特性的专业事件总线：

• 结构化 Schema ：每个事件包含明确的字段，如 event_id （唯一UUID）、 session_id （关联整个会话）、 timestamp （毫秒级精度）、 event_type （如 user_input , tool_call_start , tool_call_success , model_output , guardrail_violation ）、 payload （JSON格式的有效载荷，包含工具名、参数、返回值、模型生成的文本等）。这种结构化使得日志不再是“黑盒”，而是可以被任意下游系统消费的“数据源”。

• 因果链（Causality Chain） ：事件之间通过 parent_event_id 字段建立显式的父子关系。例如，一个 tool_call_start 事件会生成一个 tool_call_success 事件作为其子事件，而这个 tool_call_success 又会成为后续 model_output 事件的父事件。这种链式结构完美还原了代理内部的决策树和执行流，让你能清晰地看到“模型为什么生成了这句话”，因为它前面紧跟着哪几个工具调用的结果。

• 持久化与容错 ：日志存储在高可用、强一致的后端数据库（很可能是基于 RocksDB 或类似引擎的 OLAP 优化存储），而非内存或临时文件。这意味着即使整个 harness 进程崩溃、服务器宕机，只要日志服务还在运行，session 的完整历史就毫发无损。你可以随时 awake(sessionId) ，让一个新的 harness 实例从最后一个成功的 checkpoint 处无缝续跑，完全不需要用户重新输入或从头开始。

提示：这个设计的价值，在于它将“可重现性”（Reproducibility）从一个理想目标变成了一个默认属性。当你收到客户投诉“代理昨天给我推荐了错误的店铺”，你不再需要祈祷日志没被轮转掉，也不需要依赖模糊的监控指标。你只需用 session_id 查询事件日志，就能精确复现当时每一个步骤的输入、输出、耗时、甚至模型的 token 概率分布（如果启用了相关选项）。这是构建可信 AI 应用的基石。

2.2 Harness：无状态的“执行快递员”

如果说 Session 是大脑的记忆皮层，那么 Harness 就是纯粹的运动皮层——它只负责执行，不负责记忆。在 Managed Agents 架构中，Harness 被设计成一个极致轻量、完全无状态的执行单元。它的核心接口只有一个： execute(name, input) → string 。这里的 name 是一个注册过的工具名（如 weather_api 或 shop_search ）， input 是一个 JSON 对象， string 则是工具执行后的原始字符串输出（通常是 JSON，但也可以是纯文本）。

这个极简接口背后，是深刻的工程哲学：

• 解耦与演进自由 ：Harness 的实现细节（是用 Python subprocess 调用本地脚本，还是用 gRPC 连接到远程微服务，或是启动一个 Docker 容器）对上层完全透明。Anthropic 可以在不改变任何用户定义的 agent YAML 的前提下，将 Harness 的底层实现从单机进程无缝切换到 Kubernetes 上的 Serverless 函数。这种“稳定抽象层”正是操作系统虚拟化硬件的精髓——应用开发者只关心“我要读文件”，而不必操心硬盘是 SATA 还是 NVMe。

• 资源隔离与弹性伸缩 ：由于 Harness 本身不保存任何状态，它天然就是“无状态服务”。这意味着它可以被水平无限扩展。当你的销售代理集群在周一早九点迎来流量高峰时，系统可以瞬间拉起数百个 Harness 实例，处理完请求后立即销毁，零资源残留。这与传统需要维护长连接、共享内存的有状态服务相比，资源利用率和弹性都高出一个数量级。

• 安全边界清晰 ：Harness 的唯一职责是“调用工具并返回结果”。它不接触用户的原始 prompt，不解析模型的思考链，更不会去读取任何敏感配置。它的输入 input 和输出 string 都是经过严格 schema 校验的，杜绝了恶意 payload 的注入。这种“最小权限原则”（Principle of Least Privilege）是构建安全沙盒的第一道铁壁。

2.3 Sandbox：真正的“牛”，而非“宠物”

沙盒（Sandbox）是 Managed Agents 安全模型的物理载体。Anthropic 对它的定位非常明确：“cattle, not pets”（牛，而非宠物）。这意味着沙盒不是被精心呵护、长期运行、需要手动打补丁和升级的“宠物”，而是被当作一次性消耗品、按需创建、用完即焚的“牛”。

其具体实现细节虽未完全公开，但我们可以从其设计目标反推其核心特征：

• 微虚拟机（MicroVM）级隔离 ：不同于 Docker 容器共享宿主机内核，Managed Agents 的沙盒极有可能基于 Firecracker 或类似技术构建。每个沙盒都是一个轻量级的、启动速度极快（亚秒级）的虚拟机，拥有自己独立的 CPU 时间片、内存空间和根文件系统。这意味着，即使一个沙盒内的工具代码存在严重漏洞（如 malloc 错误导致内存越界），它也无法突破虚拟机边界，影响到其他沙盒或宿主机。这是真正的“硬件级”隔离。

• 凭证零可见（Credential Zero-Visibility） ：这是生产环境中最致命的安全隐患之一。传统做法是将 API Key、数据库密码等敏感凭证作为环境变量（ ENV ）注入容器。一旦工具代码存在 print(os.environ) 或 curl -v 这样的调试语句，或者被一个恶意的 system() 调用捕获，凭证就会瞬间暴露。Managed Agents 的解决方案是：凭证永远不进入沙盒。它们被安全地存储在 Anthropic 自建的 Vault 服务中。当 Harness 决定调用一个需要凭证的工具时，它会向 Vault 发起一个受严格策略控制的、短时效的（TTL）令牌请求。Vault 返回一个仅对该次调用有效的、作用域极窄的临时令牌（Token），Harness 将此令牌传入沙盒。沙盒拿到的只是一个“一次性的门禁卡”，而不是“家门钥匙”。即使沙盒被攻破，攻击者也只拿到一张几秒钟后就失效的卡片。

• 文件系统只读与临时化 ：沙盒的根文件系统是只读的，确保了基础运行时环境的不可篡改性。所有工具运行时产生的临时文件，都存放在一个独立的、内存映射的临时卷（tmpfs）中，沙盒销毁时，这些数据自动清零，不留任何痕迹。这从根本上杜绝了“脏沙盒”（Dirty Sandbox）问题——即一个被污染的沙盒被重复使用，导致跨会话的数据泄露。

注意：这种沙盒设计，其成本远高于一个简单的 Docker 容器。它需要更复杂的调度器、更精细的资源配额管理、以及与 Vault 的深度集成。Anthropic 敢于采用此方案，恰恰说明他们将“生产环境安全”置于了绝对优先级。对于金融、医疗等强监管行业，这不是一个可选项，而是一个准入门槛。

3. 实操落地：从 YAML 定义到生产部署的全流程详解

3.1 Agent 定义：用 YAML 描述你的“数字员工”

Managed Agents 的入口，是你用 YAML 文件（或自然语言）描述的一个 agent。这并非一个抽象概念，而是一个高度结构化的、可编程的契约。下面是一个为 Notion 团队定制的“会议纪要整理员”agent 的完整 YAML 示例，并附上每一行的实操注释：

# agent.yaml
# 1. 元数据：这是你的 agent 在 Anthropic 控制台中的“身份证”
name: "notion-meeting-minutes"
version: "1.2.0" # 语义化版本号，每次变更（尤其是工具或 guardrail）都必须更新
description: "An agent that reads meeting transcripts from Notion pages and generates structured minutes with action items."

# 2. 核心身份：System Prompt 是 agent 的“灵魂设定”，必须精准、无歧义
system_prompt: |
  You are a meticulous and professional meeting minute scribe.
  Your task is to read the raw transcript provided in the 'transcript' field,
  identify key discussion points, decisions made, and explicit action items.
  Action items MUST have an owner (a person's name or role) and a clear deadline.
  If no deadline is mentioned, infer a reasonable one based on context (e.g., 'by next Monday').
  Output ONLY valid JSON. Do not add any explanatory text before or after.

# 3. 工具集：这是 agent 的“手脚”，定义了它能做什么
tools:
  # 工具1：Notion API - 用于读取原始会议记录
  - name: "notion_read_page"
    description: "Reads the full content of a Notion page by its page_id."
    # 参数定义是关键！必须与实际 API 的 OpenAPI Spec 严格一致
    parameters:
      type: "object"
      properties:
        page_id:
          type: "string"
          description: "The unique ID of the Notion page to read."
      required: ["page_id"]

  # 工具2：Custom Action Item Extractor - 一个封装好的内部服务
  - name: "extract_action_items"
    description: "Extracts structured action items (owner, task, deadline) from unstructured text."
    parameters:
      type: "object"
      properties:
        transcript:
          type: "string"
          description: "The raw meeting transcript text."
      required: ["transcript"]

# 4. 执行流程：Orchestration Logic - 定义 agent 的“工作流”
orchestration:
  # 这是一个线性流程，但 Anthropic 也支持条件分支（if/else）和循环（loop）
  steps:
    # Step 1: 读取 Notion 页面
    - step_id: "read_transcript"
      tool: "notion_read_page"
      # 输入参数可以是静态值，也可以是上一步的输出（用 {{ }} 引用）
      input:
        page_id: "{{ input.page_id }}" # 这个 input 来自用户发起的会话请求

    # Step 2: 将读取到的内容交给提取器
    - step_id: "extract_actions"
      tool: "extract_action_items"
      input:
        transcript: "{{ steps.read_transcript.output.content }}" # 引用上一步的输出

# 5. 安全护栏（Guardrails）：agent 的“道德与法律准绳”
guardrails:
  # 内容安全：防止生成违法、有害、歧视性内容
  content_safety:
    enabled: true
    # 预设的策略包，也可以自定义规则
    policy_pack: "enterprise-strict"

  # 工具调用安全：防止 agent 调用它不该调用的工具
  tool_calling:
    # 白名单模式：只允许调用 YAML 中明确定义的工具
    mode: "whitelist"
    # 如果 agent 尝试调用未定义的工具，会触发此 fallback
    fallback:
      response: "I am not authorized to perform that action. Please contact your administrator."

  # 数据隐私：防止 agent 将敏感信息（如SSN、信用卡号）输出到日志
  data_privacy:
    enabled: true
    # 使用 NER（命名实体识别）模型扫描输出
    scan_output: true
    # 如果发现敏感数据，自动 redact（打码）
    redact_on_match: true

# 6. 会话配置：定义 agent 的“行为习惯”
session_config:
  # 最大运行时长，防止无限循环
  max_duration_minutes: 30
  # 最大工具调用次数，防止单次会话消耗过多资源
  max_tool_calls: 10
  # 是否启用 checkpointing，即是否在每一步后保存状态
  enable_checkpointing: true

这个 YAML 文件，就是你交付给 Anthropic 的全部。它不包含一行 Python 代码，不涉及任何框架选择。你只需要清晰地告诉 Anthropic：“我的 agent 叫什么、它信什么（system prompt）、它能干什么（tools）、它怎么干（orchestration）、它不能干什么（guardrails）”。Anthropic 的 Harness 会自动解析这个 YAML，将其编译成一个可执行的、安全的、可观测的运行时实例。这种“声明式”（Declarative）的定义方式，极大地降低了 AI 应用的开发门槛，让领域专家（如业务分析师、法务顾问）也能参与到 agent 的设计中来，因为他们无需懂编程，只需懂自己的业务逻辑。

3.2 部署与集成：如何让它真正为你工作

定义好 YAML 后，部署过程极其简单，但集成到你的现有工作流中，则需要一些关键考量：

1. 创建与部署 ：

   # 使用 Anthropic CLI（假设已安装并配置好）
   anthropic agents create --file agent.yaml --name "notion-meeting-minutes-prod"
   # 输出：Agent created successfully. ID: agt_abc123...
   

   这条命令会将你的 YAML 提交到 Anthropic 的托管服务，并返回一个唯一的 agent_id 。这个 ID 就是你后续所有 API 调用的钥匙。

2. 发起会话（Session） ：

   # 使用 curl 发起一个新会话
   curl -X POST https://api.anthropic.com/v1/agents/agt_abc123/sessions \
     -H "x-api-key: $ANTHROPIC_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
           "input": {"page_id": "notion_page_id_xyz789"},
           "stream": false
         }'
   # 响应会返回一个 session_id，如 "sess_def456..."
   

   这里 input 字段的内容，会作为 {{ input.page_id }} 注入到 YAML 的 orchestration 流程中。 stream: false 表示等待整个会话完成后再返回最终结果，适合批处理场景； stream: true 则会返回一个 SSE（Server-Sent Events）流，适合需要实时显示进度的 Web UI。

3. 查询会话状态与日志 ：

   # 查询会话的当前状态和最终结果
   curl "https://api.anthropic.com/v1/agents/agt_abc123/sessions/sess_def456" \
     -H "x-api-key: $ANTHROPIC_API_KEY"
   
   # 查询完整的、结构化的事件日志（这才是精华！）
   curl "https://api.anthropic.com/v1/agents/agt_abc123/sessions/sess_def456/events?limit=100" \
     -H "x-api-key: $ANTHROPIC_API_KEY"
   # 响应是一个 JSON 数组，每个元素就是一个 event，包含 timestamp, event_type, payload 等
   

4. 与现有系统集成的关键点 ：

   • 身份认证（Auth） ：不要把 ANTHROPIC_API_KEY 硬编码在前端或客户端。所有对 Managed Agents 的调用，都应该由你的后端服务（如一个 Node.js Express API）代理。后端服务负责验证用户身份（如 JWT），然后用自己的服务账号密钥调用 Anthropic。
   • 输入预处理 ：YAML 中的 input 字段是有限的。如果你的业务需要传递大量上下文（如整个 Notion workspace 的元数据），应该在你的后端服务中，先将这些信息聚合、摘要，再精炼成 YAML 中 input 所需的几个关键字段。
   • 输出后处理 ：Managed Agents 的最终输出是 JSON，但你的前端可能需要渲染成富文本。这个转换逻辑，应该放在你的后端或前端，而不是试图让 agent 直接生成 HTML（这违反了单一职责原则，且极易被 jailbreak）。

实操心得：我们上线第一个客户代理时，犯了一个典型错误——把 max_duration_minutes 设为了 60。结果在一次处理超长法律合同的会话中，agent 在第58分钟触发了超时，但此时它已经完成了90%的工作，所有中间结果都丢失了。后来我们改为 max_duration_minutes: 15 ，并利用 enable_checkpointing: true ，让 agent 每完成一个关键步骤（如“已提取所有条款”、“已识别所有风险点”）就自动保存一个 checkpoint。这样，即使超时，用户也能拿到已完成的部分结果，体验好得多。记住， checkpointing 不是锦上添花，而是生产环境的必需品 。

4. 竞争格局与未来演进：为什么 runtime 层注定走向“零价”

4.1 Hyperscaler 的降维打击：AWS AgentCore 的启示

Anthropic 的 Managed Agents 发布于2026年4月，而 AWS 的 Bedrock AgentCore 在2025年11月就已进入通用可用（GA）阶段。这是一个被媒体广泛忽略，但对行业格局具有决定性意义的时间差。AgentCore 的设计哲学，与 Anthropic 形成了一种微妙的互补与竞争：

• 基础设施即服务（IaaS）思维 ：AgentCore 并不试图定义一个“Anthropic 式”的 agent 标准。它把自己定位为一个“框架无关”（Framework-Agnostic）的通用运行时底座。它不关心你用的是 LangGraph、CrewAI 还是自研的 State Machine。只要你能将你的 agent 编译成一个标准的 request-response 循环（即接收一个 JSON 输入，返回一个 JSON 输出），AgentCore 就能托管它。它甚至不强制你使用 Claude——你可以自由选择 Bedrock 上的任何模型，包括 Claude、Llama、Cohere，甚至是你自己的微调模型。

• 微虚拟机（MicroVM）的极致性能 ：AgentCore 的每个 session 都运行在一个独立的 Firecracker MicroVM 中。官方数据显示，其沙盒启动时间（sandbox spin-up time）低于 100ms，会话最长可持续 8 小时。这种性能，已经逼近了传统容器的水平，却提供了远超容器的安全隔离等级。这意味着，一个企业完全可以将 AgentCore 当作其内部 AI 应用的“私有云”，所有 agent 都运行在自己的 VPC 内，数据不出域。

• 定价策略：免费即武器 ：AWS 的核心优势在于其庞大的云生态。AgentCore 的定价模型是“免费+捆绑”。它本身不单独收费，而是作为 Bedrock 服务的一部分，其计算资源消耗（CPU、内存）会计入你整体的 EC2 或 Fargate 账单。对于一个已经在 AWS 上花费数百万美元的企业客户来说，“多用一个 agent 运行时”几乎不增加任何边际成本。这是一种典型的“生态锁定”（Ecosystem Lock-in）策略：你用 AWS 的存储、网络、计算，那么 AI 运行时，自然也该用 AWS 的。

这解释了为什么 Anthropic 的发布被作者称为“防御性”的。Anthropic 的核心收入来源是 Claude 模型的 token 收费。如果它的客户发现，用 AWS AgentCore 托管一个 Claude agent，比用 Anthropic 自己的 Managed Agents 更便宜、更灵活、更安全，那么 Anthropic 就面临着一个严峻的现实：它辛苦构建的 runtime 层，正在被一个更庞大、更成熟的云基础设施所吸收和同化。这不是技术优劣之争，而是商业生态的碾压。

4.2 价值迁移：当 runtime 成为“水电煤”，钱流向哪里？

历史总是惊人的相似。作者在文中引用了 VMware 的兴衰史，这是一个绝佳的类比。2005年，VMware ESX 是一个昂贵的、专有的、高性能的虚拟化产品。十年后，KVM 和 Xen 等开源方案成熟，AWS/GCP/Azure 将虚拟化作为云服务的默认底层，虚拟化本身不再是可售卖的产品，而变成了“水电煤”一样的基础设施。价值向上游迁移，涌向了 Terraform（基础设施即代码）、Kubernetes（容器编排）、以及最终构建在其上的各种 SaaS 应用。

AI 的 runtime 层，正在经历完全相同的路径。那么，下一个十年的价值高地在哪里？答案已经非常清晰：

价值层	代表玩家	核心价值主张	为什么它能存活？
Trace Store（追踪存储）	Braintrust (Brainstore), Arize (Phoenix), LangSmith	成为 AI agent 行为的“唯一真相源”（Single Source of Truth）。提供强大的查询、分析、可视化能力，支持跨 runtime 迁移。	Trace 数据是 agent 的“DNA”，是不可再生的。无论你把 agent 从 Anthropic 迁移到 AWS，还是迁移到自建 K8s，trace 日志是唯一能跟随它、证明它行为的资产。谁能提供最开放、最标准、最易迁移的 trace 格式（如 OpenTelemetry for AI），谁就掌握了话语权。
Governance & Policy（治理与策略）	AWS (AgentCore Policy Controls), OWASP (Agentic Top 10), 新兴初创公司	提供一套企业级的、可审计的、可强制执行的 AI 行为管控体系。回答“这个 agent 被允许做什么？”、“谁批准了这个权限？”、“它的所有操作都有记录吗？”。	合规是刚需。随着《AI Act》等全球性法规的落地，企业采购 AI 服务时，第一问不再是“它有多快”，而是“它是否符合我们的 SOC2/ISO27001 合规要求？”。这是一个需要深厚安全工程和合规经验的领域，绝非单纯的技术问题。
Vertical Agent Marketplaces（垂直领域 agent 市场）	Salesforce (Agentforce), 金融/医疗/安全领域的初创公司	提供开箱即用的、针对特定行业、特定岗位、特定任务的 agent。如“医保理赔审核 agent”、“证券研究报告生成 agent”、“红队渗透测试 agent”。	企业愿意为“解决一个具体问题”付费，而不是为“一个通用的运行时”付费。Salesforce Agentforce 在2026财年Q4 达到 8 亿美元 ARR，证明了市场对“垂直 agent”的强烈付费意愿。这背后是巨大的领域知识壁垒和客户信任，是 runtime 层无法复制的。

常见问题速查表：

问题	排查思路	解决方案
Q1：我的 agent 在沙盒里调用外部 API 总是超时	检查沙盒的网络策略。默认情况下，Managed Agents 的沙盒只允许访问 Anthropic 托管的工具服务（如 Notion、Asana 的官方 connector）。访问任意公网地址是被禁止的。	方案A（推荐）：将你的外部 API 封装成一个 Anthropic 认可的“自定义工具”，通过其安全网关调用。方案B：联系 Anthropic 支持，申请白名单，但这会增加安全审查流程。
Q2：事件日志里看不到模型的原始 token 概率分布，只有最终输出	这是默认行为，为了保护模型知识产权和防止 prompt injection 分析。 payload 中的 model_output 字段只包含生成的文本。	方案：在创建 agent 时，在 session_config 中添加 enable_token_probabilities: true 。但这会显著增加日志体积和存储成本，仅在调试阶段开启。
Q3：如何让多个 agent 共享同一个长期记忆（如公司知识库）？	Managed Agents 的 Session 是隔离的，不支持跨 session 共享状态。试图在 YAML 中定义一个全局变量是无效的。	方案：将知识库抽象为一个独立的、可被所有 agent 调用的“工具”。例如，创建一个 company_knowledge_search 工具，所有 agent 都可以通过 tool_call 来查询它。这样，知识库的更新和维护就与 agent 的生命周期完全解耦。

5. 给从业者的行动建议：别在 runtime 层“造轮子”，去占领更高处

作为一个在 AI 基础设施领域摸爬滚打十多年的从业者，我见过太多团队在 runtime 层投入巨大精力，最后却发现自己的“高性能沙盒”在 AWS 的 MicroVM 面前毫无优势，自己的“智能调度器”在 Kubernetes 的 HPA（Horizontal Pod Autoscaler）面前显得笨拙。Anthropic 的 Managed Agents，以及 AWS 的 AgentCore，它们共同发出的信号是明确的： runtime 层的战争已经结束，胜者是那些拥有最大规模基础设施和最深生态整合的云厂商。

这并不意味着创业机会消失了，恰恰相反，它释放了巨大的创新能量。我的建议非常直接：

第一，立刻停止在“沙盒性能”、“Harness 调度算法”、“Session 存储优化”上投入新的研发资源。 这些领域已经进入了“军备竞赛”的尾声。你的 10% 性能提升，在 AWS 的 1000 万客户基数面前，毫无意义。把你的顶尖工程师，从这些底层细节中解放出来。

第二，全力押注“Trace Store”和“Policy Engine”。 这是未来五年最硬核、也最有护城河的技术方向。你需要做的，不是发明一个新协议，而是成为 OpenTelemetry for AI 生态的坚定贡献者和最佳实践者。去研究如何将 event_type: model_output 与 event_type: tool_call_success 的因果链，用一种既高效又可扩展的方式存储和索引。去研究如何将 OWASP Agentic Top 10 的每一条，翻译成可以在 runtime 层强制执行的、细粒度的策略规则（Policy as Code）。这需要你同时精通分布式系统、安全工程和 AI 行为学。

第三，拥抱垂直，深耕场景。 不要再幻想做一个“通用 agent 平台”。去找一个你真正懂的行业，比如你曾经在银行做过风控，那就去做一个“信贷审批 agent”；你熟悉生物医药，那就去做一个“临床试验文献筛选 agent”。把你的领域知识，全部沉淀到 system_prompt 、 tools 的参数定义、以及 orchestration 的每一步逻辑中。让这个 agent 的“智商”，不是体现在它能多快地算出一个数学题，而是体现在它能多准确地理解“什么是合格的贷前调查报告”。

最后分享一个小技巧：在评估任何一个新的 AI 基础设施产品时，不要问“它有多快？”，而要问“如果明天我就把它替换成 AWS AgentCore，我的 trace 数据、我的策略配置、我的 agent 定义，能无缝迁移过去吗？”。如果答案是否定的，那它就不是一个面向未来的投资，而是一个需要在未来某天被推倒重来的技术债。Runtime 层正在归零，但上面的每一层，都蕴藏着比以往任何时候都更丰厚的回报。看清这个趋势，你就能在 AI 的下一波浪潮中，站稳属于你的位置。