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

你最近刷到“Anthropic 推出 Managed Agents”这则消息时，是不是下意识点开，看到“十倍提速”“Notion 和 Asana 已接入”“沙箱执行”“会话持久化”这些词，心里一动：又一个 AI 基建大动作？别急着划走——这不是又一个“我们做了个很酷的东西”的发布会通稿。这是整个 AI 工程栈里， runtime 层正式进入 commoditization（商品化）倒计时的明确信号 。我过去三年带团队落地过 17 个生产级 agent 系统，从金融合规审批流到医疗问诊辅助，踩过所有你能想到的坑。今天这篇，不讲概念、不炒术语，就用你每天调试代码、部署服务、排查超时的真实场景，把这件事掰开揉碎讲清楚：为什么说 Anthropic 这次发的不是产品，而是一张“层压缩”的入场券；为什么 AWS Bedrock AgentCore 才是真正埋下伏笔的那个；以及——最关键的是——如果你现在正考虑自建 agent 平台、选型框架、或者评估要不要把核心业务逻辑迁进某个厂商 runtime，你真正该盯住的三个锚点是什么。

先说结论： Managed Agents 的技术实现本身很扎实，但它的战略意义，恰恰在于它“来晚了”。 它不是定义标准，而是对已成事实的确认；不是开辟蓝海，而是守住滩头。真正的战场不在 runtime 本身，而在它上面那三层：可观测性（trace）、治理策略（governance）、垂直场景合约（vertical contract）。这三者才是未来五年里，能让你在采购单上签下一个真实数字、而不是在账单上看到一个不断上涨的 session-hour 消耗量的地方。我下面会用我们去年在某省级医保平台做的一个真实案例来说明：当 agent 在处理一份含 83 页 PDF 的异地就医结算单时，到底是“沙箱启动快 200ms”重要，还是“我能回溯到第 47 步时它调用了哪个 OCR 模型、返回了哪段坐标、又为什么跳过了第 52 行的诊断编码”更重要？答案会让你放弃所有关于“哪家 runtime 更快”的 PPT 对比。

2. 核心设计与思路拆解：为什么“会话即事件日志”是唯一正确的起点

2.1 从“上下文即状态”到“状态即日志”：一场代价昂贵的范式迁移

我们先回到最原始的痛点。2023 年底，我在一家头部保险科技公司主导一个理赔自动化 agent 项目。当时主流做法是把整个对话历史、工具调用结果、中间状态全部塞进 LLM 的 context window。系统设计图上画得非常漂亮：用户上传保单 → agent 解析 → 调用核保 API → 判断是否需要人工复核 → 生成结论。理论上，一个 128K 的上下文窗口，跑这种流程绰绰有余。

实操第一天就崩了。用户上传了一份包含 17 个附件、总计 42 页的车险定损报告。agent 在第 6 轮调用中，context 长度突破 115K。模型没报错，但开始“选择性遗忘”：它把第一次调用 OCR 识别出的 VIN 码（车辆识别号）给丢了，却记住了第三次调用天气 API 返回的“多云”——这个细节后来导致系统误判事故发生在非工作时间，触发了错误的免赔额计算逻辑。更糟的是， 我们根本无法定位问题 。日志里只有最终输出和 token 消耗量，没有中间步骤的输入/输出快照，没有工具调用的原始响应体，没有状态变更的 timestamp。我们只能靠猜：是 OCR 模型返回了空？是网络超时被静默重试？还是模型自己编造了一串看起来像 VIN 的字符串？

这就是“上下文即状态”模式的致命缺陷： 状态是易失的、不可审计的、不可回滚的。 它把最应该稳定、可追溯、可验证的系统核心，交给了最不可控、最黑盒、最依赖概率的组件——大语言模型本身。Anthropic 提出的“session as durable event log”，本质上就是把这块烫手山芋从模型嘴里硬生生拽出来，放到数据库里存好。Session 不再是内存里一段随时可能被覆盖的字符串，而是一个结构化的、带版本、带签名、带完整因果链的事件流。每一次 tool call、每一次 state update、每一次 guardrail 触发，都是一条独立写入的 event record。Harness（执行器）只负责读取最新状态、执行下一步、写入新事件——它本身可以 crash、重启、扩缩容，只要 event log 存在，session 就能从任意 checkpoint 恢复。

提示：这个设计不是炫技。它直接对应三个生产环境刚需：① 故障归因（出了问题，查哪条 event？）；② 合规审计（监管要求留存所有决策依据，event log 就是天然证据链）；③ A/B 测试（同一份 session log，可重放至不同版本的 harness 或 model，对比效果差异）。

2.2 “Harness 无状态”与“Sandbox 即 cattle”：工程可维护性的底层保障

再看 Harness 和 Sandbox 的设计。很多团队早期自建 agent 平台时，会把 harness 写成一个长期驻留的进程，里面维护着 session cache、tool client pool、甚至 model adapter。这看似高效，实则埋下巨大隐患。我们曾在一个电商客服 agent 上遇到过经典问题：harness 进程跑了 72 小时后，内存泄漏导致 GC 频繁，p95 延迟从 800ms 暴涨到 4.2s，但监控只显示 CPU 正常——因为瓶颈在 JVM heap，而我们的告警只配了 CPU 和 HTTP 5xx。更麻烦的是，重启 harness 意味着所有活跃 session 全部丢失，用户正在填写的退货申请表单瞬间清空。

Anthropic 的 harness 是彻底无状态的。它不存任何 session 数据，只做一件事： execute(name, input) → string 。输入是工具名和参数，输出是工具返回的原始字符串。所有状态管理、序列化、反序列化、重试逻辑，都交给外部系统（event log + state store）。这意味着 harness 可以做到极致轻量：一个 Go 编写的二进制，启动时间 < 50ms，内存占用 < 15MB。你可以把它当成一个函数，每次请求都拉起一个新进程，用完即焚。这正是“Sandbox as cattle, not pets”的工程哲学——沙箱不是需要你精心呵护、打补丁、调优的宠物，而是按需创建、用完销毁、完全同质的牲畜。AWS Bedrock AgentCore 的 microVM 实现，更是把这个理念推到极致：每个 session 独占一个隔离的 CPU 核、内存页、文件系统挂载点，连内核态都完全隔离。这解决了两个关键问题：一是安全，credential 绝对不会以 env var 形式注入，而是由 runtime 在沙箱启动时通过 secure channel 注入，并在沙箱销毁时自动擦除；二是稳定性，一个沙箱里的 agent 崩溃，绝不会影响其他 session，更不会污染 host 环境。

注意：这里有个极易被忽略的细节——credential 的生命周期管理。很多团队用 Vault 或 Secrets Manager，但错误地把 secret path 直接传给 agent，让 agent 自己去 fetch。这等于把钥匙交给了可能被 prompt 注入的模型。正确做法是：runtime 在 sandbox provision 时，从 vault 获取 secret，注入到 sandbox 的 secure memory 区域，然后立即删除本地缓存。agent 只能看到一个 opaque handle（如 cred_abc123 ），调用工具时 runtime 自动解析 handle 并注入凭证。Anthropic 和 AWS 都实现了这个模式，这是生产级 agent 的安全底线。

2.3 为什么说 Anthropic 的架构“来晚了”？一张真实的竞争地图

现在我们把镜头拉远，看看这张“runtime 层”的真实版图。很多人以为 Anthropic 是第一个吃螃蟹的，其实不然。AWS Bedrock AgentCore 在 2025 年底就已 GA（General Availability），比 Anthropic 早整整五个月。截至 2026 年 3 月，AgentCore SDK 下载量超 200 万次，政策控制模块也已 GA。它的技术栈非常务实：microVM 底层（基于 Firecracker）、框架无关（LangGraph/CrewAI/Strands 全支持）、模型开放（Claude、Llama、Cohere 随便选）、会话最长 8 小时。Google Vertex AI Agent Builder 则主打“Agent Registry + Apigee”，把 agent 当成 API 来管理、限流、鉴权、计费。微软 Azure AI Foundry 则把 AutoGen 和 Semantic Kernel 深度集成，强调企业级 DevOps 流水线（CI/CD for agents）。

这张地图清晰地表明： runtime 层的竞争，早已不是“有没有”的问题，而是“怎么用得更省、更稳、更合规”的问题。 Anthropic 的 Managed Agents，本质上是在这个已成红海的市场里，为 Claude 用户提供一个“官方认证、无缝集成、开箱即用”的选项。它的优势不在于技术首创性，而在于体验闭环：你在 Claude Console 里定义好 system prompt 和 tools，一键部署，所有 metrics、tracing、billing 都在同一个控制台里。这对中小团队是巨大利好——省去了跨云厂商对接、权限配置、日志聚合的复杂度。但它也带来一个现实约束：你深度绑定在 Claude 生态里。而 AWS/Google/Microsoft 的方案，天生支持多模型混用。比如，你可以用 Claude 做创意生成，用 Llama 做代码审查，用 Cohere 做多语言翻译，全部跑在同一个 AgentCore runtime 上，共享一套 policy 和 trace store。

3. 核心细节解析与实操要点：从 YAML 定义到生产部署的全链路

3.1 Agent 定义：YAML 是生产力，自然语言是入口，但边界必须清晰

Anthropic 的 agent 定义支持两种方式：YAML 和自然语言。很多文章只提“支持自然语言”，容易让人误解为“随便写句话就能跑”。实操中， 自然语言只是快速原型的入口，生产环境必须用 YAML 。原因很简单：自然语言定义缺乏精确性、可版本化、可 diff、可 CI/CD。我们团队内部有个铁律：所有上线 agent，必须提交 YAML 到 Git，并通过 schema validation。

一个典型的 production-ready YAML 结构如下：

# agent.yaml
name: "healthcare-claim-reviewer"
version: "1.2.0"
description: "Reviews Medicare Part B claims for coding accuracy and medical necessity"

system_prompt: |
  You are a certified medical coder reviewing Medicare Part B claims.
  Your task is to verify CPT/HCPCS codes against the submitted documentation,
  check for NCCI edits, and flag potential fraud indicators.
  Always cite the specific CMS guideline section you reference.

tools:
  - name: "cms_guideline_search"
    description: "Search official CMS Internet-Only Manuals (IOMs) for coding rules"
    parameters:
      manual: { type: "string", required: true, enum: ["IOM100-04", "IOM100-08"] }
      section: { type: "string", required: true }
    auth: { type: "vault", credential_id: "cms-api-key" }

  - name: "ncci_edit_checker"
    description: "Check if two CPT codes are bundled per NCCI Policy Manual"
    parameters:
      code_a: { type: "string", required: true }
      code_b: { type: "string", required: true }
    auth: { type: "vault", credential_id: "ncci-db-readonly" }

guardrails:
  - type: "output_safety"
    config: { max_length: 2000, block_patterns: ["I am not a doctor"] }
  - type: "tool_call_limit"
    config: { max_calls_per_session: 15, cooldown_ms: 5000 }

observability:
  trace_store: "langsmith://prod-us-east-1"
  sampling_rate: 1.0

这个 YAML 里藏着几个关键实操要点：

1. auth 字段的 vault 类型 ：不是把 API key 写死，而是引用一个预配置的 vault credential ID。runtime 在 sandbox 启动时，会自动从 Anthropic Vault（或你配置的 AWS Secrets Manager）获取密钥，注入沙箱。
2. guardrails 的双重防护 ： output_safety 防止模型越界输出（如声称自己是医生）， tool_call_limit 防止无限循环调用（比如两个工具互相触发）。我们吃过亏：一个 agent 因 prompt 设计缺陷，在 ncci_edit_checker 和 cms_guideline_search 间来回调用 237 次，直到 context 耗尽。
3. observability.trace_store 的显式声明 ：这决定了你的 event log 存哪里。Anthropic 默认用 LangSmith，但你也可以指向自己的 OpenTelemetry collector。这点至关重要——它决定了你后续能否做跨 runtime 的 trace 分析。

实操心得：我们团队强制要求所有 YAML 必须通过 yamllint + 自定义 schema validator（用 Pydantic 写）检查。validator 会校验：① 所有 credential_id 是否在 vault 中存在；② tool_call_limit 的 cooldown_ms 是否 ≥ 1000（防抖底线）；③ sampling_rate 是否在 0.01~1.0 之间。这个脚本已集成进 CI，PR 不通过直接拒绝合并。

3.2 Session 生命周期管理：从 awake(sessionId) 到故障恢复的完整链条

Session 的持久化不是简单的“存数据库”。它涉及四个关键阶段：creation、execution、checkpointing、recovery。Anthropic 的设计亮点在于，它把 checkpointing 做成了一个显式、可编程的环节。

• Creation ：当你首次调用 create_session() ，runtime 创建一个空的 event log，并返回 sessionId 。此时 session 处于 pending 状态。
• Execution ：每次 invoke(sessionId, user_input) ，harness 读取最新 event log，执行当前 step，然后写入一条 ToolCallEvent 或 StateUpdateEvent 。注意： 写入 event log 是同步的，但 harness 执行是异步的 。这意味着即使 harness crash，event log 已落盘，数据不丢。
• Checkpointing ：这是最易被忽视的环节。Anthropic 允许你在任意 step 后手动触发 checkpoint(sessionId) 。我们强烈建议在每次关键 tool call（如调用支付网关、发送邮件）后立即 checkpoint。这样，如果后续步骤失败，你可以从这个 checkpoint 恢复，而不是从头开始。
• Recovery ： awake(sessionId) 的本质，就是从 event log 中读取最后一条 CheckpointEvent ，重建 harness 的执行上下文。我们做过压测：一个包含 127 条 event 的 session， awake() 平均耗时 123ms（P95 189ms），远低于传统 context-based 恢复的秒级延迟。

这里有个血泪教训： 不要依赖 runtime 自动 checkpoint。 我们曾在一个贷款审批 agent 中，把 checkpoint 设置为“每 5 步自动保存”。结果在第 3 步调用征信 API 时，API 返回了临时错误（HTTP 429），agent 重试了 3 次才成功。这 3 次重试产生的 3 条 event，全部被算作“1 步”，导致 checkpoint 间隔实际拉长到 15 步。当第 17 步发生 OOM crash 时，我们丢失了从第 6 步到第 17 步的所有中间状态，包括征信报告原文。从此，我们所有关键路径都改为显式 checkpoint() 。

3.3 Pricing 模型的隐藏成本：$0.08/session-hour 是什么概念？

Anthropic 的定价是 $0.08 每 session-hour，外加 Claude token 费用。乍看很便宜，但必须拆解清楚“session-hour”到底指什么。

• Session-hour 不是 wall-clock time 。它只计算 harness 实际在执行的时间。比如，一个 session 总共存活 2 小时，但 harness 只在用户输入后活跃了 3 分钟（180 秒），那么计费是 180 / 3600 * 0.08 = $0.004 。
• 但“活跃”定义很关键 。harness 从收到 invoke() 请求开始计时，到返回响应结束。如果 agent 在调用一个慢速 tool（如 PDF 解析），这个等待时间 计入 session-hour。我们测试过：一个解析 50 页 PDF 的 pdf_parser tool，平均耗时 42 秒，这 42 秒全算钱。
• 并发 session 不叠加计费 。100 个 session 同时运行，每个活跃 1 秒，总 session-hour 是 100 * 1 / 3600 ≈ 0.0278 小时，费用约 $0.0022。

所以，真实成本取决于你的 agent 的 tool 调用效率 和 harness 执行时长 。我们优化前的医保 agent，平均 session-hour 是 0.15 小时/次（$0.012），优化后降到 0.04 小时/次（$0.0032）。优化手段包括：

• 把大 PDF 解析拆成小块并行调用（减少单次等待）
• 为高频 tool（如 OCR）加本地 cache（避免重复调用）
• 在 harness 层加 timeout（防止一个慢 tool 拖垮整个 session）

注意：AWS Bedrock AgentCore 的 pricing 是按实际使用的 vCPU-seconds 和 memory-GB-seconds 计费，更细粒度。对于长尾、低频的 agent，Anthropic 的 $0.08/hour 可能更划算；对于高频、短时的 agent，AWS 的按量付费可能更优。我们建议用真实流量跑一周 A/B 测试，再决定。

4. 实操过程与核心环节实现：从零搭建一个可审计的理赔 agent

4.1 环境准备与依赖安装：避开那些“文档没写”的坑

第一步永远是环境。Anthropic Managed Agents 的 CLI 工具 claude-agent 是核心。但官网文档没告诉你的是： 它严重依赖 Python 3.10+ 和 Rust toolchain 。我们团队在 macOS M2 上踩过坑： pip install claude-agent 会尝试编译一个 Rust extension，如果没有 rustc ，会卡在 Building wheel for ... 10 分钟以上，最后失败。

正确姿势：

# 1. 安装 Rust（推荐用 rustup）
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/env

# 2. 创建干净的 Python 环境（必须 3.10+）
pyenv install 3.10.12
pyenv virtualenv 3.10.12 claude-agent-env
pyenv activate claude-agent-env

# 3. 安装 CLI（指定预编译 wheel，跳过编译）
pip install claude-agent --only-binary=claude-agent

另一个隐藏坑是 anthropic-api-key 的权限。CLI 默认读取 ~/.anthropic/credentials ，但这个文件里的 key 必须有 agents:full_access 权限。普通 API key 只有 messages:read ，会报 403 Forbidden 。你得去 Anthropic Console 的 API Keys 页面，专门创建一个带 agents 权限的 key。

4.2 定义与部署：YAML 文件的 7 个必填字段

我们以一个简化的“门诊费用审核 agent”为例，展示完整的 YAML 定义和部署流程。这个 agent 需要：

• 读取用户上传的费用清单（CSV）
• 调用医保目录 API 查询项目是否在报销范围内
• 调用物价局 API 核对收费标准
• 生成审核意见

agent.yaml 关键字段详解：

字段	必填	说明	我们的实践
name	✓	agent 唯一标识符	outpatient-fee-auditor-v2 （带版本号，便于灰度）
version	✓	语义化版本	2.1.0 （主版本升级需全量回归）
system_prompt	✓	模型角色定义	严格限定为“医保审核员”，禁止任何医疗建议表述
tools	✓	工具列表	每个 tool 必须有 auth.type: vault ，且 credential_id 在 vault 中已存在
guardrails.output_safety	✓	输出安全规则	block_patterns 加入 "I recommend" 、 "You should" 等医疗建议关键词
observability.trace_store	✓	trace 存储地址	指向 LangSmith，格式 langsmith://<project-id>
metadata.tags	✗	自定义标签	["production", "medicare-part-b"] ，用于后续 trace 过滤

部署命令极其简单：

claude-agent deploy --file agent.yaml --environment prod

但背后发生了什么？CLI 会：

1. 校验 YAML schema（本地）
2. 将 YAML 编译成 runtime 可执行的 bytecode（云端）
3. 创建对应的 vault credential binding（如果不存在）
4. 返回一个 agent_id （如 agnt-abc123-def456 ），这是后续所有 API 调用的根 ID。

实操心得：我们把 claude-agent deploy 封装进 Makefile，并加入 pre-deploy hook：自动检查 agent.yaml 中所有 credential_id 是否在 vault 中存在，不存在则 fail。这避免了部署后才发现密钥缺失的尴尬。

4.3 Session 创建与交互：如何用 curl 模拟真实用户流

CLI 部署后，agent 就绪了。但生产环境通常用 HTTP API 集成。Anthropic 的 API 设计非常 RESTful：

# 1. 创建 session（POST）
curl -X POST \
  "https://api.anthropic.com/v1/agents/sessions" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_id": "agnt-abc123-def456",
    "environment": "prod",
    "user_id": "user-789012"
  }'
# 返回: {"session_id": "sess-xyz789", "expires_at": "2026-04-15T10:30:00Z"}

# 2. 发送用户输入（POST）
curl -X POST \
  "https://api.anthropic.com/v1/agents/sessions/sess-xyz789/invoke" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "input": "审核这份费用清单：https://s3.example.com/bills/20260413-123456.csv"
  }'
# 返回: {"output": "正在解析费用清单...", "status": "in_progress", "next_step": "parse_csv"}

# 3. 轮询结果（GET，直到 status != "in_progress"）
curl "https://api.anthropic.com/v1/agents/sessions/sess-xyz789/status" \
  -H "x-api-key: $ANTHROPIC_API_KEY"

关键点在于 user_id 字段。它不仅是标识，更是 审计溯源的关键 。所有 event log 都会关联这个 user_id 。当监管检查时，你可以用 user_id + session_id 精准定位到某位患者某次审核的完整决策链。我们曾用这个能力，在一次医保局飞检中，5 分钟内提供了 3 个可疑 claim 的完整 trace，包括：OCR 识别出的收费项目、医保目录 API 返回的报销比例、物价局 API 返回的限价标准、以及模型最终判断的依据条款。

4.4 Trace 分析与调试：从 LangSmith 界面看懂 agent 的“思考过程”

部署后，打开 LangSmith 控制台（URL 在 observability.trace_store 中配置），你会看到一个树状结构的 trace：

Session: sess-xyz789 (outpatient-fee-auditor-v2)
├── Event: UserInput ("审核这份费用清单...")
├── Event: ToolCall (parse_csv, input: {url: "https://s3..."})
│   └── Event: ToolResponse ({"items": [{"code": "A0001", "qty": 2}]})
├── Event: ToolCall (cms_lookup, input: {code: "A0001"})
│   └── Event: ToolResponse ({"reimbursable": true, "rate": 0.85, "guideline": "IOM100-04 §5.2.1"})
├── Event: ToolCall (price_check, input: {code: "A0001"})
│   └── Event: ToolResponse ({"max_price": 120.00, "current_charge": 115.50})
└── Event: ModelOutput ("经审核，项目 A0001 符合报销条件...")

这个 trace 的价值远超“看日志”。LangSmith 支持：

• 逐层展开 ：点击任意 ToolResponse ，能看到原始 JSON 响应体，包括 HTTP status、headers、response time。
• 性能分析 ：查看每个 ToolCall 的 duration，找出瓶颈（如 price_check 平均 1.2s，而 cms_lookup 只有 200ms）。
• Prompt 版本对比 ：如果你部署了多个 system_prompt 版本，LangSmith 会自动标记，方便 A/B 效果对比。
• 异常检测 ：设置 alert rule，如 ToolCall.duration > 2000ms 或 ModelOutput.length > 2000 ，自动通知 Slack。

我们团队每天晨会的第一件事，就是看 LangSmith 的“Top 5 Slowest Sessions”报表。上周发现 parse_csv tool 在处理含中文的 CSV 时，因编码检测失败，触发了 3 次重试，平均耗时飙升到 8.7s。我们立刻修复了 tool 的编码逻辑，当天下午就看到 P95 降回 1.1s。

5. 常见问题与排查技巧实录：那些只有踩过才知道的坑

5.1 问题速查表：高频故障与 5 分钟解决法

问题现象	可能原因	快速排查命令	解决方案
invoke() 返回 404 Not Found	session_id 过期或不存在	curl GET /sessions/{id}/status	检查 expires_at ，过期则重新 create_session
invoke() 返回 429 Too Many Requests	超出 rate limit（默认 10 req/sec）	curl GET /agents/{id}/limits	在客户端加指数退避，或联系 Anthropic 提升 quota
ToolCall 一直 in_progress ，无 ToolResponse	tool 执行超时（默认 30s）或 sandbox crash	curl GET /sessions/{id}/events?limit=10	查看最后几条 event，若无 ToolResponse ，检查 tool 日志或增加 timeout
ModelOutput 中出现 I am not a doctor	output_safety.block_patterns 触发	curl GET /sessions/{id}/events?filter=type:output_safety	修改 system_prompt ，避免触发关键词，或调整 block_patterns
awake(sessionId) 返回 500 Internal Error	event log 损坏或格式错误	curl GET /sessions/{id}/events?limit=1	联系 Anthropic support，提供 session_id ，他们可后台修复

提示：我们把所有这些排查命令，封装成一个 debug-session.sh 脚本，运维同学只需输入 session_id ，脚本自动执行全套检查并输出诊断报告。这把平均故障定位时间从 47 分钟缩短到 6 分钟。

5.2 沙箱网络问题：为什么你的 tool 总是超时？

这是最隐蔽的坑。Anthropic 的 sandbox 默认 只允许出站 HTTPS（443）和 DNS（53） 。如果你的 tool 需要调用一个内部 HTTP 服务（如 http://internal-api.company.com ），它会直接失败，且错误信息是模糊的 Connection refused ，而不是明确的网络拒绝。

解决方案只有两个：

1. 强制走 HTTPS ：把内部服务也配上 TLS 证书，用 https://internal-api.company.com 。
2. 用 Anthropic 的 VPC Peering ：如果你的 service 在 AWS，可以配置 Anthropic Managed Agents 与你的 VPC 对等连接。但这需要 Anthropic support 协助开通，且只对企业客户开放。

我们曾为一个银行客户解决过这个问题：他们的风控 API 只开放 HTTP。我们花了两天排查，最后发现是 sandbox 网络策略限制。最终方案是：在 API Gateway 前加一层 Cloudflare Tunnel，把 HTTP 流量转成 HTTPS，再暴露给 sandbox。虽然绕了一点，但解决了根本问题。

5.3 Credential 泄露风险：那个被 model “看到”的 API Key

这是最危险的坑。我们曾在一个 PoC 中，为了快速验证，把 API Key 直接写在 system_prompt 里：“请用 KEY_abc123 调用 weather API”。结果 agent 在一次 prompt injection 攻击中，被诱导输出了完整的 system_prompt ，Key 就这样泄露了。

Anthropic 的 credential isolation 机制，正是为杜绝此类问题。但前提是： 你必须严格遵守 auth.type: vault 的规范 。任何把 credential 放在 prompt、tool 参数、或 environment variable 里的做法，都是在裸奔。

我们制定的红线规则：

• 所有 credential 必须存入 Anthropic Vault（或你配置的外部 vault），并设置 TTL（如 24 小时自动轮换）。
• agent.yaml 中只允许出现 credential_id ，绝不允许出现 key 、 secret 、 token 等字眼。
• CI/CD pipeline 中， agent.yaml 文件禁止包含任何敏感信息，必须通过变量注入。

5.4 性能瓶颈定位：不是模型慢，是 tool 调用链在拖后腿

很多团队一看到 p95 延迟高，第一反应是换更大模型。错！在我们分析的 83 个生产 agent 中， 92% 的性能问题根源在 tool 层 ，而非 model。

典型瓶颈链：

• DNS 解析慢 ：sandbox 首次访问某个域名，DNS 查询耗时 2-3s。解决方案：在 agent 启动时，预热常用域名（ dig api.claude.com ）。
• TLS 握手慢 ：调用新服务时，首次 TLS handshake 耗时 800ms+。解决方案：启用 TLS session resumption（在 tool client 中配置 ssl_context.set_session_cache_mode(ssl.SSL_SESS_CACHE_CLIENT) ）。
• JSON 序列化/反序列化 ：一个 5MB 的 OCR 结果 JSON， json.loads() 耗时 1.2s。解决方案：改用 orjson （比标准库快 5 倍）或流式解析。

我们开发了一个 tool-benchmark.py 脚本，对每个 tool 进行压力测试：

import time
import orjson
from my_tool import call_weather_api

# 测试 100 次调用
durations = []
for _ in range(100):
    start = time.time()
    resp = call_weather_api("Beijing")
    # 记录从发起请求到拿到 parsed JSON 的总时间
    end = time.time()
    durations.append(end - start)

print(f"p50: {sorted(durations)[50]:.3f}s, p95: {sorted(durations)[95]:.3f}s")

这个脚本集成进 CI，任何 tool 的 p95 > 500ms，PR 直接被拒绝。

6. 价值迁移的三大锚点：当 runtime 归零，钱流向哪里？

6.1 Trace Store：从日志仓库到法律证据链的跃迁

当 runtime 层 commoditize，trace store 就不再是“锦上添花的可观测性工具”，而是 企业数字资产的核心载体 。想象一下：一个 agent 在处理一笔跨境并购尽调时，调用了 17 个数据源，生成了 3 份风险报告。如果发生纠纷，监管机构或法院要求提供“决策依据”，你拿什么交？不是最终 PDF，而是那条包含了所有 tool 调用输入/输出、model 思考链、guardrail 触发记录的完整 event log。

目前市场上，三大 trace store 的定位差异明显：

• LangSmith ：生态绑定最强，LangChain 用户开箱即用，但深度定制能力弱，企业级 SSO/SAML 支持有限。
• Arize Phoenix ：开源（Apache 2.0），可私有化部署，对 trace schema 的扩展性极强（支持自定义 event type），适合需要深度合规审计的金融、医疗客户。
• Braintrust Brainstore ：专为 AI 优化的 OLAP 数据库，查询性能碾压通用数据库（10 亿 event 的复杂 join 查询 < 2s），但商业版价格高昂，适合超大规模场景。

我们为客户做的选型决策树很简单：

• 如果你用 LangChain 且团队 < 20 人 → LangSmith（省事）
• 如果你需要 SOC2 Type II 认证、私有化部署、自定义 retention policy