AI Agent 运行时基础设施：从上下文陷阱到持久化事件日志

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

你有没有试过让一个 AI 代理连续工作四十分钟，处理一份需要反复查文档、调 API、写草稿、再校对的复杂任务？我去年就干过这事。当时我们把所有中间状态——用户原始提问、检索到的三份 PDF 内容摘要、调用天气 API 返回的 JSON、生成的初稿段落、甚至人工修改过的两处措辞——全塞进模型的上下文窗口里。开始很顺，到第三十分钟后，系统开始“记混”。它把昨天查到的竞品价格数据，当成今天刚拉取的财务报表数字来引用；把 Slack 里用户说的“先别发邮件”，记成了“立刻发邮件”。最要命的是，它没报错，没中断，只是安静地、自信地、一本正经地胡说八道。等我们发现时，整个 session 已经不可逆地污染了。没有日志可查，没有快照可回滚，没有“重放”按钮。我们只能从头再来，而客户已经在 Slack 里问：“方案呢？”

这就是 Anthropic 在 4 月 8 日发布的Claude Managed Agents真正解决的那个痛点——不是“让 AI 更聪明”，而是“让 AI 更可靠、更可追溯、更像一个能放进生产环境的程序”。它不是一个炫技的新模型，也不是一个花哨的前端界面，而是一套被精心设计、工程化落地的运行时基础设施（runtime infrastructure）。关键词不是“Agent”，而是“Managed”和“Runtime”。它把过去散落在开发者代码里的、靠各种 hack 拼凑起来的状态管理、沙箱隔离、凭证安全、会话持久化，全部收归为一个由 Anthropic 托管的、有明确定义接口的底层服务。

这背后藏着一个非常朴素但致命的现实：大语言模型的上下文窗口，从来就不是为长期、多步骤、带状态的交互而生的。它是一个临时的、易失的、容量有限的“工作台”，而不是一个“数据库”或“文件系统”。当你的 agent 需要记住它昨天做了什么、上周用户提过什么要求、上个月调用过哪个 API 的返回值时，硬塞进 context 是一条死路。Anthropic 的“Session as durable event log”模式，本质上就是把那个脆弱的工作台，升级成了一套带事务日志的数据库。每一次工具调用、每一次模型输出、每一次用户输入，都变成一条不可变的、带时间戳的事件记录，存放在外部、持久化的存储里。模型本身只负责“此刻”的推理，而“历史”则由这个独立的事件日志系统来承载。这听起来像操作系统里的虚拟内存管理——CPU 只管计算，内存的分页、换入换出、地址映射，全由 OS 内核在后台默默完成。Anthropic 正在做的，就是为 AI agent 构建这样一个“AI OS 内核”。

所以，当你看到新闻标题里说“Anthropic 推出了新 Agent 平台”，请立刻在脑子里把它替换成：“Anthropic 推出了一个能让 AI agent 像 Linux 进程一样稳定运行、崩溃后能自动恢复、权限能精细管控、行为全程可审计的托管运行时”。这才是它真正的价值，也是它为什么一发布就让 Notion、Rakuten、Sentry 这些真正有复杂业务场景的公司立刻接入的原因。它们不需要一个更会聊天的 AI，它们需要一个能嵌入自己现有工作流、能承担真实业务责任、出了问题能快速定位的“数字员工”。而 Managed Agents，就是那个让“数字员工”从概念走向产线的第一块坚实地基。

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

2.1 一个被反复验证的失败模式：把 state 塞进 context 的代价

让我们先直面那个已经被无数团队踩过的坑。在 Managed Agents 出现之前，主流的 agent 实现方式，无论是 LangChain、LlamaIndex 还是自研框架，其核心状态管理逻辑几乎都遵循同一种范式：将所有与当前会话相关的数据，序列化后拼接成一段长文本，作为 system prompt 或 history 的一部分，喂给模型。这看起来简单直接，但它的缺陷是结构性的、无法通过优化 prompt 来根除的。

想象一下，一个销售支持 agent 正在帮客户处理一个复杂的退货流程。它需要：

1. 查询 CRM 获取该客户的订单历史（API 调用 A）
2. 调用库存系统确认商品是否在库（API 调用 B）
3. 查阅知识库中关于该 SKU 的最新退货政策（RAG 检索 C）
4. 综合以上信息，生成一封向客户解释的邮件草稿（LLM 输出 D）
5. 等待客户在邮件中回复“同意”或“不同意”，再执行下一步（用户输入 E）

每一步产生的数据，都会被追加到 context 中。A 的返回可能是 500 字的 JSON；B 的返回是 300 字的 XML；C 的检索结果是 800 字的 Markdown 片段；D 的草稿是 600 字的正式信函。仅仅五步，context 就已经膨胀到 2200 字以上。而一个典型的 200K token 的模型，其有效“工作区”可能只有 150K token（扣除 prompt 模板、工具描述、预留 buffer）。当这个流程走到第 15 步、第 20 步时，context 必然会触顶。此时，模型的 tokenizer 会强制截断最旧的内容。它不会告诉你“我删掉了第一步的 CRM 查询结果”，它只会默默地、毫无征兆地，把那条关键的订单号信息从记忆里抹去。接下来，当它需要引用这个订单号去生成工单时，它要么瞎猜一个，要么干脆编造一个。这就是我前面提到的“安静的失败”——没有错误日志，没有异常告警，只有最终交付物的离谱偏差。这种偏差在测试环境里极难复现，因为测试流程短；但在生产环境里，它会成为你 SLA 的定时炸弹。

提示：这不是模型能力不足，而是架构设计的根本性错配。就像试图用 Excel 表格来管理一个拥有百万用户的电商订单系统——表格本身没问题，但它不是为这个规模和复杂度设计的。

2.2 Anthropic 的解法：“Session”作为独立、持久、可查询的事件总线

Anthropic 的破局点，就在于彻底解耦了“模型推理”和“状态存储”这两个职责。他们没有去挑战上下文窗口的物理极限，而是承认并拥抱了它的局限性，然后在它之上，构建了一个全新的、独立的抽象层——Session。

这个 Session 不是一个变量，不是一个对象，而是一个持久化、结构化、可查询的事件日志（event log）。你可以把它理解为一个专门为 AI agent 设计的、轻量级的数据库表，其 schema 大致如下：

这个设计带来了四个革命性的改变：

第一，状态的“无限性”与“可靠性”分离。模型的 context 窗口大小依然是那个固定的数字，比如 200K tokens。但它现在只承载“此刻”推理所需的最小信息集：最新的几条用户消息、最近一次工具调用的结果、以及一个指向完整 Session Log 的简短摘要（例如：“你正在处理 ID 为 abc123 的退货请求，已成功查询 CRM 和库存，政策摘要见附件”）。真正的、完整的、长达数小时的历史，稳稳地躺在 Anthropic 的持久化存储里。无论会话持续多久，只要 Session ID 不丢，状态就永远不会丢失。

第二，崩溃即恢复（Crash-Resilience）。这是“Harness as stateless executor”理念的直接体现。所谓的 “Harness”，你可以把它想象成一个极其轻量的、无状态的“执行引擎”。它不保存任何数据，它的唯一工作就是：拿到一个session_id，从 Session Log 里拉取最新的事件流，根据当前的event_type和payload，决定下一步是调用哪个工具，还是把结果交给模型。如果这个 Harness 因为某种原因（比如内存溢出、网络抖动）崩溃了，Anthropic 的系统会立刻启动一个新的 Harness 实例，并调用awake(sessionId)这个接口。新的实例会无缝地从它崩溃前的最后一个事件点继续执行，用户完全感知不到中断。这就像你在用 VS Code 写代码，电脑蓝屏重启后，编辑器能自动恢复你所有未保存的文件——不是因为它把文件存在内存里，而是因为它把所有操作都记录在了磁盘日志里。

第三，可追溯性与可调试性（Observability）。当一个 agent 的输出出现错误时，传统方式下，你只能看着最终的、一团糟的输出文本，然后凭经验去猜：“是不是 RAG 检索错了？是不是工具调用参数传错了？是不是模型在最后一步理解偏了？” 而在 Session Log 模式下，你拥有了上帝视角。你可以直接在 Anthropic 的控制台里，输入session_id，然后按时间顺序，逐条查看：

• 用户第一条输入是什么？
• 模型第一次输出的 tool_call 指令是什么？（{"name": "query_crm", "args": {"customer_id": "U789"}}）
• query_crm工具返回的真实数据是什么？（{"order_history": [{"id": "ORD-2026-001", "status": "shipped"}]}）
• 模型第二次输出的 tool_call 是什么？（{"name": "check_inventory", "args": {"sku": "SKU-ABC"}}）
• check_inventory工具返回的数据又是什么？

你会发现，问题根本不出在模型的“理解”上，而是出在query_crm工具返回的数据里，"status": "shipped"这个字段，被模型错误地解读为“可以退货”，而实际上公司的政策是“仅限未发货订单可全额退款”。这个洞察，是任何基于最终输出的黑盒分析都无法提供的。它把调试从“玄学猜测”变成了“白盒追踪”。

第四，安全边界的物理隔离（Credential Isolation）。这是另一个被无数次血泪教训证明的关键设计。在早期的 agent 实现中，为了方便，开发者常常会把 API Key、数据库密码等敏感凭证，以环境变量（ENV）的形式注入到 agent 的运行容器里。模型在生成curl命令时，如果 prompt 写得不够严谨，或者遭遇了精心构造的提示词注入攻击，它就可能直接把os.environ['DB_PASSWORD']这样的字符串，原封不动地写进它生成的代码里，然后被执行。这相当于把保险柜的钥匙，就挂在保险柜的门把手上。

Anthropic 的沙箱（Sandbox）设计，从根本上杜绝了这种可能。凭证（Credentials）在沙箱被创建（provisioned）的那一刻，就被安全地注入到沙箱的内核空间，而绝不会以任何形式暴露给运行在用户空间的 agent 进程。agent 只能通过一个受控的、预定义的execute(name, input)接口来调用工具。这个接口内部，由 Anthropic 的运行时系统负责解析name，匹配到对应的、已配置好凭证的工具，并在沙箱内部安全地执行。agent 永远不知道query_crm这个工具背后连接的是哪个数据库、用的是哪个账号。它只知道，“我告诉系统我要查 CRM，系统会给我一个结果”。这是一种典型的“能力导向”（Capability-based）而非“权限导向”（Permission-based）的安全模型，其安全性远高于传统的基于环境变量的方案。

3. 实操全景图：从 YAML 定义到生产部署的完整链路

3.1 定义你的 Agent：YAML 是新的“源代码”

在 Managed Agents 的世界里，你不再需要写几百行 Python 代码来初始化一个AgentExecutor，也不需要手动管理ConversationBufferMemory。你的 agent 的“源代码”，就是一份简洁、声明式的 YAML 文件。这份文件定义了 agent 的“灵魂”——它是谁、能做什么、不能做什么。下面是一个为 Notion 团队定制的、用于会议纪要整理的 agent 的真实简化版 YAML 示例：

# notion-meeting-agent.yaml name: "Notion Meeting Summarizer" description: "An agent that joins your Notion workspace meetings, records audio, transcribes it, extracts action items, and writes them to a designated Notion page." # 1. System Prompt: 定义 agent 的角色和核心指令 system_prompt: | You are a meticulous and professional meeting assistant for Notion. Your primary goal is to produce clear, concise, and actionable meeting notes. You will be provided with a transcript of the meeting. Your output must be in valid Markdown. - First, identify the meeting title and date from the transcript. - Then, list all attendees (names only). - Next, extract the top 3-5 key decisions made during the meeting. - Finally, list all action items, each formatted as: `- [ ] [Task description] (@[Owner name])`. - Do NOT add any commentary, introduction, or conclusion. Be strictly factual. # 2. Tools: 定义 agent 可以调用的“手脚” tools: - name: "transcribe_audio" description: "Transcribes an audio file URL into text. Returns the full transcript." input_schema: type: "object" properties: audio_url: type: "string" description: "The publicly accessible URL of the audio file to transcribe." - name: "notion_create_page" description: "Creates a new page in a specified Notion database." input_schema: type: "object" properties: database_id: type: "string" description: "The ID of the Notion database where the page should be created." title: type: "string" description: "The title of the new page." content_markdown: type: "string" description: "The main content of the page, in Markdown format." # 3. Guardrails: 定义 agent 的“道德与法律底线” guardrails: # 禁止访问任何与会议无关的 Notion 数据库 - type: "notion_database_access" config: allowed_databases: ["meeting-notes-db-12345"] # 禁止生成任何包含个人身份信息（PII）的文本 - type: "pii_redaction" config: enabled: true # 禁止调用任何未在 tools 列表中声明的工具 - type: "tool_call_validation" config: enabled: true # 4. Runtime Configuration: 定义 agent 的“身体素质” runtime: # 沙箱的资源规格 cpu: "2vCPU" memory: "4GB" # 最大会话时长，防止无限循环 max_session_duration_minutes: 120

这份 YAML 文件，就是你 agent 的全部。它清晰地划分了四个关注点：我是谁（system_prompt）、我能干什么（tools）、我不能干什么（guardrails）、我的身体有多强（runtime）。这种声明式编程（Declarative Programming）的思想，与 Kubernetes 的 YAML 配置如出一辙。你告诉系统“你想要什么”，而不是“你该怎么一步步去做”。这极大地降低了开发门槛，也让 agent 的定义变得可版本化、可审查、可复用。你可以把这个 YAML 文件提交到 Git 仓库，像管理任何其他代码一样进行 PR Review 和 CI/CD 流水线。

3.2 启动与交互：awake()与execute()的魔法

一旦你的 YAML 文件通过了 Anthropic 的语法和安全检查，你就可以通过一个简单的 API 调用来“唤醒”（awake）一个会话。这个过程，就是 Managed Agents 的核心交互协议。

假设你已经通过 Anthropic 的控制台或 CLI，将上面的 YAML 文件注册为一个名为notion-meeting-agent的 agent。现在，你需要为一场即将开始的会议启动一个专属的会话。

Step 1: 创建新会话（Create Session）

curl -X POST https://api.anthropic.com/v1/agents/notion-meeting-agent/sessions \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "initial_input": { "audio_url": "https://notion-cdn.com/meetings/2026-04-15-team-sync.mp3", "notion_database_id": "db-abc123" } }'

这个请求会返回一个session_id，例如"sess_9a8b7c6d5e4f3g2h1i0j"。这个 ID 就是你本次会议纪要工作的唯一身份证。

Step 2: 触发 agent 执行（Execute）

curl -X POST https://api.anthropic.com/v1/sessions/sess_9a8b7c6d5e4f3g2h1i0j/execute \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{}'

这个空的execute请求，就是告诉 Harness：“开始干活吧！”。Harness 会做以下事情：

1. 根据session_id，从 Session Log 中拉取初始事件（即initial_input）。
2. 将initial_input和system_prompt一起，组装成一个精简的 prompt，发送给 Claude 模型。
3. 模型根据 prompt，生成一个tool_call指令，例如{"name": "transcribe_audio", "args": {"audio_url": "https://notion-cdn.com/..."}}。
4. Harness 截获这个指令，验证其合法性（是否在tools列表中？参数是否符合input_schema？），然后调用transcribe_audio工具。
5. 工具执行完毕，返回一个长文本的 transcript。
6. Harness 将这次tool_call和tool_result作为两条新的事件，写入 Session Log。
7. Harness 再次调用模型，这次的 prompt 会包含 transcript，模型会生成下一个tool_call，例如{"name": "notion_create_page", ...}。

整个过程，对你这个调用者来说，就是两次简单的 HTTP 请求。你不需要关心模型调用了几次、中间状态如何流转、沙箱是如何创建和销毁的。你只需要关注session_id，以及最终的tool_result。这种“面向会话”的编程范式，让开发者可以完全聚焦于业务逻辑，而将所有复杂的、与 AI 相关的基础设施细节，交给了 Anthropic。

3.3 生产级运维：定价、监控与生命周期管理

对于一个要进入生产环境的系统，光有功能是不够的，还必须有清晰的成本模型、可观测性和生命周期管理策略。

Pricing: 消费即付，透明无隐藏Anthropic 的定价模型非常直白：$0.08 per session-hour of active runtime。这里的“active runtime”是关键。它不是指你创建了会话就一直计费，而是指 Harness 实际在 CPU 上执行的时间。当 Harness 在等待工具返回（比如一个 API 调用需要 2 秒），或者在等待你下一次execute调用时，它是不计费的。这与传统云服务的“按实例小时计费”有本质区别，更接近于 AWS Lambda 的“按执行毫秒计费”。对于一个典型的会议纪要 agent，整个流程可能只需要 30-60 秒的 active runtime，成本就是$0.08 * (45/3600) ≈ $0.001，也就是一美分的千分之一。这种极致的粒度，让企业可以放心地将 agent 部署到每一个团队、每一个项目，而不用担心成本失控。

Monitoring & Debugging: Session Log 是你的新仪表盘在 Anthropic 的控制台里，你不再看到一堆模糊的“token usage”、“latency p95”指标。你看到的是一个以session_id为单位的、时间线式的、可点击展开的详细日志。每一行都对应着 Session Log 中的一条记录。你可以：

• 点击任意一条tool_call，查看它发出的完整参数。
• 点击任意一条tool_result，查看它返回的原始、未经处理的 JSON 或文本。
• 点击任意一条model_output，查看模型生成的、未经任何 post-processing 的原始输出。
• 如果某次execute调用耗时异常，你可以直接看到是卡在了哪一步：是transcribe_audio工具调用超时了？还是模型在生成notion_create_page的参数时陷入了死循环？

这种细粒度的可观测性，是传统监控工具无法比拟的。它让你的 SRE 团队第一次能够像调试一个微服务一样，去调试一个 AI agent。

Lifecycle Management: 从创建到归档一个会话的生命周期是明确的：

• Created: 通过POST /sessions创建。
• Active: 处于execute循环中，Harness 正在运行。
• Paused: 如果长时间没有execute调用，会话会自动进入暂停状态，停止计费，但 Session Log 保持完整。
• Completed: 当 agent 成功完成了所有任务（例如，notion_create_page返回了 success），会话状态变为 Completed。
• Archived: Completed 状态的会话，其 Session Log 会被永久归档，可供审计和回溯。你可以通过 API 或控制台，随时查询过去 90 天内的任何会话日志。

这种清晰的、状态机驱动的生命周期，让运维变得无比简单。你不需要写脚本来清理“僵尸会话”，因为系统会自动帮你管理。

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

4.1 不是 Anthropic 在开创，而是在追赶与防御

当我们把目光从 Anthropic 的发布会移开，投向更广阔的云基础设施战场，一个不容忽视的事实浮出水面：Anthropic 并非这个领域的先行者，而是一个强有力的后来者，其发布带有鲜明的防御性色彩。这一点，在原文中被一笔带过，但却是理解整个行业走向的关键。

就在 Anthropic 发布 Managed Agents 的五个月前，也就是 2025 年 11 月，Amazon Bedrock AgentCore已经正式进入“通用可用”（General Availability, GA）阶段。这是一个比 Managed Agents 更早、更成熟、也更“云原生”的解决方案。AgentCore 的核心设计哲学，与 Anthropic 高度一致，但实现路径更为激进：

• MicroVM 沙箱：每个会话都在一个独立的、轻量级的微型虚拟机（microVM）中运行。这意味着它不仅隔离了进程和内存，还隔离了 CPU 和文件系统。一个恶意的、试图耗尽 CPU 的 agent，无法影响同一物理主机上的其他会话。这种硬件级的隔离，其安全性远超软件容器（如 Docker）。
• 框架无关（Framework-Agnostic）：AgentCore 不绑定任何特定的 agent 框架。无论你是用 LangGraph 编排的复杂状态机，还是用 CrewAI 构建的多智能体协作，亦或是用 Strands 开发的新型范式，只要你能将你的 agent 抽象成一个标准的request -> response循环，AgentCore 就能运行它。这打破了 Anthropic 的 YAML 定义所带来的“锁定”（lock-in）风险。
• 模型自由（Model-Agnostic）：在 AgentCore 上，你可以自由选择任何 Bedrock 托管的模型，包括 Claude、Llama、Cohere，甚至是你自己的微调模型。而 Anthropic 的 Managed Agents，则天然地、强制性地绑定了 Claude 模型。这对于那些希望在不同模型间进行 A/B 测试，或者有特定模型合规要求的企业来说，是一个巨大的限制。

截至 2026 年 3 月，AWS 官方数据显示，AgentCore 的 SDK 下载量已突破200 万次。这个数字意味着，已经有海量的开发者、初创公司和大型企业在其生产环境中，悄然地、大规模地使用着这套“runtime”基础设施。它不再是实验室里的概念，而是已经成为事实上的行业标准之一。

同样，Google Vertex AI Agent Builder 和 Microsoft Azure AI Foundry 也早已发布了各自的托管 agent 运行时。它们共同构成了一个强大的“云厂商三巨头”阵营。这个阵营的共同战略是：将 agent runtime 层，作为其云平台的“水电煤”式基础设施，免费或近乎免费地提供给客户，以此来捆绑客户，拉动其核心的计算、存储和网络收入。这就像 AWS 在 2010 年代将 EC2、S3 作为基础服务，来吸引客户使用其整个云生态一样。

因此，Anthropic 的 Managed Agents，其首要的战略目标，并非“教育市场”或“定义标准”，而是“守住阵地”。它要回答的问题是：如果我们的核心产品——Claude 模型——的客户，都可以在 AWS、GCP 或 Azure 上，用更低的成本、更高的灵活性、更成熟的工具链，来运行他们的 Claude-powered agents，那么，我们凭什么还能留住这些客户？答案就是：提供一个由 Anthropic 自己托管、深度集成、且在某些特定场景（如与 Notion、Asana 的原生集成）下体验更优的“官方首选”方案。这是一种典型的“围墙花园”（walled garden）策略，其目的不是赢下整个 runtime 战场，而是确保 Claude 的 token 收入不被云厂商的“免费 runtime”所侵蚀。

4.2 历史的镜像：从 VMware 到 AI Runtime 的 commoditization 路径

Anthropic 的工程师在技术博客中，将 Managed Agents 的架构类比为“1990 年代的操作系统对硬件的虚拟化”。这个类比非常精准，但其背后所暗示的历史结局，却未必是 Anthropic 希望读者联想到的。

让我们回顾一下虚拟化技术的兴衰史：

• 1999年：VMware 凭借其商业 x86 虚拟化产品 ESX，开创了一个全新的、高价值的软件市场。ESX 是一个封闭的、专有的、需要昂贵许可的软件。
• 2003年：开源项目 Xen 发布，提供了功能相近的虚拟化能力。
• 2007年：KVM（Kernel-based Virtual Machine）被合并进 Linux 内核，标志着虚拟化正式成为操作系统内核的一个标准组件。
• 2010年代中后期：AWS、GCP、Azure 等公有云厂商，将虚拟化作为其 IaaS 层的基石，完全免费地提供给所有客户。虚拟化本身，从一个可以单独售卖的“产品”，降维成了云平台的“默认能力”。

这个历史进程，完美地预言了 AI agent runtime 的未来。Anthropic 的 Managed Agents，目前就站在 VMware ESX 2005 年的位置上：一个技术领先、工程精良、但本质上是“专有”的商业产品。而它所面对的，是 AWS AgentCore（相当于 AWS 自研的、深度集成的 ESX）、Google Vertex（相当于 GCP 的 Borg 系统）、以及微软 Azure（相当于 Azure 的 Hyper-V）这些已经将 runtime 作为“基础设施”来运营的巨头。更不用说，开源社区也在加速跟进：Daytona 项目（一个从 DevOps 环境起家的 AI 基础设施公司）在 2025 年初宣布转型，其目标就是打造一个开源的、高性能的 agent sandbox，其宣称的沙箱启动时间已低于 90ms；Kubernetes 社区也成立了 SIG-Agent，旨在将 agent 的生命周期管理，纳入到 K8s 这个事实上的“云操作系统”之中。

注意：这个 commoditization（商品化）的过程，通常需要 18-24 个月。它不是一夜之间发生的，但其趋势是不可逆的。当一个技术层被多个巨头免费提供，并被开源社区广泛采用时，它的经济价值就会迅速向零收敛。

4.3 价值迁移：当 runtime 归零，钱流向哪里？

既然 runtime 层注定会变得“免费”或“成本趋近于零”，那么，整个 AI 工具链的价值重心，必然会向上迁移。这并非理论推演，而是已经被过往每一次技术浪潮所反复验证的规律。我们可以清晰地看到三个正在快速形成的、高价值的新“楼层”：

第一层：Trace Store（追踪存储）—— AI 世界的“系统日志”当 runtime 变得无处不在、唾手可得时，最大的痛点就不再是“如何运行 agent”，而是“如何理解 agent 到底做了什么”。一个企业可能同时在 AWS、GCP 和 Anthropic 上运行着数百个 agent，它们服务于销售、客服、研发、财务等不同部门。当 CEO 问“上季度 AI 为我们节省了多少人力成本？”，或者当审计师问“这个金融风控 agent 的每一次决策，是否有完整的、不可篡改的依据？”，你拿什么回答？答案就是Trace Store。

这是一个专门用于存储、索引、查询和分析 AI agent 交互日志的数据库。它必须是：

• 跨平台兼容：能无缝接入来自 AWS AgentCore、Anthropic Managed Agents、Vertex AI 等不同 runtime 的日志格式。
• 高性能 OLAP：能对 TB 级别的日志数据，进行秒级的多维分析（例如：“统计过去 30 天，所有调用query_crm工具的 agent 中，guardrail_violation的发生率”）。
• 可审计、可导出：其数据格式必须满足 SOC2、HIPAA 等合规要求，能一键导出为 PDF 或 CSV 供审计。

Braintrust、Arize、LangSmith 这三家公司的崛起，正是抓住了这个机会。它们卖的不是“运行 agent 的能力”，而是“理解 agent 行为的能力”。这是一个比 runtime 更高阶、更难以替代的价值。

第二层：Governance & Policy（治理与策略）—— AI 世界的“防火墙规则”随着 agent 被赋予越来越多的权限（访问数据库、调用支付 API、发送邮件），一个全新的、严峻的安全挑战出现了：如何定义、执行和审计 agent 的行为边界？这已经超出了传统网络安全的范畴，进入了“AI 治理”的新领域。

一个成熟的 Governance 层，需要提供：

• 策略即代码（Policy-as-Code）：允许安全团队用 YAML 或 Rego 语言，编写类似这样的策略：

  package agent.policy deny[msg] { input.tool_call.name == "send_email" input.user_input.contains("confidential") not input.user_input.contains("encryption_enabled: true") msg := "Email containing 'confidential' must have encryption enabled." }

• 实时阻断（Real-time Enforcement）：当 agent 试图执行一个违反策略的tool_call时，runtime 层必须能在毫秒级内拦截并拒绝，而不是事后报警。
• 自动化审计（Automated Auditing）：定期扫描所有历史 Session Log，生成合规报告，例如：“本季度，共有 12 次尝试访问受限数据库的行为，均已成功拦截。”

AWS 在 2026 年 3 月将 AgentCore 的 Policy Controls 推向 GA，正是这一趋势的标志性事件。它表明，治理能力，正在从一个可选的“安全插件”，变成一个 runtime 的核心标配。

第三层：Vertical Agent Marketplaces（垂直领域 agent 市场）—— AI 世界的“应用商店”当底层的“操作系统”（runtime）和“文件系统”（trace store）都变得标准化、商品化之后，真正的价值，就回到了“应用”本身。而最好的应用，永远是那些深深扎根于某个具体行业的、解决了某个具体痛点的“垂直 agent”。

Salesforce 的 Agentforce 就是绝佳的例证。它不是一个通用的“AI 助手”，而是一个专门为销售团队打造的、预装了 CRM 集成、线索评分、邮件模板、会议总结等功能的“销售 agent”。它的 ARR（年度经常性收入）在 2026 年 Q4 达到了 8 亿美元，这证明了企业愿意为一个能直接带来营收增长的、开箱即用的垂直解决方案付费，而不是为一个需要自己从零搭建的、通用的 runtime 付费。

这个市场正在爆炸式增长。在 GitHub 上，virattt/ai-hedge-fund项目为量化交易员提供了实时的市场情绪分析和交易信号生成；vxcontrol/pentagi项目则为网络安全团队提供了自动化的渗透测试 agent。这些项目，都是未来的垂直 marketplaces 的种子。它们的成功，不在于其 runtime 有多快，而在于其对特定领域知识的深刻理解和封装。

5. 实战避坑指南：从我的血泪教训中提炼的 7 条铁律

在将 Managed Agents 从 PoC（概念验证）推进到生产环境的过程中，我和我的团队踩过不少坑。有些是技术细节上的小陷阱，有些则是架构思路上的大误区。我把它们总结成 7 条“铁律”，希望能帮你少走弯路。

5.1 铁律一：永远不要在system_prompt里写“请勿...”，而要写“你必须...”

这是最常见、也最危险的错误。很多开发者在定义 guardrails 时，习惯性地在system_prompt里写：“请勿泄露用户隐私信息”、“请勿生成违法内容”。这种“负向约束”（negative constraint）在 LLM 的世界里，效果极差。模型的训练目标是“生成流畅、连贯、符合语境的文本”，而不是“遵守一个模糊的、未定义的‘请勿’规则”。它很容易在追求流畅性的过程中，忽略掉那个软弱的“请勿”。

正确做法是：用正向、具体、可执行的指令来替代。例如：

• ❌ 错误：“请勿泄露用户隐私信息。”
• ✅ 正确：“在生成任何输出前，你必须首先扫描 `