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 正在帮客户处理一个复杂的退货流程。它需要查询 CRM 获取该客户的订单历史API 调用 A调用库存系统确认商品是否在库API 调用 B查阅知识库中关于该 SKU 的最新退货政策RAG 检索 C综合以上信息生成一封向客户解释的邮件草稿LLM 输出 D等待客户在邮件中回复“同意”或“不同意”再执行下一步用户输入 E每一步产生的数据都会被追加到 context 中。A 的返回可能是 500 字的 JSONB 的返回是 300 字的 XMLC 的检索结果是 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 大致如下字段名类型说明session_idUUID全局唯一会话标识符timestampISO8601事件发生精确时间event_typeENUMuser_input,model_output,tool_call,tool_result,guardrail_violation等payloadJSON事件的具体内容如用户输入文本、模型输出 JSON、工具调用参数、工具返回的原始数据metadataJSON附加信息如调用的工具名称、使用的模型版本、执行耗时、trace_id这个设计带来了四个革命性的改变第一状态的“无限性”与“可靠性”分离。模型的 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 定义你的 AgentYAML 是新的“源代码”在 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 Sessioncurl -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 执行Executecurl -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 会做以下事情根据session_id从 Session Log 中拉取初始事件即initial_input。将initial_input和system_prompt一起组装成一个精简的 prompt发送给 Claude 模型。模型根据 prompt生成一个tool_call指令例如{name: transcribe_audio, args: {audio_url: https://notion-cdn.com/...}}。Harness 截获这个指令验证其合法性是否在tools列表中参数是否符合input_schema然后调用transcribe_audio工具。工具执行完毕返回一个长文本的 transcript。Harness 将这次tool_call和tool_result作为两条新的事件写入 Session Log。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-AgnosticAgentCore 不绑定任何特定的 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年KVMKernel-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其宣称的沙箱启动时间已低于 90msKubernetes 社区也成立了 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 的世界里效果极差。模型的训练目标是“生成流畅、连贯、符合语境的文本”而不是“遵守一个模糊的、未定义的‘请勿’规则”。它很容易在追求流畅性的过程中忽略掉那个软弱的“请勿”。正确做法是用正向、具体、可执行的指令来替代。例如❌ 错误“请勿泄露用户隐私信息。”✅ 正确“在生成任何输出前你必须首先扫描