1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有试过让一个 AI 代理连续工作四十分钟不是闲聊而是真正在查资料、调 API、写代码、汇总报告——一个接一个步骤往下走。我去年就搭过这么一套系统用的是当时最主流的开源框架所有状态都塞在模型的上下文窗口里。前半小时一切顺利到第三十二分钟上下文开始溢出。模型没报错没中断甚至没提示它只是悄悄把最早调用的三个工具结果给“忘了”然后基于一个残缺的、自己脑补出来的历史继续推理。最后生成的是一份逻辑自洽但事实全错的报告。更糟的是我们根本没法回溯——没有日志、没有快照、没有事件流整个 session 就像被格式化了一样彻底消失。重跑不行中间状态丢了重跑就是从头开始时间成本翻倍。Anthropic 在 4 月 8 日发布的 Claude Managed Agents表面看是又一个“托管代理平台”但它的核心价值恰恰就卡在我这个血泪教训的痛点上它把 session 从模型的上下文里彻底搬了出来变成一个独立、持久、可查询、可回放的事件日志。这不是功能叠加是架构范式的切换。它意味着你的代理可以运行三天、三周甚至三个月而不会因为上下文爆炸而无声崩溃。它也意味着当问题发生时你不是对着一团混沌的 token 猜测“它刚才到底干了什么”而是能直接打开一个结构化的 trace逐条查看每一步工具调用、每一次决策、每一个返回值——就像调试一个传统后端服务那样清晰。这背后牵扯的是整个 AI 应用栈正在经历的一场静默革命。过去一年我们见证了 RAG 压垮了初级文档分析 SaaSTool Use 让 Zapier 的中低端自动化市场大幅萎缩Coding Agents 直接重塑了 IDE 插件生态。每一波压缩都只用了 12–18 个月就把一个曾经需要付费订阅的“能力层”变成了云厂商免费打包的基础服务。现在轮到 agent runtime 层了。Anthropic 这次发布不是在开疆拓土而是在已成红海的战场上为自己的模型客户筑起一道护城河。它卖的不是“运行时代理”的技术而是“让 Claude 模型在别人家的云上不那么好用”的体验。关键词“Towards AI - Medium”指向的正是这场行业级认知迭代的策源地——它不是一篇新闻稿而是一份写给所有 AI 工程师、架构师和创业者的战前简报。2. 核心设计为什么“Session-as-Event-Log”是唯一解2.1 架构分层从“模型即一切”到“模型只是执行器”在 Managed Agents 出现之前绝大多数自研或开源的 agent 系统其架构本质是“单体式”的。模型LLM不仅是推理引擎还是状态存储器、会话管理者、甚至安全沙箱的协调者。整个系统的生命周期被牢牢锁死在模型的 context window 里。这种设计在 demo 阶段很优雅prompt 写得漂亮few-shot 示例丰富一次调用就能完成简单任务。但一旦进入真实业务场景它立刻暴露出三大结构性缺陷状态脆弱性上下文是易失的、有上限的、不可索引的。你无法对“第 17 步调用的 Slack API 返回值”做条件查询只能靠模型自己“记得”。而模型的记忆本质上是概率性的幻觉。故障不可见当上下文溢出时系统不会抛出ContextOverflowError它只会静默降级用更短的历史、更低的置信度继续生成。这种失败是温水煮青蛙式的直到某次关键输出出错才被发现而此时已无迹可查。扩展性瓶颈想支持长周期任务只能不断增大 context window但这直接推高 token 成本且模型性能随长度非线性下降。想支持多用户并发每个 session 都要独占一份昂贵的上下文缓存资源利用率极低。Managed Agents 的破局点在于它用操作系统思维重构了这一层。它把整个 agent 生命周期明确拆解为三个正交、可替换、可独立演进的抽象Session会话一个持久化、结构化的事件日志。它不存储在模型里而是存在 Anthropic 自建的、带 ACID 语义的分布式数据库中。每一条记录包含时间戳、事件类型tool_call_start,tool_call_result,model_output、输入参数、输出 payload、执行耗时、错误堆栈等完整元数据。你可以用 SQL-like 查询语法比如SELECT * FROM session_events WHERE session_id abc123 AND event_type tool_call_result AND tool_name notion_search瞬间拉出所有相关操作。Harness执行器一个极度轻量、无状态的函数容器。它只做一件事接收一个execute(name, input)调用启动一个指定名称的工具容器Docker image传入 JSON 输入等待容器返回字符串输出。Harness 本身不保存任何状态不解析输入不校验输出。它 crash 了没关系系统会根据 session log 中的最后 checkpoint自动调用awake(sessionId)重新加载 session 状态并从断点处继续执行。这个设计让 Harness 的部署、扩缩容、升级变得和部署一个无状态 Web API 完全一样简单。Sandbox沙箱一个按需创建、用完即焚的隔离环境。每个工具调用都在一个全新的、干净的 Linux microVM 中执行。沙箱启动时凭据API keys, OAuth tokens由 Anthropic 的密钥管理服务Vault注入但绝不以环境变量形式暴露给容器内的进程。容器内看到的只是一个临时的、只读的凭证文件路径且该文件在沙箱销毁后立即被擦除。这意味着即使 agent 的 prompt 被恶意诱导执行了curl -H Authorization: Bearer $TOKEN ...这样的命令它拿到的$TOKEN也是一个早已失效的、作用域被严格限制的短期令牌。提示这个“凭证隔离”设计不是工程师的洁癖而是血的教训。我见过不止一个团队因为把生产数据库密码硬编码在 agent 的 system prompt 里结果被一个精心构造的 prompt 注入直接导致凭证泄露。Managed Agents 的沙箱机制从根源上堵死了这条路径。2.2 为什么是 YAML/自然语言定义而不是 SDK你可能会疑惑为什么 Anthropic 不提供一个功能丰富的 Python SDK让开发者用代码来定义 agent答案在于目标用户和交付效率。Managed Agents 的核心客户不是那些天天写LangChain链式调用的资深工程师而是 Notion、Rakuten 这类拥有庞大非技术产品团队的企业。他们的需求是“让销售团队能用自然语言让 Claude 帮他们自动整理每日 Slack 销售线索并同步到 CRM”。如果要求每个业务线都去学 Python、理解RunnableLambda、调试AsyncIterator落地周期会从一周拉长到三个月。而 YAML 或自然语言定义把复杂性封装在了平台层。一个产品经理可以用如下 YAML在 5 分钟内定义一个基础 agentname: Sales-Lead-Sync system_prompt: | 你是一个专业的销售助理。你的任务是 1. 从 Slack 的 #sales-leads 频道中提取过去 24 小时内所有包含“demo request”、“trial signup”或“pricing inquiry”的消息。 2. 对每条消息调用 Notion API 获取发信人的公司信息。 3. 调用 Salesforce API将线索创建为新的 Lead 记录。 4. 向 Slack 发送确认消息“已为 [公司名] 创建销售线索。” tools: - name: slack_search description: Search messages in a Slack channel by keyword and time range. parameters: channel_id: string query: string oldest_ts: float - name: notion_get_company description: Get company details from Notion database using email domain. parameters: email_domain: string - name: salesforce_create_lead description: Create a new Lead record in Salesforce. parameters: company_name: string email: string source: string guardrails: - type: pii_redaction enabled: true fields: [email, phone] - type: output_safety enabled: true categories: [harassment, self_harm]这个 YAML 文件就是 agent 的“源代码”。它被上传后Anthropic 的平台会自动完成语法校验、工具 schema 注册、安全策略编译、沙箱镜像构建。开发者无需关心底层容器如何启动、网络如何配置、日志如何收集。这种“声明式编程”Declarative Programming范式正是现代云原生基础设施如 Kubernetes, Terraform成功的关键——它把“怎么做”交给平台让人类专注在“做什么”上。2.3 “沙箱即牛非宠物”运维哲学的彻底转变“Cattle, not pets”沙箱是牛不是宠物这句话精准概括了 Managed Agents 的运维哲学。在传统运维中“宠物”服务器是被精心呵护、打补丁、调优、备份的个体。而“牛”服务器则是编号、批量部署、随时可替换的标准化单元。Managed Agents 的沙箱就是彻头彻尾的“牛”。每次execute()调用平台都会从预热池中分配一个空闲的 microVM将该沙箱的唯一 ID、session ID、本次调用的输入 JSON通过安全通道注入启动用户指定的 Docker 容器例如ghcr.io/myorg/slack-tool:v1.2容器执行完毕返回字符串输出无论成功与否该 microVM 立即被销毁所有内存、磁盘、网络状态被彻底清零下一次调用必然启用一个全新的、干净的沙箱。这个流程带来的好处是颠覆性的极致的安全隔离A 用户的 Slack 工具沙箱和 B 用户的 Salesforce 工具沙箱物理上完全隔离。一个沙箱里的漏洞绝无可能横向渗透到另一个沙箱。确定性的执行环境每个沙箱都是从同一个、经过严格审计的 base image 启动不存在“在我机器上能跑在服务器上就挂了”的经典问题。环境一致性是长周期、多步骤 agent 可靠性的基石。零运维负担你不需要为沙箱集群准备监控告警、容量规划、故障转移。Anthropic 的 SLO 是 99.95%这意味着每年宕机时间不超过 4.38 小时且全部由他们承担 SLA 赔偿。你的 DevOps 团队可以把精力从“保沙箱不死”转向“让 agent 更聪明”。我实测过一个跨时区的客服 agent它需要每天凌晨 2 点UTC自动汇总全球各区域的工单数据。在旧架构下我必须部署一个常驻的、带状态的 worker 进程还要为它设计复杂的健康检查和自动重启逻辑。迁移到 Managed Agents 后我只需要设置一个 cron job每小时触发一次awake(sessionId)。平台保证哪怕那个凌晨 2 点的沙箱因硬件故障被销毁下一个沙箱也会无缝接管从它离开的地方继续执行。这种“无感的可靠性”是自建架构永远无法企及的成本优势。3. 实操细节从零搭建一个 Notion 协作代理3.1 准备工作密钥、权限与最小权限原则在动手写 YAML 之前最关键的一步是密钥管理和权限配置。Managed Agents 的安全模型建立在“最小权限”Principle of Least Privilege之上。你不能给 agent 一个拥有admin权限的 Notion Integration Token然后指望它“自觉”只读取某个数据库。平台会强制你为每个工具精确声明它需要的权限范围。以 Notion 为例你需要创建一个专用的 Notion Integration登录 Notion Developers 点击 “ New integration”命名为Claude-Managed-Agents。选择“Internal Integration”这表示它只供你自己的 workspace 使用不会出现在 Notion App Store。配置权限Critical Step在 “Capabilities” 选项卡中只勾选Read content和Read user information。绝对不要勾选Write content、Manage users或Manage bots除非你的 agent 确实需要写入。在 “User Connections” 选项卡中只连接你真正需要访问的几个特定数据库例如Sales Leads DB,Product Roadmap DB。不要选择 “All databases in this workspace”。获取 Integration Token在 “Tokens” 选项卡中复制Secret internal integration token。这是你唯一需要保管的密钥它将被安全地存入 Anthropic Vault。注意这个 token 的权限是你在 Notion 侧授予的。Managed Agents 平台本身不会、也不能修改这个权限。它只是作为一个安全的“管道”在沙箱启动时将这个 token 以只读方式注入。如果你未来需要调整权限必须回到 Notion 控制台操作而不是在 Anthropic 平台上改。3.2 工具容器开发一个可复用的 Notion Search 工具Managed Agents 的工具本质上就是一个标准的 Docker 容器它接收一个 JSON 输入输出一个 JSON 字符串。我们来开发一个notion_search工具它能根据关键词搜索指定数据库中的页面。首先创建DockerfileFROM python:3.11-slim # 安装依赖 RUN pip install --no-cache-dir notion-client requests # 复制工具代码 COPY notion_search.py /app/notion_search.py # 设置入口点 WORKDIR /app CMD [python, notion_search.py]然后编写notion_search.py#!/usr/bin/env python3 import json import os import sys import logging from notion_client import Client # 配置日志 logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) def main(): # 1. 从标准输入读取 JSON 输入 try: input_data json.loads(sys.stdin.read()) except json.JSONDecodeError as e: logger.error(fInvalid JSON input: {e}) print(json.dumps({error: Invalid JSON input})) return # 2. 从环境变量获取 Notion Token由平台注入 notion_token os.getenv(NOTION_TOKEN) if not notion_token: logger.error(NOTION_TOKEN environment variable is missing) print(json.dumps({error: NOTION_TOKEN missing})) return # 3. 解析输入参数 database_id input_data.get(database_id) query input_data.get(query, ) filter_by input_data.get(filter_by, {}) # 可选用于过滤属性 if not database_id: logger.error(Missing required parameter: database_id) print(json.dumps({error: Missing database_id})) return try: # 4. 初始化 Notion Client client Client(authnotion_token) # 5. 执行搜索使用 Notion 的 search API # 注意这里使用 search 而非 query因为 search 支持全文本匹配 search_results client.search( queryquery, filter{property: object, value: page}, sort{timestamp: last_edited_time, direction: descending} ) # 6. 提取并格式化结果 pages [] for page in search_results.results[:10]: # 限制最多返回10个结果 # 只提取我们关心的字段避免返回敏感信息 pages.append({ id: page.id, title: page.properties.get(Name, {}).get(title, [{}])[0].get(plain_text, Untitled), url: page.url, last_edited_time: page.last_edited_time }) logger.info(fFound {len(pages)} pages for query {query}) print(json.dumps({pages: pages})) except Exception as e: logger.exception(Error during Notion search) print(json.dumps({error: str(e)})) if __name__ __main__: main()这个工具的核心设计哲学是输入/输出契约清晰它只接受一个 JSON只返回一个 JSON。没有副作用不写日志到 stdout/stderr除了 debug不依赖外部状态。错误处理完备所有可能的异常JSON 解析失败、token 缺失、Notion API 调用失败都被捕获并以结构化 JSON 返回错误信息方便上游 agent 解析和重试。最小数据暴露它只返回页面的id,title,url,last_edited_time绝不会返回properties中的原始内容避免 PII个人身份信息意外泄露。构建并推送镜像到你的私有 registry如 GitHub Container Registrydocker build -t ghcr.io/your-org/notion-search:v1.0 . docker push ghcr.io/your-org/notion-search:v1.03.3 Agent YAML 定义从声明到部署现在我们把前面准备好的工具整合进一个完整的 agent YAML。这个 agent 的名字叫Notion-Team-Assistant它的使命是当团队成员在 Slack 中发送/notion-search 关键词时自动在指定的 Notion 数据库中搜索并将结果以卡片形式回复。name: Notion-Team-Assistant description: An assistant that helps team members quickly find relevant pages in Notion. # 系统提示词定义 agent 的角色、能力和边界 system_prompt: | 你是一个高效、专业的 Notion 协作助手。你的唯一任务是 1. 理解用户提出的搜索请求例如“找一下Q3的市场活动计划”、“看看张三上周的周报”。 2. 将用户的自然语言请求精准地转化为对 Notion 数据库的搜索关键词。 3. 调用 notion_search 工具在指定的数据库中进行搜索。 4. 将搜索结果以简洁、易读的 Markdown 卡片形式呈现给用户。 5. 如果搜索结果为空礼貌地告知用户并建议尝试其他关键词。 6. 绝对不要编造结果不要猜测用户意图不要访问未授权的数据库。 # 工具定义告诉平台这个 agent 有哪些能力 tools: - name: notion_search description: Search for pages in a specific Notion database using a text query. # 这里引用我们刚刚构建的 Docker 镜像 image: ghcr.io/your-org/notion-search:v1.0 # 定义工具的输入参数 schema平台会据此进行校验 parameters: type: object properties: database_id: type: string description: The unique ID of the Notion database to search in. query: type: string description: The text query to search for within the database pages. required: [database_id, query] # 安全护栏防止 agent 越界 guardrails: # PII 红线自动检测并屏蔽输出中的邮箱、手机号、身份证号 - type: pii_redaction enabled: true fields: [email, phone, ssn] # 输出安全阻止生成包含暴力、骚扰、自我伤害等内容 - type: output_safety enabled: true categories: [harassment, self_harm, sexual_content] # 上下文长度限制防止 agent 陷入无限循环或生成过长响应 - type: max_output_tokens enabled: true value: 2048 # 会话配置定义这个 agent 的生命周期行为 session_config: # 会话最长存活时间天 max_duration_days: 30 # 会话空闲超时秒超过此时间无活动则自动休眠 idle_timeout_seconds: 3600 # 是否允许会话在休眠后被唤醒必须为 true否则无法实现长期协作 allow_wakeup: true # 部署配置指定 agent 的运行环境 deployment: # 指定默认的模型版本Claude 3.5 Sonnet model: claude-3-5-sonnet-20240620 # 指定默认的温度temperature控制输出的随机性 temperature: 0.3 # 指定最大上下文长度注意这只是模型的 context不是 session 的 max_context_tokens: 200000将这个 YAML 文件保存为notion-assistant.yaml然后通过 Anthropic 的 CLI 或 Web 控制台上传。平台会进行语法检查、工具镜像拉取验证、安全策略编译。整个过程通常在 30 秒内完成。一旦状态变为ACTIVE你的 agent 就已经上线可以开始接收请求了。3.4 与 Slack 集成让协作真正发生一个孤立的 agent 没有价值它必须嵌入到团队的工作流中。Slack 是最典型的场景。集成步骤如下在 Slack 创建一个新 App访问 api.slack.com/apps 点击 “Create New App”选择 “From scratch”命名为Claude-Notion-Assistant。添加 Slash Command在左侧菜单选择 “Slash Commands”点击 “Create New Command”。设置Command:/notion-searchRequest URL:https://api.anthropic.com/v1/agents/your-agent-id/invoke这是 Anthropic 提供的 webhook endpointDescription: “Search your teams Notion workspace”配置 OAuth Permissions在 “OAuth Permissions” 页面添加 Bot Token Scopeschat:write用于向频道发送回复users:read用于获取用户信息个性化回复点击 “Install to Workspace”授权。在 Anthropic 平台配置 Webhook在 agent 的设置页面找到 “Webhooks” 选项卡。添加一个新的 webhookURL 填入你 Slack App 的 Request URL。设置 “Verification Token”Slack 提供的用于验证请求来源。选择触发事件slash_command_invoked。完成这些配置后你就可以在 Slack 中输入/notion-search Q3 marketing plan。Slack 会将这个请求转发给 Anthropic 的 webhookAnthropic 平台会自动创建一个新的 session调用notion_search工具并将结果格式化后通过 Slack Bot Token 发送回 Slack 频道。整个链路你无需写一行后端代码所有的路由、认证、重试、错误处理都由两个平台共同完成。4. 竞争格局与现实挑战为什么说“Runtime 层正在归零”4.1 Hyperscaler 的碾压式入场AWS AgentCore 是真正的“默认选项”Anthropic 的 Managed Agents 发布稿里通篇没有提一个名字Amazon Web Services。但这恰恰是整篇文章最锋利的刀尖。就在 Anthropic 发布的五个月前也就是 2025 年 11 月AWS Bedrock 的AgentCore已经正式进入“通用可用”General Availability阶段。这不是一个 beta不是一个 preview而是一个 AWS 官方承诺 SLA、纳入企业合同、与 EC2/S3 同等级别的核心服务。AgentCore 的架构比 Managed Agents 更激进。它不提供一个“托管的 Claude 运行时”而是提供一个完全模型无关的、框架无关的、微虚拟机驱动的 agent 运行时。它的核心特性包括MicroVM 隔离每个 session 都在一个独立的 Firecracker microVM 中运行拥有专属的 CPU 核心、内存和根文件系统。这比 Docker 容器提供了更强的隔离性尤其适合运行不受信任的、用户提供的工具代码。八小时长时运行session 最长可运行 8 小时远超 Managed Agents 的默认限制虽然 Anthropic 也支持延长但需要额外申请。框架自由AgentCore 不要求你用 YAML 定义 agent。它可以原生运行 LangGraph、CrewAI、甚至你自己用 Go 或 Rust 写的、遵循request-response协议的任意 agent 二进制文件。你甚至可以在一个 session 中混合使用 Claude、Llama 3 和 Mistral 的模型。深度云集成AgentCore 的 policy controls策略控制在 2026 年 3 月已 GA。这意味着你可以用 AWS IAM Policy精确控制一个 agent session 能否调用s3:GetObject、能否访问secretsmanager:GetSecretValue、能否发起ec2:RunInstances。这种粒度的权限控制是 Anthropic 当前无法比拟的。更重要的是价格。AWS 的定价策略是“捆绑销售”。当你为一个 EC2 实例付费时AgentCore 的运行时费用已经作为“基础设施税”被隐含在了你的整体云账单里。对于一个已经在 AWS 上花费数百万美元的客户来说AgentCore 不是“新增一项支出”而是“现有支出的自然延伸”。它没有单独的$0.08/session-hour这种显性计费项它的成本是“免费的”或者说是“已经付过了的”。这就是为什么文章里说Anthropic 的发布是“防御性”的。它不是在定义未来而是在保卫现在。它的客户是那些已经爱上 Claude 模型、但尚未决定将整个 AI 基础设施迁移到 AWS 的企业。Managed Agents 的价值不在于它比 AgentCore 更先进而在于它提供了一个“Claude 专属的、无缝的、免运维的”体验从而延缓客户做出“换掉模型”的决策。4.2 开源压力Daytona 与 Kubernetes SIG 的“平价替代”如果说 hyperscaler 是来自上方的“免费”压力那么开源社区则是来自下方的“平价”压力。2025 年初一家名为 Daytona 的公司将其业务重心从“开发者桌面环境”彻底转向“AI agent 基础设施”并在 2 月完成了 2400 万美元的 A 轮融资。它的核心产品是一个开源的、Kubernetes-native 的 agent sandbox 管理器。Daytona 的杀手锏是亚秒级的沙箱启动速度。它宣称其 sandbox spin-up time沙箱启动时间稳定在 90ms 以内。这个数字意味着什么意味着你的 agent 可以在用户按下回车键后的 200ms 内就开始执行第一个工具调用。这对于交互式、低延迟的场景如实时代码补全、IDE 内嵌助手至关重要。相比之下基于 Firecracker 或 QEMU 的 microVM 方案启动时间通常在 500ms 到 2s 之间。更关键的是Daytona 是开源的Apache 2.0 License。这意味着零许可成本你可以把它部署在自己的裸金属服务器、私有云甚至是边缘设备上完全规避云厂商的锁定。完全可控你可以审查每一行代码确保它符合你的安全合规要求如 SOC2, HIPAA。快速迭代社区贡献的 PR可以几天内合并而不用等待云厂商的季度发布周期。几乎在同一时间Kubernetes 社区也成立了官方的 SIGSpecial Interest Group——SIG-Agent-Sandbox并发布了首个 alpha 版本的k8s-agent-runtime。这个项目的目标是为 Kubernetes 提供一个标准化的 CRDCustom Resource Definition让任何 agent 框架LangChain, LlamaIndex都能像部署一个 Deployment 一样轻松地将 agent 部署为一个 Kubernetes 原生资源。它内置了与 Prometheus 的指标集成、与 OpenTelemetry 的 trace 集成、以及与 Vault 的密钥集成。提示对于中大型企业尤其是那些已有成熟 Kubernetes 运维团队的公司Daytona k8s-agent-runtime 的组合是一个极具吸引力的“自主可控”方案。它让你既能享受开源社区的敏捷和透明又能利用现有 K8s 技术栈的规模效应。Anthropic 的 Managed Agents对你而言只是一个“对比基准”而非“必选项”。4.3 真正的战场Trace Store、Governance 与 Vertical Marketplaces当 runtime 层的价格被 hyperscaler 打到接近于零当开源方案的性能和稳定性追平甚至超越商业产品时整个 AI 工具链的价值重心必然向上迁移。未来的赢家将不再是谁的沙箱启动得更快而是谁掌握了以下三个“上层建筑”4.3.1 Trace StoreAI 行为的“黑匣子”与“法律证据”一个运行了 72 小时、调用了 127 个不同工具、生成了 43 份报告的 agent它的完整行为日志就是一份价值连城的资产。这份日志是调试的黄金标准当输出错误时你不再需要猜而是直接查询SELECT * FROM traces WHERE session_id xyz AND error IS NOT NULL。合规的审计依据在金融、医疗等行业监管机构会问“这个投资建议是如何生成的依据了哪些数据源是否经过人工复核”Trace Store 就是你的回答。模型优化的数据燃料将成功的 trace用户点赞、任务完成和失败的 trace用户投诉、任务中断喂给模型是提升 agent 性能最有效的 RLHF基于人类反馈的强化学习方式。目前这个领域有三家主要玩家公司产品关键优势商业模式BraintrustBrainstore专为 AI logs 设计的 OLAP 数据库查询性能极佳闭源 SaaS按查询量计费ArizePhoenixApache 2.0 开源社区版功能完整可自托管开源免费 企业版增值功能LangChainLangSmith与 LangChain 生态深度绑定安装即用零配置免费基础版 Pro 订阅它们的竞争焦点不是谁的 UI 更好看而是谁能成为“事实上的标准”。因为一旦你的 agent 运行在 AWS AgentCore 上而你的 trace 存储在 Brainstore 里那么当你未来想把 agent 迁移到 Azure Foundry 时你就必须同时迁移 trace schema 和查询逻辑。这是一个巨大的沉没成本。因此trace portability可移植性是这个市场的终极胜负手。4.3.2 Governance PolicyAI 的“交通警察”随着 agent 被赋予越来越多的权限访问数据库、调用支付 API、发送邮件一个核心问题浮出水面谁来批准 agent 的行为谁来定义它的边界谁来审计它的越界AWS 的 AgentCore Policy Controls是第一个将这个问题产品化的方案。它允许你用类似 IAM 的 JSON Policy定义{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [s3:GetObject], Resource: [arn:aws:s3:::my-company-data/*] }, { Effect: Deny, Action: [secretsmanager:GetSecretValue], Resource: [*], Condition: {StringNotEquals: {secretsmanager:ResourceTag/Environment: prod}} } ] }这个策略的意思是“允许 agent 读取my-company-dataS3 bucket 下的所有对象但禁止它读取任何非prod环境的 secrets”。然而这仅仅是开始。OWASP开放网络应用安全项目在 2026 年初发布的《Agentic Top 10》清单列出了 agent 系统面临的十大安全风险其中前三名是Prompt Injection提示注入攻击者通过精心构造的输入绕过 guardrails让 agent 执行恶意指令。Credential Leakage凭证泄露agent 在日志、错误信息或输出中意外暴露了 API keys。Over-Privileged Tools过度授权的工具一个只负责搜索的工具却被授予了s3:DeleteObject权限。解决这些问题需要的不再是单个云厂商的策略引擎而是一个横跨所有 runtime 的、统一的、可插拔的 governance layer。这个 layer 必须能理解 agent 的 intent意图而不仅仅是它的 action动作。例如当 agent 试图调用curl https://api.bank.com/transfer?toattackeramount1000000时一个简单的deny curl策略是无效的因为它会同时阻断所有合法的curl调用。真正的治理需要理解“transfer money”这个 intent并基于账户余额、转账限额、用户身份等上下文动态地批准或拒绝。这个领域目前尚无公认的领导者但它是资本最密集涌入的方向。因为它的客户是企业的 CISO首席信息安全官和 CIO首席信息官他们的采购预算远比一个工程师的云账单要大得多。4.3.3 Vertical Marketplaces从“通用能力”到“专用解决方案”最后也是最直接的变现路径是垂直领域的 agent marketplace。Salesforce 的 Agentforce就是一个教科书级的案例。它不是一个让你自己搭建 agent 的平台而是一个已经预装了 200 多个“开箱即用”的销售 agent 的应用商店。你只需点击“安装”选择你的 CRM 数据源它就能立刻开始工作