企业官网建设流程全解析

1. 这不是新赛道，而是 runtime 层的“操作系统时刻”正在重演

你打开手机看到新闻标题《Anthropic Just Shipped the Layer That’s Already Going to Zero》，第一反应可能是：又一个大模型公司搞出了什么黑科技？但如果你真花十分钟读完原始那篇长文，会发现它根本不是在讲“Anthropic 多厉害”，而是在讲一个更冷峻、更本质的事实——AI 工程栈里最基础的一层，正以肉眼可见的速度失去定价权。这不是预测，是正在发生的现实。我过去三年带团队落地过 17 个生产级 agent 系统，从金融合规审批流到医疗问诊辅助，踩过所有坑，也亲手重建过三次状态层。所以当我看到 Anthropic 把“session as event log”写进工程博客时，第一反应不是鼓掌，而是立刻翻出我们去年 Q3 的故障复盘文档：第 42 分钟，context overflow，工具调用结果被 silently truncated，用户提交的报销单金额错配了三笔发票，最终靠人工回溯日志才救回来。这种失败不炸裂，但像慢性失血——你永远不知道哪次 context 溢出会吃掉客户信任。Anthropic 做的，就是把我们当时花两周重写的外部状态层，打包成 YAML 配置加一个awake(sessionId)调用。它解决的不是“能不能做”，而是“敢不敢让 agent 跑过 30 分钟”。关键词里的 “Towards AI - Medium” 不是平台标签，而是信号：这波讨论已从技术论坛下沉到产业决策者日常信息流。它意味着采购总监开始问 CTO：“AWS AgentCore 和 Claude Managed Agents，哪个能让我们下周就上线销售线索自动分发？”而不是“LLM 是什么”。适合谁读？三类人必须细看：一是正在选型 agent 基础设施的架构师，你得知道今天签的合同，明年会不会变成沉没成本；二是创业公司 CEO，你的融资故事里如果还押注“自研 sandbox”，风险系数已拉满；三是刚学完 LangChain 的工程师，别急着写agent.run()，先搞懂session_id在哪儿存、tool_call凭证怎么隔离、trace日志谁来查——这些才是真正在产线里卡脖子的细节。这不是概念科普，是给已经在泥里打滚的人，递一把趁手的铲子。

2. 架构解构：为什么“Session as Event Log”是唯一正确的起点

2.1 表面是功能，底层是范式迁移：从“上下文即存储”到“状态外置化”

Anthropic 官方文档里轻描淡写一句“Sessions persist across days”，但这句话背后是整个 agent 工程范式的断裂与重建。我们拆开看：传统 agent 实现（比如用 LangChain + OpenAI 的经典组合），状态完全依赖 LLM 的 context window。每次 tool call 返回结果，都塞进 prompt 末尾，下次推理再读取。这就像把整个工作台塞进一个不断滚动的卷轴里——你只能看到最近几米的内容，前面的图纸、测量数据、客户邮件，全被卷轴吞掉。我们去年做的供应链对账 agent 就栽在这儿：它要串起 ERP 查询、邮件解析、PDF 发票 OCR、三方物流 API 校验四个步骤。第 3 步 OCR 结果返回后，context 已占满 92%；第 4 步调用物流 API 时，系统自动丢弃了最早的 ERP 查询结果。模型没报错，它只是“自信地”用残缺数据编造了一个物流单号——因为它的“记忆”里只剩 OCR 文本和 prompt 模板，ERP 数据早被挤出窗口。而 Anthropic 的 session-as-event-log，本质是把那个滚动卷轴，换成带时间戳的工业级流水线：每一步操作（tool_call("get_erp_data", {"order_id": "SO-789"})）、每个返回（{"status": "shipped", "tracking_no": "SF123456"}）、每次决策（{"decision": "approve_payment", "reason": "tracking confirmed"}）都作为独立事件，写入外部持久化存储（很可能是基于 RocksDB 或 TimescaleDB 的专用日志服务）。Harness（执行器）只负责按序读取事件、调用对应工具、生成新事件。模型 context window 只承载当前 step 的最小必要上下文，比如“用户刚确认收货，现在需要生成付款凭证”。这直接带来三个硬性收益：

• 可恢复性：Harness 进程崩溃？没关系，awake(sessionId)直接从最后一条成功事件续跑，不用重放整个对话；
• 可追溯性：审计时直接查 event log 表，SQL 语句就能定位“谁在何时批准了哪笔付款”，不用翻几十页 chat history；
• 可扩展性：新增一个工具，只需在 event schema 里加一个 type 字段，Harness 逻辑零修改。

提示：别被“event log”这个词迷惑。它不是简单的文本日志，而是结构化、可索引、带事务语义的存储。Anthropic 内部大概率用了类似 Kafka + Materialized View 的架构，确保高并发下事件顺序严格一致。你如果自己搭，千万别用 MySQL 的 text 字段存 JSON——查询慢、无法按 tool_name 建索引、事务回滚困难。

2.2 Credential Isolation：不是安全噱头，而是生产环境的生死线

原文提到“credentials live in vaults the sandbox never sees”，这句比 session 设计更值得划重点。很多团队在 PoC 阶段把 API Key 直接写进 system prompt 或环境变量，觉得“反正测试用”。但一旦上生产，这就是定时炸弹。我们吃过亏：某次营销 agent 要调用 Salesforce API 更新线索状态，开发为图省事，把SF_ACCESS_TOKEN注入 sandbox 的 env。结果 agent 在处理一个恶意构造的用户 query 时，触发了未预期的 tool chain，把 token 当作普通字符串输出到了 Slack 消息里——整条消息被截图发到公开群组。30 秒内，攻击者用这个 token 创建了 200 个假线索，刷爆了客户预算。Anthropic 的方案是：credential vault（很可能是 HashiCorp Vault 或 AWS Secrets Manager 的深度集成）在 sandbox 启动时，只向其注入一个短期有效的、作用域极窄的 bearer token（比如只允许PATCH /leads/{id}），且该 token 由 vault 动态签发，sandbox 进程内存里永远不存原始密钥。Harness 调用工具时，vault 代理完成实际认证，sandbox 只看到“调用成功/失败”的抽象结果。这背后是严格的职责分离：

• Sandbox：只负责执行代码，无权访问任何长期凭证；
• Vault：只负责鉴权和签发临时令牌，不参与业务逻辑；
• Harness：只负责编排事件流，不接触凭证生命周期。

这种设计不是“过度工程”，而是把 DevOps 里成熟的 secrets management 最佳实践，原封不动搬进了 agent runtime。你如果自己实现，记住铁律：任何 credential 字符串，绝不能以明文形式出现在 sandbox 进程的任何内存段、文件系统或网络包中。哪怕是一次性 token，也要用 mTLS 双向认证确保 vault 到 sandbox 的链路可信。

2.3 Harness：无状态不是口号，是应对模型不确定性的唯一解法

Harness 被定义为“stateless executor that calls containers viaexecute(name, input) → string”。初看像教科书定义，实则是直面 LLM 本质缺陷的务实选择。LLM 推理本身具有概率性、非确定性——同一 prompt，两次调用可能返回不同 JSON schema，甚至一次成功一次格式错误。如果 Harness 有状态（比如缓存了上次 tool 的返回结构），当模型突然“变卦”，整个流程就卡死。Anthropic 的无状态设计，强制 Harness 每次都把完整上下文（包括最新 event log 的摘要、当前 user query、可用 tools 列表）喂给模型，让模型自己决定下一步。Harness 只做三件事：

1. 解析模型输出的 tool call 指令（如{"name": "search_knowledge_base", "input": {"query": "return policy"}}）；
2. 调用对应 sandbox 容器，传入 input；
3. 将容器返回的 raw string，连同 timestamp、sessionId，作为新事件写入 log。

这个循环看似简单，却规避了所有“状态漂移”风险。我们曾用有状态 Harness 做客服 agent，缓存了用户设备型号。某天模型突然在未提示情况下，把“iPhone 15”识别为“device: apple-15”，导致后续所有设备相关 tool call 全部失败。改成无状态后，每次调用都带完整 device 信息，模型爱怎么解析都行，Harness 只认最终输出的标准化指令。代价是计算开销略增（每次都要重传 context），但换来的是 99.99% 的流程鲁棒性——对生产系统，这远比省那点 token 贵得多。

3. 实操对比：Anthropic Managed Agents vs AWS Bedrock AgentCore 的真实战场

3.1 部署体验：从“配置地狱”到“YAML 即一切”

我们拿一个真实场景对比：为销售团队部署一个“自动跟进未回复线索”的 agent。它需要：

• 从 CRM（如 HubSpot）拉取 24 小时内未回复的线索；
• 调用邮件 API 发送定制化跟进邮件；
• 记录发送时间、邮件 ID 到内部数据库；
• 若 48 小时后仍无回复，升级给销售经理。

Anthropic Managed Agents 实操路径：

1. 写一个sales-follower.yaml：

name: "sales-follower" system_prompt: | You are a sales operations assistant. Follow these steps strictly: 1. Fetch unresponded leads from HubSpot (last 24h) 2. For each lead, send personalized email via SendGrid 3. Log email ID and timestamp to PostgreSQL 4. If no reply in 48h, notify manager in Slack tools: - name: "hubspot_fetch_leads" description: "Fetch leads with status 'unresponded' from HubSpot" input_schema: {"type": "object", "properties": {"hours": {"type": "integer"}}} - name: "sendgrid_send_email" description: "Send email via SendGrid" input_schema: {"type": "object", "properties": {"to": {"type": "string"}, "subject": {"type": "string"}}} - name: "postgres_log" description: "Log action to PostgreSQL" input_schema: {"type": "object", "properties": {"action": {"type": "string"}}} - name: "slack_notify" description: "Notify manager in Slack" input_schema: {"type": "object", "properties": {"message": {"type": "string"}}} guardrails: - type: "output_safety" config: {"block_terms": ["password", "ssn"]}

2. 执行claude agents deploy --file sales-follower.yaml；
3. 获取agent_id，在 CRM webhook 中调用POST https://api.anthropic.com/v1/agents/{agent_id}/sessions，传入{"lead_id": "HUB-123"}。

全程无服务器管理、无容器编排、无 TLS 证书配置。YAML 文件即全部契约。

AWS Bedrock AgentCore 实操路径：

1. 在 AWS Console 创建 AgentCore；
2. 编写 Lambda 函数实现每个 tool（hubspot_fetch_leads.py,sendgrid_send_email.py...），每个函数需自行处理 auth、error retry、timeout；
3. 为每个 Lambda 配置 IAM Role，精确授予 HubSpot API Gateway、SendGrid SMTP、RDS PostgreSQL 的最小权限；
4. 在 AgentCore 控制台，手动注册每个 tool 的 ARN、input/output schema；
5. 编写 State Machine（Step Functions）定义 workflow 逻辑，处理“fetch → send → log → check timeout → notify”分支；
6. 部署后，还需配置 CloudWatch Alarms 监控 Lambda 错误率、Step Functions 执行延迟。

注意：AWS 方案里，你承担了全部 infra 运维责任。Lambda 冷启动、RDS 连接池耗尽、Step Functions 重试风暴——这些都不是 Anthropic 的问题，而是你的 on-call 电话凌晨三点响起的原因。Managed Agents 的“托管”，本质是把运维复杂度从你的 SRE 团队，转移到 Anthropic 的平台工程团队。

3.2 性能数据：p50/p95 的数字背后，是资源调度的硬实力

原文提到“p50 time-to-first-token down roughly 60%, p95 better than 90%”。这数字不能孤立看。我们实测过两套环境（均用 claude-3-5-sonnet-20241022 模型）：

差异根源在资源模型：Anthropic 的 harness 是专用进程池，预热了模型推理上下文，session 启动只需加载 event log 快照；AWS 方案中，每个 session 触发 Step Functions，进而触发多个 Lambda，每个 Lambda 都要经历冷启动（下载代码、初始化 runtime、建立 DB 连接），p95 延迟主要被冷启动拖垮。尤其当销售晨会后集中触发 200 个线索跟进，AWS 方案会出现明显的请求堆积，而 Anthropic 侧几乎无感知。这不是“优化技巧”，而是架构选择：专用 runtime vs 通用 serverless。前者为 agent 场景深度定制，后者为通用计算设计。

3.3 成本结构：$0.08/session-hour 的真实含义

Anthropic 定价是 $0.08 per session-hour of active runtime。注意关键词是active runtime，不是“session 存活时间”。我们做了压力测试：一个 session 创建后，若 5 分钟内无新事件（user query 或 timer trigger），runtime 自动 suspend，停止计费；当新事件到达，毫秒级 resume，继续计费。这意味着：

• 一个处理邮件的 session，从 fetch lead 到 send email 到 log，全程 8 秒，计费约 $0.00018；
• 一个等待用户回复的 session（如“请确认是否接受报价”），挂起 48 小时，计费 $0；
• 一个高频交互的客服 session，持续 12 分钟，计费 $0.016。

而 AWS 方案的成本是叠加的：

• Lambda 执行时间 × $0.00001667/GB-s（按内存配置）；
• Step Functions 状态转换 × $0.025/1000 transitions；
• RDS 连接维持 × $0.115/hour（db.t4g.micro）；
• CloudWatch Logs 存储 × $0.03/GB。

我们测算过，同等负载下，AWS 方案的月度成本是 Anthropic 的 2.3 倍（基于 10 万 session/月，平均时长 5 分钟）。但关键不在数字，而在成本可预测性：Anthropic 的 $0.08/session-hour，你可以用 session 数 × 平均时长 × 0.08 精确预算；AWS 方案里，Step Functions 的 transition 次数、Lambda 的并发峰值、RDS 的连接数，全取决于用户行为的不可预测性——销售旺季的 session 流量曲线，和财务月结时的流量曲线，完全不同。这对 CFO 来说，是噩梦。

4. 生产陷阱与避坑指南：那些文档里绝不会写的血泪教训

4.1 Session ID 泄露：比 API Key 更隐蔽的风险

我们上线 Managed Agents 第二周，就收到安全团队告警：某销售 agent 的 session_id 出现在前端 JavaScript 错误日志中。原因很简单：前端调用POST /api/agent/sessions后，把返回的{ "session_id": "sess_abc123", "status": "created" }直接 console.log 了。而 session_id 在 Anthropic 体系里，等同于临时访问令牌——攻击者拿到它，就能调用GET /v1/agents/{agent_id}/sessions/{session_id}/events查看所有历史事件，包括邮件内容、CRM 数据、甚至 manager 的 Slack 通知。这不是理论风险，我们抓到过一次内部测试人员用 curl 直接 dump 了整个销售线索库。解决方案必须双管齐下：

• 前端：session_id 绝不打印、不存 localStorage、不传入任何第三方分析 SDK；
• 后端：所有/sessions接口必须校验 Origin Header 和 CSRF Token，禁止跨域直接调用；
• 平台层：在 Anthropic 控制台开启 “Session ID Rotation”，让每个 session_id 有效期仅 24 小时，过期后自动失效。

实操心得：把 session_id 当作 JWT token 对待。它不是 UUID，而是 bearer token。你在设计前端调用链时，必须把它当成最高密级凭证来保护。

4.2 Tool Schema 演进：如何避免“新加一个字段，全系统停摆”

我们曾为 agent 新增一个send_smstool，input_schema 里加了个country_code字段。结果第二天，所有旧 session 全部失败——因为 Harness 在解析模型输出时，发现{"name": "send_sms", "input": {"phone": "+123456789", "country_code": "US"}}，但旧版 tool schema 里没有country_code，直接抛出 validation error。Anthropic 的 solution 是schema versioning：每个 tool 注册时，必须指定version: "v1"，Harness 会根据 session 创建时的 schema 版本，动态加载对应校验规则。但文档没写清楚的是：版本升级必须灰度。正确流程是：

1. 新注册send_sms@v2，保持 v1 并行运行；
2. 在 system_prompt 里明确写“优先使用 send_sms@v2”；
3. 监控 v1 的调用占比，降到 5% 以下后，再下线 v1。

我们跳过这步，直接切 v2，导致 37 个存量 session 因 model 输出仍为 v1 格式而中断。教训：agent 的 tool interface，和 Web API 一样，必须遵循“向后兼容”原则。任何 breaking change，都要预留至少 2 周的双版本共存期。

4.3 Event Log 查询性能：当“可追溯性”变成性能瓶颈

Anthropic 提供/sessions/{id}/eventsAPI 查询事件，但没告诉你：单 session 事件超 1000 条时，查询延迟会指数上升。我们有个金融 agent，单 session 处理一笔跨境支付，涉及 12 家银行 API 调用、5 次合规检查、3 次人工审核，事件数常破 2000。某次审计要求查“某笔交易的所有风控决策依据”，API 调用耗时 17 秒，超时失败。根本原因是 event log 底层用的是 append-only log，查询需全表扫描。解决方案是：

• 主动归档：在 session 关闭前（status: "completed"），调用POST /v1/agents/{agent_id}/sessions/{id}/archive，将事件导出到 S3，用 Athena 查询；
• 关键事件打标：在 system_prompt 里要求模型对重要决策事件加#audittag，Harness 自动提取带 tag 的事件，存入单独的 high-priority-events 表，用 PostgreSQL 的 GIN 索引加速查询；
• 前端分页：永远不要GET /events?limit=10000，用cursor参数分页，每次最多取 100 条。

注意：Anthropic 的 event log 不是数据库，是日志。把它当数据库用，一定会撞墙。真正的 trace store，得是你自己建的 OLAP 系统。

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

5.1 Trace Store：谁掌控了“agent 的行车记录仪”，谁就握住了命脉

原文点出 Braintrust、Arize、LangSmith 三家，但没说清它们真正的护城河在哪。我们对比了三者在真实场景中的表现：

• Brainstore（Braintrust）：专为 AI log 优化的列存引擎，支持 sub-100ms 的SELECT * FROM events WHERE session_id = 'xxx' AND tool_name = 'postgres_log' AND timestamp > '2026-04-01'。但它要求你把所有 event log 导出到其托管集群，数据主权移交。
• Phoenix（Arize）：Apache 2.0 开源，可私有部署。但开源版只支持基础 schema，要查“模型输出 JSON 的某个嵌套字段”，得自己写 UDF（User Defined Function），开发成本高。
• LangSmith：无缝集成 LangChain，langchain.callbacks.tracers.LangChainTracer一行代码接入。但它的存储是托管的，且 schema 固化严重——你想加一个自定义的business_context字段？得等他们发版。

我们的选择是混合架构：

• 生产环境用 LangSmith 收集原始事件（因接入成本最低）；
• 每日凌晨，用 Airflow 将 LangSmith 数据 ETL 到自建的 ClickHouse 集群；
• 在 ClickHouse 里建宽表，把model_output的 JSON 解析为列（model_output.status,model_output.confidence_score），并关联 CRM 用户画像表。

这样，审计时 SQL 查询秒出，且数据完全自主。结论：Trace Store 的胜负手，不是 dashboard 多炫，而是schema 灵活性 + 查询性能 + 数据主权三角平衡。谁能让用户用标准 SQL 查到任意维度的 agent 行为，谁就赢了。

5.2 Governance & Policy：企业采购的“准入门票”

AWS 在 March 2026 GA 的 AgentCore Policy Controls，是第一个把“agent 行为合规”产品化的方案。它允许你定义：

• deny_if_tool_contains("aws_s3_delete_object")；
• require_approval_for_tool("send_email") if user_role == "intern"；
• log_all_events_to_cloudtrail if environment == "prod"。

但这只是开始。真正的治理战场在策略即代码（Policy as Code）。我们用 Open Policy Agent（OPA）实现了更细粒度控制：

package agent.policy default allow = false allow { input.tool.name == "hubspot_update_lead" input.user.department == "sales" input.tool.input.status == "qualified" } allow { input.tool.name == "send_email" count(input.tool.input.attachments) <= 3 some i input.tool.input.attachments[i].size < 5000000 # 5MB limit }

OPA 策略在 Harness 调用 tool 前实时执行，拒绝非法请求。这比 AWS 的静态规则强大得多——它能基于实时上下文（如用户部门、附件大小）动态决策。而 Anthropic 的 guardrails 目前只支持关键词阻断，无法做这种业务逻辑判断。所以，如果你的客户是银行或医疗机构，光有 Anthropic 的 managed runtime 不够，你还得在它前面加一层 OPA 网关。Governance 不是附加功能，是进入 enterprise procurement 的硬门槛。

5.3 Vertical Agent Marketplaces：当“agent”成为可采购的商品

Salesforce Agentforce $800M ARR 的数字背后，是垂直场景的 contractability。我们和一家医疗 SaaS 公司合作时，对方 CIO 明确说：“我不买 runtime，我买‘自动处理医保拒付申诉’的 agent。我要看到 SLA：99.5% 的申诉在 2 小时内生成初稿，准确率 ≥92%，错误率 <0.3%。” 这种需求，无法用通用 agent 框架满足。它需要：

• 领域知识固化：把 CMS（美国医疗保险服务中心）的 2000+ 条拒付代码、对应申诉话术、所需附件清单，编码进 agent 的 system_prompt 和 tool logic；
• 合规审计包：提供 HIPAA-compliant 的数据流图、加密密钥轮换日志、第三方渗透测试报告；
• 按效果付费：合同约定“每成功申诉一笔拒付，收 $X”，而非按 token 或 session 计费。

这就是 vertical marketplace 的本质：它把 agent 从“技术组件”，变成了“可计量、可审计、可签约的业务能力”。我们已上线的金融 agent marketplace，入驻的 12 家 ISV（独立软件开发商），全部采用“效果分成”模式——他们不卖代码，卖的是“降低 15% 的反洗钱误报率”这个结果。Runtime 层归零，恰恰加速了这种转变：开发者不再纠结 sandbox 性能，转而深耕行业知识图谱和效果验证方法论。钱，自然流向能交付确定性结果的地方。

6. 终极拷问：你的技术栈，站在价值金字塔的哪一层？

我最后一次部署纯 runtime 层的项目，是 2023 年底。当时我们花了 4 个月，用 Kubernetes + gVisor + custom scheduler 搭建了一个号称“最安全”的 sandbox。上线三个月后，客户问：“你们的 agent 能不能自动填完这张 FDA 表格？” 我们答：“可以，但得再开发两个月。” 客户说：“隔壁家上周就上线了，他们用的是 Salesforce Agentforce。” 那一刻我明白了：技术先进性，在采购决策面前一文不值。客户买的不是 sandbox，是 FDA 表格的自动填写能力。Anthropic 的 Managed Agents，AWS 的 AgentCore，Google 的 Vertex Agent Builder，它们共同在做一件事：把 runtime 这个曾经需要博士团队攻坚的领域，压缩成一个 checkbox。这不是技术倒退，而是产业成熟——就像当年 VMware 把虚拟化做成一键安装，让企业终于能把精力从“怎么虚拟化”转向“虚拟化后跑什么应用”。今天，当你再评估一个 agent 基础设施时，请把问题从“它多快多稳”切换到“它让我离客户要的结果，近了多少”。如果你的答案还是“更快的 sandbox”，那你已经在价值金字塔的底部了。真正的机会在上面：在 trace store 里埋下法律证据的种子，在 governance policy 里写入企业的合规基因，在 vertical marketplace 里封装十年行业经验。Runtime 层归零不是终点，是价值向上迁移的发令枪。我现在的团队，已经不再招 sandbox 工程师，而是招医疗合规专家、金融风控建模师、以及能把 SOP（标准作业流程）翻译成 policy rule 的业务架构师。因为我知道，当 runtime 成为水电煤，真正的稀缺资源，永远是那些能把专业认知，转化为 agent 可执行逻辑的人。