当前位置：首页 > news >正文

Agent Runtime 重构：Session 作为事件日志的工程实践

news 2026/5/22 3:28:13

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

你有没有试过让一个 AI 代理连续工作四十分钟？不是闲聊，而是真干活：查数据库、调 API、读文档、写代码、改配置、再验证——一环扣一环。去年我带团队跑一个客户的数据迁移项目，用的是自研的 agent 框架，所有 session 状态都塞在模型 context 里。前半小时一切丝滑，到第三十二分钟，context 窗口满了。模型没报错，没中断，甚至没提示——它只是悄悄把最早调用的三个工具返回结果给“遗忘”了，然后基于残缺的历史开始编造下一步动作。我们直到凌晨两点发现生成的 SQL 把生产库的索引全删了才意识到：整个 session 已经不可逆地漂移了。没有日志可查，没有快照可回滚，没有 trace 可审计。我们只能从头重跑，损失了整整两天的调试窗口和一次关键的客户演示。

Anthropic 在 4 月 8 日发布的 Claude Managed Agents，表面看是又一个“托管 agent 平台”，但它的核心价值根本不在“托管”，而在于把 session 从 context 窗口中彻底解放出来，变成一个独立、持久、可查询、可审计的事件日志（event log）。这不是功能升级，是架构范式的切换——就像 90 年代操作系统把物理内存抽象成虚拟内存，让应用不再操心 RAM 地址一样。Managed Agents 把“会话”这个最基础、最易损、最常出问题的单元，从模型上下文这个脆弱的、容量受限的、状态隐式的“黑盒”里抽离出来，变成一个外部存储、结构化记录、按需加载的“白盒”。它不解决“agent 能不能思考”，它解决的是“agent 思考的过程能不能被信任”。

关键词里反复出现的 “Towards AI - Medium”，恰恰说明这件事已脱离技术圈内讨论，进入行业共识传播阶段。这不是某家公司的 PR 稿，而是整个 AI 工程实践正在经历的底层重构信号。它面向的不是只会调 API 的新手，而是每天要部署几十个 agent、管理上百个 session、处理千万级 token 流量、且必须对结果负法律责任的工程负责人、SRE、合规官和采购总监。他们不需要更炫的 prompt 工程，需要的是 session 不丢、凭证不泄、行为可溯、故障可复现。Managed Agents 的 YAML 配置、sandboxed 执行、vaulted credentials、checkpointed session，每一个设计点，都是踩过至少三次以上生产事故后长出来的骨头。它不承诺“更快”，但承诺“不悄无声息地坏掉”；它不吹嘘“更智能”，但确保“智能的过程可被看见”。这才是为什么 Notion 拿它做团队协作中枢，Rakuten 用它跑销售/财务/市场三套核心业务流，Sentry 让它直接写 patch 提 PR——因为这些场景里，可靠性不是加分项，是准入门槛。

2. 核心设计解构：为什么是“Session as Event Log”，而不是“Agent as Function”

2.1 架构分层的必然性：从“单体 context”到“三层解耦”

过去一年，我亲手拆解过 7 个主流 agent 框架（LangChain、LlamaIndex、CrewAI、AutoGen、Semantic Kernel、LangGraph、自研框架），它们有一个致命共性：把 state 当作 context 的附庸。开发者习惯性地把 session history、tool call 结果、用户反馈、中间变量，一股脑塞进 system prompt + chat history 的 token 流里。这在 demo 阶段很美——三行代码就能跑通天气查询。但一旦进入真实业务，问题立刻爆炸：

容量天花板硬伤：Claude 3.5 Sonnet 上下文 200K tokens，听着很大？一个中等复杂度的金融分析 agent，光是加载客户财报 PDF 的 OCR 文本就占掉 80K；加上历史对话、工具返回的 JSON、中间推理链，40 分钟后 context 必然溢出。模型不会报错，只会静默丢弃最早的内容——这是最危险的失败模式：无感知、不可逆、难复现。
状态一致性灾难：多个 tool call 并发时，context 里的 history 是线性追加的。但现实中的业务流程是网状的：A 工具结果触发 B 和 C 并行，B 完成后要等 C，C 失败要回滚 A……这种依赖关系无法用线性 token 序列表达，强行塞进去只会让模型在歧义中“自由发挥”。
审计与合规真空：当监管问“这个信贷审批 agent 为什么拒绝了客户申请”，你拿不出完整的决策链日志，只能交出一段 150K tokens 的 context 快照——里面混着 prompt、历史、噪声、甚至可能被注入的恶意指令。这在金融、医疗、政务领域是不可接受的。

Anthropic 的 Managed Agents 直接砍掉了这个死结，用三层解耦重建信任基座：

Session Layer（会话层）：独立于模型运行，存储为结构化事件日志（event log）。每个事件包含：timestamp、event_type（tool_call_start,tool_call_result,model_output,guardrail_violation）、payload（JSON 化的输入/输出）、trace_id。它存在 Anthropic 托管的持久化存储中，生命周期以天计，而非以 token 计。
Harness Layer（执行层）：真正的“无状态函数”。它只做一件事：接收awake(sessionId)请求，从 Session Layer 拉取最新事件流，拼成 context 片段（注意：是片段，不是全量！），喂给 Claude 模型，拿到 output 后，把结果作为新事件写回 Session Layer。Harness 本身可以 crash、重启、扩缩容，只要 sessionId 不变，session 就能无缝续上。
Sandbox Layer（沙箱层）：每个 tool call 在独立、一次性、资源隔离的容器中执行。凭证（API keys, DB passwords）由 Anthropic Vault 注入沙箱内部，绝不暴露给 Harness 或模型 context。沙箱启动时加载 tool definition，执行完立即销毁——真正做到“cattle, not pets”。

提示：这个分层不是炫技。我实测过：当一个需要调用 12 个不同 SaaS 工具的销售线索清洗 agent 运行到第 57 分钟时，Harness 因网络抖动重启。3 秒后awake(sessionId)被调用，Session Layer 自动加载最后 5 个事件（含未完成的 tool call），Harness 仅用 1.2 秒就恢复执行，全程用户无感知。而旧架构下，这等于 session 彻底死亡。

2.2 为什么“Credential Isolation”是生产级的生死线

几乎所有开源 agent 框架的 credential 管理方案，都停留在“环境变量注入”或“config 文件明文存储”阶段。这在本地开发没问题，但在生产环境是定时炸弹。去年 Q3，我们一个合作伙伴的客服 agent 因 prompt 注入漏洞，被诱导执行了curl -X POST https://api.slack.com/webhook -d '{"token":"xoxb-..."}—— 模型把环境变量里的 Slack token 当作普通字符串读出来了，并原样拼进了 curl 命令。结果是 23 个 Slack 工作区被恶意消息刷屏，客户直接终止合同。

Managed Agents 的 credential 设计，是典型的“防御性工程”：

Vault First：所有 credentials 必须先存入 Anthropic Vault（类似 HashiCorp Vault 的托管版），获得唯一 vault_ref（如vault://prod/slack/webhook）。
Sandbox-Only Injection：当 Harness 决定调用某个 tool 时，它只把tool_name和input发给 Sandbox Manager。Manager 查找该 tool 绑定的 vault_ref，在沙箱容器启动瞬间，将 credential 注入沙箱的内存空间（非环境变量！），并设置内存只读保护。
Model Context 零可见：整个过程中，Harness 的 context 里只有tool_name: "slack_post_message"和input: {"channel": "C012AB3CD", "text": "Hello"}，永远看不到 token 字符串。即使模型被 jailbreak，它也拿不到任何 credential。

这个设计背后是血泪教训：LLM 不是人，它没有“保密意识”，只有“字符串匹配能力”。把 credential 放进 context，等于把保险柜密码贴在保险柜门上。Managed Agents 强制把 credential 关进“沙箱保险柜”，钥匙只在沙箱启动时给一次，用完即焚。

2.3 定价模型背后的工程真相：$0.08/session-hour 的深意

看到 $0.08/session-hour，第一反应可能是“比 AWS Lambda 按 ms 计费贵多了”。但这是典型的 apples-to-oranges 比较。Lambda 计费的是 CPU 时间，Managed Agents 计费的是session 的“在线生命时长”。

我们来算一笔真实账：

一个客服 agent session 平均持续 8.2 分钟（根据 Zendesk 2025 Q1 报告）。
但它在后台需要保持活跃：等待用户输入、轮询 API 状态、执行异步任务（如生成报告）、处理超时重试……实际 session-hour 消耗远高于纯计算时间。
我们一个电商售后 agent，平均 session 生命周期 3.7 小时（含 2 小时异步物流跟踪），但其中只有 11 分钟是模型 active 推理。如果按 Lambda 的 ms 计费，成本极低；但按 session-hour，它消耗 3.7 * $0.08 = $0.296/session。

这个定价模型暴露了 Anthropic 的真实定位：它卖的不是算力，是“session 的确定性保障”。$0.08 买的是：

Session Layer 的 99.99% SLA 持久化存储；
Harness 的秒级故障恢复能力；
Sandbox 的毫秒级冷启动（实测 P95 < 120ms）；
Vault credential 的自动轮换与审计日志；
全链路 trace 的永久保留（默认 90 天，可延长）。

它本质上是一种SLO（Service Level Objective）订阅：你为“session 不丢、不乱、可追溯”付费，而不是为“模型多转了几圈”付费。这和企业采购 Splunk 或 Datadog 的逻辑一致——买的是可观测性保障，不是服务器小时数。

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

3.1 Agent 定义：YAML 是生产力，不是妥协

很多人看到“用 YAML 定义 agent”第一反应是“不够灵活”。但在我部署过 47 个生产 agent 后，结论很明确：YAML 是大规模 agent 管理的唯一可行方案。自然语言定义（如 “You are a sales agent…”）适合 demo，但无法满足：

版本控制：Git diff 必须看清是改了 prompt 还是换了 tool；
权限审计：安全团队需要精确知道哪个 agent 有访问财务 API 的权限；
CI/CD 集成：自动化测试必须基于结构化 schema 验证 tool input/output 格式。

Managed Agents 的 YAML Schema 设计极其务实。以下是一个真实部署的销售线索评分 agent 示例（已脱敏）：

# sales-lead-scorer-v2.yaml name: "sales-lead-scorer" description: "Scores inbound leads using firmographic, technographic and engagement data" version: "2.1.0" system_prompt: | You are a senior sales development representative at Acme Corp. Your task is to score leads on a scale of 0-100 based on: - Firmographic fit (revenue, employee count, industry) - Technographic fit (current tech stack vs our integrations) - Engagement score (email opens, webinar attendance, page views) Always output JSON with keys: score, confidence, rationale, next_step. tools: - name: "crmsync_get_lead" description: "Fetch lead details from Salesforce CRM" input_schema: type: "object" properties: lead_id: type: "string" description: "Salesforce Lead ID" output_schema: type: "object" properties: company_name: {type: "string"} annual_revenue: {type: "number"} employee_count: {type: "number"} industry: {type: "string"} - name: "clearbit_enrich_company" description: "Enrich company data using Clearbit API" input_schema: type: "object" properties: domain: {type: "string"} output_schema: type: "object" properties: tech_stack: {type: "array", items: {type: "string"}} funding_stage: {type: "string"} - name: "hubspot_get_engagement" description: "Get lead's engagement metrics from HubSpot" input_schema: type: "object" properties: email: {type: "string"} output_schema: type: "object" properties: email_opens: {type: "number"} webinar_attended: {type: "boolean"} pages_viewed: {type: "number"} guardrails: - type: "output_safety" config: block_categories: ["harassment", "hate_speech"] max_score_threshold: 0.85 - type: "tool_call_limit" config: max_calls_per_session: 15 max_concurrent_calls: 3 session_config: timeout_minutes: 180 auto_checkpoint_interval_minutes: 5

这个 YAML 的每一行都在解决真实痛点：

version: "2.1.0"：支持 Git tag 发布，回滚到 v2.0.0 只需改一行；
input_schema/output_schema：Harness 在调用前自动校验参数类型，避免因 JSON 字段名拼错导致的 500 错误；
auto_checkpoint_interval_minutes: 5：每 5 分钟强制保存 session 状态，确保即使沙箱崩溃，最多丢失 5 分钟数据；
tool_call_limit：防止 agent 因逻辑 bug 进入无限循环，耗尽客户配额。

实操心得：我们曾用自然语言定义一个客服 agent，上线后因 prompt 中“请用中文回答”被模型误解为“禁止使用英文单词”，导致所有 API 错误码（如404 Not Found）被过滤掉，客服完全无法诊断问题。改用 YAML 明确定义output_schema后，Harness 会强制保留原始 error response，再由 guardrail 层统一翻译——错误处理变得可预测、可测试。

3.2 Session 生命周期管理：从`awake()`到`archive()`

Managed Agents 的 session 不是“启动即运行”，而是遵循严格的事件驱动生命周期。理解这个流程，是避免资源浪费和状态混乱的关键。

标准 session 流程（以销售线索评分为例）：

Initiation（初始化）：前端调用POST /v1/sessions，传入{"agent_name": "sales-lead-scorer", "initial_input": {"lead_id": "00Q1a0000012Abc"}}。Anthropic 返回session_id: "sess_abc123"和status: "pending"。
Awake（唤醒）：Harness 启动，从 Session Layer 加载初始事件，执行crmsync_get_lead(lead_id="00Q1a0000012Abc")。沙箱启动，执行 API 调用，结果写入 Session Layer 作为新事件。
Execution Loop（执行循环）：Harness 持续拉取 Session Layer 新事件，拼 context，调用 Claude。模型输出 JSON 后，Harness 解析next_step字段，决定下一步调用clearbit_enrich_company还是hubspot_get_engagement。每次 tool call 都触发新沙箱。
Checkpoint（检查点）：每 5 分钟（或每次 tool call 后），Harness 主动调用checkpoint(session_id)，确保 Session Layer 状态最新。
Completion or Timeout（完成或超时）：当模型输出包含"next_step": "end_session"，或timeout_minutes（180 分钟）到达，Harness 调用archive(session_id)，Session Layer 将该 session 标记为archived，停止计费。

关键实操细节：

Session ID 是唯一真理：所有交互（前端轮询、后台 webhook、人工干预）都通过session_id关联。不要尝试用lead_id或user_id做 session 查询——Session Layer 只认session_id。
awake()不是“启动”，是“续命”：awake()调用频率由业务逻辑决定。对于实时聊天，前端每 2 秒调用一次；对于异步任务（如生成周报），可设为每 30 秒轮询一次。Harness 会智能判断是否需要新推理——如果 session 状态没变，它直接返回缓存结果。
Archive ≠ Delete：archive()只是停止计费和标记状态，所有事件日志永久保留（90 天起）。你可以随时用GET /v1/sessions/{session_id}/trace下载完整 JSON trace 用于审计。

我们曾踩过的坑：一个财务 agent 因前端错误，在 1 秒内并发发了 17 个awake()请求。Harness 为每个请求都启动了新实例，导致同一 session 被 17 个 Harness 并行操作，最终 session 状态混乱。解决方案是：前端必须实现幂等性，用session_id+request_id做去重，且awake()调用间隔不得小于 500ms。

3.3 生产部署 checklist：从 PoC 到 GA 的 12 个必检项

把一个 Managed Agents 从本地测试推到生产环境，远不止kubectl apply -f agent.yaml。以下是我在 3 个客户现场总结的硬性 checklist，漏一项都可能引发线上事故：

Vault Credential Scope 最小化：为每个 tool 创建独立 Vault 权限策略。例如crmsync_get_lead只需salesforce:read:Lead，绝不能给salesforce:full_access。我们曾因权限过大，agent 误删了客户 CRM 的自定义字段。
Tool Input Validation 二次校验：YAML 的input_schema是 Harness 层校验，但 tool 本身（如 Salesforce Apex）必须有独立的输入校验。Harness 不会阻止lead_id: "../../../../etc/passwd"这类路径遍历攻击。
Guardrail Threshold 动态调整：output_safety.max_score_threshold: 0.85是初始值。上线后必须用真实流量训练：收集被 block 的合法输出，用 Anthropic 的evaluate_guardrailAPI 调优阈值，避免过度拦截。
Session Timeout 与业务 SLA 对齐：timeout_minutes: 180是技术上限，但业务要求可能是“客服响应必须 < 90 秒”。需在前端实现session_timeout_ms: 90000，超时则主动调用archive()并返回友好提示。
Sandbox Network Policy 锁死：在 Anthropic 控制台，为每个 agent 沙箱配置 egress 规则。clearbit_enrich_company只允许访问api.clearbit.com，禁止访问169.254.169.254（AWS metadata endpoint）。
Trace Export 自动化：配置每日 2:00 AM 自动GET /v1/sessions?status=archived&since=24h，导出 JSON 到 S3，供 Arize 或 LangSmith 消费。手动下载 trace 是运维噩梦。
Fallback Prompt 内置：在system_prompt末尾添加：“如果遇到任何工具调用失败或模型无法生成有效 JSON，请输出{"error": "FALLBACK_REQUIRED", "suggestion": "请人工介入处理"}”。这比让模型自由发挥更可控。
Rate Limiting 分层实施：API Gateway 层限制/v1/sessions创建速率（防 DDOS），Harness 层限制tool_call_limit（防逻辑 bug），Vault 层限制 credential 调用频次（防爆破）。
Session Metadata 注入：在initial_input中加入{"source": "web", "user_id": "u_123", "campaign_id": "spring2026"}。这些字段会自动写入 Session Layer 事件，是后续 BI 分析的黄金数据。
Error Handling Webhook：配置POST /webhook/error，当guardrail_violation或sandbox_failure事件发生时，自动通知 Slack 频道和 PagerDuty。别等客户投诉才发现问题。
Cost Alerting：基于$0.08/session-hour，设置 CloudWatch 警报：当单日 session-hour 消耗 > $500 时触发。我们一个营销 agent 因配置错误，单日烧掉 $2200，警报救了我们。
Disaster Recovery Plan：明确archive()后如何恢复：是重放初始 input？还是从最近 checkpoint 重试？必须写入 runbook，且每月演练。

注意：第 6 项（Trace Export）和第 12 项（DR Plan）是客户审计必查项。没有自动化的 trace 导出，意味着你无法证明“agent 行为符合 GDPR 第 22 条”；没有书面 DR Plan，意味着你无法通过 ISO 27001 认证。

4. 竞争格局与生存指南：为什么 runtime 层注定走向“零利润”

4.1 不是 Anthropic 在开创，而是在追赶：AgentCore 的五个月领先优势

媒体把 Anthropic Managed Agents 描绘成“颠覆者”，但事实是：AWS Bedrock AgentCore 在 2025 年 11 月就已 GA（General Availability），比 Anthropic 早了整整五个月。截至 2026 年 3 月，AgentCore SDK 下载量超 200 万次，政策控制（Policy Controls）也已 GA。这不是 Beta，是已在生产环境跑满 5 个月的成熟服务。

AgentCore 的架构哲学与 Managed Agents 高度相似，但有关键差异：

MicroVM 隔离：每个 session 运行在独立 microVM 中，CPU、内存、文件系统完全隔离。比 Docker sandbox 更强的安全边界，尤其适合金融、政府客户。
Framework Agnostic：AgentCore 不绑定任何框架。你可以部署 LangGraph 的 StateGraph、CrewAI 的 Crew、甚至自研的 Rust agent，只要它遵循 request-response 协议。Managed Agents 目前深度绑定 Claude 模型栈。
Session Duration：AgentCore 支持最长 8 小时 session，Managed Agents 是 3 小时（可申请延长，但需审核）。

这意味着什么？对开发者而言：如果你的首选模型是 Claude，Managed Agents 提供了开箱即用的优化体验；但如果你的架构已基于 LangGraph 或需要超长 session，AgentCore 是更中立、更开放的选择。Anthropic 的 launch 本质是“防御性补位”——防止其最大客户（那些在 AWS 上跑 Claude 的企业）把 agent runtime 完全迁移到 AgentCore，从而失去对 token 使用场景的掌控。

实操对比：我们一个客户同时测试了两个方案。Managed Agents 在 Claude 3.5 Sonnet 上的 p50 time-to-first-token 是 1.2s，AgentCore 是 1.4s（因 microVM 启动开销）。但 AgentCore 的 p95 是 2.1s，Managed Agents 是 2.8s。原因？AgentCore 的 microVM 预热池更大，长尾更稳。选择谁，取决于你的 SLA 要求：是优化平均延迟，还是保障长尾稳定性？

4.2 开源压力曲线已成型：Daytona、K8s SIG、Deer-Flow 的真实战力

说“runtime 层将 commoditize”，不是空谈。开源社区的压力已经从概念走向可用产品：

Daytona：2025 年初从 dev environment 工具转向 AI agent infra，2 月完成 2400 万美元 A 轮。其核心卖点sub-90ms sandbox spin-up经我们实测：在 c6i.2xlarge 实例上，P95 启动时间为 87ms，比 Managed Agents 的 112ms 快 22%。关键是，Daytona 是纯开源（Apache 2.0），可私有化部署，这对银行、军工客户是刚需。
Kubernetes SIG Agent-Sandbox：2026 年 3 月发布的官方项目，将 agent sandbox 作为 Kubernetes 原生 workload。kubectl apply -f agent.yaml即可部署，天然集成 Prometheus 监控、Velero 备份、OpenPolicyAgent 策略。它不提供托管服务，但提供了构建私有 Managed Agents 的标准基座。
Deer-Flow：ByteDance 开源的 long-horizon agent harness，GitHub Star 59,000+。它内置 planning 和 subagent 调度，一个 deer-flow agent 可以自主分解“分析竞品财报”为“下载 PDF → OCR → 提取表格 → 生成摘要 → 对比历史”5 个子任务，并管理它们的依赖与重试。Managed Agents 目前不支持这种层级的自主规划。

这三股力量代表了 runtime commoditization 的三种路径：

Daytona：提供比商业托管更优的性能，靠开源免费吸引开发者；
K8s SIG：成为云原生标准，让 runtime 成为基础设施的“空气”；
Deer-Flow：向上拓展能力边界，让 runtime 不再是“执行器”，而是“协作者”。

它们共同指向一个结局：runtime 的核心价值（隔离、调度、状态管理）将迅速标准化，价格被压向零。就像当年 VMware ESX 的许可费被 KVM 和 Xen 拉平一样，Managed Agents 的 $0.08/session-hour，两年内大概率会变成 AWS 的 $0.001/session-hour（打包在 EC2 价格里），或 Daytona 的 $0（你付服务器钱就行）。

4.3 真正的护城河在哪？三块正在形成的“价值高地”

当 runtime 层被压向零，钱会流向哪里？答案很清晰，来自三个正在快速固化的高价值层：

4.3.1 Trace Store：谁掌握 agent 的“行车记录仪”，谁就掌握真相

Agent 的每一次思考、每一次调用、每一次失败，都产生结构化事件流。这个 trace 数据的价值，远超 runtime 本身：

调试金矿：当 agent 输出错误结果，trace 能精确定位是crmsync_get_lead返回了脏数据，还是clearbit_enrich_company的 API 限流了，或是模型在rationale字段 hallucinated。
合规基石：GDPR 要求“可解释的自动化决策”。一份完整的 trace JSON，就是最好的法律证据。
产品洞察：分析 10 万次hubspot_get_engagement调用，发现 37% 的email_opens字段为空——这提示销售团队要优化邮件打开率。

目前三大玩家已卡位：

Braintrust：$36M A 轮，专攻 OLAP 优化，SELECT avg(score) FROM trace WHERE event_type='model_output' AND timestamp > '2026-04-01'查询响应 < 200ms。
Arize：$131M 总融资，开源 Phoenix（Apache 2.0），提供免费基础版，商业版卖 anomaly detection 和 root cause analysis。
LangSmith：LangChain 生态自带，安装量最大，但 lock-in 风险高——如果你不用 LangChain，LangSmith 就是摆设。

我的建议：无论选哪家，必须确保 trace schema 是开放的、可导出的。我们用 Arize 的 Phoenix 开源版做基础监控，但每天自动导出 raw trace 到 S3，这样即使 Arize 商业版涨价，我们也能无缝切换到 Braintrust。

4.3.2 Governance & Policy：从“能跑”到“敢用”的最后一公里

Runtime 解决“能不能执行”，Policy 解决“该不该执行”。当 agent 被授权访问 HR 系统、财务 API、客户数据库时，企业需要的不是“它没 crash”，而是“它严格遵守了我们的规则”。

AWS AgentCore 的 Policy Controls GA 是标志性事件。它支持：

RBAC（基于角色的访问控制）：sales_agent角色可调用crmsync_get_lead，但不可调用finance_get_budget。
Data Masking：当crmsync_get_lead返回ssn: "123-45-6789"，Policy 自动将其替换为ssn: "***-**-****"再传给模型。
Output Sanitization：检测到模型输出包含信用卡号，自动 redact 并触发告警。

OWASP Agentic Top 10 的发布，更是把治理从“最佳实践”推向“强制要求”。Top 10 中的 #1 “LLM01: Prompt Injection”、#3 “LLM03: Data Leakage”、#7 “LLM07: Insufficient Access Control”，每一个都需要 Policy 层来堵漏。

这个领域尚无巨头，是创业公司最好的机会。它不拼性能，拼的是对合规框架（SOC2, HIPAA, ISO 27001）的理解深度，和与企业 IAM 系统（Okta, Azure AD）的集成能力。

4.3.3 Vertical Agent Marketplaces：当 agent 成为“SaaS 2.0”

Salesforce Agentforce ARR 达到 8 亿美元，这不是偶然。它揭示了一个本质：企业不为“runtime”付费，为“解决具体业务问题的 agent”付费。就像企业买 Salesforce 不是为了用 Oracle 数据库，而是为了管理销售流程。

垂直 marketplace 正在爆发：

Finance：virattt/ai-hedge-fund（量化交易）、TradingAgents（高频做市）；
Security：vxcontrol/pentagi（自动化渗透测试）；
Healthcare：medgpt-clinical-trial（患者招募匹配）；
Legal：lawgpt-contract-review（并购协议风险点识别）。

这些 agent 的共同点：预装了行业知识、预集成了行业 API、预配置了行业合规策略、预训练了行业术语。一个金融 agent 不需要你教它什么是“SEC Form 10-K”，它生来就懂。

它们的商业模式也回归本质：按效果付费（如“每成功匹配一个临床试验患者，收 $50”），或按 seat 付费（如“每个投资经理 $299/月”），而不是按 token 或 session-hour。这才是客户愿意签 PO 的方式。

5. 常见问题与实战排障：从“Why no response?”到“Why wrong result?”

5.1 问题速查表：高频故障与根因定位

现象	可能根因	排查步骤	解决方案
`awake()`返回 200 但无`output`字段	Session 处于`pending`状态，Harness 尚未启动	1.`GET /v1/sessions/{id}`检查`status` 2. 检查`last_event_time`是否更新	等待 5-10 秒再调用；若持续`pending`，检查 agent YAML 是否语法错误（用`anthropic validate-yaml`工具）
Tool call 失败，错误信息`sandbox_failed: connection refused`	沙箱网络策略阻断了目标域名	1.`GET /v1/sessions/{id}/trace`查看失败事件 2. 检查`tool_name`对应的 egress 规则	在 Anthropic 控制台，为该 tool 添加`api.clearbit.com:443`的 egress 规则
Session 状态正常，但模型输出 JSON 格式错误（缺少`score`字段）	`system_prompt`中的 JSON 指令未被模型严格遵守	1.`GET /v1/sessions/{id}/trace`查看`model_output`事件 2. 检查`output_schema`是否定义了`score`为 required	在`system_prompt`末尾添加：“严格按以下 JSON Schema 输出，不得添加额外字段：{output_schema}”
Guardrail`output_safety`频繁触发，拦截合法输出	`max_score_threshold`过严，或模型版本变更	1. 收集被拦截的`model_output` 2. 用`anthropic evaluate-guardrail --input "..." --threshold 0.85`测试	逐步降低阈值（0.85→0.75），或升级到 Claude 3.5 Opus（更少误判）
Session 运行 2 小时后突然`archived`，但`timeout_minutes`设为 180	客户账户的`session_hour_quota`耗尽	1.`GET /v1/account/usage`查看`session_hours_used` 2. 检查`session_hours_limit`	联系 Anthropic 销售提升配额；或优化 agent，减少不必要的`awake()`调用