企业官网建设流程全解析

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

你有没有试过让一个 AI 代理连续工作四十分钟？不是闲聊，而是真正在查资料、调 API、写代码、改文档、再交叉验证——一套完整的多步骤任务流。去年我带团队跑一个客户侧的合同智能审核 agent，流程设计得很漂亮：先用 RAG 检索历史条款库，再调用法律语义解析工具提取责任主体，接着比对最新监管文件生成风险提示，最后生成可编辑的修订建议。前二十分钟一切丝滑，token 流像溪水一样稳定。但到了第三十五分钟，模型突然开始“编造”一条根本不存在的银保监会 2023 年第 7 号文附件三——不是胡说八道，而是逻辑自洽、引用格式规范、连页码都编得有模有样。我们翻日志，发现它把最初检索到的三个 PDF 元数据全挤出了上下文，却把中间某次工具调用返回的 JSON 片段当成了原始依据。更糟的是，整个 session 没有外部快照，没有事件回放能力，连 debug 都只能靠猜。那次失败没造成客户损失，但让我在周会上拍了桌子：“下次再把 state 塞进 context window，我就亲手删掉 prompt 工程师的键盘。”

这就是 Anthropic 在 4 月 8 日发布的Claude Managed Agents真正解决的问题——它不是又一个“让 LLM 更聪明”的玩具，而是一套把 AI 代理从“状态寄存器+上下文窗口”这种脆弱耦合中解放出来的基础设施。关键词不是“agent”，而是session-as-event-log、harness-as-stateless-executor、sandbox-as-cattle。这组词听着拗口，但背后是整整一代工程师被 context overflow、credential leak、session 中断折磨后的集体共识。它和 AWS Bedrock AgentCore、Google Vertex AI Agent Builder、Azure AI Foundry 走在同一条路上：把 agent runtime 从应用层里抽出来，变成像 Linux 内核调度进程、像 Kubernetes 编排容器那样可信赖、可审计、可替换的底层能力。所谓“Layer That’s Already Going to Zero”，指的不是技术不重要，而是这个层的价值正快速从“谁做得最好”转向“谁提供得最无感”。就像你现在不会为“Linux 调度器哪家强”付费，你也不会为“agent sandbox 启动快 10ms”单独签单。它正在变成云账单里一行不起眼的 $0.08/session-hour，和你为 EC2 vCPU 付的钱一样自然。

这篇文章不讲概念，不画架构图，不列对比表格。我要带你钻进这个 runtime 层的毛细血管里，看 Anthropic 怎么用 YAML 定义一个能活三天的 agent，看 AWS 怎么用 microVM 把每个 session 隔成独立牢房，看为什么“trace portability”比“sandbox 启动速度”更能决定一家初创公司的生死。如果你正在评估要不要自建 agent infra，或者正被客户追问“你们的 agent 怎么保证不把 API key 泄露给模型”，或者只是好奇为什么 Gaurav Yadav 说“Anthropic 的 launch 是 defensive, not pioneering”——那接下来五千字，就是你该花的时间。

2. 核心设计解构：为什么必须把 state 拉出 context window？

2.1 旧范式的致命伤：Context Window 是个漏水的桶

先说清楚问题根源。当前绝大多数开源 agent 框架（LangChain、LlamaIndex、CrewAI）默认把 session state 当作“上下文的一部分”来管理。什么意思？举个具体例子：你让 agent 查天气，它调用 OpenWeatherMap API 返回了 JSON：

{"city": "Shanghai", "temp": 22.5, "condition": "Partly cloudy"}

传统做法是把这个 JSON 字符串直接拼进 system prompt 或 user message 里，变成：

你是一个天气助手。当前上海气温 22.5°C，多云。请用中文回答用户问题。

下一轮用户问“那湿度呢？”，agent 就带着这个“上海气温 22.5°C，多云”的记忆去调用另一个湿度 API。问题来了：每次调用新工具，返回结果都要塞进 context；每次模型思考，都要把之前所有工具结果、用户提问、系统指令全 load 进内存。LLM 的 context window 就像一个固定容量的桶——GPT-4 Turbo 是 128K token，Claude 3.5 Sonnet 是 200K，听起来很大，但实际一算就心凉。

我们做过实测：一个中等复杂度的金融分析 agent，每轮平均产生 1800 token 的工具返回（含 JSON 结构、错误信息、元数据），加上用户 query（平均 320 token）、system prompt（固定 1200 token）、模型思考过程（保守估计 2500 token），每轮消耗约 6000 token。128K ÷ 6000 ≈ 21 轮。这意味着：不到半小时的连续交互，context 就满了。而现实中的企业级任务远比“查天气”复杂：RAG 检索可能返回 5 个 chunk（每个 800 token），SQL 查询返回 20 行数据（每行 150 token），PDF 解析返回带格式的文本块……这些数据不是“信息”，而是“噪声源”——它们占据宝贵空间，却极少被后续步骤真正引用。更危险的是，当桶满时，LLM 不会报错，它会静默地把最早塞进去的 1000 token 删掉。你永远不知道哪条关键凭证、哪个核心参数、哪次审计日志被悄悄抹去了。这就是我前面说的“quiet and expensive failure”——没有 crash，只有缓慢失智。

提示：别信“我们用了 sliding window”这种话。Sliding window 只是把删除动作从“整段丢弃”变成“删开头几句话”，本质仍是无状态丢失。真正的 state persistence 必须脱离模型推理路径。

2.2 Anthropic 的解法：Session 作为独立事件日志

Anthropic Managed Agents 的核心突破，是把 session 从“模型上下文里的临时变量”，升格为“独立存储、可查询、可回溯的事件流”。它的实现逻辑非常干净：

• Session ID 是唯一入口：每次启动 agent，系统分配一个 UUID（如sess_abc123），这个 ID 成为所有操作的锚点。
• 所有操作写入 event log：工具调用（tool call）、模型输出（model response）、用户输入（user message）、guardrail 触发（guardrail violation）全部以结构化事件形式写入持久化存储（Anthropic 自建的 OLAP 数据库）。每条事件带 timestamp、event type、input payload、output payload、duration、status。
• Harness 只负责执行，不保存状态：Harnes 是一个极简的 stateless 服务，它只做三件事：1）接收execute(tool_name, input)请求；2）拉起 sandbox 执行；3）把结果封装成 event 写入 log。它自己不存任何 session 数据，重启后通过awake(sessionId)从 log 里重建上下文快照。
• 模型只看到“当前需要”的最小上下文：当模型要生成下一步响应时，Harness 不是把整个 event log 塞给它，而是用一套规则动态裁剪：只保留最近 N 条事件、所有未完成的 tool call、本次 task 的初始 goal。实测下来，同等任务下 context 体积压缩 65%，p50 time-to-first-token 下降 58%（官方数据 60%），p95 从 4.2s 降到 0.38s（官方数据 >90%）。

这个设计的精妙在于，它把“状态管理”这个高风险、高复杂度的工程问题，交给了成熟的数据库系统（ACID、事务、备份、审计），而不是交给不可控的 LLM 推理过程。你可以把 event log 想象成数据库的 binlog——它记录了所有变更，但不参与计算；计算由 harness 和 model 完成，它们只读取需要的部分。这就解释了为什么 Anthropic 强调 “the model context window stops being the load-bearing storage layer”。Load-bearing 意味着一旦它垮了，整个系统就崩。现在，context window 只是“缓存”，event log 才是“真相”。

2.3 AWS AgentCore 的硬核实现：MicroVM 是终极隔离

如果说 Anthropic 的方案是优雅的软件抽象，那 AWS Bedrock AgentCore 就是物理级的暴力美学。它在 2025 年底 GA 的 AgentCore，核心卖点是per-session microVM isolation。我们拆开看它怎么做到“sandbox as cattle”：

• 每个 session 独占一个 Firecracker microVM：Firecracker 是 AWS 开源的轻量级 VMM（Virtual Machine Monitor），启动时间 <125ms，内存开销 <5MB。AgentCore 为每个 session 分配一个独立 microVM，拥有专属 CPU core、独立内存空间（默认 2GB，可配）、完全隔离的 root filesystem。
• Credentials never touch the agent：这是生产环境的生命线。AgentCore 的 credential injection 机制是这样的：1）你在 IAM 中创建一个 role，授予其访问 S3、DynamoDB、Secrets Manager 的权限；2）AgentCore 在启动 microVM 时，将该 role 的临时 credentials 通过 virtio-fs 挂载到 microVM 的/run/credentials目录；3）agent 代码里调用boto3.Session()时，SDK 自动从该路径读取 creds——整个过程 agent 进程从未通过环境变量、stdin 或任何方式“看到”过 access key 和 secret。即使 agent 被 prompt 注入攻破，它也拿不到任何长期凭证。
• Filesystem 是只读的，除了 /tmp：microVM 的 rootfs 是只读镜像（基于 Amazon Linux 2023），所有 agent 代码、依赖包、配置文件都固化其中。唯一可写的路径是/tmp，且大小限制为 512MB。这意味着：1）无法持久化恶意 payload；2）无法篡改系统二进制；3）每次 session 结束，microVM 销毁，所有临时文件、内存、进程状态彻底清零。这才是真正的“cattle, not pets”。

我们做过压力测试：同时启动 500 个 session，每个 session 每秒发起 3 次 HTTP 请求（模拟真实工具调用），microVM 平均启动延迟 98ms，CPU 利用率峰值 62%，内存无泄漏。对比 Docker 容器方案（AWS 早期 PoC），microVM 的隔离强度提升 3 个数量级，而资源开销仅增加 15%。这就是为什么 AWS 敢说“sessions can run up to eight hours”——因为它的稳定性不依赖于进程管理，而依赖于硬件虚拟化层的成熟度。

3. 实操细节与关键配置：从 YAML 到生产部署

3.1 Anthropic Managed Agents：三步定义一个企业级 agent

Anthropic 的易用性体现在它把复杂的 infra 抽象成一份人类可读的 YAML。下面是一个真实用于 Notion 团队协作场景的 agent 定义（已脱敏）：

# notion-team-agent.yaml name: "notion-team-delegator" description: "Helps Notion workspace members delegate tasks to Claude by parsing natural language requests and creating pages in designated databases." # 系统指令，定义角色和边界 system_prompt: | You are a Notion assistant for enterprise teams. Your job is to: - Parse user requests like 'Create a meeting note for today's sync with engineering' or 'Add a new bug report about login timeout' - Extract structured data: database_id, title, properties (status, assignee, due_date), content blocks - NEVER create pages outside pre-approved databases (see allowed_databases below) - If user asks for something outside scope (e.g., 'send email', 'run SQL'), respond with: 'I can only help create Notion pages. Please rephrase.' # 工具列表，定义 agent 能做什么 tools: - name: "notion_create_page" description: "Creates a new page in a Notion database. Returns the page URL." input_schema: type: "object" properties: database_id: type: "string" description: "The ID of the target Notion database. Must be from allowed_databases." title: type: "string" description: "The title of the new page." properties: type: "object" description: "Key-value pairs for database properties (e.g., status, assignee)." content_blocks: type: "array" items: type: "object" description: "Notion block objects (paragraph, heading, to_do, etc.)." - name: "notion_search_database" description: "Searches a Notion database for existing pages matching criteria." input_schema: type: "object" properties: database_id: type: "string" query: type: "string" filter: type: "object" # 安全护栏：硬编码白名单，防止越权 allowed_databases: - "db-proj-tasks" # Project Task Database - "db-meeting-notes" # Meeting Notes Database - "db-bug-reports" # Bug Report Database # Guardrails：定义哪些行为必须拦截 guardrails: - type: "blocked_words" words: ["password", "secret", "api_key", "ssh_private_key"] action: "block_and_alert" - type: "output_safety" categories: ["harassment", "hate", "self-harm", "sexual"] threshold: 0.85 # 运行时配置 runtime_config: max_session_duration_hours: 72 # Session persists for 3 days max_tool_calls_per_session: 100 timeout_seconds: 300 # Per tool call

这份 YAML 的力量在于，它把四个原本分散的工程域统一了：

• 产品需求（system_prompt 描述了用户能做什么）
• API 集成（tools 定义了对接 Notion 的能力边界）
• 安全策略（allowed_databases + guardrails 是合规底线）
• 运维 SLA（runtime_config 设定了资源上限）

部署时，你只需anthropic agents deploy --file notion-team-agent.yaml。Anthropic 会自动：

1. 校验 YAML 语法和 schema；
2. 在后台创建对应的 harness 实例；
3. 将 allowed_databases 白名单同步到 credential vault；
4. 为每个 tool 注册 sandbox 模板（预装 Python 3.11、notion-sdk-py、requests）；
5. 生成唯一的 agent ID（如agent_notion_team_abc123）供前端调用。

注意：不要试图在system_prompt里写“请勿泄露 API key”。这是幻觉防火墙，不是真实防护。真正的防护在allowed_databases的硬编码白名单和notion_create_page工具的 input_schema 里——如果用户请求创建页面到db-payroll（未在白名单），harness 在调用前就会拒绝，根本不会走到模型推理环节。

3.2 AWS AgentCore：用 Terraform 管理 agent infra

AWS 的哲学是“infra as code”，所以 AgentCore 的配置不是 YAML，而是 CloudFormation/Terraform。以下是我们为 Rakuten 销售 agent 构建的最小可行 Terraform 模块（简化版）：

# main.tf provider "aws" { region = "us-east-1" } # 1. 创建 IAM Role，授予访问销售数据库和 Slack webhook 的权限 resource "aws_iam_role" "agent_sales_role" { name = "agent-sales-role" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{ Action = "sts:AssumeRole" Effect = "Allow" Principal = { Service = "bedrock.amazonaws.com" } }] }) } resource "aws_iam_role_policy_attachment" "sales_db_access" { role = aws_iam_role.agent_sales_role.name policy_arn = "arn:aws:iam::123456789012:policy/SalesDBReadOnly" } resource "aws_iam_role_policy_attachment" "slack_webhook" { role = aws_iam_role.agent_sales_role.name policy_arn = "arn:aws:iam::123456789012:policy/SlackWebhookInvoke" } # 2. 定义 AgentCore Agent，绑定 role 和 tools resource "aws_bedrock_agent" "sales_agent" { name = "rakuten-sales-agent" description = "Sales agent that routes leads from Slack to Salesforce and generates follow-up emails" auto_prepare = true # AgentCore 的核心：Tool Schema，定义工具能力 foundation_model = "anthropic.claude-3-5-sonnet-20240620-v1:0" instruction = "You are a sales assistant for Rakuten. Route qualified leads from Slack to Salesforce and draft personalized follow-up emails..." # Tool 定义，指向 Lambda 函数 tool { name = "salesforce_create_lead" description = "Creates a new lead in Salesforce using the provided contact info and source channel." input_schema = jsonencode({ type = "object" properties = { first_name = { type = "string" } last_name = { type = "string" } email = { type = "string" } source = { type = "string", enum = ["slack", "webform", "email"] } } required = ["first_name", "last_name", "email"] }) # 关键：Lambda ARN，AgentCore 会自动注入 creds tool_resource = aws_lambda_function.salesforce_lead_creator.arn } tool { name = "slack_send_message" description = "Sends a formatted message to a Slack channel or user." input_schema = jsonencode({ type = "object" properties = { channel = { type = "string" } text = { type = "string" } blocks = { type = "array" } } required = ["channel", "text"] }) tool_resource = aws_lambda_function.slack_messenger.arn } } # 3. Lambda 函数：真正的工具执行者 resource "aws_lambda_function" "salesforce_lead_creator" { filename = "salesforce_lead_creator.zip" function_name = "salesforce-lead-creator" role = aws_iam_role.lambda_exec.arn handler = "index.handler" runtime = "python3.11" # 注意：这里不需要配置 secrets，creds 由 AgentCore 注入 }

这个模块的价值在于，它把 agent 的生命周期完全纳入 AWS 的 IaC 体系：

• 安全即代码：aws_iam_role_policy_attachment显式声明了最小权限，审计时直接terraform show就能看到所有权限；
• 版本可追溯：每次terraform apply都生成 state snapshot，谁在什么时候修改了 tool schema 一目了然；
• 环境一致性：dev/staging/prod 环境用同一份代码，避免“在我机器上能跑”的悲剧；
• 成本透明：Terraform 输出会显示aws_bedrock_agent的 ARN，你可以在 Cost Explorer 里按 ARN 统计 session-hour 消耗。

我们实测过：一个包含 3 个 tools 的 agent，从terraform init到terraform apply完成部署，平均耗时 47 秒。而手动在控制台配置，平均需要 12 分钟，且极易漏掉aws_iam_role_policy_attachment这类关键安全配置。

3.3 生产环境必配的三件套：Observability, Governance, Portability

无论你选 Anthropic 还是 AWS，上线前必须搞定这三件事，否则就是裸奔：

1. Trace Store：选择你的“agent 黑匣子”

Event log 是基础，但 raw log 不是产品。你需要一个能查询、分析、告警的 trace store。目前三大玩家：

我们的经验：不要自己建。我们曾用 Elasticsearch 存 trace，半年后发现：1）schema evolution 痛苦（新增 tool 字段要 reindex）；2）查询慢（WHERE tool_name='notion_create_page' AND duration > 5000耗时 8s）；3）没有 LLM 专用 metric。切换到 Arize Phoenix 后，同样查询 <200ms，且一键生成 hallucination trend report。

2. Governance：Policy as Code

AWS AgentCore 在 2026 年 3 月 GA 的 Policy Controls，是企业采购的敲门砖。它允许你用 JSON 定义：

{ "version": "2026-03-01", "statements": [ { "effect": "DENY", "action": "bedrock:InvokeAgent", "resource": "*", "condition": { "StringNotEquals": { "bedrock:AgentName": ["rakuten-sales-agent", "rakuten-marketing-agent"] } } }, { "effect": "ALLOW", "action": "bedrock:InvokeAgent", "resource": "arn:aws:bedrock:us-east-1:123456789012:agent/rakuten-sales-agent", "condition": { "IpAddress": { "aws:SourceIp": ["203.0.113.0/24", "198.51.100.0/24"] } } } ] }

这相当于给 agent 加了两把锁：1）只有指定名字的 agent 能被调用；2）调用 IP 必须来自公司办公网段。Policy 可以 attach 到 IAM role，实现“谁有权限调用哪个 agent，在哪里调用”。

实操心得：Policy 不是写完就完事。我们每周用aws bedrock list-agents+aws iam get-policy-version自动扫描，生成报告：哪些 agent 没绑定 policy？哪些 policy 的aws:SourceIp还是测试网段？这已成为我们 SOC2 审计的标准项。

3. Portability：Trace Export 是生命线

最残酷的现实：今天你用 Anthropic，明天可能因价格或功能切换到 Azure。如果 trace 数据锁死在 Anthropic 的数据库里，你就失去了所有历史 session 的分析能力。解决方案是OpenTelemetry for LLM（OTel LLM）标准。

我们强制所有 agent 在写 event log 时，同时 emit OTel trace：

from opentelemetry import trace from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter from opentelemetry.sdk.trace import TracerProvider from opentelemetry.sdk.trace.export import BatchSpanProcessor # 初始化 exporter，指向你的 OTel collector（如 Jaeger, Datadog） exporter = OTLPSpanExporter(endpoint="https://your-otel-collector/api/v2/spans") provider = TracerProvider() processor = BatchSpanProcessor(exporter) provider.add_span_processor(processor) # 在每个 tool call 前后打点 def notion_create_page(input): tracer = trace.get_tracer(__name__) with tracer.start_as_current_span("notion.create_page") as span: span.set_attribute("notion.database_id", input["database_id"]) span.set_attribute("notion.title", input["title"]) result = _actual_call(input) # 真实调用 span.set_attribute("notion.page_url", result["url"]) return result

OTel 的好处是 vendor-neutral：今天 collector 发送到 Arize，明天可以切到 Datadog，trace 数据结构不变。我们用这套方案，实现了跨平台 trace 迁移——把 Anthropic 的 200 万条历史 session，用 3 天时间导入到自建的 Arize 集群，零数据丢失。

4. 常见问题与实战排查：那些文档里不会写的坑

4.1 “Session 持久化失效”：不是 bug，是设计误解

现象：用户反馈“我的 agent 设置了max_session_duration_hours: 72，但第二天再调用就提示 session not found”。

排查过程：

1. 首先确认 session ID 是否正确传递：检查前端是否在每次请求 header 里带上X-Session-ID: sess_abc123。常见错误是前端用localStorage存 ID，但用户换浏览器或清缓存后 ID 丢失。
2. 检查 Anthropic 的 session TTL 机制：max_session_duration_hours是“自创建起 72 小时”，不是“最后活跃起 72 小时”。如果 session 创建后 2 小时没任何 activity，它不会自动续期。
3. 最关键的：session 持久化不等于 state 持久化。Anthropic 的 session ID 只保证 event log 可查，但 harness 重启后，它只会从 log 里重建“最近 10 条事件”的快照。如果用户期望 agent 记住“昨天我说过喜欢咖啡”，那是 memory management 层的事，不是 session 层。

解决方案：

• 前端：用 cookie（HttpOnly + Secure）存 session ID，比 localStorage 更可靠；
• 后端：在awake(sessionId)后，主动调用get_session_state(sessionId)获取完整 event log，用 Redis 缓存最近 100 条，供模型生成时参考；
• 产品：明确告知用户“session 有效期 72 小时，但长期记忆需开启 memory 功能（额外收费）”。

4.2 “Credential Leak”：当 sandbox 没有真正隔离

现象：安全团队扫描发现，agent 的 sandbox 容器里存在AWS_ACCESS_KEY_ID环境变量。

根因分析： 这是典型的“伪 sandbox”陷阱。很多团队用 Docker +--env-file启动容器，把 creds 作为环境变量注入。而 Anthropic/AWS 的 sandbox 机制是：creds 存在 vault，sandbox 进程通过 IPC 临时获取 token，绝不落地为 env var。如果你在 agent 代码里写了print(os.environ.get('AWS_ACCESS_KEY_ID'))，它一定是空的。

但我们发现一个隐蔽漏洞：某些 Python SDK（如 boto3 1.28.0 之前版本）在找不到~/.aws/credentials时，会 fallback 到os.environ。如果开发者为了调试，在 sandbox 启动脚本里加了export AWS_ACCESS_KEY_ID=xxx，就绕过了所有安全设计。

修复步骤：

1. 立即审计所有 sandbox 启动脚本，删除所有export AWS_*行；
2. 升级 boto3 到 1.28.0+，它默认禁用 env var fallback；
3. 在 sandbox 的 entrypoint 脚本里加入检测：

# 检查是否有敏感 env var if [ -n "$AWS_ACCESS_KEY_ID" ] || [ -n "$AWS_SECRET_ACCESS_KEY" ]; then echo "CRITICAL: Sensitive env vars detected. Exiting." >&2 exit 1 fi

4. 在 CI/CD 流程中加入静态扫描：用grep -r "export AWS_" ./sandbox-scripts/。

4.3 “Pricing 突增”：$0.08/session-hour 的隐藏成本

现象：月账单从 $2000 暴涨到 $15000，但 session count 只增 20%。

深度排查： 我们导出 Anthropic 的 billing CSV，发现session-hour列异常高。正常情况：一个 session 平均活跃 3 分钟，1 小时可支撑 20 个 session。但数据里出现大量session-hour> 1 的记录。

真相：session-hour的计费逻辑是：从create_session到delete_session的总时长，按小时向上取整。而 Anthropic 的 session 默认不会自动销毁——它一直活着，直到你显式调用delete_session，或超过max_session_duration_hours。

我们发现一个业务逻辑 bug：客服 agent 每次接待用户，都会create_session，但用户关闭聊天窗口时，前端没有触发delete_session。结果是：1 万个 session 同时在线，每个存活 24 小时，session-hour= 10000 × 24 = 240000 小时，费用 = 240000 × $0.08 = $19200。

止损方案：

• 立即上线session cleanup cron：每 5 分钟扫描last_activity_time < now - 30m的 session，自动delete_session；
• 前端埋点：在beforeunload事件里调用delete_session；
• 在 billing dashboard 里设置告警：session-hour/day > 10000时邮件通知。

4.4 “Tool Call Timeout”：不是网络问题，是 sandbox 资源不足

现象：notion_create_page工具调用频繁超时（300s），但 Notion API 本身响应 <1s。

排查路径：

1. 首先排除网络：在 sandbox 容器里curl -v https://api.notion.com，确认 DNS 和 TLS 正常；
2. 检查 Notion rate limit：Notion 的/v1/pagesendpoint 有 3 req/sec 限制，但我们的日志显示并发 <1；
3. 关键线索：超时都发生在下午 2-4 点，和公司内部会议高峰重合。

根因： Anthropic 的 sandbox 是 shared resource pool。当大量客户在同一 region（us-east-1）启动高 CPU 工具（如 PDF 解析、图像处理），pool 会 throttling。我们的notion_create_page虽然简单，但它依赖的 Python SDK 在序列化大 JSON 时会 spike CPU。

解决方案：

• 在 tool 定义里显式声明资源需求：

tools: - name: "notion_create_page" # 告诉 Anthropic 这是个轻量级工具，优先分配低负载 sandbox resource_requirements: cpu: "256m" # 256MB RAM, 0.1 vCPU memory: "512Mi"

• 对 CPU 密集型工具（如pdf_parse），申请更高配 sandbox（cpu: "1024m"），并接受更高 price；
• 在 agent 逻辑里加入 circuit breaker：连续 3 次 timeout 后，降级到备用方案（如返回“稍后重试”）。

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

5.1 Trace Store：从日志到法律证据

去年我们帮一家医疗科技公司做 HIPAA 合规 agent。他们的 agent 会解析患者病历 PDF，提取诊断信息，生成结构化 JSON 提交到 EHR 系统。审计时，律师问了一个尖锐问题：“如果患者投诉 agent 错误地将‘高血压’标记为‘糖尿病’，你们如何证明 agent 当时看到的原始 PDF 内容？”

我们当时的回答很苍白：“我们有 event log，里面存了 PDF 的 base64。” 律师摇头：“base64 不是原始证据。法庭需要可验证的哈希值，需要证明从 PDF 到 JSON 的每一步转换都未被篡改。”

这催生了Verifiable Trace的新需求。现在的顶级 trace store（如 Braintrust 的 Brainstore）已支持：

• Immutable Log：每条 event 写入时，用私钥签名，生成signature: sha256(event_json + timestamp + nonce)；
• Merkle Tree Root：每小时生成一个 Merkle root hash，发布到 Ethereum L2（如 Arbitrum），供第三方验证；
• Zero-Knowledge Proof：允许向审计方证明“某次诊断结果确实来自某份 PDF”，而不泄露 PDF 内容。

这意味着：trace store 不再是运维工具，而是法律合规的基础设施。一家公司如果 trace store 被攻破，它面临的不是 downtime，而是集体诉讼。这就是为什么 Braintrust 能在 $150M 估值融到 $36M——投资者买的不是软件，是医疗、金融、法律行业的“数字公证处”牌照。

5.2 Governance：从策略到采购卡

AWS AgentCore 的 Policy Controls GA，表面是技术功能，实则是Enterprise Procurement 的入场券。我们跟踪了 12 家 Fortune 500 企业的采购流程，发现一个规律：当一项新技术要进入企业采购目录（Procurement Catalog），必须满足三个条件：

1. 有明确的合规认证（SOC2, HIPAA, ISO27001）；
2. 有可审计的策略引擎（Policy as Code）；
3. 能绑定到现有 IAM/SSO 体系（如 Okta, Azure AD）。

AgentCore 在 2026 年 3 月同时满足这三点，于是它出现在了 Salesforce、JPMorgan、