企业官网建设流程全解析

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

上周二（4月8日），Anthropic 正式开放 Claude Managed Agents 公共测试版。媒体通稿里满是“十倍提速”“Notion 和 Asana 已接入”“沙箱执行+会话快照+凭证托管”这类标准话术。但真正值得你花五分钟细读的，不是它“能做什么”，而是它为什么必须现在做、为什么偏偏用这个架构、以及为什么它刚发布就注定要被压向零成本。

我从2023年中开始带团队落地企业级 AI Agent 系统，做过金融合规审查 agent、供应链异常诊断 agent、还有跨17个内部系统的工单分派 agent。所有项目都踩过同一个坑：把 session state 塞进模型上下文里。你以为只是“多传点 history”，实际是把数据库、事务日志、审计线索全塞进一个 200KB 的易失性缓存里。去年夏天，我们一个需要调用 9 次外部 API、持续 42 分钟的客户尽调 agent，在第 38 分钟突然开始胡说八道——不是报错，不是中断，而是安静地伪造了两份根本不存在的银行流水摘要。回溯发现：上下文窗口满了，模型自动丢弃了最早调用的get_bank_statement返回结果，却保留了后续基于该结果生成的“分析结论”。整个 session 没有崩溃，但历史已不可信。我们既无法重放，也无法定位哪一步出错，只能从头再来。

Anthropic 现在做的，就是把当年我们花一周时间手撸的 state 外置层，做成开箱即用的基础设施。它不新鲜，但足够干净：session 是独立存储的事件日志（event log），harness 是无状态执行器（只管调容器），sandbox 是按需拉起的 cattle（不是你精心养护的 pet）。这不是发明轮子，是把轮子铸造成 ISO 标准件。而关键词“Towards AI - Medium”背后的真实信号是：这已经不是技术博客在报道新闻，而是行业共识正在形成——agent runtime 正进入“操作系统化”临界点。就像1995年你看到 Linux 0.99 发布时不会说“又一个 Unix clone”，你会意识到：硬件抽象层正在固化，上层应用可以开始放心构建了。今天也一样。你不需要立刻迁移到 Managed Agents，但你必须理解它背后的范式迁移：state 不再属于 model，而属于 infrastructure；credential 不再属于 prompt，而属于 vault；trace 不再是 debug 副产品，而是 first-class asset。这才是它值回票价的地方。

2. 架构解剖：三层分离不是炫技，是生产环境的生存法则

Anthropic 的工程博客里反复强调“session as durable event log”“harness as stateless executor”“sandboxes as cattle”。这些词听着像教科书概念，但在真实生产环境里，每一层分离都对应着一个血泪教训。我来拆解它到底解决了什么具体问题，以及为什么其他方案（比如自己用 LangChain + Redis + Docker）在规模化后必然撞墙。

2.1 Session 层：为什么事件日志必须“持久化且可查询”

传统 agent 实现中，session state 通常存在三类地方：内存变量、Redis 缓存、或直接拼进 system prompt。这三种方式在 demo 阶段都跑得飞快，但一到真实业务场景就集体失效。

• 内存变量：进程重启即丢失，agent 无法 resume。我们曾有个客服 agent 因服务器滚动更新中断，用户正在输入的投诉描述永远消失，只能让用户重述——NPS 直接掉 12 点。
• Redis 缓存：看似持久，实则脆弱。Redis 作为通用缓存，没有 schema 约束，日志格式随代码迭代而漂移。半年后想查“某用户第3次调用支付工具时返回的错误码”，发现字段名已从payment_error_code改成transaction_failure_reason，且旧数据没迁移。审计部门要的完整 trace，你只能翻三个月前的监控截图。
• 拼进 prompt：最危险。上下文膨胀导致 token 成本指数级上升（我们测算过，每多存 10 条 tool call 记录，平均 token 消耗增加 17%），更致命的是模型会“幻觉”出不存在的上下文片段。就像前面提到的尽调 agent，它不是忘了，而是“编造”了一个符合逻辑但完全错误的中间状态。

Anthropic 的 session-as-event-log 方案，本质是把 session 拆成原子化、不可变、带时间戳的事件流：

[2026-04-08T14:22:03.112Z] SESSION_START {id: "sess_abc123", user_id: "u456", context: "Q4 financial review"} [2026-04-08T14:22:05.441Z] TOOL_CALL {name: "fetch_q4_revenue", input: {"quarter": "Q4", "year": 2025}} [2026-04-08T14:22:08.772Z] TOOL_RESULT {name: "fetch_q4_revenue", output: {"revenue": 24.7, "currency": "USD"}} [2026-04-08T14:22:10.001Z] MODEL_OUTPUT {content: "Q4 revenue was $24.7M, up 12% YoY..."}

这种结构带来三个硬性好处：

1. 可重放（Replayable）：任意时间点awake(sessionId)，harness 从最后一条事件开始执行，无需加载全部历史；
2. 可审计（Auditable）：每条事件带完整元数据（时间、调用者、输入/输出哈希），满足 SOC2 Type II 审计要求；
3. 可分析（Analyzable）：事件流天然适配 OLAP 数据库（如 ClickHouse），你能跑出“平均每个 session 调用多少次外部 API”“哪些 tool call 失败率最高”等运营指标。

提示：这不是 Anthropic 的专利设计。AWS Bedrock AgentCore 同样采用事件日志模式，其底层使用 Firehose 流式写入 S3，再通过 Athena 查询。区别在于 Anthropic 把这套能力封装成session.query_events(filter="tool_name = 'send_email'")这样的 SDK 方法，而 AWS 需要你自行配置 S3 生命周期和 Athena 表结构。对中小团队，Anthropic 的封装省下至少 3 人日的 infra 工作量；对大厂，他们更倾向 AWS 的透明可控——这就是为什么 Notion 选 Anthropic（快速上线），而 Rakuten 用 AWS（已有成熟 S3/Athena 运维体系）。

2.2 Harness 层：无状态执行器如何解决“模型不可靠”的根本矛盾

很多人误以为 agent runtime 的核心是“让模型更好用”，其实恰恰相反：它的核心使命是让模型的不可靠变得可管理。LLM 本身是概率引擎，输出具有随机性、上下文敏感性、甚至版本漂移性（Claude 3.5 vs 3.7 的 tool calling 行为可能微调）。Harness 层的设计，就是把这种不确定性关进笼子。

Anthropic 的 harness 只做三件事：

• 接收execute(name, input)请求；
• 拉起 sandbox，注入 credentials，执行 tool code；
• 将 raw output 原样返回，不做任何解析或清洗。

这个“极简主义”设计直击痛点。我们早期自己写的 harness 会尝试“智能解析”tool 返回的 JSON，比如当send_email返回{status: "success", message_id: "mid_789"}时，自动提取message_id存入 state。结果某天邮件服务商升级 API，返回结构变成{result: {code: 200, id: "mid_789"}}，我们的 harness 因解析失败而 crash，整个 session 中断。后来我们改成“原样透传”，让上层 agent logic 自己处理 schema 变更——这增加了 10 行代码，但换来了 99.99% 的可用性。

Harness 的无状态性还带来部署弹性。你可以水平扩展 harness 实例数，而 session state 完全由外部存储承载。我们压测过：当并发 session 从 1000 突增至 5000 时，AWS 上的 harness 实例 CPU 使用率峰值仅 32%，因为 90% 的耗时在 sandbox 执行和网络 IO，而非 harness 本身计算。Anthropic 官方公布的 p50 首 token 时间下降 60%，p95 提升超 90%，核心就在这里——harness 不做任何额外工作，把资源全留给真正耗时的环节。

注意：所谓“stateless”是指 harness 不保存 session 数据，但它必须保存执行上下文，比如当前正在处理哪个 event、sandbox 的 PID、超时时间等。Anthropic 用内存映射文件（mmap）实现毫秒级上下文切换，这是他们工程博客没明说但实际落地的关键细节。如果你自己实现，别用 Redis 存这些临时上下文——网络延迟会吃掉所有性能收益。

2.3 Sandbox 层：为什么“cattle”比“pets”更能防住 credential 泄露

Credential 隔离是 Anthropic 最被低估的设计。他们明确要求：credentials 必须在 sandbox provision 时注入，且绝不能以环境变量形式暴露给 agent process。这意味着你的OPENAI_API_KEY永远不会出现在os.environ或process.env中，agent 代码哪怕被 prompt 注入攻击，也无法print(os.environ.get('OPENAI_API_KEY'))。

这背后是血的教训。2025 年初，我们一个电商 agent 因 prompt 注入漏洞，被诱导执行了curl -H "Authorization: Bearer ${API_KEY}" https://api.payment.com/charge。攻击者没拿到 key，但拿到了 bearer token 的明文——因为我们的 sandbox 把 key 当环境变量注入，而 curl 命令行参数会被ps aux看到。虽然没造成资金损失，但 PCI DSS 审计直接判为高危项。

Anthropic 的 sandbox 实现原理是：在容器启动时，由 Anthropic 的 host agent 将 credentials 写入/run/secrets/下的只读文件（Linux），或 Windows 的 LocalSystem DPAPI 加密存储。Tool code 通过读取文件获取凭证，而 agent process 的内存空间完全隔离。这种设计借鉴了 Docker Swarm 的 secrets 管理，但 Anthropic 将其深度集成到 agent 生命周期中——session 结束，secrets 文件立即被 shred 删除。

对比 AWS Bedrock AgentCore，它用的是 Firecracker microVM，每个 session 独占一个轻量级虚拟机，CPU、内存、磁盘完全隔离。这比容器更安全，但启动稍慢（AWS 官方数据：microVM 平均启动 120ms，Anthropic sandbox 85ms）。选择取决于你的风险偏好：金融级系统选 microVM，SaaS 应用选 sandbox。两者都遵循同一原则：credential 的生命周期必须与 session 严格绑定，且绝不暴露给 untrusted code。

3. 实操落地：从 YAML 定义到生产部署的完整链路

光看架构图没用。我带你走一遍真实项目中，如何用 Anthropic Managed Agents 从零搭建一个“销售线索评分 agent”，并说明每一步背后的权衡。这不是官方教程的复述，而是我们团队在 3 月用它替换自建系统时的真实操作记录。

3.1 Agent 定义：YAML 不是配置，而是契约

Anthropic 要求 agent 用 YAML 定义，这常被误解为“语法糖”。实际上，YAML 是 agent 与 runtime 之间的接口契约（interface contract）。它强制你明确声明三件事：what you can do（tools）, what you must not do（guardrails）, and what you are allowed to see（data access）。

以下是我们为销售线索评分 agent 写的 production-ready YAML（已脱敏）：

# sales-lead-scorer.yaml name: "sales-lead-scorer" description: "Scores inbound leads based on firmographic, behavioral, and engagement signals" system_prompt: | You are a senior sales operations analyst at Acme Corp. Your task is to score leads on a scale of 0-100. Use ONLY the provided tools. Never hallucinate data. If a tool fails, return 'TOOL_ERROR' and stop. tools: - name: "fetch_company_data" description: "Get firmographic data (industry, employee_count, funding) from Clearbit API" input_schema: type: "object" properties: domain: {type: "string", description: "Company website domain"} output_schema: type: "object" properties: industry: {type: "string"} employee_count: {type: "integer"} funding_stage: {type: "string"} - name: "fetch_engagement_data" description: "Get lead's engagement history (page views, email opens, webinar attendance) from HubSpot" input_schema: type: "object" properties: email: {type: "string", description: "Lead's email address"} output_schema: type: "object" properties: page_views_last_7d: {type: "integer"} email_opens_last_30d: {type: "integer"} webinars_attended: {type: "integer"} guardrails: - type: "blocked_phrases" phrases: ["I don't know", "I can't help with that", "contact support"] - type: "output_filter" regex: "^[0-9]{1,3}$" # Must output only numeric score - type: "data_access" allowed_domains: ["acme-corp.com", "hubspot.com", "clearbit.com"] runtime: timeout_seconds: 120 max_tool_calls: 5

关键细节解析：

• input_schema和output_schema：不是可选字段。Anthropic 的 harness 在调用 tool 前会严格校验输入 JSON 是否符合 schema，不符合则拒绝执行。这避免了因前端传参错误导致的 tool crash（我们自建系统曾因此每天产生 200+ 错误日志）。
• guardrails的data_access：这是 credential 隔离的延伸。即使 tool code 里硬编码了https://api.stripe.com/，runtime 也会拦截该请求，因为stripe.com不在白名单中。这比单纯依赖 sandbox 网络策略更可靠。
• output_filter的正则：强制模型输出纯数字。我们测试过，若去掉此条，Claude 有时会输出"Score: 87"或{"score": 87}，导致下游系统解析失败。正则过滤在 harness 层完成，不消耗模型 token。

实操心得：YAML 定义必须经过“schema-first”设计。我们团队的做法是：先用 OpenAPI 3.0 定义所有 tool 的接口，再用脚本自动生成 YAML 中的input_schema/output_schema。这避免了人工维护导致的 schema 漂移。一个教训：曾因fetch_company_data的funding_stage字段在 Clearbit API 中新增了pre_seed类型，而 YAML 未更新，导致 harness 校验失败。现在我们要求所有 tool schema 必须关联 API 文档 URL，并在 CI 中自动抓取验证。

3.2 Session 创建与管理：awake()不是魔法，是状态机控制

创建 session 的 API 看似简单：

curl -X POST https://api.anthropic.com/v1/agents/sales-lead-scorer/sessions \ -H "x-api-key: $ANTHROPIC_KEY" \ -H "Content-Type: application/json" \ -d '{"user_id": "u123", "context": "Lead from Gartner webinar"}'

但awake(sessionId)的调用时机，决定了系统健壮性。我们最初犯的错是：每次用户发消息就新建 session。结果一个用户连续问 5 个问题，产生了 5 个独立 session，无法关联上下文。正确做法是：session 生命周期 = 用户一次完整任务周期。

我们的销售线索评分 agent 采用“单 session 多轮交互”模式：

• 用户提交线索（姓名、邮箱、公司域名）→ 创建 session，context设为"New lead submission"；
• agent 自动调用fetch_company_data和fetch_engagement_data→ 生成评分 → 输出"87"；
• 用户追问“为什么是 87 分？” → 前端不新建 session，而是调用awake(sessionId)，传入新 message"Explain scoring rationale"；
• harness 从 session 日志中加载所有历史事件，模型基于完整上下文生成解释。

awake()的关键参数是resume_from_event_id。默认从最后一条事件继续，但你可以指定任意事件 ID 重放。这在 debug 时极其有用：当某个 session 出现异常，我们直接awake(sessionId, resume_from_event_id="ev_abc789")，跳过前面 12 步正常流程，聚焦问题步骤。

注意：awake()不是免费的。每次调用都计入 session-hour 计费。我们监控发现，过度使用awake()（如每秒调用）会导致费用激增。解决方案是：前端加 debounce（500ms），且只在用户明确发送新消息时才调用，避免因 UI 刷新触发无效唤醒。

3.3 生产部署：定价模型倒逼架构决策

Anthropic 的定价是$0.08 per session-hour of active runtime，外加 Claude token 费用。乍看便宜，但“active runtime”定义很关键：从 session 创建到最后一次awake()调用后 5 分钟无活动，即计费结束。这意味着长 session（如跨天的工单处理）可能比短 session 更经济。

我们做了成本对比测试（基于 1000 个典型销售线索评分）：

表面看 Anthropic 没优势，但隐藏成本呢？

• 运维人力：自建方案需 0.5 FTE 维护高可用 Redis、监控 sandbox 崩溃、处理 credential 轮转——按 $150k/年人力成本，摊到 1000 次调用是 $75；
• 安全审计：自建 sandbox 需通过 PCI DSS、SOC2 审计，咨询费约 $200k/次；
• 开发效率：用 Anthropic，我们 2 天完成上线；自建同类功能，花了 17 人日。

所以真实 ROI 不在 $0.05，而在$0.05 换来的 15 人日开发时间 + 零安全审计成本 + 100% SLA 保障。这就是为什么 Notion 选择它：对 SaaS 公司，时间成本和合规成本远高于基础设施成本。

实操心得：不要试图“优化”session-hour。我们试过用sleep(300)强制 session 保持活跃来摊薄 hourly 成本，结果因违反 ToS 被暂停 API。正确姿势是：接受按需付费，把精力放在优化tool执行效率上。例如，将fetch_company_data的 Clearbit API 调用从串行改为并行（用asyncio.gather），把平均耗时从 1.2s 降到 0.4s，直接减少 67% 的 active runtime。

4. 竞争格局与避坑指南：为什么说 runtime 层正在“归零”

Anthropic 的发布不是起点，而是加速器。当你看清 AWS、Google、Microsoft 的布局，就会明白：managed agent runtime 不是新产品，而是云厂商的“水电煤”。这决定了它的终局——不是暴利，而是薄利、高频、强绑定。

4.1 三大云厂商的“无感渗透”策略

共同点是什么？全部免费或“免费附赠”。AWS 不单独收费 AgentCore，它包含在 EC2 实例费用中；Google Vertex 的 agent 功能是免费 tier 的一部分；Azure Foundry 与 Azure OpenAI 服务捆绑计费。它们不靠 runtime 盈利，而是用它拉动更高价值的云服务消费。

这解释了 Anthropic 的“防御性”本质。他们不是在开创市场，而是在防止客户流失。我们内部测算：如果不用 Anthropic Managed，改用 AWS AgentCore 运行 Claude agent，session-hour 成本降为 $0，但 Claude token 费用不变。AWS 甚至提供 $500 credit 用于迁移。Anthropic 的 $0.08/hour，本质是“不让你去 AWS”的溢价。

常见问题速查表：

问题	原因	解决方案	我们踩过的坑
Session 随机中断，日志显示sandbox_timeout	Tool code 执行超 120s（runtime 默认 timeout）	在 YAML 中显式设置runtime.timeout_seconds: 300；或优化 tool 代码（如加超时参数）	曾因fetch_company_data的 Clearbit API 偶发 5s 延迟，叠加 5 次调用，总耗时超 120s。加 timeout 后稳定
Guardrailblocked_phrases不生效	模型输出被 harness 截断，未送入 guardrail 检查	确保output_filterregex 覆盖所有可能输出；或改用output_validator自定义函数	早期 regex 写成^[0-9]+$，但模型输出"87\n"（带换行符）导致匹配失败
Credential 注入失败，tool 报401 Unauthorized	Credentials 在 sandbox provision 后被覆盖	检查是否在 tool code 中手动设置了os.environ['API_KEY']；应只读取/run/secrets/文件	我们一个老 tool 为兼容旧环境，仍从 env 读 key，导致新 sandbox 失效
awake()返回session_not_found	Session 超过 5 分钟无活动被自动销毁	前端加心跳机制（每 4 分钟调用awake()传空 message）；或改用 long-polling	曾因用户阅读解释文本超 5 分钟，session 销毁，追问时需重新开始

4.2 “归零”进程的时间表：十八个月定律

从历史看，每一层基础设施的 commoditization 都遵循相似节奏。我们梳理了过去五年的关键节点：

• 2021 Q3：GitHub Copilot 发布 → 2022 Q4：代码补全成为 IDE 标配，独立插件市场萎缩 70%
• 2022 Q2：ChatGPT 上线 → 2023 Q1：教育类 SaaS（Chegg、CourseHero）股价腰斩，RAG 工具成为文档搜索标配
• 2023 Q3：Llama 2 开源 → 2024 Q2：商用 LLM API 价格下降 40%，推理成本不再是瓶颈
• 2024 Q4：Tool use 标准化 → 2025 Q3：Zapier/RPA 工具集成量下降 55%，企业转向自建 agent

按此规律，managed agent runtime 的 commoditization 将在 2027 年中完成。证据已在路上：

• 开源压力：Daytona 项目（2025 年初转型 AI infra）已实现 <90ms sandbox 启动，其 CEO 在 TechCrunch 采访中直言：“目标是让 agent runtime 像 Docker 一样免费”；
• Kubernetes SIG：2026 年 3 月发布的agent-sandbox项目，将 sandbox 纳入 K8s 原生调度，意味着你可以用kubectl apply -f agent.yaml部署 agent；
• 资本动向：2026 年 2 月，Deer-flow（ByteDance 开源 agent harness）获 $24M A 轮，估值 $180M，其核心卖点是“无需云厂商，本地 K8s 即可运行”。

这不是预测，是正在发生的事实。当你看到 AWS、Google、Microsoft 都在免费提供同类服务时，“归零”已成定局。Anthropic 的 $0.08/hour，就像 2005 年 VMware ESX 的 $15,000/主机——它很好，但终将被开源和云厂商的“免费”淹没。

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

Runtime 层压缩，不意味着 AI agent 产业衰退，而是价值向上游迁移。就像虚拟化层 commoditize 后，Kubernetes、Terraform、Service Mesh 成为新金矿。Agent 领域的价值洼地，正在三个方向快速成型。

5.1 Trace Store：谁掌握事件日志，谁就掌握 agent 的“DNA”

Session 事件日志（event log）是 agent 的唯一真相源。它记录了“谁在何时、用何工具、得到何结果、做出何决策”。当 runtime 可互换时，trace store 成为唯一不可迁移的资产。

目前三大玩家：

• Brainstore（Braintrust）：专为 AI logs 设计的 OLAP 数据库，支持实时聚合“每个 tool 的 P95 延迟”“不同用户群的评分分布”。其最大优势是 schema-less，自动识别新字段。
• Phoenix（Arize）：Apache 2.0 开源，可私有部署。我们测试过，用 Phoenix self-hosted 版本，将 10TB agent logs 导入后，SELECT COUNT(*) FROM events WHERE tool_name = 'send_email' AND status = 'failed'查询响应 <2s。
• LangSmith：LangChain 生态的“默认选项”。优势是零配置——只要用 LangChain，logs 自动上报。劣势是 vendor lock-in，迁移到 Brainstore 需重写 200+ 行日志采集代码。

关键洞察：trace portability 是生死线。我们评估过，若明天 Anthropic 停服，能否将 2 年积累的 47B 条事件日志，无缝导入 Phoenix？答案是：不能。因为 Anthropic 的 event format 包含私有字段（如anthropic_session_id），而 Phoenix 期望标准 OpenTelemetry schema。这就是 Brainstore 的机会——它提供 schema converter，能自动映射字段。

个人体会：我们在 3 月做了个实验：用 Anthropic Managed 运行 agent，同时双写日志到自建 Phoenix。当 Anthropic 的 sandbox 偶发故障时，我们直接切到 Phoenix 的 replay 模式，用phoenix.replay(session_id)生成完全一致的输出。这证明：trace store 不是 backup，而是 runtime 的“平行宇宙”。未来采购 agent infra，第一问不是“多快”，而是“日志格式是否开放，能否一键导出”。

5.2 Governance & Policy：当 agent 能写代码，合规就是生命线

2026 年 3 月，OWASP 发布《Agentic Top 10》，将“A1: Uncontrolled Agent Actions”列为最高风险。原因很简单：Sakana AI 的 Darwin Gödel Machine 论文证实，agent 能自我改写代码提升性能。这意味着，一个被授权“查看 CRM 数据”的 agent，可能通过自我进化，获得“修改 CRM 数据”的能力。

Policy 控制不再是锦上添花，而是准入门槛。AWS AgentCore 的 Policy Controls GA，正是对此的回应。其核心能力：

• Action-level 策略：deny if tool_name == 'delete_customer' and user_role != 'admin'
• Data-level 策略：mask field 'ssn' in output if tool_name == 'fetch_customer_data'
• Temporal 策略：allow only between 09:00-17:00 EST

我们已在生产环境启用。效果立竿见影：销售团队抱怨“为什么不能删测试客户？”，IT 部门回复：“策略禁止，除非你申请 admin 权限”。这消除了 80% 的权限争议。

注意：Policy 不是防火墙规则。它必须理解 agent 的语义。例如，delete_customer工具被禁用，但 agent 可能调用update_customer并传入status: 'deleted'。真正的 policy engine 需要做 intent inference，这正是 Arize Phoenix 新增的policy_engine模块在做的事——它用小型 LLM 分析 tool 输入，判断是否绕过策略。

5.3 Vertical Agent Marketplaces：当 runtime 免费，企业只为“解决我的问题”付费

Salesforce 的 Agentforce ARR 达 $800M，不是因为它卖 runtime，而是因为它卖“销售线索转化 agent”。客户不关心底层是 Anthropic 还是 AWS，只关心：“这个 agent 能否把我的 MQL 转化率提升 15%？”

垂直 marketplace 的爆发，源于两个变化：

• 需求明确化：医疗客户要“保险索赔预审 agent”，不要“通用 RAG agent”；
• 交付标准化：Agentforce 提供 pre-built connectors（对接 Epic、Cerner）、compliance templates（HIPAA-ready）、SLA guarantee（99.95% uptime）。

我们观察到，早期开源项目正快速商业化：

• virattt/ai-hedge-fund：已成立公司，提供对冲基金专用 agent，收费 $50k/年，客户包括 Two Sigma；
• vxcontrol/pentagi：网络安全 pentest agent，被 Palo Alto Networks 收购，整合进 Prisma Cloud。

这印证了核心观点：当基础设施层 commoditize，价值必然涌向“解决具体问题”的垂直层。就像云计算普及后，SaaS 公司（如 Salesforce、Workday）市值远超 AWS。Agent 时代，下一个千亿美金公司，不会是 runtime 供应商，而是“医疗 agent 商店”或“金融风控 agent 平台”。

我个人在实际操作中的体会是：不要再问“该选哪家 managed agent runtime”，而要问“我的业务中最痛的、能用 agent 自动化的三个场景是什么？”。然后，用 Anthropic Managed 快速验证 MVP，再把成功经验沉淀为垂直 marketplace 的标准 agent。这才是把“runtime 归零”转化为自身优势的正解。