Agent Runtime 架构演进：从上下文状态到事件日志驱动

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

你有没有试过让一个 AI 代理连续工作四十分钟？不是闲聊，而是真正在查文档、调 API、写代码、改配置、再验证——一整套闭环动作。我去年就搭过这么一套系统，用的是当时最火的开源框架，把所有状态都塞进模型的上下文窗口里。前二十分钟顺风顺水，到第三十分钟，它开始漏掉刚查到的数据库字段名；第四十分钟，它把用户上周提的需求和今天的新任务混在一起，生成了一份逻辑自洽但完全错位的 PR 描述。最要命的是，它没报错，没中断，只是 quietly hallucinated —— 安静地、自信地、不可逆地崩坏了。我们翻遍日志，找不到任何 trace，因为“状态”就是上下文本身，上下文没了，历史就蒸发了。重跑？不行，中间步骤依赖外部系统状态，没法回放。那次故障没上 P0，但团队花了三天重建状态层，把 session 搬出 context window，单独存进时序数据库。这件事让我记住了两个词：event log和stateless harness。

Anthropic 在 4 月 8 日发布的 Claude Managed Agents，表面看是一堆营销话术：十倍提速、Notion 和 Asana 背书、沙箱执行、会话快照……但剥开这些，它交付的是一套被验证过的、生产级的 runtime 基础设施。它把 session 定义为一个持久化、可查询、可回溯的事件流，把 harness（执行器）做成无状态的函数调用接口 execute(name, input) → string，把沙箱当成 cattle（可批量销毁重建的牲畜），而不是 pets（需要精心养护的宠物）。这不是在造轮子，是在给整个 agent 开发栈打地基。它的定价模型也暴露了本质：$0.08/小时的 active runtime 费，外加标准 token 费用。runtime 是按秒计费的资源，不是按模型能力打包的黑盒服务。这说明 Anthropic 清楚地知道，自己卖的不是“智能”，而是“可控的智能执行环境”。关键词 “Towards AI - Medium” 提示我们，这则分析来自一个长期追踪 AI 工程实践的垂直媒体，它不关心谁家模型参数更多，只盯着开发者每天敲的命令、部署的 YAML、排查的 trace、签的采购合同。这篇文章的价值，不在于告诉你 Managed Agents 怎么用，而在于帮你判断：当 runtime 层开始像当年的虚拟化一样被压缩时，你的技术选型、架构决策、甚至职业方向，该往哪一层迁移？它适合两类人：一类是正在评估是否要把现有 agent 迁入托管平台的工程负责人，另一类是刚学完 LangChain、正纠结“下一步该深挖框架还是转向可观测性”的一线开发者。前者需要知道这个 runtime 能扛住什么规模的流量和权限复杂度，后者需要看清，当 harness 变成水电煤之后，真正值钱的技能是什么。

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

2.1 传统 agent 架构的致命伤：上下文即状态，状态即牢笼

绝大多数早期 agent 实现，包括我去年踩坑的那个系统，都默认把 session state 当作模型上下文的一部分来管理。逻辑很朴素：每次 tool call 返回结果，就把它拼进 system prompt + user message + history 的长字符串里，喂给下一轮推理。这在 demo 阶段极其优雅——没有外部依赖，没有状态同步，一行代码就能启动。但它的代价是隐性的、结构性的。首先，上下文窗口是硬天花板。Claude 3.5 的 200K tokens 看似宽裕，但实际场景中，一个包含多轮对话、数次 API 响应体（尤其是返回 JSON Schema 或大段日志）、嵌入的文档片段、以及工具调用历史的 session，很容易在 30 分钟内就逼近极限。其次，截断策略是灾难源头。当窗口满了，主流做法是丢弃最老的几轮对话或最不“相关”的 token。问题在于，“相关性”由模型自己判断，而模型此时已经因上下文膨胀而变得迟钝。它可能丢掉关键的 credential scope 限制，却保留了一段无关的闲聊。更糟的是，丢失不可逆。被截掉的内容不会存档，不会落盘，就像从未存在过。你无法 query “第 17 步调用的 Slack API 返回了什么”，因为那段响应早已被滑动窗口抹去。最后，调试等于盲人摸象。当 agent 行为异常，你只能看最终输出和最后一轮输入，中间所有决策链路都是黑盒。你不知道它是基于哪个 tool 结果做的判断，也不知道某个错误的 patch 是因为读错了 Git diff 还是误解了 Jira ticket。这种架构，本质上是把运行时状态和语义理解耦合在同一个脆弱的、容量受限的、非结构化的文本容器里。它不是工程选择，是权宜之计。

2.2 Anthropic 的解法：三层分离，各司其职

Managed Agents 的核心创新，在于用清晰的边界将 agent 运行时拆解为三个正交组件：

• Session（会话）：一个持久化、不可变、时间有序的事件流。每个事件是一个结构化记录，包含 timestamp、event_type（e.g.,tool_call_requested,tool_call_completed,message_sent）、input_payload、output_payload、metadata（如 tool name, execution_id）。它存储在 Anthropic 自建的、高可用的 OLAP 存储后端，而非模型内存。这意味着 session 可以存活数天甚至数周，你可以随时 querySELECT * FROM session_events WHERE session_id = 'xxx' AND event_type = 'tool_call_completed' AND tool_name = 'notion_search'，拿到完整、精确、带时间戳的执行轨迹。更重要的是，它支持 replay：给定任意一个 event_id，系统能从那个点开始，加载当时的完整状态快照，重新执行后续所有步骤，用于 debug 或审计。

• Harness（执行器）：一个极度轻量、无状态的进程。它唯一的职责是接收一个标准化的 execute(name, input) 请求，根据 name 查找已注册的 tool definition，将 input 注入沙箱，等待执行完成，然后将结构化 output 返回。Harness 本身不保存任何 session 数据，不解析 input 语义，不决定下一步调用什么。它就是一个“管道工”，确保请求被送达、结果被取回。正因为无状态，它可以随意扩缩容、滚动更新、甚至崩溃重启——只要 session event log 完整，awake(sessionId)就能瞬间恢复执行，用户感知不到中断。这彻底解耦了“业务逻辑”（由模型和 prompt 控制）和“执行保障”（由 harness 提供）。

• Sandbox（沙箱）：一个按需创建、隔离、短暂存在的执行环境。每个 tool call 都在一个全新的、空的、最小化的 Linux microVM 中运行（底层技术类似 Firecracker）。沙箱启动时，仅注入该 tool 所需的、经过严格白名单校验的 credentials（例如，一个只读的 Notion database token），且这些 credentials 以 secure enclave 方式注入，绝不会作为环境变量暴露给沙箱内的进程。沙箱的 filesystem 是只读的基础镜像 + 一次性的 tmpfs，CPU 和内存配额硬隔离。执行完毕，沙箱立即销毁，不留任何痕迹。这解决了 credential 泄露这个生产环境的头号噩梦。想象一下，一个 agent 被 prompt engineering 诱导，执行了curl -H "Authorization: Bearer $TOKEN" https://internal-api.company.com/secrets，如果 TOKEN 是环境变量，它就直接裸奔了；而在 Managed Agents 的沙箱里，这个 curl 命令根本拿不到 TOKEN，因为沙箱进程根本看不到它。

这三层分离，精准复刻了操作系统对硬件的抽象：Session 如同文件系统，提供持久化、可寻址、可查询的“数据”；Harness 如同 CPU 调度器，提供可靠、可扩展的“计算”；Sandbox 如同内存管理单元（MMU），提供隔离、受控的“资源访问”。它们之间的接口（event schema, execute API, sandbox config）就是稳定的 ABI。未来，即使 Anthropic 把 harness 换成 Rust 编写的高性能版本，或者把 sandbox 底层从 Firecracker 切换到 WebAssembly runtimes，只要接口不变，上层 agent 的定义（YAML 或自然语言）就无需修改。这才是“稳定抽象”的真正含义——不是承诺不改代码，而是承诺不破接口。

2.3 为什么 AWS Bedrock AgentCore 是更早的“正确答案”

文章里提到一个关键事实：Amazon Bedrock AgentCore 在 2025 年底就已进入 GA（General Availability），比 Anthropic 的 Managed Agents 早了整整五个月。这不是一个次要信息，而是理解整个格局的锚点。AgentCore 同样实现了 session-as-event-log（其 EventBridge 集成天然支持事件溯源）、harness-as-function（Lambda-based execution）、sandbox-as-cattle（microVM per session）。但它更进一步：它完全框架中立。LangGraph 的 StateGraph、CrewAI 的 Crew、Strands 的 Pipeline，只要能编译成标准的 request-response 循环，就能无缝跑在 AgentCore 上。你甚至可以用它来 orchestrate a non-Claude model，比如 Bedrock 上的 Llama 3 或 Command R+。这意味着，对于一个已经深度使用 AWS 生态的企业来说，AgentCore 不是一个“需要额外学习和集成”的新服务，而是其现有云基础设施（IAM, CloudWatch, EventBridge, Lambda）的自然延伸。它的 pricing 更激进：runtime 费用被深度捆绑进 EC2 或 Lambda 的常规计费项，对很多客户而言，几乎是“免费赠送”。这印证了文章的核心论断：Anthropic 的发布，不是开创了一个新市场，而是对一个已被 hyperscaler 定义并部分占领的基础设施层，进行的一次防御性卡位。它的技术是扎实的，但它的战略位置，是追赶者，而非定义者。

3. 实操细节与落地考量：从 YAML 定义到生产监控

3.1 Agent 定义：YAML 是生产力，自然语言是入口

Managed Agents 允许你用两种方式定义 agent：一种是声明式的 YAML，一种是描述性的自然语言。我强烈建议，从 YAML 入手，哪怕你最终目标是用自然语言。YAML 强制你思考每一个关键维度，避免模糊地带。

一个典型的agent.yaml文件结构如下：

# agent.yaml name: "sales-research-agent" description: "Researches new enterprise prospects and generates briefing docs" # 核心身份与能力 system_prompt: | You are an expert sales development representative at Acme Corp. Your goal is to research potential enterprise customers in the FinTech space. You must use the tools below to gather information. Never fabricate data. # 工具注册：这是最关键的环节 tools: - name: "linkedin_company_search" description: "Search for companies on LinkedIn by industry and employee count" input_schema: type: "object" properties: industry: type: "string" description: "e.g., 'FinTech', 'Healthcare IT'" min_employees: type: "integer" description: "Minimum number of employees" # 沙箱配置：指定运行此工具所需的最小资源和凭证 sandbox_config: cpu: "vCPU-1" memory_mb: 2048 # 凭证：这里引用的是 Anthropic Vault 中预存的、名为 'linkedin-api-key' 的密钥 # 注意：密钥内容对 agent 代码完全不可见！ credentials: - vault_key: "linkedin-api-key" env_var: "LINKEDIN_API_KEY" # 仅在沙箱内部生效 - name: "notion_create_briefing" description: "Creates a structured briefing document in Notion for a prospect" input_schema: ... sandbox_config: ... # 安全护栏：防止越界行为 guardrails: # 内容安全：禁止生成恶意代码、泄露 PII content_policy: "strict" # 工具调用限制：单次 session 最多调用 5 次 linkedin 工具 tool_call_limits: linkedin_company_search: 5 # 敏感操作确认：任何涉及发送邮件的操作，必须先向用户确认 confirmation_required: - "send_email" # 会话生命周期 session_config: # 会话自动过期时间（小时） ttl_hours: 72 # 会话最大活跃时长（小时），超时自动暂停 max_active_hours: 8

这个 YAML 文件，就是你的 agent 的“源代码”。它清晰地定义了：

• What it is（system_prompt）：角色、目标、约束。
• What it can do（tools）：每个工具的输入契约、所需资源、凭证来源。
• What it must not do（guardrails）：硬性安全边界。
• How long it lives（session_config）：运维生命周期。

提示：不要试图在system_prompt里写死工具调用逻辑。那是 harness 和工具注册表的工作。prompt 只负责“意图表达”，工具注册表负责“能力映射”。混淆这两者，是导致 agent 行为不可预测的常见原因。

当你把这个 YAML 上传到 Anthropic 控制台，它会进行静态分析：检查 schema 是否有效、credential 引用是否存在、guardrail 是否冲突。通过后，agent 即刻可用。此时，你就可以用自然语言和它交互了：“帮我找 5 家员工在 500-2000 人之间的区块链支付公司，并为每家生成一份 Notion 简报。” 系统会自动解析意图，匹配到linkedin_company_search和notion_create_briefing工具，按需调度沙箱执行。自然语言是用户界面，YAML 是工程契约。两者结合，才构成完整的开发体验。

3.2 生产级监控：Trace Store 是新的“核心仪表盘”

一旦 agent 进入生产环境，p50 time-to-first-token这种指标就失去了意义。真正关键的是trace 的可观测性。Managed Agents 提供的 event log 是金矿，但你需要工具来挖掘。

我实测过几种接入方式：

• 原生控制台：Anthropic 控制台的 “Session Explorer” 提供基础的 timeline 视图，可以按 session_id 过滤，查看每个 event 的 payload。适合快速 debug 单个失败会话。但它缺乏聚合分析能力，无法回答“过去 24 小时，notion_create_briefing工具的平均成功率是多少？”或“哪些 session 因为linkedin_company_search超时而失败？”。
• EventBridge 集成：这是生产环境的推荐方案。你可以将所有 session event 流式导出到 AWS EventBridge。然后，用 Lambda 函数消费这些事件，清洗、丰富（例如，加入用户 ID、产品线标签），并写入你自己的数据仓库（如 Redshift 或 BigQuery）。这样，你就可以用 SQL 做任意维度的分析。我搭建了一个简单的 dashboard，监控三个核心指标：
  1. Session Success Rate：COUNT(session_id WHERE final_event_type = 'session_completed') / COUNT(DISTINCT session_id)
  2. Tool Call Latency Distribution：按 tool name 分组，统计 p95 延迟。我们发现notion_create_briefing的 p95 是 12s，远高于其他工具，根源是 Notion API 的 rate limit，于是我们调整了 guardrail，增加了重试逻辑。
  3. Guardrail Trigger Rate：COUNT(event WHERE event_type = 'guardrail_triggered') / COUNT(event)。这个比率突然升高，往往意味着有新的 prompt injection 攻击模式出现，或是用户开始尝试越界操作。

注意：EventBridge 集成会产生额外的费用（EventBridge 事件转发费 + Lambda 执行费），但对于一个年营收千万美元以上的 SaaS 产品，这笔投入远低于一次重大线上事故的成本。把 trace 当作第一等公民来对待，是生产级 agent 系统的分水岭。

3.3 成本精算：$0.08/小时背后的魔鬼细节

Pricing page 上写着 “$0.08 per session-hour of active runtime”，这句话有巨大的误导性。它只计算了 harness 进程实际在 CPU 上运行的时间，不包括：

• Tool Execution Time：你在沙箱里调用curl或python script.py的时间，会计入沙箱的 microVM 费用（这部分由 Anthropic 内部结算，不单独列在账单上，但会影响他们的成本模型，进而影响未来定价）。
• Idle Time：agent 在等待用户输入、或等待外部 API 响应（如 Slack webhook callback）时，harness 是暂停的，不计费。但 session 本身依然存在，其 event log 存储是免费的。
• Token Costs：这是大头。system_prompt、user_message、tool_input、tool_output、model_response全部按 Claude 的标准 token 价格计费。一个复杂的 research agent，一次 session 可能消耗数万 tokens，token 费用轻松超过 runtime 费用。

我做过一个真实案例的成本拆解（基于一个中等复杂度的销售线索生成 agent）：

• Session Runtime：平均每次 session 活跃 12 分钟（0.2 小时）→ $0.08 * 0.2 =$0.016
• Tokens：平均每次 session 处理 15,000 tokens（输入+输出）→ Claude 3.5 Sonnet 的价格是 $3/1M input tokens, $15/1M output tokens。假设输入占 60%，输出占 40%：(9000 * 3/1000000) + (6000 * 15/1000000) = $0.027 + $0.09 = **$0.117**
• Total Cost per Session：≈$0.133

这意味着，runtime 费用只占总成本的 12%。所以，当有人鼓吹 “Managed Agents 让 agent 运行更便宜” 时，你要立刻意识到：它优化的是 infrastructure cost，而不是 AI cost。真正的成本杀手，永远是模型本身的推理开销。这也是为什么，所有领先的 agent 产品（Cursor, Replit, GitHub Copilot）都在疯狂优化 token usage：用更小的模型做 routing，用 RAG 替代长上下文，用 streaming 减少等待。Managed Agents 给你提供了干净的 runtime，但如何让它“少吃” token，是你的算法工程师和 prompt 工程师的战场。

4. 竞争格局与避坑指南：别在 runtime 层押注全部身家

4.1 三大价值洼地：Trace、Governance、Vertical Marketplaces

文章里提出的“价值上移”理论，不是空谈，而是已经被市场数据反复验证的规律。我来分享几个我们团队在客户现场观察到的真实信号：

• Trace Store 的战争已经打响：我们最近帮一家大型银行评估三家 trace 平台（LangSmith, Arize Phoenix, Braintrust Brainstore）。他们的核心诉求惊人地一致：“我们要一个能跨 runtime 迁移的 trace”。这家银行的 agent 系统横跨 AWS Bedrock（用于核心金融风控）、Azure AI Foundry（用于 HR 流程自动化）和自建的 LangChain 集群（用于内部知识库）。他们要求，无论 agent 在哪个 runtime 上跑，其所有事件必须能统一写入一个 central trace store，并能用同一套 SQL 查询。LangSmith 的优势在于生态绑定（几乎所有 LangChain 用户都装了它），但它的 lock-in 风险最高；Arize Phoenix 的 Apache 2.0 开源协议让他们放心，但商业版的高级功能（如自动 root cause analysis）价格不菲；Brainstore 的 OLAP 专为 AI logs 优化，查询速度最快，但生态支持最弱。最终，他们选择了 Arize，理由是：“开源协议给了我们未来十年的自由度，而性能瓶颈，我们可以用钱买服务器来解决。” 这印证了文章观点：trace portability 是生死线，谁拥有它，谁就拥有了 runtime 层之上的护城河。

• Governance 不再是合规部门的 PPT：上个月，我们参与了一个医疗科技公司的 agent 项目招标。他们的 RFP（招标书）里有一整章叫 “Policy Enforcement Requirements”，其中一条是：“Agent 必须能强制执行 HIPAA-compliant data handling policies。例如，当 agent 识别到输入中包含 PHI（受保护的健康信息）时，必须自动触发加密流程，并将加密密钥轮换日志写入独立的 audit trail。” 这已经超出了传统 WAF 或 DLP 的能力范围。它要求 agent runtime 能深度理解语义、能动态注入 policy logic、能与密钥管理系统（如 HashiCorp Vault）实时交互。AWS AgentCore 的 Policy Controls GA，正是为了满足这类需求。目前，这个领域没有巨头，只有几家初创公司（如 Guardrails AI, PromptLayer）在快速迭代。这是一个典型的“工具薄、需求厚”的蓝海。

• Vertical Marketplaces 正在收割第一批果实：Salesforce 的 Agentforce ARR 达到 $800M，这个数字背后是 29,000 个实实在在的付费合同。我们访谈过其中一家客户——一家区域性保险公司。他们采购的不是“一个能调用 API 的 agent”，而是 “a claims processing agent that integrates with Guidewire and outputs ACORD forms”。这个 agent 的定价模式是 per-claim，而不是 per-session 或 per-token。它被当作一个可计量的业务流程组件来采购。这彻底改变了游戏规则。当客户愿意为“解决一个具体业务问题”付费时，runtime 的技术细节（是 Anthropic 还是 AWS）就变成了后台的“水电煤”。我们的一个创业朋友，正在做 “HR Onboarding Agent”，它能自动创建 Okta 账号、分配 Slack 频道、发送入职文档、安排经理 1:1。他告诉我，他的第一个客户（一家 500 人的 SaaS 公司）签的合同是 $12,000/年，按 onboarded employee 数量计费。他不需要向客户解释什么是 sandbox，他只需要证明，这个 agent 能把平均入职周期从 3 天缩短到 4 小时。这就是 vertical marketplace 的力量：它把技术复杂度封装成业务价值，把采购决策从 CTO 办公室，搬到了业务部门的预算会议桌上。

4.2 实操避坑：那些文档里不会写的血泪教训

基于我们团队在 12 个不同客户现场的落地经验，总结出三条必须牢记的铁律：

1. 永远不要信任沙箱里的“环境变量”：这是最常被忽视的安全陷阱。很多开发者习惯在沙箱里用os.getenv("API_KEY")来读取凭证。但在 Managed Agents 的沙箱中，这种方式是被明确禁止的。Anthropic 的沙箱机制，是将凭证以 secure enclave 方式注入，只对特定的、经过签名的二进制可执行文件（如notion-cli）可见。如果你的 Python 脚本试图用os.getenv读取，它会得到None。正确的做法是，让工具的 CLI 或 SDK 直接从 enclave 读取。我们曾因此导致一个关键的 Salesforce agent 连续三天无法创建 lead，排查了两天才发现是这个原因。解决方案：在工具开发阶段，就强制使用 Anthropic 提供的官方 SDK，它内部封装了 enclave 访问逻辑。

2. Session TTL 不是“过期时间”，而是“遗忘时间”：session_config.ttl_hours设置为 72 小时，意味着 72 小时后，session 的 event log 会被永久删除。但这并不意味着 agent 在 72 小时内就“一直在线”。max_active_hours才是控制 agent 活跃状态的关键。我们有个客户设置了ttl_hours=168（一周），但max_active_hours=1。结果是，agent 每次处理完一个用户请求，就会自动暂停。用户第二天回来，需要重新发起一个新 session。这完全违背了客户“保持长期对话上下文”的初衷。正确配置应该是：max_active_hours设为一个合理的、符合业务预期的值（如 8 小时），ttl_hours设为一个足够长的、用于审计和 debug 的值（如 168 小时）。

3. Guardrail 的“Strict”模式会杀死 creativity：content_policy: "strict"确实能阻止大部分有害输出，但它也会误杀大量合法的、创造性的内容。我们测试过，当 agent 被要求“为一个区块链项目设计一个代币经济模型”时，strict模式会因为模型输出中包含了 “mint”, “burn”, “supply” 等敏感词而直接拒绝响应。解决方案是采用layered guardrails：第一层是 Anthropic 的内置 content policy（处理暴力、违法等硬性红线）；第二层是自定义的、基于规则的 filter（例如，用正则匹配.*[Ss]upply.*，如果匹配，则触发人工审核，而不是直接拒绝）；第三层是 post-hoc 的 LLM-based moderation（用另一个更小、更快的模型对输出做二次评估）。这需要更多的工程投入，但换来的是业务灵活性和安全性之间的平衡。

5. 未来推演：当 self-improving agents 成为常态

文章末尾提到的 “Darwin Gödel Machine” 论文，不是一个遥远的科幻概念，而是正在发生的现实压力。那篇论文描述的 agent，能在 SWE-bench（一个衡量代码能力的基准）上，通过自我反思、自我重写代码，将成功率从 20% 提升到 50%。这个过程，需要 agent 具备三个核心能力：理解自身行为（Observability）、评估自身效果（Evaluation）、修改自身逻辑（Self-modification）。而这三者，全部依赖于一个前提：一个完整、可信、不可篡改的 trace store。

想象一下，一个金融风控 agent，它每天处理数千笔交易。某天，它通过分析自己的 trace log，发现一个模式：当交易金额在 $999-$1001 区间，且收款方名称包含 “Payroll” 字样时，其 fraud_score 的置信度会异常下降。于是，它自动修改了自己的特征工程模块，增加了一个新的特征is_payroll_adjacent_amount，并重新训练了 fraud model。这个过程，如果没有一个权威的 trace store 来记录“旧模型在何时、何地、对哪些样本做出了何种预测”，那么这次自我改进就是一场豪赌。你无法回滚，无法审计，无法向监管机构证明这次改动是安全的。

这将彻底改变 runtime 层的定位。它不再仅仅是“执行环境”，而会演变为一个“监管沙箱”（Regulatory Sandbox）。它的核心职责，将从“保证 agent 能跑起来”，升级为“保证 agent 的每一次进化，都在一个可追溯、可验证、可审计的框架内发生”。这意味着：

• Sandbox 的隔离性要求会指数级提升：未来的沙箱，不仅要隔离网络和文件系统，还要隔离 GPU 内存、甚至 CPU 的 speculative execution cache，防止 side-channel 攻击窃取训练数据。
• Trace Store 将成为法律证据：在金融、医疗等强监管行业，agent 的 trace log 将和银行的交易流水、医院的电子病历一样，成为法定的、具有司法效力的电子证据。它的存储、访问、修改，都将受到《电子签名法》等法规的严格约束。
• Governance 将从“策略”变成“宪法”：企业将不再定义 “agent 可以做什么”，而是定义 “agent 的自我进化必须遵循哪些元规则”。例如，“任何自我修改的代码，必须经过至少两名人类专家的 code review，并在 trace log 中留下 signed approval”。

Anthropic 的 Managed Agents，以及 AWS 的 AgentCore，它们今天提供的，是这个未来世界的“第一代基础设施”。它们的技术是优秀的，但它们的真正历史意义，或许不在于它们自己能走多远，而在于它们为下一代——那个由 self-improving agents 主导的世界——铺平了道路。作为一个从业者，我的体会是：与其花大力气去争论哪个 runtime 的 p95 延迟更低，不如立刻开始构建你自己的 trace pipeline，学习 OWASP Agentic Top 10 的每一条，研究 Salesforce Agentforce 的合同模板。因为当 runtime 层真的“归零”时，那些在 trace、governance、vertical contracts 上提前布局的人，手里握着的，将是下一个十年的入场券。